W3C home > Mailing lists > Public > www-style@w3.org > May 2013

[CSSWG] Minutes Telecon 2013-05-01

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 02 May 2013 11:40:09 -0700
Message-ID: <5182B309.8030208@inkedblade.net>
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

This archive was generated by hypermail 2.3.1 : Thursday, 2 May 2013 18:40:38 UTC