First, I’d just like to correct the record, for the benefit of the folks who have been working for years on this feature (including lots of outreach), and for everyone following this discussion:
- This feature has been in development since May, 2022 <https://chromium-review.googlesource.com/c/chromium/src/+/3647670>, and available for developer trials in Chrome since August, 2022 <https://chromium-review.googlesource.com/c/chromium/src/+/3840458>. We have been continuously shipping the feature experimentally for developers to try out, including all revisions, since then. We’ve gathered a significant amount of developer feedback, much of which is public. Four such bits of feedback are listed in the “Dev trial” section of the chromestatus entry <https://chromestatus.com/feature/5124922471874560> attached to my initial post here. - The blog post we published last week <https://developer.chrome.com/blog/anchor-positioning-api?hl=en> is not the first. We’ve been posting about this feature for a while now, starting with a teaser in May 2022 <https://web.dev/blog/state-of-css-2022#anchoring_an_element_to_another>, and then our first full blog post in March 2023 <https://developer.chrome.com/blog/tether-elements-to-each-other-with-css-anchor-positioning>. Our devrel team has spoken about it at dozens of developer conferences and venues, including CSS Day 2023 <https://youtu.be/dkBeBxs48os?si=rSd2PUMX9Hn0foSM&t=1572>, and has been gathering tons of valuable developer feedback (both publicly and privately) along the way. (The CSSWG blog <https://www.w3.org/blog/CSS/> appears to be just a list of meeting minutes?) - I have been reading your posts very carefully, and spending significant time writing responses. I’d appreciate you assuming my good faith in these responses. Second, thank you for reviewing the spec and raising some great issues. We are looking through those now - let’s discuss each of them on the issues instead of here. From our initial review, it looks like they can be addressed, and we are committed to adjusting this feature as needed to make sure it works for developers. That applies to these issues as well. Thanks, Mason On Sunday, May 12, 2024 at 7:30:34 PM UTC-7 fantasai wrote: > On 5/2/24 16:43, Mason Freed wrote: > > On Wed, May 1, 2024 at 10:04 AM fantasai <fantasa...@inkedblade.net> > wrote: > > > >> 1. The *revised design* should get feedback *from authors*. For example > by: > >> 1. Shipping your revised implementation in test builds so devs can > >> try them out/and/ > >> 2. Posting about the new model in your DevRel channels so they know > >> about it and know to give feedback! > >> 3. Presenting at e.g. CSS Day, and ideally inviting feedback on an > >> implementation the audience can test out and is excited about > >> using soon, /but is still possible to change in response to their > >> feedback./ > >> 4. Posting to the CSSWG blog about the revised spec and inviting > >> feedback from authors (which wasn't done when the spec was > >> republished in March). > >> 5. and any other channels that make sense. > > > > I (still) agree with this point. I believe we’ve done most all of these > things > > over the last two years as we’ve been developing this feature. > > 1. Not done. > 2. Completed 2 days ago. > 3. Not done. > 4. Not done. > 5. Unclear. > > "most of these things" is not true. > > > 1. The feature should get *horizontal review at W3C* and especially > > *address accessibility*. This should include: > > 1. Sending request to TAG, i18n, a11y, etc. in the appropriate > > channels > > <https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review>. > > 2. Documenting any accessibility concerns, intentions, and best > > practices in the spec, and addressing issues that come up. > > 3. Preparing to teach and promote accessible use of this feature > > together with appropriate markup. > > > > I agree. We’ve done some of that, but we’d be happy to have input on > venues > > that we should additionally contact. > > You still haven't done #1, even though I gave you the how-to link. > > > 1. The edited spec should get a *last call review in the CSSWG*. > > 1. By sending a review request to the CSSWG/www-style noting the > > revisions that /have landed/ and are ready to review, and, > > ideally, noting that Chrome intends to ship soon so that reviewers > > can prioritize accordingly. > > > > Ok, we will get this process started. > > What do you think is the "process" for this and why would you wait to > start it > until after you've already shipped? > > > If we need to make such dramatic changes after shipping, then we’ll make > them! > > Great! I just spent my weekend reviewing the spec for you. Let's see how > genuine your offer is. > > > I think it’s a bit unfair to call this “shipping the first draft”. > > I didn't call it one. > > Your responses in this thread are often not to what I've actually been > writing. Please be less sloppy in your reading, it's kindof obnoxious. > > ~fantasai > > -- 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/eda9347d-4728-463c-b1df-05f63c1d7cd6n%40chromium.org.
