Addy Osmani intros a Grunt task for removing unused CSS from your stylesheet before serving it.
While this is certainly a worthy goal, I look at the quotes from people who reduced their stylesheets by 3/4 or more and I'm like holy crap what kinda shop are you running over there?! I know "test, don't guess", but I'd guess that pretty close to 0% of the styles I write are unused. I'm sure HTML changes over time make a orphaned rule here and there, but I'd guess that is largely insignificant.
If you're going to do this, make sure you run it against lots (if not all) of your pages so you aren't removing selectors that are in use, just not on every page. I know I write minor styles all the time that make their way into the global stylesheet since that is cached and used anyway.
Say you have a table header (i.e. <th>) of "Number of Howler Monkey Species by Country" and the data in the corresponding <td> is like "3". That's an awkward mismatch of width.
Awkward
Perhaps not a huge problem for two columns, but if you had 20 that would be very hard to navigate and a poor use of space. A better use of space is to rotate the headers so that the column width can be much narrower.
Rotating 90-degrees is too far though. It makes it hard to read.
Interestingly, we get just about the same amount of space saving if we rotate the headers 45 degrees instead, and they are much easier to read.
The Trick
There are a couple of tricks here.
We're going to need to use transform: rotate() to angle the headers. Chrome/Safari lets you do that right on the <th>, but I had trouble with the text disappearing in Firefox that way, so let's do that within a nested <div>. That
we'll force to be the width we want the column to be (it also didn't work to force the cell narrow directly). We're going to need another nested element as well, so...
Note the magic numbers there. I bet some of you are smart enough to figure out the mathematical relationship to all the other numbers going on in there. In fact, my example started out life as a fork of Jimmy Bonney's Column Header Rotation article. I was able to do it without the skew() stuff he was doing which I think makes it a bit simpler, but he also had figured out some math stuff using tan() and cos() which might be a good starting point if you start digging in yourself.
Fallback
If you go down this road, you might wanna make sure you aren't applying rules that screw up the table if the transforms don't work. Modernizr can test for that and apply support/non-support classes to the <html> element, so you can write stuff like:
/* These aren't needed and will be weird if transforms don't work */ .csstransforms & th.rotate { height: 140px; white-space: nowrap; }
How you want to do the fallback is up to you, but it could be worse than just having the table be super wide:
This article "Shadow DOM" by Steven Wittens is only vaguely about the Shadow DOM. It's mostly about how awful everything is. HTML sucks, CSS sucks, the DOM sucks, SVG sucks, MathML sucks... I don't want to pick on Steven. He is, without a doubt, many (many) times smarter than I am and has well articulated points. Let's go wider.
I see this regularly from people who have been at this a long time and are very smart. They develop a dislike of the systems we have to work with. They see all the warts, mistakes, and especially what they see as deep systemic flaws or historical turns down the wrong path. This is all made worse as we trapse forwards, building upon these perceived cracks in the foundation.
They always have very good points. It's hard to do anything but nod, because they are right, the web does some whacky stuff and has failed us in many ways. Wouldn't it be wonderful if we could throw it all away and work with some new perfectly designed system that meets everyone's modern needs. Sure, of course it would. Do you want to live in your town or a utopian village? I'll take utopia.
Obligatory follow up sentence: but utopia doesn't exist!
There is no alternate layout language for the web. There is no alternative way to deliver accessible content. There is no better replacements vying for the lead here. That's because that's a monumental task. Any contender would need to:
Develop a new system for everything is empirically better.
Get a world of developers to agree that this new system is better and demand it.
Get standards bodies (or something like it) to support it so there is oversight and an independent source of implementation information.
Get all browsers to agree and implement it perfectly.
lol right.
All those things are so insurmountably difficult that it's no wonder it is rarely even attempted. I'd argue that #1 is the hardest. There are plenty of flaws with our current system, but imagine starting from scratch with something this complex.
I feel like what is going on now in web tech is that these problems are trying to be solved on a smaller scale.
It sure is a bummer HTML is our content, but also responsible for semantics, right? It would be nice to do whatever we wanted in there and not worry we were hurting semantics. Hopefully Shadow DOM can help with that. Maybe it can also help with CSS being to over-arching when you don't want it to be.
Maybe flexbox, grid layout, and regions can be the truly powerful and intuitive layout system we've always needed, without the accessibility issues inherent to tables.
SVG isn't perfect, but maybe it's still better than using a raster image format for a vector image? Maybe SVG has the potential to help with icon systems on sites in a better way? Maybe we can start using a new image format that increasingly works with modern browsers.
Maybe preprocessors can be a solution to ease authoring of these complex languages and reduce complexity?
Perhaps we can extend the web right now how we might want to see it, using existing tech.
These things are proving that we can make the web better. We can do it slowly. We can do it with the help of standards bodies. We can educate developers and change their thinking over time. We can use the browsers already out there, so we don't need to fight public behavior.
I think that sounds nice. And I don't think we have much of a choice.
The following is a guest post by Ian Marquette. Ian learned that SVG can have a <text> element, meaning that text could come from a dynamic source while still being able to do cool custom SVG-specific stuff to it.
I was recently working on a WordPress-based website that needed an infographic. Being a proponent of responsive design, I drew the infographic in Illustrator and exported it to SVG for scalability. While tinkering around in the backend I discovered that you can add WordPress custom fields to SVG text elements that allow you to control text-based content from within your WordPress CMS. How awesome is that?
Here I'll explain how I did it, and some further options you might find useful.
Preparing the SVG File
Create the graphic in your vector-editing software of choice. Add placeholder text to the area you'll want to contain user-controlled text. Here I've created a simple graphic for demonstration purposes.
My SVG file. Note that the path is to demonstrate something uniquely SVG. It could be a filter or a stroke or anything else cool that SVG can do.
Now open your SVG file with your preferred editor. You'll have to make some changes to the code. In my example the path had to be changed to a <textpath>, given an ID and linked to using xlink. If I didn't do this, each individual character in my text would have its own tag, coordinates etc.
You can just copy and paste the markup straight into a WordPress template. You could also use on of the other methods of using SVG on your page, such as linking to the file as an object. Essentially it needs to be inline SVG, not SVG used as an or background-image.
You'll want to replace the content between the <text> tags with the following code, replacing custom_field with whatever name you want to give yours:
Now create a custom field in the WordPress CMS with this label and populate it.
Now if you check out that page, you should see the custom text sitting inside your custom SVG graphic! Of course custom fields are just one way to do this that is rather extensible. You could use do the post title this way, menus, or anything else that dynamically spits out text from any CMS.
Custom field added to your SVG
Once it's in there the text can be styled just like regular markup. For instance:
... <textpath class="text-path" ... > ...
.text-path { fill: orange; }
Or any other SVG CSS property. That means using custom fonts via @font-face work just fine. You also have access to nice features such as SVG filters and animation.
19% of people never use the command line at all. The largest group, 27%, only run a handful of commands a day.
18% run 10-50 commands, 15% run 50-100 commands, and 15% run 100-1000 commands. I think it's interesting that this group, taken together (10-1000 commands a day) represent the largest number of people (48%).
The smallest group (6%) run over 1000 commands a day. Some people just live in the shell!
Personally, I'm in the 10-50 group. I'm typically doing things like firing up Grunt, starting a Rails server, and related things to get a dev environment set up.
The idea for the poll was based on the common side-conversation that always seems to accompany conversations about command line tools.
Say a new tool comes out that can only be used through the command line. Whatever it does, the end result is desirable. Some folks will be excited and be talking about it and using it. Some folks will think about using it but never get around to it because it's a bit out of the comfort zone. Some people will bemoan the fact it's a command line tool and write it off completely.
Then there will be some comments lambasting the non command line users. Some comments telling them there is nothing to be afraid of. It's easy to agree with that, since of course learning more is always a good idea. But on the other hand, not everybody needs to know everything and there is some tools that, however nerdy, could benefit from a UI. Tools like CodeKit are proof they are desired and highly used.
I suspect tools like Grunt are both:
Getting more people into the command line
Making the command line less difficult
Giving more bang-for-the-buck for learning it
If a new command line tool comes out these days that does something cool, chances are it already is a Grunt plugin or someone will make it one in short order. So now you don't have to learn something new, you just include the Grunt plugin and configure it, which you've probably already done a number of times.
I'm also of the opinion there probably will never be a GUI for Grunt - at least not one that is any good - because what matters in Grunt is the configuration of plugins. Each plugin is so different it would require it's own special UI unique to it, not something generic.
The most interesting bit I've learned here is how broad the spectrum is in command line usage, ranging all the way from zero experience to mastery. That's much different that most things we discuss in web tech, so it's good to keep in mind.
Throughout the life of this site, I've flipflopped (nope, yep) on whether or not I show social sharing buttons on articles. As anything, there are arguments in either direction. We can cover that briefly, but I also want to gather a bit of data on the subject, so that will be our next poll.
The impetus for this poll is the comments I get from people during times where there are no sharing buttons present on my articles. Like:
Hey Chris, I wanted to share an article from CSS-Tricks but there were no sharing buttons. Why?
Sometimes that will come in the form of the tweet, which is sometimes just someone wanting to know if I have any specific thoughts on that, but sometimes someone who legitimately thinks they can't share pages that don't have sharing buttons. Leading me to wonder:
I wonder how many people assume that an article is un-shareable if it doesn’t have sharing buttons. And if that’s any significant loss.
Luke Wroblewski collected some data indicating 0.25% of pageviews will share the page (from great studies like this). That is with sharing buttons present. Make me wonder what that number would be without sharing buttons. Presumably lower, but just to be clear, people can share any link they want, they don't need a button to do it, and certainly some people prefer doing it that way.
There is also the issue of how much an individual share matters. One share from a trusted and highly followed source is better than 1,000 spambot shares. My unscientific guess is that shares you miss out on by not having buttons present aren't worth much anyway. And in fact having sharing buttons can be a turnoff to the same type of people you want sharing the page. I'm not sure how we could get data on that, so let's just go with:
This best describes how I share links on my social media site(s) of choice:
I typically only share pages that have sharing buttons.
I don't use ever use sharing buttons. I share my own way.
I can go either way.
Actual poll is embedded on the site.
I'm not sure if we'll land on any perfect answer, but it will be interesting to think about.
General positives about sharing buttons:
They can make sharing easier, more sharing means more traffic
They remind people to share
You might get more sharing
General negatives about sharing buttons:
They can negatively affect page performance
They can look garish
Low numbers can look embarrassing
At the time of this writing, I have social sharing buttons on this site in the form of simple anchor links that link to those services dedicated sharing pages (rather than the JavaScript powered sharing buttons with all the extra functionality). Like these.
