undefined | Better HN

0 pointsvincnetas4y ago0 comments

It's not up to Chrome devs to accept or deny viable use cases. As someone from comments mentions, it's in the spec, and chrome devs should not deviate from that irrelevant if what they think is accepted or not accepted use case. Or they should go and push for spec change.

0 comments

thaumasiotes4y ago

I feel like repeating an old comment of mine ( https://news.ycombinator.com/item?id=27231194 ) here:

> Conforming to the spec is not a virtue.

> When the spec is malicious, conforming to the spec is malicious behavior.

> I'm comfortable calling it a bug in the spec. `a << 40` needs to have 0 in the lowest 40 bits. It does not need to have random values in bits 8-31.

> This behavior is documented, but that doesn't make things better, it makes them worse.

> But the philosophy that says "if it's documented, then it's OK" doesn't even allow for the concept of a bug in the spec.

Implementing a bad idea doesn't become a good idea just because someone once wrote that it was.

vincnetasOP4y ago

I think predictability is important. And specs define what you can expect. System with undefined/unpredictable behaviour does complicate a life in long run even if at the moment it looks more convenient.

wildrhythms4y ago

If the topic is predictability, I would expect banks to use the spec to disable only predictably non-autofillable fields with the user's best experience in mind. Disabling autocomplete on username and password fields in the name of some nebulous 'security' goal is neither predictable, nor in line with most user's expectation of usability; it also doesn't make the system more secure. I could argue that these sites themselves aren't following the spec by disabling the fields.

Remember, there are autocomplete values to accommodate "current-password"[1]. If your bank has a field representing a password without that attribute, do you think that's following the spec?

[1] https://html.spec.whatwg.org/multipage/form-control-infrastr...

bipson4y ago

I guess there are just too many pages that break autocomplete, e.g. for username/password as a "security feature".

I encountered quite a few myself and was very annoyed. I guess devs took the "usability" side of the question.

EDIT: phrasing

Aeolun4y ago

But it’s not useable at all. A form without autocomplete is perfectly useable. A form with autocomplete where it’s not wanted is an absolute hindrance.

lupire4y ago

A non autocomplete password field is an absolute hindrance.

Cederfjard4y ago

The spec is driven by browser implementations rather than the other way around, is it not?

vincnetasOP4y ago

It should not be so. Or else Spec would just look like "do as chrome does"

benhurmarcel4y ago

> It's not up to Chrome devs

Well apparently it is, because they're doing it.

eru4y ago

Why? The spec ain't God given.

irjustin4y ago

That's how we ended up with decades of Internet Explorer.

monsieurbanana4y ago

> Or they should go and push for spec change

thaumasiotes4y ago

That attitude basically endorses the idea that the spec is God-given. There's nothing so important about getting the spec changed before you start ignoring it.

1 more reply

j / k navigate · click thread line to collapse

0 comments

thaumasiotes4y ago

I feel like repeating an old comment of mine ( https://news.ycombinator.com/item?id=27231194 ) here:

> Conforming to the spec is not a virtue.

> When the spec is malicious, conforming to the spec is malicious behavior.

> I'm comfortable calling it a bug in the spec. `a << 40` needs to have 0 in the lowest 40 bits. It does not need to have random values in bits 8-31.

> This behavior is documented, but that doesn't make things better, it makes them worse.

> But the philosophy that says "if it's documented, then it's OK" doesn't even allow for the concept of a bug in the spec.

Implementing a bad idea doesn't become a good idea just because someone once wrote that it was.

vincnetasOP4y ago

wildrhythms4y ago

Remember, there are autocomplete values to accommodate "current-password"[1]. If your bank has a field representing a password without that attribute, do you think that's following the spec?

[1] https://html.spec.whatwg.org/multipage/form-control-infrastr...

bipson4y ago

I guess there are just too many pages that break autocomplete, e.g. for username/password as a "security feature".

I encountered quite a few myself and was very annoyed. I guess devs took the "usability" side of the question.

EDIT: phrasing

Aeolun4y ago

But it’s not useable at all. A form without autocomplete is perfectly useable. A form with autocomplete where it’s not wanted is an absolute hindrance.

lupire4y ago

A non autocomplete password field is an absolute hindrance.

Cederfjard4y ago

The spec is driven by browser implementations rather than the other way around, is it not?

vincnetasOP4y ago

It should not be so. Or else Spec would just look like "do as chrome does"

benhurmarcel4y ago

> It's not up to Chrome devs

Well apparently it is, because they're doing it.

eru4y ago

Why? The spec ain't God given.

irjustin4y ago

That's how we ended up with decades of Internet Explorer.

monsieurbanana4y ago

> Or they should go and push for spec change

thaumasiotes4y ago

That attitude basically endorses the idea that the spec is God-given. There's nothing so important about getting the spec changed before you start ignoring it.

1 more reply

j / k navigate · click thread line to collapse