Re: [xsl] browsers with XSL capabilities

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