W3C home > Mailing lists > Public > www-style@w3.org > January 2009

[CSSWG] Minutes and Resolutions 2009-01-07

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 07 Jan 2009 13:12:14 -0800
Message-ID: <49651AAE.4090208@inkedblade.net>
To: www-style@w3.org

   - WG will start tracking attendance and use it to determine good/bad standing
     in the WG starting this month.

   - RESOLVED: Remove slash separating background color and fallback color in
     'background-color' property. ISSUE-65
     <http://www.w3.org/Style/CSS/Tracker/issues/63>
     RATIONALE: While this makes the property slightly harder to read and
     requires typing out 'transparent' in full every time, it solves the
     2-token lookahead problem very simply.

   - TENTATIVE RESOLUTION: For background layers, the WG agreed that only
     'background-image' should determine the number of background layers.
     ISSUE-74 <http://www.w3.org/Style/CSS/Tracker/issues/74>
     RATIONALE: Less likely to cause confusion for authors or introduce
     unintended behavior through the cascade.
     PENDING: Since Apple has already implemented the other option, we are
     waiting to hear back from them. If they agree this issue will be
     resolved as above.

   - RESOLVED: Proposal accepted for CSS2.1 Issue 91
       http://wiki.csswg.org/spec/css2.1#issue-91
     Whitespace that is not rendered still affects where line breaking
     opportunities occur.

   - RESOLVED: Proposal accepted for CSS2.1 Issue 95
       http://wiki.csswg.org/spec/css2.1#issue-95
     to remove sections 13.2.1.1 and 13.2.1.2 (dealing with a page box
     that doesn't match the page sheet, which can't happen in 2.1) from
     the spec.

   - RESOLVED: The "root em" unit will stay as 'rem'.

   - RESOLVED: Proposal accepted for CSS2.1 Issue 96 (Rule D mentions all
       ancestors but forgets the element itself)
       http://wiki.csswg.org/spec/css2.1#issue-96

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

Attendees:

   David Baron
   Bert Bos
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman (chair)
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   David Singer
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2009/01/07-css-irc
<glazou> plinss: I started filling an attendance table for good standing

ScribeNick: fantasai

Attendance Records
------------------

   Daniel: First thing, ... attendance to conference calls and F2Fs
   Daniel: We said starting with the new charter we start looking at
           attendance for good/bad standing in the WG
   Daniel: So we start doing this today

CSS3 Backgrounds and Borders
----------------------------

   <glazou> http://www.w3.org/Style/CSS/Tracker/issues/63
   Daniel: First technical item is background shorthand
   fantasai: I think the only proposal we had so far was to remove the
             slash in background-color
   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Sep/0142.html
   dbaron: There are two uses of slash in the background shorthand.
   dbaron: The first case is that a slash separates the bgcolor and
           fallback color
   dbaron: The other use is the slash indicates background-size
   dbaron: When you're parsing and you get a slash, you don't know
           whether you're going to get a background-size or background-color
   dbaron: one option is to require background-size to come after a
           particular property, such as background-position
   fantasai: problem with that is that I expect people will use
             background-size a lot without background-position
   fantasai: The simplest thing would be to remove the slash in
             background-color, but that would make it harder to read
             and would require writing 'transparent' every time you
             just want a fallback
   Bert: Anne also suggested using parentheses for background-size
   <dbaron> One other proposal is to replace the symbol '/' with the
            keyword 'size' in the shorthand.
   <dbaron> sylvaing: A functional notation for the value in the shorthand?
   fantasai: we wanted to avoid using parens where grouping isn't required
   Discussion of shorthand syntax conventions and why functional notation
     is inconsistent with them
   <Bert> Five proposals so far, I think:
           (1) keep slash, but require size to follow position (and fallback
               color to follow color);
           (2) no slash between colors;
           (3) parentheses around size;
           (4) keyword 'size' before position;
           (5) use size(w, h).
   ChrisL: If the keyword is there in the shorthand, it should be present in
           the property as well
   <fantasai> background-size: size 40em 20em;
   <fantasai> That looks weird. And redundant
   <glazou> background-size: size(40em, 20em) is what he meant
   <fantasai> ah
   <ChrisL> yes, but it would keep the shorthand and the individual property
            taking the same syntax
   <glazou> ChrisL: yes but ugly
   Bert: I think I'm favoring having no slash in the color
   <fantasai> background-color: transparent white;
   <fantasai> background: ..... transparent white;
   <fantasai> vs
   <fantasai> background-color: / white;
   <fantasai> background: .... / white;
   <fantasai> background: url(pattern.png) / white;
   <fantasai> background: url(pattern.png) transparent / white;
   Daniel asks if 2-token lookahead is really a problem for everyone
   <ChrisL> no objection
   dbaron explains that he'd rather reuse code for parsing the property
   rather than having to rewrite that code in the shorthand parsing function
   Daniel proposes going with 2) remove slash
   <dbaron> (2) is fine with me
   RESOLVED: remove slash

   <glazou> http://www.w3.org/Style/CSS/Tracker/issues/74
   <dsinger> dsinger has joined #css
   Options are, either every comma-separated property determines the number
     of layers (highest wins); or only background-image defines the number
     of layers
   http://lists.w3.org/Archives/Public/www-style/2008Dec/0087.html
   Daniel: Apple has implemented the multiple-property approache
   fantasai: I think the single-property approach would be less confusing
             and less likely to introduce unintended effects through the
             cascade.
   <glazou> Daniel,David, Bert favor the bg-image approach
   fantasai: I asked Molly and Jason and they also think that would be
             less confusing for authors
   <dbaron> I'm trying to figure out if we discussed this in
            http://lists.w3.org/Archives/Member/w3c-css-wg/2004OctDec/0123.html
   <dbaron> ... or http://lists.w3.org/Archives/Member/w3c-css-wg/2004OctDec/0129.html
   sylvain: I like fantasai's solution, but I haven't thought about it
            enough to have a strong opinion
   NOTED: Working Group favors background-image solution, waiting for
          Apple's response since they have implemented the other solution
          already.
   fantasai: In terms of backwards compatibility, I think very few people
             would be taking advantage of the fact that properties other
             than background-image increase the number of layers in Safari
   Daniel: That issue deferred to next week, or sooner if Apple replies on
           the mailing list

CSS2.1
------

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-91
   <dbaron> I wonder whether Hixie has an opinion on this issue (issue 91)...
   <fantasai> <span style="white-space: nowrap">text </span> text2
   <fantasai> is there a break opportunity between text and text2?
   <fantasai> that's the question
   <dbaron> I don't think the testcase thtree lines up is all that contrived
   <fantasai> In CSS3 there will most likely be a value that removes all
              whitespace, so whatever answer we want should match the
              behavior there
   <fantasai> (in the example above the second space gets dropped)
   <fantasai> Rendered text there is "text text2"
   <Bert> (I think the collapsing affects how far apart the two words are,
          but there are conceptually still two word separators and one of
          them allows lines to break...)
   <ChrisL> so its not *removal* of ws, but not rendering it (or rendering
            as a zero-width space?)
   Daniel: Sounds consistent with fantasai's proposal.
   <sylvaing> no objection
   Daniel: Should we accept? Any objections?
   RESOLVED: http://lists.w3.org/Archives/Public/www-style/2008Dec/0075.html accepted

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-92
   Daniel: We should skip this until Melinda is here.

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-95
   http://www.w3.org/TR/CSS21/page.html#oversized-page-box
   <fantasai> These two sections (13.2.1.1 and 13.2.1.2) can't exist in 2.1
              because we removed the size property so we should just remove
              those sections
   RESOLVED: remove

Flow Roots
----------

   <glazou> http://www.w3.org/TR/css3-box/#flow-root
   Daniel: Howcome has a question about flow roots
   fantasai: flow roots are just a new name for block formatting context roots
   Bert: I thought that "element that introduces a block formatting context"
         was a bit long
   <ChrisL> :)
   howcome: The problem I'm trying to solve is that in multicolumn layout,
            a float is relative to the column box
   howcome: But I don't think each column box should be a containing block,
            e.g. for positioned content
   dbaron: The column box is a containing block. The width of elements
           inside the column, for example, are calculated wrt the column box
   fantasai: the abspos containing block can be the multicolumn box, and is
             in your spec
   dbaron: The column box shouldn't be considered to be relatively positioned.
   howcome: So it doesn't create a reference for abspos.
   dbaron: yeah
   howcome: Ok, that helps.

CSS3 Values and Unites: rem unit
--------------------------------

   howcome: Should it be rem, or rm, or something else?
   fantasai: rem sounds good to me
   <Bert> deg = 3 letters...
   howcome: the other units are two letters
   howcome: if people like rem, I'll keep that
   RESOLVED: rem

   dbaron: I have another issue with rem
   dbaron: Interaction with SVG resource documents
   dbaron: I think it needs to the root of the root document
   dbaron: we might want to postpone this

CSS2.1
------

   Daniel: Anything else?
   http://wiki.csswg.org/spec/css2.1#issue-96
   <fantasai> if people feel that needs discussion, then discuss
   <fantasai> I thought it was pretty obviously an error
   RESOLVED: it's an error, fix it
   dbaron: Might want to say "of the block box"
   dbaron: just to be more specific

Meeting closed.
Received on Wednesday, 7 January 2009 21:12:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT