Speaking from personal experience -- over about six years at this point -- there are many, many web sites on the internets that 1Password's autofill works perfectly well on, and many others where it doesn't work perfectly but fails gracefully (or at least non-destructively). "Here is one site where it makes a mistake that could be catastrophic if you don't catch it" is just not a slam-dunk proof of 1Password being "poorly designed."
It is a visible input field styled not to look like an input field until that radio button is selected, but it is not "hidden" in the HTML sense. It is not a shortcoming of the product's design to not have parsed the CSS and intuited that Substack's designers wanted to cleverly make it not look like an input field.
> It is not a shortcoming of the product's design to not have parsed the CSS and intuited that Substack's designers wanted to cleverly make it not look like an input field.
How is it not a shortcoming? Any human looking at the page can immediately tell that this form field should not be autofilled.
Difficult problem to solve? Sure, doesn't make it any less of a shortcoming.
That exactly correct, which is why the fault is with 1Password's fill mechanism.
A product has a bug when it does not produce output in-line with its stated purpose and process. Nobody would use a refrigerator that suddenly forgets to keep food cold when a carton of milk is placed on the shelf.
So you want 1Password to check CSS of the form before auto filling? The form itself isn’t hidden it’s styled to be flat. That’s the biggest problem of it.
