Slashdot Mirror

It's actually the audio tag: http://dev.w3.org/html5/spec/Overview.html

That was a fun contest. I entered a game called Onslaught!, check it out :)

Actually, surprisingly many authors use XHTML even today, and most HTML5 demos I've seen are written in well-formed XHTML in practice.

Really? Which authors use well-formed XML reliably, and which HTML5 demos are well-formed XML? The only major site I know of that serves well-formed pages reliably is Wikipedia. Remember that with XML, you don't get points for effort: if some minority of your pages are not well-formed, they fail to display.

The problem with XHTML2 didn't have anything to do with the fact that it was XML-only. The problem was that they threw out most existing HTML elements, and changed semantics for many that remained, so it wasn't backwards-compatible even with XHTML1.

I wasn't only talking about XHTML2. In 2004, Mozilla and Opera proposed that work begin in the W3C on incremental improvements to HTML independent of the path that the W3C was already pursuing. This path included XHTML2, but also XForms and other things (XML-based across the board). The W3C rejected their proposal, and that's how the WHATWG was formed. You can read a summary from the perspective of the browser implementers.

This wasn't only about XML, you're right, it was also about all-around impracticality. But XML was a big part of the picture. I can say with pretty good certainty that browser vendors would have refused to restrict new features only to XML even if that's all that was on the table. After all, implementers wrote HTML5, and had the choice to limit it to XML, but didn't. It's too brittle and hard to write correctly. One mistake and your page goes up in flames, and some of the mistakes you can make are very subtle.

Someone pointed out that on Unix, if you have a weird filename (non-printable characters) and try to visit a file:/// URL in some versions of Firefox, you get a well-formedness error. So even Mozilla can't get well-formedness right all the time. It's really hard to catch that kind of thing; XML is just too strict and too complicated. Errors about nesting are even worse, because they can't even be detected when you emit things unless you use an XML parser to build your output instead of string functions.

The thing discussed here is different - retain backwards compatibility on DOM level. This means that 1) any XHTML1 website just works, and 2) any HTML4 website can be automatically translated to XHTML1 - on the fly, if needed - and also just work.

So then you'd have to have a reliable HTML parser anyway, and you're saying it should be deployed on the server side instead of the client? What sense does that make? There are millions of servers, but at most five major clients. Implementing the parser in the client is much more reasonable, and much easier to implement. (Which is why that's what's actually done.)

The only reason to have HTML mode alongside XML in HTML5 that I see is to allow people with HTML4 websites to start using new HTML5 features without going XHTML. I do wonder how much this is an issue in practice, though, as the group of people most interested in HTML5 seem to be the same folks who proudly put "validated by W3C" stickers on their websites, and who moved it all to XHTML ages ago, anyway.

Actually, HTML5 advocates mostly get into violent arguments with XHTML advocates. ;) In practice, though, it would be a major problem. HTML5 is not only meant for standards advocates, it's meant for everyone. Plenty of Google properties use HTML5 features, but basically nothing they output is well-formed. Five or ten years from now, Joe Q. Author is expected to be slapping down video tags just like img tags, and almost no authors use well-formed XML.

> How hard is it to decide on a new standard?

Generally, not much harder than writing any piece of technical writing of the same length which has multiple authors with different (and generally conflicting) agendas. The time will also depend on the desired quality of the standard, of course. Writing a standard that says "do something here" or "behavior is not defined" takes less effort than one that carefully describes what a conforming implementation is supposed to do.

The length in this case is order of 1000 pages, last I checked. The desired quality is high (in that "behavior is not defined" stuff is being avoided). The number of authors depends on how you count them, ranging from a minimum of 1 to a maximum of several thousand depending on whom you ask. Realistically, there are at least 5 separate organizations (each with internal politics!) that have veto power over things they don't like, plus the editor, the three working group chairs (one of whom belongs to none of the above 5 organizations), and various invited experts, etc.

That's not even counting the bikeshedding that goes on.

Typical mail volume on the mailing list is around 900 messages a month or so, from a quick look at the archives (conveniently available at http://lists.w3.org/Archives/Public/public-html/ ). Another 400 messages a month or so on the whatwg list (archives at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/ ).

I'm assuming you've either never been involved in a standardization effort of any kind or got very very lucky when you were involved and dealt with something small and uncontroversial.

The "input type" mechanism for forms is lame. There are a number of standard types like "tel", but it's just text with no line breaks. They should have provided for either regular expressions or syntax like the COBOL Picture clause ("CREDIT_CARD_NUMBER PIC 9999-9999-9999-9999").

If you had RTFA you would have seen that one of the new validation types IS regex in the HTML 5 draft.

<input type="text" pattern="REGEX HERE">

(Read the "print" version of the article, instead of the "tiny blocks of text spread over many pages of ads" version.)

I have misgivings about HTML5. It gives the page more control, and the user less. That's been a trend in HTML for years, and it's getting worse.

I'm dreading "canvas". Ad blockers need to get smarter. Noticed that popups are winning over Firefox's popup blocking? We're also going to see pages that use 100% of the CPU just for display. We're going to need a browser option for "don't run canvas code for windows that aren't on top.

The "input type" mechanism for forms is lame. There are a number of standard types like "tel", but it's just text with no line breaks. They should have provided for either regular expressions or syntax like the COBOL Picture clause ("CREDIT_CARD_NUMBER PIC 9999-9999-9999-9999").

Dynamically-loaded fonts have been working for some time now in all the mainstream browsers. (IE6 and Firefox 3.5 were the last mainstream browsers not to have it.) We've been playing with that for our steampunk site. Downloadable fonts without anti-aliasing turn out to look ugly for small font sizes, because most of the display-type fonts have too much detail and not enough hinting for small font sizes. (In an annoying piece of Apple incompatibility, the iPad requires fonts in SVG, of all things. Everybody else, including Microsoft, is going to Web Open Font Format.) I'd recommend against using this feature much unless you have a good sense of typography. (Bad example: our steampunk search engine.)

I completely agree that SVG is a great standard that should be preserved and used more often. However, functionality takes a back seat to status qou and corporate sponsorship. Browsers and viewers tend to spend more energy supporting what people already use unless they see corporations pushing some new flashy thing, at which point they will support that too. People tend to only use those things which are well supported.

It's really a chicken vs. egg problem. There may be the occasional technology that finds its place before being well implemented, however, it seems that most of the new technology that will get pushed is that with commercial backing. Another great idea that hasn't seen any support is WAI-ARIA. Most people see the audio browsing as something only for the handicapped and thus unmarketable. However, it doesn't take much imagination to see how web browsing (especially mobile browsing) could be revolutionised by this technology. Until it seems trendy, it won't go anywhere.

I meant http://www.w3.org/TR/2010/WD-SVG11-20100622/, not SVG in general.

Because the hypertext transfer protocol was designed to transfer hypertext documents. It was not designed to be a remote application protocol.

That's true, if at all, only of the original, GET-only version of the HTTP protocol as supported by the first WWW prototype implementation ("HTTP 0.9".)

Its certainly not true of HTTP/1.1 which is a generic distributed object-manipulation-and-access protocol following REST principles.

But the site isn't, it has 165 errors and 8 warnings. So in fact a strict compliant browser shouldn't render it fine.

Check the validator output.

Extortion. So what - On2 Technologie's website doesn't validate. Excuse my spelling at 1 o'clock in the morning. Good night! ;-)

How would the users know it's that site that is broken, and not the browser?

Via the W3C validation buttons at the bottom of the page that the users can click and see that the site does adhere to standards (or *cough*slashdot*cough* doesn't).

Link on how a <blockquote > works

These two elements designate quoted text. BLOCKQUOTE is for long quotations (block-level content) and Q is intended for short quotations (inline content) that don't require paragraph breaks.

And on Lines and paragraphs:

A line break is defined to be a carriage return (), a line feed (), or a carriage return/line feed pair. All line breaks constitute white space.

Given that <blockquote> is supposed to have line breaks before and after, rendering a different level of whitespace seems incorrect. The fact that it follows completely different behavior from every other situation (which it renders like Gecko, Webkit, Trident, etc except when within <td> and </td> tags, it is a very obvious bug that they have refused to patch (I told them about it, got an autoreply from their bug intake, and no response. They have no public bug tracker.)

Link on how a <blockquote > works

These two elements designate quoted text. BLOCKQUOTE is for long quotations (block-level content) and Q is intended for short quotations (inline content) that don't require paragraph breaks.

And on Lines and paragraphs:

A line break is defined to be a carriage return (), a line feed (), or a carriage return/line feed pair. All line breaks constitute white space.

Given that <blockquote> is supposed to have line breaks before and after, rendering a different level of whitespace seems incorrect. The fact that it follows completely different behavior from every other situation (which it renders like Gecko, Webkit, Trident, etc except when within <td> and </td> tags, it is a very obvious bug that they have refused to patch (I told them about it, got an autoreply from their bug intake, and no response. They have no public bug tracker.)

Opera brags about this, but my experience is that it's generally quirky in comparison to other browsers (not IE) with valid (X)HTML/CSS. For instance, W3 specs say that a blockquote should be rendered with equal whitespace before and after (link here) , yet Opera won't give it any whitespace in a after the closing blockquote tag. This breaks the appearance of many sites, including imageboards.

Why should I care about a non-extensible browser that does some artificial benchmarks a millisecond faster? Not trolling, I'm trying to figure out what practical benefit Opera has for its users.

You are linking about future CSS3 tech.

Like I said, not all "-webkit-*" properties are part of the CSS3 standard, or even drafts. In fact, not all of them are even in WebKit trunk - some of that stuff Apple keeps to itself. I dare you to find "text-size-adjust" in any CSS3 draft. While you're at it, RTFM, and pay attention to numerous references to "optimizing for iPhone". You may also find this discussion on W3 mailing lists interesting.

And that is something that is heavily used already, not some abstract future problem.

So, yes, it really is "embrace & extend" all over again, and this time Apple is doing it. It's just that they've got awesome marketing, so much so that most geeks are absolutely convinced that it is all about HTML5 and standards in general.

"It's all cloud computing now"

Provided that you're willing to pay 60 USD a month for mobile broadband. A lot of us aren't, and we use numerous offline-mode workarounds such as IMAP sync, the Read It Later extension, and the like. Until IE supports HTML5 cache manifests and HTML5 web storage like Chrome and Firefox, IE won't be ready for the netbook.

"It's all cloud computing now"

Provided that you're willing to pay 60 USD a month for mobile broadband. A lot of us aren't, and we use numerous offline-mode workarounds such as IMAP sync, the Read It Later extension, and the like. Until IE supports HTML5 cache manifests and HTML5 web storage like Chrome and Firefox, IE won't be ready for the netbook.

Well, this might be an exaggeration, but many of these features already exist in XSL-FO (animation and sound at least, and arbitrarily shaped text areas). http://www.w3.org/TR/xslfo20-req/#N65820

I like the fact that I can jump to any part of the video and even direct people to that part of the video with a single url.

HTML5's <video> element supports JavaScript seeking to a new playback position. Your video page can read the fragment identifier from the URI, parse it, and then set the video element's currentTime attribute to make the player seek. The back end uses an HTTP/1.1 range retrieval, the same thing that resumable downloads use.

the video tag doesn't really do steaming in that sense.

Steaming as in a "steaming pile"?

Great post, but date was it posted? 02-07-05 could be 2002-07-05, 2002-05-07, 2005-07-02 or 2005-02-07? Please read http://w3.org/QA/Tips/iso-date

(Apologies for replying to myself.)

The biggest problem when discussing web standards is that the vendors themselves propose the standards. So Apple is the most compliant with Apple's proposed standards, while Microsoft is the most compliant with Microsoft's proposed standards, etc. From the W3C's POV they are all the same, while the marketplace sorts these things out into common "cross-browser" features versus things which are considered "proprietary".

In other words, nobody cares that CSS3 rounded borders aren't an official "standards compliant" feature, it is a "cross browser" feature and they want rounded fucking corners on their website.

Okay, so you've never actually participated in the W3C or any other standards organization. Thanks for letting us all know. Implementers pay some (not all) of the people who write and edit standards at the W3C (and elsewhere), but they write things that all implementers are willing to implement, and do.

In fact, W3C specs cannot progress to Proposed Recommendation unless they have two fully independent, interoperable implementations of every single feature. The HTML5 spec at the WHATWG has an even stronger requirement: if any major implementer refuses to implement a feature, the feature is dropped, and this has happened more than once. (Most famously, the Theora support requirement, but also Web Databases, etc.)

Typically, browser vendors use the W3C to agree on what sort of functionality authors and users want most, and then cooperate to work out a standard. Usually they try focus on the same areas and implement things more or less in sync, because a) that way authors will be able to use the features faster, and b) as soon as one browser implements something, everyone starts pestering the others with "Why does this work in their browser and not yours?"

And by the way, a version of border-radius was in W3C drafts since at least 2002. It was implemented with vendor prefixes per CSSWG policy, because it wasn't in a Candidate Recommendation yet and was subject to change. In fact, it did change, so -moz-border-radius (IIRC) behaves slightly differently from the final border-radius. It was always a standards-compliant feature.

I can understand why, when your homepage produces this.

Sorry, I don't think I'll be using something to create HTML if it's written by people who can't write proper HTML.

Since the W3C spec editor is a Google employee (see below), calling "witchcraft" on the W3C is essentially the same as calling "witchcraft" on Google, no? :-)

Geolocation API Specification
W3C Working Draft 07 July 2009
This Version:
http://www.w3.org/TR/2009/WD-geolocation-API-20090707/
Latest Published Version:
http://www.w3.org/TR/geolocation-API/
Latest Editor's Draft:
http://dev.w3.org/geo/api/spec-source.html
Previous version:
http://www.w3.org/TR/2008/WD-geolocation-API-20081222/
Editor:
Andrei Popescu, Google, Inc

Since the W3C spec editor is a Google employee (see below), calling "witchcraft" on the W3C is essentially the same as calling "witchcraft" on Google, no? :-)

Geolocation API Specification
W3C Working Draft 07 July 2009
This Version:
http://www.w3.org/TR/2009/WD-geolocation-API-20090707/
Latest Published Version:
http://www.w3.org/TR/geolocation-API/
Latest Editor's Draft:
http://dev.w3.org/geo/api/spec-source.html
Previous version:
http://www.w3.org/TR/2008/WD-geolocation-API-20081222/
Editor:
Andrei Popescu, Google, Inc

Since the W3C spec editor is a Google employee (see below), calling "witchcraft" on the W3C is essentially the same as calling "witchcraft" on Google, no? :-)

Geolocation API Specification
W3C Working Draft 07 July 2009
This Version:
http://www.w3.org/TR/2009/WD-geolocation-API-20090707/
Latest Published Version:
http://www.w3.org/TR/geolocation-API/
Latest Editor's Draft:
http://dev.w3.org/geo/api/spec-source.html
Previous version:
http://www.w3.org/TR/2008/WD-geolocation-API-20081222/
Editor:
Andrei Popescu, Google, Inc

Since the W3C spec editor is a Google employee (see below), calling "witchcraft" on the W3C is essentially the same as calling "witchcraft" on Google, no? :-)

Geolocation API Specification
W3C Working Draft 07 July 2009
This Version:
http://www.w3.org/TR/2009/WD-geolocation-API-20090707/
Latest Published Version:
http://www.w3.org/TR/geolocation-API/
Latest Editor's Draft:
http://dev.w3.org/geo/api/spec-source.html
Previous version:
http://www.w3.org/TR/2008/WD-geolocation-API-20081222/
Editor:
Andrei Popescu, Google, Inc

To obtain your location, Google Maps takes advantage of the W3C Geolocation API

That article explains EXACTLY what it does and what information is gathered. And it appears (though I might be wrong) that WiFi data is used to discern location, but not always necessarily passed to a site using My Location. It also looks like the Geolocation spec ISNT authored by google, but by the W3C. But of course its not quite as fun to call "witchcraft" on the W3C, now is it?

You know, I keep holding out hope that people on slashdot will tend to read the articles they post before posting it, but maybe Im just being naieve.

Recently, Google announced Android 2.2, the next version of their Linux-based mobile operating system targeted at phones and PDAs, at Google I/O 2010. Developers praised the update, calling it and its features a welcome addition to the platform.

Android 2.2 will bring the phone operating system closer to parity with its competitors. With 2.2r4 out now and a projected final release date of Summer '10, Android 2.2 is coming fast.

But stepping back from all of the commotion, what exactly is Google offering with this update? What are these new features and who will benefit from them? There are plenty of questions about Android 2.2and here are the answers.

Five Alive

Probably the most important update for Android for its end-users is HTML5. This changes very little about the platform itself, but it shows that Google is investing in the technology. It also means that users will have a seamless Web experience.

These two things are important for the future success of Android as a viable mobile platform, though Google's implementation might prove problematic.

On live devices, users will have to install Android 2.2 in its entirety to gain HTML5 support. An entire operating system upgrade for a browser? Get real and update the browser on its owndon't make your users go through the trouble of updating and installing a fundamental update just for some HTML5 support, Google. If this is how you run your phone operating system, I'd hate to see what you expect of Chrome OS users.

And there's also the fact that HTML5 is not novel. Every other industry player has already been including HTML5 support; Apple has long been a proponent of this, including HTML5 support in the developmental Webkit as well Safari since 2007. You're welcome to the party, Google, but don't announce it like you're the one throwing it. You can make catchup, but it's still catchup.

Flash Forward

Oh, Flash. Google and Adobe are performing a very calculated industry sixty-nine because both Apple and Google want the mobile-cum-portable market and Adobe wants the video portion of both.

Apple is pushing the open HTML5 standard; Adobe is pissed at Apple. Google, with the old the-enemy-of-my-enemy-is-my-friend tactic, sees an opportunity and hooks up with Adobe. Sadly, revenge sex only seems clever at first.

The reality is that HTML5, being open and supported by hundreds of companies and standard bodies, will win in the end. Google and Adobe will look like assholes having lapped at such a bloated, poorly-coded, closed video platform that everyone else will zoom past using their browsers sans crashy plugin.

Who wins in the end? The entire industry, sharing in the HTML5 platform, and users, whose browsers don't crash or chew up excess cycles and memory. Sadly, though, not Android users, who are unwitting Adobe consumers.

Hotspotting et al

Android will also support hotspotting, or wifi sharing funneled into its 3G or 4G network, of up to eight other devices. I'm not sure if you've done any serious work on 3G yet, but it's slow.

The prospect of using one 3G account to support other Internet-hungry devices is like expecting a pygmy to carry weightlifters: backbreaking at best and otherwise i

If MS actually owns client-side SQL, they might want to talk to the W3C.

http://dev.w3.org/html5/webdatabase/

All HTML5 compliant browsers will be implementing this.

> What are you talking about? Both are under the purview of the WHATWG working group.

That's bunk. No part of CSS is under the purview of WHATWG except insofar as CSS specs say the document language determines how something works.

>>> is generally referred to as "HTML5" by both the layman and the people writing
>>> the specs.
>>
>> Speaking as one of the latter... no, it's not.
>
> The last sentence of the first paragraph on the HTML5 wikipedia page reads: "In common
> usage, HTML5 may also refer to the additional use of CSS3

Yes, the Apple and Google attempt to create confusion around the term has somewhat worked, especially thanks to people like you.

> Apparently you are not the average layperson.

I said "the latter" (as in, person writing the specs), not "the former" (which would have been layperson). Reading comprehension, please.

>> Well, since no CSS specs are whatwg specs... that's easy.
>
> Gee WHATWG disagrees on that.

I call bullshit. Citation, please?

> which has been a fully published working draft since early 2009

You seem to be under some misapprehension as to how working drafts work in the W3C. Anyone who's a working group member (which entails only ponying up money) can propose one. If it fits within the working group's charter, the bar to publication is very low. So any member can implement any proprietary extension, document it, and propose it for standardization by publishing a working draft describing it. What typically happens after that is that either other implementors get on board and implement and the draft proceeds along the standards track or competing proposals are made (say WebGL in this case), and then the competing proposals fight it out. There are plenty of working drafts around that were proposed unilaterally and never went anywhere. http://www.w3.org/TR/NOTE-AS is a good example (the competing proposal for that was CSS).

> with open source reference implementations.

3d transforms is only supported in Safari and only on certain Apple operating systems, because it's implemented by directly calling into the closed-source and proprietary Core Animation framework to actually do all the work. If you call that an "open source reference implementation", you either have a strange definition of "open source" or have no idea what you're talking about.

> Clearly they are trying to take over the Web and make it proprietary or something?

As a matter of fact, that's the only way to interpret some of the things they're doing with Mobile Safari, yes. They would like to control as much content delivery as they possibly can, on their own terms (and are actively encouraging development of content that only works in Mobile Safari and will continue to only work in Mobile Safari).

> Yeah, you're just a hater

Or perhaps you're just and underinformed apologist?

This is a technicality, but it's fair enough. The other browsers should unprefix their implementations.

Until CSS3 is at least a recommendation rather than a draft, the CSS3-draft-related features remain proprietary extensions to CSS and the prefixes are appropriate.

In some cases, they may be using prefixes because their prefixed versions actually behave differently from the final standard.

Since the final standard does not exist yet, it is rather premature to remove prefixes on the assumption that the behavior (even if it matches the current draft) will match the final standard.

The features we're talking about, like border-radius, have reached Candidate Recommendation. According to informally-agreed-upon CSSWG process (see last sentence), prefixes can be dropped then. They don't have to wait until Recommendation – CSS 2.1 isn't even at REC, and won't reach it for some time. If IE has dropped a prefix after CR and another browser hasn't, it's fair to call that a standards-compliance win for IE.

Features specified in draft standards are not proprietary, in any case. And there is no "CSS3" standard: CSS 3 consists of a number of standards, which range from Proposed Recommendation (Selectors – further than CSS 2.1!) to not even written (like Math).

This is a technicality, but it's fair enough. The other browsers should unprefix their implementations.

Until CSS3 is at least a recommendation rather than a draft, the CSS3-draft-related features remain proprietary extensions to CSS and the prefixes are appropriate.

In some cases, they may be using prefixes because their prefixed versions actually behave differently from the final standard.

Since the final standard does not exist yet, it is rather premature to remove prefixes on the assumption that the behavior (even if it matches the current draft) will match the final standard.

The features we're talking about, like border-radius, have reached Candidate Recommendation. According to informally-agreed-upon CSSWG process (see last sentence), prefixes can be dropped then. They don't have to wait until Recommendation – CSS 2.1 isn't even at REC, and won't reach it for some time. If IE has dropped a prefix after CR and another browser hasn't, it's fair to call that a standards-compliance win for IE.

Features specified in draft standards are not proprietary, in any case. And there is no "CSS3" standard: CSS 3 consists of a number of standards, which range from Proposed Recommendation (Selectors – further than CSS 2.1!) to not even written (like Math).

This is a technicality, but it's fair enough. The other browsers should unprefix their implementations.

Until CSS3 is at least a recommendation rather than a draft, the CSS3-draft-related features remain proprietary extensions to CSS and the prefixes are appropriate.

In some cases, they may be using prefixes because their prefixed versions actually behave differently from the final standard.

Since the final standard does not exist yet, it is rather premature to remove prefixes on the assumption that the behavior (even if it matches the current draft) will match the final standard.

The features we're talking about, like border-radius, have reached Candidate Recommendation. According to informally-agreed-upon CSSWG process (see last sentence), prefixes can be dropped then. They don't have to wait until Recommendation – CSS 2.1 isn't even at REC, and won't reach it for some time. If IE has dropped a prefix after CR and another browser hasn't, it's fair to call that a standards-compliance win for IE.

Features specified in draft standards are not proprietary, in any case. And there is no "CSS3" standard: CSS 3 consists of a number of standards, which range from Proposed Recommendation (Selectors – further than CSS 2.1!) to not even written (like Math).

Woosh. Vendor prefixes are all good and well, but they're *not standard*.

They shouldn't be, but unfortunately, by the very definition that they're in the standards, they are standard.

Actually, while they allow non-standard proprietary extensions to be brought in via the back door, for good or bad, vendor extensions are valid according to the standards, although their use is discouraged. Pretty ridiculous as they allow for non-standard behaviour to be introduced while still allowing the page to pass a technical validation, they were added primarly because browser vendors wanted to add new functionality from CSS3/HTML5 etc without causing sites to fail validation to combat the fact that the W3C moves at a glacial pace. A good intention, but we all know what the road to hell is paved with...

css3-transform is not proprietary. Nor is css3-images, which describes gradient properties. The reason that these properties are implemented using the -webkit- prefix is because these standards have not reached candidate recommendation status and are still subject to change. A vendor prefix doesn’t mean “proprietary”—it means “experimental”. Once the standard reaches final recommendation status, which can only occur once two independent implementations have been created, then the vendor prefixes will be dropped.

For what it’s worth, there are a good number of people within the development community that are not happy with vendor prefixes, but it is the best option that currently exists to ensure that incompatible implementations do not use the same property name.

css3-transform is not proprietary. Nor is css3-images, which describes gradient properties. The reason that these properties are implemented using the -webkit- prefix is because these standards have not reached candidate recommendation status and are still subject to change. A vendor prefix doesn’t mean “proprietary”—it means “experimental”. Once the standard reaches final recommendation status, which can only occur once two independent implementations have been created, then the vendor prefixes will be dropped.

For what it’s worth, there are a good number of people within the development community that are not happy with vendor prefixes, but it is the best option that currently exists to ensure that incompatible implementations do not use the same property name.

It says “a copy of all the character data selected or partially selected by a Range”. By that description, and by any rational interpretation of the intent and usage of toString, window.getSelection().toString() should return the same thing that Ctrl-C returns as its plain text version (i.e. if you paste it into Notepad).

That's not true. It uses very precise terminology: character data is defined in XML to be "All text that is not markup". The DOM Level 1 spec explicitly refers to "character data" as being a term taken from XML. There is no newline in the markup and there is no newline in the DOM, so as the spec stands, there is no newline in the toString().

I mean, just look at what spec this is in: a DOM spec. The DOM specs don't depend on CSS at all. The references contain no mention of CSS. It is not possible to claim that the spec could possibly be read as saying CSS should affect the results of any operation it defines.

If the CSS creates an implicit line break character in the text node, I think that it should be copied as well.

This is a very sensible position, and I agree with it. I think it's what users will expect and it's the most useful. But it's not what the spec says. Surely you're not blaming Microsoft for writing text according to the spec itself rather than what they think the spec should say?

It says “a copy of all the character data selected or partially selected by a Range”. By that description, and by any rational interpretation of the intent and usage of toString, window.getSelection().toString() should return the same thing that Ctrl-C returns as its plain text version (i.e. if you paste it into Notepad).

That's not true. It uses very precise terminology: character data is defined in XML to be "All text that is not markup". The DOM Level 1 spec explicitly refers to "character data" as being a term taken from XML. There is no newline in the markup and there is no newline in the DOM, so as the spec stands, there is no newline in the toString().

I mean, just look at what spec this is in: a DOM spec. The DOM specs don't depend on CSS at all. The references contain no mention of CSS. It is not possible to claim that the spec could possibly be read as saying CSS should affect the results of any operation it defines.

If the CSS creates an implicit line break character in the text node, I think that it should be copied as well.

This is a very sensible position, and I agree with it. I think it's what users will expect and it's the most useful. But it's not what the spec says. Surely you're not blaming Microsoft for writing text according to the spec itself rather than what they think the spec should say?

It says “a copy of all the character data selected or partially selected by a Range”. By that description, and by any rational interpretation of the intent and usage of toString, window.getSelection().toString() should return the same thing that Ctrl-C returns as its plain text version (i.e. if you paste it into Notepad).

That's not true. It uses very precise terminology: character data is defined in XML to be "All text that is not markup". The DOM Level 1 spec explicitly refers to "character data" as being a term taken from XML. There is no newline in the markup and there is no newline in the DOM, so as the spec stands, there is no newline in the toString().

I mean, just look at what spec this is in: a DOM spec. The DOM specs don't depend on CSS at all. The references contain no mention of CSS. It is not possible to claim that the spec could possibly be read as saying CSS should affect the results of any operation it defines.

If the CSS creates an implicit line break character in the text node, I think that it should be copied as well.

This is a very sensible position, and I agree with it. I think it's what users will expect and it's the most useful. But it's not what the spec says. Surely you're not blaming Microsoft for writing text according to the spec itself rather than what they think the spec should say?

The Insert Node Into Selection test is equally retarded.

They create a new <div> element and insert it at the end of the selection in an existing <div>. In other words, they generate this:

<div id="div1">some text<div>new text</div></div>

...then they check to see if the value returned by selection.toString() is equal to “some textnew text”.

Morons. It shows up as this:

some text new text

...and that’s what toString() gives you, too.

The test is right per the spec text, the behavior of Gecko and WebKit is wrong. Opera is also right here. Read the definition of toString(). It says, "This does nothing more than simply concatenate all the character data selected by the Range. This includes character data in both Text and CDATASection nodes." In the example you give, there is no actual newline character in any text node – the line break is inserted by CSS.

Now, maybe the Gecko and WebKit behavior makes more sense. But it's not what the spec says.

There isn't full agreement but most of it is pretty complete. The only non nitpicking issue that people cant agree on is video/audio. Microsoft and Apple want push h.264 into their browsers and push h.264 as a de-facto standard so they advocate against defining a codec in HTML5 (an open standard). Of course they dont support anything else in IE and Safari(for HTML5 video tags)

If you think audio and video codecs are the only part of the spec that's controversial, you clearly don't follow the HTMLWG mailing list. There are 29 open issues, and many of them have been hotly debated. So have lots of other issues that weren't formally raised to the tracker.

The video codec issue actually was resolved long ago – the spec just doesn't say what codecs are required, and no one is really objecting to that. Mozilla, Opera, and Google support open codecs, but none has suggested that they actually be required by the spec when other major browsers refuse to implement them.

But a test of all specifications of the HTML5 Working Draft is not something easy. Have we ever had a test of all specifications of even CSS 2.1?

Not yet, but it's being worked on. As CSS 2.1 says, "A test suite and an implementations report will be provided before the document becomes a Proposed Recommendation." Microsoft has contributed an enormous number of tests to the CSS 2.1 suite.

So I ran that page using Firefox 3.6.3 and it says that it passes all of the Geolocation tests, looking at the spec though it suggests that it needs to ask me before passing that info. http://dev.w3.org/geo/api/spec-source.html "user agents must acquire permission through a user interface, unless they have prearranged trust relationships with users" If you run that page it does not ask but if you run this page http://www.mozilla.com/en-US/firefox/geolocation/ it will check with you before revieling your details.

Who the hell wrote these stupid tests? Whoever it is was a fucking moron.

I went down the list and picked the first one that Firefox supposedly failed on... “Call select() on a text field.” Firefox fails this test? What the fuck? I’ve used select() on text fields many a time and Firefox supports it just fine. Something’s fishy. So.......... I hit up the test page and read the source code.

If there’s a javascript error, the test obviously fails. A bunch of the attributes of window.getSelection() are checked, and if those don’t match what the test expected, the test fails. So I added a descriptive message to each fail condition, ran it again, and came up with the following list of exceptions:

Test result:
Anchor node not null (FAIL)
Anchor offset not zero (FAIL)
Focus node not null (FAIL)
Focus offset not zero (FAIL)
Is collapsed (PASS)
Range count not zero (FAIL)
Selection matched (PASS)
FAIL

Umm... so let’s see...

In order to pass this test, after selecting some text, the anchor node must be null, the offset zero, the focus node null, its offset zero, and the range count must be zero.

WHAT THE FUCK?

http://www.w3.org/TR/html5/editing.html#selection-0:

interface Selection {
readonly attribute Node anchorNode;
readonly attribute long anchorOffset;
readonly attribute Node focusNode;
readonly attribute long focusOffset;
readonly attribute boolean isCollapsed;
void collapse(in Node parentNode, in long offset);
void collapseToStart();
void collapseToEnd();
void selectAllChildren(in Node parentNode);
void deleteFromDocument();
readonly attribute long rangeCount;
Range getRangeAt(in long index);
void addRange(in Range range);
void removeRange(in Range range);
void removeAllRanges();
stringifier DOMString ();
};

selection.anchorNode
Returns the element that contains the start of the selection.
Returns null if there's no selection.

selection.anchorOffset
Returns the offset of the start of the selection relative to the element that contains the start of the selection.
Returns 0 if there's no selection.

selection.focusNode
Returns the element that contains the end of the selection.
Returns null if there's no selection.

selection.focusOffset
Returns the offset of the end of the selection relative to the element that contains the end of the selection.
Returns 0 if there's no selection.

selection.isCollapsed()
Returns true if there's no selection or if the selection is empty. Otherwise, returns false.

selection.rangeCount
Returns the number of ranges in the selection.

They wrote the exact opposite of these conditions for what you should expect after selecting text.

Strangely enough, Opera 10.53 also “passed”.

This is beyond incompetent, it is sleazy. They wrote their test to call everything that IE fails at a “pass” and anything that does it correctly will “fail”.

The correct test results should be:

Firefox 3.6.3:
Anchor node not null (PASS)
Anchor offset not zero (PASS)
Focus node not null (PASS)
Focus offset not zero (PASS)
Is collapsed (FAIL)
Range count not zero (PASS)
Selection matched (PASS)
FAIL

Opera 10.53:
Anchor node is null (FAIL)
Anchor offset is zero (FAIL)
Focus node

Sorry to reply to myself, but I forgot a few things:

1st: The actual ietestcenter fails validation with 12 errors and 6 warnings: http://validator.w3.org/check?uri=http://samples.msdn.microsoft.com/ietestcenter/&charset=(detect+automatically)&doctype=Inline&group=0

Including some serious ones, like no Character encoding specified.

None of the tests specify a character encoding either.

> HTML5 does not have the capability to access the webcam and the microphone on the desktop.

It's coming. See http://www.w3.org/TR/capture-api/ and I know Gecko is experimenting with this sort of thing.

Recently, Google announced Android 2.2, the next version of their Linux-based mobile operating system targeted at phones and PDAs, at Google I/O 2010. Developers praised the update, calling it and its features a welcome addition to the platform.

Android 2.2 will bring the phone operating system closer to parity with its competitors. With 2.2r4 out now and a projected final release date of Summer '10, Android 2.2 is coming fast.

But stepping back from all of the commotion, what exactly is Google offering with this update? What are these new features and who will benefit from them? There are plenty of questions about Android 2.2and here are the answers.

Five Alive

Probably the most important update for Android for its end-users is HTML5. This changes very little about the platform itself, but it shows that Google is investing in the technology. It also means that users will have a seamless Web experience.

These two things are important for the future success of Android as a viable mobile platform, though Google's implementation might prove problematic.

On live devices, users will have to install Android 2.2 in its entirety to gain HTML5 support. An entire operating system upgrade for a browser? Get real and update the browser on its owndon't make your users go through the trouble of updating and installing a fundamental update just for some HTML5 support, Google. If this is how you run your phone operating system, I'd hate to see what you expect of Chrome OS users.

And there's also the fact that HTML5 is not novel. Every other industry player has already been including HTML5 support; Apple has long been a proponent of this, including HTML5 support in the developmental Webkit as well Safari since 2007. You're welcome to the party, Google, but don't announce it like you're the one throwing it. You can make catchup, but it's still catchup.

Flash Forward

Oh, Flash. Google and Adobe are performing a very calculated industry sixty-nine because both Apple and Google want the mobile-cum-portable market and Adobe wants the video portion of both.

Apple is pushing the open HTML5 standard; Adobe is pissed at Apple. Google, with the old the-enemy-of-my-enemy-is-my-friend tactic, sees an opportunity and hooks up with Adobe. Sadly, revenge sex only seems clever at first.

The reality is that HTML5, being open and supported by hundreds of companies and standard bodies, will win in the end. Google and Adobe will look like assholes having lapped at such a bloated, poorly-coded, closed video platform that everyone else will zoom past using their browsers sans crashy plugin.

Who wins in the end? The entire industry, sharing in the HTML5 platform, and users, whose browsers don't crash or chew up excess cycles and memory. Sadly, though, not Android users, who are unwitting Adobe consumers.

Hotspotting et al

Android will also support hotspotting, or wifi sharing funneled into its 3G or 4G network, of up to eight other devices. I'm not sure if you've done any serious work on 3G yet, but it's slow.

The prospect of using one 3G account to support other Internet-hungry devices is like expecting a pygmy to carry weightlifters: backbreaking at best and otherwise i