Articles by

Chris Coyier

Brian Barrett:

Tired of Twitter? Facebook fatigued? It's time to head back to RSS.

I'm an RSS reader lover, so I hate to admit it, but RSS ain't going mainstream. It was too nerdy 20 years ago and it's too nerdy now. RSS is still incredibly useful technology, but I can't see it taking off alone.

For RSS to take off, it needs some kind of abstraction. Like Flipboard, where you can get started reading stuff right away and feeding it RSS isn't something you need to handle manually. Apple News is kinda like that. I'm a little love/hate with Apple News though. I like reading stuff in it, but I've stopped publishing in it because it became too much work to get right and have it look good. It's like managing a second site, unlike RSS which just brainlessly works when your CMS supports it. A little-known feature of Apple News was that it used to be able to function as an RSS reader, but they removed that a couple of years ago. Boooooo.

(more…)

Eric Bidelman introduces the CSS Typed Object Model. It looks like it's going to make dealing with getting and setting style values through JavaScript easier and less error-prone. Less stringy, more number-y when appropriate.

Like if we wanted to know the padding of an element, classically we'd do:

var el = document.querySelector("#thing");
var style = window.getComputedStyle(el);
console.log(style.padding);

And we'd get "20px" as a string or whatever it is.

One of these new API's lets us pull it off like this:

console.log(
  el.computedStyleMap().get('padding').value,
  el.computedStyleMap().get('padding').unit
);

And we get 20 as a real number and "px" as a string.

There is also attributeStyleMap with getters and setters, as well as functions for each of the values (e.g. CSS.px() CSS.vw()).

Eric counts the benefits:

1. Few bugs.
2. Arithmetic operations & unit conversion.
3. Value clamping & rounding.
4. Better performance.
5. Error handling.
6. Naming matches CSS exactly.

Patrick H. Lauke covers the future CSS pseudo class :focus-visible. We're in the early days of browser support, but it aims to solve an awkward situation:

... focus styles can often be undesirable when they are applied as a result of a mouse/pointer interaction. A classic example of this are buttons which trigger a particular action on a page, such as advancing a carousel. While it is important that a keyboard user is able to see when their focus is on the button, it can be confusing for a mouse user to find the look of the button change after they clicked it – making them wonder why the styles “stuck”, or if the state/functionality of the button has somehow changed.

If we use :focus-within instead of :focus, that gives the browser the freedom to not apply focus styles when it determines it's unnecessary, but still does when, for example, the element is tabbed to.

The scary part is "instead of". We can just up and switch with browser support as it is. Not even @supports can help us. But Patrick has some ideas.

(more…)