I went ahead and asked my EMPs if I could take a couple days to do an assessment of what CSS will be affected by the switch to HTML5. The request was granted and I should have some time to work on it next week. My apologies for being so aggressive on this issue, as it will probably turn out to be a minor problem in the end. If anyone is interested in helping with the assessment, please let me know.
Ryan Kaldari On 3/29/11 11:06 AM, Ryan Kaldari wrote: > 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 Kaldari<rkald...@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. Peachey<p858sn...@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 Kaldari<rkald...@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-82155.png >>> instead of this: >>> https://secure.wikimedia.org/wikipedia/mediawiki/wiki/File:Login-simplesearch-84908.png >> 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. > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
