W3C home > Mailing lists > Public > www-style@w3.org > September 2008

[CSSWG] Minutes F2F 2008-08-22

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 08 Sep 2008 18:58:00 -0700
Message-ID: <48C5D828.4020704@inkedblade.net>
To: www-style@w3.org

Attendees:
    David Baron
    Bert Bos (staff contact)
    John Daggett
    Arron Eicholz (via IRC)
    Elika Etemad
    Daniel Glazman (chair)
    Richard Ishida (observer)
    Anne van Kesteren
    Philippe Le Hégaret
    Håkon Wium Lie
    Peter Linss (chair)
    Alex Mogilevsky
    Saloni Mira Rai
    Steve Zilles

<RRSAgent> logging to http://www.w3.org/2008/08/22-css-irc
Scribe: alexmog

Agenda
------

   Styling for implicit video controls (discussing who added it to the
     agenda and if there is a proposal)
   Philippe: There are two kinds of controls for the HTML5 video element.
             There's the default controls, then you can make controls with JS
   elika: is there a proposal?
   elika: suggest we skip the topic
   (further discussion on why implicit video controls are on the agenda and
     if it needs an action item to follow up)
   discussion: video control buttons need to be styled. Define pseudo elements
               for it?
   bert: if we don't provide style, the only solution is script
   daniel: suggest a proposal comes from implementers
   peter: if this is something we want to address, we should at least discuss
          if this something we need to tackle
   steve: we don't need to solicit a proposal, it will happen or not happen
   <dsinger> I think we should have a discussion of styling of multimedia,
             including but not limited to controls, 'stylable aspects' (volume,
             brightness, contrast, perhaps) and control of optional aspects of
             the content, particularly accessibility
   <dsinger> but I agree the discussion should be anchored by proposals...
   <dsinger> and that today may not be the best use of time
   bert: if we do something we should do it soon or it will fall off the table
   <dsinger> the video-on-the-web group seems to be a good place to discuss
             cross-group aspects such as CSS implications of media elements,
             right?
   david: looking at what mozilla is doing now
   david: controls with SVG, not seeing anything with custom controls
   <dsinger> (I am in another stds meeting and cannot call in, only IRC when
             I am not paying attention here!)
   (it is noted that David Singer is interested in the topic)
   anne: We already have problems styling form controls
   anne: The appearance property is way underspecified
   anne: people are implementing form controls in JS, makes it unusable for
         mobile phones
   peter: propose action dsinger and bert to contact someone in mozilla and
          come up with a proposal
   Philippe: someone being Chris Double
   <dsinger> I'm happy to work with Bert on "CSS aspects of HTML5 media
             elements", yes
   action bert: come up with a proposal for implicit video controls
   <dbaron> And for what it's worth, I think what we're doing with the
            controls attribute is pretty much what HTML5 says to do.


Block Flow
----------

   elika: molly proposed syntax for block-progression
   elika: block-flow: tb | rl | lr | bt (bt is optional)
   elika: richard, what do you think
   richard: reasonable
   david: "flow" could be one of multiple things...
   richard: when do we want to talka about case A (on the whiteboard - tbrl
           flow)
   richard: should it be called "block-flow-direction" ?
   elika: when we talk about vertical, we'll say "in left-to-right block
          flow"
   RESOLVED: Molly's proposal accepted
   steve: when this replaces property name, do we still say "block flow
          direction"?
   elika: yes
   elika: we have a concept of "normal flow" as opposed to out of flow
   elika: ... and inline flow direction...
   elika: tblr, tbrl = "horizontal block flow"
   elika: lrtb, lrbt = "vertical block flow"
   steve: bad idea for general terminology
   peter: we should always qualify with "inline" or "block" flow
   peter: terminology is fine when talking of block flow, not for general
          discussion where "vertical" means "vertical text"
   steve: same objection
   * anne notes http://www.w3.org/QA/2008/08/css-wg-give-me-a-break.html
   elika claims it is a bad idea to use "direction" property in CSS. it
         should be in html "dir" property because content knows more
         about its direction
   alex is surprised and doesn't yet agree with it
   richard: I would use "vertical text mode" even if it isn't text
   steve: agree, that is the most common usage
   richard: do we need "mode"
   alex: in a sentence "in vertical text mode table rows are vertical" -
         is "mode" necessary?
   richard: with "mode" it sounds more specific in terminology
   elika: works for me
   RESOLVED: "vertical text mode", "horizontal text mode"
   richard: So for Mongolian you'd say "left to right vertical text mode"
   Bert: I've been using adjective terms mostly
   mongolian = "vertical text mode with left-to-right block flow direction"
   elika: could say "vertical mode containing block"
   elika: ok to use shortened form "vertical block"
   alex: define once "vertical block" = "block with vertical text flow
         direction"
   daniel: list style "tree"
   peter: arron wanted to be on call for that

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

   <glazou> next topic is CSS Backgrounds and Border
   daniel: may or may not talk about variables today. it would be good to
           have apple people for that one.
   <dsinger> (I'm in europe but don't know about variables, I'll ping the
             other apple folks, but it'll be late in the day if you catch
             them (for you, that is))
   <fantasai> http://dev.w3.org/csswg/css3-background/

   elika: couple of open issues
   -- issues 10 and 11:  specify which corner offsets are from
   http://www.w3.org/Style/CSS/Tracker/issues/10
   http://www.w3.org/Style/CSS/Tracker/issues/11
   elika: "background-position: bottom 10px right 25%"
   david: what happens when keywords and values are rearranged?
   peter: "left 15px" means "0px, 15px" - why?
   david: the problem with "bottom right 10px 25%" is, does it mean 10px horiz
          25% vert or 10px vert 25% horiz? because currently with coordinates
          the horiz is always first
   david: another way to solve same problem is calc()
   alex would find it more intuitive to have a separate property that defines
        alignment direction
   davie would rather leave it to calc() at this point
   hakon: can we write an example using calc()?
   elika: "background-position: 75% calc(100% - 10px)"
   hakon: good case for adding calc
   <fantasai> background-position: 75% calc(100% - 10px);
   <dbaron> I don't see any reason background-position: 75% calc(bottom - 10px)
            shouldn't work either
   hakon: want inside/outside too
   <dbaron> calc(0.25 * start + 0.75 * end)
   peter: calc is designed to solve odd cases
   peter: you can't build something that depends on direction
   * plh background-position: gps(N42°21.69348, W071°5.4957);
   saloni: "start + 5px" makes sense
   peter: you can't substitute "start" with 0 or 100...
   elika: I don't think we should allow keywords in calc
   hakon: agree
   discussion on difference of start/end and left/right
   steve: how do we represent start + 5px?
   elika: calc(start + 5px)
   <fantasai> background-position: 75% calc(100% - 10px);
   <fantasai> background-position: bottom 5px left 45px;
   <fantasai> background-position: start 5px top 45px;
   <fantasai> background-position: calc(start + 5px) top;
   <fantasai> background-position: calc(5px + start) top;
   <fantasai> background-position: calc(start + end) top;
   <fantasai> background-position: calc(start + bottom) top;
   <fantasai> You're going to make Molly cry if you make her do this much
              math just to put something in the bottom right corner. :(
   <fantasai> (we are looking at examples in
              http://dev.w3.org/csswg/css3-background/#the-background-position )
   <fantasai> Elika is against putting keywords in calc()
   <dbaron> calc(25% + 10px) means you position the 25% point in the image
            at the 25% + 10px point in the container
   * alexmog is not excited in parsing calc(100% + 5x) separately to determine
             anchor point in the image, then again to get the number
   <dbaron> The current definition of calc() doesn't allow keywords, so I'm ok
            with not allowing keywords too.
   <fantasai> discussion of implementing calc()
   <dbaron> background-position: 15px 20% (left top);
   <Bert> (calc() is a fancy notation for a triple (p, q, r) where p is the
          number of percentages, q the number of ems and r the number of px.)
   <dbaron> background-position: 15px 20% (start after);
   background-position: 0 15px; background-flow: rl-tb;
   <fantasai> background-position: [ <length> | <percentage> ]{2} [ keywords ] {2}
   <fantasai> Steve attempting to paraphrase Alex: for writing-mode relative
              positioning, just add one keyword to make it writing-mode relative
   <dbaron> background-position: 15px 20% from-top-left;
   <fantasai> RESOLVED: No keywords in calc() for background-position
   <dbaron> background-position: 15px 20% from-before-start;
   david: I no longer propose calc() as a solution for RTL background
   * alexmog is happy to hear that
   <fantasai> Richard Ishida draws two images
   <fantasai> [ W3C ::: :: : :   :   ]
   <fantasai> [   :   : : :: ::: W3C ]
   * glazou notes that fantasai is excellent at asciifying graphics :-)
   <dbaron> background-position: 15px 20% logical;
   it is noted that right-aligned background is possible in CSS2 -
     "background-position:100%"
   <dbaron> and then calc(100% - 10px) can handle the right-relative use case
   <dbaron> to solve vertical, you'd also need background-repeat:
            repeat-block-progression | repeat-inline-progression
   alex: if there is a keyword "logical" it picks one of 4 corners for
         origin, then tiles normally...
   <dbaron> and you'd need to make 'logical' on background-position flip the
             x and y for the vertical case
   Elika: and you'd also need mirroring / rotating of the image
   <Bert> Corners NW, NE, SE and SW?
   background-position: 15px 20% tb-lr;
   peter: we don't want to use "top-right" combinations will explode ...
         "start-right", etc.
   hakon supports an additional property that defines origin
   david: if there are 8 writing modes, do we need all 8 for background
          position?
   alex: yes, if rotate and mirror are included
   <dbaron> Elika: background-remap: absolute | reposition |
                                     [ mirror || rotate ]
   <dbaron> Håkon: can't live with this
   steve: whatever we do should work if image is designed for arabic, then
          mirrored to english version
   steve: the real requirement is for semitic pages to have the same
          capabilities as western pages
   backround-position-mode
   background-mode
   hakon: why not have a background-offset property?
   elika proposes dropping the functionality from CSS3 and taking CSS3 to CR?
Scribe: fantasai
   fantasai: New proposal: drop background positioning from other corners,
             push that and border-length to CSS4 BB, publish this draft as
             WD, then LC/CR around Dec/Jan.
   Steve: do we have consensus on using a separate property for defining
          origin corner?
   fantasai: No, because whether I agree with having a separate property
             depends on what it's defining
   fantasai: if we're defining which corner the origin is separate from the
             offsets, then I don't agree
   dbaron: I agree with Elika
   Peter: So proposal on the table is to use calc() for positioning from
          bottom right, and moving on with this draft
   Alex: I like Elika's original proposal with bottom and left keywords
         better than calc()
   David: I think I agree with what Alex is saying
   David: Take the current set of values, those are still valid
   David: Then add to that a syntax for four values
   Alex: And it's not allowed to mix logical and physical
   Alex: can't mix start and top
   Peter: My concern is that it makes the background remap unlikely to work
          later
   Alex: I think this is preferable to dropping values from CSS3
   Peter: Are you going to implement this in IE8?
   Alex: Unlikely
   Alex: If we choose to add something from CSS3 BB in IE8, multiple
         backgrounds would come much sooner than this
   * plh notes http://www.w3.org/QA/2008/08/css-wg-give-me-a-break.html
   * anne notes http://krijnhoetmer.nl/irc-logs/css/20080822#l-207
   * anne ;)
   * plh is waking up slowly :)
   proposal: elika's original version, with restrictions that remove ambiguity
   no start/end/before/after in CSS3
   <Bert> (background-position: right 1em 1px bottom 1.4em -1px)
   elika shows examples
   <fantasai> background-position: left top 10px;
   <fantasai> background-position: left 10px top;
   <fantasai> background-position: 10px 10px; /* CSS1 */
   <fantasai> background-position: top 10px left 10px;
   <fantasai> background-position: left 10px 10px; /* INVALID */
Scribe: alexmog
   hakon: what will dom return here?
   elika: 4 values
   <fantasai> fallback behavior:
   <fantasai> background-position: bottom right;
   <fantasai> background-position: bottom 10px right 10px;
   <fantasai> background-position: bottom right; /* CSS1/2 clients */
   <fantasai> background-position: bottom 10px right 10px; /* CSS3 clients */
   <fantasai> Bert: I want to wait for calc
   -!- plinss_ [peter.lins@15.243.169.72] has quit [Ping timeout]
   <fantasai> Daniel: I disagree, I think web authors will not understand calc()
   -!- plinss_ [peter.lins@15.243.169.69] has joined #css
   RESOLVED: 4-value syntax, two keywords must be present, zero values can be skipped (examples above)
   saloni: how about start/end/before/after
   <Bert> I don't think we resolved anything, I think we decided it was unresolved.
   no consensus at this point on when start/end are introduced
   RESOLVED: new background-position syntax in the draft is ok
   <SaloniR> I accept the syntax but I want the discussion on start/end to happen soon.
   <Bert> Not resolved. Objection from me.
   <Bert> calc() will happen anyway, so don't add redundant syntax.
   break

   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/28
   elika: there is a proposal to add 'transparent' keyword to border-image
          property
   elika: it would complicate the syntax, the image can be made transparent too
   david: we can skip it, syntax is complicated enough
   peter: it seems a misnomer that border-image includes background, although
          i see use cases
   consensus: no change
   RESOLVED: proposal to add "transparent" to border-image is rejected

   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/46
   issue 46 -- rename background-origin to background-box
   Steve: Why not call it background-position-area
   elika: there is background-clip with same values
   peter: sounds consistent
   elika: there is background-break property (for page boundaries)...
   peter: would expect background-clip to take a rect. should it be
          background-clip-box?
   peter: and background-box
   david: don't like background-box since there is also two; this is origin
          for positioning
   anne: let's keep it stable
   (no strong arguments to making the change)
   peter: concern about background-clip - will it interfere with adding a
          rect clip in the future?
   elika: will allow rect in background-clip
   steve: background-position-box?
   anne prefers to not change; there are implementations already
   elika: That's clearer, but my concern is that it breaks the pattern that
          given properties foo and foo-bar, foo is a shorthand that sets
          foo-bar
   <Bert> ('background-origin: NE content-corner')
   david: ok with changin background-origin; background-clip is a good name
   <anne> ('background-origin' has remained the same since 2002; nobody has
          suggested something substantially better it seems, otherwise it
          would've been changed)
   RESOLVED: no change to background-origin/background-clip naming
   <Bert> (Or combine bg-origin and bg-clip into one property?)

   elika: added no-clip to background-clip property. marked at-risk.
   david: painful to implement... an odd overflow case
   elika: no-clip with a no-repeat image overflows the box to however big
          the image is
   steve: what does it do for scrolling
   peter: probably should not trigger overflow
   alex: if it looks like overflow it should behave like overflow
   elika: shadows currently don't trigger overflow
   elika: we currently don't define anywhere what triggers overflow
   elika: if your element has scrollbar and background is scrolled you are
          allowed to clip to padding edge
   saloni: how does overflow background affects other elements?
   elika: same stacking order as normal backgrounds
   peter: does it belong to the same property?
   <fantasai> border-clip: padding-box no-clip
   <Bert> (background-repeat: repeat | no-repeat | repeat-x | repeat-y |
           no-clip ? Or background-image: url(foo) no-clip ?)
   elika notes that no-clip would be marked at-risk
   peter: not convinced it is a good idea but if we have to have it I'd
          prefer a separate keyword

   elika: box-shadow property
   elika: adding inner shadow -- inset keyword
   elika: brad kemper have images for that
   david: is the spread feature still in? I know we implement that
   elika: want to publish a working draft
   david: plan to last call reasonably soon

   anne: is border-radius stable?
   elika: yes, and we have accepted your proposal

   RESOLVED: publish WD

Template Layout
---------------

Scribe: fantasai
   Bert: Can we publish a new working draft of Template Layout that consists
         of the first section with Template Layout
   Bert: with the second and third parts removed?
   Bert: Nobody seems interested in the tabbed layout or row-based layout
   http://www.w3.org/Style/Group/css3-src/css3-layout/
   Bert: old version http://www.w3.org/TR/2007/WD-css3-layout-20070809/
   Elika: I had a comment that you should be able to assign min/max
          widths/heights to rows and columns
   Bert: there is syntax there for doing that
   Daniel: Are implementors interested in this?
   Anne, David: we are more interested in flexbox
   Howcome, Bert: This has useful things, especially the ability to reorder
                  content
   Saloni: How does this fit with the grid proposal?
   Bert: they are complementary, they work together
   Bert: With the grid module, you establish a grid, but then you need to
         use top/left etc to position things
   Bert: With this you establish the grid and create slots at the same time
   ...
   Elika: I think Grid is very useful for snap-to-grid
   Elika: I think using positioning with grid is not likely to be as robust
   Elika: but being able to snap widths/heights to grid
   Bert: or float to grid, or space out N items
   would be useful for those
   ACTION: Bert update CR Exit criteria to latest wording for CSS3 Template module
   <plinss_> Latest version of the text: http://www.w3.org/Style/CSS/Tracker/actions/44

CSS2.1 Issues
-------------

   Topic: Revisit Issue 14 in CSS2.1
   http://lists.w3.org/Archives/Public/www-style/2008Aug/0154.html
   http://lists.w3.org/Archives/Public/www-style/2008Aug/0164.html
      # The bottom margin of an in-flow block-level element is adjoining
      # to its last in-flow block-level child's bottom margin when:
      #   * the element's specified 'height' is 'auto',
      #   * the element's used height is the same as it would have
      #     been if the specified values of 'min-height' and 'max-height'
      #     were their initial values
      #   * the element has no bottom padding or border.
   Alex: Maybe the bullet about 'overflow' not 'visible' should be generalized
         to block formatting contexts
   <dbaron> Elika adds that as issue 70.
   RESOLVED: proposal accepted for Issue 14

   Change
     Vertical margins of elements with 'overflow' other than 'visible'
   to
     Vertical margins of block formatting contexts (such as floats and
     elements with 'overflow' other than 'visible')
   for Issue 70
   http://csswg.inkedblade.net/spec/css2.1#issue-70
   RESOLVED: proposal accepted for Issue 70

   http://csswg.inkedblade.net/spec/css2.1#issue-46
   http://lists.w3.org/Archives/Public/www-style/2008Jun/0106.html
   David: The issue is that we don't really say how media restrictions work
   David: We say that if the @media rule matches, then all the rules inside
          it apply
   David: But we don't say what happens with nesting
   David: if you get to a style sheet by multiple links, you don't want to
          check only the restrictions on the parent link
   David: You want to match the media restrictions on all the links
   David: Also you want this to work right if you link to the style sheet
          in multiple places.
   Daniel: The last sentence in this proposal doesn't handle media queries
   David: This is for 2.1, not CSS3
   "The import only takes effect if the target medium matches the media
    list." <- prepend to last para in 6.3
   RESOLVED: Accept dbaron's proposal plus the change above (from plinss).
             Bert to figure out exact placement etc.

   http://csswg.inkedblade.net/spec/css2.1#issue-49
   http://lists.w3.org/Archives/Public/www-style/2008Aug/0167.html accepted with s/will more/will be more/

   http://csswg.inkedblade.net/spec/css2.1#issue-62
   http://lists.w3.org/Archives/Public/www-style/2008Aug/0168.html
   RESOLVED: Proposal accepted for Issu 62/51

   Peter: Melinda raised an issue with the grammar
   Peter: rule sets can't contain other blocks
   discussion of what 'any' means and whether it is permissive enough
   inconclusive

   http://csswg.inkedblade.net/spec/css2.1#issue-32
   Daniel: I hit exactly the same problem in my source code editor.
   Daniel: @ followed by an unrecognized ident will not be recognized as an
           at-keyword by the parser
   David: You shouldn't use Appendix Gs' grammar for parsing
   Daniel: If you follow Appendix G you will not recognize @foo as an at-rule.
   http://lists.w3.org/Archives/Public/www-style/2008Aug/0165.html
   RESOLVED: Proposal by dbaron+fantasai accepted for ISSUE 32

   http://csswg.inkedblade.net/spec/css2.1#issue-35
   Issue described by
   http://lists.w3.org/Archives/Public/www-style/2008Jan/0432.html
   and
   http://lists.w3.org/Archives/Public/www-style/2008Mar/0026.html
   Daniel: I see your point, David, but I think if web authors specify all
           four offsets they will expect the replaced element to stretch
           to fit
   David: I think this would become the only case where a replaced element
          with width and height auto would behave differently from a
          non-replaced element with explicit width and height.
          ...and I'm also unsure whether we should be changing the spec at
          this point because we don't like what it says.
   Elika: I think we should make this change for replaced elements without
          an intrinsic size
   David: I don't want to half-make this change. I'd rather either make it
          or not.
   Elika: The results for http://fantasai.inkedblade.net/style/tests/issues/abspos-replaced-intrinsic-unsized
          -- using 300px by 150px
   Elika: really don't make any sense at all
   Seem to agree that this change would make sense for authors, other
     questions remain
   Peter: Would this break existing content?
   Peter: IIRC WebKit tried to match the spec here and ran into broken content
   discussion between Bert and Peter
   everyone tries to convince Bert that flexing auto makes more sense than
     ignoring a specified offset
   Bert is not convinced
   Straw Poll: Do we make an absolutely-positioned replaced element with
               intrinsic size stretch/shrink to fit if all four offsets
               are specified?
   Discussion about interoperability
   Howcome: It's not worth it to fix it. You can fix this today by setting
            the width. But we already have interoperability on the
            currently-specified behavior
   Alex: If we change this in the spec, would FF3 fix it?
   David: Not for 3.0, but perhaps for 3.1
   David: Not saying that we'd necessarily have time to change it, but that
          we'd be willing to
   Howcome: I'm not really convinced that this is worth changing from being
            interoperable to perhaps years of not being interoperable
   Howcome: I think we're taking a risk there.
   Howcome: I'm a skeptic
   David: Abstain
   Daniel: In favor
   Saloni: Change
   Richard: abstain
   Steve: abstain
   Peter: in favor
   Alex: mixed feelings. I see perfect interop here
   Alex: We can improve it, but why
   Alex: No change
   Bert: No change
   Elika: no strong opinion, change iframe not image
   Anne: seems there are enough other ways to get this effect that we can
         address this case using other means
   Anne: So I would say no change
   <arronei> From what I have just read I would say no change
   Daniel: No consensus at all.
   Daniel: So we'll have to say no change.
   RESOLVED: No change.
   Elika: Can we undefine the behavior for iframes?
   <glazou> <br style="reason: bee;"/>

Charter
-------

   * glazou has to leave in 45 minutes from now
   Daniel: I want to discuss the charter and also to report on Variables
   Philippe: I looked into the charter
   Philippe: Listent to you for past three days
   Philippe: Don't have any significant changes to suggest.
   <plh> http://www.w3.org/Style/Group/2008/draft-charter2.html
   philippe: I changed the online version of it this afternoon, some minor
             changes but perhaps they are major for some people
   Philippe: We changed success criteria
   Philippe: to be relative to each feature instead of each deliverable
   Bert: In some cases you might want per-feature, in some cases
         per-deliverable
   Bert: For example with a profile you don't want each feature you want
         the whole thing
   Philippe: My intention was to make it less restrictive.
   Philippe: So that you can choose to target the whole deliverable, but
             in other case you can also target each feature
   Philippe: I didn't see any need to call out the W3C RECs for QA
             Framework, Charmod, Web Architecture
   Philippe: We just expect everyone to follow the RECs
   Philippe: Removed sentence about minutes being public because that is
             redundant with the top part of the charter, which says
             proceedings will be public
   Philippe: Removed paragraph saying that we follow Section 3.4 Votes
             because the previous sentence adds extra restrictions
   Philippe: Some concerns about your process.
   Philippe: Your Decision Policy requires making decisions only during
             group meetings
   Philippe: And the quorum requirement  ...
   Elika: The Decision Policy paragraph seems to impose the 2/3 quorum
          requirement on all technical decisions
   Elika: Not just for formal votes.
   Elika: And we almost never have 2/3 of Members in attendance
   <dbaron> "When deciding a substantive technical issue" should have
            "by formal vote" at the end.
   See dbaron's comment in IRC -- we should make that change.
   Philippe: Deliverables section
   Philippe: I want to be clear that anything not under this section is
             not under the patent policy
   Philippe: Any contributions made to these drafts will not be under
             the patent policy
   Philippe: If you want any working drafts to be in REC track they
             must be in the Deliverables section.
   Steve: The other items are in scope, they're just not expected to be
          delivered in this charter
   This section seems to need clarification about the other items in the
     module list being on the REC track
   Philippe: Just add a pointer back into the Scope section from here to
             make it clear that those items are in the REC track
   Daniel: Steve, when we had these items under the REC track list you
           objected that it was way too many items under patent disclosure
           and Adobe lawyers would object
   Steve does not remember this
   ...
   Daniel: I think if we put everything back under the REC track then W3C
           will not accept the charter because they want us to prioritize
           more heavily
   Philippe: You need to say that these Deliverables are the items that
             the WG will deliver, but that the other items in the Scope
             section are also on the REC track
   Daniel: This is the opposite of what Chris Lilley wanted
   Daniel: I suggest you talk with Chris Lilley before we make any changes
          here
   Philippe: The IP policy would reject publishing any item not on this
             deliverable list
   Steve: Right, the agreement was that if we wanted to publish something
          as a WD we would amend the charter to include it
   discussion about being on REC track, covered under IP policy etc
   Steve: What surprised me is that the patent policy would not apply to
          the items in scope but not deliverable
   Daniel: Any other feedback on wg?
   Philippe: The WG seems to be working well. Have a resources problem,
             that is not uncommon.
   Philippe: It would be nice to have CSS2.1 as a REC asap
   Daniel: That's the goal
   Daniel: Ok, thank you Philippe
   <Bert> (I think the easiest change is to change the title from
          "Rec-track deliverables" to "milestones" to remove the impression
          that the other drafts are excluded from the Rec-track.)
   <plh> Bert, I'm fine with that change, but the charter needs to indicate
         which deliverables are on the rec track, so you need a statement
         somewhere that says that all modules are on the rec track.
   <Bert> Plh, I'm fine with saying that explicitly, but I'm sure it's
          redundant.
   <plh> fantasai, I changed the draft charter to reflect your comment
         on quorum requirements

CSS Variables
-------------

   Daniel: Dave and I made some changes from the original spec we released
           back in April
   Daniel: The first change is in the keywords themselves
   Daniel: Based on a suggestion it changed @variables into @define
   Daniel: In the current nightly builds we can use both of them
   Daniel: And we add a media type
   <arronei> Is there a link to the updated document?
   http://lists.w3.org/Archives/Public/www-style/2008Jul/0545.html
   Daniel: Note that for the time being it's vendor-prefixed
   Daniel: He added two things I thought were incredibly ugly
   Daniel: =foo= and $foo
   Danie: It really looks like a programming language now?
   John: Doesn't that cause problems in templated situations?
   Daniel: In a more recent email, Hyatt added the ability for variable
           to be a block of CSS declarations
   <plh> Bert, not in what I've seen unfortunately
   http://lists.w3.org/Archives/Public/www-style/2008Jul/0571.html
   David: Are variables variable or are they constant?
   Daniel: The syntax for calling this breaks the forwards-compatible
           grammar
   Daniel: It's something web authors have wanted for years, but it
           breaks CSS as it is
   Daniel: I personally like the feature, I don't like the design
   Daniel: If you have comments yourself about this, please jump on
           thread and make a comment
   John: So why is the functional notation a good thing?
   Elika: I don't like the functional notation because I don't want
          nested parentheses e.g. inside calc()
   http://lists.w3.org/Archives/Public/www-style/2008Jul/0571.html
   Steve: What if I created a new property that took the variable
          substitutions?
   Elika: That's a hack. It's not really a property-value combination,
          it's meant to be replaced by a set of property-value
          combinations
   David: The current CSSOM only supports one value per property
          per declaration
   David: You can't do that and get the cascading order right
   David: And change the variables after the fact
   Daniel: Then these need to be constants
   Steve: Also I could have recursive variable calls
   Anne: was there a lot of positive feedback of them being mutable
         through the DOM?
   Howcome: I don't think that's a very good idea
   <anne> (I would like to see pointers fwiw.)
   Howcome: A syntactic macro function seems reasonable
   Howcome: but manipulating them through the DOM, I don't think so
   <fantasai> I still prefer
              http://lists.w3.org/Archives/Public/www-style/2008Jul/0031.html
              personally for syntax
   Several conversations at once
   Saloni: font-size: calc( var(black) + 1em); ?
   <Bert> (These variables do so little and cost so much :-( Why not design a
           *real* macro language, with parametrized macros, conditional macros
           and all. It can be much more powerful and at the same time much
           easier to spec and use...)
   fantasai: I don't particularly like their proposal. I'd prefer something
             like macros
   Anne: constants would make things easier for the CSSOM
   David: It's not that clear whether their proposal is variables or constants
   Steve: macros just save typing, they're not that important to have
   Elika: maintenance
   Elika: Can we make a counter-proposal?
   <dbaron> (unminuted discussion with people talking very fast and
            simultaneously)
   <Bert> (... discussion continues about... scope (from definition
          forwards only?)... textual replacement or typed/pre-parsed
          replacement...)
   <anne> Test:
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A...%3Cstyle%3Ebody%20%7B%20background%3Ared%3B%20test(test)%3B%20background%3Alime%20%7D%3C%2Fstyle%3E
   ACTION: fantasai draw up parse-time constants counter-proposal
   ACTION: peter draw up parse-time constants counter-proposal
   Meeting closed.
Received on Tuesday, 9 September 2008 01:58:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:12 GMT