- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Jul 2016 21:13:28 -0400
- 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.
=========================================
Start adding things to TPAC agenda
----------------------------------
- Some items being discussed on github have mentioned that they
would be good F2F topics. Please add these items (and any
other topics) to the wiki.
- Everyone planning on attending was also reminded to make
bookings and pay for registration before prices go up.
Call for Ahem font editing
--------------------------
- Myles will be handling the font editing.
[css-ui-4][user-select] value is used value?
--------------------------------------------
- Pretty much everyone agreed that user-select should be used
value. gregwhitworth needed to check with his development team
so the formal resolution will be recorded on next week's call.
[css-values] should allow <percentage> as a resolved type
---------------------------------------------------------
- RESOLVED: Accept the changes in this commit:
https://github.com/w3c/csswg-drafts/commit/054f195a222718e182352a0ff1f87affaafb7114
to allow percentages as a resolved type.
[css-color][css-tables] should 'opacity' be hoisted from the table
box to its wrapper box
---------------------------------------------------------------------
- RESOLVED: Hoist opacity from table box to its wrapper box.
[css-tables] Calc for table layout
----------------------------------
- RESOLVED: Defer this issue to V&U 4.
- RESOLVED: A calc() with only percentage or only length is
required to be resolved in V&U 4.
- There was no decision on addressing a combined length and
percentage. More thought on it was needed.
- RESOLVED: Publish updated V&U 3 CR.
[css-color] Unnecessary comma in color()
----------------------------------------
- RESOLVED: Use this color syntax: color( [ <colorspace>? [
<number>+ | <string> ] [ / <alpha> ]? ]# [ , <color>
]? )
- RESOLVED: Backport slash to the short functions like: rgb( [<r>,
<g>, <b>] | [ <r> <g> <b> [ / <alpha> ] )
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jul/0065.html
Present:
David Baron
Bert Bos
Tantek Çelik
Dave Cramer
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Ian Kilpatrick
Chris Lilley
Myles Maxfield
Michael Miller
Florian Rivoal
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Daniel Glazman
François Remy
Jen Simmons
Ian Vollick
Scribe: dael
Start adding things to TPAC agenda
----------------------------------
astearns: Let's get started.
astearns: First thing, does anyone have anything extra to add?
astearns: TPAC. It's coming up soon.
<fantasai> https://wiki.csswg.org/planning/tpac-2016
astearns: If you haven't added your name to the wiki please do.
Please start filling the agenda with topics.
astearns: I've noticed on a few github issues people have
mentioned having them at a F2F so start linking those to
the agenda so we can see what we'll talk about.
ChrisL: If people have registered they should pay. I think the
price goes significantly up after 2 September.
astearns: And I believe flights will get more expensive too. So
make plans and pay the W3C.
Florian: And I'm coordinating if you want to AirBnB.
dauwhe: I think some TPAC hotels are already full.
astearns: I'm staying at a near AirBnB and there's lots of
possibilities.
astearns: Any other TPAC items?
Call for Ahem font editing
--------------------------
astearns: I think the second item is covered.
astearns: There was a call and myles has volunteered, so thanks.
myles: I've been doing similar in webkit.
fantasai: There's an updated version from Sergey and MS so you
want to edit that file.
astearns: Any other testing font requests, get them in now!
<ChrisL> please add tests for all of css3 fonts opentype features
:)
<fantasai> Thread wrt Ahem at
https://lists.w3.org/Archives/Public/public-css-testsuite/2016Jul/0011.html
<myles> ChrisL: i did in webkit, i could add the tests to the w3c
<fantasai> ChrisL, see the other fonts. Ahem is for layout testing.
<ChrisL> srsly? that would be super cool.
<astearns> ++ to adding more WebKit tests to the w3c suite
<ChrisL> fantasai, I know what ahem is for. and i was actually
joking
<fantasai> I mean.. we do need tests for all of those things :)
<fantasai> myles: I'm going to update the font in the test suite
with MSFT's updated version, and I'll send you a link.
What we need is another copy of the square glyph
assigned to some CJK codepoint...
<myles> ChrisL: https://trac.webkit.org/changeset/189890
<fantasai> Probably "water"
<myles> fantasai: sounds good
<ChrisL> myles, very nice test font
[css-ui-4][user-select] value is used value?
--------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/336
Florian: This is about user-select. There is a bit of computation
about computed value of user-select.
Florian: There's a couple cases where you don't want to do
inheritance- i.e. when your element is editable. You want
contain there. The question raised was do we do the
computation at used time or computed value time?
Florian: I specced at computed because it wasn't layout, but I
don't think anything else depends on it so moving to used
would be fine. What do people want?
astearns: So the question is if for this property we return the
used value?
Florian: Not if we should return. I've defined that auto computes
to this in foo situation. The question is if we should
say auto behaves as this or that so behaves at means done
at used value time.
astearns: Ah. Okay
Florian: Personally I like computed value for theoretical
completeness, but if used value is better for
implementors I can switch. Is that what you guys want?
astearns: Implementor opinion?
astearns: koji said Blink prefers used.
Florian: And I think Xidorn said Mozilla would agree.
astearns: Given that you have 2 implementors preferring change and
silence on the call, I say let's change.
gregwhitworth: I think we'll sync up. It seems odd to me. I'll
check with our devs and see what we do and give
feedback.
Florian: I'd rather not resolve and wait on feedback then.
gregwhitworth: Okay, sure.
tantek: We can resolve with current info and if there's new info
we reopen. And Florian you can delay making the edits. But
we can get a resolution on the record.
astearns: Yes. If we had no other person we're waiting on input.
Since gregwhitworth is asking I'd rather wait on
resolving until we have info. It's known unknown.
tantek: I'd just prefer since we're so close to a resolution we
resolve. This makes less friction in the likely case we're
waiting.
fantasai: We can resolve conditionally. There's a general caveat
that new information makes us revisit, but this is a
specific thing we're waiting for. The resolution should
record we're waiting a week before it's considered final.
astearns: I'm happy enough to wait. It'll be on the agenda next
week and we'll do that after we get gregwhitworth
feedback.
gregwhitworth: And this is when you query the dom element with
user-select set you want to know if we're storing
at used or computed?
Florian: The other difference is if we do it at used value it
makes it impossible for other property's computed value
to depend on this property's computed value. I don't
think there's a probable use case, but I'm not sure.
Florian: If there's implementor difficulties we can flip to used.
Florian: For the resolution I'm okay to wait or resolve
conditionally.
astearns: I'd prefer to wait.
[css-values] should allow <percentage> as a resolved type
---------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/250
fantasai: The issue is that there is in theory a possibility that
a property could accept percentages and not compute to
an equivalent thing and all percentages compute away.
The edit is to allow percentages to resolve to
themselves. I think it's straightforward, but it's a
change to CR so I wanted to bring it to the group.
<fantasai> https://github.com/w3c/csswg-drafts/commit/054f195a222718e182352a0ff1f87affaafb7114
fantasai: Here's the commit.
gregwhitworth: Seems reasonable to me. I haven't been here since
we've added a new length type, though. Do other
implementors have any worries?
fantasai: It should have no effect on implementors until there's a
value that only accepts percentages in which case it
would allow calc in that context.
astearns: Is there a particular case for percentages not resolving
to anything else?
fantasai: I don't think there's anything in mind, but they want to
allow it. TabAtkins is arguing opacity should only have
taken percentages so that could have been such a
property.
iank: This is for Houdini and the layout API where you want a
percentage not something resolved against a length. If that
adds more context.
astearns: So you want to have the custom layout code be able to
decide what a percentage means. Makes sense to me.
astearns: Other opinions?
astearns: Objections to the change?
RESOLVED: Accept the changes in this commit:
https://github.com/w3c/csswg-drafts/commit/054f195a222718e182352a0ff1f87affaafb7114
to allow percentages as a resolved type.
[css-color][css-tables] should 'opacity' be hoisted from the table
box to its wrapper box
---------------------------------------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/324
ChrisL: Is dbaron on?
ChrisL: He's critical to this.
astearns: I believe dbaron expressed regrets.
<dbaron> oh, I guess I could join, actually
fantasai: His opinion is in the issue.
fantasai: If we all think he's right I don't think he'll object to
us resolving on what he suggests.
astearns: Does anyone have a yea/nay opinion on dbaron's weak
preference for not hoisting?
fantasai: I think opacity should be.
<ChrisL> I agree opacity should be hoisted.
fantasai: Opacity we're pretty sure. And in that vein you would
say filters should have the same. I don't know if
they're sensitive to coordinates. If filters are hoisted
and therefore coordinates are effected then making
masking hoisted would make sense so it uses the same
coordinate as filters.
<ChrisL> filters generally apply to the bounding box so yes the
difference would be visible
fantasai: Following that argument, which I'm not sure is accurate,
then we should hoist them all.
astearns: dbaron said he'd join.
astearns: And my not hoisting comment as dbaron's preference was a
mis-read. That was just to not hoisting masking.
dbaron: That sounds like an accurate summary.
astearns: Would it make sense to resolve on hoisting opacity and
not decide on filters and masking because we're not sure
if people want those things to be hoisted when
coordinate changes could cause odd effects?
dbaron: Seems reasonable to me.
astearns: fantasai is that okay with you?
fantasai: I don't mind for today. We need to decide eventually.
ChrisL: Do we tests or check web compat. I'm not sure filters is
used much on HTML tables. Are we worried about breaking
existing or right thing to do?
fantasai: Right thing to do. Seems unlikely there's a web compat
issue.
<smfr> https://drafts.csswg.org/css-transforms/#grouping-property-values
smfr: The transform spec has the grouping properties which is
opacity and filters, but also others listed here ^
smfr: We may want to consider if these hoist.
fantasai: Makes sense. Probably all should.
<ChrisL> sounds good to me
<ChrisL> and I agree that all should, probably
<fantasai> ChrisL, except overflow, which is defined already to
apply to the table box
<ChrisL> oh, good catch
astearns: What if we resolve to hoist opacity today and put the
rest on TPAC agenda? Drawing things may help.
astearns: Does anyone object to hoist opacity from table box to
its wrapper box?
RESOLVED: hoist opacity from table box to its wrapper box
astearns: I'll add the rest of the hoisting discussion to TPAC.
[css-tables] Calc for table layout
----------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/94
fantasai: Currently if there is a calc value in table and heights
is a percentage the UA can treat it as auto. There was a
comment about things being stupid obvious such as if
calc contains only percentage or length then this isn't
more complex, just do the adding. So those should not be
treated as auto.
fantasai: My opinion is the spec isn't wrong, the UA could do
either. I'd defer it to level 4 V&U. For that I think
it's reasonable to require calc only with length or only
with percentage should be resolved.
dbaron: Is this tables or table parts?
fantasai: Table parts.
dbaron: There's another option. If you have calc (length +
percentage) you treat it as though you had a cell with a
length and one with percentage which isn't quite the same.
But there's also a question on - so maybe not great.
fantasai: So I propose resolve that we're deferring to 4. Resolve
in 4 that a calc with only percentage or only length is
required to be resolved. And third we don't resolve on
what to say about mixing the two yet.
fantasai: We may decide on requirements later, but we're in early
stages of level 4 so we don't need to lock down yet.
astearns: Other opinions?
Florian: For the first two parts it's reasonable. For the
combination does anyone implement that?
gregwhitworth: From my testing I couldn't find anyone that did
anything nice on percentage despite the one bug
fremy found on the thread.
gregwhitworth: The one thing to echo is I don't want to discuss
anything, just document what exists in the world.
If that's level 4 that's okay.
gregwhitworth: I'm not against talking about in the future, but I
don't think people use percentage now.
Florian: The three parts are fine. I'm just thinking on the 3rd
that the combination may be a must not support. But we
can deal with that later.
astearns: So, 3 parts. Objections to defer this to level 4 Values?
fantasai: Level 3 of Values says when specified for width and
height on tables.
astearns: So objections to deferring the question to level 4 of
V&U?
gregwhitworth: I wasn't aware this lived in V& U as well.
gregwhitworth: But since it's future it's okay. If we dig into
this and have width and height change the algorithm
we may want to bring it into Tables.
astearns: Yeah. If there's a web compat issue it would be tables 3.
gregwhitworth: Yeah. I'm not aware of one.
RESOLVED: Defer this issue to V&U 4
astearns: Objections to having a calc with only percentage or only
length is required to be resolved in V&U 4?
RESOLVED: A calc() with only percentage or only length is required
to be resolved in V&U 4
astearns: And since we're not saying anything on mixing I don't
think we need a resolution.
fantasai: I'd like another CR resolution for V&U 3 before these
issues came up.
fantasai: So I'd like another resolution.
astearns: Objections to update to V&U 3 CR?
<tantek> +1
RESOLVED: Publish updated V&U 3 CR
[css-color] Unnecessary comma in color()
----------------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/266
astearns: As far as I vaguely understand we have options. 1) just
a space 2) a slash 3) alpha keyword
astearns: Is that correct?
<fantasai> https://github.com/w3c/csswg-drafts/issues/266#issuecomment-234131024
fantasai: I think what we've got here is ^
<fantasai> color( [ <colorspace>? [ <number>+ | <string> ] [ /
<alpha> ]? ]# [ , <color> ]? )
fantasai: That's the current proposal state.
fantasai: The idea is you would separate by spaces, use commas for
fallback colors. There's some back and forth on if the
slash is needed or should be a keyword.
fantasai: I'm inclined to the slash.
fantasai: I think it helps readability, and keyword is too long
for something so common.
<tantek> some explicit syntax for separating opacity would likely
reduce unintended (overtyped) opacity
<tantek> slash seems ok to me
ChrisL: I think the keyword is too verbose. I agree with fantasai.
<tantek> having at least a slash also makes it easier to detect
authoring errors at validation time
gregwhitworth: I missed the original conversation. Why are we
moving away from commas?
fantasai: We're trying to take CSS functional notations to be a
named segment of CSS values. Using CSS values syntax
means it's not necessarily positional and it allows
reordering of names or dropping optional. There's a lot
of advantage there over commas.
fantasai: What we want to do is bring color more in line. So here
we needed a fallback and it lets us use the comma
without nesting parenthesis. It lets us make the color
space optional.
gregwhitworth: Sounds good
<fantasai> https://wiki.csswg.org/ideas/functional-notation#general-principles
ChrisL: It does in general. Does that mean parameters are
re-orderable?
fantasai: Depends on what we decide. If there's property values in
general we don't allow reordering. So if you can't parse
with reordering if it's not allowed. There are cases
where something is required first. So in this case the
name of the color profile.
Florian: Don't know if you need that. There's no other ident in
there. You have a color name, but that's a string.
ChrisL: I don't see the benefit. I like it first and optional and
if it's missing it's sRGB.
Florian: I think the 3 colors should be in order. But name first
or last I don't see a reason to prohibit
<gregwhitworth> this would be valid then color(/.5)
ChrisL: [reads gregwhitworth ]
<fantasai> gregwhitworth, the color is required currently. We
could in theory make it optional so that would be
valid...
dbaron: The argument for first is it says what the rest means. It
helps readability.
astearns: Main benefit is the color space is optional. There's
other syntaxes where rearranging is useful, but I'm not
sure this is one.
Florian: The other benefit is that we'd need to nest and that's
bigger.
<ChrisL> so I like using commas for fallback and avoiding nesting
BradK: I think avoiding nesting is important. That's where the
keyword came about is if the color mod could be a keyword.
I'm fine with a slash, I think it works better.
astearns: I have a slight preference for the keyword because it's
easier for me to remember that alpha needs an alpha
keyword.
fantasai: You'd be using colors so often you'd hate typing it.
astearns: I don't do colors often so I bow to others
<ChrisL> yeah I would hate typing "alpha" all the time
<leaverou> me too
BradK: rgba is so common forcing people to write opacity is too
much
<gregwhitworth> I agree in full notation, this is very legible
color(AdobeRGB 255 255 255 /.75, #fff);
<ChrisL> also can we stop using 0 to 255 numbers in examples? It
is 0.0 to 1.0
<ChrisL> because we will also support 10bit and 12bit per
component, especially for wide gamut spaces
gregwhitworth: When I see the / I think division
gregwhitworth: If you read the second part, I would think it's
division. If you have rgba you would have it
automatically. You wouldn't think it's rgb divided
by something.
<leaverou> gregwhitworth: that ship has sailed, we use / as a
separator in a bunch of places
astearns: I agree with leaverou. We have it as a separator
elsewhere. So if it's not a bare space a / is the thing
to use.
Florian: And since this isn't 3 parameter, it's an arbitrary
number of colors, visually you'd have no clue with a
space. I think we need a separator. And if we have one it
should be /
myles: You need the content to make meaning out of the other
numbers, so it doesn't seem bad on the last.
Florian: But if you have a 7 color profile seeing if it's 7 or 8
isn't easy.
<ChrisL> florian, exactly
<BradK> 1color( [[ <colorspace>? [ <number>+ | <string> ] [ /
<alpha> ]? | <hex> ]# )
fantasai: And you could want to change the alpha without changing
or understanding all the others. You just know you want
that color at 50% opacity and you can tell if there's an
argument there already or if you should add one.
<Florian> +1 to fantasai
<dauwhe> +1 to fantasai
Florian: There's two ways to make it special, put the / or require
percentage.
fantasai: I prefer the / because I think we should allow color
arguments to be percentage at some point in the future.
We'd be blocked from making that change.
Florian: Okay.
fantasai: Also, opacity in the rest of CSS allow numbers, so we
with a slash we can be consistent and allow them here
too.
astearns: I'm hearing consensus on using the /. I propose we add
the / to the syntax and develop some examples on various
color profiles we're expecting to handle and get it out
to authors and they can let us know if they like it.
<tantek> +1
<fantasai> color( [[ <colorspace>? [ <number>+ | <string> ] [ /
<alpha> ]? | <hex> ]# )
<ChrisL> wait, what is that hex thing? and where is the fallback?
<fantasai> (ignore that)
fantasai: Several resolutions here. We can take this ^ syntax from
Florian.
Florian: Where is the hex?
BradK: I put that. the earlier said color as a fallback, but hex
is an odd one out.
Florian: For a fallback I think the most useful is to allow
anything other than the color notation. If we just allow
a color in general it means people can comma separate the
syntax.
fantasai: It would allow variables.
fantasai: Otherwise I'd say don't allow. It's better to use the
notation with a keyword or hex, but if we want variables
in fallback I don't see why not so it should take any
color value.
Florian: It's not harmful and a bit useful.
ChrisL: fantasai can you write it out correctly?
<fantasai> color( [ <colorspace>? [ <number>+ | <string> ] [ /
<alpha> ]? ]# [ , <color> ]? )
fantasai: This one?
<fantasai> https://github.com/w3c/csswg-drafts/issues/266#issuecomment-234131024
BradK: And a note in the spec with what you just said to
discourage embedding.
astearns: I like that.
ChrisL: Can I put color space after the comma?
Florian: You can put any kind of color. hsl, blue whatever.
astearns: So we are resolving on the last color syntax in IRC:
color( [ <colorspace>? [ <number>+ | <string> ] [ /
<alpha> ]? ]# [ , <color> ]? )
<ChrisL> +1
<ChrisL> yes
astearns: Objections:
Florian: Like it.
<tantek> +1
fantasai: Me too.
BradK: Are we also resolving that colorspace can take a keyword?
Any of them. RGB, sRGB.
astearns: Let's resolve first on the syntax.
<ChrisL> huh?
RESOLVED: Use this color syntax: color( [ <colorspace>? [
<number>+ | <string> ] [ / <alpha> ]? ]# [ , <color> ]? )
astearns: So BradK asked what does colorspace mean in that syntax
ChrisL: So hsl and those are in sRGB color space. If we want to
add all previous syntaxes I can see the reason. It's not
really a colorspace, but okay.
BradK: So colorspace or color defining keyword.
<astearns> <colorthingy> : <colorspace> | <other>
ChrisL: It means we can't remove something like hsl from sRGB but
I think it's fine.
fantasai: You can, but a different keyword.
Florian: If you write 'AdobeRGB hsl' that means different than hsl.
ChrisL: It makes it complicated.
Florian: I'm just saying we're not stuck.
ChrisL: Okay. I can write this up.
Florian: Only thing I'm not sure is to allow rgb.
Florian: It should be srgb or omitted.
BradK: You'd allow lab and the others?
ChrisL: Yeah. We're not removing the short functions, though.
BradK: I'm ambivalent.
fantasai: We should keep short.
<tantek> I think we should keep short.
astearns: And it's because web compat, right?
BradK: For the ones that exist.
<tantek> keep existing short functions for webcompat, and
author-friendliness, more readable style sheets etc.
ChrisL: Also because it's more convenient. If you want lab being
able to say it and the numbers is convenient. People like
hsl and 3 numbers.
BradK: I wouldn't object.
leaverou: Are we backporting / into other color functions?
fantasai: We could.
fantasai: It would be a variation with no commas and a / for alpha.
<tantek> agreed about backporting "/" to short functions too
Florian: Might be a good idea. We would try and do rgb with rgba
and we're not sure we can, but the space and / would be
web-compatible.
BradK: Do the new functions allow commas?
Florian: I would not allow.
BradK: Keep as legacy?
ChrisL: The new ones are doing it as fantasai described.
astearns: Sounds like ChrisL will explore drafting things other
than colorspaces in the colorspace part of the syntax.
astearns: Do we need to decide on backporting the / or see it
written?
fantasai: I think we have consensus
astearns: I agree. Is anyone worried about backporting / to the
short functions?
<Florian> rgb( [<r>, <g>, <b>] | [ <r> <g> <b> [ / <alpha> ]? )
<ChrisL> yes
fantasai: What Florian typed is right
<tantek> backporting "/" to short functions is a nice to have (I
am for it), but not going to object to not
Florian: That's better than allowing the r, b, g, alpha in rgb
astearns: Objections to backporting / to the short functions like:
rgb( [<r>, <g>, <b>] | [ <r> <g> <b> [ / <alpha> ]
<tantek> same for rgba? or?
RESOLVED: Backport slash to the short functions like: rgb( [<r>,
<g>, <b>] | [ <r> <g> <b> [ / <alpha> ]
<ChrisL> rgba deprecated?
Florian: I suggest we don't go to the ones with an a. Or does rgba
work without the a?
astearns: I would assume rgba you could omit the commas and add
the slash.
Florian: Do we depreciate rgbs?
BradK: rgb and rgba become the same.
Florian: I don't think rgb can take comma separated without web
compat issues.
astearns: It's the non-comma version that they share.
astearns: We're at the top of the hour. The details of backporting
will need discussion, but we've resolved to do it.
Received on Thursday, 28 July 2016 01:14:28 UTC