On 4/16/24 09:57, 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.
And I appreciate all the hard work the Chrome Team has put into implementation
and iteration, as this was not an easy feature to fit into CSS's architecture.
Also for being open to revision from your original design.
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.
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.
I think you misread what I wrote, so let me quote it again, with some
highlighting.
What's needed for Anchor Positioning at this time, and I was hoping we
could get, is *wide review on the revised design*:
* soliciting*feedback from authors*, to see if there are additional
things to tweak for usability, additional use cases we can adjust to
accommodate, or other points of difficulty we can resolve.
* soliciting*horizontal review at W3C, particularly wrt accessibility*.
(I think we handled most internationalization concerns in this last
round, and don't anticipate much wrt privacy or security, but
accessibility seems likely to turn up concerns.)
* soliciting*detailed review of the revised spec from CSSWG members*, to
ensure the details are completely, correctly, and reasonably
specified, and the feature is self-coherent and integrates well with
the rest of CSS.
You're responding as if I only made the third point (CSSWG spec review), so
let me number my points (so it's easier to pay attention to all of them), and
break them down with action items that would implement each one:
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.
2. 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.
3. 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.
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 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.
Yes, I acknowledge that; and you've gotten some great feedback from interested
authors over those two years. But you haven't gotten that level of review on
the feature after it was substantially redesigned, so the feature /as you're
planning to ship it/ hasn't had much, if any, review outside the CSSWG.
Again, I’m glad you don’t anticipate major changes.
I might not anticipate major changes, but I'm not the only person whose
feedback you should be soliciting. If it was just about me, I could get a
review done next week...
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.
(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 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.
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.
Improvements that you might not be able to incorporate because you are
planning to ship /before/ those opportunities!
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.
Level 2 enhancements is not the topic of this thread.
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...
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.
Grid and Flexbox were designed with accessibility in mind, with the reordering
functionality introduced /for the purpose of enhancing accessibility/. The
issue was debated multiple times, and their interaction with reading/tab order
was 100% intentional and well-documented in the spec. They shipped working as
intended, and authoring materials were able to incorporate best practices
accordingly. The new `reading-order-items` feature is to support /additional/
use cases. It's not there to "fix up" a broken accessibility model.
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.
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".
~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/cd946af0-820e-4142-8914-db07a1805979%40inkedblade.net.
