- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sun, 2 Jan 2011 23:46:58 +0000
- To: Stephen Green <stephendgreenweb@gmail.com>
- Cc: John Cowan <cowan@mercury.ccil.org>, public-html-xml@w3.org
On Sun, Jan 2, 2011 at 6:58 PM, Stephen Green <stephendgreenweb@gmail.com> wrote: >> HTML plus JS is more risky than just HTML by itself. > > [snip] > >> CSS encourages semantic (or "abstract behavior") markup, protecting >> the uniform interface. > > Please excuse an interjection from an end-user of the Web and its > browsers but the idea that the 'interface' has to be kept so uniform > sounds great for the workload of browser producers but sounds like > pure boredom for us web developers. The rationale I advanced primarily protects the interests of service consumers, especially ordinary people trying to use the web to access news, read email, network with friends, write blogs and tweets, perform research, buy things from stores, download musical scores, etc. with some measure of reliability and safety and without suffering discrimination because of their abilities or culture. > If nobody had added Javascript to browsers and they had only ever > implemented pure text/html then it might have saved end users the need > for antivirus software, etc but we would never have had webmail, etc > and the lack of fun could have killed the Internet off by now. Is developer boredom supposed to be a serious rationale for feature bloat? Couldn't we be distracted with shiny objects or lolcats instead? Most of the services on WWW (including webmail) can be provided with unscripted HTML. The exceptions can be provided without JS using other forms of code-on-demand. However, I'm not saying JS should not have been added to browsers. I /am/ saying HTML has been and should continue to be designed from the perspective that consumers may not apply JS, so introducing lots of arbitrary vocabularies that depend on JS is a bad idea. > The arguments against improved XML support in browsers sound like > arguments against javascript in browsers might have sounded way back - > only likely to make the Web more boring and kill it off. Nobody is arguing against improved XML support in browsers. The discussion here is purely about text/html, a document-specific media type that is *not* XML. > It took ages for databases to almost natively support XML but they got > there in the end and I expect it has been very helpful for end-user > developers, even those who didn't embrace XML for some time. That > browsers - so close to the same W3C who gave us XML - so much more > drag their feet than database producers seemed to do is somewhat > ridiculous. As far as I can tell XML support isn't especially lacking. You can make up your own gobbledygook vocabularies, serve them as XML, transform them clientside with XSLT, style them with CSS, script them with JS, annotate them with RDFa, and try/fail to render them accessible with WAI-ARIA in all popular browsers. IE9 even renders application/xhtml+xml, which is not required for "XML support". What's missing? > As one who might merely be an end-user of the outcome of this group I > concur with the use cases. Great, so can you give an example consumer need (not developer wish!) met by Use Case 4? Can you give an example resource exemplifying that need that could not be represented through text plus the available HTML/MathML/SVG semantics plus annotations? Can you explain why - despite the absence of appropriate semantics - text/html is nevertheless a suitable media type for the job? Can you articulate why adding islands of XML would be better than working with W3C to expand the available core semantics? Can you think of any alternative ways of meeting that consumer need, but justify why they aren't as good? > I think they would have been good ones five years ago and maybe don't > go far enough in 2011. If you've got additional use cases, please do bring them to the table. > But better forward than backward - and HTML5 to > date seems to me a bit of a backward step regarding XML support if it > entrenches the attitude that the 'centre' adding selective XML > vocabularies is OK/good but end-users adding XML of their own is bad. > Nice when the centre is as innovative as the outer edge; not nice when > it seems to hold everyone back (even if it is for the sake of a > 'uniform interface'). Stephen, I'll give you the benefit of the doubt and assume that if *you* were concocting a Hypertext Made Up Language to be served as text/html you would spend the necessary time and money to gather all the necessary input to ensure that you're not reinventing the wheel, that it would not clash with other people's present or future efforts, that it was secure, that it could be made accessible to people with different abilities using different devices and software, that it was adaptable to the needs of different cultures, that it had a test suite against which people could assess their implementations, and that there were provisions to ensure your content would still be usable in a decade's time. In other words, you'd make up for everything you'd have lost for not going through the process of standardizing an addition to HTML. I see plenty of historical evidence to suggest that would not be the general approach. For example, frameworks reinventing widgets as divs like Dojo had accessibility so bad W3C had to add a whole new layer (WAI-ARIA) to the web stack to try to repair it when (surprise!) it turned out people with disabilities also use the web. Look at how Apple reinvented graphics as canvas without consultation, then Mozilla built Bespin on top without accessibility, and now the W3C is scrabbling around trying to retrofit accessibility to canvas because - hey - people with disabilities were forgotten /again/. Even within the W3C itself, groups working on different XML dialects reinvent the wheel for basic facilities like hyperlinks, text structure, formatting, and embedding multimedia. Extrapolating from history, I expect such extensions will join the legion of fashionable techniques abused by hundreds of developers profiteering off superficially flashy but ultimately inaccessible, flaky, and insecure interfaces to the on-going detriment of millions of end-users. HTML is a language for document/application semantics, not a arbitrary serialization format like XML. What value is there in HTML conformance if conformant HTML is not interoperable? If you don't think the centre's oversight has value then why are you desperate for it to bless external "innovation" with conforming status? Just go ahead and serve gobbledygook as text/html. What more do you want? A "Valid Gibberish" badge? -- Benjamin Hawkes-Lewis
Received on Sunday, 2 January 2011 23:47:31 UTC