When you are designing a responsive site, it’s best for all involved to get working prototypes in front of stakeholders early and often.
This seems so obviously true in my experience. Talking about a responsive implementation of a desktop design, or showing comps for various break points just doesn’t work. You need to get it in peoples hands so they can see how things change and adapt on different screens and devices.
GoDaddy has been transformed in recent months and is essentially a new company.
How a company becomes ‘essentially new’ in a few months takes a stretch of the imagination. It’s hard to forget SOPA and Godaddy’s full support of the bill before everyone on the Internet voiced their opinion about it. At any rate I’m relieved that I all ready migrated my sites off of Media Temple earlier this year and by chance remain a non-customer of GoDaddy.
Conditional comments have allowed us to serve CSS for a specific version of Internet Explorer for years now and they are still widely popular. I’m going to discuss why I think people are still using them and try to convince you that it’s safe to start building your projects without them.
Even Microsoft has abandoned support for conditional comments. I assume many developers still use them primarily because we’re so used to having them as a crutch to fall back on when things aren’t looking right in that browser. We’ve developed workflows around fixing things for Internet Explorer and using conditional comments is a dead simple approach to target specific versions of that browser everyone loves to hate; and it works really well. It’s also an easy technique to explain to other developers that need to maintain or contribute to your code, but aren’t experts at CSS. Another reason is that they’re wildly popular and included in many frameworks that many developers use to start their projects, like Twitter Bootstrap and HTML5 Boilerplate.
Subsequently they’re also used in websites that get a lot of traffic from HTML and CSS developers and these are the kind of folks that like to look under the hood and see how others developers are writing code. A List Apart is one such example that I imagine a lot of developers have taken a peak at.
What you’ll find at the top is the industry standard, conditional comments. The site includes 5 separate conditional comments for IE yet only use one of those selectors in their CSS a total number of one time. The surprising part is that it’s not for IE7 or IE8, but actually for IE9. Many developers see this code and will look to it as an example, but I don’t think this is the right approach. Especially since the browser landscape is changing so much more quickly now than it did just a few years ago.
Popularity and old habits aren’t the best ways to approach building a website though. We can get away from this pattern by using feature detection libraries like Modernizr to target browsers lacking specific features rather than a few very specific Microsoft browsers.
If you’re writing HTML5 markup and not using Modernizr yet and you are supporting older versions of IE, then you’re most likely using the HTML5 shim nested in a conditional comment so other browsers don’t download and run the script. At any rate you don’t need to include both as Modernizr includes the shim and smartly serves it to browsers that don’t support HTML5 tags. I see people doing this though. It does this all without resorting to the non-standard conditional comments.
We can use this feature detection to target specific versions of IE that lack support for a specific CSS property and remove conditional comments altogether. The first step is to determining what browsers you’re going to support. Do this by looking at your analytics to determine what browsers your users are viewing your site on. Then see what features those browsers are unable to support (can I use is great for this) and use those non-supported features to write targeted CSS. For IE 7 and less, box-sizing isn’t supported and since that’s something I want to use in my development, I can target IE7 by using a no-boxsizing CSS selector all without ever resorting to a conditional comment. For IE8 I use the mediaqueries selector, because I generally write up a desktop specific stylesheet for browsers that don’t support media queries.
The selectors you choose to use is up to you, but I recommend using feature detection as a way to move forward and letting go of a relic of the past.
Team Sass Design goes at with a sharp new look for sass-lang.com. Overall it’s a bit less in-your-face sassy, but it’s refreshing and those glasses are brilliant.
Type specimen No. 1 from Rosetta. Like all the fonts in their collection, it’s super nice. Free for the cost of shipping or the PDF is available for download.
#noparents is more than an emotionally charged hashtag to express your individuality and independence as an angsty teenager. Turns out it makes a lot of sense when writing CSS, too.
Jonathan Snook also talks about this in his book, which I recommend you check out if you’re a CSS developer.
Beautiful.
Services like typekit, fontdeck, and the new Webfonts by H&FJ give web designers options we didn’t have a few years ago — which is great, but it slows down the web.
I hope additional services and the competition between providers will help make web fonts even better and more performant in the future. However, if you care about performance today you should use your best judgement when adding fonts to your web design project, as they come at the cost of your website’s perceived performance and download time by creating additional network requests and bulking up the overall size of your website — which can have a significant impact on mobile website’s performance.
One option I’ve used to increase performance on smaller screened devices when building responsive sites is simply not serving the web fonts to those devices. This makes sense if your project values performance over maintaining a consistent typographical look on both your mobile and desktop sites. It’s not for everyone, but I’ve worked on some projects where there were so many assets being loaded, it just made sense to cut the fonts out to help speed up the site.
You should already be smartly not including styles and weights you’re not going to use, like excluding an italic variant if your using that font just for headings.
So assuming you want to load some fonts conditionally based on screen size, you might initially think of including them through a media query like so:
( media min-width: 620px ) {
@font-face {
font-family: "goudy-oldstyle";
url('webfonts/goudy.woff') format('woff')
}
html { font-family: "goudy-oldstyle", ... ; }
}
While this works for loading fonts from your own server, if you’re using a service like typekit it’s not so simple. This is because typekit requires the fonts be loaded from it’s servers and it’s API accessed via a JavaScript call in the head of your document.
To work around this you can check the width (or some other relavant property) of the browser viewport in the head of the document and then use document.write to load the typekit scripts if your condition has been met. In the head of the document within a “<script>” tag you would want to do something like this:
if ( window.innerWidth > 600 ) {
document.write('<script type="text/javascript" src="//use.typekit.net/your_key.js"?><\/script><script>try{Typekit.load();}catch(e){}<\/script>')
}
The value “600” is arbitrary, but would be the width in pixels of the browser width you’re trying to target. You would want to replace “//use.typekit.net/your_key.js” with your own typekit account key. Again, this technique isn’t for everyone, but it’s a simple way of saving resources if serving fonts isn’t essential for your mobile users.
These are fun and make the hamburger icon just a bit more bearable.
Looks like a great concept for improving performance by reducing document reflows.
A Web where you cannot cut and paste text; where your browser can’t “Save As…” an image; where the “allowed” uses of saved files are monitored beyond the browser; where JavaScript is sealed away in opaque tombs; and maybe even where we can no longer effectively “View Source” on some sites, is a very different Web from the one we have today. It’s a Web where user agents—browsers—must navigate a nest of enforced duties every time they visit a page. It’s a place where the next Tim Berners-Lee or Mozilla, if they were building a new browser from scratch, couldn’t just look up the details of all the “Web” technologies. They’d have to negotiate and sign compliance agreements with a raft of DRM providers just to be fully standards-compliant and interoperable.
Really surprised (and concerned) that DRM seems to be working its way into W3C proposals.
Actually, there’s one hack that was pretty cool. As mentioned, the original browser parsed and then drew to the screen character by character. Which basically means you see the browser draw, quite quickly, but still very noticeably, each character to the screen,. We wanted to emulate this, as it is as much a part of the original experience as the monochrome screen, or monospace font used.
Our original idea was to use CSS animations for this. But, this would require wrapping every individual character in a span element, then showing each character one by one.
Then in most likely a caffeine fuelled brainstorm, we came up with the idea of covering the document with a black, opaque canvas, then repeatedly erasing a rectangle the size of a character column by column, line by line.
It’s a really nice touch: Launch the Line Mode Browser
It was clear from the start that Works That Work would be a much more ambitious project: not only would it stretch across multiple platforms (online, eBook, PDF and print), but its content would also be available in various configurations.
Ambitious and well executed.
Some of the most useful yet little-known JavaScript tricks for manipulating CSS transitions and animations are the DOM events they fire. Like: animationend, animationstart, and animationiteration for animations and transitionend for transitions. You might guess what they do. These animation events fire when the animation on an element ends, starts, or completes one iteration, respectively.
The old hack of using window.scrollTo to hide the URL bar doesn’t work anymore; therefore there is no way to hide the URL bar or toolbar without user’s intervention scrolling the page.
That’s probably a good thing.