- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Oct 2021 18:35:56 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Highlight API
-----------------
- RESOLVED: Add the new attribute of highlight type which is an enum
(Issue #6498: Figure out how highlights are exposed to
the accessibility tree)
- RESOLVED: Add spelling-error, grammar-error, and highlight (Issue
#6498)
- Further discussion about how the highlights are exposed should be
added to the TPAC meeting agenda with the APA group.
CSSOM
-----
- RESOLVED: Take scientific notation and match serialization of JS
(Issue #6471: Serialization of large numbers should use
scientific notation)
CSS Color Adjust
----------------
- The group didn't think auto-darkening should be linked to forced
colors mode since auto-darkening appears to happen at paint time.
Discussion will continue on issue #6664 (Forced colors mode usage
beyond high contrast mode).
Flexbox & Sizing
----------------
- RESOLVED: min-height:auto just has special behavior that allows
child %s to still resolve, and it's not a precedent to
apply to all the other content-based keywords. (Thus,
we'll remove, or possibly keep-but-reverse, the note
that's currently in the spec.) (Issue #6457: Definiteness
of min-height: min-content)
CSSOM View
----------
- RESOLVED: The offsetWidth and offsetHeight should be computed out
of the principal css box (Issue #6588: Needs more details
for offsetWidth and offsetHeight)
- RESOLVED: It should include all fragments (Issue #6588)
- Discussion will continue on issue #6588 on how to answer how to
decide if a block is split does the block doing the splitting get
included in the calculation
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Oct/0000.html
Scribe: dael
CSS Highlight API
=================
Figure out how highlights are exposed to the accessibility tree
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6498
Rossen: Before we get going, we're starting with 2nd hour of topic.
We'll box the first topic to 15 minutes. Right?
astearns: Sure. Not sure if more because topic is complex
* florian aim for 15, not box at 15
<BoCupp> https://github.com/w3c/csswg-drafts/issues/6498#issuecomment-930627914
BoCupp: I'm seeking maybe a few resolutions
BoCupp: I'll go through what hoping to resolve on and take questions
BoCupp: Issue comment I posted in IRC summarizes proposed API change
BoCupp: Would like to resolve on adding new type attribute to
highlight api. Gives semantic meaning that can be used for
highlight a11y mappings
<BoCupp> https://drafts.csswg.org/css-pseudo-4/#highlight-selectors
BoCupp: What to resolve values should include generic highlight on
enum that can be used in absence of more applicable value.
Any other values should align with pseudo elements named in
the pseudo elements spec^
BoCupp: Last part would like to settle on is for L1 of spec with
think in addition to generic is spelling-error and
grammar-error. Open to additional ones. Right now have
selection and target text in spec
BoCupp: Selection is complicated topic. In L1 missing support for
pointer events, planned for L2. might defer until then.
That's my preference. Additionally selection has semantics
that make it more complicated
BoCupp: target-text is more of a question for anyone working on
beforeMatch API. Might be good to have discussion on if
highlight API can take over that roll
BoCupp: If so might consider expanding enum. Hoping to get as far as
we can. I'll take questions on it
florian: I think the approach is right. Had been mentioned to use
descriptive strings but that has many more problems on
translating and how a11y layer can use. Starting with
spelling and grammar is good
florian: Not sure I would limit to what's there. I think what's most
important is a11y tree knows how to handle. If the platform
knows how to handle we can add those.
florian: You have mentioned find-in-page, I think would make sense to
expose even if it's not built in
florian: Agree with general approach. Can explore more values later
BoCupp: Thank you
Rossen: Question. If we pull back, semantically what you described
makes sense for different types of ranges to be added
Rossen: From a11y PoV, and this was motivation behind issue, can you
explain how these different types of ranges are exposed to
a11y?
Rossen: Specific example: overlapping ranges that are all overlapping
one string of text. What is the a11y tree going to look like?
Will the highlight ranges have structural changes to a11y
tree or simply exposed as property on existing nodes?
BoCupp: In terms of exposure; chromium a11y tree which translates to
multiple platform a11y trees. Those trees have different
attribution types. We have different UI constants assigned to
range of text. These enums will map to constants in
platform-specific way.
BoCupp: On mac see spelling not grammar so we'd map grammar to
spelling. If we added find on page and there's no text-match
enum we'd map to a generic highlight so the user knows
something is highlighted
BoCupp: In chromium the format in tree has start and end ranges over
text. Each paired with an enum value that annotates text with
meaning. I think they can overlap. Not 100% sure on overlap,
good to followup
BoCupp: Do have priority on highlight interface. If we can't do
something for a specific platform we can resolve based on
priority of highlight. These custom highlights can sort below
regular highlights
BoCupp: Does that answer?
Rossen: Sort of. My worry is we're still exposing something most tree
structures are unsuited to deal with. Because we're allow
irregular overlapping. HTML went away from overlapping tags
in past and this is allowing. Some worry.
BoCupp: One thing to ease worry even though I don't have specific
answer. We do have selection, find-on-page, spelling and
grammar overlaps. Those exist today and our hope is to mirror
native platform
tantek: I like the exploration of the area. Like Rossen unsure about
implementability. Want to call out difference between
declarative to style vs and API that could increase impl and
privacy challenges.
tantek: find-in-page I wanted to point out browsers distinguish
between all instances of text and the current found on text
item which the user sees. Slightly different. Not sure if
will expose in API
tantek: That is a privacy hole. Giving access to what text is being
searched has privacy implications. Not sure how to quantify
but want to call it out
BoCupp: Response to that is highlight API does not expose that. It
would only be if we have something like beforeMatch event
where you would get what user is searching and then highlight
you could use. It's not a mechanism to discover what is
searched for. Thanks for comments, though. Get distinction on
find-on-page
tantek: This does seem to have overlap with web editing group. Is
there coordination?
BoCupp: There is. Originally presented there but decided it was
better developed in css
tantek: Great
fantasai: I think having types of highlights makes sense, especially
if can hook into platform APIs. Might be interesting to be
able to spec with an extra field that's descriptive and
allows l10n
fantasai: For all cases where we have or expect a highlight it would
make sense to define enum up front. As people write code we
want them to pick the appropriate enum even if that's not
doing something just yet
BoCupp: Good point, thank you
florian: I wouldn't rush to having a string. If we have it too early
people would rush to that over enum
fantasai: I think you do that by making string more annoying. Have to
put enum and the string and string through dictionary that
maps lang tag. I don't think there's a reason not to do
unless it would take a while
florian: I think it would take a while. How do you select what
translation? UA but that's often wrong so what do you use
BoCupp: My main concern with free string is that today because can't
map free string into different platforms those platforms
might evolve but in UA we can't annotate the text.
BoCupp: In absence of author hearing the experience they don't know
what to write and some people would write "grammar" and some
would write "you shouldn't have a comma without at least 3
things in a string". How do we put some semantic to it. That
was why constrained set of types
fantasai: Makes sense
BoCupp: Point I like is we can add more enums and communicating those
semantics is straight forward. I would like to stay away from
free string
<@florian> +1
<@fantasai> sgtm
Rossen: I'm seeing +1 on IRC. Let's see if we can take resolutions
Rossen: Proposal: Add the new attribute of highlight type which is an
enum
Rossen: Before we decide on values, opinions or objections to adding?
RESOLVED: Add the new attribute of highlight type which is an enum
Rossen: Highlight, spelling error, and grammar. Objections to adding
those?
heycam: Is there a particular reason to have spellingerror instead of
spelling-error?
BoCupp: Propose the hyphen to match the pseudo names
BoCupp: One of the things I said initially is prefer we align with
css pseudo in terms of names
Rossen: Not opposed. We're working on a design principle in TAG that
would invalidate this soon, but won't stop now
Rossen: Proposal: add spelling-error, grammar-error, and highlight
RESOLVED: Add spelling-error, grammar-error, and highlight
<GameMaker> +1 for matching
<@florian> q+
Rossen: Thank you for bringing this
florian: Quick question
florian: To make sense this needs to make to a11y tree. Is someone
taking action to describe that somewhere? I suspect not in
css spec
Rossen: Suggest we add this to API joint meeting during TPAC
BoCupp: Sounds good
CSSOM
=====
Serialization of large numbers should use scientific notation
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6471
Rossen: Added to TPAC agenda but we didn't get to it
smfr: The issue is how large numbers serialize.
smfr: Agreed in past to allow scientific notation when we pass.
Difference in serialization. FF and Blink use scientific
notation. Webkit writes them out
smfr: One question is if should be different for number vs int.
z-index how much precision do we maintain so they round trip,
for example
smfr: And then there are differences like blink adds leading 0s.
smfr: This impacts wpt so would be good to resolve
TabAtkins: Well defined in CSSOM. Will grab a link
<@TabAtkins> https://drafts.csswg.org/cssom/#serializing-css-values
TabAtkins: Per this int serialize fully and floats with no more than
6 digits. If needed scientific with 6 digits.
TabAtkins: It is defined. If question is should define something else
we can talk about it
smfr: Fine with as spec. Question is if implementers will implement
as spec
florian: Does this no more than 6 cover the leading 0s?
TabAtkins: 6 significant digits. And need to use shortest form.
Leading 0s are dropped
<@TabAtkins> "A base-ten number using digits 0-9 (U+0030 to U+0039)
in the shortest form possible, using "." to separate
decimals (if any), rounding the value if necessary to
not produce more than 6 decimals, preceded by "-"
(U+002D) if it is negative."
Rossen: Sounds like we don't need to change a definition. Back to
smfr question about are implementers willing to use this
definition?
Rossen: Survey question to implementers
iank: All of our folks are in EU so I'm not sure
Rossen: Perhaps we don't have right folks.
Rossen: We can resolve on the issue as no change to spec and
encourage implementers to engage
Rossen: Reasonable?
smfr: I'm reading the link from TabAtkins it says scientific notation
is not used. Is it out of date?
TabAtkins: Yes, must be. Thought it was required. Integer question is
answered. Hmm.
TabAtkins: No way to satisfy this without scientific notation. If you
do a large number you need more than 6
Rossen: And why is it a note?
TabAtkins: It's a clarification. It should fall out from definition.
Rossen: Perhaps we can try and amend the spec to require scientific
notation?
TabAtkins: Yes
smfr: Serialization we can reference? Perhaps from JS?
TabAtkins: JS does have a well specified one
smfr: Chrome JS doesn't match number serialization which is a bit
surprising
Rossen: We can call for resolution here to add scientific notation to
be used for number
Rossen: Then wait for TabAtkins or someone to define the
serialization. Unless you have one right now
TabAtkins: Happy to take that
Rossen: Proposal: Take scientific notation and match serialization
of JS
Rossen: Objections?
RESOLVED: Take scientific notation and match serialization of JS
Rossen: Call to impl and getting feedback still stays
CSS Color Adjust
================
Forced colors mode usage beyond high contrast mode
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6664
Rossen: Tagged by rune
Rossen: Can anyone take this?
TabAtkins: fantasai and I can
TabAtkins: Question is how to reflect UA feature that does forced
dark mode. Being tested on Android, I believe iOS has it
<smfr> only forced dark mode in apple mail, not in the browser
TabAtkins: Suggestion is reflect as a forced colors mode. Would imply
we're doing things forced colors does
TabAtkins: Assuming auto-darkening does match up enough I think
that's fine and we reflect that in prefers-color-scheme.
Acts like author chose a11y feature to set colors to dark
TabAtkins: Seems straight forward. Doesn't give authors more things
to react to. I suggest we accept Beverly's suggestion
Rossen: Feedback?
smfr: Not sure if auto-darkening and forced colors are same. There's
a bunch we resolved on for forced colors that's a lot difference
alisonmaher: Haven't looked too much, but I don't think forced dark
is same. I think it's paint time. Don't use system
colors to force darkening. I don't think implementations
would match as spec for forced colors
Rossen: You're saying darkening is paint?
alisonmaher: Yes. haven't looked that much
smfr: That's true of what Apple did in mail
Rossen: That's a pretty major difference in behavior. Not sure
harmonizing the two makes sense
TabAtkins: Enough difference that authors should react differently?
Not sure. If similar enough people can act the same way
and for auto-darken should change colors it's fine. If
they should do other changes should use another MQ
Rossen: Would adjust-color override apply to auto-darkening?
TabAtkins: I would assume it would
dlibby: Regarding difference between features a lot of authors will
write forced-color MQ and use system colors. With forced dark
mode being at paint time it could lead to some
inconsistencies. Seems hard to map the two concepts directly
<@fantasai> +1 to not linking this with forced-colors mode
Rossen: Feedback I'm hearing is that even though conceptually there
are similarities it doesn't necessarily mean it will be
gray-dark or green-dark or whatever in order to match the
paint time effects
Rossen: I think we should take it back to the issue and do more work
there
Rossen: Sound reasonable?
TabAtkins: Yep
Should forced-colors override border-image?
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5469#issuecomment-919751233
Rossen: My feedback before was we have not implemented border-image
override in the past and therefore never got feedback from
authors. We have overwritten BG image in the past and got
quite a bit of lover letters from users
Rossen: For that reason we came back and introduced backplate and
restored the images.
Rossen: That's why my feedback last time is we're fine with current
spec.
Rossen: That is what I said that wasn't captured
Rossen: Anything else to talk about here?
TabAtkins: What you said sounds opposite. Resolution in issue is
forced-color does not override image. You appear to say
you all did override and didn't get complaints?
Rossen: Didn't override border image ever. Didn't get complaints.
Overrode background image
TabAtkins: From perspective that no one said leaving border image was
distracting. Don't know removing would cause problems
TabAtkins: Makes sense. Can keep current resolution
Rossen: Anything else on it? If not we can close once minutes post
Flexbox & Sizing
================
Definiteness of min-height: min-content
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6457
TabAtkins: We resolved a few weeks ago...the discussion on the call
was roughly that min-height:auto needs it special behavior
but probably didn't want to extend to other content-sizing
keywords
TabAtkins: Further discussion on issue went back and forth on minor
details. Overall everyone agrees that's fine
<@fantasai> proposal is
https://github.com/w3c/csswg-drafts/issues/6457#issuecomment-917223624
<@fantasai> "min-height:auto just has special behavior that allows
child %s to still resolve, and it's not a precedent to
apply to all the other content-based keywords. "
TabAtkins: Proposal: Accept results of last discussion - all
intrinsic sizing keywords besides auto make sizes
indefinite for boxes
Rossen: Everything but auto makes it indefinite?
TabAtkins: Yeah
<@TabAtkins> So, Agenda+ to resolve that min-height:auto just has
special behavior that allows child %s to still resolve,
and it's not a precedent to apply to all the other
content-based keywords. (Thus, we'll remove, or possibly
keep-but-reverse, the note that's currently in the spec.)
TabAtkins: prop from issue ^
<@fantasai> rationale is in dholbert's comment
https://github.com/w3c/csswg-drafts/issues/6457#issuecomment-915427806
TabAtkins: content keywords make it indefinite
Rossen: Reasonable. Any comments?
<@fantasai> +1 from me (and dholbert obviously ;)
Rossen: Objections?
<@dholbert> +1 :D
RESOLVED: min-height:auto just has special behavior that allows child
%s to still resolve, and it's not a precedent to apply to
all the other content-based keywords. (Thus, we'll remove,
or possibly keep-but-reverse, the note that's currently in
the spec.)
CSSOM View
==========
Needs more details for offsetWidth and offsetHeight
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6588
fantasai: koji posted the spec for offsetWidth and Height is not very
clear. Says first layout box but that's not clearly
defined. Also not clear on 0 values
fantasai: Proposal is it should say take principal css layout box.
Given impl include fragments we should spec that. If box
fragments we consider all
fantasai: Difference in impl if an inline box is split by block
level. Gecko includes both inline fragments and block-level
box. Block and WK ignore the block-level box. Definitely
should include fragments before and after
fantasai: Handful of small things
Rossen: Clarifying question on point about fragmented boxes. Do
variable width boxes aggregate the offsetHight differently?
Rossen: If I read the last point about if block-level box should be
included. Assuming we do include the fragments after and
assuming they are not in the same width fragmentainer, does
that have any effect?
fantasai: That's a little beyond what I can answer
Rossen: I think fragmentation case will be difficult
dbaron: I wanted to mention another case. Inline boxes can be split
due to bidi reordering. Should be handled like linebreaking,
but worth explicitly mentioning so it's tested
Rossen: Good point
fantasai: Most of this is straight forward. One big question is do we
include the block-level box that induces the split or do we
only include the fragments in the inline
Rossen: Resolve on the easy ones?
Rossen: The offsetWidth and Height should be computed out of the
principal css box
Rossen: Start there?
fantasai: Sure
Rossen: Objections?
RESOLVED: The offsetWidth and offsetHeight should be computed out of
the principal css box
Rossen: Fragmentation makes it complicate. For inline case
considering all fragments makes sense. Should resolve on that
Rossen: Objections?
RESOLVED: It should include all fragments
<dbaron> I think the hard part of fragmentation is when the inline's
containing block is fragmented...
Rossen: For the block-level boxes is the previous resolution enough
and as we come up with specific cases we can add?
fantasai: I think it's a very different fragmentation case. Even in a
single column if there's an inline box and there's a block
box that causes the inline box to split we should handle
the inline fragments before and after.
fantasai: So do we also consider the block box that's doing the
splitting?
fantasai: As if it's wrapped in a fragment of this element
fantasai: Or do we ignore
Rossen: I don't know. Does anybody?
<@TabAtkins> ¯\_(ツ)_/¯
Rossen: Perhaps we leave this as an open question and continue on
this in issue
dbaron: Weakly lean toward not including. Very weakly
fantasai: That's where I'm at. Ask impl if one way is easier and if
there is go with that?
Rossen: Let's continue in GH and not force a resolution. we have
enough conversation that will go in the issue
Received on Thursday, 7 October 2021 22:37:36 UTC