Re: [css3-value] calc and child selectors (was: Proposal for Touch-Based Animation Scrubbing)

|  Oh yes please. Much more flexible than counting among the parent’s
|  children, and counters are already there.

This was the point of the proposal :-)

|  The downside is that (I think) counters get their value after box
|  generation, so this would make the computed value of calc() more
|  complicated. (Computed values are determined before box generation.)

The computed value of a calculation may already be complex, even if this 
would make it even more. I guess that if browsers want to support 
"nth-child" they would get exactly the same issue anyway.

|  Syntax nitpick: I’d rather reuse the existing counter() function and
|  allow it in calc(). This is much easier to parse that trying to group
|  whitespace-separated keywords.

In get(...), all sequence of identifiers form a single reference path. You 
can think about it as "counter.index" in JavaScript. The idea is that you 
can build more complex things like "parent counter index" (get the value of 
the counter on the parent element) or "host counter index" (to get the value 
of the 'index' counter on the host element of a Shadow DOM Tree). This is 
really useful when you deal with style references (ie: #toolbar { display: 
get(host x-toolbar-display); } in a Web Component which has a toolbar you 
want to control from CSS in the main document) or attributes (get(parent 
attr href)).

You could do the same using parentheses "get(parent(attr(href)) || default)" 
but it would make the code bloated compared to "get(parent attr href || 

|  The difference is that in numeric context (like calc()) it would
|  "return" an <integer>, while in string context (every usage so far) it
|  returns a <string> based on a counter type.

This is something we should most probably avoid. I would prefer the option 
of using another function like "get-counter(index)" than overloading the 
output argument type of a function. 

Received on Friday, 30 November 2012 20:20:35 UTC