A few notes on the history of this feature that relate to some of the questions asked:
When font-variant-position was being designed, the CSS Working Group had an extensive discussion (part 1 <https://lists.w3.org/Archives/Public/www-style/2011Mar/0280.html#:~:text=Superscripts/Subscripts> , part 2 <https://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html#:~:text=CSS3%20Fonts%3A%20superscripts%20and%20subscripts>) about trying to build a model where browsers could synthesize appropriate glyphs if the font didn't have special superscript or subscript glyphs, or only had special superscript/subscript glyphs for a subset of the characters that were superscripted/subscripted, in a way that would get the sizes and positions correct. This proposal was abandoned primarily because of evidence that font metrics for super/subscript position and size (which the proposal depended on) are generally incorrect (e.g., as noted in those minutes, all Adobe fonts at the time shipped with the same metrics for superscript position and size), but also secondarily because of the complexity needed to make it work correctly. (The underlying goal of that proposal was to make this property something that could be used for the default rendering of <sup>/<sub> elements.) However, we ended up (and I don't remember the history of this part) with synthesis in the spec, though with a requirement <https://w3c.github.io/csswg-drafts/css-fonts-4/#font-variant-position-prop:~:text=simulated%20glyphs%20should%20be%20synthesized%20for%20all%20characters> that a single super/subscript is fully synthesized if it can't be fully rendered without synthesis. The advantage of doing synthesis is that the semantics of super/subscript don't get lost, and thus using the feature doesn't require that the author fully control the fonts that are used (which authors perhaps think they can do with downloadable fonts, but which isn't always fully reliable). But synthesis can certainly lead to bad results where neighboring superscripts/subscripts are inconsistent with each other, even though consistency is required within a single super/subscript. This makes me think that the synthesis in the current model probably isn't high enough quality to be a default rendering of <sup>/<sub> elements, although the spec is very vague and thus I'm not sure one can say this authoritatively, and I don't know details of what Gecko implemented. I don't think the specification was designed around the idea that some implementations would follow the spec's rules on synthesis and some implementations would ignore the spec... and thus it does appear to be a problem that whether an implementation does synthesis isn't detectable. (This seems worth discussing in the CSS Working Group if it hasn't been already.) As far as comparison to the "old way" of doing superscript/subscript: there are (as discussed) two different "old ways". The oldest way, and the way still used <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/resources/html.css;l=1156-1164;drc=04a73d3d930f7d80d7eb7c38977798b2a93eccec> for <sup>/<sub> elements, and probably still the most common way, involves vertical-align and font-size: smaller. This produces a result that is typographically incorrect: it's just using body text shrunk to a smaller size, so the superscripts appear too "light" in comparison to the surrounding text. There's also a newer "old way" that involves using the low level font-feature-settings property, whose use for this case is discouraged <https://w3c.github.io/csswg-drafts/css-fonts/#font-feature-settings-prop> in the specification, though it produces the same typographically-correct results as font-variant-position, with all of the same disadvantages (plus a few more), including (if font-variant-position does have synthesis) the disadvantage that it might fail very badly when the font doesn't have the necessary glyphs. -David On Thu, Feb 23, 2023 at 7:48 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > The API owners discussed this at length in yesterday's meeting, without > reaching concrete conclusions. > It seems to me that it'd be good to get some web developer signals here to > get a better understanding of if and how they'd be able to use the feature, > given the interop issues in case of fonts that don't have "super"/"sub" > features. > > I'm not sure what the right answer is (feature detection, synthesis of > some kind, or something else entirely), but it seems to me that getting > "x2" instead of "x<superscript 2>" or "x<subscript2>" would result in real > semantic difference. > > Do we know how developers are using that feature today, given the > difference between Gecko and WebKit? > > On Thu, Feb 23, 2023 at 11:38 AM 'Munira Tursunova' via blink-dev < > blink-dev@chromium.org> wrote: > >> Duplicating the summary of our conversation from the chat here. >> >> We agreed that it might be confusing for some of the web authors if they >> don't check the font for the feature existence beforehand. Also >> implementing synthesis behaviour detection most probably is not possible >> since feature detection/activation happens in shaping stage in Harfbuzz >> where we check different fonts and we don't know which of the fonts will be >> finally used on the page at that point. >> >> Thanks, >> Munira >> >> On Tuesday, February 21, 2023 at 10:58:58 AM UTC+1 Manuel Rego wrote: >> >>> >>> >>> On 21/02/2023 10:06, 'Munira Tursunova' via blink-dev wrote: >>> >> Is there a way to feature detect the synthesis functionality or not? >>> How >>> >> a web author will be able to differentiate between Gecko vs >>> >> Chromium/WebKit behaviors? Would the lack of this feature confuse >>> >> authors? Maybe having some console message information when >>> >> font-variant-position doesn't have any effect due to missing >>> synthesis >>> >> functionality, dunno if that makes sense. >>> >> >>> >> Do we have an use counter for the cases where we're not using >>> >> synthesized glyphs due to lack of functionality? So we can track how >>> >> common that situation is and understand the priority of such feature >>> in >>> >> the future. >>> > >>> > I’m not sure I completely understand your question, but I suppose >>> > identifying cases when the feature is requested and the font does not >>> > have subscript/superscript glyphs might not be possible since we >>> perform >>> > the checking of the font features in the shaping stage in Harfbuzz and >>> > we check different fonts in the shaping process without knowing what >>> > font will be finally used in the page. So, for example, we can trigger >>> > on some system font that does not have sub/superscript glyphs (so this >>> > glyphs should be synthesised) however, in the end, this font won’t be >>> > used in the page but a different web font will be used instead. >>> > >>> > One of the ways to detect whether a font has super/subscript glyphs is >>> > to check whether the font with the feature has loaded (using >>> > document.fonts for instance) and if it did then we won’t synthesise. >>> >>> Mmmm, I'm not sure if I'm understanding properly. >>> In the first email you wrote: >>> > Currently font-variant-position is implemented without synthesis >>> functionality and affects only fonts that have superscript or subscript >>> glyphs (“sups”/”subs” opentype feature); i.e. if the font doesn’t have >>> superscript/subscript then setting font-variant-position to >>> “super”/“sub” won’t synthesize superscript and subscript glyphs, >>> therefore won’t change anything. >>> >>> I understood that if the font has super/subscript glyphs we'll use them, >>> but if the font doesn't have them, we won't synthesize them, so the user >>> will see no difference between a text with `font-variant-position: >>> normal;` vs `font-variant-position: super;`. Am I getting this wrong? >>> >>> If I'm right, my question was how to feature detect if the browser is >>> synthesizing things or not. For example we have this: >>> x<span style="font-variant-position: super;">2</span> >>> >>> In Firefox that will always look as "x²". In Chromium/WebKit I >>> understand that depending on the font it'll look as "x²" or "x2". >>> Is there any way the author can detect what's going on so they can use a >>> different method to do the superscript here? >>> Isn't this going to be confusing to web authors why this is not working >>> in Chromium, while working in Firefox? Are they going to be able to >>> understand this is because the selected font doesn't have the proper >>> glyphs (even when it's the same font in Firefox)? >>> >>> I was wondering about this kind of things, but I'm not sure if I >>> understood properly the original message. >>> >>> Cheers, >>> Rego >>> >>> >> I'm curious how this relates to the "old" way of doing superscript. >>> If >>> > I understand correctly (and I might not!), then x<span >>> > style="font-variant-position: super">2</span> will render as "x²", >>> > somehow finding > the "super" variant of 2 in the font? The old way of >>> > doing this would be with x<span style="vertical-align: super; >>> font-size: >>> > 0.83em">2</span> which will use the normal glyph for 2, but smaller >>> and >>> > differently > positioned? >>> > >>> > Not exactly, vertical-align always does synthesis, so even if the font >>> > has subscript or superscript opentype features vertical-align would >>> > still synthesize the glyphs. The old way of activation >>> > superscript/subscript is through font-feature-settings, i.e. setting >>> it >>> > to “sups” or ”subs”. >>> > >>> > On Wednesday, February 15, 2023 at 6:08:20 PM UTC+1 Daniel Bratell >>> wrote: >>> > >>> > I'm curious how this relates to the "old" way of doing superscript. >>> > >>> > If I understand correctly (and I might not!), then >>> > >>> > x<span style="font-variant-position: super">2</span> >>> > >>> > will render as "x²", somehow finding the "super" variant of 2 in the >>> > font? >>> > >>> > The old way of doing this would be with >>> > >>> > x<span style="vertical-align: super; font-size: 0.83em">2</span> >>> > >>> > which will use the normal glyph for 2, but smaller and differently >>> > positioned? >>> > >>> > /Daniel >>> > >>> > On 2023-02-14 22:26, Manuel Rego Casasnovas wrote: >>> > > Is there a way to feature detect the synthesis functionality or >>> > not? How >>> > > a web author will be able to differentiate between Gecko vs >>> > > Chromium/WebKit behaviors? Would the lack of this feature confuse >>> > > authors? Maybe having some console message information when >>> > > font-variant-position doesn't have any effect due to missing >>> > synthesis >>> > > functionality, dunno if that makes sense. >>> > > >>> > > Do we have an use counter for the cases where we're not using >>> > > synthesized glyphs due to lack of functionality? So we can track how >>> > > common is that situation and understand the priority of such >>> > feature in >>> > > the future. >>> > > >>> > > Cheers, >>> > > Rego >>> > > >>> > > On 14/02/2023 17:08, Philip Jägenstedt wrote: >>> > >> I will recuse myself from this one since I have an interest in the >>> > >> success of Interop 2022 (and 2023), but I think shipping this makes >>> > >> sense. Chrome is the last browser to not support it at all, and >>> > we've >>> > >> seen with other features that the time it becomes available in all >>> > >> browsers can be an inflection point in usage. >>> > >> >>> > >> On Tue, Feb 14, 2023 at 4:56 PM 'Munira Tursunova' via blink-dev >>> > >> <blin...@chromium.org <mailto:blin...@chromium.org>> wrote: >>> > >> >>> > >> >>> > >> Contact emails >>> > >> >>> > >> moo...@google.com <mailto:moo...@google.com>, dr...@google.com >>> > >> <mailto:dr...@google.com> >>> > >> >>> > >> >>> > >> Explainer >>> > >> >>> > >> >>> > https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position >>> <https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position> >>> <https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position >>> <https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position>> >>> >>> > >> >>> > >> >>> > >> Specification >>> > >> >>> > >> >>> > https://drafts.csswg.org/css-fonts-4/#propdef-font-variant-position >>> > <https://drafts.csswg.org/css-fonts-4/#propdef-font-variant-position> >>> > >> >>> > <https://drafts.csswg.org/css-fonts-4/#propdef-font-variant-position >>> > <https://drafts.csswg.org/css-fonts-4/#propdef-font-variant-position>> >>> >>> > >> >>> > >> >>> > >> Summary >>> > >> >>> > >> The font-variant-position CSS property controls the use of >>> > >> alternate, smaller glyphs that are positioned as superscript or >>> > >> subscript. >>> > >> >>> > >> >>> > >> Motivation >>> > >> >>> > >> Font-variant-position property allows users to control usage of >>> > >> typographic superscript and subscript glyphs. >>> > >> >>> > >> Currently font-variant-position is implemented without synthesis >>> > >> functionality and affects only fonts that have superscript or >>> > >> subscript glyphs (“sups”/”subs” opentype feature); i.e. if the font >>> > >> doesn’t have superscript/subscript then setting >>> > >> font-variant-position to “super”/“sub” won’t synthesize superscript >>> > >> and subscript glyphs, therefore won’t change anything. >>> > >> >>> > >> Subscript and superscript glyphs can be also activated using the >>> > >> font-feature-settings property, however using font-variant-position >>> > >> property might be more reasonable since it cascades like a regular >>> > >> CSS property and with the font-feature-settings, if the element >>> > >> inherits the “sups” or “subs” value, users need to >>> > >> activate/deactivate other features that were also defined in >>> > >> font-feature-settings of the parent element. >>> > >> >>> > >> Implementing the synthesis part would be complex and it is >>> > >> questionable if it is worth the cost since synthesized glyphs may >>> > >> look unnatural and synthesis of the font-variant-position property >>> > >> is at risk in the spec >>> > >> >>> > < >>> https://drafts.csswg.org/css-fonts-4/#:~:text=The%20following%20features,variant%2Dposition%20property >>> < >>> https://drafts.csswg.org/css-fonts-4/#:~:text=The%20following%20features,variant%2Dposition%20property>>. >>> Also Safari supports font-variant-position property without synthesis >>> functionality as well. >>> > >> >>> > >> This feature is implemented behind the ‘experimental’ flag and is >>> > >> part of Interop 2022. Shipping this feature will provide a higher >>> > >> stable score for Interop and will decrease the stable vs. >>> > >> experimental score difference.Since Chrome is the last browser to >>> > >> ship this, this will enable broader usage of the feature on the >>> web. >>> > >> >>> > >> >>> > >> Blink component >>> > >> >>> > >> Blink>Fonts >>> > >> >>> > < >>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts >>> < >>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts>> >>> >>> > >> >>> > >> >>> > >> Search tags >>> > >> >>> > >> font-variant-position >>> > >> <https://chromestatus.com/features#tags:font-variant-position >>> > <https://chromestatus.com/features#tags:font-variant-position>>, >>> > >> subscript glyphs >>> > >> <https://chromestatus.com/features#tags:subscript%20glyphs >>> > <https://chromestatus.com/features#tags:subscript%20glyphs>>, >>> > >> superscript glyphs >>> > >> <https://chromestatus.com/features#tags:superscript%20glyphs >>> > <https://chromestatus.com/features#tags:superscript%20glyphs>>, sub >>> > >> <https://chromestatus.com/features#tags:sub >>> > <https://chromestatus.com/features#tags:sub>>, super >>> > >> <https://chromestatus.com/features#tags:super >>> > <https://chromestatus.com/features#tags:super>> >>> > >> >>> > >> >>> > >> TAG review >>> > >> >>> > >> Already shipped in other browsers, see below, no TAG review >>> > required. >>> > >> >>> > >> >>> > >> TAG review status >>> > >> >>> > >> Not applicable, existing standard, shipped in other UAs >>> > >> >>> > >> >>> > >> Risks >>> > >> >>> > >> >>> > >> >>> > >> Interoperability and Compatibility >>> > >> >>> > >> >>> > >> Gecko: Shipped/Shipping >>> > >> >>> > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1024804 >>> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1024804> >>> > >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1024804 >>> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1024804>>Gecko has >>> > >> implemented the feature with the synthesis functionality. >>> > >> >>> > >> >>> > >> WebKit: Shipped/Shipping >>> > >> >>> > >> https://bugs.webkit.org/show_bug.cgi?id=148413 >>> > <https://bugs.webkit.org/show_bug.cgi?id=148413> >>> > >> <https://bugs.webkit.org/show_bug.cgi?id=148413 >>> > <https://bugs.webkit.org/show_bug.cgi?id=148413>>WebKit has >>> > >> implemented the feature without the synthesis functionality. >>> > >> >>> > >> >>> > >> Web developers: No signals >>> > >> >>> > >> >>> > >> Other signals: - >>> > >> >>> > >> >>> > >> >>> > >> Activation >>> > >> >>> > >> None expected; Feature already implemented in other browsers. >>> > >> >>> > >> >>> > >> >>> > >> Debuggability >>> > >> >>> > >> Same as any other CSS property, css_properties.json will be rolled >>> > >> to DevTools during development. >>> > >> >>> > >> >>> > >> >>> > >> Will this feature be supported on all six Blink platforms >>> > >> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>> > >> >>> > >> Yes >>> > >> >>> > >> >>> > >> Is this feature fully tested by web-platform-tests >>> > >> >>> > < >>> https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md >>> < >>> https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>>? >>> >>> > >> >>> > >> Yes, following tests are testing property implementation: >>> > >> >>> > >> https://wpt.fyi/results/css/css-fonts/font-variant-position.html >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position.html> >>> > >> <https://wpt.fyi/results/css/css-fonts/font-variant-position.html >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position.html>> >>> > >> >>> > >> >>> > https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html> >>> > >> >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html>> >>> >>> > >> >>> > >> >>> > https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html> >>> > >> >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html>> >>> >>> > >> >>> > >> >>> > https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html> >>> > >> >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html >>> > <https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html>> >>> >>> > >> >>> > >> >>> > >>> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html >>> < >>> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html> >>> < >>> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html >>> < >>> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html>> >>> >>> > >> >>> > >> >>> > >>> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html >>> < >>> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html> >>> < >>> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html >>> < >>> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html>> >>> >>> > >> >>> > >> >>> > https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html >>> <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html> >>> <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html < >>> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html>> >>> > >> >>> > >> >>> > >> Flag name >>> > >> >>> > >> FontVariantPosition >>> > >> >>> > >> >>> > >> Requires code in //chrome? >>> > >> >>> > >> False >>> > >> >>> > >> >>> > >> Tracking bug >>> > >> >>> > >> https://bugs.chromium.org/p/chromium/issues/detail?id=1212668 >>> > <https://bugs.chromium.org/p/chromium/issues/detail?id=1212668> >>> > >> <https://bugs.chromium.org/p/chromium/issues/detail?id=1212668 >>> > <https://bugs.chromium.org/p/chromium/issues/detail?id=1212668>> >>> > >> >>> > >> >>> > >> Estimated milestones >>> > >> >>> > >> No milestones specified >>> > >> >>> > >> >>> > >> >>> > >> Anticipated spec changes >>> > >> >>> > >> None expected >>> > >> >>> > >> >>> > >> >>> > >> Link to entry on the Chrome Platform Status >>> > >> >>> > >> https://chromestatus.com/feature/5067180721307648 >>> > <https://chromestatus.com/feature/5067180721307648> >>> > >> <https://chromestatus.com/feature/5067180721307648 >>> > <https://chromestatus.com/feature/5067180721307648>> >>> > >> >>> > >> >>> > >> -- >>> > >> 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 blink-dev+...@chromium.org >>> > >> <mailto:blink-dev+...@chromium.org>. >>> > >> To view this discussion on the web visit >>> > >> >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com> >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com?utm_medium=email&utm_source=footer >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%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 blink-dev+...@chromium.org >>> > >> <mailto:blink-dev+...@chromium.org>. >>> > >> To view this discussion on the web visit >>> > >> >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%40mail.gmail.com >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%40mail.gmail.com> >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%40mail.gmail.com?utm_medium=email&utm_source=footer >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%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 blink-dev+...@chromium.org >>> > <mailto:blink-dev+...@chromium.org>. >>> > To view this discussion on the web visit >>> > >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bafec970-883b-45a2-9c93-fd8f8220e741n%40chromium.org >>> < >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bafec970-883b-45a2-9c93-fd8f8220e741n%40chromium.org?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 blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eba52bce-1e12-48af-a867-bea424f7a1a2n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eba52bce-1e12-48af-a867-bea424f7a1a2n%40chromium.org?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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX3ZjLqXXO3XZWpLebMSFAaA15m6gvi0BA%3DfC1xU4KrXw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX3ZjLqXXO3XZWpLebMSFAaA15m6gvi0BA%3DfC1xU4KrXw%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3jWDc2MvPgywqqmWXnp8v5rYLje_b9Z-wv8odoenthbSg%40mail.gmail.com.
