smccandlish wrote:

To degrade gracefully, wouldn't the footer have to be wrapped around the existing div, and the CSS arranged carefully so that the end user sees the same or nearly the same rendered effect, regardless of browser and settings?

Change 212896 had a related patch set uploaded (by Prtksxna):
Use <footer> instead of <div> for #footer

https://gerrit.wikimedia.org/r/212896

Any HTML5 will not degrade gracefully on IE8; while it safely ignores the tag, any associated CSS wil also be ignored.

If we wrap div#footer with a <footer> styling will continue to get applied.

In T63801#1306267, @Prtksxna wrote:

If we wrap div#footer with a <footer> styling will continue to get applied.

What's the point? What is the net benefit for users if we use HTML5 elements in this way?

As per your suggestion, I did some looking around. HTML5 elements map to ARIA-roles, but not all browsers are aware of this mapping. As support for the role attribute is better, there is no point in using a non-sectioning element like <footer>.

However, it might be useful for us to use some of the sectioning elements like <aside> and <nav> as mentioned in T12467. While it will help in creating an outline for the document, I am not sure how useful that is, especially after seeing—

(from http://www.w3.org/TR/html5/sections.html#outlines)

The way I see it now, is that there is no immediate benefit of using these elements. But as user agents get better and start relying on some of this information it might prove helpful.

@GWicke mentioned (IRL, not on Phabricator yet) an html5shim that wouldn't cause much of a performance hit. If the performance and development cost of doing this isn't too high, then making the change if only to future-proof the front-end code, doesn't seem like a bad idea.

@Prtksxna, we can also combine role hints with semantic markup until Safari and IE have caught up. We could even add those hints dynamically with JS for just those browsers if we really wanted to avoid them in regular output.

@ssastry's comment on https://gerrit.wikimedia.org/r/#/c/196532/ seems relevant here. Copying in full—

@Krinkle and I chatted about this today. Here is my summary of his concerns.
This is not related to browser issues at all -- he is fine with using html5shiv, etc. for older browsers. In addition, all other things being equal, he would support this change.
However, he suggested that we need to better articulate the benefits of moving to this semantic DOM structure (beyond simply the fact that this is clean structural HTML) since this change will be a significant breakage. Scripts, bots, whatever depend on the previous HTML structure and they all need to be migrated over, and that is a non-trivial task (the linked phab task has some details about the things that will break with this change).
When I mentioned the fact that Parsoid generates the same HTML and we are starting to move towards parsoid html read views (and would like to bring core and parsoid html closer), he had the following observations:

1. Even with parsoid html read view, we will not be able to direclty serve parsoid-generated html -- there is a need for a post-processing step for other reasons (redlinks, etc.) which is a dependent task for this view, and we could massage parsoid html to look more like php html for images, if necessary.
2. Because of various browser bugs, and the presence of browser extensions as well as user gadgets, etc. the html that is rendered is not suitable to be directly used for editing in VE, i.e. VE will have to reload the HTML from RESTBase or wherever for editing (Ed and Roan had separately mentioned this sometime in the last couple months). I have no reason at this time to believe that they are wrong about this. In that scenario, there is no reason that the read html (after the post-processing step) need to be identical to the edit html even where the read HTML originates in Parsoid output.

We would still like to keep making progress towards eliminating the differences between read and edit html, reduce the scope of transformations done in the post-processing step. So, if nothing, we need to more intentionally make these HTML output changes -- this requires identifying what might break and developing plans for addressing those breakages, and also more clearly articulating the advantages of the change (that would offset the costs of fixing breakages). So, my understanding is that Timo wants us to be deliberate and intentional about this before this can be merged and deployed. Till such time, he suggests that we should the preserve status quo wrt the HTML structure.

@violetto, #footer already has the contentinfo role and thus is friendly with accessibility technology.

Change 212896 abandoned by Prtksxna:
Use <footer> instead of <div> for #footer

https://gerrit.wikimedia.org/r/212896

To me, one of the left-out arguments in discussion above is, that semantic HTML elements are a common code convention nowadays and it makes orientation in code a bit harder for newcomer volunteers without them.
Even though the ARIA roles are provided, they are probably not as widely known and understood.

In T63801#5985958, @Volker_E wrote:

it makes orientation in code a bit harder for newcomer volunteers.

Do you mean easier?

@Demian Thanks, updated comment to reflect our current status quo of <div id="content" class="mw-body" role="main"> as example.