Styling meter elements is kind of a pain, as they don't seem to respond to all CSS properties, some browsers respond differently than others, and all provide different ways to go about the styling. However you can do quite a bit with the element itself if you're willing to endure a little of such pain. Unfortunately they appear to behave like replaced content elements, so we lose the ability to use pseudo-elements for more fun [and profit(?)]. Even if somehow the outer element wasn't classified as such, I wouldn't expect to be able to use them on the inner bar.

That all said, that's not the end-all on styling these things. Browsers are starting to bring in elements of SVG to the HTML world so if you are willing to give up on only needing a single element (the meter itself) to style, Firefox will let you apply a clip-path to HTML elements as has been done above to get the multi-point star effect.

I've included all the fill bits to style the inner meter-state bar for WebKit and IE as well, but it should be noted that IE10 does not support the meter element. As a result of that and WebKit not applying the clip-path, this won't look nearly as good anywhere other than Firefox. Perhaps if it was wrapped in another element, more fun could be had with using the wrapper element's pseudo-elements (or box-shadow shenanigans, anyone?).

So, after all that ... why is it blue, and why does it look like that? Well, I found an article on styling the meter tag while looking around on information for another project of mine* and decided that surely things had to have improved since 2009 to the point the original image could be achieved and the mockup superceded while still using the actual element desired. In some ways, you now can. It should be obvious, though, that what I've produced above is not the same as the image in the original Steve Workman article and by using SVG it sort of violates the idea that you could achieve those fanciful looks with only one element present in the source markup.

* Incidentally, if you're also looking for such an article, I found a great one on hongkiat.com that gave me insight on this. It only misses out on IE10's ::fill and, due to only being an article on the progress element, Firefox's ::-moz-meter-bar and associated pseudo-elements as well as WebKit's associated pseudo-elements with the same name. However I could forgive the ::-moz-meter-bar becuase I only found out about it by guessing based on the existence of ::-moz-progress-bar and asking Google on the assumption there was an analogue. To my surprise, it's only ever mentioned in a bug ticket and nowhere on MDN. Also surprising, but slightly less so, is that WebKit and Firefox can agree on names, but not what those elements should do. Both define ::-[prefix]-progress-bar and ::-[prefix]-meter-bar, but in Firefox they style the bar's visual state, and in WebKit they style the base element. WebKit defines a separate ::-webkit-progress-value to handle the progress bar's state. IE by only having ::fill seems to agree in execution, if not name, with Firefox.

Lastly, if you want more ideas, I am not the only one to try to improve upon the orignial attempts. Oliver Smith has taken a go, which seems to work best in Chrome but not nearly as well as the image of his output indicates.** Chrome's support of things seems to vary every couple of releases, with regressions and bugs galore, and they still haven't managed to unprefix things they helped introduce into specifications that other browsers have long finished. So I am not surprised at this relevation. Perhaps with Blink and their separation from WebKit, they can smooth out the problems and achieve the support consistency of Safari.

** I find it better not to rely on support of pseudo-elements on things behaving like replaced content elements, which is what seems to have regressed. Chrome (WebKit?) to my knowedledge is the only browser attempting to support pseudo-elements on such elements making it a very unlikely recommendation to anyone for styling things.