Subject: Re: [xsl] browsers with XSL capabilities From: Robert Koberg <rob@xxxxxxxxxx> Date: Fri, 16 Mar 2001 16:58:03 -0800 |
> That would be cool. Until then, why wait? Just have the editors get IE5.5 and it can be done now. I am so close... if it wasn't for this damn puppy my girlfriend left me with this week :) (he is too cool and I can't stop playing with him) No server server-side lag-time and IE5.5 renders much faster than any of the server-side processors I have used (I am on win2000) ----- Original Message ----- From: "Evan Lenz" <elenz@xxxxxxxxxxx> To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx> Sent: Friday, March 16, 2001 4:54 PM Subject: RE: [xsl] browsers with XSL capabilities > 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 > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] browsers with XSL capabil, Evan Lenz | Thread | Re: [xsl] browsers with XSL capabil, Larry Garfield |
RE: [xsl] browsers with XSL capabil, Evan Lenz | Date | Re: [xsl] Is XSLT the right name?, Larry Garfield |
Month |