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

[CSSWG] Minutes and resolutions telcon 2012-05-02

From: Bert Bos <bert@w3.org>
Date: Wed, 2 May 2012 20:39:13 +0200
To: W3C style mailing list <www-style@w3.org>
Message-Id: <201205022039.14287.bert@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 GMT

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