homepage Welcome to WebmasterWorld Guest from 23.23.22.200
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 63 message thread spans 3 pages: 63 ( [1] 2 3 > >     
XHTML 2 vs HTML 5: let'em clash!
What do webmasters have to say about the future of the Web?
Herenvardo




msg:3730084
 11:49 pm on Aug 24, 2008 (gmt 0)

Straigth into the topic: within the W3C there is work in progress in two separate successors for HTML4.x / XHTML1.x:
XHTML 2.0 [w3.org] bids for a revolutionary and entirely breaking approach, redefining the language from zero as an XML application.
HTML 5 [whatwg.org], on the other hand, takes an incremental approach bidding for backwards compatibility and homogeneus error handling.

If you ask Google [google.com], it spits out roughly 80k answers to the issue in less than half a second (fortunatelly, you can check only those that appeal you, and you can take as long as you want to review them ;) )

Whatever happens there, it will surely affect us, the webmasters. And what a better place to discuss the topic that at Webmaster World?

Basic guidelines: this is mostly common sense, but I think some points should be stated out.

This is a debate, not some sort of exam: feel free to say what you think and, especially, why do you think so. There is no goal of achieving any "consensus" or common ground, the only goal is to gather as many opinions as possible, so we all end up with a bigger picture of the whole topic.

This is a debate, not a battlefield: this topic is already polarizing in several sectors, and a debate like this might start heating up as soon as there are a few members on each side. I think it's worth to remind here the point 14 of the ToS [webmasterworld.com]:
14. Please keep your language clean and decent. This include personal inflammatory language as well as obscenities.

As a general suggestion: if the discussion is too heated, preview your posts and read them; then decide whether to hit "Submit" or go to take a cold shower and rewrite the post afterwards.

This is not a competition: it's unlikely that we will be changing anything from this thread, so don't get obsessed. There are no winers and losers in this debate: if we end up with a deeper understanding of the goings-on of the process then we all win; if we end up with everybody being upset or angry, or we manage to get this thread blocked due to uncivilized behaviour, then we all lose.

In summary, try to exercise your freedom of opinion and speech, and make your best to respect these freedoms' of others.

Ready? GO!

 

csuguy




msg:3730120
 2:09 am on Aug 25, 2008 (gmt 0)

FIRST REPLY! :D

I believe HTML 5 - simply because of its backwards compatibility - is going to win. If using a language on the web intrinsically blocks users - why use it? You could create the page in multiple languages - but its not worth it IMHO.

Of course, its all about timing too. If they make the newest browsers of today (IE 7 & 8, FF3, etc) compatible with XHTML 2 and release 5 to 10 years from now, it may very well be a viable option. But the setup for XHTML 2 has to be there - it needs pre-existing backwards compatibility. Otherwise its best use will be for simple intranets.

albo




msg:3730135
 3:13 am on Aug 25, 2008 (gmt 0)

Getting real with myself, I begin to suspect HTML5.

I've done XHTML1.1 awhile now. But the simple-minded manner in which I use it amounts largely to grammatical strictness over HTML4.1: lowercase tags, close tags, tags properly nested, attribute values properly cited (even e.g. selected="selected")...

My English teacher said, "No split infinitives! Use different *from* and not different *than*!" In MY type of usage, perhaps, XHTML is purely pedantic.

Insofar as what real-world browsers will support first, I "suspect" HTML5.

Herenvardo




msg:3730167
 4:58 am on Aug 25, 2008 (gmt 0)

Well... let's start with this. I wanted the opening post to be completely neutral, and only provide factual data (and the key references) to provide a good starting point for the debate. So I'll start posting my own opinions from this post onwards. But before that, some more bits of factual data, in reply to your post:
If they make the newest browsers of today (IE 7 & 8, FF3, etc) compatible with XHTML 2 and release 5 to 10 years from now, it may very well be a viable option.

It would be good to know which release dates are being targeted, wouldn't it? ;)
According to the WG charter at W3's site, the timeframe for XHTML 2 was defined as
Following its approval by W3C Members, this group will commence in August 2002 and will terminate in August 2004.

It doesn't look too acurate. However, in March 2007 the XHTML 2 working group (which is the previously known as HTML WG) was chartered (that's the point when W3C embraced HTML5 activity, hence having to redefine the Working Groups), and a new timeline was set:
First public WD: August 2002 (this was defined as the date when the draft had been published, so it is obviously achieved)
LC: September 2007: it seems that they are almost a year late already
CR: February 2008: already late
PR: June 2008: also already late
Rec: September 2008: hurry, hurry! you can still make it! :P
For the HTML5 charter, they have used a list layout instead of fancy tables, which means that I can quote it properly here:
You can skip all this part unless you are interested in what are the Milestones for an W3C spec and how the whole process works.
1. 2007-05 HTML5 and Web Forms 2.0 specs adopted as basis for review
2. 2007-11 HTML Design Principles First Public Working Draft
3. 2008-02 HTML5 First Public Working Draft
4. 2009-03* HTML5 Last Call Working Draft

* editor's estimate is 2009-10
5. 2009-06 HTML5 Candidate Recommendation
6. 2010-06 HTML5 Proposed Recommendation
7. 2010-09 HTML5 Recommendation


The third point is already late: there is an "Editor's draft" publicly available, but it's not considered a Public Working Draft (an Editor's draft would normally be only available for WG members, but this WG has "public proceedings", so everything is available to the public). Also, if you take a look at the draft (the link in the opening post, since it is the latest draft) you will understand why this wouldn't normally be "published" :P
The 4th point is unlikely to be meet on time (a better chance if we take the editor's estimate instead, which is a more educated guess based on the pace at which feedback is dealt with). Once you read the WHATWG's FAQ [wiki.whatwg.org] (and my explanations below about how the W3 works), you will find out that the points 5 and 6 are going to take very long, and the WHATWG's estimate for HTML5 becoming an W3 recommendation is, as stated in the FAQ, "in the year 2022 or later".

About how the W3 works (and about all these flavors of specs):
[b]Editor's Working Draft
: that's the working draft the WG works with on an every-day basis. When it becomes something "human-readable", a Public WD is released.
Public Working Draft: A date is defined for the first, because there will surely be a first public draft, but there might be only one, or there might be dozens. The main goal of the public draft is to draw feedback from the different interested parties (although the HTML5 WG is doing this directly from the Editor's draft, which is also public in this case, so this one doesn't have too much meaning). Feedback is normally translated into "Issues" and issues are dealt with by the group. When all the issues are dealt with, the next public draft is released, and so on until a draft arises no issues (due to the openness of the HTML5 process, this is being done in a much more dynamic way, but the concept of issues is similar: once there is a draft that has no issues and no new issues are opened in a given timespan, the spec advances to Last Call).
Last Call WD: Also known as "Call for implementation", the release of the LC denotes some stability of the specification and invites interested vendors to implement it. At this point only implementation feedback is gathered. If this feedback translates to new issues, a new LC adressing such issues is published, and so on until a LC "survives" long enough (I'm not sure how long it takes) without new issues, it moves forward to CR. In the case of HTML5, since major browser vendors are already implementing the most "stable" parts of the spec on the run and providing feedback, the LC stage should be quite short for this case.
Candidate Recommendation: Basically, on this stage test suites must be made available, so implementations can be tested (I'm not sure if test suites need to be ready at some early stage, however). Once there are at least two public, general use implementations (ie: no betas, experimental builds, and other unusual stuff are counted, only public "final" releases) that are valid according to the test suites, then the spec takes a step forward in the process. This is likely the point where HTML5 will take longer: according to the FAQ "20,000 tests for the whole spec would probably be a conservative estimate". Actually, the same FAQ states that they aim for reaching CR by 2012, which means just 4 years from now; and then 10 more years only for the "testing" part.
Proposed Recommendation: At this point, the only thing to be done is to vote the spec within the W3C. If the voting is successful, then the spec becomes a Recommendation. If it's voted against... then I don't know what it happens :S .
Recommendation: At this point, the specification is an "oficial" W3C standard, and in theory it may be relied upon by content authors and tool (including authoring tools, browsers, and any other relevant software) vendors.
Here ends the boring part.
In summary, the specification should become stable by 2012, and become an official standard by 2022. However some parts will be available for developers to use even before that: for example, major browsers already implement the <canvas> element; and many features of HTML5 can be emulated through JavaScript to achieve a "smooth" adoption.
So, that's everything you may need to know about the dates. If you want to be aware of updates on these estimate dates, keep checking the relevant links.

Now, my opinion:
I think that, comparing the documents right away, XHTML2 is currently better: it provides a cleaner content model, draconian error handling is not an issue for me (I author compliant and well-formed documents), and it provides some improvements that I really like, such as the sectioning model, or the complete separation of presentation, structure, and semantics. For example, if you want to have a list for navigation (and be recognized as a navigational element by supporting UAs), in XHTML2 you'd use the <nl> element, probably with a role="navigation" attribute. In HTML5 you would need to use a <nav> element, which defines both the "navigation" semantics and sectioning structure: if it is navigation, then it will be forced to be a section. If you indeed wanted the navigation to be a section, XHTML2 allows you to define that as
<section role="navigation">
<nl>
...
</nl>
</section>.
Another advantage of the XHTML2's sectioning model is the <h> section header element, which is equivalent to the <h1..6> appropriate for the current level of <section> nesting. This becomes really useful when maintaining a dynamic site: you added a header and now you need to uptade all the <h3> and deeper tags in who knows how many other scripts and includes.

Of course, browser vendors' support for HTML5 is also an important factor, but it will probably get eclipsed by an even more important factor in favor of HTML5: although the XHTML2 spec is currently better when analized by its own merits (ie: without counting that browser vendors have already make their choice, or that it doesn't deal with the existing legacy of tag-soup on the web), it is already "closed" (it won't be changed at all except for the redundant appendices and editorial corrections), while HTML5 is more open than any other spec in the W3C's history: the spec is being built by the ~900 subscribers of the mailing list, with the WG members acting mostly as moderators. And I can state first-hand that the feedback provided through the lists is properly dealt with. This doesn't mean that every feature request will automatically become a HTML5 feature, but that the Editor and other group members will review it and consider it based on its technical value (ie: if it solves a real problem, it will most likely in; but if you ask for a <blink> tag without even exposing a reason you will most likely be ignored).

So all in all, I feel that currently XHTML2 is, technically speaking, better in many aspects; but HTML5 has the potential to become even much better than that. Adding to it that it has most of support, it is most probably going to "win" for good.

Regards,
Herenvardo

Lexur




msg:3730170
 5:12 am on Aug 25, 2008 (gmt 0)

I think most webmasters don't care about these things.

I use HTML 1.0, some javascript, PHP...

Why should let my sites or my users to waste a second with the 2022 standards?

csuguy




msg:3730176
 5:25 am on Aug 25, 2008 (gmt 0)

HTML 1.0? o.0

Marshall




msg:3730180
 5:35 am on Aug 25, 2008 (gmt 0)


LC: September 2007: it seems that they are almost a year late already
CR: February 2008: already late
PR: June 2008: also already late
Rec: September 2008: hurry, hurry! you can still make it! :P

I'm still waiting for the U.S. to go metric. Wasn't that suppose to happen, oh, 30 years ago. It is fine to sit back and say "we'll do this and we'll recommend that," but the real world does not work that way.

Marshall

wrgvt




msg:3730509
 2:56 pm on Aug 25, 2008 (gmt 0)

Put me in the who cares category. I have thousands of pages in HTML 4 and as long as they still work in browsers, why worry about it? Then again, I don't do anything fancy. I definitely like the KISS method.

Bert36




msg:3778146
 10:01 am on Nov 1, 2008 (gmt 0)

Ok, it is a bit of an oldish topic, but I have been reading both the drafts for XHTML2 and (X)HTML5 for the past two months now. Going through them vigorously. And I would *hate* it if (X)HTML5 became the popular standard.

A standard like this should follow the normative guidelines. You cannot provide for every practical contingency and situation, so you must give strict guidelines on a generic, categorised level. Keeping the practical implementation as flexible as possible. In addition, it should foresee in future additions.

(X)HTML5 is simply a very bloated version of HTML4. It is too stringent and does not provide for any flexibility. As I read it it felt more like a law than a standard. I also think that some mechanisms in (X)HTML5 do not do a good job of separating style from content.

XHTML on the other hand has done a fine job of not overcomplicating things while still produce a standard that is both flexible and innovative. One of the best things (for me) in XHTML2 is the fact that virtually anything can be a link or a picture. This one, simple mechanism not only gives us a huge flexibility in design, but also does wonders for accessibility. And for the latter, XHTML2 also provides a special element.

It is not to say that (X)HTML5 does not have any good ideas. The <mark> tag for example could very well be included in XHTML2 as far as I am concerned, and although I do not agree with the redefinition of the i- and b-tag in (X)HTML5, I still think XHTML2 should redefine them in a similar way (to make them more semantic).

But other than that, I can only hope that we will be able to use XHTML2 sooner than (X)HTML5. In the end it is a personal choice and it shouldn't matter, I just pray browser manufacturers will implement both equally fast and complete. My choice is XHTML2.

[edited by: Bert36 at 10:01 am (utc) on Nov. 1, 2008]

essiw




msg:3778275
 4:53 pm on Nov 1, 2008 (gmt 0)

a good internet site i found on google about it: [xhtml.com...]
seems like it is better to still use xhtml 1.0/1.1 or html 4.01 for a while

Herenvardo




msg:3778362
 8:55 pm on Nov 1, 2008 (gmt 0)

Put me in the who cares category. I have thousands of pages in HTML 4 and as long as they still work in browsers, why worry about it?

Keep in mind that HTML5 defines lots of details of browser behavior; so it might be worth to keep checking your pages from time to time, so in case some browser implements something breaking from HTML5 you can fix the pages to not break on it.

For example, any javascript relying on the DOM may be heavily affected when/if browsers switch to HTML5, since the spec requires the UA to insert "anonymous" <section> elements based on the <h1> through <h6> elements (this makes some sense, since the headers are supposed to describe the sectioning hierarchy; but will break any script that tries to "browse" through the document tree).

Ok, it is a bit of an oldish topic, but I have been reading both the drafts for XHTML2 and (X)HTML5 for the past two months now. Going through them vigorously. And I would *hate* it if (X)HTML5 became the popular standard.

Despite how much you could hate it, it is already happenning. It's not surprising that the HTML5 spec's copyright belongs to "Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA."

(X)HTML5 is simply a very bloated version of HTML4. It is too stringent and does not provide for any flexibility. As I read it it felt more like a law than a standard. I also think that some mechanisms in (X)HTML5 do not do a good job of separating style from content.

100% agree.

XHTML on the other hand has done a fine job of not overcomplicating things while still produce a standard that is both flexible and innovative.

Here I have to disagree, and I want to clarify this point because it's the very root from which all the HTML5 thing began (by then known as Web Applications 1.0).
Your statement is true for most of the XHTML2 spec... until you reach the Forms part. There are "good" theoric reasons for using XForms, but no practical arguments to redefine web forms: authors are asked to learn an entire new language for something they have been doing without serious issues for years; and browser vendors were quite unwilling to entirely re-write their rendering engines just because the XHTML2 group felt like it. And, since the group completely ignored all the feedback from these groups, there is no "officially known" good reason for XForms.
The WHATWG activity began as a response to this, aiming to define a web-forms spec that would replace the XForms part of XHTML. Why did they later decide to replace the entire language with their own bloated tag-soup is beyond my understanding :o.

But other than that, I can only hope that we will be able to use XHTML2 sooner than (X)HTML5. In the end it is a personal choice and it shouldn't matter, I just pray browser manufacturers will implement both equally fast and complete. My choice is XHTML2.

Hope as much as you want, but I'm afraid that this is, unfortunatelly, not likely to happen :(.
HTML5 is the browser vendors' spec: it is written by browser vendors, for browser vendors, with mainly browser vendors in mind. The only reason the W3C has adopted it is because vendros told the consortium something like "we aren't going to do XHTML2, but we will do HTML5, so you either pretend to agree, or you will have no more credibility".
It's a fact: browser vendors have a good deal of power: they have the final choice on whether to implement something or not. Now they are aware of that power, and they are tyranically using it to impose their viewpoint over the entire Internet.
If there were a choice, mine would be XHTML2 as well; but I'm afraid the only choice will be to feed the browsers whatever they want to chew.

a good internet site i found on google about it: [xhtml.com...]
seems like it is better to still use xhtml 1.0/1.1 or html 4.01 for a while

Of course, it's still to soon to use any of these new specs yet. But I'd like to warn you that the site you mention is both biased and outdated. It misses the main issue of XHTML2 (XForms arrogancy); and some of the drawbacks it mentions about HTML5 no longer apply (for example, the <font> tag is gone for good; as well as the pre-defined class names).

Honestly, when I started this thread, I had some hope with HTML5. With the process being as open as it was claimed to be, it would have just been a matter of time for the spec to become better than XHTML2. However, after participating in many discussions for the last two months, I have realized that this is just a facade, and feedback is only observed from the vendors viewpoint: if they like it, it gets into the spec; otherwise it doesn't.

Bert36




msg:3778524
 8:48 am on Nov 2, 2008 (gmt 0)

I must admit I didn't read the part about XForms that well. And I was unaware of what you tell me about the relationship between XForms and HTML5. Somewhere in the back of my mind I always felt uncomfortable with browser manufacturers doing standards. It is almost as if the old browser-wars never ended but the battlefield shifted.

[edited by: tedster at 7:28 pm (utc) on Nov. 2, 2008]

mattur




msg:3778795
 9:32 pm on Nov 2, 2008 (gmt 0)

The only reason the W3C has adopted it is because vendros told the consortium something like "we aren't going to do XHTML2, but we will do HTML5, so you either pretend to agree, or you will have no more credibility".

The W3C decided it would not be developing HTML any further, to focus exclusively on XHTML2, and so for the next 9 years the W3C ignored the current web. The damage this did to the W3C's credibility and relevance was self-inflicted.

It wasn't just browser makers who thought XHTML2 was impractical, overly-complex and mostly pointless. Even Zeldman, the high priest of XHTML-advocacy, said he couldn't see any benefits.

Some folks eventually got so fed up with this situation they decided that if the W3C was not going to develop standards for the current web they would, and setup the WHATWG.

If you believe XHTML2 is the way forward, then HTML5 provides a stopgap solution to the decade-long stasis that the web has suffered under the leadership of the W3C, until XHTML2 takes over. OTOH if, like me, you're unconvinced by the case for XHTML on the web, HTML5 provides an alternative path for future development, conveniently rescuing the W3C from itself at the same time.

Herenvardo




msg:3778850
 12:11 am on Nov 3, 2008 (gmt 0)

The W3C decided it would not be developing HTML any further, to focus exclusively on XHTML2, and so for the next 9 years the W3C ignored the current web.

Yet still, during all these 9 years, a good deal of the web ignored "the current web", as XHTML1 steadely gained ground over tag-soup HTML, even despite the fact the most used browser (IE) refuses to try to handle it when served properly (which makes no sense, since it is perfectly capable of rendering it, which can be proved by the fact that a quine-ish XSLT gets it rendering). Anyway, I wouldn't take too seriously a browser that has taken over 10 years before decently supporting CSS2.

It wasn't just browser makers who thought XHTML2 was impractical, overly-complex and mostly pointless. Even Zeldman, the high priest of XHTML-advocacy, said he couldn't see any benefits.

I have no idea who that Zeldman is, and even less why is "the high priest of XHTML-advocacy"; but someone who "couldn't see any benefits" on XHTML2 is either blind, hasn't looked at XHTML2 at all, or is simply lying.
A few examples from the top of my mind would be support for extensible semantics, decent fallback for <img>, or a cleaner and clearer content model.
Whether the benefits are worth the drawbacks and/or the costs could be worth discussing, but that's quite a different thing than saying there are no benefits.

Some folks eventually got so fed up with this situation they decided that if the W3C was not going to develop standards for the current web they would, and setup the WHATWG.

Curiously, these folks are three of the four major browser vendors (five, if you count Google and their recent Chrome browser): Apple, the Mozilla Foundation, and Opera Software. And, as fed up as they were of being ignored by the W3C, they are ignoring the same way every feedback that doesn't come in the form "this browser has implemented this" or as a praise.
What's still surprising is that the spec is being written in English and not in C. Have you noticed that it defines more algorythms than markup components (elements + attributes)? And it's supposed to be the spec for the new HyperText Markup Language. That's, at least, curious.

If you believe XHTML2 is the way forward

I don't. It has serious flaws that would need to be fixed for it to be really useful. For a time I thought that HTML5 would provide those fixes, but it just tosses away everything given by XHTML2, regardless of if it's good or bad, and furtherly bloats the already bloated markup HTML4 left us, up to the point of rescuing <i>, <b>, and <small>, among other 3.2-ish presentational aberrations.

then HTML5 provides a stopgap solution to the decade-long stasis that the web has suffered under the leadership of the W3C, until XHTML2 takes over.

There are two separate points here: first, you are asumming HTML5 will come sooner than XHTML2, but most of XHTML2 is already stable, while the WHATWG doesn't expect HTML5 to be stable sooner than 2012.
On the second point, about the decade-long stasis of the web, I must say that the role of the W3C has been completely irrelevant to it. Even assuming your idea that W3C's choices were all wrong and ill-fated, and whatever you want, how much matters how long does the W3C to define the next standard if the most used browser (IE) doesn't yet support a 1998 standard (CSS2)? (Ok, the IE8 betas finally seem to support it, but they are still betas.)

OTOH if, like me, you're unconvinced by the case for XHTML on the web, HTML5 provides an alternative path for future development

Indeed. I, like you, am unconvinced about XHTML: there are some things that I like, and many I don't. And effectively, HTML5 provides an alternative, but it's not that better than X2. It's like choosing between jumping into a huge abbyss or into a lava river, only that you don't really get to choose: browsers will come and push you into their own choice.

[edited by: Herenvardo at 12:17 am (utc) on Nov. 3, 2008]

pageoneresults




msg:3778881
 1:30 am on Nov 3, 2008 (gmt 0)

Last time I checked, all web applications from Microsoft and many others are based on XHTML. Do you really think that HTML 5 is going to catch on? I'm not too certain. I've browsed a little bit over there and they've got a lot of neat stuff in the works. But, it's one of those "go with the flow" things. I've tried switching back to HTML only to get whacked by me development team. They just line up and give me "Mark Harmons" every day. I've got a virtual bald spot back there too. :)

Yes, I've read all the topics on why you shouldn't use XHTML, blah, blah, blah. I'm on a Windows platform and I do have a choice. But, if I choose to force HTML, it comes with many challenges. Our pages MUST validate. Blending HTML and XHTML is challenging, I tried it and switched back to XHTML. Since then, things have run very smoothly under XHTML 1.0 Strict and Transitional DOCTYPEs.

Truthfully? I don't have any complaints about the existing standards, none whatsoever. Oh wait, they aren't promoted enough, that would be my only qualm. Everything appears to be working for me and has been for many years. Is something broken and we need another level of HTML? ;)

encyclo




msg:3778887
 1:44 am on Nov 3, 2008 (gmt 0)

pageoneresults brings up an extremely important point - the question as posed above is a false dilemma. The choice is not between XHTML2 and HTML5. The choice is between those two, HTML 4.01 and XHTML 1.0.

I had started to follow the HTML5 development, I'm now ignoring it. It's an interesting academic exercise, and has probably more chance of eventual adoption than the flawed XHTML2, not least because it is being developed by and for the browser makers and bank-rolled by Google. XHTML2 is unfunded and ignored by those who would need to implement it.

However, HTML5 is long-term at best. The simple fact is that HTML is not broken, so there is no compelling need for a new version. There is nothing today which makes any developer start longing for a new version of (X)HTML. HTML 4.01 and XHTML 1.0 (as text/html) Just Work.

mattur




msg:3779114
 12:34 pm on Nov 3, 2008 (gmt 0)

zeldman

Zeldman evangelised XHTML as head of the "Web Standards" movement, wrote the seminal "Better Living through XHTML" article, and was imho largely responsible for getting the masses to adopt XHTML1 - for no apparent reason.

But my point is it wasn't just "tyrannical" browser companies who thought XHTML2 was flawed, experts like Tantek and Mark Pilgrim, and even XHTML advocates like Zeldman, were equally unconvinced.

Your post portrayed the browser's companies decision to not support XHTML2 as some nefarious plot on their part, imposed on the rest of us. This was not the case. XHTML on the web failed (or perhaps more accurately, "fail on error" on the web failed).

[WHATWG] are ignoring the same way every feedback that doesn't come in the form "this browser has implemented this" or as a praise.

You said above:

And I can state first-hand that the feedback provided through the [HTML5] lists is properly dealt with

What changed...?!

HTML5 provides an alternative, but it's not that better than X2.

(X)HTML5 is backwards compatible, XHTML2 isn't.

So HTML5 can be adopted gradually/progressively as browser support for individual features is added (like XMLHttpRequest has been adopted), but XHTML2 required a year-zero, all-or-nothing approach to adoption.

Rosalind




msg:3779116
 12:39 pm on Nov 3, 2008 (gmt 0)

HTML is not broken

I've got to agree. How much does it cost to retrain developers and fix code every time a new standard is introduced? There has to be a compelling reason to add another html version, and I just don't see it right now.

g1smd




msg:3779130
 1:03 pm on Nov 3, 2008 (gmt 0)

Several things will happen...

People will use neither of the standards, and continue to write broken code that conforms to no known standards of any sort (or will manually edit and break code produced by a tool that did originally provide compliant code).

Leading/popular tools will default to one or the other and people will produce code using one or other of the standards, without even realising they had a choice, or what the alternatives actually were.

I see lots of people producing XHTML-like code when HTML 4.01 Transitional would have been more than good enough: and many have no idea that there was an alternative.

The web will continue to be broken unless browsers get more active in alerting users to code errors. IF XHTML2 breaks all previous standards, this could be a good time to make it more strict in application; will it be more strict in not processing files if they are not compliant?

slef




msg:3779166
 1:46 pm on Nov 3, 2008 (gmt 0)

I'm torn. I'd like xhtml2 to win because it's cleaner and seems less vendor-owned; but I like html5 for being more evolution than revolution.

tonynoriega




msg:3779233
 3:30 pm on Nov 3, 2008 (gmt 0)

this is it.. this is the beginning. the separation of the web. development, design, adaptation, acceptance and evolution are going to take two different paths. it happened in technology in the past and its going happen with browsers and internet development.

i have been designing and developing since '00 and have seen what i call the separation of "church and state". i still know people that develop entirely in pure HTML X.X and dont include any other language that might discriminate against anyone. Then i know people that go with XHTML X.X strict, with Flash and the whole kit and caboogle who dont care about those left behind.

you can try to force those behind to upgrade, conform, and accept your new rules and implementations but when forced, only reject.

Web 2.0? who in the heck decided there was a web 1.(anything) Someone got an itch, named a new type of design and communication methodology, called it 2.0 and it caught on... and took its own path.

its not an interconnected web of communicating machines anymore, its a confused mix n mash of competing machines to see who can come out on top.

Herenvardo




msg:3779295
 4:39 pm on Nov 3, 2008 (gmt 0)

pageoneresults brings up an extremely important point - the question as posed above is a false dilemma. The choice is not between XHTML2 and HTML5. The choice is between those two, HTML 4.01 and XHTML 1.0.

Currently, this is true. And the actual choice between HTML4 and XHTML1 can get reduced to very simple questions:
- Do you need any of the XMLish features provided by XHTML (such as XSLT, or embeeding of other XML-based formats such as MathML or SVG)?
- Are you Ok with XMLish draconic error handling (a.k.a. "fail on error")?
If you answer yes to both questions, then XHTML 1.0 is for you (or it should be). If you answer no and yes, respectively, then the choice doesn't matter that much. If you answer no to both, definitelly HTML4 is for you. And if you answered yes and no, respectivelly, then you face a tough choice.
When we get browser support in mind, however, IE's silly handling of the "application/xhtml+xml" mimetype leans the balance quite a bit towards HTML4. There are some other factors that may come into play (for example, I've heard that Google's AdSense has some issues with pages being served as XML); but these are often quite case-specific.

Anyway, it is a good thing that both HTML4 and XHTML1 provide the same set of elements (even the same three "flavors").
The original question on this thread's subject was not intended to ask which would you choose for authoring your pages: browsers will probably choose for us instead. The main point was to bring out what people perceives as the best and worst things on each, their pros and cons.

What changed...?!

Insight. Just that. When I initially joined the HTML5 list, I got excited by the apparent openness of the process and, I'll admit it, heavily biased. The few feedback I had seen by that time had been, effectively, been dealt with appropriately; it's just that it wasn't a representative enough sample. Two months later, having seen many more discussions, I've noticed a pattern that I already mentioned earlier:
Feedback expressed in terms of what current implementations do is properly dealt with.
Any other kind of feedback is either discredited as soon as some side-comment arises the chance or simply ignored if no such chance appears.
Honestly, I've only been following the lists for two months, and this means some tenths of discussions (ranging from a single message to around a hundred per discussion), but that pattern applies to all the discussions I've seen since there.

But my point is it wasn't just "tyrannical" browser companies who thought XHTML2 was flawed, experts like Tantek and Mark Pilgrim, and even XHTML advocates like Zeldman, were equally unconvinced.

Actually, I can quite agree with that view. Although I got a quite good impression of it the first time I looked at the XHTML2's spec drafts, I'm not really convinced by it, and the deeper I look at it the more issues I see.
To that I want to add that I am (or, at least, used to be) a XHTML advocate: even I aknowledge there are some use-cases for which XHTML is not good; I used to think that the more sites switched to XHTML, the better the Web would be as a whole.

Your post portrayed the browser's companies decision to not support XHTML2 as some nefarious plot on their part, imposed on the rest of us.

Then I apologize, I failed to express myself properly. Let me fix that issue now.
Initially, there were solid reasons to step away from XHTML2 (a couple of examples would be the "XForms arrogance" or forcing draconic error handling whitout letting autors to opt-out of it).
These legitimate reasons were aknowledged, which made browser vendors enter a "power intoxication" state, leading to despotic* behavior, not neededly intended.
* BTW, I'm now realizing that the "despotic" adjective matches better what I meant with "tyranic". So, please, assume that where I said the later in my previous posts, I meant the former. This is just a linguistic and expression issue; after all I'm not a native English speaker and sometimes make mistakes.

To put it in some other words (just to make sure I express myself decently this time), vendors said "Hey! They admit that we're right. So, if we are right, why don't we make a 'right' spec from scratch?", then threw everything XHTML2 gives, be it good or bad, to the bin, and started writting (and implementing on the fly) a spec that is as flawed and as bloated as HTML3.2 was. I'm not saying they did this with any intention to "harm" the web or to impose their criteria just to acquire more power; it's just that they are blind to the fact that they can make as many mistakes as anyone else can: we're all humans after all. And, since they don't realize they can make mistakes, they are simply rejecting any kind of feedback that involves that possibility.
So, this is not some conscious "nefarious plot on their part", but just childish and irresponsible behavior that is, at the end, leading to exactly the same results.

To top it up, the WHATWG miserably failed to scope their efforts, to the point that the document which is supposed to define their "ideal new markup language" almost forgets about the markup itself, and focuses on lots of side-stuff like the DOM, error-handling, implementation details, and so on. I want to emphasize on the "implementation details" part, because I thing this is plainly enough by itself to take that spec and set it on fire: by mere definition, a spec intended for the web must be implementation-neutral.
Finally, to round up the package, HTML5 adds the "bonus" (please read that with an implicit sarcasm) of a document so badly structured and ugly formatted that attempting to read it is just a race between your brain and your eyes to see which starts bleeding sooner. Anyway, that one is just an editorial issue with the document that defines the format, rather than with the format itself; and I hope it will be fixed as the spec matures (it's already quite better than two months ago).

XHTML on the web failed (or perhaps more accurately, "fail on error" on the web failed).

Even more accurately, XHTML (1.x) succeeded despite its "fail on error" nature. More on the "fail on error" topic later on this post, when I get down to g1smd's reply.

(X)HTML5 is backwards compatible, XHTML2 isn't.

(X)HTML5 is not backwards compatible, despite it claims so. It requires older documents to be processed as (X)HTML5 by conformant UAs, and it redefines some elements with incompatible semantics. This means that, in order to be HTML5-conformant, a UA must treat documents in a way that is guaranteed to differ both from how a HTML4 (or earlier) UA would treat it, and from how the author originally intended it to be treated. Furthermore, the HTML5 spec doesn't allow older documents to be treated according to older (relevant for that document) standards. So, not only (X)HTML5 is not backwards compatible (ie: valid HTML4 will not always be valid HTML5), but it also explicitly forbids UAs from providing such backward compatibility at the implementation level.
XHTML2, on the other hand, is defined in such a way that it only applies to documents which explicitly identify themselves as XHTML2; thus ensuring that UAs can provide backward compatibility at the implementation level. Due to this, XHTML2 doesn't need to be backwards compatible at the document level (ie: if a document is not XHTML2, then it isn't marked as such and it's not treated as XHTML2; so where is the need to make XHTML2 a superset of older specs?). Furthermore, XHTML2 takes advantage of having lifted such constraint; so it doesn't need to carry over the flaws of previous versions of X/HTML. This also means, of course, that XHTML2's flaws are XHTML2's own; since "backwards compatibility" at the document level is not an excuse anymore (for example, due to the way it is designed, it doesn't make any sense for it to preserve elements such as <a>, <img>, or the <h1>...<h6> headings).

So HTML5 can be adopted gradually/progressively as browser support for individual features is added (like XMLHttpRequest has been adopted), but XHTML2 required a year-zero, all-or-nothing approach to adoption.

Actually, this isn't entirely true. Exluding the interactive (forms and events) stuff, XHTML2 can be rendered in any current browser that supports XML + CSS2; and the default CSS2 style-sheet you'd need for that is already part of the XHTML2 spec. Furthermore, thanks to XHTML modularization (IMO, one of the best things provided by XHTML), you can easily build a DTD that imports the "document" stuff modules from XHTML2, but then take the "classic" forms module from XHTML1.1. If even that isn't enough flexibility for you, you still have the option to go nuts with XSL and transform the document into the HTMLish tag-soup browsers seem to love so much.

HTML is not broken

I mostly agree on that: HTML is not broken, although it has some issues. JavaScript-in-HTML, OTOH, is completely broken. That's one of the issues HTML5 wanted to fix, and they are doing a quite decent job at that, but this shouldn't be part of the HTML spec itself.
There has to be a compelling reason to add another html version, and I just don't see it right now.

That's a really good point. IMO, neither XHTML2 nor HTML5 provide any such compelling reason. However, this doesn't rule out the possibility that a good enough spec could be compelling enough.

People will use neither of the standards, and continue to write broken code that conforms to no known standards of any sort (or will manually edit and break code produced by a tool that did originally provide compliant code).

Indeed. There are two obvious reasons for that: the first is the lack of good, affordable for individuals/hobbyists, authoring tools, so people who can't afford an authoring tool manually write their code. The second is the fact that even the best tools are not good enough (otherwise, why would someone manually edit the code?).
Leading/popular tools will default to one or the other and people will produce code using one or other of the standards, without even realising they had a choice, or what the alternatives actually were.

Yep, this is already happenning now, and has been happenning for many years. I haven't too much to say about it, only that I wonder what would authoring tools choose as their defaults, and what would their choice based on.

I see lots of people producing XHTML-like code when HTML 4.01 Transitional would have been more than good enough: and many have no idea that there was an alternative.

I'm not sure what do you mean with this. XHTML1 Transitional is not too different from HTML4 Transitional (just the "always lowercase", "always close your tags" requirements, and the draconian error handling).
Maybe are you speaking about pages that are XHTML (ie: using the XHTML doctype and namespace, and abiding to the "X-rules") but served as text/html? I'll get a mention at that issue at the end of this post.

The web will continue to be broken unless browsers get more active in alerting users to code errors. IF XHTML2 breaks all previous standards, this could be a good time to make it more strict in application; will it be more strict in not processing files if they are not compliant?

XHTML1 already does that. Well, at least when it is actually served as XHTML.
More specifically, this is what browsers do (or claim to do) depending on what the server gives them:

  • HTML served as "text/html" is parsed as "tag-soup", and the browser will do its best to try to render the page, no matter how broken it may be. (As a curious fact, during the first browser wars, Microsoft did an amazing job, reverse-engineering subtleties about NN's error handling that even the folks at Netscape were unaware of.)
  • XHTML served as "text/xml" or "application/xml" gets normally rendered as generic XML. Browsers can, however, be smart enough and notice the XHTML's doctype and/or namespace and render the document as XHTML (I'm not sure right now which browsers do this); but authors shouldn't rely on this and use a more specific mimetype; or explicitly control the rendering via XSLT or CSS.
  • XHTML served as "application/xhtml+xml" is perfectly processed as XHTML by most browsers (with the prominent exception of IE's "obnoxious download dialog" approach); applying XML's draconian error handling (a.k.a. "fail on error"), recognizing <?xml-stylesheet?> and other XML processing instructions, and so on, and finally rendering it as an HTML webpage. It's worth mentioning that the DOM exposed on these pages for client-side scripting normally differs slightly from the one exposed in "tag-soup mode". On IE, this behavior can be partially emulated by serving the page as generic XML, with an XSLT stylesheet that simply outputs the root node (this gets XML draconic error handling applied, and then the browser feeds the document tree to its tag-soup parser); but the exposed DOM will be the one for tag-soup HTML (hence breaking scripts even further than they already break).
  • XHTML served as "text/html", which is quite often found accross the web (specially due to the IE issues, added to the fact that IE is still the most used browser, despite it is also the most broken), is taken as tag-soup. It is sometimes called "tag-soup with croutons", due to the XMLish empty tag syntax (like <br />), which would cause the page to horribly break if processed by an actual SGML parser (which all browsers are supposed to be, but fortunately none is).

So, IMO, before worring about browsers not rendering bad content, we should worry about them (especially IE) rendering valid content. Otherwise, nothing at all would be rendered by some browsers.

In addition, I want to mention that there are some cases where strict error handling isn't a good idea; mainly blogs and forum sites that allow visitors to format their comments with HTML code: since the site can't control what the users put in there, they can't afford the entire page breaking if someone posts broken code. It's possible to elegantly use CDATA blocks in an XHTML document, and then sending it through a trivial XSLT; but that's quite an overkill compared to using lenient HTML directly (unless you really want strict error handling on the "official" fragments of the page).

Ouch! Now that I thought I was done, I refreshed the thread's page and found more replies ^^;

I'm torn. I'd like xhtml2 to win because it's cleaner and seems less vendor-owned; but I like html5 for being more evolution than revolution.

I've already gone deep enough about this, but I'll mention one of the details again: XHTML2, supposed to be revolutionary, allows currently existing pages to be treated as they are currently treated; and only defines how pages marked as XHTML2 should be handled. OTOH, with the implications and attempts at "simplification" done by HTML5 (and how it interacts with the XML spec), the spec is literaly requiring from browsers to refuse many XHTML1 pages that are currently valid and 100% compliant, displaying XMLish error messages. And, funny enough, it's claimed that this is being done "to ease transition".

@tonynoriega: rather than quoting and replying inline, I'll just say this: 100% agree. IMO, "Web 2.0" is just the brand name of brokenness.

pageoneresults




msg:3779310
 4:53 pm on Nov 3, 2008 (gmt 0)

While its great to really be discussing the future of the web, I'd like to first address the history and current status. The future can wait, we still have challenges at the HTML 4 and XHTML 1 levels.

Seriously, what portion of the web is ready for two new languages? Webmasters are still battling with basic HTML. As I mentioned in my previous reply, all Windows Web Applications are based on XHTML, what is your proposal for the application developers? Should they stop what they are doing and revert back to HTML 4.01 so they can prepare for HTML 5? Ya see how confused one can get? And that is exactly what these two languages do, confuse things even more.

I'm all for evolving. Look at where we are today. :)

mattur




msg:3779356
 6:15 pm on Nov 3, 2008 (gmt 0)

Hi Herenvardo,

HTML5 is not backwards compatible... it redefines some elements with incompatible semantics.... a UA must treat documents in a way that is guaranteed to differ both from how a HTML4 (or earlier) UA would treat it, and from how the author originally intended it to be treated.

Can you give me an example of an actual RW problem this will cause? HTML offers such limited presentational semantics I can't see how minor changes to an element's "meaning" will affect anyone(?)

So HTML5 can be adopted gradually/progressively as browser support for individual features is added (like XMLHttpRequest has been adopted), but XHTML2 required a year-zero, all-or-nothing approach to adoption.

Actually, this isn't entirely true. Exluding the interactive (forms and events) stuff, XHTML2 can be rendered in any current browser that supports XML + CSS2... you can easily build a DTD ...take the "classic" forms module from XHTML1.1...

Yes, after you've re-written all your content in XHTML2, it's possible to make it work again in current browsers, like it did before. I think this re-writing qualifies as an all-or-nothing, year-zero approach ;)

HTML5 *doesn't* require us to rewrite entire sites and publishing systems to use a new feature. So when for example Canvas is widely supported we'll be able to add it to an existing website (HTML4/XHTML1/tag-soup) and it'll just work. Probably. :)

mattur




msg:3779374
 6:45 pm on Nov 3, 2008 (gmt 0)

Hi pageoneresults,

Seriously, what portion of the web is ready for two new languages?

XHTML2 is effectively dead, so that's one less language to worry about :)

HTML5 is an evolution of HTML4/XHTML1. Most people just refer to it as HTML5, but it will be available in HTML and XML versions. You can safely ignore it until its new features have widespread browser support and you want to use them.

all Windows Web Applications are based on XHTML, what is your proposal for the application developers?

Keep using XHTML1. When/if you want to use new features in (X)HTML5 just change your doctype. XML syntax is valid in the HTML version of HTML5, so in the future you should be able to upgrade to HTML5 or XHTML5 pages without problems.

Herenvardo




msg:3779449
 8:20 pm on Nov 3, 2008 (gmt 0)

Can you give me an example of an actual RW problem this will cause? HTML offers such limited presentational semantics I can't see how minor changes to an element's "meaning" will affect anyone(?)

I'm wondering how a HTML5-compliant non-visual UA would be supposed to deal with an <i> element in an old document (before HTML5 it should normally be ignored, because it is only presentational, but now HTML5 gives it a meaning...); but the example of these element redefinitions was more of a theorical nature.
If you want a practical example, however, I already gave one in my previous post: the namespace clash between XHTML1 and XMLish HTML5 (formally, the XML Serialization form of HTML 5): as the spec is written now, the element definitions on (X)HTML5 would override XHTML1's ones on that namespace, causing older documents not to match the new content model. This is not an issue when in "tag-soup mode", because the "error-recovery" stuff in the spec boringly deals with this case by case; but when the content is served as XML draconic error handling applies. The spec explicitly requires compliant UAs to treat everything as X/HTML5, ignoring doctypes and similar stuff, so trying to detect if a document is actualy good'old'XHTML1 to parse it as such would be non-compliant (and parsing it as (X)HTML5 would soundly fail on most such cases).
That's exactly what I meant when I said that HTML5 is not only backwards-incompatible at the document level (this is already caused by the fact that elements that were valid in HTML4, such as <b> or <big> is not valid anymore in HTML5); but the spec explicitly forbids backwards compatibility at the implementation level.

Yes, after you've re-written all your content in XHTML2, it's possible to make it work again in current browsers, like it did before. I think this re-writing qualifies as an all-or-nothing, year-zero approach

I guess I should have been clearer about that. What I had in mind was making new XHTML2 documents render in already available browsers; but picking single XHTML2 features and make them work on older documents is also achievable, and exactly by the same means. That's the whole point of XHTML's modularization: you get the modules, then you mix'n'match as you please. So, if instead of carrying over an older feature to the new format you want to step into a new feature from a document in the old format, there you go: instead of taking XHTML2's modules as the base, and replacing with some from XHTML1, just do it the other way around: take XHTML1 and plug in the XHTML2 modules you need. Wanna XForms on XHTML1? Already done by some sites :P Wanna the role attribute? Just import the "Role Attribute Module" into your doctype. Need ruby anotations? Get them. XML had the "fail on error" issue as a cost (for those cases where it is actually an issue; I'm actually quite glad to see at a glance on which line and character my server scripts messed some tag up while I'm debugging), but it bought something with that cost: extensibility ;).

While its great to really be discussing the future of the web, I'd like to first address the history and current status. The future can wait, we still have challenges at the HTML 4 and XHTML 1 levels.

Let's see, the past: we got the browser wars, then HTML3.2, then HTML4 + CSS, then some years of IE's monopoly stagnation until alternate browsers started gaining force, and some work starting behind the scenes by W3C and the WHATWG at the same time, finally leading to the current Babel where there are several browsers to keep in mind, a lot of different standards asking you to do things that and that other way at the same time; and when one whish we could just say "shut up!" to both standards and browsers, we get the W3C embracing WHATWG's work, now there are two more standards competing, both saying that you should stop doing things as you are used to, defining a new markup model that (almost) nobody asked for. Welcome to chaos.
Indeed, we still have challenges at the HTML 4 and XHTML 1 levels; but who are we? The W3C doesn't seem to have challenges of their own, so they've gone ahead and started defining the next XHTML. Browsers definitely have challenges with HTML4, XHTML1, CSS, and even WAI guidelines; but apparently they prefer to ignore them and cover with a [sarcasm]new[/sarcasm] [sarcasm]standard[/sarcasm] with is just a specification (and, by extension, a legitimization and perpetuation) of their actual bugs and issues, spiced up with some trivial meaningless stuff to make it pass as something "new".
Actually, they have put so much effort on that disguise that they have come up with some really good ideas, but we won't be able to really benefit from them because they are buried amongst so much non-sense.

Seriously, what portion of the web is ready for two new languages?

Easy one: none. :P
Webmasters are still battling with basic HTML. As I mentioned in my previous reply, all Windows Web Applications are based on XHTML, what is your proposal for the application developers? Should they stop what they are doing and revert back to HTML 4.01 so they can prepare for HTML 5?

That's not that easy. But what about asking their user to not "upgrade" their browsers, so they can be sure these apps will keep working? I know that this is quite absurd, but it is really the best idea I can suggest.

Ya see how confused one can get?

Yep, I see. Don't worry: it's quite normal, given the situation.

And that is exactly what these two languages do, confuse things even more.

The pity is that, buried deep under the confusion, there are good ideas on both specs. If the WGs were just a bit more willing to listen each other... and to listen someone else...

I'm all for evolving.

I'm too. It's just that I have no idea anymore of where evolution should lead to.
The XHTML2 claims that it's going last call soon; and that most of it already works on current browsers.
OTOH, HTML5 keep claiming that XHTML2 is dead, that HTML5 is going to give you everything, and blah, blah, blah... then one takes a look at their draft and stumbles with stuff like
This API sucks. Seriously. It's a terrible API. Really bad. I hate it.

(Source: HTML5 Working Draft [whatwg.org], as of Nov 03, 2008) :o What's HTML5 providing? APIs that suck?

Look at where we are today.

Ok. I'm looking. But, honestly, I have no idea about where we are :S. If you know, please tell me.
Really, if IE8 finally becomes CSS2 compliant, and replaces its older brothers soon; I have enough with that. Just HTML4/XHTML1 plus CSS2, and server-side scripting for complex stuff, even if it involves some server round-trips. I can live with that. There are things that could be improved, sure, but at which cost? I'm quite a pacifist, and I don't like wars. On wars everybody loses, and this case is no exception. It's a no-win situation:
If XHTML2 overcomes HTML5, we lose all the good stuff in HTML5 (specially the non-markup stuff, which is IMO the best part of the spec, despite it shouldn't belong there)(after all, not all the APIs on that spec suck).
If HTML5 overcomes XHTML2, we lose the good stuff in XHTML2, like a clean content model, clear sectioning and headers (especially the <h> element) or support for decent semantics.

Well, I finally exploded. Sorry for that rant, but I couldn't hold it any longer, and your questions finally triggered it.

nomis5




msg:3779475
 9:07 pm on Nov 3, 2008 (gmt 0)

A view from a simpleton. HTML does all I want, I can't be bothered to even consider XHTML. What does XHTML do that HTML can't and that the average designer needs? One indicator that this thread is for tecchhies only is the sheer length of some of the replies. If anything is that difficult to discuss then forget it is my view. Long live HTML whatever the version is.

mattur




msg:3779489
 9:36 pm on Nov 3, 2008 (gmt 0)

I'm wondering how a HTML5-compliant non-visual UA would be supposed to deal with an <i> element in an old document (before HTML5 it should normally be ignored, because it is only presentational, but now HTML5 gives it a meaning...)

And that meaning is: "a span of text in an alternate voice or mood... whose typical typographic presentation is italicized"

I suspect this isn't going to break the web :)

...picking single XHTML2 features and make them work on older [well-formed XHTML] documents is also achievable, and exactly by the same means.

Emphasis added. But what about namespace clashes eg <input> in XForms and XHTML1 Forms?

XML had the "fail on error" issue as a cost... but it bought something with that cost: extensibility

The problem for XHTML is that extensibility doesn't require "fail on error" as a cost...

Herenvardo




msg:3779519
 10:31 pm on Nov 3, 2008 (gmt 0)

...I suspect this isn't going to break the web

I already admitted it, the <i> element redefinition was a bad example. And still, it will alter how some older documents are handled by some UAs, which steps out of the definition of "backwards-compatibility". Also, I gave you a more practical example on my previous post, which I'm not going to repeat again; and you just ignored it; so I don't think there is any point on keeping discussing this one.

Emphasis added.

Ok. So you see well-formedness as an issue. Actually, it's a feature: a page being well-formed means that the browser can unambiguosly figure out its structure and semantics from the markup (which is needed to ensure that CSS is applied correctly, or that scripts run properly). If you prefer to write non-well-formed documents and let the browsers randomly guess how to deal with them, then don't bother about standards at all: just toss in the elements you want, and if the browser can handle it, it will.
In other words: it is completely irrelevant how much flexibility and/or extensibility a standard (like XML and its derivates) offers, if the document author doesn't care about standards to begin with.

But what about namespace clashes eg <input> in XForms and XHTML1 Forms?

In the event that, for some obscure reason, you really needed to use both XForms and "classic" forms in the same document :o XML provides with several mechanisms to deal with namespace clashes (it was designed with extensibility in mind after all, so it had to somehow deal with this ;)). If you tell me an example of that obscure reason, I can probably suggest you the best approach to solve the clashes for your specific case, but on the general case, an xmlns attribute on each <form> should be enough (unless you really want to mix both form models within a single form, which I don't find too advisable, but still would be syntactically doable).

The problem for XHTML is that extensibility doesn't require "fail on error" as a cost...

Actually, the cost wasn't that big. Currently, almost no browser (if any at all) is 100% compliant with the standards it claims to support, so they could have just decided to skip that part. Actually, I used to use a FF addon to achieve exactly this: when I got an XHTML page crashing due to an XML error, the addon re-feeded it to the parser as "text/html". Actually, any browser could have taken a similar approach: if the XML parsing fails, just show something on the status bar like "This page cannot be rendered according to standards", and allow the user to get a deeper explanation by some means (for example, by clicking on that notice). Why all browsers decided to strictly follow the most controversial characteristic of XML, while ignoring or getting wrong most of the other standards is beyond my knowledge.

mattur




msg:3779568
 12:08 am on Nov 4, 2008 (gmt 0)

I gave you a more practical example [of HTML5 breaking backwards compatibility]

The namespace clash? I must admit I didn't understand your point, but assumed it was basically a theological issue like the <i> and <b> examples :)

So you see well-formedness as an issue

I think well-formedness is an issue with most pages on the web today - especially, but not exclusively, with the HTML ones :)

If you tell me an example of that obscure reason [an XHTML1 form and an XForm on the same page resulting in namespace clashing]

Adding an XForm to a page that has a simple search form in the page header at the top. This is a quite common requirement. <input> is not namespaced in XHTML1 or XForms(?)

Actually, the cost wasn't that big.

The problem with the fail on error cost in XHTML is it falls on the wrong person - the visitor, not the author. The author can be completely unaware of the error for some time - that's the problem.

Actually, I used to use a FF addon to achieve exactly this: when I got an XHTML page crashing due to an XML error, the addon re-feeded it to the parser as "text/html". Actually, any browser could have taken a similar approach: if the XML parsing fails, just show something on the status bar like "This page cannot be rendered according to standards", and allow the user to get a deeper explanation by some means (for example, by clicking on that notice).

Or just use HTML and avoid forcing visitors to deal with problems they a) can't do anything about and b) don't care about anyway.

I don't entirely disagree with your POV on XML. I too think if XHTML had taken off, browsers would have introduced their own error-recovery routines. And then we'd be in exactly the same situation as we are currently with HTML: undefined, non-standard error-recovery in browsers, and lots of non-conformant pages.

This 63 message thread spans 3 pages: 63 ( [1] 2 3 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved