Your analysis of the effects of the DOCTYPE change is not correct. As Entlinkt tried to point out at the HTML5 page on mediawiki.org, inline images, inline-blocks and inline-tables can also be affected (even outside tables). The search box is a good example of this. The DOCTYPE change affects the layout of the search box in both Firefox and Safari (and those are the only browsers I've check in so far), despite the fact that it doesn't use tables at all.
The fact that you don't see the difference in the two screenshots is not reassuring. In one, the search icon is clearly misplaced as it is overlapping the border of the search input, in the other it is not. This is caused solely by the DOCTYPE difference.
After doing some very limited tests this morning, it looks like the impact on the site will probably be small. This is probably due to the fact that we are already using standards-compliant HTML and CSS throughout the site. However, we do have some CSS hacks and non-standard workarounds to deal with bugs in browsers like IE6 (both in Vector and various extensions). These are probably the areas in which the DOCTYPE change will have an impact.
I would suggest that we check the effects of the DOCTYPE change in all of the browsers we support (including the mobile ones). Hopefully, the effect is minimal and we can proceed in due course. Having the attitude that it's not even worth checking, however, is disrespectful to the people who spend their time refining our CSS so that our sites look great in things like IE6, IEMobile, and the Playstation 3 browser.
Ryan Kaldari
On 3/29/11 7:21 AM, Aryeh Gregor wrote:
On Mon, Mar 28, 2011 at 10:47 PM, Ryan Kaldarirkaldari@wikimedia.org wrote:
In case no one has mentioned this, changing the DOCTYPE has a pretty huge effect on how CSS gets rendered. Wikimedia's current DOCTYPE (XHTML transitional) maps to "almost standards mode" or "limited quirks mode" in Firefox, Safari, Chrome, Opera, IE8 and IE9. Changing to "<!DOCTYPE html>" will switch the rendering mode in all of those browsers to "standards mode". Testing and tweaking all the CSS in Mediawiki for this DOCTYPE change is a huge task.
Why? I did research this issue before changing the default doctype, and as far as I found out, there's exactly one difference between standards and almost-standards: the way images in tables are handled. This will only seriously disrupt table-based layout that relies heavily on images, like where you have a single image that you've broken up into pieces and you're lining them up again by putting them in a table. Other layouts will shift a bit, with some extra gaps appearing, but it should be only a minor aesthetic issue that can be fixed after the fact.
I'm already getting bug reports due to this issue, and I wasn't even aware we were making the change.
"Already"? You realize the default doctype in trunk has been strict standards mode continuously since **July 2009**? http://www.mediawiki.org/wiki/Special:Code/MediaWiki/53142 That's more than a year and a half. In that whole time, nobody has told me about *any* bug caused by the switch to strict standards mode. Maybe there are some I'm not aware of, but people usually CC me on bugs related to the HTML5 doctype.
What bugs exactly were filed, and how are they so difficult to fix?
The switch to<!DOCTYPE html> should be reverted immediately. If we want to switch to this DOCTYPE, we need to plan and budget for the front-end development that will be necessary to support this change.
We can talk about this when you point out specific issues that were caused by the change that are severe enough to justify a revert despite the fact that apparently no one noticed them for over a year and a half.
How exactly was the conclusion reached that this change would only affect screen-scraping tools?
Because that's the only actual problem that's been reported with the doctype change that anyone has told me about, when it's been enabled on trunk since July 2009 and enabled on Wikimedia sites for several hours on two separate occasions. If you have other actual specific problems that you'd like to point out, please do so.
(I'm not counting the fact that we were serving KHTMLFixes.css to modern-day WebKit, which happened not to break in old WebKit versions as long as we were in almost-standards mode instead of standards mode. This would have come up anyway, since WebKit changed their code so we broke in either mode, and the correct fix was to delete KHTMLFixes.css.)
The MediaWiki page on the HTML5 transition lists several other issues, none of which seem to have been adequately discussed or addressed.
Such as?
On Mon, Mar 28, 2011 at 11:22 PM, K. Peacheyp858snake@gmail.com wrote:
In hindsite, probably changing it on trunk should of probably got a tad more discussion (although I havn't looked for the revision where this occured to see what the CR discussion/comments are like), but it's only trunk (where stuff is ment to break), where as changing it in a release should really be where the discussion starts.
I started a whole thread on it back in 2009 before I changed it:
http://lists.wikimedia.org/pipermail/wikitech-l/2009-July/043865.html
There was loads of discussion, over sixty posts to the thread. I also made a point of asking Brion (then the lead developer) for approval before switching it on.
On Tue, Mar 29, 2011 at 12:52 AM, Ryan Kaldarirkaldari@wikimedia.org wrote:
So which rendering mode should I be vetting CSS for? Strict or limited quirks? Some of the CSS that I review is specifically tweaked for limited quirks since that's what the Wikimedia sites are running in.
Wikimedia should be switched to $wgHtml5 = true like trunk has been for ages now, and then everyone should write for strict mode. The problem here is Wikimedia, not trunk.
Honestly, I don't know all of the problems that this change will cause. I imagine it will just be lots of slight changes to how elements line up, i.e. things shifting by a few pixels in most cases. For example, this: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-applied-821... instead of this: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearc...
I don't know how those pictures are relevant, because one of them appears to be a cropped version of the other. But I've taken a quick look at the markup around the search box and it doesn't use any tables, so the expected changes should be none. In fact, I'd expect that the largest effect will be on wiki content, not the software interface, because the software interface uses table layout sparingly and images even more sparingly. But if it causes problems, they'll only be aesthetic warts, not serious issues, so they can be fixed after the fact.
I haven't thoroughly investigated the ramifications of switching our rendering mode, and apparently no one else has either. I'm just as anxious to start using HTML5 as everyone else, but I think we should have a better plan than "break stuff and revert if enough people complain". If we know that there are potential issues, shouldn't we have developers assigned to investigate those issues and report back before we start deploying things?
No. Why? If it really causes serious display problems that can't be immediately fixed, we can always turn it off, but that's unlikely. It's a waste of resources to preemptively find and fix minor aesthetic issues when we don't even know whether they'll occur. We're not talking about a change that might break the site.
Also, does anyone know if this will affect $wgUseTidy?
There have been no problems reported related to $wgUseTidy since July 2009, so I'd hazard a guess that it will not. I run with $wgUseTidy = true on my localhost wiki, and I've tested every HTML5 feature I added and they all work. Raymond has pointed me to translatewiki.net's config file, and they use $wgUseTidy and have reported no problems I know of:
http://translatewiki.net/wiki/BetawikiSettings.php
I think it's fair to say that at this point, $wgHtml5 = true has a strong presumption of working in every respect except breaking well-formedness. If anyone *knows* of any further problems, please give evidence that they exist, but there are no grounds for suggesting it be reverted on trunk or anything like that.