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.<p>Why don't we do the following for HTML6, and introduce one profile for sites, and one for apps.<p>- 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.<p>- 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".
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.<p>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...
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.<p>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. <a href="https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox+svg" rel="nofollow">https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firefox+svg</a><p>† Food for thought for those claiming that "modern C++" solves these problems.
How many sites are on the internet again?<p>Around a billion.<p>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.<p>In other words, it's because the internet is massive and varied.
90% of words in the English language are not used by the majority of people. Maybe we should just get rid of those words?<p>99% of the world doesn't use Calculus. Maybe we should stop teaching it in school.<p>Lame article.
And for the websites that leverage browser features, those are the websites that stand out and shine.<p>It reminds me of Sturgeon's law <a href="https://en.wikipedia.org/wiki/Sturgeon's_law" rel="nofollow">https://en.wikipedia.org/wiki/Sturgeon's_law</a><p>If 99% of everything is crap, you can bet a sizeable wager the 1% wheat from the chaff are using HTML5 and Javascript APIs.<p>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.
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.<p>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.
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.
> <i>ALS, “ambient light events”, would let browsers respond to the light level the laptop, phone or desktop is exposed to if anybody used it.</i><p>Can someone give me a good, non-gimmicky example of what this would be used for?
This seems pretty obvious to me. And at the same time, entirely not a problem.<p>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.<p>And still, I consider it a requirement. That feature that I require for exactly one site.
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."
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.<p>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.<p>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.