I like the robustness that comes with declarative languages. I also like the power that comes with imperative languages. Best of all, I like having the choice.

Take the video and audio elements, for example. If you want, you can embed a video or audio file into a web page using a straightforward declaration in HTML.

<audio src="..." controls><!-- fallback goes here --></audio>

Straightaway, that covers 80%-90% of use cases. But if you need to do more—like, provide your own custom controls—there’s a corresponding API that’s exposed in JavaScript. Using that API, you can do everything that you can do with the HTML element, and a whole lot more besides.

It’s a similar story with animation. CSS provides plenty of animation power, but it’s limited in the events that can trigger the animations. That’s okay. There’s a corresponding JavaScript API that gives you more power. Again, the CSS declarations cover 80%-90% of use cases, but for anyone in that 10%-20%, the web animation API is there to help.

Client-side form validation is another good example. For most us, the HTML attributes—required, type, etc.—are probably enough most of the time.

<input type="email" required />

When we need more fine-grained control, there’s a validation API available in JavaScript (yes, yes, I know that the API itself is problematic, but you get the point).

I really like this design pattern. Cover 80% of the use cases with a declarative solution in HTML, but also provide an imperative alternative in JavaScript that gives more power. HTML5 has plenty of examples of this pattern. But I feel like the history of web standards has a few missed opportunities too.

Geolocation is a good example of an unbalanced feature. If you want to use it, you must use JavaScript. There is no declarative alternative. This doesn’t exist:

<input type="geolocation" />

That’s a shame. Anyone writing a form that asks for the user’s location—in order to submit that information to a server for processing—must write some JavaScript. That’s okay, I guess, but it’s always going to be that bit more fragile and error-prone compared to markup.

(And just in case you’re thinking of the fallback—which would be for the input element to be rendered as though its type value were text—and you think it’s ludicrous to expect users with non-supporting browsers to enter latitude and longitude coordinates by hand, I direct your attention to input type="color": in non-supporting browsers, it’s rendered as input type="text" and users are expected to enter colour values by hand.)

Geolocation is an interesting use case because it only works on HTTPS. There are quite a few JavaScript APIs that quite rightly require a secure context—like service workers—but I can’t think of a single HTML element or attribute that requires HTTPS (although that will soon change if we don’t act to stop plans to create a two-tier web). But that can’t have been the thinking behind geolocation being JavaScript only; when geolocation first shipped, it was available over HTTP connections too.

Anyway, that’s just one example. Like I said, it’s not that I’m in favour of declarative solutions instead of imperative ones; I strongly favour the choice offered by providing declarative solutions as well as imperative ones.

In recent years there’s been a push to expose low-level browser features to developers. They’re inevitably exposed as JavaScript APIs. In most cases, that makes total sense. I can’t really imagine a declarative way of accessing the fetch or cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.

Previously, it was up to browser makers to think about these things. But now, with the advent of web components, we developers are gaining that same level of power and responsibility. So if you’re making a web component that you’re hoping other people will also use, maybe it’s worth keeping this design pattern in mind: allow authors to configure the functionality of the component using HTML attributes and JavaScript methods.

Have you published a response to this? :


Relevant to today’s WC discussions: The most powerful parts of the web platform are the things that can be done declaratively for common use cases, and augmented imperatively for special cases.

# Thursday, January 1st, 1970 at 12:00am


> the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for simple use cases, and power for more complex use e.g. <audio controls> is useful alone, but has APIs if you need them.

# Posted by CSS-Tricks on Friday, October 12th, 2018 at 5:50pm


# Thursday, January 1st, 1970 at 12:00am

# Thursday, January 1st, 1970 at 12:00am

# Liked by Aleksi Peebles on Friday, October 5th, 2018 at 11:49pm

# Liked by Kam on Friday, October 12th, 2018 at 8:46pm

1 Bookmark

# Thursday, January 1st, 1970 at 12:00am

Previously on this day

6 years ago I wrote Radio Free Earth

Hazy cosmic jive.

7 years ago I wrote To CERN with love


14 years ago I wrote Ning unveiled

Some things just don’t go together: toothpaste and orange juice, fox news and objective journalism, creationists and reality. Here’s another pair that aren’t compatible: blogging and non-disclosure agreements.

14 years ago I wrote Flickrball

This is very neat: Flickrball is a Web 2.0 game. It combines the Flickr API, some nice DOM Scripting and six degrees of Kevin Bacon.

14 years ago I wrote Treehouse revised

All’s well that ends well. You can ignore my earlier rant about the editorial cruelties that had been visited upon my article in Treehouse magazine. The PDF has been updated and you can now read A Brief History Of JavaScript as it was intended.

14 years ago I wrote Treehouse hatchet job

There’s a new PDF magazine on the block. Treehouse, from the folks at Particletree, should help fill the void left by the demise of the PDF magazine from Design In Flight.

17 years ago I wrote Busy, busy, busy

Sorry, can’t stop - people to be, places to meet; no time to blog.

18 years ago I wrote National Poetry Day

Today is National Poetry Day in Britain.

18 years ago I wrote Yahoo! Racism!

Prompted by an article written by Derek Powazek at Design For Community, I wrote the following email to Yahoo!’s customer care department:

18 years ago I wrote The two extremes

Since September 11th, I have been voraciously reading news sites, personal weblogs and any other kind of commentary I can find on the web.

18 years ago I wrote My words to the W3C

Here’s the email I wrote to the W3C about the proposed change in licencing practices.

18 years ago I wrote Making Sense of RAND

For anyone who’s confused about the proposed changes at the W3C (and let’s face, the W3C isn’t known for its snappy writing), here’s a handy little article that sums up the issues.