Last modified: 2014-11-19 20:05:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 23932 - Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, figcaption, figure, footer, header, hgroup, mark, nav, section, time
Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, f...
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Lowest enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 36755 49097
Blocks: html5
  Show dependency treegraph
 
Reported: 2010-06-12 17:23 UTC by Michael Zajac
Modified: 2014-11-19 20:05 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Michael Zajac 2010-06-12 17:23:51 UTC
article, aside, dialog, figure, footer, header, hgroup, mark, nav, section, time

Many of these tags are a natural compliment or enhancement to the structure of Wikipedia's and Wiktionaries. Levels of support:

* Whitelist, to allow use in wikitext.
* Enable for non-supporting browsers (Internet Explorer 6, 7, 8).
* Add HTML5 elements to wikitext rendering.
* Incorporate HTML5 elements into Vector skin.

There's already some support in Mozilla 3.6 and Safari 5. An enabling script is required for . 

== References ==
W3C: HTML5
http://www.w3.org/TR/html5/

WHATWG: HTML5
http://www.whatwg.org/specs/web-apps/current-work/

Wikipedia: HTML5
http://en.wikipedia.org/wiki/HTML5

New semantic elements in HTML5
http://diveintohtml5.org/semantics.html#new-elements

HTML5 enabling script
http://remysharp.com/2009/01/07/html5-enabling-script/

See also Bug 671 - Whitelist more HTML tags: abbr acronym address dfn kbd q samp
Comment 1 Michael Zajac 2010-06-12 17:29:56 UTC
We could also consider support for:

HTML5 forms
http://diveintohtml5.org/forms.html

HTML5 microdata
http://diveintohtml5.org/extensibility.html
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-06-13 23:59:13 UTC
These can't be implemented anytime soon, because they all self-close in IE prior to IE9 unless you use a JavaScript workaround.  This means that most are confusing to use at best for the next few years.

Also, I'd want to be cautious until these are more stable.  <dialog> no longer exists, for example, so it'd have been a pain if we'd ever whitelisted it.

Resolving this as LATER -- these cannot really be used effectively until IE6/7/8 are marginal enough that we're willing to require JS for them to display correctly.  If you have any places you think they'd be useful despite this problem, feel free to reopen.
Comment 3 S. McCandlish 2010-07-22 00:42:12 UTC
Have to concur, as much as I don't want to. ;-/  I think they should be added as soon as they are stable, however, and regardless of the Microsoft issue. We cannot kowtow to obsolete browsers forever.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-07-22 15:52:51 UTC
No, we only kowtow to them until they're not used by a significant number of people.  The number of users using IE <= 8 with JS disabled must be negligible before we do this, because it will break pages for them.
Comment 5 Michael Zajac 2010-07-22 16:07:24 UTC
Negligible number of users of what, Aryeh? Users where?

Isn't that a decision for a site's administrator? If Azerbaijani Wikicorduroys has no MSIE users at all, then its administrators could choose to use this feature. But only if it is added to the software first.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-07-22 18:08:35 UTC
Sure, if someone can be bothered to add it as on off-by-default site option.  Same for other similar things, like inline SVG.  It can't be on by default, that's all.  I'd still leave this RESOLVED LATER for now, though, because I don't trust that all of these elements are fully stable.
Comment 7 S. McCandlish 2010-07-24 15:35:49 UTC
When I reported elsewhere tthat using angle-bracketed material in hese  bugzilla messages makes them unreadable in some e-mail systems, you replied:

From Comment #43 on Bug #671 from Aryeh Gregor <Simetrical+wikibugs@gmail.com> 2010-07-22 17:24:10 UTC (In reply to comment #41): 
> If your mail client touches angle brackets in plaintext e-mails, it is
> absolutely and completely broken and you need to tell it to stop.
 
yet

--- Comment #4 here from Aryeh Gregor <Simetrical+wikibugs@gmail.com> 2010-07-22 15:52:51 UTC ---
> ... we only kowtow to [obsolete versions of MSIE] until they're not used by
> a significant number of people.

These are contradictory stances.  In the case I reported, the GMail app built into the Android operating system, for one, "eats" material in angle brackets. It is certainly "used by a significant number of people"; the entire initial production run of the Droid X sold out within a day or two, just like every Droid phone before it.  If your "fix the broken application; we will not adapt" attitude is good enough for the Droid goose, it's good enough for the IE gander. Users of severely  obsolete browsers are entirely used to broken or completely missing functionality on every other website they go to.  Anyone running Windows 95 (which can't practicably handle Firefox, even if some people have figured out how to install it on that OS) isn't/won't be able to use Unicode, HTML5, XHTML 2, CSS 3, etc., and have and will remain having various other issues with Wikipedia and other MW-based sites (e.g., IE 6 had over 300 well-demonstrated CSS and HTML bugs in it).  So, this whole bit about not breaking things for them is a bit of a red herring.  I don't mean for this to start a big argument, and I'm not reopening the bug or anything. But it will have to be reopened eventually, and IE6 or whatever should not be a factor in the discussion at that time.  Heck, Wikipedia not supporting obsolete MS browsers will be a strong upgrade incentive, given that WP is among the most-used websites in the world.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-07-25 17:31:50 UTC
Wikipedia's goal is to provide knowledge to everyone in the world, not just people whose browsers we like to work with.  Giving significant numbers of people reduced functionality is okay if necessary, but breaking their use of the site is absolutely not okay.

The goal of my comments in Bugzilla is to communicate with particular people, and if they have to actually follow the link to the bug report proper rather than reading my comments in their broken mail client, that's not a big deal to me.  Wikimedia's Bugzilla has completely different goals from Wikipedia itself, and so different standards are entirely appropriate.
Comment 9 Michael Zajac 2010-07-29 18:25:17 UTC
Removed dialog (removed from the draft), adding figcaption to this bug's title.
Comment 10 Michael Zajac 2010-07-29 18:26:01 UTC
Removed dialog (removed from the draft), adding figcaption to this bug's title.
Comment 11 S. McCandlish 2012-03-04 12:42:37 UTC
Well, it's been another year and a half, now.  I think it's time to re-examine opening this and moving forward.  We can't keep pretending this is the Web ca. 1996. :-)  How many people can really be still using ancient versions of IE *with JS turned off* any more? Running like that will make probably 90% of the Web unusable to you.
Comment 12 Bawolff (Brian Wolff) 2012-04-15 03:46:39 UTC
(In reply to comment #11)
> Well, it's been another year and a half, now.  I think it's time to re-examine
> opening this and moving forward.  We can't keep pretending this is the Web ca.
> 1996. :-)  How many people can really be still using ancient versions of IE
> *with JS turned off* any more? Running like that will make probably 90% of the
> Web unusable to you.

Roughly 17% of everyone are using an affected version of IE ( according to http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm ). No idea how many with js turned off, but that's still probably too many I'd imagine.
Comment 13 S. McCandlish 2012-04-15 05:36:18 UTC
Given that the most of the Web is badly malfunctional to utterly useless without JS turned on I'd bet good money that that number is <2%.
Comment 14 Leonard Wallentin 2012-10-27 22:23:40 UTC
In the meantime, I created a small tag extension https://github.com/rotsee/HTML5Tags (there are likely to be bugs, feel free to improve it).
Comment 15 John Mark Vandenberg 2013-07-28 01:05:43 UTC
Current percentages of requests:
desktop:
MSIE 8.0: 4.77%
MSIE 7.0: 1.51%
MSIE 6.0: 0.38%
MSIE 5.5: 0.03%
tablet: (javascript cant be disabled?)
MSIE 8.0: 0.21%
MSIE 7.0: 0.05%
mobile:
MSIE 4.01: 0.02%

Is it possible for our analytics team to determine roughly what percentage of MSIE <=8 readers that have JavaScript disabled?  The Visual Editor team decided to not support MSIE 8 at all, so they may already have some stats.

And/Or MediaWiki strip HTML5 elements for clients that only support HTML4?  e.g. figure/figcation -> img.  Or is that a caching problem?

Or could MediaWiki add support those HTML5 elements which degrade in IE <=8 without JS in a way that doesnt render the page unreadable?
Comment 16 Martijn Hoekstra 2014-11-17 09:53:15 UTC
Tentatively re-opening. Current percentages of requests:

MSIE 8.0: 2.33%
MSIE 7.0: 0.55%
MSIE 6.0: 0.38%
MSIE 5.5: 0.03%
--------------- +/+
          3.56%

With a very generous guess of 5% of those people having Javascript disabled (my guess for the true number is around 1-2%, but if we can get our hands on the actual numbers, that would be even better), this change would impact 0.178% of users as an upper bound.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links