3 ms·
When you put it that way, it kind of undermines the snark towards web developers. Of course things are inconsistent, no one is in charge to say “this is the way
by hyperpape 3y ago
When you put it that way, it kind of undermines the snark towards web developers. Of course things are inconsistent, no one is in charge to say “this is the way the platform does it.”
There are lots of other design sins this doesn’t excuse (low contrast, for instance), but expecting conventions to be as consistent as on a desktop OS feels naive.
- kps 3y agoDoesn't a plain old <input> do it the way the platform does it?
- hyperpape 3y agoI'm a little confused by your question. The discussion is about which button should be ok, and which should be cancel. The browser will not lay that out for you, you have to pick a layout. There are some things where the browser will apply platform conventions, but nothing resembling the consistency you'd expect from (well-designed) native apps.
- kps 3y agoOK, I interpreted this thread more generally about controls, like the checkboxes and radio buttons of the OP.
- mr_toad 3y agoThe HTML input element without any styling applied is usually rendered by the browser using the UI conventions of the operating system. But nobody uses bare input elements these days.
- jraph 3y ago<input> has never affected the button order. It also has no concept of primary / secondary button and for the better or the worst, has by default the styling the browser wants it to have, which might look like the native buttons of the current OS, or the native styling of one of toolkits anyway. System colors are not supported consistently too (although I'm discovering CSS4 a has interesting features [1], neat, but Chrome is lagging behind) [1] https://developer.mozilla.org/en-US/docs/Web/CSS/system-color https://developer.mozilla.org/en-US/docs/Web/CSS/system-colo...