3 ms·

The problem is this: HTML (+CSS) is supposed to be a standardized and recommendable format for publishing rich text with the expectation that it can be rendered

The problem is this: HTML (+CSS) is supposed to be a standardized and recommendable format for publishing rich text with the expectation that it can be rendered for a long time to come. But if only a single browser will be able to display it, this not only questions the longevity claim, but also questions the whole web stack. New CSS specs can't be reviewed and proven with independent implementations, and web specs will, even more so than they already do, become "whatever Chrome does". This is a terrible and fatal result for the web as we know it. Because why would we continue the practice of creating baroque, power-inefficient web frontends with JavaScript and the browser stack monstrosity when we're essentially targetting a single browser? We could as well use a much leaner and lighter GUI framework designed for the purpose, and a saner language. What did we really expect from the way so-called web standards are created? WHATWG (who write the HTML5 specs and call this a "standard") pride themselves in creating a "living standard" where nothing ever is locked down, and ECMA has put itself up to creating yearly JavaScript updates (after the language has stagnated for 15 years). W3C creates an enormous amount of CSS specs and has said goodbye to versions/levels and profiles a long time ago. The result is that there is no reasonable spec as an implementation target for browser development. Those in the game have closed the door behind them. Firefox has, unfortunately, a shrinking user base, is financially dependent on Google, and might suffer from problematic incentives in the future. The web is in tatters.

JumpCrisscross 8y ago
> But if only a single browser will be able to display it Chromium has no intrinsic power. If Chromium and Google disagree, the latter can easily break off. The browser political landscape is fragmented as ever.
- 43920 8y ago
  > the latter can easily break off How? Developing a browser takes hundreds of millions of dollars, and Google is currently providing all the funding for that (meaning they decide what changes get made). Who has the necessary resources to fork Chromium, and would actually be willing to do it?
  - jeromebaek 8y ago
    Microsoft, of course.
wyqydsyq 8y ago
> But if only a single browser will be able to display it, this not only questions the longevity claim, but also questions the whole web stack. New CSS specs can't be reviewed and proven with independent implementations, and web specs will, even more so than they already do, become "whatever Chrome does". Safari and Konqueror still use WebKit, Firefox still uses Gecko, so not "only a single browser will be able to display it", but multiple maintained browsers using 3 different implementations will still be able to display it. Additionally, even in that worst-case scenario of Chromium/Blink/V8 becoming the de-facto implementation and making standards irrelevant, it wouldn't be "whatever Chrome does", but "whatever Chromium does". Being in that situation Chromium would be in use by everyone, so if anything that only places more power in the hands of the community because Chromium is an open-source project. Why should every browser have their own competing (and often incompatible) implementations of each standard to the detriment of the web? How is that more beneficial than browser developers all collaborating on a common, shared implementation? Very rarely have implementation-specific differences between browsers benefited the web, generally such differences will either remain implementation-specific and become redundant (e.g. all the IE-only APIs) or are experimental implementations of a standard that's only in draft state and will be updated to be consistent once the relevant standard is finalised, in both cases they're just neat toys for developers to play with that aren't practical to employ in production (because they'll only work for a fraction of viewers). > This is a terrible and fatal result for the web as we know it. Because why would we continue the practice of creating baroque, power-inefficient web frontends with JavaScript and the browser stack monstrosity when we're essentially targetting a single browser? We could as well use a much leaner and lighter GUI framework designed for the purpose, and a saner language. This is a fantastic and wonderful result for the web as we know it. With less implementations to support, the web would be substantially faster and more efficient. Because why would we want to load our asset bundles with megabytes of polyfills and shims just so things don't explode on the odd chance someone tries to view your website in the default browser of their OS that's either outdated or poorly implements specs? If every major browser ran Blink/Webkit + V8, the web could be written once in native ES2018 javascript and consistently execute anywhere. This is not the case today because implementations behave differently, you can't write a webapp purely following the established specs because the specs are inconsistently implemented. For example `navigator.mediaDevices` API works differently across browsers, some browsers support-sub features that others don't etc. This ends up requiring checks and work-arounds that waste processing power to execute and human resources to implement.

JumpCrisscross 8y ago

> But if only a single browser will be able to display it Chromium has no intrinsic power. If Chromium and Google disagree, the latter can easily break off. The browser political landscape is fragmented as ever.

43920 8y ago
> the latter can easily break off How? Developing a browser takes hundreds of millions of dollars, and Google is currently providing all the funding for that (meaning they decide what changes get made). Who has the necessary resources to fork Chromium, and would actually be willing to do it?
- jeromebaek 8y ago
  Microsoft, of course.

wyqydsyq 8y ago

> But if only a single browser will be able to display it, this not only questions the longevity claim, but also questions the whole web stack. New CSS specs can't be reviewed and proven with independent implementations, and web specs will, even more so than they already do, become "whatever Chrome does". Safari and Konqueror still use WebKit, Firefox still uses Gecko, so not "only a single browser will be able to display it", but multiple maintained browsers using 3 different implementations will still be able to display it. Additionally, even in that worst-case scenario of Chromium/Blink/V8 becoming the de-facto implementation and making standards irrelevant, it wouldn't be "whatever Chrome does", but "whatever Chromium does". Being in that situation Chromium would be in use by everyone, so if anything that only places more power in the hands of the community because Chromium is an open-source project. Why should every browser have their own competing (and often incompatible) implementations of each standard to the detriment of the web? How is that more beneficial than browser developers all collaborating on a common, shared implementation? Very rarely have implementation-specific differences between browsers benefited the web, generally such differences will either remain implementation-specific and become redundant (e.g. all the IE-only APIs) or are experimental implementations of a standard that's only in draft state and will be updated to be consistent once the relevant standard is finalised, in both cases they're just neat toys for developers to play with that aren't practical to employ in production (because they'll only work for a fraction of viewers). > This is a terrible and fatal result for the web as we know it. Because why would we continue the practice of creating baroque, power-inefficient web frontends with JavaScript and the browser stack monstrosity when we're essentially targetting a single browser? We could as well use a much leaner and lighter GUI framework designed for the purpose, and a saner language. This is a fantastic and wonderful result for the web as we know it. With less implementations to support, the web would be substantially faster and more efficient. Because why would we want to load our asset bundles with megabytes of polyfills and shims just so things don't explode on the odd chance someone tries to view your website in the default browser of their OS that's either outdated or poorly implements specs? If every major browser ran Blink/Webkit + V8, the web could be written once in native ES2018 javascript and consistently execute anywhere. This is not the case today because implementations behave differently, you can't write a webapp purely following the established specs because the specs are inconsistently implemented. For example `navigator.mediaDevices` API works differently across browsers, some browsers support-sub features that others don't etc. This ends up requiring checks and work-arounds that waste processing power to execute and human resources to implement.