Last modified: 2014-11-19 20:05: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
We could also consider support for: HTML5 forms http://diveintohtml5.org/forms.html HTML5 microdata http://diveintohtml5.org/extensibility.html
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.
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.
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.
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.
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.
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.
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.
Removed dialog (removed from the draft), adding figcaption to this bug's title.
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.
(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.
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%.
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).
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?
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.
