This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: browsers with XSL capabilities


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@students.depaul.edu

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

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



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]