This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://dev.w3.org/html5/spec/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: The footer element (Sections, Elements of HTML). Request for clarification. Re: Interaction of <blockquote> with the prohibition on nested <footer>s. "When the footer element contains entire sections, they represent appendices, indexes, long colophons, verbose license agreements, and other such content." But I expect appendices or similar would often include <blockquote>s (or just a plain <article>) which would want to include a <footer> to mark up attribution, copyright information, etc.) Given that the spec prohibits such nesting, I would like it to comment on this. Ideally it would suggest which semantic might be more important to mark up explicitly. I.e. is it more important to be able to mark up the attributions with <footer>, or to mark appendices as <footer> material? I think the implication is that it's _not_ particularly important to enclose appendices using <footer> (and it should probably be avoided if there's a chance of hitting this problem). But a casual reader who was not initially aware of the conflict could be left with the opposite impression. Possibly the reference to appendices should be removed altogether. The examples regarding indexes and long license agreements are already quite expressive. Posted from: 86.53.68.233 User agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
I guess we could allow nested footers if there happens to be a blockquote between them? Is there a real page that would be affected by this, or is it hypothetical?
Sorry, it's hypothetical, but I should be more specific. I'm thinking about ebooks with appendices, which might contain letters - "Appendix E. Letters and Correspondence". (And wondering, even if it turns out <footer> isn't really appropriate for such letters, whether some ebooks might want to include blog comments in an appendix, using <footer> to attribute each comment). I'm looking at this as a newb formatter for a Project Gutenberg e-book - HTML version, whole book as a single file. I'm trying to work out where I might use <header> and <footer>. The book I'm starting with is fairly simple. It includes an introduction, with the writers name at the end, like <http://www.gutenberg.org/files/19826/19826-h/19826-h.htm#Page_7>. An unambiguous <footer>. Then there's a couple of block-quoted letters, and the signatures are formatted in almost exactly the same way. It makes me want to apply <footer> there too. I'm not sure that's the best choice, but it doesn't seem invalid either. It does seem to fit nicely with the "blog comment" example. [Although the letters are part of a work of fiction...]. Later, I'm trying to work out whether I should enclose the front matter (title page etc) in <header>. So I look again at the semantics for large <header>s and <footer>s. I notice that <footer> suggests itself for use in books with appendix sections. And then I become confused, because one use of an appendix is to enclose primary source material such as letters. Again, <blockquote> may well be a red herring - in an appendix of letters only, <article> might be more appropriate. The main options seem to be - permit nesting like this: <footer><section><footer> - <footer> is not necessarily appropriate for marking up letters. (Perhaps particularly letters quoted within a section which has a <footer>). - this spec design isn't focussed on e-books; leave this as an edge case. (But perhaps try to avoid confusion by e.g. not mentioning appendixes when discussing <footer>.) - Perhaps I'm missing something, and the sort of appendixes I'm thinking of are different to what the writer had in mind. If <footer> isn't really appropriate for the appendixes I'm thinking of, then there's no conflict. (But again, perhaps there's a way to make the spec clearer about it).
mass-move component to LC1
Why would a letter have a <footer>? I'm not sure I really follow. I'm not fundamentally opposed to changing this, but it would be easier to determine what is really needed if there was a concrete example to study.
## Why would a letter have a <footer>? ## In a letter, <footer>Yours sincerely, Alan</footer> might be used, to mark up similar information to <footer> in a blog comment, as used in the example for "4.4.4 The article element". The letter itself would have to be an <article> or <blockquote>. Put that inside "Appendix B: Correspondence" of a book, which is marked as an appendix by being enclosed in the top-level <footer>, and you have your illegal nesting. It's unlikely to happen outside Project Gutenberg, because everywhere else would put the Appendix in a separate HTML file. A simpler example might be an Afterword which could be of interest in itself. E.g. the print edition of "The Atrocity Archives" (novel published in 2004) ends with an essay - <footer> <article> <h1>Afterword: Inside the Fear Factory</h1> ... <footer class="aligned-right"> Charles Stross<br/> Edinburgh, UK<br/> April 2003<br/> </footer> </article> </footer> </body> The inner footer seems exemplary to me, so I have to stop thinking that appendices etc. should usually be enclosed in <footer>. Noting that the spec doesn't (I think) explicitly _require_ me to do so, and/or that representing the structure of an entire book is not a priority of HTML5. Again - if that's how it ends up, I don't think it's going to be a problem for the cases I'm thinking of. Maybe it would be clearer if <article> (and <blockquote?) was also banned inside <footer>? Is it ever appropriate to use <article> (or blockquote?) if you're not allowed to include a <footer>? I really don't know. Hmm. If a "verbose license agreement" in a <footer> was a Free Software-like license (a standard license released by someone like the FSF), it should be marked as an <article>, I should think. If you literally included the entire text of the Creative Commons license... then it does appear to have a footer of its own http://creativecommons.org/licenses/by/3.0/legalcode (search for "Creative Commons Notice"). which affects books which are published online as a single HTML file, under the Creative Commons license. Historically, that's the preferred format for conversion into arbitrary offline reading formats. Here's an example book which includes the full CC license text (footer > article ?), including the "Creative Commons Notice" (footer > article > footer ?). http://www.kschroeder.com/archive/Ventus/
Those are some valid examples, I think. I wonder how common they are. I'm going to mark this bug "LATER" for now, so that we can collect experience with the current state of things and see what the right direction is here. I agree with the points you've raised. The reason I'm not just doing what you suggest is that there is a cost to allowing arbitrary markup — we fail to catch authoring errors, and we encourage rather messy markup. Whether the cost is higher or lower than the gains is unclear, which is why I haven't simply rejected the bug. In the meantime, please don't hesitate to add more examples of indirectly nested footers, especially on real pages or documents. Also worth looking for it sites where people nest footers incorrectly (i.e. where they do it but it doesn't make sense).
This bug was cloned to create HTML WG bug 19054.
To make progress on this we probably need to study cases where people (probably unknowningly) violated the spec by nesting <footer>s, and see whether those cases are cases where it's reasonable, or whether it's an error that they would have caught if they used a validator.
W3C Bugzilla is closing down, and as such we're closing all feature request bugs against HTML as "WONTFIX", at least wontfix-in-this-bugtracker. (We have been told the Bugzilla URLs will remain active, but read-only.) If you still think this feature is valuable, please feel free to open a new issue against https://github.com/whatwg/html/issues ; the community has gotten much more active and involved since the Bugzilla days, and you might get a more useful dialogue there. If you do so, note that it seems like the next step still remains to be doing the research indicated in comment 8.