:has()
------
- bkardell informed the group that :has() has received a lot of
support on Microsoft's uservoice.
Allowing @import to be conditional on @supports queries
-------------------------------------------------------
- RESOLVED: In case of one single supports query the innermost
parentheses are optional in functional notation
- This resolution applies to both JS and supports()
Containment and Overflow
------------------------
- RESOLVED: Leave the spec as-is for contain: paint and
overflow: clip
- RESOLVED: Clarify contain to make sure it specifies the order of
operations
'system' generic font name
--------------------------
- RESOLVED: accept the new 'system' value and its definition with
a note in the spec about fingerprinting issue.
HCL colors
----------
- RESOLVED: Add LCH to the Colors 4 spec
writing-modes and text-orientation
----------------------------------
- Everyone on the call was in support of the proposal to create
sideways-lr and sideways-rl in writing-mode, but all the
interested parties weren't on the call, so a decision will
occur on the mailing list.
Remove requirement for whitespace around and/not
------------------------------------------------
- RESOLVED: Revert the spec on the whitespace requirement
Specifying how keyframes interact
---------------------------------
- Everyone received an action to review TabAtkin's proposed
algorithm for handling how animations interact with each other
when one has an animation timing function and others don't
====== FULL MINUTES BELOW =======
Present:
Tab Atkins
David Baron
Sanja Bonic
Bert Bos
Adenilson Cavalcanti
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Daniel Glazman
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Anton Prowse
Florian Rivoal
Andrey Rybka
Simon Sapin
Alan Stearns
Lea Verou
Ian Vollick
Greg Whitworth
Regrets:
none
scribe: dael
:has()
------
glazou: Let's start
<fantasai> glazou, can we add the conf call dial-in #s to the
meeting announcement template?
glazou: Yes, fantasai, I can try to do that.
<fantasai> thanks
glazou: First thing, any extra items? I saw one from fantasai on
the WG list and a mention from gregwhitworth that
backgrounds item isn't to be discussed.
glazou: Before we start, I'm away the next 3 weeks, so I won't be
at the F2F.
bkardell: To add, I wanted to have a quick regression about has
and gauging interest and feedback from Microsoft
uservoice on that.
glazou: How much time do you need?
bkardell: A minute or two.
glazou: Let's do that.
bkardell: Two weeks ago during WG telecon when we were discussing
as to if we should punt :has() and if developers wanted
it and if implementors will implement. We stuck it onto
uservoice. For those of you that don't know, uservoice
has about 500 features that developers can go spend
points to prioritize.
bkardell: In the two weeks it's in the top 10% of requested
features. I think it's clear that there's a big want. I
think we should take that feedback to our respective
implementors and advocate that it get implemented.
<ChrisL> the web developers HAVE SPOKEN
glazou: Comments from others? Implementors?
gregwhitworth: We glanced at it here. Last time we talked about it.
We discussed it with 5 or 6 of us and we like what
it offers for developers. We've discussed with
engineers at other UAs and they're concerned about
performance. I'm starting conversations about how
it's utilized to see if we can scope down to remove
the concerns a bit.
<ChrisL> are the performance issues verified or just worries? ie
how much are they based on testing?
gregwhitworth: I think it's worth keeping in the spec to say there
are issues raised and lets deal with them. The
developers are already doing it with JS.
gregwhitworth: So that's where we stand.
<bkardell> note it is currently in the spec only in the static
profile
glazou: Other opinions? Is that good for you bkardell?
bkardell: Yep. Other than to say that in the spec it's only static
profile so there shouldn't be performance concerns there.
<fantasai> bkardell, the concern I have with :has() is various
proposals to change its syntax in order to make it
restricted enough for the dynamic profile
Allowing @import to be conditional on @supports queries
-------------------------------------------------------
<glazou>
Florian: Quick summary, we had discussions as to if overflow: clip
should stay with different semantics and we agreed we'd
keep the old functionality. We're open to bikeshedding
the name.
Florian: The follow-up is, we're all clear where if you do
contain: paint and overflow: clip you get the ideal
situation. But if you don't specify overflow: clip and
you do visible, should contain: paint force it to compute
to clip? Or are we in one of those cases where the author
didn't consider he might overflow and we don't want to
make content disappear, shouldn't force it to auto
instead?
TabAtkins: I believe we should stick with contain: paint auto
clips. That's so authors don't have to do a bunch of
properties to get containment.
Florian: I initially agreed, my only doubt was the extra thing you
need to flip causes content to disappear. If you didn't
consider that, you drop content.
TabAtkins: The contain property in general, all values can do
bad things if you use them unwisely. We don't have to
safeguard this one in particular.
Florian: I can live with that. It was worth raising since we're
careful about disappearing content.
smfr: In general when one property influences a second property
we've avoided influencing the computed value of the second
property.
TabAtkins: Yeah, if it computes is a separate thing.
Florian: Yes, it's should it automatically overflow: clip or do
you have to ask explicitly.
smfr: I'm with TabAtkins. If you say contain: paint it does
everything it's supposed to do.
Florian: If we resolve this way, there is a follow-up.
Florian: So proposal, leave the spec as-is.
glazou: Objections?
TabAtkins: smfr and I expressed we're for the resolution.
RESOLVED: Leave the spec as-is for contain: paint and
overflow: clip
Florian: The follow-up, if you're not using overflow, but
overflow-x and overflow-y and then you contain: paint. If
you're visible in one direction and not the other the
visible goes to auto. The contain: paint says it goes to
clip. When I wrote this with TabAtkins the intent was the
overflow property would apply first. So you have auto and
then the contain doesn't apply.
Florian: This was raised as ambiguous on the mailing list.
TabAtkins: I'm fine with clarifying the spec.
<bkardell> +1 to clarify the spec
<bkardell> I think the way Florian described it makes as much
sense as anything
Florian: I'm not sure if it's contain or overflow that needs to
clarify, but what do we clarify to?
Florian: The speed argument might apply here against overflow
applying first.
TabAtkins: I'm okay with it. So it changes to auto and you get
the contain effect.
glazou: bkardell loves it too. Other opinions?
smfr: Contain applies last?
TabAtkins: Yes. If you were otherwise going to be
overflow: visible you're going to change, but the
others would clip auto.
smfr: What if you set scrollbars?
TabAtkins: You'd still have them, yes.
Florian: You do the computed value rules of overflow first. Then
if contain: paint you compute visible to clip if you
need to, but otherwise you leave it as is.
dbaron: That seems reasonable assuming that we want contain: paint
to be scrollable.
<dbaron> ...which I'm not completely convinced about
Florian: By default they're not. But if you explicitly ask for
scrollbars you get them.
TabAtkins: I see no reason why it would have to have anything to
do with scrolling. The elements can do whatever they
want. If you don't want scrollable, contain: paint will
do that for you.
glazou: Do we go for the suggested clarification?
TabAtkins: I can clarify contain to make sure it specifies the
order of operations.
RESOLVED: Clarify contain to make sure it specifies the order of
operations
'system' generic font name
--------------------------
<glazou>
ChrisL: The thing that may have confused people, it's normally
called LCH and discussed with LAB because they're two
identical forms. This is asking if we should add these to
the spec.
ChrisL: I think we should, I think I have an action to do it.
TabAtkins and I need to discuss it.
ChrisL: This used to be SVG and was moved it to Colors 4. I think
I'm ready to add spec text. I think we should close with
we should add it.
TabAtkins: I'm fine with that.
RESOLVED: Add LCH to the Colors 4 spec
Action ChrisL write some language for LCH
<trackbot> Created ACTION-702
writing-modes and text-orientation
----------------------------------
<glazou>
TabAtkins: Several F2Fs ago we talked about whitespace in regards
to syntax. We decided that there should be whitespace
on both sides of 'and', 'or', and 'not'. Turns out this
breaks things. There's at least one Microsoft minifier
that removes the space before the and. So requiring
that space breaks all the code using that minifier. So
I suggest we drop that requirement and recommend the
whitespace, but not require it as long as you do
something to have it parse into keywords.
Bert: I'm in favor. For MQ it's quite simple since it's WD. The
problem with be with @supports. We have a CR that requires
spaces. We'll have to pull that back to WD. I'm in favor of
doing it, but it is some work to do.
TabAtkins: Yeah, that's process. We can republish as necessary.
glazou: Who is in favor, who objects?
ChrisL: Sounds good to me.
Florian: As long as @supports is in sync
RESOLVED: Revert the spec on the whitespace requirement
Specifying how keyframes interact
---------------------------------
<glazou> Received on Thursday, 6 August 2015 11:23:33 UTC