No, not at the level you get if you start making incompatible changes. Quirks vs standards mode is a tiny set of well-contained changes in non-IE browsers.
> It's not like a browser has to respect the version number
If the number doesn't have to be respected to get proper functioning, why is it needed at all?
> Does it really serve anyone's interests to have multiple almost-but-not-quite-compatible > HTML renderers
Yes. It has several major benefits:
1) It creates competition, forcing the existing implementations to improve. 2) It allows users of minority platforms (new platforms, say) to create a web browser on
their platform as needed. Right now, the major JS engines only work reasonably on
x86/x86-64/ARM. We want it to be simple to get a browser running on a new hardware
architecture as needed. Unless you think that x86-64 and ARM are all we will need,
forever.
On a more serious note, we've already had the web in a state where there was only one browser around. That browser was IE6. Are you seriously advocating that this was a _good_ state?
> And lack of version numbers is going to make things even worse by adding another source > of ambiguity.
The main effect of lack of version numbers is that the people evolving the standards will have to actually think about the changes they make as opposed to pretending that changing the version number allows you to make arbitrary changes. See also XHTML2.
Browsers do have a quirks mode, but it's not really based on HTML version. It's based on a heuristic, which buckets some HTML4 doctypes into quirks mode and others into standards mode.
Browsers also have no plans to add any more mode switches (except for MSIE, of course), so adding more versioning information isn't exactly useful in that regard.
Note that that's where we are right now with IE; IE8 ships with at least two different layout engines (like separate codebases, last I checked) to handle "IE5" mode and "IE7" mode. And the new "IE8 standards" mode it has is implemented as a set of changes to the IE7 engine, I _think_.
Now Microsoft is OK with this: they have near-unlimited manpower (e.g. for IE9 their JS team is about 25% of the number of total engineers working at Mozilla) and don't have to worry about download size or size of testing matrix (thousands of test systems available easily) or silly things like that.
But forcing this sort of complexity on new market entrants will just entrench the existing players and be bad for the web. We _want_ people to create new web browsers!
The Skype toolbar is a method of pushing users to make phone calls (which Skype gets revenue from) via Skype.
And since the slowness and crashiness are perceived as a problem with _Firefox_, not Skype, there is no downside, right? At least until a story like this breaks.
Users can disable systemwide addons via the addons manager, which effectively removes them from their Firefox instance. They still show up in the list, as disabled, and the user can reenable them if they want, but they no longer affect the browser in any other way.
In any case, the systemwide addon functionality is really meant for stuff like enterprise deployments; Skype is fundamentally abusing it here...
Because user b is an admin on the machine? That's typically what being administrator means.
Though note that while the systemwide extensions can't be uninstalled, they _can_ be disabled. They'll still show up in the list, but they won't have any of their code running and won't affect the browser's behavior in any way other than being in the list.
The skype toolbar isn't skype itself. It's something that scans web pages for phone numbers and then gives you the option of dialing them via Skype, as I understand (haven't used it myself).
I still don't know why someone would want that, but that's presumably why they don't ask before installing it.
Except in practice, web authors _don't_ mean it when they write a doctype, so browsers assume that they should ignore it anyway and guess (or rather render per the latest version of HTML they support). So in practice, version-numbering your HTML is just playing pretend.
There are also philosophical reasons for not having a versioned HTML; I'm happy to describe those if you're interested.
> most standards are not defined tightly enough to prevent various browser manufacturers > from interpreting them ever so slightly differently
For what it's worth, the spec formerly known as HTML5 goes to great pains to NOT allow that. For example, the spec for the HTML5 parser is a state machine description that describes exactly how any stream of input bytes is parsed into a DOM (none of this "in an error case, do whatever you want" crap you see sometimes).
Maybe, but it hasn't been used for HTML on the web before... there was just some pretending to version HTML going on. Not a single browser really versioned it.
If you specify that your page is HTML 2.0 and serve it up as text/html, not a single modern browser will render it per the HTML 2.0 spec text (such as that is).
So you've never been able to "specify what behavior I want". This story (about something Ian said years ago, note) is just about the fact that the HTML spec editor would like to stop pretending otherwise and clearly describe what's actually happening as opposed to what some would really like pretend should happen...
> This is certainly a valid concern, but one that has to be weighed
Absolutely, like everything in standardization and software design.
> With Canvas 2D support able to render everything SVG can, one could even argue that the > whole of SVG, not just fonts are superfluous.
Canvas 2D and SVG have very different rendering models and hence very different performance characteristics. If you have a scene with one object moving through it, doing that with canvas is a pain without building your own retained API on top of it, for example (thus reinventing the SVG wheel).
The issue with your use case #2 above is that SVG allows embedding other non-SVG content in that situation, and then things get very nasty, very fast.
So part of the issue is that SVG _is_ trying to meet several different use cases, but they have somewhat-incompatible requirements...
The issue is not that a given standard can't be implemented, but that a combination of two standards designed by two different groups of people can't be implemented.
> Worse, it calls the entire standards process and branding mechanisms into disrepute.
That's about where it was in 2006/2007, yes. That's why WHATWG got started...
> Shouldn't we be calling for the resignations of some or all of the W3C for a bungle > like that?
Whom do you want to resign? The W3C staff? Or the people who actually wrote the standards (who are representatives of some companies, who are no longer involved in the W3C)?
Generally, having two different standards for doing the same thing on the web is bad for the web. It leads to UA bloat, author confusion, more complexity in the web platform, and more potential for UA bugs.
In the case of SVG fonts, there is the further issue that as specified in full they're not really compatible with HTML, and as implemented in some UAs just to pass ACID3 they're not at all per spec. So all the spec + test there are managing to do is encourage broken implementations.
Robert O'Callahan has described most of the issues here, I think, over the course of a bunch of posts to www-svg@w3.org (archived at http://lists.w3.org/Archives/Public/www-svg/ ) but I'm not sure anyone has collected them up into a single document (which would be long and somewhat technical, since the issues are fundamentally technical incompatibilities between how HTML rendering works and what SVG fonts require if you try to implement them as specified).... I agree that it would be nice if someone had time to do said collecting, but I doubt the result would be all that useful to someone who is not pretty familiar with SVG fonts already.
I think the issue in this case is that some of the standards involved have bits that are actively harmful to the web, from the point of view of some of the implementors involved. so it's not that they're useless; useless parts of a standard can be implemented. It's that they actively do damage...
This part of the standard is being errataed to be optional.
And yes, people skip parts of standards all the time if they don't think they're important, especially when the standard was created for a totally different use case (in particular, SVG as originally written was basically created to not be used with HTML and not be used on the web; there were nods to both but they were not the primary use case). How many zip decompressors actually allow multiple copies of the same file to be present in the archive and look at the index to see which one to extract? How many just grab whatever they find?
"bugs" includes new features in this case; every single change to the code is a "bug" in Bugzilla.
So when your rate of incoming new bugs matches your fix rate that might just mean that people are asking for lots of shiny (css3 3d transforms? css3 flexbox? etc, etc).
> Yes, distribute it by source or distribute it outside the US.
It's not quite that simple. You have to be not just outside the US, but outside most of Europe, a good bit of East Asia, outside North America period, and outside Australia. See http://weblogs.mozillazine.org/bz/archives/020400.html
It could probably be done, but it would take some work.
There main thing that Gecko uses 3D acceleration for right now, apart from WebGL itself, is compositing. That means that any time you have parts of a page that can move relative to each other you can optimize this by keeping those parts in separate textures on the graphics card and just doing a hardware composite with some offset as needed. The alternative to this is to do the compositing operation in software, which is quite a bit slower.
So the main use of 3d acceleration is for cases when stuff is moving relative to other stuff on a webpage. Typical examples would be:
1) scrolling on a page with a background-attachment:fixed background 2) scrolling on a page with fixed-position elements 3) A page that uses CSS transforms and changes the transform values 4) A page that animates some objects using CSS positioning 5) A page that uses CSS transitions in combination with either of the previous two items
None of this happens much on slashdot or a news site. It happens all the time in games, say. Items 2 above happens on things like W3C specs and various sites out on the web, and scrolling of such sites is often much choppier if you disable hardware acceleration. Depending on the complexity of the graphics, it can be choppy enough to be a serious usability problem.
As far as mobile goes... The scrolling issue is a fun one; Fennec has a totally different mechanism for scrolling from desktop, precisely because the desktop one wasn't really good enough for that environment. The drawback is that it will sometimes show you "The Matrix" as you scroll (shows some sort of placeholder pattern until it gets around to actually painting the bits you want to see).
I have no idea how mobile browsers will ever handle things like the ietestdrive demos or serious use of CSS transforms without hardware-accelerated graphics. Chances are, mobile platforms will end up growing those.... And then we get to see how battery life looks. Fun times all around.
> I have no idea how javascript performs compared to Chrome
Anywhere from 4x slower to 4x faster, depending on what you're doing, in my experience.
That's the best part with jits, especially the sort of multipass jits that both Spidermonkey and V8 are working on. If you happen to be doing something that the non-baseline compiler can handle, you win big (well, for some values of "big"; I get times comparable to C compiled with |gcc -O0| on simple stuff). If you don't, you only win somewhat.
http://lachy.id.au/log/2010/05/webm under "Benefits of Matroska" describes the seeking issues in some detail. The summary is that ogg requires you to read more separate bits to seek correctly, and each separate bit ends up having to be a separate HTTP request in the context of web streaming. So your latency starts to bite you when seeking. It's not an issue if you don't have to seek or if you have the whole file already. But for the youtube use case, neither is true, typically.
Yes, if you're careful enough. You can't write over the existing file, but you can create a new file, start using it, then make a copy once the old file is unused.
Well, the hard part is to make sure things keep working after you did the replace. In particular, the ideal is that if an update comes out the browser updates itself and the next tab you open gets the updated renderer process (while the existing tabs still have the old renderer process). If you have to update the UI process, then you obviously have to do something slightly different.
> Schedule updates for when I close the app because it's pretty damn likely I don't need to > use it for a few minutes.
It's not that simple. When you close the app in the case of a web browser, you're most likely shutting your machine down; you don't want to do the update then.
The only sane way to do it is what Google does: actually replace the binaries in-place as the program runs... We're working on getting there.:)
Slashdot Mirror
> The complexity is already there
No, not at the level you get if you start making incompatible changes. Quirks vs standards mode is a tiny set of well-contained changes in non-IE browsers.
> It's not like a browser has to respect the version number
If the number doesn't have to be respected to get proper functioning, why is it needed at all?
> Does it really serve anyone's interests to have multiple almost-but-not-quite-compatible
> HTML renderers
Yes. It has several major benefits:
1) It creates competition, forcing the existing implementations to improve.
2) It allows users of minority platforms (new platforms, say) to create a web browser on
their platform as needed. Right now, the major JS engines only work reasonably on
x86/x86-64/ARM. We want it to be simple to get a browser running on a new hardware
architecture as needed. Unless you think that x86-64 and ARM are all we will need,
forever.
On a more serious note, we've already had the web in a state where there was only one browser around. That browser was IE6. Are you seriously advocating that this was a _good_ state?
> And lack of version numbers is going to make things even worse by adding another source
> of ambiguity.
The main effect of lack of version numbers is that the people evolving the standards will have to actually think about the changes they make as opposed to pretending that changing the version number allows you to make arbitrary changes. See also XHTML2.
Browsers do have a quirks mode, but it's not really based on HTML version. It's based on a heuristic, which buckets some HTML4 doctypes into quirks mode and others into standards mode.
Browsers also have no plans to add any more mode switches (except for MSIE, of course), so adding more versioning information isn't exactly useful in that regard.
> Let's hear them.
I was going to summarize, but just found the link to the original post that sums up the argument. See http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html
Note that that's where we are right now with IE; IE8 ships with at least two different layout engines (like separate codebases, last I checked) to handle "IE5" mode and "IE7" mode. And the new "IE8 standards" mode it has is implemented as a set of changes to the IE7 engine, I _think_.
Now Microsoft is OK with this: they have near-unlimited manpower (e.g. for IE9 their JS team is about 25% of the number of total engineers working at Mozilla) and don't have to worry about download size or size of testing matrix (thousands of test systems available easily) or silly things like that.
But forcing this sort of complexity on new market entrants will just entrench the existing players and be bad for the web. We _want_ people to create new web browsers!
The Skype toolbar is a method of pushing users to make phone calls (which Skype gets revenue from) via Skype.
And since the slowness and crashiness are perceived as a problem with _Firefox_, not Skype, there is no downside, right? At least until a story like this breaks.
Users can disable systemwide addons via the addons manager, which effectively removes them from their Firefox instance. They still show up in the list, as disabled, and the user can reenable them if they want, but they no longer affect the browser in any other way.
In any case, the systemwide addon functionality is really meant for stuff like enterprise deployments; Skype is fundamentally abusing it here...
Because user b is an admin on the machine? That's typically what being administrator means.
Though note that while the systemwide extensions can't be uninstalled, they _can_ be disabled. They'll still show up in the list, but they won't have any of their code running and won't affect the browser's behavior in any way other than being in the list.
They do?
The skype toolbar isn't skype itself. It's something that scans web pages for phone numbers and then gives you the option of dialing them via Skype, as I understand (haven't used it myself).
I still don't know why someone would want that, but that's presumably why they don't ask before installing it.
Except in practice, web authors _don't_ mean it when they write a doctype, so browsers assume that they should ignore it anyway and guess (or rather render per the latest version of HTML they support). So in practice, version-numbering your HTML is just playing pretend.
There are also philosophical reasons for not having a versioned HTML; I'm happy to describe those if you're interested.
> most standards are not defined tightly enough to prevent various browser manufacturers
> from interpreting them ever so slightly differently
For what it's worth, the spec formerly known as HTML5 goes to great pains to NOT allow that. For example, the spec for the HTML5 parser is a state machine description that describes exactly how any stream of input bytes is parsed into a DOM (none of this "in an error case, do whatever you want" crap you see sometimes).
> There is a reason for versioning.
Maybe, but it hasn't been used for HTML on the web before... there was just some pretending to version HTML going on. Not a single browser really versioned it.
If you specify that your page is HTML 2.0 and serve it up as text/html, not a single modern browser will render it per the HTML 2.0 spec text (such as that is).
So you've never been able to "specify what behavior I want". This story (about something Ian said years ago, note) is just about the fact that the HTML spec editor would like to stop pretending otherwise and clearly describe what's actually happening as opposed to what some would really like pretend should happen...
> This is certainly a valid concern, but one that has to be weighed
Absolutely, like everything in standardization and software design.
> With Canvas 2D support able to render everything SVG can, one could even argue that the
> whole of SVG, not just fonts are superfluous.
Canvas 2D and SVG have very different rendering models and hence very different performance characteristics. If you have a scene with one object moving through it, doing that with canvas is a pain without building your own retained API on top of it, for example (thus reinventing the SVG wheel).
The issue with your use case #2 above is that SVG allows embedding other non-SVG content in that situation, and then things get very nasty, very fast.
So part of the issue is that SVG _is_ trying to meet several different use cases, but they have somewhat-incompatible requirements...
> How do we end up with fundamentally unimplementable standards?
See http://dbaron.org/log/2006-08#e20060818a
The issue is not that a given standard can't be implemented, but that a combination of two standards designed by two different groups of people can't be implemented.
> Worse, it calls the entire standards process and branding mechanisms into disrepute.
That's about where it was in 2006/2007, yes. That's why WHATWG got started...
> Shouldn't we be calling for the resignations of some or all of the W3C for a bungle
> like that?
Whom do you want to resign? The W3C staff? Or the people who actually wrote the standards (who are representatives of some companies, who are no longer involved in the W3C)?
Generally, having two different standards for doing the same thing on the web is bad for the web. It leads to UA bloat, author confusion, more complexity in the web platform, and more potential for UA bugs.
In the case of SVG fonts, there is the further issue that as specified in full they're not really compatible with HTML, and as implemented in some UAs just to pass ACID3 they're not at all per spec. So all the spec + test there are managing to do is encourage broken implementations.
Robert O'Callahan has described most of the issues here, I think, over the course of a bunch of posts to www-svg@w3.org (archived at http://lists.w3.org/Archives/Public/www-svg/ ) but I'm not sure anyone has collected them up into a single document (which would be long and somewhat technical, since the issues are fundamentally technical incompatibilities between how HTML rendering works and what SVG fonts require if you try to implement them as specified).... I agree that it would be nice if someone had time to do said collecting, but I doubt the result would be all that useful to someone who is not pretty familiar with SVG fonts already.
I think the issue in this case is that some of the standards involved have bits that are actively harmful to the web, from the point of view of some of the implementors involved. so it's not that they're useless; useless parts of a standard can be implemented. It's that they actively do damage...
This part of the standard is being errataed to be optional.
And yes, people skip parts of standards all the time if they don't think they're important, especially when the standard was created for a totally different use case (in particular, SVG as originally written was basically created to not be used with HTML and not be used on the web; there were nods to both but they were not the primary use case). How many zip decompressors actually allow multiple copies of the same file to be present in the archive and look at the index to see which one to extract? How many just grab whatever they find?
You may also want to read http://dbaron.org/log/2004-06#e20040609a and http://dbaron.org/log/2006-08#e20060818a for some of the history here...
"bugs" includes new features in this case; every single change to the code is a "bug" in Bugzilla.
So when your rate of incoming new bugs matches your fix rate that might just mean that people are asking for lots of shiny (css3 3d transforms? css3 flexbox? etc, etc).
> Yes, distribute it by source or distribute it outside the US.
It's not quite that simple. You have to be not just outside the US, but outside most of Europe, a good bit of East Asia, outside North America period, and outside Australia. See http://weblogs.mozillazine.org/bz/archives/020400.html
It could probably be done, but it would take some work.
The answer to your question is that it depends.
There main thing that Gecko uses 3D acceleration for right now, apart from WebGL itself, is compositing. That means that any time you have parts of a page that can move relative to each other you can optimize this by keeping those parts in separate textures on the graphics card and just doing a hardware composite with some offset as needed. The alternative to this is to do the compositing operation in software, which is quite a bit slower.
So the main use of 3d acceleration is for cases when stuff is moving relative to other stuff on a webpage. Typical examples would be:
1) scrolling on a page with a background-attachment:fixed background
2) scrolling on a page with fixed-position elements
3) A page that uses CSS transforms and changes the transform values
4) A page that animates some objects using CSS positioning
5) A page that uses CSS transitions in combination with either of the previous two items
None of this happens much on slashdot or a news site. It happens all the time in games, say. Items 2 above happens on things like W3C specs and various sites out on the web, and scrolling of such sites is often much choppier if you disable hardware acceleration. Depending on the complexity of the graphics, it can be choppy enough to be a serious usability problem.
As far as mobile goes... The scrolling issue is a fun one; Fennec has a totally different mechanism for scrolling from desktop, precisely because the desktop one wasn't really good enough for that environment. The drawback is that it will sometimes show you "The Matrix" as you scroll (shows some sort of placeholder pattern until it gets around to actually painting the bits you want to see).
I have no idea how mobile browsers will ever handle things like the ietestdrive demos or serious use of CSS transforms without hardware-accelerated graphics. Chances are, mobile platforms will end up growing those.... And then we get to see how battery life looks. Fun times all around.
Did you file a bug on Mozilla? If so, can you link me to that bug? If not, can you point me to the script in question?
> I have no idea how javascript performs compared to Chrome
Anywhere from 4x slower to 4x faster, depending on what you're doing, in my experience.
That's the best part with jits, especially the sort of multipass jits that both Spidermonkey and V8 are working on. If you happen to be doing something that the non-baseline compiler can handle, you win big (well, for some values of "big"; I get times comparable to C compiled with |gcc -O0| on simple stuff). If you don't, you only win somewhat.
http://lachy.id.au/log/2010/05/webm under "Benefits of Matroska" describes the seeking issues in some detail. The summary is that ogg requires you to read more separate bits to seek correctly, and each separate bit ends up having to be a separate HTTP request in the context of web streaming. So your latency starts to bite you when seeking. It's not an issue if you don't have to seek or if you have the whole file already. But for the youtube use case, neither is true, typically.
Yes, if you're careful enough. You can't write over the existing file, but you can create a new file, start using it, then make a copy once the old file is unused.
Well, the hard part is to make sure things keep working after you did the replace. In particular, the ideal is that if an update comes out the browser updates itself and the next tab you open gets the updated renderer process (while the existing tabs still have the old renderer process). If you have to update the UI process, then you obviously have to do something slightly different.
Right, but then you'll never update for many users (who _only_ shut down their browser when shutting down the OS), which negates the whole point.
> Schedule updates for when I close the app because it's pretty damn likely I don't need to
> use it for a few minutes.
It's not that simple. When you close the app in the case of a web browser, you're most likely shutting your machine down; you don't want to do the update then.
The only sane way to do it is what Google does: actually replace the binaries in-place as the program runs... We're working on getting there. :)