No More Version Numbers For HTML

Not a Standard. by Anonymous Coward · 2011-01-20 08:13 · Score: 5, Insightful

If you never finalize it's not a standard. This sounds like a Microsoft move to me.

Re:Not a Standard. by Anonymous Coward · 2011-01-20 08:53 · Score: 4, Informative

The real reason is because the committee which desides whats in the standard couldn't get a consensus, so HTML 5 took forever and its still not a W3C recormendation.
Look at http://www.w3schools.com/w3c/w3c_html.asp
HTML 4.01 became a W3C Recommendation 24. December 1999
XHTML 1.0 became a W3C Recommendation 20. January 2000
On January 22nd, 2008, W3C published a working draft for HTML 5.
So 10 years after xhtml 1.0 we still dont have a W3C recormendation for HTML 5, if HTML 6 carried on business as usual then we would probably be looking at 2025 for it...
Re:Not a Standard. by BoberFett · 2011-01-20 10:37 · Score: 2

That will truly help the industry, when contracts calling for levels of compliance become impossible and designers can never get paid because their work is never compliant.
Re:Not a Standard. by sdiz · 2011-01-20 13:48 · Score: 3, Interesting

You missed all those XHTML 1.1 Modules. That's how W3C wasted all its time.
Original HTML5 draft came from WHATWG, not W3C.
Re:Not a Standard. by Gadget_Guy · 2011-01-20 15:21 · Score: 2

never mind that the standards are developed in cooperation between the browser vendors, and at least two vendors must implement something before it is viable for standardization.
That was the old way of doing it, when Microsoft and Netscape kept adding more and more features in the hope that it would make it into the standard. Think tables, frames, blink - oh wait: thank god it didn't work for blink!
These days it is frowned on to add features that are outside the standards, with a few exceptions like styles with prepended browser identifiers and things hacked into meta tags (like iPhone's ones to control the layout on the small screen which I think should have been a custom style).
However, you are correct that the Microsoft way is to stick to the finalised standards rather than the ones that are still in flux. I think the reason they did this was to avoid a repetition of the box-model saga, where IE had to implement a box model before it was spelt out in any standard. But when the standard went a different way, they were stuck being incompatible with the rest of the world.
This wouldn't be a problem if the standardisation process didn't take many years to finalise. The HTML standard needs to improve in small increments. Not too small, or the browser manufacturers will always be playing catch up, and the user would be expected to upgrade every single time a new version was released. But not too big so that it takes 5-7 years for a standard to become official.

no more numbers! by shadowrat · 2011-01-20 08:13 · Score: 4, Funny

POST!

terrible idea by godrik · 2011-01-20 08:15 · Score: 5, Insightful

You'll get pages that becomes invalid with time despite they were valid before. That sounds like a very stupid idea.

Until you name the revision by dates, which is basically the same thing as giving version numbers...

Re:terrible idea by hedwards · 2011-01-20 08:33 · Score: 4, Interesting

That was my thought, it's tough enough to get browsers in compliance with a specific revision of HTML, now they're wanting to do away with numbering them?

I have to assume that this is an early April Fool's joke or the person suggesting it is full of it. But then again he works for Google and is probably just the sort of arrogant git that doesn't understand the implications of it for people that aren't constantly upgrading their browsers.
Re:terrible idea by Anonymous Coward · 2011-01-20 08:47 · Score: 4, Interesting

Until you name the revision by dates, which is basically the same thing as giving version numbers...
Or names! Firefox supports HTML Insomnia. IE is now on HTML Narcoleptic. Chrome upgrades to HTML Sonambulia. Opera is still on HTML Purgatory, but they will go to HTML Heaven next month. Oh, the possibilities!
Re:terrible idea by msclrhd · 2011-01-20 09:35 · Score: 2

An upcoming revision will make HTML Multi-Freded.
Re:terrible idea by hardburn · 2011-01-20 10:16 · Score: 4, Funny
They'll start naming them the way sequels get named.
- HTML: The Legend Continues
- HTML Unleashed
- HTML: The Next Generation
- HTML Reloaded
- Final HTML Fantasy XII-2
--
Not a typewriter

Thanks google by tokul · 2011-01-20 08:15 · Score: 5, Funny

Now we'll have beta quality software and beta quality standards. Another engineer brainwashed.

Re:Thanks google by Anonymous Coward · 2011-01-20 08:17 · Score: 5, Funny

That's The Google Way, eternal beta.
Re:Thanks google by Skreems · 2011-01-20 11:12 · Score: 3, Insightful

A. I call bullshit on the "more stable" claim, except for a few key architectural decisions that Firefox is implementing as we speak, and B. I call bullshit on the idea that they're entirely a Beta product. Their rendering engine is a solid, stable external system that has gone through many non-beta releases. If they didn't have an 8 year stable product as the core of Chrome, it wouldn't be nearly as high quality as it is.

--
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
Re:Thanks google by tokul · 2011-01-20 18:25 · Score: 2

Meh. Google's betas beat the hell out many others' released software in terms of stability and reliability. Chrome is certainly more stable the Firefox and IE, beta or no.

Standard is not software. It must be reviewed, have fixed have version number and documentation. You can't extend standard eternally and have new standard version every month.
Do you really think that software which silently puts three different entries in system task scheduler for update can be called stable. I would call such piece of shit a spyware. It acts like a spyware. Or Picasa faces feature which remains in listing even when it is turned off.

Without versions... by MrEricSir · 2011-01-20 08:15 · Score: 4, Insightful

...I can always render the latest HTML in Netscape Navigator. Right?

--
There's no -1 for "I don't get it."

Um... by FatSean · 2011-01-20 08:15 · Score: 5, Insightful

People will still need to differentiate between implementations of HTML that have different features...do they expect us all to just use the latest and hope nothing breaks?!

--
Blar.

Re:Um... by I8TheWorm · 2011-01-20 08:19 · Score: 4, Insightful

Yeah, I look forward to the "this site is compliant with some of HTML standards and not others because they're too new. We can't really define that for you because there is no version, so best of luck to you" badges.

--
Saying Android is a family of phones is akin to saying Linux is a family of PCs.
Re:Um... by I8TheWorm · 2011-01-20 09:04 · Score: 4, Insightful

It's still ok. I'll mail him a money order. Unfortunately it's for a higher amount, but he can just deposit it then send me the difference.
All will be well.

--
Saying Android is a family of phones is akin to saying Linux is a family of PCs.

Slow Browsers by Anonymous Coward · 2011-01-20 08:15 · Score: 4, Insightful

Wow, so now my browser has to interrogate every single element on a page to determine what's supported BEFORE going to plugins etc.

Yikes...

Translation by dgatwood · 2011-01-20 08:18 · Score: 4, Insightful

Microsoft got tired of people asking when they were going to fully support HTML 4....

Now everyone will be able to say "We support HTML" even though nobody fully supports all aspects of the spec. Just like today, only nobody will be able to point their finger at any sort of milestone that they missed, so companies that drag their heels in standards compliance end up looking better.

How is this a benefit again? It seems to me that we need smaller, more frequent milestones, not elimination of those milestones.

--

Check out my sci-fi/humor trilogy at PatriotsBooks.

Re:Translation by OnlyJedi · 2011-01-20 09:08 · Score: 4, Funny

Well, if the version numbering converged to something interesting like pi (or e, or the golden ratio) I could see people wanting it.
Then again, that kind of system wouldn't be rational.
Re:Translation by jc42 · 2011-01-20 09:30 · Score: 2

Now everyone will be able to say "We support HTML" even though nobody fully supports all aspects of the spec. Just like today, ...
Yeah, and the major benefit will be that developers of web sites will no longer waste their time trying to figure out what numbered version to declare in their DOCTYPE line, and pointing their fingers accusingly at browsers that don't support exactly that standard. They'll go right to testing against a flock of more-or-less current browsers (plus IE6 ;-), and making sure their HTML works somewhat sensibly in all of them.
Fact is, it has never worked very well to study any particular HTML standard and code strictly to that one. Since no browser actually implements that standard, we have always had to test against what passes for the real world, and tweak our HTML so it passes whatever test browsers the gang we're working with has decided to use.
One of my favorite counterexamples has been the ongoing attempts to persuade us to stop using the <center> tag, and replace it with CSS. It's funny to read the various suggested CSS "solutions" for this, then try them out against whatever browsers you've collected, and find that they don't work for some significant subset. Eventually you decide to just shrug and go with the center tag, which works (nearly) everywhere, and is syntactically simple. But lots of developer groups waste a lot of time fighting idiotic things like this, trying to follow some supposed expert's idea of the "right" way to do it, then finally giving up and just going with what seems to work (today).
The HTML "standards" are a mess, in large part due to the fact that the commercial browser developers see little reason to bother implementing even one numbered version correctly. This is helped along by management that has a motive to push for "walled gardens" (like IE6 ;-) that intentionally ignore or misinterpret part of the standards. This problem isn't going away. The best thing for HTML would be to face it, and work toward documenting what we might call a "real world standard" that is what most browser writers have deigned to implement. This would have to be replete with warnings about the unsolvable incompatibilities, and advice on either avoiding them or finding a workaround that at least displays semi-sensibly everywhere.
But that's probably beyond the purview of any official standards organization. After all, who would want to admit that the standard that you've worked so long at is being intentionally sabotaged by many or most of the commercial world? ;-)

--
Those who do study history are doomed to stand helplessly by while everyone else repeats it.

Living Standard? by ultranova · 2011-01-20 08:19 · Score: 5, Insightful

So, in the future it's impossible to figure out what browser supports what? Because, after all, browser support is dragging behind years even now. Or is that the very goal of Google? Make Chrome the de facto standard, and force everyone else to play the catch-up game?

Seriously, don't do this "living standard" crap. At the very least use minor version numbers to identify a given set of standards. Don't force me to guestimate how a web page I write today is going to behave in browsers 5 years from now; let me specify what behaviour I want.

--

Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

Re:Living Standard? by Daniel+Phillips · 2011-01-20 10:57 · Score: 2

Instead of doing this stupid thing a mechanism similar to OpenGL extensions would make far more sense. It has worked well for OpenGL, allowing vendors to innovate while providing application programmers a clear definition of what facilities are/are not available on a given platform. Yes, it requires the application programmer to implement fallbacks in some cases but this is not worse than the html situation today.
It is really, really important to be able to evaluate objectively the degree to which a browser implements html standards. This new brain addled flight of fancy flies in the face of that.

--
Have you got your LWN subscription yet?

Problem by Improv · 2011-01-20 08:19 · Score: 5, Insightful

There will be no way to pressure browser developers to be compliant with "NGHTML 4.7" if we can't even talk about it because it lacks a name. It'll also be hard to enumerate features of releases, to decide what version of the standard we're talking about and have programmatic support for that, etc.

This eliminates most of the benefits of having standards to begin with.

--
For every problem, there is at least one solution that is simple, neat, and wrong.

So instead... by DoofusOfDeath · 2011-01-20 08:20 · Score: 4, Interesting

So instead of versions, we'll have a big vector of flags, where each flag indicates whether or not a particular HTML feature is required, supported, etc.? And a given web page will work with a given browser only if their two flag vectors are compatible?

This is stupid. Standards exist for a reason.

Re:So instead... by mini+me · 2011-01-20 08:57 · Score: 2

We'll have exactly what we have now. Browser vendors were already adding draft features into their product before the specification was finalized. Just look at how many browsers support HTML5 features, even though HTML5 does not exist as a standard yet.
Re:So instead... by owlstead · 2011-01-20 09:32 · Score: 2

I was going to mod, but I cannot let this pass. Browsers have always added features that's true. And in some ways it is required, you cannot make progress by mindlessly adding to the standard, you will have to try out new features first.
But any *mainstream* site should be able to choose a HTML version to support, maybe taking into account some features that are badly supported by the browsers. This way you can be reasonably sure that most browsers (and with the internet appliances market soaring, there are many important ones) will parse & display the page as intended.
Now if you remove this idea of a base set of features, which is captured in the version number, you are left with checking each and every device. There are already too many choices within most standards - the more choices of differentiation, the more bugs and incompatibilities.
I'm involved in some international standardization, and it's mind-boggling how many unneeded choices are added to standards in the name of technology, flexibility and - of course - politics. Each and everyone adds to at least another branch in source code to test. Some choices are so uncommon that they are never really tested at all (and you can imagine what happens if they are encountered).

Linked blog article is fluff with no insight by Anonymous Coward · 2011-01-20 08:21 · Score: 5, Informative

Go straight to the source instead.

Re:Linked blog article is fluff with no insight by Anonymous Coward · 2011-01-20 10:06 · Score: 5, Informative

Indeed, and as that article points out, this change in naming applies ONLY to what the WhatWG was calling "HTML5", not to be confused with what W3C calls "HTML 5." For anyone that's been following this, or has read Zeldman's HTML5 book, knows, "HTML5" and "HTML 5" can refer to entirely different sets of standards.
The W3C, as far as I can tell, is still taking "snapshots" of WhatWG's "HTML" spec and numbering them, and the W3C is still the primary authority when it comes to official web specifications.
This change really isn't as big of a deal as people here seem to think, and the original article does confuse the issue.
Re:Linked blog article is fluff with no insight by The+Moof · 2011-01-20 10:29 · Score: 3, Insightful

I'm guessing we've all had a project killed by feature creep, and they haven't. Essentially, that's what they're proposing: a spec with features constantly in flux without any milestones to aim for.

Just like Chrome? by Anonymous Coward · 2011-01-20 08:21 · Score: 4, Insightful

Do they mean the browser Chrome? As in Google Chrome 8.0.552.237?
Is 8.0.552.237 not the version?

Re:Just like Chrome? by Bill_the_Engineer · 2011-01-20 09:18 · Score: 4, Funny

You're still out of date. I have the latest bleeding edge version of chrome. I'm running Chrome: living standard edition.

--
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...

Re:Internet/server backed "Apps" are the web 3.0 by jimmerz28 · 2011-01-20 08:24 · Score: 2

Really? That's weird because I thought browsers were waring over who could get HTML 5 features out first, who had the most, and showing them off.

But I might be totally crazy.

Re:Internet/server backed "Apps" are the web 3.0 by MightyMartian · 2011-01-20 08:25 · Score: 3, Funny

And what is this jet you speak of? Javascript, CSS, DOM? If these are jets, then someone put the turbines in backwards, pasted the wings on with glue sticks, and is using banana peels as fuel.

--
The world's burning. Moped Jesus spotted on I50. Details at 11.

Re:Irrelevant information about irrelevant topic. by Panaflex · 2011-01-20 08:28 · Score: 2

yes, it'll matter because the back end is still HTML. And not everything that creates and renders HTML is dreamweaver, firefox or iexplorer. And while management practices do not matter, specifications and implementations DO matter. Most especially, for those that rely on accuracy. product comparisons, and compatibility.

--
I said no... but I missed and it came out yes.

Huh? by gstoddart · 2011-01-20 08:28 · Score: 3, Interesting

Since when did Google become the keepers of the HTML spec?

I think a randomly changing feature-set sounds like a bad idea. HTML is supposed to be a standard, not something which just changes without any real control behind that.

This is like agile programming run amok -- let's expect the customer to have to upgrade to the latest nightly build. That'll work!

--
Lost at C:>. Found at C.

Re:Huh? by DragonWriter · 2011-01-20 09:27 · Score: 3, Informative

Since when did Google become the keepers of the HTML spec?
Google is not "the keepers of the HTML spec". Ian Hickson, who happens to work for Google, is the editor of the HTML5 spec. Usually, spec maintainers work for a firm involved in the area the spec addresses.

I think a randomly changing feature-set sounds like a bad idea.

In none of the discussion of this change has there been any indication that the WHATWG process for HTML will involve random changes.

HTML is supposed to be a standard, not something which just changes without any real control behind that.
There is a process, which is discussed in the WHATWG FAQ. The process just doesn't involve version numbers anymore.
Re:Huh? by msclrhd · 2011-01-20 09:58 · Score: 2

Version numbers? Where we are going, we don't *need* version numbers!

Their justification FAQ: by Anonymous Coward · 2011-01-20 08:37 · Score: 5, Informative

Their justifications for the decision are here:

http://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F

it just seems appropriate by Anonymous Coward · 2011-01-20 08:39 · Score: 5, Funny

GET!

Re:it just seems appropriate by gorzek · 2011-01-20 08:47 · Score: 2

REST!

--
Check out my world simulator thingy.
Re:it just seems appropriate by Art3x · 2011-01-20 13:22 · Score: 2

DELETE!

I can't up-moderate, so i'll just say it by BlakJak-ZL1VMF · 2011-01-20 08:44 · Score: 2

+1 to everyone who thinks this is stupid. In particular given how significant HTML is to the web-as-we-know-it surely there must've been some consultation before making a call like this? With a cacaphony of "NO" coming through here (and very little, if any, support) one has to wonder....

--
-.-. --.-

Bad engineering by cjcela · 2011-01-20 08:44 · Score: 2, Insightful

We are in the hands of morons. A constantly evolving standard is bad news for everybody except maybe a few companies that sell HTML development tools. Fast forward 10 years, and we will not be able to read half of the web, and will need 10 different browsers to see our usual choice of sites. There is a reason for versioning. Keeping up with a website will be a pain. I guess I should not complain, many people will have a job thanks to this.

Re:Internet/server backed "Apps" are the web 3.0 by hedwards · 2011-01-20 08:47 · Score: 2

It's a typical problem, the browsers battle it out first, then applications and sites tend to pop up. Which makes it a bit awkward at times.

From what I can tell, they're opting to keep the aspect of HTML which is more or less the most broken under the justification that they've always done it that way, regardless of the fact that HTML5 was mostly supposed to be changing that. A new set of standards that both modernized and theoretically was implemented by all the browsers.

It's more or less inevitable that what's going to end up happening is a rehash of the Netscape versus IE battle of the 90s and a return to fragmentation. It might not be intentional, but if the standards keep changing it's going to be a real challenge actually cruising the web.

Er, Why use Version Numbers At All? by swsuehr · 2011-01-20 08:50 · Score: 5, Interesting

I broke the cardinal rule and read TFA. From TFA:

"Hickson mentions that the group will be dropping the HTML5 name immediately, but it we have not received a confirmation that this will happen over at the W3C as well."

So WHATWG will no longer be using numbers? WHATWG can call it "Hullapuhjelpus" as far as I'm concerned as long as W3C still continues using version numbers. Version numbers provide excellent reference points to featuresets and are useful to implementers, developers, and end users alike.
From the WHATWG Blog:

"However, shortly after that we realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call "HTML5" complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves."

Because there's demand for new features you no longer want to use a numbering scheme? Many standards are evolving. Why not just increment the minor version when new features are added? HTML version 5.1 added this cool thing, 5.2 this cool thing, etc.

If we're dumping version numbers then why bother calling it Internet Explorer 6, 7, 8, and 9? Why not just call it "Internet Explorer"? We all know that each of those versions render pages the same, right? Hmm. I just realized that I invoked Internet Explorer in a discussion about standards. Mea Culpa.

How does removing the version number help the people who need to implement and work with the standard?

Re:Er, Why use Version Numbers At All? by Bogtha · 2011-01-20 09:38 · Score: 5, Informative

How does removing the version number help the people who need to implement and work with the standard?

It doesn't, it's a fucking disaster. I'll give a concrete example. I used HTML 5 audio on a site with a Flash fallback for browsers that didn't support it. All is good and well. One day, I start getting complaints that the audio is broken. Turns out that a) the HTML 5 spec had changed and b) Firefox had changed to match in a minor point release. Firefox 3.51 worked, Firefox 3.5.2 didn't, as I recall. The new API was indistinguishable from the old API in as much as all the same objects and functions were there, but a return value had changed. So, even with the best practice method of feature detection, anybody writing to the old API was screwed.
So I fixed it up by removing the HTML 5 audio and made the decision to wait until HTML 5 was published in its final form. Something that I should have done to begin with really, it's madness to use HTML 5 at the moment as it's just not finished yet. You don't know what is going to change.
And now they want to do away with a "final" version altogether? Gee thanks, guys! How am I going to be able to trust it to be stable enough to rely on ever again? What's going to stop the same thing from happening over and over again?

--
Bogtha Bogtha Bogtha

Version numbers not related to issue by DragonWriter · 2011-01-20 08:55 · Score: 5, Insightful

You'll get pages that becomes invalid with time despite they were valid before.

That is a result of backward-incompatible changes, not the absence of version numbers.

Re:Version numbers not related to issue by EdIII · 2011-01-20 10:08 · Score: 4, Insightful

You'll get pages that becomes invalid with time despite they were valid before.
That is a result of backward-incompatible changes, not the absence of version numbers.
Quite true, but what I think the poster was saying is that without version numbers it would be impossible to claim they were "standards" compliant at any one time. So even if you wrote very good code that was compatible across 99% of all browsers out there, a few years go by and you look like lazy morons that just don't care.
As for the backwards-incompatible changes, without version numbers you would really have no way to tell what you are doing anyways. Since you can't reference it by version number you would be forced to reference by a specific instance of a problem. The newest Firefox blah blah blah tends to have a problem with this, this, and this, and Opera v.x tends to have a problem with that, that, and that.
Next thing you know the browsers will go versionless too and then at that point all you can do is drink heavily.
Re:Version numbers not related to issue by DragonWriter · 2011-01-20 10:19 · Score: 2

So even if you wrote very good code that was compatible across 99% of all browsers out there, a few years go by and you look like lazy morons that just don't care.
That doesn't happen unless the standard is accepting backwards-incompatible changes to widely-established features, which they've committed not to.

As for the backwards-incompatible changes, without version numbers you would really have no way to tell what you are doing anyways. Since you can't reference it by version number you would be forced to reference by a specific instance of a problem. The newest Firefox blah blah blah tends to have a problem with this, this, and this, and Opera v.x tends to have a problem with that, that, and that.
Which is what you have to do with features in the real world anyway.
Re:Version numbers not related to issue by Haeleth · 2011-01-20 11:14 · Score: 2

That doesn't happen unless the standard is accepting backwards-incompatible changes to widely-established features, which they've committed not to.
Provided you only use "widely-established" features. Which ones are those, specifically? Because they certainly have not made any commitment to reject backwards-incompatible features in general. Quite the opposite: they make it very clear that if they decide something is "broken", they will change it without warning. Hope you weren't relying on that "broken" behaviour.

Bad interpretation by robmv · 2011-01-20 09:09 · Score: 4, Informative

What was said is that the moving spec in development is now called HTML, when a snapshot is taken it will be called HTML5, next HTMLX.X.X or any other name. The WHATWG spec is not a finalized document, HTML5 will be snapshoted sometime

Forever in beta. by westlake · 2011-01-20 09:18 · Score: 4, Interesting

Ian Hickson, a Google engineer and editor of the HTML5 standard announced that the language will be transitioned to a 'living standard' without version numbers. A bit like like Chrome, if you will."

The HTML standards committee takes eternity and a day to finalize anything.

Which is how and why workable solutions - like Flash - that evolve outside the committee gain traction.

20% of peak hour Internet traffic in the states was a content-protected Netflix stream before Netflix offered a streaming-only service. HVEC - aka H.265 - will be ready in about two years. High Efficiency Video Coding / HEVC / H.265 : Beyond H.264

Half the bit rate of H.264 for content of the same quality...

Re:Forever in beta. by Art3x · 2011-01-20 15:29 · Score: 3, Insightful

The HTML standards committee takes eternity and a day to finalize anything.
Exactly. Ten years passed between HTML 3 and 4. Another ten have now passed from 4 to 5, and 5 is still not an official standard.
Meantime, requests for features and API tweaks flow in, and all browsers are going ahead and building them (even IE!). If you froze the spec after so many features, you would be drafting HTML 8 before HTML 5 became standard.
Second, I don't know about you, but I write web apps for a living, and I've used HTML since 1997, and never once did version numbers help me. By the time I got serious, it was HTML 4. But none of the browsers posted anything like "we are an HTML 4 browser," and if they did, they lied, especially Internet Explorer. To know what worked, you tested and read about tests other people did on each the browsers.
Finally, the term "HTML 5" has already been stretched so much to be meaningless. I'm not even talking about the journalists who use it to mean things that you could do with 4. HTML 5 is huge: Canvas, video, audio, three persistent storage APIs and one session storage API, various APIs to do with the web address, geolocation, and others. Does a browser need to call itself HTML 4 until fully implements all of these? How would that help me?
The only thing I have ever really looked for are those comparison tables with the red and green squares, like we've always done, to figure out what to use in my web page next.

Moving Targets by theshowmecanuck · 2011-01-20 10:50 · Score: 2

Now browsers only have to support moving targets.

--
-- I ignore anonymous replies to my comments and postings.

The standards are too complex by bradley13 · 2011-01-20 22:57 · Score: 3, Insightful

HTML 2/3/4, XHTML/1, and CSS/1 were all small, simple, understandable standards. Then the web got popular - in part because web standards and technology were so simple. Once the web had exploded, every damn company wanted to stick its oar in. CSS 2 took years, is overly complicated, but still just barely manageable. Look at CSS 3 - everybody's special wishes are in there - the thing is immensely complex and as a standard, frankly, it is therefore nearly useless. HTML 5 is much the same - too many special wishes and fancy features. One needs to take a weed-whacker to it and to CSS, to restore some degree of simplicity.

Think of it this way: why is there a competition to see how well browsers score on the ACID tests? The standards ought to be simple enough that any decent browser scores 100%. The fact that this is not the case is proof that the standards are far, far too complex.

--
Enjoy life! This is not a dress rehearsal.

Slashdot Mirror

No More Version Numbers For HTML

58 of 336 comments (clear)