Re: Getting beyond the ping pong match

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.


> ..., 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. That's
completely counter to the whole way that @class has been both defined
and used in the past, turning something that had a simple and generic
definition, into something that is hard-coded in a number of
situations.


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


> I'm arguing for a clean
> and consistent standard. If you think otherwise, it would be a good
> start to tell me detailed where my proposal is flawed and inconsistent.

I have done, and so have many others. It seems to be a pattern in
these discussions that those putting forward extremely weak design
proposals (from a language architecture point of view) then put the
onus on others to spend a lot of time explaining the weaknesses, and
once that is all done, they then choose not to take the criticisms of
the design on board.


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


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

Why not just do the job right, instead of flailing around, hacking at
the language?


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

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

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Monday, 7 May 2007 15:36:50 UTC