W3C home > Mailing lists > Public > www-style@w3.org > December 2011

[CSSWG] Minutes and Resolutions Telecon 2011-12-07

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 08 Dec 2011 14:45:58 -0800
Message-ID: <4EE13E26.30900@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*

   - UTR50 review period closes in January. If you have feedback on orienting
     glyphs in vertical layout, make sure you review it and send comments by
   - RESOLUTION: column-spanning elements can only span when the closest
                 ancestor BFC is established by the multicol (whether by
                 the columns or the multicol)
   - RESOLVED: each column spanning element establishes a separate BFC (option C);
               margins between them collapse
   - RESOLVED: Glenn and Shane coedit cssom and cssom-view
   - RESOLVED: Florian and Sylvain become coeditors of css3-mediaqueries
   - fantasai to check in update to http://www.w3.org/Style/CSS/current-work

====== Full minutes below ======

   Glenn Adams
   Rossen Atanassov
   Tab Atkins (late)
   David Baron
   Bert Bos
   Tantek Çelik
   John Daggett
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Vincent Hardy
   Koji Ishii
   John Jansen
   Brad Kemper
   Håkon Wium Lie
   Peter Linss
   Eric Mueller
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   Steve Zilles

   If you're missing from this list, then next time either a) tell Zakim you're
   here or b) say something that's minuted so I know you're present. :)

   César Acebal
   Kimberly Blessing
   Chris Lilley
   David Storey
   Daniel Weck

<RRSAgent> logging to http://www.w3.org/2011/12/07-css-irc
Scribe: dbaron
Meeting: CSS WG Teleconference
Chair: Daniel Glazman
Scribe: David Baron


   glazou: any extra items?  Tab wanted to add item on switching back to
           fantasai's current-work listing
   glazou: I suggest doing that after the high-priority items.

Bucharest meeting in May

   glazou: Sent email to list to confirm the dates of the meeting.
   glazou: Vincent, can we confirm the dates?
   Vincent: May 9-10-11 (Wed-Thu-Fri)
   Vincent: FX meeting with SVG would be Wednesday morning
   glazou: When to expect hotel recommendations?
   ACTION Vincent provide recommended hotels for Bucharest meeting ASAP
   <trackbot> Created ACTION-407
   jdaggett: is there a wiki page with address of venue, etc.?
   ACTION vincent to make wiki page for Bucharest with location of meeting, etc.
   <trackbot> Created ACTION-408
   <tantek> I updated http://wiki.csswg.org/planning/2012 per the confirmed
            Bucharest dates above.

Multicol spanner margins

   <glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0138.html
   <glazou> http://www.w3.org/mid/4ED416B1.7070902@inkedblade.net
   glazou: previously waiting for fantasai to post blog
   fantasai: That's been done
   <fantasai> http://www.css3.info/multi-column-margin-collapse/
   glazou: We decided to make a decision this week.
   rossen: Can we do this as the second item, in 5 minutes?

Update on Unicode TR50

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0249.html
   jdaggett: This is text-orientation; action was for Sylvain and Ted to
             get feedback from Microsoft and Apple.
   sylvain: ... would come back to me with details on latest version of note.
            Chatted with Elika last time.  Sergei will have another look at it
            and I'll share what he says on the list.
   sylvain: We've provided feedback in the past; Sergei's been busy with other
   jdaggett: At the UTC meeting there were some MSFT reps. Peter Constable ...
             he'd tell you who else was there.
   jdaggett: They were talking about other proposals.
   fantasai: What they were proposing was different from what Sergei was saying
             when I talked to him.

   Ted: I've got the conversation going internally, waiting to get more useful
        feedback for list/wiki.
   Ted: Like Sylvain I don't have the knowledge myself.
   Ted: My knee-jerk reaction is that if WebKit and IE agree we should go
        with that, but I'll have some feedback on the list as soon as I can.
   jdaggett: Especially helpful would be if there are things that seem bad
             to you about the actual proposal.
   Sylvain: What kind of timeline?  Something needed before the new year?
   jdaggett: Concerned about that, since second round of comments has been
             extended to mid-January, but if we're not careful we'll miss that.
   glazou: need an action?
   jdaggett: have 2 existing

Multicol spanning margins

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0138.html
   <glazou> ACTION howcome to repost his message to www-style
   <trackbot> Created ACTION-409
   See http://lists.w3.org/Archives/Public/www-style/2011Sep/0509.html

   howcome: Certainly an issue we'd like to settle, hopefully today.
   howcome: I don't see this as a major issue; it's a corner case, but will
            have implications for authors.
   howcome: We'd published a blog on the topic.  I'm not quite up-to-date with
            the feedback on that post, but it's been made.

   <fantasai> http://www.css3.info/multi-column-margin-collapse/
   fantasai: I can summarize the feedback.
   fantasai: The blog post tried to get people to imagine the scenario we're
             envisioning, and shows the 2 options we're considering.
   fantasai: Most of the comments say collapsed margins for consistency with
             the rest of CSS.
   fantasai: A few suggest no collapsing.
   fantasai: A few wanted not collapsing for consistency with block flow
             (which doesn't make sense).
   florian: A few said they wanted no collapsing in CSS.
   fantasai: And some suggestions for a margin collapsing control property.
   fantasai: But most suggestions seemed to want collapsing just like regular

   howcome: I think if the example had column-span set to 2 out of 3 columns,
            it might have been slightly different.  That's a futuristic case.
   florian: Even if we agree that collapsing is better, it doesn't tell us
            whether we should prefer solution A or C.
   fantasai: I was talking with Kimberly while we were working on this blog
             post.  The mental model she had (with picture) was that you
             have a multicolumn element, then you have a row of columns before
             the spanner, then the spanners, and then a row of multicolumn
             elements after the spanners.  The model was that the row of
             columns was a row of columns but it behaved as a block-level
             element that was a sibling of all of the spanners.
   fantasai: And inside the block-level element you had regular block flow
             with the rows of columns being a special block-level box.
   anton: At the moment that mental model makes sense because columns can't
          have vertical margin because they can't be targeted with a selector,
          but in future they might be able to be targeted.
   anton: So if the columns themselves had bottom margin, would we expect that
          to collapse with whatever comes next?
   anton: I'd expect the margins on the columns themselves not to collapse.
   anton: I think what's important is the inter-spanner relationship rather
          than the beginning/end of the spanners.
   * fantasai thinks allowing margins on columns would be like allowing margins
              on table cells, i.e. wouldn't make sense even if we allowed
              styling those boxes
   florian: Even for inter-spanner behavior A and C propose different things:
            margin collapsing was the same but floating was not.
   <glazou> slower antonp please
   anton: Makes sense to allow floats to behave as in normal block flow.
   rossen: Would you expect floats to expect flow of column?
   ?: no, not in flow of column
   anton: spanners in A or C are wrapped in a BFC.  Question is whether each
          wrapped independently or all in one.
   rossen: In B you don't have a BFC; they are BFC.
   florian: B is ruled out by the poll
   anton: If there's just one spanner it's still wrapped in a BFC (in A), but
          if there are 2 or 3 they would all be wrapped in a BFC.
   <florianr> In A, spanners are not individually BFCs, but their are together
              wrapped in an anonymous one
   <florianr> in C, each spanner is a BFC
   Håkon: my preference is C
   <fantasai> D, each column row is a BFC and everything else just behaves
              like regular block flow

   rossen: In the blog post the example is oversimplified; just text and
           spanners.  Would like to see example that's more complicated, e.g.,
           tables in the column and the spanners coming from deep inside the
   florian: That's probably something we don't want to support at all.
   rossen: Then I'd want spanners to come only from the BFC level of the column.
   florian: After talking w/ implementors, would be comfortable with that.
   sylvain: Things become really weird otherwise.
   florian: The property just doesn't do anything when you apply it on something
            "too deep"
   anton: Restrict it to the BFC.  A spanner can't escape from a BFC.
   florian: We can argue back and forth; we certainly want to forbid things
            that are way too deep like inside a table.
   rossen: The first time I looked at it, the deeper structures were the
           problem I ran into it.  That makes collapsing pretty hairy.
   rossen: Everyone seems to be ignoring the general case.
   rossen: Either we say this is level 1 only or ??? ???
   florian: I don't think anyone wants to span things that come from deep down,
            and I think we should resolve on that.
   Håkon: ...
   Sylvain: We just need to define what Rossen means.
   fantasai: I suggest we resolve that the spanner has to be in the same BFC
             as the main level of the column content.
   Håkon: someone suggested making each column a BFC
   anton: but I've gone off that idea
   glazou: I'm almost hearing consensus.
   Rossen: BFC or non-BFC-ness of spanners themselves... not resolved
   florian: we should resolve on that first
   Sylvain: I've heard a couple of definitions of level 1 already.
   Sylvain & florian talk at the same time
   Sylvain: We agree that spanning should be scoped at some level.
   Rossen: to the BFC of the column
   Håkon: definition of spanning is that the element spans across all columns
          of the nearest multicol ancestor of the same BFC
   <howcome> The element spans across all columns of the nearest multicol
   <howcome>     ancestor of the same block formatting context.
   anton: we might need to tinker with that wording
   anton: question is whether spanner can escape inline-block
   <howcome> Proposed definition of spanner: The element spans across all
             columns of the nearest multicol ancestor of the same block
             formatting context.
   dbaron: How could a multi-column not establish a BFC?
   RESOLUTION: column-spanning elements can only span when the closest
               ancestor BFC is established by the multicol (whether by
               the columns or the multicol)
   ?: need an action for somebody to propose wording for this
   Rossen: I can write it
   ACTION rossen propose wording for column-spanning elements can only span
                 when the closest ancestor BFC is established by the multicol
                 (whether by the columns or the multicol)
   <trackbot> Created ACTION-410

   glazou: Back to the choice between A and C.
   fantasai: and D
   fantasai: D is where the multicolumn element establishes a block formatting
             context and column spanning elements are treated as regular blocks
             and each column row is a block level BFC within the multicol BFC
   fantasai: It's like the table element having an outer table that has the
             captions and the table box
   florian: This D model wouldn't play nice with the ability to select
            individual columns and do things with them (in the future).
   rossen: Especially if multicolumns are going towards ??? columns that
           Håkon was proposing.
   Håkon: Can't we just pick one of A and C ?
   fantasai: That's just what came out of the discussion I had with Kimberly.
             Though we didn't discuss floats.
   Rossen: On option A, if we were going to go with the non-BFC behavior where
           floats can affect subsequent spanning elements, what would be
           drawing order and who would be drawing floats?
   Rossen: You meant(?) anonymous BFC; in our implementation we have nothing
           of this sort.
   Rossen: Option C seems fairly consistent: spanners will collapse margins
           between themselves and keep everything else to themselves.

   Florian: There is another difference between A and C:  if the spanner
            itself has children do the margins of the children collapse with
            things in the next spanner.  In C they don't; in A they do.
   Rossen/Florian: Also if there is an empty spanner between 2 non-empty
   Anton: It depends what you want these spanners to be.  If you want them
          to look like normal block formatting then they ought to collapse.
          If they're each individually special then it's fine that they don't.
   Rossen: I think they're each individually special.
   Rossen: At the end of the day we're taking the spanners out of the flow
           and collapsing the margins between the spanners themselves.
   Rossen: Whether or not we have to treate empty spanners the way we treat
           empty blocks today.  But if we're taking them out of the block
           flow and collapsing margins in between them, then I don't see a
           reason to make them non-BFC.
   Rossen: There's no other precedent for taking anything out of the flow
           that isn't a BFC.
   Anton: I'm not entirely convinced we're taking stuff out of the flow here.
   Anton: If you've got a spanner you're ending the columns and then starting
          them again.
   Anton: They disrupt the multicol, but they're not out of the flow.
   dbaron: I think they're out of the flow.
   Rossen: They're out of the flow in our implementation apparently.
   fantasai: I see this more like a block-in-inline case.
   fantasai: Jumping out to an outer flow.

   <Bert> I think D works, but there appears to be very little difference
           with A in the visual effect.
   <fantasai> Bert, except when there are margins on the children of the spanner
   <Bert> Ah right. So then I think I actually like D better. :-)
   <fantasai> Oh, wait, no I think you're right!
   <fantasai> A and D are equivalent
   <fantasai> C and D are different

   Håkon: I think we have consensus for C.  I don't hear anyone arguing for A.
   various: does anyone object to C?
   SteveZ: Only mildly.
   SteveZ: I think one of the things fantasai just said: treatment of blocks
           in an inline.  If you look at is a headings it doesn't make much
           sense.  But if you look at it as temporarily switching back to
           single-column, it seems like the user would want those pieces to
           behave as inside one single column.
   Florian: If you want that, you can have a containing element be the spanner
            rather than make several consecutive elements spanners.
   Håkon: As long as you can insert a div around ...
   Steve: I'm not strong on this, just wondering what users will expect.
   Håkon: Float behavior will be different, that's true.
   glazou: Given constraints, I think authors won't meet expectations anyway.
   fantasai: Bert points A and D are equivalent, so I'm leaning towards A.
   fantasai: If we take the premise that a column row stretches across the
             entire column and clears all the floats before it, then A
             expresses that behavior.
   fantasai: Interrupting the column flow and going to a flow that stretches
             across the entire block... can resume multicol afterwards.
   fantasai: Within the anonymous BFC everything is a regular block.
   fantasai: Nothing different from ... except border of multicol box goes
             around everything.
   dbaron: Considering the possibility that we might later move to having
           column spans that don't cross all columns, I think it's much
           better to think of each column spanning element as isolated --
           I'm scared of doing otherwise.  Thus I prefer option C.
   Håkon: implemented ... .  ...
   Florian: Could have strange cases: span:all followed by span:3 would lead
            to weird results if you have 3 columns
   fantasai: I'm happy with C.
   Steve: I can live with C.
   glazou: anyone objecting?
   Florian: Alex, but he's not here?
   RESOLVED: each column spanning element establishes a separate BFC (option C)

Editorship of cssom and cssom-view

   glazou: Anne left the group.
   glazou: We need editors for these documents.
   glazou: Proposal from Glenn to be coeditor.
   Tab: At last TPAC Shane Stevens offered to edit as well.
   jdaggett: Florian offered?
   Florian: For Media Queries
   Sylvain: I can help with MQ too.
   <glenn> is here
   jdaggett: OM is kind of a key spec; also to some extent OM-view.  Is that
             the right spec for people new to the group?  Would be more
             comfortable with somebody with more familiarity.
   Tab: With Shane, I expect I'd be acting as a mentor for that spec.
   jdaggett: I'd feel better if he was working on different specs.
   Glenn: I've implemented cssom and cssom-view and CSS formatting semantics
          in 2 or 3 products.
   glazou: Tab, what's Shane's opinion?
   Tab: He's fine with Glenn being a coeditor.
   Glenn: I'd suggest both Shane and I be assigned as coeditors as a starting
          point, and if others want to help we can change that over time.
   Florian: I think Shane said he was interested in documenting existing
            compatible bits.
   Tab: Yeah, he dosen't want to start working on new stuff until we get
        the existing stuff documented & stable
   Sylvain: I'm more concerned about what we're working on rather than who's
            working on them.
   Sylvain: These are fundamental specs, but were neglected for a long time.
   Glenn: One reason I voluneteered because I'm working with an external org
          called DLNA, which normatively references both of these, and
          identified these as needing significant work to get to CR.
   Sylvain: One issue recently was that DLNA was depending on working drafts,
            and complained when they changed. Are we going to have shenanigans
            of that sort if a draft changes what the previous draft said?
   Glenn: You'd formally objected to a change in css3-fonts because it was
          incompatible with a prior editor's draft.
   Glenn: Formally, DLNA policy does not allow normative ref to anything other
          than final spec (REC in W3C).  They're interested in participating
          to move all the dependencies forward.
   Glenn: The css3-fonts issue I brought up while representing Samsung has
          been closed as far as I'm concerned.  I'm now representing Cox
          Communications in this WG.
   Glenn: I wish to help to move to REC as fast as possible not only these
          specs but other specs I can help with.
   glazou: What this WG would like to see is a schedule for these documents.
           They've been orphaned for a long time; they're crucial for CSS.
   glazou: Do you think this is doable?  Doing the steps to move these
           documents along the rec track.
   Glazou: At least by the end of the year, I'd like to provide a proposed
           schedule for the work.
   Florian: Seems like Shane is interested in documenting the stable bits,
            and Glenn interested in moving to Rec
   Sylvain: What is the work?  Reduce to what's implemented?  Values API?
   Tab: I think 2.1-style: reduce to what's implemented
   Tab: New stuff needs to be in CSSOM level 2.
   glazou: I agree with that
   dbaron: I'd be concerned about moving the new stuff to REC "as fast as
           possible", but if we're splitting that out I have no concern.
   glazou: I think I'm hearing consensus.
   RESOLVED: Glenn and Shane coedit cssom and cssom-view, Florian and Sylvain
             become coeditors of css3-mediaqueries, and we will revisit
             schedules in 2 weeks
   <glenn> thanks, looking forward to accomplishing this work in a timely manner

Moving stuff from css3-text to level 4

   <glazou> http://lists.w3.org/Archives/Public/www-style/2011Nov/0395.html
   fantasai: That'll take more than 2 minutes
   Tab: unless we agree to just do what fantasai's saying


   Tab: It's been more than a month; new page should be up.
   Tab: what do we need to do to make this happen?
   Tab: Bert, if there's still work you need to do, let me help you with it
   Bert: I started discussing with fantasai on common list of drafts.
         Long to do list.  The content is what I'm worried about.
   Tab: The content that fantasai proposed is much more useful than what's
        there right now.
   Tab: we can tweak it after it's up
   glazou: I agree with that.
   Bert: I'm not so sure that content is useful.
   glazou: We had a resolution on that
   * fantasai notes we don't actually, we only have an action item
   Bert: You had a resolution that you think it's more useful.
   glazou: the group
   Bert: I'd like to find some way to integrate that.  The original text that
         Elika proposed is not complete, and there are some distinctions that
         I think shouldn't be made.
   Tab: Let us do that afterwards.
   glazou: It's better.
   Bert: I don't see that -- there are so many categories: what do they mean?
   Tab: They mean the English names of the categories, and arranged in order
        of stabilization.
   glazou: we have a resolution
   fantasai: not technically...
   Bert: I have a lot of freedom in making these pages, but I still have
         responsibility there: I'm making them on behalf of the W3C not on
         behalf of the working group.
   Bert: We don't have a list that ... happy with ... agreed on.
   fantasai: You sent me a list that was a slightly modified version of mine.
             We seem to be pretty close with the exception of naming one of
             the sections.  Why can't we move to that?
   Bert: I haven't looked at your list with that in mind
   fantasai: Only changes I suggested to that was keeping hte section on
             abandoned specs, and switching the location of css3-ui in list
   Bert: I think that list is fine.
   glazou: This is part of the outreach of the wg
   glazou: We have to close that issue
   glazou: Bert, I want you to do that change as soon as possible.
   Bert: It will be done within the next week and a half.
   glazou: That's the best you can do?
   Bert: I have things to do tomorrow and the day after.
   Tab: Can one of us publish the page, then?
   Bert: I guess fantasai can.
   glazou: Let's do that.
   fantasai: I don't know the structural dependencies
   Bert: keep ids 'completed' and 'high-prio'
   ACTION fantasai update the current-work page
   <trackbot> Created ACTION-411
Received on Thursday, 8 December 2011 22:46:29 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:07 UTC