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:



  1. 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.

  2. 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








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








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








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








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 company1.


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:



  1. hostname

  2. username

  3. 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.




1 - 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








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








Freitag, 10. Oktober 2014

Sponsored: Stack – Task Management for Dev Teams




CSS-Tricks





Sponsored: Stack – Task Management for Dev Teams



Stack is a powerful new task management system for Devs and Designers. A simple and fully customizable tool that fits your workflow. Manage projects and communicate with your team hassle free and in real time.


I really like how Stack approaches this. It's exactly how I would have done it. There are projects - big buckets that tasks go into. Then each project has these columns that you can organize however you want. Each task is actually in a column. Could be different types of tasks or the state the task is in, whatever works. Then each task has it's own little world of people and conversation and todo's and stuff, if needed. So I might have a CSS-Tricks account, with a project for The Lodge, that has a column for Videos To Shoot, and each video is a task, and in the task I leave notes on what the plan is. Beautiful.


Free for 30 days, no credit card required to get started. Super simple pricing model after that ($5/month per user).


Direct Link to Article — Permalink



Sponsored: Stack – Task Management for Dev Teams is a post from CSS-Tricks