On Wed, Nov 24, 2021 at 4:30 PM Rick Byers <[email protected]> wrote:
> > > On Wed, Nov 24, 2021 at 5:21 AM Dominik Röttsches <[email protected]> > wrote: > >> Hi Rick & Frédéric, >> >> On Mon, Nov 22, 2021 at 11:27 PM Rick Byers <[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]> >>> wrote: >>> >>>> Based on +Rick Byers <[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]> 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 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 >>>>> >>>>> [2] 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]. >>>>> 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]. >>> 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]. 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.
