On 2024/05/03 5:43, Mason Freed wrote:
I stand by what I said - we will definitely be open to well-justified
changes after we ship! More inline below.
Despite the best intents, the "well-justified" part of this is going to
be a very quickly raising bar.
The same intent was declared [1] about 'text-wrap: balance' not long
ago, and shortly after it shipped we wanted to tweak it, and Chrome
pushed back [2] because of compat concerns.
The people who said then that shipping prior to spec stability was OK
because making compat breaking changes would be fine if needed were
sincere. But those who insisted that breaking compat was not worth it
when we did find things we wanted to change were being reasonable.
'text-wrap: balance' was a very simple feature, with low complexity, and
limited impact in terms of potential for breakage. And yet we ended up
being more constrained than we wished. Anchor positioning is way more
complex of a feature, so the likelihood we'll discover something we want
to change is higher, and the impact of potential breakage is higher too,
since this is a layout feature.
At the point where a number of sites will have started relying on this
highly anticipated feature, making breaking changes will be pushed back
against, with good reasons.
[1] https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1649927288
[2] https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1658998792
On 2024/05/03 5:43, Mason Freed wrote:
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.
For a layout spec, 2 years is not especially long.
Moreover, for about half of those 2 years, few people in the working
group were fully engaged. That's unfortunate, but people's priorities
cannot always shift quickly, even if they're interested. Fortunately,
there's now been significant engagement, but that's still recent. Here's
some imperfect but but illustrative evidence: out of 67 closed issues in
GitHub, 8 were closed prior to May last year [3], while 59 were closed
since then [4]. 47 of them were even closed in the last 3 months [5].
That's absolutely evidence of good progress and engagement, but I
wouldn't call that stability just yet.
[3]
https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-anchor-position-1+is%3Aclosed+closed%3A%3C2023-05-01+
[4]
https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-anchor-position-1+is%3Aclosed+closed%3A%3E2023-05-01+
[5]
https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue+label%3Acss-anchor-position-1+is%3Aclosed+closed%3A%3E2024-02-03
Now, the core concepts of the spec do seem stable at this point. But
changes don't need to be to core concepts to be breaking.
All in all, I support fantasai's position: an updated implementation in
experimental features / beta builds, as well as giving the revised spec
enough time to gather feedback from accessibility reviews and other
horizontal groups like the TAG, from web developers after Tab presents
at CSS-day and from beta builds, and from the WG itself now that the
spec has been updated, seems appropriate.
If the request was to wait for as many years as it took to ship Grid or
Writing Modes, I would understand (and agree with) the desire to ship
faster than that. But here I think we're only talking about a few more
months, and for a feature of this magnitude, that seems worth it to
ensure we don't lock ourselves into a few unfortunate shortcomings that
could permanently limit its potential.
—Florian
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bad5411e-814f-478a-9071-971cce1d3232%40rivoal.net.
