Last modified: 2011-11-21 20:57:12 UTC
Bug 209 tracks the XHTML output by mediawiki. There are however still some things which could easily be done away with to get us close to XHTML strict (in spirit, if not DTD) - see validator output. These include: * <br clear="both" /> can be replaced by <br style="clear: both" /> * <script type="text/javascript" language="JavaScript"> can just become <script type="text/javascript"> * <td width="100" height="25"> can be replaced with inline css / extracted to stylesheets in most cases
Created attachment 4720 [details] Patch to swap away from <br clear />
Created attachment 4721 [details] Patch to remove cellpadding, border, cellspacing attributes
Ugh, sorry - you guys might want to check these patches out with 'ignore whitespace changes' - my editor removed all trailing whitespace
Created attachment 4722 [details] Patch to remove <font>
Are there visual changes for those special pages?
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Daniel, thank you for the patches, and sorry that it's taken so long for you to get responses to them! I'm adding the need-review keyword to signal that these patches are awaiting a response.
I don't know how valid this bug is anymore. Some of those areas of code have already been removed, moved somewhere else, or fixed. And it's 2011 now, and rather than XHTML strict we should probably make the raw html we're generating in odd places html5 now.
All patches marked as obsolete. They're huge and will never apply Per Daniel the code has been changed alot. Closing as WONTFIX (as the bug was to apply the patches to fix issues)
They are huge because his editor removed all trailing whitespaces on the whole checkout, not necessarily because the (intended) changes would be huge. I have removed the few instances of "<br clear" I found in trunk in r103773. There shouldn't be (and there doesn't seem to be) any instance of <script type="text/javascript" language="JavaScript"> left. The google search form uses now lowercase tags (not sure what else did your patch in comment 4). Feel free to reopen if there are things missing.
With this; does the code now pass validation? http://validator.w3.org/check?uri=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FXhtml&charset=(detect+automatically)&doctype=XHTML+1.0+Strict&group=0 ... still shows me a few broken tags and table changes being needed
First, changes to trunk apply only to a mediawiki running a later version from svn http://www.mediawiki.org/wiki/Download_from_SVN Rolling into wikipedia takes an indeterminate amount of time (up to several months) About those errors: * there is no attribute "class" -> This can probably be fixed. client-nojs was added in r30497 per bug 30497. I commented on it. * there is no attribute "width" / there is no attribute "height" -> Those were manually insered into the wikitext http://en.wikipedia.org/w/index.php?title=XHTML&action=edit§ion=26&oldid=461413629 We don't always provide 100% clean XHTML with invalid input, although it would be nice sometimes. * end tag for "ul" which is not finished -> This is bug 24500 which was marked wontfix. * document type does not allow element "input" here; -> This is a silly warning, but it can be skipped by simply putting the hidden imput into a div. Fixed in r103788.
(In reply to comment #12) > First, changes to trunk apply only to a mediawiki running a later version from > svn > http://www.mediawiki.org/wiki/Download_from_SVN > > Rolling into wikipedia takes an indeterminate amount of time (up to several > months) > > About those errors: > * there is no attribute "class" -> This can probably be fixed. client-nojs was > added in r30497 per bug 30497. I commented on it. html5 permits class on <html> so I think this falls under the category of a stupid XHTML restriction we're going to ignore (like how XHTML doesn't allow id's starting with numbers but we follow html5's rules that allow it). > * there is no attribute "width" / there is no attribute "height" -> Those were > manually insered into the wikitext > http://en.wikipedia.org/w/index.php?title=XHTML&action=edit§ion=26&oldid=461413629 > We don't always provide 100% clean XHTML with invalid input, although it would > be nice sometimes. ;) and the new $wgCleanupPresentationalAttributes already in 1.19 will clean up most of those validity errors. > * end tag for "ul" which is not finished -> This is bug 24500 which was marked > wontfix. > > * document type does not allow element "input" here; -> This is a silly > warning, but it can be skipped by simply putting the hidden imput into a div. > Fixed in r103788.
> > About those errors: > > * there is no attribute "class" -> This can probably be fixed. client-nojs > > was added in r30497 per bug 30497. I commented on it. > html5 permits class on <html> so I think this falls under the category of a > stupid XHTML restriction we're going to ignore (like how XHTML doesn't allow > id's starting with numbers but we follow html5's rules that allow it). Does it have any benefit having it on html? We could have both XHTML1 and HTML5 happy be placing it in body.
