Thí bug is about implementing the style specified in bug 962502 . Still some questions before starting this : - Will this have lots of user impact ? - Is there more technical work behind this to do first ? - Should this design be Firefox specific or for all Gecko products ?

needinfo'ing for those 3 questions.

Here are the two URLs with the updated designs : http://people.mozilla.org/~mmaslaney/widget_v2/firefox-html-forms.html http://people.mozilla.org/~mmaslaney/inputs_v2/index.html

(In reply to Tim Nguyen [:ntim] from comment #0) > Thí bug is about implementing the style specified in bug 962502 . I'm having trouble telling what style is specified in that bug. > Still some questions before starting this : > - Will this have lots of user impact ? Not sure what you mean. Changing the default styles of form controls definitely needs to consider Web-compatibility, though. So not only does the unstyled appearance change affect users, but the combination of the new unstyled behavior with the different styles applied in Web content affects users. > - Is there more technical work behind this to do first ? It's not clear to me what it is you're proposing or what technical work has been done. > - Should this design be Firefox specific or for all Gecko products ? Default form control styles should be consistent between all Gecko products, although they should probably vary by platform (especially for mobile platforms).

One other thought: you're best off starting with one form control, and landing behind a pref that enables the new styles for only nightly and aurora, so that you get a sense of what issues will result and can take that into account when working on the others (also probably landing one at a time).

(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #3) > (In reply to Tim Nguyen [:ntim] from comment #0) > > Thí bug is about implementing the style specified in bug 962502 . > > I'm having trouble telling what style is specified in that bug. > > > Still some questions before starting this : > > - Will this have lots of user impact ? > > Not sure what you mean. Changing the default styles of form controls > definitely needs to consider Web-compatibility, though. So not only does > the unstyled appearance change affect users, but the combination of the new > unstyled behavior with the different styles applied in Web content affects > users. http://people.mozilla.org/~mmaslaney/widget_v2/firefox-html-forms.html http://people.mozilla.org/~mmaslaney/inputs_v2/index.html This is the style wanted for "unstyled" form widgets. It's the new version wanted of the outset/inset border we currently have. > > - Should this design be Firefox specific or for all Gecko products ? > > Default form control styles should be consistent between all Gecko products, > although they should probably vary by platform (especially for mobile > platforms). Got it ! (In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #4) > One other thought: you're best off starting with one form control, and > landing behind a pref that enables the new styles for only nightly and > aurora, so that you get a sense of what issues will result and can take that > into account when working on the others (also probably landing one at a > time). Well, I was more thinking of just updating the forms.css file.

This has no regressions in terms of usability, but it might break some reftests though.

What steps have you taken to test for compatibility with Web content and alignment with the default styles in other browsers?

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #8) > What steps have you taken to test for compatibility with Web content and > alignment with the default styles in other browsers? I made sure that the dimensions were the same as the old ones, I also made sure that the dimensions didn't change across browsers.

It terms of web compatibility, I've tested numerous websites, and I haven't seen a regression.

Pushed to try : https://tbpl.mozilla.org/?tree=Try&rev=34d7b330cfd2

(In reply to Tim Nguyen [:ntim] from comment #10) > It terms of web compatibility, I've tested numerous websites, and I haven't > seen a regression. Presumably you saw some changes in behavior, though? Did those changes align us more or less closely with other browsers?

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #12) > (In reply to Tim Nguyen [:ntim] from comment #10) > > It terms of web compatibility, I've tested numerous websites, and I haven't > > seen a regression. > > Presumably you saw some changes in behavior, though? Did those changes > align us more or less closely with other browsers? The only change in behaviour is that the focusring is drawn on the button itself, rather than the ::-moz-focus-inner pseudo elements, which actually saves some CSS for web developers. Well, those changes rather align us less closely with other browsers. But there isn't really a problem to that, since there is no actual standard, and that all browsers have differences when it comes to styling.

(In reply to Tim Nguyen [:ntim] from comment #13) > The only change in behaviour is that the focusring is drawn on the button > itself, rather than the ::-moz-focus-inner pseudo elements, which actually > saves some CSS for web developers. I'm confused. The patch you posted changes font styles for a number of form controls (to message-box, and away from the system font appropriate for that control), changes the distribution between padding and border on at least text inputs and textareas and maybe other input types, reduces the border width of selects, and makes a number of other changes. Are these somehow not changing behavior? If so, why make them?

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #14) > (In reply to Tim Nguyen [:ntim] from comment #13) > > The only change in behaviour is that the focusring is drawn on the button > > itself, rather than the ::-moz-focus-inner pseudo elements, which actually > > saves some CSS for web developers. > > I'm confused. > > The patch you posted changes font styles for a number of form controls (to > message-box, and away from the system font appropriate for that control), > changes the distribution between padding and border on at least text inputs > and textareas and maybe other input types, reduces the border width of > selects, and makes a number of other changes. Are these somehow not > changing behavior? If so, why make them? Well, this patch rather updates esthetics for unstyled form widgets. Currently, the style we have is a Windows Classic like styling. The patch modernizes that. Those changes were wanted by UX (see URL for what UX wanted as default styling). Also, the patch changes the fonts for the controls, since they didn't match the native one on Windows. They didn't even match the font that IE and Chrome uses.

(In reply to Tim Nguyen [:ntim] from comment #15) > (In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from > comment #14) > Well, this patch rather updates esthetics for unstyled form widgets. > Currently, the style we have is a Windows Classic like styling. The patch > modernizes that. Those changes were wanted by UX (see URL for what UX wanted > as default styling). So could you answer comment 8 for those changes? > Also, the patch changes the fonts for the controls, since they didn't match > the native one on Windows. They didn't even match the font that IE and > Chrome uses. That seems more likely to be a bug in the Windows system font implementation than a bug in the style sheet.

And by the windows system font implementation, I mean https://hg.mozilla.org/mozilla-central/file/70be728521e3/widget/windows/nsLookAndFeel.cpp#l530

And, to be clear, comment 8 is important because Web developers and users care about what Web pages look like. This matters for three reasons: (1) Web developers design pages with knowledge of how browsers behave, and expect those pages not to break. This means that changes outside the variation of what current browsers do may be dangerous, in ways that will get both Web developers upset and users upset (particularly if changes to control sizes break layouts and cause parts of pages to be inaccessible, but also if there are simple visual gaps or misalignments.) (2) Web developers want to do less work to get browsers to behave in similar ways. This means that when there's not a good reason to differ, it's better for browsers to agree. (3) Web developers want to do less work to make their pages look the way they want. This means that unstyled form controls that they think are better-looking are preferable to ones they think are worse-looking.

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #18) > And, to be clear, comment 8 is important because Web developers and users > care about what Web pages look like. This matters for three reasons: > > (1) Web developers design pages with knowledge of how browsers behave, and > expect those pages not to break. This means that changes outside the > variation of what current browsers do may be dangerous, in ways that will > get both Web developers upset and users upset (particularly if changes to > control sizes break layouts and cause parts of pages to be inaccessible, but > also if there are simple visual gaps or misalignments.) This actually improves this, since it gets rid of the ::-moz-focus-inner styling everyone has been complaining about. Instead, it makes the border blue on focus (it doesn't break any site though). > (2) Web developers want to do less work to get browsers to behave in > similar ways. This means that when there's not a good reason to differ, > it's better for browsers to agree. This bug only modifies the borders and the backgrounds, and these things are already defined by most web authors. > (3) Web developers want to do less work to make their pages look the way > they want. This means that unstyled form controls that they think are > better-looking are preferable to ones they think are worse-looking. That's the goal of this bug, making unstyled form controls look better. --------------- Also, about the blue focus border, I'm not sure if that's a good idea since it regresses keyboard accessibility for websites that style the borders of the buttons (:-moz-focusring is overriden too). I think it might be a better idea to add an outline around buttons on focus (kinda like IE or chrome).

Needinfo'ing for last point

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #16) > (In reply to Tim Nguyen [:ntim] from comment #15) > > (In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from > > comment #14) > > Also, the patch changes the fonts for the controls, since they didn't match > > the native one on Windows. They didn't even match the font that IE and > > Chrome uses. > > That seems more likely to be a bug in the Windows system font implementation > than a bug in the style sheet. I'll put that in a follow up bug then. I'll post a new patch tomorrow without the font changes.

(In reply to Tim Nguyen [:ntim] from comment #19) > (In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from > comment #18) > > And, to be clear, comment 8 is important because Web developers and users > > care about what Web pages look like. This matters for three reasons: > > > > (1) Web developers design pages with knowledge of how browsers behave, and > > expect those pages not to break. This means that changes outside the > > variation of what current browsers do may be dangerous, in ways that will > > get both Web developers upset and users upset (particularly if changes to > > control sizes break layouts and cause parts of pages to be inaccessible, but > > also if there are simple visual gaps or misalignments.) > This actually improves this, since it gets rid of the ::-moz-focus-inner > styling everyone has been complaining about. Instead, it makes the border > blue on focus (it doesn't break any site though). What about the cases where you're changing widths of borders and paddings? > > (2) Web developers want to do less work to get browsers to behave in > > similar ways. This means that when there's not a good reason to differ, > > it's better for browsers to agree. > This bug only modifies the borders and the backgrounds, and these things are > already defined by most web authors. What about the cases when they don't? Or cases where they define border but not padding, or padding but not border?

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #22) > (In reply to Tim Nguyen [:ntim] from comment #19) > > (In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from > > comment #18) > > > And, to be clear, comment 8 is important because Web developers and users > > > care about what Web pages look like. This matters for three reasons: > > > > > > (1) Web developers design pages with knowledge of how browsers behave, and > > > expect those pages not to break. This means that changes outside the > > > variation of what current browsers do may be dangerous, in ways that will > > > get both Web developers upset and users upset (particularly if changes to > > > control sizes break layouts and cause parts of pages to be inaccessible, but > > > also if there are simple visual gaps or misalignments.) > > This actually improves this, since it gets rid of the ::-moz-focus-inner > > styling everyone has been complaining about. Instead, it makes the border > > blue on focus (it doesn't break any site though). > > What about the cases where you're changing widths of borders and paddings? I'm changing the padding, to compensate the 1px of the border I removed, so there isn't a problem really. > > > (2) Web developers want to do less work to get browsers to behave in > > > similar ways. This means that when there's not a good reason to differ, > > > it's better for browsers to agree. > > This bug only modifies the borders and the backgrounds, and these things are > > already defined by most web authors. > > What about the cases when they don't? Or cases where they define border but > not padding, or padding but not border? If they don't define anything, they'll just see a better improved look. For the cases where only the border is defined, authors won't see a change. If the only the padding is defined, the border will look improved.

(In reply to Tim Nguyen [:ntim] from comment #23) > (In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #22) > > What about the cases where you're changing widths of borders and paddings? > I'm changing the padding, to compensate the 1px of the border I removed, so > there isn't a problem really. ... > > What about the cases when they don't? Or cases where they define border but > > not padding, or padding but not border? > > If they don't define anything, they'll just see a better improved look. > For the cases where only the border is defined, authors won't see a change. > If the only the padding is defined, the border will look improved. No, if the author defines padding but not border, then your changes make the control 1px smaller on each side (2px smaller in each dimension) by reducing the border. If the author defines border but not padding, then your changes make the control 1px larger on each side (2px larger in each dimension) by increasing the padding. Thus these changes might cause layout problems on Web content as a result of the size changes. But if you've tested that they're within the range of what other browsers do, then that's pretty good evidence that they probably won't.

I really don't think we should worry about these use cases. These are very low use cases. Current web developers either keep the controls as they are (aka native controls) or fully style them (take the example of google or bootstrap).

(In reply to Tim Nguyen [:ntim] from comment #25) > I really don't think we should worry about these use cases. These are very > low use cases. Current web developers either keep the controls as they are > (aka native controls) or fully style them (take the example of google or > bootstrap). In both of those cases these styles don't matter, since they'd be overridden by either the native theme or by the author styles, so by that argument there's also no value to fixing this bug. I suspect that isn't actually true, though. That said, for whatever the value is of fixing the bug, a big part of it is only relevant if it works across browsers. So either you should be willing to do some research about what other browsers do, or you're essentially demanding that I do that research as part of my review, which puts it at the bottom of my review queue (i.e., I'll probably never get to it).

This is what IE does.

What Chrome does (quite similar to what Firefox currently does). Chrome hides some controls completely/partially, to allow web authors style completely what they want with -webkit-appearance: none (checkboxes, radios, selects).

This is a screenshot of what I'm trying to achieve.

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #26) > (In reply to Tim Nguyen [:ntim] from comment #25) > > I really don't think we should worry about these use cases. These are very > > low use cases. Current web developers either keep the controls as they are > > (aka native controls) or fully style them (take the example of google or > > bootstrap). > > In both of those cases these styles don't matter, since they'd be overridden > by either the native theme or by the author styles, so by that argument > there's also no value to fixing this bug. > > I suspect that isn't actually true, though. Yeah, most websites where this styling will be on, are old website that only styles the background (which triggers the -moz-appearance:none styling). > That said, for whatever the value is of fixing the bug, a big part of it is > only relevant if it works across browsers. So either you should be willing > to do some research about what other browsers do, or you're essentially > demanding that I do that research as part of my review, which puts it at the > bottom of my review queue (i.e., I'll probably never get to it). I attached a screenshot of each browser if that helps. The only use-cases this patch will break, are the use cases you're suggesting. I don't see anything else that it could break. If that helps, I can restore the padding, and just change the border style and color (but the border would be 1 pixel thicker).

(In reply to Tim Nguyen [:ntim] from comment #31) > I attached a screenshot of each browser if that helps. The only use-cases > this patch will break, are the use cases you're suggesting. I don't see > anything else that it could break. If that helps, I can restore the padding, > and just change the border style and color (but the border would be 1 pixel > thicker). Whether it helps depends on whether it would be keeping us matching other browsers or keeping us from matching other browsers. I was hoping you'd draw conclusions from examining other browser behavior rather than posting a bunch of large screenshots for me to analyze.

Didn't realize this bug needed such detailed analysis : Here's the analysis for buttons : - Current Firefox : padding: 0px 6px; border: 2px outset ButtonFace; height (including border and padding) : 22px; - Chrome : padding: 1px 6px; border: 2px outset ButtonFace; (like current Firefox) height (including border and padding) : 21px; - IE : padding: 1px 8px; border: 3px solid black; height (including border and padding) : 20.33px All browsers do something different. Removing the ::-moz-focus-inner properties should reduce our height to 20px, and reducing the border-width would then reduce our height to 18px; From there, we could add a 1.5px top and bottom padding to match Chrome's height.

Comment on attachment 8470494 [details] [diff] [review] Patch v1 Review of attachment 8470494 [details] [diff] [review]: ----------------------------------------------------------------- Unassigning myself, I don't think I'll have enough time after this summer.

FYI, there's an ongoing discussion about CSS for form controls on www-style: https://lists.w3.org/Archives/Public/www-style/2015Jan/0490.html

I just took a look at the Goal Firefox screenshot and identified a few remaining issues. See attachment.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.