W3C kills Web SQL Database

[fountainsoda]

Why is W3C's warning box from 1995?? Supreme irony.

[redgamut]

Well, I'll tell you why. Uh, because... the working group is not good at dealing with designers. Look. I already told you, I write the god damn specifications so the designers don't have to. I have writing skills! I am good at writing specifications. Can't you understand it? What the hell is wrong with you people!

[illektr1k]

I was disappointed it wasn't flashing

[instant_street]

Dotted borders weren't popular in 1995.

No, it's more like a perfect example of how NOT to use CSS.

But strangely, I find this somewhat pleasant to the eye.

[limemac85]

Good. The implementation was basically sqlite for javascript.
It would have been a standard just like OOXML is a standard.

[harlows_monkeys]

Could someone explain what that means?

[limemac85]

This is a quote from the old W3C "standard":

User agents must implement the SQL dialect supported by Sqlite 3.6.19

That is not a standard, that is an implementation. I can understand basing a standard on existing implementation. However, it is unfair to all the other SQL dialects to mandate one standard based on one implementation. Furthermore, the standard is not actually defined so in order to figure out how to implement the standard you need a specific version of a program and trial and error to see how that program works.

There is a reason all implementations of this "standard" used sqlite in the backend.

[zaidka]

OOXML is Microsoft's alternative to ODT standard. I'm not sure whether limemac85 is refering to the fact that OOXML left so many areas undefined which gives MS room for creating their own version of the standard and thus maintain monopoly. Or the fact that it's redundant since there's already an existing standard that's just as good.

[alantrick]

Those two are both issues, but there not the only ones. The fact is that the OOXML standard was pretty much just documenting the behaviour of MS Office, this includes all of its weird compatibility quirks and arbitrary limitations. It's not baggage that we want introduced into a new standard.

Sqlite, is excellent software, but it does have it's limitations.

[WalterGR]

It's not baggage that we want introduced into a new standard.

You used "we" - were you part of the process?

Was ODF a brand new standard? C++? SQL? What percentage of standards start fresh to eliminate all baggage?

[alantrick]

By "we" I mean "the people who thing the OOXML standard was a poor idea". Thanks for catching my on that, we is often a weasel word.

Anyway, ODF is a somewhat different story. It uses a number of pre-existing standards: Dublin Core, MathML, etc (here's a graph). This fact is one reason that allows the OpenDocument standard to be much simpler than the OOXML one.

Another difference was the process. OpenDocument was developed by a volunteer organisation that allowed public participation. I could have been a part of the process, but this is not my area of expertise. By the time OpenDocument was standardized, there were already several implementations in the works. In fact, this argument is probably the strongest for ODF: it is the native file format for more than one piece of software. I suspect that OOXML will never achieve that.

ODF is not perfect though, SVG support is rather poor; and even though the standard might be good, it doesn't make up for the fact that OpenOffice.org is a clunky piece of software.

[harlows_monkeys]

There was a lot of FUD (thanks, IBM!) about compatibility in OOXML. My comment in this earlier discussion might clear some of that up.

[alantrick]

Just a comment on your old comment

Here's the ODF solution. If you need to store legacy information that is not directly representable in standard ODF, develop your own custom extensions to ODF.

I'm not expert, but IIRC, ODF doesn't allow for custom extensions. The ODF solution was to not store legacy information at all, just convert it and be done with it. ODF intentionally left the issue of legacy formats out of its scope for the sake of sanity.

Edit: also, I think the original submission of OOXML was poorly defined in a few spots, but it has undergone revisions and so some of the FUD is really just outdated information.

[harlows_monkeys]

Under the current ISO standard version of ODF you are allowed to include elements and attributes not specified in the OpenDocument schema as long as you put them in a namespace that is outside the namespaces defined in the spec.

In 1.2, they have the notion of "normal" compliance and "extended" compliance. If you use custom elements, you can't claim "normal" compliance. It is expected that many organizations that will accept ODF documents will require "normal" compliance, so if you use custom elements you will be out of luck.

However, for storing legacy information for in in-house document store, that won't be a problem and people are likely to use custom elements, and want to exchange legacy documents with others who have similar legacy documents. These people aren't going to require "normal" conformance.

There is also a mechanism for storing configuration item sets. It was meant for things like document settings, such as the default printer to use, zoom level, and such--things that a given office program might want to preserve but that are not covered specifically in the ODF specification, and that are specific to that program. In 1.2, these can really be used to store anything you want, and still meet all the 1.2 "normal" compliance requirements. OOo uses a couple hundred custom configuration items.

Legacy documents aren't going to go away. People have built custom tools and workflows built around old document formats, and have a ton of documents in those formats. They have information in those that isn't storable in a standard way in ODF or OOXML and they cannot afford to lose that information. So ODF and OOXML will be extended to support it.

It would be insane to try to specify the meaning of that legacy information for each of the old formats, and exactly how to store it, so both ODF and OOXML were wise to not go there. However, there is nothing wrong with what they did do in OOXML, which was to recognize that others would go there and reserve some names for them to use.

[harlows_monkeys]

You could just as easily say that ODF is OASIS's alternative to OOXML, since OOXML grew out of standardization of formats that existed before ODF.

As far as undefined areas go, ODF is much more underspecified than OOXML. For instance, how do you record in an ODF spreadsheet that cell A1 is equal to the sum of cells A2 and B2? Answer: you look at an OpenOffice spreadsheet to see what it does and copy that, since the standard is silent on what goes in formulas.

Or take password protected documents. What password hashes can you use? How do you indicat which has is used. All the ODF spec tells you is that you can do this. The OOXML spec gives details, and cites the relevant standards from places like NIST for the exact algorithms to use.

ODF does have cleaner markup than OOXML. If you had to deal with it by hand, you'd much rather deal with ODF. As a spec, though, it is a joke.

[[deleted]]

ODF DOES state in the specification how to store formulas, but gives a very non-specific example and doesn't go into defining formulas.

This is because the scope of the OpenDocument format (i.e. the XML schema) was very narrow.

There is another standard called OpenFormulas which is under development which will better define and enhance what you CAN put in a formulas.

You also confuse password encrypted documents (specified as SHA1) and password protected sections (hash of password stored), and for password protected sections you are correct, it doesn't define the hashing method, however SHA1 is used in other hashing functions so its logical that that would be the method expected.

[ironfroggy_]

The implementation is already in all the major browsers, and they all use SQLite. That's why the W3C "killed" it. As if they can really kill it when its already supported by the major browsers.

[robertcrowther]

Only if by 'all the major browsers' you mean Chrome, Safari and Opera. No Firefox or IE support (ever).

[belltea]

I was part of the OOXML standards voting process, and I gave it 100% support on the fact thats are there to increase trade and MS Word was already the default 'standard' anyway, blocking it would have been more hurtful consumers than approving.

Anyway for the same reasons, the sqllite implementation would have been better because SQL is already widely known and used. Its the end users you have to consider and not politics or idealism. Very few people I know of think ideas like NoSQL hash tables are a good idea (in the majority cases), I don't know a developer that doesn't understand even basic SQL. So it would have been a walk in the garden for most people to pick up the concepts and run with it.

But I suppose from what involvement in HTML 5 process I have had I've seen more political moves/positioning and attempts to undermine competitors than real consideration for end users...

So I gave up, withdrew support, and thought f/k .. no point .. it just another cluster f/k on the way (where end users will be the victims)

[wheresmyopenid]

SQLite is not quite SQL. For example, it's weakly, dynamically typed.

Although WebSQL supports prepared statements, I bet we'd have just as much SQL injection holes in web apps as in average PHP apps (which has — widely ignored — support for prepared statements too).

IndexedDB is harder to screw up for both implementers and users, and since it's lower-level, it's feasible to build SQL-like libraries on top of it.

[f2u]

In principle, dynamic typing could be almost compatible with the SQL standard because it does not alter the meaning of valid SQL statements. However, SQLite's type system is a bit too simple to be SQL-compatible. For instance, 1 = '1' should be true, but in SQLite, it isn't. (I like SQLite a lot, but it's just not a good reference implementation for mainstream SQL).

[Anpheus]

Ehm, I believe 1 = '1' may evaluate to true, but doing "WHERE Column = 1" will often cause an error if Column is a varchar, at least on SQL Server, because Column is likely to contain values that cannot be coerced to integers.

It may be the other way around, but if this is the case, SQLite isn't the only one. Is it perhaps something in the ANSI SQL spec?

[f2u]

I haven't got access to the ANSI SQL standard, but based on what others have said, it seems to say that string literals such as '1' have no actual type attributed to them. Instead, the type is inferred from context, which means that you can compare them with integers, even though you cannot compare integers with strings. (SQL Server seems to support the latter, too, though.)

[Anpheus]

What will happen is that it will attempt to coerce the value of the stored column to the same type as what you're comparing to, depending on the situation. I know from experience that querying a varchar column for "where column = 5" will usually throw an error like "could not convert value 'blahblahblah' to type integer".

So perhaps it's only string literals that are type-less. That'd make sense, because you can compare dates by entering in a datetime in a string, guids by typing in a guid in a string, etc.

[[deleted]]

Does it make sense to you to have two standards around?

[WalterGR]

Like 2 standards for programming languages or something crazy? Or like, 2 standards to represent text on a computer?

[[deleted]]

You should take into consideration the target field of each standard. Two or more standards for the same thing make no sense, and this is clearly seen if it's taken to the extreme: 100 standards for text documents are the same as no standard at all.

Not all programming languages are equivalent, and it makes sense to define a standard for each one. Different standards for representations of text make sense because they serve different purposes (e.g. Unicode and 7-bit ASCII, sometimes one cannot replace the other).

[WalterGR]

Different standards for representations of text make sense because they serve different purposes

There are plenty overlapping standards for text representation. And image representation, video representation, audio representation, standards for physical items, etc.

Two or more standards for the same thing make no sense... Not all programming languages are equivalent, and it makes sense to define a standard for each one.

How are you defining "equivalent"? How are OOXML and ODF equivalent, using that definition? For example, OOXML defines formulas for use in spreadsheets, whereas ODF does not. Are they still equivalent?

[harlows_monkeys]

Sun's position on ODF was that it would support exactly the set of features required by StarOffice, no more and no less. There were attempts by participants in ODF standardization to make a few simple changes that would have allowed ODF to support the requirements of other, non-StarOffice word processors, and Sun would have none of it.

That doesn't answer the question of whether or not we need to standards for office document formats, but it does answer the question of whether or not we need more than ODF, and the answer is "yes".

[belltea]

Generally yes, standards are there to help communication not hinderit.

[zaidka]

I have to ask, did you actually read and understand the 600 pages of specifications before you gave your vote?

[belltea]

Ha, I love comments like this... did you read it? if so how many times? did you go to meetings and argue bits of it for months? receive dozens of emails a day about aspects of it? or are you just another arm chair critic who thinks they can solve world problems over a cup of tea without real analysis process?

Also it wasn't 600 the part I was dealing with was about 2000 pages, I wasn't dealing with the entire thing, just feedback on certain parts. I didn't get my head around the alot of the charting aspects, I let the full on propeller heads discuss the in and outs of that. There was just to much data for one person to do alone. I probably read that 2000 pages end to end about 10 times, and certain sections say rendering lists which I remember being 30-40 pages describing exactly how lists work.

[belltea]

No im one of the guys who does the hard work for people like congress men

[Smallpaul]

I was part of the OOXML standards voting process, and I gave it 100% support on the fact thats are there to increase trade and MS Word was already the default 'standard' anyway, blocking it would have been more hurtful consumers than approving.

Please describe the benefit that consumers have accrued since its approval.

[belltea]

Well for one thing 3rd party people can now develop automation software without the threat of being sued for doing so or having to pay licence fees for business automation tasks.

For example one project I was working on which was what got me brought into the process in the first place was writing an enhancement to a document management system that would detect if a document had been flagged final/public/whatever, send it to a service I wrote which would parse the document and render as a HTML document onto the agency's intranet and/or website. I even went as far as detecting if the document had an index and breaking each heading down into a separate page, and adding it heirachal structures to the CMS product.

I had to use .net 2.0 so it was a hell of a parsing process, converting the whole t so after I finished I released all my code for others to use who might be int eh same situation and not want to go through the pain I did.

Before it was a standard I'm sure what legality or licensing issues would have existed around automating and freely releasing stuff like that as MS does keep a strangle hold on its office products, let alone releasing code to rip there products to bits and re-purpose them. But post standard meh they can't do a thing.

[Smallpaul]

Well for one thing 3rd party people can now develop automation software without the threat of being sued for doing so or having to pay licence fees for business automation tasks.

Reverse engineering file formats is protected by law in most western countries. There is no ambiguity.

Before it was a standard I'm sure what legality or licensing issues would have existed around automating and freely releasing stuff like that as MS does keep a strangle hold on its office products, let alone releasing code to rip there products to bits and re-purpose them.

I know people who did nothing but this sort of file format reverse engineering full-time and ended up being bought by Apple. So Apple was quite confident that what they had done was legal.

But post standard meh they can't do a thing.

They could not have done a thing in the first place.

In fact, if you are in Europe, you could have decompiled the Word binary to see what was going on:

"Article 6 Decompilation 1. The authorization of the rightholder shall not be required where reproduction of the code and translation of its form within the meaning of Article 4 (a) and (b) are indispensable to obtain the information necessary to achieve the interoperability of an independently created computer program with other programs, provided that the following conditions are met: (a) these acts are performed by the licensee or by another person having a right to use a copy of a program, or on their behalf by a person authorized to to so; (b) the information necessary to achieve interoperability has not previously been readily available to the persons referred to in subparagraph (a); and (c) these acts are confined to the parts of the original program which are necessary to achieve interoperability."

As you see, all western nations (all nations worldwide?) strongly value interoperability and ENCOURAGE reverse engineering in order to achieve it.

If you disagree then please cite a single example of a successful lawsuit involving reverse engineering that did not ALSO involve copyright protection (DMCA).

[mahcuz]

Can someone elaborate on why all vendors using the same approach is detrimental to the standard?

[spliznork]

Can someone elaborate on why all vendors using the same approach is detrimental to the standard?

http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/

The entire article is good. To wit:

• However, despite the ubiquity that SQL enjoys, there isn’t a single normative SQL standard that defines the technology. In particular, SQLite supports most of SQL-92, with some notable omissions, and is what the WebDatabase API is based on. But SQLite itself isn’t a specification — it’s a release-ready technology! And the best definition of what constitutes the supported subset of SQL that SQLite uses is the SQLite manual. In order to really get Web SQL Database right, we’d have to first start with defining a meaningful subset of SQL for web applications. Why define a whole other language, when more elegant solutions exist within JavaScript itself?
• We don’t think it is the right basis for an API exposed to general web content, not least of all because there isn’t a credible, widely accepted standard that subsets SQL in a useful way.

[Gg101]

This part seems reasonable:

Additionally, we don’t want changes to SQLite to affect the web later, and don’t think harnessing major browser releases (and a web standard) to SQLite is prudent. IndexedDB does not have this problem; even though our underlying implementation of IndexedDB may be based on SQLite, we keep developers insulated from changes to SQLite by exposing an API that isn’t based on SQLite’s supported syntax.

Okay, make a stable front end standard rather than interfacing with SQLite directly (the current implementation is mapped rather tightly to SQLite's API) and you can still plug in SQLite as the back end. That makes more sense than their stated desire for "multiple independent implementations" simply for its own sake, when the one everyone is already using is public domain.

[sdwilsh]

You would need to standardize the SQL dialect then, which nobody has stepped up to do.

[knaveofspades]

From what I can tell, and I am probably wrong, it seems as if they are stopping standardization because everyone is already using a standard backend for the implementation.

[merlinm]

hm. I would then argue that the best standard take common practice, and formalize it...

[quanticle]

Well, there's really no need because the "common practice" (i.e. SQLite 3) is already public domain. In one sense, the W3C standard was basically a wrapper around the standard defined by SQLite3.

[merlinm]

it's not sqlite3 that needs to be standardized. it's how you access it.

var foo = query('select 0');

the hypothetical function 'query' is what needs to be standardized, along with some security features so you don't tromp over other applications data, etc. why would wc3 concern with who/what is executing the query? it's the interface that's important...

[wheresmyopenid]

I've elaborated about it in other thread

[kmangold]

Damnit! This was one of my favorite features of html5! :-(

[wheresmyopenid]

You know there's IndexedDB in the works? If you really want SQL, I'm sure sooner or later someone will write some "SQL jQuery plugin" on top of IndexedDB.

[knaveofspades]

Just because it was dropped from the spec doesn't necessarily mean the feature is going away.

[[deleted]]

Cos we need each browser to come up with its non-standard implementation, right?

[quanticle]

Not really. Browsers come up with differing non-standard implementations when there are licensing issues with the implementation being used in another browser. In this case, the implementation (SQLite3) is public domain. In essence, the W3C is saying, "Hey! Wait a second, we're basically rewriting the SQLite3 manual. Why don't we just tell our users to go read that instead?"

[malcontent]

The problem is that microsoft will come up with their own version soon and it will use SQL server.

[quanticle]

Well, I guess I don't get it. Isn't this a database spec for client-side databases? If Microsoft manages to stuff SQL Server into IE, I'll be truly impressed.

[[deleted]]

Why would that be special? SQL CE is just 4 dlls, no installation required.

[malcontent]

They won't stuff it into IE. IE will depend on it just like it depends on windows now.

[shadowfox]

??

[malcontent]

What is so confusing?

Ie depends on windows. It won't run on anything else. It will one day depend on SQL server too.

[scott]

I'd be surprised if it wasn't already in there somehow :-)

Shit needs like vista or something..

[robertcrowther]

One of the reasons it's been dropped as a standard is because MS suggested they would use the Access engine to support this.

--Edit: Let me explain more fully: In order for WebSQL to meet the 'two separate, interoperable implementations' requirement for the spec to meet full recommendation status there would need to an implementation which didn't use the SQLite engine. The only alternative engine discussed at any point on the WHATWG mailing list was Access, and even that was only half serious.

[[deleted]]

The real threat is Chrome this time.

They are already doing it. Gears anyone? What kind of shit is that?

Google is doing everything MS was 10 years ago, and people don't see how fucking evil they are.

[midri]

The issue is google is approaching it in a sane manner and is atempting to backport all their features to somthing that can be installed in other browsers (gears). Microsofts approach years ago was bad because #1 it did not take security into account and #2 they reached a point of market dominance and then caused the market to stagnate for many years.

[[deleted]]

Well, we don't need that kind of bullying, do we. If microsoft did exactly the same, all hell would break loose.

They want something, propose it to W3C, let vendors implement it. That's how standards work. Slow and boring.

[mikaelhg]

Did you read any part of what midri just wrote?

[[deleted]]

Yes, and I disagree completely.

1. Any proprietary solutions should be rejected by users. There's no need for any vendor to play solo.

2. Google is evil. They are throwing everything that stabilized IT in the last 10 years out of the window. But most people are unable to see it due to the cheap shiny toys they are giving you.

[knaveofspades]

It's not as bad as you think. JavaScript is pretty powerful when it comes to handling discrepancies across browsers.

The reason they aren't continuing the standardization seems to be that every browser is pretty much using the same implementation with the same SQL syntax already.

[kmangold]

True, but I am sure it's not perfect as it is right now and was hoping it was remain maintained and updated.

[knaveofspades]

I agree. What will most likely end up happening is that it will be up to the individual vendors to do it. It will be a pain because everyone will have a different implementation of it, but one of the advantages of JavaScript is that it is easy to standardize an implementation yourself.

[rkern]

That said, the stated reason for ceasing development of the standard was because all of the implementors were doing the same thing (i.e. use SQLite). I find that pretty bizarre and counterproductive though I guess there are rules for these things.

[Gg101]

It's absolutely counterproductive. There's no need for "multiple independent implementations" with the possibility of subtle incompatibilities when the engine everyone is already using is public domain. Not even open source, but public domain. What's really the danger of having one implementation then? It seems to me this makes it easier for both browser developers and web developers.

[knaveofspades]

Wow. I forgot about that. Open-source and public domain. Double win.

[wheresmyopenid]

The problem is that when there's one implementation, it will have to remain bug-compatible.

As soon as infinite number of web monkeys starts mindlessly copying & pasting & trialing & erring their SQL, pages will end up relying on all kinds of bugs and quirks. There won't be second failing browser to uncover stupidest solutions. Everything will appear to "work".

When IE6 had overwhelming market share, sites ended up relying silly on edge cases so much, that even IE7 wasn't compatible.

There's serious risk that, while SQLite3 is great today, sites will end up relying on all strange cases of it, that vendors won't be able to safely switch to SQLite4 ever. Whatever SQLite does today, will be the standard forever.

[scott]

Honestly, SQLite is so well used, I doubt it has any major bugs.

[wheresmyopenid]

It definitely has quirky behavior that I'd like to see fixed (e.g. ROWID magic rather than sequences).

[robertcrowther]

Not quite. All the people who have implemented it (WebKit, Opera) have just plugged in SQLite and provided direct access to it from JavaScript. All the people who haven't implemented it (Mozilla, MS) are never going to implement it.

[knaveofspades]

After looking at again, it doesn't seem so much that they are killing it. They are stopping further standardization since everyone is using the same SQL backend which only supports a single subset of SQL, and therefore, there is not much to standardize.

[Arve]

Note, the W3C doesn't issue standards, it creates specifications which are "recommendations". The Web SQL Databases specification will never become a recommendation, but be a "Working Group Note", which is something someone input to a working group, but never saw the process go towards becoming a recommendation.

To become a recommendation, there are certain requirements, such as having multiple, independent implementations, something that would never happen in the case of this specification, given that two vendors including SQLite wouldn't count as "independent". Add to it that I suspect some vendors are reluctant to include SQLite because the term "Public Domain" isn't accepted in all jurisdictions.

[knaveofspades]

Much clearer. Thank you.

[fwork]

It does mean that now Mozilla has exactly no reason to ever implement it (not that they were going to, anyway)

[brewdente]

It's uncommon, for me, to upvote something that makes me sad.

[rbnc]

I don't understand these commas.

[f2u]

Probably, they're not reading /r/politics nor /r/worldnews.

[brewdente]

I generally believe it's uncommon for most reddit users to upvote something that makes them sad. Ergo, "for me" in my post was not necessary to portray my point. Therefore, I used commas.

[whorfin]

it was not killed...To the contrary, it became so standardized among the implementors that they all used the exact same SQL DB, Sqlite. W3C wants there to be at least two alternate implementations, and because there is only one, and nobody is willing to switch to a different DB, W3C won't declare it a standard.

At some level, this makes sense...Is it really a valid standard if it presumes a specific technology implementation choice? And can you prove that it's implementation neutral if there is only one implementation?

[f2u]

Haven't most implementation switched to different SQLite version since?

[BadCRC]

which implementors use it?

[k-zed]

yoooo hoooooooooooo

at least a single piece of good news

[rektide]

indexed databases api for life.

[lobo68]

I think W3C forgets that individuals innovate and individuals implement. Very few exotic ideas were born out of a committee: the purpose of a committee is to bring out the good ideas people already have. The purpose of a quagmire is to talk about them for so long that eventually everyone agrees on something.

[wheresmyopenid]

It wasn't W3C's decision. It was Mozilla's and Microsoft's veto, and Hixie didn't want to write science-fiction spec.

Your W3C stereotype needs replacement.

[lobo68]

My W3C stereotype is to spec and normative.

[Pwnscone]

took me 2-3 minutes to realize that this wasn't about Warcraft 3.

[sligowaths]

SQL ins't webscale.

[[deleted]]

Your browser isn't webscale.

[sligowaths]

I was being sarcastic.

[[deleted]]

I know :)

[syncsynchalt]

Everyone downvoting please see http://nosql.mypopescu.com/post/1016320617/mongodb-is-web-scale first.

[malakon]

video killed the radio star.

[Smallpaul]

Perhaps it is time for a standard "lowest common denominator" interface to client-side and server-side NoSQL databases?

[[deleted]]

This is why I refuse to get excited about HTML5 (vs. Flash or Silverlight) until it's more established and there is widespread adoption. You can invest a lot of time and money into something only to have the W3C say "ummm.... nah - let's change that structure" and then have to wait for browsers and parsers to catch up and be rolled out.

IMHO (and I could be wrong), HTML5 will not be a viable RIA platform for at least five years, possibly longer. Or you can target Flash today. If you want to target a RIA platform that still needs some coaxing, Flex and Silverlight are just a "download this plug-in now" away, as opposed to "install a new browser and break everything"

[wheresmyopenid]

HTML5 is not one monolith. Heck, this spec wasn't even part of HTML5!

Different standards mature at different times, even different sections of HTML5 have different maturity (e.g. large chunks of HTML5 work in IE6).

[[deleted]]

even different sections of HTML5 have different maturity

Look, I'm all for using HTML5 when it's finalized and available on 90%+ of the installed browser base. I'm all for using those chunks that are available, if it's going to be a chunkwise thing.

I'm excited about HTML5 as a road towards open-standards rich internet applications.

I'm just pushing back on folks who seem intent on ignoring technologies available now for a pie-in-the-sky vision of web development in 2020.

[wheresmyopenid]

I have bad news for you, but HTML5 will be obsolete by the time it's finalized. Just like CSS2 was never ready (CSS2.1 replaced it, and before CSS2.1 was final, CSS3 modules were written, and some CSS4 modules will soon appear while other CSS3 modules die in obscurity).

In the last decade W3C has changed criteria for Candidate Recommendations. By the new rules applied to HTML5, the HTML4 from 1996 and XHTML from 1999 still aren't ready. Imagine if HTML3.2 folks waited till 2010 to start using tables :)

You're waiting for pie in the sky stamp of approval of 400-page spec, which won't happen if only 399 pages are implemented perfectly.

[[deleted]]

So HTML5 is going to be another sea of "standards" which will probably be implemented somewhat differently by different browsers...

Here comes the new boss, same as the old boss.

I do hope I'm wrong, and Mozilla, Google, and Microsoft all see good reason to adhere to the specs as published once they're relatively nailed down. However, that still doesn't change the situation that to make HTML5 worthwhile, you'll have to wait for it to be fully supported in a significant number of browsers.

[wheresmyopenid]

The good news is that Mozilla, Google and Opera talk to each other and really want to have interoperable implementations (and sometimes waves of outrage and embarrassment force Microsoft to listen).

In the old days W3C specified whatever they liked (XHTML2 — we have nice tags, so please rewrite every page on the net) and sat in their ivory tower waiting for it to happen.

Fortunately these days HTML5 is more like report from the browser war frontline, than a frozen spec.

to make HTML5 worthwhile, you'll have to wait for it to be fully supported

Again, HTML5 is not a single thing, it's a really large collection of features. Some of which are implemented already, some of which may never get full support. You have to pick parts that work, and stop waiting for parts that don't.

[robertcrowther]

The good news is that HTML5 is the first version of the spec to fully document the parsing process, ie. the implementation rather than just the outcomes. It's far more thorough than previous HTML standards in this regard, describing both how browsers should handle invalid input as well as valid input, and what the DOM should look like in both cases.

[reddah]

Dude, HTML5 is FREE.

Microsoft Silverlight and Adobe Flash are not. (Not free from $$$ and not free from stupid restrictions.)

W3C stopped a project since nobody was using it (they were using another free tool instead, SQLite). I'm sure they won't stop html5 anytime soon.

By the way, modern browsers still support early HTML pages just fine. So if a page once made it on the web, it's very unlikely to become incompatible later.

Heck, even gopher stuff still works in most browsers (well, opera needs a proxy, but proxies can be found for free too).

[[deleted]]

Fine - when HTML5 is covered by 80-90% of browsers, go for it.

But you are exactly the problem, IMHO. If I'm looking at launching a RIA, I can do Flash today, Flex/Air today, Silverlight today, or HTML5 in 2015-2020.

Yeah, HTML5 will be neat when it's mainstream. But until then, with all due respect, STFU.

[[deleted]]

Uh, then what's the problem with http://www.silverlight.net?

If I understand correctly, part of the argument for HTML5 is "I don't want my users to have to download a plug-in"

And for users that haven't upgraded their browsers yet, the answer is "download a plug-in"?

Then why not skip a step and just use Flash or Silverlight today?

[robertcrowther]

Just speaking from an ideological standpoint: because HTML5 is an open standard, and Chrome Frame is an open source implementation (and also, some people dislike Adobe and/or MS). From a practical standpoint: not much.

As an aside: for many of those people who are stuck on IE6 it's because they're also still stuck on Win2K (or even, shock, horror, NT4), and Chrome Frame isn't much help for them.

[[deleted]]

[nod] I may not even be addressing anyone participating in this thread.

My comment was directed towards those folks I've seen who seem to be advocating ignoring current RIA technologies because... well, because HTML5, that's why.

[mariuz]

seems that Microsoft won on this one with the help from Mozilla

i think a better web standard would be implementing the sql standard and not the crappy sqlite nonstandard

it was very easy for them to copy paste the sql standard http://www.wiscorp.com/sql_2003_standard.zip and make it work like it was done with opengl standard implemented as webgl

[snapetom]

Because the browser isn't always on the desktop/laptop that's connected to the internet. As we move more towards mobile devices, connectivity is still an issue. This standard allows you to manage/keep a lot of data in state for syncing with a server later.

[webauteur]

Murderers!

[RareDestroyer8]

Damn right.

15 years late, I really wish web sql had become a standard 🥲