css-selector-parser

css-selector-parser copied to clipboard

fixes #12

@elad-yosifon thank you for your contribution!

I checked your PR and I think it will be a bit inconsistent with CSS spec and not so comfortable to use for the end-users.

Can I suggest a different approach?

Currently we have preudos array which as of today can only contain pseudo-classes:

pseudos: [ { name: 'lt', valueType: 'substitute', value: 'var' } ],

What if we extend it a bit?

pseudos: [
  { type: 'pseudoClass', name: 'lt', valueType: 'substitute', value: 'var' },
  { type: 'pseudoElement', name: 'after' }
],

What do you think?

@mdevils the first thing that comes into mind is backwards compatibility.. IMO this issue is a parsing issue, not a code breaking bug (assuming the end user is parsing and rendering using the lib utilities).

My initial thought was to fix the parser and "patch" the rendering utility in a backwards compatible way..

@elad-yosifon thank you for your fast response.

Backwards-compatibility is very to implement in this case. If type is missing, pseudoClass is implied.

My point is that pseudo-class and pseudo-element have different nature. For instance, pseudo element cannot have an argument or round braces after it. So they should be parsed differently. I.e. div::after(hello) should be a syntax error.

@mdevils I think both ways are acceptable.. I added this fixup in order to resolve an issue in a tight schedule project I'm working on.. Unfortunately I can't re-do this PR according to your suggestion, is this something you can implement?

Hello @elad-yosifon. After a huge refactoring version 2.0.0 was released, which doesn't have this problem anymore. Please update.