display: none;
Or The things you think are common knowledge but really they aren’t.
I was on the ShopTalk show a few weeks ago, and a few people have asked me what I meant when I said “display: none; naughties.” I foolishly thought that people would understand what I meant, (and I’ll come to that later) so I thought I’d better explain myself.
display: none; in responsive web design
When we’re changing out layouts based on viewport sizes, using media queries, we tend to switch page elements about a bit. We might make our images display one-on-top-of-the-other for narrower layouts, we might make our text super big to take advantage of bigger spaces.
There can be a lot of content on one web page, and often there’s a temptation to hide some of it on narrower viewports. This walks hand-in-hand with the assumptions that narrow viewports are mobile devices and people using mobile devices are roving the planet using the web ‘on the go.’
Assumptions
But those assumptions are exactly that, you’re just assuming that’s what the user is doing, you’re not basing that on real research or user testing. Why are you hiding so much of your content if you’re assuming it’s also useful to those browsing your site with a wider viewport?
Don’t be lazy
Just hiding content is a lazy design solution. Yes, it’s hard designing for smaller screens, but maybe that will help you ensure that every little piece of content you’re putting on that site is worthwhile. Responsive design should be about rearranging, not changing, your page elements.
And then you’re actually just loading it anyway…
When you’re putting content into your page, and then hiding it with CSS, it’s still there, it’s just not visible. So if you’re using this ‘technique’ across your site in numerous places, you’re likely taking a performance hit. And potentially, for narrower viewports/possible mobile devices, in the one place that a slow-loading page is likely to irritate a user. It’s just not worth that risk.
Changing the display, not hiding the display
One solution I’ve been using is changing the display of the content. It is a real problem that CSS can’t easily manipulate all types of content into a readable fashion on all devices. This is particularly true for navigation that needs to be displayed in a significantly different way, and often tables need to be reinterpreted into a more digestible format for narrow viewports. And in these cases, javascript can be your friend.
Mobile first
I always start mobile first, that’s not just in markup, it’s in content too. We don’t want to load up unnecessary HTML that creates performance problems, or javascript that may not working consistently on mobile devices.
If I’ve got a data table, and I think it would be better off displayed as a list of data, I would write the list of data into the HTML. This way it’ll load quickly, and those without javascript (or enough bandwidth to load javascript) will get a decent experience.
Progressively enhancing with javascript
Then, I would use media queries, or some kind of clever javascript, to load in the fancy content for particular viewport widths. I’ve done this to load in tables of data, replacing data lists, and also for navigation, replacing a vertical list of links with a show/hide button that reveals the menu when tapped (as on this site.) None of this requires display: none;. No markup is wasted.
[Edit]: Accessibility
The good Steve Marshall has pointed out that there are also accessbility issues related to display: none;. I didn’t want to cover too much in the post, but in case you want to know more about that too, I recommend Aaron Gustafson’s ‘Now You See Me’ on A List Apart and Chris Coyier’s ‘Places It’s Tempting To Use Display: None; But Don’t on CSS Tricks. [/edit]
Writing about markup
I’m a little bit scared of writing about markup. I’m sure there are loads of front-end developers out there who know a huge amount more than me, and I’m worried I’ll get it wrong or make myself look stupid.
I also shy away from writing about the ‘easy’ stuff. This post about display: none; is a fairly simple principle and I really don’t want to patronise anyone.
People do want to hear about the ‘simple’ stuff
Making these assumptions about it being a simple principle, and that everybody would know about it already, was daft. I was quickly proved wrong when people started asking me about it and then I realised how silly it was to think that we all have the same sources of information.
Scattered learning
The web is a big and varied place. To assume that someone else has read something just because you’ve read it is foolish. How do we learn about these resources? When do we all decide that we’re all going to read these particular sites and articles so that we’re all equally informed?
Even on Twitter, the resources we hear from, and learn from, are wildly different. We may follow completely different individuals and so the resources we learn from are curated by these individuals, and these may not ever crossover. Even if we do follow the same people on Twitter, noone can be expected to read every tweet, and inevitably you’ll miss some, and then you may not know about this other new thing that everybody else has been doing for years.
Where I get to the point…
The point I’m trying to make is that we shouldn’t be fearful of writing about what we know. Even if you write from the most basic point of view, about something which has been ‘around for ages’, you’ll likely be saying something new to someone. They might be new to the industry, you might just be filling in the holes in someone’s knowledge.
Every week I have a revelation on app.net or Twitter where I wonder how I didn’t know about this old technique or tool before… but we can’t be expected to keep up with everything. I hope this post does that for some people. It’s good to share what we know. You needn’t be the first, you’ll just help if you’re the first that somebody finds.
Regarding what people know, I’ve been worrying about the same thing for ages and avoiding writing about things that seem simple to me. I concluded a little while ago that what I’ve learnt so far comes mostly from other people writing about things that seem simple to them. As you say, we all look at different parts of the internet, and not everyone has been doing this job for years. I’m a pretty experienced PHP developer, but I’m perhaps still a little behind the recent changes in frontend development. Other people are probably in the reverse position.
Keep blogging the simple stuff, there will always be someone who needs that piece of knowledge :-) P.S I’d be interested to read a post from you on semantic HTML sometime. I know it’s one of your things, and I feel like I could be doing it a lot better (I still div a lot).
I’ve been working using a desktop first approach, and am considering switching to looking at ‘mobile’ first for my next project. One thing I’d like to hear more about – in the podcast you talked about loading content conditionally as browser window size is increased (using the example of the large illustration on the right hand side of your site). Can you recommend any good articles/links for further reading on this?
There’s also a lot to be said for how easy something is to Google. Before posting on something, try doing a quick search for what you’re thinking of writing about. I think more often than not, you’ll find that what you want to post about either hasn’t been covered at all, is not visible enough using the search terms you used (which anyone else might easily have searched for as well), or you do it slightly differently. Either way, sharing even the smallest bit of knowledge only makes the web community stronger.
Thanks for the great thoughts (and inspiration) Laura!
I’d be cautious with this approach as from my testing the images still get loaded.
[http://jsfiddle.net/jlaeser/pCbav/](http://jsfiddle.net/jlaeser/pCbav/" rel=“nofollow)
This could potentially make for a larger initial page load.Laura :)
thanks for this post –; well explained :)
Also, just wanted to say that I agree: writing about what might simple is always a good idea. Teaching webdesign is changing all the time and there’s so much out there that it can be a tricky endeavour to point students to good resources. By now, I recommend people and high quality sites as good resources to follow ~ which essentially means that you writing about something simple will always have an audience, from students starting out with learning webdesign to the students of the web who we all are :)
Then you Laura, are very naughty. For that’s exactly how you display your top menu at lower resolutions, no?
display: none;is used to temporarily hide the sub navigation, it is visible on hover.To be fair, I’m sure there are a lot of use cases where
display: none;has its uses. As with every rule, there are always exceptions :)I agree there are many use cases –; but this isn’t what’s implied here. I actually believe for performant web apps, using “display:none;” and modifying markup through js absolutely essential.
$('#element').hide();will ensure that, should JS be turned off the elements will still be visible. Essentialfor things like navigation!Nice article :)
Like Jason mentioned in the comments I too would like to hear more about how you approach using JS for conditionally loading content.
Cheers
I agree. It is fine to write about web design and front-end stuff even if you are not an “expert”. I have recently launched my new portfolio website and have included a blog section where I plan on writing about web design.
While doing client work we straddle a lot of areas and cannot be expected to know everything about everything.
Mea Culpa –; on my first responsive design I did a fair amount of display:none.
Cheers from Montreal,
Mark
Love the part on ‘Scattered learning’! Very important insight that not many of us think of from day to day. I feel safe to say that i’m learning new stuff each and every day, even the most basic tech but also on completely different topics that in hindsight definitely could have been worth blogging about.
Great post!
Thanks for your encouragement.
Hiding images by display none is a big issue, because they load anyway. The following research breaks the ice by documenting that “background images attached to elements that are inside a element with display none are NOT loaded”: [http://timkadlec.com/2012/04/media-query-asset-downloading-results](http://timkadlec.com/2012/04/media-query-asset-downloading-results" rel=“nofollow)
Loading images with a common 1x1px src (because the attribute cannot be empty) AND inline styling its background-image to the ‘original’ src you are able to control the load by conditionally replacing the src with the background-image src – and showing the parent element. Only then will the image load.
In an upcoming iteration, I’ve resorted to using more Ajax requests with checks for the user-agent. It’s arguably more naughty than just “display: none;”, because now there’s a bit of JS coupled to the stylesheet, but since it improves performance, it’s a net gain.
Perhaps the difference is how people get their learnings in the first place. A pre-supposition of this article appears that learning primarily occurs via blog posts and other forms of subscription based learning. I wonder how this mode of transport contrasts against learning when one encounters a problem then seeks an answer via google and stack overflow.
For instance, stack overflow is a fantastic place to ensure the content that is posted is of top notch quality, whereas with blog posts you do not have that guarantee that what you are reading is correct. However, with blog posts, you do get the subscription benefit.
Perhaps the solution to this dilemma is figuring out a way of combining stack exchange’s peer review and archival for searching abilities with blog posts careful curation, subscription and celebrity benefits.
Thoughts?
I agree that me writing this on a blog doesn’t necessarily mean I’m right, or that I know what I’m talking about, but neither do I have that guarantee when I read blog posts written by other people. The ‘peer review’ element seems to come via social networks. If someone that I respect posts a link to a blog post, then they give that post credibility.
I think that learning on the web means we all need to doubt the credibility of what we read. We build up knowledge by reading a lot around these topics and then making judgments on what we choose to believe. These aren’t always black-and-white facts, there are a lot of grey areas where we rely on ‘opinion’ pieces to understand the ‘why’s to help us make more informed decisions about our work.
I like your thoughts and I’ve decided to share more of my newbie learnings.
I think every project has an individual path. For me blogging about things I’ve learnt during a project is a way to remember what I did and at the same time being able to learn new stuff through the comments.
Just look at all the new knowledge coming through this blog posts comments.If I ever find I’m hiding an element indefinitely, it usually means it’s time to figure out if it’s needed at all. And I liked your last point over not being afraid to contribute something to the pool of knowledge. My reluctance to write blog posts comes from the fact that I’m entirely self-taught, so I have a tendency to assume everything I know IS common knowledge and I have nothing to add. I may have to rethink that.
I’m always looking for better ways to do things on the front-end, to make things faster loading, or smoother for the user.
Thanks for being one of the voices of reason and being a mentor to many in the web industry.
An article on how to do the JavaScript side of things would be great! Thanks.
“I’m a little bit scared of writing about markup. I’m sure there are loads of front-end developers out there who know a huge amount more than me, and I’m worried I’ll get it wrong or make myself look stupid.”
I bet most people feel the same way, so don’t worry. I’ve been designing & (front-end) coding for more than 10 years, and I still read about & play with the fundamentals all the time. I think it’s always important to keep re-visiting the basics, not just the very difficult stuff. Well done. Keep up the great work!