[CSSWG] Minutes Telecon 2012-09-12


   - John Daggett summarized the state of the font load event proposals.
     He is incorporating feedback this week and plans to publish an
     updated WD soon. http://dev.w3.org/csswg/css3-fonts/#font-load-events

   - RESOLVED: Accept CSS2.1 edits in

   - CSS2.1 edits up for review in

   - RESOLVED: Boxes whose contents break above the bottom of the page
               are drawn to the bottom of the page and consume height
               to the bottom of the page.

   - RESOLVED: Mark the non-2.1 Counter Styles as at-risk.

   - Co-chairs have sent out a prioritization / implementation interest
     survey to WG members and request its return, with the inclusion of
     CSS Ruby, which was left out.
     (In the interests of increased disclosure, the replies will be private,
      and aggregated results will be made public.)

====== Full minutes ======

   Rossen Atanassov
   Tab Atkins (late)
   David Baron
   Bert Bos
   John Daggett
   Elika Etemad
   Daniel Glazman
   Rebecca Hauck
   Koji Ishii
   John Jansen
   Peter Linss
   Ted O'Connor
   Anton Prowse
   Alan Stearns
   Leif Arne Storset
   Lea Verou

Regrets: szilles (AB meeting), brad, smfr (Apple event), florian, rbetts

<RRSAgent> logging to http://www.w3.org/2012/09/12-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Sep/0222.html

Scribe: fantasai


   glazou: any additions to agenda?
   glazou: First topic is Sunday of TPAC, but we don't have any news unless
           Bert joins
   <Zakim> +Bert

   glazou: Any info on TTWF location in Paris?
   rhauck: We're working on it,
   rhauck: if anyone has suggestions, let us know
   rhauck: we'll email the list when we know
   rhauck: hoping by end of week

   Bert: We reserved the room for Sunday, will be in the Hotel de la Cité
         Concorde, in the conference center
   glazou: Marie-Claire is planning a W3C meetup on Monday evening at the
           city hall of Lyon
   glazou: Will be general meetup aobut W3C and our specs and tools built
           on our specs
   glazou: Will collect items, if you want to speak, ping Marie-Claire

Counter Styles

   glazou: maybe defer this until Florian can attend

Font Load Events

   <glazou> http://dev.w3.org/csswg/css3-fonts/#font-load-events
   jdaggett: started out as proposal from Florian (?)
   jdaggett: topic brought up a number of times, need for events that
             indicate when fonts have been loaded
   jdaggett: reason for this is that there could be content on the page
             need to be measured, can't happen until fonts are loaded
   jdaggett: we've had several rounds of posts about font events from a
             couple years ago
   jdaggett: Tab recently proposed something
   jdaggett: I didn't like it, so I posted another proposal, in the spec now
   jdaggett: we need events for @font-face fonts b/c used lazily; not
             loaded until they're used
   jdaggett: Wanted to get from this call whether people happy with this
             proposal, flush out any possible objections
   jdaggett: Interface is still in flux; several people sent me private
             emails discussing certain parts of interface, things they
             find confusing, etc.

   jdaggett: Basically 2 types of events
   jdaggett: 1 gives you a way of identifying when all fonts are ready
   jdaggett: page could include multiple fonts, e.g. a bold and an italic
   jdaggett: It's hard for an author to track
   jdaggett: Also events that fire per font
   jdaggett: An app that wants to manage fonts very carefully would use
   jdaggett: The existing WebLoader interface put together by Google is
   jdaggett: by several online type services is more like per font details
   glazou: I read it and have no general comment; like it

   Bert: I have no problem with the technology, just wondering what it
         does to the schedule of the draft
   Bert: Will it push back LC, or so easy will go ahead without loss of speed?
   jdaggett: Think it can go ahead without loss of speed, b/c people are very
             interested and sending lots of feedback
   jdaggett: caveat is that the OM for CSS font face rule, leftover from CSS2
   jdaggett: it uses CSSStyleDeclaration, which is odd
   jdaggett: I'm starting to hear rumblings of people that this isn't a good
             idea, switch to something else
   jdaggett: others are ambivalent
   jdaggett: Would influence this to a certain degree

   glazou: Could you use a CSS Rule instead?
   jdaggett: You need some place to define something like GetPropertyValue
             so you can get value of descriptors
   jdaggett: don't think need a setter for that...
   glazou: To avoid putting null CSSFontFaceRule in document, use a CSSRule
   jdaggett: What does that get you?
   glazou: In the future if we change CSSFontFaceRule [..] you will get it
           through CSSRule
   glazou: The result would be CSSRule, but you say in prose it is a
   * fantasai is so confused
   several people confused
   * leaverou is confused too
   glazou: You said that CSSFontFaceRule is subject to changes, b/c ppl
           don't like how it is right now.
   glazou: Suppose it becomes CSSFontFaceRule2 in the future
   glazou: That will still query interface to CSSRule, and you can use that
           as a reply to font-face attribute
   jdaggett: Don't think on CSSRule there's any way to access info currently
             contained in CSSStyleDeclaration
   glazou: No, not saying that. Saying that giving reply as CSSRule lets
           you have another interface in the future
   dbaron: Not a question of which interface, question of what we want on
           that interface

   jdaggett: Existing implementations implement the old interface, so
             have to consider that carefully.
   jdaggett: I think I need to do more research on this.
   jdaggett: Direct answer to Bert, but other OM issue could influence
             the schedule.
   jdaggett: If no one has other comments, then will continue to work
             through details on the list
   jdaggett: Since this is relatively major piece, once syntax worked out
             on the list, would like to publish another WD
   jdaggett: Sound reasonable?
   jdaggett: Ok, I'll work on this another week, then ask WG for publish


   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0293.html
   anton: First is table box vs wrapper box and 'overflow'
   anton: Observed that it's implemented on table box, but only some
          values are supported
   anton: others are handled as visible
   <antonp> http://lists.w3.org/Archives/Public/www-style/2012Aug/0308.html
   anton: I proposed some wording, hope everyone's happy with it.
   <fantasai> works for me
   <Zakim> +TabAtkins
   Bert: Looks fine to me too
   glazou: no objection, no other comments?
   RESOLVED: Accepted

   anton: Second issue is an idea to help the wording in various places
   anton: going down a path we're going down a lot: defining terms we can reuse
   anton: Want to define the term "block container element"
   anton: "block container box" was introduced in CSS2.1
   anton: A "block container element" is an element that generates a "block
          container box"
   anton: Don't have this wording in CSS2.1 yet, but would make fixing
          various issues much easier
   anton: I proposed this on the list, talked with fantasai, but no one
          else involved in conversation.
   <antonp> http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html
   anton: Looking what other people think
   anton: It's a long email, starts with motiviation
   anton: follows with prposal
   Rossen: Can I give you feedback a little bit later?
   glazou: Ok, let's take a week to review this proposal and discuss it next week.

CSS3 Fragmentation
Scribe: TabAtkins

   Consuming height at breaks
   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Sep/0112.html
   ScribeNick: TabAtkins
   fantasai: I've been going back and forth on this.
   fantasai: Rossen and I were talking last week about edits from the San
             Diego f2f.
   fantasai: one of the issues that came up was...
   fantasai: If you have specified height on a box, that'll terminate *above*
             the bottom of the page, and continue on the next page.
   fantasai: You won't consume height between the cut and the next page,
             and won't draw there either.
   fantasai: That seems weird when you consider floats.
   fantasai: Normally you have text wrapping around floats, and eventually
             wrapping under it.
   fantasai: But here, there's space you can't wrap text around it.
   fantasai: Because the element isn't visibly taking up space there.
   fantasai: So we were discussing whether you can flow content under a
             broken float.
   fantasai: And the answer is no.
   fantasai: And so, if you're taking up space for the float, shouldn't
             you draw it's background there?
   fantasai: And if you're drawing it's background there, shouldn't that
             space consume height?
   fantasai: So we're considering reversing, and just making everything
             draw to the bottom of the page and consume height.  Thoughts?

   antonp: I think it should draw to the bottom of the page.  It's confusing
           as a reader to see something appear to terminate, but then it's
           there again at the next page.
   antonp: I think I don't want it to consume height, though.  Just calculate
           the extra space and add it on afterwards.
   rossen: In essence, what Anton is asking for is to have a fairly tight
           coupling of content and containers, which is not present anywhere
           else in layout.
   rossen: You have content, which draws independently of its container
           (to some degree).
   rossen: The content is free to extend to whatever extent it needs.
   rossen: The container may or may not take a dependency on that content.
   rossen: If your height is auto, you stretch to the height; if it's
           specified, you just stick with that regardless of content.
   rossen: Let's take as an example a block container with something with
           clearance on it.
   rossen: If it's height auto, the clearance in the presence of a float
           will extend the height of the container.
   rossen: Back to fragmentation, we're asking the same question.
   rossen: I have something inside which needs to be longer than it was
           originally (extending to the next page).
   rossen: The container may or may not take a dependency on that content,
           and stretch to the content's height.
   rossen: But if it's fixed, it's just fixed.
   rossen: So if, in this specific case, we don't consume from the specified
           height, now we're coupling content and containers.
   rossen: And then my question is, why don't we do the same thing for
           'clear' or similar mechanics?
   rossen: That's why specified height is specified - if it's exhausted,
           it's exhausted.
   antonp: That makes sense to me.  You're right to bring up that there's
           two ways to look at it.

   antonp: The question "why is height specified?"
   antonp: It could be because of the relationship between the box and its
           surroundings, or between the box and its contents.
   antonp: If you're specifying a height because you're going to specify
           properties on it that rely on that height, my answer won't be
           good - backgrounds won't look nice if they depend on the total
           size being fixed.
   antonp: But equally, if you *don't* consume height, you might get the
           same visual problem as before.
   antonp: I can imagine a situation where content is fragmented onto the
           next page.
   antonp: There's a gap, but it's only partially filled now by the content.
   antonp: You lose the visual indication that there can't be any more content.
   TabAtkins: In that case, it's kinda like overflow:visible, which does
              look horrible sometimes.

   fantasai: Yes, you might have a background positioned relative to the
             top of the box, so it looks bad if it continues.
   fantasai: On the other hand, you may have two boxes that have a specified
             height, because you want them to be the same specific size
             (maybe they're side-by-side).  If they break at different points,
             they'll end at different points, when the layout of the rest
             of the box depends on them being the same height.
   fantasai: There's no answer that'll give us the right behavior in all cases.

   rossen: You can also usually address this by specifying min-height instead.
           In the non-fragmented case, they're the same height; if height
           extends to higher than expected during fragmentation, it's auto
           height and the container will stretch as necessary.
   fantasai: One data point is that existing impls draw to the bottom of
             the page and consume height.
   fantasai: At least in Moz's codebase, it requires an extra level of
             bookkeeping if we want to draw to the bottom of the page but
             not consume height.  You either do both or do neither.
   fantasai: We're getting to the point of having more layout algorithms
             with boxes side-by-side, which should draw to the bottom of
             the page, and it makes sense for block flow to have the same
             behavior, so you're consistent.
   antonp: I wouldn't object to the status quo.
   antonp: I think it should draw to the bottom.  If it's easier, let's have
           it consume height.
   rossen: Again, I don't think anyone is suggesting the opposite.
   rossen: The visual should be consistent with the layout.
   TabAtkins: Agreed.  I liked the ability to be smart about it, but you've
              convinced me that we can't do good sufficiently often, so let's
              just do the simple thing that's usually good enough.

   plinss: My only concern is having a box accidentally overflow when it
           wasn't intended to.
   TabAtkins: Right, that's the time when it turns bad.  But as Rossen points
              out, there are ways around that (use min-height), and we can
              always expose an explicit swtich afterwards if we want.
   rossen: Reiterating, looking at different impls, that's the behavior you
           have today with pagination.  So the spec will be fairly consistent
           with that.
   rossen: So if we do introduce a smarter behavior, we may be looking at
           compat problems.
   plinss: I'll point out that the "impls already do this" is usually a
           good argument, but most impls do such a bad job at pagination,
           it's not really a very strong argument here.
   fantasai: I'd agree with that.
   fantasai: But there are cases where consuming the specified height will
             cause overflow, and other cases where it will prevent overflow -
             by not consuming the remaining space on the page, the container
             may be longer than expected, and *it's* parent now overflows.
   fantasai: Two boxes that are 100% tall in a fixed-height box, side by side.
   fantasai: I break the page, one breaks at the end of the page, the other
             breaks above it. If we don't consume height to the bottom of
             the page for both, the second box will overflow its parent.
   fantasai: So neither behavior works in all cases. It depends on the
             layout, and depends on the content.
   fantasai: Both answers are 50% good and 50% bad.  So, the argument to be
             consistent seems to win out.
   Bert: I think it's fine, but could you summarize the conclusion again?
   fantasai: The conclusion is that all boxes draw and consume height as
             normal in the presence of breaks, to the bottom of the page
             past the break.
   Bert: Okay, I can agree with that.
   TabAtkins: The point is that a break just does the equivalent of putting
              a big spacer element in there.
   antonp: If you glue the boxes back together, it's the total height.
   <Bert> (The key is "consumes height", the border may indeed not even
           reach the bottom of the page.)
   glazou: Objections?
   RESOLVED: Conclusion by fantasai about breaking, above, accepted.

Counter Styles

   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Aug/0916.html
   fantasai: I think florian's issue is that he'd like the counter styles
             that weren't in 2.1 to be marked as at-risk.
   TabAtkins: I'm fine with marking all the non-2.1 styles (the 2.0 styles,
              and the replacement CJK styles) as at-risk.
   RESOLVED: Mark the non-2.1 Counter Styles as at-risk.

CSSWG Prioritization Survey

   glazou: I have one additional thing.
   glazou: Koji, you're right that I missed CSS Ruby in the list of documents
           in the prioritization email.
   glazou: So please consider it included.  I missed it by accident.
   arronei: I have another comment on that list.
   arronei: Did you send that list to some influentials, like Molly or Designers?
   glazou: The Invited Experts in the WG got it.
   glazou: I didn't ping anyone outside the WG.
   TabAtkins: I think between our IEs we have enough "designer voice" to be
              useful - Molly, Lea, etc.
   sylvaing: I don't see anything in there that says "you have to be an
             implementor to answer this", but if Anton thought he shouldn't
             answer it...
   glazou: Be sure that the entire WG's answer will be valued.
   <leaverou> Did I hear my name or was it my idea?
   <glazou> you heard well
   <leaverou> glazou: Should I respond to that? I figured Bert will respond
              for W3C
   glazou: Lea, you have two faces in this group - on the one hand, you're
           W3C staff, on the other hand, you're an influential member of
           the design community.  So we'd probably be interested in your
           more personal opinions.
   leaverou: Like what devs would like the most?  Sure.
   glazou: So, everyone, ping your AC reps so we can get the surveys back
           in two weeks time.

Received on Thursday, 13 September 2012 00:09:31 UTC