- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Aug 2018 19:50:43 -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.
=========================================
Publishing transition updates
-----------------------------
- Editors should have a disposition of comments and changes document
complied as well as any edits already made before requesting a
CR publication.
- After the group resolves to request the CR publication the editor
should publish a the request to the transitions github. If they
don't know how or need assistance, chris is happy to help.
CSS Inline
----------
- RESOLVED: Rename this [inline-content-box-height-calculation-mode]
to be inline-sizing: normal|stretch (Issue #2989)
CSS Overflow
------------
- RESOLVED: Match the block followed by inline ordering of 2 value
pairs for the overflow-x and overflow-y shorthand to be
consistent (Issue #2988)
CSS Display
-----------
- RESOLVED: Publish a new WD of CSS Display
Be consistent about versioning in ED URLs
-----------------------------------------
- RESOLVED: Use versioned URLs for EDs (Issue #2941)
CSS Grid
--------
- RESOLVED: Drop auto from grid line syntax (Issue #2856)
CSS Color
---------
- TabAtkins will speak to his graphics team to talk through his
proposal on issue #2722 ("transparent" keyword being a special
color value, which resolves to rgba(0,0,0,0) by default?) and
add their feedback to the issue in order to continue the
conversation.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Aug/0007.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Garrett Berg
Dave Cramer
Alex Critchfield
Benjamin De Cock
Simon Fraser
Tony Graham
Dael Jackson
Chris Lilley
Peter Linss
Nigel Megitt
Thierry Michel
Anton Prowse
Manuel Rego
Melanie Richards
Geoffrey Sneddon
Alan Stearns
Lea Verou
Jeff Xu
Fuqiao Xue
Regrets:
Tantek Çelik
Emilio Cobos Álvarez
François Remy
Florian Rivoal
Jen Simmons
Sean Voisen
Greg Whitworth
Publishing transition updates
=============================
link: https://github.com/w3c/transitions/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+CSSWG
Rossen: fantasai sent us a reminder with a link to 6 publications
awaiting approval. chris can you give us an update on where
these are?
chris: 2 are waiting for CR transition meeting, they were sent on
Saturday. It was pretty clear on the tags. 2 awaiting
director are waiting. 2 waiting publication have been
approved and just waiting to be published
chris: css fonts 3 had to have a cr and there was a 2 month
exclusion so we had to wait for that to finish. I asked if we
really have to wait 2 months and haven't heard back.
chris: Snapshot I've been pushing on florian who needs to do edits
and he claims he'll do it next week
Rossen: Ones waiting for director can you nudge or are you already?
chris: There's a minimum set of days between when email sent to
chairs list and when they'll decide to give time for
objections or comments. We're inside that so we can't go
faster. Also they do the calls on Fridays and I can't make
Friday come faster.
chris: I have prepared CRs for publication already so if there are
no changes requested I can send them immediately. I'm away
next week but I've asked xfq to look out for those
Rossen: Thanks chris. fantasai is there anything else to touch on?
fantasai: Sounds great. At what point in this process
generally...when something goes through transition request
does editor only need to follow up if there's a question?
chris: The questions if they happen will be on the public repo. If
the director wants a change it's listed there
<dauwhe> https://github.com/w3c/transitions/issues/
fantasai: And once approved does editor need to do anything for it
to be published?
chris: Typically no. Only if there's a load of link errors and in
that case I'll contact the editor.
chris: It would help if you only put the tag for the next stage
rather than all following stages.
chris: One other thing, CSS Paint API took a while, but it's because
I was on vacation and we had two publishing moratoria.
fantasai: Okay, as long as things are following through
chris: I haven't seen something dropped for quite a while.
fantasai: That's great. Historically CRs have taken a long time to
publish for that reason.
Rossen: Thanks chris for pushing on those and thanks fantasai for
surfacing this and pinging us
fantasai: chris one question. When we resolve to take to CR what
would you expect and editor to do?
fantasai: I want to to be clear to everyone.
chris: For the last year I've been pushing back when there's an
agenda item to publish a CR because that's not what we do.
It's are we ready to request CR meaning do we have updated
DoC etc. In the past we'd resolve to publish but also say
editor had to do some things before. We'd have 5 or 6 months
before it's ready
chris: Now it's better because we resolve to request transition and
discuss as a group anything outstanding so it's good to go
when we decide. Github makes it easier to request. As long as
you have DoC and changes list and there's not any objections
you don't have to do anything
fantasai: Should editor file issue into transitions repo?
chris: I think if an editor feels comfortable to do that it's good.
But if an editor isn't I'm happy to show them. That happened
at Houdini. If people are worried I can help but it's very
simple.
chris: Doesn't have to be me.
fantasai: Process is if we resolve...to request you need DoC,
Changes List, any changes to be edited in edited in. And
then file an issue in transitions repo or ask chris for
help
chris: Yes
fantasai: Sound good to everybody?
Rossen: sgtm
CSS Inline 3
============
Need name for inline-content-box-height-calculation-mode property
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2989
Rossen: Nominations are welcome unless fantasai you want to
summarize the property
<fantasai> https://drafts.csswg.org/css-inline-3/#inline-box-dimensions
fantasai: We talked about use case ttml group had for this which it
does not change layout calc, just where background and
border are painted.
fantasai: Current behavior is defined as in css 2. It's possible we
might want other values at some point. I don't know 2.1
but it used font metrics or maybe 1em for height of
content box
fantasai: At one point a suggestion to have a value that contains
all glyph bounding boxes. Might want to extend to do that.
fantasai: Wanted people to think about that
fantasai: I have no good suggestion. I have a constraint that we've
had discussions about how line box height is calc. We need
to be clear that this name is not that
<dbaron> inline-box-sizing :-)
nigel: The ttml requirement is that the background areas go to the
line areas. So if there's a way that line area heights can
change we need to track that in property values.
nigel: Made a suggestion a few days ago and someone had another so
there are suggestions. When I looked at draft spec it make me
want to call it inline-box-content-height. Going back to your
point if the line edges might move then maybe the fill value
should be called line
fantasai: Another thing is we do have plans to have a height keyword
called stretch which takes a container and says I want you
to fill that. Might be another keyword that makes sense.
Could rename fill to stretch.
fantasai: Property name there's...it's the content height but
effects border-box height and shouldn't be confused with
inline-size. Cannot be mixed up with changing how line
height or box height are calc.
dbaron: One thought is inline-box-sizing since it's a mode switch
fantasai: Not terrible, but looks like might be a long hand of
box-sizing
nigel: Sizing says width as well as height, but this is only height
dbaron: Inlines aren't special in width dimension on the other hand
fantasai: Trying to remember why not a keyword to the height property
Rossen: If it's only to inlines height is a bit of an overkill.
You'd also have to add it to all other heights and this is
just used value
fantasai: True
<bradk> It would be width for vertical writing mode, right?
Rossen: I gravitate toward dbaron's reasoning. This is the switch we
use for flipping different ways of box model. Also having
something similar for inline calc which is not bad.
fantasai: But what if we decide some day we want long hands for box
sizing? Then we're stuck.
Rossen: We can make those as optional params and keep as a shorthand
fantasai: But if we decide we do want longhands this is what they
would be. We can say inline-sizing, but not
inline-box-sizing
Rossen: Fair. [missed]
fantasai: Also haven't decided name for line box height calculation
mode property. I think that one should be line-sizing or
maybe line-box-sizing. If we go with that inline-sizing is
close and it gets confusing
Rossen: Seems like we have inline-sizing, inline-box-sizing which
captures it but don't want to use because box-sizing
shorthand. inline-box-content-height proposed on github and
also inline-box-mode also from github
Rossen: Can we narrow down and if we need to change later, well, as
I said this is a favorite topic for the group so we can
bikeshed more
fantasai: I think 'mode' is generic
Rossen: Let's try inline-sizing and see if we can live with it
fantasai: Is that okay even if we have line-sizing?
Rossen: It'll be confusing but will hopefully generate interest
<bradk> Prefer inline-box-sizing
nigel: Why are you focusing on inline-ness rather than the content
area that you're setting. Content area of inline boxes, sure,
but aren't content areas always inline?
fantasai: No, all boxes have content area. And we're not only
setting content area, we're also doing margin and border
etc. It's the margin area that fills the line box. By
default the margins padding etc are by default 0, but if
they're bigger the content box would be smaller
nigel: Makes sense
Rossen: I want to see if we can get closer to resolve. Proposal was
name this inline-size. Value set?
fantasai: I think normal|stretch and maybe extend to glyphs or
something
fantasai: Should be possible to extend value set in the future.
Maybe glyphs, maybe height of whatever is inside it
fantasai: but we can start with those two things since they have
clear use cases.
Rossen: Reasonable. Objections to renaming this to be inline-sizing:
normal|stretch
RESOLVED: Rename this to be inline-sizing: normal|stretch
CSS Overflow
============
'overflow' 2-value syntax is in wrong order
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2988
Rossen: This is value ordering and we try to do x then y, but all
logical properties are block and then inline. What is the
proposal here?
fantasai: Proposal is to use the logical order, block then inline.
Overflow properties do have logical shorthands. Also
pretty important to make sure ordering matches with
scroll-snap-align. Having them opposite is fairly confusing
Rossen: This would apply to...a handful or properties
fantasai: Just overflow shorthand property. I don't know of any
others, though they might exist
<dbaron> how many engines implement 2-value overflow? Gecko does.
Rossen: Do we keep consistency for position properties?
fantasai: Once in logical coordinates are block first inline second.
All the 4 values are block first inline second
fantasai: Logical 2 value coordinates is mainly background-position
and that's a rough WD with logical positioning values
fantasai: Physical are x then y
dbaron: How many engines impl?
fantasai: Just Mozilla because we just added in April
<rego> Chromium has it in M68 I believe
<rego> https://www.chromestatus.com/feature/5090725653905408
Rossen: We've had overflow-x and -y since IE 6
fantasai: We won't change that.
Rossen: Sorry, though you were talking about long hand
Rossen: So that means compat risk is fairly small
fantasai: Yeah
<bradk> When did we resolve on doing block first? That seems wrong
to me.
<fantasai> bradk, awhile back ... when we were working on css-grid
<fantasai> bradk, I'm not entirely convinced it was a good idea,
there were good arguments in both directions... but we
should be consistent here
<bradk> fantasai: understood
Rossen: dbaron would you guys be okay with this?
dbaron: Yeah
Rossen: Proposal: Match the block followed by inline ordering of 2
value pairs for the overflow-x and overflow-y shorthand to
be consistent
Rossen: Objections?
RESOLVED: Match the block followed by inline ordering of 2 value
pairs for the overflow-x and overflow-y shorthand to be
consistent
CSS Display
===========
Reconsider if 'inline-block' and 'inline flow-root' should be
syntactically equivalent
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2947
Rossen: Oriol brought this. We've got more elaborate diagrams
[trying to figure out if right people on call]
<astearns> tab sent regrets for this week and next
fantasai: Since we're stuck on this, can we publish a WD on this?
Rossen: Yeah, let's go ahead and publish
RESOLVED: Publish a new WD of CSS Display
Be consistent about versioning in ED URLs
=========================================
github: https://github.com/w3c/csswg-drafts/issues/2941
gsnedders: This is about consistency on using level for ED.
dbaron: Is this about what the latest version points to or what's in
repo or...?
gsnedders: I think this is what the latest version in the draft is
linked to. The ED link in TR specs. I could be wrong. I'm
not sure, I can't remember
Rossen: chris anything to add?
chris: It wasn't quite the same thing. There's rules for latest
version, but doesn't cover ED
dbaron: I think underlying problem is that CSS conditional hasn't
been published since great renaming. I think solution is
repub
gsnedders: Underlying issue is to have a versionless string in TR
data which is API exposed. That's not a CSSWG thing
fantasai: If this is all pulling from a draft we should prob decide
if we want versioned URLs for ED links
gsnedders: Yes
dbaron: I think versionless is problematic when we have 2 levels
being worked on which happens a decent amount of time
<chris> most of the time, I would say
fantasai: Go with versioned URLs. It's simpler and always correct.
gsnedders: If use versioned do we want anything linked to a later
level. Once we publish as CR and start new work on a new
level do we want to link to that level?
fantasai: That's what TR latest is supposed to be for
gsnedders: Do we want to link to a newer ED?
fantasai: I think no. Let's say grid 1 and 2 are published. Having
ED link for grid 1 go to grid 2 isn't helpful. If you find
issues on L1 you should file them on L1. But if you're
looking for latest you should go to L2. The ED URL
shouldn't try to negotiate which level you're looking at.
gsnedders: Also presupposes we publish a FPWD soon after starting a
new level
fantasai: We do that frequently. When we don't it's because it's
really shaky and you shouldn't be referencing it
Rossen: To avoid the discussion going into publishing management.
URLs and URL versioning. Last proposal that resonated was to
stick with using versioned URL. Can we resolve on that?
Rossen: Objections to use versioned URLs for EDs
RESOLVED: Use versioned URLs for EDs
gsnedders: I don't object, but I want to check if there are things
we haven't published but we should have.
fantasai: gsnedders do you want to fix the repo?
gsnedders: I guess I can.
<dbaron> don't forget fxtf-drafts and css-houdini-drafts!
fantasai: If one person doesn't do them all something will be
forgotten.
Rossen: Agree. This is the kind of thing that needs to be done by
one person
CSS Grid
========
grid-line custom identifier auto?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2856
Rossen: eric brought this and fantasai you put this on the agenda
fantasai: There was an issue against grid asking if the ID auto
should be excluded from the places where we use custom
ident to represent named line. Auto has a special meaning
it doesn't resolve to a named line. We exclude span
keyword, but not auto.
fantasai: Question if we should exclude auto in places we exclude
span
Rossen: I wouldn't put span and auto in same category for this
behavior. span is forward looking directive and auto is a
applied to a single item
fantasai: You cannot have...if you named a line auto you're just
going to have trouble, esp. in level 2 where you can
combine auto with a custom ident. You can see the grammar
in the issue. If a custom ident can include auto you can
write auto1 and have that resolve. I'm not sure allowing
that is helpful
fantasai: Where we have span <custom-ident> we're planning to add
auto as a similar pattern. That's a grid 2 issue
<fantasai> https://github.com/w3c/csswg-drafts/issues/796#issuecomment-385547068
Rossen: I see your point.
Rossen: I can live with it.
Rossen: Anyone from Mozilla that's close to grid impl. dbaron do you
have an opinion?
dbaron: No opinion. Have to ask Mats
Rossen: It's only our impl that allows auto
fantasai: I think chances of people naming a line auto is pretty
much 0 unless you're a QA person
Rossen: How did we end up removing span but not auto?
fantasai: Don't know. I think there's some syntactic construct where
one was ambiguous. It said span and a custom ident you
could do and you want to know that you are consuming a
custom ident or the span up front. If you write span span
is it a keyword or an ident. So we prob did for parsing
Rossen: We allow span int and span custom ident
fantasai: Yes and auto <custom-ident> will be in L2
Rossen: Okay, I'm okay with proposed change
Rossen: Any other opinions? Or do we try to resolve?
Rossen: Objections to dropping auto from grid line syntax?
RESOLVED: Drop auto from grid line syntax
CSS Color
=========
"transparent" keyword being a special color value, which resolves to
rgba(0,0,0,0) by default?
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2722
chris: One point TabAtkins was [missed]
chris: It's if what TabAtkins did was right [missed] [audio problems]
TabAtkins: You remember back when we did gradients and there was an
issue with transparent and I made it so gradients do a
transition through premultiplied space. That has weird
implications. All impl do non-premultiplied
TabAtkins: To fake premultiplied you have to put in a number of
additional stops to do it they way transparent intends.
TabAtkins: I've come to regret this because transparent wants to be
special in more places. When I wrote edits for cross-fade
from last F2F I realized that crossfading with
transparent would darken the image half way through. Same
exact case. When you fade to transparent you expect it to
become more transparent not change color
TabAtkins: Don't want a special case where if you leave it blank you
get a different behavior
TabAtkins: Solution is slightly change original resolution.
Transparent retains itself as a special keyword through
computed value. Some cases use it as meaning something
special some can be to a more transparent version but
otherwise it can act the same where it's rgba(0,0,0,0).
Any opinions or in particular compat concerns?
dbaron: More concerned about if it's giving right behavior. In
particular sounds like you define cross fade so not in
premultiplied.
TabAtkins: Most likely, yes. I suspect most libraries we're using
aren't so we want to match
dbaron: Not so sure on that. And if you're crossfading 2 images and
one has area that's almost but not quite transparent you get
bad results. Suppose you're looking at one region of the
image and it happens to be mostly a solid. And in another
image light and opaque and you could get darkening and then
lightening. Seems not good.
dbaron: Also I think a lot of compositing is done with premultiplied.
TabAtkins: Fine with defining in premultiplied
dbaron: Worth researching
smfr: Crossfade paints the bottom image with source over operator
TabAtkins: It's not. It's not a source over it dissolves and plus
operation
TabAtkins: You're not drawing one and then fading a separate image
over it. If that's true the first image always shows if
there's any transparent areas in the second and that's
not right
Rossen: We're running out of time. I don't want to go to overtime so
I encourage people to go back to github
TabAtkins: I'll talk with graphics people and find out how our image
fading works in the platform
Rossen: Thanks everyone for calling in and we'll chat in a week
<dbaron> ok, yeah, that makes it sound like premultiplied doesn't
even matter
<TabAtkins> dbaron: no, it does still matter. You still get the
darkening effect you mentioned
<TabAtkins> White 50%, transparent 50% dissolves the white to
.5,.5,.5,.5 and the transparent to 0,0,0,0, then adds
the channels together for .5,.5,.5,.5
<TabAtkins> Aka this is just a porter-duff way of saying
"weighted-average the channels", same as gradients
<dbaron> TabAtkins: but aren't the compositing operations precisely
defined so that you don't have an option of choosing
premultiplied or not?
<dbaron> (i.e., they are premultiplied)
<TabAtkins> dbaron: Hm, the first reference I was using for the
definition of dissolve made it an unary operator, but
Wikipedia lists it as a binary op that grabs random
pixels from each layer in proportion to the weighting (
which, extended continuously, is pre-multiplied
averaging)
<AmeliaBR> Concern: How does this affect partially transparent
colors? Can you divide an animation from red to
transparent into a midpoint of #f008 and still get the
same results?
<TabAtkins> AmeliaBR: in premultiplied, yes you can
<AmeliaBR> @Tab, I know. I was thinking about if we switched to the
special case. Someone had mentioned extending special
case behavior to animations, and that seemed problematic
since intermediary values in animation need to be able to
compute out.
<AmeliaBR> But, I realize that in animation, the computed value
would change as soon as you started the animation: as I
said without thinking about it, the halfway-point from
transparent to #f00 would be #f008, not #8008, so all
would be good.
<AmeliaBR> So, for an animation red -> transparent -> blue, the
computed values would all be opacity shades of red until
you hit the exact instant of transparent, then shift to
shades of blue. So the only special behavior is for that
exact point. Any explicitly stated partially transparent
color would behave in the way it is explicitly indicated
too, which is exactly what we're trying to fix, since it
doesn't always work that way with the current spec.
Received on Wednesday, 8 August 2018 23:51:47 UTC