[CSSWG] Minutes and Resolutions 2009-07-29


   - Discussed combining background-break and border-break into box-break;
     fantasai to draft proposal into Editor's Draft for discussion

   - RESOLVED: Add min() and max() functions to calc(); min() and max() may
               also appear as standalone functions, their contents parsed
               as if wrapped in calc().
   - RESOLVED: Allow keywords in expressions.

   - Reviewed issues raised for Media Queries; they are editorial, so Anne
     will prepare a new CR draft.

   - Confirmed that repeating a pseudo-class increases specificity; will add
     clarification note to Selectors

   - Discussed fantasai's box-shadow and border-image message:
     No resolution yet.
     Original discussion was here:

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

   David Baron
   Bert Bos
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   David Hyatt
   Peter Linss
   David Singer
   Anne van Kesteren
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2009/07/29-CSS-irc

Scribe: szilles
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jul/0120.html
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Jul/0114.html

Background-break and border-break

   Hyatt: I was attempting to simplify the two properites because people will
          often want the same values on both properties and not all the
          combinations of the independent properties make sense
   fantasai: I think a combination does make sense, but I am not sure what
             the values should be
   fantasai: what behaviors should we be trying to acheive
   fantasai: for border break we might want more sophistication in the styling
   fantasai: e.g. "hidden" adds padding
   Hyatt: I might want to see a different background in each box
   Hyatt: Is this the right way to do the "bounding box" because some of the
          current renderings are awkward
   Hyatt: could we drop certain features from the combined property knowing
          that we might do things better in a future version
   dbaron: Most often the authors will just be specifying background-break
   dbaron:  Most of the time authors won't be using both borders and backgrounds.
   Daniel: there is also the issue of authors being able to reduce complexity
           and still allow authors to get the features they want
   dbaron: having just one property does not necessarily help with readability
           in the most common case
   Hyatt: a simplification is that the author would say the same thing whether
          they were only doing borders, only doing background or both together
   Bert: concern about the name
   Bert: i like having a single property describing how to handle boxes near
         (page) breaks
   Hyatt: by using a new mechanism, like background attachment fixed, you can
          get backgrounds on the page when there are multiple columns on the page
   Hyatt: for otherwise, you can only affect the column boxes
   Action: fantasai Draft a proposed combindation of the properties

Min and Max functions in CSS3

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Jul/0014.html
   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Jul/0015.html
   dbaron: there is a message that says these should be added inside calc();
           I support that addition
   fantasai: would calc() be required to do this?
   <fantasai> I don't want to write width: calc(min(80ch, 100vw));
   fantasai: Allowing it in calc makes sense, but do we need to require it
             to be inside calc()
   <Bert> I think fantasai asks if it is always calc(min(A,B)) or is min(A,B)
          on its own also fine?
   <annevk> calc(min(80em-2px,100vw)) ?
   Hyatt: do you mean that you could just say min width instead of requiring
   <dbaron> I'm ok with allowing it at toplevel, but then there's the question
            of whether to allow or disallow min(20em-2px, 19em)
   Hyatt: it might be simpler to just allow usage in calc right now
   Hyatt: if we specify it and not allow it inside calc people would object
   Bert: But this changes the model of calc, changing calcs output from a
         vector to a tree
   <fantasai> min(calc(20em-2px), 19em);
   <annevk> calc(min(80em - max(12em+16px,12.5em),100vw))
   fantasai: How about allowing calc inside min, but not min inside calc; that
             would solve most of the use cases people seem to want
   <dbaron> I'd actually probably be happy with making min() just be syntactic
            sugar for calc(min()), etc.
   <annevk> +1 to dbaron
   <sgalineau> +1
   dbaron: what I meant by my syntactic sugar suggestion is that you could use
           other calc expressions inside the min()
   <dbaron> min(20em-2px, 19em)
   <dbaron> rather than
   <dbaron> min(calc(20em-2px), 19em)
   <glazou> calc(min(80em - max(12em+16px,12.5em),100vw))
   <sgalineau> dbaron, are we saying we like the latter or the former ?
   <annevk> (that one was rather crazy :) )
   <dbaron> another possibility is that we allow calc() inside calc(), as the
            same thing as ()
   Someone mentions width: min(20em, auto);
   <Bert> min(1em,thick)
   <sgalineau> whoa
   Bert: some keywords are easier than others; for example what about 'inherit"
   Daniel: the expresion calculation should be based on the used or computed
           value, but certainly not the specified value
   fantasai: The computed value stores the expression, the used value evaluates
   fantasai: if we are allowing keywords, that makes the storage of the result
             value more complicated; it is no longer just a tuple
   dbaron: you have to already deal with complexity in values like width
   <glazou> auto - 10px
   dbaron: so having trees isn't much additional complexity
   <sgalineau> min(auto-10px,10%+2.5em)
   SteveZ: there are some "auto"s that when used in expressions would give
           circular calculations
   Daniel: I hear that people agree on allowing min inside calc; but do we
           want keywords too
   Bert: I would like the result of computing the result be independent of
         the property for which the value is being computed
   dbaron: but, percentages already have different meanings for different
   fantasai: I think it's more important to allow keywords inside min than
             min inside calc
   fantasai: I think having calc and keywords inside min would solve most
             of the use cases
   fantasai: We did resolve to require spaces around - and + to allow for
             keywords inside calc().
   fantasai: But there are some implementations that currently do not require
             spaces around "+" and "-".
   ChrisL: They might change if keywords are allowed, giving them a use case
           for requiring the spaces
   Daniel: Summary: I hear peoiple supporting both calc inside min and keywords
   Daniel: I hear no objection to DB's proposal that min(x, y) is syntactic
           sugar for calc(min(x,y))
   <Bert> I think "syntactic sugar" means: if the only thing inside calc() is
          another functional notation ("foo()"), then calc() can be left out.
   ACTION: Daniel negotiate with Håkon to update his module with the above
   RESOLVED: add min() and max() to calc(), allowing min() and max() alone
             assuming wrapped calc()
   RESOLVED: allow keywords in expressions
   * Bert next topic: adding tan(), sin() and log() :-)
   * dbaron waits for asinh
   * Bert : sin() and repentance()
   * fantasai is happy with the resolution as long as the implementors are happy
       implementing it :)
   <hyatt> "happy" :)

CSS Media Queries

   AvK: What is the next step; do we publish a new draft
   AvK: I can make edits to satisfy the 4 comments so far. Should the next step
        be WD or CR?
   Bert: if the changes are only editorial then the new draft can also be a CR
   <dbaron> It might be nice to see a diff at some point (e.g., when we're about
            to make the decision to publish).
   AvK: I will have a new draft for next week
   ACTION: Anne prepare new CR with the editorial changes

   dsinger: the media and audio tags allow a media query in the source selection;
            should the users accessability needs be added to thet query
   ChrisL: that sounds like a good idea
   fantasai: people have said that they want different styling when an image is
             loaded, but this like the above should be in a future version
   AvK: I think that we should allow these features, but I would prefer a
        "registry" approach to adding new query categories rather than requiring
        a spec update for each addition
   dsinger: The idea is that one could inquire about the accessability features
            that might be included in a given source file
   <annevk> media="all" media="all and (captioning)"
   Summary: people think this is a good idea
   * dsinger did not get any responses on the HTML5 lists
   <annevk> prolly because it was obvious dsinger :)
   * fantasai would prefer specs to registry, we will get all kinds of
              ill-defined/vendor-specific things if it's just a wiki page
   <annevk> you'd need a spec to get in the registry of course

Specificity increase due to repetition of psuedoclasses

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Jul/0046.html
   <hyatt> seems hacky but legal to me
   fantasai: yes, specificity inreases and multiple occurances are legal and
             it is hacky
   <hyatt> i'd hate  to have to special case this to not increase specificity
   <hyatt> that would just create work for implementors
   Bert: it is a bit hacky and I am not sure it should increase specificity
   Sylvain: I would just like an example that shows that it is legal and it
            does increase specificity
   Peter: This is a giant hack and calling it out is bad form
   dbaron: this applies to everything but tags
   Daniel: it does not apply to tags because only one element selector is
           allowed per chain
   ACTION: fantasai Add a clarifying note to Selectors to say multiple occurances
           are allowed and increase specificity
   <hyatt> some of the pseudo elements are sufficiently complex (nth-child) that
           i suspect most implementors just do a list for selectors :)

Box Shadow and Border Image

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jul/0120.html
   fantasai: I want to lock down a practical version of the spec. I would prefer
             leaving the spec as it currently is, no new features
   fantasai: I posted my reasons for wanting border-image to mask for box-shadow
   fantasai: The main question is how to handle "spreads";
   Chris: taking an arbitrary geometry bigger takes converting a path around
          the object to a stroke; then converting that to two paths and taking
          the union of the paths
   Peter: are we OK with saying the spread is (may be) ignored for borders
          (it works on boxes)
   fantasai: I am arguing that we want the UA to compute an appropriate shadow
             for a border-imaged box
   fantasai: I'm suggesting the proposal posted by Robert O'Callahan and Dave
             Hyatt, rather than what Chris Lilley proposed
   fantasai: I am happy with saying implementations may choose to ignore
             spread on border images if they want
   ChrisL and Hyatt: We should require that "spread" is ignored for border-image
   decision: allow ChrisL time to read the roc/hyatt discussion
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Feb/0361.html

Received on Thursday, 30 July 2009 19:07:40 UTC