- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 08 Mar 2009 23:45:43 -0700
- To: www-style@w3.org
Summary:
- 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
Attendees:
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
syntax
<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
options.
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
this?
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
break
<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:
http://dev.w3.org/csswg/css3-mediaqueries/disposition.html
<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
coding
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
-----------------------
http://www.w3.org/Style/CSS/Tracker/products/11
http://lists.w3.org/Archives/Public/www-style/2009Feb/0179.html
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
border-top+border-left+border-right+border-bottom
* 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
Options:
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
on
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
shorthand?
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> ]?
<border-image>?
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
wouldn't
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
http://dev.w3.org/csswg/css3-background/#the-background-color-property
<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
attend...
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
MEETING CLOSED!!!!
<glazou> :)
<glazou> have a good dinner all
Received on Monday, 9 March 2009 06:46:26 UTC