- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Mar 2021 19:34:05 -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.
=========================================
Administrative/Reminders
------------------------
- dbaron will be added as editor of Transforms 2
- Please indicate on the wiki (
https://wiki.csswg.org/planning/virtual-april-2021 )
if you'll be able to attend any sessions for the virtual F2F
- Everyone is encouraged to help clear out the old PRs in the repo
CSS Contain
-----------
- A decision on how to handle content-visibility:auto content for
accessibility (Issue #5857) will wait until there is more
feedback from the AT developers and accessibility teams.
- RESOLVED: Animation work is skipped in content-visibility subtrees
when they're not rendered. creating, taking, or ending
animations. Animation is refreshed if recalculate (Issue
#5611: content-visibility should pause css animations in
subtree)
CSS Highlight API
-----------------
- RESOLVED: Custom highlights will always go below native highlights
(Issue #4595: Position of the custom highlights relative
to the built in ones)
- RESOLVED: Leave custom highlight properties in the api as
currently written in spec (Issue #4591: Priority by
number or some other method)
CSS Pseudo
----------
- No one is pushing for a fast solution for issue #4398 (Semantics
of CSSPseudoElement : EventTarget) so people will continue to
think on the best way to solve the issue.
- RESOLVED: Add sub-pseudo elements [to style punctuation before or
after ::first-letter]. Bikeshed names (Issue #2040:
Problems with styling ::first-letter with punctuation)
Syntax & Values
---------------
- RESOLVED: Add quirky hex color and quirky unitless lengths to
Values & Units (Issue #6100: Upstream parser quirks to
syntax)
- RESOLVED: Add a quirks mode flag to parsing algorithm and syntax
which is passed to property specific parsers (Issue
#6100)
====== FULL MEETING MINUTES =====
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Mar/0023.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins-Bittner
Christian Biesinger
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Sanket Joshi
Brad Kemper
Una Kravets
Vladimir Levin
Daniel Libby
Ting-Yu Lin
Peter Linss
Morgan Reschenberg
Florian Rivoal
Cassondra Roberts
Miriam Suzanne
Lea Verou
Regrets:
Brian Kardell
Chris Lilley
Greg Whitworth
Scribe: dael
astearns: Still a little light, but let's get going
astearns: Item #3 was put on the agenda mistakenly so we'll skip
astearns: Any other changes to the agenda?
fantasai: Reminder Sizing 3 is up for review. 1 open issue we need
help on
astearns: You'd like people to look at issue or general review?
fantasai: Both
<fantasai> https://lists.w3.org/Archives/Public/www-style/2021Mar/0013.html
<fantasai> https://github.com/w3c/csswg-drafts/issues/5665#issuecomment-797046688
astearns: Additional thing from me, dbaron has volunteered to help
co-edit transforms 2. Happy to take him up on it.
April virtual long-form meeting
===============================
<astearns> https://wiki.csswg.org/planning/virtual-april-2021
astearns: I have set up a long for meeting. Wiki page ^
astearns: If you can attend please put yourself on the participant
list. We'll put and agenda together
Ancient PRs that need attention
===============================
astearns: Have very old PRs, some back to 2017
astearns: I'd like everybody who contributes to repo to look at PRs,
see if they can be folded in or closed. If you close put a
comment why
astearns: Would be nice to have only PRs from current year
<fantasai> https://github.com/w3c/csswg-drafts/pulls
CSS Contain
===========
Clarify whether content-visibility: auto subtree elements are visible
in accessibility
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5857
vmpstr: Continuation from last week
vmpstr: Question is what do we expose to a11y when
content-visibility:auto element is offscreen
vmpstr: Had a bit of discussion on the issue. Don't think we have a
good front runner. Wanted to continue discussion
dholbert: I spoke to Mozilla a11y folks and they prefer expose
everything approach for offscreen content we haven't
computed style for
vmpstr: That would include exposing things that would otherwise have
display:none?
dholbert: Correct. And when we compute style they may be hidden to
a11y tree
vmpstr: Okay. That was initial proposal. Rossen raised concerns. I
don't know if he is on or someone can represent.
Rossen: I'm here but sounds like we're recurring back into
discussion. Not sure what is the new part of discussion
florian: Has been new stuff on GH. Clarifications. I think everyone
agrees painting can be skipped. For styling the difficulty
is for search in page or tabbing or indexing the page then
you do need to style the content to find out what's
available
florian: For most of these you can do so lazily.
florian: Ideally you could do same for a11y tree if we had a lazy
build a11y tree. Could exist in theory, but not what we
have. It's build synchronously.
florian: Either we require you always compute the style so that we
have consistent state that makes sense or we have a
problem. Requiring computing the styles is more expensive
then being desired
vmpstr: Also dlibby mentioned that there is work to have a notion of
lazy generated content in a11y content.
vmpstr: Agree with florian that problem what is exposed to a11y is a
view on the whole doc. Hand it off to a11y tech and user can
explore in totality
vmpstr: If we do that I don't know how we solve with either not
expose the content or always style which I'm against
florian: You could skip painting, so not completely useless
vmpstr: Design was to skip work and style takes a significant chunk
of work so would reduce effectiveness
florian: So that's a summary of where we're at in GH. Haven't
figured out what to do from there
chrishtr: Sounds like a11y team of chrome and mozilla have deemed
current chrome is okay which is to always include a11y
things that are offscreen
florian: Include everything
chrishtr: Yep
florian: script, style tags, everything
chrishtr: Things with a11y roles
chrishtr: That are offscreen are included in a11y even though we do
not yet know their styles
smfr: You'll have a significant change in tree if something triggers
content-visibility to render. So something would disappear
chrishtr: Yep, might occur
florian: Landmarks could even be a problem. But a11y tree doesn't
only contain landmarks so it would contain script and style
tags which are not meant for display
Rossen: I was able to catch up on thread. I think this is still very
much in progress in thread. We seem to be repeating from
previous call. I wanted to see besides looking for more
engagement you're looking for.
vmpstr: Making progress was my hope. If engagement is what it takes,
that's what I'm looking for
vmpstr: We're stuck with same ideas. We have to start agreeing and I
don't think we are
Rossen: Do we know if "JAWS test" user that commented is from the
JAWS team? The comment they added on May 17
vmpstr: I'm not sure who that is
vmpstr: Comment they mentioned is if it's offscreen it should be
exposed and if it's hidden it should not. This is the whole
middle section of the issue. If it's offscreen it is hidden.
It's unclear what to do
Rossen: Reason I asked is I think this is going to be common
representation of AT devs. I'm not going to make a statement
on their behalf. Having worked with them I know a lot of
innovation and differentiation for ATs, especially those
working behind more restrictive platform APIs, they tend to
be very susceptible to these kinds of changes
Rossen: Given they don't have full access to the rendered tree this
for them becomes ground. And if we give them something
that's not representing reality we will confuse because
they're building caches based on what's available. Think
about it lighting up different features that should be there
in presence of content. We're saying the content is there
kinda sorta but we're going to say it's there.
Rossen: Reason I'm saying it we are repeating conversation from last
week with added clarification. Not seeing the level of
engagement. I want to see what Dominick from chrome teams
and a11y team says. Also waiting on [missed] to hear back
from the MS AT partners
vmpstr: Chrome a11y team did look and they were okay with what I
mentioned earlier
Rossen: That's a good signal. Thank you
astearns: Rossen can I task you to get feedback from your AT partners
Rossen: Not just our partners will have impact. But based on
comments Daniel Levy is contacting them
astearns: I'll take agenda tag off. Let's put it back on when we
have enough to have a yea or nay vote
content-visibility should pause css animations in subtree
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5611
vmpstr: Hard to talk about this without previous one in mind. This
is about skipping css animations in subtrees that are
unrendered by content-visibility
vmpstr: Building toward making sure we can skip the animation work
if elements are not rendered
vmpstr: Have agreement from a couple people on issue who I believe
are animation experts
vmpstr: I think we should still resolve, though we haven't solved
the previous issue
astearns: What's the resolution they agree on?
vmpstr: Animation work is skipped in content-visibility subtrees
when they're not rendered. creating, taking, or ending
animations. Animation is refreshed if recalculate
astearns: Reasonable to me. Any concerns?
astearns: Objections?
RESOLVED: Animation work is skipped in content-visibility subtrees
when they're not rendered. creating, taking, or ending
animations. Animation is refreshed if recalculate
CSS Highlight API
=================
Position of the custom highlights relative to the built in ones
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4595
sanketj: CSS pseudo spec specifies the order of highlights.
selection is on top, then target text, spelling error,
grammar error. Where does custom highlight fit?
sanketj: Proposal is below the native ones. Wouldn't want author
defined highlight to suppress
<fantasai> wfm
florian: Sounds good for default terms. If it's possible to override
is more subtle. Being at the bottom by default makes sense.
At least on one Apple system you can't draw over selection
highlight
florian: As to if it should be overrideable...going over selection
you can't. For spelling error you can imagine author
wanting custom spelling but default grammar. Without
ability to go on top of some native you can't
sanketj: Fair. Did experiment to see if wanted to support
interleaving. If you want to go above others we can't find
scenario and don't have requests so thought we could solve
that down the line and define the option later
fantasai: Agree. I would note effects of highlights to stack so some
effects will override but some will stack
florian: I'm fine with proposal. I want to make sure we talk now
because we have related issues about the API to determine
what's on top. There were suggestions for negative to go
under and positive above, if we say never above we rule
that out. Knowing if we want to enable now or later is
relevant
sanketj: I think priority stuff which is next issue is about how
they stack relative to each other. This is to custom
highlights. I think slightly tangential. I think there's
somewhat separate problems
astearns: Proposal: custom highlights will always go below native
highlights
astearns: Objections?
RESOLVED: custom highlights will always go below native highlights
Priority by number or some other method
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4591
sanketj: Within these custom highlight overlays there's default
order based on order registered. Highlights added later are
painted on top
sanketj: Problem we're trying to solve is what if author want
earlier registered on top
sanketj: Couple of options
sanketj: First is what we have in spec which is define priority
property on highlight OM type. Number you can set >0 to
give priority
sanketj: Example: If you have foo and bar highlights and bar
registered later, bar paints on top. If you want foo on top
set priority=1 and we would get that effect
sanketj: Another approach is not use priority but use highlight
registry as source of truth. Introduce additional APIs like
insertBefore which lets you change the order. Don't need
additional concept, but means we can't re-use API surface.
Seems like a lot of overhead
sanketj: Not super happy about that approach. I prefer what's in
spec. Want other thoughts.
<fantasai> +1 to not using CSS property
sanketj: On more approach listed is similar to first but use a css
property for priority. Don't think it works because it sets
individual pseudos not for the overlay. Shouldn't be able
to stack per pseudo element differently
florian: Agree. I don't think anybody loves similar to z-index but
everything else seems worse
florian: Separate issue, if we go with number is it int or float and
are negatives allowed
sanketj: Right. If we have time we can go in to that. Want to get
resolution of should we allow a number at all
astearns: Side conversation between fantasai and TabAtkins on IRC
fantasai: I just asked TabAtkins what he thinks. I'm not super
familiar.
fantasai: Question, between options 1 and 3 if there was some kind
of standard interface for a lengthless type set what would
your preference be?
sanketj: If we had something we could reuse?
fantasai: Yeah. One of hesitations is we would need custom
implementation. If that wasn't the case, what is
preference?
sanketj: Highlight registry seems more about registration. Seems
weird to manipulate that because then it's about control
not just registering. I think I'd still prefer priority by
number
florian: Agree. Having explicit manipulation would be clunky. Maybe
a little more powerful. But if you're developing all
highlights you pick a number. If using libraries you'll be
satisfied with neither direct numbers or direct manipulation
florian: I think the simpler thing is better
florian: Maybe you want some sort of constraints but we don't want
to bake that into browser. That's on 3rd party library
fantasai: I think that order used as registered is tiebreaker is
useful. Within library you can register back to back and
they'll file together. With other method that's trickier
astearns: If you have 2 and concerned about way they overlap you
register with numbers that have relationship you like. As
others are registered that doesn't change order you
register in
florian: You can register both at 733 in the right order and even if
someone uses that number they won't be able to interject
between
florian: I think there's been a bit of back and forth and no one
loves numbers, but everything else is worse in some way
fantasai: Seems reasonable
astearns: Positive int or allowing float so you can fit in between
plinss: Going back for a second. If answer is this will not satisfy
anybody why don't we do the highlight manager?
florian: You'll need a manager if you have multiple libraries with
multiple highlights. If you just write 3 yourself you give
a number then you're fine
sanketj: Agree
fantasai: If the library accepts a parameter you can pass in a
number unless you want to interleave. If you pass in to
register at 6 that's straight forward.
plinss: Isn't that a common case? Isn't it common libraries won't
bother to care about others that always use highlights
plinss: In order for multiple libraries to work they have to be
aware of each other. I don't think that's common case
sanketj: Common to have spell check extension to have highlights,
paging to have highlights. Uncoordinated use cases. For
that there's no good solution. They could manipulate
priority or the highlight registry. I don't think anyone is
trying to solve that problem that a manager would do.
sanketj: Trying to provide a middle ground so uncoordinated access
is not an issue and let authors manage the highlights they
want
florian: Even if libraries don't coordinate you can do it after they
set. Only if they're trying to fight each other. You can
fix it for them if they don't care
GameMaker: Can we change priority after?
florian: It's an attribute you can set
GameMaker: Okay
plinss: Not the hill I want to die on, but concerned platform has
half solutions that require 3rd party library to work
consistently. Don't want to add another
florian: I don't think you need a manager
astearns: Since plinss won't die on the hill, sounds like we have
consensus to add to API as a priority
florian: Can we resolve on that? There's a separate issue for type
of number
sanketj: There are. Not on agenda.
florian: They're separable
astearns: Prop: Keep what is in the spec for priority
astearns: Objections to leave custom highlight properties in the api
as in spec
RESOLVED: Leave custom highlight properties in the api as in spec
astearns: Lots of other items on agenda. Hash out number type in
issues?
sanketj: Yes, we can do that
CSS Pseudo
==========
Semantics of CSSPseudoElement : EventTarget
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4398
fantasai: I don't know what to do with it. I'm asking for help from
the WG
astearns: Anyone want to jump in?
astearns: Might be better to tag particular people
fantasai: Don't know who
florian: Punt while we figure out event handling for highlight APIs?
Might influence here
florian: Until that's resolved we leave this hanging. Unless someone
has better idea
sanketj: I think we discussed similar on a different call. I don't
think there's implementor interest in this area
dbaron: My reaction to the issue is probably worth going slow. One
suggestion is this is only for animation events and that
might be reasonable way to start
dbaron: Not a good idea to make intent to change event handling in
non-backwards compat ways. Difference in how click events
are handled is probably not what we want
florian: Even handling on pseudos we haven't attacked precisely, but
want to handle it generally. I agree
astearns: Let's leave it here. We have highlight issue linked. This
will go into issue
astearns: As dbaron says we can go slowly on this.
Problems with styling ::first-letter with punctuation
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2040
fantasai: Basically a requirement that punctuation associated with
first-letter is styled independent of the letter.
Sometimes punctuation is in font of paragraph, sometimes
in between. Sometimes not colored when letter is
fantasai: Need pseudo elements to select first letter different from
punctuation
<fantasai> https://github.com/w3c/csswg-drafts/issues/2040#issuecomment-669614648
fantasai: AmeliaBR posted ^ which is adding pseudo element which
attaches to first-letter pseudo and attaches to only
letter and only punctuation so you can style separate
fantasai: Other comment is ::marker has similar structure with
counter, prefix, postfix. Might want to use same system
and maybe same names
fantasai: Not going to get through bikesheding, but want to ask WG
if this is how they want to go about it
astearns: Not sure about parallel between this and marker. Seem
different kinds. But I do like idea of tacking on another
pseudo element to first-letter
fantasai: Do we like idea of one name for punctuation on both sides
with before/after params or separate pseudo?
florian: Common to style before and after same?
fantasai: Don't know
florian: I think that's the answer. If it's common it's useful to
style both
astearns: Less common to have following punctuation. I would guess
when you have both style same
florian: In French it's not rare. "J' is plausible. I don't know
style, though. If want to style ' same as letter you may
want before punctuation different
<florian> example: “J'aime…
fantasai: I can see cases where you want different. Things like em
dash you want aligned to center of letter but smaller
size. But might not want the vertical align on the
apostrophe
astearns: Agree with examples. I'm wrong about not having cases
astearns: Other thoughts?
astearns: Could resolve to have a pseudo element with way to pick
apart pieces
fantasai: pseudo-sub-element. And we can bikeshed later
florian: If a shortname falls out we can have it, but we shouldn't
explicitly try to have one
astearns: Shouldn't make the same syntax for marker
fantasai: prefix and postfix perhaps
<fantasai> ::prefix / ::postfix
astearns: YOu'd like resolution?
astearns: Objections?
fantasai: Add sub-pseudo elements. Bikeshed name
RESOLVED: Add sub-pseudo elements. Bikeshed name
Syntax & Values
===============
Upstream parser quirks to syntax
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6100
TabAtkins: 2 simple bits
TabAtkins: Anne pointed out there's parser quirks for hashless hex
and unitless length
TabAtkins: In quirks spec
TabAtkins: Agreed in past we should try and upstream to relevant
specs
TabAtkins: Agree can move in. Don't need to do anything in syntax
because don't parse normally so should be in V&U where we
define hashless hex and unitless length production
TabAtkins: Notes about when in quirks mode we accept these
TabAtkins: One syntax change is let you pass in that you're parsing
in quirks mode into syntax parse. Parsing algorithm
generically evokes do what you need to parse and that
should get quirks mode flag explicitly so it knows to
accept quirky hex and length
TabAtkins: Asking for 2 resolutions. Add quirky hex color and quirky
lengths to V&U
TabAtkins: Add an explicit quirk flag for parsing algo in syntax
that is invoked at point syntax spec asks you to parse
these
florian: I believe I know answer, none of these quirks could
disappear?
TabAtkins: No, have been around for forever. As long as quirks mode
exists, they will
fantasai: Fine, but shove into an appendix
TabAtkins: Happy to do that
astearns: Other comments?
RESOLVED: Add quirky hex color and quirky lengths to V&U
TabAtkins: Add a quirks mode flag to parsing algorithm and syntax
which is passed to property specific parsers
astearns: Objections?
florian: Questions - what passes it to parsing algorithm?
TabAtkins: Callers. Things don't generally invoke those, but now
they exist they can if necessary pass a quirks mode flag
astearns: Objections?
RESOLVED: Add a quirks mode flag to parsing algorithm and syntax
which is passed to property specific parsers
astearns: Nothing that's 3 minutes so we'll be done early
astearns: Thanks everyone for calling in
Received on Wednesday, 24 March 2021 23:34:47 UTC