Re: Use the role-attribute instead of predefined class names

Laurens Holst wrote:
> Matthew Raymond schreef:
>> Laurens Holst wrote:
>>> In case of <section>, the advantage is in my opinion that instead of the 
>>> fact that it’s a section being implicit (like in <article>, <nav>, etc), 
>>> it’s good to have it explicitly being a section, and then specify the 
>>> type of section on the role attribute, as a means of sub-classing it. 
>>>     
>>    First of all, an element specific attribute makes just as much sense
>> in this case because you don't necessarily want "section types" defined
>> on other elements.
> 
> I agree. The predefined classes are also different per element, doing 
> effectively this, and I would also see the ‘role’ attribute like so. 
> However, I think it makes sense to generically name this attribute 
> ‘role’ throughout the specification, and not to trying to create a 
> differently named attribute where they effectively are doing the same 
> thing. E.g. like ‘type’ is also an attribute used in more than one 
> location… Although that may be a bad example, given that it’s not 
> consistently used for the same kind of thing :), sometimes a MIME type 
> and sometimes an input type, etc.

   Having |role| on all elements suggests a global attribute where all
values work on all elements. People will get confused. It's unavoidable.
That's the very reason why attributes like |role| are so dangerous. It
really doesn't pass the "copy-paste" test, where people may copy-paste
an attribute from one element to another and expect it to work.

>>    Secondly, using attributes for "subclassing" can be a descent into
>> madness:
>>
>> | <div role="section article">...</div>
>> | <role="div section article">...</>
>>   
> 
> That’s taking it too far obviously. The section types have in common 
> that they’re all sections. Div doesn’t really mean anything.

   The <div> element can be just as much a "section" of an HTML document
as <section> is. The difference is rather subtle, and the practical
difference largely depends on authors not semantically abusing
<section>. Preventing such abuses has never been easy in the past.

> A role element means even less than div.

   It's not a role element. It's a nameless element with a |role|
attribute, meant to indicate that |role|, take to it's greatest extreme,
completely remove all semantics from the element until it becomes
nothing more than an empty structural hook for |role| values.

> I think you can hardly call it ‘subclassing’ at that point.

   I wouldn't necessarily call |role| a kind of subclassing, because
it's a global attribute that can apply any role to any element (as
currently defined in the specification, at least). Thus, it really
represents an "attributization" of semantics rather than a subclassing
of elements.

> I don’t think the argument that ‘subclassing’ is a bad idea just because 
> you can do it wrong is a very good one.

   I'm not sure it's really "subclassing" so much as it's a means of
giving higher specificity for element semantics. As such, these
refinements are context sensitive and shouldn't necessarily be
represented by the same attribute name. Should |rel| and |rev| be rolled
into the |role| or |class| attributes? I would say no.

>>    Furthermore, not having elements means that if we want to add
>> attributes to a specific kind of "section", we have to put them on the
>> root element and instruct user agents to ignore the attributes for other
>> types. Also, without elements we can't impose any logical structural
>> restraints on the markup with regard to "sections".
> 
> I don’t think such restraints are necessary.

   I can see situation where you may not want to nest certain "section"
types. For instance, I would argue that you don't want an "article"
inside a "nav".

> And even if they were, I
> don’t think having it as an attribute would prevent you from doing so.

   Using attribute values to limited the content model of an element
would complicate parsing and validation. It could also make markup
invalid simply by adding, changing, or removing an attribute value,
regardless of whether the value is predefined.

>>> The way it is currently, which elements are exactly section types and 
>>> thus how they interact with headings is extremely unclear to me.
>>>     
>>    I don't see how this is a problem. We can just define certain
>> semantics as applying to a group of elements rather than one. However, I
>> would be content to see the use of <h> limited to being inside <section>
>> elements specifically, in part because I prefer to have <section>
>> defined as a "section of an article" rather than a section of the document.
> 
> You can define it, yes. However, what I’m saying is that the current 
> interaction of all the various types of sections and headings makes it 
> very unclear to me, it is too complex.

   I don't see this. Please provide an example.

>>> Then again, I suppose it would depend on the exact definition in the 
>>> specification. If e.g. non-namespaced values were reserved for the HTML 
>>> specification, and authors were discouraged to invent any new role 
>>> attributes individually and to use the class attribute instead, I think 
>>> that problem might be avoided.
>>     
>>    The web page can't break when an unknown role pops up, especially if
>> new roles for HTML are defined at a later date and markup with these new
>> roles are viewed by a older user agent that supports roles. Therefore,
>> requiring that authors, and vendors for that matter, not invent their
>> own roles is pointless. They'll do whatever they want, and we'll be back
>> at square one.
> 
> Maybe. Is this stopping you from adding new type attribute values to the 
> input element? No.

   I'm not seeing how adding new input types invalidates my point. In
fact, we're able to add new types because legacy user agents revert to a
default of type of "text" rather than breaking the page. Similarly,
|role| would have to use defaults when encountering an unknown role,
thus removing the teeth from any limitation on the use of non-namespaced
roles.

> Role just needs to be defined so that it’s very clear that it’s not an 
> equivalent of the class attribute.

   Explain to me how |role| isn't simply a explicitly semantic subset of
|class|, with annoying namespace requirements, that's harder to style
and script.

Received on Sunday, 8 April 2007 01:37:35 UTC