-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Master: logical operator 'and' should have precedence over logical operator 'or' #2776
Comments
This seem to be more about and having higher predence then or in common programming languages. |
Makes sense. |
Although it's not about left-to-right or right-to-left but order of operations. |
Yes, it's not about operator precedence (
|
@seven-phases-max Neither order nor precedence should change the outcome. Both should evaluate to true. A logical @seven-phases-max I couldn't tell if you were posting what the problem is or what the outcome should be, but if someone comes across this thread, the correct evaluation would be:
It's not really that "and" is evaluated first so much as "and" continues to append conditions that must also evaluate to true, so all statements joined by "and" must be evaluated as a whole. Example: BUT, in the
I also notice that the required syntax for
I wonder if it might be in Less's best interest to adopt this specific rule: "to avoid confusion caused by precedence rules, the syntax does not allow ‘and’, ‘or’, and ‘not’ operators to be mixed without a layer of parentheses." |
Yes, this is correct (that was my mistake, sorry, looks like I've made some mistake when checking it in a JS console).
We should be very careful with this (down to not even using any CSS stuff where possible), since, as you already referenced above, in CSS they are too far from "normal" C-like behavior. Counting that Less also already adopted many C-like stuff there (
may simply spoil the very idea of Less being a "more usable" version of CSS. (Well, in this particular case, counting that Less guards can be assumed to be much more often used stuff than CSS conditionals). Hmm, now after I wrote this - I realize I have no straight-forward idea how to handle this at all.
is not quite true, since Less also never evaluated even |
Remember on a separate thread when we were talking about what the "docs say", and how that's not exactly gospel, especially for some features that were not completely implemented? (Can't remember what feature we were discussing it on.) This is the same case, except in this case the existing code is not gospel. The fact that Less never evaluated |
Yes, but counting the age of the feature itself (in that case it was "young" DR).
:) |
I was thinking about this more through dinner. I think we should actually deprecate "not". There's no reason for it. We can evaluate conditions with "=" and "!=" now. So I wasn't necessarily advocating for a behavior either, other than making things consistent and clear. In truth, CSS's "min-width" for media statements was always clunky, especially since it refers to viewport width and not the min-width property. And it didn't handle "<" vs "<=" very well. So yeah, you do make a good point that Less is mimicking CSS but also aiming to improve it or simplify it. In this case, we can probably improve the syntax a bit. It was good to replace the comma with "or" and we can simplify negation as well. Since "not" is so tricky in CSS, we're probably better off without it and using things like |
I have looked at operator precedence in four languages (javascript, java, python, C++) and all four evaluate I do not think we should remove not for similar reasons. Someone might want to do Right now, things In any case, these things are easy to change in code and were not released yet. |
Btw., I've just re-read the latest spec. and found quite curious things worth to note:
The first one is probably something we can safely ignore since the only reason for it seems to be unambiguous parsing (discussion), i.e. the issue we solve in Less by other means anyway. The second one is interesting because currently only Speaking of the WG requirement to use pares everywhere itself, it seems to be an invention made to improve browser ability to recover from and/or support conditional chains involving unknown/future properties, and not something done with usability or something like that in mind at all (I can't find the main discussion about that yet, but I guess this thread illustrates what it was about in general). |
Ah, yes, in a long run, the current Less requirement for parens to be around "other" expressions/values and in the same time to be optional around |
@SomMeri All good points for not dropping Usually my concerns are around language consistency and simplicity. It's conceivable that using As far as usage with the
Any CSS beginner would be able to understand those statements. Okay, so we have "and" and "or" figured out, and looks like "not" is staying. Any other language change proposals related to this should probably go into less-meta 3.0 discussion, agree? |
This is related to #2763 pull request.
The guards of this mixin:
should be evaluated to true if called like this
.orderOfEvaluation(false, false, true)
e.g. the same way as logic in javascript works.The text was updated successfully, but these errors were encountered: