- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 Jan 2020 19:32:45 -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.
=========================================
F2F Agenda
----------
- Any items for the F2F agenda need to be added soon so that people
can review and come prepared.
- The Summer F2F timing will be added to the agenda.
Media Queries
-------------
- RESOLVED: Remove hyphen from rec2020/rec-2020 in all contexts;
everything else (P3/display-P3) stays as is (Issue
#4535: color-gamut Keywords)
CSS Pseudo Elements
-------------------
- RESOLVED: Whatever highlight being applied uses colors from before
even if came from pseudo element like
::first-letter/::first-line (Issue #4625: Original color
of highlight pseudo inside ::first-letter/::first-line)
- Adding an inactive-selection media query wouldn't solve the
original use case for ::inactive-selection/::active-selection
(Issue #4579), though there may still be use cases for the media
query. fantasai will revisit having a selector on the element as
well as the other proposals within github to see what works
better for the use cases.
CSS Sizing
----------
- The group was leaning toward adding a contain-intrinsic-size
property to address issue #4531 (intrinsic-size lost the
thread), but wasn't quite ready to resolve. TabAtkins will write
up proposed spec text and dbaron will add some past examples to
the issue.
- This will be added to the F2F agenda for resolution.
- RESOLVED: Specify Firefox's behavior [Give max-content
contribution of replaced only-aspect-ratio elements ICB
width and then ratio height] (Issue #4218: max-content
contribution of replaced only-ar elements might be
improvable)
CSSOM
-----
- The group agreed that on Issue #4444 (Table row resolved width and
height) there needed to have round trip for block axis. Once
there is spec text the group will review and resolve.
CSS Text Decor
--------------
- RESOLVED: Add an 'always' value to 'text-decoration-skip-ink'
(Issue #4277: Consider adding an `all` value to
`text-decoration-skip-ink`)
CSS UI
------
- For issue #3728 (Should mention the possibility to ignore custom
cursors that go outside of the viewport) Firefox has been
invalidating images that are too large for a custom cursor.
Chrome will add its approach to the issue so the group can
decide if the spec should change.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jan/0004.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Christian Biesinger
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Chris Harrelson
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Myles Maxfield
Anton Prowse
Manuel Rego Casasnovas
Florian Rivoal
Devin Rousso
Jen Simmons
Regrets:
Ravikiran Ramachandra
François Remy
Christopher Schmitt
Lea Verou
Scribe: dael
F2F Agenda
==========
astearns: Does anybody have any changes for the agenda? There's one
we'll postpone that's far down on the list
astearns: 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
astearns: 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
Media Queries
=============
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.
chris: 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 ambiguous again.
TabAtkins has a different opinion that they mean the same
thing. I don't think they do mean the same
TabAtkins: I said they are approximately the same. They're close to
meaning same. Especially in rec2020 where one has a
hyphen and one does not is extremely bad. p3 and
display-p3 are different words.
TabAtkins: Still of opinion we should be consistent. We shouldn't
change color gamut so we should revert color function
keywords because else wise people will ask why are they
different
florian: I would argue they mean the same. If you understand MQ to
ask if gamut is supported by screen with this approximately
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 re-naming display-P3 to P3?
TabAtkins: I'm possibly in that realm. I would like rec2020 to be
consistently hyphen-less. P3 and display-P3 sound
different. Hyphen difference shouldn'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 approximately 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 rec2020 in color to be hyphen-less 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 prefer to keep
astearns: Proposal: Remove Hyphen from rec2020?
astearns: Objections?
RESOLVED: Remove hyphen from rec2020 in all context; everything else
stays as is
CSS Pseudo Elements
===================
Original color of highlight pseudo inside ::first-letter/::first-line
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4625
fantasai: Currently specified if author specifies background color
and no color we use color of originating element
fantasai: With ::first-letter/::first-line it will cause it to
change color because look at paragraph. Would be weird for
spelling or grammar error.
fantasai: 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?
astearns: Prop?
fantasai: Use the color of the text prior to applying the highlight
fantasai: 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
fantasai: Point is make it clear if there's a pseudo element
changing the color we use that color not the document
element
astearns: Objections?
RESOLVED: 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 implementations with change?
fantasai: No one implements this right now. Would all have to change
chrishtr: Backwards compat?
fantasai: No one does this. It's difficult to implement I think.
That's why I raised it
chrishtr: Good to have things not difficult to implement
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 the resolution to accept heycam proposal?
TabAtkins: Accept fantasai proposal
astearns: heycam was agreeing this is right behavior to spec. We'll
try and spec and get implementation experience to say if
it's reasonable. We can back out if too complicated to
implement
tantek: I was reviewing 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 is it hard to implement?
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.
fantasai: 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 implementations
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?
astearns: Then we'll let resolution stand
::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 instead of two pseudos. Then we ran
out of time.
fantasai: 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 which might reduce duplication
fantasai: We have to do that anyway because 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.
smfr: 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 active/inactive. 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.
fantasai: 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
fantasai: 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
astearns: 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 the github issue to something that makes more
sense?
TabAtkins: If you can think of something, sure.
TabAtkins: 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.
TabAtkins: Suggests it's not important enough to think about over
holiday at least
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.
TabAtkins: Objections or additional ideas on use cases with expanded
form of content size please say so.
<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 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
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
fantasai: I would prefer a word that clarifies in the middle
TabAtkins: contain-size sure
astearns: Issues with contain-size?
astearns: Proposal: Change the current contain:size to contain-size
as its own property
chrishtr: It's a parameter to contain:size
<rego> "contain: size" and "contain-size"
chrishtr: contain-size is a parameter to contain:size that indicates
non-zero
cbiesinger: Rename intrinsic-size to contain-size
chrishtr: If contain:size is on an element 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: Proposal: Add contain-intrinsic-size property with an
initial value of 0 that takes a pair of length
cbiesinger: Rename intrinsic-size to contain-intrinsic-size
chrishtr: And conditioned on contain:size being present
astearns: Proposal: 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
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 specify a size it'll
intercept
florian: Initial size of 0 it replaces?
TabAtkins: Yeah
astearns: TabAtkins can you commit to speccing 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
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
fantasai: Something inside it intrinsically sized with an aspect
ratio and no size info
fantasai: No interop. Chrome is 0x0 as max content. Spec says use
300px width and ratio for height. Resolvable but
arbitrary. Firefox uses initial containing block. That
seems useful. We suggest spec Firefox behavior.
astearns: Concerns?
astearns: Objections to Specify Firefox's behavior?
RESOLVED: Specify Firefox's behavior
CSSOM
=====
Table row resolved width and height
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4444
emilio: Height doesn't apply to table rows depending on writing
modes. There was interop issue found by jquery folks. A
bunch of discussion on the issue.
emilio: Various options. Nice to get an agreement.
emilio: 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 Firefox 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.
emilio: Edge used to report auto
emilio: And the computed value
emilio: Computed value of auto Firefox gets a roundtrip height and
Blink doesn't make sense. Edge returned computed value which
is consistent with inlines
astearns: Proposal: Return the computed value of height for table
rows
emilio: When it doesn't apply which is not always. Depends on
writing mode
emilio: I think that makes most sense. Alex argued for Firefox
behavior. There are other comments from fremy and oriol
saying computed value may not be most useful
emilio: A bunch of use cases for this
fantasai: Seems there are two discussions. One is which property
applies and therefore has meaningful value. And which is
in height axis of table. Then should property of block
axis return auto or used value.
fantasai: 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 should round trip
fantasai: 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?
astearns: 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
myles: Other value was none which is don't skip.
myles: 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?
astearns: Proposal: Add an always value to text-decoration-skip-ink
astearns: Objections?
RESOLVED: Add an 'always' value to 'text-decoration-skip-ink'
CSS UI
======
Should mention the possibility to ignore custom cursors that go
outside of the viewport
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3728
florian: Can specify an image as cursor. If image is too large
browsers expected to shrink
florian: Recently Chrome and FF figured 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.
florian: 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
emilio: 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
astearns: I'm told it's florian birthday so happy birthday
<rego> happy birthday florian 🎉
everyone: happy birthday
<florian> thank you all!
astearns: Safe travels everyone, talk to you then
Received on Thursday, 16 January 2020 00:33:25 UTC