Re: XBL is (mostly) W3C redundant, and CSS is wrong W3C layer for semantic behavior *markup*

On Sun, 5 Jan 2003, Shelby Moore wrote:
>>| XBL doesn't _have_ any portions which allow non-conformance, 
> When your statement above is proven false with real examples, then I will
> come back here and remind you again how inconsistent you are.

Or you could actually provide examples yourself, as you promised in
one of your e-mails:

| And also I can provide examples which show how to completely change
| the "implemented meaning" of any tag in HTML using XBL
| implementation.

Please do so.

> XBL can indeed allow implementation which will not conform to the
> semantics defined by the HTML 4.01 spec. Just making a <select> into
> a <input type='submit'> is very simple ridiculous example.

I already countered this argument, although you ignored me:

|> If a <select> submits a form, then that is a major semantic change.
| A very common idiom on the Web is:
|    <select onchange="this.form.submit()"> ... </select>
| That is a presentational, or behavioural, change: the semantics are
| still the same ("select an item from the list"), all that changes is
| the interface to the user.
| It would be much, much better for accessibility if instead of putting
| this behavioural change inline in the HTML, it could be abstracted out
| into the styling language:
|    select { binding: url(widgets.xml#submitting-listbox); }
| That way, users could forcibly override the binding in their user
| stylesheet:
|    select { binding: listbox ! important; }
| It would also allow authors to provide alternate stylesheets optimised
| for users with disablities, while keeping the auto-submit behaviour
| used for the more typical user.
| So no, making a <select> submit a form does not change its semantics.
| It only changes its behaviour.

Note also that one of the few examples you gave in this thread was of
an XSLT transformation that did almost exactly this.

This would seem to suggest that XSLT is just as bad, by your logic.

>>| By your logic, CSS is "non-conforming", due to this rule:
> Some of CSS allows implementation which creates semantics which is
> not compliant to the HTML 4.01 spec[1]. My understanding is those
> portions are CSS are by and large noted as "not required by HTML
> conforming user agents"[1].

I have already countered this claim, although again you ignored me:

|>> CSS can decide how something will be rendered, e.g., for some made
|>> up tag you could say:
|>> goo { display: table }
|> "Conforming HTML user agents may ignore the 'display' property."
| Firstly, "goo" is not an HTML element, so that line doesn't apply.
| Secondly, I have reason to believe that that line is a relic of a
| compromise between CSS's designers and UA implementors who didn't want
| to have to implement all of CSS on HTML elements (many legacy UAs have
| lots of hardcoded rendering code for HTML elements).
| Thirdly, thanks for pointing this out, I have raised this issue with
| the WG, and hopefully that line will be removed from CSS2.1.
|> Thus CSS "display" controls semantics because it admits it is not
|> conforming.
| You are reading way more into this than was intended. It certainly
| doesn't say that 'display' affects semantics, merely that HTML UAs
| need not support 'display'. The CSS2 spec has many other similar
| caveats, e.g. the rule about backgrounds on <body> elements, the
| rule about HTML UAs being allowed to ignore border styles other than
| solid, HTML UAs being allowed to ignore :first-line, etc.
| By your logic, a dotted border changes the semantics of an element!

(Note that Chris Lilley, the CSSWG chair when that line was added to
the spec, agreed with my comments above [1], so I am probably right.)

>>|    p:empty { border: solid blue; }
> A paragraph with a border is still conforming to semantics of HTML
> 4.01 spec. Thus by my definition your example CSS is
> "presentation"[2].

An empty paragraph must be ignored per HTML 4.01 section 9.3.1:

# User agents should ignore empty P elements.

Therefore according to your logic, that rule violates HTML's semantics.

Of course I think this is ridiculous, because there is no way that
that CSS rule changes an empty paragraph from being an empty

Similarly with anything that XBL could do: It doesn't change the
_meaning_, or _semantics_, of the underlying document.

>>|> You must differentiate between "conforming" and "non-conforming"
>>|> meaning.
>>| Non-conforming meaning is, by its very nature, irrelevant.
> Every implementation is non-conforming to some small degree[3].

Indeed; but these deviations do not change the semantics of the
specification as you claim.

Unless you can provide some example that shows it does?

> More importantly, many people could argue quite effectively that
> conformance with the most popular implementation has always proven
> to be the _MOST_ relevant consideration for programmers who want to
> succeed in the market.

That, however, doesn't affect the _meaning_ of the documents in any way.

For example, if I include an <abbr> element, then it indicates an
abbreviation, despite the fact that the browser with over 95% of the
market does not support that element _at all_.

>> Could you explain why my list of features that XBL has and which
>> XSLT does not is not "useful discussion" given the subject line?
> Somebody else might want to discuss "features" with you, but for me
> those are fairly ambiguous and subjective arguments.

Features are the cornerstone of a specification, and therefore
extremely relevant. Especially if you are trying to claim that XBL is
redundant with other existing specifications, since redundancy is
almost exclusively a matter of feature comparison.

-- References --

Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.                         `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 5 January 2003 18:24:00 UTC