Re: Use cases

> 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. 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. 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.

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 one who might merely be an end-user of the
outcome of this group I concur with the use cases. I
think they would have been good ones five years ago
and maybe don't go far enough in 2011. 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').

Cheers and new year greetings

Stephen D Green

On 2 January 2011 18:14, Benjamin Hawkes-Lewis
<bhawkeslewis@googlemail.com>wrote:

> On Sun, Jan 2, 2011 at 5:57 AM, John Cowan <cowan@mercury.ccil.org> wrote:
> >> Nor are all scripts trusted.
> >
> > Not all content can be trusted either, for that matter.
>
> HTML plus JS is more risky than just HTML by itself.
>
> >> If you want to maximize the RESTful characteristics of the (world
> >> wide) web, do not rely on code-on-demand facilities for your default
> >> representations.
> >
> > I might say with equal justice: do not rely on the facilities of Grade-A
> > browsers in general.
>
> Yes. You can use the user-agent header to serve simpler even simpler
> representations
> to known bad browsers. Compare:
>
> http://developer.yahoo.com/yui/articles/gbs/
>
> > I am reluctant to call "button" or even "p" *meaning*.  Abstract
> behavior,
> > if you like.  But if I were marking up this email for *meaning*, I would
> > probably use a "counterargument" element rather than a "p" element for
> > this paragraph.
>
> If you want to use that language, you're on your own, but if you
> prefer, HTML does not need another way to express "abstract behavior".
>
> >> I see no value in making semantics indirect via CBS.
> >
> > Why is it less valuable than making presentation indirect via CSS?
>
> CSS encourages semantic (or "abstract behavior") markup, protecting
> the uniform interface.
>
> CBS would discourage it by making it an extra step, damaging the
> uniform interface.
>
> Witness all the inaccessible junk built out of divs.
>
> --
> Benjamin Hawkes-Lewis
>
>