Cascading Style Sheets (CSS) Working Group Teleconference -- 11 Mar 2020

<scribe> ScribeNick: dael

Rossen_: We'll get going in a couple minutes
... We're giving a couple minutes for people to connect and then we'll get going
... Let's get started with the usual quick agenda overview for additions
... Before we do the agenda I have one item
... We did cancel the April meeting in Cork Ireland which was to be hosted by Apple due to the COVID-19 outbreak.
... It was decided to be a virtual F2F.

<Rossen_> https://github.com/w3ctag/meetings/tree/gh-pages/2020/05-distributed

Rossen_: We will work on details for exactly how to do this and format. If you have idea feel free to bring it to mailing list or ^
... We don't have good coverage for East Coast US but we can add that if there are members. It will be a highly distributed vitual F2F and we'll make sure there's chairing capabilities. We don't have exact details to talk format yet, but I did want to give the heads up

[css-align][css-grid] Do grid items that have "no baseline set" participate in baseline alignment?

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

Rossen_: Mats brought this and lajava added to agenda

TabAtkins: I'm not ready here, I looked into it and realized it wasn't easy so I haven't done enough to dig in and get the right answer. I'll try and take care of it next week

<fantasai_> I thought we assumed that items can baseline-align if they are orthogonal / have no baseline ?

<fantasai_> https://github.com/w3c/csswg-drafts/issues/721#issuecomment-264272653

Rossen_: If this encourages progress I'm fine with that.

fantasai: I saw we had discussions about this and had resolved. There was about how do orthogonal grid items align or not when placed in grid. I understand there's wording to clarify but I thought we discussed. Not sure how this is different

TabAtkins: I had same feeling but couldn't find wording in spec that defines it well. We didn't write it down

fantasai: We need to add to spec but we've had WG discussion

Rossen_: I'm happy to move on. Let's see if we can make progress and close with previous resolutions or bring it back next week

Add a note about the reasoning to forbid `insertRule(@import)`, or remove the condition?

github: https://github.com/WICG/construct-stylesheets/issues/119#issuecomment-594873154

TabAtkins: emilio is best to take it. I'm fine with it but I have an answer I want and I'm not sure what others feel

chrishtr: WE want to discuss if it throws an exception with an illegal rule. Not about allowing imports

TabAtkins: Yeah. It's if we silently ignore or if we throw an error when you try and create a sheet, replace text, or insert an import rule directly

Rossen_: Is there a proposed part forward with exception or silent?

TabAtkins: Not a decision yet. I'm for throwing b/c more consistent with CSS modules. This makes it easier to fix later. If we end up allowing imports it's less likely authors depend on it if the module is completely broken. For consistency and friendly to futire decisions I think we should throw entirely for now if you try and include an import

emilio: I disagree. I don't think it's different then syntax that doesn't work and eventually works. We should be consistent about syntax we want to eventually support. If we add @import supports and silently ignore but if we have syntactically valid we throw

Rossen_: Sounds like we have consensus around throwing

emilio: I'm arguing to not throw

chrishtr: I agree with emilio not throwing is better. Can't we change css modules to not throw?

TabAtkins: We can. It would mean we're slightly more likely to pick up a dependency if we don't decide soon
... I agree silent ignore is better overall. Consistency and reason css modules does it is compelling to me.

Rossen_: There were lengthy discussions on css modules and how they should work. Part of the recent tag review about event loop. Chasing down the thread between those that were there...there were a lot of discussions on this and pointers between groups saying css should define if we throw and us not. Lots of what's on WICG assumes we're throwing. It would be good to reconcile these discussions
... If we have strong proposal to not throw that's fine but I think we will need to reopen the larger discussion
... I don't think this will be end of conversations if we change. But do we have consensus on not throwing

TabAtkins: If we can take it back to css modules I'm fine with not throwing

Rossen_: So update this issue to say this will be consistent with css modules?

chrishtr: [missed] not to throw

Rossen_: If modules define not it's fine

emilio: Modules defines just replacing. If modules wants to throw they might need to do a general thing to throw. I still would argue that's not great

chrishtr: Suggest we resolve not to throw and someone takes and action to check this is okay with modules. If it's not okay we come back tot he group

emilio: Sounds great

chrishtr: We should also resolve insert rule throws syntax error

emilio: Can say @import does not parse in constr/ stylesheets and that gives implicit syntax error

Rossen_: Prop: Do not parse @import which will cause a syntax error and also not throw
... Objections?

<dbaron> Not supporting @import seems like it's becoming progressively more and more complicated...

emilio: @import doesn't parse in constructable stylesheets and as a result throw syntax errors

TabAtkins: Agree that's right wording for it

RESOLUTION: @import doesn't parse in constructable stylesheets and as a result throw syntax errors

Rossen_: dbaron do you want to add to conversation?

dbaron: Worried we're piling on more stuff to not support @import. Seems it's getting progressively more complex

emilio: I don't know how throwing or not makes this more complicated.

dbaron: More complicated may not be right, but there's more decisions about it because it's different

emilio: Our const. style sheets we plan to show a warning if you stash an @import
... Doesn't seem situation is worse by not throwing. In fact I think it's better

dbaron: I would be pessimistic about ever being able to change this. If we don't support @import we'll be stuck with that

emilio: That's a different discssion though? At least in replacing you have to define a way to [missed]

<TabAtkins> Phew, I simply can't hear Emilio due to the background conversation.

emilio: I was saying we need to define an error handling for replacing. Doesn't seem to me...we need to define error handling either way. I see dbaron point about not supporting @import but it's a different convo. For replacing you need error handling and I think this is most consistent

Rossen_: dbaron Do you want to reconsider the resolution? Back to the issue and discuss there?

TabAtkins: Alternative is we go resolve the issue for css modules about if imports are shared or independent in module graph. We're trying to avoid b/c we couldn't decide on that question and didn't want to lock in api

emilio: And about sharing cross document which we're not doing

<dbaron> I think we'd be much better off if we just resolved the CSS modules thing one way or the other.

Rossen_: Given this is in WICG still by no means is this final final. If you need more time to work with module folks that would be good to do so and see if we can help close the issue for the design and the @import decisions will be taken care of here by time modules are complete

<dbaron> I suspect that supporting @import either way would be less bad than not supporting @import.

chrishtr: Need decision on throwing because it impacts something being implemented. If we can preserve resolution of exception that would be good

Rossen_: We did record a resolution

chrishtr: Checking it still holds

Rossen_: Yes. Trying to see if dbaron wants to object and keep working on this or keep as is as a stop gap until modules is in better shape. dbaron can you comment on your preference to move forward?

dbaron: If you give me enough opportunities to object at some point I will

Rossen_: You've got an opportunity to object right now

dbaron: Having all this depend on one decision in css modules is weird. But I won't object

Rossen_: Then previous resolution holds. I'd encourage everyone in this to re-engage with modules and see if we can make progress

Feature introduction, subtree-visibility CSS property

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

chrishtr: At TPAC 2019 I presented a dom attribute with purpose to allow browser to avoid rendering of stuff not drawn to screen. Based on feeback there and from other vendors since proposal has changed a lot. Semantics are about same but API shape changes to improve dev semantics and now fits well within css It's a css property called subtree-visibility. Semantics are about same as visibility:hidden. One difference is when content is skipped, aka not visible
... element is contain:size. This property is meant to be paired with contain:intrinisic-size so when content is visible you can have placeholder size
... 3 properties. Invisible controlled by the browser so when content is on screen or focused to it's visible or not skipped. If it's not visible on screen to user and not part of a focus or selection it's auto marked as skipped so browser is free to skip style layout. Not required but allowed
... Can view this as another addition to contain spec where it's a way to augmenet contain so it's easier for browser to optimize work off screen
... hidden is dev controlled and meant for vitual scrollers and single page app
... Would like feedback. Is naming good? I think it's better b/c clear it's a hint. Semenatics are about boxes and block trees.
... We've impl and you can try it on demos by enabling it in chromium

Rossen_: Thank you chrishtr. I'd encourage people to engage on the issue and refresh yourselves on the property and how it fits. If/When needed we'll bring back to WG call to make decisions

[css-transforms-2] Is it necessary to serialize all 3 components of translate given the 3rd component is 0px

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

Rossen_: TabAtkins you brought this back?

<chrishtr> (had to leave early, conflicting meeting in second half-hour)

TabAtkins: Yes. Originally spec for individual transform properties distinguished between author writing 2d and 3d transform
... FF and maybe others objected b/c having z component of 0 is same as 2d translate.
... I objected at time b/c Chrome and WK had quirk where we used 3d transform presense as a hint to move to compositing layer. We were going to try and remove it which is why we accepted FF proposal
... Turns out we can't remove. We see a lot of extra paints from things not moving to compositing layer. B/c this is unacceptable amount of lost performance we're keeping the hack for now and may need forever.
... Want to revert spec to keep track of if something was 2d or 3d so you can round trip.

<flackr> I think interpolations are also different between 2d and 3d

emilio: This quirk is transform specific. Don't get why you need more

TabAtkins: All 3d transforms do it right now

emilio: I think that translate could be changed. I don't think. people are doing translate (0,0,0)

TabAtkins: I doubt they are. But if this is being kept around I'd like to be consistent across platform if we keep 2d and 3d

emilio: But transform is different b/c people use transform set

TabAtkins: Impacts how we serialize. Matrix or Matrix 3d for example

emilio: Seems wrong

dbaron: Does 2d or 3d influence animation?

TabAtkins: Only with rest of the quirk we talked about

flackr: I think this effects decomposition when intrep between matrix

AmeliaBR: Animating between 2 2d transformations then your animation is entirely 2d. 2d to 3d it gets upgraded so animation becomes 3d

flackr: If there were a case where 3d matrix becomes 2d at 0 it could cause different interp. But only when fallback to matrix interp

<TabAtkins> I was wrong - it doesn't affect whether we serialize as matrix() or matrix3d()

emilio: And doesn't apply to individual transform properties right

flackr: Right, I don't think have to fall back to individual transform prop

smfr: WK hasn't imple individual and it would be nice as a break to get away from the hack.

emilio: TabAtkins I tested and it's not what you were saying

TabAtkins: Yep, I jsut tested and found the same
... smfr I agree I would love if authors use will-change but it won't effect if we can remove translate-z hack. It means have to be inconcsistent in typedOM b/c right now they track 2d or 3d and they'll want to serialize transformed values.
... I'm not happiest with hack being limited to just 3d transform functions. I don't like inconsistent if you turn transform into individual transform. Doesn't feel right to me. Even if we don't like hack existing I don't like inconsistency in platform

emilio: Will be inconsistent one way or the other

TabAtkins: If something is promoted to compositing is inconssitent. But the more obvious to authors as to if it's in typedOM I'd like to be consistent

emilio: Still don't think you should get is3d transform

TabAtkins: We want to change if you set with 3 we serialize to 3

AmeliaBR: And that's is3d for typed OM, right?

TabAtkins: Not sure what you're asking about

AmeliaBR: Clarify what emilio thinks is inconsistent. I understand prop is we consistenly keep track of if it's 2d or 3d

emilio: Computed serializes 2d for translateZ(0)

TabAtkins: Yeah we've already got inconsistency in there. That's annoying.
... I'm fine accepting it's jsut transform functions that preserve 3d. And not even computed value. This is terrible. Everything is terrible

emilio: Agree

TabAtkins: I'm fine no change.

Rossen_: Prop: Close no change
... And then hopefully someone will make TabAtkins feel better

emilio: I can say I'm sad too

Rossen_: We all share the pain

florian: There's precedent for writing this is sad within spec

RESOLUTION: No change

[multiple] Serialization of rules

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

TabAtkins: Merged a PR to spec how to serialize @property. Decided to serialize in one line.
... Fine but wanted consistent. I looked arounda nd couldn't find one spec on how to serialize rules. But I think we tend to serialize multi line.
... I would like to define this, prob in CSSOM, with descriptors. Then we need to decide if it's on a single line or multi-line with indents

florian: I have vague memory of doing something like this in preso and trying to align to where a line is broken. I vaguely remember compat problems

emilio: style rules seem to be one line

Rossen_: Is prop to allow multi-line but not define how and where you should break?

TabAtkins: No, no. I would like precise spec. We have it for whitespace and we need that level

florian: I support doing this, write something sensible, and then if compat says we can't at least we know where

emilio: I think impl are somewhat consistent so I don't think would be hard. Happy to help

Rossen_: Don't see pushback on multi line

emilio: Biggest is that's not what browsers do

Rossen_: Compat risk?

TabAtkins: If there's compat we should follow that. emilio is right style is one line so we should consistently do that

florian: Seems sad too but okay

Rossen_: Prop: Specify serialization is one line?

TabAtkins: Prop: We define this is CSSOM to match browser compat as much as it exists.
... emilio or I can write it out

Rossen_: Objections?

RESOLUTION: We define this is CSSOM to match browser compat as much as it exists.

[css-pseudo-4] Animations on ::marker?

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

fantasai: We have an allow list for properties on ::marker b/c haven't figured out layout. POinted out animations and transitions not allowed but makes sense they should work. Suggestion is add them to list

Rossen_: Other thoughts?

oriol: Seems reasonable but a note it may be inconsistent since first-letter and -line restrict properties and you can't animate them. It would be inconsistent but could make sense since marker is tree-abiding.
... May be a bit annoying for impl b/c it will bypass filters for which properties apply. SHouldn't be hard to do I guess

<fantasai> s/deviding/tree-abiding/

AmeliaBR: So that's practical impl issue if makes harder to tell which properties can be animated. Should be able to set transition property but only ones where it works are those where allowed. But logically if you can set color you should be able to animate color

dbaron: Note thing with filtering isn't an issue with transitions since they can only go between those that apply

AmeliaBR: Making sure keyframes are properly filtered out so only those that should have an effect do

Rossen_: Hearing some feedback this might be somewhat challenging to impl but from user expectation and behavior I don't hear reasons why it shouldn't be allowed

dbaron: I don't think that' challenging. BUt not w/ animations there's two technical ways to do it and they're distinguishable. You can say animation happens and an animation rule applying the style doesn't apply or you say animation doesn't happen. First I suspect is easier but second is better api

fantasai: Plan to add more properties to ::marker once we have a layout model. Probably want to go with way animation happens b/c then don't need infrastruction in style system. Hopefullya. temp situation

flackr: Also prefer first approach

dbaron: Do have to have infrastruction b/c that they don't apply has implications for computed value. Not sure

emilio: Have a filter but if impl in FF it's a one

Rossen_: Consensus seems to be allow transitions on ::marker and allow animations with them happening and animation rules applying the style

flackr: Animation is applyed, style not observed b/c doesn't take effect

Rossen_: Objections?

RESOLUTION: allow transitions on ::marker and allow animations with animations happening and animation rules applying the style

[css-ui] Auto-disable native appearance when cascaded value has author origin

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

florian: We have appearance property with atuo look native. WHen in native there's a number of properties where if you set to a value it disables native-ness. Example is border-bottom
... 2 things undefined. What's the set of properties that have this effect and on which elements. Other thing, this issue, is how do these properties disable. One is FF which if author sets to any value it disables nativeness. Chrome is the values is set different then UA it disables nativeness. Chrome plans to switch to FF behavior
... Not spec anywhere, but an attempt in HTML and a placeholdder in CSS UI 4. Mostly a heads up from Chrome they are trying this. BUt if people think it's a bad idea it's good to say so before they try

smfr: I think Chrome inherited from WK. WOuld be interested in seeing experiment. If successful WK probably willing to follow

florian: Since appearance are sensistive to compat I'm interested to wait out experiment before changing spec

Rossen_: We're at top of hour. Anyone from Chrome that could have feedback on success now? If not we push back to GH and discuss next week

florian: No experiement yet. Pinging us before hand in case it sounds like a terrible idea. Doesn't sound like it is so we should let them run and report back.

Rossen_: I see.
... Let's end here and then hopefully we'll get data back from Chrome experiementation

end

Rossen_: Thank you. If you've got ideas or constraints about virtual F2F feel free to chime in on the thread. We'll start figuring that out.

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

11 Mar 2020

Attendees

Contents