CSS nesting parsing of complex rules

First I found a bug: https://developer.apple.com/forums//thread/745708?answerId=778577022#778577022
Then there were updates. They didn’t make anything better! Firefox stopped counting too. And Safari doesn’t even say “this CSS is invalid”, it makes it invalid (if you believe the inspector): “li: :after” comes from where?
Now I found another funny thing:
The page is a piece “holy grail”. No JS at all! The center area shows some pictures. The aside-area and the footer reside at the right and bottom border. They are “turned out” with CSS rotate. To view them and to view some bigger versions of the pictures, I did give them a tab-index. But what’s this? Tab-index is doing fine — when tabbing backwards (Shift-Tab). But it doesn’t do anything, if I try a normal, forward, Tab. After the normal Tab the page doesn’t notice Tabs any more. Neither forward, nor backwards. Even after a reload (Cmd-R) this doesn’t change. I have to close an reopen it for to see the backwards-tabbing.

Problem: the page, the CSS, is relatively complex. CSS does use CSS-nesting expensively. The sources for the mentioned effects, hovering, setting the focus and the counter-elements, are nested. It would be a hard piece of work to shrink it for an example to show here (and keep the bugs within). — Oh, one thing more: this does happen in Safari. Firefox does tabbing as expected.

I wisch, I didn’t tell you about the original bug. The answer is: more bugs!

Any suggestions?

[Karl Dubost]

Steve, 
as it is currently the bug is not really actionable. Having separate bugs for each problem help to fix things.

If it's about the counter issue, this is already tracked on Bug 268597.
If it's a new bug about CSS nested parsing probably a more focused title would help with a reduced test case. 


In https://jsfiddle.net/Rolf_b/axjvuo5y/

Two complex rules seem to trip the parsing (I say seem because I don't know if it's only the Web Inspector layout or the actual interpretation of the CSS). Simpler reduced test cases would be useful here. I removed the styles to focus on the nested rules. 

article {
    // some styles

  &::after {
    // some styles
  }

  ul {
    // some styles
  }

  li {
    // some styles
  }

  >ul>li {
    // some styles
  }

  header:not(:has(.more:checked))~& li.ext {
    // some styles
  }

  li>ul {
    // some styles

    li::after {
    // some styles
    }
  }

  &.working li::before {
    // some styles
  }
}



This one at least seems to create some issues

  header:not(:has(.more:checked)) ~ & li.ext {
    // some styles
  }

and there is another one, I'm not 100% sure

Created attachment 470633 [details]
small example without “li: :after” (instead of “li::after”)

Maybe the mentioned “doesn’t tab forwards” is a bit related: looks as this one comes with “li: :after” …
But: tests aren’t simple to build. The size of my buggy example is more than 70KiB pure HTML+CSS without images and other extras.

[Radar WebKit Bug Importer]

<rdar://problem/125666631>

Created attachment 470744 [details]
Another view  into the inspector, not liking counter and counters

Still can’t boil down the problem. But I found another symptom. Have a look at inspectors “opinion”!
Looks like the problem isn’t `::after`. But `counters` are disliked.


The related piece of CSS:
```
… {
	counter-reset: nameIndex;
	li::after {
		display: inline-block;
		counter-increment: nameIndex;
		content: "XXXXX!";
		content: "(" counters(nameIndex) ")";
		content: "(" counters(total) ":" counters(nameIndex) ")";
		…
	}
}
```