- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 06 May 2012 14:17:39 -0700
- To: www-style@w3.org
Summary:
- RESOLVED: errata 2.1 to diasallow 'inherit' as a keyword in unquoted
font family names
- RESOLVED: include sign in NUMBER, PERCENTAGE, DIMENSION tokens in 2.1
- RESOLVED: The result or attr() is of integer type if all operands
are integer and there is no division.
- RESOLVED: Allow attr() in calc() and disallow cycle().
- RESOLVED: cycle() is top-level only; when attr() is not at top level
then the type of the fallback must match the type of attr()
- RESOLVED: Drop minimum supported multipliers for repeated components
from 30 to 20.
====== Full minutes below ======
Present:
Rossen Atanassov
Tab Atkins
David Baron
Ryan Betts
Bert Bos
Arron Eicholz
Katie Ellison
Elika Etemad
Simon Fraser
Daniel Glazman
Arno Gourdol
Vincent Hardy
Koji Ishii
John Jansen
Brad Kemper
Håkon Wium Lie
Peter Linss
Divya Manian
Anton Prowse
Florian Rivoal
Alan Stearns
David Storey
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/05/02-css-irc
Scribe: Bert
Administrative
--------------
plinss: Any extra agenda?
fantasai: Adobe is organizing a test suite hackathon in June,
was wondering if we can make that an official CSSWG event.
stearns: Still in planning stages.
vhardy: Let me check, but should not be an issue. Could be FXTF event.
plinss: Could be for the joint FXTF day.
plinss: Please go through list of F2F topics on wiki and prioritize.
Send list to Daniel and me.
<plinss> http://wiki.csswg.org/planning/hamburg-2012
plinss: Send your Top 5. Because we have too many topics.
<glazou> please add your flight/hotel data to
http://wiki.csswg.org/planning/hamburg-2012
Values and Units
----------------
<fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012
fantasai: There's a 2.1 issue blocking some fixes in Values & Units
Tab: [checking if spec is up to date...]
Tab: What was the 2.1 issue?
Tab: issue 19
http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-19
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Apr/0638.html
Tab: In CSS 2.1, the syntax of font-family is less strict than we probably
intended.
Tab: It allows 'inherit' to be used as a keyword within a font family name.
Tab: We would like to disallow inherit in all positions.
...
<dbaron> sounds good to me
<dbaron> (to disallow inherit keyword anywhere within a font-family value)
<JohnJansen> errata only, for now, correct?
RESOLVED: errata 2.1 to diasallow 'inherit' as a keyword in unquoted
font family names
Tab: Issue 20
http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-20
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Apr/0639.html
Tab: Tokenizer doesn't have a token for NUMBER with preceding + or -
Tab: This leads to errors and complications in CSS grammars
Tab: Making a token for it should have no other effect than disallowing
comments between + and the number.
Tab: Then we can in the future talk about number tokens without having to
talk about +/- every time as well.
Arron: There are no test for this yet, I think.
Arron: No, there aren't any tests for this.
<dbaron> the change tab is talking about making is including the + or -
sign in the NUMBER, PERCENTAGE, and DIMENSION tokens
glazou: We use it in calc(). Is there no effect there?
glazou: and in nth-child()
Tab: :nth-child grammar has errors that need to be fixed anyway,
so when we fix that we can make sure this is fixed
<fantasai> (see http://lists.w3.org/Archives/Public/www-style/2012Apr/0805.html for nth-child grammar section)
Tab: No effect for calc().
plinss: Is whitespace implicitly allowed there?
Tab: No, white space is explicitly called out in the grammar.
glazou: Comments everywhere is a pain. Nobody puts them everywhere anyway.
glazou: Someday we should fix that.
plinss: should maybe only allow comments where whitespace is allowed
plinss: I think it reasonable to include sign in the NUMBER token.
Tab: Yes, we thought it was included when we wrote Values.
plinss: Objections?
florianr: need test
anton: every errata item should have a testcase
RESOLVED: include sign in NUMBER, PERCENTAGE, DIMENSION tokens in 2.1
Tab: issue 10
http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-10
Tab: calc() could originally only return a <length> or <number>.
Tab: We'd like it to allow to return an integer as well.
<fantasai> The proposed text is
"If the type of the result, after resolving all subexpressions,
is an integral <number>, the calc()'s resolved type is <integer>. "
dbaron: I seem to rememebr that would make some things harder.
Tab: Our implementer says it is simple. Just tag it with the type.
Tab: Can only return an integer if there are only integers in the expression.
plinss: Careful with comparing floating points. After dividing 8/2,
might get 3.9999... which should mean 4.
plinss: floating point math might result in rounding errors that fail
that check
dbaron: Maybe different issue...
dbaron: I had thought we couldn't do <number>s. Could we do <number>s before?
Tab: yeah
dbaron: So what are the rules when something is not an integer anymore?
dbaron: is calc(2.3-1.3) an integer?
dbaron: I would say that it's not an integer.
dbaron: Trying to remember how spec determined number. Trying to remember
how I implemented it.
<fantasai> http://dev.w3.org/csswg/css3-values/#calc-type-checking
dbaron: There's a constant part and a value part.
dbaron: E.g. multiplication val * const or const * val
dbaron: Are there different values allowed left and right?
dbaron: That is the case for division. Anywhere else?
Tab: Type check on operations. Division bottom must be a number.
dbaron: So when exactly is it an int?
Tab: Either more rules about types. Or test for integer at the end,
within margin.
dbaron: z-index accepts 1 but not 1.0
dbaron: rule should be that all operands are <integer> and there is no
division.
<bradk> why can't the top and bottom of division both by lengths that
resolve to a integer?
florianr: Variables?
Tab: Resolved in the same way as missmatch in DIMENSION.
dbaron: Not sure what you say about division is correct.
Tab: If left divided by right is an int, then return is also int.
[discussion of when int divisions are needed]
Tab: I'm OK with restricting division.
Tab: Author can always simplify himself.
fantasai: don't want z-index: calc(attr(...)/2) , because that would
require computed-value-time validity check
[ attr() validity is currently parse-time ]
plinss: You don't want value to become invalid based on value of attr()
Tab: Exactly.
plinss: Summary: result is int if all operands are int and there is no division.
RESOLVED: attr() is <integer> if all operands are <integer> and there
is no division.
<fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-11
Tab: issue 11: attr() type at parse time.
plinss: You are not proposing to allow attr() right now?
Tab: If we define number type, than we can allow attr() now.
Tab: cycle() could be another.
<fantasai> We should specify explicitly that attr() is allowed,
rather than relying on <number> to imply it
Tab: I think attr() is quite stable now.
dbaron: Any impls?
Tab: one or two. IE and prince, I think.
<glazou> http://www.princexml.com/doc/6.0/properties/
Tab: Only in 'content', but at leats the functionality is there.
plinss: I'm concerned with the implications of attr() inside calc(),
not just attr() on it's own.
fantasai: We can defer this to level 4.
dbaron: I think we can allow it.
howcome: Me too. We'll manage somehow.
Tab: How about cycle()?
Tab: slightly more interesting issues.
Tab: One problem with attr() is that attr() can be 0 and so not
detectable that division by 0.
Tab: Do we want to restrict that in some way?
fantasai: There are no dimensions allowed in denominator.
fantasai: could disallow attr() in denominator too
Tab: We force the denominator to a number.
plinss: grammar allows dimensions in denominator
plinss: Need to change the grammar. Percentage could be zero too.
plinss: Grammar says percentage is allowed.
Tab: It's restricted in type-checking section
Tab: Percentages turn into the type they are resolved against.
plinss: What if percentage of zero?
dbaron: I don't like to resolve percentage type after.
Tab: It is still at computed value stage.
dbaron: I think percentages should be treated same as dimension.
Tab: OK
Tab: So new proposal:
Tab: Change grammar so that it allow dimension type (not just dimen
token) but still keep the NUMBER token in there so we can detect
early division-by-zero
dbaron: About cycle(), it doesn't necessarily have a single type.
Tab: Right, but it must be valid for all types it can turn into.
dbaron: Maybe you can resolve the type beforehand.
Tab: All of its types must be valid in the given location.
Tab: In general all values must be of the same type.
fantasai: Don't see the need for cycle() in calc().
dbaron: Usually it's for keywords.
fantasai: We should make a whitelist of what is allowed in calc().
Tab: Fine.
RESOLVED: allow attr() in calc() and disallow cycle()
plinss: So percentages must be a dimension type in calc()?
Tab: Yes
dbaron: About percentages: percentages never resolve to a number, I think.
[opacity... percentages? no]
antonp: line-height?
Tab: I believe they resolve to lengths
<fantasai> even numbers resolve against <length> there :)
Tab: issue 17 is pending some advise
Tab: Let's go to 18
Tab: kenny suggested to use a specific URL for invalid URLs.
Tab: Spec currently says a UA-defined invalid value.
* dbaron is looking for the URL Gecko uses
<fantasai> http://dev.w3.org/csswg/css3-values/#attr-notation
Tab: I don't now what that URL would be.
plinss: I like the idea of it being consistent.
<dbaron> Gecko currently uses url(invalid-url:) in a few contexts
<dbaron> though that was sort of an ugly hack
plinss: Will UA ever resolve it?
Tab: If it is defined to be invalid the UA can obviously skip it.
Tab: gecko uses just a scheme?
dbaron: We use it if someone askes for a computed style when our
URL parser failed to parse the URL.
Tab: Adam Barth's URL spec I think never fails to parse. But would
need to check.
dbaron: Maybe we can get advice from him.
Tab: I think I can ping him.
Tab: OK, lest' postpone that.
Tab: issue 21
<fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-21
Tab: If you have several attr() and cycle(), you have a combinatorial
number of types to check.
<TabAtkins> text-shadow: attr(offset px, inset) 0px 0px;
Tab: So we defined that attr() fallback must match type whenever it's
one of multiple components in a property value.
Proposal: force cycle() to only ever be the sole value of a property.
florianr: Can you explain cycle()?
Tab: dbaron had ane xample where you inherit multiple cycle()s
dbaron: I think what is inherited in variables is syntactic, so cannot
inherit cycle() that way.
Tab: Right... that would seem useful, though.
Tab: I was confused where the var would be used and where the cycle()
<dbaron> cycle(left top, right)
<dbaron> was peter's example
plinss: Then cycle can give diff. # of keywrods. Is that a pb?
Tab: can change the meaning, but not problematic.
dbaron: I think cycle is top-level only.
plinss: OK, so cycle is the whole value always.
Tab: proposal: cycle() is top-level only; when attr() is not at top
level then the type of the fallback must match
Tab: we can loosen up later if needed
RESOLVED: cycle() is top-level only; when attr() is not at top level
then the type of the fallback must match the type of attr()
<bradk> so, cycle could be used for background-position property, but
not for the background-position part of the background property
then, right?
Tab: issue 22
<fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-22
Tab: required ranges are rather random.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Apr/0530.html
fantasai: we reduced # of repetition form 30 to 20.
<fantasai> at Sylvain's request
plinss: any objecions?
RESOLVED: dropping multipliers from 30 to 20.
Tab: issue 25
<fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-25
Tab: currently requiring precision of 3 decimal digits (at least).
dbaron: Where does this apply?
Tab: numbers, dimen, and percentage.
dbaron: So this precludes different representations for for dimensions.
This seems very small if you use a small unit, e.g. 0.001 mm
Tab: Spec says this applis to number and percentage. We actually don't
have a requirements for dimensions.
florianr: [...]
dbaron: If the stuff on the left of the decimal point is big, we may
even lose before the decimal point.
dbaron: due to floating point representation
dbaron: And what does "support" mean?
Tab: round-trip
dbaron: Are there implementations of this right now?
[nobody knows]
florianr: We are likely to do fixed point, but haven't done so far.
Peter: I think it's good to define required precision for numbers,
but let's not make it incompatible with float.
Tab: It doesn't require fixed point. Can use floating point.
Tab: we can reduce this or remove it entirely.
plinss: A requirement on precision is good, but not as # of decimal digits.
florianr: Compatible with single-precision floats would probably be
compatible with all current implementations.
Tab: I think I can draw that up.
plinss: Sounds good.
plinss: Maybe we need at some point a required precision for lengths.
plinss: Minimum resolution.
glazou: We discussed that in the past a bit already.
Meeting closed.
<RRSAgent> http://www.w3.org/2012/05/02-css-minutes.html
Received on Sunday, 6 May 2012 21:18:14 UTC