This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section: http://www.whatwg.org/specs/web-apps/current-work/#the-address-element Comment: The earlier version where it said "If an address element applies to a section of a document, then it represents contact information for that section only" was a better approach. I see what you're after here, but it's way too 1996. "A web page" or "a document" in 2010 terms is very, very often a composite content stream with numeous sources with independent attribution (contact info). This needs to work down to the div level. I would suggest that this be done with id attributes and some attribute of the address element that refers to an id attribute (e.g. <div id="foo">...<address scope="foo">...</address></div> Please re-examine this with a more "Web 2.0+" view. - Stanton - gmail: smccandlish - please subscribe me to this bug (I'm submitting this thru the floating mini-form at the bottom of http://whatwg.org/specs/web-apps/current-work) Posted from: 68.35.93.63
Nevermind request to add me to the bug; I noticed the pop-up link that allowed me to get the bug number and come here to get registered and do it myself.
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: Did Not Understand Request Change Description: no spec change Rationale: What is the use case for providing author contact information on a basis more fine-grained than the nearest <article>?
As I said, "a web page" today frequently consists of all sorts of inlined content piped in from somewhere else, and not attributable to the author of the page as such. Not all such items are suitable to be marked up as <article>s. An extremely common use case would be discussion forums, like this very Bugzilla, or any webboard, or any "comments" section on a blog page, or the talk pages of any wiki. Each post is individually attributable, and would probably be a <div>. The *initial* post should arguably be an <article>, but the responses arguably should not be, since they are not independent, but subordinate to and dependent upon the original "article" (post, announcement, whatever). If you re-read my original post now, it should make more sense.
The spec explicitly and normatively says you can use <article> in those cases: """ When article elements are nested, the inner article elements represent articles that are in principle related to the contents of the outer article. For instance, a blog entry on a site that accepts user-submitted comments could represent the comments as article elements nested within the article element for the blog entry. """ http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-article-element The name is arguably not ideal, but that's true for most HTML elements, and it's usually hard to come up with better ones.
I still don't see any reason this is applied at the article level instead of div. Basically it's just going to force people to have to re-code billions (across the whole Web, not individually) of divs as articles for no real reason. The original wording of HTML5's address, as I quoted in first message on this thread, made a lot more sense.
No version of HTML5 ever had the text you quoted in comment #0. That was part of a totally different spec, "HTML: The Markup Language Reference": http://dev.w3.org/html5/markup/address.html People are expected to use semantic elements such as <article> rather than non-semantic elements such as <div> when they want the relevant semantics. <div> is only meant to be used when no other element is applicable. Since a number of semantic elements were added in HTML5, this will require some rewriting compared to HTML 4, yes. Other things key off <article> specially too, like <time pubdate> and (IIRC) the header algorithm.
I didn't say is should ONLY apply to div. I said that it should be applicable down to that level (i.e., the level of block elements generally, to spell it out). That is, it should also apply to blockquote and other elements that could contain address element information. Now that I think of it, even some inline elements could use this. For example, source code (in the code element) often has such information in code comments. It would be kind of absurd to mark up a blockquote, code block, etc., as an article AND as a blockquote or code or whatever, simply to be able to use address. Such elements have *their own* semantics, and should not have to be stuffed within the semantic "wrapper" of the article tag for no good reason.
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: If it applied to <div> you'd be unable to wrap your <article>'s <address> in a <div> for styling purposes, which would be bad. I really don't see why applying it to <article> is a bad thing. That's exactly what <article> is for. In a discussion medium such as this bug database, each comment should absolutely be an <article>. That's what <article> is explicitly intended to be for.