- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Nov 2018 19:51:24 -0500
- 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.
=========================================
Selectors
---------
- RESOLVED: Rename :matches() to :is() and deprecate :matches() in
Safari and anywhere else using it (Issue #3258)
- There is a use counter running to :blank (Issue #1967). The group
will look at this in ~2 months once there's data. If there's no
compat risk, Chrome is willing to change.
- RESOLVED: Add a Sensitive 's' flag (Issue #2101)
- :valid-within / :invalid-within pseudo-classes may need to move
into Selectors 5 (Issue #3072). There's also interest in
investigating :has-child to see if that solves enough use cases
to be worth doing.
Filter Effects
--------------
- There was disagreement on where backdrop filter should be able to
be set (FXTF Issue #53: Backdrop filters should not use
BackgroundImage). Isolating it would reduce likelihood that this
is an expensive property to implement, but also reduces the
potential functionality of the property. Discussion will
continue in the github issue around potential use cases and this
will be added to the next APAC agenda when dino can attend.
- RESOLVED: Publish a new WD of Filter Effects L1
CSS Overflow
------------
- majidvp is working on trying to implement the propose change in
issue #2988 ('overflow' 2-value syntax is in wrong order). In
addition to this specific problem there's a need to address the
larger issue of logical and physical properties interacting with
shorthands.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Nov/0016.html
Present:
Rachel Andrew
Tab Atkins
Daid Baron
Emilio Cobos Álvarez
Benjamin De Cock
Elika Etemad
Simon Fraser
Chris Harrelson
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Thierry Michel
Michael Miller
Ian Pouncey
Florian Rivoal
Jen Simmons
Markus Stange
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Tantek Çelik
Dave Cramer
Tony Graham
Nigel Megitt
François Remy
Scribe: dael
astearns: Let's get started. We'll skip the first 2 items until we
have TabAtkins or chrishtr on
astearns: Is there anybody that would like changes/additions to
agenda?
Selectors
=========
Rename :matches() to :is()
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/3258
astearns: Added a while back.
fantasai: One of the side discussions during discussion about
:where() was maybe :is() is better name than :matches. We
have :not and the opposite is :matches. It being a clear
pairing would be useful, especially in contrast with
:where(). Also to make it shorter.
fantasai: I filed this as a separate issue. We didn't conclude on
that tangential discussion. Seems excitement in issue.
fantasai: We do have Safari shipping :matches() If not that this
would be obvious to switch. But there is that. What does
WG think?
leaverou: Given it's only Safari there's no web compat. Nobody is
using this. Personally I'd strongly support. :is() is a
far better name. It makes a lot of sense. It's the logical
opposite of :not()
<bkardell> does this mean :where() should be :matches() then?
<fantasai> no
astearns: One thing to avoid is having both :matches() and :is() if
it's something where Safari doesn't feel they can rename
and have to support both. Both would be a bad result
smfr: We talked about deprecation path for :matches() previously.
I'm not sure I'm okay with just switching to :is(). I'm sure
there will be somewhere using it. But I'm okay with a
deprecation path for :matches()
fantasai: Then I propose we rename in spec and Safari sets up a
deprecation path. Since you're only impl we'll all have to
impl :is(). We can note :matches() as obsolete and
browsers don't have to impl. Then Safari removes at point
it makes sense for them
fantasai: Given it's not in other impl and we don't have web compat
clamor to impl matches that seems sensible path
* leaverou wonders since when is the bar for web compat problems
"someone, somewhere is using it"?
astearns: Other concerns?
Ben: I agree no one is using it now but many people have heard of it
and there's documentation everywhere. I would piggy back on
that instead of renaming it
<bkardell> does it feel unfortunate that we have a dom method called
.matches() that kinda does what :matches() does and those
won't have symmetry anymore?
astearns: bkardell mentioned in IRC there's the DOM method called
.matches()
fantasai: Sort of. DOM takes a string. DOM doesn't deal with
specificity. One of the key distinctions we want and want
to make obvious is between :where() and this. Calling it
:matches() doesn't help this distinction. Calling it
something not matches means it's not paired to DOM.
fantasai: Using :is pairs it more closely with :not, which has the
same specificity behavior, in contrast with :where
chrisl: I agree with rename to :is(). The polyfill argument you can
do either way where when polyfills change it will change for
them
leaverou: The polyfills spit out current CSS so no compat issue
leaverou: Internal compat within CSS is more important than external
compat with JS.
astearns: How one could evaluate is more important. I tend to agree
with renaming.
astearns: Not hearing objections against rename. I propose: Rename
:matches() to :is() and deprecate :matches() in Safari and
anywhere else using it
RESOLVED: Rename :matches() to :is() and deprecate :matches() in
Safari and anywhere else using it
bkardell: I wanted to get clear in my head- That means we're set on
:where() for 0 specificity thing.
fantasai: Yeah. We considered that option and rejected it.
bkardell: Okay
astearns: Anything else on this?
Filter Effects
==============
Backdrop filters should not use BackgroundImage
-----------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/53
chrishtr: We talked at TPAC. Advantages of performance and
implementation simplicity raised
chrishtr: Also good because consistent with things like
mix-blend-mode. Objection was mix-blend-mode doesn't
respect isolation. Turns out that was typo in example
chrishtr: Reasons we should have BackdropFilter in the isolated
group are performance, ease of implementation, consistency
with other modes
chrishtr: Since TPAC Mason Freed(sp?) has done research in HTTP
Archive and we couldn't find any site that had an effect
not easily achievable by parenting BackgroundFilter under
root stacking context
smfr: I think when mix-blend-mode was impl I thought it was a
mistake. Point of backdrop filters you blur everything behind
your element. Trivial to create test cases where you couldn't
get the desired effect. Happens to be used like fixed position
because it's less intense. The effect designers haven't tried
they can't get. We need to give designers wide scope rather
then force to fudge with page
TabAtkins: Agree it's trivial to create test cases, we haven't found
any realistic cases where we can't achieve without moving
element within the DOM. It's not just a matter of free
choice. Lots of more difficult technical issue if allowed
inside various filters and stacking context.
TabAtkins: If entire content is blurred, in a blur filter container
and blur backdrop filter does it have 1 or 2 blurs?
TabAtkins: Hard question to answer if you can do arbitrary blending
with whatever is behind you. If it's stacking context
based it's much simpler
smfr: Agree there are issues to be resolved if element with
background filter has other effects.
smfr: If there aren't anything behind the elements that's not
ambiguous on order. Impl is similar in 2 cases except one you
have to get the bitmap to apply to and the other you render
from stacking context
smfr: It's hard and expensive which we know, but you get a nice
graphic property. I think it supplies more use case.
smfr: It would be hard for webkit to impl any other way because we
rely on system set backdrop
TabAtkins: We've got the opposite problem
TabAtkins: You glossed over difficulty of resolving double filter.
Example: container with blur. 2 pieces of content, an
element and a backdrop blur that's on top of first
TabAtkins: Blur on container is understood, but does that mean
backdrop filter does a blur of what's behind me sees a
blurred child and does a blur or does it see the
unblurred child? There isn't a simple answer and your
decision will have strict implications on how to impl.
Following strict stacking gives you a clear answer
TabAtkins: Even if you say we do it because how platform does, I
don't know how your platform would handle this case.
TabAtkins: I'm concerned about this as generally all pixels
underneath. That's hard to define
smfr: Easy to define of appendix of CSS2.2 You render everything up
to the element with backdrop filter. It's different the
mix-blend-mode and different to SVG filters. I think in
blurring we should clarify with test cases.
smfr: If saying element behind has blur you blur and then apply
background filter
TabAtkins: Container has the blur. That's unclear if before or after
smfr: I think you blur the thing with backdrop additionally
TabAtkins: Blur entire contents then do background filter blur?
smfr: If blur is on a container of the backdrop...[thinks]
<dbaron> I think in some cases (e.g., backdrop filter inside
something with opacity) the right thing to do "visually"
may be to *invert* the opacity (which can be seen as one
case of a filter)
<dbaron> but not all filters are invertible
chrishtr: Have to drop content underneath, apply blur, backdrop
filter, draw under, and blur it all again.
chrishtr: It can be done, but it's quite strange. Also a big
performance cliff. Drawing everything a second time and
applying effects doubles the display list. Also what if
there's a scroller or a video back there. Or multiple
nested backdrop filters. Run time will be exponential
astearns: Given that you have said the use case for not isolating
can be achieved by changing where things are in DOM, that
performance cliff is around anyway as far as I understand.
It just depends on arranging
TabAtkins: Under our preference it wouldn't work if you nest weird
or it's up high in the hierarchy and the effect works
fine. So it's cheap or works differently in a visible
way. Either way it's cheap-ish
chrishtr: Also if you define to isolated group you don't get
exponential with backdrop filter. Each is a stacking
context so only goes up to containing thing.
chrishtr: General concern about introducing something with large,
possibly exponential, to the platform without a known
effect that justified
smfr: Would like to do this on a call with dino. Can we bring this
to next APAC call?
astearns: Also useful to continue adding cases to this issue. We can
do this async and provide better clarity.
TabAtkins: Do both.
chrishtr: smfr could you reach out to dino?
smfr: Yep.
astearns: That's probably enough on this issue.
Publication
-----------
github: https://github.com/w3c/fxtf-drafts/issues/310
chrishtr: L2 spec specifies the enclosing isolated group behavior. I
think that's only thing in L2. Does ti make sense to
publish without that?
astearns: And that's only thing in L2?
chrishtr: I believe so. No objections to publishing L1
astearns: L1 is a WD?
chris: Agree if we have 2 impl and neither agrees with spec we
should fix before FPWD. L1 we should update. I think we have
editorship change and I'd like to get that in.
chrishtr: I was added as editor. krit at TPAC was committed to
finishing L1
astearns: Let me see. krit can be committed but others can work
chrishtr: Yes, point was he's still involved
astearns: Editorship aside; krit is still in. I think we can resolve
on a new WD of L1
<chris> +1 to new WD of L1
astearns: Objections to publish a new WD of filter-effects L1?
RESOLVED: Publish a new WD of filter-effects L1
astearns: I'll talk to krit about adding chrishtr as an editor.
Great if you both can work.
Selectors (continued)
=====================
Decide on :blank
----------------
github: https://github.com/w3c/csswg-drafts/issues/1967
astearns: Discussed this a number of times
astearns: Incl deferring from last week
astearns: It was if anyone was volunteering to be first impl
TabAtkins: We've added a use counter to check if change is web
compat. We're happy to change to include whitespace if
won't break. [missed] added a use counter last week. Will
be several weeks for data. Assuming it's fine we're
amenable to it. Might want to look in 2 months once we
have data
astearns: Everyone else okay waiting for data?
astearns: Great.
<TabAtkins> use counter
https://chromium-review.googlesource.com/c/chromium/src/+/1326003
Case-sensitive attribute selectors
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2101
TabAtkins: Turns out there's a couple of HTML attributes that must
be matched case insensitive in selectors.
TabAtkins: We let UAs or Authors match case insensitive for UA
stylesheet. Type attribute requires this.
TabAtkins: <ol> uses type in way that requires case sensitivity
TabAtkins: Because type elsewhere requires case insensitive it would
be weird and bad if some were sensitive and some not.
Just like we added i tag to allow authors to opt in, we
can do opposite to force case sensitive.
TabAtkins: Put in a UA style sheet and in a few places where author
needs to match against case sensitive they use that.
fantasai: I don't have objections to adding the flag. Confused as to
why type attribute it's inherently case sensitive on <ol>
dbaron: It's per attribute, not attribute+element. attribute+element
is a lot more complicated and this is only use case
TabAtkins: I like s as the flag. Insensitive = i, Sensitive = s
<florian> +1 to "s"
fantasai: Agreed
astearns: Objections to adding a Sensitive 's' flag?
RESOLVED: Add a Sensitive 's' flag
Shadow Parts
============
confirm browser support
-----------------------
astearns: Is fergal on?
TabAtkins: He just wanted a publication request. He wasn't able to
be on last week, but we resolved anyway.
astearns: I thought might be about idl changes
chris: It's queue for publication tomorrow so it's good
TabAtkins: How recently did you generate fpwd? He's made changes in
last 2 days
chris: Did it yesterday. Has to be queued 24h before
TabAtkins: That's good. Cool.
Selectors (continued)
=====================
:valid-within / :invalid-within pseudo-classes
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3072
astearns: Anything anyone knows we can resolve on? We were
discussing in issue
fantasai: Flag this for selectors 5? Don't see anything
bkardell: I think I would support Selectors 5.
bkardell: I know raised on issue, but how far do we want to care
within thing? We have :target-within and :focus-within,
but that was before :focus-visible so now we need
:focus-visible-within. Also ask for :valid-within,
:invalid-within. Valid use cases, but why just those?
bkardell: Other requests for empty/blank within. Just ways of
scooting around can't do :has
TabAtkins: Reason we have a small list is we can't do :has because
it's dramatically expensive. Can do a small number of
carefully controlled state-based, everything we add is
substantial additional cost. There will always be a small
list of what we allow. Larger list of what we want, but
can't do all. Everything has a good argument, but need to
be selective on what include
bkardell: Suggesting see if create something reasonable that avoids
some of that. Maybe impossible or unlikely that we'll have
has. I don't know that there's not something we can do
that's acceptable and not prone to a lot of withins and
explaining why some are and some aren't. Something clearly
articulates
TabAtkins: There is no clear articulation. It's the most high value
and worth spending impl and perf penalties. It's
arbitrary. No clear reason for cut off. It's we don't
feel we should add more. What's left isn't worth
increasing
TabAtkins: Boris has argued a simple :has-child might be something
impl are amenable too. It's a simple case of how much you
need to check. :has-child is only up one level, more
limited in cost. Might be okay for cost. Will cover a lot
of what people need. Won't be everything and can't allow
chaining. If we feel a lot of use cases can be addressed
by parent caring about children that's a direction - we
should check use cases
bkardell: That's what I mean. I know Boris had interesting ideas.
I've had similar convos with number of impl. A lot of
thoughts as what we could do. Instead of doing lots of
withins let's see what we can do to take a big chunk of
stuff
TabAtkins: Might be good to look at lots of cases to see if it's
just parent/child or more. If it's mostly parent/child
it's worth looking at has-child. That's a study that
should be done. I recommend if you're interested in
pursuing this
<bradk> :has(:focus|:target|:focus-visible|:valid|:invalid)
<fantasai> bradk++
<gregwhitworth> I can't imagine the use cases only being has-child()
as there are still needs for wrapper divs/spans, etc
<florian> +1 to greg.
<gregwhitworth> you'll need something that penetrates further down
<bkardell> that is also part of what I mean, that is maybe worth
articulating as a criteria we use for determining whether
we'd consider a thing and why
emilio: Slight difference between within selectors and has. Within
work on flat tree and can cross shadow boundaries. Worth
considering.
TabAtkins: Forgot about that. That is interesting
astearns: All this will go into issue. Sounds like we should
continue there and look at figuring out if this goes into
selectors 5.
<fantasai> majidvp, any update on
https://github.com/w3c/csswg-drafts/issues/2988 ?
<majidvp> fantasai: no new update. I have not had a chance to work
on this since last update. My next step was to look at the
mobile data from httparchive. Pending that does not raise
a red flag we can try to fix this in Blink.
CSS Overflow
============
'overflow' 2-value syntax is in wrong order
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2988
astearns: IRC chat above about it
fantasai: Looks like waiting on majidvp making change in Blink which
requires him doing some research
florian: What are we blocked on majidvp for?
TabAtkins: He's an interested impl who understand problem and wants
to fix.
florian: He's attempting to do what we spec and if he succeeds that
overrules the concerns?
TabAtkins: I believe so. I think only concern is compat so us being
happy avoids that
emilio: Compat concern, but also shorthands that expand to multiple
longhands. Don't know if Blink plans to impl, but need to do
more off spec work.
TabAtkins: Yes, that's discussion from TPAC. That's a larger issue
that needs to be resolved in sensible way.
TabAtkins: We already have a number of properties with this problem,
so we need to solve for all
emilio: Cannot fix this without figuring out whole thing
TabAtkins: We've already got margin-start and margin-left
emilio: margin shorthand is only physical
TabAtkins: Yes, but need to worry about shorthand interaction with
both. Same thing you've got here.
emilio: It's another level of interaction.
TabAtkins: I don't understand how different.
florian: Same as having the extra keyword on shorthands to say. We
don't have that.
TabAtkins: If you set margin and margin-inline-start and ask for
margin, we don't know what it should return
emilio: We do
florian: Margin is shorthand of physical only.
fantasai: It's impl that way. If you replace margin with physical
shorthands you get correct. gCS it's mapped across both
emilio: gCS is different because knows writing mode. Issue is
specified style. This would be a case where there is no
answer
TabAtkins: If overflow 2 value is logical and margin is physical
it's congruent
emilio: When you spec overflow it maps to 4 properties. Overflow
shorthand can take different prop
florian: Shorthand to longhand is parse time, but need to parse on
computed value
TabAtkins: Way we're talking is it's parse time. Overflow 2 value
expands to logical long hands.
emilio: But only when in 2 value
TabAtkins: When in 1 doesn't matter
emilio: Does matter because then you need to return something for
physical for compat
TabAtkins: Same problem as margin. Set margin-start and margin below
it blows away margin-start
emilio: It's about setting, not getting.
emilio: I filed a bunch of issues about serialization not round
tripping. I'm pretty sure a shorthand that expands to
multiple prop is a new problem
dbaron: Example of something where behavior now isn't specified: If
we assume that we haven't intro logical. If stylesheet says
overflow-x:visible and overflow-y:visible if you call
getPropertyValue on overflow you get visible
dbaron: If you have overflow-x:visible and overflow-y:visible and
overflow-block:visible and overflow-start:visible what do
you get?
<emilio> dbaron++
dbaron: Point isn't what answers are it's that answers aren't
obvious in spec now
TabAtkins: So it's legacy behavior running into this. I missed that.
dbaron: I don't think it's legacy. I don't know any impl that has
impl both logical and physical shorthands.
TabAtkins: Blink has logical of block
dbaron: Longhands, but shorthands aren't mapped. I think that's
because there's so many spec issues in OM
emilio: Have logical long hands and shorthands, but they only map to
logical long hands
TabAtkins: In cases right now where single property has both logical
and physical underneath it only maps...I think we wanted
the logical longhand to be ignored from shorthand after
TabAtkins: While there are legacy issues with overflow in
particular, the issue in general applies to all of our
logical and physical properties.
TabAtkins: I completely agree let's define that.
florian: majidvp experiment may provide feedback
astearns: Thanks everyone for calling in, we'll talk next week
Received on Thursday, 15 November 2018 00:52:21 UTC