- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Sep 2015 16:00:28 -0400
- To: www-style@w3.org
Fragmentation
-------------
- RESOLVED: Accept the change for behavior of cloned margins at
breaks.
- RESOLVED: Publish Fragmentation as CR.
Prefixing Policy
----------------
- fantasai will clarify the meaning of prefixing in sections 3.3.2
and 3.3.3
- Microsoft and Apple will send it around to interested parties
asking for input for next week's call.
Accessibility Requirements on Authoring Tools
---------------------------------------------
- RESOLVED: Accept the new wording (available here:
https://lists.w3.org/Archives/Public/www-style/2015Aug/0348.html)
pending bcampbell's feedback.
Baselines of Flex and Grid Containers
-------------------------------------
- RESOLVED: No change for baselines and flex and grid containers.
Reverting '0' -> '0%' Change
----------------------------
- RESOLVED: Make the change and note in the spec there's a chance
there might be a webcompat issue.
Simplification of auto-repeat
-----------------------------
- RESOLVED: Simplify spec. Leave issue open asking for use cases,
and switch back if needed. Turn the issue into a note
at CR saying a future level might expand.
Drop Group Snapping from Level 1
--------------------------------
- The snapping conversation will wait until there is more
representation from Apple.
Grid
----
- RESOLVED: Republish Grid with the changes discussed above.
- Everyone was tasked with reviewing Grid so that the authors can
stay on target to publish CR during TPAC.
Transforms, Transitions, and Animations
---------------------------------------
- glazou urged progress on these three very visible specs and will
also be reviewing the rest of the specs before TPAC to make
sure that nothing has stalled progress.
Japanese Industry Meeting
-------------------------
- Though official confirmation is pending, the meeting will likely
occur on the Sunday before TPAC.
===== FULL MINUTES BELOW ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Bo Campbell
Tantek Çelik
Alex Critchfield
Dave Cramer
Elika Etemad
Daniel Glazman
Dael Jackson
Brian Kardell
Brad Kemper
Chris Lilley
Peter Linss
Michael Miller
Anton Prowse
Matt Rakow
Florian Rivoal
Hyojin Song
Alan Stearns
Greg Whitworth
Regrets:
Simon Fraser
Lea Verou
Steve Zilles
scribe: dael
glazou: Let's start
glazou: I noticed two extra items outside what's in the agenda.
First was a request from fantasai to transition CSS Break
to CR. Sorry, three items. Second was prefixing policy.
glazou: fantasai, how much time do you need for Fragmentation?
fantasai: Not much.
glazou: So since it's publication let's start there.
Fragmentation
-------------
fantasai: Let me grab to DoC
<glazou> https://drafts.csswg.org/css-break-3/issues-lc-2015
fantasai: I also sent an e-mail. Let me get that URL. That
summarizes.
<glazou> http://www.w3.org/mid/55E7486C.9050004@inkedblade.net
fantasai: We have a DoC. Chris wants it formatted differently, but
hasn't said exactly how. The changes list is minimal.
ChrisL: The specific thing I would like, but won't object if you
don't do it, is to more clearly show if the commenter has
accepted the working group's resolution of their issue.
You asked me for a good one, but I couldn't find a recent
on. I have to explain them and it adds time to the
transition process.
ChrisL: If you don't have it or it's not easy that's okay.
ChrisL: So basically you have one color for if the WG agrees and
have a different color for if the commenter has agreed
with the resolution. Maybe a border.
fantasai: I can make that happen. Most of them were accepted and
the commenter didn't respond. I can go around and try
and accumulate responses, but I just agreed with
everything or deferred.
ChrisL: I agree it's not always easy to get a commenter to
respond, if we already did what they asked.
fantasai: There was follow-up to the NY resolution we discussed
but didn't conclude formally so I'd like a resolution or
that people don't care. People wanted to look at it more.
fantasai: If they haven't looked, we can delay another week while
people look.
fantasai: I don't know. The chairs are responsible to make sure we
have a resolution for the things in the e-mail.
glazou: So...
Florian: Who wanted extra time and how do they feel about it now?
glazou: Nobody apparently.
fantasai: Florian
Florian: Oh, it was me?
Florian: Has the thing happened? I said I was okay with the prose,
but wanted to see examples. Have they been put up?
fantasai: No, they haven't.
fantasai: The issue is I have a box with borders and margin and
padding and it has box-decoration-break. Inside, several
levels deep, there's a heading that forces a break.
Should there be a margin at the top of the page due to
the cloning of the outer box.
Florian: I remember the discussion. It still makes sense to me. If
it's just me don't block. I wasn't sure which way to go
because there wasn't a use case to help me decide. The
argument made sense in general. If it's just me, go ahead.
glazou: Objections to the proposed change?
glazou: [reads minutes] It sounds like consensus but we were
waiting on a final decision.
RESOLVED: Accept the change for behavior of cloned margins at
breaks.
glazou: Anything else?
fantasai: That's it.
fantasai: We need a resolution for CR
glazou: Transition request and edits and everything, yeah. We need
a resolution. Everyone okay with moving the document to CR?
RESOLVED: Publish Fragmentation as CR
glazou: Who will handle it?
fantasai: Probably me.
glazou: Thank you.
* fantasai needs to make the DoC more colorful, then will hand
over to ChrisL
Prefixing Policy
----------------
<glazou> https://drafts.csswg.org/css-2015/#experimental
glazou: I reviewed it and I have a few comments as a regular
member.
glazou: In section 3.3.1 you don't mention prefixing, but it is in
3.3.2 and 3.3.3 but it doesn't say what prefixing is.
glazou: I didn't understand the difference in prefixing between
the other sections and this one. Overall I think it's good
enough.
fantasai: I can take an action for those clarifications.
ACTION fantasai make clarifications of what prefixing is in 3.3.2
and 3.3.3
<trackbot> Created ACTION-721
glazou: Any other comments on that section?
fantasai: I think Microsoft and Apple wanted to take it back for
review. If they need more time we need to give it.
gregwhitworth: I'll send it around. Most of the stuff we had
concerns on we had addressed, but I'll send it
around and say I need it for next week.
glazou: I'm not sure we have anyone from Apple, but can you drop a
message to smfr to do the same?
fantasai: I can.
Accessibility Requirements on Authoring Tools
---------------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Aug/0348.html
fantasai: I had an action to come up with the wording. I sent it
to the list. If people are happy with it we can add it
to grid and flexbox.
bcampbell: I like the wording and I'd like to run it by a couple
people. I can do that really quickly and get back on
that.
glazou: Can it wait for bcampbell?
fantasai: Yes, but I'd like to hear from the rest of the group. If
everyone else is okay we can maybe do a resolution
pending bcampbell's feedback.
glazou: I have no problem with the wording.
Florian: I agree with the intent and the wording.
dauwhe: I like the wording.
TabAtkins: I'm fine with the wording.
Rossen: I LOVE the wording.
glazou: Objections?
RESOLVED: Accept the new wording pending bcampbell's feedback.
bkardell: There were some related discussions on the mailing list
about the a11y.
bkardell: Effectively I guess...do we need to strongly push the
same sort of understanding to authors that we're pushing
to the tooling? Even just today Mozilla Hacks posted an
article saying that the order of content in HTML markup
isn't important anymore.
bkardell: Everyone I've spoken to said that there is an impression
and their want/desire, but it isn't true.
fantasai: We've done as much as we can in the spec to emphasize to
authors. This is for authoring tools. We have warnings
to authors in every section. I think what people have an
impression of depends on who you're talking to. The
authors that speak at conferences understand it's so you
can give the source order in a logical manner.
fantasai: The problem is the people writing tutorials and articles
on 'order' aren't viewing it as important. I think we
can do some evangelizing on that. I don't see how much
else we can do in the spec.
bkardell: Yes. And make sure all the examples demonstrate good
source order and call it out in the examples.
fantasai: If you see anywhere we need to call it out more, please
let us know, but I think in all the cases where we used
order we explained it. If you find specific places where
we forgot, please send us feedback on that.
glazou: Okay. We have a resolution. We can move on.
<fantasai> bkardell, send me a link to the Mozilla Hacks article?
<bkardell> moz hacks article
https://hacks.mozilla.org/2015/09/the-future-of-layout-with-css-grid-layouts/
Baselines of Flex and Grid Containers
-------------------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Aug/0345.html
fantasai: This was an issue of what do we do to find the baseline
of a flex container. If you have a flex container that
has stuff inside it and that itself is being baseline-
aligned because it's in a table cell or whatever, it
needs to have a position that is its baseline.
fantasai: The rule we have now is if some of the items are
baseline-aligned, we use that. If none of them do, we
take the baseline of the first item. If that doesn't
have any text we synthesize a baseline by taking the
bottom of the content box. timeless pointed out that
instead of taking the first item and giving up, why not
keep looking for an item with text and use that and only
give up and synthesize when none have text.
fantasai: I don't have a strong opinion. Just using the first item
is probably slightly easier to implement. The other is
slightly more logical. I'd like to hear from the group
what they'd like to do. It's all summarized in the
e-mail.
glazou: Opinions?
dbaron: If an author wants an item to be the baseline, they can
baseline-align that so it doesn't seem worth the
complexity in the defaults.
fantasai: Anybody else with an opinion? If not we'll no change.
Rossen: The proposal is no change?
fantasai: We're proposing no change. timeless is proposing a
change.
Rossen: I'm for no change.
glazou: Other opinions?
glazou: It's hard to declare consensus with one opinion.
<TabAtkins> I'm fine with no change.
fantasai: Everyone that has spoken is for no change.
glazou: Objections to no change?
RESOLVED: no change for baselines and flex and grid containers
Reverting '0' -> '0%' Change
----------------------------
fantasai: In the distant past we took Flexbox to CR and got a
comment from dholbert where if you have a column-flex
container and the container is auto-height it can become
0 which isn't useful. We changed how the keyword works
where instead of that having a flex-basis of 0 we
changed it to 0% because it gets treated as auto when in
a box with unconstrained dimensions.
fantasai: There's another section that defined intrinsic sizes of
flex containers, though, and it handles this better. You
do the max-content size calculation and that preserves
the height. So this is taken care of in a way that makes
sense so we should revert the change for how we expand
the shorthand.
fantasai: What would change are the use cases where someone set
flex: 1 or flex: 3 or some integer and hasn't done
flex-basis in an auto-height flex container. I believe
that was broken in some earlier implementations so in
those cases it wouldn't have been useful.
fantasai: Also with the 0% change it gives you the same results as
if you had specified auto or not put anything. So it
seems unlikely authors would have done this
intentionally. So switching back won't cause compat
concern, but it will get us better behavior going
forward.
fantasai: It allows for a useful behavior that authors might want
which is I want all the items of equal height but at
least tall enough to contain the tallest item which is
the behavior from the intrinsic sizing rule.
fantasai: I discussed this with TabAtkins and Rossen and we think
this is the right change to make. But this is
substantial so I want to hear if the rest of the group
is okay. Christian Biesinger has concerns that this
might cause web compat if authors are using the behavior.
I haven't measured that, but it's unlikely they're using
this in this context since it's not significantly
different than the auto behavior.
<fantasai> The situation that triggers this is *column* flex
container with auto height, flex items with
'flex: <integer>' as a declaration
glazou: Opinions?
<TabAtkins> I can no longer reason about it, but when I did have
this loaded into my head, I agreed with it.
<dbaron> Which implementation is willing to make the change first?
Rossen: This is one of those things that's going to be hard to
measure based on querying web content. We can see if
people are using it as specified values. My guess is
people aren't. I want to echo fantasai's summary that it
was a terrible hack and now we have a better way to do it
so there's no reason to keep the hack.
Rossen: Any tools currently using it will change as soon as the
implementation changes.
Rossen: To dbaron's question as to which implementor will go
first, whomever is shipping the soonest.
Florian: So you don't have an issue with being first if releases
happen that way?
Rossen: If we have a shipping vehicle where we can put it out
there soon, we don't mind.
Rossen: There's usually other implementors that ship quicker than
we do, so we'll see who beats us to the punch.
Florian: But you're not waiting for someone to get to market.
dbaron: I'm inclined to think we should wait until someone else
does it first.
Rossen: At the least we can do a crawl with a modified version of
our platform and see if any breakage comes back.
Florian: TabAtkins since you're in favor and ship frequently, is
there a chance you'd be testing how well this goes?
TabAtkins: We'd be willing to test it.
glazou: Do I hear correctly we want to wait until an
implementation ships?
Florian: I think the 'we' was Mozilla.
Rossen: Why do they want to wait?
Florian: Concerns on webcompat. I heard that we're willing to
resolve, but they want to wait to make the change until
someone else does.
Rossen: I think this was something we added in Sophia last year.
Given that implementations have only done this for fairly
short period of time, do we really believe that there will
be that big of a compat hit?
fantasai: If we agree this is right, our only concern is
webcompat, we should resolve to make the change and note
in the spec there's a chance there might be a webcompat
issue.
fantasai: This gives implementers the go ahead to make the change,
and we can revisit if it turns out to be a problem.
Florian: Sounds good.
Rossen: Sounds good to me. I don't want to hold the spec for that
one issue.
glazou: So any objection to that proposal?
glazou: dbaron?
<dbaron> I'm fine with it.
glazou: Thanks dbaron. No objections?
RESOLVED: Make the change and note in the spec there's a chance
there might be a webcompat issue.
Simplification of auto-repeat
-----------------------------
<glazou> https://lists.w3.org/Archives/Public/www-style/2015Aug/0342.html
<fantasai> https://drafts.csswg.org/css-grid/#repeat-notation
fantasai: The auto-repeat syntax allows for repeating an entire
track listing. Most use cases would be handled by a
single track which might be worth simplifying to for
level one. So the proposal is to restrict auto-fill and
auto-fit to only take a single track size as an argument.
fantasai: I don't know many cases where you would need multiple
track sizes now that we have gutters. The only case
that's come up is if you have items with sub grids in
which case being able to repeat a track listing would be
helpful.
<Rossen> what happens with something like repeat(auto-fill, 100px)
auto
<TabAtkins> As responded in the list, I'm fine with this
restriction; I think most use-cases are addressed with
it. I have no problem with keeping it unrestricted as
well, tho.
<TabAtkins> Rossen: That's illegal at the grammar level.
<Rossen> what about repeat(auto-fill, min-content)
<TabAtkins> The repeat(auto*) functions are only allowed in a
"definite lengths only" variant of the track-list
grammar.
fantasai: Track listings inside the auto-repeat can only be fixed
sizes.
Rossen: What happens when...It will have a non-trivial interaction
with auto-placement, but also when you have auto-fill
min-content where the size depends on the last piece of
content.
fantasai: We forbid that. The way the algorithm works is you need
to know how many columns you have before you can do
placement, and you need to do placement before you can
size the columns. So if you're going to do as many
columns as will fit, you have to give a concrete size.
Rossen: Okay, that makes sense.
glazou: Objections to the proposal? To restrict auto-fill and
auto-fit to only take single track sizes as an argument.
astearns: I'm concerned we haven't IDed a use case for this.
Gutters was certainly the most present one, but I think
this might be prematurely restricting the expressivity
of auto-repeat
<TabAtkins> Haven't identified? They were presented in the emails
that asked for the feature.
<astearns> sorry, expressed that badly. I'm concerned that there
may be use cases for repetitions of multiple track
sizes that we aren't considering
Rossen: We can always decide to move this to level 2 if it happens
to be not very useful or hard to implement.
fantasai: I can call it out as an issue. There's two ways to
handle it. Right now the spec says we could simplify
this down. I could switch that so that the spec says the
single track and put in an issue that the WG isn't aware
of significant use cases for multiple track listings and
if you have any, please make us aware. We have a few
months before CR so we can put a call out.
fantasai: If people come back with use cases we can expand out the
spec. If nobody comes back with anything we can turn the
issue into a note that in a future level it may be
expanded. Or we leave the spec as-is and keep asking for
use cases to make it more interesting.
glazou: Does that sound like a plan? Any preference?
<astearns> I'm fine with leaving multiple track size repetitions
as a future expansion
Rossen: Any preference to...
glazou: There are two ways to handle it, she said, and highlighted
the two ways.
Rossen: I prefer the second. Don't clutter the spec.
<fantasai> a) Ask for use cases, leave spec with full track-listing
<fantasai> b) Simplify spec. Leave issue open asking for use
cases, and switch back if needed. Turn the issue
into a note at CR saying a future level might expand.
glazou: So fantasai Just typed in IRC [reads IRC]
<astearns> b sounds good to me
<Rossen> B
glazou: So astearns and Rossen say B. Other opinions?
<gregwhitworth> B
<TabAtkins> B
<Bert> abstain
glazou: A few opinions for B.
glazou: Objections to B?
RESOLVED: Simplify spec. Leave issue open asking for use cases,
and switch back if needed. Turn the issue into a note at
CR saying a future level might expand.
Drop Group Snapping from Level 1
--------------------------------
glazou: The next item about group snapping, might require someone
from Apple.
myles: I'm from Apple, but I'm not comfortable discussing this.
<TabAtkins> I'm fine with dropping; I think it's valuable, but not
necessary for level 1.
Grid
----
fantasai: Can we get a resolution to republish Grid?
glazou: Absolutely. In favor? Against?
<TabAtkins> In favor. ^_^
<Bert> +1 publish
<ChrisL> +1
<dauwhe> Yep
<astearns> +1
Florian: Sure.
<glazou> +1
RESOLVED: Republish Grid with the changes discussed above
fantasai: There's a couple of things we need to clean up in the
internals, but we're pretty much done so we're going to
issue a last call for review and hopefully get
everything wrapped up for TPAC.
ACTION everyone review Grid
Drop Group Snapping from Level 1
--------------------------------
Florian: In general I think discussing scroll snap is good. With
regards to dropping group snapping, it's not something
anyone has.
Florian: Details of snapping if Apple needs time, let's take time.
In regards to dropping group snapping, I don't think we
should be gated since that was introduced in the new
model as something we can do, but not something we had to
do.
MaRakow: Group snapping isn't in level 1 currently. There was
thought we wanted to put in before formalizing the
proposal.
Florian: The one I'm speaking of is the proposal from TabAtkins
and fantasai to replace the current level 1.
fantasai: We can sort it out later. It's not controversial.
Transforms, Transitions, and Animations
---------------------------------------
glazou: We need to make progress on that front. I got the messages
about what needs to be done and what's going to be done. I
wanted to say these are very visible specs and we need to
move one with them. I'm going to review the other specs on
our radar to see if we're lagging on any other specs and
what has to be done. We can discuss that at TPAC.
glazou: We have 5 minutes left. Anyone want to discuss something?
Japanese Industry Meeting
-------------------------
Florian: As a quick note...I don't think there's an official
message on the mailing list. We discussed the official
Japanese Industry meeting during TPAC and from what I've
heard they're looking at Sunday afternoon. I think an
official response is pending soon, but you may want to
take that into account in your plans.
glazou: Can you explain for those of us that weren't at the F2F?
Florian: The idea is that Japanese companies are interested in
things like layout and writing-mode and they'd like to
meet us. We're setting up a time for that and it's
probably Sunday afternoon before TPAC.
glazou: Anything else?
glazou: Okay. It's a shorter call. Thank you very much and see you
next week.
Received on Wednesday, 9 September 2015 20:01:27 UTC