- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 02 May 2013 11:40:09 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Move existing Template Layout doc on TR to Note, and keep the ED
- Tokyo F2F location moved from Mozilla office to Google office
- RESOLVED: Rebecca Hauck takes over testing ownership from fantasai
- RESOLVED: Paris F2F at Mozilla Sept 11-13
- Reviewed CSS3 Fonts issues
- Discussed issues with overflowing floats in multicol
http://lists.w3.org/Archives/Public/www-style/2013Apr/0639.html
- RESOLVED: In grid, percentages work as per block layout, not as per
table layout
- RESOLVED: auto margins specified on grid items override the align-self
property values, like they do in other layout modules such
as flexbox (and also block)
====== Full minutes below ======
Present:
Glenn Adams
Tab Atkins
David Baron
Tantek Çelik
Jim Dovey
Elika Etemad
Sylvain Galineau
Rebecca Hauck
Philippe Le Hégaret
Dael Jackson
Peter Linss
Anton Prowse
Matt Rakow
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Lea Verou
Steve Zilles
Agenda: http://lists.w3.org/Archives/Public/www-style/2013May/0001.html
Scribe: antonp
<dbaron> hmmm, I'm pretty sure there were some edits I wrote for the float
placement rules in CSS 2.1 that aren't in the spec
<dbaron> to address http://lists.w3.org/Archives/Public/www-style/2009Jan/0445.html
Administrative
--------------
<dbaron> could we add September meeting dates/location to the agenda?
<glazou> sure dbaron
glazou: f2f Sept place/date
Publishing Template Layout
--------------------------
glazou: grid template layout
<leaverou> http://dev.w3.org/csswg/css-template/
glazou: Has anyone reviewed the doc?
TabAtkins: My objection is already noted in the e-mails. This is the
same functionality as grid; we shouldn't have two specs doing
the same thing.
glazou: I made the same comment last week. And I don't see any implementor
commitment.
glazou: I'd like to reach a consensus here. Should we publish?
Rossen: I think we don't need it
Rossen: spirit is captured in the other grid spec.
<SimonSapin> agreed on not duplicating functionality, fwiw
glazou: opinions from Apple?
glazou: I don't hear a consensus. I suggest we defer, and in the future
consider dropping it.
glazou: right now, the WG seems unlikely to pursue it
TabAtkins: some of the stuff in that doc could be relevant to level 2
of the other grid spec
TabAtkins: I'm happy keeping the spec as an ED
glazou: that's fine by me
sgalineau: We should be clear about the status, not give it an ambiguous
status.
fantasai: It does make sense to update the WD, because the one that's
live is old. But we should add a note saying that grid
functionality is in the other spec and that the ideas in this
spec are exploratory.
TabAtkins: We have some specs with a not-ready-for-implementation notice
on them; we could do something similar.
<sgalineau> +1 to fantasai's suggestion to make sure any new WD no longer
includes things that are defined in grid layout
fantasai: We should update the TR page one way or the other
glazou: Updating and adding a warning (Defer to grid spec) gives two
different signals
glazou: I don't think we should publish.
glazou: Add a note to 20-11 doc saying that it's obsolete. Link to the
ED (if needed). And link to the grid spec
glenn: I don't have any objection to publishing as a note
fantasai: Bert's the editor and I'd prefer if he were on the call where
we decide on it
Tantek: I agree with what Tab was saying
tantek: Want to clarify that even if we publish as a note, the editor's
draft continues
SimonSapin: Does short URL stay the same if it's published as a Note?
<tantek> I asked that it still be kept as an active editor's draft
RESOLVED: Move existing doc on TR to Note, and keep the ED
fantasai: Still uncomfortable resolving without Bert
Lea: So am I
glazou: Bert was aware that we were going to review the doc today.
Publishing Box Alignment
------------------------
fantasai: Last week, people wanted time to review
fantasai: We can either publish or wait longer
fantasai: Not high priority to publish
<SteveZ> I still need to review baseline
Rossen: I'd like another week to review
glazou: OK, another week to review
Tokyo F2F Details
-----------------
plinss: John Daggett asked for this
<rhauck1> testtwf is also being held there
TabAtkins: Google can host at their office; it's within walking distance
of the prior location (Mozilla office)
TabAtkins: Your travel and accommodation plans don't need to change.
various: close to other meetings too.
plh: I query that!
dbaron: One could walk, even if the locals don't!
glazou: Please update wiki with your travel info etc
glazou: Please also add regrets
<dbaron> more like a 30 minute walk, I think
Testing Ownership
-----------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0121.html
Rebecca: fantasai recommended that I take over CSSWG testing ownership
Rebecca: Any objections to me taking over that role?
<no objections>
RESOLVED: Rebecca Hauck takes over testing ownership from fantasai
Rebecca: I was going to send a notification to the public list
TPAC
----
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013AprJun/0120.html
glazou: How many people will attend, etc?
<SteveZ> I plan to attend, would like to have our usual Monday Tuesday days
TabAtkins: Rather than an e-mail round-robin, can we use eg wiki
<sgalineau> +1 to SteveZ
<SteveZ> do not conflict with AB
fantasai: For scheduling, can we list which groups not to conflict with.
We can discuss that now.
glazou: We always do Mon and Tue, and the other WGs we're interested in
usually do Thur Fri
glazou: Hopefully it will all be the same again this time
<SteveZ> correct!
glazou: Anyone know any different?
glazou: Apart from John and myself, who is not going to make it?
<tantek> I'm not going to make it
September F2F
-------------
glazou: dbaron wanted to discuss location and dates of Sept meeting
dbaron: We said 9-11 Sept tentatively, others wanted later.
<sgalineau> on my side the request for 11-13 was due to the w3c workshop
right after it
dbaron: We hadn't chosen a location
dbaron: Looks like Mozilla can host in Paris, but would rather get
concrete dates first
dbaron: If possible, dates sooner rather than later please
<tantek> my preference is 11,12 ,13
<leaverou> I can't make 11-13
<leaverou> I have a conference
sgalineau: 11-12-13 to coincide with W3C Publishing workshop the
following Mon and Tues
szilles: I'm neutral on the dates
<Rossen> 11-13 is preferred
leaverou: I have a Brazil conf on 14, so might only make the first day
leaverou: with those suggested dates.
glazou: OK, so it's Paris, 11,12,13 Sept
dbaron: I can deal with that before next week
* leaverou was hoping to be able to attend the September f2f, since I
will miss the June one due to another conf :(
RESOLVED: Paris F2F at Mozilla Sept 11-13
CSS3 Fonts
----------
Topic: @font-face / @font-feature-values rule grammar
plinss: It was jdaggett's issue
SimonSapin: jdaggett updated the draft with a new grammar; I think it's fixed.
Topic: Unicode caseless matching
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0553.html
glazou: We need to reply to Addison
glazou: Any thoughts?
* dbaron suspects jdaggett would have an opinion here
TabAtkins: I'm happy enough, and now that it coincides with jdaggett's
opinion I'm OK with it.
TabAtkins: The thing we discussed at the last F2F is what Addison is
OK with
ACTION on glazou to ping jdaggett to request his formal opinion, then
reply to Addison
<trackbot> Created ACTION-560
* fantasai still doesn't understand why we are not normalizing
Multicol overflowing floats
---------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Apr/0639.html
* fantasai proposes adding SimonSapin as editor of multicol
SimonSapin: multicol spec says that contents in the flow should be
clipped when it overflows the column
SimonSapin: but what about out-of-flow content eg floats and abspos?
SimonSapin: The spec should say something, but what?
SimonSapin: and should we do different things for floats and abspos?
glazou: Should we defer to Hakon?
Rossen: Way back when, I think we discussed something similar (eg a year
ago) where we made it clear that columns establish their own
formatting context and hence floats shouldn't be affecting the
flow in other columns.
Rossen: Or are you talking about fragmentation?
SimonSapin: There are 2 separate issues in what François reported.
Fragmentation in the block direction: the frag spec says
that two possible behaviors are acceptable.
SimonSapin: Other issue is in the inline direction, overflowing into
the next column. If we don't clip, does it affect the line
boxes in the next col?
Rossen: We discussed that. There's a missing paragraph about columns
needing to establish a BFC
Rossen: I don't think that floats that are overflowing from one col to
another should affect anything in the inline flow
Rossen: Equiv of having 2 table cells next to each others
Rossen: Perhaps there's an action on me to add such a paragraph something
* sgalineau recalls discussion about a multicol being a BFC; can't recall
whether column boxes were...
<dbaron> presumably this means floats overflowing horizontally into
another column, rather than being fragmented into the next column?
<SimonSapin> dbaron, François talked about both, but right now we’re
discussing the former
<SimonSapin> oh, no, the latter now
antonp: I also had a bunch of issues that Hakon was discussing, and I
don't think the edits have made it into the spec yet
Rossen: Image in multicol would be monolithic, and I don't think it
should be fragmented. Chrome and Firefox are fragmenting
Rossen: I don't think it's an issue in the multicol spec per se; perhaps
we need to clarify the fragmentation spec.
glazou: But what about the issue that François reported?
SimonSapin: He reported both at once
Rossen: I think we've addressed both questions
Rossen: For fragmentation, we're describing what is monolithic or not.
[...] If something's not clear, action me to clarify it
SimonSapin: Frag spec accepts 2 behaviors but should only accept one IMO.
<SimonSapin> "The UA is not required to fragment the contents of
monolithic elements, and may instead either slice the
element's graphical representation as necessary to
fragment it or treat its box as unbreakable and overflow
the fragmentainer. In both cases it must treat the element
as having ‘break-inside: avoid’, i.e. only slice or
overflow at the fragmentainer edge if there are no possible
break points on the fragmentainer."
Rossen: I need to refresh my memory of this
<SimonSapin> http://dev.w3.org/csswg/css-break/#possible-breaks
SimonSapin: "The UA may either do this or do that"
Rossen: When we discussed with fantasai I remember go over this in length,
trying to figure out when to cut an image and when to leave it.
The idea was that the different fragmentation contexts such as
multicol vs pagination would make their own choice
Rossen: eg in continuous media, multicol + monolithic overflowing box
might be ok, but in pagination a break would make more sense
Rossen: however, there's little interop, and at the time it was hard
to make a call about which should happen when. Multicol is
apparently a victim of that.
Rossen: We can specify multicol explicitly?
SimonSapin: I don't have an opinion on what to do, but don't like that
UAs have a choice
Rossen: I can figure out what to do in the frag spec, though no change
to multicol spec.
szilles: Distinction between interactive situation and non-interactive
situation, eg scrollbar
fantasai: I don't think that's right; it's about whether overflow can
be visible
fantasai: For example, can have an interactive paged display; content
outside the page is still inaccessible.
Rossen: interactive is just one aspect of that
fantasai: in paged media, whether overflow is visible eg depends on the
size of the multicol vs the size of the page
Rossen: The multicol situation is part of a bigger problem which we won't
solve immediately, but perhaps we can deal with multicol earlier.
ACTION: Rossen to figure out what to do in the frag spec, though no
change to multicol spec
<trackbot> Created ACTION-561
Other Topics
------------
* fantasai wonders if we have open issues on Selectors or Grid to discuss
Rossen: Last week there was a discussion about named flows and flowing
into content only. If I read the minutes correctly, was I being
asked to supply use cases??
astearns: Bert was asking for use cases
glazou: we said we'd move that discussion to the mailing list
fantasai: grid layout: Rossen, Tab and I discussed some issues.
fantasai: Question: Percentages do magic things like in tables, or behave
like block (be auto when can't resolve)?
dbaron: I don't think tables are magic; they're just different
<plinss> http://w3cmemes.tumblr.com/post/34634329920/csswg-resolves-to-use-less-magic
* sgalineau made that meme 6 months ago. some jokes have a long fuse...
TabAtkins: I disagree that it's not magic
TabAtkins: [...]
fantasai: Should we investigate (for grid) making percentages behave
as per tables?
dbaron: I'm neutral
Rossen: Sounds like nobody wants magic, apart from dbaron who's neutral
<SimonSapin> "no magic" from me is as an implementer, no idea what’s
better for authors
Rossen: Proposed solution is that percentages work like block and not
like table
RESOLVED: In grid, percentages work as per block layout, not as per
table layout
Rossen: Issue 24 about alignment and how auto margins play, and whether
they win over alignment
fantasai: We decided to make them consistent with flexbox
Rossen: I have an item which e.g. is align-self:right and margin:auto
Rossen: How do we decide if the align property behaviour wins over the
legacy auto margin behaviour?
Rossen: Tab pointed out that the alignment spec already says that the
legacy auto margin wins
Rossen: Consensus is that we'll also take this into grid spec
Rossen: Personally I'd prefer it the other way around, but if everyone
else is happy with legacy auto margin winning then I can live
with that
* dbaron didn't follow the issue
TabAtkins: Alignment only applies if the margins are non-auto
TabAtkins: I don't actually really think it's legacy, but anyhow I just
want to maintain it.
Rossen: auto margins specified on grid items override the align-self
property values, like they do in other layout modules such as
flexbox (and also block)
RESOLVED: auto margins specified on grid items override the align-self
property values, like they do in other layout modules such
as flexbox (and also block)
<fantasai> dbaron, it's whether alignment with auto margins or alignment
with alignment properties wins when both are specified
Meeting closed.
<dbaron> When we're done with the agenda, could we close the meeting rather
than try to stretch it out to fill the whole hour?
<TabAtkins> dbaron: I think this is more a revisiting of the "additional
agenda topics?" question.
<stearns> I thought it was useful to resolve the two additional things
<glazou> yep
<dbaron> things take a lot less time if people are prepared to discuss them
<dbaron> I also didn't follow most of what was discussed there, though
the resolution sounded fine
<dbaron> there was about 10 minutes of explanation leading to it that I
didn't follow
<dbaron> I also don't think useful decisions are made after 5 minutes of
thought.
<dbaron> It's better to either defer to the editors entirely, or give
people a chance to think about the issue.
<glazou> dbaron, then you should say it when I ask for comments?
<stearns> fair enough - I think both of those could have been editor's calls
<dbaron> ok, I'll say so next time
<dbaron> The "filling time" at the end tends to be much less efficient than
the rest of the telecon.
<tantek> I too am ok with ending the call early unless someone brings up
an *urgent* agenda item.
<tantek> "any other agenda items" can probably be left to just discuss on
email instead, and if they require telecon time, they can get time
next week.
Received on Thursday, 2 May 2013 18:40:38 UTC