[CSSWG] Minutes Telecon 2012-10-10

Summary:

   - RESOLVED: Defer @document
   - RESOLVED: Defer issue on @import syntax for @supports queries
   - RESOLVED: Publish LC of css3-conditional
   - RESOLVED: Put 'clip' property into the Masking spec.
   - RESOLVED: Accept the definitions for additional baselines in the
               Flexbox spec
   - RESOLVED: i18nWG to maintain the informative @counter-style rules.
   - Discussed circular dependencies between flows
   - Discussed multi-col intrinsic sizing. See
       http://lists.w3.org/Archives/Public/www-style/2012Oct/0226.html
     for proposed changes to css3-multicol and
       http://lists.w3.org/Archives/Public/www-style/2012Oct/0225.html
     for discussion of proposed algorithm (css3-sizing)

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

Present:

   Tab Atkins
   Ryan Betts
   Tantek Çelik
   Arron Eicholz
   Elika Etemad (late)
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Rebecca Hauck
   Koji Ishii
   John Jansen
   Edward O'Connor
   Anton Prowse
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Steve Zilles

Regrets: Bert, dbaron, florian, Chris, kenneth, Lea, plinss

<heycam> it's not urgent, but did the review of new SVG properties get
          discussed again? IIRC dbaron asked for it to be deferred for
          a week but then it never came back on the agenda.
<RRSAgent> logging to http://www.w3.org/2012/10/10-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Oct/0223.html

Scribe: TabAtkins

CSS3 Conditional
----------------

   glazou: First item, taking CSS3 Conditional to LC.
   TabAtkins: A few weeks ago I put up a list of the last few issues in
              the Conditional draft.
   TabAtkins: I resolved two of them, and the remaining two are just
              "punt stuff to level 4".
   SimonSapin: I had an issue about allowing functions in the grammar for
               future compat.
   TabAtkins: Done now, and dbaron approved it.  It's in the at-risk list.
   RESOLVED: Publish CSS3 Conditional as LCWD.
   fantasai: Want to confirm as part of this resolution, we're dropping
             the @import addition and @document to the next level?
   TabAtkins: Yup.
   RESOLVED: Drop @document
   RESOLVED: Defer issue on @import syntax for @supports queries

text-decoration
---------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Aug/0379.html
   fantasai: I don't have a writeup yet.
   glazou: So defer it again?
   smfr: I don't have feedback yet either.

'clip' property
---------------

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012OctDec/0025.html
   krit: Should we combine 'clip' with the other clip/mask properties into
         the Masking spec?
   krit: I think it makes sense to have them in one collection, and makes
         the merging of SVG and HTML easier with one description in one place.
   <krit> Adding links:
   <krit> http://www.w3.org/TR/SVG/masking.html#OverflowAndClipProperties
   <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
   [discussion about priority of Masking]
   TabAtkins: don't need to worry about priority list unless we are worried
              about running out time in terms of things to talk about.
   szilles: If it didn't go into Masking, where would you put an updated
            version?
   * sylvaing my assumption would be that telcons go in order of priority....
   * smfr agrees with sylvain
   * tantek agrees with TabAtkins, priority list works to sort synchronous
            communication time allocation.
   rossen: Wasn't there discussion about moving 'clip' closer to the exclusion
           shapes?
   rossen: I was just wondering if that might be a more natural place for it.
   TabAtkins: I think that it makes the most sense for 'clip' to go in with
              the rest of Masking, though it will probably want to reference
              Shapes.
   glazou: Any objection?
   RESOLVED: Put 'clip' into the Masking spec.

marker-side vs marker-direction
-------------------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0118.html
   fantasai: Nothing to discuss about that yet.

Circular dependencies between flows
-----------------------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0173.html
   <stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0268.html
   stearns: I just sent a reply to the list about what to do.
   stearns: The question is, when a circular reference occurs, what happens?
   stearns: And what to do when it happens.
   stearns: So I suggest just avoiding them entirely.
   stearns: If you have a circular reference, the entire cycle doesn't
            become regions.
   TabAtkins: I agree - that's how I've dealt with other places where I
              have to track circular references.
   antonp: What's the effect on the content forced into that flow?
   stearns: If you have content using flow-to, and have a flow-from producing
            a circular ref, that flow-from is just ignored.
   antonp: And if that's the only flow-from consuming that flow, it's just
           ignored, because it's piped into a flow that's never consumed.
           That's expected behavior.
   stearns: Yes.

CSS2.1: Baselines of Blocks
---------------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0163.html
   antonp: This was raised by someone saying there was a gap about the fact
           that css3 specs expect everything to have a baseline.
   antonp: But 2.1 doesn't provide a baseline for some things, like blocks
           and tables.
   antonp: To solve an issue specific to Flexbox, Tab put in a note in
           Flexbox specifying those.
   antonp: But I think it's worthwhile to codify that.
   <fantasai> http://dev.w3.org/csswg/css3-flexbox/#flex-baselines
   antonp: The proposal is that tables have baselines, but that doesn't
           contribute toward an inline-block's baseline.
   antonp: So if a table is in an inline-block, the table doesn't contribute -
           it's skipped over during inline-block baseline determination.
   TabAtkins: Yes, we need a reasonable baseline for other things, but for
              legacy reasons inline-blocks need to ignore them.
   antonp: So Tab's basically saying, just, can we ignore the table's own
           baseline when determining the inline-block's baseline?
   antonp: I think it's reasonable.  What do others think?
   TabAtkins: I expect it'll need some more review, but we can at least
              put it somewhere normative and get it moving.
   RESOLVED: Accept the definitions for additional baselines in the Flexbox spec
   <fantasai> for 2.1?

Circular refs in regions
------------------------

   stearns: My proposal addresses the case where an element has the same
            flow in its flow-from and flow-to.  But it doesn't address
            cycles *between* elements.
   TabAtkins: Unclear about how to detect circular references, or how to
              react to cycles once detected?
   stearns: How to specify.
   TabAtkins: I have an example already in Images 4 - look in element().
              You can just copy that.
   glazou: So how to respond?
   stearns: [something that I missed about breaking one of the refs to
             avoid a cycle]
   antonp: Is all of that something that can be calculated just from the
           style rules?  No layout needed?
   stearns: Yes, it's all just looking at flow-to/from properties.

Out of topics halfway through the call, glazou asks if there's anything
else to discuss.

TPAC Agenda
-----------

   <tantek> reminder: TPAC coming up
   glazou: Reminder - sign up for TPAC - the fee goes up substantially soon.
   <tantek> http://www.w3.org/2012/10/TPAC/
   glazou: Also, put topics up on the wiki for the call.
   <tantek> http://wiki.csswg.org/planning/tpac-2012
   <tantek> looks like a lot of folks are attending:
            https://www.w3.org/2002/09/wbs/35125/TPAC2012/registrants#CSS (member only link)

Counter Styles
--------------

   fantasai: I have a quick issue about i18n.
   fantasai: They'd like to take over the @counter-style list beyond what
              we resolved to keep in Counter STyles.
   TabAtkins: I'm totally for this - it means someone who knows a lot more
              about me is taking care of these things.
   <tantek> and getting something off your plate Tab!
   RESOLVED: Let i18n maintain the additional @counter-style rules.

i18n Joint meeting
------------------

   fantasai: Also, they're meeting Thu/Fri. We should check if there are
             more topics to discuss with them than just case-sensitivity.
   szilles: Would some of them be able to show up on Tuesday and be part
            of our discussion?
   fantasai: Dunno.  But there will be some who are there earlier.
   glazou: I'll ping the i18nWG and ask.

TTA Status
----------

   fantasai: Another topic is, what's the status of TTA?  Progress? Issues
             to discuss?
   smfr: Dirk and I briefly looked at the remaining Transforms issues.
         We'll have a conf call with some people about them next week,
         so we'll hopefully have some issues to add to the agenda.

Multi-col Intrinsic Sizing
--------------------------

   fantasai: Simon had an issue on the multicol module that we didn't address
             last week.
   SimonSapin: I was working through a reply to Håkon, because he seems to
               have a response to some things that I didn't understand.
   fantasai: On that topic, Tab and I spent yesterday writing out the
             intrinsic sizing definitions for multicol elements. This is
             significantly different from what Håkon thinks it should be,
             I think.
   <fantasai> http://dev.w3.org/csswg/css3-sizing/#multicol-intrinsic
   fantasai: dholbert brought up an example related to Flexbox, and that
             guided our ideas.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0017.html
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0225.html

   SimonSapin: Do you think that should go in Sizing?
   fantasai: I think so, yeah - multicol is in CR.  Sizing is already
             taking other things from 2.1.
   fantasai: The point is that there is no definition of these sizing
             things in Multicol, and the expectation that they size the
             same as a regular block element does not work.
   SimonSapin: And if we just remove the lines from the multicol module,
               and define this in Sizing, this is fine with me.
   fantasai: Yes, I agree with your suggested changes.
   glazou: Anything to resolve?
   fantasai: I think we should resolve to take the changes that Simon suggested.
   fantasai: We'd also need to change a couple of the terms in the algorithm.
   glazou: Did Håkon have a chance to review this?
   TabAtkins: No, we just did it late yesterday.
   glazou: I suggest we ask for feedback from Håkon.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0226.html
   fantasai: The changes are in the email I just linked to.

glazou: Okay, out of topics. Call adjourned.
Meeting closed.

Received on Wednesday, 10 October 2012 23:41:55 UTC