Still not sure about the naming of the new parser rules.

I suggest to see if it would make sense to follow the names from the CSS4 document: https://drafts.csswg.org/mediaqueries/#mq-syntax. That grammar might also give a hint what needs to be supported and might enable a complete implementation.

Still not sure about the naming of the new parser rules.

I suggest to see if it would make sense to follow the names from the CSS4 document: https://drafts.csswg.org/mediaqueries/#mq-syntax. That grammar might also give a hint what needs to be supported and might enable a complete implementation.

Ah yes, at a first glance from this perspective I think mediaRangeParameter should have been mediaFeatureValue and the current mediaFeatureValue is more like a mediaFeatureValueExpression.
I will analyze it.

I've updated the naming.

• mediaFeatureType : https://drafts.csswg.org/mediaqueries/#mq-ranges
• mediaFeatureRangeContext : https://drafts.csswg.org/mediaqueries/#mq-range-context
• mediaRangeExplicitValue : separation from mediaFeatureValue which ca contain cp expression

There is a "hack" though for cp_css files in which the condition :

(mediaRangeExplicitValue | mediaFeatureValue )

was used to fix the greedy sass expression in :

`30em <= width <= 1200px`

The width was identified as term instead of mediaFeature identifier.

I see that I will have to revert some updates from NodeType for compatiblity reason.

Now I see that I got myself into some trouble emulating the new syntax :) .
Maybe some abstractions can be done to simplify the logic, but the Css model implementation needs to be updated.

Before:

And with media query 4:

@haidubogdan yeah these things have the tendency to be the proverbial can of worms. Could you give me an insight whether you need/want help and if so, where or what is the current state?

Thank you @matthiasblaesing, for the moment it should be ok.
The zone which needs to be adapted is the CssModel.
I think I understand it's implementation. In the end it's a matter of applying a compatible solution between the antlr parser and the element model factory.

@haidubogdan maybe helpful for you. The org.netbeans.modules.css.model module has only "friend-only" dependencies, so you can adjust the API + SPI and "just" take care of the use sites.

@matthiasblaesing I hope that the latest commit will pass the tests.

At the current stage there are no additional nodeType tests for the new range syntax, just the parser tests.
I didn't envision other usage for it.