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

Re: [css3-values] types and where attr() and calc() can be used

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Tue, 24 Apr 2012 04:13:18 +0800
Message-ID: <4F95B7DE.9090409@csail.mit.edu>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: WWW Style <www-style@w3.org>
(12/04/24 3:39), Tab Atkins Jr. wrote:
> This email is an acknowledgement that we've addressed all the issues
> present in your mail.  The issues I've extracted and their resolutions
> are below.

Thank you too (for addressing all of my issues)!

> Issue 3: Using the 'integer' type in attr() seems to be invalid in
> places that want <number>
> Closed as Invalid - the definition of the <number> type specifically
> says that a number is "either an <integer>, or ...".

Well, the spec says "either an integer, or ..." You seem to have no
problem about treating "integer" and "<integer>" as synonyms, but I do
have a problem. Based on my impression, this sentence is talking about
the syntax of a <number>, while whether <integer> is a subtype of
<number> has to do with the semantics.

So, no, this is not very satisfactory, but given that this amounts to an
editorial issue, this is my last try. The following are my editorial
proposals:

A. Below

  # the attr() expression's type is valid where the attr() expression
  # is placed,

add that

  | Note: a <type> of "integer" is valid where <number> is expected.

B. At the end of the description of "integer" as a <type>, add

  | This can be used where <number> is expected.

> Issue 4: Eliminate the 'integer' type entirely
> Closed as Rejected - several CSS properties use the <integer> type,
> and it's not expected that they'll change, or what the value in them
> doing so would be.

This is fine.

> Issue 7: Should calc() be allowed in @keyframes selectors?
> Closed as OutOfScope - This is something for the Animations spec to
> define.  I will raise an issue on that spec shortly.

Fine.

> Issue 9: attr() shouldn't disallow its fallback value from containing
> more attr().
> Closed as Rejected - There doesn't seem to be a strong use-case for
> this, and it adds complexity to testing and implementation to allow
> it.  If we decide it's necessary later, it's easy to relax the
> restriction in a future level.

Fine.


Cheers,
Kenny
Received on Monday, 23 April 2012 20:13:48 GMT

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