Cascading Style Sheets (CSS) Working Group Teleconference -- 14 Nov 2018

<scribe> ScribeNick: dael

astearns: As we wait for people to join the call we can see if anyone that normally attends will not be able to next week

<florian> ok for next week

astearns: is TabAtkins or chrishtr on yet?

<rego> regrets

astearns: Lacking those we can skip filter effects unless smfr you want to do anything without them?

smfr: We need them here

astearns: Let's get started. We'll skip the first 2 items until we have TabAtkins or chrishtr on
... Is there anybody that would like changes/additions to agenda?

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 then :matches. We have :not and hte opposite is :matches. It being a clear pairing would be useful, especially in contrast with :where(). Also to make it shorter.
... I filed this as a sep issue. We didn't conclude on that tangential discussion. Seems excitement in issue.
... We do have Safari shipping :matches() If not that this would be obvious. But there is that. What does WG think?

leaverou: Given it's only Safari there's no web compat. No body 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

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
... Given it's not in other impl and we don't have web compat clamor to impl matches that seems sensible path

astearns: Other concerns?

<chrishtr> Tab and I are here, consider backdrop-filter next?

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

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.

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
... 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

<fantasai> fantasai^: Using :is pairs it more closely with :not, which has the same specificity behavior, in contrast with :where

astearns: Not hearing obj against rename. I propose: Rename :matches() to :is() and deprecate :matches() in Safari and anywhere else using it

RESOLUTION: 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?

Backdrop filters should not use BackgroundImage

github: https://github.com/w3c/fxtf-drafts/issues/53

chrishtr: We talked at TPAC. Advantages of perf and impl simplicity raised
... Also good b/c consistant with things like mized blend mode. Obj was mixed blend mode doesn't respect isolation. Turns out that was typo in example
... Reasons we should have BackdropFilter in the isolated group are performance, ease of impl, consistancy with other modes
... Since TPAC Mason Freed (?) 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 Mixed 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 intence. The effect designers haven't tried they can't get. We need to give deisgners 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 technicla issue if allowed inside various filters and stacking context.
... If entire content is blurred, in a blur filter container and blur backdropfilter does it have 1 or 2 blurs?
... Hard quesiton tot answer if you can do arbitrary blending with whatever is behind you. If it's stacking context based it's much simplier

smfr: Agree there are issues to be resolved if element with backgroundfilter has other effects.
... If there aren't anything behind the elemtns that's no ambig 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
... It's hard and expensive which we knoew, but you get a nice graphic property. I think it supplies more use case.
... 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
... You glossed over difficulty of resolvign double filter. Example: container with blur. 2 pieces of content, an element and a backdrop blur that's on top of first
... 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
... Even if you say we do it b/c how platform does, I don't know how your platform would handle this case.
... 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 backdropfilter. It's different the mixed blend mode and different to SVG filters. I think in blurring we should clarify with test cases.
... If saying element behind has blur you blur and then apply backgroundfilter

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 backgroudfilter blur?

smfr: If blur is on a container of the backdrop...[thinks]

chrishtr: Have to drop content underneath, apply blur, backdrop filter, draw under, and blur it all again.
... It can be done, but it's quite strange. Also a big perf 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 backdropfilters. Run time will be exponential

<dbaron> I think in some cases (e.g., backgrdrop 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

astearns: Given that you have said the use case for not isolating can be achieved by changing where things are in DOM, that perf cliff is around anyway as far as I understand. it just depends on arranging

TabAtkins: Under our pref 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 expoential with backdropfilter. Each is a stacking context so only goes up to containing thing.
... General concern about introducing something with large, poss 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 prob enough on this issue.

Publish FPWD [filter-effects-2]

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 obj to L1

astearns: L1 is a WD?

chrisl: 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

github: none

astearns: Let me see. krit can be committed but others can work

chrishtr: Yes, point was he's still involved

<chris> +1 to new WD of L1

astearns: Editorship aside; krit is still in. I think we can resolve on a new WD of L1
... Obj to publish a new WD of filter-effects L1?

RESOLUTION: 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

decide on :blank

github: https://github.com/w3c/csswg-drafts/issues/1967

astearns: Discussed this a number of times
... Incl deferring from last week
... 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?
... Great.

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.
... We let UAs or Authors match case insensitive for UA stylesheet. Type attribute requires this.
... ol uses type in way that requires case sensitivity
... 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.
... 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 obj 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 lto more complicated and this is only use case

TabAtkins: I like s as the flag. Insensitive = i, Sensistive=s

<florian> +1 to "s"

fantasai: Agreed

astearns: Obj to adding a Sensistive 's' flag?

RESOLUTION: Add a Sensitive 's' flag

[css-shadow-parts] confirm browser support

<chris> I am too, especially as shadow parts should get published tomorrow

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.

: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.
... 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?
... 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 woth increasing
... 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

<bradk> :has(:focus|:target|:focus-visible|:valid|:invalid)

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 stull

<fantasai> bradk++

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

<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.

emilio: Slight difference between within selectors and has. within work on flat tree and can cross shadow bounderies. Worth considering.

TabAtkins: Forgot about that. That is interesting

<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

astearns: All this will go into issue. Sounds like we should continue there and look at figuring out if this goes into selectors 5.

'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?

<astearns> 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.

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.
... We already have a number of proerties 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 intereaction 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 corrent. gCS it's mapped across both

emilio: gCS is different b/c 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 phsyical it's congruint

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. Overfloew 2 value expands to logicial 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

<dbaron> I guess you can't hear me?

TabAtkins: Same problem as margin. Set margin-start and margin below it blows away margin-start

emilio: It's about setting, not getting.
... 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 spec: If we assume that we haven't intro logical. If stylesheet says overflow-x:visitible and overflow-y:visible if you call getPropertyValue on overflow you get visible
... If you have overflow-x:visitible and overflow-y:visible overflow-block:visitible 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 logicila and physical shorthands.

TabAtkins: Blink has logical of block

dbaron: Longahnds, but shorthands aren't mapped. I think that's b/c 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
... While there are legacy issues with overflow in particular, the issue in general applies to all of our logical and physical properties.
... I completely agree let's define that

florian: majidvp experiment may provide feedback

end

astearns: Thanks everyone for calling in, we'll talk next week

<astearns> trackbot, end meeting

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

14 Nov 2018

Attendees

Contents