See also: IRC log
<scribe> ScribeNick: dael
Rossen: We'll give it a minute and then get going.
<astearns> 47% present+
<jensimmons> lol
Rossen: Hello everyone.
... 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 maded
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
... I wanted to kick of discssion. What makes this different
from last snap shot
Rossen: I think variables is a
good candidate. Not sure about will-change for other
impl.
... Blink? Mozilla?
... Who is impl 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.
Rossen: k
<dbaron> fine with me
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-prefix?
dbaron: It hasn't yet, but plan is to ship not far in the future.
Rossen: But in 2016 it will not.
rachelandrew: It's march. Chrome I think is also March.
Rossen: So it's a bit early
ChrisL: CSS Speech, are we
keeping that in?
... I think it dropped off the charter
<jensimmons> that was jensimmons speaking, not rachelandrew
Rossen: I believe we agreed to continue work on this at CSS a11y TF.
s/ rachelandrew / jensimmons
<jensimmons> Grid is slated to ship in Firefox 52, in early March 2017
Rossen: I'd prefer the updates to comef rom 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 sep. Okay. I'll kick of
discussion by making the list of not listed things.
... It is hard to mentally do.
<astearns> a list will be good to maintain for future snapshots as well
Rossen: That would be great. Like
round display is missing. Please also look at FX.
... So you can take an action and then open an issue against
the snapshot in github?
ChrisL: Yes
<dbaron> attempting to diff in my head has led to possibly listing overflow-3 and ruby
ACTION ChrisL list all the specs not currently listed in snapshot 2016
<trackbot> Created ACTION-806 - List all the specs not currently listed in snapshot 2016 [on Chris Lilley - due 2016-12-28].
TabAtkins: Yes, I'll review them
all real quick.
... first is from Mats about stretching image grid in both
dimentions. The spec was written where default stretches in
both axes. For images that means you lose intrinisic
dimentions. That's not expected behavior.
... 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 dimention his grid area. This
was edited in, but after fantasai and I discussed we realized
that the align prop would now be in charge of sizing and you
then can't align the image in the dimention not filling the
area.
... That's clearly a bad solution. So the solution we proposed
was to say 'normal' has different behavior on if the item has
an intrinisic aspect ratio. If not it's stretch, if yes it's
start.
... So images are start start.
... If the image is potentially larger than 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.
... Then you could have an image fill a grid area regardless if
it's smaller or larger, maintains aspect ratio, and responds to
align.
... That's all written in the github issue.
... 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.
... So this is mostly brought up as a call to action.
... 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 fromm 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 considdered instead of a magic value, using the magic value on object fit?
TabAtkins: That dodesn't dowhat 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.
Rossen: Then let's got hte 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.
... Restarting.
... 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.
... 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.
... It meant to talk about max track sizing function in the
actual size. That's the first bit.
... Should be a small clarification.
... Second is based on futher discussion the auto min size was
happening too often and was making things grow in unwarnted
ways. We decided only cases where we want auto min size is when
sommething can get shrunk too small. This maps to tracks with
an auto size.
... If an item spans one of these it should invoke automatic
min size.
... [reads definition]
... We believe this correctly captures the intent and keeps
things from growing too small, but doesn't accidently activate
it and make things too large in other cases. Review would be
appriciated. 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.
... At first the image size will be the min size of the
image.
... 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?
<tantek> belated regrets
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 contridiction ot the track is all it's size.
TabAtkins: I think so...we didn't touch that bit of the algo
Rossen: Okay. I think I'm fine
with that.
... 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.
... 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, aut,
50px.
... We clamp the auto min size to that value because you've
said no more than 100 px. So the image exactly fits.
... 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.
<jensimmons> I think I’ve encountered this bug, the one Tab is describing. It’s annoying.
TabAtkins: So you would calc
transferred size by 200px. So we clarified that so all things
surrounding auto sizing in both axis care about clamping.
... At the end of the thread there's a clause to clarify.
Rossen: Out of curiosity, aren't spec size and content size spec somewhere?
TabAtkins: Yes. They're linked
appropriately.
... 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.
... Anyone else?
<rachelandrew> makes sense ot me
Rossen: Let's call for objections.
RESOLUTION: Accept proposal from TabAtkins and fantasai in https://github.com/w3c/csswg-drafts/issues/767
Florian: I didn't raise this, but
I have dependencies. Color properties are not listed in CSSOM
as prop that use used value. In all immpl when you have
currentColor you get a numeric value, not the keyword.
... This isn't due to poor impl. Everyone is already doing
getComputedStyle for color prop as used value. If we change
this it will unlock a pending test case.
Rossen: What spec?
Florian: CSSOM. There's a list of prop 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 impl 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. Obj to making color properties return used value as resolved value?
ChrisL: Does it have any effect on color 4 and color 3 erratta?
Rossen: I would assume only OM.
Florian: Yes. Only OM. There's a sep. issue about CSS 3 and 4 saying different things about computed, but that's sep.
RESOLUTION: make color properties return used value as resolved value
<Florian> https://github.com/w3c/csswg-drafts/issues/92#issuecomment-251727301
Florian: I don't know if people
remember, but we've discussed before.
... This comment summerizes where discussion went last
time.
... Allowing authors to oopt into variant behaviors with
overflow: auto. You may want to reserve space on scrollbar. Or
you may not want ot if scrollbar is overlay. But if borwser
would need space you want to reserve it.
... We had 3 proposals. Does anyone else remember this?
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.
<dbaron> seems like this might be a good topic for a face-to-face meeting
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.
... 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 hte scrollbar.
Rossen: [changes the gitbub]
Florian: So if anyone wants to refresh their mind before, the link I passted is a good summary.
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 seperate.
TabAtkins: It is.
TabAtkins: This was created by Majid (sp?)
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 unspec prop called -ms-scroll-chaining
Rossen: It was spec, but not doc.
TabAtkins: Unstandardized.
... Controls if you're scrolling and hit top or bottom if the
scroll i ntent escapes or is stuck inside.
... 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
resonable to standardize. scroll-boundary-behavior: propigate |
contain | none
... propigate allows you to escape. contain traps scroll and
does things like the android bounce. none traps you but doesn't
do any indication.
... Majid suggests specing in CSSOM View. zcorpan agrees on
functionality. We REALLY need better names. Propagate is hard
to spell too.
... Concept-wise does this group feel we should
standardize.
smfr: Webkit has the scroll
latching to a scrollable area. You latch in a signle 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 behaviour should distinguish or say only at the
beginning.
... Second comment is if you do scroll none you have the
ability to not let a user manipluate the page and that's bad
behavior. This impinges on where browsers may want hteir 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 ex 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 independant 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 vert & horz.
... 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.
... I also don't like the name. scroll-contain sounds nice
TabAtkins: I like scroll-chain
Rossen: Unless you're an impl it doesn't resonate as much.
<smfr> scroll-contain sounds overflow-related
Florian: You desc 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 b e very confusing. How do you compute the sum of your scroll bar. The aggrigated scrollable areas of all scrollers? And what if some are scrolled already. Propagating down is complex.
Florian: I'm not saying ti 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.
... We'll revisit as a part of the scrolling discussions at the
F2F.
koji: The proposal is to change Should text-decoration-skip to only apply to overline and line-through. Not strike-through. Webkit has this behavior. People onthe issue seem to be on consensus
Florian: I think itmakes 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 obscrured byt hte letter.
... Saying overlines do skipping [missed]
<leaverou> are there any use cases for skipping the line on line-through?
TabAtkins: Saying overlines doing skipping does make sense
koji: I think so.
Rossen: You said this is shipped by webkit?
koji: yes.
<leaverou> agreed with TabAtkins
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.
... smfr is fine to say apply to overline.
Rossen: I'm hearing consesnus. Anyobe objecting?
RESOLUTION: Ink skipping applies to overline and unnderline, 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.
... Any topics? Or should we adjourn.
... 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!
<smfr> jan 11th, right?
<leaverou> Happy new year everyone!!
<rachelandrew> happy holidays and Happy NY :)
<gsnedders> smfr: Houdini TF, 10th
<Rossen> smfr, yes :) 10 for Houdini
<gsnedders> And technically Houdini is part of the WG, right? :)
<smfr> aw crap, booked my flights for the 11th already :(
<Rossen> just show up at the airport and tell'em you made a mistake :)
<Rossen> but seriously, we'd really like if we can have you participate on 10th
<smfr> yeah i’ll try to change
<Rossen> trackbot, end meeting
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/ rachelandrew / jensimmons/ Found ScribeNick: dael Inferring Scribes: dael Default Present: dael, Rossen, rachelandrew, plinss, antenna, ChrisL, smfr, jensimmons, gsnedders, tgraham, Florian, dbaron, TabAtkins, SteveZ Present: dael Rossen rachelandrew plinss antenna ChrisL smfr jensimmons gsnedders tgraham Florian dbaron TabAtkins SteveZ Regrets: tantek WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 21 Dec 2016 Guessing minutes URL: http://www.w3.org/2016/12/21-css-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]