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

[CSSWG] Minutes and Resolutions 2009-04-08

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 08 Jun 2009 12:02:12 -0700
Message-ID: <4A2D6034.1010001@inkedblade.net>
To: www-style@w3.org
Summary:

   - Discussed whether telecon agenda should be public or private. So far
     administrivia has been kept off the public mailing list, and since
     there wasn't much enthusiasm for shifting the agenda, it will stay
     on the internal mailing list
   - RESOLVED: For CSS2.1 Issue 24
               duplicate malformed declarations rule for malformed statements
               (statements rule to come after declarations rule in the spec)
   - RESOLVED: Yves' message about class selector grammar
                 <http://lists.w3.org/Archives/Public/www-style/2009Feb/0299.html>
               is a non-issue.
   - RESOLVED: Accept Bert's proposal on CSS2.1 grammar
                 <http://lists.w3.org/Archives/Public/www-style/2009Feb/0619.html>
   - RESOLVED: Publish update to CSS2.1 with errata incorporated
   - RESOLVED: adopt Brad Kemper's border-image proposal to avoid relayout but
               make the syntax easier to understand
                 <http://lists.w3.org/Archives/Public/www-style/2009Mar/0389.html>
                 <http://www.bradclicks.com/cssplay/border-image/Thinking_Outside_The_Box.html>

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

Attendees:

   Bert Bos
   David Baron
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Melinda Grant
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   David Singer

<RRSAgent> logging to http://www.w3.org/2009/04/08-css-irc
Scribe: Chris Lilley

Agenda - Member or Public
-------------------------

   Can we discuss the sophia agenda briefly?
   Chris asks why agenda is member only but minutes are public
   Admin is member only, tech is public
   Daniel: chris suggests sending agenda to the public list
   Bert: why? no advantage
   dd: agenda almost always public. any member -specific stuff is rare and
       can be discussed separately
   <dsinger> I think the current arr. Is odd but right
   Peter: can post the agenda minus the dial in numbers to the public list
   dbaron: public may have useful feedback
   Melinda: if agenda is early enough
   Bert: don't want to do this, writing for the public takes to much time.
         unecessary
   Sylvain: specific example?
   Bert: want to hide spelling mistakes
   Peter: how about we send the agenda to the members mailing list and
          send a synopsis to the public mailing list
   <dsinger> Has any public asked?
   ChrisL: dave - no
   <dsinger> They see the minutes
   dbaron: how would they ask for it without knowing it exists
   Daniel: minor issue, no consensus to move to public agenda.
   <dsinger> It is work to fix, and does not seem worth it
   ... could take more time to sort through public feedback before meeting
   ChrisL: ok, thanks for considering it
   Daniel: we stay as we are for the time being

CSS2.1 Issue 24
---------------

   <glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2009JanMar/0212.html
   http://wiki.csswg.org/spec/css2.1#issue-24
   Everyone had an action to read Bert's email and prepare for discussion
   fantasai: made comments in email
   <fantasai> no, actually, last week's minutes
   <dbaron> the "     apple][  {color: red}" is actually a lot more complicated
            than Bert said
   fantasai: wasn't berts comment supposed to be sent to public list?
   dbaron: contents of email seem reasonable but i don't see a proposal
   dbaron: two examples look a bit complex
   <dbaron> complex in that they're more complicated than stated because of
            ()/[]/{}-matching
   Bert: my preference is to not do anything
   Bert: this is as far as I got
   fantasai: it doesn't adress selectors.  want it to cover at-rules and
             declaration blocks
   fantasai: idea that you match brackets and quotes is clear enough without
             specific microparsong rules
   fantasai: there is an error in the spec as we changed the wording and
             introduced a new issue
   fantasai: proposal was that the part on malformed declarations was
             changed to stateents
   <fantasai> http://www.w3.org/TR/CSS21/syndata.html#parsing-errors
   <fantasai> There's a rule about malformed declarations
   fantasai: should be "statements and declarations"
   Bert: not sure you always know if you are in a statement or not
   fantasai: in one if you are not in a declaration
   fantasai: @rule is always a statement
   fantasai: if you are in a decl skip to end of decl, else skip to end of that statement
   Bert: no statements inside an @media
   Bert: they look like statements, but they aren't according to the grammar
   Bert: hence the complex email, there are different types of @rules. @media
         and @page are different
   Bert: take last example in my email
   Bert: you are at the top level then you see an invalid string. have not
         started the first statement
   Bert: have to assume you are unless you are clearly not eg a comment
   Bert: would like it to be as simple as elika says but doubt it is that simple
   fantasai: only unclear case is inside @page in css3
   fantasai: so suggest duplicating the malformed rule for statements, then
             add more detail in css3 paged media
   Daniel: good compromise. is it acceptable?
   Bert: imples an error inside an @rule causes whole @rule to be ignored?
   fantasai: depends on where it occurs
   fantasai: not if the @rule has declarations.
   fantasai: trap points are statements and declarations
   dbaron: yes
   <dbaron> I think in the long run we should have a single grammar that has
            "unexpected content" productions that match pretty much anything
            and which correspond to the pieces that get ignored
   Sylvain: what are the chars that are matched?
   <fantasai> fantasai: brackets and quotes
   <sylvaing> yeah so content:"}" does not cause havoc
   <dbaron> also [
   <fantasai> and '
   <fantasai> :)
   <sylvaing> ()/{}/[]/""/''
   Daniel: any objections to fantasai's proposal
   (none heard)
   Bert: ok lets try it
   RESOLVED: duplicate malformed declarations rule for malformed statements
             (statements rule to come after declarations rule in the spec)
   dbaron: I think in the long run we should have a single grammar that has
           "unexpected content" productions that match pretty much anything
           and which correspond to the pieces that get ignored
   dbaron: this is a rather big project
   Daniel: I agree in principle, on desirability and timeline

issues with CSS2.1 Grammar
--------------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Feb/0299.html
   <ChrisL> http://lists.w3.org/Archives/Public/www-style/2009Feb/0538.html
   Daniel: should a class be a name instead of an ident?
    * sylvaing loves Yves signature quote
   dbaron: why?
   fantasai: I think he missed the point of the section
   Daniel: and why to escape the first digit
   fantasai: This section is comparing css1 and css2,  I think he is confused.
             CSS2.1 longer allows this
   Daniel: agree, not an issue
   RESOLVED: non-issue
   <dbaron> somebody should respond :-)
   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Feb/0538.html
   ACTION: daniel to respond to yves saying why ident is not an issue

   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2009Feb/0538.html
    * dbaron notes that Yves's signature quote is not handled very well by
             Google Translate
   Bert: yes, the S token is ambiguous
    * ChrisL would be surprised if google translate can deal with nissart
   Bert: ok to change the grammar
   Daniel: so remove s* from end of import?
   Bert: yes
   bert's response http://lists.w3.org/Archives/Public/www-style/2009Feb/0619.html
   <Bert> http://lists.w3.org/Archives/Public/www-style/2009Feb/0619.html
   Peter: agree
   Bert: yves says its easier if no non terminals can produce an empty string
   ... can accept that
   Daniel: any objection?
   (non heard)
   Daniel: choices in berts email seem harmless
   ... and obvious
   RESOLVED: accept berts proposal on gramar
   ACTION: bert make the changes in
           http://lists.w3.org/Archives/Public/www-style/2009Feb/0619.html

   Sylvain: do we have any outstanding 2.1 issues before publication?
   Daniel: no, so lets publish and update as soon as possible
   fantasai: bert and I will check all the edits have been made
   dbaron: so i put an issue on the end of the list
+SteveZ
   dbaron: font-weight bolder and lighter, want to backport from css3 to css 2.1
   <dbaron> issue 111
   ChrisL: is it simple to specify?
   dbaron: yes but no proposed text yet
   Bert: prefer to see actual text
   (several) yes
   dbaron: fine to publish but there is more stuff to do
   fantasai: boris has some pending issues on anonymous tales still to come
   RESOLVED: publish and update to css 2.1 asap
   <fantasai> Bert, we should schedule a day to coordinate on 2.1

Fallback color on background-image
----------------------------------

   http://lists.w3.org/Archives/Public/www-style/2009Feb/0536.html
   fantasai: at f2f we decided I would propose text so we don't need to
             discuss this now

Fallback on border-image
------------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Mar/0389.html
   <glazou> http://www.bradclicks.com/cssplay/border-image/Thinking_Outside_The_Box.html
   Daniel: who can summarise this?
   fantasai: several open issues from discussions with dave hyatt,
             brad kemper's proposal addresses all of them
   fantasai: look at his pictures
   fantasai: if image fails to load, layout jumps around. also layout
             changes depending on border-image support
   fantasai: so want it to not affect border-width
   fantasai: example with a jutting corner
   fantasai: makes a lot of sense
   fantasai: also says designers want an image where layout aligns with a
             given point of the image, wants to allow some overflow
   fantasai: minor issues to discuss on mailing list, precise syntax, but
             we should adopt this
   fantasai: hyatt and roc in gfavour
   Daniel: demoed boder image, people were scared by the nuber of arguments
           and this adds four more. its hard to remember
   fantasai: maybe a shorthand with individual properties like border-image-offset
   fantasai: more understandable at expense of adding more properties
   Daniel: public wants it to be simpler and easier to understand. need to
           look at very carefully
   ... seems to meet web designer's wishes
   Bert: what if the border image is wider than the box itself?
   fantasai: probably it gets clipped
   dbaron: there is some rule to explain how to handle this
   fantasai: needs to be worked out in detail
   Daniel: any objection to moving forward on this proposal
   howcome: not studied in detail yet
   Daniel: so, do we adopt this direction and develop it further?
   ... main issue is relayout which is a big issue
   fantasai: hyatt raised this also
   Daniel: does make sense
   Daniel: any disagreement?
   (none heard)
   Daniel: several options, functional notation or shorthand
   Sylvain: I like the proposal, but usability of the syntax is a concern
   RESOLVED: adopt this direction to avoid relayout but make the syntax
             easier to understand

next f2f in sophia
------------------

   <fantasai> http://wiki.csswg.org/planning/sophia-2009
   Daniel: need agenda items to help people with travel planning
   fantasai: pleae add topics to the wiki
    * dsinger makes it easy!
   dsinger: no specific ones to suggest but might be difficult getting
            apple dev there as right before out dev conference
   <Bert> Currently known topics: test suites, and grid/matric/template layouts
   SteveZ: last day of japan f2f should have a list of topics
   fantasai: will add them
    * sylvaing can confirm alexmog will also be there so there will at least
               be a real engineer for Microsoft :)
   dsinger: three day meeting all day?
   Daniel: yes


Other
-----

   Daniel: any other items?
   howcome: thinking on column break vs page break. any strong opinions?
   fantasai: melinda and i discussing, no opinions yet
   howcome: want to bring back the column-break-{before, after, inside}
            rather than having this in the page properties
   SteveZ: then you have an interaction problem
   howcome: yes, needs to be defined
   <melinda> I'm kinda leaning the same way... maybe with a shorthand to
             combine them...???
   howcome: yes, shorthand could be good. will propose text

adjourned

<RRSAgent> http://www.w3.org/2009/04/08-css-minutes.html
Received on Monday, 8 June 2009 20:02:51 GMT

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