4 ms·

Setting aside the merits/lack-thereof of this particular decision, Chromium ignoring established web standards like this is especially dangerous as we're trendi

by ss3000 7y ago

Setting aside the merits/lack-thereof of this particular decision, Chromium ignoring established web standards like this is especially dangerous as we're trending towards a world where 1) Chromium itself powers the most popular browser in the world by an increasingly unhealthy margin, and 2) even competing browsers are increasingly becoming skins on top of Chromium. We are becoming more and more reliant on the developers of Chromium to be steadfast stewards of the standardization process. Their massive influence means that any deviation from actual web standards on their part will inevitably create a new and conflicting de-facto standard that will create decades of lasting damage and irreversible tech debt for the entire web (eventually leading to a repeat of the IE6 dark ages). Decisions like this demonstrate an utter disregard for the crucial role Chromium plays in the web standardization process, and jeopardizes the entire ecosystem.

ko27 7y ago
Strictly speaking, Chrome is not ignoring a web standard, since the standard does not require this behavior (no "MUST" keyword).
- obituary_latte 7y ago
  Well they are ignoring hundreds if not thousands of developers which is the main issue at this point.
  - deleted 7y ago
    [deleted]
  - ko27 7y ago
    Well, that's what Chrome always does? Just like the preventDefault breaking change thing. They have no problem ignoring developers if they think it will be a net benefit for user experience.
    - obituary_latte 7y ago
      Yup. Very frustrating as a dev. I don’t really get how they rationalize it either - having their autofill appear over and obstruct a developers autocomplete functionality is not user friendly!
  - jrockway 7y ago
    By ignoring "hundreds if not thousands of developers" they are respecting the wishes of millions of end-users that don't want the site owner to decide what they can and can't autofill. Obviously a simple boolean is the wrong design here. But can you suggest a better one?
    - fuzzy2 7y ago
      I don't think "millions of end-users" want broken websites because now another developer (Google) gets to decide what's correct (instead of the web dev). A better solution could be to just behave reasonably by default but allow the user to re-enable auto-fill with a single click.
    - obituary_latte 7y ago
      Surely there’s a way to check if a field has some kind of programatic interaction like typeahead. Maybe check for that before taking over with autofill? I don’t know - maybe that would break spec or something - I’m not a browser developer. I just know the pain of autocomplete=“off” not working as expected.
- ss3000 7y ago
  Point taken. Maybe in this case the spec authors were also at fault for leaving too much leeway in the implementation. Nevertheless, from their stance on the issue so far it stands to reason that the Chromium team would have objected to any efforts to tighten the spec, which would also have led us to this same situation.
- dwb 7y ago
  That depends entirely on your interpretation of RFC 2119 in this context – whether you consider Google to have "valid reasons" or not. It's not an objective or inarguable issue.
ss3000 7y ago
W.r.t. this particular decision, I feel a more reasonable approach here might have been to allow users to manually trigger autocomplete on individual fields with `autocomplete="off"`, and/or to allow users to strip away the ability to disable autocomplete on a site by site basis. Analogously to how users are able to selectively grant access to certain default-off features for each website (notifications, camera access), users should also be able to revoke access to certain default-on features for sites that abuse them without affecting the vast majority of sites that use the features for their intended purposes to create a better user experience.
isostatic 7y ago
It’s heresy on HN to suggest that a single browser running the web is a bad idea.
- wyattpeak 7y ago
  HN comments pretty consistently argue that browser monoculture is a problem. I don't know where you're getting this.
- mcv 7y ago
  I think you're stumbling over too many negations here. A single browser running the web is a bad idea. Diversity in browsers is a good idea. If any statement related to this could be heresy here, then it would be heresy to suggest that a single browser running the web is a good idea.
jjcm 7y ago
This isn't even the first time we've seen this either. Both Chrome Mobile and Safari Mobile go against the standard and implement `vh` incorrectly. Honestly it seems strange that they go against the standard though considering how much power they have in defining it. Why break from the standard when you can just update the standard. It ends up being the worst of both worlds - documentation that says one thing (that they had a hand in building) and an implementation that does something completely different.
- chrismorgan 7y ago
  Admittedly, the viewport units are just all-round badly thought out and fundamentally broken. (The corresponding problem with vw is that the viewport units includes viewport scrollbars, so that on a page with vertical scrolling, `width: 100vw` will cause horizontal scrolling on platforms where the scrollbars take space.)
  - Santosh83 7y ago
    Genuinely curious but how are they fundamentally broken? Or at least, any more so than px or cm or em etc? They all have weird edge cases at extreme usage scenarios... Or rather, if you were to 'fix' vw/vh, how would you go about it?
    - chrismorgan 7y ago
      There are two fundamental problems. First is the scrollbar thing I mentioned. It means that you can’t use it for layout purposes; you thought you could sit four blocks side-by-side with `width: 25vw`? (And that was pretty much the whole reason why people wanted viewport units in the first place—this being before flexbox provided alternatives that are generally acceptable, though not without flaws, or grid provided often better alternatives.) Sorry, that’ll only work on a platform with overlay scrollbars, not where scrollbars actually take up space. There’s fun history around Firefox’s implementation where they made it possible to get the “right” behaviour, but no one else implemented that, so it was eventually removed from the spec. Secondly, it was also predicated on the idea that the physical viewport size won’t be changing all the time; but on mobile platforms where the address bar can get out of the way as you scroll that’s simply not true, so you’re stuck with browsers having to decide between two interpretations: vh picking either the smallest or largest value and thus not actually reflecting the viewport height half the time, or vh reflecting the viewport height and causing the page layout to jump around in a jarring fashion when the address bar expands or collapses, when vh is used as part of the layout. The first can be fixed in two ways (which can be combined): firstly, by defining new units that exclude document element scrollbars (e.g. 100vw2 ≅ calc(100vw - env(scrollbar-layout-width-auto, 0px)), to define it in terms of what follows); secondly, by exposing the layout width of scrollbars to CSS, e.g. as env(scrollbar-layout-width-auto) for the width with `scrollbar-width: auto` and env(scrollbar-layout-width-thin) for the width with `scrollbar-width: thin`. These values would be something like 17px and 8px on Firefox on Windows, and 0px and 0px on platforms with overlay scrollbars. The second, you probably need to expose new constants for the possible extreme values of viewport height. e.g. I could imagine env(viewport-min-height, 100vh) and env(viewport-max-height, 100vh) working, which would then allow developers to select one or the other, as suited their purpose. Or define new units opinionated on which value should be used, and then deprecate vw and vh since they’re inconsistently implemented. (In using env(), I must caution that it’s currently rather broken for some sorts of situations: https://github.com/w3c/csswg-drafts/issues/3285. https://github.com/w3c/csswg-drafts/issues/3285.)

by ss3000 7y ago

ko27 7y ago

Strictly speaking, Chrome is not ignoring a web standard, since the standard does not require this behavior (no "MUST" keyword).

obituary_latte 7y ago
Well they are ignoring hundreds if not thousands of developers which is the main issue at this point.
- deleted 7y ago
  [deleted]
- ko27 7y ago
  Well, that's what Chrome always does? Just like the preventDefault breaking change thing. They have no problem ignoring developers if they think it will be a net benefit for user experience.
  - obituary_latte 7y ago
    Yup. Very frustrating as a dev. I don’t really get how they rationalize it either - having their autofill appear over and obstruct a developers autocomplete functionality is not user friendly!
- jrockway 7y ago
  By ignoring "hundreds if not thousands of developers" they are respecting the wishes of millions of end-users that don't want the site owner to decide what they can and can't autofill. Obviously a simple boolean is the wrong design here. But can you suggest a better one?
  - fuzzy2 7y ago
    I don't think "millions of end-users" want broken websites because now another developer (Google) gets to decide what's correct (instead of the web dev). A better solution could be to just behave reasonably by default but allow the user to re-enable auto-fill with a single click.
  - obituary_latte 7y ago
    Surely there’s a way to check if a field has some kind of programatic interaction like typeahead. Maybe check for that before taking over with autofill? I don’t know - maybe that would break spec or something - I’m not a browser developer. I just know the pain of autocomplete=“off” not working as expected.
ss3000 7y ago
Point taken. Maybe in this case the spec authors were also at fault for leaving too much leeway in the implementation. Nevertheless, from their stance on the issue so far it stands to reason that the Chromium team would have objected to any efforts to tighten the spec, which would also have led us to this same situation.
dwb 7y ago
That depends entirely on your interpretation of RFC 2119 in this context – whether you consider Google to have "valid reasons" or not. It's not an objective or inarguable issue.

ss3000 7y ago

W.r.t. this particular decision, I feel a more reasonable approach here might have been to allow users to manually trigger autocomplete on individual fields with `autocomplete="off"`, and/or to allow users to strip away the ability to disable autocomplete on a site by site basis. Analogously to how users are able to selectively grant access to certain default-off features for each website (notifications, camera access), users should also be able to revoke access to certain default-on features for sites that abuse them without affecting the vast majority of sites that use the features for their intended purposes to create a better user experience.

isostatic 7y ago

It’s heresy on HN to suggest that a single browser running the web is a bad idea.

wyattpeak 7y ago
HN comments pretty consistently argue that browser monoculture is a problem. I don't know where you're getting this.
mcv 7y ago
I think you're stumbling over too many negations here. A single browser running the web is a bad idea. Diversity in browsers is a good idea. If any statement related to this could be heresy here, then it would be heresy to suggest that a single browser running the web is a good idea.

jjcm 7y ago

This isn't even the first time we've seen this either. Both Chrome Mobile and Safari Mobile go against the standard and implement `vh` incorrectly. Honestly it seems strange that they go against the standard though considering how much power they have in defining it. Why break from the standard when you can just update the standard. It ends up being the worst of both worlds - documentation that says one thing (that they had a hand in building) and an implementation that does something completely different.

chrismorgan 7y ago
Admittedly, the viewport units are just all-round badly thought out and fundamentally broken. (The corresponding problem with vw is that the viewport units includes viewport scrollbars, so that on a page with vertical scrolling, `width: 100vw` will cause horizontal scrolling on platforms where the scrollbars take space.)
- Santosh83 7y ago
  Genuinely curious but how are they fundamentally broken? Or at least, any more so than px or cm or em etc? They all have weird edge cases at extreme usage scenarios... Or rather, if you were to 'fix' vw/vh, how would you go about it?
  - chrismorgan 7y ago
    There are two fundamental problems. First is the scrollbar thing I mentioned. It means that you can’t use it for layout purposes; you thought you could sit four blocks side-by-side with `width: 25vw`? (And that was pretty much the whole reason why people wanted viewport units in the first place—this being before flexbox provided alternatives that are generally acceptable, though not without flaws, or grid provided often better alternatives.) Sorry, that’ll only work on a platform with overlay scrollbars, not where scrollbars actually take up space. There’s fun history around Firefox’s implementation where they made it possible to get the “right” behaviour, but no one else implemented that, so it was eventually removed from the spec. Secondly, it was also predicated on the idea that the physical viewport size won’t be changing all the time; but on mobile platforms where the address bar can get out of the way as you scroll that’s simply not true, so you’re stuck with browsers having to decide between two interpretations: vh picking either the smallest or largest value and thus not actually reflecting the viewport height half the time, or vh reflecting the viewport height and causing the page layout to jump around in a jarring fashion when the address bar expands or collapses, when vh is used as part of the layout. The first can be fixed in two ways (which can be combined): firstly, by defining new units that exclude document element scrollbars (e.g. 100vw2 ≅ calc(100vw - env(scrollbar-layout-width-auto, 0px)), to define it in terms of what follows); secondly, by exposing the layout width of scrollbars to CSS, e.g. as env(scrollbar-layout-width-auto) for the width with `scrollbar-width: auto` and env(scrollbar-layout-width-thin) for the width with `scrollbar-width: thin`. These values would be something like 17px and 8px on Firefox on Windows, and 0px and 0px on platforms with overlay scrollbars. The second, you probably need to expose new constants for the possible extreme values of viewport height. e.g. I could imagine env(viewport-min-height, 100vh) and env(viewport-max-height, 100vh) working, which would then allow developers to select one or the other, as suited their purpose. Or define new units opinionated on which value should be used, and then deprecate vw and vh since they’re inconsistently implemented. (In using env(), I must caution that it’s currently rather broken for some sorts of situations: https://github.com/w3c/csswg-drafts/issues/3285. https://github.com/w3c/csswg-drafts/issues/3285.)