Last modified: 2014-10-25 21:07:56 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 209 - (html) HTML validity (tracking)
(html)
HTML validity (tracking)
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.4.x
All All
: Low normal with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: tracking
Depends on: 212 4557 7356 17486 19177 24529 24918 35371 38487 40215 41917 44609 well-formedness 72519 211 240 460 697 925 995 1038 1124 1480 1483 1487 1608 1634 1830 2050 2186 2494 2567 2571 2663 2870 3243 3487 4515 6816 6829 6986 8264 8948 9095 9338 9530 9807 9880 10218 11777 12077 12166 12887 13016 13700 13909 13913 13922 13924 13925 13926 13949 14727 15835 16590 16891 17650 23575 24500 39614 39726 40579 48333 67084 72458
Blocks: tracking
  Show dependency treegraph
 
Reported: 2004-08-25 07:05 UTC by Brion Vibber
Modified: 2014-10-25 21:07 UTC (History)
18 users (show)

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


Attachments

Description Brion Vibber 2004-08-25 07:05:31 UTC
This is a tracking bug for problems with XHTML output compliance and compatibility.
Comment 1 Brion Vibber 2005-07-02 08:05:50 UTC
*** Bug 2663 has been marked as a duplicate of this bug. ***
Comment 2 sspecter 2006-05-04 21:44:17 UTC
*** Bug 5830 has been marked as a duplicate of this bug. ***
Comment 3 Rob Church 2007-05-06 10:26:33 UTC
*** Bug 9807 has been marked as a duplicate of this bug. ***
Comment 4 Benson Margulies 2007-05-11 16:43:49 UTC
Given that the existing pages are flagrantly and commonly not well-formed XML,
wouldn't it be better to mark them with an HTML 4.01 doctype? The XHTML DTD is
an invitation to parse with an XML parser, and they can't be parsed that way. 
Either a document is well-formed XML or it is not. Unterminated &ltbr&gt tags
are not a subtle point of interpretation.
Comment 5 Brion Vibber 2007-05-11 17:52:45 UTC
We do produce well-formed XHTML except in the presence of bugs.
Comment 6 Andrew Garrett 2009-07-29 16:38:44 UTC
Adding 'tracking' keyword.
Comment 7 Renich Bon Ciric 2010-10-05 05:51:57 UTC
Hello,

We, at LinuxCabal, think that this is a severe bug. We should set an example and follow these international standards.

If the header says XHTML 1.0 Strict, we should conform to just that.

http://validator.w3.org/check?uri=http://wiki.cabal.mx/wiki/P%25C3%25A1gina_Principal&charset=(detect+automatically)&doctype=Inline&group=0

http://wiki.cabal.mx/ <- MediaWiki 1.16.0 almost vanilla install (one extension for https logins)
Comment 8 Niklas Laxström 2010-10-05 07:26:43 UTC
(In reply to comment #7)
> Hello,
> 
> We, at LinuxCabal, think that this is a severe bug. We should set an example
> and follow these international standards.

It looks like a configuration issue at your end. Set $wgHtml5 to false. Then you should get valid transitional xhtml. I don't know where you get the strict header from.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-10-05 15:56:48 UTC
1.16.0 ships with an XHTML Strict header for XML well-formedness reasons.  Try setting the validator manually to HTML5 and it will validate (modulo bugs):

http://validator.w3.org/check?uri=http%3A%2F%2Fwiki.cabal.mx%2Fwiki%2FP%25C3%25A1gina_Principal&charset=%28detect+automatically%29&doctype=HTML5&group=0&user-agent=W3C_Validator%2F1.1

In 1.17, we switched to <!DOCTYPE html> after some fixes to ensure this doesn't break well-formedness (basically, getting rid of named entities).  In 1.16, you can either set $wgWellFormedXml = false (disabling well-formedness) or $wgHtml5 = false (disabling HTML5 features) to get the doctype to match the content.  In the default setup, output is valid HTML5 (modulo bugs) but has a misleading doctype.

Basically, there is an issue here, but it's fixed in 1.17, so there's nothing specific for us to do at this point.  The patch to remove named entities was enormous and will not be backported to 1.16.  In the future, you should file new bugs on specific issues you have, not post in existing bugs -- particularly not tracker bugs.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-10-05 15:59:49 UTC
To reiterate, 1.16.0 does *not* violate any standards here.  HTML5 permits the use of an XHTML 1.0 Strict header for HTML5 content, and so 1.16.0 is obeying HTML5 (modulo bugs).  The validator is reporting that the page is not valid XHTML 1.0 Strict, which is true, but it *is* valid HTML5 -- as the link I gave above demonstrates.
Comment 11 Renich Bon Ciric 2010-10-05 22:10:39 UTC
(In reply to comment #8)
> It looks like a configuration issue at your end. Set $wgHtml5 to false. Then
> you should get valid transitional xhtml. I don't know where you get the strict
> header from.

I did just this and still not valid:
http://validator.w3.org/check?uri=http://wiki.cabal.mx/wiki/P%25C3%25A1gina_Principal&charset=(detect+automatically)&doctype=Inline&ss=1&group=0&user-agent=W3C_Validator/1.1

Thank you for a quick reply, btw ;)
Comment 12 Renich Bon Ciric 2010-10-05 22:17:40 UTC
(In reply to comment #9)
> 1.16.0 ships with an XHTML Strict header for XML well-formedness reasons.  Try
> setting the validator manually to HTML5 and it will validate (modulo bugs):
> 
> http://validator.w3.org/check?uri=http%3A%2F%2Fwiki.cabal.mx%2Fwiki%2FP%25C3%25A1gina_Principal&charset=%28detect+automatically%29&doctype=HTML5&group=0&user-agent=W3C_Validator%2F1.1

It appeared so (before the wgHtml5 = false) but, this warning seems to negate what the validator asserts. I found the warning just bellow.

"DOCTYPE Override in effect!

The detected DOCTYPE Declaration "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">" has been suppressed and the DOCTYPE for "HTML5" inserted instead, but even if no errors are shown below the document will not be Valid until you update it to reflect this new DOCTYPE.."

It seems the validator contradicts himself but, still, there's a warning; there shouldn't be one.

> In 1.17, we switched to <!DOCTYPE html> after some fixes to ensure this doesn't
> break well-formedness (basically, getting rid of named entities).  In 1.16, you
> can either set $wgWellFormedXml = false (disabling well-formedness) or $wgHtml5
> = false (disabling HTML5 features) to get the doctype to match the content.  In
> the default setup, output is valid HTML5 (modulo bugs) but has a misleading
> doctype.
> 
> Basically, there is an issue here, but it's fixed in 1.17, so there's nothing
> specific for us to do at this point.  The patch to remove named entities was
> enormous and will not be backported to 1.16.  In the future, you should file
> new bugs on specific issues you have, not post in existing bugs -- particularly
> not tracker bugs.

Nice to read. When is 1.17.0 out? ;)
Comment 13 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-10-06 15:03:40 UTC
(In reply to comment #12)
> It appeared so (before the wgHtml5 = false) but, this warning seems to negate
> what the validator asserts. I found the warning just bellow.
> 
> "DOCTYPE Override in effect!
> 
> The detected DOCTYPE Declaration "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
> Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">" has been
> suppressed and the DOCTYPE for "HTML5" inserted instead, but even if no errors
> are shown below the document will not be Valid until you update it to reflect
> this new DOCTYPE.."

That's wrong.  That text is correct for legacy HTML versions, which permit only one doctype, but HTML5 permits several different doctypes.  Probably that validator text was written before HTML5 and never updated.

> It seems the validator contradicts himself but, still, there's a warning; there
> shouldn't be one.

The warning is gone in 1.17, but it's only a warning, not an error.  It serves to alert you to a possible problem, not to say that there definitely is one.

> Nice to read. When is 1.17.0 out? ;)

No planned release date.
Comment 14 Mark A. Hershberger 2010-12-02 22:42:26 UTC
using 1.17, I got only the following from the validator:

Warning Line 27, Column 77: The language attribute on the script element is obsolete. You can safely omit it.

  <div id="siteNotice"><script type="text/javascript" language="JavaScript">
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-12-03 00:10:25 UTC
(In reply to comment #14)
> using 1.17, I got only the following from the validator:
> 
> Warning Line 27, Column 77: The language attribute on the script element is
> obsolete. You can safely omit it.
> 
>   <div id="siteNotice"><script type="text/javascript" language="JavaScript">

Should be fixed in r77619.  It's a problem with DismissableSiteNotice, not MediaWiki itself.  (But you aren't supposed to mention bugs in tracking bugs, you're supposed to file a new bug and mark it blocking this.)
Comment 16 Siebrand Mazeland 2012-10-24 17:32:37 UTC
Should this issue be closed, as from now on, we're aiming to be HTML5-ish compliant?
Comment 17 Niklas Laxström 2012-10-24 19:02:40 UTC
We are currently supporting both and the html generation APIs are nicely abstracting the details away.
Comment 18 Daniel Friesen 2013-06-08 15:12:54 UTC
Now that we don't support XHTML 1.0 and many of the dependent bugs aren't really XHTML issues I'm making this our HTML validity tracking bug. bug 49337 will also cover things that affect our well formed XML feature.

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


Navigation
Links