OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bad News on IE6 XML Support



* Robin Berjon wrote:
>I see your point, and part of it is valid, yet I disagree.
>
>Accessibility
>
>We now have an excellent document on how to best create an accessible 
>vocabulary (http://www.w3.org/TR/xmlgl).

Someone complained in this thread, IE6 doesn't support 'display: table'
for XML documents. I wonder where this is necessary if you follow
guideline 1.3 of this document, i.e. "Reuse existing accessible modules
to indicate alternative-equivalent associations", but I'm sure you can
tell me.

>Depending on the use case, it's 
>obvious that it could be possible to create a document the structure of which 
>would fit its content much better than XHTML would, or in fact ever could.
>This alone would already promote accessibility, simply by providing better 
>context.

While I wouldn't disagree, that XHTML 1.0 is far away from beeing an
optimal XHTML, I don't see, why you proprietary document language is
considered more accessible than an XHTML document.

>Add to that some form of metadata (which could be rendered directly 
>by the stylesheet) and I think you could get a very accessible document. Yes, 
>we probably miss the tools to go that far (but it'll be a lot easier to 
>create tools to process arbitrary XML documents than tools that process the 
>kind of HTML one sees out there).

As one of the current maintainers of HTML Tidy, I strongly disagree :-)
Applications may use the upcoming HTML Tidy library to get a clean and
where possible valid (X)HTML DOM tree, so this processing argument
doesn't count, but this isn't a point here, either.

>Portability, Interoperability, and Compatibility
>
>We are only talking of having a good clean CSS model.

No, we are talking about whether presentation is everything or known
semantics matter. Building a web upon everyones proprietary document
languages doesn't consider applications relying on semantics (e.g.
search engines) and applications, that don't (maybe can't) implement
CSS. There is a common accessibilty idiom: don't rely on presentation.
Why doesn't this apply here? Maybe I'm really ignorant, but I don't see
why

  Topic { font-size: xx-large }
  ...
  <Topic>Internationalization</Topic>

is better than

  <h1>Internationalization</h1>

Maybe I really missed something and CSS is the new Lingua Franca for the
Web and the most integral part of the Semantic Web?

>I'm only scratching the surface, but imho you loose a *lot* more potential by 
>enforcing a translation to XHTML than you do by styling an adapted vocabulary 
>with CSS.

I'm sure you have examples.

>Plus, it's probably easier to write an aural CSS sheet than to 
>write another XSLT sheet to convert to VoiceML (or whatever other voice 
>markup language).

Hm, I'm sure you can tell me, why XHTML plus CSS doesn't work for Voice
Browsers.

Provide good arguments if you want to convince me. Considering the
amount of people demanding "XML in the browser" and others demanding
"XSLT in the browser" there must be very good arguments, but till now no
one told me about them and I don't see them for myself.
-- 
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/