W3C Says Don't Use HTML5 Yet 205
GMGruman writes "InfoWorld's Paul Krill reports that the W3C, the standards body behind the Web standards, is urging Web developers not to use the draft HTML5 standards on their websites. This flies in the face of HTML5 support and encouragement, especially for mobile devices, by Apple, Google, Microsoft, and others. The W3C says developers should avoid the draft HTML5 spec (the final version is not due for several years) because of interoperability issues across browsers."
So? (Score:5, Insightful)
Re: (Score:2)
Same thing happening with 802.11n
ieee is stuck for so long that vendors have started pushing draft hardware. I can see why they are stuck, my dual mode router still works better on 802.11g compared to its 802.11n, n is choppy, slow and a huge hassels, particularly if u VPN. Clearly there are bumps with the n technology.
Re: (Score:2)
Flies in the Face of Common Sense Too (Score:5, Insightful)
"The problem we're facing right now is there is already a lot of excitement for HTML5, but it's a little too early to deploy it because we're running into interoperability issues," including differences between video on devices ...
Well, I read an entire book on HTML5 [slashdot.org] and, as web developers have usually done, you just build in graceful fallbacks for unsupported browsers or devices. If APIs change, then they change but a lot of developers would probably rather opt for that than something a lot more proprietary and complicated. A whole chapter of the book I reviewed was devoted to extensively detailing how one would get video working in increasingly fallback ways depending on your preference of support. Why can't we keep up that mentality? The worst case is we just default back to the Flash/HTML4 route.
"HTML 5 is at various stages of implementation right now through the Web browsers. If you look at the various browsers, most of the aggressive implementations are in the beta versions,"
Another sage lesson from Mark Pilgrim's book: "Those who ship code win." You can sit there and tell everyone to 'hold on' all you want but if you don't give them a good reason to stop pushing forward with the implementation, they aren't going to wait for your consortium to debate for another five years. We're moving forward. There will be bumps. The time for discussing a completely perfect approach has passed and browsers will thrust what support they can into practice, warts and all. At some point this has to be done, it will never be truly perfect.
Re:Flies in the Face of Common Sense Too (Score:5, Interesting)
Re:Flies in the Face of Common Sense Too (Score:4, Insightful)
"The worst case is we just default back to the Flash/HTML4 route."
Actually the worst would probably be silverlight ;-)
Re:Flies in the Face of Common Sense Too (Score:5, Informative)
A little history about HTML5 books: For the longest time, people held off on publishing because of the same sort of FUD that W3C is spreading. What if it changes? What if I publish and a new feature becomes the hot topic and no one buys my book because I published too soon? But then Bruce Lawson and Remy Sharp published. Then I guess the other publishing houses realized that they'd better publish soon, or else Bruce and Remy were going to soak up all the disposable income that's been waiting on an actual book. So, like, one or two weeks later, Mark's book shipped. Then, like, 2 or 3 weeks later, Peter, Brian and Frank's book. So here's a big Thank You to Bruce and Remy for breaking the ice.
The cat's out of the bag, W3C. People are getting antsy to code. I don't you're going to get that cat back in the bag.
Re: (Score:2)
The most compelling case for anti-virus I've heard for quite some time.
Re: (Score:3, Insightful)
If APIs change, then you're stuck with a lose-lose situation.
Either
1. The browser makers have to support these non-standard (we could even say "proprietary") APIs, or
2. People who designed their sites for draft HTML5 and don't update them may partially work and fail in unexpected ways that the fallback doesn't cover.
We've already had a major electronics corporatio
Re:Flies in the Face of Common Sense Too (Score:5, Insightful)
!surprising (Score:3, Insightful)
I don't really find this surprising in the least. I've been saying this for awhile now. Why would you possibly want to build a professional application on top of what is basically a mudslide? The maintainability alone is completely shot.
Not that I don't think HTML5 will have a huge impact in the future, it's just, I don't know why anyone would make a professional application in it *at the moment*. Better to stick with something that is mature and fully adopted.
Just my $0.02..
Re: (Score:2)
I don't really find this surprising in the least. I've been saying this for awhile now. Why would you possibly want to build a professional application on top of what is basically a mudslide?
The thing is thats how it is now and how it was before HTML5. People are still building websites and using them to make money so it can't be that bad.
Re:!surprising (Score:5, Insightful)
So you would rather have everyone wait for them to "approve" it in 3-5 years, tell people to start using it and then find out that there's problems with real-world use. At which point they have to go back to "debating" how to fix the problems, which might takes another 3-5 years.
Unfortunately, you have to get people to start using it. Better to start finding out about "problems" now before the draft is finalized. As long as people are putting in "safe" fall-backs, then this really isn't a problem. I don't see it as extra work, since I was already having to do this for IE6 anyways.
I see you 2 and raise you another 2.
Re: (Score:2)
So you would rather have everyone wait for them to "approve" it in 3-5 years, tell people to start using it and then find out that there's problems with real-world use. At which point they have to go back to "debating" how to fix the problems, which might takes another 3-5 years.
The nature of standards is such that they're not standards until they're approved and recognized. Flaws within the standards result in further standards and modifications - but at least you can then guarantee a minimum baseline of support. That also includes flaws -- if it fails, it will fail the same way across platforms.
Re: (Score:2)
Back in reality that is not how web standards work out. HTML4, CSS2 and PNG were finalized, did that mean that they were the minimum baseline?
Re: (Score:2)
You will still have the millions of other sites from hobbyists, pet projects, etc., out there who will use HTML5 and find its quirks and problems.
One more note
Re: (Score:2)
There is a big difference between having fallbacks for lacking features and fallbacks for existing features that the user deliberately disables. Having a duplicate version for all javascript (that can be quite a bit these days) in whatever the backend is a much bigger liability then a CSS hack for IE6. That said, it is true that far too few pl
Re: (Score:2)
I don't see why using HTML5 now is a problem, with two major provisos:
Also, lol Slashdot for screwing up <ol> rendering?
Re: (Score:2)
Semantically, an unordered list would make more sense, but an ordered list fits my pattern of speech, so I chose to use it.
And funny, now it's rendering the numbers. Previously, it had displayed characters as if they were child posts folded up.
Re: (Score:2)
I'm writing a "small" (counting the number of templates required) web application at the moment. I've used HTML 5 elements, mostly for my amusement and learning.
The ones I've used are NAV, SECTION and HEADER (and I, in the HTML5 sense). I've also used a few new attributes, e.g. placeholder on a text INPUT field.
I might get rid of the NAV/SECTION/HEADER if I find any problems with IE6, but I think it's unlikely these bits of the spec will change.
Equally I've used some CSS3 stuff, e.g. to do row striping of t
Re: (Score:2, Insightful)
Re: (Score:2)
We use it at work (although many people have semi-officially installed Firefox), on Windows 2000.
We want to upgrade, but the government basically cancelled all IT spending -- it doesn't seem to matter that we've hardly spent anything on IT for the last 10 years and desperately need to upgrade, or that we'd already agreed to purchase PCs (etc) from some companies before the new policy was announced. We've lost money from not buying the stuff we'd agreed to buy, and from wasting a lot of staff time preparing
Re: (Score:3, Interesting)
There is no clear advantage or improvement that HTML5 would provide in delivering information or selling goods to our customers on the web. I don't feel like dropping everything I am doing, to re-write or re-implement everything I have now, and the customer is perfectly fine accepting. NO Client ever cared what language the site is presented in, as long as it looks decent. Html 5 is grand I am sure, but I still present websites in php driven html 3. I have enough on my plate with the
Re: (Score:2)
Not that I don't think HTML5 will have a huge impact in the future, it's just, I don't know why anyone would make a professional application in it *at the moment*. Better to stick with something that is mature and fully adopted.
You mean like (X)HTML4.x(strict|transitional), which is perfectly cohesive, and has identical and unchanging support across all modern browsers?
:-|
Re: (Score:2)
Ha ha, good one!
More evidence of the W3C's increasing irrelevance (Score:5, Insightful)
Re:More evidence of the W3C's increasing irrelevan (Score:5, Interesting)
My thoughts exactly. This reminds me of 'Pre-N' wireless, which took far too long to ratify a standard that was already in wide use. They sat on their asses so long, it became a joke in the industry. If the governing body takes this long to certify it and they are claiming 'years' more in the future before the standard is finalized, then something is broken. This smacks of Google's 'beta' status. Eventually you have to shit and get off the pot.
Essentially they just need to finalize it, and for those bits that aren't production ready, defer them to HTML6.
Re: (Score:2)
Re: (Score:2)
Re:More evidence of the W3C's increasing irrelevan (Score:4, Interesting)
I had to read that part a couple times to make sure it was right. Several years? What are these guys smoking? They actually expect people to wait that long?
Re: (Score:3, Informative)
It sounds like he hasn't actually read the spec, or his comments are being taken out of context (sounds about right for InfoWorld). Different parts of it are at different levels of readiness, and this is indicated in the document itself. It also has a nice indicator of which browsers support which features.
You absolutely should not use HTML 5 now, nor expect it to be stable in the next couple of years. However, there is a large subset of HTML 5 that is stable, well supported, and ready for use now. Not
Re: (Score:3, Interesting)
What we need is "a day in the life of a W3C draft" article to figure out why these standards and recommendations take so long to mature.
Re: (Score:3, Interesting)
In a work placement year I did the major electronics company had a couple of staff on the board for a standard -- it involved lots of XML and internet stuff, so it's not far from the kind of thing W3C does.
What took so long was working out whether technology that required infringing on each company's software patents should be "required" or "optional". In the end, Sony, Philips, Panasonic etc decided to pool their patents (their stuff is "required"), the patent troll companies were excluded by the big compa
Re: (Score:3, Funny)
Re: (Score:2)
Re:More evidence of the W3C's increasing irrelevan (Score:5, Informative)
When the draft spec for a technology that moves so fast and has so much widespread adoption is still deemed several years off I don't know how anyone can take their recommendations seriously. We're already at a level of fairly good interoperability amongst the core browser engines for the base features we need. If developers and designers took any notice of this then we'd probably all be still building sites with tables.
This is why the WHATWG – the body that originally developed HTML5, and which still develops a version in parallel to the W3C – abandoned the idea of rating the stability of the spec as a whole. The WHATWG spec version [whatwg.org] (which is edited by the same person as the W3C spec, contains everything the W3C spec does plus more, and has useful JavaScript annotations like a feedback form) is perpetually labeled "Draft Standard", and per-section annotations in the margins tell you the implementation status of each feature.
The W3C Process [w3.org], on the other hand, requires everything to proceed through the Candidate Recommendation stage, where it gets feature-frozen, and therefore becomes rapidly obsolete. It's quite backwards, but doesn't seem likely to change soon. So for sanity's sake, you can just ignore the W3C and follow the WHATWG instead.
(I really doubt that Philippe Le Hegaret actually said anything like what he was quoted as saying in TFA, though. It doesn't match what I've heard from him or the W3C before – no one seriously thinks authors shouldn't use widely-implemented things like canvas or video with suitable fallback. It sounds more like an anti-HTML5 smear piece. Paul Krill has apparently written other anti-HTML5 articles [infoworld.com].)
Re: (Score:2, Interesting)
._. The original plan of WhatWG was to stabilize in 2022 . Yes. 12 years from now. But the devil is in the details and I am not 100% up to date on the W3C details. I get the feeling that the W3C is trying to be the Debian of standardization organizations though. Slow and stable.
Re: (Score:3, Interesting)
First off, Canvas is fucking redundant and never should have been created in the first place. SVG has existed since 2001
Canvas and SVG are very different. Canvas uses an imperative model, SVG uses a declarative model. Your comment is like saying we don't need OpenGL because we have VRML. Some things are much easier to implement with canvas, some are much easier to implement with SVG.
Re: (Score:2)
Re: (Score:3, Informative)
First off, Canvas is fucking redundant and never should have been created in the first place. SVG has existed since 2001. Canvas is a crappy JavaScript-only version of Canvas with half the features stripped out. There's no reason to use canvas in the first place - just use SVG. Most browsers support it and even if they don't there's good plugin support. And it's an actual released standard.
SVG is a declarative vector graphics format, while canvas is an immediate-mode 2D graphics API for JavaScript. Using SVG for a dynamic web application is kind of ridiculous – something as simple as ctx.fillRect(x, y, w, h) to draw a rectangle would require several lines of DOM methods.
HTML5 video is completely fucking useless, because:
1. You can't stream video. (No, not a file, I mean live video.)
You can stream live video just fine, if the format and browser supports it. I've heard reports of people getting this to work just fine with Ogg. This isn't the big use-case anyway, though.
2. You can't full screen HTML 5 video. (The spec forbids this as a security flaw.)
You can full-screen HTML5 vi
Re:More evidence of the W3C's increasing irrelevan (Score:5, Informative)
This.
The W3C is a running joke at this point. They didn't even want HTML 5 in the first place. Now they're telling people to shy away from it for a few YEARS?
I don't know what Internet these guys are on, but it's not the same one that the rest of us inhabit.
Re: (Score:2)
Standard bodies always fall behind. If you count on them nothing can be done.
For the same reason, let's not abuse the 'standard-compliance' weapon either. We criticized that IE wasn't standard compliant for a long time, and that was not all for a good reason.
Who cares (Score:5, Funny)
IE fault (Score:2)
In the other hand, the main browser that have no clue on what HTML5 is is precisely IE, so now they are getting a bit of their own medicine.
Re: (Score:2)
W3C is the problem (Score:4, Insightful)
It seems obvious to me that you wouldn't use a technology that would work in less than half of the intended audience (unless you make it degrade gracefully).
But the real question is why does it take so long to come up with these standards? HTML5 started by WHATWG back in 2004. CSS3 has been around since 2005. Just get them finalized already. Don't whinge about browsers not fully supporting the standards if you don't give them a fixed document to work towards.
Re:W3C is the problem (Score:4, Informative)
But the real question is why does it take so long to come up with these standards? HTML5 started by WHATWG back in 2004. CSS3 has been around since 2005. Just get them finalized already. Don't whinge about browsers not fully supporting the standards if you don't give them a fixed document to work towards.
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
So it's mostly a matter of limited programming time, nothing mysterious.
Re: (Score:3, Informative)
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5 [opera.com].
Re:W3C is the problem (Score:5, Interesting)
Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5 [opera.com].
I quite deliberately said that Firefox 4 will be the first good implementation of HTML5 form enhancements. I wrote HTML5 form support for MediaWiki, but disabled it – partly because of an inexcusably bad WebKit bug, but also because Opera's support is just cruddy. The UI is terrible – red-bordered boxes that only appear when you try to submit the form, not when you actually do the invalid input.
And I quickly found one killer bug: if a password element doesn't meet its constraints, it outputs the currently-entered password to the screen in plaintext, so <input type=password pattern=....> to require passwords of at least four characters is a non-starter. I reported the bug to Opera around the time 10.00 was beta, and it's still not fixed in 10.60. To replicate, cut and paste this into your URL bar:
data:text/html,<form><input name=foo type=password pattern=...><input type=submit></form>
Then type one or two letters in the password field (not more) and try to submit. So, Opera's great and all, but its implementation of this stinks.
Re: (Score:2)
>To replicate, cut and paste this into your URL bar:
>data:text/html,
>Then type one or two letters in the password field (not more) and try to submit.
Chrome 6.0.472.63 works
Opera 10.62-6438 fails
Firefox 3.6.10 fails
(All on Linux x86-64
Re: (Score:2)
The starting point for Opera is 10.7 and Firefox is 4.x for HTML5 standard support.
Safari, Chrome, Epiphany and other WebKit browsers will all work. Let's test.
Chrome 7.0.536.2 dev: passes
WebKitGTK+ 1.3.4 passes
Safari Release 5.0.2 passes.
Why do they all now work? They work now with the HTML5 Algorithm complete. Go to html5test.com and check against Chrome's latest browser, WebKit Nightly and Epiphany Nightly or Epiphany with WebKitGTK 1.3.4.
Re: (Score:2)
Works properly on Safari 5.0.2
Password masking is the bug (Score:2)
And I quickly found one killer bug: if a password element doesn't meet its constraints, it outputs the currently-entered password to the screen in plaintext
Not a bug. Password masking itself is the bug [useit.com].
Re: (Score:2)
Sorry, but that's just wrong. Sometimes Nielsen has good stuff to say, but at other, he just seems out of touch:
More importantly, there's usually nobody looking over your shoulder when you log in to a website. It's just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.
Who has an office? I don't. Most of my friends don't. If you log in at work, your screen is generally visible. Ditto for on your laptop when your commuting. Home is the only safe place.
In cases where there's a tension between security and usability, sometimes security should win.
Sometimes security should win? Usability's important, but I think Nielsen is over-emphasizing its importance because its his person crusade.
It's therefore worth offering them a checkbox to have their passwords masked.
His solution? Default to insecure and require user-interaction to increase
Re: (Score:3, Insightful)
Because it should. The problem is the idea that you shouldn't implement a standard until its done. The reverse is true: a standard shouldn't be done and frozen until, at a minimum, there exist independently-developed, interoperable implementations that acheive the purpose for which the standard was developed.
A "standard" that isn't implemented at all, doesn't have interoperable implementations, or which has interoperable impl
Why not divide it? (Score:2)
If they can't write specs in less than several years, why not divide html 5 into its core components and concentrate the work on one piece at a time?
They could work on the final specs for the canva element first, then the video tag, client storage, and so on until everything is done.
There could be some kind of a transitionnal html5, falling back to html4 when something is not yet specified.
Awww crap (Score:2)
Guess I'll have to tell my client that we have to stop work on their snazzy HTML5/AJAX site and hold off on it for a few years.
Ohhh wait.... the W3C is a bunch of prudish pencil-necks who move at a snails pace and are generally clueless to how the real world works.
Hey W3C: Bite me, developers will develop no matter what you say.
Slow w3c as usual... (Score:2)
Maybe it's time they speed up their process a little?
Hopefully then they wont be passed by reality which develops at a much faster pace.
And then maybe they can avoid painful hiccups like XHTML 1, 1.5 and 2?
They started off great but more and more they are a waste of money and resources.
Re: (Score:2)
Actually HTML5 would not have existed if we let W3C figure it all out by themselves.
It was actually the WHATWG which started on HTML5, W3C only has XHTML2 as a plan, but it wasn't even backwards compatible with XHTML.
The WHATWG has really done a lot to get HTML5 'out there' fast.
I think the people who do the work on HTML5 probably also need to work on CSS3. And it's a lot of work, so it seems.
Tried to deploy html5 embedded videos, failed (Score:2, Interesting)
I tried to create a website that had to present some 480p videos. I encoded them to Ogg Theora, and figured I could forgo Internet explorer compatibility by encouraging visitors to use either Firefox or Chrome. Unfortunately, for all the noise Firefox makes about supporting open standard, their insistence on implementing their own video support rather than relying on Underlying os ability is completely messed up. Every platform I tested on exposed different bugs in Firefox that prevented the site from w
Re: (Score:2)
That version of Firefox was the first to support Ogg Theora, the streaming in particular isn't very good. Firefox 4 will be a lot better in that regard.
Re: (Score:2)
If I instead decided to use the de-facto x264 standard, I increase my browser compatibility across the board
But how much would it cost to either A. obtain a license from MPEG LA to encode your videos using x264, or B. emigrate from the United States? According to a summary of the license terms [mpegla.com], the royalty for H.264 use over the Internet is zero until the end of 2016, then $2,500 per copy (the free TV rate) afterward.
Re: (Score:2)
MPEG LA has already stated that they will further extend the existing no-fee provisions. So, practically, he will most likely not have to pay.
This is Great News!!! (Score:3, Insightful)
If developers are encouraged to use HTML5 in its present form, which has inconsistencies across browsers, some websites will not work properly on some brand new, modern browsers -- not necessarily because the browsers are not standards compliant, but because the websites had to choose to be compliant with the unfinished standard implemented within a particular browser.
While most developers would normally choose the common factor and make their websites work on all browsers, other interests may prevent them from doing so. We've already seen Microsoft pay off certain popular websites to make their pages use HTML5 that only IE9 supports, as a marketing technique to make others look bad. While you could argue that all marketing is fair game (lies and subterfuge; smoke and mirrors), this sort of thing makes the job of the standards authority much more difficult, because some things may become defacto standards, thus undermining their efforts and ultimately making compatibility across browsers more difficult.
Remember the last time this sort of thing happened? Don't forget that Microsoft still has a good chunk of market share, and could invent new ways of making history repeat itself.
The W3C needs a big reality check. (Score:5, Insightful)
Web developer here.
First off, HTML 4 has plenty of browser interoperability issues. Just try to develop something that works on IE and any other browser.
Secondly, for the love of God and all that is holy, HTML is primarily a visual medium that people look at on a computer screen! Separating content (html) from presentation (CSS) was an excellent idea. Failing to allow vertical centering without dumbass CSS and javascript hacks is not. Seriously, what the hell?
Third, why can't CSS styles inherit other styles or use constants? You were *finally* going to add that into CSS, and then some jackass decided not to include it because it would make it more *complicated*. Do you know what's complicated? Having to change 40 instances of a color in a CSS file because I can't define a damn constant. This is exactly the kind of shit CSS was supposed to *solve*. Safari implemented this briefly and removed it because *they were afraid people would like it too much and usage would become widespread before there was a standard*. Add it to the standard! Right now, we have to use ridiculous workarounds like CSS compilers, which don't fit very well into a lot of modern CMSs.
Fourth, stop deliberating and start releasing official standards, otherwise Microsoft will just run off and do its own thing and we'll all be boned *again*. You're doing way more damage than you're preventing.
Finally, your failure to support as standards things (like the aforementioned CSS vertical centering) that people need to do in the real world on a regular basis just leads web developers to use non-standard code and bullshit like Flash, which circumvents your standard altogether.
End rant.
Re: (Score:3, Insightful)
What do you suppose are the chances that Microsoft itself is slowing down the W3C's progress, for exactly the reason you state? It would not be the first time a company sabotaged a cooperative effort to further their own interests.
Re: (Score:2)
Re: (Score:3, Informative)
I can appreciate that some of that would seem more natural, but you can accomplish most (all?) of that using multiple classes and grouping. At the moment, I'd agree with this (http://dorward.me.uk/www/css/inheritance/) in that I'm not sure we even need OO style inheritance given that we have these other methods.
That said, if you REALLY need constants and inheritance you could implement some server side hackery. I realize that would not be optimal for most folks and breaks the independent style paradigm. :
Re: (Score:2)
That said, if you REALLY need constants and inheritance you could implement some server side hackery. I realize that would not be optimal for most folks and breaks the independent style paradigm.
It doesn't really. If the style coming over the wire isn't the style as written by the original developer, but has a collection of transformations applied to it in between (e.g., converting "constants" to their values) then who cares except the developer? What's really wrong is that CSS isn't done with a syntax that can be produced from XSLT processing easily; if it was, all this whining about a lack of programming flexibility would be seen for what it is.
Re: (Score:2)
> ...Microsoft will just run off and do its own thing...
With a market share below 50% and shrinking?
Re: (Score:2)
Third, why can't CSS styles inherit other styles or use constants?
This.
A million times this.
Why can't CSS natively do the following?
$constant_1 = 20em;
$constant_2 = 10em;
#container [ { .foo {
width: $constant_1;
min-height: $constant_2;
}
width: $constant_1 - 2em;
}
]
instead of
#container {
width: 20em;
min-height: 10em;
}
#container .foo {
width: 18em;
}
When I do CSS, I use a crapton of tabs to indent declarations, and I als
Re: (Score:2)
Because that's an engineering solution in a medium populated with designers.
Also, I personally think you've found a solution in search of a problem, since good class naming practices essentially create a nest anyways (though not declaratory).
Re: (Score:2)
Re: (Score:2)
We should be able to do this in CSS 3 [w3.org], at last.
No kidding... (Score:2)
I can't even use Youtube anymore. Even 360p videos don't play smoothly, and when they go fullscreen (Which isn't really fullscreen anymore) it turns into a slideshow. Forget HD.
AND THERE'S NO WAY TO DISABLE IT. Way to go, Google.
Sound advice (Score:3, Informative)
The usual games of trying to put facts on the ground first to "win" a standards battle....
HTML5 needs a LOT of work, especially in the realm of security.
Re: (Score:2)
HTML5 is not there yet. (Score:2, Interesting)
This isn't the W3C. (Score:3, Informative)
...just a guy who happens to be part of the W3C [w3.org] stating his personal opinion. There is no official press release or publication on the W3C site itself--and, for that matter, not even any on this guy's personal web page or Twitter feed (when did he even say this?).
Re: (Score:2, Troll)
A more practical alternative (Score:2)
Use HTML 4.01 STRICT DTD. Strict fixes the IE6 box model problem, which is _huge_.
Use a CSS reset to make all browsers start with a consistent base style which you then define.
Use Clearfix so you can clear floats without having to insert extra HTML (a div clear class which I see people use all the time).
Either make up your own commonly-used CSS styles, or use something pre-made like 960.
Use DD_Roundies to give IE rounded corners and give IE6 alpha transparency for PNGs. (avoid absolute positioning with this
Finalize the spec prior to release to public (Score:2, Insightful)
As a professional web application developer, I agree with the W3C on this one. Apple is quick to push HTML5 because it has some odd fascination with hating flash. HTML5, however, does not do everything that flash can do. Furthermore, there are security implications within the draft spec.
Standards need to be approved for professional applications. Sensitive sites like banks, hospitals, heck sites that store and use any personal information need to be secure. By introducing hacks and branches either with
No need to rush (Score:2)
I can't find anything on the tubes about this apart from the infoworld article (and its mirrors on apparently every site ending with -world.com). We don't know what he's actually said, and/or what his reasoning was.
If he was saying something like "Don't rely on HTML5 being fully implemented just yet, because various things are subject to change", that's just understandable. He may not be saying "don't use it" - just "don't rely on it", or "don't use in a production environment that has to work for the next
html5 vs xhtml2 (Score:2)
I thought that one of the big factors in adoption of html5 vs the superior xhtml2 spec was that html5 was here now?
Tendency Toward Perfection (Score:2)
Jorbs. (Score:4, Funny)
Finalized standards are the leading cause of cold chairs. W3C and IEEE are doing their part to combat this injustice.
Re: (Score:2)
It's probably the "need" for paper and in-vivo meetings.
If you didn't need them, standards would fly instead of committee members.
Re:Jeeze. (Score:4, Informative)
It's probably the "need" for paper and in-vivo meetings.
If you didn't need them, standards would fly instead of committee members.
HTML5 uses no in-person meetings. The HTML Working Group charter [w3.org] at the W3C even says "This group primarily conducts its technical work on a Public mailing list". Everything is done through a combination of the mailing list and Bugzilla, with some IRC discussion thrown in on the side. There are teleconferences, but nothing important is done there, and the editor doesn't attend them – the decision policy [w3.org] requires that all requests for changes be made through Bugzilla and other web interfaces. There's also no paper involved anywhere.
Really, almost nothing at the W3C is in-person. People contribute from all over the world, both W3C members and non-members. In-person meetings are impractical. This is particularly true for HTML5 – the WHATWG version of the spec is really managed exactly like an open-source project with a benevolent dictator, not at all like a conventional spec.
The reason specs progress slowly is because it takes lots of programmer-hours to implement them correctly. Most of HTML5 is fully specced and just awaiting implementation. Programming is expensive work.
Re:Jeeze. (Score:5, Insightful)
Why does it have to be implemented before it can become a finalized specification?
Because before it's implemented, it's just some words on a web page, and no one has actually tried it. Implementers inevitably spot parts that are vague, or too complicated or expensive or slow to implement, only when they actually try to implement it. Also, implementing it will mean it gets the regular security and UI review that all new browser features get, which will result in more feedback. And finally, you get almost no feedback from regular authors or users until it's shipping in at least beta versions of browsers. This is why no W3C spec can be declared finished without two interoperable implementations.
Another way of looking at it is that you could try speccing everything first, then implementing it. But it means that you miss a lot of things and wind up putting out a bad standard. Instead, web standards are usually developed in tandem with implementations, and are open to change as long as it's feasible if new information comes to light. They're only really set in stone when so much content depends on particular behavior that browsers can't change it without breaking websites – barring that, they can always be improved. Even Recommendations aren't final in practice, because they can be superseded by later versions. HTML 4.01 is a recommendation, but HTML5 contradicts it in many places, and takes precedence.
Re: (Score:2)
CSS was an example of failing the first test. It was inadequately specified, so implementations had to make guesses about what the spec really meant. This was later clarified, but by then th
Re: (Score:3, Informative)
Who do you think is "working out" HTML5 now?
The fact of the matter is, a 1000 page technical document that precisely defines the behavior of an _existing_ complicated system takes a while to write. And that's before we start thinking about the time to implement (e.g. every browser having to rewrite its HTML parser, every browser having to modify its event loop, that sort of thing).
Re: (Score:2)
Yes, I understand it's a challenging technical issue, but things like OS X (which is an amalgam of quite a few disparate technologies and APIs) took less time.
Re: (Score:2)
Re: (Score:3, Insightful)
OS X doesn't involve reconciling multiple constituencies or implementors with divergent interests. It was also not aiming to create a _specification_; just an implementation. It's often easier to implement than to specify.
Re: (Score:3, Informative)
> I should infer that the writers of the HTML5 recommendation are creating the documentation
> to fit the existing browser implementations of HTML5?
Not quite.
There are two parts to HTML5. There's the "describe how the web works" part. This would be HTML parsing, the Window object, etc. This consists of reverse-engineering the existing browsers and then specifying something preferably sane that, if implemented, gives a working web browser that works with actual web sites.
The other part is the new fea
Re: (Score:2)
I think he/she means, HTML5 actually specifies everything HTML4 did, but with the bits which were not in HTML4. There was a lot of behavior in browsers which was not defined by any standard, HTML5 now includes all that. So to make sure everyone knows how HTML should work.
Re: (Score:2)
I respect what we've been able to achieve on this platform, but I can't help but feel it is holding us back as well.
Re: (Score:2)
Releasing a new spec every 6 months sounds great. However, many web developers are still supporting the nearly-decade-old IE6! Keeping a site consistent (and working) across all browsers, right now, with just HTML 4 is incredibly time-consuming. Can you imagine if we had to support 20 different versions of a spec, just to ensure it works in every possible incantation of browser!
I'm all in favor of Google, Apple and Firefox working out the standards themselves. HTML should update twice yearly, just like Ubuntu.
Who do you think the committee is made up of?
Re: (Score:2)
I'm all in favor of Google, Apple and Firefox working out the standards themselves. HTML should update twice yearly, just like Ubuntu.
Who do you think the committee is made up of?
Well that is just bizzar, they are adding public support for features they are publicly (through this committee) asking developers not to use.
Re: (Score:2)
Standards are not like software.