Page MenuHomePhabricator

Vector: Use semantic HTML5 elements where applicable
Open, MediumPublic

Description

With T248137 in, we're able to use semantic HTML5 elements without restrictions.
Elements aimed for are header, main, nav and footer.

Example specification for nav at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/nav

Additionally we can remove ARIA landmark role definitions when element automatically commmunicates landmark.


https://developer.mozilla.org/en-US/docs/Web/HTML/Element/aside was considered as well, but not seen as correct semantic representation of anything currently in Vector. Given its “content is only indirectly related to the document's main content” and article tools are directly related to the content for example

QA steps

  • Ensure there are no layout regressions on beta cluster in comparison to production in Internet Explorer 8 and 11.
  • Ensure "Reader" mode works in Firefox, Safari and Mobile Safari in production. Wikipedia's domain name quite regularly gets special-cased to optimise or fix things they run into.

+++ This bug was initially created as a clone of Bug #61615 (now T63615) +++
Version: 1.24rc
Severity: enhancement

Related Objects

StatusSubtypeAssignedTask
ResolvedGoalovasileva
OpenNone
Resolvedovasileva
ResolvedSpikeovasileva
ResolvedSpikephuedx
Resolvedovasileva
OpenSpikeVolker_E
ResolvedSpikeovasileva
Resolvedovasileva
ResolvedBUG REPORTmatmarex
Resolvedovasileva
ResolvedJdlrobson
Resolvedphuedx
Resolvednray
ResolvedMayakp.wiki
ResolvedMayakp.wiki
Openovasileva
OpenNone
ResolvedEdtadros
OpenNone
OpenNone
DuplicateNone
ResolvedNone
OpenVolker_E
Opensgrabarczuk

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:24 AM
bzimport set Reference to bz64477.
bzimport added a subscriber: Unknown Object (MLST).

This would have to be done separately for each affected skin.

Change 212897 had a related patch set uploaded (by Prtksxna):
Use <nav> in renderNavigation()

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

Change 212898 had a related patch set uploaded (by Prtksxna):
Use <aside> in renderPortal()

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

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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 24 2015, 12:08 AM

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

We support JS here right and this is a solved problem? We can just use a shim [1].

[1] http://tatiyants.com/how-to-get-ie8-to-support-html5-tags-and-web-fonts/

Jdlrobson changed the task status from Open to Stalled.Nov 3 2015, 1:23 AM

What's blocking us from getting this going again?

GOIII added a subscriber: GOIII.Nov 3 2015, 2:56 AM

What's blocking us from getting this going again?

I'm guessing it is mostly the idea that IE8 and lower users will not be able to utilize these new tags.

<time> and <mark> were whitelisted in 1.21 however, so I'm not so sure IE≤8 support is still a valid issue.

Plus you've linked the shim solution for that concern just above anyway not to mention official support for IE8 ends on January 12, 2016 to boot.

The other reason is probably concern over the other HTML5 introduced tags like section or figcaption and how they'd fit-in or conflict-with other parser or extension generated tags. Still, that has more to do with the blocking tasks than it does with this one specifically.

At the very least you'd think they'd whitlelist some or all of these HTML5 tags on test.wikipedia.org & test2.wikipedia.org at this point in time - I don't see any good reason not to given the coming date dropping IE8 support is unavoidable.

GOIII updated the task description. (Show Details)Nov 3 2015, 3:08 AM
GOIII set Security to None.

<time> and <mark> were whitelisted in 1.21 however, so I'm not so sure IE≤8 support is still a valid issue.

IE8 doesn't crash when unknown elements are used. It just displays them as regular text. Which for content such as time and mark is a perfectly acceptable fallback in this case.

However using them for critical parts of the layout is a separate issue that has a potentially much larger impact. For those one or two elements I think we can stick with a <div> for simplicity sake. Relevant role="" attributes are available for accessibility. If there are any substantial gains from using the elements we could even consider using both (as long as we're talking about no more than a handful of central elements part of the skin layout).

GOIII added a comment.Nov 3 2015, 8:06 AM

. . . If there are any substantial gains from using the elements we could even consider using both (as long as we're talking about no more than a handful of central elements part of the skin layout).

Its wise to be cautious given the risk but supporting all the tags in question is going to happen someday (like it or not; IE8 still supported or not).

The only tag that I'm pretty sure is going to be a headache is HTML5's <section> tag versus the current LST extension's use of a self-closing <section begin= /> and <section end= /> tags. (exampled here; tags & content between <section> and </section> being stripped?)

Otherwise, I don't see the harm in activating (whitelisting) the ones without such "controversy" on at least test2.wikipedia.org for starters -- how else can we begin to discover those substantial gains and the crippling pitfalls?

Change 212897 abandoned by Prtksxna:
Use <nav> in renderNavigation()

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

Change 212898 abandoned by Prtksxna:
Use <aside> in renderPortal()

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

@Prtksxna Why did you abandon these?

@Prtksxna Why did you abandon these?

Feel free to un-abandon and take over.

Danny_B moved this task from Unsorted to Semantic HTML on the Accessibility board.
Volker_E removed a subscriber: wikibugs-l-list.
Demian added a subscriber: Demian.Apr 3 2020, 3:57 AM
Jdlrobson changed the task status from Stalled to Open.Apr 7 2020, 8:14 PM
Jdlrobson added a project: Readers-Web-Backlog.

@Jdlrobson As I understand it the IE8 RFC is not blocked on this skin change, and the opposite neither. Using HTML5 in production has had a go-ahead for 3+ years, since we shipped the html5shiv on all page views.

Volker_E renamed this task from Wrap MediaWiki toolbar menu to HTML5 <nav> and <aside> tag to Vector: Wrap MediaWiki toolbar menu to HTML5 <nav> and <aside> tag.May 7 2020, 1:46 AM
Volker_E edited projects, added Desktop Improvements; removed MediaWiki-Interface.

Change 594819 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] Use semantic HTML5 elements where applicable

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

Volker_E added a comment.EditedMay 7 2020, 10:06 PM

Given the current mix of scope in Vector sidebar, having for example page tools in the panel for the portal, aside is not the right element to choose.
Therefore narrowing scope of this task.

We will watch structural elements application in (modern) Vector and refine if useful with the further steps taken in Desktop Improvements project.

Volker_E renamed this task from Vector: Wrap MediaWiki toolbar menu to HTML5 <nav> and <aside> tag to Vector: Use HTML5 <nav> where applicable.May 7 2020, 10:08 PM
Volker_E updated the task description. (Show Details)

Change 594819 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Use semantic HTML5 elements where applicable

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

Volker_E updated the task description. (Show Details)May 7 2020, 10:18 PM
Volker_E renamed this task from Vector: Use HTML5 <nav> where applicable to Vector: Use semantic HTML5 elements where applicable.May 7 2020, 10:37 PM
Volker_E updated the task description. (Show Details)
Iniquity added a subscriber: Iniquity.
Krinkle removed a subscriber: Krinkle.Sat, May 9, 2:24 AM
Krinkle added a comment.EditedSat, May 9, 2:29 AM

Once this rolls out, be sure to also test "Reader" mode in Firefox, Safari and Mobile Safari. Not just locally or beta, but also in production. Wikipedia's domain name quite regularly gets special-cased to optimise or fix things they run into.

Volker_E added a subscriber: Johan.

@Johan Let's add a user notice:

Over-qualified CSS selectors of portals in Wikimedia skins have been changed. <code>div#p-personal</code>, <code>div#p-navigation</code>, <code>div#p-interaction</code>, <code>div#p-tb</code>, <code>div#p-lang</code>, <code>div#p-namespaces</code> or <code>div#p-variants</code> are now all removed of the <code>div</code> qualifier, as in for example it is <code>#p-personal, #p-navigation …</code>. This is so the skins can use HTML5 elements. If your gadgets or user styles used them you will have to update them.

Volker_E claimed this task.Mon, May 11, 8:18 PM
Volker_E added a subscriber: Edtadros.
Volker_E updated the task description. (Show Details)Mon, May 11, 9:32 PM

@Johan User notice task has actually been split out into T252467 to be even clearer and better addressing gadget developers and users script/stylesheet editors.

Change 595962 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/Vector@master] Use semantic HTML5 elements where applicable with minimal disruption

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

Change 595962 abandoned by VolkerE:
Use semantic HTML5 elements where applicable with minimal disruption

Reason:
Superseded by I540d9a41fc7fd580c5d61b90480e8745ae145850

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

Jdlrobson moved this task from Needs triage to Technical on the Vector board.Fri, May 15, 4:59 PM

Change 596312 had a related patch set uploaded (by Krinkle; owner: VolkerE):
[mediawiki/skins/Vector@master] Use semantic HTML5 elements where applicable

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

Izno added a subscriber: Izno.Tue, May 19, 1:58 AM
Izno added a comment.Tue, May 19, 2:23 AM

Kind of curious to know why <article> isn't in the list. Seems like an obvious inclusion. :)

@Izno Would you expand what you're missing without [[ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article | article ]]? We feature main and there's no obvious semantical win in my experience to additional define article.

We are down down to 261 pages managed by 214 users across all wikis. Pending a reply to T252467#6197821 I think we should push ahead with this change.

Jdlrobson raised the priority of this task from Low to Medium.Fri, Jun 5, 8:48 PM