CSS-Tricks

syndicated content powered by FeedBurner

FeedBurner makes it easy to receive content updates in My Yahoo!, Newsgator, Bloglines, and other news readers.

Learn more about syndication and FeedBurner...

Current Feed Content

Reader Question about Hosting

Posted: Mon, 21 Nov 2011 17:49:03 +0000
A reader (who wishes to remain anonymous) wrote in asking me about web hosting. They had a bunch of requirements:
1. Wishes to resell hosting to clients and charge them monthly (currently charges $50/year).
2. Clients need access to their own hosting, e.g. add email addresses or FTP users.
3. He isn't good at server stuff. Needs a GUI for admining whole server and clients need their own GUI admin tools also.
4. Wants to spend less than $100/month.
5. Wants to be able to scale up to more powerful hosting easily.
I use Media Temple (dv) for my own hosting and I like it. So based on my own experience, I'd probably get one of those (which scale up well) and just manually invoice clients when I add their sites to that hosting. The weakness there is that you can't give sandboxed access to them for adding emails and stuff like that. But honestly, I'd rather just get them set up on Google Apps anyway, which they can control themselves.
Or, if giving them true hosting admin access is imperative, buy an inexpensive shared hosting plan (e.g. BlueHost, HostGator or Digitalfyre) just for them, and then invoice them for that cost + markup. That might be a little tacky since they could easily see how much that service costs with trivial investigation. And I'm not sure how well scaling on those services works either.
Another consideration: do you even want to deal with this? Now if their website goes down (which of course you know about right away) it's your problem. If they have their own hosting which they purchased, they might be more likely to deal with the host directly.
Unfortunately, I don't have a perfect answer for him. Hence the post. If you have a great solution in mind, leave it in the comments below and I'm sure he'll appreciate it.
Reader Question about Hosting is a post from CSS-Tricks
Interview

Posted: Sat, 19 Nov 2011 19:27:25 +0000

Kevin Dees interviewed me. We talked about all kinds of front-endy stuff, this site, and other fun stuff. (video)
Direct Link to Article — Permalink
Interview is a post from CSS-Tricks
Using Fonts for Icons…

Posted: Sat, 19 Nov 2011 03:59:28 +0000

...is a good idea, I'm telling you.
I've created this page to attempt to convince you. It shows examples and lists six reasons why it's a good idea and three common arguments against them (some of which I refute).
Don't need convincing? Here's roundup of them from simurai.
Using Fonts for Icons… is a post from CSS-Tricks
Sharing

Posted: Thu, 17 Nov 2011 23:06:59 +0000

I just added "The Big Three" sharing buttons to articles on this site: Twitter, Google Plus, and Facebook. I've shared my thoughts on sharing buttons like this in the past. I essentially decided that I didn't like them for this site. So before anybody skewers me for hypocrisy, I thought I'd go back through my old thoughts and refute myself.
Regarding Traffic
Every website owner in the world wants more traffic, me included. Theoretically, if you put sharing buttons on your site, more people will share the article than would have otherwise, and there will be an increase in traffic to your site. I wrote in that article that I'd tried sharing buttons in the past and saw no significant up tick in traffic. That was true. I'm going to try it again and measure traffic more carefully. But traffic isn't the only factor here.
Regarding User Experience
My personal experience at the time of the last article had me a bit gun shy of clicking social sharing links. I was afraid something might be "auto-tweeted" on my behalf. When that happens, it makes feel like a stooge in front of my friends and I don't like it. I don't think anybody likes that, and the UX of these things has reflected that. I haven't had something auto-tweet for me in a long time.
I don't have any proof of this, but sharing buttons have become so ubiquitous that I think many users almost expect them to be there. In that regard, it's good to not break that expectation, especially when it's of benefit to both of us.
Regarding Which Sites
At the time, it was more common for sites to have a huge rack of sharing buttons. From the obvious big players, to stuff like Delicious and StumbleUpon, to every little trashy niche sharing site out there (e.g. DesignFloat). I was turned off by this and thought that even if I picked my favorites, that would change quickly and turn into a maintenance problem.
Today, I feel like Twitter, Google Plus, and Facebook are the big three and probably will be for some time. I'm only going to use those three for this site. All three of them provide their own native sharing functionality, which I am using. So it's not this "click a link and be whooshed away to some generic sharing URL", it's the native experience.
Regarding Aesthetics
Like anything else, done poorly, sharing buttons can be an eyesore. For my first iteration, I'm just putting them at the bottom of the article in little boxes that go with the other things in that area (Screenshot). Hey I'm not going to win any design awards but I think they work with the design just fine.
Regarding Page Speed
I'm hoping that because I'm using the standard button scripts that all three of these social sites provide, that they will very likely be in users browser cache and thus not affect page speed much. I know that doesn't help mobile out much, where caching isn't nearly as robust. All told, this will slow down the site a bit, I'm just hoping it's not drastic. If it becomes a problem, they'll have to go, speed is a deal-breaker.
I Like Liking Things
I actually use and enjoy all three of these social networks. And I like how each of them has done their unique versions of liking things. For Google Plus, I just click the little +1 button and it feels good. I've shown a bit of appreciation for that content, I can find it again more easily if I lose track of it by going through my old +'s, and other people might see it who are interested in things I +. With just a single click and no big break in my concentration. One of the big motivations for adding these buttons is because I like using them on other people's sites. I want to be able to do it on my own, too.
It's just a test
In a month or so I'll revisit this and see how things have gone. I can see exactly what happens to traffic by comparing pre-November-17th traffic to post. Nothing on the web is permanent. If things are good, they stay, if not, they go.
For comparison's sake, the last ten articles on this site saw an average of 210 tweets, 38 +1s, and 39 Likes. That will be good to compare a month from now. (You know, assuming the content quality doesn't change dramatically =))
Sharing is a post from CSS-Tricks
Bubble Point Tooltips with CSS3 & jQuery

Posted: Thu, 17 Nov 2011 15:59:21 +0000
I needed some tooltips for a thing. In looking around for a little inspiration, I didn't have to go further than my dock:

The inspiration: contextual menus from OS X dock

This is where I ended up:

View Demo Download Files

The HTML: Keepin' it Clean
Links can have tooltips in HTML with no fancy coding whatsoever. Just give a link a title attribute.
```
<a href="#" title="Hi, I'm a tooltip thingy.">link</a>
```
Then when you hover over that link a second or two, you'll get the yellow box thingy:

Default tooltip in pretty much any browser.

Let's not mess with that. Our HTML will be exactly what is shown above.
The thing is, that yellow box thingy is absolutely unstyleable. Maybe someday it will be once shadow DOM stuff like that is specced out, but today, it's not possible in any browser. So we're gonna run some JavaScript which is going to yank out that attribute and make <div>'s with the same text, which we'll position/hide/show as needed.
The JavaScript: jQuery Plugin
As usual around these parts, we'll use jQuery. This is the perfect kind of thing to make into a plugin. You might want to use this functionality on an arbitrary collection of elements of your own choosing, as well as chain it, so the plugin pattern is ideal.
Calling it will be as simple as:
```
$("article a[title]").tooltips();
```
That will tooltip-ize all links with titles that happen to be inside <article> elements. You could make that selector whatever you want.
Our plugin will do this:
1. Loop through each link
2. Create a (hidden) div.tooltip for each of them, the text inside matching that links title attribute.
3. Remove the links title attribute (only way to get rid of default yellow box popup
4. When link is hovered on...
5. Position the tooltip accordingly and slide it into visibility.
6. When link is hovered off...
7. Slide link out of visibility
Massive code dump, commented for your pleasure:
```
// IIFE to ensure safe use of $
(function( $ ) {

  // Create plugin
  $.fn.tooltips = function(el) {

    var $tooltip,
      $body = $('body'),
      $el;

    // Ensure chaining works
    return this.each(function(i, el) {

      $el = $(el).attr("data-tooltip", i);

      // Make DIV and append to page
      var $tooltip = $('<div class="tooltip" data-tooltip="' + i + '">' + $el.attr('title') + '<div class="arrow"></div></div>').appendTo("body");

      // Position right away, so first appearance is smooth
      var linkPosition = $el.position();

      $tooltip.css({
        top: linkPosition.top - $tooltip.outerHeight() - 13,
        left: linkPosition.left - ($tooltip.width()/2)
      });

      $el
      // Get rid of yellow box popup
      .removeAttr("title")

      // Mouseenter
      .hover(function() {

        $el = $(this);

        $tooltip = $('div[data-tooltip=' + $el.data('tooltip') + ']');

        // Reposition tooltip, in case of page movement e.g. screen resize
        var linkPosition = $el.position();

        $tooltip.css({
          top: linkPosition.top - $tooltip.outerHeight() - 13,
          left: linkPosition.left - ($tooltip.width()/2)
        });

        // Adding class handles animation through CSS
        $tooltip.addClass("active");

        // Mouseleave
      }, function() {

        $el = $(this);

        // Temporary class for same-direction fadeout
        $tooltip = $('div[data-tooltip=' + $el.data('tooltip') + ']').addClass("out");

        // Remove all classes
        setTimeout(function() {
          $tooltip.removeClass("active").removeClass("out");
          }, 300);

        });

      });

    }

})(jQuery);
```
Couple things to note: 1) The final demo is going to have the tooltips animated a bit. None of that happens here in the JavaScript. Animations are design. Design is CSS. Thus, we do all that in the CSS. 2) One little design touch on these is that the tooltips slide in and slide out the same direction. In CSS, by just adding and removing a single class and using transitions, that's not really possible. The transition will run in reverse upon the classes removal and thus will slide out same direction it slide in. By using a setTimeout, we can apply a temporary class, and animate that as well. Any more elegant ideas for that, let me know in the comments below.
A Semantic Bummer?
Adding divs to the bottom of the document feels like a bummer. Just doesn't feel very semantic. They aren't connected to the links they came from in any meaningful way through HTML alone.
Also removing the title tag doesn't sit quite right with me. I've heard they don't do much for accessibility anyway, but still. I wish preventDefault() would prevent that from showing, but it does not.
Any ideas on that stuff, let's hear 'em in the comments below.
The CSS: Close Counts
Notice in the OS X screenshot at the top of this article, the background and borders themselves are a bit transparent. I was unable to achieve that here. Those things are possible in general, but the pointy arrow down is an additional element and how the borders and backgrounds connect to each other is just through overlapping and it looks bad with any transparency at all. So, solid colors, NBD.
Oftentimes pointy arrows like we have here are doable with no additional markup or images by using pseudo elements and CSS triangles. In our case, we are going to use a pseudo element, but we'll need a real element as well. The real element (the that the JavaScript inserted in each tooltip <div>) serves as a positional box does the cropping. The pseudo element is the actual pointer. A box styled the exact same way as the tooltip, only rotated 45deg and cropped out by it's parent. Here's the schematics:

The thing goes in the thing

And so:
```
.tooltip, .arrow:after {
  background: black;
  border: 2px solid white;
}

.tooltip {
  pointer-events: none;
  opacity: 0;
  display: inline-block;
  position: absolute;
  padding: 10px 20px;
  color: white;
  border-radius: 20px;
  margin-top: 20px;
  text-align: center;
  font: bold 14px "Helvetica Neue", Sans-Serif;
  font-stretch: condensed;
  text-decoration: none;
  text-transform: uppercase;
  box-shadow: 0 0 7px black;
}
.arrow {
  width: 70px;
  height: 16px;
  overflow: hidden;
  position: absolute;
  left: 50%;
  margin-left: -35px;
  bottom: -16px;
}
.arrow:after {
  content: "";
  position: absolute;
  left: 20px;
  top: -20px;
  width: 25px;
  height: 25px;
  -webkit-box-shadow: 6px 5px 9px -9px black,
                      5px 6px 9px -9px black;
  -moz-box-shadow: 6px 5px 9px -9px black,
                   5px 6px 9px -9px black;
  box-shadow: 6px 5px 9px -9px black,
              5px 6px 9px -9px black;
  -webkit-transform: rotate(45deg);
  -moz-transform:    rotate(45deg);
  -ms-transform:     rotate(45deg);
  -o-transform:      rotate(45deg);
}
.tooltip.active {
  opacity: 1;
  margin-top: 5px;
  -webkit-transition: all 0.2s ease;
  -moz-transition:    all 0.2s ease;
  -ms-transition:     all 0.2s ease;
  -o-transition:      all 0.2s ease;
}
.tooltip.out {
  opacity: 0;
  margin-top: -20px;
}
```
Note the .active class is what does the slide in animation and the .out class does the slide out.
Thanks
To Adrian Adkison for helping with some ideas and code along the way.
Fair Warning about Opera
Opera doesn't support pointer-events in CSS, so this whole demo will appear not to work. That's because the tooltips are actually positioned right on top of the links with just their opacity turned down to 0. If you want to fix it up in Opera, you'll need to literally display none/block them in the JavaScript, or use CSS to move them off the links far enough they don't impede clickability. If someone wants to make that change but have it otherwise function exactly as this demo is, I'm down to update it.
Demo / Download
View Demo Download Files
Bubble Point Tooltips with CSS3 & jQuery is a post from CSS-Tricks
Vendor Prefixes, yadda yadda yadda, strong opinions

Posted: Tue, 15 Nov 2011 22:13:17 +0000

Henri Sivonen:
I think vendor prefixes are hurting the Web. They are hurting Web authors. They are hurting users of browsers. They are hurting competition in the Web browser space.
I'm tempted to raise my fist in disagreement, but you know what, I'm not an oracle. I can't know the future nor know how the world would have turned out if we never used vendor prefixes.
Here's a guess though: if we were to go back in time and influence the decision such that browsers agreed to never use vendor prefixes, we would be worse off. Less browser innovation, less of the spec implemented, and more serious cross-browser problems when some browsers jump the gun and implement specs prematurely.
Vendor prefixes, while being an eyesore and requiring maintenance, have saved us from a dystopian present (maybe).
Direct Link to Article — Permalink
Vendor Prefixes, yadda yadda yadda, strong opinions is a post from CSS-Tricks
Blue Beanie of Thankfulness

Posted: Tue, 15 Nov 2011 15:27:44 +0000

November 30th, 2011 is Blue Beanie Day. It's a (quite literal) hat tip to Jeffrey Zeldman, his book Designing with Web Standards, and a show of support for web standards.
I regret to say that I've never participated in this before. But I'm totally in this year, and I'll tell you why. This year, it feels like being thankful for web standards. Due to the event's proximity to Thanksgiving, I think thats appropriate (forgive the U.S. centric connection). Not that I minded the general comradery spirit of years past. Or even the renegade spirit before that. I just quite like the idea of being open about appreciation.
Why has the vibe changed? The war is over man. The bums lost.
The current state of affairs is that browsers are cooperating more, iterating quicker, and following the same specifications. In fact, how much of the specifications they follow and how well is a point of pride and marketing message for them.
Proprietary web technologies are on their way to extinction. If you are a front end developer today, you are working in world built and defined by web standards.
We're darn lucky to have these standards. Should "The Browser Wars" have ended differently, with browsers rejecting standards, things would be a lot worse. Certainly our jobs would be worse. We may have had to create completely differently coded versions of our websites to work in different browsers, which we may or may not even choose to do based on the difficultly. But it's much bigger than that. I'm quite sure the World would be worse off. Think of all the ways the web helps people around the world. It helps stimulate economies, it helps educate people, it helps people communicate. A lack of standards would have slowed down the growth of the web and thus less of all those good things.
And so without further ado, with love and thankfulness for all:
I'll clean my ragged butt up and do a nice photo, hopefully, on the day.
Blue Beanie of Thankfulness is a post from CSS-Tricks
Five Questions with Tab Atkins

Posted: Mon, 14 Nov 2011 16:06:32 +0000

Tab Atkins (Twitter) is a member of the CSS working group and contributor to several other working groups in the W3C. He works for Google on the Google Chrome Team. Browsers and specs are the bones and blood of our industry so that makes Tab, uhm, a orthopedic surgeon, or something. I ask Tab about all that stuff, and more, below.
*Chris: As a spec writer, what kinds of things are you concerned with when thinking about a new idea for CSS? I know you heavily considered languages when working on the spec for lists. What about things like speed or implementation difficulty? Are there things that would be good for the language of CSS but bad or otherwise not practical for browsers to implement?
Tab: I consider tons of things when thinking up a new idea for CSS. First and foremost is whether the new idea would be useful for authors. Without that, there's no reason to pursue the idea any further. Before Google hired me to work on specs full time, I was a full-time web dev, so I've still got a backlog of things to work through that would have helped me back in my old job.
Another very important consideration is how the new idea will affect CSS as a language. I try to design new features in a manner that's consistent with existing features when possible, and that I predict will be consistent with new features in the future. Sometimes this yields new ideas, rather than just filtering existing ideas, usually in the form of new knobs I can expose for controlling something that's currently magic. For example, the marker-attachment property in Lists 3 came partially out of my testing of existing browser behavior for markers. It turns out the control is also useful for internationalization, when one has mixed-direction list items.
An offshoot of that last point is internationalization. CSS 2.1 made a lot of design decisions based on the assumption of a horizontal left-to-right language like English. It was very obviously written by people who speak English or other western European languages. There are a few sops thrown to rtl languages like Hebrew or Arabic, but none at all for vertical languages like Japanese. We try much harder to make all of these languages work as naturally as possible in our newer specs. For example, the values for 'flex-flow' in the Flexbox spec automatically respect writing mode and direction, but use natural-sounding names ("row" and "column") so that authors don't have to think too hard about them either. A lot of properties that could use 'left' or 'right' in their descriptions or values now instead use the words 'start' or 'end', which flip automatically based on whether the language of the element is ltr or rtl (we call these types of values the "logical directions", as opposed to "physical directions" like 'left').
Speed and implementability are important, but never top-level concerns. I generally assume that browsers will figure out how to do whatever's necessary, and scale things down only when they push back. I've been surprised many times in the past both by something being easy or fast that I thought for sure would get shot down, and by things being widely panned that I was certain would be easy or popular.
Finally, every spec has its individual sets of concerns that I need to worry about. As you mentioned, while writing the Lists spec I thought a lot about languages. This permeates the entire spec, from the obvious aspects like the gigantic list of predefined list styles, to less obvious things like the aforementioned 'marker-attachment' property, the idea for which came from a 2-day meeting I attended about fixing internationalization problems in HTML and CSS. There's always a ton of domain-specific knowledge I have to absorb when writing a spec.
*Chris: I know you subscribe to the idea of "Own Your Data." For instance, not using a third-party service to handle comments on your blog, because that data would be owned by that third-party, not you. How far do you take that idea? Where does that come from?
Tab: I don't actually handle comments at all on my blog right now, because I haven't gotten around to writing support for it. ^_^ But yes, I refuse on principle to give my content to a third-party service. I picked up this idea from Tantek Çelik, an all-around great guy who got into Twitter so early he was able to snag one of the 27 single-letter usernames (@t, for those interested).
If you look back in time, you find huge chunks of people's lives lost from third-party services shutting down. A big, obvious example is the Geocities shutdown from several years back. There are tons of quieter examples, though, of failed social networks or blogging platforms that just reached their end-of-life. If you host your content on someone else's server, you're dependent on them staying around forever. When they inevitably shut their doors, they take your data with them. If you own your data and host it on your own domain and servers you control, you're much less likely to be victim to someone else's failed business plan.
I don't take this to extremes, though - I bow to convenience at times. I let Twitter host all of my tweets, because I consider them transient and wouldn't miss my old stuff if Twitter shut down tomorrow. I let Gmail handle my mail, because it's just so goddam good and I trust Google to stick around for a while. (Plus, they offer convenient data export, so when they do shut down I should be able to get my data out in a format that I can use.) Tantek goes a lot further. He runs a customized blogging platform called Falcon that hosts nearly all of his content, including things like tweets, and then syndicates it out to third parties like Twitter. I'd like to eventually augment my own blogging platform to do that sort of stuff as well, but I haven't had the time to focus on it yet.
Even something like hosting my own comments rather than letting Disqus host them isn't taking things far enough, though. Earlier this year, Tantek ran the first ever IndieWebCamp, a 2-day dev camp focused on the concept of owning your data. One of the most interesting discussion sessions there was about pubsub systems, and how we can leverage them to allow commenters to own their own comments on our blog posts. We already have crappy versions of this in the form of pingbacks, but what if you could post on Twitter or Facebook or your own blog in response to someone's blog post, and have it show up on the blog? What if other people could continue replying to your comment, and having the entire thing centralized and displayed under the post? We have all the technology to make this happen, and some very smart people are working on making it easy to do.
A final aspect of Own Your Data that's very important is preferring well-known text-based formats. I ditched mySQL last year in favor of a bespoke JSON-based datastore for my site. It's less powerful and less efficient than SQL, but you know what? I don't need that power. I'm not running a huge corporate site with tens of thousands of visits a day. What I do need is the ability to easily back up my data and, more importantly, restore it in the future regardless of what technologies have gone in or out of favor. We'll always be able to parse JSON, even if JSON suddenly gets rejected en masse, because it's just so simple. I write my posts in Markdown and convert them to HTML, again because both of those are well known and easy to parse even if they become unpopular in the future. As far as I'm able, none of my data is stored in a proprietary format, because then I'm at the mercy of the company owning that format. In some cases I must bow to efficiency and use a binary format, such as for storing images or videos, but then I always choose an open well-known format, as it's more likely that I'll be able to find decoders for those formats in the future.
*Chris: You work directly for Google. Working on web standards isn't a directly profitable thing. Is it simple big-thinking like: "Web standards are good for the web and what is good for the web is good for Google." Or is there more to it?
Tab: No, you pretty much got it. Remember that our corporate motto is "Do No Evil", so our money-making is done in that spirit. We made Chrome (and made it open-source!) simply to make a better browser (the good) which is good for users (more good!) and ultimately good for Google (the money-making).
Good web standards make the web better. If native apps are easier to write, or prettier, or give you abilities that the web doesn't have, authors will write them instead of web pages. It's harder to sell ads on native apps, so Google funds my work on web standards to help plug those deficiencies and make the web the best place to write apps.
Note that my actual work is independent of anything Google might specifically want for its other projects. For example, our various web-apps like Gmail or Docs are just a source of use-cases for new features like any other large app on the web. I do what I think is best for authors and the web, and that lifts everyone's boats.
*Chris: When Dart was first revealed, people compared it to JavaScript and the common attitude was "JavaScript has already won." I'm sure that fact that JavaScript has more browser support was not lost on the Dart team. What's your take?
Tab: Personally, I think it's ludicrous to try and replace Javascript at this point. The common attitude is right - barring any major missteps or a total feature-freeze for several years, Javascript has already won.
That said, I think Dart will end up being very valuable in many ways. There are a million small ways we could make the web better for authors, but each one individually isn't of much value and is easy to reject. It's only when you imagine them all working together that you see the immense value in them. I and other JS hackers within Google, like Alex Russell and Erik Arvidsson, have worked closely with the Dart people to redesign the DOM APIs for Dart to make them smaller, saner, and more consistent with the rest of the language. For example, when you get a list of an element's children, it's an honest-to-god List in Dart (similar to JS's Array), not a special NodeList type that lacks all the useful List functions. Other parts of the API return proper Maps or Sets for the same reason. This means you don't have to memorize a set of custom-named, low-power functions or attributes for the DOM - you can just reuse all the knowledge you already have. Since this has been done throughout the DOM API, the benefits are clearer, and we can use this to help sell the same improvements for the Javascript DOM APIs.
Tangential to that, Dart is also meant as a server-side language, similar to running JS in Node. There's nothing wrong with that - the server-side space is wide-open, and doesn't have the same compatibility and coordination constraints that a client-side language does.
*Chris: In software, it's smart to worry about feature bloat. You can't add new features forever without making that software worse. It can become harder to learn, harder to explain, harder to make features intuitive and discoverable, and slower running (to name a few). Do you worry about this with CSS?
Tab: Yes, always. I have a bit of a reputation in the CSSWG for pursuing a lot of new features and syntax, but I'm always conscious of bloat. That concern, though, is in direct competition with other concerns, like making sure the web can match native apps, so I'm always juggling things.
Counter-intuitively, sometimes adding new features makes things less complex, when they're designed well. Take CSS layout, for example. I'm an old hand at bending HTML and CSS to my will and making semantic markup match the Photoshop mockups I've been given. These skills have been hard-won, though, and I know (from helping a lot of other devs) that not everyone has the same facility with it that I do. You shouldn't have to be a genius to make an attractive, responsive site, but that's essentially the requirement these days. That's why you see so many layout frameworks.
We're solving this problem in CSS by designing new layout models. Block layout and floats were designed for documents, not apps, which is why it's so painful to use them. Flexbox and Grid Layout are two cooperating attempts to make layout models that are good for applications. I'm working closely with Microsoft (who provides my co-editor on Flexbox, and who is the primary driver for Grid) to keep the specs in sync, so that concepts you learn in one model can be reused in the other model.
Another way we try and keep things simpler is to defer to other languages for things that they do better. There are lots of things we could add to CSS that are currently being done in Javascript. We've taken some of them where we can provide a real benefit, like Transitions and Animations, but there's still quite a lot that JS is just better suited for. SVG is another example. Again, when we can provide a real benefit, like the much simpler and more compact linear-gradient() and radial-gradient() functions instead of the <linearGradient> and <radialGradient> elements, we'll just copy features into CSS. But quite often these days we'll just use SVG directly, and define a simple interface to it. For example, the Filters spec has a handful of predefined filter functions with a simple syntax, but lets SVG handle more complex or powerful filters with the existing SVG filter elements, and just provides a way to point to them. Another example is the element() function in Image Values, which can point directly to an SVG paint source like a gradient or a pattern and use it natively. This is somewhat useful now, but will become much more powerful in the future as SVG2 adds things like mesh gradients. I'm a member of the SVG Working Group as well, so I have a good view of how the future will turn out and how we can tune CSS to leverage it more effectively.
*Chris: Thanks Tab!
Five Questions with Tab Atkins is a post from CSS-Tricks
Yes/No Ipsum!

Posted: Wed, 09 Nov 2011 22:19:44 +0000

I've heard a number of people make statements lately like: "If you're using Lorem Ipsum text, just stop it." Or similar. That argument, expanded, goes something like this. Design exists to serve content. Lorem ipsum is fake content. If you're already designing, and you are using fake content, you are not serving the content and thus not doing your job as a designer correctly.
Pretty extreme, I think. Karen McGrane is one of the only people I've heard argue the other way, in her article "In Defense of Lorem Ipsum". She asks:
For those who would argue that it’s impossible to evaluate designs without real content, let me ask this: why then, is it okay to evaluate content out of context of the designs?
I don't know about you but I've worked on designs where only after it's been fleshed out a bit and starting having a life of it's own did it suggest the best copy. It actually makes more sense to me to not start with specific copy and let that happen more naturally during the design process.
The cool part about this discussion is that everyone has good points. Instead of "No Ipsum!" we should probably be saying "We should involve content strategy right away in new projects." Instead of saying "Yes Ipsum!" we should probably be saying "Fake content can be a useful part of the design process, like picking colors or wireframing."
Kristina Halvorson, in a comment on Karen's article:
Pointing to “lorem ipsum” as a problem is, really, simply an attention-grabbing way to start the bigger conversation, which is that very few people have a process in place for planning content.
It’s a talking point around which to structure an introduction to content strategy.
Sorry if this is dead-horse-beating, but it's been running through my head and sometimes the only way to get it out is blogging it =)
Yes/No Ipsum! is a post from CSS-Tricks
The Future, Glassy?

Posted: Tue, 08 Nov 2011 23:48:39 +0000

Bret Victor:
Now, take out your favorite Magical And Revolutionary Technology Device. Use it for a bit.
What did you feel? Did it feel glassy? Did it have no connection whatsoever with the task you were performing?
Direct Link to Article — Permalink
The Future, Glassy? is a post from CSS-Tricks