W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2006

[whatwg] Semantic styling languages in the guiseof HTML attributes.

From: Mike Schinkel <mikeschinkel@gmail.com>
Date: Sun, 24 Dec 2006 07:44:47 -0500
Message-ID: <000501c72759$72e98e30$0702a8c0@Guides.local>
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?
 
> 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.

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

> The |role| attribute itself is equivalent to having
> an infinite number of boolean attributes.

I still need to see why this is bad.

>>> Generally, though, this is just math. For every attribute or role
>>> you have that can apply to ALL elements, you have the semantics of
>>> all those  elements to interact with, plus you have interactions
>>> between an indefinite number of global attributes that may be
>>> defined on that element.
>> 
>> Can you provide some concrete examples where that might cause a
>> problem? 
> 
> <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"> 
> 
>    Granted, most people wouldn't put these together, but I
> was able to create this list using only a handful of
> attributes and roles that have already been proposed. Also,
> keep in mind that implementors have to consider these
> interactions whether people use these attributes and roles
> together or not.

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

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?

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

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 solutions?

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

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.
And in the case of something like this:

> <div role="main secondary">

I could see that being valid in unusual cases too.

So it comes down to I haven't seen anything that makes me believe semantic
markup is A Bad Thing. 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.

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. 

Lastly, let's assume that semantic markup really is A Bad Thing. 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 look forward to your response.  And happy holidays while we're at it. :)

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org/
Received on Sunday, 24 December 2006 04:44:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:31 UTC