Car Manufacturers and Flash 29.12.05
Why oh why does almost every car manufacturer insist on using Flash on their websites? And not only using Flash, but using it heavily, and without a low-bandwidth version of the site. Do they just assume that if we can’t afford broadband, we can’t afford a new car?Chevrolet.com gets my nod as probably the best car manufacturer website – it’s clean, it loads relatively quickly (even the Flash files), and the HTML is pretty good (they even use definition lists!). This is a website that I actually enjoy using. Ford can go die with its 566 KB homepage, which does nothing that can’t be done in under 100 KB with a few nice images and some clever Javascripting. Seriously, half a megabyte, just for the homepage. Unbelievable. And it’s far from being the worst offender.
While the rest of the world discovers the joys of standards-based web design and lean file sizes, the car manufacturers continue on their trek to annoy the piss out of every person with dial-up, which in America happens to be about half of the population. I think I’ll shop through my credit union website, since the cars are usually cheaper and the site isn’t bloated.
So remember, if you want to make a Flash-heavy website, please make a low-bandwidth version, or better yet don’t even use Flash for any part of the site except for small areas that absolutely need it (e.g., a 360° view of a car’s interior). Save your customers the aggravation, and save your company the bandwidth expenses.
(Boy, am I preaching to the choir or what?)
4 Comments
Blake 29.12.05
Wow, I’m quite impressed with the Chevy site, not even using tables! I tend to be very suprised when I see that from any major commercial websites (why SC design hasn’t had a bigger impact on commercial websites I’ll never completely understand).
Meawhile, I noticed that you’re using HTML 4.0 for this site … why?
:-S
Sage 29.12.05
Ah, there’s a reason for that, but it’ll take a bit to explain.
:-)
First off, we agree that there are no practical differences between well-formed XHTML and HTML, correct? I’d still use semantically-correct tags, make sure they’re closed correctly, no repeating IDs, etc.
So why would someone use XHTML over HTML? The one and only single reason is because true XHTML allows you to use XML, um, what I call plugins. For example, if you need to show complicated math stuff, you’d use MathML in your document, which requires that you use XHTML.
But, if you don’t use XML plugins, then there is no practical difference between XHTML and HTML (and 99.99% of us don’t need those XML plugins).
Now, having said that, there are reasons to not use XHTML. The biggest one is that to get it to show up at all in IE, you have to use the MIME type text/html, which is invalid in the XHTML spec; you’re supposed to send XHTML documents as application/xhtml+xml, but if you try that, IE will just show a blank page.
So, every XHTML document in the world being served to IE is broken, because it’s using an invalid MIME type. That issue doesn’t exist with HTML.
On top of that (it gets worse!), every single major browser out there (IE, Firefox, Safari, Opera…) incorrectly renders XHTML; actually, none of them really render the XHTML documents at all, but instead pretend that they’re HTML documents. For example, <br /> should be rendered by XHTML parsers as <br>>, because /> has a totally different meaning in XHTML than it does in HTML. Thus, if you were to type Hello<br />world in an XHTML document, and it were correctly parsed, it should render as:
Hello
> World
But every major browser maker knows the kind of mess that would make (you’d have greater-than signs all over the place in every single XHTML document in existence), so they’ve purposely broken their parsers to render XHTML as if they were regular HTML documents.
So, on the one hand, if you use HTML, you can’t use XML plugins. That’s the only drawback of HTML, which doesn’t affect most of us anyway. On the other hand, if you use XHTML, you have to use an invalid MIME type, and you’re relying on browsers to purposely render it incorrectly.
That’s why I use HTML, as well as some of the greatest minds in web development. A well-formed, semantically-sound HTML document is more valid and more standards-compliant than any XHTML document.
Blake 30.12.05
Some of that doesn’t make any sense, though.
For example, the self-closing tags are part of the XHTML spec (unless the W3C has lied to me ;-) ) so why would the self closed tags render as >?
Also, self closing tags are not required in HTML, so would you use them?
It all seems a little strange to me that the W3C is preaching about XHTML, meanwhile, you produce a strong argument against it. Albeit with a few points that seem a little contradictory…
Sage 30.12.05
For example, the self-closing tags are part of the XHTML spec (unless the W3C has lied to me ;-) ) so why would the self closed tags render as >?
Aww shit, I had that backwards – XHTML requires the closing slash on empty elements, but HTML forbids it.
Regardless, browsers still don’t render XHTML as XHTML (given the text/html MIME type) – they still render it using the HTML parsing engine. Basically, if you were talking to a child, HTML is like talking at the child’s level (efficient), while XHTML is like talking at an adult level, then having somebody summarize it into words that the child can understand (inefficient). That’s exactly what browsers do – they take your XHTML, and treat it as tag soup. So why write XHTML in the first place, especially with all of these issues?
Also, self closing tags are not required in HTML, so would you use them?
Well, now you know the answer to that, now that I’ve fixed my statement. ;-) No, I wouldn’t use self-closing tags in HTML, since they’re “illegal”. I don’t have too much of a choice with this blog though, since Blogger inserts self-closing tags automatically.
It all seems a little strange to me that the W3C is preaching about XHTML, meanwhile, you produce a strong argument against it.
Well, what you don’t see from the W3C are things like this. Yes, the chair of the W3C HTML Working Group said it himself: Therefore, documents served as
text/html should be treated as HTML and not as XHTML. There should be no
sniffing of text/html documents to see if they are really XHTML.
Also, as you can see from the third link I posted above (Semantic Obsolescence), people are already getting pissed off at the XHTML 2 draft, and right now there’s a movement to ignore the W3C altogether and to follow the lead of the WHAT WG, which has already released a working draft for HTML 5 (see also Anne’s analysis of HTML 5).
Adding to that movement, notice the editor of that draft, Ian Hickson, and notice his employer. There is a very, very good possibility that Google will throw its weight behind HTML 5 and not behind XHTML 2.
