[CSSWG] Minutes Telecon 2012-09-19


   - Discussed Tokyo F2F dates; currently aiming at June 5-7. Schedule poll at
   - Discussed WG reviews of SVG2 and DOM 3 Events
   - RESOLVED: Accept Anton's proposed edits for defining "block container element"
               with editorial reorg of defining paragraph by fantasai
               Open issue on whether/how "principal box" needs to be defined.
   - RESOLVED: Change all CSS module shortnames to form css-foo-N instead of
   - RESOLVED: Unversioned shortname shifts to next level of a spec when it
               reaches Snapshot maturity
   - Discussed viewport size of reftests
   - Discussed prioritization of effort within CSSWG

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

   CÚsar Acebal
   Rossen Atanassov
   David Baron
   Ryan Betts
   Bert Bos (via IRC)
   John Daggett
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Koji Ishii (late)
   John Jansen
   Brad Kemper
   Peter Linss
   Anton Prowse
   Florian Rivoal
   Simon Sapin
   Alan Steanrs
   Leif Arne Storset
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/09/19-css-irc
Scribe: Anton


   plinss: Agenda additions?
   jdaggett: css3-fonts WD request - please defer
   <fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0020.html
   fantasai: like to discuss the above post
   <fantasai> css3-sizing, FPWD publication status?
   <fantasai> css3-flexbox CR publication status?

Tokyo F2F Dates

   plinss: steve and john have a hard conflict around that time
   jdaggett: target date of June 5 through 7 (wed - Fri)
   jdaggett: SVG guys could do Mon and Tue, overlap with CSS on Weds
   glazou: how many people in CSS will attend SVG on Weds?
   jdaggett: Can treat Weds as a CSS day in which SVG guys participate
   jdaggett: We can sponsor, but our present base can't hold both groups.
             We're hoping we'll find a larger space in time
   jdaggett: for now, put down Mozilla Japan as sponsor, but need to
             check again in Jan
   florian: proposed dates don't work for me, but nor do others
   jdaggett: want to accommodate the AC meeting that's also in Tokyo
   SteveZ: I have same problem as florian
   florian: to accommodate me it'd have to be either a month earlier or
            a month later, so don't go too crazy trying to schedule for me
   jdaggett: at TPAC we can talk again
   * fantasai can start a doodle poll on weeks
   jdaggett: I'll update the wiki with relevant info, proposing 5,6,7 June
             (with 5 June as crossover day)
   florian: If I can only come on Sunday to TPAC, do I have to pay a fee?
   SteveZ: no, no fee for that day
   dbaron: Given that the next-to-AC-meeting dates don't work for Steve,
           doesn't seem like doing next-to-AC-meeting scheduling helps
           that many people.
   <fantasai> http://doodle.com/z99cyshc5fy96kbr ?

Spec Reviews

   TOPIC: svg2 property review
   plinss: feedback everyone?
   * fantasai still needs to do that...
   plinss: minor threads on www-style about IRIs/URLs
   glazou: seems to be a point of contention
   sylvaing: paintOrderProperty - name is good, but we've used the expression
             "paint order" to mean something quite different
   plinss: do we need more time to review
   glazou: I reviewed it but don't have comments, not really my area
   plinss: revisit next week?
   dbaron: I'm not that happy about paint-order but don't have better ideas
           right now
   plinss: should we make that WG feedback, or individual feedback?
   dbaron: I don't have a strong opinion, and am not crazy about WG feedback
           in general
   glazou: we've been asked as a group for feedback
   dbaron: In that case, I'd like another week
   RESOLVED: revisit next week, after review
   ACTION on glazou: contact Cameron about the delay
   <trackbot> Created ACTION-508

   TOPIC: DOM3 Events
   glazou: I reviewed it; it seems fine
   glazou: CSS is mentioned in 2 places: z-order manipulated by CSS, and
           the way in which mouse movements work
   glazou: also mouse enter and mouse leave being like hover
   smfr: Is "mouse event order" section describing something new, or
         something that's implemented?
   glazou: seems to me that it's already implemented
   SteveZ: seems like our response is "no comments"
   RESOLVED: we have no comments on DOM3 Events
   ACTION glazou: no comment on DOM 3 Events
   <trackbot> Created ACTION-509

Scribe: fantasai

   antonp: This is about a proposal to introduce the term "block container
   antonp: We raised it briefly last week so people could have a week to review
   antonp: Noticed fantasai replied today
   antonp: Rossen also wanted a chance to review
   smfr: block container element is ?
   antonp: we already have concept of block container box, but we have
           problem in CSS2.1 where we mix elements and boxes all over
           the place
   antonp: would be good to have an element vs. box distinction
   antonp: this will help us to write errata with the right terminology
   antonp: don't think it introduces anything substantial
   smfr: how does it work with anon boxes?
   antonp: An anonymous box would never generate a principal box, so
           couldn't possibly be a principal block container element
   antonp: anon boxes aren't produced by elements anyway, so no issue
   antonp: anon boxes often are block boxes, but no corresponding block element
   antonp: one question fantasai raised on list was
   antonp: suggested some alternative wording of one paragraph, seems good
           to me
   antonp: also made a comment on "Certain values" phrase
   antonp: [talks about "principal box" term, how it's used but not defined]
   antonp: I deliberately don't include inline boxes when talking about
           principal boxes
   antonp: because they behave differently from other boxes
   antonp: but fantasai feels that inlines do generate principal boxes
   antonp: I don't think we need to answer that question for CSS2.1, which
           is why the wording is deliberately vague
   antonp: a bit cheating, we can do anything in CSS3, since omitted from
   dbaron: I think if you want something to be undefined, you should say so
   dbaron: if it's omitted, it doesn't happen
   fantasai: If block-level boxes can be principal, then so can inline boxes
   fantasai: Reason inline elements have multiple boxes in CSS2.1 is that
             they're fragmented
   fantasai: But block elements also get fragmented when they're paginated e.g.
   fantasai: I think originally this was not considered by the spec authors
   fantasai: inline elements were thought of as having multiple boxes
   fantasai: but now we have concept of a "box", which is then fragmented
             into "fragments of boxes"
   fantasai: And the same phenomenon applies to block-level elements as
             to inline ones
   antonp: I agree, which is why not objecting to the idea of principal box
           for inlines
   antonp: But I don't think that ties in with Chapter 10
   antonp: I know Bert's model doesn't really match this idea of principal
   antonp: But that said, I think there are actually existing problems in
           Chapter 10 anyway
   antonp: So don't think ought to be changing our mind on basis of Chapter
           10 that might not be the best anyway
   antonp: So [...]
   antonp: Which brings me back to dbaron's comment
   antonp: I suppose, I can't argue against it
   antonp: but I do think if you're trying to clarify something thats unclear,
           and improve but not all the way, then it's still improvement
   antonp: You could argue that either way
   antonp: But if others not happy with that [...]
   szilles: I think better to leave explicitly undefined
   plinss: Do we need to leave it undefined?
   Florian: Since tricky to define whether or not they define principal
            boxes, would do what Anton says
   Florian: Can make decision to define one way or another at some later point
   fantasai: I'm fine either way
   <florian> I would prefer to mark explicitly undefined for inlines,
             but otherwise do what anton says.
   plinss: If there are issues in Chapter 10, let's just address them.
   fantasai: I'd like to hear from Bert, is he on the call?
   * Bert can't call in. Phone (or phone system?) broken :-(
   arronei: Can we just accept Anton's text and take the inline portion
            for next week?
   Florian: That would work for me
   fantasai: Can treat Anton's issue as separate from my comment, have
             that be another issue
   dbaron: Would like it to be explicitly undefined if we don't know yet
   rossen: I agree we should move forward with accepting this, but making
           the undefined part of it explicitly undefined
   <SteveZ> +1 with David  and Rossen
   <florian> +1
   <Bert> I'd like to discuss with Anton why he thinks we need the concept
          of "principal" at all. To me, list-items just generate two boxes,
          one a block-level box, the other inline-level. We refer to one
          as the principal and the other as the marker, but that is just
          to describe them for the purposes of that para. There is no
          global concept of principal box.
   <antonp> Bert: I sent you an e-mail today justifying the need for
            "principal box" as a label; I think it's useful to define
            these things like block container element
   plinss: Not satisfied with leaving another open issue against it?
   fantasai: It's not a technical issue, it has no affect on interpretation
             of the spec, it's just about tightening up prose. I don't
             think we need to draw attention to the fact that we're not
             100% certain whether the term Principal applies here or not.
   SteveZ: Since Principal is used to identify which elements are
           Block-container-elements, we should be clear about the
           handling of inline boxes
   <fantasai> SteveZ, regardless of whether inline boxes are principal
              or not, they're definitely not blocks so it doesn't matter :)
   fantasai: I also don't think this is something to spend this much
             time on on the call
   plinss: Is everyone happy with accepting Anton's text and leaving
           principal box of inlines issue open?
   fantasai: Are there any objections to accepting Anton's text and
             leaving the issue open?
   RESOLVED: accept Anton's proposal

Spec Shortname

   plinss: We have three proposals for how to rename our spec shortnames
           [to be consistent with CSS modularization/levelling]
   plinss: Let's get a resolution on which direction to move in, then
           come up with concrete proposals
   plinss: Any comments on which naming system to use?
   <fantasai> http://wiki.csswg.org/spec/shortnames#versioned-names
   <dbaron> A is cssN-foo, B is css-fooN, C is css-foo-N
   * stearns prefers C
   <SimonSapin> B or C are fine, A is confusing
   dbaron prefers C
   glazou: I prefer C, too. The N is not related to CSS, it's related
           to the module
   <SteveZ> +1 for C
   plinss: C
   * lstorset C++
   florian: C
   arronei: C
   fantasai: So! Anyone for not C? :)

   plinss: other question on wiki page was when do we move shortnames
           over to next level
   <dbaron> A == CR, B == Snapshot acceptance, C == REC
   Florian: I would say A
   szilles: I'm confused by that. We create version N+1 when we're trying
            to split it into pieces we can do now vs later
   fantasai: This isn't about when to split the document, but when the
             unversioned shortname moves to the next version.
   <SimonSapin> Does B imply waiting for the next snapshot?
   <dbaron> I think I probably also lean towards B.
   Florian: What's the criteria for snapshot?
   fantasai: We think the module is stable, don't expect any changes or
             problems. Have tests and implementations, maybe not enough
             to get to REC, but enough to identify problems as bugs that
             will be fixed and to be confident the spec can be implemented
   Florian: In that case, I prefer B
   sylvaing: me too
   ?: Would motivate updating snapshot more often
   plinss: Would update redirects when publishing snapshot
   <SteveZ> I can live with option B
   Florian: Only worry with option B that since it's not very systematic,
            would postpone
   Florian: Otherwise it's the right level
   plinss: Snapshot is note, so we can update quickly
   plinss: Objections to B?

   SteveZ: Should we reopen whether snapshots should be REC or not?
   plinss: There's nothing testable. How do you prove a snapshot?
   plinss: could revisit in the future, don't want to open now

Max Viewport Size on reftests

   plinss: min or max?
   dbaron: The viewport size
   fantasai: The test should still work on larger sizes
   dbaron: It's the minimum size at which you should run the test,
           and the maximum size at which the test should have information
           for determining pass/fail
   fantasai: Mozilla proposed 600x600, Chrome and Opera say they don't
             need to go smaller
   arronei: Don't think we'd need to go smaller
   rossen: Is this for phones?
   Leif: We run at desktop resolution only
   Florian: May want to run on phones, too
   Leif: Might want to, but don't now
   Leif: Could look into it more closely
   florian: Yeah, because even if not needed right now, if we decide to
            do it don't want to rewrite all the tests.
   Leif: Ok, will look more into that
   fantasai: Do MS or Apple need to look into it more?
   smfr: We run at 800x600, and on mobile we scale down
   smfr: For tests that test viewport specifically, might need to run at
   MS: Same scenario we have
   dbaron: So if you run tests at 800x600...
   dbaron: If people write tests at resolutions higher than this
   dbaron: Might have existing tests not compatible with smaller resolution
   dbaron: This is the reason we don't want to go too small
   dbaron: but also have some devices where, for some reason...
   smfr: 600x600 sounds constraining for some kinds of tests
   dbaron: There are a lot of tests you make things x pixels wide, no
           reason to pick that number and not half that number
   smfr: More regression tests, where putting things side by side in
         same test (?)
   lstorset: What kinds of tests would be included here? No idea how big an
             impact this decision would have
   Florian: Most tests draw a green box, could be just 100px wide
   fantasai: Ok, people should look into it. We can come back next week.

   dbaron: We need to know whether people have a reason to run at a
           smaller size
   dbaron: Also whether anyone has a pool of tests planning to contribute
           that they can't bring down to this size


   plinss: Haven't gotten much feedback on module prioritization, please
           do that
   sylvaing: what is it for?
   plinss: Will inform glazou and I how to reset priorities for the group
   sylvaing: we've answered those things for charters
   sylvaing: what are we going to do differently this time?
   glazou: When we did this for the charter, it was also to know what
           were documents we wanted in the charter
   glazou: Not the case here. All documents listed here are in scope.
   sylvaing: Every meeting I go to, we start working on some new thing
   sylvaing: Don't allocate time based on priorities
   sylvaing: Is the plan to take some action based on priorities?
   glazou: It's part of the plan
   dbaron: One thing I found difficult to answer was
   dbaron: How to balance newer specs vs older specs
   dbaron: Tried to balance by trying to think about, if we spent time on
           issues for one or the other, which was higher priority?
   dbaron: But that will also change over time, because function of where
           they are in the process
   dbaron: Put down priorities for right now, but won't be valid for the
           long time
   glazou: Not looking for long-term answer, looking for prioritization now.
   sylvaing: I'd love to hear more on what you're thinking of to do with
             the answers
   sylvaing: Fuzzy on that
   glazou: You said yourself we have 50 docs on the radar, and new ones
           popping up every other week
   glazou: We have limited time
   glazou: need to dedicate our efforts on a single set of documents that
           we can move on rec track quite fast
   glazou: we think such a list from you guys could help
   sylvaing: So we're talking about when people bring up issue for telecon,
             and not high priority, you'll say no?
   glazou: If it's low priority, and we have high priority issues, yes.
   glazou: That's exactly what we did for CSS2.1
   plinss: If we have time available, we'll spend it on low priority issue.
           But if not, then no.
   glazou: We did this informally already
   glazou: We'd discuss on Tuesday, this item isn't critical, so not add
           it to agenda
   glazou: We want to do this based on your feedback, not just our opinions
   glazou clarifies that invited experts are expected to respond


   fantasai: So, is Flexbox going to CR?
   glazou: Yes
   fantasai: So how is it getting there? When/who is publishing?
   glazou: Let's discuss that offline.

Meeting closed.

Received on Wednesday, 19 September 2012 21:28:44 UTC