The original title was, “CSS’ Units of Measurement and their impact to the quality of responsive websites”, and then I thought, “I wouldn’t want to read that — there’s no way someone else would.” So I figured I’d try something semi-punny, and then hit you with the real title inside, like a journalist or something.
Whatever. Here’s the big idea:
It’s not 1999, or 2009. We can’t predict, reliably, what devices consumers will use to consume our content. Designing a website that looks a specific way in a specific breakpoint is getting harder to do, and it makes CSSing those websites more unruly. A factor that contributes to that unruliness is the unit of measurement.
There’s more than just
em to consider now. There are many other units of measurement that can have a positive impact in a responsive website.
Having a propensity to be pedantic, today I finally reached a small breaking point with
line-height. In the grand scheme of communicating design requirements, this is a tiny little thing. But, a good understanding of line-height can improve design, documentation, and code quality all at once. If you’re not using a unitless line-height right now, I’d like to encourage you to consider it because of the benefits to the browser and your team.
We all fix things, and we all solve things. But sometimes we don’t know whether we’re fixing a problem in CSS, or solving it. And I realize that even I’m guilty of not recognizing one over the other. This isn’t good. The inability to discern a “fix” from a “solution” has huge implications for the sustainability and scalability of a code base. And if we turn a code base into a collection of fixes, we kill page load, the user experience, and ultimately ourselves.
This is part three of a series called “Front-end for the Middle”. Honestly, I didn’t mean to write three posts. But when one post is over 2,000 words without being finished, it’s time to get slicing.
Previously, we’ve talked about directing a front-end developer’s focus away from design, and on to content. And we’ve also discussed semantics and schemas. Now I want to zero in on the impact that the new HTML5 semantic elements has on how individual pieces of content relate to one another.
This is a continuation of a previous post that I wrote, entitled Front-end for the Middle: Focus and Design. Previously, we established that it’s better for a front-end developer to be focused on content, rather than design. In this post, we’re going to move into a discussion on how HTML semantics can influence what happens in the CMS. If your CMS-of-choice is Tridion, then the operative term is schema.
A few months back I had the opportunity to present at the Tridion Developer Summit in Amsterdam. Gino Toro, (former) product manager for Media Manager was going to be speaking on Media Manager, so I decided to try a different topic. After debating on a few different topics, I settled on “CSS3 and HTML5 for a better content author experience.” It seems like a lot, but the premise is simple: you can do things with your front-end that can make it easier for CMS users. So what I’d like to do now is zero in on one aspect of “Front-end for the middle”: Good markup makes for a good Tridion implementation.
Alas, it’s a really long topic, so first I’d like to explore the basic issue of how design impacts front-end devleopment.
Ever looked at a component in Tridion and wondered, “what schema does that use?” I have. All the time. Opening up the component to find out what schema it uses is just too many clicks. Ain’t nobody got time for that!
I want to select an item, right-click on it, click on something in the context menu, and be told what schema that component uses. Since Alchemy 4 Tridion is what all the cool kids are using, I’ll use it to make a GUI extension that does exactly that.
So, this week I finally decided to do a deep dive into Alchemy for Tridion, which is the latest hipster technology to have been created for Tridion. If you’re unfamiliar with Alchemy for Tridion, I had a little bit to say about it when I summarized the SDL Web MVP retreat. Alchemy is the way to make GUI extensions for Tridion now. But this week, I whipped out an old VM, tried to make a plugin, and had tons of heartache. Turns out there’s some ‘gotchas’ if you’re using Visual Studio 2012.
In January of this year, I learned that for the second time I had been honored with an award by SDL. In 2014, I’d been given the SDL Tridion MVP award. This year, I earned the SDL Web MVP award. And it was pretty rad.
If you’re unfamiliar with the SDL Web MVP awards, then you may be unfamiliar with the perks:
- A really cool badge
- Access to a super secret Skype chat room
- Access to a super secreter Slack chat
- Beach-appropriate bling
- An uncomfortable dependence on Portuguese-speakers for your survival
Now, because of non-disclosure agreements and sternly-phrased email signatures, I can’t discuss the details of the first three bullet points. However, because I never learned the Dutch/Danish/Dom translation of “What happens in Portugal stays in Portugal”, I feel confident that I can fill you in on those last two bullet points without fear of reprisal. So, I’m going to summarize them in TAPS: Tridion, Alchemy, Performance, Seafood
This year, SDL decided to host a hackathon that launched at SDL Innovate. And I, having a full time job, school, and a side project, needed something to keep me busy. So I decided to participate. I had some ideas for Media Manager, so I figured this was a good excuse to start experimenting with them.
Then I found out that there was money involved in the Hackathon. So I had an excuse to actually submit something.