- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Dec 2016 20:28:14 -0500
- 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 next snapshot
------------------------
- Will-change, Variables, and Flexbox were mentioned as specs that
should move to a higher status in the 2016 snapshot.
- ChrisL will prepare a list of specs not mentioned in the 2015
snapshot to help the group discover any specs that should be
included in 2016.
Grid Items
----------
- The proposal on how to address stretching grid items in both
directions is summarized in the github issue:
https://github.com/w3c/csswg-drafts/issues/523 Anyone
interested, especially from the design/webdev community, was
asked to review before the next call (4 Jan).
- Similarly, the proposal to correct the language around implied
minimum size is summarized on github
(https://github.com/w3c/csswg-drafts/issues/283)
and edited into the spec. A resolution will be sought on the
next call.
- RESOLVED: Accept proposal from TabAtkins and fantasai in
https://github.com/w3c/csswg-drafts/issues/767
Color properties should use "used value" as "resolved value"
------------------------------------------------------------
- RESOLVED: Make color properties return used value as resolved
value.
Overflow: Consider support for overlay scrollbars
-------------------------------------------------
- The topic will be added to the F2F agenda and was renamed to
'Consider reserving space for scrollbars with some property'
to avoid confusion.
New feature - scroll-boundary-behavior (an extension of
-ms-scroll-chaining)
--------------------------------------------------------
- There was general support in formally specifying this type of
behavior, but it wasn't ready for a resolution.
- The latching behavior done by webkit and Chrome should be added
to the proposal or at least able to be done with the
properties.
- It was agreed that the name will need to be improved.
- This will be added to the F2F agenda.
Should text-decoration-skip apply to overline and line-through?
---------------------------------------------------------------
- RESOLVED: Ink skipping applies to overline and underline, but
not line-throughs
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2016Dec/0073.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Simon Fraser
Tony Graham
Dael Jackson
Chris Lilley
Peter Linss
Michael Miller
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Steve Zilles
Regrets:
Bert Bos
Tantek Çelik
Dave Cramer
Elika Etemad
Daniel Glazman
Anton Prowse
Scribe: dael
Publishing next snapshot
========================
Rossen: Hello everyone.
Rossen: First thing, any additional items?
<ChrisL> https://drafts.csswg.org/css-2015/#css
ChrisL: We said in the charter we'd publish a snap shot at end of
2016. We haven't quite made it, but I think that's fine.
Looking at current WD I think there's a few things we
could move from stable but not much tested. will-change,
maybe variables
ChrisL: I wanted to kick of discussion. What makes this different
from last snap shot?
Rossen: I think variables is a good candidate. Not sure about
will-change for other implementations.
Rossen: Blink? Mozilla?
Rossen: Who is implement will-change?
smfr: Webkit.
dbaron: Gecko as well.
Rossen: That's good. Do you folks feel we can move this up to
ready but not much tested?
smfr: I think that's reasonable.
<dbaron> fine with me
Rossen: k
ChrisL: I think flexbox could move out of the not fully tested.
Rossen: Sure. I think flexbox is fairly interop.
ChrisL: I think so.
Rossen: I'm not sure on Grid. Did Mozilla release it non-prefixed?
dbaron: It hasn't yet, but plan is to ship not far in the future.
Rossen: But in 2016 it will not.
jensimmons: It's march. Chrome I think is also March.
<jensimmons> Grid is slated to ship in Firefox 52, in early March
2017
Rossen: So it's a bit early.
ChrisL: CSS Speech, are we keeping that in?
ChrisL: I think it dropped off the charter.
Rossen: I believe we agreed to continue work on this at CSS a11y
TF.
Rossen: I'd prefer the updates to come from that TF since that's
the purpose of it. Since Speech is fairly a11y targeted it
would be good to make it there.
ChrisL: So leave it in.
dbaron: I think it's interesting to look through things that
aren't listed here. It's a little hard to do mentally.
Rossen: You mean for new modules added?
dbaron: Yeah. I'm guessing there's a module floating around we
think is stable and not listed because we forgot.
ChrisL: I think you're right. I can go through the WD list and
make a subset of things not listed.
dbaron: Yeah. I don't remember what's in color 4 or selectors 4
and if any of those should move up.
ChrisL: Yeah. We should do a new draft of selectors 4 but that's
separate. Okay. I'll kick of discussion by making the list
of not listed things.
ChrisL: It is hard to mentally do.
Rossen: That would be great. Like round display is missing. Please
also look at FX.
<astearns> a list will be good to maintain for future snapshots as
well
Rossen: So you can take an action and then open an issue against
the snapshot in github?
ChrisL: Yes.
ACTION ChrisL list all the specs not currently listed in snapshot
2016
<trackbot> Created ACTION-806
Grid Items
==========
TabAtkins: Yes, I'll review them all real quick.
Stretching image grid items in both dimensions
----------------------------------------------
TabAtkins: First is from Mats about stretching image grid in both
dimensions. The spec was written where default
stretches in both axes. For images that means you lose
intrinsic dimensions. That's not expected behavior.
TabAtkins: You could use start or end, but then you're at native
size. Original suggestion was change behavior of
stretch for replaced items so the stretch until one
dimension his grid area. This was edited in, but after
fantasai and I discussed we realized that the alignment
properties would now be in charge of sizing and you
then can't align the image in the dimension not filling
the area.
TabAtkins: That's clearly a bad solution. So the solution we
proposed was to say 'normal' has different behavior on
if the item has an intrinsic aspect ratio. If not it's
stretch, if yes it's start.
TabAtkins: So images are start, start.
TabAtkins: If the image is potentially larger than the grid area
you can use max width 100% and max height 100%. Then as
sizing spec comes to it's own and exposes fill you can
make small images fill a grid area.
TabAtkins: Then you could have an image fill a grid area
regardless if it's smaller or larger, maintains aspect
ratio, and responds to align.
TabAtkins: That's all written in the github issue.
TabAtkins: Please review and let us know if you have opinions.
Spec has been edited and we'll seek resolution in the
future.
Rossen: So next meeting is 4 Jan.
Rossen: So this is mostly brought up as a call to action.
Rossen: I went through your summary and it seems reasonable. Last
time we discussed there was feedback from jensimmons and I
think leaverou. I'd like to hear again from the design/
webdev folks to see if they consider this normal in their
view.
TabAtkins: Yep.
Florian: I have a question. I didn't deep dive in, but have you
considered instead of a magic value, using the magic
value on object fit?
TabAtkins: That doesn't do what we want. Mainly, object-fit isn't
a natural way to resize. It doesn't have the desired
effect on box-shadow or filters.
Florian: Okay.
TabAtkins: Yeah. It's good for a number of features, but not as a
generic.
Florian: Alright, thanks.
Implied Minimum Size of Grid Items
----------------------------------
Rossen: Then let's got the the next.
TabAtkins: Implied min size. Started with a question about what we
meant for a particular clause on auto min size. We
clarified that.
TabAtkins: Restarting.
TabAtkins: Flexbox introduced automatic min size to prevent things
from shrinking too small. It also prevents shrinking
to 0.
Rossen: Yeah, it was meant to keep things in natural size.
TabAtkins: There's similar use cases in grid.
TabAtkins: It works exactly the same. It references flex
definition. It had an extra clause where if your grid
area spans tracks your min shouldn't be bigger then
that. That was clarification on what precise size it
should be because you need min and max track sizing. We
clarified that.
TabAtkins: It meant to talk about max track sizing function in the
actual size. That's the first bit.
TabAtkins: Should be a small clarification.
TabAtkins: Second is based on further discussion the auto min size
was happening too often and was making things grow in
unwarranted ways. We decided only cases where we want
auto min size is when something can get shrunk too
small. This maps to tracks with an auto size.
TabAtkins: If an item spans one of these it should invoke
automatic min size.
TabAtkins: [reads definition]
TabAtkins: We believe this correctly captures the intent and keeps
things from growing too small, but doesn't accidentally
activate it and make things too large in other cases.
Review would be appreciated. It's edited into spec and
the issue has a good breakdown.
Rossen: I did go through...you're saying I have an item that spans
3 columns. And they all have an auto min width. The middle
track is auto, the others are 0.
Rossen: At first the image size will be the min size of the image.
Rossen: Then if I change the middle track from auto to be 1fr then
all the sudden everything shrinks to 0?
TabAtkins: No, using 1fr is the same as auto, min: 1fr.
Rossen: So if I toggle between auto and fr in this case it will
have no effect.
TabAtkins: Yeah.
Rossen: So if I make it a big size...
TabAtkins: Or if you do min/max 0, 1fr.
Rossen: And if the track has min-content?
TabAtkins: It already has a similar effect. It will ask the item
what the min size is.
Rossen: And the item is spanning so it's contradiction to the
track is all it's size.
TabAtkins: I think so...we didn't touch that bit of the algorithm.
Rossen: Okay. I think I'm fine with that.
Rossen: So I think you're asking for review today and a CTA for
everyone impl or interested to look at this issue and
we'll revisit before F2F.
TabAtkins: Yep.
Automatic minimum size clamping by grid area should transfer through
aspect ratio
--------------------------------------------------------------------
TabAtkins: Third is a fairly small issue. If you're in a situation
where you care about auto min size. You have an image
200px that spans 2 tracks that are min/max auto, 50px,
auto, 50px.
TabAtkins: We clamp the auto min size to that value because you've
said no more than 100 px. So the image exactly fits.
TabAtkins: Issue is in the older spec we didn't clamp the
transferred size which sizes the height axis. So if
width is a value you multiple through aspect ratio and
get a preferred height. That wasn't getting clamped by
this clause that limited to 100px.
TabAtkins: So you would calculate transferred size by 200px. So we
clarified that so all things surrounding auto sizing in
both axis care about clamping.
TabAtkins: At the end of the thread there's a clause to clarify.
<jensimmons> I think I’ve encountered this bug, the one Tab is
describing. It’s annoying.
Rossen: Out of curiosity, aren't specified size and content size
specified somewhere?
TabAtkins: Yes. They're linked appropriately.
TabAtkins: Read the quotes as being links.
Rossen: That's fine.
jensimmons: I've run into this bug so...yay, thank you! Let's fix
it.
Rossen: That is one thumbs up I'm hearing.
Rossen: Anyone else?
<rachelandrew> makes sense to me
Rossen: Let's call for objections.
RESOLVED: Accept proposal from TabAtkins and fantasai in
https://github.com/w3c/csswg-drafts/issues/767
Color properties should use "used value" as "resolved value"
============================================================
Florian: I didn't raise this, but I have dependencies. Color
properties are not listed in CSSOM as properties that use
used value. In all implementations when you have
currentColor you get a numeric value, not the keyword.
Florian: This isn't due to poor implementation. Everyone is
already doing getComputedStyle for color properties as
used value. If we change this it will unlock a pending
test case.
Rossen: What spec?
Florian: CSSOM. There's a list of properties and a definition
saying that it's used value in specific cases. Color
isn't listed.
ChrisL: [missed]
Florian: xidorn checked.
ChrisL: I asked if this is what impl already do.
Rossen: Yes. It's defining the standard.
ChrisL: Would any tests change because of that?
Florian: None I'm looking at.
TabAtkins: Makes sense to me. I don't like expanding resolved
value, but matching implementation is good.
<dbaron> This is really fallout from the change that makes
currentcolor a computed value
Rossen: I'm hearing a lot of thumbs up. Objections to making color
properties return used value as resolved value?
ChrisL: Does it have any effect on color 4 and color 3 errata?
Rossen: I would assume only OM.
Florian: Yes. Only OM. There's a separate issue about CSS 3 and 4
saying different things about computed, but that's
separate.
RESOLVED: Make color properties return used value as resolved
value.
Overflow: Consider support for overlay scrollbars
=================================================
<Florian> https://github.com/w3c/csswg-drafts/issues/92#issuecomment-251727301
Florian: I don't know if people remember, but we've discussed
before.
Florian: This comment summarizes where discussion went last time.
Florian: Allowing authors to opt into variant behaviors with
overflow: auto. You may want to reserve space on
scrollbar. Or you may not want to if scrollbar is
overlay. But if browser would need space you want to
reserve it.
Florian: We had 3 proposals. Does anyone else remember this?
<gsnedders> remembers the discussion and remembers no conclusion
Rossen: I remember the discussion and going through github I
didn't see much since then.
Florian: I think the conversation was just cut off on the last
call. Having stagnated it could be interested to re-open.
Florian: We had agreed on the behavior, but not syntax. The
alternatives were a dedicated prop with 3 values or a
long hand of the overflow with 3 values, or adding these
additional values as switches to overflow.
<dbaron> seems like this might be a good topic for a face-to-face
meeting
* smfr agrees with dbaron
Florian: Are people ready to debate or is this too much off
everyone's mind?
smfr: Can we do it in Seattle?
Florian: Sure, sure. I wanted to revive the debate.
Rossen: I think there's plenty of interest so we should add it to
the F2F.
smfr: Can we object to the title of the issue? It confuses me
every time.
Florian: Do you have a suggestion?
smfr: It's about reserving space for the scrollbar.
Rossen: [changes the gitbub]
Florian: So if anyone wants to refresh their mind before, the link
I pasted is a good summary.
Intrinsic size of replaced elements incorrect
=============================================
<dael> https://github.com/w3c/csswg-drafts/issues/794
TabAtkins: Without fantasai I don't think we can talk about this.
Rossen: This is similar to the first topic we did. I'm not sure
this is separate.
TabAtkins: It is.
New feature - scroll-boundary-behavior (an extension of
-ms-scroll-chaining)
=======================================================
TabAtkins: This was created by Majid.
Rossen: I see zcorpan added it, but he's not on.
TabAtkins: I can discuss it.
Rossen: Do we want to try and resolve? Yeah. Let's take it.
TabAtkins: MS has had an unspecified prop called
-ms-scroll-chaining
Rossen: It was specified, but not documented.
TabAtkins: Unstandardized.
TabAtkins: Controls if you're scrolling and hit top or bottom if
the scroll intent escapes or is stuck inside.
TabAtkins: There's a lot of app cases where if you're allowed to
escape it's annoying. That's why MS did it and we
thought it reasonable to standardize.
scroll-boundary-behavior: propagate | contain | none
TabAtkins: propagate allows you to escape. contain traps scroll
and does things like the android bounce. none traps you
but doesn't do any indication.
TabAtkins: Majid suggests specing in CSSOM View. zcorpan agrees on
functionality. We REALLY need better names. Propagate
is hard to spell too.
TabAtkins: Concept-wise does this group feel we should standardize?
smfr: Webkit has the scroll latching to a scrollable area. You
latch in a single gesture. During the latch you scroll a
single thing. If you're at the bottom and you scroll again
you go to the parent. So there's a difference between the
middle and the beginning of a gesture. This behavior should
distinguish or say only at the beginning.
smfr: Second comment is if you do scroll none you have the ability
to not let a user manipulate the page and that's bad
behavior. This impinges on where browsers may want their own
behavior that lets the user interact in ways they prefer.
I'd like good use cases for the three values.
TabAtkins: I can before the F2F have Majid draw up example use
cases of apps that mess up if scrolls chain. We also do
the latching so I think we need to define to allow or
address that.
smfr: There's on use case from FB for example where the chat
widgets if you hit the bottom you don't want to propagate
for the page. That's a good use for none.
TabAtkins: I think they're mostly cases like that where it's a
mostly independent widget.
Rossen: In our case when we had the demand any time there was a
list involved...one of the initial design concepts that
were mostly in windows 8 apps was that general scroll of
apps was horizontal and the content inside was in vertical
lists. There was a handshake between the two to propagate
between vertical & horizontal.
Rossen: Having these complex behavior and not capture scroll was
difficult. I believe we have a bunch of examples we can
dig out for the F2F if we're not resolving now. We'd
support standardizing this going forward.
Rossen: I also don't like the name. scroll-contain sounds nice.
TabAtkins: I like scroll-chain.
Rossen: Unless you're an implementor it doesn't resonate as much.
<smfr> scroll-contain sounds overflow-related
Florian: You described the containment of scrolling to be going up
the chain. Can this be used in the other direction where
you have a map in the middle of a page and you scroll the
map when you meant do the page?
Rossen: This will make it hard. So assume you have a bunch of
iframes. When you gesture to scroll down your page
scrolling will stop in a number of ways. It will be very
confusing. How do you compute the sum of your scroll bar.
The aggregated scrollable areas of all scrollers? And what
if some are scrolled already. Propagating down is complex.
Florian: I'm not saying it should happen. I think it does happen.
Rossen: I think it only happens if it's the last one...I'm not
sure.
Florian: I'll research the problem better before raising it.
Rossen: Doesn't sound like we can resolve on this.
Rossen: We'll revisit as a part of the scrolling discussions at
the F2F.
Should text-decoration-skip apply to overline and line-through?
===============================================================
koji: The proposal is to change text-decoration-skip to only apply
to overline and line-through. Not strike-through. Webkit has
this behavior. People on the issue seem to be on consensus.
Florian: I think it makes sense. If you skip on strike through you
mostly can't see the line.
TabAtkins: Oh gosh yeah. I'm seeing the example image
and...they're showing how you can't see a line through
because it's obscured by the letter.
TabAtkins: Saying overlines do skipping [missed]
TabAtkins: Saying overlines doing skipping does make sense.
koji: I think so.
<leaverou> are there any use cases for skipping the line on
line-through?
Rossen: You said this is shipped by webkit?
koji: Yes.
smfr: Just underline.
Florian: Why not overline?
smfr: Because it's used on the web a million times more. Maybe we
do overline. We do it, yeah.
koji: So are you okay to resolve not to apply strike through?
smfr: Yeah. It seems strike through should strike through all the
glyphs.
koji: Yes. And the specs say apply to overline.
koji: smfr is fine to say apply to overline.
Rossen: I'm hearing consensus. Anyone objecting?
RESOLVED: Ink skipping applies to overline and underline, but not
line-throughs
Rossen: That's the end of today's topics and this year's phone
calls unless anyone wants to bring a 4 minutes topic.
Rossen: Any topics? Or should we adjourn.
Rossen: Okay. Thank you all for calling. Happy holidays, happy new
year, safe travels. We'll talk on Jan 4 and meeting Jan
10. Thank you everyone!
Received on Thursday, 22 December 2016 01:29:13 UTC