7 ms·

83% of browser features are used by under 1% of top websites

pavel_lishin 10y ago
> ALS, “ambient light events”, would let browsers respond to the light level the laptop, phone or desktop is exposed to if anybody used it. Can someone give me a good, non-gimmicky example of what this would be used for?
- unlinker 10y ago
  Use a white letters on black background theme in case the user is browsing your site in bed with his lights off? ^_^
- reicher89 10y ago
  Hmm, perhaps a text-heavy site could switch between "night" and "day" modes for ease of reading
  - mcdoh 10y ago
    Just last night I was happy to find that Safari Books Online had a 'night' feature, automatically switching would have saved me thirty minutes of burned retinas.
  - marssaxman 10y ago
    Oh god. No no no. I cannot hate this idea hard enough to overcome my fear that someday this kind of thing might actually happen! This would be the browser's job, under user control, not ever the site's job. My computer, my choice, no you don't get to decide that for me just because you are a web page designer.
    - TheCowboy 10y ago
      It's difficult to pull this off with every website and keep it readable, without any hint from the site. This is why we have CSS for different screen sizes, rather than relying on mobile browsers to make all the decisions, along with an option to view the site in "desktop mode". I do agree that it would be annoying if sites made this decision for users. But I think the more promising use for this could be enabling aesthetically pleasing color palettes that are power consumption optimized. Picture a HN that switches to darker tones of the current colors when you're on a mobile device.
      - marssaxman 10y ago
        I'm already constantly using "readability mode" to strip away as much of the custom styling as I can, because letting designers run riot - and building browsers that obey their wishes - has turned the web into such a mess. Tighter limits and more end-user control would be better. Different people have different preferences about their browsing experience and should be able to control that without having to rely on every last web designer to make helpful choices, because they really just don't.
        dredmorbius 10y ago
        My vapourware web browser is tentatively titled "fuck your web designer". It will ignore site-provided CSS. Interested?
        marssaxman 10y ago
        Ha! I would like to give that a try.
- vonklaus 10y ago
  essentially something like f.lux presumably.
- iambateman 10y ago
  Yeah. Spotify would stop ads if the audio got too low. In the same way, ambient light could be used to make sure an ad is watched. Not saying it's the most important case ever, but it would be important if you needed it
- benologist 10y ago
  Do you need an example right now or can you wait until someone does something cool with it that's only enabled because the option exists? If we stopped adding new capabilities to JavaScript even as new sensors and w/e go mainstream we'd start needing Flash all over again.
  - zghst 10y ago
    Before we add any new APIs we need a permissions interface for the web. Many new APIs add creepy data points that the user be aware that they are providing.
- zghst 10y ago
  More advanced analytics, tracking your battery + ambient lights + other capabilities...
- gene-h 10y ago
  Provided one can access sensor data fast enough, cross device tracking[0]. Display an ad that lights up the room in such a way that you can read it with the sensor. Communication across an airgap. If you have two devices with screens and said sensors in a dark room, they might be able to communicate by turning screens on and off. Most speculatively, imaging the environment with compressive imaging[1]. One might be able to flash some patterns on the screen and look at light sensor output to take a picture. Giving web browsers access to sensors on our devices is sort of scary. [0] http://arstechnica.com/tech-policy/2015/11/beware-of-ads-that-use-inaudible-sound-to-link-your-phone-tv-tablet-and-pc/ http://arstechnica.com/tech-policy/2015/11/beware-of-ads-tha... [1] http://arxiv.org/pdf/1305.7181.pdf http://arxiv.org/pdf/1305.7181.pdf
  - coroutines 10y ago
    I like how you ripped out any positivity around the topic :D You are my hero
reicher89 10y ago
this was very interesting: "SVG, for example, has a problem however you look at it: on one hand more than 15 per cent of the sites use it, on the other hand, nearly 87 per cent of blockers block it, but it's had 14 security warnings (CVEs, Common Vulnerabilities and Exposures) in the last three years."
- matthewmacleod 10y ago
  I am deeply suspicious of that number. I've never encountered a plugin or anything of the sort that provides for "blocking SVG", and it's fully supported in all recent browsers.
  - nikkwong 10y ago
    ^ Yeah. I use SVG heavily in all my web projects, and I've never seen a single user access one of my sites & had the SVG blocked. I wouldn't buy '87%' at all.
  - snyderp 10y ago
    Paper author here. The blocking % referenced, and discussed in more detail in the paper, is the % of times a feature is used when someone visits the page, but ISNT used when you visit the page with AdBlock Plus and Ghostery installed. In other words, its how often these popular blocking extensions prevent the JS APIs from firing. Its not blocking SVG, its blocking (mostly fingerprinting) JS libraries from running SVG JS methods
    - matthewmacleod 10y ago
      Aha, thank you for the clarification. That's a lot less worrying.
- snyderp 10y ago
  Just a note on this (I'm the lead author on the paper author), the blocking rate has to do with the reduction in JS usage when you install popular blocking extensions. So its not that extensions block SVG directly, its that AdBlock Plus and Ghostery block a bunch of libraries, and those libraries use the SVG methods to finger print (and do other stuff)
jbob2000 10y ago
Kind of a silly article. Most top websites just serve static content with tons of ad-network crap, they would never need 83% of the features. This is like saying "the most sold vehicles in the world don't use 90% of the horsepower they have". No shit, the most sold vehicles in the world are Corollas and Civics, ie. "sit in traffic and commute" type cars. It doesn't cost anything to keep these features around, why kill them off? Code is cheap, it doesn't cost you, the user, anything to have the features in your browser...
- ScottBurson 10y ago
  It does cost you something if that code has security holes.
  - captn3m0 10y ago
    Most of these features also rely on user-approvals so it is not as if every website is going to jump on and start using GeoLocation APIs just because they can. It is a nice study showing how far these niche new features have reached, but that shouldn't affect how we are working on the new ones (except perhaps improving the security models of these).
  - jbob2000 10y ago
    That's a big if. Anything could have security holes, seems pedantic to kill a feature because it might have a security hole at some point.
    - creshal 10y ago
      > That's a big if. Reminder that we've been issuing so many CVEs last year we had to upgrade the numbering spec to allow for more than ten thousand a year.
- vonklaus 10y ago
  I don't know this to be true, but my assumption as someone not building the interpreter/vms for JS is that if you eliminated all of that shit you could probably get a much better optimization from your engine. ALso, security was touched on above.
pilom 10y ago
Can anyone recommend an updated browser that skips most unused features to run faster, use less memory or be more secure?
- vonklaus 10y ago
  Brave software. This was created by Brendan Eich the x ceo of mozilla. Eich does seem to have some problems with equality[0] which may have contributed to his ouster at Mozilla, but Brave is a top shelf browser. Super great team, pretty security conscious and given the Eich developed JS, well, they have a pretty good working knowledge of it. Brian Bondy is a super awesome guy (thanks for adding duckduckgo BTW), Yan Zhu is a pretty well known dev & security blogger and they had the woman who wrote a couple encrypted chat clients working there (apologies her name escapes me) but she isn't on the site. I assume the rest of the team is talented. So in essence, I ove Brave. I still wish they would make a goddamn search engine, but it is an awesome browser. [0] NaN === NaN returns false?. 0.0001 + 0.0002 !== 0.0003? weird.
  - tbirdz 10y ago
    These are standard IEEE754 floating point behaviors.
    - vonklaus 10y ago
      I am aware. It was a bad joke.
  - LionessLover 10y ago
    In addition to the reply with the pointer to the standards, sure NaN !== NaN. NaN means "no idea what we've got here". When you get to say that phrase, would you expect it to be used for exactly one thing and one thing only? To me "I have no idea" means the possibilities are endless (infinite). We can only compare for equality when we know what we are looking at, otherwise it's just "status unknown". Yes, it might be equality - the chances are infinitely small though. If you take the argument a step further and say "but I got the two NaNs that I compare doing the exact same operation, so even if I don't know what I've got from a mathematical point of view whatever it is it should be equal". In that case you are not actually comparing the NaNs but the path(s) that got you there. I must say I find the whole NaN, null, 0 vs. undefined interesting on so many levels. There is a world of a difference between knowing you've got nothing (null or 0) and not knowing what've you've got at all. "null": I have no bank account. "0": my balance is 0. "undefined" or "NaN": I lost my memory after yesterdays binge drinking and don't know who I am and if I got a bank account or not. Knowledge vs. no knowledge.
vonklaus 10y ago
Ok, this seems interesting. However, unless I am misunderstanding this, of the large table they used for the bulk of the articles content they only showed 6 features under utilized. Obviously, we could prune the execution of some of the JS which is backwards compatible to the early 90s, and some of the html which is based on IBMs 1960s. My super high-level first pass optimization rec for the w3c: If a feature exists for 3 years and a random sampling of 100,000 websites has usage stats of less than < 1% it is automatically deprecated. If it is >1% but less than 5%, it is automatically phased out in 2 years of the spec.
- pilom 10y ago
  Unfortunately this would create a huge disincentive for developers to use any new features no matter how compelling. Would you learn any new features if there was a chance in 2 years all of your users would drop support for it?
  - vonklaus 10y ago
    That was the point. If a feature wasn't great enough to inspire 1 out of 20 developers to experiment with it, then I don't think it makes sense.
    - franciscop 10y ago
      1. Retrocompatibility. It's impossible to assume that 99% of the users are using a modern browser with under 3 years. 2. We are not talking about experimentation, we are talking about deployment into production.
      - vonklaus 10y ago
        I agree with you. I was certainly t aggressive in time frame, but I still agree with the sentiment. We shouldn't have failed decade old features in a browser. As to point 1, you are correct and this is certainly true, however I wish it werent. I assume everyone on hacker news has either gone to college or is aware that a presedential term is 4 years long. Consider how much you as person changed in those 4 years, consider how much the world changed during a 4 year presedential term. China as a country sets guidance for itself, directly for its billion people, and indirectly for the rest of the world, on a rolling 5 yeat basis. I would like to challenge users (and enerprises) to upgrade their browsers over this timeframe and spend the multitude of seconds this takes them to not only increase their own well being, but the well being of developers writing the software they consume.
deleted 10y ago
[deleted]
moron4hire 10y ago
To propose removing these features instead of fixing them fundamentally misunderstands the modern purpose of the web. It's not just for document distribution anymore. It is and has been for many years an application deployment system. To get rid of these features would kill whatever chance we have of getting out of walled garden app stores. I mean, a similar study would probably find "top 10,000 apps don't use 80% of OS features." Just because not a lot of people use a feature doesn't mean it shouldn't exist.
alchemical 10y ago
And for the websites that leverage browser features, those are the websites that stand out and shine. It reminds me of Sturgeon's law https://en.wikipedia.org/wiki/Sturgeon's_law https://en.wikipedia.org/wiki/Sturgeon's_law If 99% of everything is crap, you can bet a sizeable wager the 1% wheat from the chaff are using HTML5 and Javascript APIs. Also if a content silo counts as a 'top website' then this is an outlier and not to be included. Facebook is a walled garden and not indexable. Facebook is parasitical to the web. Twitter and Google are not the web either.
- Retric 10y ago
  You mean like Hacker news? Because, I don't think this site leverages HTML 5. The hard part of any design is knowing what features can be removed not added. HTML 5 and JavaScript is fluff for most websites. PS: HN even uses <table id="hnmain"... o the horror.
  - alchemical 10y ago
    > HTML 5 and JavaScript is fluff for most websites Yeah but HN can be progressively enhanced and it's also one of the few exceptions to the rule. <table id="hnmain".. Indeed. Worth noting the small eco-system of HN redesigns which all leverage HTML5+JS in some way :) All sites should be like an electric stairs: the stairs still works when the power is cut off, but to the inconvenience of the users.
captainmuon 10y ago
There are web sites, and there are web apps. Most websites, think news sites, Wikipedia, etc.. just deliver static content and a whole bunch of ads, as someone noted here. Web applications are the ones that need all this functionality. Why don't we do the following for HTML6, and introduce one profile for sites, and one for apps. - Sites: HTML + CSS, Javascript if at all only for presentation purposes (like DHTML over a decade ago). Can be viewed with a radically stripped-down web browser. All you need is the layout engine and components for display and networking. No WebGL, no sound API, and no shenanigans like ambient light sensors or vibration (wtf!). Think of Google's AMP. - Apps: The whole package that is offered nowadays. We can even go past this and rethink the division between web and native apps. Why can't a web app use sockets? Why can't a native app use the HTML layout engine or live in a tab? Google is planning to blur the gap between web and native with their new "instant apps".
- davegauer 10y ago
  I'm really happy to see that I'm not the only one with this dream. It would be good for developers and good for end users. Everybody wins.
- alchemical 10y ago
  > Can be viewed with a radically stripped-down web browser. Like Lynx? In terms of sites versus apps, I think the browser vendors are responsible for making this happen. Adobe AIR was the closest effort I saw of marrying web technologies with apps. Sadly AIR never took off and whilst I appreciate the intention, it left a huge looming question of what do we actually do with all this new web technology?. One answer I came up with in recent years was what you suggested: of partitioning off the people who want to work with the technologies and keep them separate from the text+image+CSS based web we've all grown to love. Similar to how the demo-scene was an offshoot of game development...
- nitrogen 10y ago
  No WebGL One problem is that some interactive news articles can make very impressive use of WebGL, like the interactive climbing map that accompanied an article about the Dawn Wall freeclimbing record: http://www.nytimes.com/interactive/2015/01/09/sports/the-dawn-wall-el-capitan.html http://www.nytimes.com/interactive/2015/01/09/sports/the-daw...
CM30 10y ago
How many sites are on the internet again? Around a billion. 1% would mean 10 million websites are using each possible feature. Okay, it's not quite that even, and a lot of popular sites (like many news sites) stick to the most basic features, but all these browser features are there for the other various cases. Like aforementioned web apps. Various tech demos. Sites with very specific use cases. In other words, it's because the internet is massive and varied.
bcheung 10y ago
90% of words in the English language are not used by the majority of people. Maybe we should just get rid of those words? 99% of the world doesn't use Calculus. Maybe we should stop teaching it in school. Lame article.
dyoder 10y ago
Right. And then when those features aren't available in the browser, that's used as a justification going back to proprietary (aka native) platforms. It's a circular argument made by people determined to return to the days before we had an Open Web, for whatever reasons. If you don't want to use the features, nobody is forcing you to do so.
soneil 10y ago
This seems pretty obvious to me. And at the same time, entirely not a problem. A great example that comes to mind is the drm component that Netflix require to deliver html5 instead of that spotlight .. thing. I cannot think of any other site that has needed it - or at least, any other site I visited before it was available, that suffered for it. And still, I consider it a requirement. That feature that I require for exactly one site.
pcwalton 10y ago
This is something I've noticed a lot when developing Servo. The vast majority of the time, when a site is broken in Servo, it's due to some CSS 2.1 bug or another (CSS2 has existed since 1998), or a broken DOM API that's been in the platform for years and years. Attention is disproportionately focused on the new stuff when the reality is that old standards still rule. I wouldn't necessarily agree that the conclusion is to just rip stuff out of the Web platform, though (although there is plenty of stuff I'd love to drop). Rather, we need to implement the features in a secure way. This isn't rocket science. Notice, as usual, that the majority of these security issues are straightforward memory safety issues† in C++: e.g. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox+svg https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox+svg † Food for thought for those claiming that "modern C++" solves these problems.

> ALS, “ambient light events”, would let browsers respond to the light level the laptop, phone or desktop is exposed to if anybody used it. Can someone give me a good, non-gimmicky example of what this would be used for?

unlinker 10y ago
Use a white letters on black background theme in case the user is browsing your site in bed with his lights off? ^_^
reicher89 10y ago
Hmm, perhaps a text-heavy site could switch between "night" and "day" modes for ease of reading
- mcdoh 10y ago
  Just last night I was happy to find that Safari Books Online had a 'night' feature, automatically switching would have saved me thirty minutes of burned retinas.
- marssaxman 10y ago
  Oh god. No no no. I cannot hate this idea hard enough to overcome my fear that someday this kind of thing might actually happen! This would be the browser's job, under user control, not ever the site's job. My computer, my choice, no you don't get to decide that for me just because you are a web page designer.
  - TheCowboy 10y ago
    It's difficult to pull this off with every website and keep it readable, without any hint from the site. This is why we have CSS for different screen sizes, rather than relying on mobile browsers to make all the decisions, along with an option to view the site in "desktop mode". I do agree that it would be annoying if sites made this decision for users. But I think the more promising use for this could be enabling aesthetically pleasing color palettes that are power consumption optimized. Picture a HN that switches to darker tones of the current colors when you're on a mobile device.
    - marssaxman 10y ago
      I'm already constantly using "readability mode" to strip away as much of the custom styling as I can, because letting designers run riot - and building browsers that obey their wishes - has turned the web into such a mess. Tighter limits and more end-user control would be better. Different people have different preferences about their browsing experience and should be able to control that without having to rely on every last web designer to make helpful choices, because they really just don't.
      - dredmorbius 10y ago
        My vapourware web browser is tentatively titled "fuck your web designer". It will ignore site-provided CSS. Interested?
        marssaxman 10y ago
        Ha! I would like to give that a try.
vonklaus 10y ago
essentially something like f.lux presumably.
iambateman 10y ago
Yeah. Spotify would stop ads if the audio got too low. In the same way, ambient light could be used to make sure an ad is watched. Not saying it's the most important case ever, but it would be important if you needed it
benologist 10y ago
Do you need an example right now or can you wait until someone does something cool with it that's only enabled because the option exists? If we stopped adding new capabilities to JavaScript even as new sensors and w/e go mainstream we'd start needing Flash all over again.
- zghst 10y ago
  Before we add any new APIs we need a permissions interface for the web. Many new APIs add creepy data points that the user be aware that they are providing.
zghst 10y ago
More advanced analytics, tracking your battery + ambient lights + other capabilities...
gene-h 10y ago
Provided one can access sensor data fast enough, cross device tracking[0]. Display an ad that lights up the room in such a way that you can read it with the sensor. Communication across an airgap. If you have two devices with screens and said sensors in a dark room, they might be able to communicate by turning screens on and off. Most speculatively, imaging the environment with compressive imaging[1]. One might be able to flash some patterns on the screen and look at light sensor output to take a picture. Giving web browsers access to sensors on our devices is sort of scary. [0] http://arstechnica.com/tech-policy/2015/11/beware-of-ads-that-use-inaudible-sound-to-link-your-phone-tv-tablet-and-pc/ http://arstechnica.com/tech-policy/2015/11/beware-of-ads-tha... [1] http://arxiv.org/pdf/1305.7181.pdf http://arxiv.org/pdf/1305.7181.pdf
- coroutines 10y ago
  I like how you ripped out any positivity around the topic :D You are my hero

reicher89 10y ago

this was very interesting: "SVG, for example, has a problem however you look at it: on one hand more than 15 per cent of the sites use it, on the other hand, nearly 87 per cent of blockers block it, but it's had 14 security warnings (CVEs, Common Vulnerabilities and Exposures) in the last three years."

matthewmacleod 10y ago
I am deeply suspicious of that number. I've never encountered a plugin or anything of the sort that provides for "blocking SVG", and it's fully supported in all recent browsers.
- nikkwong 10y ago
  ^ Yeah. I use SVG heavily in all my web projects, and I've never seen a single user access one of my sites & had the SVG blocked. I wouldn't buy '87%' at all.
- snyderp 10y ago
  Paper author here. The blocking % referenced, and discussed in more detail in the paper, is the % of times a feature is used when someone visits the page, but ISNT used when you visit the page with AdBlock Plus and Ghostery installed. In other words, its how often these popular blocking extensions prevent the JS APIs from firing. Its not blocking SVG, its blocking (mostly fingerprinting) JS libraries from running SVG JS methods
  - matthewmacleod 10y ago
    Aha, thank you for the clarification. That's a lot less worrying.
snyderp 10y ago
Just a note on this (I'm the lead author on the paper author), the blocking rate has to do with the reduction in JS usage when you install popular blocking extensions. So its not that extensions block SVG directly, its that AdBlock Plus and Ghostery block a bunch of libraries, and those libraries use the SVG methods to finger print (and do other stuff)

jbob2000 10y ago

Kind of a silly article. Most top websites just serve static content with tons of ad-network crap, they would never need 83% of the features. This is like saying "the most sold vehicles in the world don't use 90% of the horsepower they have". No shit, the most sold vehicles in the world are Corollas and Civics, ie. "sit in traffic and commute" type cars. It doesn't cost anything to keep these features around, why kill them off? Code is cheap, it doesn't cost you, the user, anything to have the features in your browser...

ScottBurson 10y ago
It does cost you something if that code has security holes.
- captn3m0 10y ago
  Most of these features also rely on user-approvals so it is not as if every website is going to jump on and start using GeoLocation APIs just because they can. It is a nice study showing how far these niche new features have reached, but that shouldn't affect how we are working on the new ones (except perhaps improving the security models of these).
- jbob2000 10y ago
  That's a big if. Anything could have security holes, seems pedantic to kill a feature because it might have a security hole at some point.
  - creshal 10y ago
    > That's a big if. Reminder that we've been issuing so many CVEs last year we had to upgrade the numbering spec to allow for more than ten thousand a year.
vonklaus 10y ago
I don't know this to be true, but my assumption as someone not building the interpreter/vms for JS is that if you eliminated all of that shit you could probably get a much better optimization from your engine. ALso, security was touched on above.

pilom 10y ago

Can anyone recommend an updated browser that skips most unused features to run faster, use less memory or be more secure?

vonklaus 10y ago
Brave software. This was created by Brendan Eich the x ceo of mozilla. Eich does seem to have some problems with equality[0] which may have contributed to his ouster at Mozilla, but Brave is a top shelf browser. Super great team, pretty security conscious and given the Eich developed JS, well, they have a pretty good working knowledge of it. Brian Bondy is a super awesome guy (thanks for adding duckduckgo BTW), Yan Zhu is a pretty well known dev & security blogger and they had the woman who wrote a couple encrypted chat clients working there (apologies her name escapes me) but she isn't on the site. I assume the rest of the team is talented. So in essence, I ove Brave. I still wish they would make a goddamn search engine, but it is an awesome browser. [0] NaN === NaN returns false?. 0.0001 + 0.0002 !== 0.0003? weird.
- tbirdz 10y ago
  These are standard IEEE754 floating point behaviors.
  - vonklaus 10y ago
    I am aware. It was a bad joke.
- LionessLover 10y ago
  In addition to the reply with the pointer to the standards, sure NaN !== NaN. NaN means "no idea what we've got here". When you get to say that phrase, would you expect it to be used for exactly one thing and one thing only? To me "I have no idea" means the possibilities are endless (infinite). We can only compare for equality when we know what we are looking at, otherwise it's just "status unknown". Yes, it might be equality - the chances are infinitely small though. If you take the argument a step further and say "but I got the two NaNs that I compare doing the exact same operation, so even if I don't know what I've got from a mathematical point of view whatever it is it should be equal". In that case you are not actually comparing the NaNs but the path(s) that got you there. I must say I find the whole NaN, null, 0 vs. undefined interesting on so many levels. There is a world of a difference between knowing you've got nothing (null or 0) and not knowing what've you've got at all. "null": I have no bank account. "0": my balance is 0. "undefined" or "NaN": I lost my memory after yesterdays binge drinking and don't know who I am and if I got a bank account or not. Knowledge vs. no knowledge.

vonklaus 10y ago

Ok, this seems interesting. However, unless I am misunderstanding this, of the large table they used for the bulk of the articles content they only showed 6 features under utilized. Obviously, we could prune the execution of some of the JS which is backwards compatible to the early 90s, and some of the html which is based on IBMs 1960s. My super high-level first pass optimization rec for the w3c: If a feature exists for 3 years and a random sampling of 100,000 websites has usage stats of less than < 1% it is automatically deprecated. If it is >1% but less than 5%, it is automatically phased out in 2 years of the spec.

pilom 10y ago
Unfortunately this would create a huge disincentive for developers to use any new features no matter how compelling. Would you learn any new features if there was a chance in 2 years all of your users would drop support for it?
- vonklaus 10y ago
  That was the point. If a feature wasn't great enough to inspire 1 out of 20 developers to experiment with it, then I don't think it makes sense.
  - franciscop 10y ago
    1. Retrocompatibility. It's impossible to assume that 99% of the users are using a modern browser with under 3 years. 2. We are not talking about experimentation, we are talking about deployment into production.
    - vonklaus 10y ago
      I agree with you. I was certainly t aggressive in time frame, but I still agree with the sentiment. We shouldn't have failed decade old features in a browser. As to point 1, you are correct and this is certainly true, however I wish it werent. I assume everyone on hacker news has either gone to college or is aware that a presedential term is 4 years long. Consider how much you as person changed in those 4 years, consider how much the world changed during a 4 year presedential term. China as a country sets guidance for itself, directly for its billion people, and indirectly for the rest of the world, on a rolling 5 yeat basis. I would like to challenge users (and enerprises) to upgrade their browsers over this timeframe and spend the multitude of seconds this takes them to not only increase their own well being, but the well being of developers writing the software they consume.

deleted 10y ago

[deleted]

moron4hire 10y ago

To propose removing these features instead of fixing them fundamentally misunderstands the modern purpose of the web. It's not just for document distribution anymore. It is and has been for many years an application deployment system. To get rid of these features would kill whatever chance we have of getting out of walled garden app stores. I mean, a similar study would probably find "top 10,000 apps don't use 80% of OS features." Just because not a lot of people use a feature doesn't mean it shouldn't exist.

alchemical 10y ago

And for the websites that leverage browser features, those are the websites that stand out and shine. It reminds me of Sturgeon's law https://en.wikipedia.org/wiki/Sturgeon's_law https://en.wikipedia.org/wiki/Sturgeon's_law If 99% of everything is crap, you can bet a sizeable wager the 1% wheat from the chaff are using HTML5 and Javascript APIs. Also if a content silo counts as a 'top website' then this is an outlier and not to be included. Facebook is a walled garden and not indexable. Facebook is parasitical to the web. Twitter and Google are not the web either.

Retric 10y ago
You mean like Hacker news? Because, I don't think this site leverages HTML 5. The hard part of any design is knowing what features can be removed not added. HTML 5 and JavaScript is fluff for most websites. PS: HN even uses <table id="hnmain"... o the horror.
- alchemical 10y ago
  > HTML 5 and JavaScript is fluff for most websites Yeah but HN can be progressively enhanced and it's also one of the few exceptions to the rule. <table id="hnmain".. Indeed. Worth noting the small eco-system of HN redesigns which all leverage HTML5+JS in some way :) All sites should be like an electric stairs: the stairs still works when the power is cut off, but to the inconvenience of the users.

captainmuon 10y ago

There are web sites, and there are web apps. Most websites, think news sites, Wikipedia, etc.. just deliver static content and a whole bunch of ads, as someone noted here. Web applications are the ones that need all this functionality. Why don't we do the following for HTML6, and introduce one profile for sites, and one for apps. - Sites: HTML + CSS, Javascript if at all only for presentation purposes (like DHTML over a decade ago). Can be viewed with a radically stripped-down web browser. All you need is the layout engine and components for display and networking. No WebGL, no sound API, and no shenanigans like ambient light sensors or vibration (wtf!). Think of Google's AMP. - Apps: The whole package that is offered nowadays. We can even go past this and rethink the division between web and native apps. Why can't a web app use sockets? Why can't a native app use the HTML layout engine or live in a tab? Google is planning to blur the gap between web and native with their new "instant apps".

davegauer 10y ago
I'm really happy to see that I'm not the only one with this dream. It would be good for developers and good for end users. Everybody wins.
alchemical 10y ago
> Can be viewed with a radically stripped-down web browser. Like Lynx? In terms of sites versus apps, I think the browser vendors are responsible for making this happen. Adobe AIR was the closest effort I saw of marrying web technologies with apps. Sadly AIR never took off and whilst I appreciate the intention, it left a huge looming question of what do we actually do with all this new web technology?. One answer I came up with in recent years was what you suggested: of partitioning off the people who want to work with the technologies and keep them separate from the text+image+CSS based web we've all grown to love. Similar to how the demo-scene was an offshoot of game development...
nitrogen 10y ago
No WebGL One problem is that some interactive news articles can make very impressive use of WebGL, like the interactive climbing map that accompanied an article about the Dawn Wall freeclimbing record: http://www.nytimes.com/interactive/2015/01/09/sports/the-dawn-wall-el-capitan.html http://www.nytimes.com/interactive/2015/01/09/sports/the-daw...

CM30 10y ago

How many sites are on the internet again? Around a billion. 1% would mean 10 million websites are using each possible feature. Okay, it's not quite that even, and a lot of popular sites (like many news sites) stick to the most basic features, but all these browser features are there for the other various cases. Like aforementioned web apps. Various tech demos. Sites with very specific use cases. In other words, it's because the internet is massive and varied.

bcheung 10y ago

90% of words in the English language are not used by the majority of people. Maybe we should just get rid of those words? 99% of the world doesn't use Calculus. Maybe we should stop teaching it in school. Lame article.

dyoder 10y ago

Right. And then when those features aren't available in the browser, that's used as a justification going back to proprietary (aka native) platforms. It's a circular argument made by people determined to return to the days before we had an Open Web, for whatever reasons. If you don't want to use the features, nobody is forcing you to do so.

soneil 10y ago

This seems pretty obvious to me. And at the same time, entirely not a problem. A great example that comes to mind is the drm component that Netflix require to deliver html5 instead of that spotlight .. thing. I cannot think of any other site that has needed it - or at least, any other site I visited before it was available, that suffered for it. And still, I consider it a requirement. That feature that I require for exactly one site.

pcwalton 10y ago

This is something I've noticed a lot when developing Servo. The vast majority of the time, when a site is broken in Servo, it's due to some CSS 2.1 bug or another (CSS2 has existed since 1998), or a broken DOM API that's been in the platform for years and years. Attention is disproportionately focused on the new stuff when the reality is that old standards still rule. I wouldn't necessarily agree that the conclusion is to just rip stuff out of the Web platform, though (although there is plenty of stuff I'd love to drop). Rather, we need to implement the features in a secure way. This isn't rocket science. Notice, as usual, that the majority of these security issues are straightforward memory safety issues† in C++: e.g. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox+svg https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox+svg † Food for thought for those claiming that "modern C++" solves these problems.