> If the aside is equivalent to a printed sidebar, there should be no nav
> elements, and shouldn't be referenced as a web page sidebar. This confuses the
> semantics of the element, which decreases its value.

It's intended to be used for anything that's "considered separate from the main content of the page".  That can often include navs, and certainly includes the majority of what you'd find in a web page sidebar.  Anything that, if removed, wouldn't change the meaning of the content is a candidate for wrapping in an aside.

In other words, it's not directly equivalent to a printed sidebar, but is pretty well analogous.  You just don't often see navigation in sidebars in print; you do on the web.
 
> In addition, no navigation should be embedded in an aside element--not if it is
> to be used for pull quotes or typographical sidebars. Placing navigation in the
> aside could lead to it being skipped by some user agents, who treat the
> element's semantics seriously.

That's precisely what we want.  I have to employ weird tricks to make it easy to skip over the navigation and sidebar content for keyboard and screen-reader users.  If jumping past these areas was a native ability, it would be much better for my users.  Note that "jumping past" is not the same as "ignoring completely forever"; you should always be able to read what's in an aside, it's just not directly relevant to the content in front of you.

(In reply to comment #1)
> > If the aside is equivalent to a printed sidebar, there should be no nav
> > elements, and shouldn't be referenced as a web page sidebar. This confuses the
> > semantics of the element, which decreases its value.
> 
> It's intended to be used for anything that's "considered separate from the main
> content of the page".  That can often include navs, and certainly includes the
> majority of what you'd find in a web page sidebar.  Anything that, if removed,
> wouldn't change the meaning of the content is a candidate for wrapping in an
> aside.
> 
> In other words, it's not directly equivalent to a printed sidebar, but is
> pretty well analogous.  You just don't often see navigation in sidebars in
> print; you do on the web.
> 
> > In addition, no navigation should be embedded in an aside element--not if it is
> > to be used for pull quotes or typographical sidebars. Placing navigation in the
> > aside could lead to it being skipped by some user agents, who treat the
> > element's semantics seriously.
> 
> That's precisely what we want.  I have to employ weird tricks to make it easy
> to skip over the navigation and sidebar content for keyboard and screen-reader
> users.  If jumping past these areas was a native ability, it would be much
> better for my users.  Note that "jumping past" is not the same as "ignoring
> completely forever"; you should always be able to read what's in an aside, it's
> just not directly relevant to the content in front of you.
> 


A web sidebar is not the same as a typographical sidebar. It's unfortunate that the term was used for the web, because sidebars in the web really are nothing more than separate sections. Their use is specific to the web page, not the content. 

Originally, the aside element had a clean semantic definition, where it was that of a typographical sidebar. However, the HTML5 editor "listened" to developers, and weakened the semantics of the element so it can supposedly be used as a web page sidebar, or even pseudo-footer navigation[1]. Something that can be used for a pull quote is not the same thing as something that can be used for a web page sidebar. 

This was an error. It confuses the semantics of the element. It no longer is equivalent to a typographical sidebar. It's really nothing more than an element that represents "something that is no content". 

That's too loose, and not useful. And, unfortunately, such looseness will lead to confusion about use, and aside will, most likely, end up being used incorrectly. 

[1] http://html5doctor.com/aside-revisited/

(In reply to comment #0)
> Currently, the following line is given with the aside element:
> 
> "The element can be used for typographical effects like pull quotes or
> sidebars, for advertising, for groups of nav elements, and for other content
> that is considered separate from the main content of the page."
> 
> If the aside is equivalent to a printed sidebar, there should be no nav
> elements, and shouldn't be referenced as a web page sidebar. This confuses the
> semantics of the element, which decreases its value.

<nav> elements have a more specific semantic than <aside>. This argument is like saying that because <div> exists, there should be no <p> element.

> Another section element should be used for a web page sidebar, the same as a
> section should be used for the main content (or a second sidebar, etc). 
> 
> In addition, no navigation should be embedded in an aside element--not if it is
> to be used for pull quotes or typographical sidebars. Placing navigation in the
> aside could lead to it being skipped by some user agents, who treat the
> element's semantics seriously.

Indeed, it would generally be better to use <nav> in the specific case of a navigation sidebar (as opposed to a general sidebar for other purposes).

> If there is an HTML5 primer, we would want to clarify that the aside element is
> not used for web page sidebars.

That would only be the case for navigation sidebars. However, the following kinds of sidebars would be fine to put in an <aside> element:

- a sidebar containing ads
- a sidebar containing a separate related article (i.e. the exact case of a print sidebar)
- a blogroll sidebar (this would not match the semantics of <nav> which state "Not all groups of links on a page need to be in a nav element  only sections that consist of major navigation blocks are appropriate for the nav element." -- links to other blogs would not generally be considered major navigation blocks)
- a sidebar listing recent posts (this would also not be a "major navigation block")
- sidebars containing a list of contacts, as in some mail apps
- sidebars containing widgets/gadgets which are ancillary to the main page
- a sidebar providing contact information for the author or authors of the site
- a sidebar on an online store page listing most popular items or top sellers (this would not be a major navigation block)- sidebars containing one or more of the foregoing, as well as a navigation section (which would then be in a <nav> tested in the <aside>)

Note: the above are all examples from real sites.

(In reply to comment #3)
> (In reply to comment #0)
> > Currently, the following line is given with the aside element:
> > 
> > "The element can be used for typographical effects like pull quotes or
> > sidebars, for advertising, for groups of nav elements, and for other content
> > that is considered separate from the main content of the page."
> > 
> > If the aside is equivalent to a printed sidebar, there should be no nav
> > elements, and shouldn't be referenced as a web page sidebar. This confuses the
> > semantics of the element, which decreases its value.
> 
> <nav> elements have a more specific semantic than <aside>. This argument is
> like saying that because <div> exists, there should be no <p> element.
> 
> > Another section element should be used for a web page sidebar, the same as a
> > section should be used for the main content (or a second sidebar, etc). 
> > 
> > In addition, no navigation should be embedded in an aside element--not if it is
> > to be used for pull quotes or typographical sidebars. Placing navigation in the
> > aside could lead to it being skipped by some user agents, who treat the
> > element's semantics seriously.
> 
> Indeed, it would generally be better to use <nav> in the specific case of a
> navigation sidebar (as opposed to a general sidebar for other purposes).
> 
> > If there is an HTML5 primer, we would want to clarify that the aside element is
> > not used for web page sidebars.
> 
> That would only be the case for navigation sidebars. However, the following
> kinds of sidebars would be fine to put in an <aside> element:
> 
> - a sidebar containing ads
> - a sidebar containing a separate related article (i.e. the exact case of a
> print sidebar)
> - a blogroll sidebar (this would not match the semantics of <nav> which state
> "Not all groups of links on a page need to be in a nav element  only sections
> that consist of major navigation blocks are appropriate for the nav element."
> -- links to other blogs would not generally be considered major navigation
> blocks)
> - a sidebar listing recent posts (this would also not be a "major navigation
> block")
> - sidebars containing a list of contacts, as in some mail apps
> - sidebars containing widgets/gadgets which are ancillary to the main page
> - a sidebar providing contact information for the author or authors of the site
> - a sidebar on an online store page listing most popular items or top sellers
> (this would not be a major navigation block)- sidebars containing one or more
> of the foregoing, as well as a navigation section (which would then be in a
> <nav> tested in the <aside>)
> 
> Note: the above are all examples from real sites.
> 


Yes, i have seen sidebars in web pages. 

However, these are not examples of typographical sidebars. Nor are they equivalent to what is known as a "pull quote". 

Confused semantics will lead to misunderstandings and misuse of the new HTML5 elements. 

(In reply to comment #2)
> This was an error. It confuses the semantics of the element. It no longer is
> equivalent to a typographical sidebar. It's really nothing more than an element
> that represents "something that is no content". 

That's precisely the semantics we're looking for (where the "no content" label is in relative to the main content of the page).  Web pages often include tons of crap that are not required to be read to understand the page; we sighted people can easily see that and skip over such content until we choose to specifically look at it, but it's more difficult for people using screenreaders to do so.  Marking up that semantic explicitly will hopefully allow such users the ability to emulate the ease of ignoring irrelevant things that we sighted take for granted.

You've latched onto a wrong idea about the 'appropriate' semantics, and then are judging the element based on that.  It states in the element definition what the semantics actually are.

 
> That's too loose, and not useful. And, unfortunately, such looseness will lead
> to confusion about use, and aside will, most likely, end up being used
> incorrectly. 

As noted above, it's actually a very useful semantic.  It's also very difficult to misuse <aside> because of that; even putting the main nav of the page in an <aside>, while possibly not ideal, wouldn't be 'incorrect'; at worst it's unnecessary because users should also be able to skip <nav>s.

(In reply to comment #4)
> 
> 
> Yes, i have seen sidebars in web pages. 
> 
> However, these are not examples of typographical sidebars. Nor are they
> equivalent to what is known as a "pull quote". 
> 
> Confused semantics will lead to misunderstandings and misuse of the new HTML5
> elements. 
> 

All of the examples I cited satisfy the current semantics of <aside>, but not <nav>. They also seem clearly distinct from a plain old ordinary <section> that's part of the main content of the page, in that they are ancillary, and not directly related to the main content. Thus, <aside> has meaningful semantics in this case that go beyond <section>. Just as <header> is more meaningful than <section>, even though it's a kind of section.

Arguments against aside (and probably figure) which try to limit their applicability based on purely visual characteristics in the industry using only a more restricted medium they originate from preclude judicious generalisation. Just like under the notion of operators we have invisible operators in Unicode (InvisibleTimes, InvisiblePlus and InvisibleSeparator, prominently featured in MathML) with no direct counterparts in print, we can have aside in HTML to mark up the kind of things commonly used in hypertext documents which are sematically close to printed asides.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Concurred without counter-arguments above. As Shelley says, the draft was updated based on feedback from Web developers. Given that Web developers are the people who will be using this technology, that seems wise, and not at all something to be ashamed of.

There will always be one group of people or another who want something stated, as is, in the document. Our job in the Working Group, though, is to ensure that the HTML5 specification is consistent, does not introduce extraneous material, does not encapsulate material best left for other standards bodies (or specs), or does not introduce confusion by allowing too generic a definition on our supposedly "semantic" new elements.

Originally aside was defined in such a way that it is consistent with the publishing industry's concept of "sidebar". But then some folks asked that it be used for sidebar, primarily because sidebar was used in the earlier description. 

A sidebar should be nothing more than another section. It is a unique column, all of its own. By the over broad redefining of aside, we've basically limited its usefulness.

I would like this escalated to a tracker issue. Please use bug title, and original comment as the tracker issue body.

This has been escalated to a tracker issue:

http://www.w3.org/html/wg/tracker/issues/91