CSS WG telcon

02 May 2012

See also: IRC log


Divya Manian, Alan Alan, Daniel Glazman, Peter Linss, Arron Eicholz, Elika Etemad, Brad Kemper, Anton Prowse, David Baron, Ryan Betts, John Jansen, Simon Fraser, Bert Bos, Koji Ishii, Tab Atkins, Steve Zilles, Arno Gourdol, Katie Ellison, David Storey, Håkon Lie, Florian Rivoal, Rossen Atanassov



Extra agenda items

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.

Values & units

<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.

<Elika> http://lists.w3.org/Archives/Public/www-style/2012Apr/0638.htmlhttp://lists.w3.org/Archives/Public/www-style/2012Apr/0638.html

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!

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/05/02 18:37:38 $