Re: [blink-dev] Intent to Ship: CSS interpolate-size property and calc-size() function

[David Baron]

The anticipated spec change is now merged
<https://github.com/w3c/csswg-drafts/commit/aa94f650329b2f3096cbeddc6820100b30280baf>,
and the tentative-named WPT tests have been renamed (CL
<https://chromium-review.googlesource.com/c/chromium/src/+/5740910>, WPT PR
<https://github.com/web-platform-tests/wpt/pull/47297>).

-David

On Mon, Jul 22, 2024 at 8:19 PM Domenic Denicola 
wrote:

>
>
> On Tue, Jul 16, 2024 at 12:23 AM David Baron  wrote:
>
>> Contact emailsdba...@chromium.org
>>
>> Explainer
>> https://github.com/w3c/csswg-drafts/blob/main/css-values-5/calc-size-explainer.md
>>
>> Specificationhttps://drafts.csswg.org/css-values-5/#calc-size
>>
>> Summary
>>
>> The CSS interpolate-size property allows a page to opt in to animations
>> and transitions of CSS intrinsic sizing keywords such as auto, min-content,
>> fit-content, etc., in the cases where we can animate those keywords. The
>> CSS calc-size() function is a CSS function similar to calc(), but that also
>> supports operations on exactly one of the values auto, min-content,
>> max-content, fit-content, stretch, or contain. This function is used to
>> represent the values in the middle of the animations allowed by the
>> interpolate-size property.
>>
>>
>> Blink componentBlink>Layout
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/955
>>
>> TAG review statusIssues open.
>>
>> I think there were two substantive issues that came out of the TAG
>> review, one of which is addressed and one of which we disagree with and is
>> not addressed.
>>
>> One issue was that the use of the calc-size() function as the recommended
>> opt-in mechanism for animation of sizing keywords was not ideal.  This is
>> because of behavior in browsers that don't yet support the feature.
>> Changing the way that the endpoints of the animation are specified breaks
>> not only the animation but also the static behavior before or after the
>> animation, unless authors are careful to use additional fallback
>> declarations with supported values.  This was addressed with the somewhat
>> late-breaking addition of a separate opt-in, the interpolate-size property,
>> which was already being discussed for other reasons.  This will be the
>> recommended way to opt in to animation of keywords.  Some (but probably not
>> all) documentation has been updated to reflect this change.  The
>> calc-size() syntax is kept for three reasons: first, that developers have
>> found other useful ways to use it that aren't about animations; second
>> (related to the first) that the extensible web manifesto argues that we
>> should bias towards exposing internal mechanisms unless there's a good
>> reason not to; and third, that it would be difficult architecturally to
>> support CSS animations where the computed value in the middle can't be
>> represented in CSS syntax.
>>
>> The second issue, where we disagree (see the discussion in the TAG
>> review) is that the TAG thinks that this syntax should be part of the
>> calc() function (with complex limitations on when the sizing keywords can
>> be used) rather than a separate calc-size() function that more clearly
>> presents those limitations.
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> No concrete risks. There may be some risk due to the amount of discussion
>> that the feature has had so far, though it has been discussed multiple
>> times in the CSS Working Group, and has had a TAG review. I haven't yet
>> heard back on the standards-positions requests from other vendors, though
>> they've been on file for a few months.
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/1022)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/348)
>>
>> *Web developers*: Positive Animation to/from auto height is a very
>> commonly requested feature by developers. See citations and comments in
>> https://github.com/w3c/csswg-drafts/issues/626,
>> https://issues.chromium.org/40339056, and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=571344.
>>
>> Also see the following excitement about the feature since prototyping has
>> started (also see boosts and responses):
>> https://twitter.com/yisibl/status/1791452140663345300
>> https://twitter.com/Una/status/1791531167558090920
>> https://front-end.social/@chriscoyier/112575832546969221
>> https:/

Re: [blink-dev] Intent to Ship: CSS interpolate-size property and calc-size() function

[David Baron]

I suppose mostly the test naming as "tentative" just needs to be updated,
but I was planning to do it along with landing the one line changes to the
property value definitions (which I mentioned in the "Anticipated spec
changes" section of the intent), since technically it's testing stuff that
isn't formally required without that.

-David

On Tue, Jul 16, 2024 at 2:40 PM Mike Taylor  wrote:

> On 7/16/24 2:27 PM, Chris Harrelson wrote:
>
> LGTM1!
>
> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>> https://wpt.fyi/results/css/css-values/calc-size
>>
> I see that most of these tests are marked as tentative - is that
> intentional, or just needs to be updated?
>

-- 
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/CAG0MU3g%3DSGfk_Pqs-t%2BB9a2ezDWptesWc9xeVMwvzinSPDTh5g%40mail.gmail.com.

[blink-dev] Intent to Ship: CSS interpolate-size property and calc-size() function

[David Baron]

Contact emailsdba...@chromium.org

Explainer
https://github.com/w3c/csswg-drafts/blob/main/css-values-5/calc-size-explainer.md

Specificationhttps://drafts.csswg.org/css-values-5/#calc-size

Summary

The CSS interpolate-size property allows a page to opt in to animations and
transitions of CSS intrinsic sizing keywords such as auto, min-content,
fit-content, etc., in the cases where we can animate those keywords. The
CSS calc-size() function is a CSS function similar to calc(), but that also
supports operations on exactly one of the values auto, min-content,
max-content, fit-content, stretch, or contain. This function is used to
represent the values in the middle of the animations allowed by the
interpolate-size property.


Blink componentBlink>Layout


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/955

TAG review statusIssues open.

I think there were two substantive issues that came out of the TAG
review, one of which is addressed and one of which we disagree with and is
not addressed.

One issue was that the use of the calc-size() function as the recommended
opt-in mechanism for animation of sizing keywords was not ideal.  This is
because of behavior in browsers that don't yet support the feature.
Changing the way that the endpoints of the animation are specified breaks
not only the animation but also the static behavior before or after the
animation, unless authors are careful to use additional fallback
declarations with supported values.  This was addressed with the somewhat
late-breaking addition of a separate opt-in, the interpolate-size property,
which was already being discussed for other reasons.  This will be the
recommended way to opt in to animation of keywords.  Some (but probably not
all) documentation has been updated to reflect this change.  The
calc-size() syntax is kept for three reasons: first, that developers have
found other useful ways to use it that aren't about animations; second
(related to the first) that the extensible web manifesto argues that we
should bias towards exposing internal mechanisms unless there's a good
reason not to; and third, that it would be difficult architecturally to
support CSS animations where the computed value in the middle can't be
represented in CSS syntax.

The second issue, where we disagree (see the discussion in the TAG review)
is that the TAG thinks that this syntax should be part of the calc()
function (with complex limitations on when the sizing keywords can be used)
rather than a separate calc-size() function that more clearly presents
those limitations.

Risks


Interoperability and Compatibility

No concrete risks. There may be some risk due to the amount of discussion
that the feature has had so far, though it has been discussed multiple
times in the CSS Working Group, and has had a TAG review. I haven't yet
heard back on the standards-positions requests from other vendors, though
they've been on file for a few months.


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/1022)

*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/348)

*Web developers*: Positive Animation to/from auto height is a very commonly
requested feature by developers. See citations and comments in
https://github.com/w3c/csswg-drafts/issues/626,
https://issues.chromium.org/40339056, and
https://bugzilla.mozilla.org/show_bug.cgi?id=571344.

Also see the following excitement about the feature since prototyping has
started (also see boosts and responses):
https://twitter.com/yisibl/status/1791452140663345300
https://twitter.com/Una/status/1791531167558090920
https://front-end.social/@chriscoyier/112575832546969221
https://www.youtube.com/watch?v=1VsMKz4Zweg
https://front-end.social/@kizu/112537660977381136
https://blog.kizu.dev/weekly-bookmarks-010/

*Other signals*:

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?

None


Debuggability

Expected to be similar to existing CSS calc() function.


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

?Yes

https://wpt.fyi/results/css/css-values/calc-size


Flag name on chrome://flagsNone

Finch feature namekCSSCalcSizeFunction

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=313072

Estimated milestones
Shipping on desktop 128
DevTrial on desktop 123
Shipping on Android 128
DevTrial on Android 123
Shipping on WebView 128
   Note that the 128 estimate is moderately ambitious, and slipping to 129
may be needed.

Anticipated spec changes

Open questions about a feature may be a source of future web compat or

[blink-dev] Re: RuntimeEnabledFeatures flags that we might be able to remove

[David Baron]

I've updated the spreadsheet of stable feature flags
<https://docs.google.com/spreadsheets/d/1OoQOp19o0dtuWXyyQJdBCAAt_6sq4PpvdRszGb0lNmo/edit>
to include features that shipped to stable in M121 and M122, and to remove
flags that have been removed since my last update.  (I left the previous
version of the sheet in the second tab.)  As before, hopefully this will
prompt some removal of flags that we don't need any longer.

-David

On Fri, Jan 12, 2024 at 11:39 AM David Baron  wrote:

> Since we've recently been more careful about creating feature flags for
> changes that have the possibility of breaking content, we've also been
> creating more feature flags than before.  This means that we're also
> creating a larger number of feature flags that have shipped to stable, been
> shown to be safe, and have served their purpose.  Many of these flags (and
> associated flag-controlled code) can hopefully be removed.
>
> I made a spreadsheet of feature flags that have been shipped in stable
> <https://docs.google.com/spreadsheets/d/1OoQOp19o0dtuWXyyQJdBCAAt_6sq4PpvdRszGb0lNmo/edit>
>  along
> with the stable milestone they shipped in.  The sheet should be publicly
> viewable and editable by any Chromium committer.  The sheet itself has
> notes about how I made it (briefly: mostly with
> third_party/blink/tools/list_stable_features.py).
>
> This sheet is presented as data to help folks remember to remove flags
> that they were intending to remove.  I'm sure there are a bunch of flags
> listed that shouldn't be removed, but also plenty that can be removed
> (either now or soon).
>
> Feel free to add notes to the sheet, update owners as needed, and to write
> CLs to remove flags that we don't need anymore.
>
> -David
>

-- 
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/CAG0MU3hvobd6Q9ehGToK%3DeixkCGbwXkTSheF0kVi53RcCcK%2Big%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

[David Baron]

For what it's worth, some of the historical context around the 2009 changes
is in WebApps TPAC 2009 minutes
 and Anne's
folllowup email to www-style
.

-David

On Tue, Jan 23, 2024 at 2:31 PM 'Dan Clark' via blink-dev <
blink-dev@chromium.org> wrote:

> For the shadow DOM scenario, have we started the spec conversation about
> what behavior we want to end up at? I find the Gecko behavior a bit
> suspicious since it's piercing into potentially-closed shadow trees without
> having a prior reference to them. Maybe caretPositionFromPoint should not
> pierce shadow DOMs and instead support shadows by being on
> DocumentOrShadowRoot. That said, since this is already shipped in Gecko it
> could be hard to reverse course.
>
> If the shadow DOM question hasn't been discussed in standards yet I think
> it's worth kicking that off in parallel with prototyping, so it doesn't end
> up being a barrier to shipping the full implementation later on. A lot of
> the developer feedback has been about how caretRangeFromPoint doesn't
> work with shadows so it seems like this is of central importance for the
> API.
>
> -- Dan
>
> On Thursday, January 18, 2024 at 6:13:48 AM UTC-8 Daniel Bratell wrote:
>
>> Sounds like something that should be reflected in the specs. Again, not
>> directly related to this Intent, but maybe something that should happen in
>> parallel.
>>
>> /Daniel
>> On 2024-01-17 23:38, 'Siye Liu' via blink-dev wrote:
>>
>> Blink has similar concept called "affinity" when placing caret at wrapped
>> line. definition:
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/editing/visible_position.h;l=39-54
>>
>> Thanks,
>> Siye
>>
>> On Wednesday, January 17, 2024 at 6:35:14 AM UTC-8 Daniel Bratell wrote:
>>
>>> This is not directly related to this one function but more to the whole
>>> API. I quickly skimmed the spec and I could not find out how it handles
>>> line breaks which make caret positions ambigious?
>>>
>>> When you press the END key at one line, and the HOME key at the
>>> following line your caret DOM position can be the same, but the visual
>>> caret positions should be different, and so should certain actions like
>>> arrow-down and arrow-up.
>>>
>>> When developing code to handle this in Opera, I solved it by letting
>>> carets know if they were connected forward or backwards (basically a bool)
>>> in the dom element, but maybe this is solved in some other way now?
>>>
>>> /Daniel
>>> On 2024-01-16 18:31, 'Siye Liu' via blink-dev wrote:
>>>
>>> Hi Brian,
>>>
>>> To answer your question,
>>> 1. This prototype only covers the main dom scenario (
>>> https://crbug.com/388976). Shadow dom scenario is tracked in
>>> https://crbug.com/1514810.
>>> 2. The prototype should have similar behavior as caretRangeFromPoint's
>>> implementation in Blink (when the point is over an input element, the
>>> returned CaretPosition should be the nearest ancestor of the input element)
>>> because I expect both APIs share same hit testing logic under the hood.
>>>
>>> Once the prototype is ready for dev trial, we can discuss further about
>>> improving current implementation in both caretRangeFromPoint and
>>> caretPositionFromPoint in Blink.
>>>
>>>
>>> Thanks,
>>> Siye
>>>
>>> On Friday, January 12, 2024 at 5:23:25 PM UTC-8 Brian Birtles wrote:
>>>
>>> Hi,
>>>
>>> Will this also cover the behavioral differences between
>>> caretPositionFromPoint as implemented in Gecko and caretRangeFromPoint as
>>> implemented in Blink such as:
>>>
>>> 1. caretPositionFromPoint in Gecko digs into shadow DOM elements whereas
>>> caretRangeFromPoint in Blink does not.
>>> 2. When the point is over a text input element, caretPositionFromPoint
>>> in Gecko returns the text input element and offset into it but
>>> caretRangeFromPoint in Blink returns the nearest ancestor of the text input
>>> element. (Note that caretRangeFromPoint in Webkit returns the text input
>>> element but always returns a zero offset into it.)
>>>
>>> Thanks,
>>>
>>> Brian
>>>
>>> 2024年1月13日土曜日 3:35:59 UTC+9 si...@microsoft.com:
>>>
>>> Contact emails
>>> si...@microsoft.com, sa...@microsoft.com
>>>
>>> Explainer
>>> None
>>>
>>> Specification
>>> https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint
>>>
>>> Summary
>>>
>>> This new API allows users to get current caret position from a given
>>> screen point. The API returns a CaretPosition object which represents the
>>> caret position indicating current text insertion point including the
>>> containing DOM node, caret's character offset, and the client rectangle of
>>> caret range.
>>>
>>>
>>> Blink component
>>> Blink>CSS
>>> 
>>>
>>> Motivation
>>>
>>> document.caretPositionFromPoint API is in CSSOM View and is already
>>> implemented by Gecko. WebKit/Blink has 

[blink-dev] RuntimeEnabledFeatures flags that we might be able to remove

[David Baron]

Since we've recently been more careful about creating feature flags for
changes that have the possibility of breaking content, we've also been
creating more feature flags than before.  This means that we're also
creating a larger number of feature flags that have shipped to stable, been
shown to be safe, and have served their purpose.  Many of these flags (and
associated flag-controlled code) can hopefully be removed.

I made a spreadsheet of feature flags that have been shipped in stable

along
with the stable milestone they shipped in.  The sheet should be publicly
viewable and editable by any Chromium committer.  The sheet itself has
notes about how I made it (briefly: mostly with
third_party/blink/tools/list_stable_features.py).

This sheet is presented as data to help folks remember to remove flags that
they were intending to remove.  I'm sure there are a bunch of flags listed
that shouldn't be removed, but also plenty that can be removed (either now
or soon).

Feel free to add notes to the sheet, update owners as needed, and to write
CLs to remove flags that we don't need anymore.

-David

-- 
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/CAG0MU3ia7vybzAWOADVmqdLhN%2BT7VJsfNcmaLcXAutwZRSpVTQ%40mail.gmail.com.

[blink-dev] Re: Intent to implement and ship: Allow elements with CSS display:contents to be focusable

[David Baron]

On Wed, Jan 10, 2024 at 11:14 AM Yoav Weiss  wrote:

>
>
> On Tuesday, January 9, 2024 at 5:39:19 PM UTC+1 David Baron wrote:
>
> Contact emailsdba...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/w3c/csswg-drafts/issues/2632#
> issuecomment-438851770
>
>
> Is this actually defined in the spec? Should the spec be more explicit
> about it?
>

There was certainly some disagreement about that, but whatwg/html#9425
<https://github.com/whatwg/html/pull/9425> makes it much more explicit.


> Interoperability and Compatibility
>
> This is proposing to change a currently interoperable behavior. This has
> some risk that other engines won't match the change and we'll end up with
> less interoperability. However, I think there is probably enough support
> from other engines at this point that we should take the lead and hope that
> other engines will soon follow.
>
>
> What about compat? Would existing users of `display: contents` have their
> keyboard flows disrupted by this change?
>
>

That is a possible concern, although (a) I think the amount of existing
content affected by the change is likely small, although I haven't
attempted to measure and (b) I think such a change seems more likely to be
an improvement than a regression.

 -David

>

-- 
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/CAG0MU3gZiQxJ3P4rBgadJT-HLR51ru_RhcXAj-oFSBy2UWL5Vg%40mail.gmail.com.

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

[David Baron]

I think such a console error sounds like a reasonable idea, but I'd need to
dig in to see how hard it would be to do.

-David

On Tue, Jan 9, 2024 at 2:59 PM Aaron Leventhal 
wrote:

> WDYT about a console error in developer tools when there is no focus rule
> applied?
>
> On Tue, Jan 9, 2024 at 2:56 PM David Baron  wrote:
>
>> I think in theory it might make sense for focus outlines to use something
>> like an aggregation of child bounds.  (The specifications even allow focus
>> outlines on regular elements to expand to contain the bounds of children.)
>>
>> However, in the case of display:contents, it would be hard to implement
>> in all browser engines (need to figure out responsibility for painting and
>> invalidating it), hard to specify (need to describe how it interacts with
>> visual effects... and also implement that interaction), hard to explain to
>> developers (doesn't fit with the normal model around how outlines are drawn
>> and how display:contents works), and probably hard to get standards
>> consensus around (for those same reasons).
>>
>> So my current preference is to allow display:contents elements to be
>> focusable and to make visual indication of the outline the developer's
>> problem (but perhaps still somewhat discourage having to go down that path).
>>
>> -David
>>
>> On Tue, Jan 9, 2024 at 12:49 PM Aaron Leventhal 
>> wrote:
>>
>>> Would an option for focus outlines to be to use the same idea we're
>>> discussing for AT bounding boxes? Namely, to use an aggregation of child
>>> outlines?
>>>
>>> On Tue, Jan 9, 2024 at 12:33 PM David Baron  wrote:
>>>
>>>> I think accumulating the rectangles of children seems like a good
>>>> option if we need to report a bounding box.  It sounds like that's
>>>> something else where I need to test, and possibly change, our current
>>>> behavior for elements with display:contents.
>>>>
>>>> Regarding focus outlines:  these elements won't draw focus outlines.
>>>> This is definitely a tradeoff.  As I wrote in
>>>> https://github.com/WebKit/standards-positions/issues/164#issuecomment-1708822339
>>>> :
>>>>
>>>> So I think my preference for outline is that we say that if a developer
>>>> is going to depend on focusability of something with display: contents,
>>>> they need to add appropriate styles to draw the focus outline (for example,
>>>> by drawing it on an appropriate descendant or descendants).
>>>>
>>>> I admit that developers aren't going to get that right all the time.
>>>> But the same is true of the current situation. That is, I think developers
>>>> will sometimes not do what we want if we say either of:
>>>>
>>>>
>>>>- developers shouldn't use display: contents if they need an
>>>>element to be focusable, or
>>>>- developers should add appropriate focus styles if they use
>>>>display: contents on something that is focusable.
>>>>
>>>> (Note that needing an element to be focusable is often a need for users
>>>> using keyboard navigation or similar, that may not apply to users using a
>>>> mouse. So developers may well miss it.)
>>>>
>>>> Then the question is which problem is worse: is it worse to have an
>>>> element that the user needs to get to but that can't be focused at all, or
>>>> worse to have it be focusable but without a good indication that it's
>>>> focused. The latter at least gives a keyboard user a chance to figure out
>>>> what's going on, whereas with the former they're out of luck. So my
>>>> inclination is that having the element be focusable but without an
>>>> indication of focus is less bad than having it not be focusable at all when
>>>> it should be. I admit that this is just my instinct and I haven't attempted
>>>> to confirm this. And there's also the confounding factor that the two
>>>> problems might occur at different rates.
>>>>
>>>> -David
>>>>
>>>> On Tue, Jan 9, 2024 at 11:46 AM Aaron Leventhal <
>>>> alevent...@chromium.org> wrote:
>>>>
>>>>> And (duh to myself), we need to compute a bounding box for our own
>>>>> focus outline.
>>>>>
>>>>> Apologies if this is answered elsewhere.
>>>>>
>>>>> On Tue, Jan 9, 2024 at 11:45 AM Aaron Leventhal <
>>>>> aleven

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

[David Baron]

I think in theory it might make sense for focus outlines to use something
like an aggregation of child bounds.  (The specifications even allow focus
outlines on regular elements to expand to contain the bounds of children.)

However, in the case of display:contents, it would be hard to implement in
all browser engines (need to figure out responsibility for painting and
invalidating it), hard to specify (need to describe how it interacts with
visual effects... and also implement that interaction), hard to explain to
developers (doesn't fit with the normal model around how outlines are drawn
and how display:contents works), and probably hard to get standards
consensus around (for those same reasons).

So my current preference is to allow display:contents elements to be
focusable and to make visual indication of the outline the developer's
problem (but perhaps still somewhat discourage having to go down that path).

-David

On Tue, Jan 9, 2024 at 12:49 PM Aaron Leventhal 
wrote:

> Would an option for focus outlines to be to use the same idea we're
> discussing for AT bounding boxes? Namely, to use an aggregation of child
> outlines?
>
> On Tue, Jan 9, 2024 at 12:33 PM David Baron  wrote:
>
>> I think accumulating the rectangles of children seems like a good option
>> if we need to report a bounding box.  It sounds like that's something else
>> where I need to test, and possibly change, our current behavior for
>> elements with display:contents.
>>
>> Regarding focus outlines:  these elements won't draw focus outlines.
>> This is definitely a tradeoff.  As I wrote in
>> https://github.com/WebKit/standards-positions/issues/164#issuecomment-1708822339
>> :
>>
>> So I think my preference for outline is that we say that if a developer
>> is going to depend on focusability of something with display: contents,
>> they need to add appropriate styles to draw the focus outline (for example,
>> by drawing it on an appropriate descendant or descendants).
>>
>> I admit that developers aren't going to get that right all the time. But
>> the same is true of the current situation. That is, I think developers will
>> sometimes not do what we want if we say either of:
>>
>>
>>- developers shouldn't use display: contents if they need an element
>>to be focusable, or
>>- developers should add appropriate focus styles if they use display:
>>contents on something that is focusable.
>>
>> (Note that needing an element to be focusable is often a need for users
>> using keyboard navigation or similar, that may not apply to users using a
>> mouse. So developers may well miss it.)
>>
>> Then the question is which problem is worse: is it worse to have an
>> element that the user needs to get to but that can't be focused at all, or
>> worse to have it be focusable but without a good indication that it's
>> focused. The latter at least gives a keyboard user a chance to figure out
>> what's going on, whereas with the former they're out of luck. So my
>> inclination is that having the element be focusable but without an
>> indication of focus is less bad than having it not be focusable at all when
>> it should be. I admit that this is just my instinct and I haven't attempted
>> to confirm this. And there's also the confounding factor that the two
>> problems might occur at different rates.
>>
>> -David
>>
>> On Tue, Jan 9, 2024 at 11:46 AM Aaron Leventhal 
>> wrote:
>>
>>> And (duh to myself), we need to compute a bounding box for our own focus
>>> outline.
>>>
>>> Apologies if this is answered elsewhere.
>>>
>>> On Tue, Jan 9, 2024 at 11:45 AM Aaron Leventhal 
>>> wrote:
>>>
>>>> Interesting. How will the bounding box be reported via a11y APIs?
>>>>
>>>> Examples of where this is used:
>>>> 1. ATs for low vision users that draw a box around the focus and/or
>>>> move the focus onscreen (especially for a magnifier that is only showing
>>>> part of the actual screen's contents in a virtual viewport).
>>>> 2. Voice Input: used to show numbers next to the item when several
>>>> things have the same name, e.g. a bunch of links labelled "click here".
>>>> 3. Single switch ATs: for highlighting an item that the user can select
>>>>
>>>> One answer might be to accumulate the rectangles of all children and to
>>>> use that. Not sure what the algorithm would do for out-of-flow children.
>>>>
>>>> Aaron
>>>>
>>>> On Tue, Jan 9, 2024 at 11:39 AM David Baron 
>>>&g

Re: [blink-dev] Intent to implement and ship: Allow elements with CSS display:contents to be focusable

[David Baron]

I think accumulating the rectangles of children seems like a good option if
we need to report a bounding box.  It sounds like that's something else
where I need to test, and possibly change, our current behavior for
elements with display:contents.

Regarding focus outlines:  these elements won't draw focus outlines.  This
is definitely a tradeoff.  As I wrote in
https://github.com/WebKit/standards-positions/issues/164#issuecomment-1708822339
:

So I think my preference for outline is that we say that if a developer is
going to depend on focusability of something with display: contents, they
need to add appropriate styles to draw the focus outline (for example, by
drawing it on an appropriate descendant or descendants).

I admit that developers aren't going to get that right all the time. But
the same is true of the current situation. That is, I think developers will
sometimes not do what we want if we say either of:


   - developers shouldn't use display: contents if they need an element to
   be focusable, or
   - developers should add appropriate focus styles if they use display:
   contents on something that is focusable.

(Note that needing an element to be focusable is often a need for users
using keyboard navigation or similar, that may not apply to users using a
mouse. So developers may well miss it.)

Then the question is which problem is worse: is it worse to have an element
that the user needs to get to but that can't be focused at all, or worse to
have it be focusable but without a good indication that it's focused. The
latter at least gives a keyboard user a chance to figure out what's going
on, whereas with the former they're out of luck. So my inclination is that
having the element be focusable but without an indication of focus is less
bad than having it not be focusable at all when it should be. I admit that
this is just my instinct and I haven't attempted to confirm this. And
there's also the confounding factor that the two problems might occur at
different rates.

-David

On Tue, Jan 9, 2024 at 11:46 AM Aaron Leventhal 
wrote:

> And (duh to myself), we need to compute a bounding box for our own focus
> outline.
>
> Apologies if this is answered elsewhere.
>
> On Tue, Jan 9, 2024 at 11:45 AM Aaron Leventhal 
> wrote:
>
>> Interesting. How will the bounding box be reported via a11y APIs?
>>
>> Examples of where this is used:
>> 1. ATs for low vision users that draw a box around the focus and/or move
>> the focus onscreen (especially for a magnifier that is only showing part of
>> the actual screen's contents in a virtual viewport).
>> 2. Voice Input: used to show numbers next to the item when several things
>> have the same name, e.g. a bunch of links labelled "click here".
>> 3. Single switch ATs: for highlighting an item that the user can select
>>
>> One answer might be to accumulate the rectangles of all children and to
>> use that. Not sure what the algorithm would do for out-of-flow children.
>>
>> Aaron
>>
>> On Tue, Jan 9, 2024 at 11:39 AM David Baron  wrote:
>>
>>> Contact emailsdba...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specification
>>> https://github.com/w3c/csswg-drafts/issues/2632#issuecomment-438851770
>>>
>>> Summary
>>>
>>> This change means that elements that have CSS display:contents can be
>>> focusable. In other words, if they would have been focusable without
>>> display:contents, display:contents will no longer change that. Before this
>>> change, elements with display:contents could never be focused. Developers
>>> making elements with display:contents that can be focused need to ensure
>>> that such elements have appropriate styles to make the focus visually
>>> apparent, since they will not have a default focus outline.
>>>
>>>
>>> Blink componentBlink>HTML>Focus
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3EFocus>
>>>
>>> Motivation
>>>
>>> Elements with display:contents are exposed to assistive technology as
>>> having their normal roles (as though they had their default display). The
>>> contract for the meaning of accessibility roles includes support for
>>> certain role-specific keyboard interactions which often include
>>> focusability. So it's important that the exposure to AT match the
>>> focusability. The CSS Working Group has concluded that both AT exposure and
>>> focusability should be as-normal. Prior to this change, AT exposure was
>>> interoperably as specified, but such elements were interoperably not
>>> focusable.
>>>
>>>
>>> Search tagsCSS <htt

[blink-dev] Intent to Prototype: CSS calc-size() function

[David Baron]

Contact emailsdba...@chromium.org

ExplainerNone yet.  (But the starting point for writing one, particularly a
section on alternatives considered, would probably be the discussion in the
github issue starting from Tab's November 6 comment
 to
the present.)

SpecificationNone yet, but the CSS Working Group has resolved (yesterday)
to add this feature to CSS Values & Units Module Level 5
.

Summary

The CSS calc-size() function is a CSS function similar to calc(), but that
also supports operations on exactly one of the values auto, min-content,
max-content, fit-content, stretch, or contain. This allows transitions and
animations to and from these values (or mathematical functions of these
values), as long as the calc-size() function is used on at least one of the
endpoints of the transition or animation to opt in.

Blink componentBlink>Layout


Motivation

Animation to or from auto heights is a very commonly requested feature by
web developers because it is important for animation of elements (such as
the contents of disclosure widgets) opening/closing between a content-based
height (or width) and a small (often zero) height (or width). This feature
fits the desire to do such animations into the way that CSS transitions and
animations work. More generally, this allows animating any height that can
currently be specified in CSS to zero or to/from a small fixed value.

Initial public proposal
https://github.com/w3c/csswg-drafts/issues/626#issuecomment-1800254442

TAG reviewNone yet.

TAG review statusPending

Risks


Interoperability and Compatibility

The CSS Working Group has so far had only a brief synchronous discussion of
the proposal, so I didn't get a good sense of what other engine developers
think of the proposal (and they also haven't yet had a lot of time to
examine it). However, given the history of developer demand for the
feature, I think a (hopefully) compelling prototype in Chromium may help
make a strong case for implementation in other engines.

*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Positive. Animation to/from auto height is a very
commonly requested feature by developers. See citations, stars/votes, and
comments in https://github.com/w3c/csswg-drafts/issues/626,
https://bugs.chromium.org/p/chromium/issues/detail?id=313072, and
https://bugzilla.mozilla.org/show_bug.cgi?id=571344.

*Other signals*:

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?

None


Debuggability

Expected to be similar to existing CSS calc() function.


Is this feature fully tested by web-platform-tests

?No, but I intend to write WPT tests as I work on it, with the caveat that
I might not be quite as thorough as I would be if I weren't expecting
substantial future changes to the proposal based on what we learn from
trying to prototype it.

Flag name on chrome://flagsNone

Finch feature namekCSSCalcSizeFunction

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=313072

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5196713071738880

This intent message was generated by Chrome Platform Status
 and edited by hand.

-- 
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/CAG0MU3hBtXebfpW3JSoO-RF43aCCsNK-vZ0uvqoVaBoJbfAT6g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Accordion pattern using name attribute on elements

[David Baron]

On Wed, Oct 4, 2023 at 6:30 AM Yoav Weiss  wrote:

>
> On Fri, Sep 29, 2023 at 11:04 PM David Baron  wrote:
>
>> Summary
>>
>> This feature adds the ability to construct exclusive accordions using a
>> sequence of HTML  elements. It adds a name attribute to the
>>  element. When this attribute is used, multiple  elements
>> that have the same name form a group. At most one element in the group can
>> be open at once.
>>
>
> This looks great!!
> The only tiny concern I have is the question of compatibility: Is it
> possible that existing  elements share a name attribute?
> Would it be possible for you to run a quick HTTPArchive scan and see this
> is not a semi-common pattern?
>

I ran a query with HTTPArchive
<https://docs.google.com/document/d/1cpjWFoXBiuFYI4zb9I7wHs7uYZ0ntbOgLwH-mgqXdEM/edit>,
in particular, the following query:

SELECT page, url
FROM `httparchive.all.requests`
WHERE
date = '2023-09-01' AND
client = 'desktop' AND
is_main_document AND
REGEXP_CONTAINS(response_body, r
'(?is)]*?[[:space:]]name(=|[[:space:]]|>)')

This produced 6 urls (for 7 pages; two of them redirect to the same URL).
I did view-source: of the 6 urls and based on visual inspection found that
0 of the 6 would be broken by shipping this feature.  In more detail:

   - 3 of the 6 (associated with the same site, mailchimp.com) had multiple
elements, on each of which the name and id attributes had the
   same value, and these values were properly unique (at least among the
elements)
   - 1 had a single  with name="somename"
   - 1 had a single  with name="body" and id="body"; there were
   other elements with this name/id, but none of the others were 
   - 1 had a single  element with a unique-ish looking name

So none of the pages found used the name attribute in a way that would be
affected by shipping this feature (i.e., multiple  elements with
the same name).

Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> There may still be some small changes as part of the process of getting
>> https://github.com/whatwg/html/pull/9400 finished, but I hope to
>> implement those before shipping (at least those that happen soon).
>>
>
> The PR is merged. Is there more work happening on it?
>

No.  I sent the intent before the PR was merged.  I do still need to follow
up on a piece of the discussion there and file an issue on html-aam, though.

-David

-- 
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/CAG0MU3gisj8cH4aCDOeDDMJpmUyOKxoU5FnfrT-FeFDN-_c%3DJQ%40mail.gmail.com.

[blink-dev] Intent to Ship: CSS :dir() pseudo-class selector

[David Baron]

Contact emailsdba...@chromium.org, dizha...@chromium.org,
myid.s...@igalia.com

ExplainerNone

Specificationhttps://www.w3.org/TR/selectors-4/#the-dir-pseudo

Summary

The :dir() CSS pseudo-class selector matches elements based on
directionality, which is determined based on the HTML dir attribute.
:dir(ltr) matches left-to-right text directionality, and :dir(rtl) matches
elements with right-to-left text directionality. It is not equivalent to
[dir] attribute selectors because it matches against directions inherited
from an ancestor with the dir attribute, and because it matches against the
direction computed from use of dir=auto (which determines directionality
from the first character in the text with strong directionality).


Blink componentBlink>CSS


TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This is largely an additive feature. However, as part of the process of
preparing to ship the feature, we worked on more clearly specifying exactly
how directionality in HTML works, and particularly how it interacts with
shadow DOM. This work is occurring in
https://github.com/whatwg/html/issues/3699
https://github.com/whatwg/html/pull/9554 and
https://github.com/whatwg/html/pull/9796 . Since these changes to HTML
directionality also affect the dirname attribute (which is a form
submission feature), they have been implemented behind the same flag as the
pseudo-class. However, they are likely to be low risk because the
recommended way of using the dirname attribute is to use dir=auto on the
same element as the dirname attribute, and that usage pattern should not be
affected. This feature is part of Interop2023's focus area on CSS
Pseudo-classes: https://wpt.fyi/interop-2023


*Gecko*: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=562169)

*WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=64861)
Supported as of Safari 16.4 according to https://caniuse.com/css-dir-pseudo

*Web developers*: No signals

*Other signals*: CSSWG consensus to ship documented in
https://www.w3.org/TR/css-2017/#experimental (CSSWG includes reps from all
major browser vendors)

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

Same as other pseudo-classes


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?No

Is this feature fully tested by web-platform-tests

?Yes

WPT test plan (somewhat out of date, since recent CLs have added many
tests) at https://github.com/web-platform-tests/wpt/issues/25569 Existing
tests have names starting with "dir" in
https://wpt.fyi/results/css/selectors and
https://wpt.fyi/results/html/dom/elements/global-attributes PR for testing
shadow DOM interaction at
https://github.com/web-platform-tests/wpt/pull/29820 which will add
additional tests


Flag name on chrome://flags

Finch feature namekCSSPseudoDir

Requires code in //chrome?False

Tracking bughttps://code.google.com/p/chromium/issues/detail?id=576815

Availability expectationAvailable in all major browsers once we ship.

Sample links
https://jsfiddle.net/fxc9a8uc/1

Estimated milestones
Shipping on desktop 120
Shipping on Android 120
Shipping on WebView 120

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
PR at https://github.com/whatwg/html/pull/9796 to better define the
feature, particularly how it relates to Shadow DOM

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5751531651465216

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/p0Wc66rbVOc/m/khHJ0dSsAwAJ

This intent message was generated by Chrome Platform Status
.

-- 
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/CAG0MU3iYpepa-W7j8eX65F6KtMf1ioC82-ujZw%2BjnGNGpxEKzQ%40mail.gmail.com.

[blink-dev] Intent to Ship: Accordion pattern using name attribute on elements

[David Baron]

Contact emailsdba...@chromium.org

Explainerhttps://open-ui.org/components/accordion.explainer

Specificationhttps://github.com/whatwg/html/pull/9400

Summary

This feature adds the ability to construct exclusive accordions using a
sequence of HTML  elements. It adds a name attribute to the
 element. When this attribute is used, multiple  elements
that have the same name form a group. At most one element in the group can
be open at once.


Blink componentBlink>HTML>Details


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/866 (design
review)

TAG review statusIssues addressed

Risks


Interoperability and Compatibility



*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/831
)

*WebKit*: In development (
https://github.com/WebKit/standards-positions/issues/209) positive
standards position and code landed (although a little behind the most
recent changes to the proposal)

*Web developers*: No signals Got significant feedback from web developers
in https://github.com/openui/open-ui/issues/812 . See examples of use on
live sites in
https://open-ui.org/components/accordion.explainer/#developer-demand-for-exclusive-accordion

*Other signals*:

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



Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flags

Finch feature namekAccordionPattern

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1444057

Availability expectationHoping to get cross-browser adoption relatively
quickly (<12 months) given that it's a small feature that seems to be
widely supported.

Adoption expectationWider adoption may depend on also doing other changes,
like improved stylability of  and  elements.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dependencies to function?
no

Estimated milestones
Shipping on desktop 120
Shipping on Android 120
Shipping on WebView 120

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
There may still be some small changes as part of the process of getting
https://github.com/whatwg/html/pull/9400 finished, but I hope to implement
those before shipping (at least those that happen soon).

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6710427028815872

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/Q1OX6ZA_aaE/m/ALwkAOfHAwAJ

This intent message was generated by Chrome Platform Status
.

-- 
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/CAG0MU3jdK2cMo8_hwyEFQLWUQ9W0xa60uy4wJnAMpZMdBApDfQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS font-variant-position property

[David Baron]

ose selected from the web), so are Mac fonts.
>
> In any event, I did a quick check:
> Mac: Helvetica, Times, and Courier New on Mac, and as far as I can tell,
> neither has a specific superscript or subscript OpenType or AAT font
> feature.
> Windows: Out of Arial, Courier, Times, Verdana only Verdana has subscript
> glyphs (no superscript), the others do not have such a feature.
>
> Bottom line:
> I am with Rick on shipping this and considering a lack of glyph support up
> a site bug.
> Depending on feedback from API owners, if needed, we can measure an
> approximation of selection of the feature vs. support in the font.
>
> As is, this measurement may read too high (see above: initial shaping with
> fallback font), but potentially we can filter that measurement and only
> report selection of the feature vs. support in a successfully loaded
> web-font. Development of such a measurement takes from 2 days to 9 days,
> depending on complexity (very basic, no distinction of
> font-feature-settings and font-variant-position, no distinction of system
> fonts to complex: distinguish font-feature-settings from
> font-variant-position, distinguish system fonts, web fonts).
>
>
> Dominik
>
>
>
> On Wed, May 24, 2023 at 5:41 PM Rick Byers  wrote:
>
>> It's a shame to me to be holding back interop on the case of fonts having
>> the superscript or subscript glyphs out of fear for the case where they
>> don't. Perhaps we can treat the case of font-variant-position being used
>> with fonts that lack the glyphs as a site bug that we can work to address
>> independently? Personally, as long as Safari and Chrome behave the same
>> here, I'm skeptical that the lack of synthesis would turn into a
>> non-trivial problem in practice.
>>
>> If we were to ship without synthesis, would it be practical to have a
>> UseCounter which measures how often we see font-variant-position used with
>> a font that lacks the glyphs? This would tell us how important the bug is.
>> If it remains really rare, then IMHO we've probably already wasted more
>> energy worrying about it than it's worth. If it becomes more common over
>> time then I think we have a variety of options, chiefly implementing
>> synthesis, but also raising awareness with devtools features, UKM-based
>> site-specific outreach, and possibly even interventions of some form (like
>> using a fallback font?).
>>
>> Rick
>>
>> On Fri, Feb 24, 2023 at 9:22 AM David Baron  wrote:
>>
>>> On Fri, Feb 24, 2023 at 5:49 AM Yoav Weiss 
>>> wrote:
>>>
>>>> On Fri, Feb 24, 2023 at 11:27 AM Manuel Rego Casasnovas <
>>>> r...@igalia.com> wrote:
>>>>
>>>>> There's a CSSWG issue about this topic in particular:
>>>>> https://github.com/w3c/csswg-drafts/issues/7441
>>>>
>>>>
>>>> Is this something that can be put on the agenda for the CSSWG to
>>>> discuss?
>>>>
>>>
>>> I added this to the group's (long) agenda backlog.
>>>
>>> (Also, a few other relevant CSSWG issues I found were
>>> w3c/csswg-drafts#1888 <https://github.com/w3c/csswg-drafts/issues/1888>
>>> , w3c/csswg-drafts#2796
>>> <https://github.com/w3c/csswg-drafts/issues/2796>, w3c/csswg-drafts#5225
>>> <https://github.com/w3c/csswg-drafts/issues/5225>, w3c/csswg-drafts#5518
>>> <https://github.com/w3c/csswg-drafts/issues/5518>, and also some
>>> minutes from July 2020
>>> <https://lists.w3.org/Archives/Public/www-style/2020Aug/0006.html#:~:text=vertical%2Dalign%3A%20super%20and%20font%20metrics>
>>> and from September 2020
>>> <https://lists.w3.org/Archives/Public/www-style/2020Sep/0023.html#:~:text=should%20we%20add%20the%20super%20and%20subscript>
>>> .)
>>>
>>> One other point that I missed yesterday is that one of the key reasons
>>> that these new properties can't be used for the default rendering of
>>> / elements is that they don't support *nested*
>>> subscript/superscript.  One of the goals of the 2011 discussion I cited
>>> above was to solve that issue in a reasonable way.  All of the current ways
>>> of doing typographically correct super/subscripts only support a single
>>> level of super/subscript, and not nesting.  This works for the majority of
>>> use cases, but not all.
>>>
>>> -David
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group a

Re: [blink-dev] Intent to Ship: CSS font-variant-position property

[David Baron]

I think it's worth noting that lack of interop here could take two
different forms: (1) different behavior in different browser engines and
(2) different behavior on different machines in the same browser engine,
because of different system font availability.  Some of the more advanced
font capabilities in CSS mostly make sense only with downloadable fonts and
not with system fonts -- and the choices we make regarding synthesis may
affect whether this falls into that bucket of capabilities.

So if it makes sense to add use counters to understand the compatibility
implications here, I think it may be worth adding what we would need to
understand the breakdown of how many sites are using this in a way that (a)
is interoperable across browsers/machines versus (b) is broken in some
browsers and working on others versus (c) is broken on some machines and
working on other machines, even using the same browser.  I suspect this
would mean something like measuring how often we see font-variant-position
used with a system font versus a downloadable font.  (This might also need
to be recorded along with the data on whether the font has or lacks the
superscript/subscript glyphs, because the intersection of the two might be
interesting.)

-David

On Wed, May 24, 2023 at 10:41 AM Rick Byers  wrote:

> It's a shame to me to be holding back interop on the case of fonts having
> the superscript or subscript glyphs out of fear for the case where they
> don't. Perhaps we can treat the case of font-variant-position being used
> with fonts that lack the glyphs as a site bug that we can work to address
> independently? Personally, as long as Safari and Chrome behave the same
> here, I'm skeptical that the lack of synthesis would turn into a
> non-trivial problem in practice.
>
> If we were to ship without synthesis, would it be practical to have a
> UseCounter which measures how often we see font-variant-position used with
> a font that lacks the glyphs? This would tell us how important the bug is.
> If it remains really rare, then IMHO we've probably already wasted more
> energy worrying about it than it's worth. If it becomes more common over
> time then I think we have a variety of options, chiefly implementing
> synthesis, but also raising awareness with devtools features, UKM-based
> site-specific outreach, and possibly even interventions of some form (like
> using a fallback font?).
>
> Rick
>
> On Fri, Feb 24, 2023 at 9:22 AM David Baron  wrote:
>
>> On Fri, Feb 24, 2023 at 5:49 AM Yoav Weiss 
>> wrote:
>>
>>> On Fri, Feb 24, 2023 at 11:27 AM Manuel Rego Casasnovas 
>>> wrote:
>>>
>>>> There's a CSSWG issue about this topic in particular:
>>>> https://github.com/w3c/csswg-drafts/issues/7441
>>>
>>>
>>> Is this something that can be put on the agenda for the CSSWG to discuss?
>>>
>>
>> I added this to the group's (long) agenda backlog.
>>
>> (Also, a few other relevant CSSWG issues I found were
>> w3c/csswg-drafts#1888 <https://github.com/w3c/csswg-drafts/issues/1888>,
>> w3c/csswg-drafts#2796 <https://github.com/w3c/csswg-drafts/issues/2796>,
>> w3c/csswg-drafts#5225 <https://github.com/w3c/csswg-drafts/issues/5225>,
>> w3c/csswg-drafts#5518 <https://github.com/w3c/csswg-drafts/issues/5518>,
>> and also some minutes from July 2020
>> <https://lists.w3.org/Archives/Public/www-style/2020Aug/0006.html#:~:text=vertical%2Dalign%3A%20super%20and%20font%20metrics>
>> and from September 2020
>> <https://lists.w3.org/Archives/Public/www-style/2020Sep/0023.html#:~:text=should%20we%20add%20the%20super%20and%20subscript>
>> .)
>>
>> One other point that I missed yesterday is that one of the key reasons
>> that these new properties can't be used for the default rendering of
>> / elements is that they don't support *nested*
>> subscript/superscript.  One of the goals of the 2011 discussion I cited
>> above was to solve that issue in a reasonable way.  All of the current ways
>> of doing typographically correct super/subscripts only support a single
>> level of super/subscript, and not nesting.  This works for the majority of
>> use cases, but not all.
>>
>> -David
>>
>> --
>> 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/CAG0MU3ht%3DrZwCtQoUWJXR4avCaY2TvAa9NMiYAfMsdan94wzVw%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org

[blink-dev] Intent to Prototype: Accordion pattern using elements

[David Baron]

Contact emailsdba...@chromium.org

Explainerhttps://open-ui.org/components/accordion.explainer
https://github.com/dbaron/details-styling

SpecificationNone

Summary

This is a set of work to enable better platform support for the accordion
widget  pattern, and
particularly exclusive accordions, using HTML  elements. As we see
it right now (and this could certainly change) this work appears to consist
of three parts: the ability to link multiple details elements
 together to
semantically be an accordion (possibly with some small changes to keyboard
behavior and/or accessibility roles, but likely not), improvements to
stylability of details elements 
(particularly around styling/replacing the marker and having more
flexibility to lay out the parts), and improvements to the accessibility of
/ (particularly related to problems of interactive
content inside of the ).


This work is still at an early stage, and the process of working out what
specific features will be part of this work is still happening. That
process will involve discussions (some already started) in appropriate
venues, starting with the Open UI community group .


Blink componentBlink>HTML>Details


Motivation

Developers regularly use accordions on the Web. Today, that generally means
that they build their own widget rather than using a widget provided by the
platform, either because there is no widget for exclusive accordions, or
because the existing widget for disclosures and non-exclusive accordions
does not meet their needs (most likely due to stylability). This proposal
is suggesting that we add features for exclusive accordions and better
stylability of  to the platform. Doing so would help users because
it would make (or at least would enable making) the user experience more
consistent, and generally better, in a number of areas: * keyboard
shortcuts and focus handling, * exposure via ARIA to assistive technology,
and * integration with browser features such as find-in-page. Reducing the
need for developers to build their own widgets should also reduce the size
of pages that use such widgets, which reduces the time and bandwidth needed
for users to load those pages.


Initial public proposalhttps://github.com/openui/open-ui/issues/725

TAG review

TAG review statusNot yet requested.  I intend to do so after the ideas are
a bit more concrete.

Risks


Interoperability and Compatibility

There's some interoperability and compatibility risk around changes to
 styling. Currently details styling is not interoperable as there
are two different approaches, one taken by Gecko and (current) Chromium,
and another taken by WebKit (which was previously shared with Chromium). I
plan to consider interoperability and compatibility when deciding what
approaches to improving  styling are viable.


*Gecko*: No signal.  (See "Tag review status" above.)

*WebKit*: No signal  (See "Tag review status" above.)

*Web developers*: No signals

*Other signals*:

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?

not yet sure, mainly because approach to  styling is not yet
determined


Debuggability

Too early to tell for sure, though probably mostly similar to existing
debugging of CSS.  It's possible UI to find the elements in a group would
be useful (as it might be for radio inputs).

Is this feature fully tested by web-platform-tests

?No, but I intend to add tests as it is developed.

Flag name

Requires code in //chrome?False

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6710427028815872

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status
.

-- 
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/CAG0MU3hf4-mESHH3k%2B%3DpkHr4%3DS6jfxJhKY%3D3Est%2BHc7%2BqUdMdQ%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: CSS font-size-adjust: two-value syntax

[David Baron]

On Mon, Mar 27, 2023 at 6:33 PM ChangSeok Oh  wrote:

> *   Interoperability and Compatibility*
>
>Gecko: Publicly support
>
>WebKit: Positive and in development
>https://bugs.webkit.org/show_bug.cgi?id=254191
>https://github.com/WebKit/WebKit/pull/11744 (I am the author)
>
>Web developers: No signals
>
>Other signals:
>
>WebView application risks
>No known risks
>

It might be useful to separately describe (for some or all of these
sources) support for the 1-value syntax (CSS 2.1, css-fonts-3, css-fonts-4)
and support for the 2-value syntax (css-fonts-5).  For example, according
to MDN
,
Gecko has been shipping the 1-value syntax since Firefox 3 (June 2008) and
the 2-value syntax since Firefox 92 (September 2021).

I'll also add that I'm a big fan of this feature and am happy to see it
implemented.

-David

-- 
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/CAG0MU3i4OsprqC7BT0ELQaUYWKX1%3D-m3Kk_Wym6AfhPKFni_ZQ%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype: CSS inline leading-trim

[David Baron]

Does this also involve implementing the text-edge property (which
leading-trim depends on)?

It also seems like it may be worth starting a discussion in the CSS Working
Group about implementation status, given that the spec says "Do not
implement (yet)".

I also think the summary of the issues WebKit implementors filed
 was informative.

-David

On Mon, Mar 6, 2023 at 9:59 AM Lingqi Chi  wrote:

> Contact emails
>
> lin...@chromium.org, ko...@chromium.org
>
> Explainer
>
> None
>
> Specification
>
> https://w3c.github.io/csswg-drafts/css-inline-3/#propdef-leading-trim
>
> Summary
>
> Specifies whether and how browsers should remove vertical spacings above
> and below the text content from the first and last lines of block text.
> This feature allows developers to have precise control over spacing, and
> ensures font metrics are respected during layout in terms of spacing.
>
>
> Blink component
>
> Blink>Layout>Inline
> 
>
> Motivation
>
> Developers and designers sometimes find the texts are not visually
> aligned, as browsers would pad extra spaces to ensure line height without
> taking the font-reserved space into account. This feature aims to improve
> this.
>
> Initial public proposal
>
> https://github.com/w3c/csswg-drafts/issues/3240
>
> TAG review
>
> N/A
>
> TAG review status
>
> Not applicable
>
> RisksInteroperability and Compatibility
>
> Gecko: No signal
>
> WebKit: Preview
>
>
> https://webkit.org/blog/13839/release-notes-for-safari-technology-preview-163/
>
>
> Web developers:
>
>   The issue was proposed in 2018[1], and got many responses.
>
> [1] https://github.com/w3c/csswg-drafts/issues/3240
>
> Other signals:
>
> WebView application risks
>
> No.
>
>
> Debuggability
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No. Will add more.
>
> Flag nameCSSLeadingTrimBasic
>
> Requires code in //chrome?
>
> False
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1411581
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5174589850648576
>
> --
> 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/CA%2B99URLC-V9Zrscj8F%3D%3DkGmnmp0OmNhGB11Uyy%2B-y5ZExSK5MQ%40mail.gmail.com
> 
> .
>

-- 
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/CAG0MU3iLtOiweH5pvCz%2B_cLtq4A8hvGAORk_PFL8%3Dk%2B-ptQTXg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS font-variant-position property

[David Baron]

On Fri, Feb 24, 2023 at 5:49 AM Yoav Weiss  wrote:

> On Fri, Feb 24, 2023 at 11:27 AM Manuel Rego Casasnovas 
> wrote:
>
>> There's a CSSWG issue about this topic in particular:
>> https://github.com/w3c/csswg-drafts/issues/7441
>
>
> Is this something that can be put on the agenda for the CSSWG to discuss?
>

I added this to the group's (long) agenda backlog.

(Also, a few other relevant CSSWG issues I found were w3c/csswg-drafts#1888
, w3c/csswg-drafts#2796
, w3c/csswg-drafts#5225
, w3c/csswg-drafts#5518
, and also some minutes from
July 2020

and from September 2020

.)

One other point that I missed yesterday is that one of the key reasons that
these new properties can't be used for the default rendering of
/ elements
is that they don't support *nested* subscript/superscript.  One of the
goals of the 2011 discussion I cited above was to solve that issue in a
reasonable way.  All of the current ways of doing typographically correct
super/subscripts only support a single level of super/subscript, and not
nesting.  This works for the majority of use cases, but not all.

-David

-- 
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/CAG0MU3ht%3DrZwCtQoUWJXR4avCaY2TvAa9NMiYAfMsdan94wzVw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS font-variant-position property

[David Baron]

A few notes on the history of this feature that relate to some of the
questions asked:

When font-variant-position was being designed, the CSS Working Group had an
extensive discussion (part 1

, part 2
)
about
trying to build a model where browsers could synthesize appropriate glyphs
if the font didn't have special superscript or subscript glyphs, or only
had special superscript/subscript glyphs for a subset of the characters
that were superscripted/subscripted, in a way that would get the sizes and
positions correct.  This proposal was abandoned primarily because of
evidence that font metrics for super/subscript position and size (which the
proposal depended on) are generally incorrect (e.g., as noted in those
minutes, all Adobe fonts at the time shipped with the same metrics for
superscript position and size), but also secondarily because of the
complexity needed to make it work correctly.  (The underlying goal of that
proposal was to make this property something that could be used for the
default rendering of / elements.)

However, we ended up (and I don't remember the history of this part) with
synthesis in the spec, though with a requirement

that
a single super/subscript is fully synthesized if it can't be fully rendered
without synthesis.  The advantage of doing synthesis is that the semantics
of super/subscript don't get lost, and thus using the feature doesn't
require that the author fully control the fonts that are used (which
authors perhaps think they can do with downloadable fonts, but which isn't
always fully reliable).  But synthesis can certainly lead to bad results
where neighboring superscripts/subscripts are inconsistent with each other,
even though consistency is required within a single super/subscript.  This
makes me think that the synthesis in the current model probably isn't high
enough quality to be a default rendering of / elements, although
the spec is very vague and thus I'm not sure one can say this
authoritatively, and I don't know details of what Gecko implemented.

I don't think the specification was designed around the idea that some
implementations would follow the spec's rules on synthesis and some
implementations would ignore the spec... and thus it does appear to be a
problem that whether an implementation does synthesis isn't detectable.
(This seems worth discussing in the CSS Working Group if it hasn't been
already.)

As far as comparison to the "old way" of doing superscript/subscript:
there are (as discussed) two different "old ways".  The oldest way, and the
way still used

for / elements, and probably still the most common way, involves
vertical-align and font-size: smaller.  This produces a result that is
typographically incorrect:  it's just using body text shrunk to a smaller
size, so the superscripts appear too "light" in comparison to the
surrounding text.  There's also a newer "old way" that involves using the
low level font-feature-settings property, whose use for this case is
discouraged

in the specification, though it produces the same typographically-correct
results as font-variant-position, with all of the same disadvantages (plus
a few more), including (if font-variant-position does have synthesis) the
disadvantage that it might fail very badly when the font doesn't have the
necessary glyphs.

-David

On Thu, Feb 23, 2023 at 7:48 AM Yoav Weiss  wrote:

> The API owners discussed this at length in yesterday's meeting, without
> reaching concrete conclusions.
> It seems to me that it'd be good to get some web developer signals here to
> get a better understanding of if and how they'd be able to use the feature,
> given the interop issues in case of fonts that don't have "super"/"sub"
> features.
>
> I'm not sure what the right answer is (feature detection, synthesis of
> some kind, or something else entirely), but it seems to me that getting
> "x2" instead of "x" or "x" would result in real
> semantic difference.
>
> Do we know how developers are using that feature today, given the
> difference between Gecko and WebKit?
>
> On Thu, Feb 23, 2023 at 11:38 AM 'Munira Tursunova' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Duplicating the summary of our conversation from the chat here.
>>
>> We agreed that it might be confusing for some of the web authors if they
>> don't check the font for the feature existence beforehand. Also
>> 

Re: [blink-dev] Intent to Prototype: CSS headline balancing (`text-wrap: balance`)

[David Baron]

On Tue, Feb 7, 2023 at 7:31 AM Koji Ishii  wrote:

> Specification
> https://w3c.github.io/csswg-drafts/css-text-4/#valdef-text-wrap-balance
>
> Summary
>
> Enables the lengths of lines in a paragraph balanced, for better
> readability and to prevent typographic widows. This feature is often used
> in headlines.
>


It's worth noting that the specification describes text-wrap as one of the
longhand properties comprising part of the newly-shorthand white-space
property.

Is what you're proposing to do here:

 (1) Implement:
   text-space-collapse: collapse | preserve | preserve-breaks
   text-wrap: wrap | no-wrap | balance
   and then turn white-space into a shorthand?  (Optionally, implement
more of the values of text-space-collapse and/or text-wrap or also
implement text-space-trim, but those don't seem necessary to do the text-wrap:
balance feature in line with the spec's model.)  This seems to be the
minimal approach that would be in line with the spec.

(2) Implement text-wrap balance without making it relate to the white-space
property.  This would diverge from what is currently in the spec.

If you're planning to do (2), have you discussed it with the CSS Working
Group?

-David

-- 
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/CAG0MU3g0Ceo5LftCSTwB1DiGD%2BZ7iEcFTYPTzFjULg-Qfx77HA%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: CSS default keyword is disallowed in custom identifiers

[David Baron]

On Mon, Jul 11, 2022 at 12:10 PM Joe Medley  wrote:

> In which milestone will this be removed?
>

Assuming nothing changes, Chrome 105.  I've updated chromestatus.

On Thu, Jul 7, 2022 at 10:36 AM David Baron  wrote:

> As far as what the breakage might look like:  it would look different for
> the different uses of custom idents in CSS.  The possible cases are the CSS
> features that (a) use custom idents and (b) are shipping (no flag or a flag
> with "status: stable") and (c) don't already separately forbid default.
> That list is the following:
>
>- CSS animation names (the @keyframes rule and the value of
>animation-name).  In this case, the breakage would most likely be the
>absence of a CSS animation that was supposed to happen.  It could also lead
>to a *different* set of CSS animations running, if one (now broken) CSS
>declaration of animation or animation-name was previously overriding
>another (still working) one.
>- CSS counter names in the counter-reset, counter-increment, and
>counter-set properties and the counter() and counters() values of the
>content property.  This failure would likely lead to incorrect
>numbering of list-items, footnotes, headings, or something else numbered
>via CSS.
>- The CSS Paint API accepts custom idents as names of the paint
>functions.  Failure here would lead to a custom paint use not working.
>- A property defined with the @property at-rule's syntax descriptor to
>take a  value would also no longer accept default as a
>value where the  was used.
>- The CSS page property accepts custom idents for named pages.  This
>could lead to printing on an incorrectly sized or oriented page or with
>incorrect margins.
>- The CSS @counter-style rule's symbol descriptor accepts custom
>idents in place of strings.  Use of "default" here seems very unlikely in
>valid usage since it is unlikely that the string "default" is used as a
>list marker.
>- The values of CSS transition-property accept custom-idents as a
>forward-compatibility mechanism, to avoid having parse errors when current
>and future CSS properties are mixed.  This means that if a developer
>attempted to specify a transition on a list of CSS properties that included
>default, behavior could change, because that list would now be ignored
>(either leaving no transitions or fallback to another declaration).
>- Likewise, the CSS color-scheme property accepts custom-idents as a
>forward-compatibility mechanism.
>
>
In the process of writing the change, I found that there were some
additional cases (that I could remove in the change) that separately
forbade default.  This means that, for my 8 item list above, I should
actually have removed the fourth and eighth items:

   - the @property at-rule's syntax descriptor
   - the color-scheme property

and thus there are only 6 cases where I believe the behavior changes.

-David


> On Wed, Jul 6, 2022 at 9:50 PM David Baron  wrote:
>>
>>> Contact emailsdba...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://www.w3.org/TR/css-values-3/#custom-idents
>>>
>>> Summary
>>>
>>> The CSS keyword 'default' is not allowed within CSS custom identifiers,
>>> which are used for many types of user-defined names in CSS (for example,
>>> names created by @keyframes rules, counters, @container names, custom
>>> layout or paint names). This adds 'default' to the list of names that are
>>> reserved from being used in custom identifiers, which already reserve
>>> 'inherit', 'initial', 'unset', 'revert', and 'revert-layer'.
>>>
>>>
>>> Note that some existing CSS features that accept custom identifiers
>>> check specifically for 'default' to avoid the risk of worsening the
>>> potential compatibility problem in this deprecation. This means that fixing
>>> the general code for custom identifiers will fix the remaining cases,
>>> though some cases are already fixed.
>>>
>>> Blink componentBlink>CSS
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>
>>> Motivation
>>>
>>> Keywords that CSS uses (or is likely to use in the future) as values
>>> accepted by any CSS property should not be allowed in custom identifiers
>>> because many custom identifiers are also values of CSS properties. If they
>>> can be custom identifiers, then developers could create content that would
>>> be broken by the addition of these keywords as property values either to
>>> all CSS propert

Re: [blink-dev] Intent to Deprecate and Remove: CSS default keyword is disallowed in custom identifiers

[David Baron]

On Thu, Jul 7, 2022 at 10:36 AM David Baron  wrote:

> Most relevant to this intent is the case on http://www.elster.de where
> default is used (which is the only actual site that I'm aware of this
> change affecting):  it is a use in the animation-name property.  The
> relevant chunk of CSS is the following (with newlines added):
>
> body{animation-name:default;animation-duration:1ms;content:'default'}
> @media screen and
> (min-width:20rem),print{body{animation-name:min;content:'min'}}
> @media screen and
> (min-width:30rem),print{body{animation-name:xs;content:'xs'}}
> @media screen and
> (min-width:48rem),print{body{animation-name:small;content:'small'}}
> @media screen and
> (min-width:60rem),print{body{animation-name:content;content:'content'}}
> @media screen and
> (min-width:60rem),print{body{animation-name:medium;content:'medium'}}
> @media screen and
> (min-width:80rem),print{body{animation-name:large;content:'large'}}
> @media screen and
> (min-width:105rem),print{body{animation-name:xl;content:'xl'}}
> @media screen and
> (min-width:120rem),print{body{animation-name:max;content:'max(a, b)'}}
> @keyframes
> default{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> min{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> xs{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> small{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> content{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> medium{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> large{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> xl{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
> @keyframes
> max{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
>
> This is rather a lot of CSS to apply the clip property to body for the
> first 1ms of the page's existence.  I'm not sure why it's there, but maybe
> it's a workaround for something.  In any case, this change would cause this
> chunk of CSS to no longer do whatever it does (which is likely not very
> much) for pages whose width is less than 20rem.
>
> elster.de has had
> <https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+elster> a
> bunch of webcompat issues with Firefox, but none of the ones in that list
> seem related to this issue.
>

And one further point about www.elster.de that I had forgotten about:  the
clip property only applies to absolutely positioned elements, which their
body element is not.  So whether or not default is valid as a custom-ident,
the above CSS should be 18 lines of no-op.

-David

-- 
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/CAG0MU3iCbPu4zd555RAn-b4raJwg7Go42RuV%3DuQ0Mpp0kf8Etw%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: CSS default keyword is disallowed in custom identifiers

[David Baron]

,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
@keyframes
content{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
@keyframes
medium{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
@keyframes
large{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
@keyframes
xl{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}
@keyframes
max{from{clip:rect(1px,auto,auto,auto)}to{clip:rect(0,auto,auto,auto)}}

This is rather a lot of CSS to apply the clip property to body for the
first 1ms of the page's existence.  I'm not sure why it's there, but maybe
it's a workaround for something.  In any case, this change would cause this
chunk of CSS to no longer do whatever it does (which is likely not very
much) for pages whose width is less than 20rem.

elster.de has had
<https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+elster> a bunch
of webcompat issues with Firefox, but none of the ones in that list seem
related to this issue.

-David

On Thu, Jul 7, 2022 at 1:00 AM Yoav Weiss  wrote:

>
>
> On Wed, Jul 6, 2022 at 9:50 PM David Baron  wrote:
>
>> Contact emailsdba...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://www.w3.org/TR/css-values-3/#custom-idents
>>
>> Summary
>>
>> The CSS keyword 'default' is not allowed within CSS custom identifiers,
>> which are used for many types of user-defined names in CSS (for example,
>> names created by @keyframes rules, counters, @container names, custom
>> layout or paint names). This adds 'default' to the list of names that are
>> reserved from being used in custom identifiers, which already reserve
>> 'inherit', 'initial', 'unset', 'revert', and 'revert-layer'.
>>
>>
>> Note that some existing CSS features that accept custom identifiers check
>> specifically for 'default' to avoid the risk of worsening the potential
>> compatibility problem in this deprecation. This means that fixing the
>> general code for custom identifiers will fix the remaining cases, though
>> some cases are already fixed.
>>
>> Blink componentBlink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> Motivation
>>
>> Keywords that CSS uses (or is likely to use in the future) as values
>> accepted by any CSS property should not be allowed in custom identifiers
>> because many custom identifiers are also values of CSS properties. If they
>> can be custom identifiers, then developers could create content that would
>> be broken by the addition of these keywords as property values either to
>> all CSS properties, or to a particular CSS property that already accepts
>> custom identifiers.
>>
>>
>> Initial public proposal
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is some compatibility risk if pages are using default as a custom
>> identifier (for example, as the name of an @keyframes rule that is
>> referenced in animation-name). This risk is lessened by the fact that Gecko
>> and WebKit have already shipped this change; thus shipping this deprecation
>> reduces interoperability risk.
>>
>>
>> *Gecko*: Shipped/Shipping (
>> https://searchfox.org/mozilla-central/rev/f816e52d85cdaf0be7c9e1d2297f833e9ef53e2e/servo/components/style/values/mod.rs#462
>> )
>>
>> *WebKit*: Shipped/Shipping (
>> https://github.com/WebKit/WebKit/blob/main/Source/WebCore/css/parser/CSSParserIdioms.h#L77
>> )
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> 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?
>>
>>
>>
>> Debuggability
>>
>> The debuggability matches the debuggability of syntax errors produced for
>> existing invalid values, which include the reserved names 'inherit',
>> 'initial', etc.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?No.
>>
>> There are tests for some, but not all, of the features that use custom
>> identifiers. I hope to add a few more as part of landing this. An existing
>> test that covers this case is:
>> https://wpt.fyi/results/css/css-properties-values-api/register-property-syntax-parsing.html?label=stable=master
>>  and
>> an existing test that should be expanded is:
>> https://

[blink-dev] Intent to Deprecate and Remove: CSS default keyword is disallowed in custom identifiers

[David Baron]

Contact emailsdba...@chromium.org

ExplainerNone

Specificationhttps://www.w3.org/TR/css-values-3/#custom-idents

Summary

The CSS keyword 'default' is not allowed within CSS custom identifiers,
which are used for many types of user-defined names in CSS (for example,
names created by @keyframes rules, counters, @container names, custom
layout or paint names). This adds 'default' to the list of names that are
reserved from being used in custom identifiers, which already reserve
'inherit', 'initial', 'unset', 'revert', and 'revert-layer'.


Note that some existing CSS features that accept custom identifiers check
specifically for 'default' to avoid the risk of worsening the potential
compatibility problem in this deprecation. This means that fixing the
general code for custom identifiers will fix the remaining cases, though
some cases are already fixed.

Blink componentBlink>CSS


Motivation

Keywords that CSS uses (or is likely to use in the future) as values
accepted by any CSS property should not be allowed in custom identifiers
because many custom identifiers are also values of CSS properties. If they
can be custom identifiers, then developers could create content that would
be broken by the addition of these keywords as property values either to
all CSS properties, or to a particular CSS property that already accepts
custom identifiers.


Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is some compatibility risk if pages are using default as a custom
identifier (for example, as the name of an @keyframes rule that is
referenced in animation-name). This risk is lessened by the fact that Gecko
and WebKit have already shipped this change; thus shipping this deprecation
reduces interoperability risk.


*Gecko*: Shipped/Shipping (
https://searchfox.org/mozilla-central/rev/f816e52d85cdaf0be7c9e1d2297f833e9ef53e2e/servo/components/style/values/mod.rs#462
)

*WebKit*: Shipped/Shipping (
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/css/parser/CSSParserIdioms.h#L77
)

*Web developers*: No signals

*Other signals*:

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?



Debuggability

The debuggability matches the debuggability of syntax errors produced for
existing invalid values, which include the reserved names 'inherit',
'initial', etc.


Is this feature fully tested by web-platform-tests

?No.

There are tests for some, but not all, of the features that use custom
identifiers. I hope to add a few more as part of landing this. An existing
test that covers this case is:
https://wpt.fyi/results/css/css-properties-values-api/register-property-syntax-parsing.html?label=stable=master
and
an existing test that should be expanded is:
https://wpt.fyi/results/css/css-font-loading/fontfaceset-load-css-wide-keywords.html?label=stable=master

Flag name

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=882285

Measurementhttps://chromestatus.com/metrics/feature/timeline/popularity/2628 is
a use counter that is currently around 0.0086% and increasing.
https://github.com/w3c/csswg-drafts/issues/7431#issuecomment-1170371304 has
data from a cluster telemetry run showing one site in the 10K set that
could be affected.

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5096490737860608

This intent message was generated by Chrome Platform Status
 and then hand edited.

-- 
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/CAG0MU3gf2ifuNT64OM7nHvo0jnXxkbZ4BmAh%2BYw0UUSq_iG%3D_g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Independent/Individual Properties for CSS Transforms

[David Baron]

Despite considerably more delay (in getting the dependencies for compositor
animation landed) than I was expecting when I posted the intent to ship...
this is now on track to ship in Chrome 104.  (And I've updated chromestatus
accordingly.)

-David

On Wed, Oct 27, 2021 at 1:26 PM Joe Medley  wrote:

> Hi,
>
> In which version of Chrome do you hope to ship?
>
> Joe
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Thu, Oct 21, 2021 at 12:03 PM Manuel Rego Casasnovas 
> wrote:
>
>> LGTM3.
>>
>> On 21/10/2021 19:53, Daniel Bratell wrote:
>> > LGTM2.
>> >
>> > /Daniel
>> >
>> > On 2021-10-21 08:19, Yoav Weiss wrote:
>> >> LGTM1
>> >> Seems important to catch up here, so thanks for working on this!!
>> >>
>> >> On Mon, Oct 18, 2021 at 11:05 PM David Baron 
>> wrote:
>> >>
>> >>
>> >> Contact emails
>> >>
>> >>
>> >> dba...@chromium.org, kev...@chromium.org,
>> fla...@chromium.org
>> >>
>> >>
>> >> Explainer
>> >>
>> >>
>> >> None
>> >>
>> >>
>> >> Specification
>> >>
>> >>
>> >>
>> https://drafts.csswg.org/css-transforms-2/#individual-transforms
>> >>
>> >>
>> >> Summary
>> >>
>> >>
>> >> This adds three new CSS properties: translate, rotate, and
>> >> scale. This exposes a simple way for web developers to
>> >> access transforms in an intuitive way, without having to
>> >> think about how functions in the transform property
>> >> interact with each other. The properties are individually
>> >> animatable.
>> >>
>> >>
>> >>
>> >> Blink component
>> >>
>> >>
>> >> Blink
>> >> <
>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>> >>
>> >>
>> >> TAG review
>> >>
>> >>
>> >> Already shipped in two browser engines.
>> >>
>> >>
>> >> TAG review status
>> >>
>> >>
>> >> Not applicable (I think)
>> >>
>> >>
>> >> Risks
>> >>
>> >>
>> >>
>> >>
>> >> Interoperability and Compatibility
>> >>
>> >>
>> >>
>> >>
>> >> Gecko: Shipped/Shipping
>> >> (https://bugzilla.mozilla.org/show_bug.cgi?id=1424900)
>> >> Shipped in Firefox 72, January 2020.
>> >>
>> >> WebKit: Shipped/Shipping
>> >> (
>> https://webkit.org/blog/11420/css-individual-transform-properties/)
>> >> Shipped in Safari 14.1 (desktop) / 14.5 (iOS), April 2021.
>> >>
>> >> Web developers: Positive: 25 stars
>> >> on
>> https://bugs.chromium.org/p/chromium/issues/detail?id=496550 .
>> >> Notable early developer request for the feature (before WG
>> >> adoption)
>> >> in:
>> https://twitter.com/rachelnabors/status/618266391993454592
>> https://twitter.com/rachelnabors/status/618267483296825344 and
>> >> early reaction to WG adoption
>> >> in
>> https://twitter.com/SaraSoueidan/status/613368671315054592 .
>> >> Positive developer reactions
>> >> to
>> https://twitter.com/argyleink/status/1338907239990497280 .
>> >> Largely positive reactions to news of other engines
>> >> shipping the feature in responses
>> >> to
>> https://twitter.com/jensimmons/status/1387870244392382468 ,
>> https://twitter.com/simevidas/status/627956718098485248 ,
>> https://twitter.com/dancwilson/status/121457225783989862 ,
>> >> and
>> >> in
>> https://twitter.com/guerriero_se/status/1338468028804001796 ,
>> https://twitter.com/eladsc/status/1216286886697885696 ,
>> https:/

Re: [blink-dev] Intent to Prototype: CSS toggles

[David Baron]

On Tue, Apr 19, 2022 at 10:32 AM Mike Taylor  wrote:

> Specification https://tabatkins.github.io/css-toggle/
>
> A question came up in Security & Privacy review today. Can you clarify
> what "persistent state" means in
> https://tabatkins.github.io/css-toggle/#toggles? I suspect we're not
> re-inventing cookies in CSS here, but can you help me understand what that
> means in the context of CSS toggles? Does it just mean that once set, other
> CSS properties can't influence the state? Or "persistent state (for the
> lifetime of the page)"?
>

I think what the "persistent state" bit is saying is that once a toggle is
created on an element (by the toggle-root property), the toggle doesn't go
away even if the toggle-root property changes.  It's definitely not
something like cookies, since the state doesn't get transferred to other
pages or to fresh loads of the same page.

(I haven't thought much about the question yet, but it's *possible* that it
might be something like form control state that gets persisted specially
during back/forward navigation even when the entire page isn't cached.  I
suspect that may cause more problems than it fixes, though.)

-David

-- 
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/CAG0MU3idUeNMQB4L5C3sZt7T1fpPokoHUz5GT%3DpVDwC_6atR-w%40mail.gmail.com.

[blink-dev] Intent to Prototype: CSS toggles

[David Baron]

Contact emailsdba...@chromium.org, ns...@google.com

Explainerhttps://css.oddbird.net/toggles/explainer/

Specificationhttps://tabatkins.github.io/css-toggle/

Summary

CSS toggles are a mechanism for associating toggleable state with a DOM
element. This state can be defined and connected to activations through CSS
properties, and can be queried in CSS selectors. This provides a
declarative mechanism for specifying state that describes behaviors like
the existing HTML behaviors for checkboxes or radio buttons.

Blink componentBlink>DOM


Motivation

There are many cases where a user interaction (such as a click) toggles
state that styles depend on. These cases include popups, tabs, carousels,
accordions, and toggles controlling light/dark mode. Building these today
requires Javascript. We would like to build a declarative way of doing this
that, if we do it right, will be easier for developers to use, faster, and
more accessible than the solutions that are used today.

Additional context

I'd like to emphasize that this intent to prototype really is an intent to
*prototype*. The goal here is to build an implementation that can be used
to guide the design of this feature (by giving those involved an
implementation to test), not to build something that we'd like to ship
quickly.


Before we would consider shipping something in this space, we would (among
other things) want to do further testing to validate that the result *is*
more accessible than what people use today (or learn that we need to build
in more distinctions that can be reflected into accessibility roles), and
do additional development of the things that we hope can be built on top of
toggles to validate that it works as a primitive.

Initial public proposalhttps://github.com/w3c/csswg-drafts/issues/6991

TAG review
https://github.com/w3ctag/design-reviews/issues/730

TAG review statusPending (just filed)

Risks

Interoperability and Compatibility
Gecko: No signal

WebKit: No signal

Web developers: No direct signals, but what kicked off the original designs
here was OpenUI work around tabs (see, e.g.,
https://open-ui.org/components/tabs.research ).

Other signals:

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

New CSS properties and CSS selectors should be debuggable in the same way
that all existing properties and selectors are. If this turns into
something that we want to ship, we will probably want to add additional
devtools support for understanding the underlying toggle states, but we
don't want to do so this early in the prototyping process.

Is this feature fully tested by web-platform-tests

?No, though I plan to add tests as I write the code

Flag nameCSSToggles

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1250716

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5072281125519360

This intent message was generated by Chrome Platform Status
 and then edited by hand.

-- 
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/CAG0MU3hE3gnQQNHTD7hT-jukBYFgwTXbYZQWSS1iJVXn9J7iyg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: HDR CSS Media Queries

[David Baron]

On Thu, Oct 28, 2021 at 2:38 PM Yoav Weiss  wrote:

>
>
> On Friday, October 22, 2021 at 10:19:44 PM UTC+2 Fernando Serboncini wrote:
>
>> [coming from the other thread... :) ]
>>
>> +1 to what David said. It doesn't seem that returning dynamic-range: high
>> right now would be useful.
>>
>> The spec could use some clarification:
>> - clarify if those criterias need to be supported on different
>> conditions: CSS, images, canvas, ...
>> - clarify if the criterias need to be supported for both with/without
>> alpha (afaik there may be implementation differences there, but I may be
>> wrong here).
>> - I wonder if the definitions of high contrast/peak brightness should
>> match the industry definitions for HDR displays? I'm not an expert, but I
>> know those exist.
>> I think it's potentially okay to ignore those definitions, but I'd ask
>> for a rationale here.
>>
>> I think it's a great thing to summarize hdr into a single media query,
>> but the risk here would be to release a semantic that guarantees very
>> little, and therefore is not useful in the long run.
>>
>>
>> On Fri, Oct 22, 2021 at 10:04 AM David Baron  wrote:
>>
>>> This sounds like exactly the sort of case where an implementation should
>>> report (dynamic-range: standard) and (video-dynamic-range: high).  It
>>> would be great to see the spec clarified to make it clearer what UA support
>>> is expected for each, though.
>>>
>>> -David
>>>
>>> On Thu, Oct 21, 2021 at 7:03 PM Will Cassella 
>>> wrote:
>>>
>>>> Copying over from the other thread (trying to continue the discussion
>>>> here):
>>>>
>>>> The spec <https://www.w3.org/TR/mediaqueries-5/#dynamic-range> requires
>>>>> that "The combination of the User Agent and the output device fulfill all
>>>>> of the following criteria" when describing what it means to be high
>>>>> dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS,
>>>>> HTML, or Canvas
>>>>
>>>>
> David - I'm likely missing something here, but I thought (based on this
> thread
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/epSTNPYkLIs/m/o5l7pZk1AwAJ>)
> that we do have wide-gamut support in CSS, HTML and Canvas.
> Are you saying we don't support this due to lack of color level 4 support?
> Or something else?
>

That intent makes it sound like we have wide-gamut support for canvas
(though others would be able to speak more authoritatively about it) but I
don't think we do in HTML or CSS.  (I also should have included images in
my list, though I think if we have support with canvas then we probably do
for images as well.).)


> I also didn't interpret the spec as saying anything about gamut (but
> rather about color depth <https://www.w3.org/TR/mediaqueries-5/#color>),
> although it may be possible that wide gamuts and high color depth correlate
> 1:1. Can you clarify if that's what you meant?
>

I should have been more precise about meeting the spec's requirements
rather than just using the term "wide-gamut".  You're correct that it's not
1:1, though I think that in practice an implementation is unlikely to meet
the spec's requirements on color depth and contrast ratio without
supporting colors beyond sRGB's gamut.

(I also suspect we may not meet the color depth requirement in the spec,
perhaps not for canvas or images as well.)

-David


>
>
>> , I think it's probably incorrect to report that (dynamic-range: high) is
>>>>> true based only on the device, which is what it looks to me like the 
>>>>> current
>>>>> code
>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/media_query_evaluator.cc;l=351-378;drc=4d3cb20c1aebba55e54112531222c7434d29f3b0>
>>>>>  does.
>>>>> Admittedly, the spec could probably use some clarification as to what it
>>>>> means for the User Agent to fulfill the criteria for both the
>>>>> dynamic-range and video-dynamic-range queries, but my understanding
>>>>> of what the spec is trying to say is that Chrome probably shouldn't say
>>>>> that (dynamic-range: high) is true until it supports wide-gamut
>>>>> colors in at least some and maybe all of those contexts.
>>>>
>>>>
>>>> I think you're right that the spec needs some clarification, since
>>>> we're trying to incrementally enable adoption of HDR on the web the intent
>>>> isn't

Re: [blink-dev] Intent to Ship: HDR CSS Media Queries

[David Baron]

This sounds like exactly the sort of case where an implementation should
report (dynamic-range: standard) and (video-dynamic-range: high).  It would
be great to see the spec clarified to make it clearer what UA support is
expected for each, though.

-David

On Thu, Oct 21, 2021 at 7:03 PM Will Cassella  wrote:

> Copying over from the other thread (trying to continue the discussion
> here):
>
> The spec  requires
>> that "The combination of the User Agent and the output device fulfill all
>> of the following criteria" when describing what it means to be high
>> dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS,
>> HTML, or Canvas, I think it's probably incorrect to report that 
>> (dynamic-range:
>> high) is true based only on the device, which is what it looks to me
>> like the current code
>> 
>>  does.
>> Admittedly, the spec could probably use some clarification as to what it
>> means for the User Agent to fulfill the criteria for both the
>> dynamic-range and video-dynamic-range queries, but my understanding of
>> what the spec is trying to say is that Chrome probably shouldn't say that 
>> (dynamic-range:
>> high) is true until it supports wide-gamut colors in at least some and
>> maybe all of those contexts.
>
>
> I think you're right that the spec needs some clarification, since we're
> trying to incrementally enable adoption of HDR on the web the intent isn't
> to signal that HDR is supported by all APIs. We do already support HDR in
> some scenarios, such as the  element, so having these queries exist
> to let developers detect display capabilities is already useful.
>
> On Wed, Oct 20, 2021 at 11:27 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Thu, Oct 21, 2021 at 7:01 AM Will Cassella 
>> wrote:
>>
>>> Thanks for the feedback! I've updated that section:
>>>
>>> Debuggability
>>>
>>> Styles with these media queries can be viewed and edited in the devtools
>>> frontend, albeit without proper highlighting. I've created pull requests on
>>> the relevant libraries used in the devtools frontend to enable this.
>>> https://github.com/stylelint/stylelint/pull/5613
>>> https://github.com/codemirror/CodeMirror/pull/6803
>>>
>>> On Wednesday, October 20, 2021 at 9:10:36 AM UTC-7 Mathias Bynens wrote:
>>>
 On Wed, Oct 20, 2021 at 5:44 PM Will Cassella 
 wrote:

> Contact emailscas...@chromium.org, chcunning...@chromium.org,
> videostack-...@chromium.org
>
> Explainer
> Adds MediaQueries for detecting HDR vs HDR displays
> https://www.w3.org/TR/mediaqueries-5/#dynamic-range
> https://www.w3.org/TR/mediaqueries-5/#video-dynamic-range
>
> Specificationhttps://www.w3.org/TR/mediaqueries-5/#dynamic-range
>
> Summary
>
> Adds media queries to CSS which allow a page to detect the current
> display device’s support for HDR. This feature adds two new CSS media
> queries: 'dynamic-range' and 'video-dynamic-range', both of which may be
> one of 'standard' or 'high'. Chrome will resolve these queries according 
> to
> the capabilities of the display device the browser window is currently
> positioned on, allowing pages to toggle CSS rules accordingly or respond 
> in
> Javascript via 'window.matchMedia()'.
>
>
> Blink componentBlink>CSS
> 
>
> Motivation
>
> As HDR-supported displays become more common, web developers need ways
> to enable HDR content on their web pages without compromising the
> experience for users of non-HDR displays, or mixed-HDR multi-display
> setups. CSS already provides the 'media query' concept for toggling rules
> based on display device characteristics, and this feature extends that set
> of queries to enable detecting HDR support on the current display device.
>
>
> Initial public proposal
>
> TAG reviewNot Filed. This is an incremental change to CSS Media
> Queries, already adopted by CSS WG.
>

>> I agree a TAG review is not needed for the `dynamic-range` MQ, as it's
>> shipped in Safari and adopted by the CSSWG.
>> The video variant however doesn't meet that criteria. Was the concept of
>> `video-*` MQs discussed with the TAG? Are there other `video-*` MQs that
>> are already shipped?
>>
>>
>>>
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Worth prototyping (
> https://github.com/mozilla/standards-positions/issues/584)
>
> WebKit: Shipped/Shipping (
> https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/)
> Partially implemented - `video-dynamic-range` not yet supported

Re: [blink-dev] Intent to Ship: HDR CSS Media Queries

[David Baron]

The spec  requires
that "The combination of the User Agent and the output device fulfill all
of the following criteria" when describing what it means to be high
dynamic-range.  Since Chromium doesn't support wide-gamut colors in CSS,
HTML, or Canvas, I think it's probably incorrect to report that (dynamic-range:
high) is true based only on the device, which is what it looks to me like
the current code

does.  Admittedly, the spec could probably use some clarification as to
what it means for the User Agent to fulfill the criteria for both the
dynamic-range and video-dynamic-range queries, but my understanding of what
the spec is trying to say is that Chrome probably shouldn't say that
(dynamic-range:
high) is true until it supports wide-gamut colors in at least some and
maybe all of those contexts.

-David

On Wed, Oct 20, 2021 at 11:41 AM 'Will Cassella' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailscas...@chromium.org, chcunning...@chromium.org,
> videostack-...@chromium.org
>
> Explainer
> Adds MediaQueries for detecting HDR vs HDR displays
> https://www.w3.org/TR/mediaqueries-5/#dynamic-range
> https://www.w3.org/TR/mediaqueries-5/#video-dynamic-range
>
> Specificationhttps://www.w3.org/TR/mediaqueries-5/#dynamic-range
>
> Summary
>
> Adds media queries to CSS which allow a page to detect the current display
> device’s support for HDR. This feature adds two new CSS media queries:
> 'dynamic-range' and 'video-dynamic-range', both of which may be one of
> 'standard' or 'high'. Chrome will resolve these queries according to the
> capabilities of the display device the browser window is currently
> positioned on, allowing pages to toggle CSS rules accordingly or respond in
> Javascript via 'window.matchMedia()'.
>
>
> Blink componentBlink>CSS
> 
>
> Motivation
>
> As HDR-supported displays become more common, web developers need ways to
> enable HDR content on their web pages without compromising the experience
> for users of non-HDR displays, or mixed-HDR multi-display setups. CSS
> already provides the 'media query' concept for toggling rules based on
> display device characteristics, and this feature extends that set of
> queries to enable detecting HDR support on the current display device.
>
>
> Initial public proposal
>
> TAG reviewNot Filed. This is an incremental change to CSS Media Queries,
> already adopted by CSS WG.
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> Gecko: Worth prototyping (
> https://github.com/mozilla/standards-positions/issues/584)
>
> WebKit: Shipped/Shipping (
> https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/)
> Partially implemented - `video-dynamic-range` not yet supported
>
> Web developers: Positive (
> https://github.com/w3c/csswg-drafts/issues/4471#issuecomment-548085935)
> Feature designed with the help of Netflix.
>
>
> Debuggability
>
> No specific DevTools support
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
> https://wpt.fyi/results/css/mediaqueries/dynamic-range.html
>
> Flag nameCSSDynamicRangeMediaQueries
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1224711
>
> Estimated milestones97
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5680926106320896
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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/CAKj4DkD1-oS5OSZye8DwcGhdrYVwKYv3omYOwE0p-WCm3L77iw%40mail.gmail.com
> 
> .
>

-- 
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/CAG0MU3gHMxyCBxWphPTg4mP8RNbsJQC30pAaB4-P4%3D-FLA4B0w%40mail.gmail.com.

Re: [blink-dev] Intent to Implement and Ship: transform: perspective(none)

[David Baron]

Thanks for the LGTMs.

I filed WebKit bug 231361 <https://bugs.webkit.org/show_bug.cgi?id=231361> for
implementing perspective(none) in WebKit, and for MDN documentation of
perspective() I created PR mdn/content#9653
<https://github.com/mdn/content/pull/9653> (fixing some other issues as
well) and filed issue mdn/browser-compat-data#12742
<https://github.com/mdn/browser-compat-data/issues/12742>.

It's indeed expected that the existing WPT tests for perspective(none) are
all passing in Firefox since they were all added as part of the patch that
implemented it in Firefox.  I have one more WPT test addition in the
Chromium patch.

-David

On Thu, Oct 7, 2021 at 3:55 AM Philip Jägenstedt 
wrote:

> LGTM3, this is an easy case, an improvement to an existing feature already
> on track to ship in another browser.
>
> Although not part of our launch process, can I ask what documentation
> updates will be needed here?
> https://developer.mozilla.org/en-US/docs/Web/CSS/transform-function/perspective()
> doesn't mention "none" at all, is that the page to update? If so, a new
> entry in the compat table at the bottom of the page would also be a good
> idea. If it's clear what needs to be done, would you mind filing issues at
> https://github.com/mdn/content/issues and
> https://github.com/mdn/browser-compat-data/issues? (Again, not a proper
> part of our launch process, so optional.)
>
> For WPT, indeed it looks like this is already passing in Firefox:
>
> https://wpt.fyi/results/css/css-transforms/animation/transform-interpolation-001.html?label=experimental=master
>
> On Thu, Oct 7, 2021 at 8:49 AM Manuel Rego Casasnovas 
> wrote:
>
>> LGTM2
>>
>> On 07/10/2021 08:07, Yoav Weiss wrote:
>> > LGTM1
>> >
>> > On Mon, Oct 4, 2021 at 10:42 PM David Baron > > <mailto:dba...@chromium.org>> wrote:
>> >
>> >
>> > Contact emails
>> >
>> > dba...@chromium.org <mailto:dba...@chromium.org>
>> >
>> >
>> > Explainer
>> >
>> > None
>> >
>> >
>> > Specification
>> >
>> > https://drafts.csswg.org/css-transforms-2/#funcdef-perspective
>> > <https://drafts.csswg.org/css-transforms-2/#funcdef-perspective>
>> >
>> >
>> > Summary
>> >
>> > Implement support for a 'none' argument to the perspective()
>> > function within the syntax of the CSS transform property. This
>> > provides the perspective() function with a value that gives the
>> > identity matrix. Its effect is as though the perspective() function
>> > was given an argument that is infinite. This makes it easier (or, in
>> > some cases, possible) to do animations involving the perspective()
>> > function where one of the endpoints of the animation is the identity
>> > matrix.
>> >
>> >
>> >
>> > Blink component
>> >
>> > Blink>CSS
>> > <
>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>> >
>> >
>> > Search tags
>> >
>> > css <https://chromestatus.com/features#tags:css>, transform
>> > <https://chromestatus.com/features#tags:transform>, perspective
>> > <https://chromestatus.com/features#tags:perspective>
>> >
>> >
>> > TAG review
>> >
>> > Not needed for a single value addition to a single function within a
>> > CSS property.
>> >
>> >
>> > TAG review status
>> >
>> > Not applicable
>> >
>> >
>> > Risks
>> >
>> >
>> >
>> > Interoperability and Compatibility
>> >
>> >
>> >
>> > Gecko: Shipped/Shipping
>> > (https://bugzilla.mozilla.org/show_bug.cgi?id=1725207
>> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1725207>) Will ship
>> > very soon in Firefox 93.
>> >
>> > WebKit: No signal
>> > (
>> https://github.com/w3c/csswg-drafts/issues/6488#issuecomment-896962025
>> > <
>> https://github.com/w3c/csswg-drafts/issues/6488#issuecomment-896962025>)
>> > Safari developers participated in the CSS Working Group discussion
>> > about adding it and were ok with the addition. I recognize this
>> > isn't an official signal, but this seems perhaps to

[blink-dev] Intent to Implement and Ship: transform: perspective(none)

[David Baron]

Contact emailsdba...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/css-transforms-2/#funcdef-perspective

Summary

Implement support for a 'none' argument to the perspective() function
within the syntax of the CSS transform property. This provides the
perspective() function with a value that gives the identity matrix. Its
effect is as though the perspective() function was given an argument that
is infinite. This makes it easier (or, in some cases, possible) to do
animations involving the perspective() function where one of the endpoints
of the animation is the identity matrix.


Blink componentBlink>CSS


Search tagscss , transform
, perspective


TAG reviewNot needed for a single value addition to a single function
within a CSS property.

TAG review statusNot applicable

Risks


Interoperability and Compatibility



Gecko: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1725207) Will ship very soon
in Firefox 93.

WebKit: No signal (
https://github.com/w3c/csswg-drafts/issues/6488#issuecomment-896962025)
Safari developers participated in the CSS Working Group discussion about
adding it and were ok with the addition. I recognize this isn't an official
signal, but this seems perhaps too small a feature to ask for an explicit
one.

Web developers: Positive (
https://bugzilla.mozilla.org/show_bug.cgi?id=1723266#c2) this is the one
explicit signal from a developer that I could find


Debuggability

Should be equally debuggable as existing values of the perspective()
function.


Is this feature fully tested by web-platform-tests

?Yes

Flag name

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1253596

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5687325523705856

This intent message was generated by Chrome Platform Status
.

-- 
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/CAG0MU3iW8-GYebwN6TF8WCCKLcQNEVkqunuoPSL%2BkPrPW1u0qQ%40mail.gmail.com.