Interesting to see what the CSS sausagemakers consider failures of CSS.
I think the box-sizing choice has probably caused the most confusion and extra code over the years. Thankfully it's fixable.
Interesting to see what the CSS sausagemakers consider failures of CSS.
I think the box-sizing choice has probably caused the most confusion and extra code over the years. Thankfully it's fixable.
This is important because:
<img srcset>too, which is a close cousin and useful when swapping sources with media queries alone would suck.
If you're building an icon system for a site, you have some options. If you know the icons need to be raster images, then you'll likely be using CSS sprites. If the icons will be vector images (much more common these days), you have some options. Two of those options are using inline SVG and using icon fonts.
Sometimes these types of articles are cheezy and filled with fairly obvious stuff, but not when Louis Lazaris does them. All of these are pretty non-obvious.
There isn't just one way to animate SVG. There is the
<animate></animate> tag that goes right into the SVG code. There are libraries that help with it like Snap.svg or SVG.js. We're going to look at another way: using inline SVG (SVG code right inside HTML) and animating the parts right through CSS.
Everybody has a list of things they don't like: an appointment at the dentist, a traffic jam, or a canceled flight. When I was preparing my book, I wasn't surprised that a lot of designers and developers would add merge conflicts to this list without hesitation.
When using Git for version control, there is nothing to fear. Once you understand how merge conflicts work and how to deal with them, I'm sure you'll be able to cross them off this list.
The first thing that you should keep in mind is that you can always undo a merge and go back to the state before the conflict occurred. You're always able to undo and start fresh.
If you're coming from another version control system (e.g. Subversion) you might be traumatized: conflicts in Subversion have the (rightful) reputation of being incredibly complex and nasty. One reason for this is that Git, simply stated, works completely different in this regard than Subversion. As a consequence, Git is able to take care of most things during a merge - leaving you with comparatively simple scenarios to solve.
Also, a conflict will only ever handicap yourself. It will not bring your complete team to a halt or cripple your central repository. This is because, in Git, conflicts can only occur on a your local machine - and not on the server.
In Git, "merging" is the act of integrating another branch into your current working branch. You're taking changes from another context (that's what a branch effectively is: a context) and combine them with your current working files. Have a look at this introduction to branching if you're new to the concept in general.
A great thing about having Git as your version control system is that it makes merging extremely easy: in most cases, Git will figure out how to integrate new changes.
However, there's a handful of situations where you might have to step in and tell Git what to do. Most commonly, this is when there are changes to the same file on both branches. Even in this case, Git will most likely be able to figure it out on its own. But if two people changed the same lines in that same file, or if one person decided to delete it while the other person decided to modify it, Git simply cannot know what is correct. Git will then mark the file as having a conflict - which you'll have to solve before you can continue your work.
When faced with a merge conflict, the first step is to understand what happened. Did one of your colleagues edit the same file on the same lines as you? Did they delete a file that you modified? Did you both add a file with the same name?
Git will tell you that you have "unmerged paths" (which is just another way of telling you that you have one or more conflicts) via "git status":
Let's take an in-depth look on how to solve the most common case: when two changes affected the same file on the same lines.
Now is the time to have a look at the contents of the conflicted file. Literally open it in your code editor. Git is nice enough to mark the problematic area in the file by enclosing it in "<<<<<<< HEAD" and ">>>>>>> [other/branch/name]".
The contents after the first marker originate from your current working branch. After the angle brackets, Git tells us where (from which branch) the changes came from. A line with "=======" separates the two conflicting changes.
Our job is now to clean up these lines: when we're done, the file should look exactly as we want it to look. It can be necessary to consult the teammate who wrote the conflicting changes to decide which code is finally correct. Maybe it's yours, maybe it's theirs, or maybe a mixture between the two.
Opening the raw file in your editor and cleaning it up there is perfectly valid, but not very comfortable. Using a dedicated merge tool can make this job a great deal easier. You can configure your tool of choice using the "git config" command. Consult your tool's documentation for detailed instructions. Note that just because you have git installed doesn't mean you have a dedicated merge tool installed, these are separate, optional software tools.
Then, in case of a conflict, you can later invoke it by simply typing "git mergetool".
For this example, I've used Kaleidoscope on Mac:
The left and right panes stand for the conflicting changes; a far more elegant visualization than <<<<<<<" and ">>>>>>>".
You can now simply toggle which change shall be taken. The middle pane shows the resulting code; in good tools, you can even edit this further.
Now, after cleaning up the file with the final code, all that's left is to save it. To give Git a hint that you're done with this file, you should quit the merge tool to continue. Behind the scenes, this told Git to execute a "git add" command on the (now formerly) conflicted file. This marks the conflict as solved. Should you decide not to use a merge tool and instead clean up the file in your editor, you'll have to mark the file as resolved by hand (by executing "git add <filename>").
Finally, after resolving all conflicts, a merge conflict situation needs to be concluded by a regular commit.
As already said, you can return to the state before you started the merge at any time. This should give you the confidence that you can't break anything. On the command line, a simple "git merge --abort" will do this for you.
In case you've made a mistake while resolving a conflict and realize this only after completing the merge, you can still easily undo it: just roll back to the commit before the merge happened with "git reset --hard <commit-hash>" and start over again.
I've already mentioned it briefly: being equipped with good tools can make your life quite a bit easier. A proper merge tool will help you better understand a conflict scenario and make the right decision.
With all the safety nets in place that Git provides, there's really no need to be afraid of merge conflicts in any way. Once understood how they work and what your options are, you should be ready to merge like there's no tomorrow. Always keep in mind: you can't break anything!
Tobias modestly left out Tower as an excellent tool to help with merge conflicts. In fact one of the reasons I personally use Tower is because I like how it helps with merge conflicts.
It's very clear when you have a conflict:
And right-clicking on the conflicted file gives you some nice options:
So my process is usually:
Why can't I edit my tweets?! Twitter should allow that.
It's so simple right? CRUD apps (Create, Read, Update, and Delete) are app-building 101! What a gross oversight. But wait. Just as a fun nerdy little exercise, let's think about what a feature like this might take for the Twitter team. I don't work there or have any inside knowledge, so this is all hypothetical for the sake of understanding app development.
Mobile is the future. What wins mobile, wins the Internet. Right now, apps are winning and the web is losing.
We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors. They’re all just clients to the same services.
Perhaps it's not HTTP and back end web that is in danger, but it's the front end that's in danger.
For whatever reason I don't feel particularly worried for the web, even front end. It feels like a safe long-term bet.
I was on How to Hold a Pencil where Reuben Ingber and I chat about what it's like to be a beginner and where to go next.
I was on Pencil vs Pixel where Cesar Contreras and I talked about capturing ideas, motivation, and the future.
I was on the CDNify podcast as well.
Spring is breaking finally here in Wisconsin so it feels good to be back biking around town. I've been doing a good job at going to the gym and sticking with my training. We even trained outside today for the first time this year.
I'm just about to take off for a few weeks though. I'm headed down to Tampa, Florida to see some friends (I used to live there, back in the Wufoo days) and we're also getting together there as Team CodePen for an in-person sprint.
I leave from Florida and head up to North Carolina where I'm picking up a new camper trailer, the SylvanSport Go, which I'm pretty stoked about. It just so happens that MerleFest is going on at the same time so I'm going to meet some of my bluegrass buddies there for the weekend.
Then I need to high tail it back to Wisconsin because I have a flight down to Champaign, Illinois for the University of Illinois Web Conference where I get to keynote one of the days.
From there I fly to Columbia, South Carolina for ConvergeSE.
Then finally back home, where I only have a week before another big adventure. I'll save that for next time.
We've been hard at work at at CodePen. The new feature releases were a little slow for a while because we were buried in a huge one: Teams. It might seem like a simple thing, but it was anything but. We even talked about it a bit on the podcast.
Perhaps I haven't mentioned here? We're doing a new podcast over at CodePen, a kind of self-documentary of what it's like running a web software business. We call it CodePen Radio.
Taxes are another thing on my mind. They are due the 15th here in the US, and despite starting on them as early as I could, I'm cutting it down to the wire. It's crazy how late you can get needed documents to do it all properly. I think I'm just about done and it's a very painful year (mostly due to my own lack of planning in paying quarterlies). Gonna have to tighten the belt for a few months.
Me, for the last year or so: "
rem's are so cool! I'm gonna size everything with them, that way I can adjust the font-size on the root element and everything will scale with it!" It was a nice dream. And it wasn't a disaster. (more…)
The following is a guest post by Bear Travis, a Web Standards Engineer at Adobe. I'm a fan of how Adobe is pushing the web forward with new design capabilities, and doing it in a responsible way. CSS filters is a good example. They knew they were desired because Photoshop paved the way. They brought them to the web with a sensible syntax and they helped with both the spec and browser implementation. Now we're seeing them in stable browsers, and they are advocating use through responsible progressive enhancement. Hallelujah. Here's Bear with a tutorial about just that.
Latest Update: The plugin has been merged into WordPress core. So if you're running WordPress 4.4 or newer, you automatically have this.
Update: The plugin created in this article has moved here and now uses the more appropriate
srcset attribute. It's the official WordPress plugin of the Responsive Images Community Group and is endorsed by the WordPress Core Team. It sounds likely that this will make it into WordPress core eventually. Pretty cool!
The following post is guest co-authored by Tim Evko (@tevko). WordPress has a built-in media uploading system. When you upload an image, it automatically creates and saves different versions of it. Tim will show us how we can customize and exploit that ability to help us with responsive images in content.
This is worth linking up directly from here, as it's this very site the hacker was targeting. And then later, me.
Addy Osmani intros a Grunt task for removing unused CSS from your stylesheet before serving it.
While this is certainly a worthy goal, I look at the quotes from people who reduced their stylesheets by 3/4 or more and I'm like holy crap what kinda shop are you running over there?! I know "test, don't guess", but I'd guess that pretty close to 0% of the styles I write are unused. I'm sure HTML changes over time make a orphaned rule here and there, but I'd guess that is largely insignificant.
If you're going to do this, make sure you run it against lots (if not all) of your pages so you aren't removing selectors that are in use, just not on every page. I know I write minor styles all the time that make their way into the global stylesheet since that is cached and used anyway.
Say you have a table header (i.e.
<th></th>) of "Number of Howler Monkey Species by Country" and the data in the corresponding
<td></td> is like "3". That's an awkward mismatch of width.
This article "Shadow DOM" by Steven Wittens is only vaguely about the Shadow DOM. It's mostly about how awful everything is. HTML sucks, CSS sucks, the DOM sucks, SVG sucks, MathML sucks... I don't want to pick on Steven. He is, without a doubt, many (many) times smarter than I am and has well articulated points. Let's go wider.
I joined Jamie Ashbrook and Ben Briggs to talk about SVG and tooling and whatnot.
I chatted with Jen Simmons about flexbox and the general future of the web.
I redesigned this site a smidge. It's not a huge re-thinking or as big of an undertaking as v10 was, but it's different enough I'm going to call it v11.
Should they continue their studies or jump straight into the labour market? I usually tell them that ability trumps education and I don’t put much faith on the current raft of tech degrees. So I’d prefer to see three years of experience than three years of study.
That being said, I’ll also point out that University is about much more than just acquiring a skill. It’s a formative experience that will shape your attitudes for the rest of your life. It’s also a huge amount of fun...
Solid advice. If your life is a singular mission to become an incredible web worker, university may not be for you. But you'll (probably) grow up faster and have more fun at school.
The following is a guest post by Bryan Jones, the creator of CodeKit. I've been using CodeKit for a couple of years now and I've talked about it plenty. In my opinion it changed the game in front end development making it easy to use advanced tools that, while powerful, felt out of reach for many. Now CodeKit 2.0 it out, which has followed the landscape of front end development, bringing us more powerful tools that are tough to pull off otherwise. Bryan is going to introduce it, and I'll interject here and there to share my thoughts as I've been using 2.0 the last month or so.
It's a fun little soundbite to talk about how the web is responsive right out of the box. With no authored CSS at all, a website will flow to whatever screen width is available. If your site isn't responsive, you broke it.
Well that's almost true, but as Adam Morse says in this new project:
HTML is almost 100% responsive out of the box. These 115 bytes of css fix the 'almost' part.
Things like images and tables can have a set widths that would force a layout wider than a viewport. And of course, the meta tag.
And look at that TLD!
I've been a big proponent of icon fonts. Lots of sites really need a system for icons, and icon fonts offer a damn fine system. However, I think assuming you're good with IE 9+, using inline SVG and the
<use></use> element to reference an icon is a superior system.
First let's cover how it works.
The following is a guest post by Agop Shirinian. Agop ran into an interesting scenario where he needed an element to be scrollable in one direction, while allowing the overflow in the other direction. You'd think that's what overflow-x and overflow-y are for, but it's not that simple. I'll let Agop explain.
Chris Albrecht posted a question on StackOverflow about grids. Essentially: imagine you have an element with an unknown number of children. Each of those children is some percentage of the width of parent such that they make equal rows, like 25% wide each for four columns, 33.33% wide each for three columns, etc. The goal is to fill the space of this "grid" evenly. There are an unknown number of children, so let's say you were going with 25% and there were 7 children, that would be 4 in the first row and 3 in the second. Chris needed the final 3 to adjust in width to fill the space, rather than leaving the gap.
Imagine something like these Transformer Tabs as a widget in a fluid column in a responsive design. Depending on the browser window width, perhaps this design is either 4, 2, or 1 column wide. When it breaks from 4 to 2, the column probably temporarily gets wider than it was, even though the screen is narrower. It would be preferable when writing the media query logic for those tabs to consider how much space the widget has available rather than the entire window, which might be totally unrelated, especially when re-using this widget.
Jonathan Neal has some thoughts on how this might work, including the complicated bits you might not have thought about, like how a widgets contents might affect its parent container and cause an infinite loop.
Someone wrote in to me asking how to create a simple bar navigation with icons. This is a pretty simple layout thing that could be accomplished loads of different ways. List items as inline-block probably makes the most sense in general.
But I've been enjoying tinkering with flexbox, so I decided to toss it together with that, and it made for a pretty educational example I think.
Mark Otto "derping around with measuring CSS performance". Nothing looks particularly concerning to me, to the point where I would change how I do things. The most surprising numbers were in
background-color, but Paul Irish debunks that a bit.
There must be something in the water as Ben Frain has dug in a little bit on CSS performance as well. I like Ben's soundbite:
With CSS, architecture is outside the braces; performance is inside
It's worth noting that the
srcset attribute for the
img element has landed in Chromium (Chrome will get it in 34, Opera 21). Their example:
<img alt="A rad wolf." src="pic1x.jpg" srcset="pic1x.jpg 1x, pic2x.jpg 2x, pic4x.jpg 4x"> And:
Stay tuned for the
We needed this. The fight was arduous. The solution is good. Other browsers will be on the way. This is notable as once a browser supports something, the tendency is for it to always be supported. Plus now polyfills can be true polyfills.
Just as you can declare the background of an element to be a solid color in CSS, you can also declare that background to be a gradient. Using gradients declared in CSS, rather using an actual image file, is better for control and performance.
Gradients are typically one color that fades into another, but in CSS you can control every aspect of how that happens, from the direction to the colors (as many as you want) to where those color changes happen. Let's go through it all.
Bennett Feely has been doing a good job of showing people the glory of CSS blend modes. There are lots of designerly effects that we're used to seeing in static designs (thanks to Photoshop) that we don't see on the web much, with dynamic content. But that will change as CSS blend modes get more support. I'd like to look at the different ways of doing it, since it's not exactly cut and dry.
Responsive design is a pretty well defined strategy, but how you come at it can vary quite a bit. Brad Frost covers the angles.
emis relative to the font-size of its direct or nearest parent,
remis only relative to the html (root) font-size.
Jeremy tends to favor
em, because of the ability to control an area of a design. As in, scale the type in that specific area relatively. I have tended to like
rem because of the ability to scale type across the entire page easily, but I've gotten into issues where that wasn't good enough control so I could see moving back to
em for that reason.
You've probably seen this pattern going around. It's an input that appears as if it has placeholder text in it, but when you click/tap into that input, that text moves out of the way and allows you to type there. It's rather clever, I think. Brad Frost has a really good post on it, detailing the pros and cons and such.
The following is a guest post by Parker Bennett. While icon fonts are efficient and easy to use and scaleable and all that, one of the classic "strikes" against them is that the icon can only be one color. Parker has a brand new project that solves that issue in a simple and clever way. I'll let him introduce it for you.
I bet all of you have seen that little trick where an SVG path is animated to look like it's drawing itself. It's super cool. Jake Archibald pioneered the technique and has a super good interactive blog post on how it works. Brian Suda wrote about it on 24 Ways. Polygon used it to great effect on a custom designed article and wrote about it. Codrops has some neat examples.
I have very little to add, except my brain just kinda figured it out, so I thought I would explain it one more time the way it clicked for me.
We'll need to make three Ajax requests. Since we don't want to show anything to the user until the feature is ready to go (plus they all kinda rely on each other to work right) we need to wait for all three of them to be complete before proceeding.
What's the best way to do that?
Browser support for SVG isn't quite as simple as yes or no. In addition to some quirks on how that support plays out, it depends on how that SVG is being used. One common way is right within an image tag, like
<img src="image.svg" alt="description"/>.
How can you detect if a browser supports SVG use in that way?
I followed this guide by Mark Goodyear to try Gulp (a Grunt competitor) out. I don't use either of them at a level where I'm qualified to have a strong opinion about betterness. They both work for me. I do enjoy the piping in Gulp how you say "take this, do this, this, and this, then put it here" - rather than configuring a source and destination on each thing like in Grunt.
One hiccup I faced: I was running Node 0.8 something locally, which was too old for Gulp. Might as well get yourself upgrade to 0.10 something.
But recently in trying to achieve a certain effect (see title of this article) I couldn't quite get jQuery UI to do it how I wanted. But I got it done and here's how.