Foolproof HTML

Ville V. Vanninen

UX Designer at OP Lab

@sakamies

I've been thinking and prototyping a native HTML editor for a while⁺. (Native as opposed to a text editor that's customized to work with HTML) This is a rough transcript of a presentation I gave on the subject. This presentation is about HTML, but these ideas could be useful for other markup languages, data formats and programming languages too.

What's the problem?

Do you write code? Have you ever encountered a syntax error? (of course you have)

What if you had to write a language where you can make mistakes, but there are no errors? Where your parser just silently accepts anything you give it. Where you'll have to carefully compare your intentions to the parsed output to figure out what went wrong.

Do you write HTML?

What I just described was how browsers handle HTML. They will happily accept anything you give them and try their best to make sense of it. They could swap out element places, change attributes, or do whatever if there's a typo in your code.

Do you use web developer tools?

All popular browsers have them these days. They're awesome! Go ahead and open your devtools, let's try some stuff. In Chrome they're under the View menu. Go to View → Developer → Developer Tools. Open the Elements tab and press esc to show the console at the same time.

What happens if you forget the closing quote of an attributes value? Try this bit of code in the console.

document.body.innerHTML = '<div a="b><span></span></div>'

After parsing that, chrome thinks the result should be nothing! The body element is empty.

Now let's try the same thing, only with the first quote missing.

document.body.innerHTML = '<div a=b"><span></span></div>'

Okay, the result is a bit better, maybe. Now Chrome encodes the second quote as an entity because it thinks the attribute is written without quotes, so it includes the latter quote as a part of the attribute value.

What if you miss an angle bracket?

body.innerHTML = '<div something="else"<span>test</span></div>'

Now we get an empty attribute that's named <span .

Yep, the console agrees.

What happens if you have mismatched start/end tags? How do you figure out the HTML structure if you get unclear indentation, or worse, code with no whitespace at all? One typo or copy & paste could change the way your document is rendered, but the only way you'll get feedback is watching your app break.

HTML5 actually has well defined parsing rules that tell you how invalid markup should be handled, but browsers will happily accept anything you throw at them without telling you what they fixed or changed.

You could validate your HTML with validator.nu, that would give you a decent overview or any possible typo based errors. There are browser and text editor plugins for validating too! Do you already validate your HTML? I expect the answer to be no. Very few developers do that, I don't either. Validating won't make your HTML foolproof, but it will give you some reporting on the end result.

That's fine for plain HTML, and checking the code at the stage when the user sees it, but what about when you're writing templates?

If you have a good strategy for validating your template files, I'd love to hear it! How about a javascript rendered single page app? What about external dependencies that could produce unexpected markup? Validation as a part of your build system could work though.

There are syntax highlighters, linting plugins, autocomplete and all that. Syntax highlighting and text editors have served us for a long time, but we need tools that better understand how we're thinking. Linters, snippets, autocomplete etc. are all part of this, and they're great, but a lot of coding is still managing text and syntax.

HTML is parsed to tree structure in the browser, not a bunch of text. With code on the top, if you make typo, you're screwed. On the bottom, with devtools, you can edit tags, attributes and whatever, you can type anything and the structure still makes sense. Devtools are awesome, but can't really be used for creating and editing files. In devtools, you edit the actual thing, not a description of the thing. All funny syntax characters are escaped automatically so you can't mess up syntax by typing.

Could we make typo based errors go away?

Could we prevent all syntax mistakes?

Prior art

Remember front page 98? (That's how I started learning HTML) WYSIWYG can be great for design, but you can't usually code stuff with it, but that's an article for another day

Do any of those look familiar?

Emmet is a text editor plugin for HTML & CSS editing. Jade (recently renamed to Pug), Haml and Slim are full shorthand languages that compile to HTML. Here's Slim:

Looks nice! Less syntax means less errors, right? I especially like slim because it just looks pretty and familiar. Reducing syntax like this can be tempting, but the code gets less explicit and more fragile. Your code becomes more dependant on proper formatting and you actually have less room for mistakes. Pre-processed languages do have the advantage that they will report errors. If you forget a quote, the parser will yell at you and show where it thinks the error is.

These shorthand template languages are pretty great, but they're usually tied to a certain programming language or even a framework. I switch between languages and frameworks all the time. I want a native HTML editor with shorthand language superpowers that doesn't care if there's some random code mixed in with the HTML.

Proposal

Here's a spectrum of solutions to help with creating HTML. Could there be something unexplored in the middle?

So far I haven't found much for web design that would qualify for the center column. I've seen some promising starts, but they've always been quite a bit to the WYSIWYG side of the graph, so I started making my own.

Here are some high level principles that I'd like to have in an HTML (or CSS) editor.

Hide anything that's irrelevant to humans Let humans only edit the parts they care about Let humans ignore writing syntax Prioritize the most common actions

These could apply to any kind of editing really. There are probably lots of other good principles, let me know if you have ideas! Let's go through these one by one with the prototype I built.

Hide anything that's irrelevant to humans

Imagine it works like the Chrome devtools, so the HTML shown is a tree, not text.

Let's hide the end tags.

Let's remove angle brackets. Looks suspiciosly like that Slim example!

Let's simplify even more.

That would probably be pretty fragile if it was text only syntax.

Let humans only edit the parts they care about

You edit one separate thing at a time. You can't touch the colons in between the attribute name and value. If you delete that id attribute name there, the value should get deleted too, or if you delete the body tag name, the whole row gets deleted.

Let humans ignore writing syntax

You should be able to write any crap you want and everything should just work. Everything should be automatically escaped.

Prioritize the most common actions

Here's how I think the most common HTML editing actions could work. Your preference for shortcuts and how common you think these actions are will probably differ from mine. Let me know what you think are the most common actions and how you think they should work.

Type lowercase letters to make elements. Press space to add an attribute. Press # (hash) or . (dot) to add id's and classes, this should be familiar from css. Type uppercase to add plain text. Drag & drop to move stuff around. Select items of interest instead of one character at a time, press enter to edit.

For some hardcore coding, this model would probably restrict your output a bit. Sometimes that's a good thing.

Open questions

How much freedom vs. how much forced correctness?

How to add ruby/js/whatever if special characters are automatically escaped?

HTML sometimes needs formatting with whitespace, how should that work?

Let's make Foolproof HTML happen!

I really need some developer help with this. I can do a lot with javascript, but creating a full blown editor is quite a bit of work and needs some competent app architecting! Let's talk.

Ville V. Vanninen / @sakamies





Notes