- From: Olivier GENDRIN <olivier.gendrin@gmail.com>
- Date: Wed, 9 May 2007 17:38:57 +0200
- To: "Rene Saarsoo" <nene@triin.net>
- Cc: public-html@w3.org
On 5/9/07, Rene Saarsoo <nene@triin.net> wrote: > > Matthew Raymond wrote: > > Note that |role| is not immune to the problem of naming conflicts. > > > > Because new "roles" may be added in future HTML specifications, > > earlier user agents will have to ignore unidentified roles so that they > > can preserve graceful degradation for future HTML specs. Thus, people > > may start using roles that are undefined for a given namespace (or use > > undefined roles without namespaces). This is especially true of clueless > > web authors who don't necessarily understand what |role| is: > > 1. If authors use their own arbitrary values with @class, > then this is absolutely correct use of @class. > > 2. When authors use their own arbitrary values with @role, > then this will NOT be the correct use of @role. > > Similarly authors can make up their own element <foo>, which > might be assigned a meaning in some future spec of HTML. > But usually there is no benefit in making up your own elements, > and people rarely do it. Similarly do they rarely come up with new > values for other attributes with predefined sets of values. > Why should it be the case with @role? I totaly agree rene : the former HTML specs never warned authors about predefined classes. But HTML 5 spec will have to include a big red shinny warn about misuse of role (and some other property), and will also have to be very clear about the way it's used and the way to add a role value to the spec. -- Olivier G. http://www.lespacedunmatin.info/blog/
Received on Wednesday, 9 May 2007 15:39:17 UTC