HTML5: Oktober 2014

Freitag, 31. Oktober 2014

Taking Control of the CSS/JS that WordPress Plugins Load

CSS-Tricks

Taking Control of the CSS/JS that WordPress Plugins Load

The other day on ShopTalk a question we got led us down a short tangent on WordPress plugins, the resources they load, and what that would look like in a perfect world. I ended up writing up some thoughts on it and getting some feedback. I think it came to a somewhat satisfying conclusion so I figured I write it up.

How Some Plugins Work Now

Let's take a real-world example. The WP-Polls plugin. I think it's a nice plugin. Does a good job with polls. I use it here on CSS-Tricks.

To put those polls on your site, it needs some JavaScript to handle the functionality (i.e. voting and seeing results without a page refresh) and CSS to style the poll widget (the results bars and whatnot).

The way that it adds that CSS is by injecting a stylesheet via the wp_head() hook, putting this in the <head>:

<link rel='stylesheet' id='wp-polls-css'  href='http://example.com/wp-content/plugins/wp-polls/polls-css.css?ver=2.67' type='text/css' media='all' />

The way it adds that JavaScript is by injecting a script via the wp_footer() hook, putting this near the bottom of the document:

<script type='text/javascript' src='http://example.com/wp-content/plugins/wp-polls/polls-js.js?ver=2.67'></script>

That makes sense. That's what they need to do to make this plugin work. Plugin authors need to make sure their plugins are easy to use and work.

As a performance-concerned developer, I want to concatenate scripts and styles.

Now we have these two single-purpose resources being loaded on the page. When you look into web performance and how to make websites faster, some of the first advice you hear is to concatenate resources. Very good rule of thumb: the less resources a website needs to load, the faster it will be.

Concatenating resources isn't some obscure thing only the most elite websites need to worry about. It's an every website problem. People have tackled this problem in a million ways. CSS sprites were all about concatenating image resources. Icon fonts and SVG sprites are solving that same problem. CSS preprocessors help you concatenate your stylesheets. The Rails Asset Pipeline helps you concatenate resources. There are Grunt and Gulp plugins galore that are designed for this.

But we're in WordPress land here, so we solutions for that.

Should plugins themselves help?

The first idea I thought of was that plugins should allow us to dequeue anything they enqueue from UI they add to the plugin itself. Even go so far as to provide the resources they would have loaded for you in a textarea for easy copy-and-pasting into your own system.

I now think that was a little misguided. It would take a major movement in the WordPress plugins world to get this going. Even if that happened, that's a lot of duplicate effort, and this issue can be handled more efficiently.

Solution #1: Use a Plugin

The plugin MinQueue offers a solution I like. It doesn't do anything automatically, it allows you to configure what resources you want concatenated and in what order.

With the plugin active, in the Admin Bar on the front end you'll see a little helper link you can click.

In our demo, I know I want to concatenate our theme's CSS and WP-Polls CSS together. So I take those names from the helper and put them into a new "queue" in the plugin settings.

Now neither of those CSS files loads individually anymore. MinQueue creates a combined (and cached) version and serves that:

<link rel='stylesheet' id='minqueue-117c22aa-ebc80003-css'  href='http://example.com/wp-content/uploads/minqueue-cache/minqueue-117c22aa-ebc80003.css' type='text/css' media='all' />

You can create multiple "queues", which gives you a good amount of control. For instance, perhaps a subsection of your site loads different resources, those could be combined separately if you wish, it's not required you concatenate them with the main group.

Note that this means you'll need to enqueue your theme's stylesheet, but that's pretty easy.

Also note the popular W3 Total Cache does concatenation too, but I find it a bit more confusing. You add stylesheets via URL's and it seems a bit more basic and easy to break.

Solution #2: Manually dequeue assets and concatenate yourself

Plugins that add resources do it through wp_enqueue_script and wp_enqueue style. You can dig through their plugin code and find where they do that, so you can see what name they applied when they did it. Then, in your own theme's functions.php file (or custom functionality plugin), you dequeue them.

Justin Tadlock has a post about this can you can read. Simple example of dequeuing one stylesheet:

add_action('wp_print_styles', 'my_deregister_styles', 100);

function my_deregister_styles() {
  wp_deregister_style('name-of-style');
}

Now it's on you to go find that resource and concatenate it into the CSS you are still loading on the page yourself. Perhaps you're using a CSS preprocessor and you can @import it. Perhaps you're using a task running like Grunt can can add it to the list to files to go get and concatenate. Or go fully manual and just copy and paste it's contents into your own stylesheet (just be aware if you do this you don't get updates when the plugin updates).

Solution #3: Use a plugin to dequeue assets and concatenate yourself

While I'm capable of digging through a plugin's code to find instances of enqueuing resources, that doesn't seem like a fantastic approach to me. I'd rather do it programmatically, making it easier and reducing human error.

During the earlier discussions happening around this, Nate Wright of Theme of the Crop cooked up a brand new plugin for this called Asset Queue Manager. It has a UI you use (from the front end) for you to easily dequeue assets.

From the front end of the site, you click a link in the Admin Bar to reveal a dropdown of all the enqueued assets on that page.

There is a button for dequeuing that asset. The plugin will keep that asset dequeued until you say otherwise. Now again it's on you to go concatenate that into your stylesheets however you wish. There is another button there that links directly to the resource, making it super easy to find. Pretty cool!

Conclusion

There are plenty of ways to wrangle control of the CSS and JavaScript that WordPress plugins can load. You can and should do this, with the urgency increasing for each unconcatenated resource.

How many resources files of each type OK to load? One, Two or Three.

Taking Control of the CSS/JS that WordPress Plugins Load is a post from CSS-Tricks

more info...

Donnerstag, 30. Oktober 2014

The Specificity Graph

CSS-Tricks

The Specificity Graph

Harry Roberts, on charting CSS selector specificity across entire codebases:

A spiky graph is a bad graph.

I would think if you went 100% on a methodology that encouraged class names for everything, your chart would be damn near flat. I wonder if that's a worthy goal. Something to draw a line in the sand on, for the good of a project.

Direct Link to Article — Permalink

The Specificity Graph is a post from CSS-Tricks

more info...

Dienstag, 28. Oktober 2014

Shape Blobbing in CSS

CSS-Tricks

Shape Blobbing in CSS

We just covered shape morphing in SVG, where shapes change from one to another. Let's look at shapes that blob into each other! You know, that gooey squishy blobby effect like droplets of mercury on a surface.

I'm not sure who first discovered this was possible on the web, but the first place I ever saw it was a demo by Lucas Bebber:

See the Pen Gooey Pagination by Lucas Bebber (@lbebber) on CodePen.

And then again by Felix Hornoiu (low framerate GIF for web practicality):

The trick is fairly simple, use filter to BOTH add blur and contrast to an element

The blur obvious makes the element blurry, the contrast fights against the blur, preferring stark changes in color. If you contrast enough, you're left with a (fairly) sharp looking shape again.

The fancy parts comes from the fact that when two blurred (yet forced to look non-blurry) elements come near each other, their would-be blurs create enough would-be color contrast that the shapes actually appear to connect.

I find it easier to get working if you blur the shapes but add contrast to the whole area. Like:

.stage {
  /* must be explicit, for contrast to work */
  background: white;
  
  /* weirdness happens when edges hit, also consider hiding overflow */
  padding: 30px;
  
  -webkit-filter: contrast(20);
  filter: contrast(20);
}
.dot {
  border-radius: 50%;
  width: 50px;
  height: 50px;

  /* needs to be very contrasty color. E.g. light gray on white won't work */
  background: black;

  -webkit-filter: blur(15px);
  filter: blur(15px);
}

And then the fun happens when you add animation to blob those suckers all around. Here's a demo where you can play with the values, including brightness which affects the blur:

See the Pen Blobbing Playground by Chris Coyier (@chriscoyier) on CodePen.

Browser Support

Not just WebKit/Blink anymore! Firefox 35 will be supporting filters without any flag or anything. Aurora, their beta-beta, is in v35 right now and I popped it open in that and it works great.

So... current Chrome / Safari / Opera / Firefox / iOS / Android. Not bad. Just no IE.

Predictions of Exclaimed Things

It's not practical!!! Go to bed.

It makes my fan spin like crazy!!! Yeah my demo with tons of elements interacting makes my CPU pretty busy as well. The more chill demos with just two circles bumping into each other are fine though. Use decision making skills.

There are better ways to do this!!! Awesome.

Shape Blobbing in CSS is a post from CSS-Tricks

more info...

Montag, 27. Oktober 2014

Datalists for Different Input Types

CSS-Tricks

Datalists for Different Input Types

I saw an HTML5 date input the other day, which had the dropdown arrow on the right, which I've grown accustom to clicking to reveal a calendar datepicker in which to choose a date.

Typically, that looks like this:

I've seen variations on this before, like when you use a week input instead of date:

But I hadn't seen this before:

Turns out that's what you get when you apply a <datalist> to an input of that type! Who knew!

The format is like this:

<input type="date" list="days">
<datalist id="days">
  <option label="Chris' Birthday">1980-08-26</option>
  <option label="Apollo 11 Moon Landing">1969-07-20</option>
  <option label="DDay">1944-06-06</option>
</datalist>

The values for each of the options just need to be valid values for the input, otherwise they just don't show up.

Browser Support

As far as I understand it, the spec doesn't dictate any particular UI requirements for HTML5 input types. If a browser wants to build a datepicker thingy, great, but not doing it doesn't violate the spec. Thus, this additional UI nicety also isn't required. I just mention that because lack of "support" here doesn't indicate a browser is doing a bad job.

These fancy datalist inputs appear to largely be a Blink thing.

A quick check around the latest version of browsers, just testing input type="date" with a datalist:

Chrome 38 = works

Opera 23 = works

Safari 8.0 = doesn't support input type="date"

Firefox 32 = doesn't support input type="date"

Internet Explorer 11 = doesn't support input type="date"

iOS 8.1 = date works / datalist doesn't (see screenshot)

Android 5 = works (see screenshot)

Opera Mobile 11.5 = date works / datalist doesn't

"Support" again meaning "doesn't do anything special for" - but falls back to a useable text input.

iOS 8.1 - you get the date controls but nothing special for the datalist.

Here's the rub with features like this. If it's just a little nicety you can provide, but not crucial, just use it and think of it as progressive enhancement. If it's totally vital that all users to your site need UI for choosing recommended options and you support browsers that don't support this, you'll need either a polyfill or a custom solution.

Other Types

Date doesn't get to have all the fun! While putting this together, I ran across Eiji Kitamura's comprehensive test page for all this. It's not just text and date inputs that datalist can work for, it's all the variety of date inputs as well as color and range!

type="range"

Opera 23. Shows little ticks, dragging across them, the rubber kinda "sticks" to each point as you pass.

type="color"

A little dangerous on Opera Mobile 11.5. It supports the datalist, but ONLY those in the datalist, there is no way to activate a more generic color picker or manually type in another color.

Datalists for Different Input Types is a post from CSS-Tricks

more info...

Samstag, 25. Oktober 2014

How SVG Shape Morphing Works

CSS-Tricks

How SVG Shape Morphing Works

While animating SVG with CSS is easy and comfortable, CSS can't animate all the SVG properties that are possible to animate. For instance, all the properties that define the actual shape of the elements aren't possible to change or animate in CSS. You can animate them through SMIL though. Sara Soueidan covers this in her guide to SMIL here on CSS-Tricks, but I thought I would shine a light on this particular ability.

Most important fact: the shapes need to have the same number of points

Otherwise, the animation will just fail. The shape won't disappear or anything, but it won't animate.

It's not extremely obvious how many points a shape has just by looking at the d (in the case of a path) or points attribute (in the case of a polygon) so you may just need to start in a vector editor program with a single shape and work from there.

1. Start with the most complicated shape

In this demo I'm going to morph from a star to a check. The star is more complex:

Save a copy of that SVG, then make a new copy for the next shape.

2. Make the next shape with those same points.

Drag the points around until you have your next shape.

3. Use the starting shape on the SVG shape element itself

<svg viewBox="0 0 194.6 185.1">

  <polygon fill="#FFD41D" points=" ... shape 1 points ... ">

  </polygon>

</svg>

4. Add an animation element that animates to the next shape

<svg viewBox="0 0 194.6 185.1">

  <polygon fill="#FFD41D" points=" ... shape 1 points ... ">

    <animate attributeName="points" dur="500ms" to=" ... shape 2 points ... />

  </polygon>

</svg>

That animation will run immediately, so we'll need to fix that up a bit.

5. Trigger the animations as needed

SMIL has the ability to handle interactions like clicks and hovers, so long as all that happens within the SVG itself. For instance, you could begin the animation when it's clicked on, like:

<polygon id="shape" points=" ... shape 1 points ... ">

  <animate begin="shape.click" attributeName="points" dur="500ms" to=" ... shape 2 points ... />

</polygon>

That's pretty neat, but it's a little limiting since you can only handle clicks from other elements right in that same SVG. Perhaps this SVG is just a part of a <button> and you want to run the animation on any click on that button.

First give the animation an ID so we can find it with JavaScript, and then prevent it from running with:

<animate id="animation-to-check" begin="indefinite" ... />

Now you can get a reference to that animation and kick if off how you like:

animationToCheck = document.getElementById("animation-to-check");

// run this on a click or whenever you want
animationToCheck.beginElement();

Demo

This demo actually has four animations. One to morph the star to a check, one to change the color, and then both those same animations in reverse. Clicking the button checks the state of the button and then runs the appropriate ones.

See the Pen Shape Morph Button by Chris Coyier (@chriscoyier) on CodePen.

Would be pretty cool for charts, like this old Raphael demo:

How SVG Shape Morphing Works is a post from CSS-Tricks

more info...

Freitag, 24. Oktober 2014

Lobotomized Owls

CSS-Tricks

Lobotomized Owls

I had a post in my drafts for CSS-Tricks recently I called "Removing the Space from the Bottom of Modules". It's all about that tricky situation where you want even padding all the way around some elements to visually separate them. But elements inside will also need bottom margins, and that might lead to extra space along the bottom where that margin hits the padding.

Apparently I'm getting old and losing my mind, because I've already written about it. But I didn't come to any stunning conclusion in that article. The best I came up with was a kinda gross compound selector that I don't even want to talk about.

Heydon Pickering does have a stunning conclusion for this issue:

* + * {
  margin-top: 1.5em;
}

I'd definitely try that in a new project. It does make me think that future CSS could help us here though. Perhaps specifying that a particular edge of padding was allowed to collapse into margin?

Direct Link to Article — Permalink

Lobotomized Owls is a post from CSS-Tricks

more info...

Donnerstag, 23. Oktober 2014

Sponsor: Hack Reactor’s Immersive Remote Beta Course

CSS-Tricks

Sponsor: Hack Reactor’s Immersive Remote Beta Course

Hack Reactor's Coding School is accepting applications for its next online immersive course, Remote Beta. Their team of exceptional instructors and staff work towards a two-fold mission of empowering people and transforming education through rapid-iteration teaching. Students build the skills and confidence they need to graduate as mid-to-senior level engineers and work for top tech companies in both backend and front end tasks.

Apply today for an upcoming onsite or online cohort and be on your way to becoming an engineer in 12 immersive weeks.

Two anecdotes from me:

I just watched the documentary Ivory Tower and it's a pretty interesting look at the state of universities. One thing is for sure: education is changing.

I now have two personal friends who have transformed their career through coding schools.

Direct Link to Article — Permalink

Sponsor: Hack Reactor’s Immersive Remote Beta Course is a post from CSS-Tricks

more info...

Mittwoch, 22. Oktober 2014

CSS-Tricks Chronicle XIX

CSS-Tricks

CSS-Tricks Chronicle XIX

Today I hop on a plane to Norway for the Trondheim Developer Conference. First time there. Can't wait. The conference isn't until Monday, but I suck at traveling to Europe. I'm a big baby about jet lag, so I like lots of extra time to acclimate.

I was on Craig McKeachie's Front-End Developer Podcast in the episode How to use custom fonts and @font-face.

I also got to be on Real Thread's Local Masters podcast.

Things are going well at CodePen. We just recently hit 2,000,000 Pens created. We've been doing a bunch of maintenance work, a lot of it is kinda unsexy behind the scenes stuff, but I appreciate work like that more and more the longer we're around.

One of the more public-facing features I worked on was converting the layout of the editors to use flexbox throughout. That made it easier to offer resizeable editors, a hotly requested featured since we launched.

We've been continuing our podcast series CodePen Radio with recent episodes including Responsibility and Churn.

One cool thing that I'm sure some of you can make us of: we're giving away 2 weeks of PRO for free. Just click a button to activate yours.

So much more to come!

At the end of August I was back at Hilton Head Health trying to keep healthy lifestyle stuff in check. I left right on September 1st and spent that entire month eating vegan. It wasn't life changing, but I enjoyed it, and hit my all time low weight. Sadly I've come back up a little, so I need to watch it.

Dave and I are still enjoying the heck out of doing ShopTalk. We'll have episodes every week until around Christmas where we'll probably take a few weeks off.

Don't miss Web Standards Southern Gentlemen in the last RAPIDFIRE.

Since I last chronicled, I was at BlendConf which was a huge and wonderful conference. I met a bunch of folks there that I've been wanting to meet. I was vegan at the time and we scouted out the restaurant Bean to eat at, which I loved so much we went back twice. I had also just set up a turntable at home my friend gave me, and so went record shopping at Lunchbox which was pretty sweet. I love the idea of hitting up local record stores in cities I visit.

I also was at An Event Apart Austin, which was super good even as compared to other AEA's, which are always good. I feel like I'm always treated very well as a speaker at conferences, but I extra appreciate the AEA organizer clan and how welcome they make me feel. Shout Jeffrey, Marcy, Toby, Steven and all! Some new very important things clicked for me listening to Mat Marquis and talking with Jason Grigsby about responsive images. Particularly this mostly-use-srcset business.

At BlendConf I met Nicole (and Max) Fenton and at AEA Austin I met Kate Kiefer Lee - the authors of Nicely Said. I look up to both of them tremendously for being so damn good at writing about writing.

A few weeks ago I was down in Key West (another first!) for a wedding. The whole Team CodePen was there, because it was our friend Ryan's wedding. We all worked together back in the Wufoo days and I love it that we're all still friends. I went pretty Florida Man.

I spent some time cleaning up the email that gets sent out around here. If you don't get it yet, sign up here. It's just all the blog posts that get published here but in a nice clean format right in your inbox.

Just plugging away here on CSS-Tricks as well.

Behind the scenes, I'm about to cut over to a larger, dedicated database server which I hope will increase the server side speed around here which has been a might slow.

If you're a member of the forums, there are some new settings as part of your profile for when you wish to be emailed regarding @name notifications.

We tried a little chat widget in the forums area to see if people enjoyed realtime chat, but it just wasn't a good fit.

You might notice some new Wufoo ads on the site. They renewed their sponsorship here, which is awesome because obviously I'm a big fan. They are tinkering with some new design over there, so I got a sneak peak at some of that and I designed these new ads in that direction.

You may have also noticed I'm doing sponsored posts here and there on the site. I'm marking them as clearly as I can so you know what is sponsored and what isn't. If you're interested in that, check out Syndicate Ads.

As always I have ten million ideas for things to write about so I'll just keep on writing if you keep on reading.

CSS-Tricks Chronicle XIX is a post from CSS-Tricks

more info...

Dienstag, 21. Oktober 2014

Probably Don’t Base64 SVG

CSS-Tricks

Probably Don’t Base64 SVG

Perhaps you've heard of data URIs. It's a really nice way of including a resource that would have otherwise been a separate HTTP request. The format that you use in a data URI can vary. Essentially you just tell it what content type it is (e.g. image/png), semicolon, then the data of that file.

Like:

<img src='data: ... '>

or:

.bg {
  background: url('data: ... ');
}

For a raster image like a PNG, the data of that image needs to be in base64 format. I'm not a huge expert here, but as far as I understand, base64 is safe for use in something like HTML or CSS because it only uses 64 characters known to be safe in those formats.

On the left, the data of a PNG, which includes characters that have the potential to screw up HTML. On the right, that same image base64 encoded with all safe characters.

Probably better Stack Overflow answer by Dave Markle:

You never know - some protocols may interpret your binary data as control characters (like a modem), or your binary data could be screwed up because the underlying protocol might think that you've entered a special character combination (like how FTP translates line endings).

So to get around this, people encode the binary data into characters. Base64 is one of these types of encodings.

Base64 looks like gibberish, and we often associate gibberish with compression on the web. But this gibberish isn't compression, it's actually a bit bigger than the original because, to quote Jon Skeet on the same Stack Overflow thread:

It takes 4 characters per 3 bytes of data, plus potentially a bit of padding at the end.

I'm not sure how gzip factors into it though. But what I'm getting at here is how SVG factors into this.

You can use data URIs for SVG too.

<img src='data:image/svg+xml; ... '>

.bg {
  background: url('data:image/svg+xml; ... ');
}

For SVG, you don't have to convert the data into base64. Again, not an expert here, but I think the SVG syntax just doesn't have any crazy characters in it. It's just XML like HTML is, so it's safe to use in HTML.

You can leave the encoding in UTF-8, and drop the <svg> syntax right in there! Like this:

<img src='data:image/svg+xml;utf8,<svg ... > ... </svg>'>

.bg {
  background: url('data:image/svg+xml;utf8,<svg ...> ... </svg>');
}

So because we can do that, and we know that base64 often increases the size, might as well do that right? Yep. As a side benefit, the <svg> syntax left alone does gzip better, because it's far more repetitive than base64 is. Say you wanted two versions of an icon, one red, one yellow. You can use the same SVG syntax duplicated just change the fill color. Gzip will eat that for breakfast. Credit to Todd Parker for that tip, and that's also the approach of Grunticon, which data URI's SVG in UTF-8 into CSS.

A Test

To test this out, I downloaded three SVG icons from IcoMoon.

cog.svg - 1,026 bytes

play.svg - 399 bytes

replay.svg - 495 bytes

I ran them through SVGO just so they are nicely optimized and kinda ready for use as a data URI (whitespace removed, although I guess not strictly necessary).

cog.svg - 685 bytes

play.svg - 118 bytes

replay.svg - 212 bytes

Then I ran those through a base64 converter.

cog.svg - 916 bytes - 133% of the original size

play.svg - 160 bytes - 136% of the original size

replay.svg - 283 bytes - 134% of the original size

So that makes sense, right? If it's 4 characters for every 3 bytes, that's 133% bigger, with the variation coming from uneven lengths and thus padding.

Anyway, maybe this is all super obvious. But it just seems to me if you're going to use a data URI for SVG there is no reason to ever base64 it.

Props to Matt Flaschen for his email a few months ago that highlighted this issue for me.

Probably Don’t Base64 SVG is a post from CSS-Tricks

more info...

Montag, 20. Oktober 2014

SVG Artboard Sizing

CSS-Tricks

SVG Artboard Sizing

There are a couple of different (rational) approaches to SVG artboard sizing.

The term "Artboard" here is referring to that concept in Illustrator, basically the white drawing area you have for the document. Ultimately it refers to the viewBox in the actual SVG output. It matters very much for front end developers, because if there is no consistency, the positioning of the SVGs will always be a little one-off battle and really hurt the idea of SVG being a useful system.

I recently met developer Emma Arce at a conference who relayed a very interesting conversation between her team as they were attempting to standardize on something and get this right. Here's my take on the situation.

Approach #1: Make them all the exact same size

You'll probably be applying sizing through CSS, so size of the artboard doesn't matter much, but the dimensions should be identical. Here's what that looks like:

Advantages

Relative sizing. You control right in the design of the icon itself how it is sized compared to other icons. So if you size them all the same in CSS later, all the icons will maintain that size relationship and look good together.

If the right arrow icon was edge-to-edge, it might be too large in comparison to the tray icon below if sized the same in CSS.

Disadvantages

Directional alignment. Since there is an arbitrary amount of whitespace on any given side of any given icon, it's hard to align things to the edge of an icon or expect a consistent amount of space between an icon and adjacent element.

Depending on which icon is in use, there will be different amounts of space between whatever is adjacent.

Approach #2: Crop to edges

Again the actual "size" of the artboard doesn't matter since you'll likely be applying sizing through CSS anyway, but the artboard should meet the edge of the artwork on all sides. In Illustrator, it's an easy move:

Here's what that looks like:

Advantages

Alignment and positioning. If you want to position an icon in the upper right corner of an element, it's going to go there and look nice and aligned. There won't be some weird arbitrary amount of whitespace to compensate for.

Disadvantages

Sizing inconsistency. All the icons have different aspect ratios now. That's not a huge problem for complexity, because you can still size them with CSS with a fixed width/height and they will center within that area (assuming a default preserveAspectRatio). But, that will affect their sizing. The closer any given icons aspect ratio is to a square, the bigger it will seem (it will fill the space given). Taller or wider icons will need to shrink to fit in the space and appear smaller. So consistant and other-icon-relative sizing is harder.

Winner?

I'm afraid I just can't pick one. I really like the positioning consistency of cropped icons, but the inconsistent sizing can drive me nuts. And I'm sure it would work exactly the opposite if I changed.

Other Considerations

Consistency through boxes: If in every single instance of using SVG you are placing the icon within a visually-defined box, alignment becomes a non-issue since you can align the boxes and they will look fine.

You can always do one-offs: Let's say you have one really long and skinny arrow shape. You can always do some special CSS just for that one. I wouldn't change a whole system based on a handful of outliers. This is about the system as a whole.

SVG Artboard Sizing is a post from CSS-Tricks

more info...

Freitag, 17. Oktober 2014

How To Get Started in Web Design

CSS-Tricks

How To Get Started in Web Design

Here's an answer to how to get started building websites that I fully endorse and isn't vague. This is going to cost a little money, just like learning to play the guitar requires buying a guitar and some accessories. This is also going to require a little time and mostly isn't directly about the coding itself. It's about getting you to a place where you're doing web design for real and you can't help but learn!

I'm going to mention specific company names without linking to them, just to be clear this article isn't an affiliate marketing thing. Googling them should bring them right up.

1. Buy a domain name

Buy a domain name from Hover. Buy something useful, like your-name.com or buisness-idea.com. Or buy something silly that you will actually do something with.

2. Buy some web hosting

Buy the cheapest hosting plan at Media Temple. Tell them you already have a domain. I think it's preferable to separate your domain buying company and your hosting company¹.

Once it goes through, you'll get a service activation email.

3. Point the nameservers of your new domain to your new hosting

The link in that service activation email will take you to Media Temple's guide with all kinds of information in it you need to finish setting this up. Under the DNS section, you'll see Media Temples nameservers. We need to change the nameservers for our domain over on Hover so that the domain properly points over to Media Temple.

When we're changing these nameservers, we're changing DNS information. Whenever you change DNS information there might be some time involved. This information needs to propagate it's way to routers all around the world that power the internet. That's how the internet works!

Just know that it might take a little time for this to start working (for your website we're about to put up to actually show up).

4. Get some FTP Software

FTP is for transferring files. We're going to use it to transfer files from your computer to the web hosting server computer. We'll talk about those files in a minute, but for now we're just setting it up.

If you're on a Mac, get Coda. Coda is an FTP client, but it's also a code editor, and when you're just starting out as you are, that's mighty convenient.

I'm not as familiar with PC software, but googling "FTP client for PC" brings up plenty of stuff. I'm sure there are some nice ones.

5. FTP into your Web Hosting

That Media Temple guide area will also include FTP information, meaning a:

hostname

username

password

Enter the FTP credentials from the email into the FTP client (create a new Site).

Connect to the server.

6. Add the Domain to the Hosting

When we bought the hosting, we told them we had our own domain. So let's set that up in there. This will certainly vary from hosting company to hosting company. Here's how it worked on Media Temple:

7. Find the web root through FTP on your server

There is always a particular folder on your server that is the "web root". For example, if you put an index.html file there, that is what displays when you go to your-name.com, or if you make a folder there called "cool" and put an index.html file in that folder, that is what displays when you go to your-name.com/cool/

8. FEEL THE POWER COURSE THROUGH YOUR VEINS

Whatever you put in that web root is live on the internet!

If you put an index.html file there, that's what shows when you go to your domain in a web browser.

9. Go find a nice template to download, and upload it to your server

Go download a template. Google something like "Free HTML templates", or even find a paid one you like and buy that. There is nothing wrong with templates. Eventually you'll be good enough to not need one or make educated choices about when to use one, but for now, it's best to kick things off with a nice looking site that you can tweak and make yours. Kinda like how it's more fun (and easier to get better) learning an instrument by playing a song you like rather than learning scales.

10. Congrats

You've now built a website. You absolutely have the ability to edit those files and make things happen. Without any further training at all, you are smart enough to find words that you want to change and change them in HTML and see the results. You are smart enough to find color values in CSS and change them to see the results. You are smart enough to figure out the connections between HTML elements and CSS selectors.

That's how the vast majority of web designers started out. I know I did.

Now, everything else you learn you can learn in context of a actual site you're working on. You can imagine how the things you learn might apply to your real website. And the more you do it, the better you get. Wanna get better? Just build websites!

Alternatives

I wanted to be very specific in this article. Nothing vauge. But that doesn't mean this is the only path. Let's similar but alternative paths in the comments.

Leveling Up

After feeling pretty comfortable with this process, there are lots of ways to level up. Some of those might include

Install a CMS like WordPress (video series), Kirby, Perch, Ghost, or the like.

Working on your design skills in general, by designing more.

Learning some jQuery (video series) to add advanced functionality and interaction.

Learning about a version control system like Git.

Learn about running a web design business effectively.

There are a million ways to get better. You'll likely discover most of them organically.

¹ - For example, if you buy your domain from your hosting company, and then decide to change hosting companies, the hosting company is disincentivized to help you with your domain.

How To Get Started in Web Design is a post from CSS-Tricks

more info...

Donnerstag, 16. Oktober 2014

Sponsor: Creative Market – October Big Bundle

CSS-Tricks

Sponsor: Creative Market – October Big Bundle

It's always great to have a personal collection of design resources you know that you can use for whatever you like at your fingertips. Vectors flourishes and illustrations, photos, textures, patterns, fonts, layouts, all that good stuff.

No better place to stock up than Creative Market. This week, they have put together a Big Bundle of their best products. From graphics and fonts to photos and Photoshop actions. For only $39, you can fill up your designer's toolkit with 105 resources. This will only be available until October 21st, so be sure to grab it before it's too late.

Direct Link to Article — Permalink

Sponsor: Creative Market – October Big Bundle is a post from CSS-Tricks

more info...

Freitag, 10. Oktober 2014

Donnerstag, 9. Oktober 2014

Intermediary Pages in a Site Hierarchy

CSS-Tricks

Intermediary Pages in a Site Hierarchy

I had a reader write in with an interesting question:

When one has multi-level navigation, do you think it crucial to have an actual page for the top-level item? For instance, About > Company, Founder, History.

There isn't really anything worth putting on the About page that wouldn't be on the three sub-pages. In the nav, should About just redirect to Company? Should there not be a Company page and its content be moved to About?

Any best practices you've found over the years?

I'm picturing this kind of thing:

And the issue is that "About" by itself isn't particularly useful. But it is useful as a grouping for the sub pages.

I would think the "About" link should be functional no matter what. It's just a matter of what to do with it.

Just make an intermediary page

Have the parent link:

http://website.com/about/

And the subpages:

http://website.com/about/company/

http://website.com/about/founder/


http://website.com/about/history/

They said there isn't anything "worth" putting on the About page, but that's just a matter of content wrangling. You could write some new content introducing the other content there. Or show some elaborate breadcrumbs encouraging them to go deeper. Or show some images or snippets from the sub pages. I'm sure you can think of something.

Redirect the intermediary page

Have:

http://website.com/about/

Redirect to:

http://website.com/about/company/

That way the URL stays nice and hierarchical and gives you the opportunity to create an About page alone in the future.

It might feel a little unexpected though, so it might be nice to offer some kind of sideways navigation. Seems like the kind of thing that could be tabbed:

Skip the hierarchy

If there is really no point to having a parent page, maybe the URL's should be clear that there isn't one.

http://website.com/about-company/

http://website.com/about-founder/


http://website.com/about-history/

And then use the redirect for the top-level navigation option.

Put them all on one page

Is there any value in separating them? You could go with a tabs design pattern with all on-page content. Or just make a long page, the web can handle it =).

The URL's could use hashes to go to the relevant place (or tab):

http://website.com/about/#company

http://website.com/about/#founder


http://website.com/about/#history

Best Practices

I'm not sure any one of these is any better than the other. I think the best practices here come in the form of don'ts:

Don't do it one way then change it to another next month. Cool URL's don't change.

Don't make your dropdown 100% reliant on JavaScript.

Don't make the About link not-actually-a-link just because you don't have this figure out yet. Link it to something or redirect it.

Have you all gone through this kind of thing before?

Intermediary Pages in a Site Hierarchy is a post from CSS-Tricks

more info...

Mittwoch, 8. Oktober 2014

Intermediary Pages in a Site Heirarchy

CSS-Tricks

Intermediary Pages in a Site Heirarchy

I had a reader write in with an interesting question:

When one has multi-level navigation, do you think it crucial to have an actual page for the top-level item? For instance, About > Company, Founder, History.

There isn't really anything worth putting on the About page that wouldn't be on the three sub-pages. In the nav, should About just redirect to Company? Should there not be a Company page and its content be moved to About?

Any best practices you've found over the years?

I'm picturing this kind of thing:

And the issue is that "About" by itself isn't particularly useful. But it is useful as a grouping for the sub pages.

I would think the "About" link should be functional no matter what. It's just a matter of what to do with it.

Just make an intermediary page

Have the parent link:

http://website.com/about/

And the subpages:

http://website.com/about/company/

http://website.com/about/founder/


http://website.com/about/history/

Redirect the intermediary page

Have:

http://website.com/about/

Redirect to:

http://website.com/about/company/

That way the URL stays nice and hierarchical and gives you the opportunity to create an About page alone in the future.

It might feel a little unexpected though, so it might be nice to offer some kind of sideways navigation. Seems like the kind of thing that could be tabbed:

Skip the hierarchy

If there is really no point to having a parent page, maybe the URL's should be clear that there isn't one.

http://website.com/about-company/

http://website.com/about-founder/


http://website.com/about-history/

And then use the redirect for the top-level navigation option.

Put them all on one page

Is there any value in separating them? You could go with a tabs design pattern with all on-page content. Or just make a long page, the web can handle it =).

The URL's could use hashes to go to the relevant place (or tab):

http://website.com/about/#company

http://website.com/about/#founder


http://website.com/about/#history

Best Practices

I'm not sure any one of these is any better than the other. I think the best practices here come in the form of don'ts:

Don't do it one way then change it to another next month. Cool URL's don't change.

Don't make your dropdown 100% reliant on JavaScript.

Don't make the About link not-actually-a-link just because you don't have this figure out yet. Link it to something or redirect it.

Have you all gone through this kind of thing before?

Intermediary Pages in a Site Heirarchy is a post from CSS-Tricks

more info...

Dienstag, 7. Oktober 2014

When users leave the search box empty…

CSS-Tricks

When users leave the search box empty…

The following is a guest post by Brin Wilson of WinningWP. Brin wrote to me wanting to do a little advertising for his site. I of course would happily accept that, but even better, since Brin is a tech writer anyway, why not write a guest post. That's always a win-win, and since he had a good idea anyway... take it away Brin!

If you're reading this, my guess is you're someone who cares about user experience. Like me, I'll bet you've probably spent countless hours trying to perfect every last detail of your site: from ensuring everything looks as it should on numerous different devices to creating either an entertaining and/or a helpful 404 page! But have you ever considered what happens when people search your site using the search functionality you've provided (i.e. usually a simple search box located somewhere near top of the page) but inadvertently hit enter without having actually typed anything?

Looking around the web, there appears to be no real consensus on what should happen in this particular edge-case scenario. Indeed, even the vast majority of industry-leading web design blogs seem to give no real consensus on what should or shouldn't happen!

Some Examples of Empty Searches

Reload / Redirect to Homepage

Familiar examples include: Web Designer Wall and the Team Treehouse Blog.

In these cases it's likely a WordPress theme that is 1) using default WordPress search and 2) missing a search.php template file (or the template is essentially the same as the homepage). So, the default homepage will be loaded with no search filter, meaning no filter is applied and you'll see whatever is normally on that page. It's not very clear what is going on.

Do Nothing

Familiar examples include: Codrops and Sitepoint.

The search box simply does nothing and/or closes itself.

Nothing Searched For / Nothing Found

Familiar examples include this very site, i.e. CSS-Tricks and, in fact, currently my own site WinningWP.

A default result appears quoting whatever the user has searched for (in this case nothing), and no results are shown. Kind of the opposite of the first examples where because there is no search filter, everything is found. But you're also on a clear search page so some action has happened.

Nothing Search For / Everything Found

Familiar examples include WebDesignerDepot and Code Tuts+.

A list of the most recent posts appears.

Completely Blank

Familiar examples include Smashing Magazine and Designmodo.

A completely blank list of search results appears.

Borked

Familiar examples include TheNextWeb and 1stWebdesigner.

The page just looks (or says) it's broken.

A better result

So what should be made to happen? Well, using the attribute 'required' would arguably go along way towards improving the user-experience in browsers that support this part of HTML5.

<input required type="search" name="q" id="q">

Thereby simply stopping the users with more-modern browsers from even being able to perform a blank search in the first place (as exemplified by the empty-search-box-behavior over on Speckboy Design Magazine). Here's a complete form example:

<form id="search-form" action="/search-results/">
  <div>
    <label for="q" id="search-label">
      Search
    </label>
    <input required aria-labelledby="search-label" id="q" type="search" name="q" class="search-field" value="">
    <input type="submit" value="Search" class="screen-reader">
  </div>
</form>

Editors note: I updated the search form here to use `required` because it seems like an easy/obvious improvement.

But what about non-supporting browsers? Is this good enough? And more to the point: can we do better?

Personally, I'm of the opinion that these types of empty search-box searches could perhaps best serve the user by being made to return a result that tells the user they've conducted a search but somehow or other managed to leave the search box empty. Perhaps in a kind of humorous-404-page style. Although, that said, I realize this might be going overboard – and would probably be a bit inappropriate for some websites.

Perhaps one of the nicest user-experiences (suggested by Chris after seeing the first draft of this post) could be provided by taking the user to a really well-designed full-page search experience: perhaps with the addition of some suggested popular search terms.

Or maybe the blank search is just too much of an edge case to worry about – especially on sites with relatively low traffic.

Any other suggestions for what best to return when a user leaves the search box empty? Is there some chance the user just clicked search on accident or had another assumption about what it would do? Thoughts?

When users leave the search box empty… is a post from CSS-Tricks

more info...