- 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