True enough, but JetPack is work in progress (in terms of the API it supports) and businesses (in fact all extension authors) take time to adapt. If this change in release cadence upsets enterprises, the extension rewrite won't be against JetPack, it'll be against Chrome or IE APIs.
I'm not surprised; Microsoft are already making hay.
Personally, I am dismayed by this attitude from Asa (and most other mozilla devs posting on this). Who do they think employs all the developers and enthusiasts who supported Mozilla in its early days? They don't all sit in web design boutiques dreaming up webGL demos, they are employed by businesses across the world.
We supported Mozilla before Firefox had its name; we were early adopters ourselves before we could use it at work; we paid to advertise Firefox 1.0, but more importantly we enthused about the browser to those less technical. This helped Firefox gain its 100s of millions of users. Now, once we've made the case for using Mozilla tech in our enterprises, and are reaping the benefits of modern browsers, we feel betrayed by the people we supported to get here.
Open Source is not, and has never been, a home use only affair. The Open Source landscape needs a browser for home and business use. I would rather that come from an independent Mozilla than cede the whole ground to Google.
Quite a number of corporates have built their own internal Firefox extensions (not plugins by the way, plugins don't need changing when the browser changes). Firefox 5.0 has changed the Firefox ABI; any extension that calls native code functions needs recompiling for 5.0, it may need changes to the code, calling it 4.1 wouldn't have changed this.
That looks like a good description of Mozilla's current position. Personally, I think it's mad.
The very small IT department for whom I work for part time is not IBM, yet share some of the same issues. Like IBM we have users on Windows Mac and Linux. Like IBM we were not ready to update our users to Firefox4 before it was out of support. We have internal apps which have been developed by people who have left, and by contractors. Dotzler's answer of use IE, is impossible across our OS mix.
IBM's 500000 users are, to Asa, a fraction of a fraction of a %, but he's not just turning off IBM. Replicate it across many other businesses and it's harmful to Mozilla as a whole.
Chrome also follow this policy of upgrading everyone to the latest version, security updates, new features, UI changes all included. This was one of the reasons we didn't switch during the period before Firefox4 (when Firefox 3.6 lagged noticeably behind Chrome in speed). Now Firefox has an even shorter Eol, we might as well switch.
It's a shame there's no Open Source browser in the market for business use (even 12 months between release and EoL would do).
Firefox's market share is vulnerable at the moment, and I really don't think becoming more and more like Chrome will help them. As they remove the things they did differently to Chrome, why expect to compete against the heavily marketed alternative from Google.
Many of our non technical users were introduced to Firefox because we installed it on work machines. They often wish to have the same browser on home and work machines so use it there too. I don't think being so corporate hostile will help Mozilla retain share. Nor will building up bad will with those of us long term Mozilla supporters who are paid to support businesses.
This group of five economicallly small nations could stand up to the big bully on the global scene.
Economically small? While South Africa might reasonably be described as an economically small nation, China has a GDP similar to Japan, either the 3rd or 2nd largest, and Brazil is top ten, nestled between Western European countries such as the UK and Italy. Their combined GDP is over $11 trillian (against $14 trillian for the US economy).
Yes, and the answer is to give people the options to respond to change at the pace that they can cope with. Attract them in with better interfaces, which if they are better will become apparent over time. Releasing "upgrades" to previous versions which take away functionality people are used to and doesn't offer configuration is guaranteed to annoy users. Considering the interface people have huge amounts invested in using a deprecated compatibility option which is there for hardware they don't support is not good.
Why should people have to change at Ubuntu's pace to continue to get their work done? Apple are the only company who've managed to successively transition a large number of users from one technology to another, and, on the desktop, they have a rather specific userbase (plus high quality design which only gets released when it's ready).
With their bug #1, Ubuntu always seem to be designing for the users they don't have (and will quite probably never get) rather than looking after the interests of their current users.
While I do actually like the direction of Unity as a netbook interface (where it started out in fact), I'm much less happy for my multi-screen desktop where I'm used to configuring things as makes sense to me, for my tasks, rather than in the fashion that Canonical UI designers think makes sense to them for their typical users (mostly inexperienced switchers from Windows/Mac if the testees in the article are anything to go by).
Yes, but it's more due to economy of scale rather than lack of willingness to invest. If you're setting up that server management infrastructure, better to split the cost across many users rather than one. You're no doubt negotiating better deals on your hardware too, and if you're a big provider with the flexibility to locate your data centre where power is cheap, even better.
Where I work we are gradually moving from departments hosting their own servers in separate small server rooms or random cupboards and offices, to departments renting VMs from centrally provided infrastructure. This is specifically about investing the money to expand central facilities, saving money/power for the organisation as a whole, and providing more flexibility to users. As part of this we would like the flexibility to run VMs on our own machines or, if demand is high, to supplement that with external cloud capacity. It makes no sense to massively overprovision local facilities in case some service or project needs extra capacity in a hurry.
I think you'll find that Shibboleth is an implementation of SAML rather than SASL.
But in general I agree. I don't have 4 passwords to use on the internet, I have dozens (and have had to create two more just today). Whilst I wouldn't want all my online activity behind just one identity, any single sign-on systems that help me keep it below 100 are appreciated.
That's just royalties for _use_ of an encoder or streaming of content; those licenses are subject to the condition that you _only_ use licensed equipment to encode and decode. ffmpeg is not a licensed decoder; x264 is not a licensed encoder; there are license costs for producing an encoding or decoding device too.
What you write implies that internal use of H.264 is free -- only if you use commercial licensed software at every step.
MPEG-LA's world only really considers the model of traditional large software companies shipping binaries. Even if you wanted to, there is no way for you to license your own compiled version of ffmpeg without the considerable expense of registering yourself as a software supplier.
1) Google doesn't have a particularly extensive patent portfolio, at least compared to other tech corps of similar size.
2) The MPEG-LA is not MPEG, it's just a licensing authority it doesn't produce anything other than license certificates. Other people's patents don't mean anything to it, they only matter to those producing hardware/software.
3) It's not so likely that anyone will come forward with vp8 patents (unless they already have these patents in the H.264 pool). If you had a crucial patent for vp8 the last thing you would want is to produce it now and stifle any chance of people using vp8; your best hope is to wait and hope that WebM is a huge success before announcing the patent when its too late.
More likely, this is an attempt by the H.264 patent holders to spread doubt about WebM, and help ensure that their favoured codec becomes/remains the standard for the web.
What I'm interested in seeing is consistent, predictable, and interoperable implementations of SVG; not just interoperable between HTML5 browsers, but with other SVG tools.
Implementing subsets, or particular versions, of standards hinders end users (graphic designers & web devs in this case), by making use of the technology inconsistent, unpredictable and non-interoperable. Over time this harms the whole format in the eyes of users (a fact that unscrupulous vendors have used in the past to undermine open standards they don't like).
There's nothing inherently unreasonable about Mozilla's favoured SVG subset, but by being a subset (and not one of several existing profiles of SVG), it creates further confusion as to what SVG means and what you can do with any particular "SVG" document. In my mind there is a greater common good in SVG being one consistent thing than implementers quibbling over particular (admittedly flawed) bits of it. Fix the flaws in future versions of the standard, or don't claim to be supporting it.
If the web wants a particular SVG profile, fine, but I'd prefer if it was given a clear name, preferably a different file extension, and certainly a different MIME type. As is, Firefox will claim any SVG document as its own, thus not opening it in a graphics app with fully featured SVG support, yet not be able to display it properly for the user.
I know that browser devs tend to think about it in terms of SVG fragments embedded in HTML documents. There, SVG Fonts support is much less of an issue.
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,
This is certainly a valid concern, but one that has to be weighed; it can't be an article of faith deployed against every forward step. There are already many parts of the web platform which offer more than one way to do it; there can be advantages too.
Animation of DHTML elements has always been possible using javascript (and recent API extensions make this even more feasible), yet now we also get not just SMIL animation, but CSS3 animation too.
With Canvas 2D support able to render everything SVG can, one could even argue that the whole of SVG, not just fonts are superfluous.
But, having a declarative vector graphics format on the web is useful in itself, and I see 3 main places SVG fits on the web:
1) As a way to add more feature-full decoration to pages, used inline in HTML.
2) As an image format which supports vectors, served as a.svg file and used in the same places and fashion as JPEG and PNG.
3) As a part of DOM. A format which can be viewed as text, or a tree structure; generated or edited programatically in either fashion. All the same stuff this brings to documents with HTML, brought to graphics too.
For (1) I don't see a strong need for SVG Fonts. Content creators are already used to using a whole set of interdepending assets, and serving them separately.
However for (2) things are a bit different. If you want SVG to be a useful as a stand alone image format on the web (and I do want an open vector format on the web), then it needs to be fully featured. It should support basically any SVG you're going to see from content creation apps, otherwise the format as a whole is tarnished.
For (3) I don't see why, if the benefits apply to the structured format that is graphics they aren't appropriate for the structured format that is fonts. I understand that there are limitations to the current SVG Font spec, but start small and it could improve over time.
Mostly, I would be happy if Firefox could render all SVG features when linked as an image file. If it didn't support SVG Fonts for inline SVG, or in SMIL animation then it wouldn't worry me (though it might become confusing to explain to web designers). To me, the cost of further fragmenting SVG as a format outweighs that of adding a new format to web UAs.
Actually, I am quite glad that Mozilla does take a fairly principled approach to what goes into the web platform. Some venders seem to take a kitchen sink approach to extending the web. But I don't wish to see SVG further hobbled as a format, with yet more complicated profiles of it.
Incidentally, to go with a well specified vector graphics support the browser needs:
- A lossy image format which supports alpha channel; why should we have to use PNG when it's not optimal just to get transparency. (Should have been JNG, but this sane and simple extension to PNG got fatally wounded in the cross-fire of the great MNG debacle).
- An image format featuring higher bit depth and wide gammut. (Probably further down the line, as there's no easy option here.)
So how do the unimplemented parts of ACID3 (SVG fonts as far as I can see) do harm to anyone particularly the web?
I've not seen any clear explanation of the active harm in SVG Fonts (other than some ideas that WOFF won, WOFF supported more features, WOFF had industry support).
I would like to read an explanation. In the case that this is a well thought out objection to parts of a web standard, I think this explanation should be a part of Mozilla's official documentation of Firefox/gecko.
It's somewhat like explaining the rational for not supporting H.264 (except more so as H.264 was never made part of the HTML5 video standard).
You're right that partial implementations of standards are common, though that doesn't make it a good thing. It always comes at a cost to users in interoperability, and consistency.
The web is a poster case for the worst of partially implemented standards. Using the "Open Standards" that back the web is impossible using the published documents as guidance, so ends up being a mixture of searching weblogs and quirks databases; trial and error with those few browsers you have in front of you; and copying poorly understood markup/code from other sites.
The world for the millions of web developers and many millions of end users would be better if the thousands of web browser implementers took a less pick n mix approach to implementing standards. Of course Mozilla are far from the worst, and have done much to implement and champion open standards, but I'd feel happier still if devs strived for full implementation, rather than justifying the bits of candy they liked best.
I find Mozilla's attitude to SVG Fonts rather odd. Yes, WOFF is a superior font format in many ways. Yes, many commercial fonts may not be licensed to embed as SVG fonts, but they do allow a self contained SVG document to contain everything needed to render it
If you're exporting a labeled diagram, or a figure which contains some maths symbols as SVG to put on the web, you're currently left with 2 options:
1) render every glyph down to paths, thus losing any ability for selection of text and making accessibility harder
2) make an SVG file which depends on external font files which then have to be placed in the right locations when published on your website
In the same way as a PDF is convenient as it contains everything to render, SVG could be. Implementing just part of spec is confusing for SVG users - some.svg files will work in web browser, but not all - and only drives users towards proprietary document formats.
As far as I see it WOFF and SVG fonts serve two different purposes, so why not just implement them both, gain the Acid Test brownie points (worthwhile for the PR value) and be done with it.
With the power of the internet your scheme would soon end up with bookswap sites where you could borrow a book from some random person who's already read it (for success add in some web2.0 style social graph and personal ratings for how much you've lent).
In the worst case for the publishers this leads to a world where they only sell enough books to cover the maximum number of simultaneous readers. Kind of like a perfectly efficient library system. A good world for users but unimaginable to the publishers, and probably not too good for authors.
Not that I approve of DRM on eBooks. I struggle using a Sony Reader with Linux, and find that content is only available on Kindle (so I can read it on my phone with a Kindle App, but not in eInk).
The reason you traffic shape to 90% line speed is to stop your upstream from buffering at all. It's all just a workaround for the fact that your ISP has large buffers.
The fact we nerds can configure Linux routers to avoid the issue, doesn't mean its a non-issue to everyone else.
Seriously, maybe your/. ID is too high;-) You've grown up always using network connections which have this issue, and, since you're technical enough, you've learned workarounds like the one you (and Jim) suggest of rate limiting your connection. All your throttling does is allow your local network to start dropping packets so TCP will work and do its own throttling.
The problem is that all this is way over non slashdot-poster's heads. People should be able plug in their routers and it have it work without knowing their line's maximum throughput and configuring throttling. There's no justification for you and I having to configure our routers and set up QoS, and for everyone else to live with bad latency.
And it wasn't always like this. Back in the 80s, the creators of the internet spent plenty of effort building protocols that did scale. In Jim's day, despite slower network speeds, it was perfectly possible to download over FTP (not HTTP, that didn't exist) while interacting on telnet (not SSH that didn't exist either). Of course latency on a 100% network will be affected somewhat, but not unusably so. Transmission Control Protocol exists for a reason, let that do the throttling.
But not all applications up/downloading large volumes of data have a --bwlimit equivalent. And how exactly are you supposed to know at what rate to set the limit to avoid network congestion? It might well change over time; someone on your network may start another download. Manually setting bandwidth use for every application is not the answer.
Allowing TCP to do what it's designed for is better alternative, just one that is thwarted by ISPs/hardware OEMs who put unnecessarily large buffers in their products to avoid any dropped packets.
Yes, that is stupid. I thought, after beta7, they were planning to shrink the add-on bar to match the original status bar. Maybe that's still going to happen.
Re:Will it support languages other than JavaScript
on
Firefox 4 Beta 8 Up
·
· Score: 1
While the python on that page is interpreted. The python interpreter itself is compiled from C to javascript using emscripten.
You can compile any other languages supported by LLVM to javascript. Alternatively, if you want to compile Java to javascript, use GWT which has been doing that for years. These aren't the only examples, it is becoming a popular strategy.
This is close to what you want, except that machine generated javascript has replaced your bytecode. Having a defined virtual machine and bytecode on the web was tried with the JVM, but didn't work out so well. Persuading the world to try again won't work; improving the browsers javascript implementations (and extending the JS spec) is more feasible and reaches much the same goal.
Listen to Brendan Eich on byte code in the browser in his podcast.
I think you mean _you_ didn't ask for that new feature. Plenty of people were complaining that, in comparison to Chrome, Firefox used a lot of screen space for its UI.
As web use moves towards online applications rather than document browsing, it makes sense that the browser interface becomes less prominent. Of course, there are many very different users of the web; I think these changes benefit the general user.
Fortunately, Firefox has a mature and well supported extension system; I'm confident that extensions will be produced to meet your more specific desires.
Slashdot Mirror
True enough, but JetPack is work in progress (in terms of the API it supports) and businesses (in fact all extension authors) take time to adapt. If this change in release cadence upsets enterprises, the extension rewrite won't be against JetPack, it'll be against Chrome or IE APIs.
I'm not surprised; Microsoft are already making hay.
Personally, I am dismayed by this attitude from Asa (and most other mozilla devs posting on this). Who do they think employs all the developers and enthusiasts who supported Mozilla in its early days? They don't all sit in web design boutiques dreaming up webGL demos, they are employed by businesses across the world.
We supported Mozilla before Firefox had its name; we were early adopters ourselves before we could use it at work; we paid to advertise Firefox 1.0, but more importantly we enthused about the browser to those less technical. This helped Firefox gain its 100s of millions of users. Now, once we've made the case for using Mozilla tech in our enterprises, and are reaping the benefits of modern browsers, we feel betrayed by the people we supported to get here.
Open Source is not, and has never been, a home use only affair. The Open Source landscape needs a browser for home and business use. I would rather that come from an independent Mozilla than cede the whole ground to Google.
Quite a number of corporates have built their own internal Firefox extensions (not plugins by the way, plugins don't need changing when the browser changes). Firefox 5.0 has changed the Firefox ABI; any extension that calls native code functions needs recompiling for 5.0, it may need changes to the code, calling it 4.1 wouldn't have changed this.
That looks like a good description of Mozilla's current position. Personally, I think it's mad.
The very small IT department for whom I work for part time is not IBM, yet share some of the same issues. Like IBM we have users on Windows Mac and Linux. Like IBM we were not ready to update our users to Firefox4 before it was out of support. We have internal apps which have been developed by people who have left, and by contractors. Dotzler's answer of use IE, is impossible across our OS mix.
IBM's 500000 users are, to Asa, a fraction of a fraction of a %, but he's not just turning off IBM. Replicate it across many other businesses and it's harmful to Mozilla as a whole.
Chrome also follow this policy of upgrading everyone to the latest version, security updates, new features, UI changes all included. This was one of the reasons we didn't switch during the period before Firefox4 (when Firefox 3.6 lagged noticeably behind Chrome in speed). Now Firefox has an even shorter Eol, we might as well switch.
It's a shame there's no Open Source browser in the market for business use (even 12 months between release and EoL would do).
Firefox's market share is vulnerable at the moment, and I really don't think becoming more and more like Chrome will help them. As they remove the things they did differently to Chrome, why expect to compete against the heavily marketed alternative from Google.
Many of our non technical users were introduced to Firefox because we installed it on work machines. They often wish to have the same browser on home and work machines so use it there too. I don't think being so corporate hostile will help Mozilla retain share. Nor will building up bad will with those of us long term Mozilla supporters who are paid to support businesses.
Really. Do you have a reliable parser for common date formats that works in all languages and scripts? If so I'd be keen for a reference.
Or is this a comment by someone with the typical ASCII-is-all-we-need view of the world?
This group of five economicallly small nations could stand up to the big bully on the global scene.
Economically small? While South Africa might reasonably be described as an economically small nation, China has a GDP similar to Japan, either the 3rd or 2nd largest, and Brazil is top ten, nestled between Western European countries such as the UK and Italy. Their combined GDP is over $11 trillian (against $14 trillian for the US economy).
Who, by your definition, counts as large?
Sometimes, I think people criticize ANY change.
Yes, and the answer is to give people the options to respond to change at the pace that they can cope with. Attract them in with better interfaces, which if they are better will become apparent over time. Releasing "upgrades" to previous versions which take away functionality people are used to and doesn't offer configuration is guaranteed to annoy users. Considering the interface people have huge amounts invested in using a deprecated compatibility option which is there for hardware they don't support is not good.
Why should people have to change at Ubuntu's pace to continue to get their work done? Apple are the only company who've managed to successively transition a large number of users from one technology to another, and, on the desktop, they have a rather specific userbase (plus high quality design which only gets released when it's ready).
With their bug #1, Ubuntu always seem to be designing for the users they don't have (and will quite probably never get) rather than looking after the interests of their current users.
While I do actually like the direction of Unity as a netbook interface (where it started out in fact), I'm much less happy for my multi-screen desktop where I'm used to configuring things as makes sense to me, for my tasks, rather than in the fashion that Canonical UI designers think makes sense to them for their typical users (mostly inexperienced switchers from Windows/Mac if the testees in the article are anything to go by).
Yes, but it's more due to economy of scale rather than lack of willingness to invest. If you're setting up that server management infrastructure, better to split the cost across many users rather than one. You're no doubt negotiating better deals on your hardware too, and if you're a big provider with the flexibility to locate your data centre where power is cheap, even better.
Where I work we are gradually moving from departments hosting their own servers in separate small server rooms or random cupboards and offices, to departments renting VMs from centrally provided infrastructure. This is specifically about investing the money to expand central facilities, saving money/power for the organisation as a whole, and providing more flexibility to users. As part of this we would like the flexibility to run VMs on our own machines or, if demand is high, to supplement that with external cloud capacity. It makes no sense to massively overprovision local facilities in case some service or project needs extra capacity in a hurry.
I think you'll find that Shibboleth is an implementation of SAML rather than SASL.
But in general I agree. I don't have 4 passwords to use on the internet, I have dozens (and have had to create two more just today). Whilst I wouldn't want all my online activity behind just one identity, any single sign-on systems that help me keep it below 100 are appreciated.
I think you're confusing MPEG-LA with MPEG; they're not at all the same.
That's just royalties for _use_ of an encoder or streaming of content; those licenses are subject to the condition that you _only_ use licensed equipment to encode and decode. ffmpeg is not a licensed decoder; x264 is not a licensed encoder; there are license costs for producing an encoding or decoding device too.
What you write implies that internal use of H.264 is free -- only if you use commercial licensed software at every step.
MPEG-LA's world only really considers the model of traditional large software companies shipping binaries. Even if you wanted to, there is no way for you to license your own compiled version of ffmpeg without the considerable expense of registering yourself as a software supplier.
This is wrong in so many ways.
1) Google doesn't have a particularly extensive patent portfolio, at least compared to other tech corps of similar size.
2) The MPEG-LA is not MPEG, it's just a licensing authority it doesn't produce anything other than license certificates. Other people's patents don't mean anything to it, they only matter to those producing hardware/software.
3) It's not so likely that anyone will come forward with vp8 patents (unless they already have these patents in the H.264 pool). If you had a crucial patent for vp8 the last thing you would want is to produce it now and stifle any chance of people using vp8; your best hope is to wait and hope that WebM is a huge success before announcing the patent when its too late.
More likely, this is an attempt by the H.264 patent holders to spread doubt about WebM, and help ensure that their favoured codec becomes/remains the standard for the web.
What I'm interested in seeing is consistent, predictable, and interoperable implementations of SVG; not just interoperable between HTML5 browsers, but with other SVG tools.
Implementing subsets, or particular versions, of standards hinders end users (graphic designers & web devs in this case), by making use of the technology inconsistent, unpredictable and non-interoperable. Over time this harms the whole format in the eyes of users (a fact that unscrupulous vendors have used in the past to undermine open standards they don't like).
There's nothing inherently unreasonable about Mozilla's favoured SVG subset, but by being a subset (and not one of several existing profiles of SVG), it creates further confusion as to what SVG means and what you can do with any particular "SVG" document. In my mind there is a greater common good in SVG being one consistent thing than implementers quibbling over particular (admittedly flawed) bits of it. Fix the flaws in future versions of the standard, or don't claim to be supporting it.
If the web wants a particular SVG profile, fine, but I'd prefer if it was given a clear name, preferably a different file extension, and certainly a different MIME type. As is, Firefox will claim any SVG document as its own, thus not opening it in a graphics app with fully featured SVG support, yet not be able to display it properly for the user.
I know that browser devs tend to think about it in terms of SVG fragments embedded in HTML documents. There, SVG Fonts support is much less of an issue.
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,
This is certainly a valid concern, but one that has to be weighed; it can't be an article of faith deployed against every forward step. There are already many parts of the web platform which offer more than one way to do it; there can be advantages too.
Animation of DHTML elements has always been possible using javascript (and recent API extensions make this even more feasible), yet now we also get not just SMIL animation, but CSS3 animation too.
With Canvas 2D support able to render everything SVG can, one could even argue that the whole of SVG, not just fonts are superfluous.
But, having a declarative vector graphics format on the web is useful in itself, and I see 3 main places SVG fits on the web:
1) As a way to add more feature-full decoration to pages, used inline in HTML.
2) As an image format which supports vectors, served as a .svg file and used in the same places and fashion as JPEG and PNG.
3) As a part of DOM. A format which can be viewed as text, or a tree structure; generated or edited programatically in either fashion. All the same stuff this brings to documents with HTML, brought to graphics too.
For (1) I don't see a strong need for SVG Fonts. Content creators are already used to using a whole set of interdepending assets, and serving them separately.
However for (2) things are a bit different. If you want SVG to be a useful as a stand alone image format on the web (and I do want an open vector format on the web), then it needs to be fully featured. It should support basically any SVG you're going to see from content creation apps, otherwise the format as a whole is tarnished.
For (3) I don't see why, if the benefits apply to the structured format that is graphics they aren't appropriate for the structured format that is fonts. I understand that there are limitations to the current SVG Font spec, but start small and it could improve over time.
Mostly, I would be happy if Firefox could render all SVG features when linked as an image file. If it didn't support SVG Fonts for inline SVG, or in SMIL animation then it wouldn't worry me (though it might become confusing to explain to web designers). To me, the cost of further fragmenting SVG as a format outweighs that of adding a new format to web UAs.
Actually, I am quite glad that Mozilla does take a fairly principled approach to what goes into the web platform. Some venders seem to take a kitchen sink approach to extending the web. But I don't wish to see SVG further hobbled as a format, with yet more complicated profiles of it.
Incidentally, to go with a well specified vector graphics support the browser needs:
- A lossy image format which supports alpha channel; why should we have to use PNG when it's not optimal just to get transparency. (Should have been JNG, but this sane and simple extension to PNG got fatally wounded in the cross-fire of the great MNG debacle).
- An image format featuring higher bit depth and wide gammut. (Probably further down the line, as there's no easy option here.)
So how do the unimplemented parts of ACID3 (SVG fonts as far as I can see) do harm to anyone particularly the web?
I've not seen any clear explanation of the active harm in SVG Fonts (other than some ideas that WOFF won, WOFF supported more features, WOFF had industry support).
I would like to read an explanation. In the case that this is a well thought out objection to parts of a web standard, I think this explanation should be a part of Mozilla's official documentation of Firefox/gecko.
It's somewhat like explaining the rational for not supporting H.264 (except more so as H.264 was never made part of the HTML5 video standard).
You're right that partial implementations of standards are common, though that doesn't make it a good thing. It always comes at a cost to users in interoperability, and consistency.
The web is a poster case for the worst of partially implemented standards. Using the "Open Standards" that back the web is impossible using the published documents as guidance, so ends up being a mixture of searching weblogs and quirks databases; trial and error with those few browsers you have in front of you; and copying poorly understood markup/code from other sites.
The world for the millions of web developers and many millions of end users would be better if the thousands of web browser implementers took a less pick n mix approach to implementing standards. Of course Mozilla are far from the worst, and have done much to implement and champion open standards, but I'd feel happier still if devs strived for full implementation, rather than justifying the bits of candy they liked best.
I find Mozilla's attitude to SVG Fonts rather odd. Yes, WOFF is a superior font format in many ways. Yes, many commercial fonts may not be licensed to embed as SVG fonts, but they do allow a self contained SVG document to contain everything needed to render it
If you're exporting a labeled diagram, or a figure which contains some maths symbols as SVG to put on the web, you're currently left with 2 options:
1) render every glyph down to paths, thus losing any ability for selection of text and making accessibility harder
2) make an SVG file which depends on external font files which then have to be placed in the right locations when published on your website
In the same way as a PDF is convenient as it contains everything to render, SVG could be. Implementing just part of spec is confusing for SVG users - some .svg files will work in web browser, but not all - and only drives users towards proprietary document formats.
As far as I see it WOFF and SVG fonts serve two different purposes, so why not just implement them both, gain the Acid Test brownie points (worthwhile for the PR value) and be done with it.
With the power of the internet your scheme would soon end up with bookswap sites where you could borrow a book from some random person who's already read it (for success add in some web2.0 style social graph and personal ratings for how much you've lent).
In the worst case for the publishers this leads to a world where they only sell enough books to cover the maximum number of simultaneous readers. Kind of like a perfectly efficient library system. A good world for users but unimaginable to the publishers, and probably not too good for authors.
Not that I approve of DRM on eBooks. I struggle using a Sony Reader with Linux, and find that content is only available on Kindle (so I can read it on my phone with a Kindle App, but not in eInk).
The reason you traffic shape to 90% line speed is to stop your upstream from buffering at all. It's all just a workaround for the fact that your ISP has large buffers.
The fact we nerds can configure Linux routers to avoid the issue, doesn't mean its a non-issue to everyone else.
Seriously, maybe your /. ID is too high ;-) You've grown up always using network connections which have this issue, and, since you're technical enough, you've learned workarounds like the one you (and Jim) suggest of rate limiting your connection. All your throttling does is allow your local network to start dropping packets so TCP will work and do its own throttling.
The problem is that all this is way over non slashdot-poster's heads. People should be able plug in their routers and it have it work without knowing their line's maximum throughput and configuring throttling. There's no justification for you and I having to configure our routers and set up QoS, and for everyone else to live with bad latency.
And it wasn't always like this. Back in the 80s, the creators of the internet spent plenty of effort building protocols that did scale. In Jim's day, despite slower network speeds, it was perfectly possible to download over FTP (not HTTP, that didn't exist) while interacting on telnet (not SSH that didn't exist either). Of course latency on a 100% network will be affected somewhat, but not unusably so. Transmission Control Protocol exists for a reason, let that do the throttling.
British Telecom, renamed itself to BT in 1991, a full ten years before Bram Cohen named a protocol Bit Torrent. So I'd say you are getting old.
But not all applications up/downloading large volumes of data have a --bwlimit equivalent. And how exactly are you supposed to know at what rate to set the limit to avoid network congestion? It might well change over time; someone on your network may start another download. Manually setting bandwidth use for every application is not the answer.
Allowing TCP to do what it's designed for is better alternative, just one that is thwarted by ISPs/hardware OEMs who put unnecessarily large buffers in their products to avoid any dropped packets.
Yes, that is stupid. I thought, after beta7, they were planning to shrink the add-on bar to match the original status bar. Maybe that's still going to happen.
While the python on that page is interpreted. The python interpreter itself is compiled from C to javascript using emscripten.
You can compile any other languages supported by LLVM to javascript. Alternatively, if you want to compile Java to javascript, use GWT which has been doing that for years. These aren't the only examples, it is becoming a popular strategy.
This is close to what you want, except that machine generated javascript has replaced your bytecode. Having a defined virtual machine and bytecode on the web was tried with the JVM, but didn't work out so well. Persuading the world to try again won't work; improving the browsers javascript implementations (and extending the JS spec) is more feasible and reaches much the same goal.
Listen to Brendan Eich on byte code in the browser in his podcast.
I think you mean _you_ didn't ask for that new feature. Plenty of people were complaining that, in comparison to Chrome, Firefox used a lot of screen space for its UI.
As web use moves towards online applications rather than document browsing, it makes sense that the browser interface becomes less prominent. Of course, there are many very different users of the web; I think these changes benefit the general user.
Fortunately, Firefox has a mature and well supported extension system; I'm confident that extensions will be produced to meet your more specific desires.