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

On Sun, 5 Jan 2003, Shelby Moore wrote:
|
| If a <select> submits a form, then that is a major semantic change.
|
 -- http://lists.w3.org/Archives/Public/www-style/2003Jan/0088.html

On the same day, Sun 5 Jan 2003, the same Shelby Moore wrote:
>
> No where in HTML 4.01 spec does it say that <select> can not submit
> a form.
>
 -- http://lists.w3.org/Archives/Public/www-style/2003Jan/0129.html

Could you please explain how making a <select> submit a form is a
major semantic change, if, as you say, the HTML4 spec doesn't say that
it cannot?


>>>>| By your logic, CSS is "non-conforming", due to this rule:
> 
> I did not write that _all_ of CSS is "non-conforming".
> 
> Only "portions of CSS are" and they "are noted as not required".

But the empty paragraph feature _is not_ noted as not required.

Do you therefore also think that dotted borders would change the
semantics? Because that is "noted as not required" in CSS2.


>>|>> 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. 
> 
> This is inane because "non-conforming" doesn't apply if there is no
> specification for the tag.

CSS applies to all XML.


> Thus in that case, CSS is defining the semantics.

No, the semantics are defined by David Hyatt's specification for the
http://mymadeupnamespace.org/ namespace. And if there isn't one, then
the element has no semantics.

CSS does not define semantics. To make sure this is very clear, I have
proposed we make this explicit in CSS2.1.


> Else I assume there is a specification some where and that line
> would apply. It says "conformig HTML".

Yes, and since that is not HTML at all, let alone conforming HTML, the
clause you quoted does not apply.


>> (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.)
> 
> Chris's logic imo (and based on corrections I have made to his
> posts) thus far has not been up to speed on the totality of issues
> in this thread.

Chris Lilley's logic is irrelevant, since he stated factual
information that he is in a position to know, and which you are not.
(Unless you were a working group member at the time he was chair?)


>>>>|    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.
>> -- http://www.w3.org/TR/html4/struct/text.html#h-9.3.1
> 
> It also says "We discourage authors from using empty P elements.".
> So using an empty paragraph is non-conforming markup.

According to the HTML spec's conformance section, RFC2119 is cannon,
and therefore "should" counts as normative and "discourage" does not.

Using an empty <p> element is therefore _not_ a violation of the HTML
spec and my point stands: That CSS rule is not one of the "optional"
ones and yet it "violates" (according to you) the HTML specification.


>> Indeed; but these deviations do not change the semantics of the
>> specification as you claim.
> 
> I did not claim they _always_ change semantics. I only claimed they
> can _some_ times. Prove they can not.

You are once again shifting the burden of proof, but nonetheless:

They don't change the semantics, because CSS only changes the
presentation, which is unrelated to the semantics.

Now prove that they can. Providing one example which does would be
enough: all the ones you have given so far have been countered. (One
of them was countered by yourself!)


>>> 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.
> 
> I was refuting your point in which you wrote "Non-conforming meaning
> is, by its very nature, irrelevant"[1]

My apologies for being too vague.

What I meant was that non-conforming meaning is, by its very nature,
irrelevant to the semantics of documents, and therefore irrelevant to
the matter at hand.


It seems to me that you have gone from arguing that XBL is a "semantic
binding" language and therefore does not belong in CSS, which cannot
change semantics; to saying that CSS can change semantics, and therefore
is itself a semantic binding language.

Well if CSS is a semantic binding language, it seems that you would think
that XBL would be ideally positioned in the CSS fold.


I personally don't think either CSS nor XBL can affect semantics, but if
you think either can, then the other can, since there are some things that
can be done in both.

Could you resummarise your current objections to XBL so that we know
whether we are discussing relevant material?


>> Features are the cornerstone of a specification
> 
> I'd rather discuss the specifications themselves.

What is there to a specification _other_ than its features?

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

Received on Sunday, 5 January 2003 19:19:27 UTC