Re: Getting beyond the ping pong match

Mark Birbeck schrieb:
> 
> Hi Dao,
> 
>> No, I'm not suggesting to hack the language, given that the WA1 draft
>> isn't a finalized language yet. I'm suggesting to standardize class
>> names where it makes sense...
> 
> It's a hack to the HTML language, since as HTML stands at the moment,
> class values have no _universal_ meaning. There is nothing wrong with
> proposing a mechanism by which @class could carry values that do have
> a universal meaning--perhaps by using a prefix, for example--or
> proposing a new attribute that is explicitly defined to not be about
> CSS--such as @role--but to simply say all previous occurrences of a
> certain value will now have some arbitrarily defined universal meaning
> whilst every other values will not, is a great, big, horrible, hack.

All classes should have a meaning. The idea is to standardize some of 
them, so that user agents can take advantage of that.

>> ..., which can of course mean to correct the WA1
>> draft. aside, body, p, section and span seems to be a random choice to
>> define 'search' for, and since Rene pointed to other use cases of the
>> 'search' class, I'm proposing to not define a meaning for random 
>> elements.
> 
> That's hack number two. After first giving @class values universal
> meaning where before they had none, you now propose to prohibit
> certain values from appearing in @class, on certain elements.

No, that's not what I wrote. All class names should be allowed 
everywhere, but only the standardized cases would carry an interoperable 
semantic meaning.

The current WA1 draft says "It must only be used on the following 
elements: [...]" -- I disagree with that.

>> Obviously, my argument is not that we take something that is clearly
>> flawed and inconsistent. That would be stupid.
> 
> Don't worry, I wasn't implying that your goal was to use something
> flawed and inconsistent per se. But the fact is that the proposal to
> use unqualified class values is flawed (since it doesn't work) and
> inconsistent (since it changes the meaning of @class).

Changing something isn't inconsistent per se. In fact, the rationale is 
that the predefined classes would be /consistent/ with existing content.

>> For instance, how does defining the search class for form elements add
>> inconsistencies?
> 
> Because at the moment there are no restrictions on the use of class on
> any element. You are now making @class behave in a special way, and in
> some situations in a way that is unique to particular elements.

Defining the search class for form elements doesn't restrict anything 
other than using it for non-search forms.

>> > What I find most ironic is that in one thread we have people arguing
>> > that HTML 5 is built on the idea of backwards compatibility and
>> > graceful degradation, and in another thread we find that we can no
>> > longer use any class values that we like.
>>
>> You're not doing yourself any favour if you use class names that clash
>> with the actual content. So yes, I'm arguing to limit your rights --
>> mind you, you won't be punished of you ignore that. No site will really
>> break if the author uses nonsensical class names.
> 
> But we're not talking just about sites. What about finding a way to
> provide enough information such that crawlers can say "yes, I am now
> 100% certain that I have found the copyright information for this
> site, and I'm going to do something with it". Or what about allowing
> browser extensions like GreaseMonkey to say "here is the copyright
> information, and I'm going to display it differently, or retrieve the
> license and show it in a mouseover"? The point is that whilst you
> define a standard that is based on using ambiguous values of @class,
> then no process will never be able to be 100% certain that they have
> actually located anything useful.

Sorry, but sites are the crux of what I'm talking about. I want 
GreaseMonkey to say "here is the copyright information, and I'm going to 
display it differently, or retrieve the license and show it in a 
mouseover" on as many sites as possible. If this doesn't work on one of 
thousand sites, I can still advise the author to correct that. Contrary, 
chances are that nobody will care to write a GreaseMonkey script for 
something that isn't used.

It should also be noted that there's nothing like 100% certainty, given 
that content is created by humans who hardly know what they are doing. 
If the role attribute should become widespread, it would also be misused.

>> There is the risk to get false positives, as it's always the case with
>> semantic markup. That risk is far outweighed by the semantic enrichment
>> of existing and future content. Prefixed class names or the role
>> attribute, on the other hand, would be doomed to marginal niche 
>> existence.
> 
> With respect, I'm not getting the impression that you know what you
> are talking about here. First, when dealing with semantics, we try as
> much as possible to eliminate false positives, rather than turning
> them into a virtue...or at least failing at the first hurdle.

It's not failing at the first hurdle, as the actual standard is still 
discussed and the false positives are theoretical so far. In the 
'search' case, I've made a suggestion that would reduce the risk 
significantly.

I also disagree that inventing something that will be used by 
significantly fewer sits is a good way to eliminate false positives. It 
doesn't help accessibility.

> Second, there is plenty available to read on the use of prefixed class
> names in the context of RDFa, as well as a lot of stuff on the role
> attribute. RDFa encompasses all of the topics we are discussing, and
> has support from Creative Commons and IBM (amongst many others). The
> role attribute is also garnering support, and of most interest is
> probably the fact that is is supported in Firefox. So far I'm having
> trouble squaring this with your use of the terms 'doomed', 'marginal'
> and 'niche'.

Maybe comparing it to the million pages that contain meaningful class 
names gives you a clue why I made that statement.

--Dao

Received on Monday, 7 May 2007 16:21:27 UTC