Last modified: 2011-11-21 20:57:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13381 - Improve the XHTML strictness
Improve the XHTML strictness
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://validator.w3.org/check?uri=htt...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-15 12:55 UTC by Daniel O'Connor
Modified: 2011-11-21 20:57 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to swap away from <br clear /> (65.29 KB, patch)
2008-03-15 12:56 UTC, Daniel O'Connor
Details
Patch to remove cellpadding, border, cellspacing attributes (74.38 KB, patch)
2008-03-15 13:09 UTC, Daniel O'Connor
Details
Patch to remove <font> (104.27 KB, patch)
2008-03-15 13:22 UTC, Daniel O'Connor
Details

Description Daniel O'Connor 2008-03-15 12:55:35 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
Comment 1 Daniel O'Connor 2008-03-15 12:56:58 UTC
Created attachment 4720 [details]
Patch to swap away from <br clear />
Comment 2 Daniel O'Connor 2008-03-15 13:09:11 UTC
Created attachment 4721 [details]
Patch to remove cellpadding, border, cellspacing attributes
Comment 3 Daniel O'Connor 2008-03-15 13:10:19 UTC
Ugh, sorry - you guys might want to check these patches out with 'ignore whitespace changes' - my editor removed all trailing whitespace
Comment 4 Daniel O'Connor 2008-03-15 13:22:49 UTC
Created attachment 4722 [details]
Patch to remove <font>
Comment 5 Bryan Baron 2009-09-24 22:15:49 UTC
Are there visual changes for those special pages?
Comment 6 p858snake 2011-04-30 00:09:40 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 7 Sumana Harihareswara 2011-11-10 00:06:52 UTC
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.
Comment 8 Daniel Friesen 2011-11-10 01:13:55 UTC
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.
Comment 9 Sam Reed (reedy) 2011-11-20 18:42:42 UTC
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)
Comment 10 Platonides 2011-11-20 19:03:00 UTC
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.
Comment 11 Daniel O'Connor 2011-11-20 20:53:43 UTC
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
Comment 12 Platonides 2011-11-20 21:45:20 UTC
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&section=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.
Comment 13 Daniel Friesen 2011-11-21 00:13:50 UTC
(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&section=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.
Comment 14 Platonides 2011-11-21 20:57:12 UTC
> > 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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links