Investigate the tbela99/css parser

[oliverklee]

This parser looks quite promising: https://github.com/tbela99/css It requires PHP >= 8.0, though.

[JakeQZ]

Is it any or much better than PHP-CSS-Parser, and is it worth the effort making switching possible?

I suppose in some ways checking it out could help us streamline our interfaces, so that in theory the user/implementor could select which CSS parser they want, if it really matters, and there could be an interfacing class which is a wrapping on the box containing the unknown CSS parser.

[oliverklee]

Mostly, its code seems to be more modern, and it seems to have a better test coverage. (On the down side, it seems to be as much of a one-person project as our current CSS parser).

[tbela99]

Thanks for your interest in that project. I would like to answer some of your questions

• There is a php 5.6 and up version at https://github.com/tbela99/css/tree/php56-backport . It is on par with the php 8 branch.
• contributors and maintainers are welcome 🤗

[JakeQZ]

* There is a php 5.6 and up version at https://github.com/tbela99/css/tree/php56-backport . It is on par with the php 8 branch.

Not sure how that would or could work with Composer. But next year PHP 7.4 will be EOL, so that will become a non-issue.

And a project to incorporate this or allow switching of parsers is not likely to be completed by then (we also have day jobs).

could help us streamline our interfaces, so that in theory the user/implementor could select which CSS parser they want

We do need to tidy up and refactor some of our code in this area. Using the Sabberworm parser was a start, but there is more to be done. We still have some ugly code using string-indexed arrays rather than classes.

I think we should do this ahead of #994. And doing so would probably also resolve quite a few other open issues. When we have a really clean and tidy codebase, we can think about #994 - otherwise we would be trying to run before we can walk.