Noam RosenthalWhen seeing a border described as "circle() square()", do you imagine is as:
- A circle surrounding a square (outside-in)
- A circle surrounded by a square (inside-out)
See first comment for illustration
Outside-in
Inside-out
Poll ended at .
Roma Komarov@nomster a) outside-out, but I really think this should not be conflated with the order of borders, as these two features are just different. One is a composite shape, for which the mental model is “take one shape, subtract another from it”, and another is “let’s add an infinite number of borders” to it.
If we were to define doing both in the same way, it should not be for the consistency argument.
@nomster Random almost off-topic, but I would love CSS to get some “array” methods to work with lists of values, haha.
--shapes: circle() square();
--reversed: reverse(circle() square());
and you get `square() circle()`, and so on. There are so many use cases for iteration, splitting, extracting, etc!
Then, if we had this, with mixins and functions, authors could create a syntax that would fit their mental models rather than relying on the defaults.
@kizu ship it!(*)
* (% a few years of discussions)
@nomster Will try to slowly gather use cases, so any potential proposal could start strong, haha. But yeah, while I don't think we need unbounded loops in CSS, there _are_ plenty of use cases for iteration and repetition across known counts of entities, either coming from some pre-existing list, or mapped over the DOM, etc.
Looking at what things are left from the CSS preprocessors, those loops (and general list manipulation) are one of the things we still don't have any support in CSS at all.