W3C

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

15 Jan 2020

Attendees

Present
dael, fantasai, rachelandrew, chrishtr, smfr, florian, jensimmons, oriol, dauwhe, cbiesinger, chris, rego, emilio, TabAtkins, antonp, Rossen_, tantek, myles, dbaron, bradk, drousso, bkardell_
Regrets
Chair
SV_MEETING_CHAIR
Scribe
dael

Contents


<scribe> Scribenick: dael

astearns: We'll give people a minute or two to join
... We've got enough people to get going
... Does anybody have any changes for the agenda? There's one we'll postpone that's far down on the list
... Anything other than that?

fantasai: Scheduling? rachelandrew has been asking us for a lot of months to lock down summer dates

astearns: I don't think we can get to it on the call. We're waiting on Google people to confirm dates. Let's make sure we get to it at F2F next week
... F2F is next week, we could use more agenda items. Please add them as soon as you can so people can be prepared at the meeting

[MQ] color-gamut Keywords

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

astearns: chris you commented last

chris: I'm of the opinion this is shipped in 2 browsers so large change cost. If we designed now more generic names would be better but fact is Apple and others have shipped P3-gamut.
... We discussed hyphenation and got consensus on that and I don't want to rename them back. We went to display-P3 and then we'd have to rename and it would become ambig again. TabAtkins has a different opinion that they mean the same. I don't think they do mean the same

TabAtkins: I said they are approx the same. They're close to meaning same. Especially in ref2020 where one has a hyphen and one not is extremely bad. p3 and display-p3 are different words.
... Still of opinion we should be consistent. We shouldn't change color gamut so we should revert color function keywords because else people will ask why different

florian: I would argue mean the same. If you understand MQ to ask if gamut is supported by screen with this approx as large as this color space then it's yes. If screen isn't an exact match it's okay. You're not asking about color space specifically

chris: No one suggests renamining display-P3 to P3?

TabAtkins: I'm possibly in that relm. I would like ref2020 to be consistently hyphenless. P3 and display-P3 sound different. Hyphen diff shoudln't be

florian: I would align P3 to the one used in MQ.

chris: Remember Apple wanted display-P3. When we reverted to what they wanted and what everyone talks about that's the name

TabAtkins: That's why I'm okay with display-P3. A subset of name in color gamut is okay. P3 means approx any of these.

florian: I don't think I would object to different P3. But your question was anyone suggesting we merge and I suggest we do. Won't object to don't

TabAtkins: Revert ref2020 in color to be hyphenless and leave p3/display-p3 alone?

chris: Okay with that....

<fantasai> I would strongly object to having the only difference be the presence of hyphens

florian: Maybe hear from Apple?

smfr: Apple precer to keep

astearns: Prop: Remove Hyphen from rec2020?
... Objections?

RESOLUTION: Remove Hyphen from rec2020 in all context; everything else stays as is

[css-pseudo-4] Original color of highlight pseudo inside ::first-letter/::first-line

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

fantasai: Currently spec if author spec background color and no color we use color of originating element
... With ::first-letter/::first-line it will cause it to change color b/c look at paragraph. Would be weird for spelling or grammar error.
... Do we make it look up ::first-letter/::first-line color or is that difficult?

TabAtkins: While I'm inclined to think it's complicated but heycam thought it was fine so sure. I think it's reasonable

astearns: Other impl feedback?
... Prop?

fantasai: Use the color of the text prior to applying the highlight
... Whatever highlight being applied uses colors from before even if came from pseudo element like ::first-letter/::first-line

astearns: Any other pseudo elements effected?

fantasai: Not sure, possible ::before or ::after
... POint is make it clear if there's a pseudo element changing the color we use that color not the document element

astearns: Objections?

RESOLUTION: Whatever highlight being applied uses colors from before even if came from pseudo element like ::first-letter/::first-line

fantasai: One note is currentColor keyword we'll have to make it resolve to a value for purpose of gCS. Will need to represent multiple colors

florian: Why?

fantasai: If you have a selection...we attach selections to an element not ::first-letter/::first-line. Could change the model

florian: I see

fantasai: That's going to be interesting

florian: Yeah. For ::before/::after it's not a problem, but weird for ::first-letter/::first-line

fantasai: I'll try and spec it out. It will be complicated

tantek: Impact on impl with change?

fantasai: No one impl this right now. Would all have to change

chrishtr: Backwards compat?

fantasai: No one does this. It's difficult to impl I think. That's why I raised it

chrishtr: Good to have things not difficult to impl

fantasai: But good to have good behavior too. I can spec it

TabAtkins: I had same feeling as you but heycam thought it most reasonable to do. Since he doesn't think impl overrides correct behavior I decided to trust him

smfr: Is it to accept heycam proposal?

TabAtkins: Accept fantasai proposal

astearns: heycam was agreeing this is righ behavior to spec. We'll try and spec and get impl experience to say if it's reasonable. We can back out if too complicated to impl

tantek: I was revieing GH and saw fantasai question what to do. I didn't see the proposal.

fantasai: I need to write a proposal. Not worth it if no one wants to do it

tantek: Looks like heycam had a proposal

fantasai: There's two possibilities at a high level and heycam said this one

tantek: That's what we resolved on?

fantasai: Yes

myles: Why hard to impl?

fantasai: Highlight is attached to element in doc not firstline. So you can have a highlight span and have to look up different colors depending on if you're first line even if same element. You have to paint with different colors and have currentColor with presumably multiple colors.
... I don't know how machinery will work; per-element ::selection needs substantial changes to make it work. We'll have to see what happens and how impl shake out

myles: My intuition is this wouldn't be difficult to implement. In MacOS we draw highlight per element so it's just an if for us. iOS is different. I don't think would be hard

fantasai: Okay

florian: Clarification we resolved on high level principle and fantasai you're going to worry about how to do currentColor later.

fantasai: Yep

astearns: Next step if fantasai spec this out. Anyone with enough concern that it's a waste of time for her to work on this?
... THen we'll let resolution stand

[css-pseudo-4] ::selection vs ::inactive-selection

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

fantasai: Started discussing last week, came up with...discussion was why not have a MQ intead of two pseudos. Then we ran out of time.
... Do we want to go in that direction and drop ::inactive-selection from spec and add a MQ to MQ5?

astearns: Use case for inactive MQ outside of selection?

fantasai: Probably. There's some JS methods that allow you to detect that

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

astearns: Main difference is instead of having to fully spec both styling you can do all your selection styling and have an inactive override to might reduce duplication

fantasai: We have to do that anyway b/c selection is when window is inactive. Whatever way we take it needs to apply. 3 ways to do it, 2 are in the issue and 3rd is do in a MQ where you can do inactive anything

AmeliaBR: Selection styles always apply active or not is what we have. DOesn't match browser styles. I like MQ idea and have benefit of being able to do things like pause animations and transitions which is more consistent with request animation frame transitions

smfr: Need to be a little careful with window activation. An iframe without focus is inactive color. It's focus state of document maybe.
... Wondering case about inactive selection with the same document as active selection. There may be scenarios like that

AmeliaBR: Interesting. Then inconsistent with page visibility APIs concept of activeinactive. Useful to have specific examples of which browsers and OS conventions do have those distinguishments between this selection is preserved but not currently active and the cases where that can happen

astearns: I'd want to make sure the MQ had as much of same behavior as page visibility API. Doesn't seem like should be a difference if we can manage it

fantasai: Then it's not same as ::inactive-selection. When you have ::inactive-selection and ::active-selection in the same page we need the pseudo
... Other idea taken up during previous call was a selector on the element that says hey this element is focused so make selection this color. Some word that represents being selectable in an active way. Don't know if it would work

AmeliaBR: That would cover case of text area preserving selection even when text area doesn't have focus. A pseudo class on text area and then selection style with regular selection element?

fantasai: Yeah, I think so. but then...I don't know...need to think about cascading
... That's good points, we should move to another issue. We won't solve now.

astearns: I'm still interested to see if an inactive MQ would be useful, but may be out of scope for this problem
... Let's continue in GH and maybe on agenda for next week

[css-sizing] intrinsic-size lost the thread

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

myles: Can we rename to something that makes more sense?

TabAtkins: If you can think of something, sure.
... Last month we talked about this and asked for any additional use cases beyond the major one that caused this issue and the minor cases we came up with after. Since then no one has commented.
... Suggests it's not important enough to think about over holiday at least

github: none

[css-sizing] intrinsic-size lost the thread

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

TabAtkins: Given there's no additional suggestions our current proposal is revert back to a property with a default size for a contain:size element. Proposed name is content-placeholder-size. Happy to bikeshed. Makes it clear that it's a special case
... Objections or additional ideas on use cases with expanded form of content size please say so.

fantasai: I think if specific to contain it should be prefixed with contain.

TabAtkins: contain-placeholder is fine

myles: Placeholder a term of art for inputs?

fantasai: It's used for placeholder in inputs. I'm hesitant to use the word

TabAtkins: Where is placeholder in css?

<fantasai> ::placeholder and :placeholder-shown

dbaron: pseudo element and pseudo class

TabAtkins: Yeah, forgot about that one

<dbaron> ::placeholder and :placeholder-shown, I think

fantasai: contain-size unless you've got a good word in the middle

astearns: contain-initial-size

TabAtkins: initial or default seems reasonable

fantasai: If it's a flex item stretched it won't size to that size. contain-content-size maybe. Initial may not make sense

<dbaron> (it wasn't minuted, but I did say above that I wasn't aware of https://github.com/w3c/csswg-drafts/issues/4585 until it was mentioned today)

fantasai: I would prefer a word that clarifies in the middle

TabAtkins: contain-size sure

astearns: issues with contain-size?
... Prop: Change the current contain:size to contain-size as its own property

<fantasai> dbaron, you could have posted suggestions into the original issue? But either way if you come up with something to add I'm sure we can reconsider.

chrishtr: it's a param to contain:size
... contain-size is a param to contain:size that indicates non-zero

cbiesinger: Rename intrinsic-size to contain-size

chrishtr: If contain:size is on an eleemnt we look to see if contain-size is set and then set placeholder sizing

TabAtkins: Contain-size is none or lengths

fantasai: contain-intrinsic-size?

astearns: Prop: Add contain-intrinsic-size property with an initial value of 0 that takes a pair of length

cbiesinger: Remain intrinisc-size to contain-intrinisic-size

<cbiesinger> s/remain/rename/

chrishtr: And conditioned on contain:size being present

astearns: Prop: Have a contain-intrinsic-size property

dbaron: I missed the request for examples. I'd like to try and do that next week and get examples in the past

fantasai: Let's say if we do in this direction we'll do this and waiting on dbaron examples

<tantek> is confused trying to follow this and can't offer a specific opinion. :/ examples would help.

florian: We mentioned initial value. For contain-size it's 0 for non-replaces which isn't always 0. Does initial value =0 and adds size or is it auto?

TabAtkins: Initial value of none. If you spec size it'll intercept

florian: Initial size of 0 it replaces?

TabAtkins: Yeah

astearns: TabAtkins can you commit to specing this out so we can have all the details and dbaron examples and see if it fits?

TabAtkins: Yes

fantasai: TabAtkins maybe spec both and we'll delete the one we don't select

astearns: Let's get proposal and examples together and we'll look next week

[css-sizing-3] max-content contribution of replaced only-ar elements might be improvable

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

fantasai: We triaged this last week. Case is we have some box which says I want width max-content
... Something inside it intrinsically sized with an aspect ratio and no size info
... No interop. Chrome is 0x0 as max content. Spec says use 300px width and ratio for height. Resolvable but arbitratry. FF uses initial containing block. That seems useful. We suggest spec FF behavior

astearns: Concerns?
... Objections to Specify Firefox's behavior?

RESOLUTION: Specify Firefox's behavior

[cssom] Table row resolved width and height

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

emilio: Height doens't apply to table rows depending on writing modes. There was interop issue found by jquery folks. A bunch of discussion on the issue.
... Various options. Nice to get an agreement.
... Webkit and Chrome behavior doesn't roundtrip. I propose to return computed value which is what we do for other elements that don't support height. People argued against that

TabAtkins: I'll proxy Alex and say FF is correct and roundtrip should work. Let's roll

astearns: Reading thread. What needs to be done to roundtrip height?

emilio: Using the computed value works. FF does give a resolved value it just roundtrips so not what I proposed.
... Edge used to report auto
... And the computed value
... Computed value of auto FF gets a roundtrip height and Blink doesn't make sense. Edge returned computed value which is consistent with inlines

astearns: Prop: Return the computed value of height for table rows

emilio: When it doesn't apply which is not always. Depends on writing mode
... I think that makes most sense. Alex argued for FF behavior. There are other comments from fremy and oriol saying computed value may not be most useful
... A bunch of use cases for this

fantasai: Seems there are two discussions. One is which property applies and therfore has meaningful value. And which is in height axis of table. Then should prop of block axis return auto or used value.
... Mapping question should be switching based on writing mode of table. In terms of if we return used value or auto I don't have option other than it hsould round trip
... Means block axis on row needs to return. Can't default to auto. Inline axis doesn't matter

emilio: Used to have stronger opinion but I'm happy to keep discussing and figure out best compromise. If people don't have strong opinion

astearns: Leave that intent is to have round trip for block axis and leave it at that until we have actual text?

emilio: Fair

astearns: Concerns with having round trip value for block axis of table rows?
... Let's work in issue

[css-text-decor] Consider adding an `all` value to `text-decoration-skip-ink`

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

myles: Right now when you turn on text-decoration-skip-ink you can use auto which is skip everything except cjk. cjk letters usually lower on line and intersect too much with underline. That was a decision I made many years ago; looked at cjk and it was awful so made it not apply
... Other value was none which is don't skip.
... Now that there's a property to move underline it's reasonable for an author to want to place underline such that it doesn't intersect. Then having ink-skipping on cjk makes sense. Let's add a 3rd value that does it on everything, even cjk. Makes total sense to me

<fantasai> I agree with doing this, would suggest using always rather than all

jensimmons: Makes sense to me to give authors rest of power to do what they want. They should have option to force it on even if default for script is off

florian: Makes sense to me

astearns: fantasai prefers always instead of all? Any other opinion?
... Prop: Add an always value to text-decoration-skip-ink
... Objections?

RESOLUTION: Add an 'always' value to 'text-decoration-skip-ink'

Should mention the posibility to ignore custom cursors that go outside of the viewport

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

florian: Can spec image as cursor. If image is too large browsers expected to shrink
... Recently Chrome and FF fiured out security concern and they wanted to reject instead of shrink. I know they've tried things, reject or crop. I believe what they do is not what spec says. Maybe need to change spec to allow. Maybe experiment points to a right thing.
... I would like people experimenting to report their findings after doing it for a few months

emilio: In FF we fallback to next image or to default. We treat as invalid. You can't shrink b/c you can set a hotpoint and then need to shrink that too. I think Chrome did the same
... I could be wrong on Chrome

astearns: Anyone know who looked at this on Chrome?

chrishtr: Need to follow up

florian: I'd appreciate follow up.

astearns: Let's see if we can get information on Chrome and continue discussion then

<emilio> whoops :-)

end

astearns: I'm told it's florian birthday so happy birthday

everyone: happy birthday

astearns: Safe travels everyone, talk to you then

<florian> thank you all!

<rego> happy birthday florian 🎉

<emilio> chrishtr: I always get confused between you and csharrison :(

<rego> safe travels for everyone if you need anything during your time in Galicia, feel free to ping me 😉

<emilio> florian: happy birthday :-)

<chrishtr> LOL, not a problem. csharrison is Charlie Harrison

Summary of Action Items

Summary of Resolutions

  1. Remove Hyphen from rec2020 in all context; everything else stays as is
  2. Whatever highlight being applied uses colors from before even if came from pseudo element like ::first-letter/::first-line
  3. Specify Firefox's behavior
  4. Add an 'always' value to 'text-decoration-skip-ink'
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/01/15 18:10:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/is a hypen/has a hyphen/
Succeeded: s/ref2020/rec2020/
Succeeded: s/ref/rec/
Succeeded: s/dob/doc/
Succeeded: s/needs substantial/per-element ::selection needs substantial/
Succeeded: s/wouldn't be difficult/wouldn't be difficult to implement/
Succeeded: s/inactive selection/::inactive-selection/
Succeeded: s/??/cbiesinger/
Succeeded: s/intrinsit/intrinsic/
FAILED: s/remain/rename/
Default Present: dael, fantasai, rachelandrew, chrishtr, smfr, florian, jensimmons, oriol, dauwhe, cbiesinger, chris, rego, emilio, TabAtkins, antonp, Rossen_, tantek, myles, dbaron, bradk, drousso, bkardell_
Present: dael fantasai rachelandrew chrishtr smfr florian jensimmons oriol dauwhe cbiesinger chris rego emilio TabAtkins antonp Rossen_ tantek myles dbaron bradk drousso bkardell_
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]