Re: Use cases

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