On Wed, May 1, 2024 at 10:04 AM fantasai <fantasai.li...@inkedblade.net> wrote:
> On 4/16/24 09:57, Mason Freed wrote: > > One thing to note is that we’re very committed to addressing any open > issues, either now or after additional issues are discovered. > > You won't be as open to change after you ship, though, because then (as > you yourself write further down!), you'll be weighing the change against > breaking compat. > I stand by what I said - we will definitely be open to well-justified changes after we ship! More inline below. > > > 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. That’s why the feature is so cool at this point! We think it’s now time to expand the group of folks that can give feedback by shipping the initial version of this feature. > > 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. We have forthcoming blog posts and documentation, and we’d welcome your input on those in case you think we can improve them in any way. > > > 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. > > Requesting review after a feature has shipped in production is not very > effective, since changes are constrained by compat. > > I think it's particularly important for this feature because the more open > the design space, the more we need review; and a new layout model is one of > the most open design spaces in the realm of CSS. > I do agree that shipped features are more constrained than unshipped ones. However, in the beginning stages of shipping a feature such as this, there is still opportunity to improve or tweak the design if needed. > > 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. > > There's "breaking" in the sense of "the underlying behavior got tweaked a > bit, and websites might change, and some sensitive ones might break"... > > And then there's "breaking" in the sense that "we tweaked the syntax > again, and previous code is invalid" or "we changed default behavior, so > most pages will change layout". These are minor changes from an > implementation point of view, but they are not changes that are safe for a > shipping implementation. > If we need to make such dramatic changes after shipping, then we’ll make them! Presumably, though, if we need to decide to do that, then the change must be extremely important and something in the design must have been fatally flawed. Given that we’ve been working with this feature for quite some time (yes with variations in syntax, but fairly consistently in functionality) my hope and assumption is that there aren’t any such fatal flaws in the design. However, if I’m wrong, we’re willing to take the pain of that change. We’d just hope that any such change is approached in the spirit of making developers' lives better, taken as a whole, including the pain of breakage. > > (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. > > Not true: when a feature is solidly specified and reviewed, we typically > don't get this kind of reaction from the WG. Writing Modes, Grid Layout, > Cascade Layers, there are many features in CSS where I don't recall such > hesitancy. > I’m sure it’s true that when a feature has been reviewed for an extensive amount of time in the WG, it doesn’t get pushback from the WG. Though in that case we get the other kind of pushback, from *developers*, about why features take a glacially long time to be added to the web. I guess it’s a matter of striking the right balance between these two. > > 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. > > Of course they are! It's solving a very real problem. They would have been > excited even if you shipped off your first draft. But once that excitement > wears off, you want them to still find the feature delightful to use 5-10 > years later. > > Like Grid. We could have shipped off MSFT's first draft and authors would > have been super excited. But I don't think we would have had the > consistently positive reaction we have had to the much more developed and > polished work that actually ended up shipping. > I think it’s a bit unfair to call this “shipping the first draft”. Again, we’ve been working through the nuances of this feature for more than 2 years, and this is hardly the first (or second or third) draft. I think the core feature is quite stable. > > On the topic of accessibility in particular.... >> > > 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. > > That's the main one I'm aware of, but again, you didn't submit for > accessibility review... > Ok, let’s continue to work toward improved accessibility. We’ll submit officially for a11y review. > > Afaict, Anchor Positioning's accessibility story is simply fallout from > how it happens to work. There's no documentation in the spec (or anywhere > else afaict) of design rationale or intended AT behavior, its consequences, > or how it's expected to be used by authors in a way that is > accessibility-enhancing rather than accessibility-breaking. > This section <https://drafts.csswg.org/css-anchor-position-1/#accessibility> of the anchor-pos spec talks about accessibility, and is similar in spirit and approach to the section that discusses the `order` property <https://drafts.csswg.org/css-display-3/#order-accessibility> for grid/flex. We’d love specific feedback (other than csswg-drafts/issues/9356 <https://github.com/w3c/csswg-drafts/issues/9356> where the discussion continues) on any other things we should address. > > 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. > > "We'll figure it out later" is not a satisfactory answer to "is this > feature designed to support, rather than break, accessible layouts and if > so how". > I don’t recall saying that, and I cannot find where I might have said “we’ll figure it out later” about any part of this feature, accessibility in particular. We’ve thought about accessibility (see issue 9356 <https://github.com/w3c/csswg-drafts/issues/9356> for example), think the feature is ready as-is for an initial launch, and plan to enhance it over time with the features I’ve mentioned. Thanks, Mason ~fantasai > > -- > 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+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cd946af0-820e-4142-8914-db07a1805979%40inkedblade.net > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cd946af0-820e-4142-8914-db07a1805979%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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgQaR3-R3JuJOT%2B_10_vnf1UyhJXo5QfggEX%3D7rDFT6Jg%40mail.gmail.com.
