Skip navigation
Help

CSS filter

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
GoogleDevelopers


Google I/O 2013 - Stunning Mobile Visualization with CSS Filters

Alex Danilo, Alexis Deveria The future platform for reading is mobile. Creating a compelling digital magazine experience requires taking advantage of leading...
From:
GoogleDevelopers
Views:
212

11
ratings
Time:
45:15
More in
Science & Technology

0
Your rating: None

CSS Blend Modes demo. Image: Screenshot/Webmonkey.

We use the term “CSS 3″ all the time on Webmonkey, but technically that’s something of a misnomer. There is no spoon, you see.

In fact, the CSS Working Group, which oversees the CSS specification at the W3C, is cranking out draft specs of new features all the time — the monolithic “3.0″ or “4.0″ versioning was tossed out after CSS 2.1. Instead new features are developed as “modules” so that, for example, the Selector Module can be published without waiting for the Layout Module.

That means there are new CSS features coming all the time.

Adobe’s Divya Manian — who is also one of the developers behind HTML5 Boilerplate — recently gave a talk titled “CSS Next“, which highlights some of the exciting new CSS features coming soon to a browser near you.

Among the cool things Manian highlights are some impressive new tricks for web fonts, including better tools for working with ligatures, unicode and icon fonts.

There are also some impressive new layout tools in the works, namely CSS Regions and Exclusions. We looked at both back when Adobe first proposed them, but since then not only have they progressed to actual draft specs, but they’re now supported in Chrome’s Canary builds (rather than requiring a custom build from Adobe).

It’s still going to be a while before either can claim a spot in your CSS layout toolkit, but there are already a few demos you can check out to see the new layout possibilities Regions and Exclusions offer. Grab a copy of Chrome Canary and turn on “Enable Experimental WebKit Features” in chrome:flags and then point your browser to this demo of Regions and this “shape inside” demo of Exclusions.

Other things Manian covers that we’re looking forward to include CSS Filters and Blend modes. CSS Filters already work in WebKit browsers and allow you to apply effects like blur or grayscale to any HTML element. CSS Blend Modes work just like layer-blending modes in Photoshop and other graphics apps — allowing you to blend layers using modes like “difference,” “overlay,” “multiply” and so on. As of right now you still need a special build of Chromium to see Blend Modes in action.

Manian also covers two intriguing WebKit-only features that aren’t yet a part of any CSS spec, but could be one day. Be sure to read through Manian’s post for more info and a few other new things, including two Webmonkey has covered recently — CSS @supports and CSS Variables.

0
Your rating: None

  

Howdy, folks! Welcome to the new incarnation of Smashing Magazine’s Q&A. It’s going to work like this: you send in questions you have about CSS, and at least once a month we’ll pick out the best questions and answer them so that everyone can benefit from the exchange. Your question could be about a very specific problem you’re having, or it could be a question about a philosophical approach. We’ll take all kinds.

We’ve done a bit of this kind of exchange before with a wider scope, so if you enjoy reading the Q&A, check out my author archive for more of them.

Designing For Email

Andrejs Abrickis asks:

“Sometimes I face trouble with HTML email design and the proper CSS code. It takes quite a lot of time to make it cross-client compatible. I would like to know your opinion about the best CSS reset that could help to speed up email newsletter development. Is there any good tool for testing HTML emails?”

First and foremost, I recommend keeping emails very simple. Ask yourself what the primary message of the email is and how well the current design of the email is serving that. Could it simply be text? Would it be better if it was text? I find that’s often true.

If you are certain you need to make an HTML email, I’d again error on the very simple. An idea I’ve been toying around with is making the email design the size of a portrait smartphone layout. That constraight forces you to think about the message again, enforces simplicity (and as a side bonus, will look good on both mobile and desktop clients). When is the last time you got an email and thought: “Man, I wish this email was more complicated!”

HTML Email Boilerplate
HTML Email Boilerplate provides a template of sorts, absent of design or layout, that will help you avoid some of the major rendering problems with the most common email clients out there — Gmail, Outlook, Yahoo Mail, etc.

But you wanted to know about cross-client compatibility and testing. Do check out the HTML Email Boilerplate. It was created in the same spirit as the HTML5 Boilerplate in that it addresses all the various quirks across email clients and gives an example of a very minimal structure by which to start. I’ve tried to use it as is, but I have to admit that I found it a bit too much for the simple email work I was doing. More complex and varied emails will certainly benefit from it and it’s also certainly a great reference for snagging quick problem-solving bits of code.

The two simple rules of thumb for HTML email development are:

  1. Use tables for layout. This is still the most sturdy layout method for cross-client.
  2. Inline style everything. Any other CSS support is spotty.

Designing using inline styles is a big pain in the butt, so I’d recommend developing with a <style> block in the <head> for your CSS. Save that as your development copy, and then just before deployment, run it through MailChimp’s Automatic CSS Inliner Tool which will do the dirty work of inline styling everything for you.

Speaking of MailChimp, you might want to consider just using their service to build and deploy emails. Their templates are already cross-client compatible (plus they have a testing service). Their designer tool is easy to use and helps you through the process. Not to mention, you get all these other huge benefits like better deliverability that you can’t get on your own, statistics, support, and many more features. Sorry if that sounded like an ad, but I’m all about using services that make our lives easier and better as developers.

MailChimp isn’t the only service on the block either, Campaign Monitor is also great, and do great things for the developer community, including maintaining this epic chart of CSS support for email clients.

Campaign Monitor HTML Email Reference
CSS support on Campaign Monitor.

Type On A Grid

Maxime Parmentier asks:

“I was wondering how you keep a consistent line-height in every element of your page? It’s much more difficult than it sounds in practice. Any tools or techniques that you can recommend?”

Often times that practice is called maintaining a “baseline grid.” Here’s a demo from a Richard Rutter article. And another demo from a Wilson Miner article. I’ve played with it myself a bit.

Dave Rupert offers a talk about responsive design, where he discusses how ems are useful for baseline grids because they are based on ratios. He also talks about how they are particularly good in the math-ridden world of responsive design. Here’s an example by Dave of type lining up nicely to a grid that also accommodates some of the weirdness of different-sized headers.

Baseline Grid
View this example.

There is a book by Khoi Vinh all about grids (including type grids) called Ordering Disorder: Grid Principals for Web Design. Khoi teaches all about grids but is clear that you don’t have to be dogmatic about them. Breaking the grid sometimes is OK, as long as you come back to it. I think one nice metaphor he mentions is about syncopation in music—the rhythm is broken on purpose during a song, so that when it kicks back in, it’s noticed and feels good.

Centering And Resets

Smarajit Dasgupta asks:

1. What is a decent browser-compatible way to center floated (or inline) elements like buttons and links in flexible (or unknown) width scenarios?

2. What is your preferred CSS reset in the HTML5 age? Do you still advise the usage of the great Eric Meyer’s reset, which pretty much strips all the browser-induced styles for elements? Or do you use something such as normalize.css or write your own on a case basis?”

1. Inline elements are easy to center, as they respect the text-align value of the parent, which you can set to center. So say you have a bunch of anchor links in a row, you’d just wrap them in a nav element and apply the center text alignment to that (like this). If you need them to behave a bit more like block level elements (e.g. be of a set width or height), you can make them display: inline-block; and they will still stay centered (like this).

Unfortunately you can’t center a floated element. I’m not surprised really, as the “what happens if” scenarios surrounding that are too many to count. But just for funzies, let’s say you had two columns of text and you wanted to “center float” an image between them, meaning that the text in the left column would wrap to the left, and the text in the right column would wrap to the right. You can “fake” this by positioning two elements half the size (might as well be pseudo elements, because they have no semantic meaning) on the right-side of the left column and left-side of the right column. A picture is easier to understand:

Floating Image
The floating kitty demo.

Then you would place the element in the space that makes sense (probably with absolute positioning). More about this idea here.

2. I like normalize.css. I don’t like the idea of stripping things away just to put them back. So my process is to take a copy of normalize.css, not remove anything, but change some declarations to my liking (which still ensures consistency, because you are being explicit). Then include that in my global style sheet like I would include a reset, and go from there.

Opacity Blues

Chris Klein asks:

“How do I stop inheritation of opacity? I can’t use another png with 50% opacity and higher z-index above it as the layout has to stay 100% liquid. Also, I tried to insert spans between the box with opacity and the following boxes—but the opacity still is inherited to all other boxes it follows. Even if the following boxes claim opacity: 1;, it doesn’t matter, inheritation goes on.”

There are a lot of little bits in there that make me wish we could look at the exact layout you’re working with. If the backgrounds in question are flat colors, just use RGBa or HSLa. These are both color value types you can use to declare an alpha value, which essentially means “what percentage transparent is this color?”. For instance rgba(255, 0, 0, 0.5) means “50% red”. This makes a lot more sense than using actual opacity on element, which as you know, affects everything inside (not just the background).

As you also know, opacity affects all child elements and you can’t fight against it by setting a child element’s opacity higher (the child does have full opacity by default, it’s just within a parent that doesn’t). It is like that for good reason. We would be much worse off if, in order to fade out an area of a website, we had to select theoretically infinite child elements and fade each individually.

If the background in your design isn’t a flat color, you can join the club for wishing there was a background-opacity property. One thing you may want to try are pseudo elements. Leave the main element at full opacity, but apply ::before and ::after selectors that you position as needed and apply opacity to those. Nicolas Gallagher has a demo of that.

Pseudo Element
The Jupiter oppacity demo.

Border-Radius On Images

Donovan Hutchinson asks:

“Why isn’t it possible to directly apply border-radius to an image? And is the best approach to use a wrapping div?”

It is possible! You apply it just like you think you would:

img {
  border-radius: 10px;
}

Border Radius
Border Radius demo.

I think there was some confusion on this for a while, because in the not-so-distant past, Firefox 3.6 required the use of -moz-border-radius for rounded corners, and that implementation didn’t work on images. IE9 was the first version to support border radius and it does so un-prefixed and perfectly fine on images so even IE isn’t a concern here.

If you absolutely need Firefox 3.6 (and down) support (1.55% global usage and falling fast), yep, like you mentioned, you can get it by using a div instead and setting the background-image of the div to the src of the image. You would do that in your template wherever it spits out that URL (or if that’s not possible, with a bit of jQuery):

$("div.avatar").each(function() {
  var el = $(this);
  var url = el.find("img").hide().attr("src");
  el.css("background-image", "url(" + url + ")");
});

Spotting Bad Code

Michael Zanzini asks:

“How can you tell if your CSS code smells? What are the signs that the code is sub-optional, or that the developer hasn’t done a good job? What do you look for in the code to determine how good or bad it is?”

The most obvious way to tell: does the website look all screwed up? Then it’s bad CSS. If the website looks perfect, then it passes the first test.

The next thing I’d look for without getting too down and dirty is the formatting. I wouldn’t care about trivial things like tabs or spaces or spacing after selectors, but instead general cleanliness and consistency. Does it look like they have a style that they adhere to, or is it sloppy and random? Clean code is a sign of a respectful developer. It’s not proof the code is good but it’s a good start. Mind you, you should be looking at the authored CSS, not deployed CSS, as that could be altered during a build process.

After those rather obvious things, you’ll have to get mentally more into the code. Read through it. Do the selectors look nice and rational (e.g. nothing too ridiculously specific like .article #comments ul > li > a.button)? Does there appear to be an awful lot of repeated code (e.g. the same complex box-shadow declared 15 times)? Is it absolutely enormous (e.g. 100k would be be absolutely enormous, as a check)?

The last thing I might do is try and test understandability by running a personal test. Assuming that you are half-way decent at CSS yourself, think of a small task you might need to do on the website. Adjust the colors and spacing of a particular header. Try and do it. Was it easy? Good. Was it hard to figure out? Not good.

Submit Your Question!

Keep up the great questions, folks! Got a good one? Submit your CSS question via our form, and we’ll pick the best for the next edition. So long!

(jvb)

© Chris Coyier for Smashing Magazine, 2012.

0
Your rating: None

I didn't intend for Please Don't Learn to Code to be so controversial, but it seemed to strike a nerve. Apparently a significant percentage of readers stopped reading at the title.

So I will open with my own story. I think you'll find it instructive.

My mom once told me that the only reason she dated my father is because her mother told her to stay away from that boy, he's a bad influence.

If she had, I would not exist.

True story, folks.

I'd argue that the people who need to learn to code will be spurred on most of all by honesty, not religious faith in the truthiness of code as a universal good. Go in knowing both sides of the story, because there are no silver bullets in code. If, after hearing both the pros and cons, you still want to learn to code, then by all means learn to code. If you're so easily dissuaded by hearing a few downsides to coding, there are plenty of other things you could spend your time learning that are more unambiguously useful and practical. Per Michael Lopp, you could learn to be a better communicator. Per Gina Trapani, you could learn how to propose better solutions. Slinging code is just a tiny part of the overall solution in my experience. Why optimize for that?

On the earliest computers, everyone had to be a programmer because there was no software. If you wanted the computer to do anything, you wrote code. Computers in the not so distant past booted directly to the friendly blinking cursor of a BASIC interpreter. I view the entire arc of software development as a field where we programmers spend our lives writing code so that our fellow human beings no longer need to write code (or even worse, become programmers) to get things done with computers. So this idea that "everyone must know how to code" is, to me, going backwards.

Grace-hopper-and-the-univac

I fully support a push for basic Internet literacy. But in order to be a competent driver, does everyone need to know, in detail, how their automobile works? Must we teach all human beings the basics of being an auto mechanic, and elevate shop class to the same level as English and Mathematics classes? Isn't knowing how to change a tire, and when to take your car in for an oil change, sufficient? If your toilet is clogged, you shouldn't need to take a two week in depth plumbing course on toiletcademy.com to understand how to fix that. Reading a single web page, just in time, should be more than adequate.

What is code, in the most abstract sense?

code (kōd) …

    1. A system of signals used to represent letters or numbers in transmitting messages.
    2. A system of symbols, letters, or words given certain arbitrary meanings, used for transmitting messages requiring secrecy or brevity.
  1. A system of symbols and rules used to represent instructions to a computer…

The American Heritage Dictionary of the English Language

Is it punchcards? Remote terminals? Emacs? Textmate? Eclipse? Visual Studio? C? Ruby? JavaScript? In the 1920s, it was considered important to learn how to use slide rules. In the 1960s, it was considered important to learn mechanical drawing. None of that matters today. I'm hesitant to recommend any particular approach to coding other than the fundamentals as outlined in Code: The Hidden Language of Computer Hardware and Software, because I'm not sure we'll even recognize coding in the next 20 or 30 years. To kids today, perhaps coding will eventually resemble Minecraft, or building levels in Portal 2.

But everyone should try writing a little code, because it somehow sharpens the mind, right? Maybe in the same abstract way that reading the entire Encyclopedia Brittanica from beginning to end does. Honestly, I'd prefer that people spend their time discovering what problems they love and find interesting, first, and researching the hell out of those problems. The toughest thing in life is not learning a bunch of potentially hypothetically useful stuff, but figuring out what the heck it is you want to do. If said research and exploration leads to coding, then by all means learn to code with my blessing … which is worth exactly what it sounds like, nothing.

So, no, I don't advocate learning to code for the sake of learning to code. What I advocate is shamelessly following your joy. For example, I received the following email yesterday.

I am a 45 year old attorney/C.P.A. attempting to abandon my solo law practice as soon as humanly possible and strike out in search of my next vocation. I am actually paying someone to help me do this and, as a first step in the "find yourself" process, I was told to look back over my long and winding career and identify those times in my professional life when I was doing something I truly enjoyed.

Coming of age as an accountant during the PC revolution (when I started my first "real" job at Arthur Andersen we were still billing clients to update depreciation schedules manually), I spend a lot of time learning how to make computers, printers, and software (VisiCalc anyone?) work. This quasi-technical aspect of my work reached its apex when I was hired as a healthcare financial analyst for a large hospital system. When I arrived for my first day of work in that job, I learned that my predecessor had bequeathed me only a one page static Excel spreadsheet that purported to "analyze" a multi-million dollar managed care contract for a seven hospital health system. I proceeded to build my own spreadsheet but quickly exceeded the database functional capacity of Excel and had to teach myself Access and thereafter proceeded to stretch the envelope of Access' spreadsheet capabilities to their utmost capacity – I had to retrieve hundreds of thousands of patient records and then perform pro forma calculations on them to see if the proposed contracts would result in more or less payment given identical utilization.

I will be the first to admit that I was not coding in any professional sense of the word. I did manage to make Access do things that MS technical support told me it could not do but I was still simply using very basic commands to bend an existing application to my will. The one thing I do remember was being happy. I typed infinitely nested commands into formula cells for twelve to fourteen hours a day and was still disappointed when I had to stop.

My experience in building that monster and making it run was, to date, my most satisfying professional accomplishment, despite going on to later become CFO of another healthcare facility, a feat that should have fulfilled all of my professional ambitions at that time. More than just the work, however, was the group of like-minded analysts and IT folks with whom I became associated as I tried, failed, tried, debugged, and continued building this behemoth of a database. I learned about Easter Eggs and coding lore and found myself hacking into areas of the hospital mainframe which were completely offlimits to someone of my paygrade. And yet, I kept pursuing my "professional goals" and ended up in jobs/careers I hated doing work I loathed.

Here's a person who a) found an interesting problem, b) attempted to create a solution to the problem, which naturally c) led them to learning to code. And they loved it. This is how it's supposed to work. I didn't become a programmer because someone told me learning to code was important, I became a programmer because I wanted to change the rules of the video games I was playing, and learning to code was the only way to do that. Along the way, I too fell in love.

All that to say that as I stand at the crossroads once more, I still hear the siren song of those halcyon days of quasi-coding during which I enjoyed my work. My question for you is whether you think it is even possible for someone of my vintage to learn to code to a level that I could be hired as a programmer. I am not trying to do this on the side while running the city of New York as a day job. Rather, I sincerely and completely want to become a bona fide programmer and spend my days creating (and/or debugging) something of value.

Unfortunately, calling yourself a "programmer" can be a career-limiting move, particularly for someone who was a CFO in a previous career. People who work with money tend to make a lot of money; see Wall Street.

But this isn't about money, is it? It's about love. So, if you want to be a programmer, all you need to do is follow your joy and fall in love with code. Any programmer worth their salt immediately recognizes a fellow true believer, a person as madly in love with code as they are, warts and all. Welcome to the tribe.

And if you're reading this and thinking, "screw this Jeff Atwood guy, who is he to tell me whether I should learn to code or not", all I can say is: good! That's the spirit!

[advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today!

0
Your rating: None

The whole "everyone should learn programming" meme has gotten so out of control that the mayor of New York City actually vowed to learn to code in 2012.

Bloomberg-vows-to-code

A noble gesture to garner the NYC tech community vote, for sure, but if the mayor of New York City actually needs to sling JavaScript code to do his job, something is deeply, horribly, terribly wrong with politics in the state of New York. Even if Mr. Bloomberg did "learn to code", with apologies to Adam Vandenberg, I expect we'd end up with this:

10 PRINT "I AM MAYOR"
20 GOTO 10

Fortunately, the odds of this technological flight of fancy happening – even in jest – are zero, and for good reason: the mayor of New York City will hopefully spend his time doing the job taxpayers paid him to do instead. According to the Office of the Mayor home page, that means working on absenteeism programs for schools, public transit improvements, the 2013 city budget, and … do I really need to go on?

To those who argue programming is an essential skill we should be teaching our children, right up there with reading, writing, and arithmetic: can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder? It is obvious to me how being a skilled reader, a skilled writer, and at least high school level math are fundamental to performing the job of a politician. Or at any job, for that matter. But understanding variables and functions, pointers and recursion? I can't see it.

Look, I love programming. I also believe programming is important … in the right context, for some people. But so are a lot of skills. I would no more urge everyone to learn programming than I would urge everyone to learn plumbing. That'd be ridiculous, right?

Advice-for-plumbers

The "everyone should learn to code" movement isn't just wrong because it falsely equates coding with essential life skills like reading, writing, and math. I wish. It is wrong in so many other ways.

  • It assumes that more code in the world is an inherently desirable thing. In my thirty year career as a programmer, I have found this … not to be the case. Should you learn to write code? No, I can't get behind that. You should be learning to write as little code as possible. Ideally none.
  • It assumes that coding is the goal. Software developers tend to be software addicts who think their job is to write code. But it's not. Their job is to solve problems. Don't celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.
  • It puts the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is. Do you even have a problem? Can you explain it to others in a way they can understand? Have you researched the problem, and its possible solutions, deeply? Does coding solve that problem? Are you sure?
  • It assumes that adding naive, novice, not-even-sure-they-like-this-whole-programming-thing coders to the workforce is a net positive for the world. I guess that's true if you consider that one bad programmer can easily create two new jobs a year. And for that matter, most people who already call themselves programmers can't even code, so please pardon my skepticism of the sentiment that "everyone can learn to code".
  • It implies that there's a thin, easily permeable membrane between learning to program and getting paid to program professionally. Just look at these new programmers who got offered jobs at an average salary of $79k/year after attending a mere two and a half month bootcamp! Maybe you too can teach yourself Perl in 24 hours! While I love that programming is an egalitarian field where degrees and certifications are irrelevant in the face of experience, you still gotta put in your ten thousand hours like the rest of us.

I suppose I can support learning a tiny bit about programming just so you can recognize what code is, and when code might be an appropriate way to approach a problem you have. But I can also recognize plumbing problems when I see them without any particular training in the area. The general populace (and its political leadership) could probably benefit most of all from a basic understanding of how computers, and the Internet, work. Being able to get around on the Internet is becoming a basic life skill, and we should be worried about fixing that first and most of all, before we start jumping all the way into code.

Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks. Instead, I humbly suggest that we spend our time learning how to …

  • Research voraciously, and understand how the things around us work at a basic level.
  • Communicate effectively with other human beings.

These are skills that extend far beyond mere coding and will help you in every aspect of your life.

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!

0
Your rating: None