Slashdot Mirror

How is that relevant, when drawing analogies with mobile phones, in the context of appstores with custom apps for every little thing which can be handled by web browser

A custom app is stored in a dedicated area in the phone's memory. A web app is stored in a smaller area called the cache that will be emptied once there are enough other items, and once it's gone, the app is unusable until the user turns the handset's data connection back on.

Yes, some things are better as a local application, I'm not saying they're not

So let's quantify which are. Browser-based apps will reduce the need for local apps as user agents come to support JIT compiling of JavaScript, the 2D canvas, WebGL, localStorage, and explicit caching. But with so many deployed handsets still officially stuck on Android 1.x, I don't see that happening too quickly.

Why, oh why did javascript become the defacto client-side scripting language for the browser
If you want to scale horizontally across multi-cores, you need a language that allows easy multi-threading and concurrency
About the only thing JS offers for concurrency is that horrid settimeout function

What we need is a better scripting language
Why not incorporate a Python interpreter into browsers, and develop a stripped down sub-set of python for use on the web
I see no technical issues in doing this, only trying to battle the inertia of JS

I want to correct you on two confusions. First, while setTimeout relies on a timer, but once the event occurs, the user handler is executed synchronously within the primary thread, and its semantics don't allow for parallel execution without serious side effects. You can use setTimeout to simulate cooperative tasking, but not for implementing actual multi-core concurrency.

And second: Web Workers is gradually being adopted by browsers, which is the tool for implementing concurrency: a safe alternative to raw threading. This is a threaded and simplified implementation of the Actor pattern, a background thread that you feed some input, and it's executed isolated in parallel and then returns results in an event back to your primary thread.

Don't confuse a language with the browser API, and don't assume languages and APIs are frozen in time. Other things coming to JS/HTML these days are audio processing, video playback and even OpenGL (WebGL), as you may know, so I'd say JS is keeping up with the times adequately.

I hate it when i go to read a news story, or a howto or something else online and it's only available in video form

Open a help ticket and say your hard-of-hearing family member couldn't enjoy the video or the advertisement before it due to lack of SRT captions. If your country has a disability discrimination act, and you have a lawyer in the family, you can probably push this even harder.

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

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

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 embe

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

Apple was stalling things for a while. Not sure about the whole story on this, what changed, when and how long it took for the IE team to get things done once the legal stuff was sorted out. Here is an original email form apple.

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-March/010129.html

and some background http://ajaxian.com/archives/microsoft-canvas-and-the-whatwg This is all several years old at this point. But this was an IE history lesson, not current events.

However, unlike previous HTML specifications, HTML5 is attempting to define which formats are required to be supported by media tags.

No, it is not.

Had they just written an article, they'd have gotten their message across perfectly and within a few minutes rather than an hour.

SRT (SubRip text) is a file format containing timed text, where each piece of text has a start and end time. YouTube accepts SRT for subtitles, as seen in this video. So do HTML5 audio and video. So ideally, if you want to read a video instead of watching it, your user agent should provide a way to view the SRT directly.

<abbr title="abbreviation">abbrev.</abbr>

There. That's a completely unambiguous way to represent an abbreviation. Technical writing? There's no shortage of options for that.

There's no magic answer to the sentence spacing issue though. Use an em space if it bothers you that much. Go bitch at the Unicode consortium if that's not good enough; they've still got a few empty slots in the General Punctuation block.

<abbr title="abbreviation">abbrev.</abbr>

There. That's a completely unambiguous way to represent an abbreviation. Technical writing? There's no shortage of options for that.

There's no magic answer to the sentence spacing issue though. Use an em space if it bothers you that much. Go bitch at the Unicode consortium if that's not good enough; they've still got a few empty slots in the General Punctuation block.

<abbr title="abbreviation">abbrev.</abbr>

There. That's a completely unambiguous way to represent an abbreviation. Technical writing? There's no shortage of options for that.

There's no magic answer to the sentence spacing issue though. Use an em space if it bothers you that much. Go bitch at the Unicode consortium if that's not good enough; they've still got a few empty slots in the General Punctuation block.

Well, we can't make that red because what about people who can't see red. You mean like stop signs and traffic lights?

Color-blind people see things in shades of black, yellow, gray, blue, and white. Stop signs in the United States are a shade of yellow conventionally called "red", but they're also regular octagons. The traffic signal for stop is also "red", but it's on top. The traffic signal for go isn't "green" at all; it's turquoise, like Slashdot's color scheme.

Or whatever future innovation from say HTML5 that we want to use.

The HTML5 working group designs the new elements with assistive user agents in mind. For example, the <video> element supports SRT timed text that a user agent can display as a transcript or as synchronized captions. The problem is with outdated screen reader software that either A. doesn't support the new elements or B. can't track changes to the DOM that your JavaScript app makes.

That is actually one of the most significant problems with HTML5. It provides no way for the video to maximize to full screen and is actually even against such functionality with JavaScript (page could maximize the window automatically and so on).

This will be done. See this whatwg thread, or this one. WebKit has a non-standard experimental implementation, and it's likely we'll see progress on standardization and deployment in the next year or so. For now, you can usually view videos full-screen by right-clicking and choosing the fullscreen option, or by opening in a new tab and hitting F11. This is one of six concerns that John Harding of YouTube told the WHATWG was important for YouTube to use HTML5 video more, and all the implementers are aware it needs to be fixed at some point.

That is actually one of the most significant problems with HTML5. It provides no way for the video to maximize to full screen and is actually even against such functionality with JavaScript (page could maximize the window automatically and so on).

This will be done. See this whatwg thread, or this one. WebKit has a non-standard experimental implementation, and it's likely we'll see progress on standardization and deployment in the next year or so. For now, you can usually view videos full-screen by right-clicking and choosing the fullscreen option, or by opening in a new tab and hitting F11. This is one of six concerns that John Harding of YouTube told the WHATWG was important for YouTube to use HTML5 video more, and all the implementers are aware it needs to be fixed at some point.

That is actually one of the most significant problems with HTML5. It provides no way for the video to maximize to full screen and is actually even against such functionality with JavaScript (page could maximize the window automatically and so on).

This will be done. See this whatwg thread, or this one. WebKit has a non-standard experimental implementation, and it's likely we'll see progress on standardization and deployment in the next year or so. For now, you can usually view videos full-screen by right-clicking and choosing the fullscreen option, or by opening in a new tab and hitting F11. This is one of six concerns that John Harding of YouTube told the WHATWG was important for YouTube to use HTML5 video more, and all the implementers are aware it needs to be fixed at some point.

...at least not in its non-XML form (check out the doctype for starters). If you've wanted to cope with your typical "in the wild" web page over at least the past 10 years, you've needed a special HTML parser anyway - SGML wasn't enough.

What HTML5 has tried to do is codify how to recover from errors so hopefully if you do choose to make non-validating HTML5 pages there is a greater chance that all browsers will recover the same way.

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

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

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

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

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

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

IE9, which should hit beta later this year, supports all HTML5 elements.

Not even close. No browser is even close. Large swathes of the HTML5 spec are totally unimplemented. If you restrict yourself solely to new elements and not other new features (I don't know why you would), no browser implements <progress>, <meter>, <details>, <menu>, and several others. Some elements are implemented by at least one browser but not by IE9, like <keygen>, <datalist>, <output>, maybe a couple others.

Overall, IE9 is a huge step forward from IE8 and drastically closes the standards-compliance gap with other browsers, but it's still behind.

IE9, which should hit beta later this year, supports all HTML5 elements.

Not even close. No browser is even close. Large swathes of the HTML5 spec are totally unimplemented. If you restrict yourself solely to new elements and not other new features (I don't know why you would), no browser implements <progress>, <meter>, <details>, <menu>, and several others. Some elements are implemented by at least one browser but not by IE9, like <keygen>, <datalist>, <output>, maybe a couple others.

Overall, IE9 is a huge step forward from IE8 and drastically closes the standards-compliance gap with other browsers, but it's still behind.

IE9, which should hit beta later this year, supports all HTML5 elements.

Not even close. No browser is even close. Large swathes of the HTML5 spec are totally unimplemented. If you restrict yourself solely to new elements and not other new features (I don't know why you would), no browser implements <progress>, <meter>, <details>, <menu>, and several others. Some elements are implemented by at least one browser but not by IE9, like <keygen>, <datalist>, <output>, maybe a couple others.

Overall, IE9 is a huge step forward from IE8 and drastically closes the standards-compliance gap with other browsers, but it's still behind.

IE9, which should hit beta later this year, supports all HTML5 elements.

Not even close. No browser is even close. Large swathes of the HTML5 spec are totally unimplemented. If you restrict yourself solely to new elements and not other new features (I don't know why you would), no browser implements <progress>, <meter>, <details>, <menu>, and several others. Some elements are implemented by at least one browser but not by IE9, like <keygen>, <datalist>, <output>, maybe a couple others.

Overall, IE9 is a huge step forward from IE8 and drastically closes the standards-compliance gap with other browsers, but it's still behind.

I've learned long ago that developing against standards that are not yet official is the road to pain. This is demonstrated even in the summary itself. So - I'm supposed to start implementing cutting edge changes for my production sites, when the browsers that support those changes are "soon to be released"? Soo... now I'm already having to code workarounds before the standard is even official? Again - thanks, no. I'll wait until it's ratified as a standard, and the first revision of major browsers offers compliance.

Well then you can enjoy the wait until 2022, because that's when it will reach W3C Recommendation, which is the current status of HTML4.

Of course, by that time the rest of us will all be enjoying HTML9.

The real standard is "what do 80% of browsers support?" Browser support for HTML5 will be added piecemeal, just like they did with HTML4.

HTML5's text/html syntax is not defined in terms of SGML, it is a separate syntax specific to HTML, defined at http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html.

And what, pray tell, do you think <canvas> is? Look at the spec. It's SVG written in JavaScript.

As a developer, sysadmin and end user I would like to tell you that HTTP is not for this there are other ports than 80 and the web browser is not a virtual machine.

Then it's a good thing that that WebSockets aren't HTTP. It's a completely new protocol that's designed for efficient two-way communication over a connection that's held open on both sides. See section 1.7 of that draft RFC, "Relationship to TCP and HTTP":

The WebSocket protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request.

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

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

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

Steaming as in a "steaming pile"?

***HTML5 will allow applications to tap local file storage***

Once or twice a decade I encounter a "They can't possibly be serious" moment. This is one of those occasions.

Nothing in HTML5 allows you to actually browse the filesystem from a web app, or anything even vaguely similar to that. localStorage basically works like cookies, except it has a higher capacity and isn't sent to the server on every request (so only accessible from JavaScript). The privacy/security implications are basically the same as cookies – browsers are encouraged to use the same exact button to clear cookies and localStorage, and they do.

Read the spec if you want to know all the details on how it works. Third-party summaries are usually written by idiots, as you may have discovered by now.

HTML5 is more than vapourware, and provides new features that are useful to people making real-world websites.

I note you said 'people making websites' and not 'people using websites'. A better method of pushing ads down my throat is not a benefit to me.

Frankly, the obvious ways these 'new features' will be abused look like a good justification for going back to gopher.

That is not logically possible when XHTML is a subset of HTML5.

Making something bigger does not logically make it better: in fact, bigger often means worse. A five hundred pound girl might be superior to Natalie Portman in sumo wrestling, but I know which one I'd prefer to date.

Why are we using HTML5 and not XHTML 2?

HTML5 is more than vapourware, and provides new features that are useful to people making real-world websites.

XML abuses aside, XHTML is superior to HTML5.

That is not logically possible when XHTML is a subset of HTML5.

HTML5 requires a more complex parser than XHTML ever will.

Guess what? The real world isn't a pretty theoretical little flower. HTML5 defines consistent error handling for content on the existing internet, not the non-existent one.

XHTML can be validated for correctness, HTML5 is more difficult to do so.

The code exists for both already, so this is a moot point.

I honestly don't understand the reason for following the HTML route. XHTML is already in an industry understood format that tools already exist for.

Because we're sick of waiting decades for the fucking W3C to do anything. They've procrastinated themselves into irrelevance.

The market rarely reflects a superior technology. I still support XHTML. HTML5 is messy, ugly and a kludge.

Is BASIC also messy, ugly and a kludge to you? Would you say the world would be better off if C64s came with Haskell instead? Get real.

http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F

That estimates the spec will not be completely finished (which means test cases and interoperable implementations for every single feature) until 2022 or later. But there are large parts that are uncontroversial and interoperably implemented now, like canvas, the text/html syntax, drag-and-drop, getElementsByClassName(), etc. It's a huge spec, it's not going to reach agreement all at once.

HTML 5 won't be a standard until 2020. Or it looks like they've removed that wildly pessimistic estimate now: http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F.

Read your own link, please, in full. The editor estimates that HTML5 will not reach Recommendation status at the W3C until 2022 or later. This is not "being a standard". HTML5 is a draft standard right now de jure, and much of it is a de facto standard as well. Browsers are already implementing it and it can already be used, regardless of its progress along the formal W3C recommendation track. The latter is a formality and can be safely ignored if you're not a bureaucrat.

http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F

HTML 5 won't be a standard until 2020. Or it looks like they've removed that wildly pessimistic estimate now: http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F.

It doesn't claim that those tests either represent the whole of the HTML5 spec or any draft thereof, or even that they test behavior required by the spec or any draft thereof

They're all drafts. There is NO HTML 5.0 spec. Heck the w3c even say

Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways.

But that wording is more of a dig from goggle who appear to be highjacking it to get more of the stuff they need for Wave than anything else.

Saying HTML5.0 is a spec is saying you're just a little bit pregnant. Hell the canvas draft changed again and was republished YESTERDAY

Paragraphs next time, please.

So, if I'm using a browser that supports WebM, I still need it to support H.264 if I'm browsing a site that has videos encoded in H.264. Is this correct?

Yes, of course.

what is really the big deal about html5 vs playing video with a plug in?

<video> is semantic - it has a specific meaning, unlike object or embed, which could be anything. Then there are the attributes and the DOM interface that go with the <video> tag, which allow direct control and integration with the page. Plugin-based systems are just a big black box sitting in the midst of all this native web content, with minimal interaction between the two. <video> makes video a native, interactive, first class citizen of the web.

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html

The video decoding could still be handled with an external process, BTW. Nothing in the spec prevents that.

Source

The Mozilla development team released Firefox 3.6, codenamed Namoroka, on 21 January 2010 after some anticipation; Firefox 3.5 was a step forward in features but two steps backward in performance. As a minor update, Namoroka was a chance to optimize the last release.

So, now that it's out, did it alleviate some of these problems? Well, let's find out by looking at what 3.6 offers over 3.5.

First and most visible is support for skins, called personas. Firefox developers have been tinkering with the XUL format and they cite its power. They also claim that it has been under-utilized, so personas were a "natural addition."

TraceMonkey received a performance boost, caching more bytecode in RAM using the new "Stored History Integration Table" system which dynamically stores each JavaScript routine as an object in memory in order to more quickly access it during execution.

Firefox's plugin system also received an overhaul, and now lets the user know when a plugin is incompatible. Mozilla also included support for full-screen Theora and WOFF, the Web Open Font File format, as well as additional but otherwise unspecified performance and security enhancements.

Overall, it's a nice list of bullet points for the bump from 3.5 to Nakamora, but the fact that performance wasn't a priority already points away from optimization and to new features. And the features are actually not new at all, but fixes for issues that should have been taken care of during the initial design stages or other numerous upgrades.

For instance, Firefox has been skinnable for years using XUL, and personas are just a hack to this system that allows the user to use bitmapped images as toolbar backgrounds. You are not mistaken if you just had a flashback to Internet Explorer 3.

These personas also slow the browser down, negating any advantage from the TraceMonkey JavaScript engine. One writer on the web even suggests that the TraceMonkey enhancements were done in anticipation of new-feature bloat. Talk about the tail wagging the fox!

Plugin incompatibility usually occurs when a plugin was written for an older version of the plugin system, which demands a question about the wisdom of upgrading the plugin system for Nakamoru the first place. But that's just how Firefox developers roll.

Now, if you're running an incompatible plugin, Firefox alerts you at startup and launches the plugin manager, a JavaScript-based app that contacts Firefox's plugin server and swaps all kinds of metadata in a frantic attempt to update your third party add-ons.

Several of the changes are plainly just developmental masturbation. For example, Theora is the least-used web video codec, with the penetration that the newer QuickTime X has. And WOFF is an open standard that Mozilla wants to support for political reasons that isn't actually in use anywhere.

So what exactly are Mozilla development managers doing?

If a private company with an opaque development model like Apple can apply the breaks and optimize an entire operating system, à la Leopard to Snow Leopard, why can't a public, transparent development team be bothered to do the same for something much less complex like a web browser?

HTML5 video does a lot more than the object tag. It specifies a model for controlling the playing of the video, and other features in HTML5 allow the UI for those controls to be specified with the video. Further features allow all manner of transformations on the video.

Basically, it's wrong to say HTML5 video is like the object tag.

I'm pretty sure the only XHTML-compliant place to put script tags is inside the <head> tag

You're mistaken. HTML5 permits scripts "Where phrasing content is expected", and phrasing content is the stuff that goes in regular old paragraphs and so forth. HTML 4.01 (thus also XHTML 1.0) also says scripts "may appear any number of times in the HEAD or BODY of an HTML document."

In fact, it's a good idea to put scripts in the body if possible, ideally at the end of the page. That way they won't block page rendering. "Put Scripts at the Bottom" is Rule 6 of High Performance Web Sites, an O'Reilly book that's worth reading if you're interested in the subject.

I'm pretty sure the only XHTML-compliant place to put script tags is inside the <head> tag

You're mistaken. HTML5 permits scripts "Where phrasing content is expected", and phrasing content is the stuff that goes in regular old paragraphs and so forth. HTML 4.01 (thus also XHTML 1.0) also says scripts "may appear any number of times in the HEAD or BODY of an HTML document."

In fact, it's a good idea to put scripts in the body if possible, ideally at the end of the page. That way they won't block page rendering. "Put Scripts at the Bottom" is Rule 6 of High Performance Web Sites, an O'Reilly book that's worth reading if you're interested in the subject.

http://bit.ly/9AvjLc:

The Mozilla development team released Firefox 3.6, codenamed Namoroka, on 21 January 2010 after some anticipation; Firefox 3.5 was a step forward in features but two steps backward in performance. As a minor update, Namoroka was a chance to optimize the last release.

So, now that it's out, did it alleviate some of these problems? Well, let's find out by looking at what 3.6 offers over 3.5.

First and most visible is support for skins, called personas. Firefox developers have been tinkering with the XUL format and they cite its power. They also claim that it has been under-utilized, so personas were a "natural addition."

TraceMonkey received a performance boost, caching more bytecode in RAM using the new "Stored History Integration Table" system which dynamically stores each JavaScript routine as an object in memory in order to more quickly access it during execution.

Firefox's plugin system also received an overhaul, and now lets the user know when a plugin is incompatible. Mozilla also included support for full-screen Theora and WOFF, the Web Open Font File format, as well as additional but otherwise unspecified performance and security enhancements.

Overall, it's a nice list of bullet points for the bump from 3.5 to Nakamora, but the fact that performance wasn't a priority already points away from optimization and to new features. And the features are actually not new at all, but fixes for issues that should have been taken care of during the initial design stages or other numerous upgrades.

For instance, Firefox has been skinnable for years using XUL, and personas are just a hack to this system that allows the user to use bitmapped images as toolbar backgrounds. You are not mistaken if you just had a flashback to Internet Explorer 3.

These personas also slow the browser down, negating any advantage from the TraceMonkey JavaScript engine. One writer on the web even suggests that the TraceMonkey enhancements were done in anticipation of new-feature bloat. Talk about the tail wagging the fox!

Plugin incompatibility usually occurs when a plugin was written for an older version of the plugin system, which demands a question about the wisdom of upgrading the plugin system for Nakamoru the first place. But that's just how Firefox developers roll.

Now, if you're running an incompatible plugin, Firefox alerts you at startup and launches the plugin manager, a JavaScript-based app that contacts Firefox's plugin server and swaps all kinds of metadata in a frantic attempt to update your third party add-ons.

Several of the changes are plainly just developmental masturbation. For example, Theora is the least-used web video codec, with the penetration that the newer QuickTime X has. And WOFF is an open standard that Mozilla wants to support for political reasons that isn't actually in use anywhere.

So what exactly are Mozilla development managers doing?

If a private company with an opaque development model like Apple can apply the breaks and optimize an entire operating system, à la Leopard to Snow Leopard, why can't a public, transparent development team be bothered to do the same for something much less complex like a web

See Chris Dibona's explanation.

The video tag works very much like the img tag and thus can support multiple codecs.

That's the problem. video is a lot like good ol' object, which already determines video type based on the server or the MIME type in attribute type , and has the same wrong-MIME-related problems. From there (assuming the right MIME), the browser can just use a default player (as Chrome, Firefox, and even IE are sometimes smart enough to do). If said player can't figure out the exact codecs, then some combination of (a) the player isn't smart enough (really, exact-codec-hunting should be the player's job), (b) the video's some old, busted, or old and busted format, and (c) the video is not a video and no amount of "dieflashdie" will save its ass or the user's.

Other than some issues of how default object players would do the whole controls and poster thing, I remain unconvinced that video is not redundant or even bad. With the failed one-format effort, I keep blinking and thinking "Meet the new HTML" and so forth. *sighs* just hoped that we'd all drop img and any other format-specific object tags now that Acid2 checks some object images and stuff. Rant over, do continue.

Flash games, such as those made by Zynga (think Cafe World and Farmville) are especially heinous in this regard - I've seen 60% CPU usage and 0.5GB RAM sucked up by a single instance of firefox

That's nothing. For shits and giggles pay a visit to the one page version of the HTML5 spec. That page completly blocks Firefox with 100% CPU for over 5 minutes(!) on Intel Core Duo 6300. In this time Firefox becomes completly unresponsive, but it hasn't actually crashed, its just really busy doing the layout.

Well, it was Opera who first proposed and created a proof of concept for the video tag, not apple.

What do you mean by "your browsers HTML editing feature"? It's not like browsers have a native "edit HTML" widget, AFAIK.

Actually, they do, and had it for a while, though you have to provide the toolbar yourself - all formatting is exposed as an API to JavaScript, but there's no stock UI (though, usually, if you cut & paste preformatted text from another application, it will be properly formatted).

Chris DiBona of the Google open source group claimed that "If [youtube] were to switch to theora and maintain even a semblance of the current youtube quality it would take up most available bandwidth across the Internet."

This was shown to be false.

Mr DiBona then mysteriously vanished without trace.

Could he please manifest and either (a) support his claims or (b) concede his error?

Thanks ever so much.

One of those W3C standards is that an element id or name cannot begin with a digit. It can contain digits mind you, it just can't begin with one.

This is true in HTML 4.01 and all non-HTML5 versions of XHTML. It is no longer true in HTML5:

The id attribute specifies its element's unique identifier (ID). The value must be unique amongst all the IDs in the element's home subtree and must contain at least one character. The value must not contain any space characters.

It now just has to be non-empty, and can't contain ASCII whitespace. I'm waiting for this to be widely implemented so I can switch MediaWiki to not use awful id's with ad hoc UTF-8 hex digits in them . . . the old (HTML 4.01) rules didn't allow non-ASCII characters either.

The EU has certainly waited until far too late - this step should have been taken 10 years ago. However, I do support what they are doing simply because it will prevent history from repeating itself.

Won't happen, not in IE's favour anyway. 10 years ago Netscape 4 was crap compared to IE, and then they stopped development to rewrite it from scratch. This time, there are a number of different options around that one browser disappearing will not be so dramatic.

You *need* standards, otherwise you go back to a situation where the platforms have diverged and only the majority platform is supported

I agree that you need standards. I was saying that W3C has never been great at leading the standards. Way too often they were reacting to the extensions that the browsers came up with For example, Netscape's Javascript and tables. Also Microsoft's iframes and various DOM stuff. Fortunately they ignored Netscape's layers and <blink>other crap!</blink>

HTML 5 is a terrible design. XHTML introduced some real improvements over HTML 4.01, but a small number of vendors (Microsoft, Nokia, etc.) decided to raise two fingers at the W3C and implement their own badly designed standard instead (HTML 5).

I am not a great fan of HTML 5, but at least they are adding features that will be seen by the punters. Also, Microsoft and Nokia had nothing to do with HTML 5. According to the WHATWG FAQ it was started "by individuals of Apple, the Mozilla Foundation, and Opera Software".

Finally, there is going to be an XHTML 5. I haven't look at it to know how useful it will be.