[CSSWG] Minutes and Resolutions F2F Mountain View March 2011: CSS2.1, Charter

Summary:
   - RESOLVED: For CSS2.1 Issue 242, proposal in minutes accepted.
   - RESOLVED: For CSS2.1 Issue 243, proposal accepted.
   - RESOLVED: For CSS2.1 Issue 227, fixed.
   - RESOLVED: For CSS2.1 Issue 238, defer to CSS3 Fonts.
   - RESOLVED: For CSS2.1 Issue 246, defer to CSS3.
   - RESOLVED: For CSS2.1 Issue 249, defer next editorial edition.
   - RESOLVED: For CSS2.1 Issue 251, defer to errata.
   - RESOLVED: For CSS2.1 Issue 258, revise note as proposed.
   - RESOLVED: Revert test, no changes to spec for block-in-inline-relpos.
   - RESOLVED: Discuss new charter at next telecon (2 weeks from now)

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

CSS2.1
------

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-242
   <plinss> http://lists.w3.org/Archives/Public/www-style/2011Mar/0179.html
   <fantasai> "(es) (even if either side is empty)"
   <dbaron> (and any block-level siblings that are consecutive or separated
             by only ignorable whitespace or out-of-flow elements)
   <dbaron> probably s/by only/only by/
   <fantasai> s#or#and/or#
   <fantasai> :)
   <dbaron> are broken around the block-level box (and any block-level siblings
            that are consecutive or separated only by collapsible whitespace
            and/or out-of-flow elements), splitting the inline box into two
            boxes (even if either side is empty), one on each side of the
            block-level box.
   RESOLVED: proposal above accepted

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-243
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Mar/0180.html
   RESOLVED: Proposal accepted.

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-227
   RESOLVED: fix error
   Bert: Fixed already.

   <dbaron> http://wiki.csswg.org/spec/css2.1#issue-238
   RESOLVED: defer to CSS3 Fonts

   <dbaron> http://wiki.csswg.org/spec/css2.1#issue-246
   RESOLVED: defer to css3

   <dbaron> http://wiki.csswg.org/spec/css2.1#issue-249
   RESOLVED: next editorial revision

   <dbaron> http://wiki.csswg.org/spec/css2.1#issue-251
   RESOLVED: errata

   <dbaron> http://wiki.csswg.org/spec/css2.1#issue-258
   RESOLVED: Revise note
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jan/0074.html
   <plinss> Note that COMMENT tokens cannot occur within other tokens:
   <plinss> thus, "url(/*x*/pic.png)" denotes the URI "/*x*/pic.png",
   <plinss> not "pic.png".

   CSS2.1 LC issues all resolved.
   <johnjan> w00t

   plinss: Next is responding to all these emails and writing the disposition
           of comments

   <johnjan> Arron has one test case to discuss. It's the last one though.
   block-in-inline-relpos-000
   <Arron> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/block-in-inline-relpos-002.htm
   <dbaron> When an inline box contains an in-flow block-level box, the
            inline box (and its inline ancestors within the same line box)
            are broken around the block-level box, dividing the inline box
            into two pieces (even if either side is empty). The line boxes
            before the break and after the break are enclosed in anonymous
            block boxes, and the block-level box becomes a sibling of those
            anonymous boxes. When such an inline box is affected by relative
            positioning, the relative positioning also affects the
            block-level box contained in the inline box.
   <dbaron> in 9.2.1.1
   Discussion of block-in-inline-relpos-002 and why it's failing and on
     which impls its failing.
   Arron: Opera and WebKit fail because they don't move the block at all
   Arron: IE moves the floats
   dbaron and arron investigate
   fantasai thinks we should just make it undefined, and then spec whatever
            we have interop on later
   <hyatt> that's hard in webkit
   <hyatt> for our implementation to do
   <hyatt> since the block isn't contained inside the inline from a tree
           perspective
   <hyatt> so we lose the knowledge of the relative positioning
   <hyatt> other things won't work either like opacity
   <hyatt> i don't know maybe other browsers just hacked only relpositioning
           to work
   <hyatt> and didn't handle cases like opacity
   fantasai: Let's make whether floats inside the relpos are translated be
             undefined
   ...
   dbaron: This might be the only test in the test suite that's testing this
           other really important concept that FF3.6 got wrong
   dbaron: Concept that if you have inlines, block, inlines, block, inlines
           you do two splits
   <johnjan> if we edited the test to only be that one part, would there be
             two passes?
   fantasai: This test uses out-of-flows, not inlines, in the middle of that
             sandwich
   dbaron: So the clarifying edit we made earlier this morning makes this
           testcase invalid
   fantasai: Didn't you change this testcase, it was originally matching
             the other interpretation
   <Arron> http://test.csswg.org/suites/css2.1/20110111/html4/block-in-inline-relpos-002.htm
   Arron: We have two passes on the old version of the test
   fantasai: dbaron, wrt our implementation, when bz and I split nsBlockFrame,
             changing this behavior call fall out of that refactoring. I don't
             think it will be hard.
   RESOLVED: Revert test, no changes to spec for block-in-inline-relpos

   plinss: So, who is going to help us respond to issues?
   <johnjan> There are now 24 edits remaining that are assigned to Bert
             (most very small). If both Arron and Elika help edit, along with
             helping write the disposition of comments, and getting the 9
             blocking tests taken care of, it won't take very long at all.
   <johnjan> I can help as well (either edit or DOCs).
   <johnjan> but I would need to get permissions to edit.
   <dbaron> test reverted
   <dbaron> (reverting of test is r1991)
   <fantasai> you probably don't want to edit :) but helping with responses /
              DOC would be nice
   <johnjan> I definitely don't want to edit, but I want to help any way I
             can :-).
   dbaron: I had specific actions to respond to specific posts
   <johnjan> David, I have you marked as having only one of those left.
   <dbaron> we need to link to responses in the wiki page
   <johnjan> issue 234

   <fantasai> If, as you're responding to issues, you run across an editorial
              edit that we rejected, assign the issue to me as =fantasai= respond
   <fantasai> That way I can fold those edits into a diff for the next revision
   <Bert> Most of the work will be responding. Looks like the edits will take
          me half a day.
   <Bert> But getting you an edit account is a good idea anyway.
   <johnjan> I agree Bert. Let's talk about that after the next conf call.
   <fantasai> So plan is, Arron &co will respond to all substantive issues and
              any issus that were accepted
   <fantasai> I will respond to editorial issues that were rejected
   <johnjan> Sounds like a good plan.
   <johnjan> When can we finish? (both the edits and the DOC) - tomorrow?
   <johnjan> Today?
   <johnjan> It's only 3 :-)
   Arron: Plan to finish by next conference call (in 2 weeks)
   <fantasai> johnjan, you are way enthusiastic :)
   fantasai: When you respond to an issue, put a link to your response in
             the Wiki
   fantasai: That's really important! we need it to compile the DoC
   <johnjan> I am enthusiastic, that's true. 2 weeks seems really late
             balanced against the expiration of our charter
   <johnjan> I'm really hoping we can get the DOC and edits done in less
             than two weeks.
   <johnjan> Why not schedule a 'special conf call' to get this done.
   <johnjan> we just did some amazing work over the last three days to get
             here, and I hate to lose that momentum.
   <fantasai> johnjan, a lot of people are going to be at sxsw,
   <Bert> I'll have the edits done before next Wednesday, with an updated
          (public) editor's draft.
   <johnjan> even better. Then we're all in the same time zone (except
             glazou apparently). :-)
   <johnjan> final comment on it from johnjan: I propose that if Bert is
             able to get the edits done by next wed and Elika finds time
             during SXSW to do her part, we have the conf call next wed.
             I realize it's a long shot.
   <johnjan> And I'll be quiet now.

Charter
-------

   jdaggett: Charter is up March 31st
   Steve: Given where we are, I'm sure the directory would be happy to extend
         the charter for 2 months or so
   jdaggett: So what's the status of the charter? Is Chris Lilley going to get
             to it? Do we have a Plan B?
   jdaggett: Can Bert help?
   jdaggett: We have a draft, and we have a proposal, and it needs editing.
   Bert: Chris is on holiday this week. He was supposed to have a draft ready
   Bert: But he hasn't sent it yet
   jdaggett: Can we give him a specific deadline to send it?
   jdaggett: And have somebody else take over if he can't do it?
   RESOLVED: Discuss new charter at next telecon

Received on Monday, 14 March 2011 21:28:25 UTC