A recent Digg poll showed that many people are incapable of escaping using Internet Explorer i.e. on closed systems or at work, so it's no surprise IE still has as lingering percentage of marketshare.
As Microsoft will be one of the foremost implementers of HTML5 (with IE still having a majority of the market share, unfortunately) it's a very good thing that Microsoft has decided to become involved in the spec rather than leaving it up to its competitors, giving it some notion of responsibility in how the spec turns out.
It seems some of the comments are looking for simple justification (such as why the >aside< tag exists, use cases, etc.) as well as more clear definitions of other new features (including their very own original contentEditable feature), and rather than "influence the spec" as the summary claims, it looks like the IE team is looking critically at how a completely new entity would approach HTML5 (not having had the vested involvement other browser makers have).
What remains to be seen, however, is if the IE team responds to the working group's justification and follows through on the spec, or if it only trusts its own judgment and implements the parts it deems "necessary". This is still the dogged-slow Microsoft team, and in spite of great improvements in IE7 and IE8, reporting issues in the spec during the Last Call stage is not an encouraging insight to their commitment to making HTML5 happen.
Re:HTML 5 parsing is just awful.
on
XHTML 2 Cancelled
·
· Score: 4, Informative
Now try to imagine Microsoft, Opera, Mozilla, and Google implementing that compatibly.
I believe they already do, for the most part. HTML5 parsing rules were mostly reverse-engineered from existing browsers' HTML parsing rules, which are more or less consistent across modern browsers, so it's only documenting what most existing browsers already do.
What the spec is defining is a limited subset of an SGML-like language (whose entire parsing rules, if incorporated into HTML, would span for pages) and how to transform it into a DOM. It isn't mandating any new parser rules, it only documents them for the benefit of new implementations of the spec, and to align what minor variations there are between browser parsing models together. Compared to SGML rules (of which HTML 4.01 is technically a subset), this is a great improvement.
This is exactly what CSS is designed for, presentation. The CSS3 Paged Media module already defines a number of the properties and settings you're going for.
It even includes positions such as @bottom-center to allow you to position footnotes and references. The only thing missing is a way to mark this up in HTML, which could easily be done with anchors and the longdesc attribute, coupled with the CSS content: property.
What you're looking for is a CSS3 enabled browser, not a new specification.
Seeing as how the new improvements are based on Nanojit, a component of Tamarin, the JIT ECMAScript compiler that powers Flash and which Adobe donated to Mozilla, I should think these improvements could rival Flash.
Classes are not out of the question.
on
ECMAScript 4.0 Is Dead
·
· Score: 3, Informative
Classes are syntatic sugar. That's what the working group found, when it discovered that most class-centric features can be boiled down to simpler APIs such as.freeze(),.defineProperty(), &c., all of which are being implemented in ES3.1. Classes, then, would only be user interface to what can already be implemented using these features.
ES-Harmony is about standardizing new features that already work in (three out of four) major browsers, without changing the syntax of the language. Brendan Eich of Mozilla in the Open Web Podcast already discussed how script versioning will allows coders to use different language versions in the future. So syntax changes are not out of the question, they're simply being postponed until after ES3.1.
Until then, users will still have all the power of classes in their code, just without the ease-of-use of a "class" keyword (which will be a lot easier to implement after ES3.1 is proven and tested).
HTTP 1.1 (RFC 2616) clearly defines what HTTP is used for:
It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers.
As for logging into websites: Cookies were a hack added on to HTTP by Netscape, and aren't even in the HTTP 1.1 standard. You can have 'sessions' without cookies. An ideal login system would have your HTTP authentication data sent with every request, which is why HTTP has things like Basic and Digest Authentication. But people don't like HTTP login boxes, and browsers don't let users easily log out of it, so people resort to hacks like cookies to make users happy. Let's get browsers to fix that before we try to arbitrarily revise an already functional protocol.
Sessions are completely unnecessary for HTTP. In the case where they are necessary, then you're using the wrong protocol.
The entire point of HTTP is to be stateless, hence why other protocols (like Adobe's) were invented. If you want a stateless protocol, use a constant TCP connection. Don't try to wedge functionality where it doesn't belong.
HTTP 1.0 already has keep-alive connections, and already has the capability to send requests, so there's no need to update the spec.
What you're describing is making the server a client and turning the user's computer into a server, which has a number of implications. It's simply much more feasible for the user to pull content than the server to push it, especially as it leaves it up to the user's discretion when to receive updates.
Slashdot Mirror
Depends on who you want to believe.
A recent Digg poll showed that many people are incapable of escaping using Internet Explorer i.e. on closed systems or at work, so it's no surprise IE still has as lingering percentage of marketshare.
As Microsoft will be one of the foremost implementers of HTML5 (with IE still having a majority of the market share, unfortunately) it's a very good thing that Microsoft has decided to become involved in the spec rather than leaving it up to its competitors, giving it some notion of responsibility in how the spec turns out.
It seems some of the comments are looking for simple justification (such as why the >aside< tag exists, use cases, etc.) as well as more clear definitions of other new features (including their very own original contentEditable feature), and rather than "influence the spec" as the summary claims, it looks like the IE team is looking critically at how a completely new entity would approach HTML5 (not having had the vested involvement other browser makers have).
What remains to be seen, however, is if the IE team responds to the working group's justification and follows through on the spec, or if it only trusts its own judgment and implements the parts it deems "necessary". This is still the dogged-slow Microsoft team, and in spite of great improvements in IE7 and IE8, reporting issues in the spec during the Last Call stage is not an encouraging insight to their commitment to making HTML5 happen.
Now try to imagine Microsoft, Opera, Mozilla, and Google implementing that compatibly.
I believe they already do, for the most part. HTML5 parsing rules were mostly reverse-engineered from existing browsers' HTML parsing rules, which are more or less consistent across modern browsers, so it's only documenting what most existing browsers already do.
What the spec is defining is a limited subset of an SGML-like language (whose entire parsing rules, if incorporated into HTML, would span for pages) and how to transform it into a DOM. It isn't mandating any new parser rules, it only documents them for the benefit of new implementations of the spec, and to align what minor variations there are between browser parsing models together. Compared to SGML rules (of which HTML 4.01 is technically a subset), this is a great improvement.
This is exactly what CSS is designed for, presentation. The CSS3 Paged Media module already defines a number of the properties and settings you're going for. It even includes positions such as @bottom-center to allow you to position footnotes and references. The only thing missing is a way to mark this up in HTML, which could easily be done with anchors and the longdesc attribute, coupled with the CSS content: property. What you're looking for is a CSS3 enabled browser, not a new specification.
Don't install it.
Well, the fennec is nocturnal...
Seeing as how the new improvements are based on Nanojit, a component of Tamarin, the JIT ECMAScript compiler that powers Flash and which Adobe donated to Mozilla, I should think these improvements could rival Flash.
Classes are syntatic sugar. That's what the working group found, when it discovered that most class-centric features can be boiled down to simpler APIs such as .freeze(), .defineProperty(), &c., all of which are being implemented in ES3.1. Classes, then, would only be user interface to what can already be implemented using these features.
ES-Harmony is about standardizing new features that already work in (three out of four) major browsers, without changing the syntax of the language. Brendan Eich of Mozilla in the Open Web Podcast already discussed how script versioning will allows coders to use different language versions in the future. So syntax changes are not out of the question, they're simply being postponed until after ES3.1.
Until then, users will still have all the power of classes in their code, just without the ease-of-use of a "class" keyword (which will be a lot easier to implement after ES3.1 is proven and tested).
HTTP 1.1 (RFC 2616) clearly defines what HTTP is used for:
As for logging into websites: Cookies were a hack added on to HTTP by Netscape, and aren't even in the HTTP 1.1 standard. You can have 'sessions' without cookies. An ideal login system would have your HTTP authentication data sent with every request, which is why HTTP has things like Basic and Digest Authentication. But people don't like HTTP login boxes, and browsers don't let users easily log out of it, so people resort to hacks like cookies to make users happy. Let's get browsers to fix that before we try to arbitrarily revise an already functional protocol.
Sessions are completely unnecessary for HTTP. In the case where they are necessary, then you're using the wrong protocol.
The entire point of HTTP is to be stateless, hence why other protocols (like Adobe's) were invented. If you want a stateless protocol, use a constant TCP connection. Don't try to wedge functionality where it doesn't belong.
Why stick with three dimensions? Let's just skip three, and go straight to five! And add a moisturizing strip!
HTTP 1.0 already has keep-alive connections, and already has the capability to send requests, so there's no need to update the spec.
What you're describing is making the server a client and turning the user's computer into a server, which has a number of implications. It's simply much more feasible for the user to pull content than the server to push it, especially as it leaves it up to the user's discretion when to receive updates.