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

[CSSWG] Minutes and Resolutions Tokyo F2F Thurs: Values and Units, Media Queries, Backgrounds and Borders, F2F Scheduling

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 08 Mar 2009 23:45:43 -0700
Message-ID: <49B4BB17.1040405@inkedblade.net>
To: www-style@w3.org

   - RESOLVED: Add && notation to 2.1 unless somebody comes up with something better,
               to avoid having to publish a syntax module for just that one new notation.

   - RESOLVED: whitespace required around plus and minus signs in calc(), option to
               revisit later if it's a problem

   - RESOLVED: Publish Media Queries as CR

   - RESOLVED: border shorthand resets border-image

   - RESOLVED: border shorthand cannot set border-image

   - Discussed fallback color and syntax, no consensus so fantasai will edit
     and collect complaints later.

   - RESOLVED: CSSWG will do either TPAC or mini-TPAC in Oct/Nov in Bay Area
               Which one depends on what SVG/WebApps/HTML are doing

   - RESOLVED: Publish Selectors as Last Call Working Draft, 4 week LC period

   - RESOLVED: Plan to meet in France, work on an agenda tomorrow

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

<RRSAgent> logging to http://www.w3.org/2009/03/05-css-irc
Meeting: Cascading Style Sheets (CSS) Working Group Meeting
Date: 05 March 2009

   David Baron
   John Daggett
   Elika Etemad
   Sylvain Galineau
   Håkon Wium Lie
   Chris Lilley (late)
   Shinyu Murakami
   Mike Smith
   Anne van Kesteren
   Steve Zilles

Chair: #css
Scribe: fantasai

Values and Units

   howcome: What's the interface between the syntax module and the values and
            units module?
   dbaron: I think it's ok as the draft is now
   howcome: There's a couple of things I'd like to update in the syntax module
   dbaron: Update what?
   dbaron: I don't think we have much to put in it other than what's in 2.1
   howcome: fantasai wanted to copy over the value definition syntax
   <howcome> http://www.w3.org/TR/CSS21/about.html#property-defs
   dbaron: why not reference 2.1?
   fantasai: I wanted to add &&
   dbaron: I don't know that we even want &&; might be better to just write
           things out, potentially with sub-productions.
   dbaron: Or just use || and say one of the parts is mandatory.
   dbaron: (say via prose or via other syntax)
   <anne> ||+
   dbaron: Could we put && in 2.1 even though 2.1 doesn't use it?
   ACTION: fantasai to send message to www-style to explain rationale for &&
           and see if somebody can come up with something better
   RESOLUTION: Add && to 2.1 unless somebody comes up with something better,
               to avoid having to publish a syntax module for just that one
               new feature.

   dbaron: My other comment on values and units was the cycle() feature
   dbaron: I'm pretty sure we resolved to add it
   howcome: ok, so it's my action point to add that
   howcome: can you have recursive cycles?
   dbaron: well, you /could/. In my message I explained how it would work.
           You can create a state machine with that, although it's not the best
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jan/0104.html
            has references to the proposed text

   howcome: any other issues?
   fantasai: Do you define whitespace for calc()?
   howcome: yes, I added S tokens
   fantasai: whitespace should be required
   <howcome> http://dev.w3.org/csswg/css3-values/#the-calc-function
   fantasai: at least around the + - signs, because otherwise you have to
             retokenize inside calc()
   dbaron: retokenizing in our implementation isn't that hard, because it's a
           hand-coded recursive descent parser and we can be mean to our
           tokenizer and send back pieces of tokens
   dbaron: but if you are using a parser generator it's not so easy
   dbaron: I think WebKit uses a parser generator
   <shinyu> we implemented calc() allowing non-whitespace around + or -
   fantasai: I'm concerned also about what we might want to allow inside calc()
             in the future. If we don't require spaces, that restricts our
   dbaron: Yeah, so in our implementation of :nth-child() we do push pieces of
           tokens back to the tokenizer
   dbaron: I suspect Webkit tokenizes :nth-child() as one token, and then hand
           parses that token
   dbaron: which would be much harder to do with calc()
   howcome: I suggest we put in the required spaces now. We can take them out
            later if we need to.
   howcome: ok, so it's in the dev version now. Is anyone planning to implement
   dbaron: in the medium term
   Murakami-san: I'm ok with requiring or not requiring white space
   Murakami-san: we implement this feature. We allow but don't require
                 whitespace around the operators
   no objections to requiring whitespace around plus/minus operators

<MikeSmith> Present+ Masataka_Yakura

[[Page-breaking, GCPM, and Multi-col Discussion, see previous set of minutes]]

Media Queries

   Anne: I made all the changes to Media Queries
   Anne: So I would like to go to CR
   <anne> Disposition of Comments:
   <anne> Draft: http://dev.w3.org/csswg/css3-mediaqueries/
   fantasai: Any objections to publishing CR of Media Queries?
   RESOLVED: publish Media Queries as CR

   Chris: It would help if in the disposition of comments you had some color
   dbaron: When I did the comments for CSS3 Color I colored rejected feature
           requests differently from other rejected comments
   steve: what you really want to note is which resolutions the commentor
          didn't agree with

   <glazou> I received a request by email to extend MQ to detection of
            implementation of a pair (property, values)
   <dbaron> glazou, we've heard that before
   <glazou> yes
   <dbaron> glazou, too late for this level, anyway, as we just discussed :-)
   <glazou> dbaron: oh sure, I was just mentioning it

Backgrounds and Borders

   Whether various border shorthands should reset border-image
     in order to give the author a blank canvas to set borders on
   dbaron: Also a question is whether border-style should reset border-image
   dbaron: since border-image is kind of like a border style
   fantasai: I think the 'border' shorthand should reset border-image. Not
             sure about others
   dbaron: complication is that border is no longer
   * dbaron marvels at the operator-precedence in the previous line :-P
   anne: why not just have border-image always override border-style?
   dbaron: That's the current behavior. The concern is in complicated style
           sheets you won't always remember to reset border-image every time
           you use border-style
   <glazou> +1
   * dbaron wonders what glazou is +1ing
   <glazou> what dbaron said just above
   fantasai: I think the two reasonable options here are to either have only
             'border' reset border-image, or have any shorthand that sets
             border-style turn off the image
   dbaron: or potentially any property that touchs the border-style, not
           just any shorthand
   Steve: If only the shorthand turns it off, then to do something like change
          one value then I have to use the shorthand to get rid of the image
   discussion of how authors in complicated style sheets set borders
   * glazou answer is "sometimes with great pain" :)
   anne: The resetting behavior seems like quite a bit of complexity for
         something the author can easily solve by resetting border-image
   <anne> I also said that I expect sites that use border-image to use it
          consistently throughout and probably also specify border for
          backwards compatibility anyway
   fantasai: So, the advantage of having 'border' reset the border-image is
             that we can encourage authors to use it as a way to get a blank
             border canvas
   fantasai: And this will work also in the future when we add more border
             properties: 'border' will always get you a blank canvas
   fantasai: The advantage of having any shorthand that touches border-style
             reset the border image is that the process is pretty much
             invisible to the author
   1. Do nothing. border-image always overrides
   2. 'border' shorthand resets border-image
   (and in the future, any other border-tweaking things)
   3. any shorthand that touches the border-style properties resets border-image
   Anne: was it considered to make border-image part of the border shorthand?
   Straw poll:
   howcome: 2
   anne: 2 or 1
   dbaron: 2
   jdagget: 2
   Yakura-san: 2
   Murakami-san: 2
   fantasai: 2
   * glazou 2 for me as well
   * sylvaing remembered he's here and votes for 2 as well

   Steve: I dislike how border-image and border-style are independently turned
   Steve: If I add border-characters as my next property, how does it interact?
   Steve: It seems like this isn't going to scale
   Steve suggests a value for border-style that turns on the image
   Anne responds that this is too indirect and will be hard to understand
   jdaggett: Maybe for the example in the spec, have a use case that is closer
             to what people are actually requesting?
   fantasai: I'm not a graphics person, we'd have to ask Brad Kemper to come up
             with one

   fantasai: Anne's comment, should border-image be part of the border
   fantasai: We /can/ do that syntactically, if we place <border-image> after
             any style/width/color bits
   fantasai: So we can do either border: [ <border-style> || <border-width>
             || <border-color> ] | <border-image>;
   fantasai: Or we can do border: [ <border-style> || <border-width> ||
             <border-color> ] <border-image>;
   <anne> [ <border-style> || <border-width> || <border-color> ]?
   Straw poll on whether we should add border-mage to the shorthand
   Chris: I think if we're having trouble with this, then we shouldn't add it
   Sylvain puts his head on the desk
   Anne: Yes?
   dbaron: No, because if they use border-image that'll at least lead them to
           the documentation for the feature whereas using the shorthand
   Chris: so the self-documenting web
   Mike: abstain
   jdaggett: No
   Yakura-san: maybe not
   Murakami-san: no
   fantasai: no
   * sylvaing also said no
   * glazou hum, no
   Steve: Yes for the reasons Anne listed, but I don't feel strongly about it
   howcome: I tend to disagree with Anne a lot today
   RESOLVED: border shorthand resets border-image
   RESOLVED: border shorthand cannot set border-image
   Steve has concerns that we are deciding this kind of question without
     author input
   jdaggett: I think if we show the designers that syntax they will cry
   <anne> (admittedly having border reset border-image does make fallback
          slightly trickier)

Scribe: Sylvain
   <trackbot> ISSUE-94 -- Syntax for fallback color unclear -- RAISED
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/94
   <ChrisL> (long explanation of the feature)
   dbaron: proposes not allowing the piece before / to be omitted (both cases)
   dbaron: if you need the value after the slash, you need to specify the
           value before it i.e. you can have a or a/b but not /b
   chrisl: if this removes the parsing ambiguity, this seems a good option
   fantasai reviews options
   <fantasai> Several options for changing the shorthand
   anne suggests removing the fallback color
   fantasai: I don't want to require specifying background-position and
             background-size in order to specify background color
   <fantasai> I prefer
   <fantasai>    * require that background-size not immediately follow
                   background-color (so that if you find a slash after
   <fantasai>      background-color, you know the fallback color is next)
   fantasai: I'd prefer to have web author feedback before removing the feature
   ACTION fantasai email www-style on whether web designers want fallback color
   szilles finds the preferred proposal above to be too hard to explain
   short proposal crossfire ensues. minute taker is reset.
   <fantasai> fantasai is just goin to put in my own proposal and let y'all
              complain during the LC period
   <fantasai> :)
   <anne> background:red/blue url("test") 2px 2px no-repeat / 100% 50%
   <anne> o_O

F2F schedule, TPAC

   <jdaggett> glazou: you there?
   <glazou> yes
   jdagget: Chris sent email re: whether we consider to go to TPAC.
   ChrisL: there is deadline to determine group commitment
   jdaggett: we have a F2F in France, we also have TPAC. Do we do both, one ?
   <glazou> deadline 18-mar
   fantasai: the first question is whether we do TPAC; this is the place
             where we meet the other groups
   <glazou> the question is will we have enough people able to travel to france?
   fantasai: TPAC is more cost-effective since you can travel to multiple
             meetings at once
   <dbaron> http://lists.w3.org/Archives/Member/chairs/2009JanMar/0059.html
   <glazou> Tokyo itself is already a "small" meeting because of so many people
            having budget/travel restrictions
   <fantasai> not that small, glazou. The main participants missing are you
              and peter
   <fantasai> (since Apple is usually absent anyway ;)
   * glazou and Melinda, Molly, Bert
   <fantasai> ah, yeah
   <fantasai> Bert's missing too
   <fantasai> so
   <fantasai> all the official-type people
   * glazou and Emily and others
   * fantasai doesn't remember Emily
   <glazou> TPAC is also later in the year, can help have more agenda items
            in a better structured agenda
   <anne> reasons for Molly are not budget/travel
   <glazou> TPAC seems to me an almost mandatory meeting because of the join
            meetings and productive side discussios with other WG and W3C staff
   <sylvaing> discussion of TPAC attendance of other groups....
Scribe: fantasai
   Chris: Eric suggested a mini-TPAC of browser-oriented groups like SVG,
          CSS, HTML, WebApps, etc.
   Chris: Since we're not interested in meeting with Semantic Web etc anyway
   <glazou> that's a great idea
   Chris: SVG will not attend TPAC because they're doing SVG Open in the
          same area one month before
   <glazou> TPAC's location being not far away from Apple, I hope they will
   Attending: XML Core, Media Annotations, XML Security, WAI Education and
              Outreach, XHTML 2, and XForms say they are attending
   * anne it's the Forms WG, officially
   Not attending: Policy Languages, Semantic Web IG, WCAG, SVG, Timed Text,
                  WAI Evaluation and Repair Tools, MWI Test Suites
   Mike: We did a mini-TPAC thing once before, and it was really one of the
         better meetings
   Sylvain: Also if we're on the West Coast Arron can attend too
   <glazou> seems there's consensus on TPAC
   <ChrisL> mini-TP seems to be more of interest
   <glazou> but same time and location ? or different ?
   Steve: I would rather just do the TPAC
   fantasai: but you don't have to travel anyway
   Steve: I'd like to say the CSS would like to do the TPAC if a significan
          number of HTML, WebApps, SVG are also doing TPAC
   Steve: i18n is another one conceivably useful
   various: mini-TPAC would need to be in Bay Area
   SVG Open is in Cupertino, hosted by Google
   fantasai: We should probably arrange the mini-TPAC there and then, then
   <sylvaing> SVG Open 2009: Oct. 2-4 in Mountain View
   A large number of this group is on the West Coast
   <sylvaing> http://www.svgopen.org/2009/
   szilles: so if the other groups we're interested in meeting with were to
            attend TPAC we'd go; if not we'd consider SVG Open as an alternative
   RESOLVED: We will either do TPAC or mini-TPAC in Oct/Nov in Bay Area
   <glazou> please not svgopen attendance is not cost-free
   <fantasai> no, glazou, just before or after so we can meet with SVG
   <glazou> ok

   Discussing June in France
   Wed/Thurs/Fri of 1st week in June in Sophia-Antipolis
   <glazou> that's 3-5
   <glazou> please note 1st-jun is a holiday in france
   dbaron: I think we're stretching to get an agenda for a 3-day meeting
           for this one
   dbaron: I don't know if we're going to have more to talk about in 3 months
   dbaron: Stuff that's useful to have the whole group talk about, rather than
           stuff we can go off and do on our own
   dbaron: Part of that is my failure to do stuff for us to talk about
   dbaron: But if we're going to meet, then we should make sure it's worth it
   anne: It's pretty easy for me to go to France, but there should be an agenda
   Steve: JLTF took a lot of time, is not likely to happen in France
   howcome takes a count of how many ppl will attend
   <sylvaing> glazou, we assume you'd come to sophia ?
   <glazou> eh, of course
   howcome, Chris, Sylvain + 1, Anne, maybe dbaron, Steve, fantasai, glazou
   * glazou can't tell for Peter
   <sylvaing> and Bert
   <glazou> Bert won't have a long trip for that one :)
   Steve: Can we spend some time tomorrow discussing what kinds of things we
          will discuss there, and if we can't do that then we get a pretty
          good indication that the meeting isn't going to happen?
   <glazou> that supposes nothing will become a potentially interesting or
            important agenda item between now and June ?
   howcome: I think we should have homework in this group. Everyone who's an
            editor should have a new draft at least one week before the meeting
   howcome: Then at least the editor knows what issues to prepare and present
   Anne: Not much for the group to discuss for cssom-view
   Anne: namespaces and media queries are pretty much done
   Steve: Status on Snapshot?
   fantasai: Waiting on Selectors
   fantasai: Selectors is waiting for i18n
   Chris: i18n doesn't have anything
   <glazou> fantasai: we're beyond the 2 weeks limit we discussed, we should
            publish now
   RESOLVED: Publish Selectors as Last Call Working Draft
   <glazou> cool
   Four weeks LC period
   RESOLVED: 4 weeks LC period
   Steve: What they wanted to do isn't the right solution to the problem b/c
          it doesn't deal with most of the problem, and not even the most
          important part of the problem
   Steve: What's bothering me is that we haven't discussed a coherent way to
          fit normalization into CSS as a whole
   jdaggett: Isn't that also an HTML problem?
   <glazou> this is more a W3C-wide problem imho
   <fantasai> yeah, I totally agree
   <glazou> touches many many specs
   (jdaggett nods)
   <glazou> but that's clear we're impacted
   * glazou will have to leave in 10mns from now, business appt
   RESOLUTION: We plan to meet in France, and will work on discussing an
               agenda tomorrow
   <glazou> :)
   <glazou> have a good dinner all
Received on Monday, 9 March 2009 06:46:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:24 UTC