W3C home > Mailing lists > Public > www-style@w3.org > August 2016

Re: [css-values] CSS counters inside CALC function

From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Date: Tue, 30 Aug 2016 16:25:31 -0600
Message-ID: <CAFDDJ7zMtwsf7OPbcQU63kPHc6fP8J_e+YY+osdR24LeuN1AdQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Hr Gwea <hrg.wea@gmail.com>, www-style list <www-style@w3.org>
Tab: When essentially the same feature request came up in March (
https://lists.w3.org/Archives/Public/www-style/2016Mar/0211.html), you
agreed to note it as an outstanding issue for now.

The issue is in the Editor's Draft here:

Has there been specific feedback from other implementers since then?  I'm
certainly one person who'd love to see this as a language feature.

When discussing performance impacts, remember that the alternative (widely
used in decorative layouts on CodePen; I don't know how widely used in "the
wild") is to use a CSS pre-processor to generate a series of nth-of-type
selectors, which bloat style sheets and have their own performance concerns.


On 30 August 2016 at 15:55, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Fri, Aug 26, 2016 at 4:29 AM, Hr Gwea <hrg.wea@gmail.com> wrote:
> > Have you, guys, thought of the possibility of using CSS counters inside
> the
> > CALC function?
> > That would be super useful for so many cases.
> The current counter() function outputs a <string>, so it can't be used
> directly in calc(). We could possibly define a counter-value()
> function that gave an integer, of course.
> However, all of the uses I've ever seen for this have been pretty
> trivial "toy" cases.  The closest thing to reasonable I've ever seen
> has been clock use-cases, like your example seems to be, and those are
> rare enough that they're not very strong justification for this
> feature.  Counters are surprisingly expensive in browsers, and so
> they're loathe to add new features that would promote heavier usage of
> them without strong justification.
> ~TJ
Received on Tuesday, 30 August 2016 22:26:01 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:00 UTC