But they were still able to sell the iPhone in France, so I don't think those laws are that strict.
In Belgium, however, there are better laws on this, and the iPhone still isn't officially being sold here. There are shops that sell imported unlocked ones, though, for a hefty price.
Don't worry, Mozilla never was big on Thunderbird, and they dropped it months ago. Its development is now the responsibility of the Mozilla Messaging entity.
There's no mixed namespace support after munging XHTML into HTML 4 either.
Of course not. But since you decided to serve XHTML as HTML, it is implied you already lost that support and don't need it.
Option 3 introduces needless complexity and introduces barriers to later switching to option 1.
Needless complexity? Barriers? Please. You keep the XHTML version locally, and serve HTML to clients. Since you were already serving XHTML as HTML, there are no hurdles to converting XHTML to HTML.
Serving XHTML as HTML is in itself already a barrier, and the most important one.
Indeed it can be a boon to the developer, but it's not an argument for serving XHTML to the client. Use XHTML for your development so you can use those XML parsers, and serve actual, compliant HTML to the client. You know how easy it is.
And I wouldn't say I'm ignoring benefits after serving it, as there are none. There are benefits before, for the developer.
As I mentioned in my previous post, there are downsides to serving XHTML as text/html. No mixed namespace support, for one thing, which is one of the big things XHTML has going for it.
Just because I'm telling people to stop abusing XHTML doesn't mean that I don't know what the real problems are.
No, it shouldn't. It should be sent as application/xhtml+xml. Sending an XHTML page as text/html means the page will be treated as invalid HTML, losing any 'benefits' your page would have had by using XHTML in the first place.
That's all fine and dandy if you Server-Side Includes for your link tags or use PHP to generate your pages. But if you don't, it means changing all the HTML pages you have every time to insert/change/remove those IE conditional HTML comments. In light of that, CSS hacks make more sense.
I guess it was only a matter of time before they started using this signal that mobile phones spread. The first time I was made aware of them was when one of my siblings got a "Welcome to France" text message when we crossed the border. Kind of worrying if you think about it.
I argued yesterday with someone I know on the Internet about exactly this. Said person always leaves his computer on with AIM open to "collect messages". When told this is what e-mail is for, the reply was that e-mail isn't always instantaneous. This is not true unless you're on Hotmail.
To paraphrase: "What if my girlfriend wants to tell me she will be a bit later, and her cell phone's battery is dead?".
He isn't the only one. I used to know someone else with the exact same excuse.
They don't have an AIM account for just that, though, but it's still quite silly.
While the purists are going to argue that valid markup defines the quality of the code on a given website the reality of the real world always tends to rear it's ugly head and debunk that fantasy.
Valid markup is the start of quality code. Invalid markup leads to unpredictable rendering.
They are tools that should be used by a web developer to run through and make sure they can be as close to valid as possible but I am willing to bet that out of the top 100 sites on the internet, the front page of all of them will produce Markup validation errors. The reason is simple: The validation rules are so restrictive that there is no point even worrying about them. It would be impossible to make a working website by being totally loyal to the markup rules.
Total bullshit. It's very much possible to have a working website that validates with the W3 Validator. Anyone who says it's not is most likely too lazy to follow the rules.
Especially with the validator's stupidity in treating & signs in the href attribute of my a elements as the beginning of an entity which it's not!/rant >.>
An ampersand is a special character. Encode it. The validator is right; it's the beginning of an entity. This is no different from programming languages were special characters have to be escaped.
I think if there were a really easy addon to firefox that said "render for the blind" that didn't actually do the screen-reading part of rendering, but did dump all graphics, render things in "order" rather than how they show up visually, etc. there might be more effort made.
If you code your website to web standards, it's as easy as turning off the CSS.
I use SeaMonkey, but I believe in Firefox it's View > Page Style > No style.
The whole original premise of Firefox was that it was lightweight, fast, and actually worked.
That was never the premise. The premise was to have a fast cross-platform web browser with the right set of features. No lean mean light stuff, except for not being too large a download.
Slashdot Mirror
But they were still able to sell the iPhone in France, so I don't think those laws are that strict.
In Belgium, however, there are better laws on this, and the iPhone still isn't officially being sold here. There are shops that sell imported unlocked ones, though, for a hefty price.
I want to browse the web, not complaints. :(
SeaMonkey, of course. :)
I made a Mozilla product name generator a half year back.
Don't worry, Mozilla never was big on Thunderbird, and they dropped it months ago. Its development is now the responsibility of the Mozilla Messaging entity.
Of course not. But since you decided to serve XHTML as HTML, it is implied you already lost that support and don't need it.
Needless complexity? Barriers? Please. You keep the XHTML version locally, and serve HTML to clients. Since you were already serving XHTML as HTML, there are no hurdles to converting XHTML to HTML.
Serving XHTML as HTML is in itself already a barrier, and the most important one.
Indeed it can be a boon to the developer, but it's not an argument for serving XHTML to the client. Use XHTML for your development so you can use those XML parsers, and serve actual, compliant HTML to the client. You know how easy it is.
And I wouldn't say I'm ignoring benefits after serving it, as there are none. There are benefits before, for the developer.
As I mentioned in my previous post, there are downsides to serving XHTML as text/html. No mixed namespace support, for one thing, which is one of the big things XHTML has going for it.
Just because I'm telling people to stop abusing XHTML doesn't mean that I don't know what the real problems are.
This is the first time I hear of this. Where can I find more information about IE's flawed HTTP implementation?
No, it shouldn't. It should be sent as application/xhtml+xml. Sending an XHTML page as text/html means the page will be treated as invalid HTML, losing any 'benefits' your page would have had by using XHTML in the first place.
Sending XHTML as text/html is plain stupid.
Maybe you should use HTML 4.01 Strict instead. There's not much point in using XHTML. http://www.spartanicus.utvinternet.ie/no-xhtml.htm
That's all fine and dandy if you Server-Side Includes for your link tags or use PHP to generate your pages. But if you don't, it means changing all the HTML pages you have every time to insert/change/remove those IE conditional HTML comments. In light of that, CSS hacks make more sense.
Amen, brother/sister!
I guess it was only a matter of time before they started using this signal that mobile phones spread. The first time I was made aware of them was when one of my siblings got a "Welcome to France" text message when we crossed the border. Kind of worrying if you think about it.
That's a good point, thanks. I remember getting an offline message from a buddy on AIM upon signing in months ago, actually.
I argued yesterday with someone I know on the Internet about exactly this. Said person always leaves his computer on with AIM open to "collect messages". When told this is what e-mail is for, the reply was that e-mail isn't always instantaneous. This is not true unless you're on Hotmail.
To paraphrase: "What if my girlfriend wants to tell me she will be a bit later, and her cell phone's battery is dead?".
He isn't the only one. I used to know someone else with the exact same excuse.
They don't have an AIM account for just that, though, but it's still quite silly.
To promote their product?
Silverlight has been released more than a year ago already. They have had quite some time already, especially for a company with massive resources.
Valid markup is the start of quality code. Invalid markup leads to unpredictable rendering.
Total bullshit. It's very much possible to have a working website that validates with the W3 Validator. Anyone who says it's not is most likely too lazy to follow the rules.
An ampersand is a special character. Encode it. The validator is right; it's the beginning of an entity. This is no different from programming languages were special characters have to be escaped.
If you code your website to web standards, it's as easy as turning off the CSS.
I use SeaMonkey, but I believe in Firefox it's View > Page Style > No style.
Nothing wrong with an image link, as long as the alt attribute of the image is filled in and makes the link clear.
"they're" is short for "they are". You meant "their".
HTML is based on SGML, not XML. XHTML is HTML in XML notation.
You mean "laissez-faire".
*ROAR*
Your English class notes must not have sold a lot of copies...
Have they ever done this? I can't think of an example, but then again, I only use their search engine and hear GMail is still in beta.
That was never the premise. The premise was to have a fast cross-platform web browser with the right set of features. No lean mean light stuff, except for not being too large a download.
Source: http://www.mozilla.org/projects/firefox/charter.html
But I get my eyes back, because you misspelled it yourself! Those are two words: "Damn it".