- From: Bert Bos <bert@w3.org>
- Date: Wed, 2 May 2012 20:39:13 +0200
- To: W3C style mailing list <www-style@w3.org>
Summary:
- RESOLVED: Errata CSS 2.1 to disallow 'inherit' after comma in
'font-family'
- RESOLVED: Include the sign in the NUMBER token in CSS 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.
- RESOLVED: Drop minimum supported multipliers for repeated components
from 30 to 20.
====== Full minutes below ======
See also: [2]IRC log
[2] http://www.w3.org/2012/05/02-css-irc
Attendees
Present
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
Regrets
Chair
Peter
Scribe
Bert
Contents
* [3]Topics
1. [4]Extra agenda items
2. [5]Values & units
* [6]Summary of Action Items
__________________________________________________________
[7]Agenda
[7] http://lists.w3.org/Archives/Public/www-
style/2012May/0024.html
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> [8]http://wiki.csswg.org/planning/hamburg-2012
[8] http://wiki.csswg.org/planning/hamburg-2012
Peter: Top 5. Because we have too many topics.
Values & units
<Elika> [9]http://dev.w3.org/csswg/css3-values/issues-lc-2012
[9] 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
[10]http://wiki.csswg.org/planning/hamburg-2012
[10] http://wiki.csswg.org/planning/hamburg-2012
<Elika>
[11]http://lists.w3.org/Archives/Public/www-style/2012Apr/0639.
html
[11] 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>
[12]http://lists.w3.org/Archives/Public/www-style/2012Apr/0638.
htmlhttp://lists.w3.org/Archives/Public/www-style/2012Apr/0638.
html
[12] 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
[13]http://lists.w3.org/Archives/Public/www-style/2012Apr/0805.
html for nth-child grammar section)
[13] http://lists.w3.org/Archives/Public/www-
style/2012Apr/0805.html
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>
[14]http://dev.w3.org/csswg/css3-values/#calc-type-checking
[14] 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>
[15]http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-11
[15] 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> [16]http://www.princexml.com/doc/6.0/properties/
[16] 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> [17]http://dev.w3.org/csswg/css3-values/#attr-notation
[17] 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>
[18]http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-21
[18] http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-21
<Elika>
[19]http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-22
[19] 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>
[20]http://lists.w3.org/Archives/Public/www-style/2012Apr/0530.
html
[20] 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>
[21]http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-25
[21] 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 [22]scribe.perl version
1.136 ([23]CVS log)
$Date: 2012/05/02 18:37:38 $
[22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[23] http://dev.w3.org/cvsweb/2002/scribe/
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Wednesday, 2 May 2012 18:39:47 UTC