So what you are saying is that it's a really bad thing for Cisco to cover up a problem that can cause that instead of fixing the problem?
If only companies weren't allowed to cover up something like that. Oh wait, employees with consciences could blow the whistle. Oh wait, one did, and then he was threatened with a lawsuit and investigated by the FBI.
Anyone reminded of Adobe vs Skylarov? As soon as he was arrested, Adobe changed their mind and avoided bad publicity by backing off. Now that the FBI are investigating Lynn, Cisco are backing off to avoid bad publicity...
This news story is exactly about that. It is about something o extreme violence being 15 rated, yet something which contains sex, a less (if at all) violent act being 18 rated
RTFA. All the classification board said was that they were forced to revoke the classification, and that without a classification, it couldn't be sold.
The bit about not being able to certify a game as 18+ wasn't a quote, it doesn't say anywhere that the classification board's only option would have been to rate it as 18+, it doesn't say anywhere that the classification board isn't going to review the classification, and it doesn't say anywhere that the classification board can't reinstate the 15+ classification once they have reviewed it.
The idea that it's 18+ content (in the eyes of the classification board) causing the ban is merely something the journalist implied. Haven't you ever seen journalists imply something that isn't true?
Cue the crappy tetris clone that you can sell to kids, which everybody knows can be manipulated to display hardcore pornography.
The fact that you have to modify it is irrelevant. The fact that the hidden content is tame compared with the bits of the game where you set people on fire etc is what is important.
Some feminists believe that it leads to objectification of women that while not criminal or even evidenced by a particular act, indelibly colors a persons attitudes and treatment of women and increases the likelihood of prejudice or violence against women.
Except one of the parts of GTA:SA involves dressing in a gimp outfit so a dominant woman can have her way with you. If anything, that's the opposite of what feminists complain about.
Why is blowing people's heads off considered less serious than sex?
This particular news story isn't about that. The fact is, this game was certified without full knowledge of what was being certified. Now that it's come to light that there is stuff in there that the certification board didn't see, and that many people have a problem with, the current certification is no longer valid until the certification board has had the opportunity to review this content.
As the law stands in various countries, it's illegal to sell something that's uncertified, or at least you need a special license to do so.
It's likely that the certification board will take one look at the content and reinstate the certification, but until that happens (and you know how slow government organisations can act sometimes), the fact is that this game is uncertified and thus is restricted in how it can be sold.
I agree that the general attitude of "violence is bad, but sex is worse" is ridiculous, but I'm not convinced that this is what the "ban" is all about.
Well, that's a valid point but short of requiring every Firefox user to register, how do you reliably gather usage statistics?
You use out-of-band measurements. In other words, you ask people, same as any other survey.
Yeah, it's more difficult than looking at logs. But log numbers are meaningless. It's not good enough to say "well we know these numbers are wildly inaccurate, but they're the best we can be bothered to get, so they'll have to do." If you don't have halfway decent numbers, then the usage statistic you have is [unknown], not [number pulled from ass].
Re:Does it support W3C standards?
on
IE7 Bugs and Reviews
·
· Score: 2, Interesting
I think IE have a problem.
I think WE have a problem.
Virtually no web developer can afford to produce sites that aren't compatible with Internet Explorer 5, 6 and 7. As far as end-users are concerned, it doesn't matter how crappy Internet Explorer 7's rendering engine is, websites will "just work" because us web developers must hide the problems in Internet Explorer 7.
It's a vicious circle. They don't see problems because we hide them. We hide them because Internet Explorer is so popular. Internet Explorer is so popular because they don't see problems.
The only way to break the vicious circle is to start producing websites that don't work in Internet Explorer. Obviously, professional websites can't afford to do this. But hobby websites like weblogs can. Just don't bother working around Internet Explorer's problems, and use Javascript to put a notice at the top of the screen explaining the problem for Internet Explorer users (e.g. "If this website looks screwed up, it's because you are using a broken web browser. _Read more_ on how to fix it.").
Does no one find bitching about a beta a little less than productive?
You've got to consider the context. Microsoft have been saying for a year that "We're committed to standards! Every release of Internet Explorer has improved support for standards." For a year, everyone's been saying "So what are you doing about it? Give us some details!" For a year, they've been saying "We're working on it!" and not giving any details. So now, they release a beta with *three bug fixes*, it's clear that they were just stalling until they could release an unimproved Internet Explorer 7 as a fait accompli.
They're putting some effort into supporting more standards, but seemingly just enough to keep only a few years behind the other browsers.
I wouldn't even go that far. They have fixed two CSS rendering bugs - no improvement in compliance, merely bugfixes where bits of the page disappear. They have fixed the alpha channel in PNG images. There are no other improvements whatsoever to the rendering engine.
If I had to take a guess, I would say that there's zero management support for improving compliance with the specifications, and the developers feel like crap for pissing everybody off, so one or two of them implemented a couple of fixes on their lunch break.
Really - they've been working on Internet Explorer 7 for about a year now - what else could explain the dismal progress? They aren't complete imbeciles.
They made no moral judgments on the definition of "theft".
They didn't make a ruling on it, but they did talk about it, and they made it clear that equating copyright infringement and theft is not correct.
there is the legal definition of "theft", as defined by laws and lawyers and judges and then there's the moral definition of theft.
Morals don't define what words mean. Feel free to repost your comment using some other word in place of "moral", because I can't figure out what you mean when you say "moral definition".
I can see why there should be a rudimentary one that you can download your choice of real browser from. But I can't see why a convicted monopolist (convicted for bundling Internet Explorer no less!) should be allowed to ship something that's intended to compete with real browsers. Microsoft should have been forced to ship a basic web browser with homepage set to Google/Yahoo/some other neutral search engine, without any features like bookmarks, Javascript, etc, and offer Internet Explorer as an optional download at microsoft.com. OEMs could bundle Internet Explorer if they wanted to (not compelled to do as part of their OEM contract with Microsoft).
When would serving XHTML 1.0 as text/html be a bad idea?
One example would be if you have to write web pages in certain languages. RFC 2854 says that you have to follow Appendix C of the XHTML 1.0 specification. Appendix C says that you can't use the XML prolog. XML 1.0 says that if you don't use the XML prolog, then you are restricted to the UTF-8 or UTF-16 character encodings. Compatibility issues make these suboptimal choices for certain languages.
Or are you simply stating that, all things being equal[1], you'd serve XHTML 1.0 as application/xhtml+xml?
I prefer to serve XHTML as text/html, but have it accessible as application/xhtml+xml for testing. Serving application/xhtml+xml means either dropping Internet Explorer support (not feasible for most people), or using content negotiation (which lowers your cache hit rate, increasing load on the server and raising bandwidth bills).
On the other hand, I mostly recommend that people use HTML 4.01 instead of XHTML, because there are a lot of subtle ways in which you can make mistakes with XHTML, and unless you are a specification pedant like me, you won't know about them. Or, as Mark Pilgrim would put it, "Most developers are morons, and the rest are assholes." Until the developer toolsets improve significantly, only the assholes will be able to do XHTML correctly. (You shouldn't read too much into the "morons" bit; it's rhetoric rather than a low opinion).
[1] For example, if MSIE understood what application/xhtml+xml content was.
If Internet Explorer understood it, and associated software (e.g. JAWS and IBM Homepage Reader), then I'd probably just switch over to application/xhtml+xml completely. In fact, I think most people should, since it's so much easier to weed out bugs.
The latest CVS version of Safari renders it properly. The latest beta of iCab renders it properly. And, IIRC, the version of Konqueror in Subversion renders it properly too.
There's no such thing as "Acid2 compliant", browsers don't support it, it's not an acronym, and there aren't any extensions to it. It's a web page. The way you talk, you seem to be under the impression that it's some sort of file format or protocol.
Given that you don't seem to know what Acid2 is and haven't heard of many web browsers, are you really qualified to tell people what browsers do and don't support?
No, they don't. We are talking about an MSDN subscription. What competition is there to that? Who else, besides Microsoft, offers you the opportunity to test in upcoming Microsoft software - something that is an absolute necessity for many organisations?
As far as I am aware, Microsoft has absolutely no competition whatsoever when it comes to MSDN. The existence of competition to Microsoft in other markets does not change this fact in any way.
Yes, everybody was saying that Netscape would make platform-independent applications possible through the web. And then Microsoft destroyed their market by illegally bundling Internet Explorer. And once it had a controlling market share, they held back the web further by refusing to make any improvements to it for four years (actually, it will be four years next month since the last version of Internet Explorer was released).
This document is a Note made available by the World Wide Web Consortium (W3C) for your information. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.
Feel free to ignore it, it's something some W3C members published for guidance, it's certainly not normative, it hasn't gone through the normal W3C publication process involving peer review, and means about as much as a tutorial found on a non-W3C site. Don't let the fact that it appears on the W3C website fool you.
I was mistaken though, it is the DOCTYPE that sends the browser into quirks mode, not the content-type.
Only some doctypes send browsers into quirks mode - some HTML and XHTML doctypes do it, some don't. You can use XHTML without triggering quirks mode just fine.
According to W3C specifications, sending XHTML 1.1 strict as text/html is invalid.
That's not exactly true. It has nothing to do with validity, and it's an IETF specification, although it was co-written by a W3C member. It is against spec to send XHTML 1.1 as text/html, but you can send XHTML 1.0 documents following Appendix C as text/html just fine according to spec.
"Tag soup" originally meant code that was written as if tags were commands, rather than to arrange a document into a tree-like structure, and was usually characterised by mis-nested tags. These days, it's often used as a synonym for "code I don't like".
Sending XHTML 1.0 strict as text/html would make the browser read it as tag soup
No. Sending XHTML 1.0 Strict as text/html makes some browsers process it with the rendering engine they use for tag soup. It does not make XHTML into tag soup. The XHTML continues to be valid, compliant with the XML specification, and perfectly within spec. The fact that some browsers don't treat it as such is irrelevent.
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.
This statement merely says that the thing that caused people to write tag soup (i.e. tags as commands instead of tags defining a tree) is not present in XHTML because of the well-formed requirement of the XML 1.0 specification. It sounds to me as if you are reading more into it.
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.
I'm not sure what that statement means to say, it's very badly written. What does "affected by tag soup" mean? Serving an XHTML document as text/html doesn't leave open a vulnerability where evil tags can come in and corrupt your documents. "Tag soup" is a property of invalid documents, if you write valid XHTML, then there is no tag soup to affect anything.
Ah. You really shouldn't quote Wikipedia, it's not an authoritive source. I've noticed a number of technical errors in the articles there in the past. Refer to the specifications instead.
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
Yes it will. In this particular case we are discussing, it will let you use innerHTML in Gecko-based browsers.
and it may not work the way you expect it to. That is why it is a bad practice.
If you don't know what you are doing, anything is a bad practice. I'm well aware of the differences between HTML and XHTML; in fact I've written several testcases for browsers bugs to help fix XHTML support fairly recently.
You're suggesting a operating system should not come with a Web browser?
No. Read my comment again. I was describing how Windows and applications that run on Windows work. I was not expressing an opinion about what should and shouldn't be bundled with anything.
IE is integral to the platform in the same way Konqueror/KHTML is to KDE. It is part of the standard libraries/components and applications can expect it to be available to view richly formatted data.
This is not true. Applications don't give a damn if Internet Explorer is installed. Applications depend on Trident. Trident is the rendering engine that transforms web pages into something you can see and interact with.
Internet Explorer is nothing but a (pretty poor) shell around Trident. Internet Explorer is simply not necessary for the correct operation of Windows or Windows applications. Trident is. Internet Explorer is an application bundled with Windows.
Of course it's completely fallacious, as going in the KDE print or save dialog, the buttons are NOT always in the same place.
You misread me. I mean they stay in the same place from version to version. I upgraded Firefox once, and when using 'Add Bookmark', the Cancel and Add buttons had swapped places. For quite a while after upgrading, I was losing bookmarks, because I would invariably hit 'Add Bookmark', and hit Cancel without noticing, because it was exactly where Add used to be.
For example, in a save dialog, any user I have seen take more time checking where they save, than their eye do finding the button to save or cancel.
And that's my point.
But it is STILL very slow to click on them. A power user should now better and use the Esc key to cancel, or Enter for the default action (save, print,...) which is focused by default
Firstly, it's only slower if you aren't already using the mouse. If you are typing something and hit a keyboard shortcut, then sure, it's usually quicker to hit escape or whatever, but if you click on something, it's usually quicker to keep clicking.
More importantly, the only GTK+/GNOME applications I use have always had problems with focus in dialogs. That's Firefox, Pan and the GIMP. "Simply hitting enter" doesn't work as far as I can tell. It seems to me the problem got significantly worse going from GTK+ 1.x to 2.x - around the time the usability "improvements" started taking place.
I'm not saying that it is. I'm saying that it is text/html. text/html is a media type that covers a number of different document formats, XHTML happens to be one of them.
I don't see how you can say that you can serve XHTML up as text/html
I'm not trying to look trendy by saying it's not "real" XHTML, but it isn't.
Yes, it is. Labelling it as text/html does not change it from being XHTML. If you labelled it as text/plain, then that would be different, as text/plain only means one thing, plain text. But labelling it as text/html means "this document could be one of a number of different document types, one of them being XHTML".
The fact that Mozilla doesn't choose to apply XHTML rules to XHTML documents served as text/html doesn't change their nature. It's a limitation of Mozilla, and in this particular instance, it means innerHTML works where otherwise, another limitation of Mozilla would prevent it from doing so.
Furthermore, serving up XHTML documents as text/html puts the browser into quirks mode
You are mistaken there, it does no such thing.
I am not sure what the difference is between invalid and malformed - do you mean unsupported tags?
An XML parser cannot "not support" tags. You mean element types. All XML parsers support all tags.
XML parsers are required to throw fatal errors when they encounter malformed documents. Malformed documents are documents that don't follow basic XML syntax - this means things like forgetting a closing tag, or mis-nesting tags. XML parsers are not required to (and generally don't) throw fatal errors when they encounter invalid documents. Invalid documents are documents that don't follow the rules of the particular document type in question. These rules are a superset of the basic XML syntax rules - all malformed documents are invalid, but not all invalid documents are malformed.
One example of a well-formed but invalid document would be an XHTML 1.1 document that used the <font> element type. By following all the XML syntax rules like closing all elements in the right order, the document would be well-formed. But by using an element type not defined for this document type, the document would be invalid. XML parsers would not be required to throw a fatal error when processing this document, and you will find that Mozilla does not.
I know that firefox won't allow you to add innerHTML to an XHTML document.
Mozilla lets you use innerHTML in an XHTML document, so long as it's served as text/html. And ignore the temptation to look trendy by saying it's not "real" XHTML. It's Mozilla's choice to treat it as HTML and not XHTML; it's fully conformant to spec. to serve (some) XHTML documents as text/html and interpret (some) text/html documents as XHTML. XHTML served as text/html is just as real and valid as any other type of XHTML.
I'm sure you know that if you try to load up an invalid XHTML document in Firefox (that is, if you have set the content-type and DTD correctly) it will show up as a parse error.
No, that's malformed XHTML. That's a different thing to invalid XHTML. Invalid XHTML can display just fine in Mozilla, even when you serve it as application/xhtml+xml.
innerHTML is not the way to go for XHTML because XHTML is not HTML and you simply don't want to easily insert something that will break the page.
There's nothing about innerHTML that makes it incompatible with XHTML. Sure, you can call it with text that would produce malformed XHTML, but the browser can just throw an exception in those cases.
I think you missed out a bit of your sample code, but in any case, are you aware of DOM3LS? You can do XML serialisation with that.
Slashdot Mirror
So what you are saying is that it's a really bad thing for Cisco to cover up a problem that can cause that instead of fixing the problem?
If only companies weren't allowed to cover up something like that. Oh wait, employees with consciences could blow the whistle. Oh wait, one did, and then he was threatened with a lawsuit and investigated by the FBI.
Anyone reminded of Adobe vs Skylarov? As soon as he was arrested, Adobe changed their mind and avoided bad publicity by backing off. Now that the FBI are investigating Lynn, Cisco are backing off to avoid bad publicity...
JPEG 2000 is patent encumbered.
This news story is exactly about that. It is about something o extreme violence being 15 rated, yet something which contains sex, a less (if at all) violent act being 18 rated
RTFA. All the classification board said was that they were forced to revoke the classification, and that without a classification, it couldn't be sold.
The bit about not being able to certify a game as 18+ wasn't a quote, it doesn't say anywhere that the classification board's only option would have been to rate it as 18+, it doesn't say anywhere that the classification board isn't going to review the classification, and it doesn't say anywhere that the classification board can't reinstate the 15+ classification once they have reviewed it.
The idea that it's 18+ content (in the eyes of the classification board) causing the ban is merely something the journalist implied. Haven't you ever seen journalists imply something that isn't true?
Cue the crappy tetris clone that you can sell to kids, which everybody knows can be manipulated to display hardcore pornography.
The fact that you have to modify it is irrelevant. The fact that the hidden content is tame compared with the bits of the game where you set people on fire etc is what is important.
Some feminists believe that it leads to objectification of women that while not criminal or even evidenced by a particular act, indelibly colors a persons attitudes and treatment of women and increases the likelihood of prejudice or violence against women.
Except one of the parts of GTA:SA involves dressing in a gimp outfit so a dominant woman can have her way with you. If anything, that's the opposite of what feminists complain about.
Why is blowing people's heads off considered less serious than sex?
This particular news story isn't about that. The fact is, this game was certified without full knowledge of what was being certified. Now that it's come to light that there is stuff in there that the certification board didn't see, and that many people have a problem with, the current certification is no longer valid until the certification board has had the opportunity to review this content.
As the law stands in various countries, it's illegal to sell something that's uncertified, or at least you need a special license to do so.
It's likely that the certification board will take one look at the content and reinstate the certification, but until that happens (and you know how slow government organisations can act sometimes), the fact is that this game is uncertified and thus is restricted in how it can be sold.
I agree that the general attitude of "violence is bad, but sex is worse" is ridiculous, but I'm not convinced that this is what the "ban" is all about.
Well, that's a valid point but short of requiring every Firefox user to register, how do you reliably gather usage statistics?
You use out-of-band measurements. In other words, you ask people, same as any other survey.
Yeah, it's more difficult than looking at logs. But log numbers are meaningless. It's not good enough to say "well we know these numbers are wildly inaccurate, but they're the best we can be bothered to get, so they'll have to do." If you don't have halfway decent numbers, then the usage statistic you have is [unknown], not [number pulled from ass].
I think IE have a problem.
I think WE have a problem.
Virtually no web developer can afford to produce sites that aren't compatible with Internet Explorer 5, 6 and 7. As far as end-users are concerned, it doesn't matter how crappy Internet Explorer 7's rendering engine is, websites will "just work" because us web developers must hide the problems in Internet Explorer 7.
It's a vicious circle. They don't see problems because we hide them. We hide them because Internet Explorer is so popular. Internet Explorer is so popular because they don't see problems.
The only way to break the vicious circle is to start producing websites that don't work in Internet Explorer. Obviously, professional websites can't afford to do this. But hobby websites like weblogs can. Just don't bother working around Internet Explorer's problems, and use Javascript to put a notice at the top of the screen explaining the problem for Internet Explorer users (e.g. "If this website looks screwed up, it's because you are using a broken web browser. _Read more_ on how to fix it.").
Does no one find bitching about a beta a little less than productive?
You've got to consider the context. Microsoft have been saying for a year that "We're committed to standards! Every release of Internet Explorer has improved support for standards." For a year, everyone's been saying "So what are you doing about it? Give us some details!" For a year, they've been saying "We're working on it!" and not giving any details. So now, they release a beta with *three bug fixes*, it's clear that they were just stalling until they could release an unimproved Internet Explorer 7 as a fait accompli.
They're putting some effort into supporting more standards, but seemingly just enough to keep only a few years behind the other browsers.
I wouldn't even go that far. They have fixed two CSS rendering bugs - no improvement in compliance, merely bugfixes where bits of the page disappear. They have fixed the alpha channel in PNG images. There are no other improvements whatsoever to the rendering engine.
If I had to take a guess, I would say that there's zero management support for improving compliance with the specifications, and the developers feel like crap for pissing everybody off, so one or two of them implemented a couple of fixes on their lunch break.
Really - they've been working on Internet Explorer 7 for about a year now - what else could explain the dismal progress? They aren't complete imbeciles.
No mention of hell or portals at all.
That can't be right! They said "every effort was being made to make the movie faithful to the game"! Surely they weren't being dishonest?
They made no moral judgments on the definition of "theft".
They didn't make a ruling on it, but they did talk about it, and they made it clear that equating copyright infringement and theft is not correct.
there is the legal definition of "theft", as defined by laws and lawyers and judges and then there's the moral definition of theft.
Morals don't define what words mean. Feel free to repost your comment using some other word in place of "moral", because I can't figure out what you mean when you say "moral definition".
I can see why there should be a rudimentary one that you can download your choice of real browser from. But I can't see why a convicted monopolist (convicted for bundling Internet Explorer no less!) should be allowed to ship something that's intended to compete with real browsers. Microsoft should have been forced to ship a basic web browser with homepage set to Google/Yahoo/some other neutral search engine, without any features like bookmarks, Javascript, etc, and offer Internet Explorer as an optional download at microsoft.com. OEMs could bundle Internet Explorer if they wanted to (not compelled to do as part of their OEM contract with Microsoft).
When would serving XHTML 1.0 as text/html be a bad idea?
One example would be if you have to write web pages in certain languages. RFC 2854 says that you have to follow Appendix C of the XHTML 1.0 specification. Appendix C says that you can't use the XML prolog. XML 1.0 says that if you don't use the XML prolog, then you are restricted to the UTF-8 or UTF-16 character encodings. Compatibility issues make these suboptimal choices for certain languages.
Or are you simply stating that, all things being equal[1], you'd serve XHTML 1.0 as application/xhtml+xml?
I prefer to serve XHTML as text/html, but have it accessible as application/xhtml+xml for testing. Serving application/xhtml+xml means either dropping Internet Explorer support (not feasible for most people), or using content negotiation (which lowers your cache hit rate, increasing load on the server and raising bandwidth bills).
On the other hand, I mostly recommend that people use HTML 4.01 instead of XHTML, because there are a lot of subtle ways in which you can make mistakes with XHTML, and unless you are a specification pedant like me, you won't know about them. Or, as Mark Pilgrim would put it, "Most developers are morons, and the rest are assholes." Until the developer toolsets improve significantly, only the assholes will be able to do XHTML correctly. (You shouldn't read too much into the "morons" bit; it's rhetoric rather than a low opinion).
[1] For example, if MSIE understood what application/xhtml+xml content was.
If Internet Explorer understood it, and associated software (e.g. JAWS and IBM Homepage Reader), then I'd probably just switch over to application/xhtml+xml completely. In fact, I think most people should, since it's so much easier to weed out bugs.
The latest CVS version of Safari renders it properly. The latest beta of iCab renders it properly. And, IIRC, the version of Konqueror in Subversion renders it properly too.
There's no such thing as "Acid2 compliant", browsers don't support it, it's not an acronym, and there aren't any extensions to it. It's a web page. The way you talk, you seem to be under the impression that it's some sort of file format or protocol.
Given that you don't seem to know what Acid2 is and haven't heard of many web browsers, are you really qualified to tell people what browsers do and don't support?
I want the $35 per year back that I shelled out to Ziff Davis from 89-96. What a ripoff.
You know what they say. Fool me once, shame on you. Fool me twice, shame on me. Fool me for seven years on the trot, get an award of some kind.
Except they do have competition
No, they don't. We are talking about an MSDN subscription. What competition is there to that? Who else, besides Microsoft, offers you the opportunity to test in upcoming Microsoft software - something that is an absolute necessity for many organisations?
As far as I am aware, Microsoft has absolutely no competition whatsoever when it comes to MSDN. The existence of competition to Microsoft in other markets does not change this fact in any way.
Didn't they say this ten years ago?
Yes, everybody was saying that Netscape would make platform-independent applications possible through the web. And then Microsoft destroyed their market by illegally bundling Internet Explorer. And once it had a controlling market share, they held back the web further by refusing to make any improvements to it for four years (actually, it will be four years next month since the last version of Internet Explorer was released).
Take a look here.
Yes, I'm well aware of that note. I quote:
Feel free to ignore it, it's something some W3C members published for guidance, it's certainly not normative, it hasn't gone through the normal W3C publication process involving peer review, and means about as much as a tutorial found on a non-W3C site. Don't let the fact that it appears on the W3C website fool you.
I was mistaken though, it is the DOCTYPE that sends the browser into quirks mode, not the content-type.
Only some doctypes send browsers into quirks mode - some HTML and XHTML doctypes do it, some don't. You can use XHTML without triggering quirks mode just fine.
According to W3C specifications, sending XHTML 1.1 strict as text/html is invalid.
That's not exactly true. It has nothing to do with validity, and it's an IETF specification, although it was co-written by a W3C member. It is against spec to send XHTML 1.1 as text/html, but you can send XHTML 1.0 documents following Appendix C as text/html just fine according to spec.
"Tag soup" originally meant code that was written as if tags were commands, rather than to arrange a document into a tree-like structure, and was usually characterised by mis-nested tags. These days, it's often used as a synonym for "code I don't like".
Sending XHTML 1.0 strict as text/html would make the browser read it as tag soup
No. Sending XHTML 1.0 Strict as text/html makes some browsers process it with the rendering engine they use for tag soup. It does not make XHTML into tag soup. The XHTML continues to be valid, compliant with the XML specification, and perfectly within spec. The fact that some browsers don't treat it as such is irrelevent.
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.
This statement merely says that the thing that caused people to write tag soup (i.e. tags as commands instead of tags defining a tree) is not present in XHTML because of the well-formed requirement of the XML 1.0 specification. It sounds to me as if you are reading more into it.
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.
I'm not sure what that statement means to say, it's very badly written. What does "affected by tag soup" mean? Serving an XHTML document as text/html doesn't leave open a vulnerability where evil tags can come in and corrupt your documents. "Tag soup" is a property of invalid documents, if you write valid XHTML, then there is no tag soup to affect anything.
Source
Ah. You really shouldn't quote Wikipedia, it's not an authoritive source. I've noticed a number of technical errors in the articles there in the past. Refer to the specifications instead.
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
Yes it will. In this particular case we are discussing, it will let you use innerHTML in Gecko-based browsers.
and it may not work the way you expect it to. That is why it is a bad practice.
If you don't know what you are doing, anything is a bad practice. I'm well aware of the differences between HTML and XHTML; in fact I've written several testcases for browsers bugs to help fix XHTML support fairly recently.
I'm saying:
You're suggesting a operating system should not come with a Web browser?
No. Read my comment again. I was describing how Windows and applications that run on Windows work. I was not expressing an opinion about what should and shouldn't be bundled with anything.
This Internet Explorer 7 beta doesn't even comply with the CSS 1.0 specification. That's right, the one published in 1996, nine years ago.
How often do we have to go through this?
Obviously a few more times.
IE is integral to the platform in the same way Konqueror/KHTML is to KDE. It is part of the standard libraries/components and applications can expect it to be available to view richly formatted data.
This is not true. Applications don't give a damn if Internet Explorer is installed. Applications depend on Trident. Trident is the rendering engine that transforms web pages into something you can see and interact with.
Internet Explorer is nothing but a (pretty poor) shell around Trident. Internet Explorer is simply not necessary for the correct operation of Windows or Windows applications. Trident is. Internet Explorer is an application bundled with Windows.
Of course it's completely fallacious, as going in the KDE print or save dialog, the buttons are NOT always in the same place.
You misread me. I mean they stay in the same place from version to version. I upgraded Firefox once, and when using 'Add Bookmark', the Cancel and Add buttons had swapped places. For quite a while after upgrading, I was losing bookmarks, because I would invariably hit 'Add Bookmark', and hit Cancel without noticing, because it was exactly where Add used to be.
For example, in a save dialog, any user I have seen take more time checking where they save, than their eye do finding the button to save or cancel.
And that's my point.
But it is STILL very slow to click on them. A power user should now better and use the Esc key to cancel, or Enter for the default action (save, print, ...) which is focused by default
Firstly, it's only slower if you aren't already using the mouse. If you are typing something and hit a keyboard shortcut, then sure, it's usually quicker to hit escape or whatever, but if you click on something, it's usually quicker to keep clicking.
More importantly, the only GTK+/GNOME applications I use have always had problems with focus in dialogs. That's Firefox, Pan and the GIMP. "Simply hitting enter" doesn't work as far as I can tell. It seems to me the problem got significantly worse going from GTK+ 1.x to 2.x - around the time the usability "improvements" started taking place.
XHTML is not HTML.
I'm not saying that it is. I'm saying that it is text/html. text/html is a media type that covers a number of different document formats, XHTML happens to be one of them.
I don't see how you can say that you can serve XHTML up as text/html
Not me. The text/html specification: RFC 2854.
I'm not trying to look trendy by saying it's not "real" XHTML, but it isn't.
Yes, it is. Labelling it as text/html does not change it from being XHTML. If you labelled it as text/plain, then that would be different, as text/plain only means one thing, plain text. But labelling it as text/html means "this document could be one of a number of different document types, one of them being XHTML".
The fact that Mozilla doesn't choose to apply XHTML rules to XHTML documents served as text/html doesn't change their nature. It's a limitation of Mozilla, and in this particular instance, it means innerHTML works where otherwise, another limitation of Mozilla would prevent it from doing so.
Furthermore, serving up XHTML documents as text/html puts the browser into quirks mode
You are mistaken there, it does no such thing.
I am not sure what the difference is between invalid and malformed - do you mean unsupported tags?
An XML parser cannot "not support" tags. You mean element types. All XML parsers support all tags.
XML parsers are required to throw fatal errors when they encounter malformed documents. Malformed documents are documents that don't follow basic XML syntax - this means things like forgetting a closing tag, or mis-nesting tags. XML parsers are not required to (and generally don't) throw fatal errors when they encounter invalid documents. Invalid documents are documents that don't follow the rules of the particular document type in question. These rules are a superset of the basic XML syntax rules - all malformed documents are invalid, but not all invalid documents are malformed.
One example of a well-formed but invalid document would be an XHTML 1.1 document that used the <font> element type. By following all the XML syntax rules like closing all elements in the right order, the document would be well-formed. But by using an element type not defined for this document type, the document would be invalid. XML parsers would not be required to throw a fatal error when processing this document, and you will find that Mozilla does not.
I know that firefox won't allow you to add innerHTML to an XHTML document.
Mozilla lets you use innerHTML in an XHTML document, so long as it's served as text/html. And ignore the temptation to look trendy by saying it's not "real" XHTML. It's Mozilla's choice to treat it as HTML and not XHTML; it's fully conformant to spec. to serve (some) XHTML documents as text/html and interpret (some) text/html documents as XHTML. XHTML served as text/html is just as real and valid as any other type of XHTML.
I'm sure you know that if you try to load up an invalid XHTML document in Firefox (that is, if you have set the content-type and DTD correctly) it will show up as a parse error.
No, that's malformed XHTML. That's a different thing to invalid XHTML. Invalid XHTML can display just fine in Mozilla, even when you serve it as application/xhtml+xml.
innerHTML is not the way to go for XHTML because XHTML is not HTML and you simply don't want to easily insert something that will break the page.
There's nothing about innerHTML that makes it incompatible with XHTML. Sure, you can call it with text that would produce malformed XHTML, but the browser can just throw an exception in those cases.
I think you missed out a bit of your sample code, but in any case, are you aware of DOM3LS? You can do XML serialisation with that.