The Logical Border Radius Equivalents

I find this hard to remember and it’s come up for me a few times lately so I’m writing it down gosh darn it!

The individual corner border-radius values, like border-top-right-radius (which is hard enough to remember on its own) have logical property versions, meaning that should the flow of the document change, the border radius values should come along for the ride.

border-top-right-radiusborder-start-end-radius
border-top-left-radiusborder-start-start-radius
border-bottom-right-radiusborder-end-end-radius
border-bottom-left-radiusborder-end-start-radius

(By “equivalent” I mean the these turn out the same in left-to-right, top-to-bottom languages like English, Spanish, French, etc. In other directional situations, these are not equivalent, which is kinda the point.)

The syntax is:

border-[block direction]-[inline direction]-radius

You’d choose the logical versions if you were using border-radius on elements where the flow was relevant. Here’s an example of a “tag” shape on some inline text, and you’d potentially want the direction to flip.

If border-radius is being applied entirely as an aesthetic thing and it makes more sense to apply physical directionality rather than text-flow directionality, which is entirely common, feel free to use the classic properties.

I feel these newer logical properties for border-radius took an understandability hit, as while “border-top-right-radius” is hard to remember because of trying to remember the right order of the words, at least once you’ve got it, it’s clear where that radius is going to apply. Whereas with “border-start-end-radius” you just have to know (or guess and test) which direction “start” applies to and which direction “end” applies to.

Something like border-inline-start-block-end-radius would solve that, but I do understand that is an awfully long property name and might suffer from confusion. If someone accidentally mentally grouped it like “border-inline” “start-block” “end-radius”, that’s, uh, a meaningless jumble.

There is an interesting gotcha Michelle Barker found in Logical Border Radius with vertical writing modes, so if that comes up for you read what she’s got to say there.

Need front-end development training?

3 responses to “The Logical Border Radius Equivalents”

  1. The logical syntax definitely trips me up at times, but once you know what the syntax is, it gets… slightly less awkward to write/look at. Which by the way, it should show the syntax the other way around, right?

    border-[block direction]-[inline direction]-radius
    
  2. pd says:

    These alternatives are much less intuitive to me.

    In fact, they’re meaningless.

    border-end-start

    End start? Really?

    I appreciate you’re trying to improve CSS and that so-called ‘logical’ wording is being introduced elsewhere. But CSS has used top right bottom left forever. The benefit is it’s exactly the same regardless of text direction.

    So-called ‘logical’ in this case is just semantics.

    One person’s perception of what is semantically more ‘logical’ than another’s.

    Let’s not portray one person’s semantic intuition as ‘illogical’ because it’s not the same as another person’s.

    Perhaps a solution that would be more confident with the rest of CSS would be too implement the ‘missing’ border-radius equivalent of the margin and padding shortcut syntax .

    We’ve never been able to do this:

    border-radius: [left-corners] [right-corners]

    … with …

    border-left-radius
    border-right-radius

    … for setting the properties of just one individual side.

    Rather than getting caught up in this start / end nightmare, the demo use case could be solved very easily with a shortcut syntax border-radius never had but has always been missed (well, at least by the little black duck).

    If the “we can’t be politically correct unless we go and use ‘logical’ words [instead of literal words, which is what I think everyone’s been trying to portray their arguments as when using the word ‘logical’ whilst actually presenting ‘semantic’ variations] to cater for RTL and stop being singularly LTR ist” crowd insists, these start|endsemantic preferences can be aliased to the “margin/padding-esque two-unit shortcuts for border-radius we mysteriously never got in the first place”.

    Having said all that, I’ve been known to use the compass, anyway. North, south, east, west for logical AND literal.

Leave a Reply

Your email address will not be published. Required fields are marked *

Did you know?

Frontend Masters Donates to open source projects. $313,806 contributed to date.