"Don’t use it if article, aside or nav is more appropriate"

CommentFileSizeAuthor
aside.patch620 bytesseutje
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mason@thecodingdesigner.com’s picture

I don't think this is a case for ASIDE. Since this is a generic use case and we can't know the content. we don't know if the 'secondary' element is related semantically to the 'primary' (which might be the case for ASIDE) or if it's simply another place for a piece or group of content. SECTION seemed like the better choice between the options of SECTION, ASIDE, and DIV.

I think themers will need to address the other options based on the content a specific site will have. Maybe we can help them with documentation, or perhaps programmatically with some preprocess logic or theme_settings.

masagin’s picture

I agree with canaryMason. This should be SECTION or even a DIV. Often there's so much non-related stuff in sidebars that it's better to use more general elements. On the other hand, some blocks inside the sidebar could possibly be ASIDES but we can't know that beforehand. Themers must decide on their own.

seutje’s picture

do you mean "content that is tangentially related to the content that forms the main textual flow of a document."?

seutje’s picture

heh, by that logic, you shouldn't even be using section or footer anywhere

often there's navigational elements in the footer and stuff in the main content area that isn't (or shouldn't) be in the outline

if there's stuff in your sidebars that doesn't relate in any way to the content, you're probably doing it wrong

people will find a way to misuse things, whichever way you go... I figured we could assume people would be doing it right

tim.plunkett’s picture

Sidebars aren't asides. Nothing persistent like a region should be.

"Just because some content appears to the left or to the right of the main content isn’t enough reason to use the aside element. Ask yourself if the content within an aside could be removed without reducing the meaning of the main content of the document or section. Pullquotes are a good example of tangentially related content; they’re nice to have, but you can remove them without affect- ing the comprehension of the main content."

masagin’s picture

Tim, ASIDE was slightly reconsidered and it can be used for sidebars not only "tangentially related content". http://html5doctor.com/aside-revisited/

Still, I'm not sure about this particular case.

mason@thecodingdesigner.com’s picture

Now I'm reconsidering using SECTION. Since we don't / can't know the content is these are just wrappers for style and should probably be DIVs. Perhaps we don't implement SECTION until we're working on things like views tpl.php files. ASIDE could be applied to specific blocks, or specific CCK fields. Nodes should probably default to ARTICLE, but I'm sure that won't be right 100% of the time.

tim.plunkett’s picture

Rereading the current spec (thanks bganicky!), I can see why it might make sense to make the sidebar an ASIDE. I can't think of an example where the contents of a sidebar aren't in any way related to the contents of the page.

The region in question is $right. In Mothership, that was declared as "right sidebar". Currently, html5_base has no regions, so I'm not sure of the intention.

mason@thecodingdesigner.com’s picture

Perhaps we should take a step back and define what our basic regions are? Maybe we can asume/suggest some semantic meaning based on what regions themers choose to use? We could have a $secondary_content region, a $sidebar region, and a $side_nav region. Each of these might display in the same place (in a column on the right for example) but would be marked up with SECTION, ASIDE, and NAV respectively.

tim.plunkett’s picture

I was thinking the same thing. Perhaps this should be put on hold until we resolve #864572: Which regions?.

seutje’s picture

also note that it was sort of designed that the first (top level) element encountered that isn't <header><nav><aside><footer> would be considered the main content, regardless of it being a <div><section><article> or whatever, which is one of the reasons there was no <content> element described in the spec

so please, don't use <section> for sidebars as I can imagine many cases where this would be misinterpreted as the main content

jensimmons’s picture

When I first heard about <aside>, I thought, oh sidebars. Then I read more, and saw people saying no way, sidebars != <aside>. (This was a while ago. A year or more ago.)

More recently, I've been reading Jeremy Keith's book, and Bruce Lawson's book, and I've been left with the sense that our sidebars absolutely should be <aside>s. Lawson goes on about <aside> at length, in fact, and the conclusion is basically we should use <aside> in this case.

I'm going to read it again, but so far, my vote is let's use <aside> to wrap the sidebars.

mason@thecodingdesigner.com’s picture

Just re-read the spec, and I can see the case for sidebars-as-ASIDEs. I'm convinced. Is that a consensus?

seutje’s picture

btw, not really related to this issue, but the wrapper shouldn't be printed if there's nothing in it

seems like that was a bug directly transferred from mothership

-> #875038: Don't print empty containers && #875042: Don't print empty containers

jensimmons’s picture

Status: Needs review » Fixed

Everything discussed in this thread is now implemented.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jensimmons’s picture

Version: » 7.x-2.x-dev
Category: bug » feature
Status: Closed (fixed) » Needs work

I can't remember why I said this issue was fixed. Looking at the theme now, there are no custom tpls for the two Drupal core sidebar regions, so they use the default region template, making them <section>s. I'm changing this now, as I still believe that the most common use of sidebar content makes them asides to the page.

jensimmons’s picture

Status: Needs work » Fixed

oh perhaps this ticket was closed for the 6.x branch. Well, I just adjusted it for the 7.x branch.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.