We expose a pattern frequently to supply content that is appended or prepended to an element. Typically this is to facilitate attaching icons. Historically, we've used the names beforeContent and afterContent to expose this feature, but there has been some feedback that these names are long and cumbersome. Opening up a discussion thread on alternative names:
Some possible alternative options:
before & afterstart & end (Material UI uses startIcon and endIcon for a similar function)Lets use this thread to get consensus on what names we want.
I like the alternative of before and after as it models after the naming of pseudo elements. I'm open to start & end as well; it would be interesting to see if they have documented their reasoning for those semantics.
In CSS we do have start and end for things like text-align, I would say if the expectation is that things reverse in right-to-left, we use start and end and if they do not we use before and after.
In CSS we do have
startandendfor things liketext-align, I would say if the expectation is that things reverse in right-to-left, we usestartandendand if they do not we usebeforeandafter.
@janechu I believe that before and after both would localize equally as well, would they not?
They do not, behold: https://codepen.io/janemchu/pen/gOpQJdg
They do not, behold: https://codepen.io/janemchu/pen/gOpQJdg
Solid.
Wow I didn't know that either:
+1 for start/end
OK, apparently I am a little wrong, the ::before and ::after psuedo elements don't necessarily respect the dir attribute but they do detect if the content is an rtl language (I've updated that codepen link to illustrate), and will swap. This seems kind of crazy to me and I'm having a hard time finding any threads about the logic of this. Regardless, start/end +1.
Very odd - also didn't know that. I'm also still in favor of start/end. It is shorter and maps to properties that have more predictable directional behavior.
@nicholasrice we seem aligned on start/end - unless there are some late opinions looking to interject here I think we can consider this issue landed and closed. If everyone is good with that we can open a separate issue to update the slot names across existing web components.