- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Mon, 7 May 2007 16:36:44 +0100
- To: public-html@w3.org
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