Is Not A Four-Letter Word
Before we had CSS (Cascading Stylesheets), we had Font tags. And Table layouts. And, of course, the beautiful and ever-versatile "spacer.gif". When CSS came along, however, we were able to get rid of these hacky and verbose solutions. And, the more that modern browsers support advanced CSS, the more hacky solutions we are able to drop. For me, however, there is still one hold-over from this pre-CSS era - the non-breaking space, or for short.
In my HTML, I'll often use a to add a little more white-space on either side of a pipe; it's lets the links "breathe" a little more and makes the text more readable, providing for a better user experience (UX):
<p>
<a href="#">This</a>
|
<a href="#">That</a>
</p>
I am sure that many of you CSS experts are looking at this and gasping in horror at my archaic use of out-dated HTML entities to do something that modern-day CSS can do for me. But, for my money, nothing is quite as simple and elegant as a non-breaking space.
Or maybe it's just my lack of CSS expertise? If I were forced to replace the with CSS, it might look something like this:
<style type="text/css">
span.pipe {
display: inline-block ;
padding: 0px 5px 0px 5px ;
}
</style>
<p>
<a href="#">This</a>
<span class="pipe">|</span>
<a href="#">That</a>
</p>
Here's I'm simply using CSS to replacing the padding.
Or, maybe I could go crazy and try to replace the pipe itself, substituting a border instead of the pipe character:
<style type="text/css">
ul.nav {
margin-left: 0px ;
padding-left: 0px ;
}
ul.nav li {
border-left: 1px solid #333333 ;
display: inline-block ;
padding: 0px 5px 0px 7px ;
}
ul.nav li:first-child {
border-left-width: 0px ;
padding-left: 0px ;
}
</style>
<ul class="nav">
<li>
<a href="#">This</a>
</li>
<li>
<a href="#">That</a>
</li>
</ul>
Of course, the left-border looks mad junky-to-the-monkey. As such, I could try to remove the pipe, but recreate the pipe character as a pseudo-element:
<style type="text/css">
ul.nav2 {
margin-left: 0px ;
padding-left: 0px ;
}
ul.nav2 li {
display: inline ;
}
ul.nav2 li:not(:first-child):before {
content: "|" ;
display: inline-block ;
padding: 0px 5px 0px 5px ;
}
</style>
<ul class="nav2">
<li>
<a href="#">This</a>
</li>
<li>
<a href="#">That</a>
</li>
</ul>
All of these CSS-based solutions work; but, let's face it - these solutions are all kind of overkill when compared to the simplicity, the brevity, and the sheer beauty of the non-breaking space. That said, I'm definitely open to the possibility that it's my skill-set holding me back. If you have a CSS solution that is more elegant than the non-breaking space, I'd love to see it.
Want to use code from this post? Check out the license.
Reader Comments
All the examples are overkill...
http://jsfiddle.net/24oLso5z/
Just stick padding on the anchors and leave the pipe alone.
@Phunky,
That can work. But there are two down-sides. First, the first link will have a left-padding which will break its vertical alignment with the rest of the page. You could, of course, add a :first-child selector to conditionally remove that padding. The second down-side is that this actually enlarged the click-area of the link itself. I'm not saying that's bad, but it will become evident if you have a :hover effect on the link.
Not shooting it down - just saying it's not quite that simple ;)
@Phunky,
Also if the pipe is purely presentation only, then i'd look at moving it out of the markup with something like:
http://jsfiddle.net/24oLso5z/1/
@Ben,
Well tbh I was only looking at the use case stated, removing the need of sure there are lots of edge cases this will bring regarding the interaction and other visuals, but they can all be handled.
@Ben,
Eeek, wish I could edit comments... so if you wanted the visual, without affecting the hit area of the anchor then you'll likely want to use a list or some other form of wrapper element.
http://jsfiddle.net/24oLso5z/3/
@Phunky,
Yeah, if I had to go with a purely CSS approach, I think I would us the :before / :after approach. Seems like the most elegant of the CSS approaches. Plus, I happen to have a soft-spot in my heart for :before and :after - when I discovered them, they kind of blew my mind! And, once we dropped support for IE7 (which didn't support those pseudo-elements), it was time for a happy-dance :D
FWIW, there are some valid uses for using in web content:
http://blog.liveeditorcms.com/html-tip-keeping-some-words-together/
I know your post is mainly talking about Band-aid scenarios that we all fall captive to, but we should strive to understand the good uses for tools like this as well.
Plus I know you're obsessed with the details too, Ben. :)
Love it! I use the non-breaking space too sometimes (gasp!) I am also thrilled to see that you posted two blogs today and that you've been posting a lot more frequently lately. I was beginning to miss you. :-)
I too am a non-breaking spacer. You, sir, are not alone in this world. I certainly have a lot more I could learn about CSS, but I don't think it's blaspheme to throw one in every now and then.
@Chris,
Yeah, that's a good point. I've also had that problem. Typically, I'll use that inside of "Read More", and other phrases that just look right on one line ;)
@Anna,
Glad to be back... and missed :D
@Jim,
I'm in good company, then!
it is so eyesore seeing so many blogs in 800px width but you are not only one. Unfortunately most popular blogs have 800px. How come they don't want to build something responsive? You are working with design company, maybe I am missing something. But to me this blog looks like from early 2000 to me.
There are valid use-cases for nbsp -- the article Chris Peters linked to had a prime one -- using it to prevent text from splitting in certain places. That's literally what a non-break space is for -- a space that doesn't break.
But the pipe example in this article is an abuse of markup -- using it for a visual effect, rather than a semantic purpose.
Whether or not the pipe should be literal or generated content depends on how the markup is written.
If the links are written as consecutive links (A + A), then the pipe should be in literal markup to delimit them (because you shouldn't have consecutive links with nothing in between them, since some users might not be able to visually differentiate them).
But the correct solution (IMO) is the unordered list, with CSS to style them as a row and generated content for the pipe in-between.
That's not overkill -- it's "correct but verbose" as opposed to "incorrect but simple". :-)
You could, in the spirit of
http://www.heydonworks.com/article/font-hacking
also go nuts with fonts: Create a single-character font only containing the pipe, but with its x-advance set as generously as needed. Then embed this font using standard @font-face and use it in the navigation. E voilà! Your pipe gains more whitespace around it magically without any added mark-up.
@Ben, there was a period of time, I noticed, where you weren't blogging quite as much, but then, somewhat recently, I started noticing more and more blog entries from you again, which pleased me greatly. I have been enjoying learning angular through you, though I can not contribute much if at all to that particular conversation (unfortunately). It will go with what I am working on nowadays, as I have shifted into .net territory, a place I thought I would never go. At least not willingly. I still love ColdFusion, and it is still my first love as far as programming languages go, but .net is what is in demand around here, unfortunately. I wish you'd do some .net and blog some about it, because I know it would help immensely with your fast-learning ability and ability to teach others through blogging. :-) You have a true gift for that. But I am sure you are busy with angular, etc., and wouldn't ask someone to go into .net territory if they didn't have to.
OK, so to get back on topic, because I know I went a little off, you COULD do a pipe graphic and use hspace. :-D hehe. CSS is something I struggled initially to really get into as opposed to the older ways of just hacking out a bunch of html code and putting inline styles, etc., in to just work. . .just "making it work". . .and being a coder, it was really hard on me at first when "tableless web sites" became all the rage and I was used to arranging everything in tables and making it work that way with nicely defined columns and rows, etc. I mean, I get it, at least kind of, the whole table-less thing, it was just hard to wrap my head around at first. I guess in my head, there's kind of a table organizational structure that seems natural or something.
And as I mentioned before, I do throw a little nbsp in there every now and then. I've tried to go all-css and try to work with it to do spacing, page layout, styling, etc., but nbsp has been my friend on numerous occasions. OK, back to .net world! At least I can work some of your angular approaches in this programming world that is still kinda new to me. :-)
Hey Ben. I think   should only be used if youd like to inteoduce space that will not lead to wordwrap. Of course you could use it for layout, the same way you could use tables for layout. Tables are also quite easy to use compared to write your won grid layout right? so why not use tables for that job :-) You endorse to violate semantics of the web and destroy clear separation of concern. Also imagine the poor screen readers who need to read your pipe symbol between the navigation items. Blind people might think this is some sort of a plumpers website. I love your posts but I dont agree with your agruments of just being more efficient, but at what price?
If you want to compromise on the seperation of your domain specific languages, go ahead. As always, sometimes you need to put best practice aside for the sake of time / tech-monogamy. But lengthy blog posts aside, its still a bit gross and in many modern web scenarios it will come back and bite you in the butt.
I feel I should stress your "but, let's face it" conclusion is subjective. With my level of comfort in CSS, the CSS solutions are much simpler.
@Ayhan,
Honestly, I've not really put in any time to learn about responsive design yet. Since I do basically all of my work on a desktop, I've not yet had an personal friction from having to view things on a mobile device or tablet. That said, I wouldn't really want to make the site much wider - I find liquid layouts a bit awkward to consume as monitors get larger. But, of course, that's just my personal opinion.
@Brothercake,
Ah, that's such an interesting statement:
> "correct but verbose" as opposed to "incorrect but simple"
I want to disagree... but I don't think I do :D
@Manuel,
That article looks intense! I'll try to set aside some more time read it when I'm not a work. In my career, I've never really learned too much about fonts. I used to just go with "arial, verdana, sans-serif". Thankfully, Google Fonts and TypeKit and the like have helped me evolve; but still, I only know that stuff at the very superficial level.
@Ash,
Can you expand on this:
> it will come back and bite you in the butt.
I am not sure what you are envisioning? I'm curious to hear if you are considering something that I am not considering. Also, as far as comfort with CSS, how would you do it? Would it much different than some of the CSS-based solutions I provided? I am not sure if you are saying you have a CSS solution that is easier?
@Gion,
I must admit that I don't often think about accessibility :( It's not something I have much experience with. That said, I would agree with you that removing extraneous content for screen readers is a good thing. And, in that case, I would agree with you.
@Ben,
> I want to disagree... but I don't think I do :D
:-)
> I find liquid layouts a bit awkward to consume as monitors get larger. But, of course, that's just my personal opinion.
But you can resize your window ;-)
It's very true that (for example) 14px text within a 1000px column is way too wide, because long lines are harder to read. But what if the user had increased the font size to 28px, or 100px! The length of a line is not really a factor of the column width, it's a factor of the relationship between column width and font size.
Ultimately, the benefit of flexible layouts for desktop, is that it's then the user's choice to decide how much space they want or need the layout to use.
In my view, the best way to describe responsive breakpoints is using "em" units. Because then, they don't get triggered just by decreases in window size, they also get triggered by increases in font size -- i.e. when the font size increases to a certain point, the single-column "mobile" layout is triggered, and that's exactly what the user needs to provide space for larger text.
@Brothercake,
In my world - the only good window is a *maximized* window ... but, I grant that this strictly personal preference. I have maximized windows for everything and then simple CMD+Tab and CMD+Tilde to get from application to application. For me, personally, that allows for the most focus and concentration.
Have you seen this article on the golden-ratio applied to Fonts:
http://www.pearsonified.com/2011/12/golden-ratio-typography.php
I tried reading that the other day and my brain started to melt :D
Definitely making this blog more responsive is on my list of things to do, if nothing else, as a learning experience.
> In my view, the best way to describe responsive breakpoints is using "em" units. Because then, they don't get triggered just by decreases in window size, they also get triggered by increases in font size -- i.e. when the font size increases to a certain point, the single-column "mobile" layout is triggered, and that's exactly what the user needs to provide space for larger text.
That sounds really interesting - I don't think I've ever seen that before. I think most of the examples that I can remember seeing are all strict px-based breakpoints.
I also use sometimes, and don't see it as a big problem. A screen reader would just ingore it, treating it as a space:
http://stackoverflow.com/questions/1693478/is-nbsp-allowed-to-make-space-in-terms-of-semantic-web-standards-and-accessib
The above link includes the tip of using style="white-space: nowrap". A css way to do the same thing. A little simpler than your block with padding. But a plain is still the easiest of all.
Screen readers seem to typically be smart enough to recognize a pipe on it's own isn't spoken:
http://www.deque.com/blog/dont-screen-readers-read-whats-screen-part-1-punctuation-typographic-symbols/
Regarding the layout discussion also in these comments...
I've been looking at how to adapt an old site to be more reponsive, or more specifically, how to make it look better on wider monitors.
Any site with a lot of text on it is very difficult to read if the width gets too wide. Some may argue with that, but newspapers put content in narrow columns for good reason. However, multiple columns are hard to adapt to scrolling used on the web.
Found it interesting to look at how the major search engines display their result text. Google, Yahoo, and Bing all fit search results into a column probably about 600px wide - a comfortable reading width, with generous white space on the left. Most people never notice that it isn't really optimized to use the wider screen space. And they sometimes throw in extra content on the right since they have all that empty space.
I think you're blog looks just fine on my wide screen, the header and footer stretch across the full width, and the text in the middle is easy to read.
I agree with the use of ":before" and ":after" for this... but further to that, why not use EM instead of PX for the padding measurements? It'd scale with the text :)
@Rick,
FWIW I find that's a waste of space.
Users need to be able to resize text (and by extension, line height and letter spacing), but they don't need to be able to resize padding.
Increasing the text size puts pressure on the viewport (because larger text needs more space), so resizing the padding as well exacerbates that problem.
@Chris,
I appreciate the positive feedback. One of the sticking points for me, in trying to experiment with responsive design on this blog, are the code-blocks. It's one thing to think about "content text" expanding and contracting; but, blocks of code, on the other hand, are a very different beast. When you read prose, you could theoretically read it one ... word... at .... a... time... and it would likely make sense. As in, you could create a mental model and follow along.
But, if you're on a mobile device and I give you a block of code, I can't arbitrarily make that code scroll horizontally or have line breaks. Code, unlike prose, is very contextual and very visual. We're not compilers - we need to see the code in its context, in its layout, in its relation to other code. That's how we (or maybe just me) makes sense of it.
So, that's where I get hung-up. Sure, I could add breakpoints ... but, will that *truly* make the content *easier to read* ? Or, will it simply be responsive with no value-add?
And, if I have to be super honest, I don't find it enjoyable to read code on anything smaller than a tablet. I've tried to read code on my mobile when standing in line or waiting somewhere and I find it to be quite an enjoyable experience.
@Ben,
Something wrong with "overflow-x:auto"? :-)
This is the approach I prefer, and it works responsively: http://www.sitepoint.com/best-practice-for-code-examples/
(The comments got bogged down with tabs vs spaces ... but anyway :-) )
Though it is true that the code is harder to read on a small screen. But I'm not sure there's ever much you can do about that, as long as it is actually legible and doesn't make the whole page overflow, then that's enough. Some things are just easier on a larger screen, but that's not a reason not to do *something* for the smaller screen.
@Brothercake,
Ooh, thanks for the link. Honestly, I'm happy to read anything about "Best practices" on this matter as I do feel a bit without direction. I'm feeling inspired! Maybe I can try to fool around with this over the weekend. Luckily, there aren't too many UI components on this site; so, it shouldn't be a monumental effort.
@Ben,
lol, you say that now ;-)
@Brothercake,
Ha ha, right?! Maybe I shouldn't make any assumptions until I actually start. A the very least, I am use LESS CSS already, so at least that *should* make it easier to integrate break-points.
@Ben,
Or it might make it harder :-O
I've never used any of those pre-processors, so I can't really comment.
But it always seems to come down to the same thing -- it's only when you finish something, that you understand how you should have built it :-D
I use LESS as well, and it's the same as any other tool... it all depends on how you use it.
I once used one inside of an H1 tag above all my other content to create some additional space real quick instead of creating a top margin. Don't think I ever removed or replaced it with css and is still in use somewhere out there.
Agree with much of what you've said - keeping it simple. When I'm working away I feel I can afford to get away with "archaic" tools, like stuff that I know I "should" be using CSS for... but you can't beat speed...!
Accessibility beats speed.
Like rock-paper-scissors.
Hmm .. there's an unclosed STRONG tag floating around somewhere!
Haha hang on let me close it! is that better??
Ooops, sorry about the formatting. I need to add some validation on that stuff. Really, I'd love to revamp all the formatting in the comments and *try* to get sort of Mark-Down style support.... on the list of things to do... up there with responsive design :|
Nice one
@Kenna,
Love it