W3C home > Mailing lists > Public > www-style@w3.org > April 2012

[CSSWG] Minutes and Resolutions Telecon 2012-04-18

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 18 Apr 2012 17:48:04 -0700
Message-ID: <4F8F60C4.1040800@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: Add new editors from Opera to Device Adaptation
   - Request to review Regions new auto-sizing section
   - RESOLVED: Accept Sylvain's proposal for handling negative animation-delay
   - RESOLVED: 2^24-1 minimum for numeric types, 30-component minimum for
               repetitions, 30-component minimum for calc(), adjust lower if
               necessary later
   - RESOLVED: Baseline of flexbox is baseline of baseline-aligned boxes if
               any, otherwise take first child
   - RESOLVED: Use the table for converting display types to block-level types
               to determine baselines; effectively this is using display-inside

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

   Tab Atkins
   Tantek «elik (via IRC)
   Arron Eicholz
   Katie Ellison
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Vincent Hardy
   John Jansen
   Brad Kemper
   Chris Lilley
   Peter Linss
   Alex Mogilevsky
   Edward O'Connor
   Florian Rivoal
   Anton Prowse
   Dirk Schulze
   Alan Stearns
   David Storey

<RRSAgent> logging to http://www.w3.org/2012/04/18-css-irc
   ScribeNick: fantasai


   Florian: Wanted to add new editors to CSS Device Adaptation
   <florianr> https://lists.w3.org/Archives/Member/w3c-css-wg/2012AprJun/0073.html
   Vincent: We're looking internally to see if someone might be able to
            join as well

   plinss: Please take time to add agenda topics to Hamburg wiki
   plinss: And some of those there are vague; please add more detail

   plinss: One issue left on margin collapsing?
   antonp: I'd like to work on other 2.1 issues than that one
   antonp: so let's postpone, and for next week I'll try to prepare some other ones
   plinss: Ok, ping me when it's ready

   glazou: Announce that Backgrounds and Borders / Image Values moved to CR
   glazou: missing announcements
   TabAtkins: yeah, fantasai and I were working all day on css3-values
   TabAtkins: will get to that

Device Adaptation

   Florian: Current editor for CSS Device Adaptation is going on paternity
            leave, so we're proposing two new editors from Opera myself and
            ōyvind Stenhaug
   Florian: We also invite people from other vendors to join, help us move
            this forward
   Vincent: What's the status of this module?
   Florian: Some open issues, and some editorial work
   Florian: Don't think there is a public test suite
   Sylvain: We have a partial implementation, might provide feedback soon
   Florian: Would be much appreciated
   Florian: Noticed you only implemented part of the spec, want to know if
            that's because you haven't done it yet or thought better to not
            implement it.
   Sylvain: Mostly we don't have it yet
   RESOLVED: Add new editors from Opera to Device Adaptation

CSS Regions

   <stearns> list intro: http://lists.w3.org/Archives/Public/www-style/2012Apr/0278.html
   <stearns> ED section: http://dev.w3.org/csswg/css3-regions/#regions-visual-formatting-details
   stearns: Added new sections to Regions to handle auto-height regions
   stearns: We've been validating this in code in a WebKit branch, making
            sure what we have there is implementable
   stearns: would like people to take a look and give us some feedback
   stearns: that's all
   howcome: I went through it, and I find it hard to read/understand/comprehend
            that part
   howcome: It may be right, but I find it hard to review and relate to the
            regions spec
   howcome: when the #1 concern that I and others have raised is not addressed yet
   howcome: I would have preferred if that hurdle could be passed.
   howcome: Right now, it doesn't seem like this should be something to work on
   stearns: It's definitely something we're working o
   stearns: what you do with the regions box is not related to how you size it
   stearns: we want the sizing algorithm independent of where the box comes from
   stearns: I agree we need to address box generation
   stearns: don't know that that issue gates auto-sizing regions
   howcome: I agree they may be independent, but there's not much motivation to
            review the spec when this hurdle remains in the way
   <sylvaing> didn't we agree to address this as part of the template work in Paris?
   Vincent: We are working on page templates, syntax for generating regions
   Vincent: We're trying to address the big issues you and others have raised;
            auto-sizing was one of those issues
   Vincent: We're not ignoring the other issues
   11:14  * tantek is on IRC only for this meeting.
   <Zakim> ... [Microsoft.aa], TabAtkins
   <Zakim> [Microsoft] has alexmog
   <Zakim> +ChrisL
   <plinss> ack glazou
   11:14  * Zakim sees no one on the speaker queue
   glazou: I reviewed document with a fresh eye
   glazou: I did not find it hard to read or understand
   glazou: I found it pretty easy to read and understand
   glazou: The thing I originally missed, and discovered rereading it
   glazou: Is that generating boxes is completely independent of notion of regions
   glazou: Explanation in Section 7 is needed to explain how regions work
   glazou: could be independent of generation of boxes
   glazou: We might need for other things in CSS
   glazou: Without that, document is not understandable as a whole
   antonp: I found it hard to get on the first read through. What could help
           is if someone maybe posts a summary of what's going on in Section 7,
           to orient the reader a bit?
   stearns: maybe I'll post an outline of the section to the list
   bradk: I thought Section 7 was easy to understand, esp with examples

   bradk: What was hard for me, doesn't have an exact definition of "fragment"
   bradk: There's no terminology section
   bradk: Afraid it might mean different things in different parts of the
   Vincent: Referencing CSS3 Fragmentation Spec
   stearns: I think I have a task to go through the document and make sure
            we have all relevant spec links
   stearns: We should have more links to css3-break
   bradk: Fragmentation spec talks about portions that occur between breaking
          opportunities, right?
   bradk: Seemed like in some parts it meant something different, like portion
          of element that's within the region box or something like that
   bradk: Want to make sure it's consistent
   Vincent: If you have any places you notice, point us at them


   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2012Apr/0239.html
   sylvaing: Made a fix to clarify ...
   sylvaing: But case that's not covered -- negative animation delays
   sylvaing: If you have a 2s animation and you have a -1s delay, your
             animation starts in the middle
   sylvaing: but if you have -5s animation, what does it mean?
   sylvaing: Implementations agree that if you have repetition of 1, and you
             have delay greater than duration, nothing happens
   sylvaing: However if you have more, and you ask for a delay, then you
             might skip repetitions
   * scribe unsure if that was quite right
   Florian: Looks like you didn't test Opera. The behavior we have in Opera,
            we don't like it
   smfr: Need to define what happens if fill mode is greater than duration
   smfr: do you jump to last keyframe even though you didn't run the animation?
   smfr: For all cases where the animation either never runs or completes
         instantaneously, we need to decide what fill-mode does
   smfr: Also define whether event fires
   <oyvind> I assume that should say "if you have fill mode and delay is
            greater than duration"
   plinss: Any objections?
   RESOLVED: Accept Sylvain's proposal

   <oyvind> or rather "if you have fill mode and negative delay of greater magnitude than duration"
   * fantasai wonders what happened to
   <fantasai> if it ever got filed.
   <smfr> fantasai: i don't think it did
   <fantasai> smfr, :/

Values and Units

   <glazou> is there a URL for the current topic ?
   <Ms2ger> http://lists.w3.org/Archives/Public/www-style/2012Apr/0403.html

   TabAtkins: Awhile back, resolved to find minimum required ranges
   TabAtkins: we asked Arron for those numbers, but he didn't get back to us
              for awhile, so we made some numbers up
   TabAtkins: yesterday he suggested 2^27-1 for all numeric types
   TabAtkins: He said it doesn't actually match minimums in IE in all places,
              but thinks it's reasonable
   Florian: Opera used to have extremely random sizes
   Florian: We recently changed to use 32-bit, but considering moving to
            24-bit representation
   Florian: So we might go back low
   <ChrisL> 2^24 -1 then?
   TabAtkins: That still seems like a large limit
   <gsnedders> ChrisL: Yeah
   TabAtkins: Should be more than needed for anything except z-index
   fantasai: The goal here is to be conservative, so low numbers should be fine
   <glazou> and we may need something expressing MAXRANGEVALUE
   * ChrisL z-index is an unrestrained binary coded decimal?
   TabAtkins: Ok, we'll use 2^24-1; if anyone has another concern bring it
              up within the week
   <bradk> Wasn't there some talk about making z-index into a float?

   TabAtkins: Another issue is repetitions of component values.
   TabAtkins: We picked 30
   Florian: We used to have a limit of 32, but now limited only by memory
   Florian: So we're fine either way
   sylvaing: ???
   TabAtkins: Any time the grammar has a repetition, e.g. + or *, how many
              are required
   <glazou> chained lists in memory are so hard to implement ? ;-)
   Florian: I believe IE was limited to 20 in some cases
   TabAtkins: calc(), I think
   TabAtkins: Also have a 30-term min on calc
   TabAtkins: So, we'll put this in, and people can object if it's too high;
              we'll lower it if necessary
   glazou: good strategy
   TabAtkins: We can even do that in CR, since it won't make anyone invalid
              that was valid before
   RESOLVED: 2^24-1 minimum for numeric types, 30-component minimum for repetitions,
             30-component minimum for calc(), adjust lower if necessary later
   glazou: Should that be tested?
   TabAtkins: Yes, the whole point is to allow testing
   talk about testing this

   TabAtkins: another issue
   TabAtkins: Kenny brought up the really fun situation...
   TabAtkins: Right now, when we have attr(), we do early syntax checking
              if the type and the fallback are appropriate for the place
   TabAtkins: I can give an example, where this is still confusing
   <TabAtkins> box-shadow: attr(size px, inset) 5px 10px blue;
   TabAtkins: So, in this, whether you interpret the attr() as a pixel size
              or the 'inset' keyword, but you get completely different
              meanings out of the two
   TabAtkins: If you have multiple attrs(), you have to do combinatorial
              checking of possible values
   TabAtkins: We went and restricted it to say that if attr() is the sole
              value of the property, you can do whatever you want
   TabAtkins: But if you use it as a component value, the fallback has to
              be the same type as the declared attr type
   fantasai: I'd like to have dbaron check on this before we close

   smfr: Going back to value ranges, sometime ago I proposed some text about
   smfr: If you supply value that's too large, it gets truncated, you write
         it back out it should roundtrip
   TabAtkins: Could add some specific requirements if that's needed
   smfr: ... z-index ...
   TabAtkins: Requirement is that you clamp to the nearest supported value
   smfr: So it clamps and then roundtrips, ok that's fine

   TabAtkins: I don't think we have anything else right now
   fantasai: Stay tuned, we'll have lots of issues to resolve next week!


   TabAtkins: The issue was a) we didn't define the baseline of a flexbox
   TabAtkins: The possibilities are either baseline of first-child, or
               somehow do what tables do (don't remember what they do)
   alexmog: We came to a conclusion for our implementation
   alexmog: Baseline of first child is baseline of flexbox
   alexmog: But we didn't have per-item alignment
   alexmog: I think what we had then is still ok
   alexmog: If there are items with baseline-alignment sharing baseline,
             reasonable for that to be baseline of flexbox. Otherwise
             take first one
   RESOLVED: Baseline of flexbox is baseline of baseline-aligned boxes if
             any, otherwise take first child

   TabAtkins: Second part is, how do you determine baseline of the first child
   TabAtkins: Proposal is use baseline of first child's display type
   Florian: We'd prefer not to do that, because if we consider things in
            terms of display-inside, display-outside, your display-outside
            would be something like flexbox-item, so you can't distinguish
            inline-block and block
   * fantasai agrees with Florian
   TabAtkins: So in practice, we could use the 2.1 conversion table for this
   TabAtkins: I don't care much either way, but several implementers said
              using display type makes sense to them
   <TabAtkins> http://www.w3.org/mid/87pqbfkcex.fsf@aeneas.oslo.osa
   fantasai: It's implementable, because we can always look up the computed
             style, but that doesn't necessarily mean it makes sense
   * sylvaing alternative: flexbox item with the highest z-index wins!
   alexmog: I think flexbox child would have it's display type, and just
            have an internal display-outside of flexbox-item
   Florian: In that case, you shouldn't be using display-outside of inline/
            block to determine different alignments
   alexmog: That's what I'm saying, inline-block and block should behave
            the same

   alexmog: Related issue is that suppose you have flexbox with one item,
            and that's inline-block or block or table with table cell
   alexmog: each with different definition of baseline
   alexmog: no way to make us actually ignore that internal baseline entirely
            and say that I want the baseline of that box be the bottom of the
   alexmog: Or can i?
   fantasai: I think there were some proposals for that. Might be added to
             Line Layout module
   TabAtkins: Think we can defer that to later

   RESOLVED: Use the table for converting display types to block-level types
             to determine baselines; effectively this is using display-inside

   <TabAtkins> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Flexbox&resolution=---
   TabAtkins: I think there are less than 6 weeks of work left on Flexbox,
              so I think we're ready for LC.
   fantasai: No.
   TabAtkins: If there are other issues to bring up, appreciate that happening
   <ChrisL> that is being ready in 6 weeks
   <ChrisL> and there should be no open issues, so its a stable document for
   fantasai explains that LC doesn't mean "I think I have 6 weeks left of work
            on this module" but "I think I'm done, please take a last look
            over what we're about to release".
   TabAtkins: I don't think there are any major issues left.
   ChrisL: If you think you have only one week of work left, then come back
           in a week and ask for Last Call
   alexmog: I think we're done, we don't have anything else
   fantasai: I disagree, and I would like to see the alignment issues
             addressed before LC
   <ChrisL> I agree with fantasai that if there are pending edits, do them
            first before going to last call
   plinss: I agree with fantasai [...]
   plinss: Major issues / minor issues, whatever.
   plinss: Want to present things for people to review.
   <ChrisL> so defer that issue as out of scope
   <sylvaing> can we just accept/postpone LC?
   * ChrisL wishes we wouldn't try to rewrite the process every time
   Florian: zero bugs is hard to get to
   Florian: But you shouldn't go to LC with bugs that you aren't willing
            to defer to next level
   fantasai: If you are making significant changes between LC and CR, you
             need to do another LC. You're not gaining anything there.
   Anton: If you've got a bunch of pending edits you haven't made, then
          it's not really a Last Call, it's another Working Draft
   glazou: Going to LC is decision of the WG. Decisions of the WG is made
           based on review of the members. Asking for review before
           transition request is fair
   sylvaing: maybe we should talk about actual issues?
   * glazou does not see a consensus about going to LC anyway
   florian: have a small question, fantasai has said several times that
            shouldn't go to LC until dbaron reviews.
   TabAtkins: AFAIK dbaron is deferring to dholbert
   plinss: We don't have consensus to go to LC. So work on the issues,
           and we'll come back to it later
   sylvaing: There's some issues that require WG discussion, e.g. renaming
             everything and going to LC are incompatible
   antonp: What exactly do I need to review here?
   antonp: Is bugzilla + current editor's draft what's needed to review
           this thing?
   Tab: yes
   plinss: Everyone please review

Meeting closed.
Received on Thursday, 19 April 2012 00:48:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:57 UTC