- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 6 Aug 2015 07:22:35 -0400
- To: www-style@w3.org
: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> https://lists.w3.org/Archives/Public/www-style/2015Mar/0402.html
Florian: I think we spoke about that a few times and there was
something tricky about the preloader.
fantasai: What does the preloader have to do with syntax?
Florian: There was a bigger discussion about @supports and general
MQ and the interaction with @viewport. If you start to do
things like this you end up with the whole thing. While
it sounds okay at the syntax level, you get surprising
performance...
Florian: The advantage of @import only being at the top, the
preloader can support that without complex syntax. So it
can load, but not preload. Personally I don't care all
that much, but last time we talked there were big
concerns.
fantasai: This mail is about double parentheses in the @import.
Florian: Okay, ignore that. I'm off topic.
* Florian apologizes for confusing this topic with another one,
and jumping straight in without listening first, which
would have avoided wasting everybody's time.
glazou: So fantasai you wanted to discuss because it's the last
one on the radar?
<fantasai> @import "url" support(<supports-condition>)
fantasai: Right now we have @import and a URL and @supports where
you can put a condition. It was pointed out where if you
just have one condition...if you have two conditions it
makes sense
<fantasai> @import "url" support((display: flex) and
(align-items: start))
fantasai: That's fine.
<fantasai> @import "url" support((display: flex))
fantasai: For very simple cases you end up with the double
parentheses. Can we change the grammar to allow one set
of parentheses?
<fantasai> @import "url" support(display: flex)
<SimonSapin> sounds ok
glazou: For usability and readability I'd support that.
glazou: I'd like to hear from others. SimonSapin said okay.
SimonSapin: Would this only be @import?
fantasai: Yeah, because @supports doesn't have parentheses in
itself.
SimonSapin: Right. I think that's fine.
fantasai: We might also consider allowing it for the JS .supports
<fantasai> .supports("(display: flex)")
fantasai: It's not quite the same, but it's similar problem.
smfr: What would it look like with a not?
fantasai: You would need parentheses. Only in the case with just
the one thing.
glazou: Any objections?
Florian: I think a long time ago we resolved in the other
direction for JS. I don't strongly care either way, but
given that we did resolve the other direction, is there
something we're not considering this time?
fantasai: I think it's weirder when it's just in CSS
glazou: It's often the case that we review something because we
originally decided on purity of the language and then we
find it's ugly and make the change.
Florian: Sure.
glazou: So no objections?
RESOLVED: Allow to one stack of parentheses in the case of one
single supports query
fantasai: Do we want to extend that to JS and is dbaron on the
call?
SimonSapin: I think rather than default to, I think we want to
allow both.
glazou: Let's imagine you have an @import with two, you remove
one, and then you end up with two stacks, we want to allow
that.
TabAtkins: Yeah, you can put an infinite amount of parentheses in
a supports.
RESOLVED: In case of one single supports query the innermost
parentheses are optional in functional notation
(to take place of last resolution)
<fantasai> Resolution applies to both JS and supports(), to clarify
<SimonSapin> In terms of grammar: `something_something :
supports_condition | declaration`
* fantasai thanks SimonSapin:)
Containment and Overflow
------------------------
Florian: We discussed last week, but there is follow-up.
<Florian> https://lists.w3.org/Archives/Public/www-style/2015Jul/0461.html
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> https://lists.w3.org/Archives/Public/www-style/2015Jul/0169.html
glazou: It's been on the agenda for three weeks and has had a lot
of traction on the mailing list, so we should do this one.
myles: There's...at Apple we've gotten a fair number of requests
for people to style contents so it fits with the UI. The
proposal is to create a font family generic font name so
that it matches the UI of the OS. It seems Android, iOS and
Windows 10 have a relevant font family that this would use.
What are your thoughts?
fantasai: Makes sense to me.
ChrisL: Do OS only have a single one? Do any have serif and
sans-serif or something like that?
<Bert> KDE has 8 UI fonts
myles: Of the OS I looked at, they have one font family for the UI
elements. So this is about font families.
Florian: In theory they could be all over the place, but in
practice there aren't. Generally there is one font
family, but there could be more so we should spec
properly for that.
Bert: The system I'm using, KDE, has by default its UI fonts, but
I noticed that knowing the family and size isn't enough if
you want to mimic the normal look. You need the color and if
they use shadows. It's rather more complex.
myles: I think it's viable to not make this very complicated to
support KDE.
Bert: I have no conclusion, I was looking at the question and
since you asked about the families, at the moment my system
is using the same family but with different weights and
sizes. If you want to look the same, knowing the family
isn't enough.
ChrisL: I don't think the claim was that this one value would be
enough to mimic the UI, just the font.
TabAtkins: Yes, it was to just have you mimic the UI. The font
used can be jarring if you're trying to look native.
TabAtkins: We should specify at least suggestions on how to choose
a system font for things that have multiple fonts. So
those of us that have browsers that run on Linux need
to know what to use.
<ChrisL> +1 to what tab said, for spec clarity
myles: That's fine, I can write something up.
<leaverou> Is there a use case of mimicking the default typography
of an OS, without mimicking any other part of its UI? (
since we have no access to anything else)
<bradk> 'Color:system; text-shadow: system'?
<fantasai> bradk, wouldn't work, since different elements have
different values for it
<leaverou> TabAtkins: Looking native takes much more than just
mimicking the font or text-shadow though
<gregwhitworth> I'm less inclined for the system function, but
like the system name itself
glazou: Can you answer dbaron proposal from the e-mails in a
summary?
myles: The proposal was to have system be a function so you can
put system menu and get the menu font.
glazou: And your answer?
myles: The answer is that this is what I described before where,
for the OSes I looked at, there's only one so it seemed
needlessly complicated.
Bert: One other issue that Nick Doty brought up. If you allow an
app to ask what the system UI font is, you have an extra
surface for fingerprinting. If there's a way to make the
server not know what's being displayed.
fantasai: We have this problem already. CSS 2.1 has system font
keywords already. This gives you less information.
TabAtkins: It's also almost completely subjugated...this allows
for no additional entropy except for people that
customize their fonts.
Bert: But this does effect those people.
TabAtkins: Yes, but that entropy is already out there.
<dbaron> It's a little annoying to have two different system font
mechanisms that work in entirely different ways...
glazou: So in case we resolve on this, maybe a note summarizing
Nick Doty's message would be good.
Florian: The message is bringing up the fingerprinting, what does
the note say?
glazou: At least web authors are warned.
<dbaron> It's not authors who should be warned; it's users.
myles: There's no note for the font keywords.
TabAtkins: Yes. If we're going to start marking fingerprinting
vectors we can be more consistent about that and mark
them elsewhere.
glazou: The W3C started to do more about privacy. I think it's
good to have a warning.
myles: I'm fine with that.
Florian: I'm just trying to see who should be warned.
TabAtkins: The most useful target is people producing privacy
enhancing tools.
Florian: That's a good point.
glazou: So we accept the new value and its definition with a note
in the spec. Objections?
<Bert> +1 to a note, even if we don't know how to solve it yet :-)
RESOLVED: Accept the new 'system' value and its definition with a
note in the spec about fingerprinting issue.
fantasai: Who is going to edit this in? We need someone to do the
editing work for this.
TabAtkins: I have a reasonably complete fonts 3 that we can port
over to fonts 4.
myles: So is that volunteer?
TabAtkins: Well...if no one else is going to do it, I'll put it on
the list of specs I'm contributing to.
myles: Certainly for this value I was intending on contributing
prose.
TabAtkins: Should I take an action finishing polishing the
bikeshed version and create an ED for fonts 4?
fantasai: Can we deal with fonts 3 not being bikeshedded?
ChrisL: Yeah.
fantasai: I think that's a good idea. Can we get a resolution?
<ChrisL> +1
Florian: Bikeshed 3, diff spec 4, TabAtkins as an editor?
glazou: Objections?
dbaron: I think it's worth running by jdaggett
ChrisL: Would he object?
TabAtkins: He's weakly objected to other things but I can try
again.
fantasai: There's things he wanted fixed in bikeshed before
porting it over so you two should probably coordinate on
that.
glazou: Okay, let's do that.
HCL colors
----------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0098.html
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> https://lists.w3.org/Archives/Public/www-style/2015Jul/0060.html
fantasai: I can summarize, but not resolve today since Koji isn't
on the call.
fantasai: We have a writing-mode property that says if you're LTR
or RTL or Top to Bottom and we also have text
orientation that says how that line of text is rotated
in that original box. Do you rotate clockwise or anti-
clockwise. To do something like a book spine you would
use these things in combination.
fantasai: The problem with the design is you can end up with the
left side on the top or bottom or both in the same BFC.
fantasai: You can also rotate 180 in the same line which is also
complex.
fantasai: There was a request to simplify what can be done. There
was discussion on how to do this and this proposal is to
change...instead of having the text-orientation give all
the possible orientations, we move some to writing-mode.
<dbaron> I don't think it's actually that hard from an
implementation perspective, although it does require some
work; I think the main difficulty is specifying it
correctly.
fantasai: It would add sideways-lr and sideways-rl which would
rotate the entire block. Anything that's not CJK would
use that to turn the text sideways and that would ignore
the text-orientation. If you're trying to do upright you
would use vertical-lr and possibly text-orientation to
tweak that.
fantasai: We lose two use cases if we switch to this model. It's
top to bottom Arabic in a CJK document which is rare. Or
Ogram in a CJK document which is also weird and rare.
Florian: Two comments. I spent a bit of time off list with Koji
discussing this. We independently landed on this solution
as well so we're both in favor.
Florian: One downside of what we had previously is that it was
biased to CJK. horizontal-language authors could not use
the writing mode property for side captions without also
using the text-orientation property. The new proposal
fixes that. The simple use cases are just in the
writing-mode property. Both for CJK and English users.
Florian: The other point, for the use case we're using, if you
have RTL inside Japanese, and want both to go
top-top-bottom rather than end up in a bidi situation,
we can no longer do this inline.
I did some research to see if that case existed. I
reached out to academics and librarians and no one could
point out a use case. It's extremely rare if it exists.
We're not losing anything.
glazou: Okay. We don't have Koji so I suggest we resolve on the
mailing list.
Florian: Koji is fine. I'm not sure about jdaggett.
glazou: We don't have everyone around the table. Let's gather the
opinions before we decide.
glazou: We have 8 minutes. We have Ruby issues, keyframes
interaction, whitespace around and/not and max-content
contribution.
Remove requirement for whitespace around and/not
------------------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0332.html
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> https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html
TabAtkins: This is about how animations interact with each other
when one has an animation timing function and others
don't; that's not well defined. I wrote an e-mail
algorizing the thing. This needs review and someone
saying it matches up. Internally it's correct as far as
we know. As long as people are okay with it, that's
great. Review on the mailing list.
smfr: I think the general algorithm is correct, but I don't like
the word transition since that's a thing.
TabAtkins: If you can come up with a better word, that's fine, lay
it on me.
TabAtkins: If anyone has a better name, please tell me and we'll
change it.
TabAtkins: Otherwise, there's nothing specific for that. Review
and give a stamp of approval.
ACTION everyone review the proposal so we can approve
glazou: There's only a minute left. Thank you everyone, have a
good F2F, I'll talk to you in September.
Received on Thursday, 6 August 2015 11:23:33 UTC