Slashdot Mirror

You may have a look at this:
http://public.web.cern.ch/public/Content/Chapters/ AboutCERN/Achievements/WorldWideWeb/WWW-en.html
among others, includes the link to the proposal of the WWW made at CERN by Tim in 1989:
http://www.w3.org/History/1989/proposal.html
and refined by Robert Cailliau in 1990:
http://www.w3.org/Proposal.html

BTW, noone seems to remember about Robert Cailliau, the co-author of the thing...

The original browser (already including a built-in editor), written by Tim on a NeXT, had a real stupid name: WorldWideWeb.app ;-)

It was later renamed to Nexus.app.

Second, there is this thing known as the W3C validator... and last I checked, it seemed to think that my HTML was valid XHTML 1.0 Strict and my CSS was fine.

Third... well, it runs as it should on Gecko/Spidermonkey, which has a reputation as a fairly standards-compliant browser (albeit a bit permissive in some areas).

If it makes you happy, I'll acknowledge that it's a little difficult to be absolutely sure that the DOM interaction with Javascript is correct and standards-compliant. And I'll be a lot happier when I can get it to work on at least one other renderer+javascript implementation.

What was that? You don't have a working implementation that implements the standards completely and correctly?

Surprisingly enough, no, I don't have my own superstrict web browser to test on. I considered doing that, but thought it might be just a bit too much work. :)

Javascript is [...] not standardized

Elements are nodes in the document tree.

Exactly what I said. Thank you for agreeing with me, Mr. Troll.

No. You said:

"Element" is a generic term for all objects that can be in the document structure.

This is not the same thing as "elements are nodes in the document tree". There's a big difference between "nodes in the document tree" and "objects in the document structure". "All objects that can be in the document structure" include attributes, which are not elements. I even gave that as an example, which you ignored in favour of repeating your point and misrepresenting me as agreeing with you. You also said:

"Tag" is a more specific type of element.

Which is so bone-headed I can't even imagine where you got the idea. Here's some HTML:

<table>
<tr>
<td>Foo</td>
</tr>
</table>

Count the tags. Count the elements.

There are six tags - an opening table tag, an opening tr tag, an opening td tag, and the closing tags that match them.

There are four elements. A table element, a tbody element, a tr element and a td element.

Elements are part of the document structure. Tags are part of the syntax that describes the structure. By confusing tags and elements, you are muddling up two different ideas - syntax and structure.

If tags are a specific type of element, then please explain how it is that there are more tags than elements in the example I gave.

Please, read the HTML specification's explanation of how elements, element types and tags relate to each other. You might find it informative yet embarrassing.

The element is created dynamically. Just WHO do you think would have a handler on it?

You ignored my pre-emptive answer to that. Feel free to go back and read it.

Except that attachEvent is an IE quirk, and addEventListener is not supported by IE

Learn the meaning of the word "and". Or look up Scott Andrew's generic addEvent script.

Backward compatibility is a design principle, not the primary purpose.

See that's funny, because you stated that non-CSS user-agents are "deprecated" (not mentioning by who exactly). The fact that the publishers of the CSS specification take pains in pointing out that non-CSS user-agents should be catered for in multiple places kinda blows that claim out of the water, wouldn't you say?

This is in direct opposition to the HTML concept, which was designed only for screen usage.

"It is required that HTML be a common language between all platforms. This implies no device-specific markup..." That's a quote from the very first HTML specification. If it was designed for screen-only, how come the very specification says that it's intended to be device-independent?

For example, you're ignoring this entire section from your link

WTF are you talking about? It has no bearing on the current discussion, which is why I didn't call attention to it. It certainly doesn't contradict me - where did I say that CSS wasn't device independent?

I've called you a troll. Which you are. Why? Because you initiated an uncalled for attack,

I was correcting you because you clearly don't know what you are talking about.

ignored the complexities of the issues,

Actually, it's you that is completely *unaware* of the complexities of the issues. It's quite obvious to anybody with a grounding in SGML that you are simply making shit up as you go along.

Come on. Admit it. Be the bigger man. You assumed I was just a troll so you misrepresented your uninformed speculation as the truth to shut me up, and now you've been caught with your

Elements are nodes in the document tree.

Exactly what I said. Thank you for agreeing with me, Mr. Troll.

No. You said:

"Element" is a generic term for all objects that can be in the document structure.

This is not the same thing as "elements are nodes in the document tree". There's a big difference between "nodes in the document tree" and "objects in the document structure". "All objects that can be in the document structure" include attributes, which are not elements. I even gave that as an example, which you ignored in favour of repeating your point and misrepresenting me as agreeing with you. You also said:

"Tag" is a more specific type of element.

Which is so bone-headed I can't even imagine where you got the idea. Here's some HTML:

<table>
<tr>
<td>Foo</td>
</tr>
</table>

Count the tags. Count the elements.

There are six tags - an opening table tag, an opening tr tag, an opening td tag, and the closing tags that match them.

There are four elements. A table element, a tbody element, a tr element and a td element.

Elements are part of the document structure. Tags are part of the syntax that describes the structure. By confusing tags and elements, you are muddling up two different ideas - syntax and structure.

If tags are a specific type of element, then please explain how it is that there are more tags than elements in the example I gave.

Please, read the HTML specification's explanation of how elements, element types and tags relate to each other. You might find it informative yet embarrassing.

The element is created dynamically. Just WHO do you think would have a handler on it?

You ignored my pre-emptive answer to that. Feel free to go back and read it.

Except that attachEvent is an IE quirk, and addEventListener is not supported by IE

Learn the meaning of the word "and". Or look up Scott Andrew's generic addEvent script.

Backward compatibility is a design principle, not the primary purpose.

See that's funny, because you stated that non-CSS user-agents are "deprecated" (not mentioning by who exactly). The fact that the publishers of the CSS specification take pains in pointing out that non-CSS user-agents should be catered for in multiple places kinda blows that claim out of the water, wouldn't you say?

This is in direct opposition to the HTML concept, which was designed only for screen usage.

"It is required that HTML be a common language between all platforms. This implies no device-specific markup..." That's a quote from the very first HTML specification. If it was designed for screen-only, how come the very specification says that it's intended to be device-independent?

For example, you're ignoring this entire section from your link

WTF are you talking about? It has no bearing on the current discussion, which is why I didn't call attention to it. It certainly doesn't contradict me - where did I say that CSS wasn't device independent?

I've called you a troll. Which you are. Why? Because you initiated an uncalled for attack,

I was correcting you because you clearly don't know what you are talking about.

ignored the complexities of the issues,

Actually, it's you that is completely *unaware* of the complexities of the issues. It's quite obvious to anybody with a grounding in SGML that you are simply making shit up as you go along.

Come on. Admit it. Be the bigger man. You assumed I was just a troll so you misrepresented your uninformed speculation as the truth to shut me up, and now you've been caught with your

Anyone else find it amusing that these "purist" people haven't even read the official specification?

Those "purists" actually have read the specification, and then they've gone on to read the Note on Media Types which upgrades the lower-case "may" in the XHTML 1.0 spec to an upper-case RFC2119 "MAY" in the case of "compatible" XHTML 1.0 and adds a "SHOULD NOT" for any other XHTML. Of course, that "compatibility" is imposed by fiat, not by any actual compatibility of the XHTML and SGML-based HTML syntaxes. There are actually some important incompatibilities even if all the guidelines in Appendix C of the XHTML 1.0 spec are followed. But I'm sure a "purist" like yourself has read up on that, right?

And I'm not just talking about problems with XHTML's minimized tag syntax conflicting with SGML's SHORTTAG. For an example, consider the example of point 1 in the HTML Compatibility Guidelines. It says, in part:

Remember, however, that when the XML declaration is not included in a document, the document can only use the default character encodings UTF-8 or UTF-16.

Sounds nice, but it's wrong and can actually lead to well-formedness errors which will be detected by strict XML parsers. This is because any text/* media type, when sent with an HTTP Content-Type header which did not include the charset parameter, is defined as being encoded in US-ASCII. So if you write your XHTML in UTF-8 or UTF-16, and follow the recommendation to leave out the XML declaration, then you should expect to see well-formedness errors related to the character encoding of the document. Whoops. For added fun, note that this problem crops up when you send text/xml, too; the only way you can guarantee an assumption of UTF-8 or UTF-16 by the parser is to use application/xml or application/xhtml+xml, because then RFC 3023 will mandate those to be the default encodings.

Trolling, trolling, trolling.
Mr. Troll keeps trolling.
Trolling, trolling, trolling.
Troll On! Yee-ha!

Trolling, trolling, trolling.
Mr. Troll keeps trolling.
Trolling, trolling, trolling.
Troll On! Yee-ha!

Accessibility. Several CSS features will make the Web more accessible to users with disabilities:

* Properties to control font appearance allow authors to eliminate inaccessible bit-mapped text images.
* Positioning properties allow authors to eliminate mark-up tricks (e.g., invisible images) to force layout.
* The semantics of !important rules mean that users with particular presentation requirements can override the author's style sheets.
* The 'inherit' value for all properties improves cascading generality and allows for easier and more consistent style tuning.
* Improved media support, including media groups and the braille, embossed, and tty media types, will allow users and authors to tailor pages to those devices.

Vendor, platform, and device independence. Style sheets enable documents to remain vendor, platform, and device independent. Style sheets themselves are also vendor and platform independent, but CSS 2.1 allows you to target a style sheet for a group of devices (e.g., printers).

Trolling, trolling, trolling.
Mr. Troll keeps trolling.
Trolling, trolling, trolling.
Troll On! Yee-ha!

"Element" is a generic term for all objects that can be in the document structure. "Tag" is a more specific type of element.

Completely and utterly wrong.

Elements are nodes in the document tree. Tags are merely the delimiters that tell the parser where the elements begin and end. Don't believe me though, read the HTML 4.01 specification.

One example of something that fits your definition of "element" but doesn't fit the reality is an attribute. Attributes are objects in the document structure, but they are properties of elements, not elements themselves. And the HTML specification actually says "elements are not tags".

Basically, you are full of shit. Read the specifications. Learn a little about SGML. You are wrong and have resorted to name-calling ("trolly-wolly"? How old are you?) and inventing your own definitions instead of admitting you are wrong.

He is intentionally confusing a document-level click handler with an element level click handler. For the record, the element level click handler does not replace the document level handler.

That whooshing sound is my point sailing over your head.

Simply assigning a handler to the onclick property of an element node overwrites whatever previous handler has already been installed there. This makes your style of code unsuitable for generic scripts. The correct appropach is to use attachEvent and addEventListener. Some discussion of the brokenness of onclick assignment here.

Sure, in some situations it doesn't matter, but why bother with learning two ways of doing it when one way works fine all the time and your way breaks some of the time? Like I said, it's a stupid way of doing things.

If Mr. Troll was a little more educated, he'd know that all non-CSS compliant browsers are deprecated and can no longer be used if one wishes to follow the "standards".

You're just making this shit up as you go along, aren't you? Compatibility with non-CSS user-agents is a design principle of CSS. Again, you are full of shit. Want more? The W3C, which published the CSS specifications, also published WCAG, which states Organize documents so they may be read without style sheets..

I've backed up my argument with links to explanations, hints on where to find more information, and authorative quotations from specifications. You've just blown a lot of hot air and called me names. Who's the real troll?

"Element" is a generic term for all objects that can be in the document structure. "Tag" is a more specific type of element.

Completely and utterly wrong.

Elements are nodes in the document tree. Tags are merely the delimiters that tell the parser where the elements begin and end. Don't believe me though, read the HTML 4.01 specification.

One example of something that fits your definition of "element" but doesn't fit the reality is an attribute. Attributes are objects in the document structure, but they are properties of elements, not elements themselves. And the HTML specification actually says "elements are not tags".

Basically, you are full of shit. Read the specifications. Learn a little about SGML. You are wrong and have resorted to name-calling ("trolly-wolly"? How old are you?) and inventing your own definitions instead of admitting you are wrong.

He is intentionally confusing a document-level click handler with an element level click handler. For the record, the element level click handler does not replace the document level handler.

That whooshing sound is my point sailing over your head.

Simply assigning a handler to the onclick property of an element node overwrites whatever previous handler has already been installed there. This makes your style of code unsuitable for generic scripts. The correct appropach is to use attachEvent and addEventListener. Some discussion of the brokenness of onclick assignment here.

Sure, in some situations it doesn't matter, but why bother with learning two ways of doing it when one way works fine all the time and your way breaks some of the time? Like I said, it's a stupid way of doing things.

If Mr. Troll was a little more educated, he'd know that all non-CSS compliant browsers are deprecated and can no longer be used if one wishes to follow the "standards".

You're just making this shit up as you go along, aren't you? Compatibility with non-CSS user-agents is a design principle of CSS. Again, you are full of shit. Want more? The W3C, which published the CSS specifications, also published WCAG, which states Organize documents so they may be read without style sheets..

I've backed up my argument with links to explanations, hints on where to find more information, and authorative quotations from specifications. You've just blown a lot of hot air and called me names. Who's the real troll?

"Element" is a generic term for all objects that can be in the document structure. "Tag" is a more specific type of element.

Completely and utterly wrong.

Elements are nodes in the document tree. Tags are merely the delimiters that tell the parser where the elements begin and end. Don't believe me though, read the HTML 4.01 specification.

One example of something that fits your definition of "element" but doesn't fit the reality is an attribute. Attributes are objects in the document structure, but they are properties of elements, not elements themselves. And the HTML specification actually says "elements are not tags".

Basically, you are full of shit. Read the specifications. Learn a little about SGML. You are wrong and have resorted to name-calling ("trolly-wolly"? How old are you?) and inventing your own definitions instead of admitting you are wrong.

He is intentionally confusing a document-level click handler with an element level click handler. For the record, the element level click handler does not replace the document level handler.

That whooshing sound is my point sailing over your head.

Simply assigning a handler to the onclick property of an element node overwrites whatever previous handler has already been installed there. This makes your style of code unsuitable for generic scripts. The correct appropach is to use attachEvent and addEventListener. Some discussion of the brokenness of onclick assignment here.

Sure, in some situations it doesn't matter, but why bother with learning two ways of doing it when one way works fine all the time and your way breaks some of the time? Like I said, it's a stupid way of doing things.

If Mr. Troll was a little more educated, he'd know that all non-CSS compliant browsers are deprecated and can no longer be used if one wishes to follow the "standards".

You're just making this shit up as you go along, aren't you? Compatibility with non-CSS user-agents is a design principle of CSS. Again, you are full of shit. Want more? The W3C, which published the CSS specifications, also published WCAG, which states Organize documents so they may be read without style sheets..

I've backed up my argument with links to explanations, hints on where to find more information, and authorative quotations from specifications. You've just blown a lot of hot air and called me names. Who's the real troll?

Ah! A perfect learning example. This, my good Slashdotters, is an example of a troll. Trolls almost always post as AC, and pretend to know their head from their ass when they are really looking to make people mad. Let's pick this one apart, shall we?

FFS. You aren't creating a "tag", you are creating an element. You'd think the function name "createElement" would be a hint.

This is a perfect example of nit-picking, while being completely wrong. "Element" is a generic term for all objects that can be in the document structure. "Tag" is a more specific type of element. Thus the two are interchangable in this situation. But Mr. Troll would rather pick at nits because he can make people mad. Isn't that right Mr. Trolly-wolly?

Your onclick attachment is stupid as well. It overwrites any existing onclick handler, which means you can't use that code in any generic page.

Again, Mr. Trolly-Wolly doesn't know what he's talking about, but professes that he does. He is intentionally confusing a document-level click handler with an element level click handler. For the record, the element level click handler does not replace the document level handler. Document level handlers are BAAAAAD, and should only be used in specific circumstances.

And since we're creating the tag element from scratch, we don't have to worry about any prior events being attached.

That and your "who needs to handle non-CSS user-agents" comment really shows how little your comment is worth.

And again, Mr. Trolly doesn't actually understand this issue, but he feels that he must use it to anger people into submission. If Mr. Troll was a little more educated, he'd know that all non-CSS compliant browsers are deprecated and can no longer be used if one wishes to follow the "standards". CSS is particularly important to small devices and screen readers, which are supposed to use CSS hints for small-screen or aural rendering.

That's it for this edition of "Make the Trolls Look Stupid!" Join us next time when we show you how to get your pet troll to do tricks!

>Yes, I'm a purist like that.

Anyone else find it amusing that these "purist" people haven't even read the official specification? It's clearly stated at http://www.w3.org/TR/xhtml1/ that you are allowed to send XHTML 1.0 (which is what most sites are using) as text/html and they even give you an appendix full of compatibility tips when doing so.

Classes are for CSS behavior, not JavaScript behavior.

I don't know where you picked up that little nuggest of "wisdom", but it's completely wrong.

The class attribute is for grouping disparate elements. This is very useful in both CSS and Javascript, but it is not "for" either. It's a general mechanism - you can use it in custom written shell scripts that work with wget if you like, no Javascript, no CSS, still perfectly fine.

If you are confused about what an element type or attribute is for, consult the specification. It is quite clear in stating that it's for "general purpose processing by user-agents".

While I haven't looked at this example myself, any solution for the web should absolutely support all visitors to the site, including the visually impared.

In the case of blind people, I've become interested in Aural Stylesheets. I need to find a good aural screen reader to start designing with sound in mind, though.

Horrible but perfectly valid

Why this is bad has been covered before...

Tim Berners-Lee talked about it over a year ago, and many other people have covered the reasons why it's bad.

The main reason being that creating top level domain names for specific devices is dumb. Cell phones / mobile devices may be hot shit right now, but what happens in 10 years when every device we own had access to the web... will we get a .toaster tld? what about .fridge or .car?

User agents have content negotiation and identify themselves for a reason. that is what should be used, not the TLD to determine content.

No problem, just go through Coral Cache:
http://validator.w3.org/check?uri=http%3A%2F%2Fsla shdot.org.nyud.net%3A8090%2F

Yes but, they knew enough to block W3C's validator from their site:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .slashdot.org%2F

I guess it depends on what you're calling "correct" HTML. If you're going by the W3C standard, very, very few sites are up to snuff. I worked as my school's web master for a couple of years, and because I had nothing to do, I decided to bring the code up to W3C XHTML standard.

Wow.

That process of rewriting the code to standards was not only a pain in the butt, but it also broke it on IE. This was one of my many aggravations while working at that job (that and traversing the byzantine bureaucracy (cool... alliteration)). Microsoft goes off on their own weird tangents with IE and throws the standard to the wind, while Firefox sticks with it, but at the same time is choking itself because very few sites out there write to standards.

It's amazing how the corporate version of history tends to suplant reality in th public mind.

The first web browser and web server would have been WorldWideWeb, the man who invented the web. http://www.w3.org/People/Berners-Lee/WorldWideWeb. html

The first widely used and popular web server and browser were NCSA httpd http://hoohoo.ncsa.uiuc.edu/ and NCSA mosaic http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/N CSAMosaicHome.html
These were developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana - Champaign, IL, USA.

Many of these people would later go on to build netscape.
Apache is something of a pun, "a patchy web server." Origonally it
was a set of patches for NCSA httpd

"Open Source Software, such as Linux, is attributed with the characteristic of being FREE. To exploit a cliche - free as in speech, as well as free as in beer. "

Let's not start all that again. It looks like MS don't need to beat F/OSS, they just have to wait till the factions destroy each other over the meaning of the word 'free'.

"By restricting access to only those who can afford Microsoft software,"

Don't most PCs come with Windows pre-installed? PCs have gone down in price, but I still wouldn't call them cheap, either.

If you can afford a PC, you can afford Windows.

" you have placed strains on myself and many others who find themselves liberated of the pressures of proprietry software."

Get over yourself. Linux is not a religious cause or a higher plane of existence, it's just a UNIX knock-off with delusions of grandeur and lots of software copied from Windows equivalents. So much for Free Software innovation...

" I implore you to consider the needs of a wide spectrum of PC users, instead of just those who can afford disgustingly overpriced software,"

Wide spectrum of about 10% of computer users? I know this is trying to get a point across, but don't think the recipient of this will not check the facts. Linux and Mac users are a minority. Sad, but true.

"without the need to run _furthur_ software that would likely fail in order to emulate."

Spell checkers. There are enough open source ones, unless you did use one and the bazaar model of development and testing missed the correct spelling of 'further'.

" One possible solution to this is to open the source code up for conversion, and security, by the general population."

Linux and Mac users are not 'general population', asserting something repeatedly does not make it fact.

The general population just want to file a tax return, as far as this software is concerned.

" Either that, or allow a standard protocol for tax returns, so as the general population can code their own software for use with tax returns."

Again, implication of a majority where none exists. You're still in the minority, get over it!

Part of this is a common misconception among the Linux crowd. The general population are not programmers. They don't want or care about source code, they couldn't give a monkey's about software being 'Free' as long as it works and it's easy to install and use.

By the way - usually the Linux mob insist on open standards and standards compliance...

http://validator.w3.org/

Your site is not valid. HTH.

troll! The first cite is just a splash page, the second doesn't have ANY history of Web servers, and the third is a rather self-serving history from CERN.

Check these out:

http://www.w3.org/Security/Faq/wwwsf3.html
http://lists.ibiblio.org/pipermail/internetworkers /2001-January/002462.html
http://www.w3.org/Daemon/User/Admin.html
http://www.bergen.org/ATC/Course/InfoTech/VRML_FAQ .html
http://csc.colstate.edu/summers/NOTES/servers-ch11 .htm
http://roub.net/mtmstitch.cgi?conversation=allaire
http://aolserver-archive.cleverly.com/GNNDEVELOPER -L.LOG9607.txt
http://sirius.itfrontier.co.jp/kb/cf_article.cfm?T YPE=en&ID=12970

troll! The first cite is just a splash page, the second doesn't have ANY history of Web servers, and the third is a rather self-serving history from CERN.

Check these out:

http://www.w3.org/Security/Faq/wwwsf3.html
http://lists.ibiblio.org/pipermail/internetworkers /2001-January/002462.html
http://www.w3.org/Daemon/User/Admin.html
http://www.bergen.org/ATC/Course/InfoTech/VRML_FAQ .html
http://csc.colstate.edu/summers/NOTES/servers-ch11 .htm
http://roub.net/mtmstitch.cgi?conversation=allaire
http://aolserver-archive.cleverly.com/GNNDEVELOPER -L.LOG9607.txt
http://sirius.itfrontier.co.jp/kb/cf_article.cfm?T YPE=en&ID=12970

Perhaps you could explain then why MS and EMWACS are not credited here:

http://www.w3.org/2004/Talks/w3c10-HowItAllStarted / ...or here
http://www.historyoftheinternet.com/chap6.html ...or here
http://www.w3.org/History.html ...or any number of places. Although there is a reference to Httpd.

Perhaps you could explain then why MS and EMWACS are not credited here:

http://www.w3.org/2004/Talks/w3c10-HowItAllStarted / ...or here
http://www.historyoftheinternet.com/chap6.html ...or here
http://www.w3.org/History.html ...or any number of places. Although there is a reference to Httpd.

No, you're not out of the loop, in spite of the cries from the fanboys, FCKeditor is out of the loop. An editor which relies on browser features (and yes, quirky java is a browser feature) is guaranteed to write those pages we all try to avoid: This page best viewed in version abc of browser XYZ

For a standards based editor/browser try Amaya. But even Amaya users complain when it fails to render pages carefully broken to render on browser XYZ.

Microsoft is using an open and robust format (XML) for their office documents
No, they are not. They are using a proprietary XML format to represent electronic forms. The standard way to implement forms in XML is XForms which has been around since 2003.

Does this mean the MS Office 12 implements the XForms standard, or that it embraces and extends it in a proprietary way? If so, what's the advantage for users of MS Office 12 over XForms?

the US, along with its vast military-industrial complex, the Department of Defense and DARPA's investments into pie-in-the-sky technologies, and our massive academic research establishment are what you and the entire fucking world HAS TO THANK for the "internet"

Uh... the World Wide Web was invented at CERN, in Europe (hello Timmy Berners-Lee). So should we make sure the EU keeps total control of all web-related standards?

Your statement of fact is based on what?

As just one example, PlanetLab.org runs an entire network of open proxies.

http://codeen.cs.princeton.edu/

Because I run a web server with a database that everyone wants to "scrape", I see this kind of rogue spider hiding behind proxy servers that don't read robots.txt and try to hide every day.

I now ban every known -open- proxy IP and aggressively gather lists in order to block access.

However I think his claim that ignoring robots.txt as being "illegal" is unfounded. Civil suits are not the same thing as criminal matters.

In the same paragraph in the letter he both says:

"None of HMS's harvesting source code even mentions the ROBOTS file, let alone obeys it." and

"Yet at least one of the authors of the harvesting system did know about it, since the "RequestDistribution.txt" document in the harvester source code actually contains a reference to the W3C standard for ROBOTS.TXT."

Your honor, I would submit that one or the other of those statements is not true.

And robots.txt is -not- a W3C standard. It is a voluntary agreement among web spider authors.

From:
http://www.robotstxt.org/wc/norobots.html

"It is not an official standard backed by a standards body, or owned by any commercial organisation. It is not enforced by anybody, and there no guarantee that all current and future robots will use it. Consider it a common facility the majority of robot authors offer the WWW community to protect WWW server against unwanted accesses by their robots."

If fact, WC3 -explicity- says on their web site that robots.txt is not a compulsary standard:

http://validator.w3.org/docs/checklink#bot

"Note that /robots.txt rules affect only user agents that honor it; it is not a generic method for access control."

If you're going to accuse your employer of illegal activity, you sure better have your facts right.

Have you tried running the results through the W3C's [X]HTML Validator. That's really the only sensible test...

There's a *lot* of scope for compressing that code further...

Also, you SHOULD NOT server XHTML-1.1 as text/html.

Oh, and your CSS doesn't validate.

There's a *lot* of scope for compressing that code further...

Also, you SHOULD NOT server XHTML-1.1 as text/html.

Oh, and your CSS doesn't validate.

Stick with target, but use the XHTML Frameset DTD instead.

All languages are "living" hence they are susceptible of change. That's good and necessary to be able to communicate new things, nevertheless it's fundamentally wrong to simply add to the dictionary whichever sound, onomatopoeia or misheard word that starts being used by many people, because the main purpose of language is to communicate ideas and to do it accurately, if that fails is just like having a buggy script. Language is a form of code for people and we all know what happens when you write a program with mistakes in the code. In my native language (Spanish) there is an organization created to regulate the "accepted" words called "Real Academia Española de la Lengua" they tend to accept just about everything that starts going around (I'm personally against that) but the good thing is they compile all those words, and if you are interested at least you have reference material just like the W3C does to web related programming languages. I don't know if there's a similar organization for English but I guess standards are indeed necessary.

Except that you can do pretty much all the AJAX stuff using a hidden frame instead of XmlHttpRequest.

HTML 4 Strict and XHTML Strict do not include frame or iframe elements, and an object element (the official replacement for iframe) may not act as the target for an a element or for a scripted load. If your client or your boss has specified that the project shall use a Strict DTD and shall work when XMLHttpRequest is not available, then you can't use AJAX.

This is exaclty right. AJAX is built on XmlHttpRequest which is not a W3C standard. It was first implemented by Microsoft in IE 5, then by the Gecko crew in Mozilla 1.0. There is a W3C proposal that is similar, but it is basicaly ex post facto. Apple and Opera adopted XmlHttpRequest basically so their users could use GMail. There are differences in implementation on each of these browsers, so there is definitely no standard.

What's sort of interesting is that Microsoft first introduced this as one of those non-ECMA standards they were popping out left and right in the late 90's. Many people believe these were all designed to hurt Netscape. They didn't really do much with this gem once Netscape had bit the dust. Then Google comes along and resurrects it with GMail making them look like them look like these great innovators, especially compared to Microsoft's Hotmail and Yahoo! Mail. Oh the irony.

While I agree that Microsoft's way leaves much to be desired (primarily because AJAX on IE requires that you leave your browser open to ActiveX insercurities), I'm afraid there isn't really a "correct" way to do it. Your way (testing for the native XMLHttpRequest object, and then falling back to the ActiveX object if necessary) is certainly the best way, however.

IIRC, Mozilla's XMLHttpRequest object was created to mimic the functionality of Microsoft's ActiveX version, and then Safari and Opera (to a certain extent) followed suit. However, the XMLHttpRequest has never been part of ECMAScript (the standard that Javascript is based on) nor the W3C DOM. It has always been an "extension" that Microsoft has foisted upon the world, much like the <marquee> tags and layers we love to hate.

As such, it is inconsistently supported -- particularly in Opera and Safari 1.3/2.0. There are also minor differences (e.g. the number of arguments that the send method accepts) that arise due to the lack of a standard specification.

Fortunately, because of its immense utility in creating modern web-apps, it has become a de-facto standard and thus rather reliable. I would love to eventually see browsers support a standards-based version of AJAX (something like the W3C Level 3 DOM Load and Save specification), but until then, there is no truly "correct" way to do it.

While I agree that Microsoft's way leaves much to be desired (primarily because AJAX on IE requires that you leave your browser open to ActiveX insercurities), I'm afraid there isn't really a "correct" way to do it. Your way (testing for the native XMLHttpRequest object, and then falling back to the ActiveX object if necessary) is certainly the best way, however.

IIRC, Mozilla's XMLHttpRequest object was created to mimic the functionality of Microsoft's ActiveX version, and then Safari and Opera (to a certain extent) followed suit. However, the XMLHttpRequest has never been part of ECMAScript (the standard that Javascript is based on) nor the W3C DOM. It has always been an "extension" that Microsoft has foisted upon the world, much like the <marquee> tags and layers we love to hate.

As such, it is inconsistently supported -- particularly in Opera and Safari 1.3/2.0. There are also minor differences (e.g. the number of arguments that the send method accepts) that arise due to the lack of a standard specification.

Fortunately, because of its immense utility in creating modern web-apps, it has become a de-facto standard and thus rather reliable. I would love to eventually see browsers support a standards-based version of AJAX (something like the W3C Level 3 DOM Load and Save specification), but until then, there is no truly "correct" way to do it.

Please see: http://www.w3.org/Style/css2-updates/REC-CSS2-1998 0512-errata.html

IE7 fixes rendering bugs in CSS styles. It also supports some additional features of CSS2.1. I won't talk about specifics.

Here you go: New Web Developer Features in Deer Park Alpha 1

• CSS
  • CSS3 :only-child
  • CSS3 columns
  • CSS3 overflow-x and overflow-y properties
• A subset of SVG 1.1
• Some scripting and DOM goodies like XML Events
• <canvas> with compatibility for Apple's implementation in mind

Here you go: New Web Developer Features in Deer Park Alpha 1

• CSS
  • CSS3 :only-child
  • CSS3 columns
  • CSS3 overflow-x and overflow-y properties
• A subset of SVG 1.1
• Some scripting and DOM goodies like XML Events
• <canvas> with compatibility for Apple's implementation in mind

Here you go: New Web Developer Features in Deer Park Alpha 1

• CSS
  • CSS3 :only-child
  • CSS3 columns
  • CSS3 overflow-x and overflow-y properties
• A subset of SVG 1.1
• Some scripting and DOM goodies like XML Events
• <canvas> with compatibility for Apple's implementation in mind

Microsoft have recently re-done their entire MSN site in most countries to take advantage of pure xhtml and css..

Not very well though: Validate MSN.

> They used an unusual interface (XMLHTTPRequest) which most
> pre-8 versions didn't support.

A relatively new* JavaScript object, but not an unusual one. XMLHTTPRequest is the only way to write asynchronous JavaScript web apps ("Ajax" and all that hype).

* First supported in the Windows IE 5.0
* Available in Mozilla 1.0 (Netscape 7.0)
* In Safari by 1.2
* Apparently in Opera after 8.0

The W3C's DOM Level-3 defines a non-Microsoft method to do the same thing, but I don't know if any browsers implement it.

Under no circumstances may more than a single concurrent submit process be under way for a particular XForms submission.

Under no circumstances may more than a single concurrent submit process be under way for a particular XForms submission.

1. "Opera is configured by default to identify itself as Internet Explorer' "
Isn't that fraud?

No. Fraud is about using lies for direct financial gain, and requires specific intent. Opera identifies itself as IE for interoperability purposes, something that "modern" tech laws (such as the DMCA) protect.

Plus, the whole point of the www is that it is browser independent. So this is unstandard behavior, and should be shunned(2).

I'm sure Grandma will think it's great that her bank and realtor websites don't work because Opera is taking a stand.

The real blame for this lies first in Netscape (which extended the web in many incompatible ways, but at least worked on every OS) and later in Microsoft (who used Netscape's tactics to sew up the web). If Tim Berners-Lee was dead, I'm sure he'd be rolling in his grave. Instead he's had to settle for being alive and helping correct this nonsense.

Well, according to the W3C you can put any URI in an <a href="...">, not only URLs.