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.
@kizu wouldn't this be confusing if at some point we decide to list border-shape pairs as well? It's about consistency in borders rather than consistency in general.
(btw I'm fine with what you've said, but want to make the conclusion explicit)
@nomster Do you mean having a comma-separated list of space-separated 2-tuples of shapes? _That_ could go in the same order as whatever we will decide with borders, but I still think it is not necessary to have a correlation between the order of shapes inside each of those, and that of the borders.
And the nested shaped borders case sounds like a much rarer use case compared to regular borders, where the former shouldn't dictate the shape of the later, imo.
@kizu Yes, I'm OK with this. I mainly want to make sure we're not pushing ourself to an un-intuitive corner for border-shape in order to be consistent with something that's perhaps intuitive for border listification.