Get ::before value

Andrew Poulos

unread,

Jul 16, 2021, 3:53:08 AM7/16/21

to

Some content gets generated by CSS and I need to get the "live" value.

The element in question has this CSS

::before {
counter-increment: num;
content: counter(num) ". ";
}

I tried
getComputedStyle(elem, '::before').getPropertyValue('content');
and it returns
counter(num) ". "
and not the "live" value I was expecting (hoping).

How can I get the actual text that is displayed?

Andrew Poulos

Julio Di Egidio

unread,

Jul 16, 2021, 10:43:09 AM7/16/21

to

As far as I can tell, there is no way to access that value. Indeed, you cannot even select the generated text (I mean, not even with your mouse).

See also here: <https://stackoverflow.com/questions/532073/how-can-i-read-the-applied-css-counter-value>

The obvious work-around is to generate the numbering from JS, i.e. just do not use that CSS: or do, but then be prepared to compute the same on the scripting side some other way, and make also sure that who writes the CSS talks to who writes the JS and vice versa...

Julio

Andrew Poulos

unread,

Jul 16, 2021, 7:15:41 PM7/16/21

to

On 17/07/2021 12:43 am, Julio Di Egidio wrote:
> On Friday, 16 July 2021 at 09:53:08 UTC+2, Andrew Poulos wrote:
>> Some content gets generated by CSS and I need to get the "live" value.
>>
>> The element in question has this CSS
>>
>> ::before {
>> counter-increment: num;
>> content: counter(num) ". ";
>> }
>>
>> I tried
>> getComputedStyle(elem, '::before').getPropertyValue('content');
>> and it returns
>> counter(num) ". "
>> and not the "live" value I was expecting (hoping).
>>
>> How can I get the actual text that is displayed?
>
> As far as I can tell, there is no way to access that value. Indeed, you cannot even select the generated text (I mean, not even with your mouse).
>
> See also here: <https://stackoverflow.com/questions/532073/how-can-i-read-the-applied-css-counter-value>

Thanks for link.

> The obvious work-around is to generate the numbering from JS, i.e. just do not use that CSS: or do, but then be prepared to compute the same on the scripting side some other way, and make also sure that who writes the CSS talks to who writes the JS and vice versa...

Funny that the browser knows what text to display but I will need to
script some workaround to get it.

Andrew Poulos

Andrew Poulos

unread,

Jul 16, 2021, 9:36:36 PM7/16/21

to

I guess it's something similar with the "numbers" for ordered list items
in that you can't query what a browser is actually displaying.

Andrew Poulos

Julio Di Egidio

unread,

Jul 17, 2021, 8:30:03 AM7/17/21

to

Right. I suppose it has to do with how the browser is structured, anyway the docs (MDN) are quite explicit (though it's a bit all over the place), that it's stuff that doesn't make it to the DOM nor to the "accessibility tree", e.g. see here: <https://developer.mozilla.org/en-US/docs/Web/CSS/content#accessibility_concerns> In particular, I take that to mean that not even a screen reader would see that part.

I think the bottom line is to use these features only as lightweight "graphic effects", when e.g. the numbering is not significant, just decorative. Similarly for CSS animations and other effects: if e.g. sequencing or synchronisation is a requirement, CSS is just not the way to go. Indeed, the fact that some of this stuff doesn't even make it to the DOM nor to accessibility tree to me is signal that it shouldn't be used at all, unless it really does not matter.

Anyway, my 2c.

Julio

Michael Haufe (TNO)

unread,

Jul 18, 2021, 11:27:26 AM7/18/21

to

This is not possible currently. There are hacks that might work but with the complexity involved it's probably better to do this with JavaScript.

There is a new CSS standard in the works `target-counter()` to make this possible in the future:

<https://github.com/w3c/csswg-drafts/issues/5879>

Julio Di Egidio

unread,

Jul 20, 2021, 7:06:58 AM7/20/21

to

On Sunday, 18 July 2021 at 17:27:26 UTC+2, Michael Haufe (TNO) wrote:
> On Friday, July 16, 2021 at 2:53:08 AM UTC-5, Andrew Poulos wrote:
> > Some content gets generated by CSS and I need to get the "live" value.
> >
> > The element in question has this CSS
> >
> > ::before {
> > counter-increment: num;
> > content: counter(num) ". ";
> > }
> >
> > I tried
> > getComputedStyle(elem, '::before').getPropertyValue('content');
> > and it returns
> > counter(num) ". "
> > and not the "live" value I was expecting (hoping).
> >
> > How can I get the actual text that is displayed?
>
> This is not possible currently. There are hacks that might work
> but with the complexity involved it's probably better to do this with JavaScript.

There are no hacks, there is just no access from JS to the runtime value of those properties.

> There is a new CSS standard in the works `target-counter()` to make this possible in the future:
>
> <https://github.com/w3c/csswg-drafts/issues/5879>

"The target-counter() function does exactly this in CSS, not JS", i.e. same as above.

Julio

Michael Haufe (TNO)

unread,

Jul 20, 2021, 11:11:31 AM7/20/21

to

On Tuesday, July 20, 2021 at 6:06:58 AM UTC-5, ju...@diegidio.name wrote:
> On Sunday, 18 July 2021 at 17:27:26 UTC+2, Michael Haufe (TNO) wrote:

> > This is not possible currently. There are hacks that might work
> > but with the complexity involved it's probably better to do this with JavaScript.

> There are no hacks, there is just no access from JS to the runtime value of those properties.

You misinterpret what I was referring to with 'this'. I am fully aware that the runtime value is not available.

> > There is a new CSS standard in the works `target-counter()` to make this possible in the future:
> >
> > <https://github.com/w3c/csswg-drafts/issues/5879>
> "The target-counter() function does exactly this in CSS, not JS", i.e. same as above.

The difference being that this value could be accessible from the CSSOM, therefore not the same as above. As mentioned in that same thread there is a browser flag available that one could use to confirm: `--enable-blink-features=CSSAtRuleCounterStyle`, but I don't care enough to try.

Julio Di Egidio

unread,

Jul 21, 2021, 10:14:07 AM7/21/21

to

On Saturday, 17 July 2021 at 14:30:03 UTC+2, Julio Di Egidio wrote:
> On Saturday, 17 July 2021 at 03:36:36 UTC+2, Andrew Poulos wrote:

<snip>

> > I guess it's something similar with the "numbers" for ordered list items
> > in that you can't query what a browser is actually displaying.
>
> Right. I suppose it has to do with how the browser is structured,

<https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work>

Julio

Julio Di Egidio

unread,

Jul 21, 2021, 10:29:15 AM7/21/21

to

On Tuesday, 20 July 2021 at 17:11:31 UTC+2, Michael Haufe (TNO) wrote:
> On Tuesday, July 20, 2021 at 6:06:58 AM UTC-5, ju...@diegidio.name wrote:
> > On Sunday, 18 July 2021 at 17:27:26 UTC+2, Michael Haufe (TNO) wrote:

<snip>

> > > There is a new CSS standard in the works `target-counter()` to make this possible in the future:
> > >
> > > <https://github.com/w3c/csswg-drafts/issues/5879>
> >
> > "The target-counter() function does exactly this in CSS, not JS", i.e. same as above.
>
> The difference being that this value could be accessible from the CSSOM,

You just guessing? I see no trace that such thing is in the workings. And, even if eventually it will (if you start asking for it...), it wouldn't just be for one isolated property: indeed, see my link on how a browser works, the point being that a modification like scripted access to the rendered value of the above properties means changing the browser' pipeline. But then of course that simply boils down to collapsing some layers, and we are back to square one: that those CSS features should rather and only be used for... etc. etc.

Anyway, my 2c... (EOD.)

Julio