Last modified: 2009-08-10 17:50:01 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T4809, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2809 - Produce valid XHTML 2.0 output (when XHTML becomes a standard)
Produce valid XHTML 2.0 output (when XHTML becomes a standard)
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-07-11 22:27 UTC by Mathias Schindler
Modified: 2009-08-10 17:50 UTC (History)
1 user (show)

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


Description Mathias Schindler 2005-07-11 22:27:25 UTC
According to wikipedia, <a
2.0</a> will take another while to get drafted. XHTML will result in a major
break in terms of compatibility. 

We won't have mainstream browser software for XHTML 2.0 in 2006 if everything
goes planned.

This feature request is a rather hard one: A lot of tags will be replaced from
our current output. Complying to XHTML 2.0 means rewriting almost every output
related part of the Mediawiki code, AFAIK.

This is the <a href="">future</a>....
Comment 1 peter green 2005-07-11 22:32:52 UTC
from what i can gather xhtml 2 in its present form is basically unusable due to
the fact it doesn't allow pages to be authored in a backwards compatible manner.

if/when xhtml2 becomes useable this can possiblly be revisited but i see any
need/reason for mediawiki to be an early adoptor.
Comment 2 Brion Vibber 2005-07-12 08:42:58 UTC
I'm gonna go wild and resolve this as LATER, which we haven't used much before. ;)

Generally speaking I don't think supporting XHTML 2.0 will be all that difficult -- 
mostly it should be a straightforward transformation of existing markup to new 

Aside from the fact that there's no point in it until there's widespread browser support, 
the main technical obstacle is that we still don't guarantee well-formed XML output to 
begin with. Until the parser can guarantee proper nesting of elements, there would be 
little point in expending the transformation effort either.
Comment 3 Chad H. 2009-08-10 17:50:01 UTC

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