Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

CSS CSS Layout Techniques Display Modes Inline-Block Formatting

Chris Mitchell
Chris Mitchell
12,719 Points

inline-block formatting... a inside li

Is this perfectly valid and not a hack??

In the video, you say that when we set the a elements to display block, then the whole area is clickable, however if you for example set the .main-nav li to 50px then i find that the a element breaks outside of the li element..... for those that are interested then i found by setting the a element to the same border-radius as the li element fixes this and indeed makes the whole li area only clickable.

try changing my .main-nav li border radius here and you will see where the clickable area is that i set the color to a transparent reddish color: http://cdpn.io/dHgGs

I am not sure exactly what you mean could you elaborate. Also a quick codepen tip. I see you included all the normalize code, however you don't need to do this. If you click the cog next to CSS you can include normalize behind the scenes to make your code look nicer. Other options too for each language

4 Answers

Hi Chris,

I see what you mean. I did not know if this was expected behavior or not so I tried doing a little searching. I wasn't even really sure what to sure for but I finally found this stackoverflow question which should shed some light on the issue:
http://stackoverflow.com/questions/8582176/should-border-radius-clip-the-content

So according to the spec it seems that this is the expected behavior if overflow is set to visible. The solution is to set overflow:hidden

This is probably more preferred over your solution. You're having to repeat the border radius value which does work but it's repetitive and if you change your parent radius at some point then you have to also remember to change the child radius. Of course, if you're using a css preprocessor then this would be less of an issue because you could use the same variable for both and they would change together.

Chris Mitchell
Chris Mitchell
12,719 Points

Hey thanks for the tip Adam and great reply Jason, that's answered everything for me. I had to go work and didn't have time to research it!

Chris Mitchell
Chris Mitchell
12,719 Points

Jason Anello

I have tried to do the over flow hidden. This does clip the visibility to hidden but when you hover over it is still there.

set both to block or inline-block and repeating code is the only way i found works so your suggestion of using a preprocessor like sass is the way to go!! I have updated the codepen to view and added a much bigger logo http://cdpn.io/kwseL

Maybe im being a little fussy??? but my thinking was if you have something extra big then the clickable area outside is going to be much bigger too.

Maybe I'm misunderstanding things. Are you saying that after overflow: hidden the corners are still clickable?

I took your original codepen and I commented out the border radius for the a element and I was able to see the red background extend to the corners. I then set the overflow to hidden on the li and it seems to have clipped both the background color and the clickable area. For me, the corners are not clickable anymore.

I forked your original codepen: http://codepen.io/anon/pen/fGenI The corners don't seem to be clickable to me unless I'm misunderstanding what you're saying.

It did produce a gap below the li elements which I'm not sure about at the moment.

Chris Mitchell
Chris Mitchell
12,719 Points

ok try this, i made in a possibly very hacky way (so ignore the hacks lol) everything larger and the reason why i brought this up as the larger it gets, the worse it becomes.... ive left comments in the css to follow http://cdpn.io/dHgGs

Now I think I finally know what's going on here thanks to my girlfriend who was watching me hovering around the corners and wondered if it was a browser issue.

It didn't even occur to me this time to check different browsers.

Are you on chrome? I've been on firefox the whole time but just tried it on chrome and see the exact problem you're describing. It clips the background but not the clickable area.

I want to say it's a bug in chrome. It seems to me that firefox is following the spec on this one but I could be wrong. So maybe you've discovered a bug in either firefox or chrome.

So it seems that you would have to use your fix of setting a matching border radius on the child to work cross browser. Unless there's some other property that can be used to make chrome comply.

If you take a look at this section of the spec on corner-clipping: http://www.w3.org/TR/css3-background/#corner-clipping

It says, Also, the area outside the curve of the border edge does not accept pointer events on behalf of the element.

You would think then that this would also apply to child elements if you've set overflow: hidden on the parent. It seems to me that the child should not accept pointer events outside the curve.

I wish I could find something in the spec which definitively states what the behavior should be.

It's possible that this is a gray area in the spec and firefox went one way with it and chrome went the other way.

Chris Mitchell
Chris Mitchell
12,719 Points

lol women are somehow always the better detectives, my g/f says its just curiosity....hmmm.

Yes I am on chrome, and I didnt think of trying another browser either.

Quote from http://www.w3.org/TR/css3-background/#corner-clipping : As ‘border-radius’ reduces the interactive area of an element authors should make sure the remaining interactive area conforms to recommended minima for the platforms they target; in particular, conforming to recommended minimum touch target sizes may require larger widths and heights when ‘border-radius’ is used.

I am not sure if I understand this but do you think that chrome are thinking of the small touch screen devices??

So if the element starts to get too small then the unclipped area around the border-radius provides a little bit of a larger area to hit for touch events??

Maybe that's why FF went one way and Chrome the other, I am just guessing tho.

Anyway's great work on highlighting this for us.

I could be wrong but I think we're the authors and it's telling us that we need to take care that we've used sensible borders. I believe the spec's refer to the creator's of websites as authors and browsers are referred to as user agents. So I'm not sure that a browser is supposed to do that for us.

For the time being, I think that your solution would be fine to do until the browsers reach an agreement, if ever.

I'll probably look into this a little bit more out of curiosity. Thanks for bringing up this issue. It's something to remember whenever we're in this situation.