Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:The final version is not due for several years (Score 1) 205

Alright, it seems I spoke way too fast. I did some research on HTML (checked wikipedia) and it seems that updating HTML twice a year would be reckless. However, HTML4 was published as a W3C recommendation in 1997. Just to put that in perspective Windows98 and Napster were yet to happen. This is what AOL.com looked like at the time. 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.

The reason for this is because the W3C got derailed by XHTML. Work was focused for years on impractical specs that browsers didn't want to implement, like XHTML 2 and XForms. HTML5 only started in about 2004, so that's about seven years of zero new standardized HTML features. If you look at it that way, we've seen pretty decent progress in the last few years. Most of the delay is is the implementation, not the actual standards-writing. The HTML5 editor is avoiding large additions while he waits for implementations of what's already specced – you don't have implementers twiddling their thumbs because they have no standards to implement.

Comment Re:This isn't the W3C. (Score 1) 205

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

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

Comment Re:The W3C needs a big reality check. (Score 1) 205

I would bet on it. Look what Microsoft did with OOXML to damage ISO

The W3C is vastly smaller and less bureaucratic than ISO, and also more open. The HTML Working Group conducts its business exclusively on Bugzilla and the public-html mailing list, so if Microsoft were trying anything, everyone would see it. Nothing is done by vote in the HTMLWG, so Microsoft can't try to buy votes secretly. All decisions are made by either the editor (employed by Google) or the co-chairs (one employed by Microsoft, one Apple, one IBM). And everything is being overseen by the W3C administration; you can literally appeal directly to Tim Berners-Lee if you have a problem with the chairs' decision, and people have done that.

Nothing underhanded is going on here. Microsoft can mainly be faulted for not participating much, not for trying to subvert anything.

Comment Re:The W3C needs a big reality check. (Score 1) 205

What do you suppose are the chances that Microsoft itself is slowing down the W3C's progress, for exactly the reason you state?

Zero. Follow the proceedings of the HTML Working Group and see for yourself. You can criticize Microsoft's involvement on various grounds, but nothing they've done has the effect of slowing down progress much. The Working Group is proceeding on a timetable toward Last Call set by the three co-chairs, only one of whom is employed by Microsoft (the other two are Apple and IBM). Microsoft has no more say in the W3C than any other member, and all four of its competitors in the browser market participate more actively in the HTMLWG (and WHATWG) than it does. They wouldn't let it get away with anything even if it tried, which it hasn't.

Standards work always appears slow. With vendor-specific stuff, they don't design it until right before they intend to implement it, and you don't hear about it until the implementation is done. So it sounds like it appears out of thin air. With standards, the design is usually done long before all browsers have the resources allocated to implement it, so it looks like it's taking much longer: you can see the design from day one, and there's a big gap between design and full implementation. Malice has nothing to do with it.

Comment Re:Why not divide it? (Score 1) 205

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?

Because the spec is written. Go read it yourself. The editor cut back on adding new features a few years ago when it was clear that his feature-writing was outstripping implementers' ability to implement the features. He routinely replies to requests for significant new features by saying he's waiting for browsers to implement what's in the spec now before he adds more. The editing right now is almost all just that, editing – hammering out minor flaws that people discover and report. (There are some exceptions, like WebSRT.)

Comment Re:More evidence of the W3C's increasing irrelevan (Score 1) 205

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

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

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

Comment Re:Flies in the Face of Common Sense Too (Score 1) 205

Your job is to write code, not to design a Sculpture to be admired throughout the ages. Designs are fluid, so is the code that implements them.

That's all very well, but when browsers change widely-used APIs, they break sites. Then users complain loudly and refuse to upgrade, because the old version works better than the new one for them if they use those sites. So all the browser implementers except Microsoft refuse to change behavior in ways that will break sites more than absolutely necessary, and Microsoft only pulls off such behavior changes because of its compatibility modes. Which means that once the APIs are widely used, they don't change, period. Browsers will not break content.

Comment Re:W3C is the problem (Score 1) 205

The spec hasn't changed all that much since then (although it has changed)

It seems that recently there has been a change on the set of methods that are supported by an HTML5 form, where PUT and DELETE are no longer supported.

Big Mistake.

There have been tons of minor changes like that, sure. HTML5 initially mandated PUT and DELETE be supported on HTML5 forms, which HTML4 didn't allow, but implementers are not likely to spend time on it without clear advantages that accrue to the average user or web author. You can still do PUT and DELETE from HTML via XMLHttpRequest, in clients that support script (the overwhelming majority), so it's not like it's a huge loss.

Comment Re:More evidence of the W3C's increasing irrelevan (Score 1) 205

._. 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.

The WHATWG never planned to stabilize in 2022. Ian Hickson, the editor of HTML5, predicted that it would take until 2022 to reach the equivalent of W3C Recommendation status: where every single feature has at least two independent implementations, plus a full test suite (which would require hundreds of thousands if not millions of tests for such a large spec). The spec becomes basically stable at the Candidate Recommendation stage, which Ian originally predicted to be 2012 (and that looks to be plausible so far). You can read more about this in the WHATWG FAQ.

Comment Re:More evidence of the W3C's increasing irrelevan (Score 2, Informative) 205

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 video in Firefox 3.6 and later (IIRC) via the context menu. There's no standard JavaScript API to full-screen the video yet, because no one has worked out the security implications in enough detail yet: you'd have to design it carefully so that malicious scripts can't take over the screen (maybe just by copying what Flash does). WebKit has an experimental API in that regard. Plus, you can always just make the <video> tag fill the screen and let the user hit F11 if they want – YouTube does this, and it works pretty well (although it's not ideal).

3. There is no standard format, leaving you to encode an unknown number of versions. Hell, even if you stick with just H.264, you still need to encode to multiple profiles if you want to support everything.

HTML5 video is not yet usable as the only video format anyway, since you have to support IE

4. You can't seek in videos in anything remotely near a reliable manner. You know how you can link to a certain time in a Youtube video? Not possible in HTML5.

It's perfectly possible. YouTube has some JavaScript that will automatically seek the Flash video based on the fragment, and they could do exactly the same for HTML5 video. Seeking is as simple as setting video.currentTime. YouTube already uses this attribute to make its custom seek bar work.

5. You can't switch to lower/higher-bandwidth versions while the video is playing.

Of course you can. Just record currentTime, change the src, and then set the new currentTime. This is all trivial from JavaScript, much easier for a typical web developer than trying to communicate with Flash.

The HTML5 spec as is stands today is useless. The features it does offer above HTML4 already exist and are handled better via existing specs or plugins. Pretty much anything that isn't canvas or video isn't implemented anywhere, making the features entirely useless instead of done better elsewhere.

HTML5 is a vast spec that includes a huge number of improvements and refinements. The HTML5 parsing algorithm, for instance, will make a lot of weird websites work exactly the same across browsers when formerly they all behaved a bit differently – it's enabled by default in Firefox 4, and experimentally available for WebKit. This and many other clarifications are giving each new browser release more opportunity to be consistent with other browsers.

Canvas, video, and audio are not yet as reliable, widely available, or full-featured as their plugin-based equivalents, but they're suitable at least as fallbacks where the plugins aren't available (iOS, sometimes Linux). SVG and MathML embedded in HTML (not XHTML) documents are usable on some cutting-edge browsers, with painless ways to fall back to rasterized versions (requiring barely more work than just using the rasterized version). Microdata can be used today and some search engines will recognize it.

(Yes, you can do some of the above using plugins. But plugins don't work on iOS, don't work reliably on Linux, and don't integrate well with the page. If you want to do Flash video, you have to script it in ActionScript, not JavaScript. Plugins tend to have all sorts of nasty warts, like not obeying CSS or trapping commands that the user intends the browser to receive. I've seen Flash videos display on top of random content that was supposed to overlay the video, and I hate when keyboard shortcuts stop working when I have anything Flash focused. It's just a lousy solution.)

HTML5 includes a lot of nice little things that can easily be used to augment your existing pages without too much work, while keeping your legacy code for legacy browsers. Examples of this are the autofocus attribute, the placeholder attribute, and getElementsByClassName(), all of which are supported in recent enough Firefox and WebKit (for instance).

And it also makes a lot of convenient things valid that browsers already supported anyway. This includes <meta charset="">, omitting quote marks and closing tags in more cases than HTML 4 permitted, standardizing innerHTML, standardizing contenteditable (although not precisely enough for real interop yet), standardizing autocomplete, and permitting custom attributes if they start with "data-".

I encourage you to read the Editor's Draft of HTML5 differences from HTML4 for a more comprehensive list of what HTML5 adds. Many of these features are supported in enough browsers to be useful today, which is why some HTML5 features are used by practically all major sites and all up-to-date JS libraries. There is no reason not to use the things that are useful today, which is a fairly decent amount – although nothing compared to what we'll be seeing five years from now when big features like canvas and video/audio are better-developed and more reliably available.

And, of course, all of this only talking about the HTML5 spec proper. If you include all the other things that are often labeled "HTML5", there's tons more to talk about: CSS3, Web Storage, Web Databases, WebSockets, and a host of other features. This is a time where the web is moving forward at a very rapid pace, in sharp contrast to the stagnation we saw five to ten years ago – and yes, quite a lot of features are already usable to some degree.

Comment Re:W3C is the problem (Score 1) 205

>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

You're not getting what's I was testing. Opera prints the password in cleartext when you do what I described, no other browser does. Firefox 4 nightlies print an unhelpful error message (unhelpful because I provided no title attribute on the input element, for brevity, otherwise it would be helpful), and everything else just submits the form, but nothing else prints the password.

Comment Re:W3C is the problem (Score 4, Interesting) 205

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.

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.

Comment Re:Jeeze. (Score 4, Insightful) 205

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.

Comment Re:Jeeze. (Score 3, Informative) 205

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

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

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

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

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

Comment Re:More evidence of the W3C's increasing irrelevan (Score 5, Informative) 205

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

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

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

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

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."