XHTML5

For technical support for all editions of CSS HTML Validator. Includes bug reports.
alnico
Rank I - Novice
Rank I - Novice
Posts: 15
Joined: Mon Jun 21, 2010 4:07 am

XHTML5

Post by alnico » Thu Nov 11, 2010 8:34 am

I'm trying to use XHTML5 with my code where I've declared the doctype as <!DOCTYPE html>

However if I use the validator with the doctype declaration, I get the error message

Code: Select all

"This document has an HTML DOCTYPE but uses XHTML features (such as XHTML attributes). The XHTML features and attributes should be removed or an XHTML DOCTYPE should be used. XHTML and other DOCTYPEs can be inserted using the Tag Inserter."
And, if I do not use the doctype attibute, I get thie error message

Code: Select all

"[24] A document type declaration should normally appear as the second line for XHTML documents (the first line should be an XML declaration). For example, for XHTML 1.0 Strict documents, <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> should be the second line (or the first line if there is no XML declaration). For XHTML 1.0 Transitional documents, the line should be <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">. For XHTML 1.0 Frameset documents, the line should be <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "DTD/xhtml1-frameset.dtd">. Although the XHTML recommendation requires this line, most browsers probably ignore it. If you're using HTML Validator's integrated editor, then this can be added from the 'Tags' menu or from the Tag Inserter.
---"
So the problem is that no matter what I want to do to upgrade from XHTML 1.1 to XHTML5, HTML Validator still gives me an error which I cannot hide. Please could the next update accommodate XHTML5 doctype?

User avatar
MikeGale
Rank VI - Professional
Rank VI - Professional
Posts: 711
Joined: Mon Dec 13, 2004 1:50 pm
Location: Tannhauser Gate

Re: XHTML5

Post by MikeGale » Thu Nov 11, 2010 3:04 pm

When I saw the doctype for XHTML 5 I couldn't believe it.

It seems to me that it cannot be an enduring solution and is arrogant.

alnico
Rank I - Novice
Rank I - Novice
Posts: 15
Joined: Mon Jun 21, 2010 4:07 am

Re: XHTML5

Post by alnico » Fri Nov 12, 2010 5:25 am

Mike, there isn't a doctype specifically for XHTML5. Some sites mention that the doctype can be omitted for XHTML, while others such as Wikipedia state that <!DOCTYOE html> (case sensitive) should keep XHTML folks happy.

I'm having a mess trying to upgrade from XHTML1.1+RDFa to XHTML5+RDFa at the moment. I'm caught between both. I want my site to be rendered under the most stringent standards but am stuck in a quagmire with future technologies. I don't want my sites to appear 'old-fashioned' by using XHTML 1.1, but I also want to make sure my code is parsed with the XML parser.

User avatar
Albert Wiersch
Site Admin
Site Admin
Posts: 3453
Joined: Sat Dec 11, 2004 9:23 am
Location: Near Dallas, TX
Contact:

Re: XHTML5

Post by Albert Wiersch » Fri Nov 12, 2010 9:39 am

It seems to me that the best and simplest solution is not to display this message for documents with HTML5 DOCTYPEs, since it doesn't make sense:

Code: Select all

"This document has an HTML DOCTYPE but uses XHTML features (such as XHTML attributes). The XHTML features and attributes should be removed or an XHTML DOCTYPE should be used. XHTML and other DOCTYPEs can be inserted using the Tag Inserter."
Does that sound reasonable to all?
Image
Albert Wiersch

alnico
Rank I - Novice
Rank I - Novice
Posts: 15
Joined: Mon Jun 21, 2010 4:07 am

Re: XHTML5

Post by alnico » Fri Nov 12, 2010 11:22 am

Makes sense. Thanks!

User avatar
Albert Wiersch
Site Admin
Site Admin
Posts: 3453
Joined: Sat Dec 11, 2004 9:23 am
Location: Near Dallas, TX
Contact:

Re: XHTML5

Post by Albert Wiersch » Fri Nov 12, 2010 2:39 pm

alnico wrote:Makes sense. Thanks!
Great! This should be fixed in the next update.
Image
Albert Wiersch

User avatar
MikeGale
Rank VI - Professional
Rank VI - Professional
Posts: 711
Joined: Mon Dec 13, 2004 1:50 pm
Location: Tannhauser Gate

Re: XHTML5

Post by MikeGale » Sun Nov 14, 2010 4:18 pm

alnico wrote:Mike, there isn't a doctype specifically for XHTML5. Some sites mention that the doctype can be omitted for XHTML, while others such as Wikipedia state that <!DOCTYOE html> (case sensitive) should keep XHTML folks happy.
Yea. The early X/HTML 5 work was going along nicely, with a proper spec. for those who believe in doing things properly. Then along comes this peculiar cop-out that so few people do XHTML or even do HTML properly that we'll just give up. That needless, in my opinion, decision guarantees that future markup will be sloppy. Not impressive!

These standards guys have a hard time. Just take a look at the detailed activity within WHATWG and W3C, you can see how hard it is. HTML5 is finally going somewhere after such a long period of inactivity, that's good. Unfortunately decisions like this actively shut out professionalism. The good thing is that Ian Hixon has declared the WHATWG to be a place where ideas for HTML version next get hammered out. If, like me, you're underwhelmed by what's in 5, you can always put your resources where your mouth is and make proposals for the versions beyond.

For all the problems, we owe the people who are working to push the web ahead a great thanks.

ormaaj
Rank I - Novice
Rank I - Novice
Posts: 10
Joined: Mon Nov 15, 2010 8:25 am

Re: XHTML5

Post by ormaaj » Sun Dec 12, 2010 11:21 am

alnico wrote:Mike, there isn't a doctype specifically for XHTML5. Some sites mention that the doctype can be omitted for XHTML, while others such as Wikipedia state that <!DOCTYOE html> (case sensitive) should keep XHTML folks happy.
Correct, a doctype isn't required in an XHTML5 document. Just to clarify - as you're probably aware as things currently stand you're likely better off without associating your XHTML5 documents with a DTD at all.

Unlike previous XHTML specs, an XML mime type is a hard requirement of all XHTML5 documents - even those not using foreign-namespaced elements. If it isn't some +xml suffixed media type, then it isn't XHTML5 without exception. While this breaks content negotiation hacks for <IE9, this isn't the bad news it might first appear it to be. Consider this: all browsers which support real XML parsing (including IE9) always render in standards mode regardless of the (possibly absent) doctype declaration. Take Firefox for example::
The following trigger full standards mode:

Any document sent with an XML MIME type such as text/xml, application/xml, or application/xhtml+xml (since sniffing only occurs for documents sent as text/html).
The only purpose of the HTML5 doctype "stub" is to trigger the standards mode rendering that we're already guaranteed anyway by virtue of using XHTML5 which in turn gurarnees that documents will never be processed as HTML. Unless you specifically require a DTD for either validation or external entity definitions (which only function under very specific circumstances since UAs aren't required to dereference a public identifier), then there's no reason to declare any doctype at all. An HTML5 doctype would be incorrect in terms of XML validity anyway as the only instance that could meet the criteria you're asserting contains an empty, attribute-less <html> root node and nothing else. That's an unfortunate sacrifice to work around in the event that you for some reason need polyglot syntax.

The DTD problem has nothing to do with "sloppy markup" (which most people associate with well-formedness issues which are automatically solved by virtue of using XML). The problem is in having to implement the DTD. There aren't premade public DTD implementations of every concievable combination of RDFa (which uses CURIE mappings in v1.0 without RDFa 1.1 profiles, but no namespaced elements), SVG, MathML, XHTML, and whatever future browser features you might want to bind to an XML element and mix with XHTML. Though XHTML 1.1 was supposed to make modularization easy, lack of namespace support in DTDs is a problem to extensibility, and forcing web developers to write custom DTDs for use in mixed-namespace documents seems unrealistic because absolutely everything you want to use must be implemented in your DTD in order for your document to be valid. While HTML5 includes some non-extensible mechanisms to specifically work around the problems of inline SVG and MathML, the same doesn't apply to XML.

In the future matters may be improved further by allowing mappings from specifications in arbitrary schema languages to documents http://www.w3.org/TR/xml-model/. Until then, I'd say going with schema-only validation for XHTML5 isn't a bad idea, as I say, unless you really do have a technical need for a DTD. "I'm using $foo version of XHTML" is becoming sort of a nonsensical statement. With the exception of external entities, browsers treat everything the same for all XML documents and apply implicit treatment to formatting of elements in XHTML, SVG, MathML, XUL, etc namespaces.

All of the above assumes you don't mind breaking IE of course. Though if you're expecting the browser to render MathML - you don't.

User avatar
MikeGale
Rank VI - Professional
Rank VI - Professional
Posts: 711
Joined: Mon Dec 13, 2004 1:50 pm
Location: Tannhauser Gate

Re: XHTML5

Post by MikeGale » Sun Dec 12, 2010 2:22 pm

I didn't understand all of that last post on initial reading. But note the following:

1) Previous versions of markup need a declaration. Why break the chain?

2) The rest of the argument seems to depend on not caring whether it works in IE. In my real world I don't have control over what browsers the audience uses, I get whatever they've chosen to use, neither do I want to control. (Though I am delighted when a Netscape 4 or IE6, market share goes low enough that I can just ignore them, no testing every time I edit a page!) So any argument that's based on ignoring high market share browsers isn't valuable to me.

3) Even though a DTD/Schema isn't that great an design, they hold out the promise of being able to do what you want. Escaping from the dictatorship of a "one size fits all" specification. Albeit with extra work. Something that just works on all user agents. It sounds really good and would help those who want to do more. I gave it try some time ago. Can't recall the details, but it just didn't work in the real world. If that's changed please give me a reference. (Mind you no flaky, well it almost works, sort of stuff. I'm after something that's commercial/business strength and actually just works, across the browsers I encounter.)

ormaaj
Rank I - Novice
Rank I - Novice
Posts: 10
Joined: Mon Nov 15, 2010 8:25 am

Re: XHTML5

Post by ormaaj » Tue Dec 14, 2010 5:01 pm

MikeGale wrote:1) Previous versions of markup need a declaration. Why break the chain?
Sort of. There's no denying that XHTML 1.1 conformance requirements call the DOCTYPE a "MUST", and If a document really does validate (in the true XML sense), then I'm all for making that assertion by referencing the formal definition in the document itself. Likewise, if you were to write a document to current XHTML5 proposals, there's nothing stopping you from writing a formal specification (and people have http://syntax.whattf.org/) .

From the point of view of a browser that supports XML though (essentially all of them incl. IE9), XHTML™ is nothing special. XHTML is just yet another XML language whose elements are implicitly bound to styles. The thing which triggers that presentation is the namespace, not the doctype, which means the presentation is always identical regardless of which "version" of XHTML you're using (for now at least). This is correct behavior, and means that any kind of schema should only be used for it's real purpose - a way to inform others and UAs of the properties of a document's structure, not as a way of informing UAs about versions of a spec in order to treat documents differently on that basis.

That said, I don't think most people who write webpages understand XHTML modularization, and since XHTML 1.1's second edition became a recommendation a few weeks ago, the DTD is still a requirement. If you wanted to extend the schema, you would have to do the same to the DTD. In the future I'd suspect that wanting to do that will become both more common and more difficult if legacy DTD remains a requirement. (It isn't that bad, but NVDL is easier). Even the official XHTML DTDs contain hacks to work around namespace issues by adding common ones as default attributes. They go further by making a special exception in the spec for "XHTML validators", and the W3C validator for instance works around the problem by hiding namespace-related errors.

With regards to the original poster, the CSE validator technically isn't a validator AFAICT, just a lint tool that's strictly limited to the scope of (X)HTML, but freaks out if you try to abuse it for either general-purpose XML validation, or an HTML language it doesn't understand. Even if CSE were a validator, as I said in my previous post, the correct behavior would be to not pass validation because the document doesn't (and couldn't possibly) conform to the specified DOCTYPE. It would be more correct to leave it out, and since XHTML5 is completely incompatible with IE, there's no reason for it anyway unless specifying a real DTD for validation.
2) The rest of the argument seems to depend on not caring whether it works in IE. In my real world I don't have control over what browsers the audience uses, I get whatever they've chosen to use, neither do I want to control. (Though I am delighted when a Netscape 4 or IE6, market share goes low enough that I can just ignore them, no testing every time I edit a page!) So any argument that's based on ignoring high market share browsers isn't valuable to me.
That's all perfectly fine and understandable especially if someone is paying you to support IE6. On commercial websites you don't really have a choice and will just have to make due with what's available.

When I'm not required to do this, I'm going to make available to users of modern browsers pages that emphasize correctness, scalability, and make use of all available standard features. I prioritize forwards over backwards compatibility wherever possible. My opinion is to judge by the intended audience. People who care about viewing web content correctly and wish to access pages which make use of more advanced media are not going to be using IE.

I don't feel bad about breaking things because NOBODY uses IE by choice. At least no informed person, because it is strictly inferior to every other browser by every measure. The barriers to switching to a modern browser are very low due to the plethora of fantastic free and open source implementations of those standards which eliminate any rational reason there might be to continue using IE (lest your irrational tech department forces you because they're too cheap to update their intranet, or have backwards ideas about security). I'm also reasonably confident that such implementations will continue to be well maintained and free on all major platforms for the foreseeable future. Even if IE9 is a smashing success, the same can't be said.

One little known fact about IE is that as a last resort, IE makes use of the file extension to determine the document type even if served as application/xhtml+xml. I spent half a day testing things, even analyzing packets in wireshark fed to IE6, 7, and 8 in a virtual machine to make sure I was giving it the right headers, but it kept displaying pages as html rather than downloading them. It turns out I had to change the extensions to .xml or .xhtml to cause a failure. Though it's probably a bad idea to rely upon that behavior, it turns out there's no need to do bad content negotiation. It works so long as the xhtml documents are close enough to html to work (as is normally the requirement).
3) Even though a DTD/Schema isn't that great an design, they hold out the promise of being able to do what you want. Escaping from the dictatorship of a "one size fits all" specification. Albeit with extra work. Something that just works on all user agents. It sounds really good and would help those who want to do more. I gave it try some time ago. Can't recall the details, but it just didn't work in the real world. If that's changed please give me a reference. (Mind you no flaky, well it almost works, sort of stuff. I'm after something that's commercial/business strength and actually just works, across the browsers I encounter.)
Not quite sure what you meant by this one. Most current browsers fully support HTML4, XHTML, and CSS2 albeit sometimes inconsistently. For other languages, nobody supports every feature of any spec. If what you mean by the "real world" is IE, then yes, stable IE versions don't support hardly anything beyond basic CSS and HTML (and often incorreclty). Other browsers do consistently implement certain subsets of other languages to the point where I wouldn't consider them flaky, and XML makes for a great "one size fits all" base to build from. Any browser (but IE) should let you roll your own XML language and style it with CSS or XSLT. SVG is quite well supported to the point where it can be mixed with other XML languages or HTML5, styled with CSS, and manipulated with Javascript in a mostly predictable way. http://apike.ca/prog_svg_threed.html http://totlandweb.info/reiko

User avatar
MikeGale
Rank VI - Professional
Rank VI - Professional
Posts: 711
Joined: Mon Dec 13, 2004 1:50 pm
Location: Tannhauser Gate

Re: XHTML5

Post by MikeGale » Tue Dec 14, 2010 8:46 pm

This is an interesting discussion. Thanks.
..I don't think most people who write webpages understand XHTML modularization...
The uptake of modularisation has been poor (I haven't looked at it recently, by maybe almost non-existent in the wild). Having faced namespaces (like when working with XSLT) I think that there is something flawed with the namespace idea as defined in XML. A developer keeps experiencing cognitive double takes... A better approach would help us advance. (I saw some Python code a while ago that essentially replaced XSLT with something more succint, it might have had a namespace alternative.)
...CSE validator technically isn't a validator AFAICT...
Depends on your definitions. I find that of the validators that I've tried CSE is the one that best does what I want. (There is at least one other that has become useful recently...) It detects things that a DTD driven program can't. Things I need to know. It also helps with CSS. I've not tried to use it as a general purpose XML checking tool.
...support IE6...NOBODY uses IE by choice..
I haven't experienced audiences defined by browser choice. I view the browser used as orthogonal to what defines the audience. That being said I would walk away from a project that targeted IE6 specifically. (Isn't it ironic that the browser that forces you to upgrade, no option of parallel installs, has ended up like this. The recalcitrance of those who have made this happen is breath taking.) I actually use IE by choice. (I also choose to use FF, Chrome, Opera and Safari. It enables me to better appreciate what others are seeing.)
...Even if IE9 is a smashing success...
My recollection is that IE led the pack for a while. I recall that the guys at Spyglass kinda threw their hands in the air when they saw the size of team working on the project. Then something happened at MS management. (I've never seen an informed analysis of what.) The lead was given up. From what I've seen of IE9, the recent status quo might be about to change. Though Doug Crockford has some interesting comments in this video http://bit.ly/gB8Dgd.
...they hold out the promise of being able to do what you want...Any browser (but IE) should let you roll your own...
What I meant here is that neither HTML4 nor XHTML, define what I want to do. They both do more and less than I'd like. For the more they spend a lot of CPU cycles doing things that I don't intend to use. That's a tax for everybody having the same markup, so I can live with it. There are things I do, which could be done in markup, but I've not found it feasible. Practically I haven't been able to extend the markup language, so I haven't (unfortunately) been able to roll my own. That just means that some work must be done in back end web services, roll your own code generators, and maybe alternative presentation technologies (or more usually, not done at all). SVG is indeed a great idea and very powerful. (A great pity that it hasn't been usable on general web sites. I did develop a way of using it many years ago. I rendered it in code to an image, and served the image up from memory, or sometimes file, to the browser. Worthwhile in some cases!)

alnico
Rank I - Novice
Rank I - Novice
Posts: 15
Joined: Mon Jun 21, 2010 4:07 am

Re: XHTML5

Post by alnico » Sat Nov 12, 2011 6:39 pm

Reopening the old topic.

I just tried v11 and I still want to use XHTML5.

When I use

Code: Select all

<!DOCTYPE xhtml>
, I get this warning
[65] This document's DOCTYPE is not a recognized DOCTYPE and may not be valid. Note that most DOCTYPEs are treated as being case-sensitive. See the description of flag 65 in the documentation for more information and the list of recognized DOCTYPEs.
this also leads to similar warnings for header, article, footer, section, and nav.
The HTML5 element "header" has been used but this does not appear to be an HTML5 document. This message is displayed only once.
On Wikipedia: http://en.wikipedia.org/wiki/XHTML#XHTML5
In order to validate an XHTML document, a Document Type Declaration, or DOCTYPE, may be used.
Based on my Wikipedia understanding, the doctype is valid. I would therefore seek to ensure that the above warnings be downgraded to comments when the xhtml doctype be used in the next version.

User avatar
MikeGale
Rank VI - Professional
Rank VI - Professional
Posts: 711
Joined: Mon Dec 13, 2004 1:50 pm
Location: Tannhauser Gate

Re: XHTML5

Post by MikeGale » Sun Nov 13, 2011 4:15 pm

My understanding is that some part of an xhtml5 document might look like this:

Code: Select all

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
<meta charset="UTF-8" />
</head>

<body>
<svg xmlns="http://www.w3.org/2000/svg">
<rect stroke="black" fill="blue" x="45px" y="45px" width="200px" height="100px" stroke-width="2" />
</svg>
</body>
</html>
Where the page content that we're looking at is not sufficient to define it as xhtml5 because it also needs a mime type header of "application/xhtml+xml" issued by the server. (See http://blog.whatwg.org/xhtml5-in-a-nutshell for more detail.)

In other words technically it's not enough to just look at the page source. (Which raises issues about validating such a document from file (as opposed to http).)

I haven't been keeping an eye on this recently. Has it changed since then? Has the html moved to xhtml?

User avatar
Albert Wiersch
Site Admin
Site Admin
Posts: 3453
Joined: Sat Dec 11, 2004 9:23 am
Location: Near Dallas, TX
Contact:

Re: XHTML5

Post by Albert Wiersch » Mon Nov 14, 2011 11:51 am

I've never seen the "<!DOCTYPE xhtml>" DOCTYPE.

Check out this link:
http://en.wikipedia.org/wiki/Document_T ... ss_DOCTYPE
In XHTML5 the DOCTYPE has to be a case-sensitive match of the string "<!DOCTYPE html>".
It also says "Given, however, that the HTML5 specification forbids XML-serialized HTML5 (XHTML5) from being served with any MIME type other than application/xhtml+xml". So if you are using XHTML5, then technically you are also suppose to serve it with that mime-type, assuming this is correct. I'll look into this further for v11.01 and see if I can add a new check for this... but the issue is that this may cause issues that you wouldn't have simply using the more popular "text/html".

What you might want to do is use HTML5, not XHTML5, and enable some CSE HTML Validator options to enforce more XML based syntax - like the option to require all optional end tags.

Unless there is some real need to use XHTML5 because HTML5 won't work, I would think using HTML5 instead of XHTML5 would be better (less problematic).
Image
Albert Wiersch

alnico
Rank I - Novice
Rank I - Novice
Posts: 15
Joined: Mon Jun 21, 2010 4:07 am

Re: XHTML5

Post by alnico » Tue Nov 15, 2011 5:05 am

My pages were valid XHTML1.1 until a year back. When HTML Validator added support for HTML5, I simply added the new tags, and removed the deprecated ones to match HTML5. When I used HTML Validator to check my syntax, I got a royal mess as I didn't know whether to move to HTML5 or stick with XHTML rules.

My pages are served up as application/xhtml+xml through the use of a PHP script - it's a neat script to serve up this MIME type to Standards compatible browsers, and serve a text/xml for IE6,7 etc. The script also renders and OBJECT tag instead of IMG for images, and renders an

Code: Select all

application/javascript
instead of

Code: Select all

text/javascript
.

I like XHTML because I notice the XML parser rendering pages on Firefox, Chrome & Opera load a page much faster than if served as text.

These are the errors if I use HTML Validator to validate an XHTML syntax page as HTML5:

Code: Select all

<meta property="og:type" name="og.type" content="sport" />
The "meta" tag requires that the following attributes be mutually exclusive: "name" "http-equiv" "charset" "itemprop" "property". No more than one of these attributes may be used simultaneously.

Code: Select all

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-gb" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dcterm="http://purl.org/dc/terms/"  xmlns:ctag="http://commontag.org/ns#" xmlns:c="http://s.opencalais.com/1/pred/" xmlns:v="http://rdf.data-vocabulary.org/#" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:sioc="http://rdfs.org/sioc/ns#" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:sioctypes="http://rdfs.org/sioc/types#">
The "xmlns:v" attribute was found but is not allowed by the current configuration (because its category is not active). This could be because "xmlns:v" is a proprietary (non-HTML5) attribute.

HTML5 requires that the "lang" attribute also be specified when "xml:lang" is used in HTML documents (this is not a requirement in XML documents). NOTE: The value of the "lang" and "xml:lang" attributes must be a case-insensitive match.

Thanks!

Post Reply