With the success of their first online cohort, Hack Reactor is happy to announce two new Remote Beta classes. Aspiring engineers no longer need to relocate to San Francisco in order to attend their 12-week immersive JavaScript coding school. Take Hack Reactor’s program from home and gain the skills and confidence needed to build amazing products.
Remote Beta Classes begin October 27th & December 8th with recommended application deadlines of September 29th and November 10th, respectively. Apply today and take their exceptional Remote Beta program from wherever you are!
Let's say you're having a health back-and-forth between you, a front end developer, and a designer. All the best work comes through collaboration and iteration, right? I believe that. But I also believe there are time traps in there. If you feel you're wasting time by getting peppered with tiny design tweaks, there might be salvation in giving designers tools to do the tweaks and then give you exactly what you need.
Let's see some simple examples.
Positioning Elements in a Space
Let's say you have some absolutely positioned elements. Their exact position is a big part of how the design feels. You could hook up a script to allow those elements to be dragged, and then report their position with the exact CSS you'll need to put them there.
Here I've used David DeSandro's Draggabilly to do that:
It's a fairly small little script that allows elements to be dragged, and when a drag event stops, it creates the little bit of CSS needed based on that elements ID and top/left position, and puts that in the bottom right corner of the document ready for copy-pasting and providing to you, the front end developer.
Changing Font Stuff
How about little <select> that comes up over paragraphs that allows you to toggle between font families in development?
Or perhaps a range input that controls line-height:
Wouldn't be too difficult to drop in a color picker that shows up around elements you choose and changes backgrounds, fills, borders, strokes, text color, etc.
Of course building your own tools is great because:
They can be designed just how you like them
You can build them to change anything whatsoever
They can be integrated directly onto the design
But... they are a bunch of work as well. You will likely get quite a bit of mileage out of just showing a designer how to use a browsers DevTools to tweak designers. Chances are, they will really take to it.
Have you ever done this?
While I prefaced the article with the idea that this could be time saving for the developer, since you're giving designers tools in which to express exactly what they want, it could backfire. Meaning you could spend a ton of time on these little tools only to see them used very little. Communication, as always, is key.
Have you ever tried doing something like this in your team workflow?
Lucas Bebber's Glitch is a super cool effect. It's like you're looking at some text displayed on a progressive scan monitor that has been dropped on the ground one too many times and so the alignment of the pixels is off in weirdly un-even amounts time and space.
It's bonafide CSS trick if there ever was one! It took me a bit to figure out how it was working, so I thought I'd explain. Then I ended up making it work for other kinds of content as well as making it into a group of Sass @mixins to make working with it a bit easier.
/* important: opaque background masks the original */ background: black; }
So now the three copies are like this:
Clipping the Copies
You'd only ever see the top copy if left as-is. Probably the ::after version, unless you alter with z-index. But never fear, we're going to be only revealing parts of the top, altered copies with the clipproperty. This property is apparently deprecated in favor of clip-path, but at the time of this writing, only clip was working for me. I'm sure that will change in time, so we'll have to keep an eye on it, and presumably Autoprefixer will handle it.
The syntax for clip is kinda weird. For the four values, you might expect something like top/left/width/height, or point-at-top-left/point-at-bottom-right. But instead it's like margin and padding: top/right/bottom/left
.glitch::before { clip: rect(44px, 450px, 56px, 0); /* Essentially a box from 0, 44px to 450px, 56px */ }
Here's some example clips on those layers, now with fully opaque backgrounds applied (but still rotated and with extra colors so you can see what's going on):
Animate the Clips
Turns out clip can be animated, so, that clipped box will animate to a new position over time if told to, Here's an example of keyframes:
Because you'd want two sets of randomized clipping positions, you'd make two sets of those @keyframes, and apply them to the copies:
.glitch::before { ...
animation: glitch-anim-1 2s infinite linear alternate-reverse; }
.glitch::after { ...
animation: glitch-anim-2 2s infinite linear alternate-reverse; }
There is where we set the speed (number of keyframes also affects speed) as well as making it run infinitely back and forth.
It's pretty fun to watch:
Although it should go without saying a little goes a long way.
Sass @mixins
I thought it would be neat if the technique was more reusable. Basically call a @mixin with parameters to control the effect and get just what you need.
// Ensure the @keyframes are generated at the root level @at-root { // We need two different ones @for $i from 1 through 2 { @keyframes #{$name}-anim-#{$i} { @for $i from 0 through $steps { #{percentage($i*(1/$steps))} { clip: rect( random($height)+px, $width+px, random($height)+px, 0 ); } } } } } &:before, &:after { content: attr(data-text); position: absolute; top: 0; left: 0; width: 100%; background: $background; clip: rect(0, 0, 0, 0); } &:after { left: 2px; text-shadow: -1px 0 $highlightColor1; animation: #{$name}-anim-1 2s infinite linear alternate-reverse; } &:before { left: -2px; text-shadow: 2px 0 $highlightColor2; animation: #{$name}-anim-2 3s infinite linear alternate-reverse; }
}
There are a million different ways to approach it, this is just one. Totally depends on how much you want the mixin to do for you, how much customizability you want or need, what you want left in the HTML, etc.
I also made two more mixins, one for applying this effect to images, and on for inline SVG. They are different, because they don't use pseudo elements to make the copies, coloring happens in different ways, positioning happens differently, etc. Here's all three of them together.
Sponsor: Frontend Masters – Expert Web Development Training
Frontend Masters produces quality video training by industry leaders like Kyle Simpson, Douglas Crockford and Estelle Weyl. I like how these courses are targeted at intermediate and advanced developers:
You've got the basics down and don't want to learn from teachers who just spoon feed you their google results - you want to learn from the masters! Here, you get experts as teachers - people who are actively shaping the industry
Upgrade your JavaScript, CSS and front-end skills with Frontend Masters courses. Check out the complete course list.
Centering things in CSS is the poster child of CSS complaining. Why does it have to be so hard? They jeer. I think the issue isn't that it's difficult to do, but in that there so many different ways of doing it, depending on the situation, it's hard to know which to reach for.
So let's make it a decision tree and hopefully make it easier.
You can center a block-level element by giving it margin-left and margin-right of auto (and it has a set width, otherwise it would be full width and wouldn't need centering). That's often done with shorthand like this:
If you have two or more block-level elements that need to be centered horizontally in a row, chances are you'd be better served making them a different display type. Here's an example of making them inline-block and an example of flexbox:
If padding isn't an option for some reason, and you're trying to center some text that you know will not wrap, there is a trick were making the line-height equal to the height will center the text.
Equal padding on top and bottom can give the centered effect for multiple lines of text too, but if that isn't going to work, perhaps the element the text is in can be a table cell, either literally or made to behave like one with CSS. The vertical-align property handles this, in this case, unlike what it normally does which is handle the alignment of elements aligned on a row. (More on that.)
Remember that it's only really relevant if the parent container has a fixed height (px, %, etc), which is why the container here has a height.
If both of these techniques are out, you could employ the "ghost element" technique, in which a full-height pseudo element is placed inside the container and the text is vertically aligned with that.
It's fairly common to not know the height in web page layout, for lots of reasons: if the width changes, text reflow can change the height. Variance in the styling of text can change the height. Variance in the amount of text can change the height. Elements with a fixed aspect ratio, like images, can change height when resized. Etc.
But if you do know the height, you can center vertically like:
.parent { position: relative; } .child { position: absolute; top: 50%; height: 100px; margin-top: -50px; /* account for padding and border if not using box-sizing: border-box; */ }
Using negative margins equal to half of that width and height, after you've absolutely positioned it at 50% / 50% will center it with great cross browser support:
If you don't know the width or height, you can use the transform property and a negative translate of 50% in both directions (it is based on the current width/height of the element) to center:
you can set the value through the setProperty() method on the style object
Which makes #1 possible and opens up cool possibilities.
They can be scoped to an element. So perhaps you could set variables representing color to theme a site, but override them at a component level to apply different themes in smaller places as needed.
