W3C home > Mailing lists > Public > public-html@w3.org > September 2012

Re: maincontent element

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Mon, 10 Sep 2012 16:43:16 +0200
Message-ID: <CA+ri+V=yTVHmOUp+bbohPHrLAY6oqQURm562t7yHN235C0hYVQ@mail.gmail.com>
To: Cameron Jones <cmhjones@gmail.com>
Cc: HTMLWG WG <public-html@w3.org>
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"



> 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.

[1] http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html

regards
SteveF

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 14:44:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 September 2012 14:44:24 GMT