Is this expected behaviour?

Using XPP 9.4 in CSS mode if I have:

para::before { counter-reset: tester 5; content: counter(tester); }

then I get the 5 output before the start of the text, however if I have:

para::after { counter-reset: tester 5; content: counter(tester); }

then the output is zero.

I don't understand why I can't load a value into a counter in the "after" selector - am I missing something?

  • Chris,

    First of all: I could easily duplicate your problem and in the doc there is nothing that says that the counter-reset property can not be used in a ::before or ::after pseudo element.

    But there is a lot more going on
    I think the whole counter-reset thing seem to be broken.
    I have created the following test case:

    doc {
    	counter-reset: pCounter 5;
    }
    
    p {
    	display: block;
    	counter-increment: pCounter;
    }
    
    p::before {
    	content: counter(pCounter) ". ";
    	
    }

    and that works fine, so you get 6 for the first para and 7 for the next one.

    But if you change things to:

    doc {
    	counter-reset: pCounter 5;
    	counter-reset: pCounter2 6;
    }
    

    Things stop working and the first para is numbered 1, etc
    The same thing happens if you add a second counter-reset statement in your example

    Time to open up a ticket?

  • OK will do - was just checking I had not missed something obvious!

  • I just entered my ticket as I want to be sure that the problem with multiple counter-reset properties was deald with as well

  • I referred them to this thread anyway - so hopefully it will all get fixed!

  • I do not think I will live the day that 'all' get fixed in XPPGrinning

  • I don't have an answer (yet) for the problem being reported by Chris.

    But, Bart, I think that your reported "problem" is merely a CSS syntax problem with how you've specified your rule with the two counter-reset's in it (for the doc selector).

    AFAIK having the same property specified multiple times within the same CSS rule is not "additive" as you seem to be expecting. So, in your example the second counter-reset (for pCounter2) causes the first counter-reset (for pCounter) to effectively be ignored.

    If I change the order of those two counter-reset lines, then the pCounter reset does happen (because it's specified last).

    To make both counter-reset's happen, this is what I used to make it work:

    doc {
    counter-reset: pCounter 5 pCounter2 6;
    }

    Jonathan Dagresta
    SDL XPP Engineering

    Jonathan Dagresta
    RWS Group/
    XPP Development

  • Chris (and Bart), as far as I can tell XPP composition is not processing any counter-reset or counter-increment properties at all that occur within an ::after pseudo element.

    Entering your ticket with Customer Support was the right action.

    It does seem a bit "unusual" to want to use counter-reset and/or counter-increment in an ::after pseudo element.

    I imagine it's an oversight (i.e. there was no known "use case" at the time of implementation), but I'm not all that familiar with CSS and specifically in the context of XPP composition, so we'll need to make sure that there's not any reason that it would cause a "problem" to add it (i.e. "fix the apparent bug").

    Jonathan Dagresta
    SDL XPP Engineering

    Jonathan Dagresta
    RWS Group/
    XPP Development

  • Yes Jonathan you are right.
    I did not think this through...

    Maybe I need to open up a documentation issue on this as the doc does not specify that you can address several counters at the same time....?

    Currently the doc for counter-reset is as follows:
    counter-reset The counter-reset property creates or resets one or more
    counters. The counter-reset property is usually used together
    with the counter-increment property and the content property.
    Initial Value none
    Inherited? no
    Syntax identifier integer | none | inherit

    I think this last thing should become

    Syntax (identifier integer )+ | none | inherit
    with a little extra info and maybe a small example

  • Well I have been thinking a bit more on this problem and maybe because in this case we are working 'after' the element, the system is addressing a different level of the counter.
    After all for mulit-level numbered list we use the same named counter, but the system keeps track of the level in which we use this 'named counter' and outputs (or resets) the correct value for a particular level of the named counter. All of this without us as users having to care about which level we are in.

    It is unclear to me when the system decides to use multi level named counters or just a single level counter.
    (could be tricky if you want to use the same unique counter at different levels in your document...?) 

    It would be nice if engineering can give us some more info on this