[whatwg] Semantic styling languages in the guise of HTML attributes.

Sun Dec 31 14:54:56 PST 2006

Mike Schinkel wrote:
> Matthew Raymond wrote:
>> Mike Schinkel wrote:
>>> Why should attributes (only?) specify the details of semantics that
>>> elements already possess?
>>    Global attributes aren't necessarily wrong if their
> 
> By "global" do you simply mean attributes for HTML elements, i.e. a "type"
> attribute for a <DIV> element, for example?

   Interesting that you should choose that example, because it can mean
different things depending on the element you use it on. Therefore, a
global |type| attribute would almost certainly conflict with the
element-specific attribute unless it was defined otherwise.

   One thing an element like |type| does provide, however, is mutual
exclusion. However, you could do that with a namespace:

| <xhtml:element ns1:type="value" ns2:type="value" />

   For |role|, you're required to use namespaces anyways, so I don't see
how |role| brings anything to the table. It's just a means of creating
minimized boolean attributes in XML. I'd much rather see XML modified to
accommodate minimized attributes because I suspect the additional
parsing of the attribute value would be just as burdensome.

   Now, remember this example?

| <input [..] role="wairole:textbox wairole:checkbox wairole:select">

   Let's take out the conflicting roles and add a check state:

| <input role="wairole:checkbox" aaa:state="checked">

   It could be eliminated by using a mutually exclusive attribute:

| <input wai:widget="checkbox" aaa:state="checked">

   Even then, though, you have to determine how the attributes interact
with the element they're assigned to. Does |wai:widget| override the
<input> element's |type| attribute? Or its |value|? How does this
attribute integrate into the form submission model? How would I use this
attribute with XHTML 2.0 and XForms? Every time you introduce a new
namespace, you have an entire set of elements for which you have to
define interactions with other namespaces.

>> purpose is orthogonal to the purpose of the elements they're
>> being added to. That's why |id| and |class| are so useful.
>> They don't alter the semantics of the element. Rather, they
>> act as targets for styling and scripting.
>>
>>    However, global attributes like |role|, |src| and |href|
>> directly compete with the semantics of HTML elements in many
>> ways. We already see this with |role| versus "HTML5". Many
>> roles have semantics that overlap with elements like <nav>
>> (navigation), <article> (secondary), <aside>
>> (note) and <footer> (contentinfo).
> 
> You reference altering the semantics as if that was A Bad Thing. I believe I
> am to understand that you believe it is A Bad Thing, but my current view is
> that it is not a bad thing and AFAICT you've not given any evidence that it
> is A Bad Thing.  Now I'm not saying that I won't ultimately realize that it
> is A Bad Thing, but right now I just don't see it.

   I've shown you that not only are there conflicts with proposed
attributes, roles and elements, but that they actually compete in
certain situations. Furthermore, I did so with only minutes worth of
research.

>>> Is there an axiom or W3C finding that we can reference for this?
>>
>>    Of course not. That's the problem. You see the power of
>> markup being shifted from elements to attributes to attribute
>> values. 
> 
> I'm having to read between the lines here in order to understand your point.
> Are you saying that you see it as a big problem, but nobody else has seen it
> as a big problem, or at least not enough people to author an guidance
> against doing so?

   This line of conversation doesn't advance our conversation regarding
global attributes and roles. Even if there is no support for my
viewpoint in the W3C, the idea that this proves my argument invalid is a
logical fallacy.

>> The |role| attribute itself is equivalent to having
>> an infinite number of boolean attributes.
> 
> I still need to see why this is bad.

   Because markup structure has semantic significance. If you shift all
the semantic meaning to global attributes, you loose the ability to use
structure for semantic purposes.

>> <input contenteditable readonly>
>> <input type="hidden" role="banner">
>> <output role="search">
>> <body role="seealso">
>> <body role="secondary">
>> <div role="main secondary">
>> <div role="main note">
>> <input type="checkbox" role="wairole:textbox">
>> <input type="file" role="wairole:checkboxtristate">
>> <input type="hidden" href="http://whatwg.org">
>> <input type="hidden" src="http://whatwg.org/images/logo">
>> <script [...] href="http://whatwg.org" />
>> <input [...] role="wairole:textbox wairole:checkbox wairole:select">
>> <hr role="main">
[Snip!]
> From a quick scan of your examples, it seems you have provided numerous
> examples where each one is a case of conflicting and/or mutually exclusive
> attributes semantics, attribute vs. element semantics, or visibility vs.
> visual element semantics. Did I get that right, or did I miss something?
> Further, it appears you are providing HTML5 examples, correct?

   I'm providing non-theoretical examples of attributes and roles that
are in existing working drafts and proposals and how they conflict with
HTML4 or features of other working drafts.

> If we are still on the same page, then it seems you are saying there are two
> problems with this:
> 
> 1.) The mutually exclusive directives will create conflicts and/or unknown
> situations, and 
> 2.) Implementors of client software will need to deal with all of those
> combinations.
> 
> Did I get those correct?  Was there anything I missed?

3) Without proper definitions of all interactions, user agent vendors
will implement support in a way that isn't consistent between user agents.

4) In situations where vendors can't determine the correct behavior,
there is the possibility that they may just disable the attribute or
role instead of deciding the behavior on their own. (This is especially
likely in situations where they don't want to support the legacy
behavior when a standards organization finally gets around to defining
the proper behavior.)

5) Greater interactions in markup lead to greater code complexity and
more bugs in user agents.

> Again, assumed we are still on the same page, this doesn't seem to be a real
> problem to me.  
> 
> Looking at #1, there are many situations where someone could write HTML code
> that was invalid.

   So you admit that we'd have to actually define what combination of
attributes, roles and elements are invalid???

> Of course those may bother you too, but I don't think it
> is possible or even that useful to try and avoid any situation where someone
> can misuse something. On the contrary, eliminating all potential for misuse
> leaves one with so little room left that it makes it very difficult to
> design new features.

   There's a threshold of potential abuse that one shouldn't cross. Some
  potential markup is too inherently abusive to let stand. As it stands,
things like roles can be abused so easily that it's almost impossible to
avoid accidental abuse, and that's a design flaw.

   My greatest concern, though, is not necessarily about intentional use
of combinations of elements, attributes and roles as exploits or
instruments of user-hostile action (although that can certainly be the
case too). I'm more concerned about confusing web authors with regards
to markup interactions and about the software development and support
complexities. I also think role and poorly conceived global attributes
will have a negative impact on how markup degrades for legacy user agents.

> So, what to do about #1?  Where this is an obvious case that should
> override, such as "hidden" (I say why it is obvious in a minutes), we should
> have it override.  Where there is no obvious case, it is undefined and
> should simply do nothing.  So I ask, why is this not a valid [solution]?

   Using this logic, if you don't define an interaction, it does
nothing. In that case, you might as well just have scoped attributes
because there would be no difference.

> For #2, implementors have to deal with a lot of things when new features are
> added; why should this be a special case?

   It isn't any different, which is the problem. Take HTML parsing, for
instance. Right now, the WHATWG is spending a lot of time hammering out
how to handle HTML parsing errors because error handling was never
defined in the spec and it doesn't work the same across all user agents.

> As for why it should override, let's look at one of your examples:
> 
>> <input type="hidden" role="banner">
> 
> I can envision situations where this is completely valid using AJAX to
> expose or hide the banner based on a profile situation or other situation.

   It's a hidden input. I could see an empty <div role="banner"> making
sense in an AJAX scenario, but an input makes no sense as a banner, let
alone a hidden one.

> And in the case of something like this:
> 
>> <div role="main secondary">
> 
> I could see that being valid in unusual cases too.

   Really? Because I see this as causing problems with document outline
algorithms, not to mention the fact that it complicates adding markup to
the page later because the "secondary" component would have to be split
off into a separate child <div>.

   By the way, what would be the semantic significance of multiple
separate "main" elements in a document? What about nested "main"
elements? A "main" element nested in a "secondary" element? Do you
expect UA vendors to come up with the same answers to all these questions?

> So it comes down to I haven't seen anything that makes me believe semantic
> markup is A Bad Thing.

   Me neither. ;)

> And I'm not just trying to be contrary, I'm trying to
> have as open-minded view as possible, but I don't see it.

| <div role="secondary banner">
|   <hr role="main" />
|   <hr role="main" />
|   <hr role="main" />
|   <hr role="main" />
|   <hr role="main" />
| </div>

   And don't tell me that's invalid, because there's nothing in the
specs that say it is.

> In lurking on lists and reading other's disagreements if often seems that
> core disagreements come because the people debating are coming from
> completely different use cases and neither can enivison the world in which
> the others are working and their subsequent requirements.  Maybe it would
> help if I know your use-cases and what you work on. 

   How can there be use cases for not including a feature? You show use
cases to demonstrate the need for a feature, not the lack of one. Show
me, for instance, that we need the roles defined in the XHTML Role spec.

> Lastly, let's assume that semantic markup really is A Bad Thing.

   Your terminology is too broad. We're talking about non-scoped
attributes and roles, not semantic markup.

> How would
> you propose people add semantics into their HTML files for machine
> processing? Although I used to view things very differently, I'm now a
> strong proponent that the simplier you make things for the document author,
> and more obvious it is and the easier it is for them to find and view
> examples (i.e. via the "view source effect"), the better the chance that a
> technology is going to see adoption. And one of my interests is the desire
> to see as much adoptions as possible.

   I don't see this as simpler. I see a proliferation of hidden
complexity. With |role| specifically, you can add an infinite number of
roles, and there really isn't any mechanism to determine if they're
actually semantic. You just create a namespace and add what you want.
Sure, the spec shakes its finger at non-semantic roles, but all
implementors can do with non-semantic roles is (at best) ignore them,
which is really no better in practice that retooling |class| for the
same purpose.