Thank you Yoav, Rick and Dominik,
Some random remarks/thoughts:
1. First I believe the risk is probably not to have missing characters :
At the end, we actually always do try "-webkit-standard" internally as a
fallback. Instead, the risk is more to have inconsistent fonts selected
(with different style, metrics) for the same text. Say, MyGenericFont
would contain basic CJK or emoji or math characters but then would lack
some more exotic ones which would then be taken by another
MySpecializedFont.
2. That said, I can't explain why how " -webkit-standard" would really
guarantee anything against the inconsistent font selected. Maybe instead
this -webkit-standard value is used to to explicitly select a preferred
font per Unicode scripts (on non-Android platforms) or to resolve CJK
scripts specially (on Android).
3. My guess is more that these usages are really generated by tools (as
Mike mentioned) not introduced on purpose by authors. Indeed, the result
of using -webkit-standard explicitly is really hard to predict.
4. In any case, unshipping support for explicit -webkit-standard may
affect the selected font, but does not change the selection via explicit
-webkit-body or for initial/fallback font (I sent an email to clarify
that, as that was lost in the initial email)
5. On Android, the feature only has effect for CJK scripts and it was
previously mentioned usage might be on purpose. But it seems very low on
that platform per Rick's stats so that no longer seems a concern to me.
6. I suspect all these -webkit-* stuff were introduced by Apple and used
in their product, so it does not seem surprising to have higher usage on
mac.
7. Also, Mike mentioned co-occurence with mso- properties (used by
enterprise's products?) so that may explain the weekday analysis by Rick.
In any case, I shared with Sonia (cc'ed) the results provided by Yoav.
She will try and analyze them in more details and we will come back to
this thread when we are able to explain things more concretely.
Le 25/11/2021 à 10:58, 'Dominik Röttsches' via blink-dev a écrit :
On Wed, Nov 24, 2021 at 4:30 PM Rick Byers <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Nov 24, 2021 at 5:21 AM Dominik Röttsches
<[email protected] <mailto:[email protected]>> wrote:
Hi Rick & Frédéric,
On Mon, Nov 22, 2021 at 11:27 PM Rick Byers
<[email protected] <mailto:[email protected]>> wrote:
I wonder if we have metrics about unrenderable characters?
I.e. how often we fail to render some text because the
glyph isn't present in the selected font? If we did, then
I think it would be pretty easy to do a finch trial for
changes like this and decide go/no-go based on that data.
We used to have a metric to tell us for which Unicode code
block no fallback character was found after the primary fonts,
user preference font and system fallback, but I think we
removed that after it had given us the useful information that
these were mostly math symbols and some emoji. For privacy
reasons we can't have a metric to track missing glyph coverage
for single characters, but the bucketed Unicode block approach
worked. To my knowledge we do not (and did not) have metrics
on coverage/missing glyphs per selected font.
Ok, thanks! Any thoughts on the compat risk of this change? If we
spot check 10 HA results and can explain why the change doesn't
noticeably break anything on those 10, then I'm guessing that
makes this change low enough risk to proceed. But I'm not sure I
trust my judgment on that. WDYT?
Yes, I think that's fair, even thorough I would say, as I trust the
low numbers of occurence. I am not sure what guarantees authors who
used -webkit-standard were expecting. Generic family names, including
system-ui etc. are safer to use. Looking at a few examples from HA
might shed some light on what the idea of the usage was.
Dominik
Dominik
On Mon, Nov 22, 2021 at 4:27 AM Yoav Weiss
<[email protected] <mailto:[email protected]>>
wrote:
Based on +Rick Byers <mailto:[email protected]>'s HA
for webcompat document
<https://docs.google.com/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit#>,
I just ran the following query:
```
SELECT url FROM `httparchive.latest.pages_mobile`
WHERE JSON_EXTRACT(payload,
"$._blinkFeatureFirstUsed.Features['3987']") IS NOT NULL
```
Results are here
<https://docs.google.com/spreadsheets/d/1WZTRBujaaFrtUaRnBOoVYzJkZuColXFN-GgToF6nR5Q/edit?usp=sharing>.
In short, there are 191 pages that touch this
usecounter, out of 7655542 pages in that table. (or
~0.0025% of pages)
This resolves my previous concerns about HA showing an
order of magnitude more usage than our chromestatus
use counter data.
While digging into UKM data could be interesting, it'd
take some time to gather, so it might be sufficient to
take a random sample from the HA list and see what the
impact on those sites would be.
On Mon, Nov 22, 2021 at 9:49 AM Frédéric Wang
<[email protected] <mailto:[email protected]>> wrote:
Le 18/11/2021 à 21:29, Chris Harrelson a écrit :
Would it be possible to get results of top
pages hitting the use counter, so one can
analyze them more carefully ? Do we need to
do any additional change in Chromium to make
that possible ?
chromestatus.com <http://chromestatus.com>
already has this feature, by combining UseCounter
with HTTPArchive. It can take a while for this
data to be populated though, because of latency
in the indexing.
Hi Chris,
Last week Chromestatus was showing wrong results,
basically for any feature it was returning matches
for all HTTPArchive pages. Now it returns no data
at all for -webkit-standard. Not sure if we need
to wait more before indexing happens...
Otherwise, I was thinking of something we did for
scroll position values in non-default writing
modes in the past [1] i.e. use UKM to better
collect and analyze affected origins and maybe
introducing a finch flag to ship this more safely
(the code change to disable that is one line [2]
so that should be easy). But IIRC we will need
help from a Googler for that purpose.
[1]
https://groups.google.com/a/chromium.org/g/blink-dev/c/7X2CKPGeEa0/m/7Rau54VwDQAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/7X2CKPGeEa0/m/7Rau54VwDQAJ>
[2]
https://chromium-review.googlesource.com/c/chromium/src/+/3282157
<https://chromium-review.googlesource.com/c/chromium/src/+/3282157>
--
Frédéric Wang
--
You received this message because you are
subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
[email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f4dd6049-8221-e881-8979-c9029dc5ae01%40igalia.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f4dd6049-8221-e881-8979-c9029dc5ae01%40igalia.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to
the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to
[email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fqrpWok%3DB_s2qBacf%2BHZzcJYHiWY3e6OHODQ%2BWiVDXw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fqrpWok%3DB_s2qBacf%2BHZzcJYHiWY3e6OHODQ%2BWiVDXw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBtoJAiCcMT-DBOkR3VyD_uW_%3D%3DCMGo-CJrO8PjqwXObqA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBtoJAiCcMT-DBOkR3VyD_uW_%3D%3DCMGo-CJrO8PjqwXObqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
Frédéric Wang
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b6350a6b-24b0-4dcb-4231-4f68fbab9a4c%40igalia.com.
