Re: [xsl] browsers with XSL capabilities

Subject: Re: [xsl] browsers with XSL capabilities
From: Larry Garfield <lgarfiel@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 16 Mar 2001 19:07:24 -0600
I'd actually recommend against such things, as those attributes and features are
IE 5.5 ONLY.  If they were part of the W3C's spec, fine, I'd accept someone
saying "non-conformant browsers can bugger off."  But I would advise against
MS-only extensions in every and all cases.  (Unless I'm way off the mark and
contentEditable is in some W3C spec I haven't read yet, in which case I'll go
back to my cave and shut up.)

Evan Lenz wrote:

> Robert Koberg wrote:
> > There are some really cool things you can do with IE5.5 - it is a great
> > browser! Editable DIVs and SPANs, etc, control over right click (context
> > sensitive) menus and so much more.
>
> I agree. The contentEditable attribute is quite powerful.
>
> > It would seem that if a good (javascript) developer could come up
> > with a way
> > to "roundtrip" (back to XML) these editable DIVs and SPANs you
> > could have a
> > really cool browser based XML editing system... :)
>
> That would be cool. Until then, you can do server-side XML construction
> based on what the user submits and still get many of the same benefits. If
> you allow them to edit full HTML, which is certainly supported, but only
> scoped to a certain part of the page, then you could store that HTML as text
> content (rather than markup, because its not well-formed) within XML. This
> goes against the basic idea of the separation of presentation and content,
> but not if you consider user-customized presentation as part of the content.
> For example, you could allow them to edit full WYSIWYG HTML but only scoped
> to a certain element on the page. The "real" presentation (generated from
> XSLT on either the server or the client), including things like navbars and
> footers, is read-only with respect to what the user is able to edit.
>
> Unfortunately, since the HTML produced by the browser-based editing is not
> well-formed, you can't do much with that content when you want to display
> the edited page again unless you use XSLT's disable-output-escaping. Tough
> luck if you try this with Cocoon. MSXML3 handles it fine though.
>
> For a small demo, I've put up a temporary page on my website, so you can get
> an idea of what I'm talking about. The server would take the posted data (in
> this case only one field containing HTML-encoded text) and include/replace
> it in the XML source file. The demo requires IE 5.5 but not MSXML.
>
> http://xmlportfolio.com/temp/contentEditable.html
>
> This is a remnant from a past prototype project, so please excuse the messy
> source code.
>
> Evan Lenz
> XYZFind Corp.
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

--
Larry Garfield
lgarfiel@xxxxxxxxxxxxxxxxxxx

Do you have a PalmOS Organizer?  Click here to add me to your address book:
http://signature.coola.com/?lgarfiel@xxxxxxxxxxxxxxxxxxx

-- "If at first you don't succeed, skydiving isn't for you." :-)



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread