- From: Cameron Jones <cmhjones@gmail.com>
- Date: Mon, 10 Sep 2012 16:17:38 +0100
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: HTMLWG WG <public-html@w3.org>
On Mon, Sep 10, 2012 at 3:43 PM, Steve Faulkner <faulkner.steve@gmail.com> wrote: > Hi Cameron, > >> The id and/or class are added for stylistic targeting and not semantic >> markup, so the common practice is for a different purpose than >> semantic structure. > > the same argument could be used for footer and header etc and was in > fact used, as an argument to *include* them as elements. > > Developers have long been encouraged to use semantic naming of > containers, there are many articles out there about it so you point is > off mark, here is a few > > http://woork.blogspot.de/2008/11/css-coding-semantic-approach-in-naming.html > http://mattwilcox.net/archive/entry/id/1058/ > http://sixrevisions.com/css/css-tips/css-tip-2-structural-naming-convention-in-css/ > > andy clarke [1] on CSS namimg conventions: > > > " Name for content rather than presentation or positioning > Build a structural heirarchy > Allow for flexibility and extensibility within a common framework" > > I subscribe to andy clarke's sensibilities and methodologies, but he's talking about stylistic semantics and not structural semantics. It's why its so difficult to come up with good CSS class names without directly referencing their stylistic properties. The <header>, <footer> and <aside> structural elements fall pray to stylistic interpretation which is why their structural attributes are emphasized over an inferred location. Footers could equally be called indicia's but this wouldn't really be of much benefit to anyone and just send everyone to dictionary.com. For structural demarcation, <article> represents a single piece, and <section> represents a set of pieces as part of a whole. Where is the room for another abstract structural container element which is supposed to have meaning? The problem with "main", "content" or "maincontent" i think can be summarized by the rationalization people will justify in using it: "Ooh, this <p> is some main content, better wrap it in a <maincontent> tag!". "Ooh, this <span> is also main content, better make sure i wrap it in a <maincontent> tag too!!". Hence, the concern that this tag would be grossly overused to the point of negating any intended usefulness arising from predictability. Compare this with the more distinct inference of the semantics of <article> and <section>. They infer single and multiple frequency which is difficult to be confused and are at the level which structural elements are targeted for use and practical benefit. > >> This attribute applies the necessary annotation for accessibility, >> doesn't it make more sense for people to use this and have a clear >> meant-for-accessibility annotation? It promotes annotating for web >> accessibility, which i thought you would be all for? > > I am all for building in rather than bolting on semantics via the use > of native HTML elements rather than asking authors to add special > accessibility semantics in additon to use of an element. > Wouldn't it be better is we just added to the HTML FAQ: Q. Looking for <main>, <content> or <maincontent>? A. Apply role="main" from <a href="...">ARIA<a> to the relevant element. We will end up with far more useful and predictable markup. > [1] http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html > > regards > SteveF > Thanks, Cameron Jones > On 10 September 2012 14:31, Cameron Jones <cmhjones@gmail.com> wrote: >> On Sun, Sep 9, 2012 at 8:24 PM, Steve Faulkner <faulkner.steve@gmail.com> wrote: >>> There has been continued discussion [1] in other fora on the addition >>> of an element that identifies the main content of a web page, the idea >>> has been around for a long time. >>> >> >> I participated in the discussion and was against it due to lack of >> tangible value. I'll probably just be repeating some of the comments i >> made there, here. >> >>> This element would formalise common the common practice [2] of using >>> an id value such as "content" or "main" (typically on a div) to >>> identify a container element for the main content area of a document >>> or application. >> >> The id and/or class are added for stylistic targeting and not semantic >> markup, so the common practice is for a different purpose than >> semantic structure. >> >> >>> It would also provide an element that is a HTML version of the ARIA role=main. >>> >> >> This attribute applies the necessary annotation for accessibility, >> doesn't it make more sense for people to use this and have a clear >> meant-for-accessibility annotation? It promotes annotating for web >> accessibility, which i thought you would be all for? >> >> >> On Mon, Sep 10, 2012 at 8:36 AM, Steve Faulkner >> <faulkner.steve@gmail.com> wrote: >>> Hi David, >>> >>> new HTML5 elements such as article/footer/header/nav/section etc have >>> implicit mapping to ARIA roles which are being implemented in >>> browsers. This means that rather than having to add landmark roles to >>> elements, the semantics are (when implemented) conveyed through the >>> use of the element. This is a better approach for authors as it means >>> when they use the elements they get the semantics conveyed withou >>> having to add aria roles. The addition of a maincontent element would >>> complete the provision of native HTML semantic elements that convey >>> common and useful landmark structures. >>> >> >> The problem, however, is that if the semantics are not crystal clear >> they will be misused and you end up with a semantic-soup, which >> eliminates the concise structure which we are yet to bathe in. >> >> I haven't heard a good case of what semantic value is added over >> <article> and <section>. The arguments tend to fall on authorship >> aesthetics, which is meaningless and based on a naive document >> structure which is just as substitute for CSS class names. >> >> The "implicit" mapping from semantic elements to ARIA roles fits >> sometimes but also infers costs the other way round, now people are >> adding new, meaningless structure for supporting accessibility when >> attributes already serve greater flexibility. >> >> LIke calls to wait for HTML.next, i think if this is going to move >> forward is should only be based on solid feedback from the wild, from >> consumers as well as producers. I'm more confident that ARIA will be >> integrated more universally, and people will use <article> and >> <section> for semantic encapsulation and partitioning of content which >> can be syndicated or segmented. >> >>> >>> regards >>> SteveF >>> >> >> Thanks, >> Cameron Jones > > > > -- > with regards > > Steve Faulkner > Technical Director - TPG > > www.paciellogroup.com | www.HTML5accessibility.com | > www.twitter.com/stevefaulkner > HTML5: Techniques for providing useful text alternatives - > dev.w3.org/html5/alt-techniques/ > Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Monday, 10 September 2012 15:18:11 UTC