Datalists for Different Input Types

CSS-Tricks

Datalists for Different Input Types

I saw an HTML5 date input the other day, which had the dropdown arrow on the right, which I've grown accustom to clicking to reveal a calendar datepicker in which to choose a date.

Typically, that looks like this:

<input type="date" />

I've seen variations on this before, like when you use a week input instead of date:

<input type="week" />

But I hadn't seen this before:

Turns out that's what you get when you apply a <datalist> to an input of that type! Who knew!

The format is like this:

<input type="date" list="days">
<datalist id="days">
  <option label="Chris' Birthday">1980-08-26</option>
  <option label="Apollo 11 Moon Landing">1969-07-20</option>
  <option label="DDay">1944-06-06</option>
</datalist>

The values for each of the options just need to be valid values for the input, otherwise they just don't show up.

Browser Support

As far as I understand it, the spec doesn't dictate any particular UI requirements for HTML5 input types. If a browser wants to build a datepicker thingy, great, but not doing it doesn't violate the spec. Thus, this additional UI nicety also isn't required. I just mention that because lack of "support" here doesn't indicate a browser is doing a bad job.

These fancy datalist inputs appear to largely be a Blink thing.

A quick check around the latest version of browsers, just testing input type="date" with a datalist:

Chrome 38 = works

Opera 23 = works

Safari 8.0 = doesn't support input type="date"

Firefox 32 = doesn't support input type="date"

Internet Explorer 11 = doesn't support input type="date"

iOS 8.1 = date works / datalist doesn't (see screenshot)

Android 5 = works (see screenshot)

Opera Mobile 11.5 = date works / datalist doesn't

"Support" again meaning "doesn't do anything special for" - but falls back to a useable text input.

iOS 8.1 - you get the date controls but nothing special for the datalist.

Android 5

Here's the rub with features like this. If it's just a little nicety you can provide, but not crucial, just use it and think of it as progressive enhancement. If it's totally vital that all users to your site need UI for choosing recommended options and you support browsers that don't support this, you'll need either a polyfill or a custom solution.

Other Types

Date doesn't get to have all the fun! While putting this together, I ran across Eiji Kitamura's comprehensive test page for all this. It's not just text and date inputs that datalist can work for, it's all the variety of date inputs as well as color and range!

type="range"

Opera 23. Shows little ticks, dragging across them, the rubber kinda "sticks" to each point as you pass.

Android 5

IE 10 - So this isn't entirely Blink...

Opera Mobile 11.5

type="color"

Android 5

A little dangerous on Opera Mobile 11.5. It supports the datalist, but ONLY those in the datalist, there is no way to activate a more generic color picker or manually type in another color.

It's fine in desktop Opera (23)

---

Datalists for Different Input Types is a post from CSS-Tricks

more info...

How SVG Shape Morphing Works

CSS-Tricks

How SVG Shape Morphing Works

While animating SVG with CSS is easy and comfortable, CSS can't animate all the SVG properties that are possible to animate. For instance, all the properties that define the actual shape of the elements aren't possible to change or animate in CSS. You can animate them through SMIL though. Sara Soueidan covers this in her guide to SMIL here on CSS-Tricks, but I thought I would shine a light on this particular ability.

Most important fact: the shapes need to have the same number of points

Otherwise, the animation will just fail. The shape won't disappear or anything, but it won't animate.

It's not extremely obvious how many points a shape has just by looking at the d (in the case of a path) or points attribute (in the case of a polygon) so you may just need to start in a vector editor program with a single shape and work from there.

1. Start with the most complicated shape

In this demo I'm going to morph from a star to a check. The star is more complex:

Save a copy of that SVG, then make a new copy for the next shape.

2. Make the next shape with those same points.

Drag the points around until you have your next shape.

3. Use the starting shape on the SVG shape element itself

<svg viewBox="0 0 194.6 185.1">

  <polygon fill="#FFD41D" points=" ... shape 1 points ... ">

  </polygon>

</svg>

4. Add an animation element that animates to the next shape

<svg viewBox="0 0 194.6 185.1">

  <polygon fill="#FFD41D" points=" ... shape 1 points ... ">

    <animate attributeName="points" dur="500ms" to=" ... shape 2 points ... />

  </polygon>

</svg>

That animation will run immediately, so we'll need to fix that up a bit.

5. Trigger the animations as needed

SMIL has the ability to handle interactions like clicks and hovers, so long as all that happens within the SVG itself. For instance, you could begin the animation when it's clicked on, like:

<polygon id="shape" points=" ... shape 1 points ... ">

  <animate begin="shape.click" attributeName="points" dur="500ms" to=" ... shape 2 points ... />

</polygon>

That's pretty neat, but it's a little limiting since you can only handle clicks from other elements right in that same SVG. Perhaps this SVG is just a part of a <button> and you want to run the animation on any click on that button.

First give the animation an ID so we can find it with JavaScript, and then prevent it from running with:

<animate id="animation-to-check" begin="indefinite" ... />

Now you can get a reference to that animation and kick if off how you like:

animationToCheck = document.getElementById("animation-to-check");

// run this on a click or whenever you want
animationToCheck.beginElement();

Demo

This demo actually has four animations. One to morph the star to a check, one to change the color, and then both those same animations in reverse. Clicking the button checks the state of the button and then runs the appropriate ones.

See the Pen Shape Morph Button by Chris Coyier (@chriscoyier) on CodePen.

Would be pretty cool for charts, like this old Raphael demo:

---

How SVG Shape Morphing Works is a post from CSS-Tricks

more info...

Lobotomized Owls

CSS-Tricks

Lobotomized Owls

I had a post in my drafts for CSS-Tricks recently I called "Removing the Space from the Bottom of Modules". It's all about that tricky situation where you want even padding all the way around some elements to visually separate them. But elements inside will also need bottom margins, and that might lead to extra space along the bottom where that margin hits the padding.

Apparently I'm getting old and losing my mind, because I've already written about it. But I didn't come to any stunning conclusion in that article. The best I came up with was a kinda gross compound selector that I don't even want to talk about.

Heydon Pickering does have a stunning conclusion for this issue:

* + * {
  margin-top: 1.5em;
}

I'd definitely try that in a new project. It does make me think that future CSS could help us here though. Perhaps specifying that a particular edge of padding was allowed to collapse into margin?

Direct Link to Article — Permalink

---

Lobotomized Owls is a post from CSS-Tricks

more info...

Sponsor: Hack Reactor’s Immersive Remote Beta Course

CSS-Tricks

Sponsor: Hack Reactor’s Immersive Remote Beta Course

Hack Reactor's Coding School is accepting applications for its next online immersive course, Remote Beta. Their team of exceptional instructors and staff work towards a two-fold mission of empowering people and transforming education through rapid-iteration teaching. Students build the skills and confidence they need to graduate as mid-to-senior level engineers and work for top tech companies in both backend and front end tasks.

Apply today for an upcoming onsite or online cohort and be on your way to becoming an engineer in 12 immersive weeks.

Two anecdotes from me:

1. I just watched the documentary Ivory Tower and it's a pretty interesting look at the state of universities. One thing is for sure: education is changing.


2. I now have two personal friends who have transformed their career through coding schools.

Direct Link to Article — Permalink

---

Sponsor: Hack Reactor’s Immersive Remote Beta Course is a post from CSS-Tricks

more info...

CSS-Tricks Chronicle XIX

CSS-Tricks

CSS-Tricks Chronicle XIX

Today I hop on a plane to Norway for the Trondheim Developer Conference. First time there. Can't wait. The conference isn't until Monday, but I suck at traveling to Europe. I'm a big baby about jet lag, so I like lots of extra time to acclimate.

---

I was on Craig McKeachie's Front-End Developer Podcast in the episode How to use custom fonts and @font-face.

I also got to be on Real Thread's Local Masters podcast.

---

Things are going well at CodePen. We just recently hit 2,000,000 Pens created. We've been doing a bunch of maintenance work, a lot of it is kinda unsexy behind the scenes stuff, but I appreciate work like that more and more the longer we're around.

One of the more public-facing features I worked on was converting the layout of the editors to use flexbox throughout. That made it easier to offer resizeable editors, a hotly requested featured since we launched.

We've been continuing our podcast series CodePen Radio with recent episodes including Responsibility and Churn.

One cool thing that I'm sure some of you can make us of: we're giving away 2 weeks of PRO for free. Just click a button to activate yours.

So much more to come!

---

At the end of August I was back at Hilton Head Health trying to keep healthy lifestyle stuff in check. I left right on September 1st and spent that entire month eating vegan. It wasn't life changing, but I enjoyed it, and hit my all time low weight. Sadly I've come back up a little, so I need to watch it.

---

Dave and I are still enjoying the heck out of doing ShopTalk. We'll have episodes every week until around Christmas where we'll probably take a few weeks off.

Don't miss Web Standards Southern Gentlemen in the last RAPIDFIRE.

---

Since I last chronicled, I was at BlendConf which was a huge and wonderful conference. I met a bunch of folks there that I've been wanting to meet. I was vegan at the time and we scouted out the restaurant Bean to eat at, which I loved so much we went back twice. I had also just set up a turntable at home my friend gave me, and so went record shopping at Lunchbox which was pretty sweet. I love the idea of hitting up local record stores in cities I visit.

I also was at An Event Apart Austin, which was super good even as compared to other AEA's, which are always good. I feel like I'm always treated very well as a speaker at conferences, but I extra appreciate the AEA organizer clan and how welcome they make me feel. Shout Jeffrey, Marcy, Toby, Steven and all! Some new very important things clicked for me listening to Mat Marquis and talking with Jason Grigsby about responsive images. Particularly this mostly-use-srcset business.

At BlendConf I met Nicole (and Max) Fenton and at AEA Austin I met Kate Kiefer Lee - the authors of Nicely Said. I look up to both of them tremendously for being so damn good at writing about writing.

---

A few weeks ago I was down in Key West (another first!) for a wedding. The whole Team CodePen was there, because it was our friend Ryan's wedding. We all worked together back in the Wufoo days and I love it that we're all still friends. I went pretty Florida Man.

---

I spent some time cleaning up the email that gets sent out around here. If you don't get it yet, sign up here. It's just all the blog posts that get published here but in a nice clean format right in your inbox.

---

Just plugging away here on CSS-Tricks as well.

Behind the scenes, I'm about to cut over to a larger, dedicated database server which I hope will increase the server side speed around here which has been a might slow.

If you're a member of the forums, there are some new settings as part of your profile for when you wish to be emailed regarding @name notifications.

We tried a little chat widget in the forums area to see if people enjoyed realtime chat, but it just wasn't a good fit.

You might notice some new Wufoo ads on the site. They renewed their sponsorship here, which is awesome because obviously I'm a big fan. They are tinkering with some new design over there, so I got a sneak peak at some of that and I designed these new ads in that direction.

You may have also noticed I'm doing sponsored posts here and there on the site. I'm marking them as clearly as I can so you know what is sponsored and what isn't. If you're interested in that, check out Syndicate Ads.

As always I have ten million ideas for things to write about so I'll just keep on writing if you keep on reading.

---

CSS-Tricks Chronicle XIX is a post from CSS-Tricks

more info...

Probably Don’t Base64 SVG

CSS-Tricks

Probably Don’t Base64 SVG

Perhaps you've heard of data URIs. It's a really nice way of including a resource that would have otherwise been a separate HTTP request. The format that you use in a data URI can vary. Essentially you just tell it what content type it is (e.g. image/png), semicolon, then the data of that file.

Like:

<img src='data: ... '>

or:

.bg {
  background: url('data: ... ');
}

For a raster image like a PNG, the data of that image needs to be in base64 format. I'm not a huge expert here, but as far as I understand, base64 is safe for use in something like HTML or CSS because it only uses 64 characters known to be safe in those formats.

On the left, the data of a PNG, which includes characters that have the potential to screw up HTML. On the right, that same image base64 encoded with all safe characters.

Probably better Stack Overflow answer by Dave Markle:

You never know - some protocols may interpret your binary data as control characters (like a modem), or your binary data could be screwed up because the underlying protocol might think that you've entered a special character combination (like how FTP translates line endings).

So to get around this, people encode the binary data into characters. Base64 is one of these types of encodings.

Base64 looks like gibberish, and we often associate gibberish with compression on the web. But this gibberish isn't compression, it's actually a bit bigger than the original because, to quote Jon Skeet on the same Stack Overflow thread:

It takes 4 characters per 3 bytes of data, plus potentially a bit of padding at the end.

I'm not sure how gzip factors into it though. But what I'm getting at here is how SVG factors into this.

You can use data URIs for SVG too.

<img src='data:image/svg+xml; ... '>

.bg {
  background: url('data:image/svg+xml; ... ');
}

For SVG, you don't have to convert the data into base64. Again, not an expert here, but I think the SVG syntax just doesn't have any crazy characters in it. It's just XML like HTML is, so it's safe to use in HTML.

You can leave the encoding in UTF-8, and drop the <svg> syntax right in there! Like this:

<img src='data:image/svg+xml;utf8,<svg ... > ... </svg>'>

.bg {
  background: url('data:image/svg+xml;utf8,<svg ...> ... </svg>');
}

So because we can do that, and we know that base64 often increases the size, might as well do that right? Yep. As a side benefit, the <svg> syntax left alone does gzip better, because it's far more repetitive than base64 is. Say you wanted two versions of an icon, one red, one yellow. You can use the same SVG syntax duplicated just change the fill color. Gzip will eat that for breakfast. Credit to Todd Parker for that tip, and that's also the approach of Grunticon, which data URI's SVG in UTF-8 into CSS.

A Test

To test this out, I downloaded three SVG icons from IcoMoon.

cog.svg - 1,026 bytes

play.svg - 399 bytes

replay.svg - 495 bytes

I ran them through SVGO just so they are nicely optimized and kinda ready for use as a data URI (whitespace removed, although I guess not strictly necessary).

cog.svg - 685 bytes

play.svg - 118 bytes

replay.svg - 212 bytes

Then I ran those through a base64 converter.

cog.svg - 916 bytes - 133% of the original size

play.svg - 160 bytes - 136% of the original size

replay.svg - 283 bytes - 134% of the original size

So that makes sense, right? If it's 4 characters for every 3 bytes, that's 133% bigger, with the variation coming from uneven lengths and thus padding.

Anyway, maybe this is all super obvious. But it just seems to me if you're going to use a data URI for SVG there is no reason to ever base64 it.

Props to Matt Flaschen for his email a few months ago that highlighted this issue for me.

---

Probably Don’t Base64 SVG is a post from CSS-Tricks

more info...

SVG Artboard Sizing

CSS-Tricks

SVG Artboard Sizing

There are a couple of different (rational) approaches to SVG artboard sizing.

The term "Artboard" here is referring to that concept in Illustrator, basically the white drawing area you have for the document. Ultimately it refers to the viewBox in the actual SVG output. It matters very much for front end developers, because if there is no consistency, the positioning of the SVGs will always be a little one-off battle and really hurt the idea of SVG being a useful system.

I recently met developer Emma Arce at a conference who relayed a very interesting conversation between her team as they were attempting to standardize on something and get this right. Here's my take on the situation.

Approach #1: Make them all the exact same size

You'll probably be applying sizing through CSS, so size of the artboard doesn't matter much, but the dimensions should be identical. Here's what that looks like:

Advantages

Relative sizing. You control right in the design of the icon itself how it is sized compared to other icons. So if you size them all the same in CSS later, all the icons will maintain that size relationship and look good together.

Disadvantages

Directional alignment. Since there is an arbitrary amount of whitespace on any given side of any given icon, it's hard to align things to the edge of an icon or expect a consistent amount of space between an icon and adjacent element.

Approach #2: Crop to edges

Again the actual "size" of the artboard doesn't matter since you'll likely be applying sizing through CSS anyway, but the artboard should meet the edge of the artwork on all sides. In Illustrator, it's an easy move:

Here's what that looks like:

Advantages

Alignment and positioning. If you want to position an icon in the upper right corner of an element, it's going to go there and look nice and aligned. There won't be some weird arbitrary amount of whitespace to compensate for.

Disadvantages

Sizing inconsistency. All the icons have different aspect ratios now. That's not a huge problem for complexity, because you can still size them with CSS with a fixed width/height and they will center within that area (assuming a default preserveAspectRatio). But, that will affect their sizing. The closer any given icons aspect ratio is to a square, the bigger it will seem (it will fill the space given). Taller or wider icons will need to shrink to fit in the space and appear smaller. So consistant and other-icon-relative sizing is harder.

Winner?

I'm afraid I just can't pick one. I really like the positioning consistency of cropped icons, but the inconsistent sizing can drive me nuts. And I'm sure it would work exactly the opposite if I changed.

Other Considerations

Consistency through boxes: If in every single instance of using SVG you are placing the icon within a visually-defined box, alignment becomes a non-issue since you can align the boxes and they will look fine.

You can always do one-offs: Let's say you have one really long and skinny arrow shape. You can always do some special CSS just for that one. I wouldn't change a whole system based on a handful of outliers. This is about the system as a whole.

---

SVG Artboard Sizing is a post from CSS-Tricks

more info...