[wp-trac] [WordPress Trac] #48531: Regression: styling of most form elements is uneven or off-center

Thu Dec 5 15:07:26 UTC 2019

#48531: Regression: styling of most form elements is uneven or off-center
-----------------------------+--------------------------------------
 Reporter:  azaozz           |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  5.3.1
Component:  Administration   |     Version:  5.3
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui, css, administration
-----------------------------+--------------------------------------
Changes (by afercia):

 * focuses:  ui, administration => ui, css, administration

Comment:

 Replying to [comment:10 azaozz]:
 > Indeed, perhaps this can be folded under an "umbrella" ticket ...

 Let's make this issue be the umbrella :)

 I can only repeat the last patch on #47477 addressed most of the remaining
 glitches :) Although I recommended to commit that patch, it wasn't
 committed because (I assume) there was no consensus amongst the release
 leads given it was a bit late in the release cycle. I must note that other
 more important and more impactful changes were committed during Beta and
 RC. Not willing to argue but with the benefit of hindsight maybe
 committing that last patch would have been a better decision. I do know
 the development process isn't always linear and sometimes things just
 happen.

 At the same time, the teams involved in these changes (specifically
 @audrasjb and I) were diligent and prepared what was needed for a revert
 before the release, maintaining a detailed list of all the committed
 changes. There was no objection to a revert, if really necessary. The
 revert didn't happen and I'd like to point out it was up to the release
 leads to make such a call.

 == About testing

 > Sorry but it's not evident how this particular code was tested ...

 I'd like to remind everyone that two teams were involved in these changes
 and multiple contributors tested them. Moreover, @audrasjb made a huge
 effort to test the changes with more of 20 amongst the most known
 WordPress plugins to make sure there were no serious breakages.
 [https://make.wordpress.org/core/2019/10/15/report-wp-5-3-admin-css-
 changes-tested-against-top-20-plugins/ He published the testing results on
 the Make blog], including several screenshots.

 That's not to say the testing catched all the issues but I'd like to point
 out that many of the reported glitches are actually pre-existing issues.
 The CSS changed in 5.3 just made them more evident. Also that's not to say
 these changes are perfect :) Perfection is enemy of good though and if
 WordPress doesn't start improving the admin CSS no progress will ever
 happen.

 == Admin CSS state

 Any WordPress contributor that worked on the admin CSS knows very well
 that touching even a small thing can produce unexpected consequences. The
 admin CSS state is far from ideal, to be fair, and that's perfectly
 understandable in a so large project.

 Lack of maintenance, standardization, established patterns, etc. led the
 admin CSS to its current state over the years. A CSS roadmap to sanity is
 waiting since 5 years https://make.wordpress.org/core/2014/12/19/core-css-
 roadmap/. As of today, no substantial progress was made.

 == Iterations

 In my humble opinion, these changes go in the right direction because they
 try to standardize and simplify as much as possible. They remove several
 exceptions. They aren't perfect: they need iterations and adjustments.
 This was discussed by the teams involved and there was consensus for
 iterations in the following releases.

 Given the current state of the admin CSS I'd strongly recommend
 improvements based on iterations also in minor releases. There's so much
 to do that I'm not sure everything can be addressed in a "big" change in a
 major release. I'd like to suggest to consider a different approach, based
 on smaller, more frequent, changes even if they may introduce temporary
 glitches if these glitches can be fixed after a few weeks in a minor
 release. I'd like to see this point discussed more in depth and consider
 to commit #48420 in WordPress 5.3.1 as that was the original plan.

 As I see it, that's the only reasonable approach to start a CSS sanity
 roadmap. I realize such a process would need better tools.

 There are now a number of very good proposal to improve the UI, see for
 example:
 - [https://make.wordpress.org/design/2019/10/31/proposal-a-consistent-
 spacing-system-for-wordpress/ Spacing system (grid)]
 - [https://make.wordpress.org/design/2019/10/11/proposal-a-consistent-
 type-scale-for-wordpress/ Type scale]
 - [https://make.wordpress.org/design/2019/11/26/proposal-a-new-color-
 palette-for-wordpress/ Color palette]
 - [https://make.wordpress.org/design/2019/08/12/project-reviewing-
 wordpress-components/ Reviewing components]

 Some of these proposals relate also to form controls. It's very likely
 that all the inputs and buttons will soon have a minimum default height of
 32 pixels to adapt to a 8 pixels based grid. Honestly I don't see a good
 reason why such a change should wait for a major release. it would be
 great to have this kind of improvements released continuously and
 continuously refined also in minor releases instead of having to wait for
 ''months''  to fix, for example, a 2 pixels misalignment.

 == The Windows system fonts issue

 Regarding the vertical alignments issue on Windows, I'd recommend to give
 #48423 a try. For a quick test, just remove "Segoe UI" from the font stack
 and see how the vertical alignments on Windows "magically" improve. That's
 the only reliable, future-proof, way to make things look better on
 Windows.

 The "system fonts" change [37361] from April 2016 is basically an
 incomplete job. Even the commit message stated:
 > There will definitely be visual bugs, mainly around alignment and
 spacing; these should be documented and reported on the ticket and fixed
 more atomically so that our current and future selves have a better
 understanding of what happened and why.

 For what is worth, on the related ticket I was the only one to point out
 there were vertical alignments problems on Windows, see
 ticket:36753#comment:84

 The necessary adjustments and fixes never happened and today we're still
 in a situation where on Windows alignments are far from ideal.

 == Tools

 Testing CSS changes in the admin is terribly hard. A real challenge. It's
 still, basically, a manual process.

 On one hand, WordPress should do its best to standardize and remove all
 the exceptions introduced here and there to its UI components. I guess
 that before that, WordPress should maybe establish what the UI components
 are :)

 On the other hand, I'd like to see better tools ''available on trunk'' to
 make the testing process easier. A few years ago @helen and @ryelle worked
 on [https://github.com/helen/wp-style-guide the WordPress Admin Pattern
 Library plugin]. Plugins are hard to maintain though and the plugin didn't
 become a widely used tool for testing.

 As a start, I'd like to propose the introduction on trunk of a sort of
 style guide page where the rendering of various UI components can be
 tested. Starting simple, very basic, with form controls. I'm available to
 articulate in a more details proposal, as soon as I find some time.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48531#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform