Slashdot Mirror

So I'm running FF3.6.9 and click on the first of the video tests, which they claim they got "no result" for in both FF 3 and 4.

It seems to pass just fine, and matches their example image.

This makes me wonder if anybody even bothered to check the results.

<link rel="author" title="Microsoft" href="http://www.microsoft.com/" />

Check the source for yourself: http://test.w3.org/html/tests/harness/harness.htm

On one hand, Microsoft managed to produce an excellent product that's almost fully compatible with the latest standards.

Well, at leat "almost fully compatible with" the elements of the standard covered by the first set of tests included in the conformance test suite.

Which tests were submitted to the W3C by...guess who?

(hint: see here.)

IE 9 is currently the most HTML5 compatible browser - but are they only testing the new HTML5 features?

From the coverage of the tests, they seem to be pretty close to the features that were tested in Microsoft's own compliance tests, which were then submitted to the W3C for inclusion in the W3Cs test suite.

To highlight this: see here.

Notice that the only directory here is "Microsoft"?

...according to the test developers.

According to wired:

Run IE9 against other aspects of HTML5 and the browser would be decidedly behind its competitors. IE9 lacks support for Web Workers, drag-and-drop features, SVG animations and the File API, all of which are vital components for building useful web applications, and all of which enjoy considerable support in other browsers.

I stopped clicking through the tests one-by-one when I came across one that would have been fixed by a simple “if (x1 == x2 && y1 == y2) return;”. I went ahead and scrolled down the list, though... for some reason a lot of the tests near the bottom read “No Result” for many/most browsers, and clicking a test at random (canvas(2d.transformation.scale..zero.html)) that said “No Result” in every column except Safari gave me a 404 error.

I’m not terribly impressed.

You need a limitation on space.

Which localStorage has, as I understand the spec. As it stands now, user agents SHOULD allocate 5 MB per origin until the user raises or lowers it.

You need very carefully defined sharing, so sites can federate.

A cross-document message broker running as a script in one document can very carefully define how other documents can interact with an origin's store.

You probably need enforcement of https.

Right now HTTPS requires a static IP and a certificate. More widespread HTTPS would need more widespread deployment of DNSSEC and either IPv6 or client operating systems supporting SNI.

You need a limitation on space.

Which localStorage has, as I understand the spec. As it stands now, user agents SHOULD allocate 5 MB per origin until the user raises or lowers it.

You need very carefully defined sharing, so sites can federate.

A cross-document message broker running as a script in one document can very carefully define how other documents can interact with an origin's store.

You probably need enforcement of https.

Right now HTTPS requires a static IP and a certificate. More widespread HTTPS would need more widespread deployment of DNSSEC and either IPv6 or client operating systems supporting SNI.

Everyone wants to blame Microsoft for everything, the real blame is on the standards bodies.

I don't think so at all.

Berners-Lee's original draft for HTML appeared under the auspices of the IETF in 1993. By the end of 1995, HTML was already at version 2.0. The first W3C "recommendation," HTML 3.2, was released in January of 1997.

ASP 1.0 was released in December of 1996. PHP 1.0 had existed since June of 1995, and people were already writing web applications in existing languages like Perl before then. PHP 2.0 was released in November of 1997; I remember writing some PostgreSQL-backed applications in that language soon thereafter. This whole "there wasn't any alternative to Microsoft" perspective on early web application development that I've seen here recently on Slashdot has no basis in reality. If anything, the array of free tools and the pace of their development quickly surpassed anything Microsoft had to offer.

I also don't think you can exempt Microsoft from blame for whatever delays you might think took place in the W3C standards meetings either. After all, Microsoft had, and still has, a seat at the W3C table. At the time they wanted nothing to do with a standards-based Internet. This history of HTML at the W3C site makes for interesting reading about that early period. (Microsoft isn't the only guilty party here, of course. The first HTML "Editorial Review Board," set up when the more open IETF working group failed to reach a consensus, included representatives from IBM, Microsoft, Netscape, Novell, and the W3 Consortium. One outcome of these head-to-head negotiations was Microsoft trading away the MARQUEE tag in return for Netscape giving up BLINK!)

Privacy on the web: FOAF+SSL on a private server.

Well, this sure is a clever way to push their tag video and audio codecs. If only everyone would invent something cool to get their formats accepted.

These are no more "their" (Mozilla's) formats than they are Apple's, Microsoft's, Google's or Opera's. These are openly documented and patent-free (as far as anyone knows) formats that can (and should) be used anywhere that handles audio and video to ensure interoperability.

Hopefully the W3C can pick up some speed on the Device API so that there is a formalized way for other browsers to do this kind of thing. Access to local devices like webcams is important because even though not all of us may share an interest in services that could make use of it, it is another step in weaning the web off Flash.

Well if it's just plain text they could open the file in an editor, highlight the text, and use copy/paste to drop it in a textarea field in an HTML form.

So let's make the problem harder. How would I have enabled uploading of a binary object in 2001? I'd do the same thing I do today; use "forms-based file uploading."

RFC 1867 defining "forms-based file uploads" appeared in 1995, some months before Berners-Lee and company released RFC 1945 proposing HTTP 1.0. HTML 3.2 (1997) defined the "file" input type that Web applications use for file uploads. That element is usually displayed as a text box into which a file path can be entered, along with a "Browse" button that opens the local file browser.

Of course, there were many other ways to upload a file to a web server by 2001. I wrote a PHP-based application for a legal foundation that enabled subscribed attorneys to share documents in an online archive. Members could register a document online. They'd then receive a mail message to which they would reply after attaching the file. The message included a unique code that so the file could be matched to the registration entry in the database. This worked especially well with people on services like AOL whose interfaces at the time were not friendly to RFC-1867 uploads. (Nowadays I'd probably use either WEBDAV or dspace depending on how much structure I'd need.)

Sometimes I'd use Samba to export directories from a Linux application server to the Windows desktops. Then staff members could simply drop HTML files into pre-determined folders and have them appear within the context of the website. Nowadays, though, I handle pretty much all the content editing on the browser side with forms and TinyMCE. That way I get reasonably clean HTML code as opposed to what you get from someone copying and pasting from Word into a text box.

I wouldn't have thought uploading files was a key obstacle in the way of platform-independent development in 2001. Surely there must have been some bigger roadblocks.

If you're talking about an application that periodically collects files from a Windows workstation, in 2001 I'd have used an automated shell script running smbclient to connect to the workstation using SMB/Netbios and collect the file(s). What happens next depends on the application. I often run PHP scripts from the command line to process text files because I know it well, because of the enormous array of functions it offers, and, frankly, because I've always found Perl's syntax rather intimidating. grep, sed, and awk go a long way, too. Automatically manipulate a graphic image? ImageMagick.

after all, a user/browser is simply requesting the info - the site (which is under their control) is then giving it to them. There's no copying here, except what they implicitly permit by their own actions.

Good point. They need to read up a little bit on http return code 402.

That's why I suggested this years ago:
http://lists.w3.org/Archives/Public/www-html/2002May/0021.html
http://www.mail-archive.com/mozilla-security@mozilla.org/msg01448.html

I think mozilla are finally trying to do something about it:
https://developer.mozilla.org/en/Security/CSP

But after so many years, worms and exploits...

Until Windows Internet Explorer gains support for new HTML5 technologies allowing a web application to work offline (localStorage and CACHE MANIFEST), very few web applications will have a useful offline mode. This means it'll cost an extra $59.99 per month for mobile broadband to get anything done on a laptop on the bus ride to and from work, the mall, etc.

Until Windows Internet Explorer gains support for new HTML5 technologies allowing a web application to work offline (localStorage and CACHE MANIFEST), very few web applications will have a useful offline mode. This means it'll cost an extra $59.99 per month for mobile broadband to get anything done on a laptop on the bus ride to and from work, the mall, etc.

I wrote a blog entry on this subject for those who are interested: http://www.w3.org/QA/2010/10/html5_the_jewel_in_the_open_we.html -- Philippe Le Hegaret

The article is nonsense. Every privacy problem mentioned either doesn't exist or predates HTML5. Every browser has a security team that carefully reviews any new features for privacy breaches and reports problems back to the standards bodies before implementation. Everyone involved in web standards is well aware of all of these issues and tries to head them off at the pass. No website can read another website's data, none can store things without the user's permission, and nothing stops users from clearing all private data at any time.

Let's look at this systematically. First of all:

The new Web language and its additional features present more tracking opportunities because the technology uses a process in which large amounts of data can be collected and stored on the user’s hard drive while online. Because of that process, advertisers and others could, experts say, see weeks or even months of personal data. That could include a user’s location, time zone, photographs, text from blogs, shopping cart contents, e-mails and a history of the Web pages visited.

Web Storage, Web SQL Database, and IndexedDB are three of the standards commonly lumped in with HTML5, and all of them do indeed allow larger amounts of data to be stored client-side than ever before. What the article doesn't mention is it's only available to the site that stored it, and users can clear it as easily as cookies. It poses absolutely no privacy threat beyond cookies: if a server wants to store data on your computer, it can already just store it on the server and store a short identifying key as the cookie.

What the unnamed "experts" here say is therefore crazy. Nothing in HTML allows advertisers to see your location or time zone without your consent, let alone shopping cart contents or e-mail. Since the article doesn't deign to specify what HTML5 technologies are supposed to be able to do this magic, I can't refute it beyond saying it's just nonsense.

The new Web language “gives trackers one more bucket to put tracking information into,” said Hakon Wium Lie, the chief technology officer at Opera, a browser company.

Hâkon knows what he's talking about – he's a notable figure in the web standards community, editing such high-profile standards as CSS 2.1. But look at what he says carefully: trackers get "one more bucket". One more just like all the others, which can be controlled and cleared along with all the others, thus no greater privacy risk. I'd bet good money that this quote of his is taken completely out of context, and that he was dismissing the reporter's fearmongering.

Then there's mention of evercookie. But nothing that evercookie does relies on any HTML5 feature. Yes, it stores things in four different types of HTML5 storage, but again, those are cleared just like cookies. Try it yourself: create an evercookie on that page, clear your cookies from your browser's menus, and then click to rediscover cookies. You'll see that the four HTML5 methods (localData, globalData, sessionData, dbData) are all cleared too.

(There is one other mention of HTML5 on evercookie's page, but it's red herring. The pngData mechanism uses HTML5 canvas, but if you look at how it works, it would work just as easily by storing a JavaScript file or even a plain text file, and retrieving it via <script> or XMLHttpRequest.)

It's worth emphasizing, by the way, that using your browser's "private browsing mode" (whatever it's called) will completely defeat evercookie. So this is not some earth-shattering problem that no one's thought of.

The article goes on:

Each browser has different privacy settin

The article is nonsense. Every privacy problem mentioned either doesn't exist or predates HTML5. Every browser has a security team that carefully reviews any new features for privacy breaches and reports problems back to the standards bodies before implementation. Everyone involved in web standards is well aware of all of these issues and tries to head them off at the pass. No website can read another website's data, none can store things without the user's permission, and nothing stops users from clearing all private data at any time.

Let's look at this systematically. First of all:

The new Web language and its additional features present more tracking opportunities because the technology uses a process in which large amounts of data can be collected and stored on the user’s hard drive while online. Because of that process, advertisers and others could, experts say, see weeks or even months of personal data. That could include a user’s location, time zone, photographs, text from blogs, shopping cart contents, e-mails and a history of the Web pages visited.

Web Storage, Web SQL Database, and IndexedDB are three of the standards commonly lumped in with HTML5, and all of them do indeed allow larger amounts of data to be stored client-side than ever before. What the article doesn't mention is it's only available to the site that stored it, and users can clear it as easily as cookies. It poses absolutely no privacy threat beyond cookies: if a server wants to store data on your computer, it can already just store it on the server and store a short identifying key as the cookie.

What the unnamed "experts" here say is therefore crazy. Nothing in HTML allows advertisers to see your location or time zone without your consent, let alone shopping cart contents or e-mail. Since the article doesn't deign to specify what HTML5 technologies are supposed to be able to do this magic, I can't refute it beyond saying it's just nonsense.

The new Web language “gives trackers one more bucket to put tracking information into,” said Hakon Wium Lie, the chief technology officer at Opera, a browser company.

Hâkon knows what he's talking about – he's a notable figure in the web standards community, editing such high-profile standards as CSS 2.1. But look at what he says carefully: trackers get "one more bucket". One more just like all the others, which can be controlled and cleared along with all the others, thus no greater privacy risk. I'd bet good money that this quote of his is taken completely out of context, and that he was dismissing the reporter's fearmongering.

Then there's mention of evercookie. But nothing that evercookie does relies on any HTML5 feature. Yes, it stores things in four different types of HTML5 storage, but again, those are cleared just like cookies. Try it yourself: create an evercookie on that page, clear your cookies from your browser's menus, and then click to rediscover cookies. You'll see that the four HTML5 methods (localData, globalData, sessionData, dbData) are all cleared too.

(There is one other mention of HTML5 on evercookie's page, but it's red herring. The pngData mechanism uses HTML5 canvas, but if you look at how it works, it would work just as easily by storing a JavaScript file or even a plain text file, and retrieving it via <script> or XMLHttpRequest.)

It's worth emphasizing, by the way, that using your browser's "private browsing mode" (whatever it's called) will completely defeat evercookie. So this is not some earth-shattering problem that no one's thought of.

The article goes on:

Each browser has different privacy settin

The article is nonsense. Every privacy problem mentioned either doesn't exist or predates HTML5. Every browser has a security team that carefully reviews any new features for privacy breaches and reports problems back to the standards bodies before implementation. Everyone involved in web standards is well aware of all of these issues and tries to head them off at the pass. No website can read another website's data, none can store things without the user's permission, and nothing stops users from clearing all private data at any time.

Let's look at this systematically. First of all:

The new Web language and its additional features present more tracking opportunities because the technology uses a process in which large amounts of data can be collected and stored on the user’s hard drive while online. Because of that process, advertisers and others could, experts say, see weeks or even months of personal data. That could include a user’s location, time zone, photographs, text from blogs, shopping cart contents, e-mails and a history of the Web pages visited.

Web Storage, Web SQL Database, and IndexedDB are three of the standards commonly lumped in with HTML5, and all of them do indeed allow larger amounts of data to be stored client-side than ever before. What the article doesn't mention is it's only available to the site that stored it, and users can clear it as easily as cookies. It poses absolutely no privacy threat beyond cookies: if a server wants to store data on your computer, it can already just store it on the server and store a short identifying key as the cookie.

What the unnamed "experts" here say is therefore crazy. Nothing in HTML allows advertisers to see your location or time zone without your consent, let alone shopping cart contents or e-mail. Since the article doesn't deign to specify what HTML5 technologies are supposed to be able to do this magic, I can't refute it beyond saying it's just nonsense.

The new Web language “gives trackers one more bucket to put tracking information into,” said Hakon Wium Lie, the chief technology officer at Opera, a browser company.

Hâkon knows what he's talking about – he's a notable figure in the web standards community, editing such high-profile standards as CSS 2.1. But look at what he says carefully: trackers get "one more bucket". One more just like all the others, which can be controlled and cleared along with all the others, thus no greater privacy risk. I'd bet good money that this quote of his is taken completely out of context, and that he was dismissing the reporter's fearmongering.

Then there's mention of evercookie. But nothing that evercookie does relies on any HTML5 feature. Yes, it stores things in four different types of HTML5 storage, but again, those are cleared just like cookies. Try it yourself: create an evercookie on that page, clear your cookies from your browser's menus, and then click to rediscover cookies. You'll see that the four HTML5 methods (localData, globalData, sessionData, dbData) are all cleared too.

(There is one other mention of HTML5 on evercookie's page, but it's red herring. The pngData mechanism uses HTML5 canvas, but if you look at how it works, it would work just as easily by storing a JavaScript file or even a plain text file, and retrieving it via <script> or XMLHttpRequest.)

It's worth emphasizing, by the way, that using your browser's "private browsing mode" (whatever it's called) will completely defeat evercookie. So this is not some earth-shattering problem that no one's thought of.

The article goes on:

Each browser has different privacy settin

The article is nonsense. Every privacy problem mentioned either doesn't exist or predates HTML5. Every browser has a security team that carefully reviews any new features for privacy breaches and reports problems back to the standards bodies before implementation. Everyone involved in web standards is well aware of all of these issues and tries to head them off at the pass. No website can read another website's data, none can store things without the user's permission, and nothing stops users from clearing all private data at any time.

Let's look at this systematically. First of all:

The new Web language and its additional features present more tracking opportunities because the technology uses a process in which large amounts of data can be collected and stored on the user’s hard drive while online. Because of that process, advertisers and others could, experts say, see weeks or even months of personal data. That could include a user’s location, time zone, photographs, text from blogs, shopping cart contents, e-mails and a history of the Web pages visited.

Web Storage, Web SQL Database, and IndexedDB are three of the standards commonly lumped in with HTML5, and all of them do indeed allow larger amounts of data to be stored client-side than ever before. What the article doesn't mention is it's only available to the site that stored it, and users can clear it as easily as cookies. It poses absolutely no privacy threat beyond cookies: if a server wants to store data on your computer, it can already just store it on the server and store a short identifying key as the cookie.

What the unnamed "experts" here say is therefore crazy. Nothing in HTML allows advertisers to see your location or time zone without your consent, let alone shopping cart contents or e-mail. Since the article doesn't deign to specify what HTML5 technologies are supposed to be able to do this magic, I can't refute it beyond saying it's just nonsense.

The new Web language “gives trackers one more bucket to put tracking information into,” said Hakon Wium Lie, the chief technology officer at Opera, a browser company.

Hâkon knows what he's talking about – he's a notable figure in the web standards community, editing such high-profile standards as CSS 2.1. But look at what he says carefully: trackers get "one more bucket". One more just like all the others, which can be controlled and cleared along with all the others, thus no greater privacy risk. I'd bet good money that this quote of his is taken completely out of context, and that he was dismissing the reporter's fearmongering.

Then there's mention of evercookie. But nothing that evercookie does relies on any HTML5 feature. Yes, it stores things in four different types of HTML5 storage, but again, those are cleared just like cookies. Try it yourself: create an evercookie on that page, clear your cookies from your browser's menus, and then click to rediscover cookies. You'll see that the four HTML5 methods (localData, globalData, sessionData, dbData) are all cleared too.

(There is one other mention of HTML5 on evercookie's page, but it's red herring. The pngData mechanism uses HTML5 canvas, but if you look at how it works, it would work just as easily by storing a JavaScript file or even a plain text file, and retrieving it via <script> or XMLHttpRequest.)

It's worth emphasizing, by the way, that using your browser's "private browsing mode" (whatever it's called) will completely defeat evercookie. So this is not some earth-shattering problem that no one's thought of.

The article goes on:

Each browser has different privacy settin

Folks, I thought this isn't new at all. Don't cookies do the same thing? I have a cookie that will 'never' expire unless I delete it. What am I missing?

That, in combination with html5 local databases, you can create cookies that cannot be deleted. Ever.

This is completely false. The Web Storage spec says:

If users attempt to protect their privacy by clearing cookies without also clearing data stored in the local storage area, sites can defeat those attempts by using the two features as redundant backup for each other. User agents should present the interfaces for clearing these in a way that helps users to understand this possibility and enables them to delete data in all persistent storage features simultaneously.

In practice, this is what browsers do. Every time you clear cookies, you clear all persistent storage that the browser controls – leaving only things like Flash storage, and of course things that are stored on the server rather than the client. If you're referring to Evercookie, that has nothing to do with HTML5.

The fact that HTML is open to all means anyone can implement it in their 'browser' ...

Sure, all 705 pages of it are open for anyone to implement. Get started!

XHTML 2.0 was abandoned before reaching recommendation status, it only got to "working draft" status, last update was 2006.

what is so terrible int that standard, i did a 10 quick check and the sample I have read looked sane to me. What did you find so terrible in this spec? Take the page : http://www.w3.org/TR/2010/WD-html5-20100624/elements.html , where did you saw something so disgraceful that it must be called terrible ?

And yes, the standard is terrible. Go read it.

-- Barbie

It's called P3P and its already a W3C standard. P3P

I have been implementing it on all my sites for a few years.

...just a guy who happens to be part of the W3C stating his personal opinion. There is no official press release or publication on the W3C site itself--and, for that matter, not even any on this guy's personal web page or Twitter feed (when did he even say this?).

A guy who "happens" to be leader of the entire Interaction Domain, including HTML (and CSS, SVG, etc.). So, yes, it's not an official W3C statement, but Philippe Le Hégaret is not just "a guy who happens to be part of the W3C".

In a work placement year I did the major electronics company had a couple of staff on the board for a standard -- it involved lots of XML and internet stuff, so it's not far from the kind of thing W3C does.

What took so long was working out whether technology that required infringing on each company's software patents should be "required" or "optional". In the end, Sony, Philips, Panasonic etc decided to pool their patents (their stuff is "required"), the patent troll companies were excluded by the big company's votes (so the neat technology they'd patented was "optional" or left out entirely) and the couple of small businesses or individuals who'd already got products running using the draft spec were ignored.

The W3C has a Patent Policy requiring that all its specifications be implementable royalty-free, so this is not an issue. No spec can be covered by any known patents at all unless those are irrevocably licensed royalty-free. I've heard this kind of bickering can suck up time at less enlightened standards organizations, though, which believe in unreasonable stuff like RAND (= let everyone on the standards committee rake in money by making sure some patent of theirs is required).

Why don't modern browsers render this character?

Two reasons, the first being that HTML 4 specs call for it to not be rendered unless it meets the criteria. Here is the full blurb:

9.3.3 Hyphenation

In HTML, there are two types of hyphens: the plain hyphen and the soft hyphen. The plain hyphen should be interpreted by a user agent as just another character. The soft hyphen tells the user agent where a line break can occur.

Those browsers that interpret soft hyphens must observe the following semantics: If a line is broken at a soft hyphen, a hyphen character must be displayed at the end of the first line. If a line is not broken at a soft hyphen, the user agent must not display a hyphen character. For operations such as searching and sorting, the soft hyphen should always be ignored.

In HTML, the plain hyphen is represented by the "-" character ( or ). The soft hyphen is represented by the character entity reference ( or )

The other reason is that the current unicode standard basically says it doesn't support when and where it should be displayed as a hyphen and leaves it open to interpretation of whoever is coding for it. Here is the blurb from the unicode standard on it:

Hyphenation. U+00AD soft hyphen (SHY) indicates an intraword break point, where a line break is preferred if a word must be hyphenated or otherwise broken across lines. Such break points are generally determined by an automatic hyphenator. SHY can be used with any script, but its use is generally limited to situations where users need to override the behavior of such a hyphenator. The visible rendering of a line break at an intraword break point, whether automatically determined or indicated by a SHY, depends on the surrounding characters, the rules governing the script and language used, and, at times, the meaning of the word. The precise rules are outside the scope of this standard, but see Unicode Standard Annex #14, “Unicode Line Breaking Algorithm,” for additional information. A common default rendering is to insert a hyphen before the line break, but this is insufficient or even incorrect in many situations.

Contrast this usage with U+2027 hyphenation point, which is used for a visible indication of the place of hyphenation in dictionaries. For a complete list of dash characters in the Unicode Standard, including all the hyphens, see Table 6-3.

The Unicode Standard includes two nonbreaking hyphen characters: U+2011 non-breaking hyphen and U+0F0C tibetan mark delimiter tsheg bstar. See Section 10.2, Tibetan, for more discussion of the Tibetan-specific line breaking behavior.

We should be able to do this in CSS 3, at last.

TFA sure doesn't.

Server side push never took off, web sockets probably will.

That's all anyone need know.

...just a guy who happens to be part of the W3C stating his personal opinion. There is no official press release or publication on the W3C site itself--and, for that matter, not even any on this guy's personal web page or Twitter feed (when did he even say this?).

It's probably the "need" for paper and in-vivo meetings.

If you didn't need them, standards would fly instead of committee members.

HTML5 uses no in-person meetings. The HTML Working Group charter at the W3C even says "This group primarily conducts its technical work on a Public mailing list". Everything is done through a combination of the mailing list and Bugzilla, with some IRC discussion thrown in on the side. There are teleconferences, but nothing important is done there, and the editor doesn't attend them – the decision policy requires that all requests for changes be made through Bugzilla and other web interfaces. There's also no paper involved anywhere.

Really, almost nothing at the W3C is in-person. People contribute from all over the world, both W3C members and non-members. In-person meetings are impractical. This is particularly true for HTML5 – the WHATWG version of the spec is really managed exactly like an open-source project with a benevolent dictator, not at all like a conventional spec.

The reason specs progress slowly is because it takes lots of programmer-hours to implement them correctly. Most of HTML5 is fully specced and just awaiting implementation. Programming is expensive work.

It's probably the "need" for paper and in-vivo meetings.

If you didn't need them, standards would fly instead of committee members.

HTML5 uses no in-person meetings. The HTML Working Group charter at the W3C even says "This group primarily conducts its technical work on a Public mailing list". Everything is done through a combination of the mailing list and Bugzilla, with some IRC discussion thrown in on the side. There are teleconferences, but nothing important is done there, and the editor doesn't attend them – the decision policy requires that all requests for changes be made through Bugzilla and other web interfaces. There's also no paper involved anywhere.

Really, almost nothing at the W3C is in-person. People contribute from all over the world, both W3C members and non-members. In-person meetings are impractical. This is particularly true for HTML5 – the WHATWG version of the spec is really managed exactly like an open-source project with a benevolent dictator, not at all like a conventional spec.

The reason specs progress slowly is because it takes lots of programmer-hours to implement them correctly. Most of HTML5 is fully specced and just awaiting implementation. Programming is expensive work.

When the draft spec for a technology that moves so fast and has so much widespread adoption is still deemed several years off I don't know how anyone can take their recommendations seriously. We're already at a level of fairly good interoperability amongst the core browser engines for the base features we need. If developers and designers took any notice of this then we'd probably all be still building sites with tables.

This is why the WHATWG – the body that originally developed HTML5, and which still develops a version in parallel to the W3C – abandoned the idea of rating the stability of the spec as a whole. The WHATWG spec version (which is edited by the same person as the W3C spec, contains everything the W3C spec does plus more, and has useful JavaScript annotations like a feedback form) is perpetually labeled "Draft Standard", and per-section annotations in the margins tell you the implementation status of each feature.

The W3C Process, on the other hand, requires everything to proceed through the Candidate Recommendation stage, where it gets feature-frozen, and therefore becomes rapidly obsolete. It's quite backwards, but doesn't seem likely to change soon. So for sanity's sake, you can just ignore the W3C and follow the WHATWG instead.

(I really doubt that Philippe Le Hegaret actually said anything like what he was quoted as saying in TFA, though. It doesn't match what I've heard from him or the W3C before – no one seriously thinks authors shouldn't use widely-implemented things like canvas or video with suitable fallback. It sounds more like an anti-HTML5 smear piece. Paul Krill has apparently written other anti-HTML5 articles.)

10.3 Redirection 3xx

This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.

Note: previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation.

the policy of a computer letting a user do EXACTLY what they want to do CAN NEVER BE "WRONG".

Why were these changes made? Because the spec was wrong, that's why.

Then what would you say about an OS which:

  - was \textsc{unix}
  - supported the initial versions of http
  - was used to develop a graphical web browser and editor named worldwideweb.app[1]

NeXTstep, available in 1989

William

1 - _Weaving the Web_ by Sir Tim Berners-Lee --- http://www.w3.org/People/Berners-Lee/Weaving/Overview.html

Let me start out by reminding everyone that when Netscape came up with Cookies, everyone thought they were fine. Now, thanks to 1 pixel images and other tracking methods, cookies are the key to online companies aggregating bits of "anonymous" data into an identifiable profile of a person. Does Google know only as much about you as you would like? In fact, they know far more about you than you would expect, even if you don't use GMail.

The single biggest shot across the bow to privacy in HTML5 is the ping attribute. It may seem innocuous at first glance, but according to MozillaZine, it sends an HTTP POST request to each url. Why not GET instead?

This will allow Google, Alexa, FaceBook, or any "partner" to track users, if a site implements ping, easier than ever before. Some say trackers will migrate away from redirect URLs, but I say they will do both, if only to sop up every last piece of data they can.

I can see ping being used as a stealth DDOS attack, if enough malicious links can be distributed. Some content provider web API gets hacked, thousands of sites load up links (via AJAX) that ping slashdot.org, and Slashdot goes down. Will ping implementations be smart enough to reduce the list of URLs down to unique values? How many times does ping="slashdot.org slashdot.org/foo slashdot.org/comments.pl slashdot.org/article.pl" actually hit the poor, unsuspecting server? There's no apparent limit to how many URLs can be stuffed into a single ping, either.

I'm sure the black hats will think of other ways to exploit this. I agree that tools are neither evil nor good, but this is ripe for unintended consequences.

who calls the rampant ageism 'really f***ed up,'

Phhhbbt, sounds like something your average old timer would say ...

'It's probably the reason why we keep going around in the same loops over and over, because we chuck our experience, wholesale, every ten years or so.'

Oh, sure the initial steps in the web's client/server model may have had resembled the dumb terminals and mainframes of the days of yore but with HTML5 my generation is bringing in a new original and fresh way of computing where worker threads and local storage give us the ability to distribute ...

*red LED under the skin of eldavojohn's arm starts flashing*

What's this!? What? Wait, no! Nooo! It can't be!

*eldavojohn stands up to run only to be met by two members of the sunset squad holding stun batons behind him*

No, I just turned 28! You bastards, I was supposed to have more time! It's not my time yet!

*as they drag him away, a young acne faced male takes his place and begins mockingly humming "Circle of Life" from the Lion King while tearing down the X-Files poster and MST3K figurines adorning the cubicle*

who calls the rampant ageism 'really f***ed up,'

Phhhbbt, sounds like something your average old timer would say ...

'It's probably the reason why we keep going around in the same loops over and over, because we chuck our experience, wholesale, every ten years or so.'

Oh, sure the initial steps in the web's client/server model may have had resembled the dumb terminals and mainframes of the days of yore but with HTML5 my generation is bringing in a new original and fresh way of computing where worker threads and local storage give us the ability to distribute ...

*red LED under the skin of eldavojohn's arm starts flashing*

What's this!? What? Wait, no! Nooo! It can't be!

*eldavojohn stands up to run only to be met by two members of the sunset squad holding stun batons behind him*

No, I just turned 28! You bastards, I was supposed to have more time! It's not my time yet!

*as they drag him away, a young acne faced male takes his place and begins mockingly humming "Circle of Life" from the Lion King while tearing down the X-Files poster and MST3K figurines adorning the cubicle*

Unlikely. DOM structures are generally huge, complicated beasts. The odds that you can write a CSS selector that matches the ads on one page without hitting anything on other pages are pretty good. Even if it is just a div in a div in a div in a div called left-nav, some of the ancestors are likely to have identifyable properties, either from classes, ids, other attributes, their position with regards to their siblings... something. And since it would be easy to keep unique css rules per site or even page, you wouldn't really run the risk of wiping out content on other websites.

It's all about how much effort you (for some value of "you") want to spend keeping the rules up to date.

Unlikely. DOM structures are generally huge, complicated beasts. The odds that you can write a CSS selector that matches the ads on one page without hitting anything on other pages are pretty good. Even if it is just a div in a div in a div in a div called left-nav, some of the ancestors are likely to have identifyable properties, either from classes, ids, other attributes, their position with regards to their siblings... something. And since it would be easy to keep unique css rules per site or even page, you wouldn't really run the risk of wiping out content on other websites.

It's all about how much effort you (for some value of "you") want to spend keeping the rules up to date.

Slashdot doesn't, your web browser does. http://www.w3.org/TR/html4/struct/text.html#idx-white_space-2

In particular, user agents should collapse input white space sequences when producing output inter-word space.

This is why we have &nbsp; and <pre>

Please explain why you used one space between all sentences in your post.

He actually used two spaces. Unfortunately for him, browsers collapse multiple spaces into one. He lacks commitment; a true Double-Spacer would have used two non-breaking spaces.

HTML 5 has the device tag for accessing cameras and microphones. It's just not been implemented by any browser yet.

I've seen timeline-based editors and things that'll convert and run flash into SVG/javascript. Hell, even CS5 has got a export to html5 option..

Browsers are about the most complex piece of software you will find anywhere. Think about all they can do. They have a not just one page rendering algorithm, several different types. Different modes mean different things, and W3 lists over 20 different modes.

Then they have the networking part, that communicates to servers, opening several sockets at a time and coordinating their retrieval. And they have to be able to do it with HTTP1.0 or HTTP2.0. And they have to be able to handle weird HTTP things, like password authentication.

After that, they have to be able to parse at least three different image types (and image parsing libraries are a great place to look for vulnerabilities because they are complex and the data is hard to validate). And they have to be able to interact with the OS in some way to allow movie and audio playing. And flash. And Java Applets. And any other weird plugin.

Then add to it a complex, object oriented, interpreted language (as if the several versions of HTML weren't bad enough), and the fact that the entire page has to be dynamic. Quickly dynamic: people want to do animations with this stuff, it has to happen in milliseconds.

And a spell checker. Oh, and it has to be able to interact with and recognize tons of different character encodings. In short, if I had a choice between writing a kernel and guaranteeing that it was vulnerability-free, and writing a browser and guaranteeing it was vulnerability-free, I would take the kernel any day. It's a significantly easier piece of software.

So there are still bugs in IE too, don't worry.

Granted, IE6 is broken, but not in the way most developers seem to think, or want to claim. It had bugs, and when it was designed, the W3C had not clarified how the box model was supposed to work, and IE6's assumptions were were wrong.

I agree that people drastically underestimate how good a browser IE6 was. It got 95% market share because it was the best browser at the time, period. However, this specific statement of yours is wrong, as far as I know. CSS2 clearly specified the box model and the meaning of the "width" property in 1998. IE6 was released on August 2001, IE5.5 in July 2000, IE5 in March 1999.

Thus IE6 must have still been in the design phase by the time that the box model was officially clarified, and its team must have decided that this bug wasn't worth delaying the browser release over. I don't begrudge them that decision, because I don't know what reasoning went into it. As I recall a Mozilla developer once saying when denying the blocking flag on a bug, "Release management is the art of deciding who to tick off." Software can't ship with all desired features, or even close to it.

I think it's fair to say overall that the thing we should be hating Microsoft for is not releasing IE6, but for taking five years to release IE7. If they had released incremental updates every two years after IE6, we would not be in nearly as terrible a situation as we're in today. IE7 is bad but way better than IE6, IE8 is actually tolerable in objective terms, and IE9 is looking to actually be almost competitive in standards support.