Re: Use cases

On Sun, Jan 2, 2011 at 1:37 AM, John Cowan <cowan@mercury.ccil.org> wrote:
> Benjamin Hawkes-Lewis scripsit:
>
>> That is, how might it happen without the web's client software being
>> updated to build interfaces on top of the semantics expressed by those
>> namespaced vocabularies?
>
> The whole point of JavaScript is to make the web's client
> software dynamically updatable.

The *whole* point? Says who?

That's not what Netscape and Sun thought they were doing:

http://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html

It's not what HTML4 claimed to be doing when standardizing how script hooks
into HTML:

http://www.w3.org/TR/html401/interact/scripts.html

It's not why HTML5 includes script hooks:

http://dev.w3.org/html5/spec/scripting-1.html#scripting-1

In my experience, JS tends to work okayish (Grade D) when it composes
interfaces from the building blocks (buttons, links, form fields) of the common
interfaces. It tends to break quite badly (in terms of usability,
accessibility, automation, Grade F) when it doesn't and tries to construct
entirely new building blocks using divs, spans, canvas, and SVG shapes.

> (Of course, not all clients are JavaScript-capable.)

Nor are all scripts trusted.

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.

"Lack of visibility leads to obvious deployment problems if the client cannot
trust the servers."

http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm

On the (world wide) web, you can't trust the servers.

>> My argument is: using arbitrary vocabularies to express renderable
>> content, rather than merely annotate it with metadata, will break
>> those interfaces, and namespaces do *nothing* to help with this
>> situation. How could they?
>
> Some convention must exist to determine which part of a
> dynamically-updated client is to process what.  For SVG-in-HTML5 and
> MathML-in-HTML5 (as distinct from SVG and MathML as XML vocabularies)
> that's the special root elements "svg" and "math".  That convention is
> no more and no less problematic than the namespace convention, except
> that it's simpler because it is more direct (and by the same token
> less extensible).

The pros and cons of namespaces as a disambiguating mechanism are irrelevant to
my argument.

My objection is to substituting arbitrary vocabularies for recognized
vocabularies, not to namespaces. My only essential point about namespaces was
that they are not some sort of fairy dust that cures the RESTless ills of
arbitrary vocabularies.

>>    <foo:whizzbangbutton foo:quux="Do something"></foo>
>>
>> is /just/ gobbledygook. This is bad HTML because the button has not
>> been marked up with an appropriate element, so it cannot be recognized
>> in the uniform interface.
>
> That doesn't work (and only doesn't work) because there is no standard
> declarative way to specify the behavior of an element in the way that
> CSS specifies its appearance.  In a hypothetical CBS, you could write
> "foo|whizzbangbutton { button }" and get interoperability.

First, we should be specifying meaning not behavior so that user agents can
apply behaviors suitable for their purposes.

Second, you could design lots of ways in lots of languages to indicate the
semantics of things.

But text/html already has an way to do that: use elements and attributes that
carry semantics via a commonly recognized vocabulary. It doesn't need another.
("role" already makes this way more complicated and broken than it needs to
be.) If you need a button, use the "button" element. If plain text plus the
commonly recognized vocabulary cannot express your meaning, then we'll need to
add to the vocabulary through the standards process regardless of whether
meaning is carried by markup or CBS.

I see no value in making semantics indirect via CBS. But in so far as CBS could
be used to bind HTML semantics to arbitrary gobbledygook elements, it would be
an equally good solution for binding arbitrary gobbledygook semantics to HTML
elements. So whatever potential CBS has is yet another reason why we don't need
to support arbitrary gobbledygook elements.

In passing, I think it's telling that people are trying to defend
possible solutions to
unstated problems but nobody's jumped forward to better identify the
problem to be
solved.

As I asked earlier:

> What are some example end-user problems this would solve? Might there
> be other (better?) ways to solve them?

--
Benjamin Hawkes-Lewis

Received on Sunday, 2 January 2011 02:37:25 UTC