[CSSWG] Minutes and Resolutions 2010-01-20


   - Reviewed status of action items and CSS2.1 test suite
   - RESOLVED: Fix grammar to allow spaces inside parentheses in calc()
               ISSUE-116 <http://www.w3.org/Style/CSS/Tracker/issues/116>

   - RESOLVED: Clamp calc() results outside property's value range to within
               the range. Document that this requires all properties accepting
               calc() to define their range as closed (not open) intervals.
               ISSUE-117 <http://www.w3.org/Style/CSS/Tracker/issues/117>

   - RESOLVED: min() and max() take one or more arguments
               ISSUE-112 <http://www.w3.org/Style/CSS/Tracker/issues/112>

   - Discussed dbaron's email about calc() being overly-restrictive wrt units.
     Agreed that the output of calc() just needs to match the input of the property.
     WG seems interested in having value / value divisions, and in cases where this
     leads to division by zero, to have it fall back to inherit-or-initial as
     defined by the property's default inheritance behavior. dbaron to write up
     a proposal.
       ISSUE-118 <http://www.w3.org/Style/CSS/Tracker/issues/118>

   - RESOLVED: Accept proposal to make transitioning 'visibility' values beween
               0 and 1 map to visible.

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


   Tab Atkins
   David Baron
   Bert Bos
   Beth Dakin
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Håkon Wium Lie
   Peter Linss
   Alex Mogilevsky
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/01/20-CSS-irc
Scribe: Tab Atkins


   glazou: extra agenda items?
   glazou: Action items from last week!
   glazou: First was on me to respond that Tab's response was official.  Done.
   glazou: Second action was on Tab to summarize pt/px.
   TabAtkins: Did so last night; David Singer's was mostly correct.  I just
              added implementation experience.
   glazou: Third was on Simon for dbaron's rules?
   <glazou> yes
   smfr: Done.
   glazou: Bert, review style-attr issues.
   glazou: Any further action on any of the items?  Tab?
   TabAtkins: Everybody agrees, so all we neeed to do is think on Brad's
              suggestion and then integrate into a spec.
   smfr: Everyone needs to read mine and see if they agree.  We also need to see
         if we want to allow scinot in numbers, which will affect the grammar.
   <smfr> Here is my suggested amendment to CSS Numbers:

Test Suite Status

   glazou: Second item - test suite!
   glazou: We were expecting some things last week.
   glazou: fantasai said that Boris still had so solve some issues and
           contribute something, and by the end of the week she should be
           ready to be published to the test suite.
   fantasai: Yup, still gathering them right now.  Mozilla also gathered
             a bunch of tests.
   glazou: After the 15th deadline?
   fantasai: Don't remember exactly, but somewhere around then.
   dbaron: I submitted them on the 14th.
   glazou: We need to stop accepting tests.  So let's gather tests, publish it,
           and show w3c that we're moving.
   dbaron: Boris did not submit his run-in tests late.

CSS3 Values: calc() grammar

   glazou: css3 values issues.  There's a bunch.
   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0234.html
   dbaron: I don't think this needs much discussion; I think it's just an
           error that we didn't allow whitespace in calc just inside the parens.
   RESOLVED: add spaces inside parentheses in calc()

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0236.html
   dbaron: Some properties, like width, have negative values as parse errors.
   dbaron: In calc you can't always determine if a result is negative at
           parse time.
   dbaron: 1) Does the restriction on the individual values change what's
              allowed for each value inside calc?
   dbaron: 2) What do you do when the calc gives a negative result?
   dbaron: When you're parsing a calc, you're looking for individual values
           that are acceptable for the value.  If it accepts length, you
           look for length.
   dbaron: But we shouldn't disallow negative values *inside* the calc, so
           width: calc(50% - 2px); should still be valid, even though -2px
           isn't valid.
   dbaron: Second, what to do when the calc gives a value outside the range,
           clamp it to the range.
   dbaron: So for width, a negative value would become 0.
   howcome: That would make the behavior different from normal behavior.
            width: -2px; is just ignored, right?
   dbaron: Yes.
   howcome: You're not proposing to change the non-calc case?
   dbaron: No.
   howcome: Is there a way to keep it ignoring?
   TabAtkins: I think the clamping behavior is virtually *always* the expected
   dbaron: It also makes it more complicated to fail it rather than clamp it.
   howcome: Is there any way to make the clamping the default behavior,
            so width:-2px; is the same as width:0;?
   dbaron: I don't think that's web-compatible at this point.
   glazou: You said it's more complicated to fail rather than clamp.
   glazou: But is it really?  Clamping requires knowledge of the property's
   dbaron: You'd need to carry around extra cascade information, since you
           might not know if fails until after layout.
   szilles: Is it obvious there's a clamp value that works for everything?
   dbaron: I believe in current css it is.
   dbaron: We don't have any float-valued properties that accept only
           positive values.  Integer values, yes, but not floats.
   smfr: Does opacity affect negative values?
   smfr: Isn't that a float value that is restricted to positive values?
   dbaron: Nah, it accepts 0
   Open intervales are a problem. Closed intervals are fine.
   szilles: Somewhere that assumption should be documented, just so we don't
            accidentally create a float-valued property that only accepts
            positive values.
   szilles: Probably in the Values spec.
   RESOLVED: Clamp calc() results outside property's value range to within
             the range. Document that this requires all properties accepting
             calc() to define their range as closed (not open) intervals.

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0237.html
   dbaron: Whole bunch of followups, and I still need to reply to the last one.

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0238.html
   dbaron: I can give a full description, but I'd like to defer it until I
           write up what I'm trying to implement.
   glazou: Okay, deferred.

   dbaron: I think we agreed in the past to add min and max to calc.
   dbaron: This is a proposal for how to do that in the grammar.
   dbaron: I don't know that there's much to discuss, as long as other people
           agree with my memory that we should add min/max.
   howcome: Yeah, it's in the minutes.
   howcome: Are we adding any circular dependencies that need to be resolved
   dbaron: I'm not seeing how.  It's just min/max of values.  Say, "larger
           of 3em or 20px".
   <fantasai> min & max added to calc:
   howcome: So min/max takes comma separated values?
   dbaron: yes.
   szilles: What about max(50%)?
   dbaron: Yes, frex, max(50%,200px).
   dbaron: If that's a problem, it's a problem with % to begin with.
   bert: It doesn't look like the grammar disallows going over numbers, frex,
         max(1,2).  Is that intentional?
   dbaron: Intentional, but only becuase I didn't see much reason for it.
           If people want it for symmetry, that's fine.
   bert: If you divide 2em by 2em, you'll end up with the number 1.
   dbaron: That ties into the previous issue, that I wanted to skip over for now.
   bert: You're saying you can only divide by number, not units?
   dbaron: Not quite what it actually says, but I think what it meant to say.
   szilles: Is there a usage of min/max to guarantee that you end up with an
   szilles: floor/ceiling, that is, in the number case.
   dbaron: floor and ceiling with lengths are more complicated, as you have
           to figure out what unit it should be relative to.
   dbaron: In the grammer I'd like to end up with, the result of a division
           would always be a length, not a number.
   glazou: I have a case.  Frex, if you want to have the full width, 100%,
           divided into columns of 200px, you could do calc(100%/200px) and
           would get a column-count value.

   dbaron: What's hard about that is figuring out what to do with division by 0.
   dbaron: The spec currently says that division by zero in calc is a parse error.
   dbaron: Which is fine as long as you only allow division by number.
   dbaron: But if you allow division by values, you have to be able to compute
           all values at parse time, which isn't possible.
   dbaron: Preventing division by values prevents that case.  The grammar
           currently says that, but I'm not ceretain if that was the intention.
   bert: I recall that was the intention.
   szilles: You want a parse error so you can do fallback, right?
   dbaron: yes.
   dbaron: I can implement the division by zero case, I just don't know what
           I should do with it.
   plinss: Use animation/transforms and do a swirling black hole.
   szilles: Make the entire screen blue.  It's well established.
   glazou: We'll keep that in mind.  Let's move on with David's proposal.

   glazou: Objections to min/max proposal?
   <Bert> (Before we decided to add min() and max(), the calc() was a fancy
           notation for a 4-tuple: a px + b em + c cm + d %. The a b c d
           could be calculated at parse time.)
   szilles: If we allow division by values, does that affect min/max?
   dbaron: If we allow it, there's more reason to allow min/max on numbers,
           rathere than just units.
   dbaron: It's a syntax thing.
   dbaron: But in the next issue, I think we need to rework the whole
           grammar anyway.
   * sylvaing wants a 'It's a syntax thing' t-shirt
   dbaron: It's just details, but I don't think it's worth discussing the
           details of the productions too much given the other issue we're
           skipping right now.
   szilles: Why do you require two expressions in min/max?
   dbaron: I don't care which way, whether we do 2-or-more or 1-or-more.
   Bert: it should either be 1-or-more or exactly 2
   TabAtkins: I say 1-or-more.  It makes sense and is simple.
   several: agree
   RESOLVED: min/max take 1 or more arguments.

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0239.html
   dbaron: There are a bunch of examples in the spec of calc using both
           lengths and %.  but the grammar says it only uses lengths.
           Not %, not angles, not times, not frequencies.
   dbaron: I think we should say that the values allowed in calc should
           match with the values for the property in some way.  Units as
           appropriate for the property.
   glazou: That would be useful for rotations, frex.
   glazou: I support that.  Other opinions?
   several: Yeah.
   szilles: So, the syntax isn't going to limit what's there, other than
            that the value that calc produces must be of the right kind.
   dbaron: We want to limit it so that the value is right for the property,
           but we probably want to limit it in some way.  We may not want
           arbitrary keywords, frex.  We may also not want integers.
   bert: And colors as well?
   dbaron: Right.
   bert: Do you suggest we write 3 or 4 grammars, all the same except for
         the atomic unit?  Or one grammar with some explanatory text saying
         that the end value has to be of the right kind?
   dbaron: Yeah, one grammar, with a production referring to some text that
           defers to the property, restricting it to values that calc allows.
   szilles: If you allow division by values, writing a syntax for it would
            be very difficult.
   dbaron: Yeah, that's part of the followups to the message we skipped.
   dbaron: The current grammar has some weird cases where it allow a*b/c or
           when parenthesized one way, but not parenthesized another way.
   szilles: Basically, i was trying to say "Keep the grammar simple, and
            put the explanation in the text"
   dbaron: Yes, that was one of my suggestions in te thread.  But then
           there's questions of what we want the restriction to be.  But
           I think we're better off putting the unit restrictions in the
           text, not the grammar.
   szilles: And this relates to both the divide-by-zero and the limit thing?
            Basically it says "when you use calc you won't get a parse error
            unless it's really a parse error".  You'll get an invalid value
   dbaron: Nah, sometimes you'll get a parse error, like if you put a unit
           in calc that doesn't match what the property expects.  Or a unit
           mismatch, like an em plus a number.
   szilles: But you might have two angles that produce a unitless number,
            which could be allowed.
   dbaron: Yeah, that's part of what we skipped.  I'm tempted to say we
           don't allow it for the first version.
   szilles: How about defining incommensurate expressions, like numbers to
            lengths, and saying these are disallowed, but everything else
            is allowed?  And the result must be of the correct type?
   dbaron: One possibility is that you track units all the way down for
           each operation.  And then at the top you check that the answer
           has the right unit type: length, frequency, etc.
   szilles: It seems to me that is the right way to do it, and if we find
            specific combinations that should be disallowed, put them in
   dbaron: One possibility is to forbid any unit that's not a valid type
           for the property.
   szilles: I want to avoid that, because it doesn't make sense in the long term.
   szilles: Like taking the ratio of two angles to decide a length.
   dbaron: I'm okay with that, but it requires we deal with division by zero.
   szilles: But we have to do that anyway, right?
   dbaron: Depends.  If we disallow division by values, then it works out.
   plinss: What about clamping div-by-0 to the maximum allowed value?
   dbaron: There really isn't one.
   szilles: Yeah, you may be doing infinite-precision arithmetic.  I think
            we need to do a different thing for div-by-0 anyway.
   szilles: It seems to me that it should *work* like a parse error, but
            without keeping the fallbacks.
   dbaron: Yah, just compute to the initial value is an option.

   szilles: It should inherit if the value is inherited, use initial value
            if not inherited.
   szilles: The same as if there *were* no other fallback.  If there was
            nothing else setting the property, you get the initial value.
   plinss: But that's a different problem then negative numbers, where we clamp.
   plinss: as you approach division by zero, your value approaches infinity.
   szilles: Not with 0/0
   TabAtkins: That's undefined.
   plinss: We can define it.
   dbaron: You don't know the sign of the infinite value, because you don't
           know if you approached 0 from above or below.
   szilles: Is it so bad to have a discontinuity when you divide by 0?
   <sylvaing> (said zero could even come from previously mentioned clamping...)
   plinss: but it won't be hardcoded, it'll be computed, and then you'll
           have a discontinuity.
   dbaron: Where a division-by-0 happens anyway probably isn't important
           for authors anyway, as it's probably not usually doing something
           that they actually intend.
   szilles: You can use min/max to prevent the divide-by-zero.
   szilles: There are ways to work around it.
   plinss: If the author finds out about it.
   TabAtkins: But the value will blow up before it hits div-by-0, and if the
              case is at all likely, the author will find it anyway and can
              stop it.
   glazou: Doesn't sound like this is getting resolved.
   dbaron: Sounds like the will of the group is that we want division by values.
   several: Yes.
   dbaron: Then the question is what to do in the div-by-0 case.
   dbaron: I'm partial to falling back to initial value.
   <fantasai> I would also prefer inherit-or-initial
   dbaron: Then should we do initial, or inherit-or-initial?
   several: inherit-or-initial.
   dbaron: It might be harder to implement, but I'll think about it and see.
   ACTION: dbaron update proposal for min/max and to allow value/value divisions
           with fallback to initial-or-inherit for div-by-0 cases.
   <sylvaing> so if the value is out of range we clamp, if it can't be computed
              we fallback to initial/inherited ?
   <dbaron> it includes one of my favorite spelling mistakes, though :-)

Variable-sized Columns

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0256.html
   glazou: A proposal of mine to allow differently-sized columns.
   glazou: Right now colunn-width takes one argument.  Proposal is to allow
           property to take multiple values.
   fantasai: I think it's a very interesting idea, and we want to look at
             it in the future.  But I don't think it's right for right now.
   fantasai: We already have lots of pagination problems, and ROC says that
             some implementations don't have the architecture for columns
             of different widths, just as they currently have trouble with
             pages of different widths.
   fantasai: So until we get better page-layout architecture, I think we
             should file it away for the future.
   glazou: That's fine with me.
   howcome: It's an easy change in the grammar, but it's a complex change
            for implementors.
   howcome: We've just gone to CR, and have several impls that do the same
            thing, so I think it's too much for right now.  But I do see it
            being useful in the future.
   szilles: When XSL did this, they were using a * system also, because
            sometimes you don't want explicit values for the column width,
            but distribute.
   szilles: It's not quite percentages, but you want to be able to say,
            "This column should be twice as wide as that one".
   glazou: Okay, we'll keep it for the future.  People at leaest agree that
           the feature is interesting.

Transitions Issues

   glazou: I don't think we can discuss any of the remaining issues in 4 minutes?
   dbaron: 2nd transitions comment should be trivial.
   smfr: I thought we already talked about this and agreed it was a mistake
         in the spec?
   dbaron: I think we all agree it's a mistake in the spec, and we can solve
           it in two minutes.
   dbaron: The transition spec has a rule to interpolate visibilty.
   dbaron: The intent is that it's visible at all points between, and
           hidden at the end.  But it says the opposite.
   RESOLVED: Accept proposal to make transitioning 'visibility' values beween
             0 and 1 map to visible.

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html
   smfr: This is related to having transition-delay apply to all properties.
   smfr: I think it's already related to Dean's proposal of a stepwise timing
   smfr: It would allow applying transitions to all properties, since you'd
         just snap between values.
   szilles: Is this related to the discussion when you restart transitions?
   [clarification of szilles's point]
   smfr: No, not related to that.
   smfr: I think it's a reasonable proposal, but I'd have to think more about
         it and implement it to see if it gets out of hand.
   smfr: There's a risk that you're saving transition information about
         everything on the page, which may have performance implications.
   smfr: I won't have time to try it out in my impl for a few weeks.
   dbaron: I think we also want to discuss this with Dean's proposal.

Meeting closed.

Received on Thursday, 21 January 2010 00:27:02 UTC