W3C home > Mailing lists > Public > public-xhtml2@w3.org > December 2008

Re: Semantics and the classic argument: elements vs attributes

From: Shane McCarron <shane@aptest.com>
Date: Thu, 04 Dec 2008 11:37:22 -0600
Message-ID: <49381552.4080308@aptest.com>
To: Roland Merrick <roland_merrick@uk.ibm.com>
CC: XHTML WG <public-xhtml2@w3.org>

FWIW, the rationale for NL had nothing whatsoever to do with defining a 
section of the document that has nagivational semantics.  It had to do 
with defining hierarchic menus that could then be styled in whatever way 
had sense for the target device.  I personally find the specific issue 
of navigation sections uninteresting.  As you point out, there is an 
@role value for this people can use.  The purpose of that value is not 
in conflict with the requirements that drove the creation of the NL 
element.  If we no longer believe that the web needs hierarchic 
navigation menus, or we believe that the same thing can be readily 
accomplished using existing constructs, then let's drop it.

That's not the topic I was actioned to introduce, and its not the topic 
I was trying to present in this thread.

Roland Merrick wrote:
> Greetings Shane, I think that the subject line doesn't fully cover 
> what you are discussing. There is the age old debate between elements 
> and attributes but there is the additional dimension of their values, 
> particularly attribute values. While discussing principles is useful 
> it can also become a sterile debate. With that in mind I would like to 
> explore what you have raised using the concrete example that started 
> this thread.
> The genesis was a question from Dustin Boyd [1] "Do we really need 
> four different types of lists in XHTML 2.0?" We discussed for a while 
> and felt that the three that are already in (X)HTML were fine but were 
> not so sure about the new one : <nl /> .
> I cannot locate the original requirement that led to the creation of 
> <nl /> but I imagine it would have been something like the need to 
> clearly identify that a particular segment of a web page purpose for 
> existence was to gather together constructs related to navigation 
> (links).
> This is a common requirement and number of solutions have been arrived 
> at in various groups. The XHTML Role Vocabulary defines a value 
> *"navigation"* for use with the @role. This attribute can be applied 
> to any element. The aforementioned <nl /> (part of XHTML 2) defines an 
> ordered list of items for navigation purposes. The <nav />  (part of 
> HTML 5) defines a specialised section for the navigation/linking purpose.
> Something that I have not found is an attribute for this purpose 
> though it would be easy to imagine something like <section 
> navigation="primary">.
> Perhaps this example allows us to develop a principle but I would like 
> to make sure that a specific answer to the question of how to handle 
> navigation is arrived at. My personal view is that a section is a 
> better container than a list, though I concede that the section will 
> most likely contain a list. I prefer <nav /> to <nl /> since it suits 
> the scenarios I have explored before, particularly when adapting 
> content to different devices.
> [1] http://lists.w3.org/Archives/Public/www-html/2008May/0005.html 
> <http://lists.w3.org/Archives/Public/www-html/2008May/0005.html>
> Regards, Roland
> From: 	Shane McCarron <shane@aptest.com>
> To: 	XHTML WG <public-xhtml2@w3.org>
> Date: 	20/11/2008 16:43
> Subject: 	Semantics and the classic argument: elements vs attributes
> During the call Wednesday, there was a brief (re)discussion of whether
> we are smarter to embed semantics in elements, attributes, or attribute
> values.  This is an old argument, but it apparently still has a lot of
> heat.  I wanted to capture my opinions about this as a way of kicking
> off a discussion here rather than trying to do it during a call.  If we
> can get our positions clearly stated here, we may find that we are all
> in violent agreement.  I am not convinced this will happen, but it 
> *could*.
> Anyway, here is what I think.  XML and XHTML are designed to be extended
> at the element AND the attribute level.  In particular, XHTML M12N
> defines an infrastructure for integrating components into "hybrid"
> markup languages.  In general, we envisioned that those components would
> be developed by the W3C or other industry groups, not by individuals.  
> Why?  Because it is not easy, and such extensions need definition by a
> group to make them viable, interesting, and most importantly *supported*.
> What do I mean by supported?  Anyone can define a new element or
> attribute.  Anyone can create a hybrid markup language that includes
> that element or attribute.  With CSS2 it is possible for us to define
> presentation rules for the element or selectors that switch on the
> attribute.  But even with all of that, no user agent will know what it
> *means*.  And there is no mechanism for the person defining this element
> or attribute to describe its meaning in a way that a smart,
> "follow-your-nose" user agent could use to even determine what it
> means.  So, if a new element or attribute is defined, it will not become
> meaningful until a complete new generation of user agents is deployed.  
> And worse yet, if it is not defined by some group that user agent
> developers care about, then that new element or attribute will always
> have just as much meaning as "span" or "@title" - e.g., none at all.
> To address this problem, we ALSO introduced dynamic semantic extension
> mechanisms through RDFa and @role.  The purpose of these mechanisms is
> to allow the declaration of characteristics of a document, and associate
> those characteristics with definitions that are machine discoverable and
> machine interpretable.  The ultimate result of this, when it is done
> right, is that a role value of "foo:bar" is a vocabulary term defined in
> some vocab space pointed to by "foo" that defines the MEANING of bar
> based upon common RDF terms, or upon other vocabs that use those common
> RDF terms.
> So, we have two mechanisms.  Elements and Attributes.  Here's what I
> believe:
>    * I believe that both mechanisms are important.
>    * I also believe that we, as a part of an industry group, have the
>      wherewithal to define elements and attribute and declare their
>      semantics knowing that they will be *supported* someday.
>    * I believe it is critical that we define new elements and
>      attributes when that is what good design requires.  (e.g., in XML
>      Events we could have done all the handler stuff with attributes.
>      We could have done RDFa with values of @class.  Those would have
>      been bad design decisions.)
>    * Finally, I believe that it is also critical that we ONLY use the
>      attribute extension mechanisms when what we are doing is purely
>      and generally semantic.  If what we are doing is at all
>      structural, then we MUST NOT use the attribute extension
>      mechanisms.  It overloads our existing elements AND it permits the
>      use of the vocabulary terms anywhere - which is probably NOT what
>      we want.
> How does this apply practically?  I am afraid if I start drilling down
> to a specific element or attribute then we will get sidetracked by
> that.  I wonder if we could discuss this basic principle and see if we
> can agree on guidelines for when we define new elements or attributes,
> as opposed to when we would use our @role and RDFa extension mechanisms
> we would then have something we could use to test current and future
> decisions against.
> Opinions?
> -- 
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
> /
> /
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU/

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Thursday, 4 December 2008 17:38:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:30:31 UTC