Closed bob2517 closed 9 months ago
Or even use target() instead of scope(). Might make a bit more sense to people.
Or even use target() instead of scope(). Might make a bit more sense to people.
Happy Lord's Day!
Not that they have to be the same, but :target
is a bit different in CSS. That may cause some confusion.
The more ACSS emulates the CSS standard, the more intuitive ACSS becomes, IMHO.
Also, code efficiency and consolidation in generally is a good thing but sometimes at the cost of context and intuitiveness.
I could have written my personal project much more efficiently by consolidating the code but it would have been at the cost of future DEVs losing the contextual knowledge of how I arrived at such efficiencies (without having to write documentation vise letting the code explain itself intuitively). In my mind, if they want to consolidate and make their code more efficient for their own project, they are welcome to, even as they judge my code for not being so, not understanding that it is purposely so for their benefit.
Good point.
Could use selector() instead of scope() maybe? Just throwing it out there.
button:click
add-class: selector(#myDiv) .something;
}
Nah - I think selector() will get confusing depending on the action command. Some action commands use selectors.
Ok - sticking with scope for the moment unless a better one arises.
Nah - I think selector will get confusing depending on the action command.
Ok - sticking with scope for the moment unless a better one arises.
Agreed.
The word "selector" is not used in CSS as far as I know...
How about...
button:click
add-class: (#myDiv) .something;
}
or even without the parens...
button:click
add-class: #myDiv .something;
}
This leverages CSS's native cascade syntax as scope.
This would add .something
class to ALL children inside of #myDiv
.
Yes, this had crossed my mind.
button:click
add-class: (#myDiv) .something;
}
The second one won't work, because some action commands already have selectors in them. It need to work with selectors in the action command - two selectors right next to each other would be impossible to differentiate.
My only consideration about the parentheses solution is that I'm not 100% certain that it isn't already a part of CSS syntax. If it isn't, then that would be a great solution.
I don't think a selector in parentheses is valid CSS though, so I think it could be ok...
Ok - we'll leave this for the moment and let it ferment with this syntax:
button:click
add-class: (#myDiv) .something;
}
That does look quite neat.
My only consideration about the parentheses solution is that I'm not 100% certain that it isn't already a part of CSS syntax. If it isn't, then that would be a great solution.
Hmmm... I wouldn't want to mislead the CSS developer if not having the parans didn't mean what it would intuitively mean in native CSS. So maybe the parens are enough of a differentiator that makes sense as an exclusive ACSS thing?
Here is an informative explanation that came up when I Googled parens in CSS... https://stackoverflow.com/questions/5478920/are-parentheses-allowed-in-css-selectors#:~:text=No%2C%20parentheses%20are%20not%20valid,gumby%20%3E%20.
No, parentheses are not valid operators in CSS selectors. They are reserved for functional notations, such as :lang(), :not(), and :nth-child().
You don't need them anyway; .gumby > .pokey + h3 by itself will work just fine.
This is because a sequence of selectors and combinators is always read linearly. Combinators don't have any sort of precedence. The selector can be interpreted as
Select an h3 element that immediately follows an element with class pokey that is a child of an element with class gumby.
And because of how node trees work, the use of sibling and child combinators here implies that both .pokey and the h3 are children of .gumby, which in your case they are, because of its statement that both of them are siblings.
That's cool. I think it might work then. It looks pretty stable then. Will just need to keep an eye of any future spec changes.
I need to double-check all the action commands to make sure it's not going to clash with anything else.
But if used, this would be the rule:
Any selector found in an action command that is contained within parentheses acts as the target selector for the action command.
Or something less wordy.
Closing - will handle each command on a case by case.
This is just an idea for code brevity.
Rather than do the following when only one action command is needed:
We could do this and save the extra loop on a new target selector in the core, which would be more performant, and the code is a bit more condensed, so more code is visible at the same time in text editors:
There's actually a bit more to type, and it may be a bit harder to read, but some people might prefer it. It should be slightly faster to process in the core too.
I personally have a tendency to do this when I only have one action command, so I can see more on the page at once, but you do lose consistency in the overall coding style:
The scope() option is useful on some commands, so it would make sense to centralise the logic for this and make it available everywhere - it's basically a way of specifying the target selector without having a target selector wrapping commands. It also gives an additional third-level of selector choice if used from within a target selector without getting into allowing deep nested deeper target selectors. I'm not ruling out nesting for future versions, but this would still be useful for brevity in coding regardless, even if deep curly nesting was implemented.