Closed bob2517-whiteline closed 1 year ago
Example use:
Step 1, inserting a component after an element, with a render-after-end, and then hiding the original element. Step 2, then from the component, reshowing the previous element and removing the component itself. None of that functionality needs extra variable references if combinators alone are used. The parent combinator "<" can be used anywhere in the component's events to target the outer component tag. With the previous combinator, the thing that created the element can be targeted too without any mucking about.
Correction - previous adjacent symbol will be " - " - with a space either side of the minus sign. Otherwise there is the danger of matching to custom elements (like "my-element"). Unless a better symbol comes up, that's the plan.
It will work like the CSS spec for next sibling (+) and work with simple selectors. So everything after the minus sign (that isn't a special ACSS combinator like "->" or "<") will get counted as the previous selector.
The previous adjacent combinator is done, and I've basically set it up to do the opposite of the "+" combinator from CSS. So this now works:
span:click {
& < p - p - p {
background-color: blue;
}
}
On a click that would go to the closest p tag parent, go to that parent's previous sibling element if it is a p tag, and finally go to that last one's previous sibling if that is a p tag.
It works with all the other CSS and ACSS combinators.
That's going to be a lot quicker than writing it in JS. You wouldn't even bother though usually, as it's too painful to write - you would use a reference class, id, attribute or a variable or something. But you don't need to set up any additional markup at all if this combinator is used instead, which is nice. Sometimes having reference names is better for readability, and assigning a class or attribute may be more helpful if things tend to change in the HTML. But if you've got a handle on that, and the HTML is not going to change (which would make the selector stop working), then this is a conciser option.
That, in combination with the other existing combinators, means that it's should be a lot easier to attack certain elements without needing classes, and all that other referency stuff.
That will be put on the branch tomorrow morning.
Note that jQuery has a number of functions that do similar things, so it's worth reviewing all of those to see if it's worth setting up additional combinators or see how CSS could do the same thing. This is the area where the browser loses the framework/library battle - it needs to be quicker to provide solutions like these.
The other previous combinator, the general, multiple result one, which is looking like it's going to be "-~", following basic math symbol conventions, is going to be a bit more tricky to set up in the core, but I've got a basic plan for it.
While looking at that, I found that seems to be an issue related to multiple elements being found in the middle of complex combinations of CSS and ACSS combinators, and only one of those elements found would then work with the rest of the selection. So I'll fix that as part of this upgrade - it's slightly disrelated to this issue though.
The prev sibling combinator is now on the 2.11.0 branch (-).
The multi-result previous sibling combinator is now on branch (-~). It only currently works as the final item in a selector string.
I'm not going to close this issue though until the issue is resolved of getting multi-results from the middle of a selector containing special ACSS selector clauses, like "p -~ div > span". I think it's only really come up as a thing due to these new selectors, because the chances of someone wanting to target multiple shadow DOM contents at the same time is probably a bit niche, so it's not come up as a bug before.
This is the earliest half-baked issue. Will wrap this up next and add support for multiple element result sets to allow it to work fully as advertised.
I think I've done as much on this as I care to do at the moment. This now works as syntax:
button:click {
& < div -~ div:nth-of-type(3) > p:last-of-type < div -~ div:nth-of-type(1) > p:first-of-type {
background-color: green;
}
}
There's probably a key scenario that I've missed, but for now I'm going to call that a wrap for this release and handle any combinations that get reported as they turn up. Will have this on the branch tomorrow morning and then try and crack on towards the release date.
Closing in preparation for release.
Do the adjacent sibling combinator first. Make it like the next sibling combinator, "+".
It probably makes sense to use "-", as it's the opposite of "+".
Like "div - p" to get the previous sibling if it's a p tag.
It is unlikely that this would be implemented in the rendering engine, but it does makes sense in ACSS, where locating targets for actions are done from an event. The "<" closest combinator has already proven very useful indeed for UI. It saves on having to store reference variables/attributes to do things with parent elements.
I'll implement this and see how useful it is before it's officially released. It shouldn't be a big deal to set up in the core. I have found an intuitive need for it, which is why I'm creating an issue for it.
Still need to work out a character for the general previous sibling selector. But I haven't worked out what the opposite of "~" is yet...