<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
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
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
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
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
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
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
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'
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 :-)
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
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]