1239922 - Google Docs' toolbar/findbar high-res icons hidden behind a a webkit-specific media query

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, defect, P1)

Description

[Daniel Holbert [:dholbert]]

(This was discovered in bug 1237101; spinning it off into its own bug.)

Google Docs has CSS to provide high-res icons, but there are two problems that prevent us from receiving them.

 (1) They're behind a webkit-specific media query "-webkit-min-device-pixel-ratio".  (instead of the standard "min-resolution: 2dppx" media query)

 (2) They're accompanied by a style rule which sets the "content" property on a normal element (not a pseudo-element), which is a not-yet-stable CSS feature, and which isn't supported in Firefox

We can get around (1) via webkit prefix support, but that just makes the site break on HiDPI displays, because of (2).

Filing this bug to cover reaching out to them & hopefully addressing both (1) and (2) at once.

Comment 1

[Daniel Holbert [:dholbert]]

The CSS in question lives here:
  https://docs.google.com/static/document/client/css/3258872644-KixCss_ltr.css

Here's a sampling of the most relevant chunks (with stuff in between pruned out):
===========
.docs-icon-img:before {
	content:url(//ssl.gstatic.com/docs/common/jfk_sprite138.png)
}
.docs-icon-img-container {
	height:3489px;
	position:absolute;
	width:42px
}
.docs-icon-save {
	left:0;
	top:-801px
}
@media screen and (-webkit-min-device-pixel-ratio:2) {
	.docs-icon-img {
		content:url(//ssl.gstatic.com/docs/common/jfk_sprite_hdpi76.png)
	}
	.docs-icon-img-container {
		height:3321px;
		position:absolute;
		width:42px
	}
	.docs-icon-save {
		left:-21px;
		top:-2355px
	}
===========

The rules before the @media query are what give us the low-res icons.  The rules inside of the (webkit-specific) @media query are what provide the high-res icons.

And note that the "content" setting outside of the media query is on a pseudo-element -- ".docs-icon-img:before" -- which is legit.  The usage inside of the media query, though, is just directly on ".docs-icon-img", which is non-standard (at this point) and not yet supported in Firefox. That's part (2) in my first comment here.

(Bug 215083 is filed on supporting "content" on non-psuedo-elements, and it's specced in https://drafts.csswg.org/css-content-3/#content-function-header , though note that this spec says "Not Ready For Implementation" at the top.)

Comment 2

[Daniel Holbert [:dholbert]]

[Transferring Mike's "Karl, can you do outreach to Google about this please?" request from bug 1237101 to this bug.]

Comment 3

[Karl Dubost💡 :karlcow]

Contacted today.

Comment 4

[Daniel Holbert [:dholbert]]

For reference, here's a random public Google Doc which can be used to test this bug without needing to be logged into Google:
 https://docs.google.com/document/d/19M59-wHuataEZh8f6joZ_Mvay3IZCbZfaxJKN-H_Bk0/

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)
>  (2) They're accompanied by a style rule which sets the "content" property
> on a normal element (not a pseudo-element), which is a not-yet-stable CSS
> feature, and which isn't supported in Firefox

One particularly-problematic aspect of (2) is that they depend on being able to size the image that's used in this "content" property, with the "width" property.

This won't work (in any browser) on pseudo-elements like :before, because the generated image is anonymous (and hence not directly stylable with "width").  However, it happens to work in WebKit/Blink *for the non-pseudo-element case*.

It looks like the CSSWG would like to put this sizing behavior behind an additional keyword, so that pseudo-elements & non-pseudo-elements are consistent here (and so that the css3 "content" spec ends up consistent with css 2.1), per this thread (particularly the last post I'm linking to):
  Florian: https://lists.w3.org/Archives/Public/www-style/2011Nov/0451.html
  Boris:   https://lists.w3.org/Archives/Public/www-style/2011Nov/0452.html
  Tab:     https://lists.w3.org/Archives/Public/www-style/2011Nov/0462.html

(There might be more recent csswg discussion on this topic, too; not sure, just happened to stumble across that ^ thread.)

Comment 6

[Daniel Holbert [:dholbert]]

...but for the time being, this means the fix on Google's side won't be quite as easy as just modernizing the media query & moving their 'content' property to a ":before" selector.

And on our side, it means that Bug 215083 (implementing "content" on non-pseudo-elements) won't help us here, unless we happen to also implement this sizing quirk.

Comment 7

[Daniel Holbert [:dholbert]]

For the record, I can work around this bug locally in devtools by using "background-image" & "background-size", in place of "content" & "width".

Specifically, using Nightly:
 (1) Set the following prefs, to activate the problematic CSS:
      layout.css.prefixes.device-pixel-ratio-webkit = true
      layout.css.devPixelsPerPx = 2  (or just use a HiDPI screen, e.g. retina mac)

 (2) Visit the google docs URL from comment 4 (or any Google Doc).
       (you should now see the bug, if you look at the icons)

 (3) Open Style Editor (shift+F7) and click the lower stylesheet (the CSS file, rather than the inline style)
 (4) Click in the styles, press Ctrl+F to activate "find", type "hdpi", and press enter. This should take you right to the relevant style rule.
 (5) Delete these style rules...
	.docs-icon-img {
		content:url(//ssl.gstatic.com/docs/common/jfk_sprite_hdpi76.png)
	}
	.docs-icon-img-container {
		height:3321px;
		position:absolute;
		width:42px
	}
...and replace them with the following style rule:
  .docs-icon-img:before {
    content: "";
    background-image: url(//ssl.gstatic.com/docs/common/jfk_sprite_hdpi76.png);
    height:3321px;
    width:42px;
    position:absolute;
    background-size: 42px 3321px;
  }

This fixes the icons for me.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screencast of possible fix from comment 7 (using :before & background & background-size, instead of 'content' & 'width'-which-should-not-work)

Here's a screencast of the workaround described in comment 7.

The idea is to display the image-sprite using a CSS background (which *can* be explicitly sized in CSS) instead of as generated content (which *cannot* be sized in CSS, with some exceptions in WebKit/Blink that the CSSWG may disagree with, as noted in comment 5).

This could probably be expressed even more cleanly using "background-position" instead of absolute positioning; I'm not sure. This is just proof-of-concept minimum viable tweak to get this working.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #7)
> For the record, I can work around this bug locally in devtools by using
> "background-image" & "background-size", in place of "content" & "width".

Google can't use my suggested background-image strategy, or else it'd break Google Docs in Firefox's & IE's "high contrast mode", because CSS background images are suppressed (by the browser) in that mode. Drat.

The Google Docs team is planning on converting these icons to SVG at some point (which should make their min-device-pixel-ratio media-query & their CSS "content" usages unnecessary).  But that's a bigger job, and it's not at the top of their priorities at the moment.

Comment 10

[Karl Dubost💡 :karlcow]

Sent a reminder about this issue on the partner mailing-list.

Comment 11

[Karl Dubost💡 :karlcow]

So there is a discussion going on the partner mailing-list for the best way to do this. 

Basically Firefox and Edge do the same thing here. 
Chrome is following the recently rewritten CSS specification. Quoting Daniel Holbert:

> current spec actually has
> special-case text that calls for Chrome's behavior (only honoring image
> URLs on these elements):
>  # Applies to: [...] Image and url values can apply to all elements.
> https://drafts.csswg.org/css-content/#content-property
> 
> So Chrome is indeed matching the spec here.  (Or rather, the spec
> accurately describes Chrome's behavior. :))
> 
> Firefox and Edge don't implement this behavior yet

We are still discussing on the best course of action, aka Google moving to SVG icons and with which schedule and for Mozilla/Microsoft to implement this spec.

Comment 12

[Daniel Holbert [:dholbert]]

According to bug 1237101 comment 25 - 26, it sounds like this might be fixed now.

Comment 13

[Chris Peterson [:cpeterson]]

Attachment: Find_toolbar_screenshot.jpg

With this code change, some Google Docs toolbar button icons are upside-down or misaligned.

STR:
1. Open a Google Doc or Spreadsheet.
2. Ctrl+F to open the floating Find toolbar.

RESULT:
The Find toolbar's button icons are upside-down or misaligned. See the attached screenshot.

I can reproduce this bug on both Windows 10 and macOS.

Comment 14

[Chris Peterson [:cpeterson]]

(In reply to Chris Peterson [:cpeterson] from comment #13)
> I can reproduce this bug on both Windows 10 and macOS.

I am running Firefox Nightly 61 (2018-03-14).

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Chris Peterson [:cpeterson] from comment #13)
> With this code change, some Google Docs toolbar button icons are upside-down
> or misaligned.

("with this code change" = "with layout.css.prefixes.device-pixel-ratio-webkit = true")

I landed a change to set that pref to true a couple days ago (in bug 1444139), but I've now backed that out in light of cpeterson's finding.

Comment 16

[Chris Peterson [:cpeterson]]

(In reply to Daniel Holbert [:dholbert] from comment #15)
> ("with this code change" = "with
> layout.css.prefixes.device-pixel-ratio-webkit = true")
> 
> I landed a change to set that pref to true a couple days ago (in bug
> 1444139), but I've now backed that out in light of cpeterson's finding.

Yes. Setting the "layout.css.prefixes.device-pixel-ratio-webkit" pref = false makes the button bug go away.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] (recovering from vacation reviews/bugmail) from comment #9)
> The Google Docs team is planning on converting these icons to SVG at some
> point (which should make their min-device-pixel-ratio media-query & their
> CSS "content" usages unnecessary).  But that's a bigger job, and it's not at
> the top of their priorities at the moment.

FWIW, it seems like the Google Docs team *did* convert the icons *on the main google docs toolbar* to SVG - that's presumably why this recently seemed fixed, per comment 12.  I see this in the CSS for the justification icons:
  .docs-material .docs-icon-img::before {
      content: url(//ssl.gstatic.com/docs/common/material_common_sprite47.svg);

...but for their findbar icons, they still seem to be using PNG, which is why that part's still broken (per comment 13):
  .docs-icon-img::before {
      content: url(//ssl.gstatic.com/docs/common/jfk_sprite186.png);

The findbar doesn't have class "docs-material" on any ancestor, which is why it's left with the less-specific PNG rule rather than getting the more-specific SVG rule. BUT, if I add that class to an ancestor, then the former rule applies and the icons Just Work as SVG, and I'm able to flip the pref without breaking the findbar! (on my HiDPI linux laptop)

Comment 18

[Mike Taylor [:miketaylr]]

Karl, can we give a gentle re-ping to the docs folks re: Comment #17? Thanks.

Comment 19

[Karl Dubost💡 :karlcow]

Done today. :)

Comment 20

[Daniel Holbert [:dholbert]]

Per bug 1444139 comment 11, we maybe don't need to bother with this Tech Evang / outreach anymore.

Comment 21

[Daniel Holbert [:dholbert]]

Bumping to WONTFIX, per comment 20 -- we added the missing feature ('content: <image>' on non-pseudo-elements) whose absence was causing problems here.