Slashdot Mirror

Because.

why HTML 4 as opposed to XHTML 1 Strict?

One reason was the mistaken deprecation in HTML 4.01 of the value attribute of the li element, which was carried forward into XHTML 1.0. Some would claim that the value element has been superseded by CSS counters, but that's not acceptable for two reasons: First, no widely used web browser supports CSS counters. More importantly, if I want to express that an album's track list starts at 13 (see Follow the Leader by Korn), that's content, not presentation. But if I'm using a Strict DOCTYPE, I can't use deprecated attributes, not even mistakenly deprecated ones such as <li value="13">It's On!</li>.

So why not use XHTML 1.0 Transitional? Others have explained the reasons, but I'll recap: Well over two-thirds of web users still use Microsoft Internet Explorer up to and including version 6 as their primary web browser, and IE up to and including version 6 does not support XHTML. No, Section C is not the answer. Or do you expect every web site owner to develop, test, debug, and deploy a filter that 1. reliably distinguishes between user agents that do support XHTML and those that do not, even when agents send broken Accept: headers, and 2. dynamically translates XHTML to HTML 4 for all IE users? And what about users of two different user agents behind the same caching proxy?

Perhaps you'd prefer hearing it from one of the editors of various CSS specifications, as well as the CSS QA person for both Opera and Mozilla/Firefox? - Sending XHTML as text/html Considered Harmful.

Hixie said it best. Using HTML 4.01 Strict probably makes most purists *happier*.

Here's another article on why XHTML isn't so great.

Oh yes, the very idea of supporting a little used browser like IE! I mean what was he thinking? Is he trying to tell us he has clients that need business or something? *guffaw*

Latest IE still doesn't support XHTML properly.

Ian Hickson agrees with him:

http://www.hixie.ch/advocacy/xhtml

AJAX will work with nearly any major browser off the shelf. poof.

Bzzt. Wrong.

"AJAX" will work with Internet Explorer, Gecko-based browsers, and Apple's Safari, and nothing else, because these are the only browsers to have included implementations of the XMLHTTPRequest object yet.

Oh, your client uses Konqueror? Or a cell phone? Or may ever use a user-agent other than the big three? Now you have to program a second, stripped down, clunky version just for that contingency. Try using the most widely deployed enterprise "AJAX" app out there -- Microsoft's Outlook Web Access -- in IE and then Firefox and you'll see what I mean.

Why does OWE degrade in Firefox? Doesn't "AJAX" work "off the shelf" in all major browsers? Well, the problem is that each of these browsers has their own incompatible implementation of XMLHTTPRequest. So you have to sniff out which browser the client is using and do your "AJAX" according to what it's expecting. (This is because of XMLHTTPRequest's origins as a proprietary IE extension to the browser API.)

Microsoft, naturally, only supports the IE flavor of "AJAX" in OWE. But you're not Microsoft and you probably don't get to dictate browsers like that, so you'll have to code around and cover all of them. If you're using an "AJAX toolkit", you're not seeing all this cruft because it's being hidden under a layer of abstraction; but that doesn't mean it's not there.

Because there is no standardized, according-to-Hoyle way to implement "AJAX", when you use it you do so at the risk of sacrificing something important -- forward compatibility. For some applications that's not a concern, but you might want to think about whether that's true for your app before you run and rewrite the whole thing in "AJAX" just because that's teh new hotness.

(Oh, and have you given thought to what happens when visually-impaired people use your kewl "AJAX" app?)

Long story short, to make effective use of XHTML you have to serve it as "text/html" to the browser, as IE doesn't support its proper MIME type (thanks, Microsoft!). Here's a good summary of the issues surrounding XHTML vs HTML 4.

Personally, I don't mind using XHTML 1.0 as text/html, as although it's not quite "ivory-tower" perfect, it's still IMHO a little cleaner and more elegant. Either way, (X)HTML+CSS still beats the living daylights out of "any-old-HTML + tables".

Take a look here.

Also, take a look here for some information on sending IE into quirks mode. I was mistaken though, it is the DOCTYPE that sends the browser into quirks mode, not the content-type.

According to W3C specifications, sending XHTML 1.1 strict as text/html is invalid. Sending XHTML 1.0 strict as text/html would make the browser read it as tag soup, which is not what you want to do:

"How XHTML affects tag soup

XHTML is a reformulation of the HTML language based on XML. The XML Specification clearly defines what a conforming user agent (such as a web browser) must do when malformed code is encountered. Thus, a browser interpreting a Web page as XHTML will refuse to display the page if it encounters a well-formedness error, ensuring that future XHTML will not be tag soup.

However, XHTML 1.0 states that XHTML may be interpreted by current Web browsers as HTML if it follows a set of compatibility guidelines defined in Appendix C of the XHTML 1.0 Recommendation. At this time, the popular web browser Internet Explorer is unable to interpret XHTML documents as XML, and thus most current XHTML pages are served to browsers as HTML, using the MIME type of "text/html".

Because XHTML 1.0 served to browsers as HTML is parsed as if it were badly-formed HTML, XHTML 1.0 is affected by tag soup in the same way as HTML.

Future versions of XHTML after version 1.0 do not allow the XHTML to be served to browsers as HTML. If implemented according to the recommendation, this should prevent the problem of tag soup once XHTML served as XHTML is supported by all major browsers."

Source

I am not saying that serving up the content as text/html changes it from XHTML to HTML, but it will affect the rendering of the page - and it may not work the way you expect it to. That is why it is a bad practice. The W3C recommends that you serve XHTML documents as they are supposed to be served up: application/xml+xhtml.

Here is also a page that talks about why serving XHTML as text/html is considered harmful.

I'm also not saying that you can't serve up XHTML as text/html, just that it's probably not a good idea, and that it could cause problems later.

Thanks for the explanation of invalid vs. malformed.

CSS2.1 is CSS2.

(Disclosure: I'm one of CSS2.1 editors and I wrote that blog post.)

CSS2.1 is CSS2.

(Disclosure: I'm one of CSS2.1 editors and I wrote that blog post.)

CSS2 *IS* a flawed standard. That's why CSS 2.1 will totally replace it once it's finalized.

What you mean is "CSS 2.0 is a flawed specification".

Please see CSS2.1 is CSS2. In short, "CSS 2.1" is short for "CSS 2, Revision 1".

"Yet, people wear their xhtml compliant gif's like medals of honor."

And most, if not all of those XHTML compliant buttons on websites are incorrect, since they are sending the content as text/html, which is not an XML application, as XHTML was designed for.

If your XHTML isn't being sent as application/xhtml+xml, then it isn't XHTML, period. Yes, I'm a purist like that.

See Sending XHTML as text/html Considered Harmful for more detail on this.

Incidentally, the software I use is on my site:
http://software.hixie.ch/utilities/unix/trains/
Not exactly the prettiest code, but it works. Consider it covered by the GPL if you want to use it.

I checked a few Drupal-based sites and they all seemed to use text/html as their content-type so it seems to be the default in Drupal. AFAIK Sending XHTML as text/html is harmful, so could someone please clarify why is a project as big as Drupal using it?

With proper use of XHTML and CSS any website / web application can be attractive to all prospective users.

Except now you've broken access for the 90 percent who aren't blind and use Microsoft Internet Explorer, which is incompatible with XHTML.

If it can't be made web-based perhaps you need to re-think its complexity? Imagine you're using a curses interface or the lynx browser.

Does Gmail, which uses client-side scripts that poll the server (the so-called "Ajax" method), count as "web based"? Lynx doesn't run client-side scripts.

CSS 2.1 is not yet a w3c recommendation, only a candidate Browsers than conform to it rather than CSS 2.0 are broken.

This is incorrect.

The W3C implemented a change in procedure between the times CSS 2.0 and CSS 2.1 were published. What used to be called recommendations are now only candidate recommendations until they are widely implemented.

Ian Hickson, who is on the CSS working group and employed by Opera, says this:

CSS2.1 is in CR, which is the call for implementations stage. It is appropriate for implementors to implement CSS2.1. It is not a draft.

(Note that CSS2.1 and CSS2 are at the same state in the W3C process -- they are both at the "call for implementations" stage. The difference is that the name of that stage changed between 1998 and 2004. What used to be called "REC" or "Recommendation" is now called "CR" or "Candidate Recommendation". The new stage currently called "Recommendation", which indicates that the specification has reached a very high level of implementation maturity, didn't exist back in 1998.)

CSS2.1 is what CSS implementations should be using as reference if they want to implement CSS level 2.

For the future, you might want to read the article before you cite it, because absolutely nowhere does it specify the degree of IE's support for HTML or XML. You also claim that IE is "fully standards compliant" -- which anyone who has wrestled with CSS2 (a 6 year old standard) will know is plain false.

It is well documented that IE6 does not support XHTML served with the application/xhtml+xml mime-type. You can start here, and Google can help you with the rest.

Great blog post by Ian 'Hixie' Hickson (of mozilla.org, Opera, W3C CSS-WG fame) on making new names for existing technologies
http://ln.hixie.ch/?start=1111339822&count=1

Of course XHTML+CSS has a clear advantage of HTML that contains both content and formatting, but what about HTML+CSS? HTML is still a valid standard, and in most cases I see no clear advantage of XHTML+CSS over plain HTML+CSS--especially since anyone who's using XHTML will serve it as the wrong mimetype if they want some 90% of potential viewers to see it properly, and not serving XML as XML essentially reduces it to the tag soup that is HTML...

Hixie (Ian Hickson) of Mozilla, W3C, and now Opera fame has more on the problems associated with this: http://www.hixie.ch/advocacy/xhtml

Candidate Recommendations aren't what you think they are:

http://ln.hixie.ch/?start=1111107793&count=1

> I'll hand it to PDF for being pretty good, even if the software to use PDF (read AND write) is very expensive

On what planet, exactly, is writing PDFs expensive ? I manage to do this for free all the time with a variety of software packages. I thought everyone else did the same. If not, well, I'm glad to have possibly helped you cut your PDF production expenses ;-)

> I believe a browser should be smart enough to withstand whatever's thrown at it, and if it recieves errored data, to notify the user as such, and move on

Most browsers, when they receive erroneous[*] data, are perfectly able to "withstand" it (actually, they just ignore whatever tags or parameters they can't understand). I suppose you're talking about not rendering the page if it has bugs ? Well, you *can* force a browser to do that (Gecko will do it if you send an application/xhtml+xml MIME type header), but you cannot generalize this beahviour, for the following reasons : (1) the *vast* majority of Web pages out there are invalid (*cough*Slashdot*cough*), and (2) even those who are valid can be rendered invalid by external factors (ad banner code, for instance). And you cannot fail to render much of the Web, at least, if you want to have users, because without a large userbase, you won't be able to push for more standards support (yes, it's quite ironic, I know).

> it is also our fault for not implementing all of the features

It would probably help if the standard was a tad less obscure. Of course, you've a lot of conformance tests out there, but still...

> As Microsoft does have more of the market share, that shouldn't stop people from creating pages that don't work with Internet Explorer

Huh... Yeah, sure. Whatever. I'm sure my customers would be thrilled at the opportunity to break their site for ~80% of their visitors, don't you think so ? Seriously, that's not (yet) possible, the best people can do is make standards-compliant pages that work on most browsers (note I didn't even say "all browsers" because there are differences in CSS rendering between nearly every one of them. *Sigh*).

> If it was anyone's "fault" [...] it's the Web Developers for not using the standards

What about the funny people at Netscape who started the nonstandard tag mania in the first place ? The W3C for not being vocal enough ? I only heard about Web standards fairly recently (a few years). That campaign should have been launched much earlier, *before* the damage (i.e. gazillions of invalid pages all over the Web) was done !

[*] Yes, I'm a grammar Nazi, too. You're out of luck, today *grin*

CSS 2.1 is the current revision of CSS 2, so when someone asks for CSS 2 support, that's what they mean. It is not a draft; it is in the CR (call for implementations) stage. The only thing that may get fixed is errors in the specs. They're waiting for UAs to implement it.

This comes from Ian Hickson (Hixie), someone who actually worked on the specification, so he knows what he's talking about.

Perhaps the inventor of XML just knows that the web browser in use on more than 80 percent of Internet-connected desktop PCs can't read documents in the XML variation of XHTML.

"I just clicked on your link, and you are out of spec. because you serve XHTML as text/html without complying with Appendix C of the XHTML 1.0 recommendation."

MSIE doesn't support XHTML, at all. I know all about the issues with text/html, but this allows the site to function for those using a crippled browser (MSIE).

"Furthermore, your code kicks Internet Explorer and Opera into "quirks mode", where they intentionally go out of spec. in order to cater to non-compliant pages."

That main page was a testing ground for several different ideas I had at the time. It needs to be rewritten anyway, and I'm not surprised it kicks those other browsers into "quirks mode". Shrug. It'll be fixed when I have time to fix it.

"If you are going to claim to be an absolute authority on something, make sure you're doing it right, eh? :)"

Thanks, I always do, and will continue to do so.

Is there any possiblity IE7 will support XHTML 1.0 properly, or XHTML 1.1 at all?

Not that we'd want to rush things - given MS's struggles with XML, actual support for XHTML may be an unfair demand. After all, the XHTML 1.1 standard isn't quite four years old yet. Still, maybe the new IE should at least be able to communicate its ineptitude with XML to the world's webservers. Maybe MS could resource a project team to edit the string that will give the next-generation IE a sane Accept header. (Maybe Steve Jobs would strike back by forming an Apple project team to find out what an Accept header is.)

Is there any possiblity IE7 will support XHTML 1.0 properly, or XHTML 1.1 at all?

Not that we'd want to rush things - given MS's struggles with XML, actual support for XHTML may be an unfair demand. After all, the XHTML 1.1 standard isn't quite four years old yet. Still, maybe the new IE should at least be able to communicate its ineptitude with XML to the world's webservers. Maybe MS could resource a project team to edit the string that will give the next-generation IE a sane Accept header. (Maybe Steve Jobs would strike back by forming an Apple project team to find out what an Accept header is.)

D'oh. I completely posted the wrong link the second paragraph.
It was supposed to be to this site: http://www.hixie.ch/advocacy/xhtml

but last I checked even version 0.70 won't let you start by default using XHTML 1.1 rather than HTML 4.0.

Which web browser with at least 20 percent market share can make sense of conforming XHTML? No, Appendix C is not the answer.

10. Use XHTML Transitional (as no popular web UA supports CSS counters yet, which are necessary for starting lists at any number but 1 in XHTML Strict)

But most importantly:

11. Exclude All IE Users (as no version of Microsoft Internet Explorer understands XHTML semantics, not even with Appendix C)

Are you trying to imply that the thousands of XHTML Strict websites out there produced by web/graphic designers, web developers, bloggers, and those who are supporting the standards are doing something wrong?

Yup. Check out Ian Hickson's "Sending XHTML as text/html Considered Harmful" for a quick primer on what most sites that do XHTML are doing wrong. Check out Evan Goer's list of "X-Philes" for a list of the very few sites which get it right, and his purge of sites from that list for an indication of how easy it is to go wrong even after you've initially gotten it right.

As for HTML generally not producing good markup and being "too loose", I hate to break it to you but XHTML 1.0 and HTML 4.01 are element-for-element identical; the only difference between the two is that one is an SGML application and one is an XML application. And when you serve XHTML 1.0 as "text/html" (e.g., when you do XHTML the way ESPN and others do) you don't gain any of the strictness benefits of XML. And the only thing XHTML 1.1 does on top of that is deprecate a couple more things and add modularization and ruby support, so I'm really not sure where all the "good markup" would come from in a transition to XHTML. Plus there's no reason to believe that serving XHTML 1.1 as "text/html" is conformant, so if you use 1.1 you either break the spec or you shut out IE. Likewise, switching to an XHTML DOCTYPE and using XML syntax doesn't magically confer accessibility on a page; it's just as easy to write a horrid, bloated, table-based images-for-everything page in XHTML as it is in HTML 4.01.

I suspect that you're making a common mistake among people who've just discovered web standards: you're confusing XHTML with good markup and best practices (check out Molly Holzschlag on what standards are and aren't). Anyway, it's quite possible to write beautiful, clean, accessible, semantically rich HTML 4.01 with separation of content from presentation; after all, it's got the same set of tags and attributes as XHTML 1.0, so if you can do it in one you can do it in the other just as easily. And when you consider that serving valid, well-formed XHTML according to the spec can be a nightmare at times, it's no surprise that even "gurus" of the standards world (e.g., Mark Pilgrim, Anne van Kesteren) have gone back to or recommended sticking with HTML 4.01 unless you really need one of the features gained by an XML-based HTML.

And lest you continue to think I'm some sort of skeptic or enemey of web standards, well, every site I've built in the past three years (basically, since I discovered there was such a thing as a "web standard") has been valid, accessible, and CSS-based. I just know from experience that valid markup and stylesheets are one part of the equation, and there are an awful lot of those "best practices" that aren't ever published in a spec from the W3C or anyone else.

They already have a penthouse office, but they all drive a broken lift.

IE and other old browsers handle XHTML just fine, assuming you follow the Compatibility Guidelines.

Those guidelines published by W3C are BS, and here's why. To start with, imagine having to escape scripts like this:

<script type="text/javascript" ><!--//--><![CDATA[//><!--
...
// --><!]]></script>

and styles like this:

<style type="text/css" ><!--/* --><![CDATA[/*><!--*/
...
/* ]]>*/--></style>

Then watch greater-than signs appear all over your documents when rendered with a strictly conforming HTML 4 engine.

Anyone making a new website would be foolish to use HTML 4.01.

I disagree. Consider reading the following article: Sending XHTML as text/html Considered Harmful.

Is that why the W3C site isn't written in HTML 4.01?

Many regularly-updated sections of the W3C's site aren't written in XHTML (e.g., Web Accessibility Initiative).

Is that why people who make build websites for a living (like myself) code XHTML?

Tim Berners-Lee's documents aren't marked up using XHTML.

I suggest you spend some time reading posts made to the comp.infosystems.www.authoring newsgroups, whose contributors include, among others, academics who've marked up their documents properly years before all the blogging designers were polluting the Web with their "guidance".

FYI, Hixie is one of the main Mozilla developers.

Do you like Strict? If so, I have a question for you. What's the Strict way to express a list with five items, whose first item is numbered 6, and whose last item is numbered 10? (<li value="..."> is deprecated.) And what's the Strict equivalent to Transitional's <a target="...">?

And here's why we're not going to see application/xhtml+xml any time soon.

Why you shouldn't use XHTML.

I'll grant that XHTML 1.0 doesn't make clear either way whether its text/html compatibility profile extends to future versions, but will assume it does for a moment. So if you wish to use text/html, you must follow the guidelines of Appendix C of the XHTML 1.0 specification.

Another big one is use of the name attribute as a fragment identifier (C.8 in XHTML 1.0 spec). These are used for such things as anchors within a document. Again, 1.0 Appendix C has a suggestion that one set the id and name attributes together to the same value. And XHTML 1.1 has removed the name attribute from the a and map elements.

However, all of this is moot as the W3C position seems to be that the compatibility profile defined in XHTML 1.0 does not apply to 1.1. There is even a W3C Note on XHTML Media Types which you may find enlightening (as seems to often be the case, the pretty colors near the end are the important parts here).

Furthermore, I'd recommend reading Sending XHTML as text/html Considered Harmful by Ian Hickson.

Sending XHTML as text/html Considered Harmful

Besides which, XHTML 1.1 and 2.0 aren't even vaguely backward-compatible.

That it is the webforms stuff that goes first is not at all surprising, as Hixie isn't very fond of XForms.

Anyway, I think it is pretty straightforward: The guys forming the group didn't want MS on board. It's probably a matter of personal taste, not a big attack intended to bring Goliath down once and for all.

Mozilla has both a "quirks" mode and a "web standards complient" mode; where the rendering changes depending on whether the page in question conforms to the standards.

Personally, I think people place too much emphasis on "web standards"; there is this myth going around that, if a web page is correct XHTML, one doesn't need to test their web page on different browsers. Sorry, nope. First of all, different browsers have different bugs one needs to work around. IE 5.x, for example, is well known for having a broken "CSS" box model. Dillo has a bug where it treats UTF-8 documents as iso-8859-1 pages, even with a <meta http-equiv="Content-Type" content="text/html; charset=utf-8"$gt;. Second of all, MSIE 6.0 is about 90% of the browser market. It can not corrently handle Content-Type: application/xml documents.

some more info

Well it's technically not an error. It's a messy situation. Authors are allowed to send XHTML1.0 as text/html if they follow appendix C of XHTML 1.0 specification. However, user agents must treat anything sent as text/html as if it was tag soup.

So really there is very little point in sending XHTML as text/html.

I go on at length about this in http://www.hixie.ch/advocacy/xhtml

This is incorrect. IE6 does not support XHTML. It only supports HTML. (I've had Microsoft employees explicitly confirm this to me, too.)

Testcases to demonstrate this:

• http://www.hixie.ch/tests/adhoc/xhtml/001.xhtml (sent as application/xhtml+xml)
• http://www.hixie.ch/tests/adhoc/xhtml/001.xml (sent as text/xml)

Testcase to demonstrate that IE doesn't even try to sniff for XHTML:

• http://www.hixie.ch/tests/adhoc/xhtml/002.html (sent as text/html)

(The first two should be green if it supports XHTML. The last one should be green if it doesn't try to sniff for it (which would be the only way to support it if the first two tests fail). In a compliant UA, all three would be green.)

This is incorrect. IE6 does not support XHTML. It only supports HTML. (I've had Microsoft employees explicitly confirm this to me, too.)

Testcases to demonstrate this:

• http://www.hixie.ch/tests/adhoc/xhtml/001.xhtml (sent as application/xhtml+xml)
• http://www.hixie.ch/tests/adhoc/xhtml/001.xml (sent as text/xml)

Testcase to demonstrate that IE doesn't even try to sniff for XHTML:

• http://www.hixie.ch/tests/adhoc/xhtml/002.html (sent as text/html)

(The first two should be green if it supports XHTML. The last one should be green if it doesn't try to sniff for it (which would be the only way to support it if the first two tests fail). In a compliant UA, all three would be green.)

This is incorrect. IE6 does not support XHTML. It only supports HTML. (I've had Microsoft employees explicitly confirm this to me, too.)

Testcases to demonstrate this:

• http://www.hixie.ch/tests/adhoc/xhtml/001.xhtml (sent as application/xhtml+xml)
• http://www.hixie.ch/tests/adhoc/xhtml/001.xml (sent as text/xml)

Testcase to demonstrate that IE doesn't even try to sniff for XHTML:

• http://www.hixie.ch/tests/adhoc/xhtml/002.html (sent as text/html)

(The first two should be green if it supports XHTML. The last one should be green if it doesn't try to sniff for it (which would be the only way to support it if the first two tests fail). In a compliant UA, all three would be green.)

Ian Hickson mentions other crappy things about SVG in his blog (which I'll be nice and not link to from /. - learn to google)

Link right here.

If this stuff was implemented in SVG it would be cool, but unfortunatly SVG has become too unweildy... The latest draft of the spec has support for SOCKETS?!??! WTF???!?!?! you don't need that! SVG should remain a presentational language. Stick to graphics and leave the rest to other protocols/components. There's a good post on this here (I think she's an Opera developer but I'm not sure)

Currently the SVG spec is 719 pages long... TWICE THAT OF CSS 2.1... and alot of browsers don't even have support for that yet. Not to mention that SVG doesn't even have decent support for more than one line of text even.

all I can say is K.I.S.S

Cam

1.3. Relationship to XForms

This specification is in no way aimed at replacing XForms 1.0 [XForms], nor is it a subset of XForms 1.0.

XForms 1.0 is well suited for describing business logic and data constraints. Unfortunately, due to its requirements on technologies not widely supported by Web browsers, it has not been widely implemented by those browsers itself. This specification aims to simplify the task of transforming XForms 1.0 systems into documents that can be rendered on every day Web browsers.

1.3. Relationship to XForms

This specification is in no way aimed at replacing XForms 1.0 [XForms], nor is it a subset of XForms 1.0.

XForms 1.0 is well suited for describing business logic and data constraints. Unfortunately, due to its requirements on technologies not widely supported by Web browsers, it has not been widely implemented by those browsers itself. This specification aims to simplify the task of transforming XForms 1.0 systems into documents that can be rendered on every day Web browsers.

Follow the links to Hixie's Web Forms 2 proposal -- which extends HTML forms to include things like date controls and built-in validation. Oh, could we get this? please please pretty-please It would eliminate a ton of the cost assocaited with HTML apps and some of the pushback towards thicker clients.

Just from the outside, it seems like the W3C is whack -- the next-gen tech they are pushing: XHTML2, XForms, RDF, etc is overly complex, not backwards compatible, and doesn't seem to have much of a constituency. It all lacks the easy/sloppy angle that made HTML so popular in the first place. When faced with the choice next-gen tech, it will be a lot easier for devs to pick up MS XAML than XForms.

What we really want is improvements on the core tech of HTML/CSS/etc, not something grandiose and new. The web seems to have stangated around HTML4 and CSS1. If 'they' continue to improve the browser experience, stuff like XAML will stay in the java applet niche.