Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for January, 2019.

Archive for January, 2019

[webfinds] Shouting at your screen to prefetch some Word Art

Tuesday, January 29th, 2019

As people complained that I post too many links to follow on Twitter (it is my stream of consciousness – as I find it, I post it), I’m starting to release these link lists every few days now. Hopefully that helps.

Spock sobbing mathematically



Cool demos:

HTML is and always was a compilation target – can we deal with that?

Monday, January 28th, 2019

Every few weeks the webdevelopment Twitter world gets in a frenzy over terrible HTML. HTML that is only DIVs and SPANs with random classes on them. HTML lacking any sensible interfaces like anchors or buttons. HTML lacking any structure like headings and lists. Non-semantic HTML. Unreadable HTML.

HTML is well defined. It is also robust, inasmuch that it is forgiving. We tried to make HTML less forgiving in the XHTML days but the web was not in a state to allow for that. Developer mistakes should not result in user lock-out. Instead, browsers should be lenient with HTML and fix things on the fly when rendering. This should worry us, as we are forced to carry with us years of horrible browser decisions. That’s why – amongst other things – browsers are fat and slow.

HTML is forgiving

This leniency, however, helped the web survive. It ensures that today’s browsers can show age-old content without us having to go back and change it. Years of Flash content now not available proves that this is a sensible thing to do in an environment as fluctuating as the web.

It does mean, however, that there is no perceivable punishment for non-semantic HTML. DIVs and SPANs work, Table Layouts still work (oh, hai, hackernews).

Browser showing anything should worry us as it makes writing “clean” and “semantic” HTML a nice to have. A special skill. The caligraphy of writing for the web, where most of the other content is random smeared scribbles on dog-eared sticky notes.

Semantic HTML is better, there is no question about it. You get a lot of free accessibility benefits from it. It tends to perform better. It often means that you have no third party dependencies. It is also much easier to read and understand. And many of us learned about the web by looking at the source of other web sites. This is an anachronism, and I wrote about this in length a few months ago.

It is time we start dealing with this on a more mature level rather than re-iterating the same complaints every few months.

HTML is and has always been a compilation target. The wonderful world of “hand-crafted HTML” is one for a very small group of loud enthusiasts.

I am part of that group and I have been ever since I started blogging 14 years ago. I love that the web is accessible to all. All you needed was a text editor, some documentation and you’re off to publish on it.

Hand-written HTML is a rarity, a collector’s item

However, even 20 years ago when I started as a web developer, this was not how people worked. This was not how most web products were created. In fact, it was even that uncommon that in any job description I wrote we specifically asked for “hand written HTML/CSS/JS skills”. It was an elite, highly interested and invested group who cared about that. Good people to hire if you want to make a change for a cleaner, more semantic web. But was that change even in demand?

The larger part of the web was based on other technology:

  • Server-Side-Includes (remember .shtml pages)
  • CGI/Perl templating systems
  • Content Management Systems with own templating languages rendering out HTML
  • WYSIWYG Editors that created something resembling HTML
  • Templating languages like PHP, ColdFusion, Template Toolkit, ASP and many others
  • Online editors and page generators like Geocities
  • Forum and Blog editors with sometimes own languages (remember BBCode?)

None of these were necessary to publish on the web. In the case of some of the enterprise CMS I worked with they were ridiculously complex and inflated. But people used them. Because they promised an easier, more defined and clearer publication path of web content. They solved developer and manager problems, not end user experience. In the case of Geocities and similar services they made it easier for people to publish on the web as they didn’t even need to write any code.

What you see in the browser is almost never the source code. If you want to improve its quality, we need to go higher up the chain.

Even back then looking at the source of a document wasn’t the document that someone wrote. It was the result of lots of includes being put together by some server-side code, maybe even optimised and then thrown to the browser.

And that makes total sense. Having lots of different components allowed people to work on them in parallel. Often your site navigation was a global one even written and maintained by some other department or company. You didn’t even have access to the HTML, and – if you were lucky – you could fix a few issues with CSS.

HTML is a compilation target

Fast forward to now. HTML is not cool. Writing your own templating language is. Markdown, Pug, Jade and many others keep getting invented. Meant to save us from the complexity of HTML and the compatibility issues it has with this or that environment.

HTML has a bad reputation for being something that should work, but doesn’t reliably deliver. A framework that gives you more control and promises to be “modern” is much more exciting than an age-old technology that promises not to break.

It is irrelevant to most that the web shouldn’t be controlled by us but that our users need to cater the outcome to their needs. Most developers don’t get paid to think in those terms – they get paid to roll out a certain interface in a certain amount of time. We need to fix that.

HTML is not seen as a thing to worry about – as the execution environment is lenient about its quality. It is generally seen as a much better use of your time to learn higher abstractions. People don’t want to build a web site. They want to build an app. That in most cases they don’t need an app is not important. We dropped the ball in keeping HTML interesting. We wanted the web to give us more capabilities, to be on par with native code on mobiles. And this always results in more complexity. The extensible web manifesto pretty much nailed that a publisher on the web needs to have a more developer mindset than a writer or publisher. We wanted control, we wanted to be in charge. Now we are.

What does this leave us with? For one thing, we need to come to peace with the fact HTML on the web in most cases is the result of some sort of compilation. Looking at the final result and bemoaning its quality makes no sense. Nobody ever edits this and it is not meant to be readable.

I am not giving up on semantic HTML and its merits, but I understand that we won’t sell it to developers by telling them their end product is terrible. We need to work with the framework developers, the creators of components. We need to help with the template code source, the framework renderers. We need to ensure that the conversion stage results in good HTML - not easy HTML.

And we need to work with tool developers to make sure that people learn about the value of semantics. In-editor linting and autocompletion goes a long way. We have a much bigger toolbox to choose from these days to make sure that developers do the right thing without having to think about it. I like that idea. Let’s fix the problems at the source rather than complaining about the symptoms.

[webfinds] Be safe on the internet, contain and specify CSS, history of JavaScript modules and empathy through documentation

Friday, January 25th, 2019

As people complained that I post too many links to follow on Twitter (it is my stream of consciousness – as I find it, I post it), I’m starting to release these link lists every few days now. Hopefully that helps.

Conspiracy Theorist

[webfinds] Ethical performance, programming sucks and 101 bash tips

Wednesday, January 16th, 2019

As people complained that I post too many links to follow on Twitter (it is my stream of consciousness – as I find it, I post it), I’m starting to release these link lists every few days now. Hopefully that helps.

Old man aged 26 stating that being an engineer is not stressful at all


Web Development

Work inspiration

not sure about the plumbing / toilet analogy, but this argument from New Dark Age about why learning to code is not enough is at least thought provoking
We need more people who are willing to travel that distance and build up the craftsmanship that produces great work. So take pride in your craft. Take interest in learning. And create great things.
This file is Good Code. It has sensible and consistent names for functions and variables. It’s concise. It doesn’t do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry written by someone over thirty.


Meta stuff, long reads

A more complicated web

Tuesday, January 15th, 2019

One of the amazing things about the web used to be its simplicity. It was not too hard to become your own publisher on it. You either used one of the now defunct services like Geocities, Xoom, Apple Web Pages, Google Pages and so on… Or you got a server, learned about HTML and CSS and a dash of JavaScript and created your own site. Training materials were online and largely free and open.

The more important thing to me was there was a sense of adventure and exploration. Many of us took our first steps as web developers by changing colours on a GeoCities or NeoPets web site. We looked at the source code. We used what we had and made it work – no matter how convoluted. That way we discovered now terrible ideas like layout tables or inline styles. There was no guide to follow – it was the thrill of beating the system and making it do something it wasn’t meant to. It was our cleverness that got us there – not picking from a huge offer of choices and finding one that does the job. I loved the times when online magazines about web design talked about CSS techniques like sliding doors and what image replacement technique to use and not “which is the best framework to get started” or “which browser is the fastest this month”.

A read-write web

The big success of the web is that everybody can take part and the barriers to entry were low. It was a read-write web, you learned the trade by using the medium. This was the big breakthrough. You didn’t learn sound production by listening to the radio. You didn’t learn how to make movies by watching TV. Old school media needed many experts to work together to produce the final product. On the web, things seemed much easier. And being able to peek under the hood with a view-source was a great opportunity.

This is still the idea of the indie web and there are many great ideas to be your own publisher. And – maybe even more importantly – the owner of your publishing platform and how your content gets to the end users. I consider this incredibly important but I am torn about what happens in that area.

I’m disappointed that we allowed self-publishing on the web to become a niche experience again. But the more problematic part to me is that outside the indie web movement there is a general call to go back to when the web was simpler and we can fight the siren song of Facebook by running our own blogs. First of all, fighting Facebook is fighting the most finely honed skinner box and peer pressure machinery out there. Secondly, it is not as simple to run your own web site these days as it used to be.

The problem that I see though is that there is a romantic view of the realities of the web today. In the following few paragraphs I will point out a few things that broke along the way of the dream of an open and simple to contribute web. These are based on 20 years experience in this field, working as a web developer, server admin, in security and on browsers and standards.

I don’t want them to discourage anyone to take part in the web. But I am tired of the message that “everything was simpler back in the days” and that “we should go back to that”. Running a web site means you take on responsibility for your users and – to a degree – the open web. Any system is as weak as its weakest link.

The gamed web

The web isn’t a cool geek playground any longer. It is a vital part of everyday life. And decades of trying to find a way to monetise something open and decentralised took their toll. When I look back at when I started publishing on the web there was a genuine “build it and they will come”. Or, to be more precise, “write it and they will come” – as good content, structured in a clear way, was the big winner. To a degree, it still is, but the question is who will come.

Put an email link on the web and you will get 95% spam, 3% people trying to sell you their content services and 2% genuine requests. Have a comment option on your web product and things are worse. You will either have to share your content with a third party doing spam protection for you or drown in it. A huge part of web traffic these days is bots and scripts. Which is a downside of a simple system designed to be open.

Good content still gets you found. But it also invites a lot of people to quote, steal or find some other way to associate their – often terrible – products with it. It is damn easy to set up a web product full of scraped content with lots of link optimisation. Lazy SEO consultants have been doing it for years.

Take this blog. I have no uncertain words about it being my work, and that I don’t publish third party content. Yet I get about 50 emails a week of people offering me their articles, infographics or videos to publish for a link back. I even have been approached by companies in direct competition to the product I work on offering me money for each download of theirs.

Fact is that when you publish on your own site, you inherit a whole community of people you don’t want and you need to deal with them. You need to factor this time in.

The abused web

What we consider a way to express ourselves on the web – our personal web site – is a welcome opportunity for attackers. You may think that your little home on the web isn’t interesting to attackers. It probably isn’t. But it can be recruited as a part of a botnet or to store illegal and malicious content for re-distribution.

Publish any form or non-paranoid display of user entered or URL data and you will have lots of hacking attempts. So we need to be constantly vigilant about this. It may look like nothing when a security tool shows a JavaScript alert on your page, but it isn’t. To an attacker this means they can access your server and store whatever they want, scan for more credentials and create their own users. Unless you have access to the server logs, you often don’t realise unauthorised use. Often with shared virtual hosting, you don’t. And even if you do but lack the tools or knowledge it can be months before you realise someone is abusing your server. I did.

Any chance to publish content is a possible attack vector. If you want to hear a real horror story about this, check out what Remy Sharp went through over the years with JSBin .

To put this in other words:

If it is easy for you to quickly FTP some content to your web product, it is easy for everybody.

Which brings me to the last part of our open web world.

A new level of technical complexity

Again, I don’t want to discourage people to take part in the open web and I am 100% behind the message that we need to own our content. But I also want to make sure that when we tell people to do that about the responsibilities and dangers.

The web of old had a few attack vectors but now the game has changed. Our goal as web standards and browser makers shifted some time ago. It wasn’t only about offering and displaying web content. It was to match what native apps offered. This was a necessity to keep the web alive in a world of mobile devices. It had to answer the different challenges of mobile connectivity. That way we made the web a lot more complicated. We have databases, offline functionality and storage, workers and can use and create binary code in the browser. In CSS we have layout tools that aren’t abuse of position and float. We can generate and manipulate images with gradients, drop shadows and filters. We can generate sound and access cameras and sensors. It is a wonderful time to be a web developer.

One big change in this new functionality of the web was the extensible web manifesto . In it we rightfully demanded more transparency and access to the low-level functionality of browsers. We didn’t want “magical functionality” on the web that did things. We wanted more detailed access to how browsers work and how they show the things we defined in our markup. Thus we created a much more complex web. More access means more responsibility. And more responsibility demands more insight and knowledge.

Lately I got a few bug reports of scripts I wrote to work with HTML5 canvas. People complained that Chrome reported tainted canvas data not being available. It turns out that people downloaded my script and used it in a local file in the browser. Almost every newer API in the browser needs to be accessed via http or even a safer resource accessed with https or by running a local server. This is now a given – and it means we need to step up as new developers and for us to train them accordingly.

So, to me, there is no such thing as going back to the good old web where everything was simple. It never was. What we need now to match the siren call of closed garden publishers is making it easier to publish on the web. And to control your data and protect the one of your users. This isn’t a technical problem – it is one of user interfaces, services and tools that make the new complexity of the web manageable. I’m tired of complaints about people using frameworks when there is a simpler alternative. I am tired of the argument of “too much JavaScript”.

Every feature of an interface isn’t an opportunity but a choice. And it costs some effort to blend it out when you don’t need it until you do. When we introduce new people to the web these days we often overwhelm them with an overload of choice. Freedom of choice should be a gift, not a burden.

Publishing on Medium, Facebook and LinkedIn is simple. It also comes with a pre-filtered audience and tools to control abuse. Self-publishing is better – no question asked. But as of now, it is harder to do. It seems simple enough, but can get problematic soon. We have enough un-maintained, open-to-attack resources out there . All these started with the best intentions in mind but ran out of steam soon enough.

Own your content. Own your platform. But take your time to understand the risk. Learn how to be a good landlord for your words and thoughts by keeping their home in check.

This is where tooling comes in. Teaching new publishers on the web using an editor that lints and creates local servers for you is a great idea. Showing them tools that check their sites for interoperability, security and accessibility issues with explanations is a good idea. Getting people started with GitHub to host their projects and find a way to generate a static page from them is a good idea. I don’t want to see people using a file name as version control any longer and have no history of their work. Sure, they have the right to make life harder for them, but isn’t this about publishing content?