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

On Sun, 5 Jan 2003, Shelby Moore wrote:
> At 05:19 PM 1/5/2003 +0000, Ian Hickson wrote:
>> I agreed that a specification cannot completely control the semantics
>> of the language it specifies, because other specificaitons can enhance
>> those semantics.
>>
>> However, that is a far cry from (indeed, it is the opposite of) saying
>> that implementations control the semantics.
> 
> Rather than reply to your points, I will just go straight to the final
> answer since it supercedes your points.
> 
> See the following 2 posts for final answer:
> 
> [1] http://lists.w3.org/Archives/Public/www-style/2003Jan/0104.html
> [2] http://lists.w3.org/Archives/Public/www-style/2003Jan/0102.html

My post countered both of those posts, but for completeness, I have
addressed them explicitly as well in this updated version of my
previous post.

Note that you have not yet answered _any_ of the points in this post.


> I finally got Ian to agree that specification does not _control_
> semantics[1]. Only implementation can control semantics.

This is a massive misrepresentation of what I stated.

I agreed that a specification cannot completely control the semantics
of the language it specifies, because other specificaitons can enhance
those semantics.

However, that is a far cry from (indeed, it is the opposite of) saying
that implementations control the semantics.

They don't, for the many reasons I gave in:

   http://lists.w3.org/Archives/Public/www-style/2003Jan/0082.html

...namely that even without an implementation, the semantics still
exist, and even with only non-compliant implementations, the semantics
are still the same.

Implementations cannot affect the semantics of a document.

If you disagree, then given that there has never been a compliant
implementation of the HTML specification, could you show us an example
of how the semantics of the HTML language have changed, as you assert
they must have?


> Well if you remember Ian was arguing that it was impossible for XBL
> to change semantics, as he argued that semantics is controlled by
> specification and not by implementation.

Indeed.


> He is still arguing that, even though he agreed it is not.

I agreed that specifications cannot _completely_ control the
semantics.


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

Now you are changing your argument from "XBL changes semantics" to
"XBL changes implemented meaning". We had finally agreed on what
"semantics" mean, what on earth does "implemented meaning" mean?

(David Hyatt also asked you to define "implementation", so it is not
only me who is having trouble understanding it.)

However, I would welcome the examples that you offer.


> Indeed XBL has infinitely more power to change semantic
> implementation than CSS does, because XBL can replace the
> implementation of HTML 4.01 tags and it can define implementation of
> new tags.
> 
> Afaik CSS can not generally do this.

CSS1:

   p { display: inline; }
   img { display: list-item; }

   big { font-size: smaller; }
   small { font-size: larger; }


CSS2:

   table { display: block; }
   h1 { display: run-in; }
   p { display: table; }


Proposed CSS3:

   img { content: url(another-image); }
   h2 { move-to: endnote; }


As we increase the power of CSS to achieve more and more of the
presentation effects authors are asking for, it gradually gets more
and more possible to write confusing CSS. However, at no stage do the
semantics of the document itself change: only the presentation.

Check the CSS spec: nowhere does it purport to be changing the meaning
or semantics of the original document.


> I agree that the generated content features of CSS are dangerous,
> but not so much, because you can not (afaik) change a <select> into
> a submit button using CSS.

CSS1:

   select option { display: none; }
   select { border: outset; }
   select:active { border: inset; }

(Actually, XBL alone can't do this without CSS' help.)


> XBL is targetted to swappable implementation (or augmentation) of
> tags.

XBL is not aimed at this, it's aimed at advanced presentation.


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


> If an implementation change violates the specification, then it is
> non-conforming and thus it is a semantic change.

By your logic, CSS is "non-conforming", due to this rule:

   p:empty { border: solid blue; }

...as I mentioned in an earlier post.


> You must differentiate between "conforming" and "non-conforming"
> meaning.

Non-conforming meaning is, by its very nature, irrelevant. Would the
stylesheet given above indicate that CSS could create non-conforming
meaning?


>> Can you clarify what you mean when you say "implementation"? 
> 
> Non-conforming semantic implementation is any change to the
> implementation of markup which is non-conforming to normative
> specification.

In that definition you both fail to elucidate and have a circular
definition, all at the same time. Impressive. Not to mention that you
didn't clarify the term Hyatt asked you to clarify.

What do you mean by "implementation"?


>> CSS can decide how something will be rendered, e.g., for some made
>> up tag you could say:
>> 
>> goo { display: table }
> 
> http://www.w3.org/TR/REC-CSS2/visuren.html#display-prop
> 
> "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.


> Whereas, XBL is unable to isolate its portions which allow
> non-conformance. So there is no way to be both XBL and HTML
> conforming at the same time.

XBL doesn't _have_ any portions which allow non-conformance, so it
doesn't have any to explicitly point out. If you disagree, I will have
to request examples.


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


> I object to putting more non-conforming power in the CSS layer, when
> it isn't necessary to accomplish the kind of goals people have with
> XBL. Similar goals can be done with XSLT (subject of this thread:
> "XBL is (mostly) W3C redundant").

Please demonstrate how XSLT achieves the following goals:

   * Bind event handlers and styles to an element from the style
     layer.

   * Bind event handlers and styles to an element without affecting
     the original DOM.

   * Allow dynamic changes to the DOM to be reflected by the binding
     dynamically.

   * Allow individual elements to have bindings changed dynamically.

   * Allow multiple bindings to be added to the same element
     simultaneously.

   * Allow the user to individually override bindings without
     completely overriding the author bindings.

   * Allow new functions to be defined in the scope of the bindings
     without _any_ pollution of the document namespace.

   * Bind stylesheets to subtrees of the document without affecting
     any other elements.

From my reading of the XSLT spec, I couldn't see any way of doing any
of the above. They are all critical aspects to the binding problem.
They are all solved by XBL.


>> I actually envisioned another form of binding for XBL (in addition
>> to CSS and the DOM), and that was through a processing instruction
>> in the document that would then use an XPath expression to attach a
>> binding.
> 
> Yes! That is the correct direction. Put the binding at the semantic
> layer (before the parser and DOM). And then make the events bindings
> orthogonal also.

XPath depends on the parser and matches based on the DOM.

Indeed, the PI itself depends on the parser.


>> Note that XBL itself is largely agnostic regarding how it is bound.  
> 
> Cool!  But the <handler> is bound non-orthogonally.

The <handler>s are bound in _exactly_ the same way as all other parts
of the XBL binding.


>> This does in effect give CSS (using XBL) the power to render an
>> element as though it were any other kind of element, even though
>> the source document's DOM remains unaltered.
>>
>> So my (possibly naive) question is this: what is so horrible about
>> a world in which CSS has that kind of power?
> 
> Okay that is good question to explore. I always wanted to get to
> that point. But first we need to make sure we have the enough agreed
> foundation on what is fundamentally agreed and not agreed. I am not
> going to jump n detail (as I did with Ian), and then have the
> foundation of debate constantly shifting.

I have been saying all along that XBL gives CSS more power. Even CSS
on its own can make one element render identically to another, for
example:

   p { font-size: xx-large; }
   h1 { font-size: medium; }

...turns paragraphs into large text and headers into small text.

Just because the elements _look_ and _behave_ the same with a
particular stylesheet does not say anything about their underlying
semantics. The header is still a header and the paragraph is still a
paragraph.

Nowhere in CSS or in XBL does it say "making an element look like a
header changes the semantics of the element to be a header".

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 5 January 2003 13:33:37 UTC