- 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>
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
<nl>
or
<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">
but
<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
values.
--
- 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