The problem is that when browsers interpret features as "polite suggestions", what tends to happen is either

A) Developers hack their way around to the result they want anyway, or

B) Users of that browser lose a chunk of the experience.

Either way, everyone loses.

C) Users get a much better experience, like with reader mode.

When I read a site I want to read it in the colors and fonts I want, not what some designer things looks nice.

The web was designed to work this way.

Yeah, this is the root of the conflict.

Web designers think web pages are like magazines, that they get to dictate layout. And most of the development in web browsers and standards lend themselves to that view.

As a user, OTOH, I think of web browser as my User Agent. I accept "polite suggestions" from the website, but ultimately I should have the last word about how it looks. The web was originally designed to work this way.

I'm not sure how to reconcile those views. I'm obviously biased towards the second, and I'd love web developers to be told to bite it. But this, unfortunately, won't work, because there are strong business pressures to the contrary.

> If you want pixel perfect rendering then publish PDF's.

I hope that's sarcasm. PDFs are similarly beholden.

Code should be explicit. There should be no "in between the lines" and the browser should not be guessing what the developer or consumer wants, let alone override what was explicitly declared.

Then having to "politely suggest" max-height: 1000000px is not the right conversation.

What does it mean to "be explicit" about how to render a page, when the UA is, say, a screen-reader for a blind person? Or Siri? Or an even more novel client-type with no directly-applicable CSS rules? They want to do a completely different thing with the page than what you think of as "rendering" it. They might take some of your CSS as hints on how to do that job, but they're not obeying that CSS; they're inferring their own rule set for their own rendering algorithm from CSS.

Perhaps there needs to be a distinction made between "standard web browsers in Standards Mode"—programs that nominally "obey" CSS, and should be chastised for deviating from it—and all other clients, on which you can place no such expectation.

(But even then, it's perfectly within the rules of CSS to apply UA styles at the beginning of the cascade. Usually those are per-browser, but there's no reason there couldn't be per-document ones generated from heuristics. Want to turn them off? Use a CSS Reset.)

> when the UA is, say, a screen-reader for a blind person?

The blind person explicitly turns on blind mode. This is not a difficult problem. Trying to guess if the user is blind is a hard problem.

If the user wants bigger fonts, they can zoom. If font boosting is a feature they would like on, then have them turn it on. If the author makes a crappy page it should be on them. The best thing a browser could do is let them know. And to visitors, provide options. But instead, they automatically enable these secret brilliant features that break random things. These are not solutions. These are the cause of many problems.

Automatic login? Great. Have a button. Have a feature. Don't do it in the background. Just let me tell you what I want. And let the page authors embrace those features and tailor them, and not wind up hacking them to tame their functionality.

I'm not talking about option-switches; I'm talking about purpose-built browsers or browser extensions, where using the browser was the choice you made to get these effects.

If someone wants to develop what's essentially "automatic login, even for sites that would hate you if you did that: the browser", is that wrong?

Hell, this is essentially the same argument as the one behind ad-blocking. If someone wants to build a browser that—by default—alters your page to remove ads (surprise: someone does!), and people want to use that browser (probably: everyone), I don't think you have the moral high ground to tell them to stop.

Sure, you might be able to at least insist that they do some sort of feature-negotiation, where they tell you (maybe with feature-headers? a piece-wise replacement for UA-string heuristics, how lovely) what they're going to do to the page, and your server can then choose to do things like just not serving pages to people who have {font boosting, ad-blockers, etc.}; or redirecting to a page telling them their browser is bad and they should feel bad.

> feature-negotiation

It's words like these. We should not be looking to negotiate with anyone -- not as an author, and not as a consumer.

If someone builds an auto-login browser, or an auto-login feature, then fine. But when Mozilla decides to put this in by default without telling everyone, then not fine.

If font boosting was part of some cross browser mobile web standard then fine. But if you're Google and it's a feature specific for your browser, and you turn it on be default, then not fine.

Of course, it seems like the premise is always that your feature can do no harm. But in practice it's always the opposite. There are always edge cases where something is broken or not right, that leads to these features as a cause.

Login is actually extremely important. To tamper with the behavior of the browser when it comes to logins, and to do it automatically, seems extremely dangerous.

But either way, it's about communication, not negotiation. If the user wants to turn it on, great. If the author turns it on, great. If no one turns it on, but the browser developer just "thinks it's a good idea" for every site ever built, then not great.

The author suggested having a standard browser UI for login. The website would only support it. Am I misunderstanding their intent? I don't see the problem here.

I agree with you with the caveat that the customer themselves can, and should, be changing things to suit their own needs.

But at that point if the customer screws something up, they understand that's on them.

Exactly. My rant was lopsided, but to be more accurate: The browser should facilitate the communication between the author and the reader of the page, and not contaminate it.

All these features are great. They just need to be made explicit and obvious. Inferring what anyone wants let alone overriding what they said they wanted should just be a standard no no.

The best thing a browser could do for the author and the reader would be to explicitly say why something is broken and how to fix it. For example, "X is broken because of extension Y".

Browsers already have great analysis tools but there could be one more FYI breakdown where the browser would just tell you what it knows about any conflicts or issues it sees, and provide options. Something designed for the average user, but that could be extremely useful for authors also by providing a simple list of issues the browser sees about their page -- from an objective, browser POV. Input is always valuable. Acting on it without permission, not so much.

Wrll the polite suggestion becomes the "magic number" we are taught to avoid writing in our programming 101 class.