On Fri, Jul 10, 2009 at 2:29 PM, David Gerard<dger...@gmail.com> wrote: > Plans for shifting Wikimedia to HTML5, probably starting with en:wp Main Page.
Clarification: the plan is to have MediaWiki output HTML 5 by default, always. (I.e., it will serve an HTML 5 doctype.) Once it's doing that, we want to have it be *valid* HTML 5 -- if it's invalid it will still work perfectly fine, but we want to be compliant with the standard to the extent practical, all things being equal. I and others have changed things so on most pages the *software* should generate only valid HTML 5. But user input might still be invalid. For the initial announcement, it would be nice if this link could report that we're providing valid HTML 5 on the Main Page: http://validator.w3.org/check?uri=http://en.wikipedia.org/wiki/Main_Page&charset=(detect+automatically)&doctype=HTML5&group=0 If that doesn't happen, I can give a link to Special:AllPages or something instead, but the Main Page is obviously more visible. The following errors are fixed in the software and/or must be fixed by sysadmins, and do *not* need to be fixed by enwiki admins: Bad value Content-Style-Type for attribute http-equiv on element meta. Text not allowed in element script in this context. Attribute name not allowed on element a at this point. Attribute border not allowed on element img at this point. The following errors are caused by the content on the Main Page, and *must* be fixed by enwiki sysops: Attribute cellpadding not allowed on element table at this point. Attribute cellspacing not allowed on element table at this point. Attribute align not allowed on element div at this point. Attribute clear not allowed on element br at this point. These attributes are among those removed in HTML 5. They were already deprecated in XHTML 1.0 Transitional, which we currently use, and are removed in XHTML 1.0 Strict. (The software doesn't need significant updates to be conformant HTML 5, because it already avoided deprecated elements in almost all cases.) So these just need to be replaced by CSS. align="right" should be basically the same as style="float: right"; clear="all" should be identical to style="clear: both"; cellpadding and cellspacing may require a little more fidgeting. Someone should do this who's good with CSS -- maybe I'll rope a dev-sysop like Werdna into it. (There are these rare cases when enwiki sysophood will be useful . . . perhaps I'll try RFA again someday.) It should be easy enough to do for someone who knows enough about HTML and CSS. It's not a big project that needs a lot of help, just something we need one person to spend half an hour fiddling with. > (Simetrical is quite keen on this change, as apart from anything else > it'll cut our served page size *after gzipping* by 5-20%.) First of all, this is only one of a number of reasons to switch to HTML 5, and not nearly the biggest. The major reason is so we can use new functionality as it's added to the spec and supported by browsers, in the long term. And since we're going to switch *eventually* anyway, we may as well do it now and get some modest benefits immediately. Second of all, we're not doing anything to reduce page size now. For the time being we're still serving well-formed XML to avoid breaking bots, so we don't get size savings from killing quotes/closing tags/etc. So this is a non-reason at present, although in the medium term it may be relevant. Third of all, I *really* doubt it will be close to 20% savings. I'm sure I never said anything close to that. I think I estimated 5%, and that's only if we're really thorough -- which would require a large amount of work (with not so much benefit, compared to the work required and the potential for introducing bugs) and won't happen quickly even when we do break XML well-formedness. If/when the change goes live, I'll put up a blog post on the tech blog explaining things in a practical manner. The short answer is: there is likely to be very little practical difference to the average user right now. It's more of a single step in a longer-term process. Users of recent non-IE browsers will likely see some modest improvements in the very near future -- like slightly better video support, slightly more helpful forms for Opera 9.6x users -- but most of the benefit is long-term. I'd also like to emphasize that for the time being, this change is still experimental, and it's still possible at this point that it will be reverted for some reason. We have not yet deployed HTML 5 and probably should not bother announcing the switch to the broader world until we know it's not going to be vaporware. On Fri, Jul 10, 2009 at 3:22 PM, Peter Coombe<thewub.w...@googlemail.com> wrote: > If we can do it, this sounds like a great idea. Forgive my ignorance though, > but what does "scap" mean? It's a Wikimedia-specific term, an abbreviation for the script sync-common-all-php. Basically it means update the site software to the latest version, bringing all new features/bug fixes live that were made since the last scap and weren't synced individually. Scaps require that all recent software changes be reviewed, which takes time, and a careful eye needs to be kept on the site for a while afterward to fix any breakage. These days we tend to have a scap every few weeks. _______________________________________________ WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l