W3C home > Mailing lists > Public > www-style@w3.org > May 2012

[CSSWG] Minutes and Resolutions Telcon 2012-05-02 [CORRECTED]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 06 May 2012 14:17:39 -0700
Message-ID: <4FA6EA73.6000402@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:53 GMT