Mason, can you confirm that what is shipping is accurately represented by the specification field, i.e., CSS anchor positioning only? In particular, the HTML anchor="" attribute <https://github.com/whatwg/html/pull/9144> is not included in this I2S?
On Wed, Apr 17, 2024 at 5:01 AM Daniel Herr <danielstephenh...@gmail.com> wrote: > If there is some debate as to whether the design is finished and the > possibility of breaking changes, but also a desire to let developers try it > out in production, why not use an origin trial instead of straight to > shipping? > On Tuesday, April 16, 2024 at 3:05:56 PM UTC-4 Rick Byers wrote: > >> LGTM3 >> >> There's definitely some forward compat risk here, but we know adoption >> for these sorts of features tends to be slow before reaching all engines, >> so I'm confident in our ability to make small breaking changes as needed as >> the spec continues to mature. Seeing how much diligence and review has gone >> into this after 4 years of work, lacking significant known open issues, and >> the benefits for web developers, I think it's consistent with the Chromium >> project value of carefully but urgently pushing the web forward to be >> shipping this now, despite the discomfort in not yet being perfect. >> >> Thank you Fantasai for the feedback and the additional context on the >> webkit standards position. Note that we were explicitly asked (by Maciej I >> think?) to wait >> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit> >> for the standards position to be officially set before claiming something >> other than "no signals" to ensure we're accurately reflecting the position >> of the WebKit project overall (rather than just the support of some select >> engineers). But adding additional context to "no signals" is definitely >> worth doing, thank you for correcting that! >> >> Rick >> >> On Tue, Apr 16, 2024 at 11:34 AM Mike Taylor <mike...@chromium.org> >> wrote: >> >>> LGTM2. And thanks to fantasai for giving a more nuanced read on the lack >>> of an official, published WebKit position. I appreciate the rest of the >>> concerns raised, and agree with Mason that getting the feature in front of >>> developers will be a net positive now, vs delaying until some future >>> post-review time. >>> On 4/16/24 1:58 PM, Alex Russell wrote: >>> >> LGTM1. Excited to see this ship! >>> >>> On Monday, April 15, 2024 at 5:57:40 PM UTC-7 Mason Freed wrote: >>> >>> Thanks for the detailed reply, fantasai! And also thank you very much >>>> for all of the hard work you and Tab have put into this feature to make it >>>> what it is. We very much appreciate it. >>>> >>>> More inline: >>>> >>>> On Sun, Apr 14, 2024 at 10:56 PM fantasai <fantasa...@inkedblade.net> >>>> wrote: >>>> >>>>> Speaking for myself only (not as Apple/WebKit), as an individual >>>>> co-editor of this spec--and from the perspective of having edited many >>>>> layout specs including Grid and Flexbox--I think Anchor Positioning is not >>>>> quite ready to ship (though I think it's pretty close). >>>>> >>>>> The spec just went through a significant overhaul, with major changes >>>>> to syntax, behavior, and interactions among various features. Typically >>>>> after such changes, a spec needs some time to settle, and also another >>>>> round of review to flush out additional issues and refine the new design. >>>>> This is particularly true for layout specs due to their complexity--both >>>>> the inherent complexity of the feature (we want to ensure it's fully >>>>> coherent, even after all the changes), as well as the complexity of how it >>>>> gets used (we want to ensure good usability for the various use cases). >>>>> >>>> >>>> It sounds from your overall comment here that you think the feature is >>>> quite close to “ready” - I’m glad! We agree with that general point. You >>>> say you don’t think it’s “quite ready to ship” here and I appreciate that. >>>> One thing to note is that we’re very committed to addressing any open >>>> issues, either now or after additional issues are discovered. We further >>>> strongly believe that shipping the API allows **all** developers to start >>>> kicking the tires of the feature to find open issues. It’s possible that >>>> issues would be discovered by the CSSWG community via a spec-text-only >>>> review, but that’s much more likely to happen when many developers are >>>> actively trying to make it work for their application using a real >>>> implementation. >>>> >>>> >>>>> AFAICT, we haven't actively solicited these reviews yet. >>>>> >>>> >>>> I do believe we’ve been pretty actively soliciting feedback for the >>>> past two years as the feature was developed, and we’ve received some great >>>> feedback that helped shape the feature, particularly from Apple. Having >>>> said that, we plan to participate in the steps to get to CR over time. >>>> >>>> >>>>> I do think Anchor Positioning is in good shape right now in the sense >>>>> that I think most major concerns with the earlier design are resolved. I >>>>> don't anticipate further major changes to the design and implementation. >>>>> But I do think it's reasonably likely that we'll want to make minor >>>>> breaking changes to syntax and behavior during this settling period, and I >>>>> don't want us to be constrained by a shipping Chrome implementation. >>>>> >>>> >>>> Again, I’m glad you don’t anticipate major changes. And we fully expect >>>> to see minor breaking changes as the feature gets wider evaluation by >>>> developers. It would be natural to assume some reasonable such changes over >>>> the coming months, and Chrome will be open to such changes if they are >>>> compelling, even if they’re breaking. >>>> >>>> >>>>> (For additional context, my response here is prompted by a non-Apple, >>>>> non-WebKit CSSWG member messaging me over the weekend and asking "isn't >>>>> this a bit premature?" So it's not just me/Apple that has some lingering >>>>> concerns. :) >>>>> >>>> >>>> This is a very large feature, so there is bound to be some discomfort >>>> about shipping it, no matter when that shipment happens. I do understand! >>>> But we’ve also received a significant number of developers commenting that >>>> they were very excited to see this feature finally shipping after all these >>>> years. >>>> >>>> >>>>> In terms of scheduling, I think targetting the summer is better: Tab >>>>> is giving a talk on Anchor Positioning at CSS Day, which I think is a >>>>> great >>>>> opportunity to present the full proposal and Chrome's implementation in >>>>> its >>>>> latest form and solicit feedback from advanced CSS authors, and there's a >>>>> CSSWG F2F the following week during which we should be able to resolve any >>>>> issues remaining or raised during wide review. >>>>> >>>> >>>> I think you’re right that these venues will provide great opportunities >>>> to discuss the feature and talk about improvements. Indeed, there is a long >>>> list of css-anchor-position-2 issues >>>> <https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+is%3Aopen+label%3Acss-anchor-position-2> >>>> that will provide discussion topics for many meetings to come, I’m sure. >>>> >>>> >>>>> On the topic of accessibility in particular, it is not addressed at >>>>> all in the draft. Whether there needs to be some special affordance in >>>>> implementations or not, we need to address accessibility requirements and >>>>> best practices and document them clearly, as we did with Grid and Flexbox. >>>>> The point at which this feature ships in Chrome is the point at which >>>>> knowledge of this feature and how to use it will start to spread widely >>>>> and >>>>> rapidly. We need to have a solid accessibility story prepared, documented, >>>>> and evangelized together with the basic how-tos and other DevRel around >>>>> this CSS feature at the same time as it's released. And I suspect the >>>>> story >>>>> here is going to be more complex than Grid and Flexbox. >>>>> >>>> >>>> Are there particular issues you’re aware of? The only one I’m aware of >>>> is csswg-drafts/issues/9356 >>>> <https://github.com/w3c/csswg-drafts/issues/9356> which talks about >>>> display and keyboard ordering. Incidentally, that’s an issue that applies >>>> to Grid and Flexbox already, and we’re actively working on a prototype >>>> implementation and spec proposal for `reading-order-items`. But as >>>> evidenced by that, even Grid/Flexbox aren’t fully “done” yet. Are there >>>> other a11y issues related to anchor pos? We’re not aware of any, but please >>>> do raise the ones you see. >>>> >>>> Your point about having the a11y story documented is a good one. We >>>> will make sure to include that story in blog posts, etc. If you have >>>> particular points to include, please do share. >>>> >>>> Thanks again for the detailed comments! >>>> >>>> Thanks, >>>> Mason >>>> >>>> >>>> >>>> >>>> >>>>> On 4/12/24 08:03, Mason Freed wrote: >>>>> >>>> Contact emails >>>>> >>>>> >>>>> * mas...@chromium.org * Explainer >>>>> >>>>> >>>>> >>>>> * >>>>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md >>>>> <https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md> >>>>> https://xiaochengh.github.io/Explainers/css-anchor-position/explainer.html >>>>> <https://xiaochengh.github.io/Explainers/css-anchor-position/explainer.html> >>>>> https://developer.chrome.com/blog/tether-elements-to-each-other-with-css-anchor-positioning >>>>> <https://developer.chrome.com/blog/tether-elements-to-each-other-with-css-anchor-positioning> >>>>> https://12daysofweb.dev/2023/anchor-positioning >>>>> <https://12daysofweb.dev/2023/anchor-positioning> {Note: the explainers >>>>> above are in chronological order. This feature has been in public >>>>> discussion since 2021, so there is significant history. As such, the >>>>> explainers above explain the user problem anchor positioning intends to >>>>> solve and why it solves them, but in some cases reference an out-of-date >>>>> API shape. In parallel with this I2S we are working on an updated blog >>>>> post >>>>> that uses the latest spec draft syntax.} * Specification >>>>> >>>>> >>>>> * https://drafts.csswg.org/css-anchor-position-1 >>>>> <https://drafts.csswg.org/css-anchor-position-1/> * Summary >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> * CSS anchor positioning allows authors to "tether" an absolutely >>>>> positioned element to one or more other elements on the page (the >>>>> "anchors"), in a declarative way, without the use of Javascript. Anchor >>>>> positioning works performantly when the anchors are scrollable. A common >>>>> use case is to position a popover such as a tooltip next to the element >>>>> that invoked it, or a select menu and its popover options list. Before the >>>>> anchor positioning feature, these use cases required Javascript to >>>>> dynamically position the popover, and keep it anchored as the invoking >>>>> element was scrolled, which is a performance footgun and difficult to get >>>>> right. With anchor positioning, these use cases can be implemented >>>>> performantly and declaratively. The anchor positioning feature consists of >>>>> a large number of CSS properties, which are fully described in the spec >>>>> (https://drafts.csswg.org/css-anchor-position-1 >>>>> <https://drafts.csswg.org/css-anchor-position-1/>). The key >>>>> features/properties include: - `anchor-name`: sets up an element to be an >>>>> anchor for other elements. - `position-anchor`: describes the "default" >>>>> anchor that an anchored element should use for anchor positioning. - The >>>>> `anchor()` function: used to refer to the position of the anchor element, >>>>> in positioning the anchored element. E.g. `top: anchor(bottom)`. In >>>>> addition to implicitly using the `position-anchor` as the anchor, explicit >>>>> anchor references can also be used, e.g. `top: anchor(--button bottom)`. - >>>>> The `anchor-size()` function: used to size the anchored element relative >>>>> to >>>>> the anchor. For example, `width: anchor-size(width)` would make the >>>>> anchored element have the same width as the anchor element. - >>>>> `inset-area`: >>>>> a shorthand for positioning, for common relative positions. E.g. >>>>> `inset-area: top left`. Many inset-area values are available, making >>>>> common >>>>> use cases easy to implement. - The “position-try” properties and @ rules: >>>>> enables “fallback positioning”, which allows multiple potential position >>>>> options to be considered, with the “best” option automatically selected. >>>>> The related properties/rules are: - `position-try` (and associated >>>>> longhands): a list of options for positioning the anchored element. The >>>>> “best” of these options will be selected based on the position of the >>>>> anchor, the layout of the anchored element, and the available space. - >>>>> `@position-try`: one set of positioning properties to be considered as an >>>>> option within a `position-try` list. E.g. `@position-try --left-side >>>>> {right: anchor(left)}`. - `position-try-order`: select the position option >>>>> based on available space, e.g. the one with the `most-block-size`. - the >>>>> “try-tactics”: shorthand values for `position-try` that automatically >>>>> generate common positioning options, such as `flip-block` to automatically >>>>> flip to the other side of the anchor in the block direction. - The >>>>> `anchor-center` value, for the self-alignment properties >>>>> <https://www.w3.org/TR/css-align-3/#self-alignment-properties>. This value >>>>> allows easy centering of an anchored element relative to the anchor >>>>> element. - The `position-visibility` property: specifies that the anchored >>>>> element should be hidden in some circumstances, based on the >>>>> visibility/availability of the anchor element. For example, >>>>> `position-visibility: anchors-visible` will hide the anchored element when >>>>> the anchor is no longer visible. All of the above features are implemented >>>>> and fully-tested >>>>> <https://wpt.fyi/results/css/css-anchor-position?label=experimental&label=master&aligned>. >>>>> Some corner cases are not supported for now: - The `anchors-valid` value >>>>> for the `position-visibility` property is not yet supported. This value >>>>> has >>>>> some open spec questions (csswg-drafts/issues/10201 >>>>> <https://github.com/w3c/csswg-drafts/issues/10201>) that we feel need more >>>>> crisp discussion and definition. The remaining values are supported, and >>>>> the missing value is feature-detectable via `@supports`. We are tracking >>>>> this in crbug.com/333421963 <http://crbug.com/333421963>. - The >>>>> interaction >>>>> of `anchor-name` with content-visibility is not fully implemented, >>>>> particularly when the anchored element is hidden but the anchor is not. >>>>> The >>>>> spec csswg-drafts/issues/10184 >>>>> <https://github.com/w3c/csswg-drafts/issues/10184> has recently been >>>>> resolved, so we will implement the resolved behavior. We are tracking this >>>>> in crbug.com/333443429 <http://crbug.com/333443429>. - The `anchor-scope` >>>>> CSS property is not yet implemented. We are tracking that in >>>>> crbug.com/40281992 <http://crbug.com/40281992>. - The >>>>> “last-successful-position-option” portion of the “determine the position >>>>> fallback styles” algorithm is not yet implemented. We are tracking that in >>>>> crbug.com/331841274 <http://crbug.com/331841274>. - There is a discussion >>>>> about expanding `anchor-size()` to be allowed in more properties >>>>> (csswg-drafts/issues/9827 >>>>> <https://github.com/w3c/csswg-drafts/issues/9827>) and once that gets >>>>> resolved, we will implement the resolved behavior. We are tracking this in >>>>> crbug.com/333421962 <http://crbug.com/333421962>. - There is a discussion >>>>> (csswg-drafts/issues/10182 >>>>> <https://github.com/w3c/csswg-drafts/issues/10182>) about adding a new >>>>> "visibility: strongly-hidden" value (which 'position-visibility' forces >>>>> the >>>>> element to compute to), and which can be used in animations/transitions. >>>>> Once that gets resolved, we will implement the resolved behavior. We are >>>>> tracking this in crbug.com/333477766 <http://crbug.com/333477766>. We >>>>> believe all of these corner cases will not impact early adopters of this >>>>> feature, will be backward-compatible, and we also plan to add support for >>>>> them (once any spec issues are resolved) in the coming weeks (with >>>>> additional I2S or PSA). We further strongly believe that there is great >>>>> value in launching the feature now, to let developers test the overall >>>>> feature, discover new use cases (and bugs), and increase the level of >>>>> feedback we receive to continue to shape the feature going forward. {Due >>>>> to >>>>> chromestatus character limitations, not everything from this email exists >>>>> in the chromestatus entry. This description is more complete.} * Blink >>>>> component >>>>> >>>>> >>>>> * Blink>Layout >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout> >>>>> * Search tags >>>>> >>>>> >>>>> * css <https://chromestatus.com/features#tags:css>, anchor >>>>> <https://chromestatus.com/features#tags:anchor>, position >>>>> <https://chromestatus.com/features#tags:position> * TAG review >>>>> >>>>> >>>>> * https://github.com/w3ctag/design-reviews/issues/848 >>>>> <https://github.com/w3ctag/design-reviews/issues/848> * TAG review >>>>> status >>>>> >>>>> >>>>> * Issues addressed * Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> * Low risk, since this is a new feature. This feature received very >>>>> robust review at the CSSWG over many meetings and many years, and has had >>>>> multiple public working drafts posted. Gecko: Positive >>>>> (https://github.com/mozilla/standards-positions/issues/794 >>>>> <https://github.com/mozilla/standards-positions/issues/794>) WebKit: No >>>>> signal (https://github.com/WebKit/standards-positions/issues/167 >>>>> <https://github.com/WebKit/standards-positions/issues/167>) Web >>>>> developers: >>>>> Strongly positive (https://crbug.com/40059176 >>>>> <https://issues.chromium.org/issues/40059176> has 37 stars) Lots of >>>>> excited >>>>> developer blog posts: - https://kizu.dev/anchor-positioning-experiments/ >>>>> <https://kizu.dev/anchor-positioning-experiments/> - >>>>> https://12daysofweb.dev/2023/anchor-positioning/ >>>>> <https://12daysofweb.dev/2023/anchor-positioning/> - >>>>> https://blog.logrocket.com/use-css-anchor-positioning/ >>>>> <https://blog.logrocket.com/use-css-anchor-positioning/> - >>>>> https://frontendmasters.com/blog/drawing-a-line-to-connect-elements-with-css-anchor-positioning/ >>>>> <https://frontendmasters.com/blog/drawing-a-line-to-connect-elements-with-css-anchor-positioning/> >>>>> - >>>>> https://medium.com/@shriyanspranaybuisness/css-anchor-positioning-ec9f861f4498 >>>>> <https://medium.com/@shriyanspranaybuisness/css-anchor-positioning-ec9f861f4498> >>>>> - …and many more * Ergonomics >>>>> >>>>> >>>>> >>>>> >>>>> * One feature that works quite nicely with anchor positioning is the >>>>> Popover API, which will soon be supported in all browsers. There should >>>>> not >>>>> be any performance issues, since the API was designed carefully with >>>>> performance in mind. * Activation >>>>> >>>>> >>>>> >>>>> >>>>> * There is an anchor positioning polyfill >>>>> <https://github.com/oddbird/css-anchor-positioning> for some features (see >>>>> the Limitations section in the linked document), but it may not be >>>>> up-to-date with the latest syntax changes. >>>>> <https://github.com/oddbird/css-anchor-positioning> There are also a few >>>>> quite common libraries that do "anchor positioning" in userspace, e.g. >>>>> popper.js <https://popper.js.org/docs/v2/> / floating-ui >>>>> <https://floating-ui.com/>. Much of the functionality in those libraries >>>>> could be implemented using the anchor positioning API, and we have engaged >>>>> with the authors of these libraries to incorporate important use cases. * >>>>> Security >>>>> >>>>> >>>>> >>>>> * N/A * WebView application risks >>>>> >>>>> >>>>> >>>>> * Does this intent deprecate or change behavior of existing APIs, such >>>>> that it has potentially high risk for Android WebView-based applications? >>>>> No. * Debuggability >>>>> >>>>> >>>>> * DevTools has basic support for anchor positioning, including making >>>>> sure auto-fallback styles are properly displayed. There is a plan to add >>>>> advanced support (e.g. showing the current anchor element for an anchor >>>>> reference) in the future. * Will this feature be supported on all six >>>>> Blink platforms (Windows, Mac, Linux, ChromeOS, 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> >>>>> ? >>>>> >>>>> >>>>> >>>>> * Yes https://wpt.fyi/results/css/css-anchor-position >>>>> <https://wpt.fyi/results/css/css-anchor-position> * Flag name on >>>>> chrome://flags >>>>> >>>>> >>>>> * CSSAnchorPositioning * Finch feature name >>>>> >>>>> >>>>> * CSSAnchorPositioning * Requires code in //chrome? >>>>> >>>>> >>>>> * False * Tracking bug >>>>> >>>>> >>>>> * https://issues.chromium.org/issues/40059176 >>>>> <https://issues.chromium.org/issues/40059176> * Measurement >>>>> >>>>> >>>>> * https://chromestatus.com/metrics/feature/timeline/popularity/4467 >>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4467> * >>>>> Sample >>>>> links https://anchor-tool.com >>>>> Estimated milestones >>>>> >>>>> >>>>> * Shipping on desktop: 125 DevTrial on desktop: 104 Shipping on >>>>> Android: 125 DevTrial on Android: 104 Shipping on WebView: 125 * >>>>> Anticipated >>>>> spec changes >>>>> >>>>> >>>>> * There are no known spec changes planned that might risk interop. As >>>>> a large feature, there are (and will likely always be) open issues to >>>>> expand the feature, add capabilities, tweak corner cases, etc. After >>>>> landing the initial feature, developers will begin to explore how it >>>>> works, >>>>> and will undoubtedly discover new ways to use it, potentially uncovering >>>>> new feature requests or behavior change requests. This is as-intended, and >>>>> is the reason we’d like to start shipping this feature now, to get that >>>>> process started. This is all equivalent to additions/changes made after >>>>> shipping CSS flex and grid, for example. There is a very small list of >>>>> open >>>>> issues >>>>> <https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+is%3Aopen+label%3Acss-anchor-position-1>, >>>>> most of which are small editorial issues. A few represent changes needed >>>>> to >>>>> the spec, and those are all discussed in the Summary section above. Upon a >>>>> very careful review, none of the open issues appear to present any type of >>>>> backwards compatibility issue, if addressed properly. * Link to entry >>>>> on the Chrome Platform Status >>>>> >>>>> >>>>> * https://chromestatus.com/feature/5124922471874560 >>>>> <https://chromestatus.com/feature/5124922471874560> * Links to >>>>> previous Intent discussions >>>>> >>>>> Intent to prototype: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vsPddM3fGj0/m/5s87Yx95BAAJ >>>>> >>>>> Ready for Trial: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vsPddM3fGj0/m/5s87Yx95BAAJ >>>>> >>>>> >>>>> This intent message was generated by Chrome Platform Status >>>>> <https://chromestatus.com/> {and edited to provide more context}. >>>>> >>>>> -- >>>>> 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. >>>>> >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgGMzSh43dYk486vdsWZG0upxwzqw%3DpiL16pCz-Wh0Acw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgGMzSh43dYk486vdsWZG0upxwzqw%3DpiL16pCz-Wh0Acw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- >>>>> >>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "blink-dev" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/a/chromium.org/d/topic/blink-dev/jGTYNuidPRs/unsubscribe >>>>> . >>>>> >>>> To unsubscribe from this group and all its topics, send an email to >>>>> blink-dev+...@chromium.org. >>>> >>>> >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7fe37aa5-7cf4-40f8-9581-f12ff0817caf%40inkedblade.net >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7fe37aa5-7cf4-40f8-9581-f12ff0817caf%40inkedblade.net?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. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b163fec-0afb-436e-af2c-7a3651ae0951n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b163fec-0afb-436e-af2c-7a3651ae0951n%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+...@chromium.org. >>> >> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6b9dd254-be2c-4154-871f-4b69de6fb78a%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6b9dd254-be2c-4154-871f-4b69de6fb78a%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/e5f7b2c0-69d0-4fdb-abc7-be25dd2569adn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e5f7b2c0-69d0-4fdb-abc7-be25dd2569adn%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/CAM0wra_G%3D9HiouyOcQXp9t99uHXbD%2Bu_j_6efB5HLt0ZHYMkFw%40mail.gmail.com.
