Snippets

Scaling an SVG without scaling the stroke

A few days ago, I ran into a little problem when using SVGs. I’d created a reusable set of SVG symbols for a project I was working on, and started sprucing it up with all the pretty icons my designer gave to me. As we all know, one of the biggest benefits to using SVG is the “scalable” part of it, meaning that graphics render perfectly at and size, no matter the original size of the graphic. I’m a huge fan in general of SVG, and implementing them into this project was a no brainer for me.

However, a few of the icons in the design consisted of strokes, and those strokes were always 1px in width, no matter the size. When you scale an SVG, it scales everything about it, so an icon that’s scaled up two times would have stroke widths that are double the size of the original. One such example was a “+” icon that indicated there was more content. I had to reuse that icon at small and large sizes, but:

  1. I wanted the stroke width at all sizes to be 2px
  2. I wanted to create one graphic that I could reuse at any size without scaling the stroke width

Enter The Vector Effect Attribute

One of my favourite things about programming is being faced with a problem. It challenges you to research and find solutions. In this case, I stumbled upon the vector-effect attribute, which conveniently has an available value called non-scaling-stroke. It does exactly what it says, i.e. prevents strokes from scaling as an SVG scales.

[…]

I’d see a scaled up icon including scaled up effects. This one’s dimensions are 4 times the size of the original view box. As such, the stroke would render at 8px. In order to circumvent this, I added the vector-effect attribute to the paths on the original graphic, and set the value to non-scaling-stroke, like this:

Code language: HTML

<circle vector-effect="non-scaling-stroke"/>
<path vector-effect="non-scaling-stroke"/>
<path vector-effect="non-scaling-stroke"/>
Tags

Style List Markers in CSS

It’s a perfectly reasonable to want to style the marker of list items. You know: blue bullets with black text in an unordered list. Or red counters with knockout white numbers in an ordered list.

There is a working draft spec that defines a ::marker pseudo-element that would give us this control.

Code language: CSS

/* Not supported anywhere; subject to change */
li::marker {
  color: blue;
}

It’s possible to do this styling now, though, thanks to CSS counters. The trick is to remove the list-style, then apply the markers through pseudo-element counters.

Code language: CSS

ol {
  list-style: none;
  counter-reset: my-awesome-counter;
}
li {
  counter-increment: my-awesome-counter;
}
li::before {
  content: counter(my-awesome-counter);
 
  /* Style away! */
 
}

Annotation is now a web standard

Many have tried over the years to bring us web annotations. The lack of standards has been one of the key things holding these efforts back– a need we highlighted in the first of our 12 original principles back in 2013 and have been working towards ever since.

Yesterday, on February 23, things took a giant leap forward when the W3C, the standards body for the Web, standardized annotation.

Twenty four years after Marc Andreessen first built collaborative annotation into Mosaic and tested it on a few “guinea pigs” before turning it off, annotations have finally become first-class citizens of the web.

From the W3C Web Annotation co-chairs, Rob Sanderson and Tim Cole:

“Many websites already allow comments, but current […] systems rely on unique, usually proprietary technologies chosen and provided by publishers. Notes cannot be shared easily across the Web and comments about a Web page can only be saved and viewed via a single website. Readers cannot select their own tools, choose their own service providers or bring their own communities.”

 

So what exactly does this mean for you?

Comment widgets may soon become a thing of the past.

The W3C standards (called Recommendations) are a key milestone towards a future in which all pages could support rich layers of conversation without requiring any action by their publishers—because that capability can be built into the browser itself and be available as a native feature, just like web search. The shared vision is that conversations will be able happen anywhere on the Web, or even on documents in native apps, and inline instead of below-the fold, in a federated, standards-based way.