W3C home > Mailing lists > Public > public-xhtml2@w3.org > January 2009

Re: Semantics and the classic argument: elements vs attributes

From: Tina Holmboe <tina@greytower.net>
Date: Wed, 14 Jan 2009 15:09:09 +0100 (CET)
To: Shane McCarron <shane@aptest.com>
cc: XHTML WG <public-xhtml2@w3.org>
Message-ID: <tkrat.8ae9f65611e12ec3@greytower.net>

On 20 Nov, Shane McCarron wrote:

> 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

  First - I agree. We need to discuss the principle, and the philosophy,
  not the specifics. That, actually, is part of my problem here. I
  rather dislike, to be blunt about it, the mix and match of two
  entirely different methods for encoding semantics.

  So, bravo Shane. Well put.

  I'll be brief. The very reason for using generic coding language is to
  ensure that, regardless of method, content is marked up as what it IS,
  as opposed to how it looks.

  The advantage, and the very reason why we use such languages, is that
  a processor - regardless of which type - can take a piece of content
  and present this to its user in a manner depending entirely on the
  user's physical reality - a reality the author knows nothing about.

  When confronted with a quotation, for example, the processor can
  convey both the content AND the fact that it IS a quotation to its
  user independently of how the author believe it should be presented or
  interacted with. This is valuable.

  In the end it doesn't matter whether an author write



   <ul role="navigation">

  As long as the processor - for instance a browser - known how to
  create a node tree, extract attributes, AND understand what certain
  keywords such as "nl" or "navigation" MEAN, it can do a proper job of
  presenting the information.

  However. Up to this point - ie. up to XHTML 1.1 - we have encoded such
  semantic information using the element type name - NL, in this case.

  There is no technical reason why we should change that. Subsequently I
  suggest that we

   (a) Use element type names when adding NEW semantics, and
   (b) Use @role when we REFINE existing semantics.

  I wouldn't object to

   <p role="introduction">


   <menu> or <nl>

  would be far more logical at this point in time than would

   <list role="navigation">

  although we could discuss

   <ol role="navigation">

  It won't matter for browsers, after all. They already know how to deal
  with both elements AND attributes, but will need to learn new keywords
  regardless of whether these keywords are element names or attribute
 - Tina Holmboe       siteSifter                  Greytower Technologies
            http://www.sitesifter.co.uk          http://www.greytower.net
      Website Quality and Accessibility Testing
Received on Wednesday, 14 January 2009 14:19:59 UTC

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