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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 23 Apr 2012 12:39:24 -0700
Message-ID: <CAAWBYDB_7muYBFsTAZjX_M5vD17DXLW4fQjHAu2yxOO+WNu9BQ@mail.gmail.com>
To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
Cc: WWW Style <www-style@w3.org>
Heya Kenny!

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.

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

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.

Issue 5: attr() needs to either clarify what element it draws from
when not in a rule (and where exactly it's allowed), or disallow that
case
Closed as Accepted - The opening sentence of attr() now reads: "The
attr() function is allowed as a component value in properties applied
to an element or pseudo-element."  It's not allowed anywhere else.

Issue 6: @import should probably disallow attr()
Closed as Accepted - This follows as a consequence of the previous

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.

Issue 8: attr() should disallow its fallback value from *containing*
another attr(), not just *being* attr().
Closed as Accepted - The attr() section now says that it's only valid
if "the <fallback> does not contain another attr() expression".

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.

Issue 10: Can calc() return an <integer>? If so, clarify when it does so.
Closed as Accepted:  We editors have decided that calc() should be
able to return an <integer>, but believe the WG should resolve on it
first.  We haven't made the edits yet.

Please confirm that our resolution of your issues is satisfactory.
Particularly, we'd appreciate confirmation that you're okay with our
rejection of several issues.

~TJ
Received on Monday, 23 April 2012 19:40:13 GMT

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