Closed AlexanderNey closed 10 years ago
@Ajax64 Nice, thanks for the contribution!
Seems inefficient to have to split the cas_styleClass string everytime we check if selector matches. Since this is something that happens very often need to make sure it's as efficient as possible. What are your thoughts?
Have you come across the need for multiple style classes quite often?
Personally, I do need multiple style classes (at least two) quite often, and end up having to concatenate the names and list them all inside the .cas file, which is highly inconvenient. For example, a few minutes ago I've used .incomingMessage
and .outgoingMessage
classes because I couldn't do .message.incoming
and .message.outgoing
. It gets ridiculous when there are more states involved (like perhaps .message.incoming.invalid
).
@Ajax64 @andreyvit happy to reopen if my earlier concerns are addressed and test cases please :)
Sure, I'll try to find some time to work on it, unless @Ajax64 beats me to it.
Hey guys,
I am very sorry to have abandoned this but I had some very busy weeks (deliver time ;) ). I am currently working with my prototype solution and I'll happy to finish that in the next two weeks if that is ok with you.
I am using multiple classes heavily for my prototypes - so I'll happy to see that going in to the project.
@andreyvit did you start already?
@AlexanderNey Nope, didn't start, deadline time here as well. :-)
Hey mate,
I added support for multiple style class values (as in CSS) and updated the sorting order of the selectors so that the last one (on cad file) overwrites the previously declared one. I am not sure what my implications my changes in the styleItem: method will have as your previously traversed the style nodes in reverse order.
I did not update the parser to support selectors with multiple classes (like CSS: .style1.style2) but it works fine if you declare just multiple selectors.
Please let me think what you think about that.
Cheers,
Alex
Changelog: