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

Re: [css3-lists] Where can the counter() function be used?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 9 Jul 2012 08:56:42 -0700
Message-ID: <CAAWBYDDVdEAHDxkWNFK=dJu_MmH9NDYFv7sVdSQADDX2Ox=YKg@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
On Mon, Jul 9, 2012 at 8:39 AM, L. David Baron <dbaron@dbaron.org> wrote:
> On Monday 2012-07-09 07:32 -0700, Tab Atkins Jr. wrote:
>> On Mon, Jul 9, 2012 at 7:24 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> > On 7/9/12 3:16 AM, Tab Atkins Jr. wrote:
>> >> One way this could be solved would be to allow math on counter values
>> >> (which are just integers), such as allowing the counter() function
>> >> inside of calc().  Then you could write your use-case as:
>> >>
>> >> animation-delay: calc(counter(delay-timer) * 1s);
>> >
>> > I must be missing something.
>> >
>> > Counter values depend on whether boxes are present or not, no?
>> >
>> > It seems pretty odd to me to require that values of some properties depend
>> > on whether some completely unrelated boxes far away in the DOM are present.
>> > It might also be somewhat difficult to implement correctly in the face of
>> > dynamic changes.
>> >
>> > -Boris
>> >
>> > P.S.  Note that "boxes are present" does not actually map directly to
>> > computed display values, by the way.  It probably does map to used display
>> > values...
>> You must be missing something, since what you just described is how
>> counters always work.  It's just that in the past they've been limited
>> to being used in 'content' only.
> Counters aren't computed to anything in the computed value of
> 'content'.
> Introducing a feature like this is equally broken as the entire
> reason we had to introduce the used value concept into CSS:
> preventing computed values of properties from depending on layout
> data.
> You claim it *could* be computed from style, but it can't be
> computed from *local* style -- i.e., the element and its parent.
> That's nearly as bad as depending on layout.  There are operations
> on layout that are non-local, but finding computed values isn't.

We should probably make it clearer what kind of operations are allowed
when deciding something is allowed to be a computed value.  If the
restriction we want is that it's resolveable without layout data or
non-local style data, that's fine, but these restrictions are unclear
to me a priori.

So, does this mean that you're opposed to counters being referenced
from anywhere besides 'content'?  That's a very important restriction
if so.

Counters seem to be basically equivalent to variables here, except
with slightly different scope rules - counters can be affected by
previous siblings as well as parents, while variables are only
parents.  Is this difference sufficient to punt counters to the "don't
use" category while variables are okay?

If so, would a future variant of variables that had a scope of
following siblings only (didn't inherit) be okay?

Received on Monday, 9 July 2012 15:57:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:18 UTC