See also: IRC log
Peter: Any extra agenda?
Elika: Hackaton?
Alan: Still in planning stages.
Vincent: What did you want to dicuss exactly?
... Let me check, but should not be an issue. Could be an FXTF event.
Peter: Could be for the joint FXTF day.
... Please, go through the list of topics on the wiki and prioritize. Send
list to Daniel and me.
<Peter> http://wiki.csswg.org/planning/hamburg-2012
Peter: Top 5. Because we have too many topics.
<Elika> http://dev.w3.org/csswg/css3-values/issues-lc-2012
Elika: There's a 2.1 issue.
<Daniel> Håkon: will you attend hamburg meeting ?
Tab: [checking if spec is up to date...]
... What was the 2.1 issue?
<David Baron> Issue 19?
<Håkon> yes, I will be in Hamburg
Tab: issue 19
<Daniel> Håkon: please add your flight/hotel data to http://wiki.csswg.org/planning/hamburg-2012
<Elika> http://lists.w3.org/Archives/Public/www-style/2012Apr/0639.html
Tab: 2.1 in font-family is less strict than we
probably intended.
... It potentially allows 'inherit' after comma in font-family.
Tab: We would like a modification to disallow 'inherit'.
<David Baron> sounds good to me
<John> errata only, for now, correct?
<David Baron> (to disallow inherit anywhere within a font-family value)
Tab: (Same thread as issue 20)
<David Baron> inherit keyword, that is
RESOLUTION: errata 2.1 to disallow 'inherit' after comma in 'font-family'
Tab: Issue 20
... Grammar doesn't have a token for number with preceding + or -
... Making a token for it should have no other effect than disallowing
comments between +/- and the number.
... Then we can in the future talk about number tokens without having to talk
about +/- every time as well.
... There are no test for this yet, I think.
Daniel: We use it in calc(). Is there no effect
there?
... and in nth-child()?
<Elika> Tab: No effect on calc() -- makes it more accurate anyway
Tab: We have to fix the grammar for nth-child anyway. No effect for calc().
<David Baron> the change tab is talking about making is including the + or - sign in the number, percentage, and dimension tokens
Peter: Whitespace?
Tab: Yes, explicitly called out.
Daniel: Comments everywhere is a pain.
... Someday we should fix that.
<Elika> (see http://lists.w3.org/Archives/Public/www-style/2012Apr/0805.html for nth-child grammar section)
Peter: I think it reasonable to include sign in the number token. (We should maybe only allow comments where whitespace is allowed.)
Tab: Yes, we thought it was included when we wrote values.
Peter: Objections?
Florian: Need test.
Anton: Every errata item should have a testcase.
RESOLUTION: include sign in NUMBER token in 2.1.
TAB: issue 10
... calc() could originally only return a length.
... We'd like to allow returning an integer as well.
<Elika> 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>. "
David Baron: I seem to remember that that would make some things harder.
Tab: Our implementer says it is simple. Just tag
it with the type.
... Can only return an integer if there are only integers in the
expression.
Peter: Careful with comparing floating points. After division 3.9999... is maybe 4.
<Elika> Peter: floating point math might result in rounding errors that fail that check
David Baron: Maybe I'm thinking of a different
issue.
... Can we already do numbers [i.e., not integer]?
<Elika> David Baron: I had thought we couldn't do <number>s. Could we do <number>s before?
Tab: Yes.
David Baron: So what are the rules when something is not an integer anymore? I would say 2.3 - 1.3 is not an int.
<Elika> http://dev.w3.org/csswg/css3-values/#calc-type-checking
David Baron: Trying to remember how the spec
determined a number. Trying to remember how I implemented it.
... Constant part and value part. E.g. multiplication can be value * constant
or constant * value
... Are there different values allowed left and right?
... That is the case for division. Anywhere else?
Tab: Type check on operations. Division bottom must be a number.
David Baron: So when exactly is it an integer?
Tab: Either we need more rules about types, or we test for integer at the end, within a certain margin.
David Baron: z-index accepts 1 but not 1.0. The rule to [to determine if the result is an integer] should be that all operands are integers and there is no division.
<bradk> why can't the top and bottom of division both be lengths that resolve to a integer?
Florian: Variables?
Tab: Variables are resolved in the same way.
David Baron: Not sure what you say about division is correct.
Tab: If left divided by right is an integer, then the result is also integer.
[discussion of when integer divisions are needed]
Tab: I'm OK with restricting division.
... Author can always simplify it himself.
Peter: You don't want a value to become invalid based on the value of attr().
Tab: Exactly.
Elika: I don't want 'z-index: calc(attr(...)/2)' , because that would require a computed-value-time validity check.
Peter: Summary: result is int if all operands are int and there is no division.
RESOLUTION: Result of attr() is integer if all operands are integer and there is no division.
<Elika> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-11
Tab: Issue 11: attr() type at parse time.
Peter: You are not proposing to allow attr() right now?
Tab: If we define a number type, than we can allow attr() now.
<Elika> We should specify explicitly that attr() is allowed, rather than relying on <number> to imply it
Tab: cycle() could be another.
... I think attr() is quite stable now.
David Baron: Any implementations?
Tab: One or two. IE and Prince, I think.
... Only in 'content', but at least the functionality is there.
Peter: I'm concerned with the implications of attr() inside calc().
<Daniel> http://www.princexml.com/doc/6.0/properties/
Elika: We can defer to level 4.
David Baron: I think we can allow it.
Håkon: Me too. We'll manage somehow.
Tab: How about cycle()?
... slightly more interesting issues.
... One problem with attr() is that attr() can be 0 and so it's not detectable
if there is a division by 0.
... Do we want to restrict that in some way?
Elika: There are no dimensions allowed in denominator. We could disallow attr() in denominator, too.
Tab: We force the denomninator to a number in the type-checking section.
Peter: The grammar allows dimensions in denominator
Peter: Need to change the grammar. Percentage could be zero, too. Grammar says percentage is allowed.
Tab: Percentages turn into the type they are resolved against.
Peter: What if it's a percentage of zero?
David Baron: I don't like to resolve percentage type after.
Tab: It is still at computed value stage.
David Baron: I think percentages should be treated same as dimension.
Tab: OK
... So new proposal:
... Change grammar so that it allows dimen type (not just dimen token) but
still keep the NUMBER token in there so we can detect early
division-by-zero.
David Baron: About cycle(), it doesn't necessarily have a single type.
Tab: Right, but it must be valid for all types it can turn into.
David Baron: Maybe you can resolve the type beforehand.
Tab: All of its types must be valid in the given
location.
... In general all values must be of the same type.
Elika: Don't see the need for cycle() in calc().
David Baron: Usually it's for keywords.
Elika: We should make a whitelist of what is allowed.
Tab: Fine.
RESOLUTION: Allow attr() in calc() and disallow cycle().
Peter: attr() must be a dimension.
Tab: Yes.
David Baron: About percentages: percentages never resolve to a number, I think.
[opacity... percentages? no]
Anton: line-height?
Tab: I believe percentages resolve to lengths there.
<Elika> even numbers resolve against <length> there :)
Tab: issue 17 is pending some advise
... Let's do 18
... Kenny suggested to use a specific URL for invalid URLs.
... Specification currently says it's a UA-defined invalid value.
<Elika> http://dev.w3.org/csswg/css3-values/#attr-notation
Tab: I don't know what that URL would be.
Peter: I like the idea of it being consistent.
<David Baron> Gecko currently uses url(invalid-url:) in a few contexts
Peter: Will the UA ever resolve it?
Tab: If it is defined to be invalid the UA can obviously skip it.
<David Baron> though that was sort of an ugly hack
Tab: Gecko uses just a scheme?
David Baron: We use it if someone asks 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.
David Baron: Maybe we can get advice from him.
Tab: I think I can ping him.
... OK, let's postpone that.
... issue 21.
Tab: If you have several attr() and cycle(), you have a combinatorial number of types to check.
<Elika> text-shadow: attr(offset px, inset) 0px 0px;
Tab: attr() fallback must match type.
... Proposal: force cycle() to only ever be the sole value of a property.
<Elika> Tab: force cycle() to be sole value of property, and for attr() fallback must match type if it's not the sole value of a property
Florian: Can you explain cycle()?
Tab: David Baron had an example with variables where you inherit multiple cycle()s.
David Baron: I think what is inherited in variables is syntactic, so you cannot inherit cycle() that way.
Tab: Right... that would seem useful, though.
... I was confused where the var would be used and where the cycle()
<David Baron> cycle(left top, right)
<David Baron> was peter's example
Peter: Example: 'cycle(left top, right)'. Then cycle can give different numbers of keywords. Is that a problem?
Tab: Can change the meaning, but not problematic.
David Baron: I think cycle is top-level only.
Peter: OK, so cycle is the whole value always.
<David Baron> Tab: proposal: cycle() is top-level only; when attr() is not at top level then the type of the fallback must match
Peter: We can loosen up later.
RESOLVED: cycle() is top-level only; when attr() is not at top level then the type of the fallback must match
<Elika> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-21
<Elika> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-22
Tab: issue 22.
... Required ranges are rather random.
<bradk> so, cycle could be used for background-position property, but not for the background-position part of the background property then, right?
<Elika> http://lists.w3.org/Archives/Public/www-style/2012Apr/0530.html
Elika: We reduced # of repetitions form 30 to 20, at Sylvain's request.
Peter: Any objecions?
<Elika> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-25
RESOLUTION: Drop minimum supported multipliers for repeated components from 30 to 20.
Tab: issue 25.
... Currently 3 decimal digits (at least).
David Baron: Where does this apply?
Tab: Numbers, dimen and percentage.
David Baron: So this precludes different representations for dimens. This seems very small: '0.001 mm'
Tab: Specification says this applies to number and percentage. We actually don't have a requirement for dimen.
Florian: [...]
David Baron: If the stuff on the left of the
decimal point is big, we may even lose precision before the decimal point.
... It's floating point.
... And what does "support" mean?
Tab: It means round-trip.
David Baron: Are there implementations of this right now?
[nobody knows]
Florian: We are likely to do fixed point, but haven't done so far.
Tab: It doesn't require fixed point, can use
floating point.
... We can reduce this or remove it entirely.
Peter: A requirement on precision is good, but not as a number of decimal digits. Let's not make it incompatible with float.
Florian: Compatible with single precision floats would probably be compatible with all current implementations.
Tab: I think I can draw that up.
Peter: Sounds good.
... Maybe we need at some point a required precision for lengths: minimum
resolution.
Daniel: We discussed that in the past a bit already.
Peter: See you in Hamburg!