Tags: dom_scripting

33

sparkline

Saturday, July 11th, 2020

A little bit of plain Javascript can do a lot

I decided to implement almost all of the UI by just adding & removing CSS classes, and using CSS transitions if I want to animate a transition.

Yup. It’s remarkable how much can be accomplished with that one DOM scripting pattern.

I was pretty surprised by how much I could get done with just plain JS. I ended up writing about 50 lines of JS to do everything I wanted to do.

Tuesday, July 7th, 2020

Custom properties

I made the website for the Clearleft podcast last week. The design is mostly lifted straight from the rest of the Clearleft website. The main difference is the masthead. If the browser window is wide enough, there’s a background image on the right hand side.

I mostly added that because I felt like the design was a bit imbalanced without something there. On the home page, it’s a picture of me. Kind of cheesy. But the image can be swapped out. On other pages, there are different photos. All it takes is a different class name on that masthead.

I thought about having the image be completely random (and I still might end up doing this). I’d need to use a bit of JavaScript to choose a class name at random from a list of possible values. Something like this:

var names = ['jeremy','katie','rich','helen','trys','chris'];
var name = names[Math.floor(Math.random() * names.length)];
document.querySelector('.masthead').classList.add(name);

(You could paste that into the dev tools console to see it in action on the podcast site.)

Then I read something completely unrelated. Cassie wrote a fantastic article on her site called Making lil’ me - part 1. In it, she describes how she made the mouse-triggered animation of her avatar in the footer of her home page.

It’s such a well-written technical article. She explains the logic of what she’s doing, and translates that logic into code. Then, after walking you through the native code, she shows how you could use the Greeksock library to achieve the same effect. That’s the way to do it! Instead of saying, “Here’s a library that will save you time—don’t worry about how it works!”, she’s saying “Here’s it works without a library; here’s how it works with a library; now you can make an informed choice about what to use.” It’s a very empowering approach.

Anyway, in the article, Cassie demonstrates how you can use custom properties as a bridge between JavaScript and CSS. JavaScript reads the mouse position and updates some custom properties accordingly. Those same custom properties are used in CSS for positioning. Voila! Now you’ve got the position of an element responding to mouse movements.

That’s what made me think of the code snippet I wrote above to update a class name from JavaScript. I automatically thought of updating a class name because, frankly, that’s how I’ve always done it. I’d say about 90% of the DOM scripting I’ve ever done involves toggling the presence of class values: accordions, fly-out menus, tool-tips, and other progressive disclosure patterns.

That’s fine. But really, I should try to avoid touching the DOM at all. It can have performance implications, possibly triggering unnecessary repaints and reflows.

Now with custom properties, there’s a direct line of communication between JavaScript and CSS. No need to use the HTML as a courier.

This made me realise that I need to be aware of automatically reaching for a solution just because that’s the way I’ve done something in the past. I should step back and think about the more efficient solutions that are possible now.

It also made me realise that “CSS variables” is a very limiting way of thinking about custom properties. The fact that they can be updated in real time—in CSS or JavaScript—makes them much more powerful than, say, Sass variables (which are more like constants).

But I too have been guilty of underselling them. I almost always refer to them as “CSS custom properties” …but a lot of their potential comes from the fact that they’re not confined to CSS. From now on, I’m going to try calling them custom properties, without any qualification.

Wednesday, June 17th, 2020

Where did the focus go? | Amber’s Website

Amber documents a very handy bit of DOM scripting when it comes to debugging focus management: document.activeElement.

Sunday, May 10th, 2020

Getting Started with the DOM

Here’s a short clear introduction to DOM scripting.

Monday, March 30th, 2020

HTML DOM - Common tasks of managing HTML DOM with vanilla JavaScript

This is a great way to organise code snippets—listed by use case, and searchable too!

Next time you’re stuck on some DOM scripting, before reaching for a framework or library, check here first.

Tuesday, March 17th, 2020

Scripts: async, defer

I’m constantly forgetting the difference between the async attribute and the defer attribute on script elements—this is a handy explanation.

Monday, April 15th, 2019

Saturday, April 13th, 2019

Inline an SVG file in HTML, declaratively & asynchronously!

Woah! This is one smart hack!

Scott has figured out a way to get all the benefits of pointing to an external SVG file …that then gets embedded. This means you can get all the styling and scripting benefits that only apply to embedded SVGs (like using fill).

The fallback is very graceful indeed: you still get the SVG (just not embedded).

Now imagine using this technique for chunks of HTML too …transclusion, baby!

Wednesday, December 12th, 2018

What’s the difference between JavaScript event delegation, bubbling, and capturing? | Go Make Things

I can never keep these straight—this is going to be a handy reference to keep on hand.

Friday, July 13th, 2018

CSS: A New Kind Of JavaScript | HeydonWorks

A bold proposal by Heydon to make the process of styling on the web less painful and more scalable. I think it’s got legs, but do we really need another three-letter initialism?

We waste far too much time writing and maintaining styles with JavaScript, and I think it’s time for a change. Which is why it’s my pleasure to announce an emerging web standard called CSS.

Tuesday, May 22nd, 2018

Easy Toggle State

I think about 90% of the JavaScript I’ve ever written was some DOM scripting to handle the situation of “when the user triggers an event on this element, do something to this other element.” Toggles, lightboxes, accordions, tabs, tooltips …they’re all basically following the same underlying pattern. So it makes sense to me to see this pattern abstracted into a little library.

Thursday, February 16th, 2017

Teaching in Porto, day three

Day two ended with a bit of a cliffhanger as I had the students mark up a document, but not yet style it. In the morning of day three, the styling began.

Rather than just treat “styling” as one big monolithic task, I broke it down into typography, colour, negative space, and so on. We time-boxed each one of those parts of the visual design. So everyone got, say, fifteen minutes to write styles relating to font families and sizes, then another fifteen minutes to write styles for colours and background colours. Bit by bit, the styles were layered on.

When it came to layout, we closed the laptops and returned to paper. Everyone did a quick round of 6-up sketching so that there was plenty of fast iteration on layout ideas. That was followed by some critique and dot-voting of the sketches.

Rather than diving into the CSS for layout—which can get quite complex—I instead walked through the approach for layout; namely putting all your layout styles inside media queries. To explain media queries, I first explained media types and then introduced the query part.

I felt pretty confident that I could skip over the nitty-gritty of media queries and cross-device layout because the next masterclass that will be taught at the New Digital School will be a week of responsive design, taught by Vitaly. I just gave them a taster—Vitaly can dive deeper.

By lunch time, I felt that we had covered CSS pretty well. After lunch it was time for the really challenging part: JavaScript.

The reason why I think JavaScript is challenging is that it’s inherently more complex than HTML or CSS. Those are declarative languages with fairly basic concepts at heart (elements, attributes, selectors, etc.), whereas an imperative language like JavaScript means entering the territory of logic, loops, variables, arrays, objects, and so on. I really didn’t want to get stuck in the weeds with that stuff.

I focused on the combination of JavaScript and the Document Object Model as a way of manipulating the HTML and CSS that’s already inside a browser. A lot of that boils down to this pattern:

When (some event happens), then (take this action).

We brainstormed some examples of this e.g. “When the user submits a form, then show a modal dialogue with an acknowledgement.” I then encouraged them to write a script …but I don’t mean a script in the JavaScript sense; I mean a script in the screenwriting or theatre sense. Line by line, write out each step that you want to accomplish. Once you’ve done that, translate each line of your English (or Portuguese) script into JavaScript.

I did quick demo as a proof of concept (which, much to my surprise, actually worked first time), but I was at pains to point out that they didn’t need to remember the syntax or vocabulary of the script; it was much more important to have a clear understanding of the thinking behind it.

With the remaining time left in the day, we ran through the many browser APIs available to JavaScript, from the relatively simple—like querySelector and Ajax—right up to the latest device APIs. I think I got the message across that, using JavaScript, there’s practically no limit to what you can do on the web these days …but the trick is to use that power responsibly.

At this point, we’ve had three days and we’ve covered three layers of web technologies: HTML, CSS, and JavaScript. Tomorrow we’ll take a step back from the nitty-gritty of the code. It’s going to be all about how to plan and think about building for the web before a single line of code gets written.

Monday, March 7th, 2016

A Year Without jQuery

In many ways, moving to vanilla JavaScript highlights the ugliness of working with the DOM directly, and the shortcomings of native Element object — shortcomings which Resig solved so incredibly eloquently with the jQuery API.

Having said that, the lessons I’ve learned over the last year have made me a better developer, and the tools built in the process have opened my eyes and given me enough confidence and understanding of vanilla JavaScript that the only scenario where I would personally consider using jQuery again would be a project needing IE8 support.

Wednesday, December 17th, 2014

You Don’t Need jQuery! – Free yourself from the chains of jQuery by embracing and understanding the modern Web API and discovering various directed libraries to help you fill in the gaps.

The tone is a bit too heavy-handed for my taste, but the code examples here are very handy if you’re weaning yourself off jQuery.

Thursday, January 16th, 2014

A Dive Into Plain JavaScript

A nice introduction to writing vanilla JavaScript, especially if you’re used to using jQuery.

Monday, December 9th, 2013

OriDomi - origami for the web

A fun little JavaScript library for folding the DOM like paper. The annotated source is really nicely documented.

Monday, January 28th, 2013

On layout and web performance by Kelly Norton

This is handy: a look at which DOM properties and methods cause layout thrashing (reflows).

Monday, January 21st, 2013

Foreword to DOM Enlightenment by Cody Lindley

The foreword to the O’Reilly book.

I make websites. Sometimes I make music. Over the years, I’ve noticed an interesting pattern of behavior from some musicians—often self-taught—who think of themselves as creative types: they display an aversion to learning any music theory. The logic, they say, is that knowing the theory behind music will somehow constrain their creative abilities. I’ve never understood that logic (and I secretly believe that it’s a retroactive excuse for a lack of discipline). To my mind, I just don’t see how any kind of knowledge or enlightenment could be a bad thing.

Alas, I have seen the same kind of logic at work in the world of web design. There are designers who not only don’t know how to write markup and CSS, they actively refuse to learn. Again, they cite the fear of somehow being constrained by this knowledge (and again, I believe that’s a self-justifying excuse).

In the world of front-end development, that attitude is fortunately far less prevalent. Most web devs understand that there’s always more to learn. But even amongst developers who have an encyclopediac knowledge of HTML and CSS, there is often a knowledge gap when it comes to the Document Object Model. That’s understandable. You don’t need to understand the inner workings of the DOM if you’re using a library like jQuery. The whole point of JavaScript libraries is to abstract away the browser’s internal API and provide a different, better API instead.

Nonetheless, I think that many front-end devs have a feeling that they should know what’s going on under the hood. That’s the natural reaction of a good geek when presented with a system they’re expected to work with. Now, thanks to DOM Enlightenment, they can scratch that natural itch.

Douglas Crockford gave us a map to understand the inner workings of the JavaScript language in his book JavaScript: The Good Parts. Now Cody Lindley has given us the corresponding map for the Document Object Model. Armed with this map, you’ll gain the knowledge required to navigate the passageways and tunnels of the DOM. ix

You might not end up using this knowledge in every project. You might decide to use a library like jQuery instead. But now it will be your decision. Instead of having to use a library because that’s all that you know, you can choose if and when to use a library. That’s a very empowering feeling. That’s what knowledge provides. That is true enlightenment.

Thursday, September 20th, 2012

DOM Enlightenment

This looks great! It’s a CC-licensed book by Cody Lindley (whose work I’ve admired for many years) aimed at teaching DOM Scripting for modern browsers. You can read the whole thing online or wait for the paper version from O’Reilly.

If all your JavaScript currently consists of writing jQuery plugins, I highly recommend you read this.

Friday, January 6th, 2012

Vanilla JavaScript FTW

I’ve found myself using jQuery less and less recently. Partly to avoid the extra download and file size but also—as shown here—when it comes to DOM manipulation, there’s a lot you can do straight out of the box.