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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] browsers with XSL capabil, Robert Koberg | Thread | Re: [xsl] browsers with XSL capabil, Robert Koberg |
Re: [xsl] Is XSLT the right name?, Larry Garfield | Date | Re: [xsl] browsers with XSL capabil, Robert Koberg |
Month |