The fourth edition of Eric Meyer and Estelle Weyl's CSS: The Definitive Guide was recently released. The new book weighs in at 1,016 pages, which is up drastically from 447 in the third edition, which was up slightly from 436 in the second edition.
You love HTML emails, don't you?
As a developer, probably not... but subscribers absolutely do. They devour them, consume them on every device known to man, and drive a hell of a lot of revenue for companies that take their email marketing seriously.
But most web developers tasked with building HTML emails merely want to get them out the door as quickly as possible and move on to more interesting assignments. Despite email's perennial value for subscribers, tight timelines, and a general loathing of the work result in things falling by the wayside; and, just like in the web world, one of the first things to be set aside in email is accessibility.
The Wix dev team throws their hat into the CSS preprocessor ring:
Stylable is a CSS preprocessor that enables you to write reusable, highly-performant, styled components. Each component exposes a style API that maps its internal parts so you can reuse components across teams without sacrificing stylability.
- Scopes styles to components so they don’t “leak” and clash with other styles.
- Enables custom pseudo-classes and pseudo-elements that abstract the internal structure of a component. These can then be styled externally.
- Uses themes so you can apply different look and feel across your web application.
At build time, the preprocessor converts the Stylable CSS into flat, static, valid, vanilla CSS that works cross-browser.
Looks like Sass luminary Chris Eppstein is getting in on the game of scoped styles with the not-yet-released CSS Blocks. And think of Vue's support for
<style scoped>, and the popularity of utility libraries. I think scoped styles might be the hottest CSS topic in 2018.
Accessibility is a hot topic these days, and the older we web-makers get, the hotter it's going to become! That might be a snarky outlook, but what I'm trying to say is that it's about time we start designing the web for everyone because the web was meant to be for everyone, and less and less are we able to predict where, when, and how our work will be consumed.
HTML has given us loads of form validation stuff in the last few years. Dave Rupert puts a point on the UX problems with it:
If you’ve ever experimented with HTML5 Form Validation, you’ve probably been disappointed. The out-of-box experience isn’t quite what you want. Adding the
requiredattribute to inputs works wonderfully. However the styling portion with
input:invalidsorta sucks because empty inputs are trigger the
:invalidstate, even before the user has interacted with the page.
Fortunately, there is an
invalid DOM event that does fire with useful timing: when the form is submitted. Remember this doesn't buy you super deep browser support though. If you need that, look into polyfilling. I imagine the future of form validation is either HTML/CSS offering better and more controllable UX, or this.
Harry Roberts wrote about design systems and how compromise has to be baked into them from the very start. He argues that we can’t be dictatorial about what is and isn’t permitted because design, whether that’s the design of a product, service or system, is always about compromise.
Amanda Silver introduces "Visual Studio Live Share", which:
enables developers using Visual Studio 2017 or Visual Studio Code to collaborate in real-time!
GitHub's Atom editor also has Teletype, which:
lets developers share their workspace with team members and collaborate on code in real time.
Atom has the concept of a host, in which:
As the host moves between files, collaborators follow along with the active tab automatically.
The Apple Watch comes with a stock app called Breathe that reminds you to, um, breathe. There's actually more to it than that, but the thought of needing a reminder to breathe makes me giggle. The point is, the app has this kinda awesome interface with a nice animation.
Color is pretty good for separating things. That's what your basic pie chart is, isn't it? You tell the slices apart by color. With enough color contrast, you might be OK, but you might be even better off (particularly where accessibility is concerned) using patterns, or a combination.
The topic of disabling links popped up at my work the other day. Somehow, a "disabled" anchor style was added to our typography styles last year when I wasn't looking. There is a problem though: there is no real way to disable an
<a></a> link (with a valid
href attribute) in HTML. Not to mention, why would you even want to? Links are the basis of the web.
At a certain point, it looked like my co-workers were not going to accept this fact, so I started thinking of how this could be accomplished. Knowing that it would take a lot, I wanted to prove that it was not worth the effort and code to support such an unconventional interaction, but I feared that by showing it could be done they would ignore all my warnings and just use my example as proof that it was OK. This hasn't quite shaken out for me yet, but I figured we could go through my research.
I could probably list about 100 reasons, since as a founder, user, and (ahem) PRO member of CodePen myself, I'm motivated to do so. But let me just list a few here. Some of these are my favorites, some are what PRO members have told us are their favorite, and some are lesser-known but very awesome.
It wasn't long ago when Mikael Ainalem's Pen demonstrated how you might use SVG outlines in HTML then lazyload the image (later turned into a webpack loader by Emil Tholin). It's kind of like a skeleton screen, in that it gives the user a hint of what's coming. Or the blur up technique, which loads a very small image blurrily blown up as the placeholder image.