Remove any CSS class added based on wp_is_mobile() and use pure media queries instead

[afercia]

Splitting this out from https://core.trac.wordpress.org/ticket/65445#comment:21

In WordPress, detection of mobile devices was Introduced 15 years ago in [19368] where it used the global $is_iphone and then changed 14 years ago in [20417] to use wp_is_mobile().

It detects the user-agent header that identifies your browser / device.

It is used across the admin for two purposes:

• Conditionally add some JS scripts.
• In a few cases, conditionally add a mobile CSS class to the body.

I'd like to propose to remove the cases where it adds the mobile CSS class and use styling entirely based on media queries instead.

I'm guessing the historical reason why the mobile CSS class is added this way is because 15 years ago CSS media queries weren't a thing.

Today the styling of some UIs in WordPress is an inextricable mix of styles based on the mobile class and media queries, all mixed together. The admin bar styling is an example, which makes developing and debugging unnecessarily complex.

I'm not even sure the user-agent headers evaluated by wp_is_mobile() are up to date and reliable.

Regardless, at least for the CSS part, WordPress should use pure media queris and nothing else. In the case of the admin bar, this would allow a great simplification of the related CSS.

It is also a developers convenience issue. As noted in https://core.trac.wordpress.org/ticket/65445#comment:21 the CSS class is added when your browser's devtools are open and emulating a responsive view regardless whether the styles based on the media queries kicked in. This may mislead developers who aren't aware that the class is added on the PHP side and it is not toggled 'on the fly' while changing viewport size.

I realize this would require a substantial refactoring of some large parts of the admin CSS. Suggest to keep some time for discussions and feedback before proceeding with a patch.

[joedolson]

I think this would be a good task to take on. User-agent parsing is complex, and even if the specific checks are up to date, it's unlikely that they're totally reliable; and the differences between "is mobile" and "is a small viewport" are not the same issues.

Media queries and feature detection are better tools for identifying both specific mobile support needs and for handling smaller viewports.

[khokansardar]

Agreed this is worth doing. Before any patch, here's an inventory of the current surface so the discussion has concrete boundaries.

Where the class is added

Only three places append a mobile class:

File	Adds	Reach
src/wp-admin/admin-header.php:199-200	body.mobile	whole admin
src/wp-admin/customize.php:137-139	body.mobile	customizer
src/wp-includes/class-wp-admin-bar.php:465-466	#wpadminbar.mobile	admin and front end

One thing to watch in customize.php: the same conditional also does add_filter( 'admin_viewport_meta', '_customizer_mobile_viewport_meta' ). That is a separate viewport-meta concern and would need to stay, so the class removal there is not a clean deletion of the whole block.

The other wp_is_mobile() calls (conditional script enqueues, and the iOS 7 plupload multi_selection workaround in wp-admin/includes/media.php / wp-includes/media.php from #29602) are not CSS classes and I'd suggest keeping them out of this ticket.

CSS consumers

30 selector occurrences in source files, which expand to roughly 285 in build output because colors/_admin.scss regenerates every colour scheme in both LTR and RTL:

• src/wp-includes/css/admin-bar.css — 10
• src/wp-admin/css/colors/_admin.scss — 15
• src/wp-includes/css/media-views.css — 3 (.wp-customizer:not(.mobile))
• src/wp-admin/css/list-tables.css — 1 (.mobile .row-actions)
• src/wp-admin/css/common.css — 1 (body.mobile.modal-open #wpwrap)

JavaScript also reads the class

This is the part that I think most affects scoping, because media queries can't cover it. Two scripts branch on the body class:

• src/js/_enqueues/vendor/plupload/handlers.js:577 — up.features.dragdrop && ! $( document.body ).hasClass( 'mobile' ) gates the drag-drop class, i.e. whether drag-and-drop uploading is offered at all.
• src/js/_enqueues/admin/postbox.js:365 — sets the jQuery UI sortable delay to 200 instead of 0, so postbox dragging doesn't fire on a touch scroll.

Removing the class without haently change upload andpostbox behaviour. They'd need matchMedia() or feature detection rather than CSS.

The class is doing three different jobs

I think this is the main thing to settle before patching. mobile is currently standing in for three unrelatnts a different replacement:

Consumer

Actuadate replacement

#wpadminbar:not(.mobile) …:hover	hover capability	@media (hover: hover)	| #wpadminbar.mobile .quicklia (hover: none)
.mobile .row-actions	no hover (actions must stay visible)	@media (hover: none)
.wp-customizer:not(.mobile)	viewport width	width media query
body.mobile.modal-open #wpirk	needs its own decision		postbox sortable delay	ia( '(pointer: coarse)' )
plupload dragdrop gate	input capability	feature detection / (pointer: coarse)

So it is not a straight swap es. Most of the admin barrules are really hover-capability rules, which is consistent with the note in #65445 comment:21 that the intent waer on real mobile". Using(hover: hover) there would also change behaviour on hybrid and touch-capable laptops,which seems like the main thi.
body.mobile.modal-open #wpwration: fixed scroll-locking isa mobile-browser quirk workaround rather than a viewport or hover concern, so it may need to be applied unconditioting.

Sequencing

#65445 is currently assigned nd touches the same admin barhover/focus rules. Landing a broad admin bar CSS refactor before that one closes would likely conflict, so it in bar portion of this ticketafter #65445, or splitting this into per-area follow-ups (admin bar / list tables / customizer + media views / JS reviewed and tested on itsown.

Happy to work up a patch for whichever slice once there's agreement on the hover-vs-pointer-vs-width map