- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 20 Jan 2010 16:26:25 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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>
<http://lists.w3.org/Archives/Public/www-style/2009Dec/0234.html>
- 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>
<http://lists.w3.org/Archives/Public/www-style/2009Dec/0236.html>
- 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>
<http://lists.w3.org/Archives/Public/www-style/2009Dec/0239.html
- RESOLVED: Accept proposal to make transitioning 'visibility' values beween
0 and 1 map to visible.
====== Full minutes below ======
Present:
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
Administrative
--------------
glazou: extra agenda items?
(silence)
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:
http://lists.w3.org/Archives/Public/www-style/2010Jan/0319.html
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
behavior.
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
range.
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
somehow?
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:
http://www.w3.org/blog/CSS/2009/07/30/resolutions_73
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
integer?
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
instead.
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
explicitly.
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.
http://lists.w3.org/Archives/Public/www-style/2009Nov/0329.html
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
function.
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