I've hand-built this website and run it on a web server in the Amazon Web Services (AWS) network. Because I'm in complete control I get to do anything I want. Because of that choice, if I want something done, I've got to it myself.
An endmark is something I see in illustrated books. It's a symbol or icon placed at the end of a body of text. It's a design flourish signalling to the reader they've arrived at the end.
I think it looks cool and I wanted it on my blog.
I'm a strong supporter of responsive web design (RWD) and development. I want my website to work wherever the reader needs it to. For example: a small phone screen, a medium laptop display, or a huge external desktop monitor.
For the most part RWD is phenomenal. The exact same text copy and product photos works on any sized screen no matter what. It takes a little extra planning, but it's worth the results.
In the case of my endmark I wanted media queries to support these small, medium, and large breaking-points:
You might think scaling an image down means setting its
width attribute to 75%
via CSS style at the mobile breaking-point. Then scaling it up for desktop monitors means
width to 150%.
width attribute is a good first pass to try, but it won't work.
In fact it tells the
image to fill based on the pixel size of the element which contains it. Perhaps that's
<section> that we don't really know the size
it's totally dynamic. Sizes of various elements in the HTML hierarchy are based on the browser
flowing a page onto whatever sized screen is used by the user client.
For a second-pass try we could hard-code the
<img> based on pixels. We
know what the original image size is, say 200x200, and we could just write 100x100 and 300x300
and call it a day. It would work, and we would feel dirty about it. Those numbers would float
in our dreams, haunting us like a splinter in the mind.
Hard-coding is a bad smell and we all know it's a mistake when we see it in other people's code. Why? It's brittle! Art assets are data, and easily swapped out by anyone on the team at any time in the future.
When that happens our style breaks, it looks ugly, and people yell and cry. By the way, it's perfectly fine to feel like crying in the face of stressful disappointment!
What I really want is the image to be 75% of its original size on small screens, 100% normal
by default on laptop displays, and 150% of its original size on external monitors. For
that I wrote styles leveraging the CSS
transform: scale(width, height)
capability. It's very cool!
Transformation is a math term from geometry class. It means an object is being manipulated in space by one of three ways:
Your art direct might see all of these percentages being used for width, and the height is simple computer by the browser, and ask you to tell exactly what numbers they are. Their UI design must be "pixel-perfect."
Tell them the age of pixel-perfect is over. There's so much random hardware out in the word we can't possibly know what to expect and develop for it. Retina displays actually compute sub-pixel rendering. Frankly, why should any of us seek out that level of control? Make it work!
Pictures stored in pixel-based file-formats such as
PNG, can lose detail when scaled. They look fuzzy when shrunk
down, and become very blocky and harsh scaled up. This is traditional, and we've seen it a
million times on computer screens.
My image is in a flexible format called Scaled Vector Graphics. Pictures
SVG files are vector-based graphics. They're built in
a way that makes it easy
and clean to shrink down and scale up clearly.
If you're wondering exactly which graphic I'm talking about, it's the logomark that ends each article on my blog. There's one a few inches down from this sentence.
You can use this web page as a live demo of the scaling technique. Swipe the browser larger and smaller to see the behavior. Dig deeper. Try opening up the developer tools and changing the style attributes to further learn.
If you want to experiment with CSS-transform, but don't have an
SVG file of your
own, feel free to use mine as a placeholder. It's sitting out there on the Internet stored on
my public-facing webserver.
I used Sketch to make this SVG image. Browsers make it
very easy to simply drop-in a SVG file as part of the
<img> tag. In the
code snippet above you'll see how the
src= attribute handles it simply.
Are you curious what a
SVG file looks like inside? Peek inside.
Download the file and open it in your favorite programmer's editor. It's not a traditional computer image. It's not a rectangular map of pixel colors at all.
In fact it's a text file storing a series of drawing commands interpreted by a graphics engine. That's how a browser can recreate the image, precisely transformed, no matter what size screen it's showing on.
Pretty cool, right?