The problem for XHTML documents

by **PMB9** » Wed Mar 19, 2008 5:09 pm

Code: Select all: <?xml version="1.0" encoding="utf-8" ?> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Example</title> <meta name="description" content="This is an example to illustrate XHTML"/> </head> <body> <h>Lorem ipsum</h> <section> <h>Ipsum lorem</h> <p>Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p> <separator/> <p>Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.</p> </section> <section> <h>Autem duis</h> <p>Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.</p> </section> </body> </html>

There is one big problem: There are two standards for this document. HTML 5 and XHTML 1. How should it be interpreted?

edit: Now it's valid HTML5.

by **zcorpan** » Thu Mar 20, 2008 11:05 am

The above is not an XHTML document...

by **PMB9** » Thu Mar 20, 2008 7:42 pm

It will be an HTML5 document.

Please use another namespace than the XHTML1-Namespace if you can't work with the W3C to produce ONE Standard.

by **zcorpan** » Thu Mar 20, 2008 10:20 pm

PMB9 wrote: Please use another namespace than the XHTML1-Namespace ...

That would not be backwards compatible with shipped browsers or existing XHTML documents on the Web.

by **zcorpan** » Thu Mar 20, 2008 10:32 pm

PMB9 wrote:There is one big problem: There are two standards for this document. HTML 5 and XHTML 1. How should it be interpreted?

It should be interpreted according to HTML 5.

This specification is intended to replace (be the new version of) what was previously the HTML4, XHTML 1.x, and DOM2 HTML specifications.

-- http://www.whatwg.org/specs/web-apps/cu ... ge/#status

by **SneakyWho_am_i** » Wed Oct 08, 2008 1:25 pm

Unfortunately all the links posted in these threads seem to have slightly broken. That one nicely would have taken me to the middle of some previous page, but instead I find myself stranded at the top of the page.

Personally I find this new "It's both HTML AND XHTML" thing to be great.

Sadly, it won't help to clarify the differences between XHTML and HTML

Happily, it will erase quite a number of them, which hopefully will drag some of us into the future kicking and screaming.

"Hopefully" is the key word there, but anyway sitting and playing with my silly toys in my little sandbox I think it's great that I can now send my XHTML as valid HTML without doing any weird XSL transformations or scary custom buffer functions, or Load and Save, or anything weird like that. Just one or two lines to negotiate the headers, and then serve ONE page.

Nice.

by **Jarvklo** » Sun Dec 21, 2008 2:02 pm

One problem with negotiating the headers is that there are currently at least two competing and partly incompatible recommendations that claim the MIME-type "application/xhtml+xml".

So if something asks your server for a resource via HTTP claiming that it accepts "application/xhtml+xml" there will be no simple way to figure out wheter that something actually will treat your code as XHTML5 or XHTML Basic 1.1 - and there are IMHO currently enough DOM-related differences between the two alternatives (XML Namespaces allowed, or not, noscript allowed, or not, tbody automatically injected into your tables, or not - to name three obvious ones beside the (X)HTML5 specific new DOM and added capabilities in general) to make this an issue that IMHO needs to be resolved before we can reach "dual serialization heaven" in practice.

by **anne** » Wed Dec 24, 2008 6:25 pm

As long as clients implement the same standard -- here we expect that to be HTML5 -- there should not be an issue, right?

by **Jarvklo** » Tue Dec 30, 2008 8:18 pm

Indeed.
If that were actually the case right now this wouldn't be an issue.

Unfortunately it seems, at least to me, that the current situation is not that simple, and that the ambiguity sadly will remain as long as there are two supported working groups claiming the same MIME type for two diffferent markup languages. with two different purposes and very differing inherent existensibility properties...

by **anne** » Sun Jan 04, 2009 11:51 pm

So which implementations are not following or planning to follow HTML5? That Working Groups are working on conflicting specifications does not directly imply there is a problem. It is only a problem if deployments of both specifications are attempted within the same "arena".

by **Jarvklo** » Fri Jan 09, 2009 7:59 pm

anne wrote:So which implementations are not following or planning to follow HTML5?

Oh, please :roll:

If you didn't so easilly stoop to cheap rethoric trics instead of taking this concern seriously I wouldn't need to remind you of the following:

The point is, the web is full of use cases for extensibility. Full of it. It does no good to bring them up, though, if we're going to be caught up in a circular argument of, "Prove to me you need it. Well, that's not proof. Prove to me you need it..."

(from http://lastweekinhtml5.blogspot.com/200 ... -axes.html )

anne wrote: That Working Groups are working on conflicting specifications does not directly imply there is a problem. It is only a problem if deployments of both specifications are attempted within the same "arena".

Indeed - The issue here is that the HTML5 specification seemingly is trying to make darned sure that application/xhtml+xml can no longer be relied on for future XHTML- (i.e. XML-) based extensions and/or inventions (at leat not without forcing people to "pollute" their Content Negotiation strategies with browser sniffing)
My fear is that the current approach regardning application/xhtml+xml seems more to be aimed at "pulling the rug" out under the possibility of actually using Modular XHTML as a host language for future inventions than implementing a backwards compatible and future safe dual serialization.

But I guess I should have known better than to bring the issue up here with the hope of actually being taken seriously. Thanks for clarifying that at least Anne! - I won't bother this forum further and graciously give you the last word opportunity of this thread :roll:

The problem for XHTML documents

The problem for XHTML documents

Re: The problem for XHTML documents

Who is online

Who is online