On Nov 7, 2012, at 8:52 AM, Ojan Vafai <o...@chromium.org> wrote: > On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters <sim...@opera.com> wrote: > >> My impression from TPAC is that implementors are on board with the idea of >> adding <main> to HTML, and we're left with Hixie objecting to it. >> > > For those of use who couldn't make it, which browser vendors voiced > support? I assume Opera since you're writing this thread.
I personally think <main> would be useful. I don't think it has a huge benefit, but it has modest benefits, like <aside>, <header>, <footer> and <section>. I also think the implementation costs are low. The reasons I think it has some benefits: - Even though heuristics (such as the scooby-doo algorithm or even guesses based on role or class, or the layout) will always be necessary in some cases, it's still good to have a simple and relatively trustworthy marker of the main content. This is useful both for accessibility purposes and for other browser features that want to find the main content. In many cases, we have found that even when semantics can be heuristically inferred, having an explicit marker is still useful. For example, you can usually guess that some text is an address, but we still have a microformat that helps identify such data unambiguously. - From a language design perspective, it seems inelegant to identify the main content solely by what it is not. I realize that this is a matter of taste and that tastes may differ. By analogy, in imperative programming languages that have a main function, it is generally marked with as specific name rather than just by not being any of the non-main functions. This is not perfectly analogous, but it still seems motivating to me. - The "Scooby-Doo algorithm" is not actually defined in HTML5 afaict so I am not sure what the spec recommends to find the main content or which elements should be excluded. I presume that header, nav, footer and aside are excluded. What about address? small? Arbitrary other elements with non-main ARIA landmark roles? It seems insufficient to me to say that the use case of finding the main content is satisfied by an algorithm that's ambiguous and not actually defined anywhere. Given the state of play, authors have no way to be confident that their main content can be identified correctly, and implementors have no way to know how to find it. - I'm not confident that the sectioning elements in HTML5 exhaustively cover all possible forms of non-main content. If not, then it's likely that authors will have legitimate reason to have non-main content inside <body> which cannot reliably be skipped by the Scooby-Doo algorithm. Overall, I would not fall on my sword to get the <main> element into WebKit but I would not reject a patch to add it either, assuming a sufficiently good spec exists for it somewhere. > This idea doesn't seem to address any pressing use-cases. I don't expect > authors to use it as intended consistently enough for it to be useful in > practice for things like Safari's Reader mode. You're stuck needing to use > something like the Scooby-Doo algorithm most of the time anyways. I don't > outright object, but I think our time would be better spent on addressing > more pressing problems with the web platform. The same argument could have been made for <article>, but the implementation cost was so low that the benefit didn't have to be huge. I think the same applies to <main>. Regards, Maciej
