– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

astearns: We'll wait a few minutes for a few more people to join

astearns: Hopefully we'll get more people, but still seems light

astearns: Since it's 4 after we should start. We'll see what we can get to with who is on the call

astearns: Announcement- We are going to have a physical TPAC with hybrid meetings

astearns: W3C management made the decision today they are going to hold the physical meeting. Working with A/V contractors for better cameras and mics for the event and to get good ventalation

astearns: Agenda-wise we'll skip item 4

<chrishtr> (via phone)

astearns: Got a request to move item 6, but I don't see Chris yet. We'll move up to #3 unless someone else can take

<chrishtr> vlad: go for it

astearns: Okay, let's put it as item 3

astearns: Other changes?

[css-contain-3] container :/ size

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

miriam: Since last week the spec is now up to date with current state of all the syntax changes

miriam: Only thing missing from ED is CSSOM resolutions. All syntax is up to date which should help with this convo

miriam: Sebastian pointed out in thread currently it allows the shorthand syntax for container which takes name and type...currently both are optional meaning it could be empty as well as original issue where if only a type have to start with a \

miriam: Proposal here is we could require a container name in the shorthand

miriam: since we are right now container type of style is default on every element and heavily encourage names. If you just need a type you can use the longhand

miriam: That's the prop. Open for questions

astearns: If I recall correctly have plenty of places where shorthands cannot express every possible value longhands can do

miriam: And you could express it, but have to explicitly use 'none' in name of syntax

astearns: Prop: Require the container name in the shorthand syntax

miriam: Right

astearns: Any concerns?

astearns: Obj?

RESOLUTION: Require the container name in the shorthand syntax

[css-content] Implementing content:none on elements is not web-compatible

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

dholbert: Basically we arrived at a point where wondering if content:none and normal should be 2 alues as computed style or if it should be alias

dholbert: Seems everyone impl as 2 values. I think that's new information

dholbert: I think we want to stick with that unless reason to change

dholbert: Some subtilty around how none resolves to normal and browsers disagree a bit but I think it's mostly known bugs.

dholbert: I think this issue is no change, but not 100% sure. oriol has done more investigation and left useful comments. Curious his thoughts

oriol: The thing is that in Blink while content:noen and normal are diff computed values you cannot observe it from webpages. One resolves to the other. Possible this could change. When I impl none I didn't want to risk compat but I didn't try.

oriol: In WK there's a recent change from Jan where if set content:none gCS provices none. Otherside get normal. So get diff in WK and they didn't have to revert so seems it's web compat

oriol: I think FF impl and that's web exposed. So maybe can consider different and say resolve to themselves

florian: I think historically the 2 main contexts were regular elements where content:none did nothing and before and after pseudo where "normal" was empty. marker forces difference where normal isn't empty but none is.

florian: From there I think should try for as distinct as we can. if we have compat issues we can do to the extent required but should keep separate by default

astearns: dholbert you suggested close no change?

dholbert: I had forgotten what oriol mentioned. I tend to think we should wait to see how the WK change survives. If they can keep as distinct in gCS that's the simpliest and I'm sure easy change for Gecko and Blink

dholbert: Potentially resolve in favor of that but might be premature since WK has recently shipped so I don't know how much exposure it has got

<florian> [seems reasonable to me]

astearns: Make no resolution and leave issue open for now?

dholbert: Yeah. Might re-agenda+ for another question. i think original request to make them compute to same I think have decided we don't need to. now question of if we can keep them distinct

dholbert: I can add a summary on the issue

astearns: Could resolve we're not going to have them compute to each other

dholbert: Happy on that since it matches existing impl

astearns: Prop: none does not compute to normal

astearns: Will leave issue open with summary from dholbert on what we need to see with time

astearns: Obj?

RESOLUTION: none does not compute to normal

[css-images-4][css-overflow-3] How do object-overflow and object-view-box interact with overflow and overflow-clip-margin?

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

khushal: supporting css overflow and overflow clip

khushal: all replaced elements clip to content box by default. each except svg don't support overflow. When overflow is on svg it diverts

khushal: svg clips to content box and we don't support properties that make it scrollable

khushal: discussion on issue toward supporting overflow for all replaced elements sim to SVG. All values supported except those that make it scrollable

khushal: Ways in clipping diverges instead of doing the behavior in engine retail with UI css. Because it's in UI CSS devs can override

khushal: Want to mention that we brought up this question with overflow for replaced elements and talked about adding object-overflow to permit

khushal: In trying ti explain interaction with overflow we realized it was easier to do similar so we can remove this property from the spec

smfr: Sounds like in prop that you're allowing author to set overflow:visible on replaced element. Is that true?

khushal: If a website had overflow:visible today and defaulted to clip, it would now apply and cause visible

smfr: Seems like could be compat issue

khushal: Did come up that it might break backwards compat. Applying this prop on existing page wouldn't have worked and does now. Could try and get use counter for how often it's used to confirm compat isk is minimal

smfr: 2nd question is UA applys overflow:hidden. Does that allow scripts to progmattically scroll?

khushal: that's a way replaced have behaved differently. Script won't be able to

smfr: Sound UA stylesheet use overflow:clip?

khushal: Yes, you're right

smfr: Thought I saw issue on iframes. IS this proposed for that?

khushal: Another issue about which elements to limit this. Security reasons for iFrames so could make it !important so devs can't override for something like iframe

smfr: When a replaced element has overflow b/c overflow:visible, ink or layout?

khushal: ink overflow

smfr: Different to overflow on normal element, irght?

khushal: Right. Had discussed for object overflow that overflow for replaced should be considered ink

smfr: I think b/c list of issues I'm not a big fan, but want to hear others

florian: I overlap with some of smfr. You said all values except scroll. but all of overflow other than visible and clip support scrolling

<iank_> is it enough to support just overflow:clip & overflow:visible ?

florian: You talked about UA using overflow:clip, but it said in issue if author did overflow:scroll it was like hidden but hidden is scrollable.

<smfr> what about overflow-x & overflow-y?

khushal: It should say clip. Anything that defines scroll maps to clip for replaced elements

astearns: And for values of overflow that are not clip or visible do we want them to work and make a scrollable thing or should they all function as overflow:clip

khushal: later. All overflow:clip for replaced elements

astearns: So they only get clip and visible

khushal: Right. Either clipped or visible

astearns: q on IRC about overflow-x and -y. If we set -x are things visible in -y?

khushal: I think it's reasonable for overflow clip and visible to be different in x or y direction

khushal: I'm interp if you set overflow-x:clip and -y:visible it will clip in x and not y

<iank_> I think part of the question is if you do overflow-y: scroll for example

florian: Yeah, Id on't see why different for this

smfr: Yeah, sounds okay

astearns: Other questions or concerns?

iank_: I think part or a question that needs to be answers if you set overflow-y:scroll what happens

iank_: There's various fixup today

florian: I guess either you first fixup the other dimension to be a scrolling value and then they both become clip or you coerce scrolling to slip immediately and other remains visible

chrishtr: 3rd alternative could be ignore values other than visible and clip. Can set but don't do anything. Compute to visible

chrishtr: May be less confusing than apply some behavior but not all. It would clip but not scroll and might not know why

astearns: Use counter suggested for overfow:isible. If we want that need a use counter for all the other values on replaced elements

chrishtr: Then alternative is we could go with new css property to avoid the concerns. Does seem behaviors are similar to svg

iank_: chrishtr if I understand correct and we just do visible and clip are there compat concerns since clip hasn't been out long

chrishtr: Good point. coerce hidden and scroll to visible then it's only sites with overflow clip

smfr: Isn't compat issue overflow:visible?

vmpstr: Right, it's the other side

<iank_> my bad sorry.

smfr: And object:fit would leak pixels

khushal: I think it's something like object:position that would leak

smfr: a/r resize version of object:fit doesn't that cause bits of image to leak and if it's overflow:visible it adds ink overflow

khushal: right. If dev used overflow:visible and object-fit:cover they would get slipping now but overflow visible would start after this

florian: Back to visible in 1d and scroll in the other...I suspect doesn't matter for use case b/c you can get one behavior so for impl PoV seems easier to add conflict resolution as is. Visible in 1 and scroll in other leads to visible dimension hidden and now both behave as clip

florian: Suggest to me we don't need to change style computation pass

khushal: 2 issues. 1 how to deal with overflow in x and y direction being different. If 1 d says visisble and other scroll we coerce to scroll and then clip

khushal: second is if it's set to visible in both directions where previously ignored and now visible. Is there a way to check or is thisa deal breaker

florian: Need use counter. If it's a lot it's a deal breaker but if it's rare maybe not a problem

smfr: Do we know if reset stylesheets set overflow:visible

<Zakim> fantasai, you wanted to bring up Tab's point about content-edge vs padding-edge

iank_: I don't think it's common. Might be wrong

fantasai: I want to bring up opint from TabAtkins in thread. Overflow as a property currently clips to padding edge. Type of clipping we're looking at is content box. Replaced elements are special magic or do we need 2 properties?

<fantasai> https://github.com/w3c/csswg-drafts/issues/7188

fantasai: oriol mentioned 7188 with a use case for clipping replaced elements to padding box. Haven't looked in detail but woth considering before we decide to merge to 1 prop

<heycam> wonder if it would be difficult to make the use counter check for overflow:visible only if there's ink overflow

khushal: Suggestion on issue for changing ref box is UI CSS rule. The discussion on issue was toward if start allowing overflow on replaced elements makes sense for overflow to work as well. Idea was default behavior is done with existing properties and devs can change

fantasai: Okay

<florian> that makes sense to me

astearns: [reads IRC from heycam]

astearns: I think use counter is of overflow:visible is set on replaced elements at all. if it is can eval us to see if introducting ink overflow is going to be unacceptable change

heycam: Just looking to see if can skip manual step to check influence

astearns: Before we collect use counter, say the use counter gives it as very rare. Would anyone continue to have a problem with this change? Is it worth the use counter?

smfr: Need use counter data b/c would be compat. If use counter data is okay I'm okay with it

astearns: use counter seems like the next step. Given the details about various values and which replaced elements this impacts and overflow-x and -y and writing all that down. Once we have use counter data we can come back

chrishtr: So accept pending use counter?

astearns: Resolution is collect data and wait to resolve until it's anayzed

fantasai: With a bias toward accepting if use counter says it's okay

chrishtr: I think reasonable in my opinion to accept change and if use counter says otherwise we revert

plinss: Quick point on use counter data. I think if use counter shows a lot of usage it's easy to say no. If use counter shows little usage that doesn't mean it's clear Could be a lot of data behind something like corporate firewalls. If use counter is extremely low fine, but if use count is marginal might be breaking more than we think

astearns: As far as accept change for now and revert I do like having spect ext as opposed to a summary

chrishtr: I would point out failure is showing more ink overflow which is not that bad

astearns: But could obscure content. Making things unreadbale that used to be readable is something we have to avoid

fantasai: Example from smfr about cover image that is visible outside of img element suddenly could be significant data loss. If we do find singificant use. Currently doesn't have effect but if someone used overly-general selectorsl could have effect

florian: I think use counters are in engine so could get behind corporate firewalls, but wouldn't get offweb like epub.

iank_: not necessarily. Depends on if org has opted into metrics collection. Orgs typically do opt out

iank_: other point is we do have some usecounter blindness. I don't think will be case for this. Corps tend to use frameworks so if we see something on public likely to see it in the blindspot as well. Fair bit of correlation for these rendering changes

<fantasai> +1 to iank, unlikely to find this problem on intranets if open web doesn't show the problem

smfr: I think might be first time we allow contents to overlap border. Makes me wonder if we spec the paint order

fantasai: Same as other elements

smfr: So paint on top of borders?

khushal: Was going to add sg allows overflow today and I think they draw on top of border

smfr: Okay

iank_: So replaced elements paint in content phase?

astearns: We have spec a content phase in painting?

<fantasai> CSS2 appendix E

khushal: Another question - earlier resolved having new behavior thought object overflow which is new prop where if set to visible only contents of replaced element can overflow.

<fantasai> https://www.w3.org/TR/2011/REC-CSS2-20110607/zindex.html#q23.0

<fantasai> The painting order of border vs replaced content is already defined

khushal: If we do see use counter usage is high enough that change is risky, would it be good to continue using object overflow and come back to group on how to handle if visible is defined?

astearns: Makes sense to me. If what discussed today dones't work we figure out how object overflow would work as a sep property for this use case

khushal: Issue was if object-overflow as defined in spec exists how does overflow interact with replaced and my take away is it continues as is. We can come back for more concrete resolution

astearns: So adding the path of using overflow on replaced elements in a draft

fantasai: Add and mark as tentative pending data with a link to the issue

astearns: Remove object overflow or put an issue on that?

fantasai: I would go with remove from spec and mentioning in issue that if we can't go in direction we're trying we may reconsider

astearns: Obj to Add this path forward to the spec with a note linking back to this issue

RESOLUTION: Add this path forward to the spec with a note linking back to this issue

[css-text] Syntax for percentage-of-width-of-space for 'word-spacing'

[css-ui] Should the cursor property support image-set()?

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

florian: Has always supported url production to point to image

florian: Since css ui 3 spec says it's allowed to support image production to do image sets, gradients, etc

florian: It's as a may b/c as of time for css ui 3 no one did it

florian: Since then we have 1 shipping and 1 experimental of more than urls but supporting image-set function as long as image-set only contains links to urls.

florian: one poss is we keep spec as is. Other is we explicitly call out now that there's 2 impl is you can do url and this version and may the rest. 3rd is switch entire spec to using image production and encourage browsers to fill in what's missing

astearns: Opinions?

florian: I'm inclined to spec what is impl. We were refaining b/c no one had done it. Still not all impl but since we have more spec that would be nice. Can't just use imace-set production b/c no one does gradients.

florian: Since we have multiple implementations we should spec it

astearns: I think fine to spec what's impl. I assume there's no tests in wpt

florian: I haven't checked. As a spec writer Id idn't create

iank_: This just coveres image-set. Also the image function. Was that impl?

florian: Don't think so. Only seen image-set with URLs. spec allows more but I don't think anyone has impl

astearns: Prop: Add a URL param-specific version of image-set function to the cursor property

astearns: Obj?

RESOLUTION: Add a URL parameter-specific version of image-set function to the cursor property

astearns: Please do add tests

florian: Sure

[css-cascade] Should 'revert' really treat animation origin as author origin?

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

<fantasai> https://github.com/w3c/csswg-drafts/issues/7083#issuecomment-1083631261

astearns: Suggested resolution at the end from TabAtkins

fantasai: We suggest for revert-layer no change. There are use cases and how set is most natural way. This issues is around revert. We suggest close no change b/c this is spec and impl. If people thik treat same as revert-layer that is reasonable behavior; main problem is it's a change

astearns: Prop: Close no change

<miriam> +1 close no change

fantasai: Yeah. unless someone feels significantly better to behave same as revert-layer

oriol: Initially I filed this b/c impl that way had some performance cost in WK and in Blink there was a comment saying it disabled optimization. In discussion of issue turned out changing wouldn't improve perf in Blink b/c disabled due to em units.

oriol: So I think changing would not improve perf so we can close no change

astearns: dbaron you commented. Is this okay?

<dbaron> no objections

astearns: objections to Close no change

RESOLUTION: Close no change

[css-logical][css-cascade] revert/revert-layer with logical properties

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

fantasai: Prop: Spec what's implemented

astearns: Is that the whole things?

oriol: The thing is what happens if you have mix of logicial and physical and set one to revert-layer do you roll back to same ignoring pairing property?

oriol: I looked at impl and all agree that first they run the escape and when have final writing mode turn them phsyical ones. Logical and physical properties convert into same mapping. Once resolved you revert into resolved property

oriol: If you have margin-left and revert-layer and previously you set margin-start you revert to that.

oriol: Prop is revert after resolving the properties

fantasai: Makes sense to user. revert is rolling back value on this property to what would have been if author stylesheet didn't exist and this has that effect

astearns: Thanks oriol

astearns: Obj to specify what browsers currently do

RESOLUTION: specify what browsers currently do

end

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

<florian> Hmmm. css-image-4 defines image-set() as "no change from [css3-images]." But level 3 doesn't define it…

<florian> ha. css-images-4 does define image-set(), in the ED, but not on the TR version, which is 5 years out of date

<florian> fantasai, TabAtkins, leaverou do you think you could do something about ^ in the not-too-distant future?