Slashdot Mirror

just like you can use any number of proprietary image formats and w3c never recommend a patent-free image format... oh wait .. there was the whole png standard. How many png images where used on the web before it was a recommended? MPEG as a "standard" is irrelevant as long as it remains non-free to implement, since distribution costs are inherently incompatible with free browser distributions. Ogg theora is on the other hand perfectly compatible with being distributed in a proprietary system.

A codec agnostic implementation of the video tag is next to worthless. A simple javaScript library could accomplish the same thing.. Codec agnostic video tag resents no significant difference from the object/embed tags that we already have today. If that approach is taken video will remain a second class web citizen wrapped up in proprietary encapsulations. The whole point of the w3c is to promote/develop interoperable technologies, in the current browser environment non-free implementations are not interoperable. The w3c will be obsoleting themselves if they take the codec agnostic approach.

The drive for codec agnostic video tag is simply an effort to put a proprietary wedge into web video distribution platform. The codec agnostic video lets proprietary technology providers squeeze hugely profitable wedge into the web platform. This represents a new, undesirable, untested and unhealthy direction for the web. We are already well down with the consequence of proprietary video being felt worldwide. road of proprietary web with flash video and its network effect that pushes web technologies into service model more so than other web platforms that are based on open standards such as wikis and blogs that have been mostly distributed. of consequences that is only starting to be felt. So far Adobe/On2 has been very lax in enforcing their proprietary codecs with many sites getting away with using ffmpegs flash video encoding for "free". But we should not give away ownership key portion of the web platform to a single corporation. Its antithetical to what the web platform is and why it has been so successful.

just like you can use any number of proprietary image formats and w3c never recommend a patent-free image format... oh wait .. there was the whole png standard. How many png images where used on the web before it was a recommended? MPEG as a "standard" is irrelevant as long as it remains non-free to implement, since distribution costs are inherently incompatible with free browser distributions. Ogg theora is on the other hand perfectly compatible with being distributed in a proprietary system.

A codec agnostic implementation of the video tag is next to worthless. A simple javaScript library could accomplish the same thing.. Codec agnostic video tag resents no significant difference from the object/embed tags that we already have today. If that approach is taken video will remain a second class web citizen wrapped up in proprietary encapsulations. The whole point of the w3c is to promote/develop interoperable technologies, in the current browser environment non-free implementations are not interoperable. The w3c will be obsoleting themselves if they take the codec agnostic approach.

The drive for codec agnostic video tag is simply an effort to put a proprietary wedge into web video distribution platform. The codec agnostic video lets proprietary technology providers squeeze hugely profitable wedge into the web platform. This represents a new, undesirable, untested and unhealthy direction for the web. We are already well down with the consequence of proprietary video being felt worldwide. road of proprietary web with flash video and its network effect that pushes web technologies into service model more so than other web platforms that are based on open standards such as wikis and blogs that have been mostly distributed. of consequences that is only starting to be felt. So far Adobe/On2 has been very lax in enforcing their proprietary codecs with many sites getting away with using ffmpegs flash video encoding for "free". But we should not give away ownership key portion of the web platform to a single corporation. Its antithetical to what the web platform is and why it has been so successful.

What we still need is to continue moving towards full interoperability. Hopefully having a proper spec will help with that.

Behaviour such as handling of getResponseHeader(header) when no header exists still varies: IE returns null, Fx/Opera return an empty string. If you want to check if a header exists, claiming it is an empty string isn't helpful.

It does suck.

As for the "refreshing[] hard-headed" questions, all I see are questions about performance and silly flitting about with their own buzzwords and pipe dreams about getting rid of real applications in favor of their toys.

Here are some questions:

• Whatever happened to degrading gracefully? If you look at the apps produced by Google, the poster child for "AJAX", you'll see that they took the time to make most or all of the functionality work without JavaScript, without images, without CSS, or with a deranged hodgepodge of those. I don't see others making the same efforts.
• How about semantics, and security? We're getting back into the mess of data intermingled with code. I'm seeing more and more sites out there have a blank page that loads, and then JavaScript that loads the content. Now you have to have scripting enabled for every site you visit. MS Office macros all over again. And forget trying to spider the content without having some sort of bizarre Turing machine debugger to try to get at the real content.
• Yeah, how about mobile devices? If you were doing it right (see above) you wouldn't have to worry about the iPhone or about a special mobile AJAX. It would work fine within the constraints of any device. Google does.
• How do you plan to interact with the local filesystem? Java has an effective sandbox, signed codebases, and granular user permissions (although the latter are kind of sucky). Are users not allowed to retain control over their own data?
• How are users supposed to have any confidence about what you're doing to them? The previous model was good. Users knew when they were sending anything to the server, and if the UA vendors would do their jobs they would also know when they were affecting data. What are users supposed to do now, have wireshark running all the time? Not acceptable.

I'm implementing Web-based applications as of this writing, and I plan to have some dynamic features to simplify some of the UI (such as cascading follow-up questions during user signup). But these will be an optional extra.

These jokers forget that the World Wide Web is a repository for mutual citation of academic-style documents. New stuff is good, just don't break the old stuff.

Every improvement on the Internet has been in the direction of better user controls, decentralization, caching, peer-to-peer, transport tunnels, etc. The AJAX people are swimming against the tide and they need to realize it and shape up.

You need to read what I said. I know this is the world we live in

I didn't say you didn't. Seriously, go back and read the thread, you keep responding to sentences individually and taking them out of the context of the thread. It went like this:

1. Ignorant Aardvark doesn't realise this is how things are.
2. I explain it is, and give lack of JPEG 2000 support in Firefox as an example of that.
3. You misinterpret my mention of that format as a complaint that it isn't supported.
4. I point out you are misinterpreting it and explain that I was correcting Ignorant Aardvark.

I am not trying to explain to you that the world is this way. I was explaining it to Ignorant Aardvark, and you misinterpreted something I said, so I explained why I said it.

W3C *should* specify a required (image/audio/video) format that everyone must support.

But why must this be in the HTML specification? HTML is a markup language, its specification should concern itself with markup, not codecs.

And why should it be the W3C that does this? There are other standards organisations, ones more experienced with video and audio.

Times change and I think the HTML spec should grow with the times.

So you think that anything useful, no matter what it is, should be crammed into one behemoth specification? No. That's ludicrous. It goes against established principles of the web architecture. Specifically, orthogonal abstractions benefit from orthogonal specifications.. I quote:

Experience demonstrates that problems arise where orthogonal concepts occur in a single specification.

http://www.w3.org/2007/08/video/positions/Nokia.pdf

Forgive my ignorance, I've not been following the topic at all, but why would one even consider it a good thing to have specific support for one format -- free-as-in-beer-speech-whathaveyou -- embedded in HTML in the first place? Aside from the usual not very good hippie-mountain-crunch commun/social/altru-istic reasons, especially when there is likely to be an encoding-agnostic means to attempt to embed objects into HTML?

And countering yours:

• From it's inventor:

  Unlike Vorbis and Speex, legitimate best-in-class codecs, Theora's coding quality is obviously poor relative to contemporary competition. This poor performance stems both from implementation and design deficiencies. As a seperate problem, Theora is also poorly integrated with Ogg due to incomplete multiplexing software and documentation on the Ogg side. Without guidance from Xiph.Org, outside development and implementation of Theora-in-Ogg has been chaotic and of low quality.

• It's safe to say that MPEG4 and it's codecs have been more thoroughly researched than Theora. Remember the FOSS mantra: "many eyes make all bugs shallow"? That applies to lots of things, such as many video producers' legal teams checking this stuff out.
• I absolutely, positively promise you that Youtube serves more video than Wikipedia, and they don't stream Theora.
• You're imagining that Theora is equivalent to H.264, etc. It's not. There's no first-mover advantage to it because it's already been overtaken by, well, pretty much everything.
• There's no standard web image format. By convention, most people use GIF and JPG (with a few PNGs sprinkled about for good measure), but that's just the way it happened to work out. I'm not sure why people have this wrong impression, but it's simply not true. Don't believe me? Read the spec yourself. If that isn't clear enough, W3 explicitly states that

  The HTML specification does not prescribe or limit which graphics format you can use.

I'm a huge FOSS buff, but that doesn't mean I have to blindly love everything pushed out the door as "freedom friendly". I don't have anything against Theora except that it's just not very competitive. I wouldn't want to see it as the official video file format any more than I'd want to see ASCII text as the official document file format; both have clear limitations when compared to their competitors.

The W3 made the right choice. As much as I like the idea of Theora, I'm glad we don't have to be saddled with the reality of it.

And countering yours:

• From it's inventor:

  Unlike Vorbis and Speex, legitimate best-in-class codecs, Theora's coding quality is obviously poor relative to contemporary competition. This poor performance stems both from implementation and design deficiencies. As a seperate problem, Theora is also poorly integrated with Ogg due to incomplete multiplexing software and documentation on the Ogg side. Without guidance from Xiph.Org, outside development and implementation of Theora-in-Ogg has been chaotic and of low quality.

• It's safe to say that MPEG4 and it's codecs have been more thoroughly researched than Theora. Remember the FOSS mantra: "many eyes make all bugs shallow"? That applies to lots of things, such as many video producers' legal teams checking this stuff out.
• I absolutely, positively promise you that Youtube serves more video than Wikipedia, and they don't stream Theora.
• You're imagining that Theora is equivalent to H.264, etc. It's not. There's no first-mover advantage to it because it's already been overtaken by, well, pretty much everything.
• There's no standard web image format. By convention, most people use GIF and JPG (with a few PNGs sprinkled about for good measure), but that's just the way it happened to work out. I'm not sure why people have this wrong impression, but it's simply not true. Don't believe me? Read the spec yourself. If that isn't clear enough, W3 explicitly states that

  The HTML specification does not prescribe or limit which graphics format you can use.

I'm a huge FOSS buff, but that doesn't mean I have to blindly love everything pushed out the door as "freedom friendly". I don't have anything against Theora except that it's just not very competitive. I wouldn't want to see it as the official video file format any more than I'd want to see ASCII text as the official document file format; both have clear limitations when compared to their competitors.

The W3 made the right choice. As much as I like the idea of Theora, I'm glad we don't have to be saddled with the reality of it.

It's easier to describe both as failed proprietary technologies that nobody uses ...
For the WC3 to push an obscure format that nobody uses as the baseline of web video of the future is absurd. ...
rhetoric vs reality ...

Thanks :)
And, yes, rofl. I think the best part is that it's in Simplified Chinese.

Fun, it's CSS writing-layout: tb-rl. Except that doesn't seem to exist in the newest CSS3 text draft (it used to exist in previous drafts). Sigh; would have been cool. (I don't blame MS, just the slow progression that is CSS3)

The tag can be replaced by the tag (according to the w3c, I haven't tested browser support for this because I hardly ever need iframe-like stuff), which can be used to embed pretty much anything (even images, so we wouldn't even needed <img>).

Usually the w3c has solutions for all kinds of stuff, but one browser vendor decided to implement the same feature differently, and the rest decided to copy that implementation instead of listening to the w3c (that's why we have the <embed> tag, for instance).

"This module describes multi-column layout in CSS. It builds on the CSS3 Box model module and adds functionality to flow the content of an element into multiple columns."

http://www.w3.org/TR/css3-multicol/

The only way we will evolve on the web is with another bloody tag war.

I agree in general – though fortunately we've learned from last time, and there is more negotiation and less bloody war. One example is CSS animation: the WebKit developers designed and implemented a first draft, and provided it in their nightly builds, and sent a description to the CSS group to get feedback from developers of other browsers and from other people with relevant expertise.

Similarly, Opera proposed a <video> element earlier this year, and released an experimental alpha build with the feature. The HTML5 group developed a specification for it, and significantly extended the functionality based on feedback from relevant people (Apple, Google (YouTube), etc). Now Apple and Mozilla have experimental implementations of the same feature. There has been very little blood (except over the issue of codecs), and it seems a much better model than the old idea of simply releasing features in a new browser version and expecting your competitors to reverse-engineer your implementation. So there is some hope for the future.

I think the native support of SVG in IE is impossible. VML(http://www.w3.org/TR/NOTE-VML) is already there.

I've never understood why people would want a 3 column layout on the web. The web isn't a newspaper. 3 Column layout doesn't work well. I seriously think someone went through the trouble of figuring out what CSS couldn't do (however useless or obscure) and started it as a meme or how weak CSS was. Firefox has x-rounded-corners because it's part of CSS3, and it's not officially supported yet, so they don't want everyone using the actual css rounded corners thinking that it's fully supported. For more information on rounded corners in CSS follow the link.

Isn't Firefox the same way?

In any case, TBODY is part of the HTML 4 spec, so if your doctype was HTML, you don't have much room to complain. http://www.w3.org/TR/html401/struct/tables.html

"The TBODY start tag is always required except when the table contains only one table body and no table head or foot sections. The TBODY end tag may always be safely omitted."

So while TBODY is optional for tables with only one table body, IE just adds it to the DOM anyway, probably for some internal renderer use. This doesn't strike me as particularly incorrect. And IIRC, Firefox does the same thing, but my memory might be fault.

ISO/IEC 15948:2003

I'll incorporate your entire comment by reference--mainly because I absolutely agree with every single sentence, word, and letter of it, to the extent that I've become an instant fan of yours--and further add that ever since I heard of and realized what both Canvas and HTML5 were, I thought one thing in each case: STOP REINVENTING THE FUCKING WHEEL.

We already have a canvas.

We already have XHTML 1.0. The rules there respect XML--which is at least a partial subset of SGML--and force people to actually write something that fits into a grammar, unlike whatever the browsers allow. No need to switch to something that has no consistent foundations in (SG|X)ML. When I read the WHATTF spec (or lack thereof) I almost cried; it's like Kristi Yamaguchi found the perfect plan for landing 4 triple axels* while keeping the rest of the routine in beat with whatever music was in the BG, and then said "You know, that might've been a bad idea, let me do a forward flip slamming my head into the ice instead, those judges will love it!".

The W3C (or what's left of it that's not churning out redundant language after redundant language) needs to grow a pair and revert to XHTML 1.0 and SVG, and HTML5, "Canvas", and WHATWG (I think I might have spelled it wrong above after a fit of trauma-inspired imaginary nausea, sorry) need to be removed from this universe (and any others) by guillotine or Cutey Honey. Hell, forget the guillotine...and the removal...

*No, not a car analogy. It's bad enough that it's a figure-skating one.

Note that robots.txt, favicon.ico and /w3c/p3p have been raised as issues for the W3C Technical Architecture Group:

http://www.w3.org/2001/tag/group/track/issues/36

See Tim B-L's original mail here:

http://lists.w3.org/Archives/Public/www-tag/2003Feb/0093

One can only hope that any new efforts keep this issue in mind (hint: stop polluting *everyone's* namespace!).

Note that robots.txt, favicon.ico and /w3c/p3p have been raised as issues for the W3C Technical Architecture Group:

http://www.w3.org/2001/tag/group/track/issues/36

See Tim B-L's original mail here:

http://lists.w3.org/Archives/Public/www-tag/2003Feb/0093

One can only hope that any new efforts keep this issue in mind (hint: stop polluting *everyone's* namespace!).

It didn't affect normal images - it broke the drawImage function from the HTML 5 <canvas> element API, which is a fairly new feature and is used relatively rarely but actually quite widely (with ~10 independent bug reports in a couple of days).

Still, I agree it's an unacceptable failure of testing, and I should have said that more strongly. Even the most trivial automated testing of that feature would have caught the problem immediately. Looking at the new tests in Firefox 3, there's still only one which incidentally relies on drawImage. (I have several hundred browser-independent canvas test cases, so I guess I should see if they could be incorporated into Mozilla somehow, to avoid a repeat of this problem in this particular area...)

HTML4 has long since been deprecated...

I'm with you on the HTML 5 skepticism, but this is not true.

HTML 4.01 and XHTML 1.0 are parallel, current standards--the two specs were originally released just over a month apart. But given that IE does not support application/xhtml+xml, there are almost no real-world advantages to using XHTML 1.0 instead HTML 4.01.

HTML4 has long since been deprecated...

I'm with you on the HTML 5 skepticism, but this is not true.

HTML 4.01 and XHTML 1.0 are parallel, current standards--the two specs were originally released just over a month apart. But given that IE does not support application/xhtml+xml, there are almost no real-world advantages to using XHTML 1.0 instead HTML 4.01.

Another catch is that the evolving of HTML into XHTML may be with good intentions but the end result is that it's no longer an easy world to work in. That means that HTML still should evolve in it's own right. However there are a few features that I really would like to see in future HTML versions:

• Consistent tag handling where all tags shall have start and stop tagging as XHTML has. It will make things more consistent.
• HTML may keep it's case insensitive tags - that's no big issue.
• Look into a few new input tag types, the ones that exists aren't bad but sometimes there would be benefit from a <select> tag that also allows the user to manually input a value, which is impossible today unless you insert a special component to handle that feature.
• A certification test program for web browsers wouldn't really hurt. There is the Acid2 test and a few others, but a more comprehensive test wouldn't hurt.

Another web feature that needs an overhaul is the scripting. JavaScript is in some ways good, but it's also very bad since it isn't type-safe. It is however a lot better than VBscript which is something that we got for our sins and binds the functionality to the Microsoft world only. So what we have are two solutions; One half-baked, namely JavaScript and one completely sticky and messy, VBScript.

So much for rants and flames...

I believe an HTML like that already exists: HTML 2.0 (1995).

JP

The pixel perfect web that most designers want really was never part of the design. HTML was never intended to get exactly the same result in all browsers.

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.crockford.com%2Fhtml%2F&charset=(detect+automatically)&doctype=Inline&group=0

He doesn't even terminate his own entities correctly.

I like the getElementsByCSSSelector() idea.

I want javascript access to the css parse tree just like with the DOM.

The problem with the government accessibility guidelines is that it sets developers back 10 years in what we can do, and still the webpage will operate very poorly to blind users.

Using Lynx, and command line OS's usually give them the best interface.

I had to write an intranet program for a government agency there is one blind person in the agency.

Are any links on the web truly permanent?

Stupid. Those fonts are primarily meant for TeX-based applications, for example LaTeX. rarely used characters are written with commands that start with backslash, for example: \ldots .

This beta test is limited to the OpenType version of the STIX Fonts. Now that the font designs are complete, we are working to prepare a LaTeX support package for the Type1 version of the STIX Fonts. This package should be ready for beta test before the end of 2007.

Not to split hairs but, technically speaking, the major browser implementations of GET and POST are not broken. There is nothing in the spec about overlaying the response from either into any arbitrary part of a DOM tree specified by an XPATH or XQUERY expression.

I think that it would be easier from a developer perspective here in 2007 to just code some java script than it would be to change something as fundamental as RFC 2616 and to rewrite every web browser in existence to accommodate that.

The pffft made me think you were being sarcastic. But the rest of your post seems to indicate you were serious. So, I hopped over to your site. If that's actually your site, then you shouldn't be offering web design tips.

* Your code doesn't validate, even against a transitional DTD.
* You have javascript, which is against your own principles. And what clunky javascript, I must add. You sniff for user agent strings? Really!? Sheesh.
* You have javascript errors, very unprofessional.
* You have invented HTML elements like CSSCRIPTDICT. Huh? Did you write your own DTD? No, no you didn't.

Not everyone is a web developer. This is fine. But don't criticize developers who choose to use "new" "scary" technology like javascript. Some sites require javascript. Why one earth would site developers want to use nasty evil dirty javascript? Because it's ubiquitous. It's simple. It's reliable. It's useful. And it enhances the user experience. It's not unprofessional just because you don't like it. Grow up. Learn stuff.

But, in the interest of finding merit where it lies...there are some good points you make. Let's have a *real* web developer (me) highlight them.

1) don't force your users to use a certain font size. Use em to specify your fonts.

2) IF your content doesn't require javascript, then don't make your site require it. If your content does require javascript, then know that you will alienate some folks. That said, if everyone coded to the lowest common denominator (folks who, for whatever reason, use a platform that disallows javascript) there would be no ajax. ajax haters aside, ajax is a good thing when used properly. Don't run away from javascript just because a very small amount of people disallow it. Roads are not designed around people who refuse to use horseless carriages, and websites shouldn't be developed around people who refuse to adapt. The web is a product of quickly evolving technology. Before you complain about people making use of said technologies, get off the intarwebs first.

There, the valid points you made have been lifted from the mire that is the rest of your post.

As much as i agree with you html and java are apples and oranges and that boat shipped long ago.

Half the web wouldn't render...

http://validator.w3.org/check?uri=http%3A%2F%2Fslashdot.org%2F&charset=(detect+automatically)&doctype=Inline&group=0

The W3C part is to add semantic information to web pages and other data so that you can use it in multiple applications (like twine, I guess). Right now, data I get from a web page is only good for me to look at, but with semantic markup I could automatically import it into other uses.

An example would be going over my finances at the end of the month. Right now I get either a paper statement, or log into each account, and then copy numbers over to Quicken. This would allow me to set up Quicken to automatically log in to all my accounts, balance my checkbook and generate a report of income and expenses for the month. It sounds good in principle, but I think the devil is in the details.

Ajax is one single function: XMLHttpRequest, a extension to the browser DOM invented by MS. In other words its a propierty hack on the browser API, nothing more.

Do you have a reference for this? As I understand it, the specification was written in a generic way precisely so different languages could implement the exact same interface. If you are referring to this text from the DOM 1 specification:

Vendors can support the DOM as an interface to their proprietary data structures and APIs, and content authors can write to the standard DOM interfaces rather than product-specific APIs, thus increasing interoperability on the Web.

...and this:

The DOM specifies interfaces which may be used to manage XML or HTML documents. It is important to realize that these interfaces are an abstraction - much like "abstract base classes" in C++, they are a means of specifying a way to access and manipulate an application's internal representation of a document. Interfaces do not imply a particular concrete implementation. Each DOM application is free to maintain documents in any convenient representation, as long as the interfaces shown in this specification are supported.

...then what this means is that it shouldn't matter how Microsoft or Mozilla decide to implement their rendering engines, web developers should be able to write to a single, portable interface without worrying about how any one browser implements things. If you look further, it certainly seems like the W3C were aiming for a canonical interface:

As a W3C specification, one important objective for the Document Object Model is to provide a standard programming interface that can be used in a wide variety of environments and applications. The DOM is designed to be used with any programming language.

I also wish these two databases interoperated more.

This can be a sticky issue in software design (i.e. how much support for external systems to include directly in the system). However, it has been my experience that it is better, from a design perspective, to create a standard interface for communications, or use one that has already been defined (W3C Web Services come to mind, but other types are possible) whereby adapters can be built to mediate and facilitate communications between pairs of systems. The use of the adapter pattern creates services which are decoupled from their clients allowing both to vary independently behind their respective interfaces and isolating any changes in the specific adapter(s). This is desirable from a design standpoint, even if it costs some performance (performance alone is almost never a good reason to violate abstraction), because it increases cohesion between components while at the same time reducing and minimizing coupling.

then use a standard HTML anchor tag with the HREF attribute set.

Like this

See CSS2 feature font-size-adjust . It allows you to tell browser about the ratio between the x-height and font-size. From the spec:

For example, the popular font Verdana has an aspect value of 0.58; when Verdana's font size 100 units, its x-height is 58 units. For comparison, Times New Roman has an aspect value of 0.46. Verdana will therefore tend to remain legible at smaller sizes than Times New Roman. Conversely, Verdana will often look 'too big' if substituted for Times New Roman at a chosen size.

The idea is that you provide the ratio for the preferred font and if that is not available, the browser is supposed to scale the replacement font (using the ratio given by font-size-adjust and the ratio available from replacement font's properties) so that it has visually the intended size.

Too bad that CSS2 is not implemented by browsers. The same applies for that new feature you suggested (which results to pretty much similar behavior).

• serif
• sans-serif
• cursive
• fantasy
• monospace

opera 9.23 on Linux seems to get stuck in some kind of Flash von Nueman loop abomination on the slash screen. Lynx at least let me navigate, but the site was so access uncompliatnt all the links were buttons withoul alt comments.
This page is not Valid (no Doctype found)!Result: Failed validation, 50 Errors w3c.org; so much for being HTML Experts.

THAT's EMBARRASSING - And expecting that anybody really would want to look at their HTML code... Only reason may be that they wrote the pages themselves and don't want to stand out as morons when it comes to writing HTML code.

On the other hand - it can also be a marketing trick.

And if the person that reads their HTML is located outside the US what leverage do they have?

Mostly seems to be about "how stupid can one get?"

The world definitely needs more web fonts, but supplying them in small packages by Microsoft (or anyone else for that matter) every ten years is not much of a way to go. The future of web fonts could much more likely lie in technologies like CSS (similar technologies have been supported by some browsers for a long time now, but without proper standardization can never reach the required level of adoption by majority of browsers and users).

there's no reason you shouldn't specify {font-family:calibri,arial,sans-serif}

font-family: Constantia, "Palatino Linotype", "Book Antiqua", Palatino;

They are phenomenal fonts, but there's only one problem - CSS's font fallback support is almost useless.

Please point your blame in a different direction. CSS 2.0 had perfectly good support for this, but no browser vendors implemented it, so it was taken out of CSS 2.1.

no shit This page is not Valid (no Doctype found)!Result: Failed validation, 65 Errors Markup Validation Service
it's a testement to our browsers that the page even renders! Oh I know now, it's like the phone book can't be copyrighted because its just facts, but the wrong numbers are not facts so they are copyrighted, it's ok to copy the correct numbers but not the wrong numbers and its not ok to copy anything from that firm's site vbecause it just wrong!

W3C Validator results