I'd venture to say that most developers and designers are not big fans of proxy browsers—assuming they pay attention to them at all. They don't behave in ways a typical browser does, which leads to frustration as we see our carefully created sites fall apart for seemingly no reason at all. And frankly, most of us don't really need to use them on …

]]>A new series of posts by Tim Kadlec on proxy browsers and why some people need them:

I'd venture to say that most developers and designers are not big fans of proxy browsers—assuming they pay attention to them at all. They don't behave in ways a typical browser does, which leads to frustration as we see our carefully created sites fall apart for seemingly no reason at all. And frankly, most of us don't really need to use them on a day-to-day basis. Through the lens we view the web, proxy browsers are merely troublesome relics of a time before the idea of a "smartphone" was anything other than a pipe dream.

But our view of the web is not the only view of the web. People all over the world face challenges getting online—everything from the cost of data and poor connectivity to religious and political obstacles. In these environments proxy browsers are far from troublesome; they are essential.

]]>https://css-tricks.com/understanding-proxy-browsers/feed/0Motion along path in CSShttps://www.chromestatus.com/feature/6190642178818048
https://css-tricks.com/motion-along-path-in-css/#commentsWed, 29 Jul 2015 18:12:21 +0000https://css-tricks.com/?p=205698From the "I barely knew this was a thing and you can already play with it in browsers" files:

Motion paths allow authors to animate any graphical object along an author-specified path.

I suspect Chrome jumped on this because it's something that was only otherwise doable in SMIL, which they are ditching. I believe this is the first time the full path syntax has made it into CSS? (e.g. motion-path: path('M100,250 C 100,50 400,50 400,250');).

]]>From the "I barely knew this was a thing and you can already play with it in browsers" files:

Motion paths allow authors to animate any graphical object along an author-specified path.

I suspect Chrome jumped on this because it's something that was only otherwise doable in SMIL, which they are ditching. I believe this is the first time the full path syntax has made it into CSS? (e.g. motion-path: path('M100,250 C 100,50 400,50 400,250');).

]]>https://css-tricks.com/on-the-verge/feed/0Position an element relatively to another elementhttp://discourse.wicg.io/t/position-an-element-relatively-to-another-element-from-anywhere-in-the-dom/968
https://css-tricks.com/position-an-element-relatively-to-another-element/#commentsWed, 29 Jul 2015 18:11:17 +0000https://css-tricks.com/?p=205693Not possible currently in CSS, but there is a discussion happening around syntax like:

.el {
position: element(#target)
}

Of course there are tons of details, gotchas, and edge cases, but it sounds likely.

]]>https://css-tricks.com/position-an-element-relatively-to-another-element/feed/0Scroll-to-top-then-fixedhttp://demosthenes.info/blog/1052/position-sticky-scroll-to-top-then-fixed-in-pure-CSS
https://css-tricks.com/scroll-to-top-then-fixed/#commentsTue, 28 Jul 2015 17:04:52 +0000https://css-tricks.com/?p=205680Chrome yanked position: sticky;, but Firefox and Safari still have it. Dudley Storey shows how to do the common sidebar pattern where a chunk follows you as you scroll down, but only when there is room for it. He does it in CSS, and the demo polyfills support with stickyfill.

]]>Chrome yanked position: sticky;, but Firefox and Safari still have it. Dudley Storey shows how to do the common sidebar pattern where a chunk follows you as you scroll down, but only when there is room for it. He does it in CSS, and the demo polyfills support with stickyfill.

]]>https://css-tricks.com/fix-scrolling-performance-with-css-will-change-property/feed/0Modern CSS Layout, power and responsibilityhttps://www.rachelandrew.co.uk/archives/2015/07/28/modern-css-layout-power-and-responsibility/
https://css-tricks.com/modern-css-layout-power-and-responsibility/#commentsTue, 28 Jul 2015 16:54:18 +0000https://css-tricks.com/?p=205676Rachel Andrew reminds us that the power new CSS layout methods gives us could be used to form new anti-patterns:

With this power comes great responsibility. For just as it will be possible for a developer to start out with a beautifully semantic, well structured document and use Grid and Flexbox to meet the design requirements, it will be possible for them to stop caring about the document structure at all. Worse, I believe there will be a strong temptation, …

]]>Rachel Andrew reminds us that the power new CSS layout methods gives us could be used to form new anti-patterns:

With this power comes great responsibility. For just as it will be possible for a developer to start out with a beautifully semantic, well structured document and use Grid and Flexbox to meet the design requirements, it will be possible for them to stop caring about the document structure at all. Worse, I believe there will be a strong temptation, especially with Grid, to flatten out document structure in order that all elements become a child of the element with the Grid declared. Making layout simple, but at what cost?

]]>Guil Hernandez introduces how easy sliders (with nice UX) will be with very simple HTML and CSS' brand new scroll-snap-* properties. CSS is moving fairly fast these days, with features like this moving from "never heard of it" to:

... browser support for CSS scroll snap points is limited to IE10+ and Firefox 39+. But it looks like Safari 9 will include support, and you can enable scroll snap points in Chrome Canary.

before you know it. The Chrome support means it will trickle to Opera and Android, and the Safari support means it will trickle to iOS, so pretty solid support across the board soon.

]]>https://css-tricks.com/thinking-ahead-css-scroll-snap-points/feed/0The Difference Between Minification and Gzippinghttps://css-tricks.com/the-difference-between-minification-and-gzipping/
https://css-tricks.com/the-difference-between-minification-and-gzipping/#commentsMon, 27 Jul 2015 17:16:24 +0000https://css-tricks.com/?p=205543These are both things that you do to assets on your website (things like .css files and .js files). They are both things that reduce the size of the file, making it more efficient in crossing the network between servers and browsers. As in, good for performance. The network is the speed bottleneck of the web and reducing file size helps.

But these two things are distinctly different. If you didn't already know that, it's worth understanding.

]]>These are both things that you do to assets on your website (things like .css files and .js files). They are both things that reduce the size of the file, making it more efficient in crossing the network between servers and browsers. As in, good for performance. The network is the speed bottleneck of the web and reducing file size helps.

But these two things are distinctly different. If you didn't already know that, it's worth understanding.

... and stuff like that. The file remains perfectly valid code. You wouldn't want to try to read it or work with it, but it's not breaking any rules. The browser can read it and use it just like it could the original file.

Minification creates a new file that you ultimately use. For instance, you'd create a `style.css` that you work with. Then you could minify it into `style.min.css`.

Gzipping finds all repetitive strings and replaces them with pointers to the first instance of that string.

Julia Evans created a wonderful way to understand this (see her post and video). See this first paragraph of a poem:

The text within the curly brackets has been discovered by gzip to be repetitive. Thus will be replaced with a pointer that uses less space than the text itself does.

This can be incredibly effective at reducing file size, especially with code, since code be incredibly repetitive. Imagine how many instances of <div there are in an HTML file or { in a CSS file.

You can create gzipped version of files (i.e. style.css.zip) but you rarely ever do that and the browser won't know what to do with it.

On the web, gzipping is done directly by your server. It's a matter of configuring the server to do it. Once that's done, gzipping automatically happens, there isn't any ongoing work you have to do. The server compresses the file and sends it across the network like that. The browser receives the file and unzipped it before using it. I've never heard anyone mention anything about the overhead of zipping and unzipping, so I just assume it's negligible and the benefits far outweigh the overhead.

An Example

You'll save about 17% minifying the CSS, 85% gzipping, or 86% if you do both.

Here's the ideal situation when checking everything is working from DevTools:

Gzipping is far more effective. Doing both is ideal.

Gzipping reduces the file size about five times as much as minifying does. But, you get a littleboost from minifying as well, and since it likely requires little additional effort in a build step, you might as well.

There is also some evidence that browsers can read and parse a minified file faster:

As expected, minification helps parse-n-load in addition to network transmission time. This is probably due to the absence of comments and extra whitespace.

So in Windows 10 and Microsoft Edge, we've added new fast paths, improved inlining and optimized some heuristics in Chakra's JIT compiler to ensure that minified code runs as fast, if not faster than the non-minified versions. With these changes, the performance of individual code patterns minified using UglifyJS that we tested, improved between 20-50%.

Caching assets is also related to this conversation, as nothing is faster than a browser that doesn't have to request an asset at all! There is plenty of information on that around the web (or in books), but we may just do a post on it soon with some tricks.

]]>https://css-tricks.com/the-difference-between-minification-and-gzipping/feed/40Front End Development is Developmenthttps://css-tricks.com/front-end-development-is-development/
https://css-tricks.com/front-end-development-is-development/#commentsFri, 24 Jul 2015 17:52:36 +0000https://css-tricks.com/?p=205460There is some sentiment out there that front end development isn't real development. It's a swaggering, trollish sentiment. Still, it's fun to puff our chests back sometimes. Let's try to put a point on why front end development is every bit as difficult and worthy of the title as any other subset.

This is a continuation of my post last week on how the expected skills of a front end developer are hard to nail down and how different we …

]]>There is some sentiment out there that front end development isn't real development. It's a swaggering, trollish sentiment. Still, it's fun to puff our chests back sometimes. Let's try to put a point on why front end development is every bit as difficult and worthy of the title as any other subset.

This is a continuation of my post last week on how the expected skills of a front end developer are hard to nail down and how different we all can be. That post struck a chord with a good chunk of readers, and the comments that came in were full of interesting stories and experiences about what front end development means in both the technical and personal sense.

The practice of front end development is similar to playing the bass: it's easy to learn but difficult to master. There is a lot more to it than HTML and CSS (which are plenty difficult onto themselves).

And while the majority of responses were certainly entertaining and LOL-worthy, there were some nuggets of wisdom in there as well. Let's take a look at the common themes that make front-end development, uh, development!

We have to deal with cross browser compatibility.

This was far and away the most cited gripe in the group. While Internet Explorer continues to be the brunt of most jokes, every browser has its own quirks that often require special development techniques to overcome.

It's rather expected of us that we know how to build websites that can work cross-browser. We should know what browsers support what and how to debug and overcome browser-specific issues. We should know how to do emulate or otherwise test on a variety of browsers.

We should know tools that help us with cross-browser problems either automatically or enable us to write code to handle situations of support and nonsupport of features. We should know how to do fallbacks. We should know about progressive enhancement and graceful degradation.

Frameworks, libraries, preprocessing, dependencies, plugins...

It used to be that linking up a stylesheet and maybe a JavaScript file in the HTML was all that was needed to start designing and building a site. In fact, that's still the baseline.

Today's development feels a lot different. The toolchain is a lot thicker. We're making choices about build processes, which libraries to use, what languages to write in, how invested in future syntaxes we want to be, how much we want to depend on frameworks, which third-party tools make sense and feel safe to use.

Not only is it fatiguing to think about the choices, it's increasingly difficult to know what the best choices are and if these choices are smart in the long term.

There are just as many choices, or more, at the front end level of development than there are anywhere else. Not to mention the landscape moves extremely quickly.

We're the bridge between visual designers, back end developers, and other disciplines.

Many of today's frameworks and CMS's, straddle the line between lots of different disciplines. Front end developers are right in the middle of it all. We're ultimately responsible for design—how the site looks. We're helping content people ensure they have what they need and they give us what we need. We're working in templates prying out the data we need in the formats we need. We're handling user input and ensuring it funneling where it goes for more back end concerns.

Not only do we sit in the intersection of a lot of disciplines, there is some expectation that we know enough back end languages to be useful. You'd be pretty sorry WordPress developer if you didn't know any PHP. You wouldn't be very useful on a Rails project if you didn't know any Ruby or Rails conventions at all. The more you know, the more agile and self-sufficient you can be for your team.

Everybody and their dentist thinks they can do it.

It's easy, make it like this..wait-now like this...ok now that we're done, can we change everything to this? it's easy...

The barrier to entry for front end development is fairly low. Everyone has heard of HTML. They "know enough to be dangerous" as it were. Because that barrier is low and because it so easy to dabble, it makes sense people assume there isn't that much to know and that front end development isn't particularly difficult.

Naming things. And we have to name a lot of things.

I imagine you've heard the maxim about naming things being one of the hardest problems in computer science. Us front enders are naming things all the time. Class names and IDs, data attributes, file names, communicating patterns with your team. It's endless. It feels like there are dozens of name choices on an average day.

Not to mention the task of copywriting often falls to us, which isn't quite naming but is in a similar vein of difficulty.

"The right way" and "the wrong way" aren't as cut and dry as with back end development.

No standard production pipeline. No reference browser implementation. No right answers, but tons of wrong ones.

In back end development, if what you are expecting to happen happens, you've succeeded. Surely they are different ways to get there, some better than others. But in front end development, the paths to completing a task seem endless. Even if you've seemingly succeeded, it can feel like just a matter of time until a bug is found in how you've done it.

CSS is very hard to test.

Back end languages (and even JavaScript) can use unit testing and integration testing to help make sure the code works as expected. CSS has no such luxury. There are certainly people trying and there is some information and tools out there. But none of it is all that great and there are very few success stories.

Bugs can be subtle, confusing, and unexpected. Worse, a seemingly little change may have an adverse effect in an unexpected place where you don't notice until it's too late.

There are linting tools, which help a little. There are some styleguide enforcement tools, but they don't really help enforce more important things like adherence to naming standards.

Front end developers need to hold a very strong understanding of the entire website in their head in order to be most effective and efficient.

JavaScript is just as complex as any other programming language. It's weird and hard.

JavaScript is front end development. JavaScript is programming. Programming is part of software development. Software development is hard.

Performance is 80% on our shoulders.

The rule of thumb is that 20% of the waiting for a website to load is from back end concerns. Once HTML document has arrived, the rest of loading time is the concern of front end developers. What resources are loaded, how many resources are loaded, how optimized they are, in what fashion they load in and how that feels, etc.

It's where accessibility happens.

Building sites that are visually stunning is one thing and the accessibility of them is another. Designers care very much how users interact with a site and that might not always be a visual interaction. Designing and developing for disabilities is a discipline onto itself, but is most tightly tied to front end development. Accessibility has its own set of specifications that sadly aren't typically taught along with traditional front end development training.

It's hard to hire for.

Front end developers are typically the hardest seats to fill.

And, of course...

Wrapping Up

So what do you think? Is front end development "real" development? I'd like to think so and believe the feedback provided here—especially by others—is solid proof. Are there more things that make it hard? SEO? Is this a conversation worth having?