justmarkup

Thirteen years

2025-01-31T10:12:08+01:00

Thirteen years ago I published my first article on this site, and it's still alive (is it?).

This site #

I've only posted once in the past year, and that's perfectly fine. I could list all the reasons for my irregular posting schedule, but honestly, it boils down to time and motivation. The best part is that I still have this space online to publish whatever I want, whenever I want.

I'm not very active on social media these days. I occasionally check Mastodon and LinkedIn, but that's about it. I rely on RSS to stay informed—it just works.

Since the end of last year, my family and I have had a small garden with a dacha (a "Schrebergarten"). I'm currently renovating it, and I'm really enjoying the hands-on work. I'm also looking forward to growing vegetables and simply spending time in the garden.

That's my yearly update. Stay safe, and keep being awesome!

Not sharing GIFs

2025-01-13T18:12:08+01:00

This morning I shared an article about Balancing text in CSS (it's a great article, read it) on LinkedIn. To give a quick preview I decided to create a simple GIF of the first interactive example in the article. The GIF showed more or less how I clicked a button, which, after I clicked it, applied the CSS text-wrap: balance; to the text, and the text visually looked more balanced after that. I added an alternative text to it, as well as some more text, and shared it. All good I thought, the post is accessible for all.

Was I wrong! Shortly after that, I read a post, which reminded everyone how problematic it is to share GIFs on LinkedIn in terms of accessibility. It fails Web Content Accessibility Guidelines (WCAG) success criterion 2.3.1 and WCAG success criterion 2.2.2. The issues are that you can't stop, pause or hide the GIF on LinkedIn, and as it starts automatically (which you can't disable in settings, like you can on Mastodon) there is flash of content.

I quickly converted the GIF to a MP4 video file and tried to edit my article. But, after I tried to upload the video on LinkedIn, it didn't work. The issue? It was too small with only 31Kb, the minimum there is 75 Kb. Great, so I just removed the GIF and didn't replace it with anything.

LinkedIn has various options to make this better for everyone. They could add settings where you could disable autoplaying GIFs. They could automatically convert GIFs to a video, which would even improve performance, as videos are way smaller than GIFs. Don't know why they didn't change anything yet, but let's hope they will.

For now please don't use GIFs on LinkedIn, and the same is most probably true for many other social networks, where GIFs are always automatically played.

I planned to share some stuff on LinkedIn starting this year, so far it doesn't work out so great, but you can still connect with me there if you want.

Twelve years

2024-01-31T10:12:08+01:00

Twelve years ago I published my first article on this site, and it's still alive (is it?).

Writing #

I haven't published anything in the last year. Last year I thought I will come back to writing again, but it didn't happen. Maybe I will get back to writing again here, but I just don't know.

I'm also not really active anymore on social media. I do browse through my Mastodon timeline from time to time, but don't post much there.

So, what am I doing all day? Glad you asked. I leased a small piece of land last year to grow vegetables, which was a fantastic experience. This year I started to draw more and more, every day after dinner my daughter and me sit together to draw something. It's interesting how much better you can get by doing something ten minutes a day.

Besides that I enjoy my time with my family and friends.

That's it with my yearly update, stay safe, and keep on being awesome.

Eleven years

2023-01-31T10:12:08+01:00

Eleven years ago I published my first article on this site, and it's still alive.

Writing #

I haven't really published anything in the last year, only five thoughts (notes), but no technical article at all. After spending a lot of time in 2021 working on the Learn Forms course I needed a break from writing, and somehow never managed to get back to writing again.

I hope to get back to writing, but as Max Böck I have reasons why I don't write, mostly time.

Miss writing more and more, so 2023 may be the year I write regularly again.

Like many others I abandoned Twitter last year and use only Mastodon now. This time I didn't want to have the content only there, but also on my site, so created a simple form, which sends my thoughts to a Node.js server, which then kicks off an Eleventy build publishing the content on bits.justmarkup.com. In the form I also have a checkbox to sync to Masto, so If I check this, the thought will also be posted on my Mastodon profile.

It's really minimal, but works fine for me for the moment. Plan to improve the setup though.

Early this year I also decided to only use Social Media only while I work, so I forced myself to have no access to Mastodon on my phone, and can only check it on my laptop.

That's it with my yearly update, stay safe, and keep on being awesome.

Book – Engineering Management for the Rest of Us

2022-12-06T14:12:08+01:00

Rating: 4,5/5
Would recommend: yes
Would read again: yes

Review and takeaway #

After reading this book, I reminded myself to be more open, be more human. I was often acting like a machine in the last month, doing good work, but missing the human part, the important part of working.

It also reminded me to say No more often, to trust others.

It's also a good reminder how important communication is, to build trust, to document.

I can recommend this book for everyone thinking about changing to management, but also for everybody else working as a developer or with developers, or really anyone working in a team.

Summary and remarks #

Values – individual, company, and team values. #

Clarity is key
Understand each other
Set boundaries

Remark: As a freelancer, I have worked with lots of companies. Companies communicating their values, and practicing them, are a joy to work with.

Trust and vulnerability. #

Trust takes time
Trust is crucial.

Remark: If I can't trust my team colleagues, it makes working with them very hard.

Your team is not them, your team is we. #

Boost morale
Explain reason behind decisions
Clarify mistakes

Remark: It's really important to communicate with the team, and be transparent.

Happiness and drive #

Create space where people feel like they're getting their best work done
Provide an environment where flow state can happen

Remark: Everyone works different. If the team provides me the option to work the way I prefer, I will do my best work.

Long-term care of employees #

Set your team up for success
Understand how to delegate
Trust is inclusion
We all have bias
Talk about employee goals

Remark: Having managers who care is fundamental. I worked with fantastic managers, again, the best communicate very well, build trust, and understand the needs of employees.

Career laddering #

Senior: best you
Staff: beyond yourself, teach people
Principal: help people where they are

Remark: The further you are into your career, the more it's about helping other people. Care about people in every stage of your career.

1:1s are critical #

Provide clarity
Place to talk freely
Come prepared to 1:1s

Remark: In the past, I considered 1:1s as not important. I was wrong there. Once I took the 1:1s seriously, they made a lot of sense, and I look forward to having them.

Communicating as a manager #

Teach people to fish
Address the goals, mission
Format things clearly
All about transparency

Remark: I have worked with many companies who have no clear mission, this is unsatisfying in the long-term. If you don't know why you do something, it makes no sense.

Change management #

More to lose by staying still
Connect people to the why

Remark: Again, it's all about communicating.

Giving and receiving feedback #

Ask about feedback preference
Give guidance for the future
It's necessary, thoughtful, helps them improve at work
Praise in public, feedback in private

Remark: I personally started to request feedback, and it really helps me to see where I could do better, what I do well.

Prioritizing your teams work #

know / communicate what's most important
have focus

Objectives and key results (OKR)

70% rule (fine to establish 70%)
Look forward and look back
Quarterly planning

Remark: Take them seriously, but not too seriously. OKRs should be in line with the overall mission.

Scope down PRs #

Easier to review
Easier to test

Remark: Feature flags, as mentioned in the book, really helps to achieve this. With feature flags, you can do changes / features step by step without risking anything.

Speed of execution #

Set direction first
Assess motivation
Assess psychological safety
Assess tech stack

Remark: What I learned after many years, preparation is key. Be open to changes, don't fixate on a tech stack, think about users first.

Split time between product and engineering work #

Technical debt
Innovative projects
Slow, ongoing work (internal documentation, ...)
Migrations (As much research as possible, Clear decision makers, Document, high and low level, Maintenance and ownership)

Remark: Having a lot of technical debts can be frustrating. When doing migrations / refactoring, spend a lot of time with research, documentation to avoid more technical debts.

Prioritizing #

Schedule breaks and focus time
Create systems
Add accomplished stuff in the to-do list

Remark: For me, it is often hard to prioritize. What helps me is having some tasks I know I can finish in a short amount of time on my daily to-do, along with the more time-consuming tasks. Finishing the less time-consuming tasks shows me I did something.

Boundaries #

Say no more often
Too many meetings
Forgive myself

Remark: Saying no is really hard for me, I want to help. But, I need to get better at saying no, as often it's better someone else takes over or something is not done. I am also very strict with myself, I need to accept that I am not perfect (like anybody else) and it's okay to make mistakes.

Lazy loading HTML includes

2022-08-31T13:12:08+02:00

Browser supports :has() and container queries. So, why shouldn't they be able to support lazy loading HTML?

HTML includes #

In PHP (Hypertext Preprocessor), it's done like this:

<?php include 'component.php';?>

In HTML, it may look like this:

<div include="component.html"></div>

<include src="component.html">

How would this work? #

Instead of preprocessing the final HTML before the browser parses it, as it's done in PHP, with HTML includes, the browser will include the HTML while parsing it.

The HTML parser starts parsing, detects an include, makes an HTTP request, parses the HTML and inserts it into the DOM tree. Like streaming the HTML.

Lazy loading #

Browser supports the lazy loading attribute, loading="lazy". This could be reused for the HTML includes.

<include src="component.html" loading="lazy">

You have a component at the very bottom of a long page. Lazy load it. The browser only includes the HTML if the user scrolls down far enough.

This will make this feature even more interesting. We have JavaScript to do the same, you say? Yes, but I could say the same for container queries or :has().

Make it happen #

There are probably hundreds of issues I haven't thought of, and many would even say it's impossible. Okay, but browsers gets better and better, hardware gets better and better. Browser vendors will figure this out.

One day we will have HTML includes and HTML lazy loading includes. Looking forward to it.

Of course I am not the only one thinking about HTML includes, see this long thread which started in 2017 and people still discuss.

Building a house

2022-08-05T09:12:08+02:00

No, I am not really building a house. This is a story about many houses (websites) are build these days.

The building #

You are a group of developers and get the task to build a house. You have done this before multiple times, you check the acceptance criteria and start building; you build the base, walls and the roof. After that, you paint the house like requested.

The issue #

The house looks gorgeous, all acceptance criteria are fulfilled. You applaud each other and move on to building another house.

Suddenly, a call from the manager: The customer is not at all happy with the house. There is no door, they can't get in the house. Is this a bug or a feature, you wonder. According to the acceptance criteria, the house should have no door, so this will be handled as a feature request.

So, you demolish part of the wall and add a door. The customer likes the new door. You applaud each other and move on to building another house.

Wait, another call from the customer: They also say they miss windows. The calls, building, applauding continues for some more month. At the end, it cost ten times more, took 8 months longer; nobody is applauding anymore.

Before not after #

This could all have been avoided by planing it right from the beginning.

It has been said thousands of time; Plan for accessibility and performance before you start building. Sure, you can fix accessibility issues and improve performance after you build, but it will take way longer.

Think, think some more, start building.

Stop supporting Internet Explorer!

2022-07-06T09:12:08+02:00

As of 15th of June 2022 Internet Explorer has retired and is officially out of support.

Great, let's stop supporting Internet Explorer finally, you say? Sure, I will do the same, but your support may be different from how I approach this. Let's have a look.

Ways to support a browser #

There are two ways to support a browser:

Add polyfills/workarounds, so all unsupported features work the same in unsupported browsers as in supported browsers.
Use progressive enhancement. Basics work in every browser, new features (extras) only in supported browsers.

Support Internet Explorer #

When I say 'Stop supporting IE' it means to me that I won't go the extra mile to get unsupported features working in Internet Explorer, but still make sure Internet Explorer users get the basics, and can use the site.

For example, in one project, we are using the Beacon API for a feature (an extra, not required). At the time (about 3 years ago), we integrated the feature, Internet Explorer was still fully supported, and we had quite some users using IE11. Therefore, we decided that it's worth to load a polyfill, so IE11 users will also get this extra. Now, this changed, the numbers of IE users are really low, so we will now remove this polyfill. IE users still get the basic experience, but not this extra feature.

We could also have kept the polyfill, you say? Sure, but we try to keep our third-party dependencies as low as possible. One fewer means one fewer to check for security issues, updates – one less dependency to care about.

So, this is how I will support Internet Explorer from now on. You could also think about it this way: Your Internet Explorer user should now get the same experience as your No-JavaScript user – the basics.

Resources #

Ten years 🎉

2022-01-31T10:12:08+01:00

Reached the milestone of one decade of publishing. On this day ten years ago, I published my first article on this site.

Since then, I published over 145 articles and notes.

From the ~315.569,520 seconds since I published the first article, I wasted quite some time staring at loading screens, and trying to interact with inaccessible websites. Hopefully, though, saved some seconds for others, by helping developers build faster, and more accessible sites by sharing my knowledge here.

I haven't published a lot during the previous year, and don't really know if this will change again. I still enjoy writing and sharing content, but I don't feel forced anymore to do it.

Stay safe and on to the next ten years!

Keeping up-to-date with web development

2022-01-04T12:04:08+01:00

Over the last ten years I spend many hours to keep up-to-date with the web platform: Reading articles, writing articles, trying out new web platform features, listening to web development podcasts, using Twitter to stay in the loop, watching conference talks, reading books, reading RSS feeds.

Out of interest, I asked on Twitter how much time my followers spend on keeping up-to-date with the web platform. Most spend 0-5 hours, about a quarter spend 5-10 hours, and 11% spend 10 or more hours.

About 40% of all respondents spend more than five hours a week of their leisure time. I guess there aren’t many other professions where people spend so much unpaid time to get better at their jobs.

As a follow-up, I asked the same question, this time how much time of their paid/work time they spend keeping up-to-date. 75% spend 0-5 hours, 10% 5-10 hours, 7% 10-20 hours, and 7% spend more than 20 hours a week. It seems some companies enable employees to spend time (some quite a lot) trying out new things, and keeping up-to-date, while most don’t.

What about me? In average, I spend about 5-10 hours a week doing all this, as a freelancer this all happens in my leisure time, all unpaid. Somewhere in 2021 I reduced this to 1-2 hours, after realizing I am on my way to burn-out, spending so much time of my leisure time on keeping up-to-date.

On the one hand it’s great that the web platform evolves so quickly nowadays, on the other hand it’s getting really hard to keep up-to-date with all new features. And there is more, new frameworks, new build tools, new coding approaches, new plugins. I had to realize that is’s impossible to try out and learn everything. Nobody is able to keep up-to-date with everything; That’s okay.

Learn forms course on web.dev

2021-12-23T12:01:10+01:00

This year I was fortunate enough to write a complete course about HTML forms together with the help of Rachel Andrew and Sam Dutton.

It has been some intense months of writing and editing, and I am really excited how it turned out.

In total, there are 22 modules.

I learned a lot about forms (again), and hope you will too.

Start the course on web.dev

100 days - 100 HTML elements in a tweet

2021-04-12T15:51:20+02:00

After tweeting about a CSS property for 100 days in a row last year, I did it again this year, this time it was all about HTML elements.

Again, I learned quite a lot about a language I have been using for over 15 years now almost daily. There is some interesting about almost every HTML element. I also have to say that it is fantastic to have MDN as a reference available. You can learn so much by looking things up there.

So, without further ado here is the full list of elements I tweeted about. You can also look them up directly on twitter using the #HTMLElementInATweet hashtag if you prefer.

Day 1: <html>

The root element. All other elements must be descendants of this element.

ℹ️ Always set the lang attributehttps://t.co/1M9IuYKfnU #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 1, 2021

Day 2: <audio>

Embed sound content in documents

ℹ️ Never use the autoplay attribute - let the users decide if they want to hear it.https://t.co/a73RjyygRz #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 2, 2021

Day 3: <br>

Produces a line break in text

ℹ️ Better use <p> elements, and use CSS properties to control the spacing.https://t.co/dDkty2QVhh #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 3, 2021

Day 4: <li>

Represents an item in a list

ℹ️ You can use the value attribute to indicate the current ordinal value of the list item as defined by the <ol> element.https://t.co/x3NEHrXHNq #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 4, 2021

Day 5: <h1> - <h6>

The section headings

ℹ️ Although no browser support <h> and/or the document outline they do style headlines different based on surrounding sections https://t.co/bipv4RJ155 https://t.co/NlBCXtRtcq #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 5, 2021

Day 6: <base>

Specifies the base URL to use for all relative URLs in a document.

ℹ️ Open Graph tags do not acknowledge <base>, and should always have full absolute URLs.https://t.co/qY7k4jT4Xt #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 6, 2021

Day 7: <ins>

Represents a range of text that has been added to a document.

ℹ️ The presence of the <ins> element is not announced by most screen reading technology in its default configuration.https://t.co/okkdDoubPz #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 7, 2021

Day 8: <noscript>

Defines a section of HTML to be inserted if scripting is currently turned off in the browser.

ℹ️ If you use <noscript>Turn on JavaScript to view this page</noscript>, you are doing it wrong.https://t.co/1sHapOe0MV #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 8, 2021

Day 9: <title>

Defines the document's title.

ℹ️ It is important to provide a title value that describes the page's purpose. https://t.co/pLXMBFEkJb #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 9, 2021

Day 10: <math>

The top-level element in MathML for describing mathematical notations

ℹ️ Only supported in Firefox and Safari

Example: https://t.co/Ym9yV4DNG9 https://t.co/zKeVlxm020 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 10, 2021

Day 11: <p>

Represents a paragraph

ℹ️ The end tag may be omitted if the element is immediately followed by another block-level element.https://t.co/VJCdX94I4g #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 11, 2021

Day 12: <span>

A generic inline container for phrasing content

ℹ️ It should only be used when no other semantic element is appropriate.https://t.co/jTI5MvAZx1 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 12, 2021

Day 13: <button>

A clickable button, used to submit forms or anywhere in a document for accessible, standard button functionality.

ℹ️ A <button> inside a form will act as a submit button, unless you add type="button"https://t.co/slNtJwZBoc #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 13, 2021

Day 14: <tr>

Defines a row of cells in a table

ℹ️ There are various valid use cases for a table, layout is none of them.https://t.co/aa9w6Oo9Bw #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 14, 2021

Day 15: <div>

Is the generic container for flow content.

ℹ️ It is a container, never misuse as an interactive element.

Would personally prefer they would have it called <block> :-)https://t.co/rI22G7tcVg #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 15, 2021

Day 16: <cite>

It is used to describe a reference to a cited creative work.

ℹ️ Typically, browsers style the contents of an <cite> element in italics by default.https://t.co/9nmfjuk5vV #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 16, 2021

Day 17: <tfoot>

Defines a set of rows summarizing the columns of the table.

ℹ️ Not the most interesting element, still very useful for semantics and accessibility if used right.https://t.co/mwMTLpN3Yk #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 17, 2021

Day 18: <time>

Represents a specific period in time

ℹ️ You should include the datetime attribute to translate dates into machine-readable formathttps://t.co/UoffxKUXJc #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 18, 2021

Day 19: <body>

Represents the content of an HTML document

ℹ️ The element with the most possible attributes, including many deprecated like link="pink" (used to change default browser defined color for links)https://t.co/K2FtL6FSHn #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 19, 2021

Day 20: <textarea>

Represents a multi-line plain-text editing control.

ℹ️ Never set resize: none; better use resize: vertical; so users can still resize vertically, but it won't break your horizontal layout.https://t.co/GfiwvcM4pg #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 20, 2021

Day 21: <param>

Defines parameters for an <object> element.

ℹ️ Was useful for embedding Flash (officially gone since 31.12.2020)https://t.co/vjkogoJwCD #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 21, 2021

Day 22: <ruby>

Represents small annotations

ℹ️ The term ruby originated as a unit of measurement used by typesetters, representing the smallest size that text can be printed on newsprint while remaining legible.https://t.co/pg7Lh5q9Cb #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 22, 2021

Day 23: <colgroup>

Defines a group of columns within a table.

ℹ️ You can use the span attribute indicating the number of consecutive columns the <colgroup> element spanshttps://t.co/vInvCA4OQe #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 23, 2021

Day 24: <kbd>

Represents a span of inline text denoting textual user input from a keyboard, voice input, or any other text entry device.

For example: <kbd>Strg</kbd>+<kbd>b</kbd>: Boldhttps://t.co/jH2vI5xCNW #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 24, 2021

Day 25: <head>

Contains machine-readable information (metadata) about the document

ℹ️ There is a lot that can be in the <head> https://t.co/SBkYBl8nWl https://t.co/nClLKh7Wlk #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 25, 2021

Day 26: <meter>

Represents either a scalar value within a known range or a fractional value.

ℹ️ The meter element should not be used to indicate progresshttps://t.co/FW4EQKhALq #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 26, 2021

Day 27: <main>

Represents the dominant content of the <body> of a document.

ℹ️ Browser reader mode functionality looks for the presence of the <main> element.https://t.co/Geo65nsC2J #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 27, 2021

Day 28: <fieldset>

Is used to group several controls as well as labels (<label>) within a web form.

ℹ️ Great for grouping radio buttons, checkboxes and related fields.https://t.co/CFoYzwVK7i #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 28, 2021

Day 29: <b>

Is used to draw the reader's attention to the element's contents

ℹ️ Although browsers style content inside <b> as bold, do not use it for styling purposes.https://t.co/YwvzssVgv7 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 29, 2021

Day 30: <var>

Represents the name of a variable in a mathematical expression or a programming context.https://t.co/X3ELf5tFpO #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 30, 2021

Day 31: <map>

Is used with <area> elements to define an image map (a clickable link area).

ℹ️ Instead of image map you can create the same functionality nowadays with SVG.https://t.co/1vWcWCy21A #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) January 31, 2021

Day 32: <ul>

Represents an unordered list of items

ℹ️ If you using list-style:none; Safari will remove semantics https://t.co/xQ4ym6MyLi https://t.co/O4wIqkyp7R #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 1, 2021

Day 33: <sup>

Specifies inline text which is to be displayed as superscript

ℹ️ The <sup> element should only be used for typographical reasonshttps://t.co/9LPdgoIA5l #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 2, 2021

Day 34: <address>

Indicates that the enclosed HTML provides contact information

ℹ️ Can be used for physical address, URL, email address, phone number, social media handle, geographic coordinates, and so forth.https://t.co/QMEAa29JPl #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 3, 2021

Day 35: <picture>

Contains zero or more <source> elements and one <img> element to offer alternative versions of an image

ℹ️ Great for art direction, handling multiple image formats and adapting to user preferenceshttps://t.co/I2toAM8P1O #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 4, 2021

Day 36: <slot>

Is a placeholder inside a web component that you can fill with your own markup.

ℹ️ It lets you create separate DOM trees and present them together.https://t.co/e9Mfmw6x9e #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 5, 2021

Day 37: <aside>

Represents a portion of a document whose content is only indirectly related to the document's main content.

ℹ️ One of the elements added with HTML5 – which was already supported in IE 9 – time flieshttps://t.co/tNcJShsZGc #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 6, 2021

Day 38: <table>

Represents tabular data

ℹ️ You can use the CSS property border-collapse only for this element, although I wish it could be used for other elements.https://t.co/fhMqCDMnqL #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 7, 2021

Day 39: <caption>

Specifies the caption (or title) of a table.

ℹ️ The <caption> element should be the first child of its parent <table> element.https://t.co/1gixqJ5lLs #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 8, 2021

Day 40: <s>

Renders text with a strikethrough, or a line through it.

ℹ️ Use the <s> element to represent things that are no longer relevant or no longer accurate – not for styling.https://t.co/xhQv6giGQD #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 9, 2021

Day 41: <area>

Defines an area inside an image map that has predefined clickable areas

ℹ️ Did you know, that before image map in HTML there were server-side image maps? https://t.co/fZqCMEW3sB https://t.co/2ydPQXlZYZ #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 10, 2021

Day 42: <dd>

Provides the description, definition, or value for the preceding term (<dt>) in a description list (<dl>).

ℹ️ VoiceOver on iOS 14 Supports Description Lists https://t.co/3U5vNLRjpa https://t.co/RVg9JRnImk #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 11, 2021

Day 43: <section>

Represents a standalone section

ℹ️ If the contents of the element would make sense syndicated as a standalone piece, the <article> element may be a better choice.https://t.co/H4pXPlj2ll #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 12, 2021

Day 44: <q>

Indicates that the enclosed text is a short inline quotation.

ℹ️ Most modern browsers will automatically add quotation marks around text inside a <q> element.https://t.co/CqZoW7GRbe #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 13, 2021

Day 45: <source>

Specifies multiple media resources <picture>, <audio>, or the <video> element

ℹ️ The media attribute currently only works for <picture>, it was removed for <video> in all browsers but Safari https://t.co/94Z3tw8ES2 https://t.co/ufC46N61en #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 14, 2021

Day 46: <dfn>

Is used to indicate the term being defined within the context of a definition phrase or sentence.

ℹ️ If the <dfn> element has a title attribute, it must contain the term being defined and no other text.https://t.co/m986AlyNlc #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 15, 2021

Day 47: <embed>

Embeds external content at the specified point in the document.

ℹ️ Use the title attribute on an embed element to label its content so that people using assistive technology can understand what it contains.https://t.co/RhgTwpliKq #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 16, 2021

Day 48: <hr>

Represents a thematic break between paragraph-level elements

ℹ️ Only use if for semantic reason. If you wish to draw a horizontal line, you should do so using CSS.https://t.co/GJFGkbc4xm #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 17, 2021

Day 49: <dialog>

Represents a dialog box or other interactive component

ℹ️ While supported in Chromium, there are accessibility issues which makes it not usable for now https://t.co/dC9DVeaffd https://t.co/V7PHaDGr5I #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 18, 2021

Day 50: <tbody>

Encapsulates a set of table rows (<tr>), indicating that they comprise the body of the table.

ℹ️ If the table includes a <thead> block (to semantically identify header rows), the <tbody> block must come after it.https://t.co/M5tCuCPFo0 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 19, 2021

Day 51: <canvas>

Use the HTML <canvas> element with either the canvas scripting API or the WebGL API to draw graphics and animations.

ℹ️ You should provide alternate content inside the <canvas> block.https://t.co/c7unZdWlbY #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 20, 2021

Day 52: <abbr>

Represents an abbreviation or acronym

ℹ️ Spelling out the acronym or abbreviation in full the first time it is used on a page is beneficial for helping people understand ithttps://t.co/aBzHZtzMLH #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 21, 2021

Day 53: <a>

Creates a hyperlink to web pages, files, email addresses, locations in the same page, or anything else a URL can address.

ℹ️ If it goes somewhere, use <a>https://t.co/3lFe7alPyn #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 22, 2021

Day 54: <code>

Displays its contents styled in a fashion intended to indicate that the text is a short fragment of computer code.

ℹ️ To represent multiple lines of code, wrap the <code> element within a <pre> element.https://t.co/DDnsn7FJgm #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 23, 2021

Day 55: <sub>

Specifies inline text which should be displayed as subscript for solely typographical reasons.

ℹ️ Should be used only for typographical reasons, else use CSS like vertical-align: -25%https://t.co/LcsftBH5Sg #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 24, 2021

Day 56: <mark>

Represents text which is marked or highlighted for reference or notation purpose

ℹ️ Don't use <mark> for syntax highlighting purposeshttps://t.co/PHiUxXISxT #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 25, 2021

Day 57: <figure>

Represents self-contained content, potentially with an optional caption

ℹ️ Not only for <img>, can also be used for things like code, poems and everything referenced as a single unit.https://t.co/aa48awSs1T #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 26, 2021

Day 58: <header>

Represents introductory content

ℹ️ It was originally used as the <head> element and was used on the first website https://t.co/U8p1rlqJ1z but made it only in the specification with HTML5https://t.co/R1YfxnZjfC #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 27, 2021

Day 59: <strong>

Indicates that its contents have strong importance, seriousness, or urgency.

ℹ️ You have to be strong now, but this is not for styling.https://t.co/TfWctuelug #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) February 28, 2021

Day 60: <rb>

Is used to delimit the base text component of a <ruby> annotation

ℹ️ This feature is non-standard and is not on a standards track. Only supported in Firefox and, wait for it, Internet Explorer 5 - 11https://t.co/9iNu7xsCcX #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 1, 2021

Day 61: <thead>

Defines a set of rows defining the head of the columns of the table.

ℹ️ There was a (now obsolete) attribute called char, which is now specified (but not supported) in CSS as text-align: "."; https://t.co/WNXU0t3aJm https://t.co/ur8Re83rfP #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 2, 2021

Day 62: <nav>

Represents a section of a page whose purpose is to provide navigation links

ℹ️ Use aria-label to describe the purpose of the navhttps://t.co/CX5oVSDuuj #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 3, 2021

Day 63: <figcaption>

Represents a caption or legend describing the rest of the contents of its parent <figure> element.

ℹ️ How to figure? https://t.co/sOCylQ9yRP https://t.co/T7WsFio39a #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 4, 2021

Day 64: <bdo>

Overrides the current directionality of text, so that the text within is rendered in a different direction.

<p>This text will go left to right.</p>
<p><bdo dir="rtl">This text will go right
to left.</bdo></p>https://t.co/9QNvAh1HD1 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 5, 2021

Day 65: <meta>

Represents metadata that cannot be represented by other HTML meta-related elements

ℹ️ There are many interesting standard metadata names https://t.co/VNFmOXVZzv https://t.co/pozxavczFW #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 6, 2021

Day 66: <del>

Represents a range of text that has been deleted from a document.

ℹ️ As it is not announced to screen reader you should use :before/:after to announce it https://t.co/jJD0twc2od https://t.co/g6F1ndpQJf #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 7, 2021

Day 67: <input>

Is used to create interactive controls for web-based forms in order to accept data from the user

ℹ️ Don't use the placeholder attribute instead of a label.https://t.co/b1KBxtS7oG #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 8, 2021

Day 68: <template>

Is a mechanism for holding HTML that is not to be rendered immediately when a page is loaded

ℹ️ Great for web components to define the enhanced HTML.https://t.co/zzgt2lQAe2 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 9, 2021

Day 69: <hgroup>

Represents a multi-level heading for a section of a document

ℹ️ It is partially implemented in most browsers, but will most likely never be usable. Looking at you outline algorithm.https://t.co/ojBekuxNUv #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 10, 2021

Day 70: <iframe>

Represents a nested browsing context, embedding another HTML page into the current one.

ℹ️ Always set the title attribute to concisely describe the embedded content.https://t.co/hKEF3Brl0N #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 11, 2021

Day 71: <samp>

Is used to enclose inline text which represents sample (or quoted) output from a computer program.

ℹ️ Can be used for example to show the output after running a command in bash on your site.https://t.co/TFzFdSVHWg #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 12, 2021

Day 72: <data>

Links a given piece of content with a machine-readable translation.

ℹ️ Can be combined with microformats or the microdata attributeshttps://t.co/NhLlsp9Fzr #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 13, 2021

Day 73: <summary>

Specifies a summary, caption, or legend for a <details> element's disclosure box.

ℹ️ Content can be any heading content, plain text, or HTML that can be used within a paragraph.https://t.co/kZ9nUi306l #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 14, 2021

Day 74: <style>

Contains style information for a document, or part of a document.

ℹ️ You can use the nonce attribute to whitelist inline styles in a style-src Content-Security-Policy.https://t.co/1LPAXXhtJm #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 15, 2021

Day 75: <track>

Is used as a child of the media elements, <audio> and <video> to specify timed text tracks.

ℹ️ Can be used to provide captions and subtitles.https://t.co/aOJivzBCm7 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 16, 2021

Day 76: <datalist>

Contains a set of <option> elements that represent the permissible or recommended options available

ℹ️ It is very basic and you can't really style or define when it should be shown. Still good for some use cases.https://t.co/DO2ucDECuV #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 17, 2021

Day 77: <img>

Embeds an image into the document.

ℹ️ Always set the alt attribute, use empty value if decorative or decide if background-image or none is better in that case anyway.https://t.co/TLNZwGa2lZ #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 18, 2021

Day 78: <option>

Is used to define an item contained in a <select>, an <optgroup>, or a <datalist> element.

ℹ️ Not really stylable as of now, but this might change someday I hope.https://t.co/dWkOGt4gOm #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 19, 2021

Day 79: <i>

Represents a range of text that is set off from the normal text for some reason, such as idiomatic text, technical terms, taxonomical designations, among others. https://t.co/2Z4Yd5URdW #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 20, 2021

Day 80: <video>

Embeds a media player which supports video playback into the document.

ℹ️ Videos should provide both captions and transcripts that accurately describe its contenthttps://t.co/FmuilLQYI8 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 21, 2021

Day 81: <label>

Represents a caption for an item in a user interface.

ℹ️ Don't place interactive elements such as anchors or buttons inside a label.https://t.co/UYgloacd2J #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 22, 2021

Day 82: <em>

Marks text that has stress emphasis.

<p>Use HTML <em>now</em>!</p>https://t.co/5xg3GDBnyp #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 23, 2021

Day 83: <object>

Represents an external resourcehttps://t.co/m63WG7xYq6 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 24, 2021

Day 84: <article>

Represents a self-contained composition in a document

ℹ️ Each <article> should be identified by a headinghttps://t.co/U8UACwXFYq #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 25, 2021

Day 85: <ol>

Represents an ordered list of items

ℹ️ You can use the reversed attribute to number the items from high to low.https://t.co/bT8uueUE6M #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 26, 2021

Day 86: <pre>

Represents preformatted text which is to be presented exactly as written in the HTML file.

ℹ️ If you want to show ASCII images, always provide an alternate description.https://t.co/zFtc9zsxrm #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 27, 2021

Day 87: <small>

Represents side-comments and small print, like copyright and legal text.

ℹ️ Like with every other HTML element, don't misuse for styling. https://t.co/1XPHfeotdw #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 28, 2021

Day 88: <link>

Specifies relationships between the current document and an external resource.

ℹ️ prefetch/preload can be very helpful, but as always, test if this is really the best for your case.https://t.co/Wo5bA0RZXN #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 29, 2021

Day 89: <legend>

Represents a caption for the content of its parent <fieldset>

ℹ️ Always use a <legend> if you use a <fieldset>https://t.co/AjsTCIh5Ck #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 30, 2021

Day 90: <optgroup>

Creates a grouping of options within a <select> element.

ℹ️ Use the label attribute to give the group a heading.https://t.co/X57gusVAkt #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) March 31, 2021

Day 91: <blockquote>

Indicates that the enclosed text is an extended quotation.

ℹ️ You can use the cite attribute to specify the source of the quotation.https://t.co/qB76gYp7Ba #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) April 1, 2021

Day 92: <script>

Is used to embed executable code or data

ℹ️ Use type="module" to only load JavaScript for modern browsers, make sure base experience is still working without JavaScript.https://t.co/VZybDYSSeb #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) April 2, 2021

Day 93: <select>

Represents a control that provides a menu of options.

ℹ️ Yes, hard to style, still think twice before using a JavaScript-based alternative - getting them accessibility is really hard.https://t.co/QYG7iLAw24 #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) April 3, 2021

Day 94: <output>

Is a container element into which a site or app can inject the results of a calculation or the outcome of a user action.

ℹ️ Many browsers implement this element as an aria-live regionhttps://t.co/hwbaEDHOXd #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) April 4, 2021

Day 95: <progress>

Displays an indicator showing the completion progress of a task.

ℹ️ The minimum value is always 0, and you can not set any other value for min.https://t.co/Znu2lTjqKR #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) April 5, 2021

Day 96: <details>

Creates a disclosure widget in which information is visible only when the widget is toggled into an "open" state.

ℹ️ Do not misuse as a hamburger menu.https://t.co/PyfpMKWNwU #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) April 6, 2021

Day 97: <svg>

Is a container that defines a new coordinate system and viewport.

ℹ️ You don't need the xmlns attribute when using it directly in HTML.https://t.co/cof8ojVnjl #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) April 7, 2021

Day 98: <wbr>

Represents a word break opportunity

ℹ️ Behaves like the U+200B ZERO-WIDTH SPACE code pointhttps://t.co/ZP5eVSesmH #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) April 8, 2021

Day 99: <form>

Represents a document section containing interactive controls for submitting information.

ℹ️ Your daily reminder that you can do a lot using form and server-side code.https://t.co/in4Qr8pikw #HTMLElementInATweet
— Michael Scharnagl (@justmarkup) April 9, 2021

Day 100: <footer>

Represents a footer for its nearest sectioning content or sectioning root element.

🎉 That's it. That was fun. 100 days of #HTMLElementInATweet are over now. Hope you learned something.https://t.co/KWujbA3OXH
— Michael Scharnagl (@justmarkup) April 10, 2021

Overenhancement

2021-03-19T16:04:08+01:00

A friend of mine upgraded their bicycle to an electric bicycle some years ago, mainly to improve their commute to work. It sounded like a great choice, in the end the upgrade did however not make their life easier. The upgrade had the opposite effect.

This article is all about enhancements, enhancements going too far; Overenhancements.

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." — Edsger W. Dijkstra (1930-2002) "On the nature of Computing Science" (EWD896) August 10, 1984

Hamburger #

The first websites didn't have a main navigation we are used to having today. They linked from one page to another.

Today, almost every website has some sort of main navigation – a list of links for the most important (overview) pages of a site. When smartphones got popular, people realized that the spare space available had to be used effectively. So they came up with a solution – the hamburger menu.

Given the spare space available on small screens it sounds like a great idea to hide the navigation behind a button at first and only reveal it once the hamburger is selected. This can also be build in a progressive and accessible way making it available for as many users as possible.

There is however one problem – using this pattern in every case. If you only have three navigation items, it makes no sense at all to initially hide them. Enhancing a list of three navigation items to a hamburger menu will make it more complicated to use the navigation; Overenhancement.

Tabs #

Another prominent enhancement pattern are tabs. Say, you have a page with multiple headlines all with corresponding text. In HTML one would structure it like this:

<h2>A topic</h2>
<p>This is all about...</p>
<h2>Another topic</h2>
<p>More about this topic...</p>

Now, the idea is to enhance this using tabs to save space and give the user a better overview of available topics and the option to quickly switch between them.

Again, this sounds like a great enhancement at first, and it is again possible to build it in a progressive and accessible way. For many users though, this can make things worse.

First, by using tabs you make it harder for users to use the native in-search functionality browsers offer. In addition, you may run into problems if there are too many tabs, if headlines are really long and so forth.

Most importantly, as tabs are not a native HTML feature, all work a bit differently for keyboard users, on some you can switch tabs with the arrow keys, on some only with tabs, on some with both. This makes them hard to use for keyboard users and users using assistive technologies. Much harder than our basic version with headlines and paragraphs.

There are lots of other enhancements which can turn out to have the opposite effect, so be really careful when you enhance. Don't enhance just for the sake of it.

It depends™ #

Remember my friend I mentioned at the beginning, who upgraded to an electric bicycle to enhance their commute? The reason why the enhancement did not work out for them? The commute was only 1 km and while the electric power made the biking itself less exhausting they didn't think about the other consequences.

The power only lasted for a while, so they regularly had to charge the battery, which means taking the battery out of the bicycle, charge it and not forget it to take it back the next morning. Even more frustrating was, that at work they had no elevator and as they wouldn't want their expensive bike to be stolen, they had to carry the bike (which was much heavier than the non-electric one) to the 4th floor every day.

The enhancement looked great at first, in the end though it did make their life not easier, but quite the opposite.

As with electric bicycles, there are a lot of cases where some mentioned patterns do make things easier and do enhance the user experience, at the same time there are a lot of cases where using these patterns do overcomplicate things and make it harder for users; Overenhancement.

The Void

2021-03-01T16:11:08+01:00

I have a document in Writerie which is called The Void - every time (at least most of the time) I am angry about something or want to complain and would normally tweet it out, I instead write it down in The Void.

This way it is out of the way, and at the same time I don't tweet something stupid I may regret later. Getting it out of my head is very important for me. If I don't write it down, I will think about it again and again and get mad.

The Void helps me here and frees my thoughts.

Happy voiding!

Reduce your client-side JavaScript in Next.js

2021-02-10T20:01:10+01:00

I am currently working on a side-project, where most parts are static, but there are pages where I need to access a database and do things on the server which I can not pre-build. In the past I would have probably used Node.js with an Express server for this, but I thought it is time to give Next.js a try. After using it for some weeks, I have to say I like it, and it is a good option for these type of projects.

The performance you get with Next.js is already pretty good, but there is always room for more. In this article I would like to outline some ways to ship less client-side JavaScript in Next.js.

Disable client-side JavaScript #

Almost every app or site has one or various landing pages. And let's be honest here - a lot of users visiting your landing page(s) will leave your site without further interacting with it. Therefore, we should do our best to serve that page(s) as fast as possible and requesting as few data as possible. If it takes too long to load, people may even leave before they see the content – another potential customer lost.

Among optimizing images, limiting web fonts and other performance improvements, we could serve this pages without any client-side JavaScript. Almost all landing pages I ever visited are static and not interactive, so why ship JavaScript if you don't need it there?

In Next.js by default there will always be client-side JavaScript, but you can disable this with this experimental config.

export const config = {
  unstable_runtimeJS: false
};

You can add this to every page (path), where you don't need client-side JavaScript. I said it is experimental, so while it works great for me, there may be some edge cases where this won't work.

I learned about this one from Andy Bell

Use Preact #

You don't have only landing pages in most of the cases, so what can you do to reduce the size of your client-side JavaScript? A good approach for many apps to replace React with Preact.

As a first step to use Preact instead of React, we should install the needed Preact packages by running

npm install --save preact preact-compat preact-render-to-string

in your terminal.

Now we can open our package.json and alias React to Preact with:

"react": "github:preact-compat/react#1.0.0",
"react-dom": "github:preact-compat/react-dom#1.0.0"

and after that open your terminal and run

npm install

just to be sure.

As a last step, we can uninstall react and react-dom by running

npm uninstall react react-dom

In the end it should look like this:

{
  "dependencies": {
    "preact": "^10.5.12",
    "preact-render-to-string": "^5.1.12",
    "react": "github:preact-compat/react#1.0.0",
    "react-dom": "github:preact-compat/react-dom#1.0.0"
  }
}

While using Preact instead of React will reduce your client-side JavaScript enormous, but be aware that not everything may work as expected by using Preact instead of React. You should still at least try to replace it, if you encounter unsolvable problems you can switch back pretty easy.

Preload #

Some time ago Harry Roberts asked about a way to disable rel="preload" in Next.js, and they got some good answers there. As with disabling client-side JavaScript there is an experimental config setting for disabling Preload using:

export const config = {
  unstable_JsPreload: false
};

This has only been added recently so may not be available in the Next.js version you are using. And it is also experimental, so be aware that I may not always work like expected.

Conclusion #

Next.js is already doing a great job regarding performance, but as you can see there are some ways to reduce the JavaScript code users have to download and most important, the JavaScript code the browser has to parse and execute. I always recommend testing your site with an average Android Device like the Moto G. If you don't own such a device you can also use WebPageTest to test on a real Moto G – if your site loads fast there, you have done a great job.

Resources #

Nine years

2021-01-31T12:11:08+01:00

The site is live now for almost a decade. Nine years ago I published my first article here.

Since then, I published over 140 more articles and notes.

The biggest change on this site since last year is, that I now a have a bookmark section. I wrote an article about this change and how you too can integrate Pocket in your Eleventy site.

There is also another section coming to this page - the reading section. It is almost done and will go live soon. It will be a bit different from the usual bookshelves, but I think you will like it.

I also wanted to restyle everything again, but this will take some more time, as at the moment I enjoy writing more than redesigning.

Oh, and early this year I added the option to support me underneath each article. Thanks to everybody supporting, reading, sharing and discussing my articles. Thank you.

On to the next nine years!

Integrate Pocket in Eleventy

2021-01-19T13:04:10+01:00

I have been using Pocket since many years to organize my bookmarks and reading list and thought it would be great to show them on my blog where I use Eleventy. In this article you will learn how to get your data from Pocket and show them on your Eleventy site.

Get a consumer key from Pocket #

We assume that you already have a Pocket account, if not you should register an account there first.

First, we need a consumer key, which we get on their Developer site - use "Create an Application" there. Give it a name and description of your choice, set permissions to Retrieve, and Platforms to Web. After the application got created you will be directed to a site where you can see your consumer key which you should save somewhere now as we need it later.

Obtain the access token #

To be able to use the Pocket API, we also need the access token of our account. To get this you can use pocket-auth-cli

Open your terminal and install the package globally:

npm install -g pocket-auth-cli

After the installation is finished run the following command (replace <consumer_key> with the key you saved above):

pocket-auth <consumer_key>

If everything worked, you will see your access_token in your terminal. Copy and save that as we also need this one later as well.

You can test if all worked by opening the URL https://getpocket.com/v3/get?consumerkey=<consumer_key>&access_token=<access_token> in your browser (replace <consumer_key> and <access_token> with your data)

Fetch data from Pocket #

Now, let's switch to your Eleventy project.

To start, create a file called pocket.js and save it in the _data folder (if you don't have the _data folder already create it now)

Now, switch back to the terminal and navigate to the root of your Eleventy project. To be able to fetch data, we need to install node-fetch and to be able to read our environment variables (more on this later) we need the dotenv package

npm install node-fetch dotenv --save-dev

After this has been installed, we need to define the environment variables. To do this in your local project, create a file called .env (if there is none) and safe it in the root of the project.

Note: Never add your environment variables and files (in our case .env) to your Git repository. To avoid ever having them there you can use a .gitignore file in the root of your project and add .env there.

Next, we define our variables there:

POCKET_CONSUMER_KEY=CONSUMER_KEY
POCKET_ACCESS_TOKEN=ACCESS_TOKEN
POCKET_TAG=TAG

Replace CONSUMERKEY and ACCESSTOKEN with your values you saved above. For TAG, you can either use the value all to get all, or use one of your tags to be able to define what you want to show in public. I use a tag called public for example.

Now, let's move back to our code editor and open the pocket.js file we created before and insert the following code.

const fetch = require("node-fetch");
require('dotenv').config()

const CONSUMER_KEY = process.env.POCKET_CONSUMER_KEY;
const ACCESS_TOKEN = process.env.POCKET_ACCESS_TOKEN;
const TAG = process.env.POCKET_TAG;
const POCKET_URI = `https://getpocket.com/v3/get?consumer_key=${CONSUMER_KEY}&access_token=${ACCESS_TOKEN}&tag=${TAG}`

module.exports = async function() {
    return fetch(POCKET_URI)
        .then(res => res.json())
        .then(json => {
            return Object.values(json.list);
        });
};

Let's go through this. In the first two lines we import the packages we installed before. Next we define some variables we extract from the .env file. The interesting part happens in module.exports.

There we have a function, which uses fetch to, well fetch the data from the pocket API, transform this to json and return an Object with our list of items we saved in Pocket.

Integrate in your template #

Now, that we have the data fetch in place, let's integrate the data in our template. We are using Nunjucks as our template engine as the example here, but you can also use any other template language supported by Eleventy.

{% if pocket.length %}
  <ul>
  {%- for entry in pocket | reverse %}
    <li>
      <h2><a href="{{ entry.given_url }}">{{ entry.resolved_title }}</a></h2>
      <p>{{ entry.excerpt }}</p>
    </li>
  {%- endfor %}
  </ul>
{%- endif %}

Let's have a look there. First we check if there are any items available at all, and if yes, output an <ul>.

Now we use a for loop to go through every item and output some of the values we got from Pocket. On the Pocket Developer site you find a list of all values available.

With this in place, we can go back to the terminal and run the Eleventy serve command:

npx eleventy --serve

If you now open the template where you integrated Pocket you should see a list of all your items (or if you used a specific tag, all your items tagged with the specific tag).

You can now deploy your site and show your Pocket list on your site.

Extra (automatic deploys, caching) #

You most probably want to have the data up-to-date and have automatic deploys. Here is a tutorial how you can do that on Netlify, but this is also possible with many other hosts. In my case it is a bit more complicated, so will share my setup to do automatic deploys on a traditional hoster in a future article.

Be aware that there is a rate limit, but it is very generous with 320 calls per hour. You probably will never reach that, but you may still want to cache data requests. I won't cover this here as well, if you want to integrate caching I can recommend this tutorial.

My Bookmarks #

If you are curious what I have saved at Pocket have a look at my bookmark section

Make the page count of a 3D book visible using CSS custom properties

2021-01-12T13:34:10+01:00

I am currently building a book section for this site and thought it would be cool to show the books in 3D and also to make it visible how many pages a book has. In this article I would like to show you how to use CSS custom properties to adapt the depth of a 3D book showing how many pages the book has.

3D Book in CSS #

There are many resources and code examples how to build a 3D Book in CSS. As a starting point I used this.

Here is the HTML for creating the book:

<div class="book">
  <div class="book__wrapper">
    <img class="book__cover" src="/books/world-wide-waste.jpg" alt="World Wide Waste: How Digital Is Killing Our Planet-and What We Can Do About It by Gerry McGovern "/>
  </div>
</div>

And here is the CSS:

.book {
  width: 200px;
  height: 300px;
  margin: 30px;
  display: flex;
  align-items: center;
  justify-content: center;
  perspective: 400px;
}

.book__wrapper {
  transform: rotateY(-30deg);
  position: relative;
  transform-style: preserve-3d;
  width: 200px;
  height: 300px;
  transition: transform 1s ease;
}

.book__cover {
  position: absolute;
  background: #0d47a1aa;
  width: 200px;
  height: 300px;
  border-top-right-radius: 3px;
  border-bottom-right-radius: 3px;
  box-shadow: 5px 5px 20px #666;
}

.book__wrapper::before {
  content: ' ';
  background: #fff;
  height: calc(300px - 2 * 3px);
  width: 50px;
  top: 3px;
  position: absolute;
  transform: translateX(calc(200px - 50px / 2 - 3px)) rotateY(90deg) translateX(calc(50px / 2))
}

.book__wrapper::after {
  content: ' ';
  position: absolute;
  left: 0;
  width: 200px;
  height: 300px;
  border-top-right-radius: 3px;
  border-bottom-right-radius: 3px;
  background: #01060f;
  transform: translateZ(-50px);
  box-shadow: -10px 0 50px 10px #666;
}

Demo: https://jsbin.com/nuzaten/1/edit?html,css,output

Customize via CSS custom properties #

This looks already really great, so now enhance this and change the depth of the book based on the pages of the book.

First let's define a range – I decided to increase the depth every 50 pages, starting from 50 pages and ending at 1000 pages.

html {
  --page-count: 50;
  --page-count-range: clamp(1, calc(var(--page-count) / 50), 20);
  --page-width: calc(10px * var(--page-count-range));
}
/* only showing the updated stuff here */
.book__wrapper::before {
  width: var(--page-width);
  transform: translateX(calc(200px - var(--page-width) / 2 - 3px)) rotateY(90deg) translateX(calc(calc(var(--page-width)) / 2))
}

.book__wrapper::after {
  transform: translateZ(calc(var(--page-width) * -1));
}

Let's go through this.

First, we set three CSS custom properties whereas the first one defines the actual page count.

In the second one it is getting interesting. There we use clamp() to define our minimum as 1 (50 pages or fewer), our preferred value (page count divided by 50) and a maximum of 20 (1000 pages or more).

In the last property we multiply the range by 10px, so we can use that in our CSS for the transform and width properties that we need to adapt.

If you open the demo you can change the --page-count property to see how the depth changes. And that's it. With some small changes, the depth of the book is now reactive. CSS: What a wonderful language!

That was a fun challenge and can't wait to share my book section where you will see this in action.

Resources #

Demo: https://jsbin.com/dozadun/3/edit?html,css,output
Create an animated 3D book in CSS, step by step

Loading and replacing HTML parts with HTML

2020-12-28T14:11:08+01:00

In the last weeks there has been another round of approaches about loading HTML and server-rendered components. We had the option to only load and replace some parts of an HTML page for over 20 years with JavaScript, and even longer by using framesets. The idea is always the same, replace only some parts of HTML instead of loading everything again. There has been many approaches to load and replace parts of a document and there will be many more. This got me thinking again. What if we can do that with HTML properly. In this article I would like to describe an idea to load and replace HTML with HTML and why browsers could do it best.

Disclaimer: I am probably not the first one thinking about such an approach, but I couldn't find any article describing. If you know about one, please let me know.

The idea #

Let's get straight to the basic idea with an example:

<a href="/another-article.html" target="#main">Another article</a>
<main id="main"></main>

So, if a user clicks on the link, there will be no page reload, instead the browser will fetch another-article.html, parse the HTML, look for the first element with the id of main, and replaces the content on the page the link was triggered.

This means, by adding two attributes in our HTML to make a connection we can get SPA-like loading experiences. The browser will do the job, they would also replace the title of the page, not load any requests outside our target, take care of focus and browser history and probably also about caching and more.

This feature should make simple things simple and also possible to achieve more complicated things, which I will explain later down.

Note: We would need another attribute, as using a value like "#main" for target currently opens the page in a new tab - which is not what we want as a fallback.

Let the browser do the job #

This can all be done already today using JavaScript, but to make this accessible and robust you need to take care of a lot of stuff and handle edge cases you might never think of. This is hard. Do you handle focus properly, do you update the title correctly, do you handle errors correctly and much more? So, why not let the browser to the job.

Accessibility build-in #

HTML is accessible by default, at least mostly. This is a big advantage over any approach using JavaScript to replace HTML - doing it with JavaScript means you have to take care of accessibility for yourself, and it is easy to do it wrong. By using HTML it is less likely that we will mess it up, on top of it is also a lot more robust, if there are any JavaScript errors it will still work.

There are a lot of intelligent people writing specifications and implementing this in browsers. They know their job and I have more trust in native features over any tool/library to make something accessible. It would make it also a lot easier for assistive technologies to adapt to this.

Easily enhanceable #

As said above I would like to make it as simple as possible to use this, but also give developers tools to handle more complicated use cases.

Enhance with JavaScript #

On top of the HTML part, there could be JavaScript events we can listen to. There could be an event when the fetch starts, one while the browser is loading and parsing the document and one once it is done.

const myElement = document.getElementById('main');

myElement.addEventListener("beforeload", function(event) {
  console.log("The user triggered a change of the content");
});

myElement.addEventListener("loading", function(event) {
  console.log("The content is loading");
});

myElement.addEventListener("loaded", function(event) {
  console.log("Successfully replaced the HTML of #main");
});

There may be even more events, but this would already make it possible to add transitions and animations and more and improve the loading experience even more.

Enhance with CSS #

Speaking of transitions and animations, why not also implement a new CSS pseudo-class on top of it.

main:loading {
  filter: blur(5px);
}

main:loading:before {
  content: "Loading";
}

This would make it very easy to implement the loading experience we are used from SPA today.

We also may want to change the styling of the current active navigation item, so we could get another pseudo-class there as well, which will check the value of the href attribute and if it matches will apply the styles, something like:

a:active-link {
  font-weight: bold;
}

Enhance with request header #

You might wonder why my idea is based on the idea to fetch the whole document, and not only parts of it, say you have the full html and then only the HTML of main at another-article.content.html. This would require quite some changes to implement and not every developer might be able to generate two versions. The simple should be simple principle.

The browser could however send a header for these types of links, say something like:

link-target: #main

This way developers could check for the header on the backend and only send back the HTML required.

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Another article</title>
</head>
<body>
  <main id="main">
    <h1>Another article</h1>
    <p>Lorem</p>
  </main>
</body>
</html>

This would reduce the page load even more.

Conclusion #

Does this make sense at all, or is it a bad idea? Please let me know.

There are of course many details missing here, but I really would like HTML to be more powerful, and I think showing other content without a full page reload is something people wanted for decades and will probably also want in the future, so it may be worth to see if we can do this in HTML.

To be honest, I had to write this down, because I was thinking about this for way too long, and by writing it and publishing it, it is out of my head and I can focus on other things again.

I would still like to follow-up on this and will open an issue about this in the GitHub repo of the W3C in the new year.

References #

Hotwire https://hotwire.dev/
React Server Components https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
HTML: The Inaccessible Parts https://daverupert.com/2020/02/html-the-inaccessible-parts/
Smaller HTML Payloads with Service Workers https://philipwalton.com/articles/smaller-html-payloads-with-service-workers/

Too much noise

2020-11-13T10:11:08+01:00

On the 12th of November I decided to take a break from Twitter. I really enjoy the little bubble I have there, meet new people there, made new friends, and discovered lots of fantastic resources there. It also helps me to keep up-to-date with all the stuff happening in Frontend. The problem is that it is too much, the constant feeling of missing out if I don't check my Twitter feed for some time, the urge to contribute there. It more and more felt to me like a huge to-do list which grows and grows and will never be completed.

It's all about engagement and social networks know how to play this game perfectly. I don't want to play this game any more.

I am sure I will return to Twitter again, but first I have to find a cheat which works for me to be able to play there again. Maybe it will be screen-saving apps, which won't let me access twitter after I spend, say 30 minutes there a day, or something else. We will see.

After one day I still have the reflex to open twitter, but I am logged out everywhere, and so I just see the login screen and close it again.

In the meantime I really look forward to writing more here on my blog.

Stay healthy and happy.

If you want to get in touch, you can still reach me by good old Email

Styling the details element

2020-09-22T07:11:10+02:00

I recently worked on a FAQ page, and as I like semantic and accessible HTML I chose to use the <details> element to show the questions and answers. The default styling of <details> is pretty okay, but the designer had something different in mind, and so I had to find ways to style it according to the design specification.

In this article you will learn how to style the summary, change the default arrows, and how to animate the opening/closing.

Style the summary #

First I had to get rid of the default disclosure triangle.

The <summary> element supports the list-style property, so to remove the default triangle we can use list-style: none; to remove it. In theory, we are done now, the icon is removed, and we can add our own icon. Unfortunately, Chromium-based browsers do not support list-style on the summary element, so we additionally have to use the non-standard ::-webkit-details-marker

Here is the CSS to remove the icon in all modern browsers:

summary {list-style: none}
summary::-webkit-details-marker {display: none; }

With this in place we can now add our own icons.

details summary::before { 
  content:"🡒"; 
  color: red; 
  /* you can style it however you want, use background-image for example */
}

/* By using [open] we can define different styles when the disclosure widget is open */
details[open] summary::before { 
  content:"🡑"; 
  color: red 
}

Animate it #

The next issue was that the designer didn't like the abrupt opening/closing. To achieve this, we need a way to transition the height of the content. As you may know, transition doesn't work for height: auto; and while there are some workarounds to still achieve this in CSS, this won't work for <details>.

To still achieve this we therefore need JavaScript and here is my attempt.

@keyframes slideDown {
  0% {
    opacity: 0;
    height: 0;
  }
  100% {
    opacity: 1;
    height: var(--details-height-open, '100%');
  }
}

html {
  --details-transition-time: 400ms;
}

details {
  transition: all ease-out var(--details-transition-time, 0);
  max-height: var(--details-height-closed, auto);
}

details[open] {
  max-height: var(--details-height-open, auto);

}

details div {
  transition: all ease-out var(--details-transition-time, 0);
  max-height: var(--details-content-height-closed, auto);
  overflow: hidden;
  animation-name: slideDown;
  animation-duration: var(--details-transition-time);
}

details.is--open div {
  max-height: var(--details-content-height-open, auto);
}

const details = document.querySelectorAll('details');

details.forEach(detail => {
  const detailContent = detail.querySelector('div');
  const detailClosedHeight = detail.scrollHeight;
  // open the details to get the height of the content
  detail.open = true;
  // pass it to the the element as CSS property
  detailContent.style.setProperty('--details-content-height-open', detailContent.scrollHeight + 'px');
  detail.style.setProperty('--details-height-open', detailContent.scrollHeight + detailClosedHeight + 'px');
  // close the details again
  detail.open = false;

  detailContent.style.setProperty('--details-content-height-closed', detailContent.scrollHeight + 'px');
  detail.style.setProperty('--details-height-closed', detailClosedHeight + 'px');

  detail.addEventListener('click', (ev) => {
    const container = ev.target.parentElement;
    // get time of transition from CSS property
    const timeout = getComputedStyle(container.querySelector('div')).getPropertyValue('--details-transition-time');
    
    // we can't use [open] as it will be only removed after the transition
    container.classList.toggle('is--open');
   
    // remove the open attribute once the transition is done, because otherwise we won't see the transition
    if (container.open) {
      ev.preventDefault();
      setTimeout(function() {
        container.open = false;
      }, parseInt(timeout))
    }
  })
});

Lets got through it line by line.

First, let's get all details in the DOM and iterate over them.

Next, we set the open attribute to true to get the actual height of the content, pass it to CSS using custom properties and remove the open attribute again.

After that we create an eventListener for the details element.

There we get the transition time defined in our CSS which we use further down.

Next we toggle the class is--open, which we need in CSS to make the transition work, as we can't use the open attribute for this. The reason is, that if we would use the transition on [open] it will only work when opening it, but not when closing it, as the content will transition, but the details will already be closed by then.

To avoid this, we set a timeout here with the value we set in CSS before via a custom property and remove the open attribute not before the transition is done.

As an extra for Chromium we have to use CSS animation for the opening, as transition somehow doesn't work there. To get it also working in Safari, we need also transition the height of the details itself.

Reacting to preferences and screen changes #

There is still some issue with this approach, if you resize the browser the height of the container will be either too small or too big.

details.forEach(detail => {
  // ...code from above

  // this is the new part
  window.addEventListener('resize', (ev) => {
    // if the details is open, adjust height
    if (detail.classList.contains('is--open')) {
      detailContent.style.setProperty('--details-height-open', detailContent.scrollHeight + 'px');
      }
  });
});

To correct this, we listen on resize and if the details is currently open, we change the value of our CSS custom property, to adjust the height accordingly. This way the height of our details element is always as big as the content.

As a final step let's reduce the transition time to 1ms if the user prefers reduced motion.

@media (prefers-reduced-motion: reduce) {
  details div {
    --details-transition-time: 1ms;
  }
}

With this in place we are done. The details element is now styled to our liking and there is a transition when opening/closing it.

You can find the final demo on JS Bin.

Resources #

Update 24.09.2020: Vadim Makeev pointed out that the opening transition is not working in Chrome and Safari. And while I was 100% sure it did work at least in Chrome, they were absolutely right and it didn't work. To fix this in Chrome I added the animation.

Update 25.09.2020: Add workaround for Safari to transition also there the opening.

Better Image Description Browser Extension

2020-06-09T06:11:08+02:00

I sometimes run accessibility audits and one issue I almost always find is missing or insufficient alt text for images. Many of these images are from authors publishing the images via some sort of CMS.

To make it easier for them and for everybody else to see if an image has insufficient alt text I created a browser extension which lets you run a check on every website.

Note: This is meant for everybody and not only developers.

Firefox #

There is a Firefox extension available if you want to give it a try.

Chrome #

There is also a version for Chrome which will also work in most other Chromium-based browsers like the new Edge.

Current checks #

The following checks are currently covered:

Missing alt attribute (error)
Name of image is used as value for alt attribute (error)
Only the word image is used for the alt attribute (error) - looking at you Twitter.
Empty alt attribute (warning, one should check if only decorative)
Image uses aria-hidden, aria-role="presentation" or aria-role="none" (warning, one should check if only decorative)
Alt attribute uses the same text as the nearby headline. (warning)
Alt attribute starts with "Image of" (warning)
Alt attribute contains image extension (.jpg, .gif) (warning)
Alt attribute contains two or fewer characters (warning)
Image is only child of link (warning, alt should describe the link action)

There will be more in the future, but it is a good start I think.

If you have any feedback or checks I should add please let me know via Email or on Twitter

The need for a web accessibility law

2020-05-27T14:23:12+02:00

Yesterday I was frustrated again that so many websites are still inaccessible, so as you do, I tweeted.

More and more convinced that the only way to improve accessibility of the web is to have laws.

Laws written by accessibility experts in force in every country.

GDPR, but done right.

As this got quite some replies, and as Twitter is a bad place to write about complex stuff, you can now read here why I think that we need a global web accessibility law.

Nobody cares #

By "nobody" I mean all the A holes not caring about accessibility. If you care and build accessible sites, you don't belong to this group and are a good person.

The current analysis from WebAIM (web accessibility in mind) about the state of web accessibility of the top one million websites shows that it got even worse as it was already before. Detectable WCAG (Web Content Accessibility Guidelines) failure rate rose from 97.8% to 98.1%.

They found for example that 56% of the 3.4 million form inputs identified were unlabeled. This is so frustrating. Adding a label for form inputs is really not rocket science and there is no reason why you should not use a label.

So, why are still so many sites shipped with these issues?

Learning #

If you are able to develop a site with React, there is no reason you can not make it accessible. There are millions of resources out there - articles, videos, conference talks, code examples, tools... It is all there.

Say you are looking for a new job, you open one of the job search sites and search for "frontend". I just did this and got 6.565 jobs listed for Germany. Next, I used the advanced search and filtered all jobs which contains the word "accessibility" or the German translation "barrierefreiheit" - only 126 jobs were left. 98% of all frontend jobs currently listed don't require any sort of skills regarding accessibility. This also show how few companies care.

Out of curiosity I also checked how many listings used "react" - 1.753 jobs.

This is a big issue. To get a job you have better chances if you know react than by knowing about web accessibility.

If you don't need accessibility to find a job, don't need it in your job, it is less likely you ever learn it.

So, what can be done to make accessibility a requirement for all sites, to make it the standard?

Penalize sites #

We can write millions of more articles, publish thousands of more videos about accessibility, build hundreds of more examples and tell everyone why accessibility is not a feature but the standard way of building a site. In the end, people and companies are sill A holes and don't care.

So, in my opinion, the only way to improve accessibility is by enforcing it.

Search engines #

Years ago, only a few sites used HTTPS. Even if using HTTPS would make a site more secure, most companies didn't care. This all changed when Google announced that they will reward sites using HTTPS. Suddenly all sites switched to HTTPS. I remember various clients I tried to convince for month that they should HTTPS, they all refused to until the announcement – suddenly they wanted to switch as soon as possible.

It clearly shows how much companies care about SEO. They don't use HTTPS now because they care about security, they do because they don't want to be penalized by search engines.

If Google would announce that they will start penalizing inaccessible websites, I am sure all sites will do everything to make their sites accessible. Again, not because they care about their user, they only care that they will lose money.

Browsers #

Similarly to search engines, browser can also influence how sites are build. For insecure HTTP sites, browser nowadays clearly show in the address bar that the site is not secure - you don't want to be that company having to tell users why their site is not secure.

Browsers could also show a warning if a site is inaccessible. As nobody wants a warning when visiting a site, they again would start making their sites more accessible.

Especially search engines could help to make the web more accessible. There is just one problem – unless with HTTPS, it is nearly impossible to automatically check if a site is accessible. Yet, they could check for color contrast, missing alt attributes, missing semantic, missing labels – this would already help a lot.

Even, if search engines would introduce an accessibility ranking and browsers would start showing a warning for inaccessible sites, it may be not enough.

A new law #

Which brings us to the title of this article.

As of today (May 2020), there are various Web Accessibility Laws & Policies in place in various countries. The first issue here is that almost no country enforces the law they have, the other one is that they are country specific, the third one is that these laws are really hard to understand by average people.

Global #

As you may know, WWW means World Wide Web. There is no Austria Web, no South African Web, no Peru Web. So why should we have a law which only applies to one country. This makes no sense.

By experts #

The law has to be written by web accessibility experts, by people knowing everything about web accessibility.

In addition, there has to be a version for us. A version which is understandable, a document you can actually read. This is really important.

Enforcement #

The law needs to be enforced. First it should apply to all government and public sites, later for all commercial sites.

Two years ago GDPR went into effect. Personally I don't have the feeling that my data are now more secure and more private. All the big tech companies still collect all the data they can get, the only thing that changed seems to be that we now have annoying cookie consent popups on every site. All hate these popups.

I still don't know why they didn't use DNT (Do not track header) there. This would have been so much more user-friendly.

Anyway, we should learn from GDPR and don't make the same mistakes when introducing an accessibility law.

I have no idea how to write a law, but I think we really need one to make the web a better place.

Being optimistic, I also think that we will never get such a law. But the chances are still better than hoping people will not be A holes anymore.

Read out loud - Text to speech with the Web Speech API.

2020-05-19T04:31:10+02:00

I recently added Text to speech for Writerie and here is what I learned about using the Web Speech API.

Check for support #

Before using it we have to check if the browser supports the Web Speech API. We can do this by using a feature test.

if ('speechSynthesis' in window) {
    // Great, browser supports the Web Speech API - let's use it
}

Voices #

With that in place, we can now start using it. First, let's see how to get all available voices.

window.speechSynthesis.getVoices();

The available voices differ quite a lot between browser and OS. On Microsoft and also on the new Edge on Mac you will get specific Microsoft voices, on all Google browsers you get Google voices and in some like the Yandex browser you will only get one native voice. For me personally the Microsoft voices sound much less robotic as others.

One thing to note here is that on Chrome you will get an empty list if you call getVoices() directly. This is because when a page is loaded, it takes some amount of time to populate the voices array as it does so, asynchronously. If you need to get the voices on page load you can work around this by calling getVoices() after a timeout of some milliseconds (50 seems safe) or by using a Promise. If you call it after a user interaction you should be fine, as at this point it should already be populated.

Utterance #

Next, let's have a look at SpeechSynthesisUtterance, which represents a speech request.

const utterance = new SpeechSynthesisUtterance();
const voice = window.speechSynthesis.getVoices()[0];

// Utterance properties
utterance.text = 'My text';
utterance.voice = voice;
utterance.pitch = 1;
utterance.rate = 1;
utterance.volume = 1;

You can define what text should be spoken, what voice should be used, and the pitch, rate and volume.

If you don't define a voice it will use the first voice in the getVoices() array. For pitch, rate and volume the default values are 1.

Text is empty by default, and can either be set via new SpeechSynthesisUtterance().text or directly by using new SpeechSynthesisUtterance('My text');

Note that the maximum length of the text that can be spoken in each utterance is 32,767 characters.

Speak, pause, resume, cancel #

Now, let's see how to speak out our defined text. This can be done by calling .speak() and passing our defined utterance.

window.speechSynthesis.speak(utterance);

The text will now be spoken with all the settings you defined for the utterance.

To pause the text use window.speechSynthesis.pause(); to resume from there window.speechSynthesis.resume(); and to cancel it completely use window.speechSynthesis.cancel();.

Breaks #

If you pass a text it will be spoken one sentence after another. While it makes a small break after every dot, line breaks are ignored, to force a break you can however use a comma (,). Here is a simple example to replace all line breaks with a comma for a break.

text = text.replace(/nn/g, ', ');

Chrome bug #

I initially tested in Firefox, where everything worked perfect. When I tried it in Chrome though, it always stopped after some seconds and it took me some time to realize it is a browser bug and not a bug in my code.

In Chrome on Windows and Ubuntu, it always stops after about 15 seconds. To work around this, one have to create an interval which runs every 14 seconds and checks if it is still active.

const synthesis = window.speechSynthesis;
const utterance = new SpeechSynthesisUtterance('Hello');
let isPlaying = false;

this.synthesis.speak(utterance);
isPlaying = true;

// somehow chrome stops after 14seconds, so resume from there
var synthesisInterval = setInterval(() => {
    if (!isPlaying) {
        clearInterval(synthesisInterval);
    } else {
        synthesis.resume();
    } 
}, 14000);

utterance.onend = () => {
    isPlaying = false;
}

Demo #

I put the code for the demo on Github and you can also directly try the demo here.

You should also try it out in Writerie.

Conclusion #

Text to speech is a great enhancement. People often prefer to listen instead of reading and by using the Web Speech API we can offer that with little effort.

Written with Writerie

2020-04-23T10:38:12+02:00

Earlier this week I finally launched Writerie – a distraction free writing tool. Here is my story why I build it, what it is and what the future will be for Writerie.

Background #

I first started to build a writing tool in summer 2017, because I wanted a place where I could store all my documents and articles and not being tracked. Until this point I mostly just used my code editor to write in Markdown, but this meant I couldn't edit them on the phone or if I don't have my laptop with me. The first version was very basic and was missing a lot of things, but it did the job for me.

Time went by and I rarely made changes here and there. Until Autumn 2019, when I wanted to finally make it more usable. At this point I restarted the project with the goal to launch it in 2020 and make it usable to others as well. What followed were months of work.

Status Quo #

I had thousands of features planned, but also knew that I should first start with a Minimum Viable Product, before having built hundreds of features nobody wants.

On top of accessible and privacy friendly which I don't see as features but as a given for every project I wanted to have the option to use plain Markdown to write, but also to have a Rich Text Editor for things like a table which I still find harder to do in Markdown than via a User Interface. So I build it this way that you can switch every time between the two modes.

Another feature I wanted to have is a better integration of links (resources). You can easily add links to Writerie and later use them in any document. Links are regularly unreachable after some time, so in Writerie we check all links if they are still reachable and show you a warning if not.

We also generate an automatic outline for you, so you have a better overview on longer documents.

One of the last things I implemented were comments. This makes it possible to add a comment for every text snippet. It works in Markdown and in WYSIWG Mode and we also added to option to include or exclude them in the export (we support PDF, HTML and Markdown for now). Thanks to Heydon Pickering for proposing it.

It also supports Dark/Light Mode of course.

On 21. April I finally launched the site. It is not perfect, but it is a start. Yes, we are in a pandemic right now and I have thought a lot about postponing the launch to later this year or even next year, but as Cameron Moll said:

Deploying in the middle of a pandemic seems so unimportant at the moment. Or maybe there's no better time for it.

The Future #

There are a lot more features I want to integrate in the future, but I also want to build things people want, and not things I think people want, so there is a Roadmap where users can propose new features and vote on features proposed by others.

One of the next things I will integrate is Text to Speech – hearing the text you wrote often helps a lot to find errors and improve the writing style.

Some other features I have in mind are collaboration, implement a tool to catch insensitive, inconsiderate writing, integration with Static Site Generators and much more. Really looking forward to seeing how Writerie will involve in the months and years to come.

What features would you like to see in Writerie? Please let me know via Email or via Twitter DM.

Give Writerie a try

100 days - 100 CSS properties in a tweet

2020-04-15T05:51:20+02:00

At the beginning of the year I thought it may be fun to tweet about a CSS property for 100 days in a row. Before I started I wasn't really sure if there are even so many different CSS properties, but I soon realized there are much more, especially if you count all the long-hand properties as separate properties. Or did you know that there are 61 properties starting with border?

I have to say I learned quite a lot about CSS the last 100 days, many of the properties I have never used before or even never heard before. It is pretty incredible how CSS involved over all the years. I also have to say that it is fantastic to have MDN as a reference available. You can learn so much by looking things up there.

So, without further ado here is the full list of properties I tweeted about.

Day 1: outline:

- Shorthand for outline-style, outline-width, and outline-color
- Doesn't take up space, unlike border
- All sides same style, no eg. outline-bottom

ℹ️ Never set outline: none; unless you provide alternative styles.

https://t.co/utFCUb6hQz

#CSSPropertyInTweet

pic.twitter.com/YmlkCsB0IB
— Michael Scharnagl (@justmarkup)

January 6, 2020

Day 2: font-size-adjust

- How font size should be chosen based on the height of lowercase.
- Set size of fallback fonts (less FOUC)

ℹ️ Not well supported, so recommend

https://t.co/T8NyGx2ifn for now to set size of fallback fonts

https://t.co/sFpo4rFck6

#CSSPropertyInTweet

pic.twitter.com/WDJgT78sFp
— Michael Scharnagl (@justmarkup)

January 7, 2020

Day 3: transform

- Rotate, scale, skew, or translate an element.
- If value is not none creates a stacking context.
- Perfect for performant animation.

ℹ️ When using in animation make use of the prefers-reduced-motion media feature

https://t.co/zGLWTRfb8Q

#CSSPropertyInTweet

pic.twitter.com/up4M6TWO9w
— Michael Scharnagl (@justmarkup)

January 8, 2020

Day 4: display

- Sets whether an element is treated as a block or inline element and the layout used for its children, such as flow layout, grid or flex.

Too many values to fit in a tweet 😁

https://t.co/N38gILb57V

#CSSPropertyInTweet

pic.twitter.com/l2hr19mns0
— Michael Scharnagl (@justmarkup)

January 9, 2020

Day 5: clip-path

- Creates a clipping region that sets what part of an element should be shown
- You can use svg (eg. url(a.svg#b);), shape values (eg. circle(50px at 0 100px)) and geometry-box values eg. margin-box)

https://t.co/V4CrKbieg9

#CSSPropertyInTweet

pic.twitter.com/tT2CV5kH82
— Michael Scharnagl (@justmarkup)

January 10, 2020

Day 6: box-sizing

- Sets how the total width and height of an element is calculated.

/* Reset, so an element's specified width and height aren't affected by padding or borders */
*,
*::before,
*::after {
box-sizing: border-box;
}

https://t.co/LYRZIk1lBI

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 11, 2020

Day 7: position

- Sets how an element is positioned
- Possible values are relative, absolute, fixed, sticky and static

ℹ️ Use absolute, fixed and sticky positioned elements carefully, as they may be problematic for keyboard users.

https://t.co/UBFoy6p4ke

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 12, 2020

Day 8: all

- Resets all of an element's properties (except unicode-bidi and direction)
- Set properties to their initial or inherited values, or to the values specified in another stylesheet origin

https://t.co/59MGEEG3nP

#CSSPropertyInTweet

pic.twitter.com/croTcFXSQD
— Michael Scharnagl (@justmarkup)

January 13, 2020

Day 9: border-image

- Draws an image around an element. Replaces the element's regular border.
- You can use linear-gradient or an image source.

ℹ️ Always define a border-style as fallback in case the border image fails to load.

https://t.co/NUOCA9u9gH

#CSSPropertyInTweet

pic.twitter.com/fPpGfDfgAK
— Michael Scharnagl (@justmarkup)

January 14, 2020

Day 10: font

- Shorthand for font-style, font-variant, font-weight, font-stretch, font-size, line-height, font-family
- Alternatively, sets an element's font to a system font

ℹ️ Nobody* knows the correct order for the font property

https://t.co/XELaH2zRRR

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 15, 2020

Day 11: animation-play-state

- Sets whether an animation is running or paused.

ℹ️ When you set it to paused and after again to running it will start the animation from where it left off at the time it was paused

https://t.co/wyvCnNBVsk

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 16, 2020

Day 13: caption-side

- Puts the content of a table's <caption> on the specified side. The values are relative to the writing-mode of the table
- Currently supported values are either top or bottom

https://t.co/oCJ5CvSwUm

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 18, 2020

Day 14: background-attachment

- Sets whether a background image's position is fixed within the viewport, or scrolls with its containing block
- Possible values are scroll, local, fixed

ℹ️ Was already available in IE4 (scroll, fixed)

https://t.co/537iNB8zkd

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 19, 2020

Day 15: animation-delay

- Sets when an animation starts.

ℹ️ If you provide a negative value the animation begins immediately, but partway through its cycle

https://t.co/T7oLmBqmSG

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 20, 2020

Day 16: text-combine-upright

- Sets the combination of characters into the space of a single character.

ℹ️ This is used to produce an effect that is known as tate-chū-yoko (縦中横) in Japanese, or as 直書橫向 in Chinese.

https://t.co/WphlZmZaDB

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 21, 2020

Day 17: padding-block-end

- Defines logical block end padding of an element, which maps to a physical padding depending on the element's writing mode

ℹ️ To also support old Edge and IE use PostCSS or similiar

https://t.co/xlQ1JhsaKD

https://t.co/xwBMV5SuTP

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 22, 2020

Day 18: font-kerning

- Sets the use of the kerning information stored in a font.

ℹ️ In well-kerned fonts, this feature makes character spacing more uniform and pleasant to read than it would otherwise be

https://t.co/gMdW6u4dhN

#CSSPropertyInTweet

pic.twitter.com/KRds5rPPJM
— Michael Scharnagl (@justmarkup)

January 23, 2020

Day 19: columns

- Sets the column width and column count of an element.
- It is a shorthand property that sets both the column-width and column-count properties in a single, convenient declaration.

https://t.co/IL4I2i7knx

#CSSPropertyInTweet

pic.twitter.com/ygo9ouh5xy
— Michael Scharnagl (@justmarkup)

January 24, 2020

Day 20: justify-content

- Defines how the browser distributes space between and around content items along the main-axis of a flex container, and the inline axis of a grid container.

https://t.co/tbOuTMokao

#CSSPropertyInTweet

pic.twitter.com/DRfkPgUe3d
— Michael Scharnagl (@justmarkup)

January 25, 2020

Day 21: right

- Participates in specifying the horizontal position of a positioned element.

ℹ️ When both left and right are defined, if not prevented from doing so by other properties, the element will stretch to satisfy both.

https://t.co/SS7M3cJHmr

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 26, 2020

Day 22: text-shadow

- Adds shadows to text.

ℹ️ When more than one shadow is given, shadows are applied front-to-back, with the first-specified shadow on top.

https://t.co/IrNuESkzOZ

#CSSPropertyInTweet

pic.twitter.com/BQ1N6nnie3
— Michael Scharnagl (@justmarkup)

January 27, 2020

Day 23: list-style-image

- Sets an image to be used as the list item marker.

ℹ️ Be aware, you can't define the size of the used image here with CSS.

https://t.co/Ttl5OgRJnp

#CSSPropertyInTweet

pic.twitter.com/1Vn4j3ZHLU
— Michael Scharnagl (@justmarkup)

January 28, 2020

Day 24: white-space

- Sets how white space inside an element is handled.

ℹ️ To make words break within themselves, use overflow-wrap, word-break, or hyphens instead.

https://t.co/88uhqyOnRE

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 29, 2020

Day 25: scroll-behavior

- Sets the behavior for a scrolling box when scrolling is triggered by the navigation or CSSOM scrolling APIs

ℹ️ Note that any other scrolls, eg. those performed by the user, are not affected by this property

https://t.co/GnIbDgvOci

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 30, 2020

Day 26: max-height

- Sets the maximum height of an element
- Prevents the height property from becoming larger than the value specified for max-height.

ℹ️ Often used to transition height, as to height: auto not possible

https://t.co/kTtWBBjUij

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

January 31, 2020

Day 27: block-size

- Defines the horizontal or vertical size of an element's block, depending on its writing mode.

ℹ️ It corresponds to either the width or the height property, depending on the value of writing-mode.

https://t.co/NjupUrEcq1

#CSSPropertyInTweet

pic.twitter.com/k6HHYeUNf7
— Michael Scharnagl (@justmarkup)

February 1, 2020

Day 28: text-indent

- Sets the length of empty space (indentation) that is put before lines of text in a block

ℹ️ Often used to visually hide content (text-indent: -10000px;) - Better use an alternative

https://t.co/fAh536rVkv

https://t.co/ujqoSG4Rzl

#CSSPropertyInTweet

pic.twitter.com/fCPVc8n49q
— Michael Scharnagl (@justmarkup)

February 2, 2020

Day 29: justify-items

- Defines the default justify-self for all items of the box

ℹ️ In flexbox layouts, this property is ignored

https://t.co/ayVvQ3E7Lz

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 3, 2020

Day 30: scale

- Allows you to specify scale transforms individually and independantly of the transform property

ℹ️ One/two values for scale along X and Y axes, by using three values last will be for the Z axis (same as scale3d())

https://t.co/ZCn4Wcks6E

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 4, 2020

Day 31: animation-direction

- Sets whether an animation should play forwards, backwards, or alternating back and forth.

ℹ️ Possible values are normal, reverse, alternate and alternate-reverse

https://t.co/CrJTSFegGx

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 5, 2020

Day 32: mix-blend-mode

- Sets how an element's content should blend with the content of the element's parent and the element's background.

ℹ️ Creative demo:

https://t.co/kzg2mw9yAJ

https://t.co/WJYOEPh7Ue

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 6, 2020

Day 33: text-orientation

- Sets the orientation of the text characters in a line.
- It only affects text in vertical mode (when writing-mode is not horizontal-tb).

https://t.co/grMRAZ2D8C

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 7, 2020

Day 34: letter-spacing

- Sets the spacing behavior between text characters.

ℹ️ Applying negative letter spacing to headings makes them more compact and closer in appearance to the body type.

https://t.co/r5D5TdRDnH

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 8, 2020

Day 35: content

- Replaces an element with a generated value
- Applies to ::before and ::after pseudo-elements

ℹ️ Be aware that some screen reader announce the text

https://t.co/lKya6R4kQn

https://t.co/4ZjZXL8LeD

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 9, 2020

Day 36: hyphens

- Specifies how words should be hyphenated when text wraps across multiple lines.

ℹ️ Hyphenation does vary from browser to browser and language support varies quite a lot between them.

https://t.co/PorF3qmsfP

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 10, 2020

Day 37: object-fit

- Sets how the content of a replaced element, such as an <img> or <video>, should be resized to fit its container

ℹ️ It's one of the properties I somehow always forget the name and have to look it up.

https://t.co/bgGuCwUkwH

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 11, 2020

Day 38: caret-color

- Sets the color of the insertion caret, the visible marker where the next character typed will be inserted.

ℹ️ The caret is typically a thin vertical line that flashes to help make it more noticeable.

https://t.co/BwwdaVmdvi

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 12, 2020

Day 39: scroll-margin

- Is a shorthand property which sets all of the scroll-margin longhands,

ℹ️ The value specified for scroll-margin determines how much of the page that's primarily outside the snapport should remain visible.

https://t.co/ZBB8PmFnCD

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 13, 2020

Day 40: resize

- Sets whether an element is resizable, and if so, in which directions.

ℹ️ You shouldn't use resize: none; for textarea

https://t.co/wiLKtbIunh

https://t.co/USYjrWZItZ

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 14, 2020

Day 41: background-blend-mode

- Sets how an element's background images should blend with each other and with the element's background color.

https://t.co/QBVLLmS2S1

#CSSPropertyInTweet

pic.twitter.com/aqV3isCvCY
— Michael Scharnagl (@justmarkup)

February 15, 2020

Day 42: isloation

-Determines whether an element must create a new stacking context.

ℹ️ This property is especially helpful when used in conjunction with mix-blend-mode.

https://t.co/yvW3kujQ44

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 16, 2020

Day 43: text-decoration-thickness

- Sets the thickness, or width, of the decoration line that is used on text in an element, such as a line-through, underline, or overline.

https://t.co/JkWuUFXCRU

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 17, 2020

Day 44: direction

- Sets the direction of text, table columns, and horizontal overflow.

ℹ️ Note that text direction is usually defined within a document (e.g. dir attribute) rather than through direct use of the direction property.

https://t.co/CCMA49D01C

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 18, 2020

Day 45: translate

- Allows you to specify translation transforms individually and independently of the transform property.

ℹ️ Currently only supported in Firefox, but others will follow soon hopefully.

https://t.co/sxpsbri2jp

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 19, 2020

Day 46: background-position

- Sets the initial position for each background image.
- It is relative to the position layer set by background-origin.

Note: You can't position background-color.

https://t.co/zYhVYjn1Q7

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 20, 2020

Day 47: text-justify

- Sets what type of justification should be applied to text when text-align: justify; is set on an element.

ℹ️ Be careful as the uneven spaces created by justify can harm readability and be very distracting.

https://t.co/Eg1Qd3KAZi

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 21, 2020

Day 48: flex

- Sets how a flex item will grow or shrink to fit the space available in its flex container.
- It is a shorthand for flex-grow, flex-shrink, and flex-basis.

ℹ️ CSS Flexbox is awesome in case you didn't know :-)

https://t.co/JV9zVKTld3

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 22, 2020

Day 49: z-index

- Sets the z-order of a positioned element and its descendants or flex items.

ℹ️ The maximum value is infinite, bounded only by a browser's variable size. For most browsers this days the highest is 2147483647 though.

https://t.co/PleBHuDPF6

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 23, 2020

Day 50: cursor

- Sets the type of cursor, if any, to show when the mouse pointer is over an element.

ℹ️ cursor: none; is for mouse users as outline: none; is for keyboard users - don't do either!

https://t.co/CgFcXsxLwt

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 24, 2020

Day 51: will-change

- Hints to browsers how an element is expected to change.

ℹ️ In some situations it imay have negative performance impact. So, always test carefully and use as a last resort.

https://t.co/yvI73qtT0e

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 25, 2020

Day 52: tab-size

- Is used to customize the width of tab characters (U+0009).
- The default value for the tab-size property is 8 space characters

https://t.co/P7PhDnECvp

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 26, 2020

Day 53: margin-block

- Defines the logical block start and end margins of an element

ℹ️ More about logical properties and values:

https://t.co/AdGKPGFkVP

https://t.co/atyk48pdfZ

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 27, 2020

Day 54: font-feature-settings

- Controls advanced typographic features in OpenType fonts.

ℹ️ Lots of examples:

https://t.co/6yHo5tbHvk

https://t.co/5aPWsdJPHg

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 28, 2020

Day 55: image-orientation

- Specifies a layout-independent correction to the orientation of an image

ℹ️ Will be probably deprecated in the future. The good news is that browsers will honor EXIF info (Safari and Chrome already does)

https://t.co/8jPaLmQWGT

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

February 29, 2020

Day 56: line-break

- Sets how to break lines of Chinese, Japanese, or Korean (CJK) text when working with punctuation and symbols.

https://t.co/fUlpqxPRsn

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 1, 2020

Day 57: box-shadow

- Adds shadow effects around an element's frame.

ℹ️ Generator:

https://t.co/jRiFIKPL1N

https://t.co/JJPeiRy5tq

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 2, 2020

Day 58: writing-mode

- Sets whether lines of text are laid out horizontally or vertically, as well as the direction in which blocks progress.

https://t.co/7zwoyWb55Z

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 3, 2020

Day 59: counter-increment

- Increases or decreases the value of a CSS counter by a given value.

ℹ️ You can change multiple counter at once, eg. counter-increment: cter1 cter2 -4; will increment cter1 by 1 and decrement cter2 by 4

https://t.co/pO99ufKqtg

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 4, 2020

Day 60: quotes

- Sets how quotation marks appear.

/* Set open-quote and close-quote to the French quotation marks */

quotes: "«" "»" "‹" "›";

https://t.co/ipLqlHQ9go

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 5, 2020

Day 61: image-rendering

- Sets an image scaling algorithm.
- Values are auto, smooth, high-quality, crisp-edges and pixelated

https://t.co/OkZtGa3S1o

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 6, 2020

Day 62: justify-self

- Sets the way a box is justified inside its alignment container along the appropriate axis.

https://t.co/frjanwHj3D

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 7, 2020

Day 63: place-content

- Is a shorthand for align-content and justify-content.

ℹ️ If the second value is not present, the first value is used for both, provided it is a valid value for both.

https://t.co/gLGy8W36vR

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 8, 2020

Day 64: row-gap (grid-row-gap)

- Sets the size of the gap (gutter) between an element's grid rows.

ℹ️ CSS Grid Layout initially defined the grid-row-gap property. This prefixed property is being replaced by row-gap.

https://t.co/rVCfOvFrA2

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 9, 2020

Day 65: backface-visibility

- Sets whether the back face of an element is visible when turned towards the user.

ℹ️ Though invisible in 2D, it can become visible when a transformation causes the element to be rotated in 3D space.

https://t.co/gUyvfEqUNG

#CSSPropertyInTweet

pic.twitter.com/BoOXYJW84h
— Michael Scharnagl (@justmarkup)

March 10, 2020

Day 66: opacity

- Sets the opacity of an element.

ℹ️ Browsers can animate opacity cheaply

https://t.co/McNwz7DY2z

https://t.co/sjhEbofYeA

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 11, 2020

Day 67: border-block-end

- Is a shorthand property for setting the individual logical block-end border property value

https://t.co/1qzRHeOQym

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 12, 2020

Day 68: box-decoration-break

- Specifies how an element's fragments should be rendered when broken across multiple lines, columns, or pages.

https://t.co/ToTEQkl6el

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 13, 2020

Day 69: padding

- Sets the padding area on all four sides of an element.

ℹ️ If you use box-sizing: border-box; the padding the width/height will include the padding value.

https://t.co/8NHhePLv0O

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 14, 2020

Day 70: gap (grid-gap)

- Sets the gaps (gutters) between rows and columns.

ℹ️ Can be used with Flexbox (Supported only in Firefox for now) and with Grid.

https://t.co/IeQ4v0TKi5

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 15, 2020

Day 71: filter

- Applies graphical effects like blur or color shift to an element.

ℹ️ filter: invert(80%); works great to adjust e.g. SVG for dark/light mode

https://t.co/MoSs7oVC2D

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 16, 2020

Day 72: grid

- Is a shorthand property that sets all of the explicit grid properties, and all the implicit grid properties, in a single declaration.

ℹ️ It rocks!

https://t.co/IEzRQo4wJj

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 17, 2020

Day 73: mask-image

- Sets the image that is used as mask layer for an element.

Example:

https://t.co/BOw1LpSkvy

https://t.co/bwYMae31yf

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 18, 2020

Day 74: object-position

- Specifies the alignment of the selected replaced element's contents within the element's box.

ℹ️ Like background-position, but for <img>, <video>

https://t.co/KxxZXzhYGt

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 19, 2020

Day 75: order

- Sets the order to lay out an item in a flex or grid container.

ℹ️ Only effects visual order and not logical or tab order, so be aware of accessibility issues.

https://t.co/i84A4VIc01

https://t.co/kUH5T8HQv8

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 20, 2020

Day 76: margin

- Sets the margin area on all four sides of an element.

ℹ️ Learn about mastering margin collapsing

https://t.co/uNfSQtiv0G

https://t.co/cpX5S4ZGFi

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 21, 2020

Day 77: orphans

- Sets the minimum number of lines in a block container that must be shown at the bottom of a page, region, or column.

https://t.co/PvZUesvDvb

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 22, 2020

Day 78: place-self

- Is a shorthand property sets both the align-self and justify-self properties.

ℹ️ The first value is the align-self property value, the second the justify-self one.

https://t.co/7dRDJF7QrF

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 23, 2020

Day 79: table-layout

- Sets the algorithm used to lay out <table> cells, rows, and columns.

https://t.co/pR4ilvN9Pq

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 24, 2020

Day 80: scrollbar-color

- Sets the color of the scrollbar track and thumb.

ℹ️ As with every color you set, make sure the color contrast is sufficient.

https://t.co/lOkTcCSLTu

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 25, 2020

Day 81: overflow

- Sets what to do when an element's content is too big to fit in its block formatting context.

ℹ️ Setting one axis to visible while setting the other to a different value results in visible behaving as auto.

https://t.co/c3DLcTHYMs

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 26, 2020

Day 82: word-spacing

- Sets the length of space between words and between tags.

ℹ️ A large positive or negative word-spacing value will make the sentences the styling is applied to unreadable and therefore inaccessible.

https://t.co/p2Kj4cxTqA

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 27, 2020

Day 83: padding-inline-start

- Defines the logical inline start padding of an element, which maps to a physical padding depending on the element's writing mode, directionality, and text orientation.

https://t.co/H2SPAqIv06

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 28, 2020

Day 84: color

- Sets the foreground color value of an element's text and text decorations, and sets the currentcolor value.

ℹ️ The value must be a uniform color. It can't be a <gradient>, which is actually a type of <image>

https://t.co/Jr6UW0Wd7I

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 29, 2020

Day 85: widows

- Sets the minimum number of lines in a block container that must be shown at the top of a page, region, or column.

https://t.co/6oTxmYx2cy

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 30, 2020

Day 86: scroll-snap-stop

- Defines whether the scroll container is allowed to "pass over" possible snap positions.

https://t.co/BvCy8UGauR

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

March 31, 2020

Day 87: text-emphasis-style

- Sets the appearance of emphasis marks.

https://t.co/A2iwHN8C2n

#CSSPropertyInTweet

pic.twitter.com/JfILoQrMBz
— Michael Scharnagl (@justmarkup)

April 1, 2020

Day 88: visibility

- Shows or hides an element without changing the layout of a document.

ℹ️ visibility: hidden removes the element from the accessibility tree

https://t.co/L0VBlgNE1i

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 2, 2020

Day 89: place-items

- Sets the align-items and justify-items properties, respectively.

ℹ️ If the second value is not set, the first value is also used for it.

https://t.co/XLtwvan7NW

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 3, 2020

Day 90: inline-size

- Defines the horizontal or vertical size of an element's block, depending on its writing mode.

https://t.co/5vB4X5klwU

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 4, 2020

Day 91: text-transform

- Specifies how to capitalize an element's text.

ℹ️ Support for language-specific cases varies between browsers

https://t.co/YSDkZVnfz3

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 5, 2020

Day 92: perspective

- Determines the distance between the z=0 plane and the user in order to give a 3D-positioned element some perspective.

https://t.co/wENb9rGFJj

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 6, 2020

Day 93: shape-outside

- Defines a shape—which may be non-rectangular—around which adjacent inline content should wrap.

ℹ️ The shape editor in Firefox Devtools is really cool

https://t.co/dD9FCVsy9f

https://t.co/lL9UFpRl11

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 7, 2020

Day 94: pointer-events

- Sets under what circumstances (if any) a particular graphic element can become the target of pointer events.

https://t.co/bh6e8MXnGr

input[disabled],
button[disabled] {
pointer-events: none;
}

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 8, 2020

Day 95: rotate

- Allows you to specify rotation transforms individually and independently of the transform property.

ℹ️ You can also set the name of the axis you want to rotate the affected element around, e.g. rotate: x 90deg;

https://t.co/HlgcPw6CD0

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 9, 2020

Day 96: shape-image-threshold

- Sets the alpha channel threshold used to extract the shape using an image as the value for shape-outside.

https://t.co/9L3vwVeWSG

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 10, 2020

Day 97: touch-action

- Sets how an element's region can be manipulated by a touchscreen user

ℹ️ After a gesture starts, changes to touch-action will not have any impact on the behavior of the current gesture.

https://t.co/sgDTQSYCMQ

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 11, 2020

Day 98: perspective-origin

- Determines the position at which the viewer is looking.
- It is used as the vanishing point by the perspective property.

https://t.co/lM8w1wHeId

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 12, 2020

Day 99: font-optical-sizing

- Sets whether text rendering is optimized for viewing at different sizes.

ℹ️ The optical size variation axis is represented by opsz in font-variation-settings.

https://t.co/COuqQob1iV

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 13, 2020

Day 100: color-adjust

- Sets what, if anything, the user agent may do to optimize the appearance of the element on the output device.

ℹ️ With that the series is done.

https://t.co/A4p89bomZG

#CSSPropertyInTweet
— Michael Scharnagl (@justmarkup)

April 14, 2020

Here is the full list on twitter

If you looked closely you saw that I somehow missed Day 12 to tweet - I realized this just now when writing this article, even though I was 100% sure before I didn't miss a day. So, there are only 99 properties after all I tweeted.

Oh, here is what would have been Day 12:

Day 12: inset

Defines physical offsets, regardless of the element's writing mode, directionality, and text orientation

ℹ️ Is still an Editor’s Draft and currently only supported in Firefox

https://developer.mozilla.org/en-US/docs/Web/CSS/inset

#CSSPropertyInTweet

I might repeat this some day, maybe 50 JavaScript keywords or something.

<information>
This article was written with Writerie - The Writer for Internet People.
</information>

A poll, third-party, assumptions, and some tips

2020-04-10T09:54:10+02:00

Last week I started a poll on twitter to find out how much we rely on third-party code in front end. I asked the people how much of their JavaScript and CSS code is third-party.

On average, how much of all the KB of JavaScript you ship, are written by yourself versus third-party code?
— Michael Scharnagl (@justmarkup) April 1, 2020

Next round: CSS

On average, how much of all the KB of CSS you ship, are written by yourself versus third-party code?
— Michael Scharnagl (@justmarkup) April 5, 2020

As is the tradition with every poll you post, you make assumptions, so here we go.

More third-party JavaScript than third-party CSS #

More than 50% said that their JavaScript is mostly third-party code, while only 3% said the same for CSS. This isn't very surprising though, while there are various CSS frameworks like Foundation or Bootstrap, you still have to adjust and write your own CSS on top of it. This may be also the issue many have with CSS, you have to master it alone.

For JavaScript it is quite different, first there are a lot of JavaScript frameworks and libraries which already comes with a lot of components and other stuff to build your UI. On top of that there is often a solution for a problem just one npm install away. Need to sort some data, search for 'sort' in the npm registry and you most certainly will find a solution and a documentation along with it - Boom, another third-party script added.

Talking about npm, let's move on.

What does fast mean? #

On the server it doesn't really matter how big a package is. Even the cheapest hosting packages offer some GB of space. What matters is execution time. If there are two packages offering the same functionality, say a function to sort numbers. If one package is 1 MB and another one is only 10 kB, but the one with 100 MB is twice as fast (say 10ms instead of 20ms) you would choose the 1 MB package, even though it requires 100x the space of the 10 kB package. If 1.000.000 people request your site and every time the sort function is executed, you only need the space once, but can deliver the result 1.000.000x twice as fast, or instead of in 20.000.000ms in 10.000.000ms.

On the client it is a different story. While execution time is also important, it is also really important how many kB the user has to download before they can even make use of it. If we would have to decide if we would use the 1 MB package or the 10 kB package you should go with the 10 kB package, even if it takes twice as long. If 1.000.000 users need to download the file with the sort function, they would have to download 1.000.000 MB, but only 10.000 MB if we have chosen to ship the 10 kB package.

npm was originally a package manager for Node.js (JavaScript running on the server), but lately it is also used a lot for JavaScript running on the client. The issue is that they are quite different as outlined above and while some package may be the best solution on the server, the same package may be the worst solution on the client.

One example often cited is moment - "A lightweight JavaScript date library for parsing, validating, manipulating, and formatting dates." as they market it. Lightweight means in this case about 232 kB of JavaScript. On the server this is no problem at all, but on the client this is way too much.

What makes a good third-party package? #

To finish this with something useful, here are some things you should consider before using a third-party script.

1. Well maintained #

Before using a package you should check on npm/Github/Gitlab... if the package is still actively maintained. When was the last release? How many people work on this project? Are the open issues monitored, or was there no response for a longer time?

All this questions give you a first good overview how well a package is maintained.

2. Is it accessible #

If the problem you try to solve involves any form of user interaction the JavaScript and CSS you need for it needs to be accessible. First, you may try adding the keywords "Accessibility" or "A11y" to your search. If a package is using these keywords it is a good first sign, but you should still not take this for granted. As a next step I usually open the code repository and search for "keyboard" - if there is a documentation/wiki explaining how well it works with keyboard-only it is fantastic, if there is only one issue found in the search complaining about keyboard issues, it is a bad sign. After "keyboard" I usually do the same search again with "screen reader" looking for the same patterns.

This a good first steps to see if a package might be accessible. As a next step you should test a demo version of if, running some accessibility linters and do your own tests how well it works for keyboard users and users using a screen reader.

3. Is it lightweight #

Sadly, most packages don't market their lightweight size anymore (maybe because they got heavier and heavier after the years) like years ago when every jQuery plugin wrote at the top of their description - Only 1.6 kB or something.

Even if there are sizes mentioned, it is often unclear what they mean. Is this before/after minification, before/after gzip.

So, do find out how lightweight or heavy a package is you mostly have to install it locally and see for yourself.

4. Do I really need that #

Coming back to the moment.js example - if you find that a package is probably not as lightweight as you want, there is often an alternative package or sometimes browser support got so got that you can use native solutions and no third-party at all.

Conclusion #

Almost all websites ship with some third-party code. Yes, for mostly static sites you probably don't need any third-party code. But, the more complex the site is and the more features you have, you will probably use third-party code at some point. Often there are great solutions available for the problems you want to solve, but you should always question the solution. Is there a better one, a more accessible one, a more lightweight one and do I really need that third-party package or can I build it on my own now as browser support involved.

<information>
This article was written with Writerie - The Writer for Internet People.
</information>

Basic tests for a frontend feature

2020-03-10T19:24:10+01:00

If you ever worked in an agile team and used SCRUM you probably heard of Definition of Done. While I am still skeptical that SCRUM is the best way to build a product, I find having a Definition of Done to be really helpful.

Here are some things I find to be valuable to have in there when it comes to testing.

1) Tests on devices/browsers listed in the project assumptions passed #

What devices and browsers you should test depends on your product, your market and many other factors. You should, however, have a least one low-end Android device in there, like the Moto G4 or the Alacatel 1X. Testing there gives you a good idea how efficient a feature really is.

2) Can be used with keyboard only #

That's self-explanatory – all actions of the feature can be done by using only your keyboard.

3) Automated accessibility tests passed #

While you can't automatically test any accessibility issue, it is a good start. There are various tools available, like WAVE, axe, Pa11y and many others. Most tools show you contrast failures, missing alt attributes, missing labels and much more.

You should at least test with one screen reader. You can use a free screen reader like VoiceOver (macOS, iOS), TalkBAck (Android), NVDA (Windows) to test. Note, there are differences between screen reader, how they support web features.

5) Core actions are usable without JavaScript #

No matter what happens, one thing will always be true - JavaScript can and will fail at some point. Therefore, make sure all the core features are usable without JavaScript, and more importantly, when JavaScript is available, but fails for whatever reason.

Conclusion #

This list is by no means complete. Nothing will ever be perfect, but if all these tests pass you are most probably ready to ship.

The beauty of the Unknown

2020-02-28T12:42:10+01:00

Building for the frontend on the web comes with the challenge of many unknowns. Many seem to dislike this and want to build only for one environment. I really like the challenge and you should too if you are a Front-end developer.

All the browser and devices #

At the moment there are about 63.000 browser-platform-device combinations. That's a lot. And there will be even more in the future.

It is impossible to test your site in all these combinations, so you have to find a way to make sure that your site works there without testing it everywhere. The way to do this is to learn to build for the unknown. To learn that every code may fail and be prepared.

I want only one browser #

I regularly hear from developers that they wish that there would only be one browser(engine). At the moment (beginning of 2020) we are in a situation where only three big browser/engines are active (Firefox, WebKit, Chromium). I really hope we don't end up with a monopoly. While it would be different from the »Internet Explorer monopoly« we had in the past, it would clearly not help the web.

Even if there would be only one browser engine left, there would still be fragmentation. Different devices, different screen sizes, different CPU power, different input devices, different output devices, different operation systems – so many differences.

So the bad news for everybody wishing that at some point they can build only for the known. It will never happen on the Front-end. If you dislike the challenge of the unknown that much, you may better work on the Back-end.

Progressive enhancement #

In the end, it is all about Progressive Enhancement. There is a lot about wrong assumptions about Progressive Enhancement as it seems. Some think it means to not use JavaScript at all, some think it is useless because they can't imagine that their CSS/JavaScript can fail in some scenarios and some think it means that you can't use new web technologies.

That's not really how I think about Progressive Enhancement. For me, Progressive Enhancement means »Preparing for the Worst and building for the Best«. It also means that I feel much more confident using new and even experimental web technologies, because I use them as an enhancement and I am still sure the basic stuff is there and works.

You should learn to like the idea of Progressive Enhancement, whatever you call it.

Teaser with multiple links

2020-02-21T06:56:12+01:00

Cards, teaser, preview blocks – there are many different ways to name them – one thing they all have in common is that they usually consist of a headline, an image, some text and a read more link. The other similarity is that all these elements should link to the same goal. In theory, writing the HTML for this pattern seems pretty straightforward, but there are some accessibility concerns which may not be obvious at a first glance.

In this article we will have a look at the possible options to make all the elements link-able and their advantages and disadvantages.

Extra link for each element #

One option to make all the elements (image, headline, ...) link-able, would be to define an extra link for each element.

<article>
  <h2>
    <a href="/bestarticle">Headline</a>
  </h2>
  <a href="/bestarticle">
    <img src="bestimage.jpg" alt="Best image">
  </a>
  <p>Some text</p>
  <a href="/bestarticle">Read more <span class="visually-hidden">about Headline</span></a>
</article>

If you happen to use a mouse or touch device this sounds like a good way to define the HTML. If you use a screen reader or are a keyboard user this isn't. The problem with this approach is the redundancy – as a keyboard user you have to tab three times to get to the next teaser, as a screen reader user you will get announced the same link three times as well.

Advantages #

You can define extra :hover/:focus states for each element
Every text is selectable
The context menu works as expected (e.g. option to open link in a new tab)

Disadvantages #

A lot of redundancy for many users, which makes it inaccessible

You may wonder now, we have three advantages and only on disadvantage – what's the problem? The problem is that this approach is not fully accessible and we never want to ship inaccessible code.

Let's see what other options we have.

One block link #

Since HTML5 you can create so-called Block Level Links. This means, instead of a link for each element, we can use one link around all our elements.

<article>
  <a href="/bestarticle">
    <h2>
      Headline
    </h2>
    <img src="bestimage.jpg" alt="Best image">
    <p>Some text</p>
    <p>Read more <span class="visually-hidden">about Headline</span></p>
  </a>
</article>

Advantages #

The context menu works as expected (e.g. option to open link in a new tab)
No link redundancy

Disadvantages #

You can't define extra :hover/:focus states for each element
Selecting individual text parts is pretty hard
Screen readers may announce all the text, which can be annoying

From an accessible point of view this is better than having the redundancy problem, but it comes with other disadvantages, so let's see at yet another approach.

An absolute positioned link #

Our next approach is to use an absolute positioned link. The idea is to have only one inline link in the HTML, and use ::before to stretch that link around the whole teaser.

<article>
  <h2>Headline</h2>
  <img src="bestimage.jpg" alt="Best image">
  <p>Some text</p>
  <a class="readmore" href="/bestarticle">Read more <span class="visually-hidden">about Headline</span></a>
</article>

With this HTML alone only the Read More Link would be clickable, so let's add some CSS to expand the click area to the whole teaser.

article {
  position: relative;
}

.readmore::before {
  content: "";
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
}

Now with the CSS added you can click everywhere on the teaser.

Advantages #

The context menu works as expected (e.g. option to open link in a new tab)
No link redundancy

Disadvantages #

You can't define extra :hover/:focus states for each element
Selecting individual text parts is pretty hard

JavaScript all the things #

How could I forget about JavaScript? JavaScript is the best, it makes everything better. So let's see how to handle this with good old JavaScript.

<article>
  <h2>Headline</h2>
  <img src="bestimage.jpg" alt="Best image">
  <p>Some text</p>
  <a class="readmore" href="/bestarticle">Read more <span class="visually-hidden">about Headline</span></a>
</article>

We start with the same HTML as in the previous example, but instead of using CSS we will now "enhance" it with JavaScript.

const article = document.querySelector('article');
article.addEventListener('click', function () {
  const link = this.querySelector('a');
  link.click();
})

So, every time the user clicks on any part of our teaser we trigger a click on the Read More link. To avoid that a click is triggered when a user wants to select some text, we can use this method described by Heydon Pickering to only trigger the click after a 200 millisecond threshold.

Advantages #

Selecting text is possible with some extra effort
No link redundancy

Disadvantages #

The context menu doesn't work anymore (e.g. option to open link in a new tab)

All in all, this approach seems pretty good, but the non-working context menu is a big no-go for me and JavaScript is just too fragile to make this a great solution.

Conclusion #

As you can see, there is no real winner here. All the approaches have their disadvantages. Personally, I prefer to use the absolute positioned link approach, as I often don't need individual :hover/:focus styles and I am okay with the disadvantage of not being able to select text there, as on the full article the text will be select-able. And it offers the best experience for keyboard and screen reader users.

If you came as far, go and read more about building cards elements on Inclusive Components.

Share images to your website using the Web Share Target API

2020-02-11T10:46:43+01:00

Last year my daughter was born, and of course we wanted to be able to share pictures of her with family and friends. I could have used any of the available services to share photos/galleries with them, but I don't feel comfortable at all that pictures of here are saved somewhere I don't really have access to. So, I made a simple web app, where my partner and me can upload the images to my server and family and friends can see them if they have the credentials.

To make it more convenient for us, I added the possibility to share photos directly from the phone gallery to the website. In this article, you will learn how to use the Web Share API to share images to your website and handle the data.

Manifest #

To be able to use the Web Share Target API we first need to add a share_target entry to our Web App Manifest (manifest.webmanifest).

"share_target": {
    "action": "./upload",
    "method": "POST",
    "enctype": "multipart/form-data",
    "params": {
        "files": [{
            "name": "file",
            "accept": ["image/*"]
        }]
    }
}

The params keys will be used as query parameters when the target is launched, so you can access them from /upload just like an HTML form submission has happened.

So, the same data will be send to /upload as if we used this form:

<form class="form" action="./upload" enctype="multipart/form-data" method="POST">
    <label for="file">Select images: </label>
    <input type="file" id="file" name="file" multiple>
    <input type="submit" value="Upload your images">
</form>

With this in place, now let's see how to handle the data once a user shares them with our site.

Handling the data #

We can handle the data like any other POST request to our server. In Node.js this would look like this:

const multer = require('multer');

const upload = multer({
  limits: {
    fileSize: 4 * 1024 * 1024,
  }
});

app.post('/upload', upload.single('file'), function(req, res) {
  const file = req.file;
  // now you can do whatever you want with the file 
});

The other option is to handle the request via an Service Worker. Here, we listen on the fetch event, check if the request method is POST and the URL is the one defined as action in our share_target in the Manifest file.

If this is the case, we redirect the user to our defined page and send the file data via postMessage.

addEventListener('fetch', event => {
    // ignore all requests with are not of method POST and which are not the URL we defined in in share_target as action
    if (event.request.method !== 'POST' || event.request.url.startsWith('https://justmarkup.com/demos/web-share-target-image-to-grayscale/upload') === false) {
        return;
    }

    // Code mostly from https://paul.kinlan.me/file-web-share-target/
    event.respondWith(Response.redirect('https://justmarkup.com/demos/web-share-target-image-to-grayscale/output.html'));
    event.waitUntil(async function() {
        const data = await event.request.formData();
        const client = await self.clients.get(event.resultingClientId || event.clientId);

        const file = data.get('file');
        // send the image data to the client
        client.postMessage({ file, action: 'load-image' });
    }());
});

Now, on the client (output.html) we can listen to onmessage event and do some stuff with the image data we received.

navigator.serviceWorker.onmessage = function(event) {
    const imageBlob = event.data.file;
    // we now have the file data and can for example use it as a source for an img with the id image on our page
    const image = document.getElementById('image');
    image.src = URL.createObjectURL(imageBlob);
};

After all the code and explanation, let's look at a demo.

Demo #

Ever wanted to easily convert an image to an grayscale image on your phone? I do sometimes, and that's why I build a demo using the Web Share Target API to achieve exactly that.

For this I used the Service Worker way to handle the data. Once the data is received on the client, I use drawImage from canvas to draw the image in canvas, use the grayscale filter to convert it to a grayscale image and output the final image.

navigator.serviceWorker.onmessage = function(event) {
    const imageBlob = event.data.file;
    const image = document.getElementById('image');
    image.src = URL.createObjectURL(imageBlob);

    const canvas = document.getElementById("canvas");
    const img = document.createElement('img');
    const ctx = canvas.getContext('2d');

    img.src = URL.createObjectURL(imageBlob);
    img.crossOrigin = "anonymous";

    img.onload = function() {
        canvas.width = img.width;
        canvas.height = img.height;
        ctx.filter = "grayscale(100%)";
        ctx.drawImage(img, 0, 0, canvas.width, canvas.height);

        const data = canvas.toDataURL("image/jpeg");
        image.src = data;
    }
};

Here is the final demo and you can find the code on Github.

Support #

Currently the Web Share Target API is only supported in Chrome and also only on Android. Nevertheless, this is a good progressive enhancement. If the browser supports if you can enhance the upload experience and let users directly share images from their phone without opening the site first.

Eight years

2020-01-31T10:13:20+01:00

It's been eight years since I launched this site with my first article.

Since then I published 130 more articles and notes and one even explains why this site is named justmarkup.

Last year I wrote that I plan to switch from WordPress to a Static Site generator. This is done now, and this site is now using 11ty and I am more than happy with it. If you are curious, the code behind this very site can be found on Github.

I haven't written a lot last year for various reasons, but now I really enjoy it again and plan to write more frequently this year. There will be more tutorials again how to build accessible, progressive-enhanced stuff as well as my thoughts about web stuff and in general which you can all see in my Notes section.

Oh, and early this year I added an info box underneath each article, about ways to support me. Thanks to everybody reading, sharing and discussing my articles. Thank you.

On to the next eight years!

Boring by default

2020-01-14T19:42:10+01:00

When starting a new web project one often reaches for new cutting-edge technologies to be up-to-date. However, why not start with the basics first and add stuff on top if you really need it. Boring by default.

I really like new and cutting-edge technology, but lately, I feel more and more that we're just over-engineering everything... 😢

I spent the last hour solving problems that I wouldn't have had with a "traditional stack", static HTML and some hand-written JavaScript.

— Stefan Judis (@stefanjudis) January 5, 2020

As Stefan and many others, I also often see and experience over-engineered sites regularly. Let's see why starting with a traditional, or boring stack may not be the worst idea.

Start with the basics #

When starting a new website all you need to build it is a computer, an editor and a browser to view it. Yes, that's all – no need for a build script or task runners or for installing something via npm. Yet, nowadays we tend to over-complicate all of this. The arguments for this are that it makes it so much easier to build a site using all this tools, another is that you will clearly need all of this once several people work on the project and/or the project is getting large.

These are all valid points, but to you really need this all from the beginning? What if you abandon the project (like the millions of half-finished side-projects out there), or find that a static HTML page is all you need.

Maintenance #

Ever needed to change "just a small thing" on an old page you build years ago? I recently had the pleasure and the simple task of changing some colors in CSS lead to a whole day of me wrangling with old deprecated Grunt tasks and trying to get the build task running.

The same will happen to you as well some day, everybody used Grunt back then and almost nobody does today, the same will probably also happen to Babel or other tools – at least you would have to get an old version running which isn't supported anymore at the time you want to change some CSS in 2025.

That's why starting with HTML, CSS and JavaScript without the need to ever compile anything on your local machine is a good idea. Changing some colors on such a page would indeed only take minutes and not a whole day.

It depends #

That said, if your whole team is really into React or Vue or AnotherFrameworkDevelopedRightNow and you know for sure that using these tools is the perfect choice for you. Use that. But, don't tell others they also have to and that this is the only way to build things – it all depends.

Your job as an developer is to decide, to decide what tools to use, to decide what frameworks to use, to decide what to prioritize, to decide what is the best way to maintain a project – a lot of questions only your team is able to answer.

Again, it all depends.

Conclusion #

Never feel ashamed to start with a traditional (boring) stack – you may be the one launching a great project, while others still set up there build scripts.

Be boring by default and enhance on the way.

Do's and Don'ts of implementing a hamburger menu

2019-12-04T08:20:43+01:00

The infamous hamburger menu is one of the examples where I see bad practice very often. Surf the web one day using a screen reader or using only your keyboard and you will most likely experience some of the problems as well. Let's have a look at the most common errors and how to avoid them.

Before even thinking about the best way to implement a hamburger menu, one should ask if it is even needed at all. There are various Responsive Navigation Patterns to use instead. Lately, there is also the trend to use a hamburger menu on large screens – while this may look fancy – it means that users have to click two times to go to one of the listed pages. So, if there is space, it is better to directly show all navigation items and only hide them behind the hamburger toggle on small screens.

Okay, so you still think a hamburger menu is the best choice for the site you are building? Let's see what to consider when implementing it.

The icon #

We start with the hamburger icon, also referred to as Navicon. Let's start with some bad examples and see what better alternatives there are available.

Many use the Unicode sign for 'IDENTICAL TO' (U+2261) or the one for 'TRIGRAM FOR HEAVEN' (U+2630) to visually show the three lines. The first problem with this approach of showing the icon is, that not all browsers support these Unicode signs and also not all fonts do, which means these users will see a square □ (also called tofu or replacement Glyph instead of the three lines.

The bigger problem with this approach is that screen readers may announce the U+2630 sign as "the trigram for heaven".

We could use something like:

<button class="nav-toggle" aria-expanded="false" aria-controls="menu">
  <span aria-hidden="true">☰</span> Menu
</button>

to hide the glyph for screen readers, so only the word "Menu" would get announced, but we may still run into browser/font support problems. Another approach many used and sadly still use is using an icon font. Regarding this, I can only say – Seriously, Don’t Use Icon Fonts.

Now that we know, what not to use, see some good examples to achieve this. The first way is to use an <img>, with an empty alt attribute as it is purely decorative.

<button class="nav-toggle" aria-expanded="false" aria-controls="menu">
  <img src="menu.svg" alt="">
  Menu
</button>

We could also rebuild the three lines with CSS using box-shadow, gradient or borders and a pseudo element.

Another approach would be to use an SVG directly in the HTML. In this case, you have to set aria-hidden="true" and focusable="false for the SVG element, as described here by Sara Soueidan.

Really bad: Use Unicode without aria hidden. Use icon font.
Still not good: Use Unicode icon with aria hidden
Good: Use img, CSS or an SVG and not use the icon alone

The toggle button #

Now let's move on to the toggle button. As you hopefully guessed right, it is called button because we should use a real <button>. Still, many people sadly use <span> or <div> or <a> for the toggle button. Many argue that a <button> is hard to style with CSS, but this is not true and you can quite easily reset the styles so it looks like a <span> or <div>.

The same is true if you think using a <a> is the right choice here. It is not, a link is called a link because it is used to link to other pages or other parts of the pages and not to provide functionality.

Great, now that we know we have to use a <button>, you may think that it is the best way to server-side render it because client-side rendering is all bad, right? As much this is true for content, it is not for interactive elements which are pretty much useless without JavaScript.

First let's start with the fallback version which works completely without JavaScript and shows all navigation items directly.

<nav>
    <div hidden data-menu-button>
      Menu
    </div>
    <ul id="menu" data-menu>
        <li><a href="/">Home</a></li>
        <li><a href="/about">About</a></li>
        <li><a href="/shop">Shop</a></li>
        <li><a href="/contact">Contact</a></li>
    </ul>
</nav>

See the div there, didn't I just say that we should never use a div for a button? Yes, this is still right, but this is only a placeholder that we will later replace with a real <button>. We also use the hidden attribute here to hide it, so it won't be visible and also will not be announced by screen readers.

Another alternative is to use a <a> with an anchor link to the navigation in the footer. In both ways the navigation is still accessible if JavaScript fails and no useless buttons are shown.

Now, let's enhance that when JavaScript is available and ready.

(function() {
  const fakeButton = document.querySelector('[data-menu-button]');
  const menu = document.querySelector('[data-menu]');

  const toggleMenuButton = document.createElement('button');
  toggleMenuButton.textContent = fakeButton.textContent;
  toggleMenuButton.setAttribute('aria-expanded', false);
  toggleMenuButton.setAttribute('aria-controls', 'menu');
  toggleMenuButton.classList.add('nav__toggle');

  fakeButton.parentNode.replaceChild(toggleMenuButton, fakeButton);

  toggleMenuButton.addEventListener('click', function() {
    let expanded = this.getAttribute('aria-expanded') === 'true' || false;
    this.setAttribute('aria-expanded', !expanded);
    menu.hidden = !menu.hidden;
  });

  menu.hidden = true;
})()

Here we replace the fake button with a real <button>, add aria-expanded and aria-controls attributes and add an EventListener which toggles the visibility of our menu and also updates the ARIA attributes accordingly. You can find an unstyled example of this on JS Bin.

We now have all the functionality we want and still make the navigation available if JavaScript fails.

Really bad: Use anything else as a real button element
Still not good: Render the button server-side
Good: Use a client-side generated button with appropriate ARIA

The checkbox hack #

At this point you may wonder – Isn't there a CSS-only way to achieve this? You may also remember hearing about a way to toggle content using the so-called Checkbox Hack and may consider using that. Please don't, as it involves some usability and accessibility concerns. So, forget that it even exists.

Really bad: Even thinking about using it.

Styling and user preferences #

Okay, as a last step let's see what can go wrong with styling and why we should respect user preferences.

First, you should, as always, check the contrast ratio, for example using this tool. You should also check the navigation in high-contrast mode.
Also, make sure that the click target of the links is big enough.

Be also sure to test it with small screens. I have quite often seen navigation with lots of links, but only the half of it where reachable to the user, so make sure to use overflow: auto if your navigation is fixed to make the list scrollable.

Also, if you are applying animations and or transitions for the show/hide effect, make use of the reduced motion media query to minimize/avoid these effects for everyone who prefers reduced motion.

Really bad: Low contrast, too small click areas
Good: Tested in high-contrast mode, great contrast, large click area and respecting user preference

Conclusion #

First of all, think twice before hiding content at the first place – avoiding extra clicks for the users is always a good idea. If you need to hide the navigation behind a toggle button, only do it on smaller screens where there is not enough space available and not on large screens where they would perfectly fit.

Use an image, a SVG or a CSS approach to show the hamburger icon, avoid using the Unicode character or an icon font. It is also a good idea to show real text next to the icon, a simple "Menu" will do the trick. While the hamburger icon may be used by a lot of sites and apps, many people still have no idea what it means.

Provide a basic version in case JavaScript fails, so users could at least continue to your other pages.

Use a client-side generated <button> to toggle the menu and always use the appropriate ARIA properties to make it accessible.

Last but not least, be sure to test your implementation with screen readers, only your keyboard and in high-contrast mode – you know, the basic tests you should make for every component and page you are building.

Happy coding!

Resources #

Accessible Icon Buttons by Sara Soueidan
Three Line Menu Navicon by Chris Coyier
Browser Test Page for Unicode Character 'IDENTICAL TO' (U+2261)
Browser Test Page for Unicode Character 'TRIGRAM FOR HEAVEN' (U+2630)
HTMHELL - #11 The trigram for heaven
Seriously, Don’t Use Icon Fonts by Tyler Sticka
Responsive Navigation Patterns by Brad Frost
Accessible Mobile Navigation by Ahmad Shadeed
A Brief Overview On Responsive Navigation Patterns by Chris Poteet
Adventures in Responsive Navigation by Erick Arbé
Introducing the Button element by Andy Bell
The link to button enhancement
Who can use by Corey Ginnivan
Revisiting prefers-reduced-motion, the reduced motion media query by Eric Bailey

image orientation on the web

2019-10-21T08:18:43+02:00

I am currently working on a little side project, where I upload images to my server (using file input and additionally Web Share Target) to make them available to others. While I had a first working version ready pretty quickly there was one problem – when uploading a portrait image from my phone, the image was shown with the wrong orientation.

In this article you will learn about the current status of image orientation on the web, how to correct orientation of images using Node.js, and how browsers will handle this in the future.

Current status #

If you view this image (I it got from the exif orientation examples) it may show correctly in portrait mode or it may incorrectly be shown 90deg rotated to the left.

You are most probably a browser on iOS if you see the word top actually at the top and another browser if you see the word top on the left. The reason for this is that the EXIF data for this image has the info Rotate 90 CW for orientation.

When you embed the image using <img>, or background-image the image will be shown wrong in all browsers, except from browsers on iOS. If you, however, open the image directly it will be shown correctly in Firefox, Chrome and Safari, but will still be shown wrong rotated in Edge and Internet Explorer. What a great consistency!

The image-orientation property #

When looking for possible ways to fix orientation using CSS or JavaScript I found about the image-orientation property.

At the moment this property is only supported in Firefox and you can use it this way so browsers honor the EXIF data and fix the orientation:

img {
    image-orientation: from-image;
}

When looking for more information I also found that this property is already deprecated which was confusing to me at first, because this property would be an easy way for me to fix my issue with image orientation if it would be supported by all browsers.

After reading some more through the Github issue, I learned that the plan is that all browsers will honor the EXIF orientation in the future, and therefore will use image-orientation: from-image by default. Great, that's what I want!

Fixing the orientation with Node.js #

We learned so far that there is quite some disagreement among browsers how to deal with EXIF orientation and no cross-browser way to easily correct it on the front end. In short, it is quite a mess and as we don`t want that some users will see broken images, let's see how we can fix this using Node.js.

First, we need a form to upload our images:

<form class="form" action="./upload" enctype="multipart/form-data" method="POST">
    <label for="file">Select image: </label>
    <input type="file" required name="file" multiple="" accept="image/*">
    <input type="submit" value="Upload your photos">
</form>

Once you select an image and submit the form a POST request will be made to /upload, so let's see the upload route next:

app.post('/upload', upload.array('file'), async(req, res, next) => {
    const images = req.files;

    for (image of images) {
        await correctOrientation(image);
    }

    res.redirect('./show');
});

We are using multer as a middleware here to process the images and for every image we call correctOrientation to correct the orientation.

Before we look into correctOrientation, here is the multer configuration we are using to save images to our /uploads folder.

var storage = multer.diskStorage({
    destination: function(req, file, cb) {
        cb(null, path.join(__dirname, "uploads"));
    },
    filename: function(req, file, cb) {
        cb(null, Date.now() + '__' + file.originalname);
    }
})

const upload = multer({ storage: storage });

So, let's see the interesting part - the correction of the image orientation:

const readFileAsync = async(file) => {
    return await new Promise((resolve, reject) => {
        fs.readFile(file, async(err, data) => {
            err ? reject(err) : resolve(data);
        });
    });
};

const correctOrientation = async(image) => {
    let imageOrientation = false;
    let rotateDeg = 0;

    const buffer = modifyExif(await readFileAsync(path.join(__dirname, "uploads") + '/' + image.filename), data => {
        imageOrientation = data && data["0th"] && data["0th"]["274"] ? data["0th"]["274"] : false;
        if (imageOrientation) {
            if (imageOrientation === 1) {
                imageOrientation = false;
            } else {
                data["0th"]["274"] = 1; // reset EXIF orientation value
            }
        }
    });

    if (imageOrientation) {
        switch (imageOrientation) {
            case 3:
                rotateDeg = 180;
                break;
            case 6:
                rotateDeg = 270;
                break;
            case 8:
                rotateDeg = 90;
                reak;
            default:
                rotateDeg = 0;
                break;
        }
        Jimp.read(buffer, (err, lenna) => {
            if (err) {
                console.log('err', err);
                return;
            }
            lenna
                .rotate(rotateDeg) // correct orientation
                .write(path.join(__dirname, "uploads") + '/' + image.filename); // save
        });
    }
};

First we define readFileAsync which turns the fs.readFile function in to a promise.

Now, let's see what we have in the actual function. First, we are using the modify-exif package to set the EXIF orientation value for every image to the value of 1 (the default one) if it was not already 1.

After we changed the EXIF information, we now use jimp to rotate the image according to EXIF orientation value we got before and re-save the image.

And that's it - all images are now correctly shown in every browser.

You can find the full example on Github.

Conclusion #

As of now, the only browser honoring the EXIF orientation is browsers on iOS, but there is hope that all other browsers will sooner or later also honor it and show the correct orientation. This way this issue would get solved automatically and we developers have one less issue to deal with.

However, for the moment the only way to fix the orientation problem, is by removing the EXIF orientation data and rotating the image accordingly which can either be done manually or using your favorite back end. It would also be possible to correct it on the client-side using JavaScript, but I advise against it as we should outsource as less as possible of the heavy work to the front end and therefore the user.

Happy coding and don`t forget to tell your favorite browser that they should honor EXIF orientation and fix this issue.

Closing feediary

2019-10-05T12:20:10+02:00

When I finally launched feediary last summer I was really excited. It was my first side project which I turned into a business. It was the first time I asked users to pay for my project. It was scary.

From fun to business #

It all started when I was looking for a RSS reader. I wanted to use RSS again and wanted a tool which respects privacy, can be used on the web and is accessible. None of the available options offered all of these, so I started to build my own. Time went by, the project got bigger and bigger, I added more and more features. It was a great time and a lot of fun. I was looking forward to evenings and weekends where I could work on feediary.

At some point I asked myself – This is really useful for me, so why not make it available for everyone. I had three options at this time. The first was to integrate lots of advertisement to be able to pay the recurring costs. The second one was to open-source it so everybody could install it on their server. The third one was to use a subscription model and offer a Free and a PRO plan. As using advertisement (which I already dislike) also means using tracking (which I hate) this was no option at all. So, I thought about open-sourcing it, which would mean that only people who know how to run a server and install everything would be able to use it. So, I decided to try the subscription model.

This sounds easy at first, add a new user role, make some features only available to PRO users, add payment to the registration and done. It took me a lot of time and swearing to get this all running. One of my goals was to use as less third-party as possible and regarding payment this was a bad idea. As I am based in Europe I have to participate in VAT MOSS (collecting VAT based on country of user), which was/is not supported by stripe (the only third-party I decided to use because nobody wants/can directly integrate payment without a third-party), and which lead to a lot of work for me. I had to check which country the user is from, check if the user has a business (by checking their VAT identification number and if it is valid) and then calculate the correct VAT. I really should have used a service which helps with this, but was too narrow-minded to trust any of these third-party tools.

Anyway, after some time I got it all running and feediary was ready for the public. The day of the launch came and it went really well. Within two hours after announcing it I already had my first PRO user – I was really enthusiastic and was looking forward to the fun again after all the hard work.

Money, Money, Money #

Time went by. Every day new users registered for feediary, I now spend a lot of time with support and at the same time fixing bugs and adding new features – still all in my free time after/before work. It was fun and exciting, besides that only very few (about 0.2% of all all users) decided to actually pay for feediary and upgrade to the PRO plan. From my rough estimates I knew that I need at least 3% PRO users to pay for all the recurring costs, so every month the ratio was below that I lost money. I am not counting all the money I invested by my work and time, but this was real money I had to pay so that others could use feediary. And every month it got a little more, because more users means more data, means more database and server cost.

So, I tried to increase the free-to-pro ratio by adding more features for the PRO plan, by telling everyone how awesome it is to be a feediary PRO user. It didn't really help.

It got frustrating to see a growing list of features and bugs I had to work on, and at the same time the certainty that I loose money every day if I can't find enough users to upgrade.

The end #

Fast forward to early summer of 2019 when I first heard about Strong Customer Authentication (SCA) and that I need to completely change my custom payment methods. I had about two months to finish this, as by 14th of September this had to be done.

At the beginning I was confident to finish it, but every week I worked on and couldn't finish I got more and more frustrated. At this point there was no fun left, it was all boring and frustrating work.

I also felt less and less confident that I will reach the needed free-to-pro ratio any time soon. I thought about spending money on advertisement to make feediary more known, but I personally dislike ads, feediary was all against ads and honoured privacy - so investing in ads was a no-go. I thought about going PRO-only. I thought about many ways to make it work. To make it fun again for me.

In the end I decided to let it go, to close feediary, to make it a fun project for me again and do not worry all the time about it.

The future #

All in all it was a fantastic experience, from the beginning to the end. I really learned a ton and it was fun - most of the time. Ready for my next adventure now.

Version Eight

2019-05-06T12:50:10+02:00

I just released a new version of justmarkup.com. 🎉 This is now the 8th version of this site and while it is still far from perfect, I decided it is about time to release it anyway.

In terms of layout there isn't much of a change since the last version, but I tried to make it more readable and also improved the design of the code examples and the embed data. I certainly will tweak the design more in the next weeks and also plan to make extra design for some pages - Whenever I find the time for that.

I also decided to not use web fonts for now - mostly because I couldn't decide which one to use, but I definitely plan to use one for recurring visitors in the future.

The biggest change in this version is that it is no longer using WordPress. Instead I now use Eleventy and I am pretty happy about it so far. As I first step I transformed all my WordPress posts to Markdown using puppeteer, and from there I used the Eleventy Base Blog as a starting point.

The main benefits of the switch are that I now can use Markdown for writing (I already did this in the past, but now I don't need to convert to WordPress Posts anymore), and that the performance improved quite a bit.

Some may miss the possibility to comment on an article. While I won't bring back regular comments I will implement Webmentions soon and will also show all old comments underneath the article.

You can find the code on Github and if you find anything you want me to change, please open an issue there or let me know on Twitter or via Email.

Enjoy!

Adapting to user preferences

2019-02-19T15:48:43+01:00

Over the last years, browsers implemented various features to react to user preferences on the web using CSS, JavaScript or by checking for preferences on the server-side. In this article, I would like to show which user preferences are currently exposed by browsers, the best way to handle them and a look in to the future to see what might be available soon.

Reduced Motion #

Let’s start with the prefers-reduced-motion media query. It was introduced in Safari 10.1 and is currently (February 2019) supported in the latest versions of Safari, iOS Safari, Firefox and Chrome.

The prefers-reduced-motion media feature is used to detect if the user has requested the system minimize the amount of animation or motion it uses. You can either detect it using a CSS media query

@media (prefers-reduced-motion: reduce) {
    /* disable animations/transitions */
}

or you can also use JavaScript to check if the users prefers reduced motion:

var motionQuery = matchMedia('(prefers-reduced-motion)');
function handleReduceMotionChanged() {
    if (motionQuery.matches) {
    /* disabled animations/transitions */
    } else { 
    /* enable animations/transitions */
    }
}
motionQuery.addListener(handleReduceMotionChanged);
handleReduceMotionChanged();

The safest way to disable all CSS animations and transitions is to use:

@media (prefers-reduced-motion: reduce) {
    * {
        transition: none !important;
        animation: none !important;
    }
}

This would however also not trigger animation start/end events or keyframe states, so if your code relies on them you might use:

@media (prefers-reduced-motion: reduce) { 
    * { 
        animation-duration: 0.1s !important; 
        transition-duration: 0.1s !important; 
    } 
}

This is the safest solution, but it might not be the best solution as you may still want to use animations/transitions for some parts even if the user prefers reduced motion. I recommend reading Designing Safer Web Animation For Motion Sensitivity by Val Head to learn more about when it is a good idea to use animations or transitions.

prefers-color-scheme #

The next user preference is the prefers-color-scheme media query which is currently (February 2019) only supported in Safari 12.1. It will however also be supported by Firefox soon and Chrome will also add support in the future.

The prefers-color-scheme media query is probably better known by Dark/Light mode which you can enable on MacOs in preferences.

In CSS you can use the following media query to check if a user prefers dark mode. For light mode the query would be prefers-color-scheme: light.

@media (prefers-color-scheme: dark) {
    /* adust styles for dark mode */
}

As it is a media query you can also use JavaScript to check for it:

var colorSchemeQuery = matchMedia('(prefers-color-scheme: dark)');
function handleColorSchemeChanged() {
    if (colorSchemeQuery.matches) {
    /* dark mode */
    } else { 
    /* light mode */
    }
}
colorSchemeQuery.addListener(handleColorSchemeChanged);
handleColorSchemeChanged();

You can read more about designing for dark mode in this article by Andy Clarke.

Save data #

On to the next one – the SaveData request header. Users can activate the SaveData mode in their browser and we as developers can use that information to deliver a *light* version. This means we could serve system fonts instead of web fonts if save data is enabled or serve low-res images instead of high-res and much more.

We can either detect it via JavaScript using:

if ("connection" in navigator) {
    if (navigator.connection && navigator.connection.saveData === true) {
        // saveData mode is enabled - don't load heavy assets like high-res images or webfonts
    }
}

Or you can also detect it on the server-side, here is an example in PHP:

if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
    // `Save-Data` detected!
    $saveData = true;
}

There is currently no media query for saveData and while we probably never get bandwith media query there is hope that there will be a save data media query in the future.

Fore more infos on delivering fast and light applications with Save-Data I recommend this article:

Do Not Track #

Next is the Do Not Track request header, which I wrote about before as I am all against tracking and had great hopes in this feature. Unfortunately, Safari Technoloy Preview 75 disabled the feature recently, as it was used by some sites for – wait for it – tracking; Oh the irony.

So while I am not sure if other browsers will also disable it, it is still great and gives you extra karma if you honour the Do Not Track setting. It can again be checked via JavaScript:

var doNotTrack = (navigator.doNotTrack === "1" || navigator.doNotTrack === "yes" || navigator.msDoNotTrack === "1" || window.doNotTrack === "1");

if (!doNotTrack) {
    /* load analytics if you really need to */
}

You can also check for Do Not Track on the server-side, again here an example in PHP:

$donottrack= (isset($_SERVER['HTTP_DNT']) && $_SERVER['HTTP_DNT'] == 1); 
if (!$donottrack) {
    echo 'embed analytics script if you really need to'; 
}

Let the user decide #

While it is great if you honour user preferences you should also make sure that users can override it on your site. A user may prefer dark mode in general, but may prefer light mode on your site – so you should have a setting to change the theme and use that to override the general user setting exposed by the browser. And talking about settings – always make sure users can find the setting easily.

What’s next? #

Let’s have a look at the User Preference Media Features to see what we may see next in browsers.

As you can see there are some new media queries defined, like “inverted-colors”, “prefers-reduced-transparency” and “prefers-contrast” which are currently (February 2019) not implemented in any browsers, but probably will be in the future.

Conclusion #

As you can see there are currently various ways to adapt your site to honour user preferences and there will be even more in the future. This features help to improve accessibility, performance and privacy and you can make your users happy when you adapt to them.

Happy coding!

Seven years

2019-01-31T06:13:20+01:00

On the 31th of January 2012 this site was launched with an article me saying Servus (Hello).

Since then I published 120 more articles and notes and one even explains why this site is named justmarkup.

I still enjoy writing articles about my experience and findings and I always have a big smile in my face when I search for a problem and find an old article I wrote with a solution. I also have the same big smile in my face every time someone shares my article or contacts me telling me they found an article interesting and learned something from it – Thank you!

The site is still using WordPress like it did seven years ago, but this will change in the next months as I am currently switching to a Static Site generator. There will also be a new design (the 3th or 4th one I guess), once this is all ready. Stay tuned.

On to the next seven years!

A look at CSS hyphenation in 2019

2019-01-28T09:40:34+01:00

I recently worked on a web site which used big headlines (as in font-size) and also is available in German. This means there are often rather long words and they often don’t fit in the surrounding container. Without doing anything this would »break« the layout as a horizontal scroll bar would appear. So, I reread an article I wrote almost four years ago about Dealing with long words and implemented the final solution.

This seemed to still work great, but there were some issues with this approach. Let’s have a look at the browser support of CSS Hyphenation, how to use it today and which feature I would like to see in browsers.

Browser support #

Support for CSS Hyphenation is pretty good. You should keep in mind that while it works in Chromium-based browsers on Mac & Android platforms it doesn’t work at the moment (January 2019) on Windows and Linux. It also doesn’t work in Opera Mini and some other mobile browsers (Blackberry browser, IE mobile, …), but overall the support is solid.

Update 2021: Hyphenation is now also supported in Chromium on Windows.

Using CSS Hyphenation #

To use hyphens today we still need to add prefixes for IE/Edge/Chromium, so it is best to use the following for every text which should use hyphens:

.hyphenate {
    -webkit-hyphens: auto;
    -ms-hyphens: auto;
    hyphens: auto;
}

As you probably want to break words and not the layout in unsupported browsers I recommend the following. This way all words will be hyphenated in supported browsers and will break into new lines in unsupported browsers.

.hyphenate {
    overflow-wrap: break-word;
    word-wrap: break-word;
    -webkit-hyphens: auto;
    -ms-hyphens: auto;
    hyphens: auto;
}

Now, that we know how to use CSS Hyphenation today, let’s have a look at what’s missing to make it even better.

Too much Hyphenation #

The biggest problem we had with Hyphenation was that it simple hyphenates too often. What this means shows the following example, here it hyphenates the word Josef (Joseph), which doesn’t look great. It also makes the text harder to read and therefore a little bit less accessible.

This is because, unless the UA (user agent) is able to calculate a better value, it is suggested that hyphens: auto means two for before and after, and five for the word total. This means hyphens will be used for every word, which is at least five characters long and it will break after/before a minium of two words.

I am not sure why they came up with this default values, but here we are now having them. There is a solution though already defined in the specification – The hyphenate-limit-chars property.
It specifies the minimum number of characters in a hyphenated word and thus we can use it to override the default value of 5 (word length) 2 (before break) 2 (after break).

So, in theory we could use the following to only use hyphens for words with 10 characters or more and only break before/after after four characters:

hyphenate-limit-chars: 10 4 4;

In reality, this property is still only supported in Internet Explorer 10+ and in Edge with the -ms prefix. It would be really great to get better support for hyphenate-limit-chars – so please let your favorite browser(s) know that you want it – thanks! Here is the issue for Chromium and here for Firefox

Additional note: Webkit-based browsers (Safari) support the -webkit-hyphenate-limit-before, -webkit-hyphenate-limit-after and -webkit-hyphenate-limit-lines properties, which lets you also define the minimum length and the minimum characters before/after a break.

As you can see support for CSS Hyphenation is pretty solid in 2019. The only issue for me is the lack of support for the hyphenate-limit-chars property which will hopefully get better in the future when enough users/developers request it.

Update from 28.01.2018: Added info about similiar properties for webkit-based browser as pointed out by Alexander Rutz and Jiminy Panoz.

The link to button enhancement

2019-01-21T16:21:01+01:00

One of the enhancement patterns I use quite a lot is transforming a link to a button – a link to a new page becomes a button which opens a dialog with the content, an on-page link to the navigation becomes a button to toggle the visibility of the navigation. In this article, I would like to explain why it is often useful to transform a link to a button, how to enhance a login link and why a button not associated with a form is useless without JavaScript.

The button element #

Before we start, some basics about the button element. To quote MDN here:

The HTML <button> element represents a clickable button, which can be used in forms or anywhere in a document that needs simple, standard button functionality.

One thing I have to add here is:

A <button> not associated with a form is useless without JavaScript.

This means you should either create <button> outside forms with JavaScript or use the hidden attribute and remove it with JavaScript afterwards.

And there is more, if you use a <button> in an <form> it will be treated as <button type="submit> – so if you want a button inside a form not to send the form set type=”button” on it.

After refreshing our knowledge about the <button> element, let’s see how we can transform a link to a button.

Transforming a link to a button #

It all starts with a link:

<a href="anotherpage.html">Link to another page</a>

Once this is rendered in the browser, people can use it to navigate to a new page – no matter what input/output device they are using. The can disable CSS, something can break the JavaScript on the page – the link will still work.

Now, let’s enhance the link to a button:

(function() {
    const wannabeButtons = document.querySelectorAll('[data-button]');

    Array.prototype.forEach.call(wannabeButtons, wannabeButton => {

    wannabeButton.outerHTML = `
        <button data-link="${wannabeButton.href}">
        ${wannabeButton.textContent}
        </button>
    `;

    const btn = document.querySelector('[data-link="' + wannabeButton.href + '"]')

    btn.onclick = () => {
        console.log('clicked the button')  
    }

    })
})()

First, we get all links on the page with the data-button (can be anything, but I like to give elements I want to enhance a data atttribute) attribute. We loop over all of them and replace the outerHTML, so the link becomes and actual <button>. Next we save a reference to the new button by using the data-link attribute we set before on it. This way we can now add event listeners on it and so on.

This basic example is useless this way as you may notice, all we did was replacing the link with a button without defining what action should happen after activating the button. So, let’s move on to a real example to show how to enhance a basic link to a page to a button opening an dialog with the main content of the page.

It all starts again with a link to our login page, which is probably defined inside our main navigation on the page:

<a href="login.html" data-open-overlay>Login</a>

Once a user visits the link, they can login to the site – all good. Now enhance this to show an overlay/dialog with the login form. We will use A11y Dialog here to create an accessible dialog window.

First, we include the CSS, JavaScript and HTML for the A11y Dialog on our site. We will also include a JavaScript file called script.js with our custom JavaScript.

<!doctype html>
<html lang="en">

<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Login Link to Login Overlay</title>
    <link rel="stylesheet" href="./style.css" />
</head>

<body>
    <div id="content" class="content">
        <header>
            <nav>
                <ul>
                    <li><a href="./" aria-current="page">Home</a></li>
                    <li><a href="login.html" data-open-overlay>Login</a></li>
                    <li><a href="anotherpage.html">Another page</a></li>
                </ul>
            </nav>
        </header>
        <main>
            <h1>Login Link to Login Overlay example</h1>

            <p>Some Content here</p>
        </main>
        <footer>
            <p>The footer of the page</p>
        </footer>
    </div>

    <div id="dialog" class="dialog" hidden>
        <div role="dialog" class="dialog-content">
            <button type="button" class="dialog-close" data-a11y-dialog-hide aria-label="Close this dialog window">
            &times;
            </button>

            <div data-dialog-content></div>
        </div>
    </div>

    <script type="module" src="a11y-dialog.js"></script>
    <script type="module" src="script.js"></script>
</body>

</html>

You may have noticed that we use type=”module” for the scripts here, this way the JavaScript will be loaded and run as expected in modern browsers and ignored in older browser not supporting it. This also means we can use modern JavaScript features in our script.js.

Now move on to the script.js and the actual enhancement.

(function() {
    var dialogOpeners = document.querySelectorAll('[data-open-overlay]') || false;

    if (dialogOpeners && dialogOpeners.length > 0) {
        Array.prototype.forEach.call(dialogOpeners, dialogOpener => {
            var dialogContent = document.querySelector('[data-dialog-content]');
            window.dialog = false;

            if (!window.dialog) {
                var dialogElement = document.getElementById('dialog');
                var mainEl = document.querySelector('#content');
                window.dialog = new A11yDialog(dialogElement, mainEl);

                dialogElement.removeAttribute('hidden');

                window.dialog.on('hide', function(dialogEl, event) {
                    dialogContent.innerHTML = '';
                });
            }

            dialogOpener.outerHTML = `
                <button data-link="${dialogOpener.href}" >
                    ${dialogOpener.textContent}
                </button>
            `;

            dialogOpener = document.querySelector('[data-link="' + dialogOpener.href + '"]');

            dialogOpener.addEventListener('click', function(ev) {
                var link = this.dataset.link ? this.dataset.link : false;

                if (link) {

                    fetch(link)
                        .then(function(response) {
                            return response.text();
                        })
                        .then(function(html) {
                            var parser = new DOMParser();
                            var doc = parser.parseFromString(html, "text/html");
                            var pageContent = doc.querySelector('#main');
                            dialogContent.innerHTML = '';

                            if (dialogContent && pageContent) {
                                dialogContent.innerHTML = pageContent.innerHTML;
                                window.dialog.show();
                            } else {
                                document.location = link;
                            }

                        })
                        .catch(function(err) {
                            console.log('Failed to fetch page: ', err);
                            document.location = link;
                        });
                    ev.preventDefault();
                }

            });
        });
    }
}());

Let’s go through it. We get all links with the attribute data-open-overlay and loop over them. Next, we reference the element with the attribute data-dialog-content where we will later insert the login form and the dialog itself. After that, we transform the link to a button, as already shown above.

Now the event listener for our button. There we check if the link has the data-link attribute set (we filled this with the href of the original link before). If it does, we use fetch to get the text content of the page. Once we get it, we use DOMParser to get only the HTML inside <main id="main"> of login.html. Now that we have the HTML, we insert it into our dialog content element defined above and show the dialog.

So, now if the user clicks on Login an Overlay with the Login form will open. If the user is using an older browser or if anything goes wrong with the fetch of the login form they will be redirected to login.html and can still login.

If you want to see it in action, here is a demo and you can also view the code on Github.

Happy enhancing!

Using Puppeteer to crawl pages and save them as Markdown files

2019-01-04T07:55:11+01:00

One of my goals for 2019 is to finally launch a redesign of this site and more importantly switch from WordPress to a Static Site. To get this rolling, I first need to have all my posts saved as Markdown. I first looked for some existing WordPress plugins to achieve this, but this wasn’t really working for me. I also could have used the WordPress REST API or even the RSS feed to get the data – again this didn’t feel like the right tools. Then, I read this article by Drew McLellan, where he writes about using Puppeteer to take screenshots of a page and use them for social sharing and I had a plan.

In this article I will describe how to use Puppeteer to find all articles of a page, open them one after another, extract the content, convert it to markdown and save them as separate files.

Get Puppeteer running #

Puppeteer is built on Node.js and provides a clean API to control headless Chrome. This means you can start a Chrome browser from the command line without ever drawing anything to a user interface window. You can open pages, it renders CSS, it runs JavaScript – so you can do everything Chrome on Desktop does, just without an user interface.

Before continuing you should already have Node.js installed.

To install Puppeteer run

npm i puppeteer

in your command line.

This will install the API as well as a Chromium version (~200MB). On my Windows Subsystem for Linux I had some problems installing it, as dependencies were missing, so I had to install some more libraries, but after this extra installs all worked. If you have any problems installing Puppeteer, have a look at the Troubleshooting page.

Get the data #

First we launch a new browser with Puppeteer and go to a new page. To do this create a new file called index.js and insert the following:

const puppeteer = require('puppeteer');

(async() => {
    // start the browser
    const browser = await puppeteer.launch({ args: ['--no-sandbox'] });
    // open a new page
    const page = await browser.newPage();
    const pageURL = 'https://justmarkup.com';
    try {
        // try to go to URL
        await page.goto(pageURL);
        console.log(`opened the page: ${pageURL}`);
    } catch (error) {
        console.log(`failed to open the page: ${pageURL} with the error: ${error}`);
    }

    // all done, close the browser
    await browser.close();

    process.exit()
})();

First, we require the Puppeteer library. Next we use puppeteer.launch() to create a new browser and browser.newPage() to define a new page/tab. Last we use page.goto(URL) to open an URL.

If we run node index.js, it should log “opened the page https://justmarkup.com” in the command line. There may also be an error (invalid URL, SSL error, timeout, resource failed to load) opening the URL, so we use a try/catch statement here to catch the possible errors.

Now, that we know how to launch a browser and open an URL, let’s see how we can get data from the DOM of the page.

const puppeteer = require('puppeteer');

(async() => {
    // start the browser
    const browser = await puppeteer.launch({ args: ['--no-sandbox'] });
    // open a new page
    const page = await browser.newPage();
    const pageURL = 'https://justmarkup.com';
    try {
        // try to go to URL
        await page.goto(pageURL);
        console.log(`opened the page: ${pageURL}`);
    } catch (error) {
        console.log(`failed to open the page: ${pageURL} with the error: ${error}`);
    }

    // Find all links to articles
    const postsSelector = '.main .article h2 a';
    await page.waitForSelector(postsSelector, { timeout: 0 });
    const postUrls = await page.$$eval(postsSelector, postLinks => postLinks.map(link => link.href));

    // Visit each page one by one
    for (let postUrl of postUrls) {

        // open the page
        try {
            await page.goto(postUrl);
            console.log('opened the page: ', postUrl);
        } catch (error) {
            console.log(error);
            console.log('failed to open the page: ', postUrl);
        }

        // get the pathname
        let pagePathname = await page.evaluate(() => location.pathname);
        pagePathname = pagePathname.replace(/\//g, "-");
        console.log('got the pathname:', pagePathname);

        // get the title of the post
        const titleSelector = '.article h1';
        await page.waitForSelector(titleSelector);
        const pageTitle = await page.$eval(titleSelector, titleSelector => titleSelector.outerHTML);
        console.log('found the title', pageTitle);

        // get the content of the page
        const contentSelector = '.article .entry-content';
        await page.waitForSelector(contentSelector, { timeout: 0 });
        const pageContent = await page.$eval(contentSelector, contentSelector => contentSelector.innerHTML);
        console.log('found the content: ', pageContent);

    }

    // all done, close the browser
    await browser.close();

    process.exit()
})();

First, we get all links to our posts we find in the entry page, in my case they can be targeted with the selector ‘.main .article h2 a’.

// Find all links to articles
const postsSelector = '.main .article h2 a';
await page.waitForSelector(postsSelector, { timeout: 0 });
const postUrls = await page.$$eval(postsSelector, postLinks => postLinks.map(link => link.href));

We define the selector and use waitForSelector() to be sure the DOM nodes are visible. Next, we use page.$$eval(selector, pageFunction[, …args]), which runs Array.from(document.querySelectorAll(selector)) within the page and passes it as the first argument to pageFunction. Lastly we use the map() method to get the links to the pages defined in the href attribute. Great, we now have an Array with all our links.

Now, it is time to open all links, one after another and get the data (headline, content, pathname) we need.

for (let postUrl of postUrls) {

    // open the page
    try {
        await page.goto(postUrl);
        console.log('opened the page: ', postUrl);
    } catch (error) {
        console.log(error);
        console.log('failed to open the page: ', postUrl);
    }

    // get the pathname
    let pagePathname = await page.evaluate(() => location.pathname);
    pagePathname = pagePathname.replace(/\//g, "-");
    console.log('got the pathname:', pagePathname);

    // get the title of the post
    const titleSelector = '.article h1';
    await page.waitForSelector(titleSelector);
    const pageTitle = await page.$eval(titleSelector, titleSelector => titleSelector.outerHTML);
    console.log('found the title', pageTitle);

    // get the content of the page
    const contentSelector = '.article .entry-content';
    await page.waitForSelector(contentSelector, { timeout: 0 });
    const pageContent = await page.$eval(contentSelector, contentSelector => contentSelector.innerHTML);
    console.log('found the content: ', pageContent);

}

We loop through the above defined postUrls and use page.goto() to open each URL. Now we get the pathname, which we will later use as our filename. Here we use page.evaluate() to get the pathname defined in window.location. We also replace all “/” with “-” to get a valid filename.

Next up is the main headline of the article. Here we define a selector (in my case ‘.article h1’), use page.waitForSelector() again to make sure it is visible, and use page.$eval() to get the outerHTML of the headline. We are using outerHTML so we can pass that to the HTML-to-markdown API later.

Lastly, we get the main content of the article. We define another selector (in my case ‘.article .entry-content’), use page.waitForSelector() again to make sure it is visible, and use page.$eval() to get the innerHTML of the content.

Great, we now know how to find URLs, how to open each URL and how to get data from a page.

Convert to markdown #

So, we now have all the needed data. As the next step we will use Turndown to convert the HTML to Markdown.

const puppeteer = require('puppeteer');
const TurndownService = require('turndown');

const turndownService = new TurndownService();

(async() => {
    // start the browser
    const browser = await puppeteer.launch({ args: ['--no-sandbox'] });
    // open a new page
    const page = await browser.newPage();
    const pageURL = 'https://justmarkup.com';
    try {
        // try to go to URL
        await page.goto(pageURL);
        console.log(`opened the page: ${pageURL}`);
    } catch (error) {
        console.log(`failed to open the page: ${pageURL} with the error: ${error}`);
    }

    // Find all links to articles
    const postsSelector = '.main .article h2 a';
    await page.waitForSelector(postsSelector, { timeout: 0 });
    const postUrls = await page.$$eval(postsSelector, postLinks => postLinks.map(link => link.href));

    // Visit each page one by one
    for (let postUrl of postUrls) {

        // open the page
        try {
            await page.goto(postUrl);
            console.log('opened the page: ', postUrl);
        } catch (error) {
            console.log(error);
            console.log('failed to open the page: ', postUrl);
        }

        // get the pathname
        let pagePathname = await page.evaluate(() => location.pathname);
        pagePathname = pagePathname.replace(/\//g, "-");

        // get the title of the post
        const titleSelector = '.article h1';
        await page.waitForSelector(titleSelector);
        const pageTitle = await page.$eval(titleSelector, titleSelector => titleSelector.outerHTML);

        // get the content of the page
        const contentSelector = '.article .entry-content';
        await page.waitForSelector(contentSelector, { timeout: 0 });
        const pageContent = await page.$eval(contentSelector, contentSelector => contentSelector.innerHTML);

        // convert the html to markdown
        let pageContentMarkdown = turndownService.turndown(pageTitle + pageContent);
        console.log('Yes, this is the headline and content as markdown', pageContentMarkdown)
    }

    // all done, close the browser
    await browser.close();

    process.exit()
})();

First, we need to install Turndown by running npm install turndown in our command line. After that, we require turndown at the top of our index.js, and define the service with const turndownService = new TurndownService();

Now, we only need to add let pageContentMarkdown = turndownService.turndown(pageTitle + pageContent); after the part where we defined our pageTitle and pageContent before and voilà, we have our HTML converted to Markdown.

Save markdown files #

To finish the plan, we now need to save the converted Markdown in files (one for each article).

const puppeteer = require('puppeteer');
const TurndownService = require('turndown');
const fs = require('fs');

const turndownService = new TurndownService();

(async() => {
    // start the browser
    const browser = await puppeteer.launch({ args: ['--no-sandbox'] });
    // open a new page
    const page = await browser.newPage();
    const pageURL = 'https://justmarkup.com';
    try {
        // try to go to URL
        await page.goto(pageURL);
        console.log(`opened the page: ${pageURL}`);
    } catch (error) {
        console.log(`failed to open the page: ${pageURL} with the error: ${error}`);
    }

    // Find all links to articles
    const postsSelector = '.main .article h2 a';
    await page.waitForSelector(postsSelector, { timeout: 0 });
    const postUrls = await page.$$eval(postsSelector, postLinks => postLinks.map(link => link.href));

    // Visit each page one by one
    for (let postUrl of postUrls) {

        // open the page
        try {
            await page.goto(postUrl);
            console.log('opened the page: ', postUrl);
        } catch (error) {
            console.log(error);
            console.log('failed to open the page: ', postUrl);
        }

        // get the pathname
        let pagePathname = await page.evaluate(() => location.pathname);
        pagePathname = pagePathname.replace(/\//g, "-");

        // get the title of the post
        const titleSelector = '.article h1';
        await page.waitForSelector(titleSelector);
        const pageTitle = await page.$eval(titleSelector, titleSelector => titleSelector.outerHTML);

        // get the content of the page
        const contentSelector = '.article .entry-content';
        await page.waitForSelector(contentSelector, { timeout: 0 });
        const pageContent = await page.$eval(contentSelector, contentSelector => contentSelector.innerHTML);

        // convert the html to markdown
        let pageContentMarkdown = turndownService.turndown(pageTitle + pageContent);


            // Check if folder exists before writing files there
        const postsDirectory = '/posts/';
        if (!fs.existsSync(postsDirectory)) {
            fs.mkdirSync(postsDirectory);
        }

        // save the file as ${pathname}.md
        fs.writeFile(postsDirectory + pagePathname + '.md', pageContentMarkdown, (err) => {
            if (err) {
                console.log(err);
            }

            // success case, the file was saved
            console.log('Page saved!');
        });
    }

    // all done, close the browser
    await browser.close();

    process.exit()
})();

We are using the File System API (fs) from Node.js here, so as a first step we require it at the the top of our index.js. I wanted to save all posts in a folder called ‘posts’. So, we first check if the folder already exists, and if not we will create the folder using:

// Check if folder exists before writing files there
const postsDirectory = '/posts/';
if (!fs.existsSync(postsDirectory)) {
    fs.mkdirSync(postsDirectory);
}

Now on to the final part to save a Markdown file for each article.

// save the file as ${pathname}.md
fs.writeFile(postsDirectory + pagePathname + '.md', pageContentMarkdown, (err) => {
    if (err) {
        console.log(err);
    }

    // success case, the file was saved
    console.log('Page saved!');
});

Here we use fs.writeFile(). We want to save our files in ‘/posts/’, using our pagePathname as the filename and use the file extension “.md” so we pass that as the first argument. As the second argument we will pass pageContentMarkdown which contains the converted Markdown as a String. If all goes well, the articles now get saved one after another as Markdown files. Yes, goal achieved!

I hope you learned something from this article and maybe your next plan also includes using Puppeteer to achieve something.

I also put the final code on Github if you are curious.

Just markup

2018-11-27T07:01:10+01:00

When I started working as a Front-end Developer (or rather Web designer, as people doing HTML, CSS and a bit of JavaScript were usually called back then), all the Back-end people working at the company *laughed* at me because I was »just« doing HTML and CSS and not »real programming«. They thought all you need to know in HTML are <font>, <br> and some form elements (including <input> without labels of course).

<FONT color="black" face=Arial size=2>I am a real programmer.</FONT>

CSS was only used inline and only to change font-size and color and if they needed to align something they build some terrible tables (at a time where using tables for layout were already bad practice for several years). They didn’t think a second about accessibility, maintainability or semantics.

At that time I also used the username “justmarkup” for the first time and stuck to it when I started blogging 2012. So, if you ever wondered about my username, now you know.

On to the now #

10 years later, this hasn’t really changed. Yes, there are many Back-end/JavaScript developers now realizing that HTML and CSS is really important, that it takes a long time to master it and that a website is useless without proper HTML and CSS. At the same time, many Back-end/JavaScript developers still say that doing HTML/CSS is not »real programming«, that you more or less only need to know about <div> and <span> and that CSS is annoying.

Telling other people working on the web and doing a great job building web sites that they are useless because they focus on HTML and CSS is very wrong.

JavaScript !== Front-end #

What I am seeing is that many developers focus entirely on JavaScript nowadays and I see companies where they replace Back-end Developers with JavaScript Developers. What some don’t understand is that a JavaScript Developer is not per se a Front-end Developer. A JavaScript Developer may not like to write CSS or does not really care about semantics. That’s the same way I prefer not to work directly with Databases or configure a Server. That’s okay. What is not okay is if you don’t want to use something and at the same time tell others what they do is easy or useless. Even worse is if you try to tell experts in their field that they are doing it all wrong and that they should do it »your way«.

I had this article in my drafts for over three years and sadly the bashing even got worse in my experience. Let’s stop this madness, respect and value what others do and never think »Bla bla FIRST«.

On using tracking scripts

2018-09-13T15:06:37+02:00

Today, I saw a tweet from Jeremy Keith (@adactio)

Too many businesses treat analytics and tracking scripts as victimless technologies — they only see the benefits (in data acquisation) without understanding the costs (in performance).

which inspired me to write about the benefits and the costs for a business and for the user when using tracking scripts.

On the business side #

Benefits #

1) Free data acquisition

When using tracking scripts you can get a lot of free data from your users. You can identify a user, check what sites they visited, see the sources where they came from, check where they clicked on your site, check every mouse move and much more depending on what tracking script(s) you are using.

2) Make more money

One of the main benefits I often hear when companys want to use tracking software is that they are sure they can make more money if they know everything about their user. In theory this may be the case, but if even Amazon is unable to provide great recommendations (just ask everyone selling a book on Amazon how often they saw a recommendation to buy their own book :-)), I am unsure your company can improve sales by evaluating all the collected data.

3) Be sure that the user experience is bad

With all the collected data you may find out that a lot of user leave the registration form before finishing it. You may find many more issues after studying all the data. While this may be a benefit, most of this issues could be found without tracking, eg. by user testing. If you actually improve the user experience based on data, good, from my experience as a user and as a developer this rarely happens.

Costs #

1) Implement the script(s)

When using a tracking script, someone needs to implement it, so there are development costs. The cost may be low, if you only add a third-party script to the site, but may cost quite a lot if you want to track custom events or use more advanced features.

From a user perspective #

Benefits #

1) Better user experience

As said before a site could improve the user experience based on the data they collected. So, this is a potential benefit for you as a user.

2) ???

I am really not sure if there is any other benefit from a user perspective. If you know one please let me know hallo@justmarkup.com

Costs #

1) Performance

When using tracking scripts the performance of a site will automatically decrease. When a user is using a fast network they may not notice this, but on 3G or 2G this tracking scripts may increase the load time by several seconds. Many sites even load this scripts in the head (without async or defer) and will block other resources. When loading a tracking script is your first priority, I can’t trust your business.

2) Privacy

Depending on what tracking scripts you are using you can get a lot of information about a user (often without the knowledge of the user). Many sites also happily share this data with other companies. If you include Google Analytics they also get all the data and they can combine this with data from other sites easily (not saying they are doing this). Again, most users are not aware that their data is collected and shared and are shocked when they discover this.

3) Real money loss

I have seen sites using no more than seven different tracking scripts, together about 700kb in ~40 requests. For a user in Canada on a postpaid data plan this costs ~0.09 $. Yes, this is an extreme case and most tracking scripts are below 50kb, but if you think about it that users actually have to buy money so they can get tracked is really crazy.

4) Potential errors

When loading an external resource on a site, the JavaScript which gets executed may cause an error on a site. In the worst case the whole site may be unusable because of a third-party script. Developers of third-party scripts of course test their scripts, but I am sure they don’t test in every browser and no matter how big the company is, there is always the potential that JavaScript with an error gets shipped.

This is also not only a cost for users, but also a cost for a business – if a user can’t finish a registration or a checkout you won’t make any money from this user.

5) Vulnerability

Imagine someone manages to hack Google Analytics. Yes, this is very unlikely, but it can be done. Once an attacker is able to change the content of the script, they would be able to manipulate all sites using the script, would be able to steal data and much more. Including a third-party script is like Russian roulette – you can be never sure the third-party script is doing any harm.

Best way to handle tracking scripts #

Here is a list, how a business can handle tracking scripts, from best to worst.

Don’t use any tracking at all
Only track on the server-side
Only use self-hosted tracking scripts
Load third-party tracking scripts
Load several third-party tracking scripts
Load all the third-party tracking scripts
Load all the third-party tracking scripts before anything else

Conclusion #

When looking at the costs versus the benefits it is hard to believe that almost every website is using tracking scripts. It is like trying to sell a fridge on the south pole and nearly everyone you ask if they want one would say yes even they know that there are no real benefits but quite some costs.

The next time, you implement a tracking script it would be great if you could rethink it and ask yourself if it is really worth. When building feediary it was clear from the beginning that we don’t want to use any tracking at all and I am really happy about this decision.

Hey there feediary.com

2018-07-31T05:49:56+02:00

This past week has been really exciting with the launch of feediary.com on the 24th of July and all the awesome feedback I got afterwards. In the official announcement I already wrote about what feediary is and why you should try it. In this article I would like to talk about the Why – Why did I build the RSS reader feediary?

It all started in the middle of January 2018 – at this point I was not actively using an RSS reader and got most of the information through twitter. This mostly worked for me, but there were some problems: twitter doesn’t show feeds in chronological order anymore – which means I would often miss an interesting article. And a big issue for me, I was spending way too much time on twitter to keep up-to-date and do not miss anything. I knew I had to stop this and use it less. About at the same time people in my timeline started sharing their RSS feeds after a tweet from Laura Kalbag.

This was the perfect timing, and some days later I started working on a first prototype. Why was I not using one of the existing RSS reader you may ask now. I tried several at this time, but wasn’t really happy with any of them – some were clustered with ads, some didn’t care about my privacy, some were not really developed actively anymore and many required me to download an App for every OS I want to use it on or only worked on Desktop. So, that’s why I stared working on feediary. At first I developed it solely for me, but after some time I thought “Maybe this could be useful for many others”, and so I started again with version 0.1.

Over the next month I spent many hours beside my freelance jobs on it. I often reached a point where I wanted to give up, but after some days I always came back and started working on it again. You probably heard this before, but if you are stuck with a problem – stop trying to find a solution right away – I spend too many hours sitting there and trying to find a solution, only to find the solution in like 5 minutes the next day after a good sleep. Now, if I can’t get something to work in ~1hour I will switch to another task and come back to it the next day.

About 6 months after the first version, the site was finally ready for the public and with your support it will be here for a long time.

I will write about the technical backgrounds of feediary, the problems I faced along the way and other development stories in the future – now I need to go back and work on new features (something with offline I heard). If you want to keep up-to-date with feediary, why not subscribe to the RSS feed of our blog or follow @feediary on twitter.

I would like to thank my partner Johanna for all her great work and support, Laura for her help with the design, and Bryony for her help with copywriting. Without your fantastic work feediary would still be a prototype.

If you also 💜 RSS, do me the favour and try feediary and spread the word about it.

Progressive Enhancement and Marketing

2018-07-03T12:30:24+02:00

I am currently building a RSS reader (intro blog article about feediary) and like always it is progressive enhanced. In short this means the main features of the site will all work in older browsers, but there are several enhancements only available for supported browsers. This strategy worked great until I started working on a new feature – Themes. It is a feature only available for paid subscriptions and I wanted to make the feature available to as many different browsers and users as possible.

This got me thinking. I could build this using CSS Custom Properties, browser support is ~88% at the moment (July 2018). Still, ~10% of potential users may not be able to use the feature. I could build a fallback version for them, but this would take quite some time I have to spend on top of building it with Custom Properties. So, in the end I decided to not use Custom Properties for themes. In this article I will explain why I decided against using a new web platform feature in this case and options to list a feature not available in all browsers.

Using new web platform features #

More than two years ago I wrote about building a theme switcher using Custom Properties. Back then I finished the article by saying that you can use Custom Properties as an enhancement today. The today is now two years ago and browser support got far better and I still decided to build the theme feature without Custom Properties in this case.

As said, I wanted to offer themes to as many users as possible. To achieve this there are two ways. Build it using Custom Properties and build a fallback version for non-supported browsers. Build only the fallback version and use it for all users. The second version is faster to build. So, I went with the fallback-only version. Custom Properties are awesome and I already used them in production for themes, but there it was not a main feature – there it was an enhancement. As always – It depends.

List progressive enhanced features #

Some features can only be build using modern platform features. One example is push notifications. Support for push notifications is getting better and better, but there are still many users using a non-supported browsers. They can still use the website, but won’t get this extra feature. Others can be build using new features, but could also be build using widely supported HTML, CSS and JavaScript.

I often said and still believe that websites not only don’t have to look the same in all browsers, but that also some non-essential features don’t have to work in every browser. When I started building feediary and thought about listing the features, there was one problem with this approach – should I list features only available to some browsers, not list them at all, only list them in supported browsers or add a remark about browser support.

Don’t list the feature #

From a marketing point of view this is less than ideal. Your website offers a great feature, which may be available to most of your audience, but not for all. To not confuse users using non-supported users the best approach may be to not promote the feature at all. It is still available in supported browsers, but you don’t advertise it.

List the feature only in supported browsers #

Another approach might be to make a feature test and if the feature is supported, list the feature. If the feature is not supported you don’t list it in your features list. This way a user knows about all the features they can use in the browser they are using right now. There is one problem. If a user starts using your service in a supported browser and later switches to a non-supported browsers, they may be really confused. Even more so if they regularly switch between different browsers.

List feature with explanation to browser support #

There is another way to list a feature in all browsers. List the feature, but add an explanation next to it. A link named “in supported browsers only” which links to a page where all supported browsers are listed. This way all users know about the feature, and also know if it is supported in their browsers. The main disadvantage of this is that you have to keep the list of supported browsers up-to-date as non-supported browsers could become supported browsers any time.

I am still not sure about the best way to handle marketing for progressive enhanced features. Is it again – It depends? How are you handling this? Please let me know, you can contact me on Twitter (DM open) or by writing me an email.

Setting up https with a valid certificate for a local domain – and use it with Node.js

2018-05-31T04:36:19+02:00

Many new web platform features require a connection via https nowadays. So if you want to use and test Service Worker, you need a domain which runs on https and has a valid SSL certificate. If you have a public domain (like .com or .party), your hosting company most likely offers SSL certificates (often free now thanks to Let’s Encrypt), which are also easy to install in most cases. But, if you develop, you don’t use a public domain. You can either use http://localhost or you can use a local domain (e.g. justmarkup.localhost). If you use localhost you can still test Service Worker, as browsers have whitelisted this, but if you use http://justmarkup.localhost it won’t work.

You should use .localhost, .test, .example or .invalid for your local domain as they are save to use. Others like .dev used to work fine until some time ago and this may happen to others too, so you should stick to the Reserved Top Level DNS Names.

Often localhost is fine for developing, but if you need a subdomain or if your CMS requires you to use a top-level domain‚ you need to set up a valid SSL certificate for this domain. In this article, I will explain how to set up a local domain, how to set up Node.js and a https server, how to configure an OpenSSL certificate and how to ensure browsers consider it as a valid cerfificate.

Setting up the domain #

If you already know how to do this, jump straight to Setting up a certificate. If not, you first have to edit your hosts file. On MacOS and Linux you can find this file at /etc/hosts and on Windows it can be found at [SystemRoot]\system32\drivers\etc\hosts (if you are using the Linux subsystem it is here: /mnt/c/Windows/System32/drivers/etc/hosts). Open the hosts file and add the following at the end.

127.0.0.1 justmarkup.localhost

Replace justmarkup.localhost with your domain of choice.

With this in place we can move on and get our SSL certificate.

Setting up and installing a certificate #

First create a new folder called cert in your project folder. This is where we will save our certificates and keys. If you plan to use git for the project, I recommend adding the cert folder to your .gitignore file.

Create the root.cnf #

Okay, so first create the file root.cnf with the following content and save it in the cert folder.

# OpenSSL configuration for Root CA

[ req ]

prompt             = no
string_mask        = default

# The size of the keys in bits:
default_bits       = 2048
distinguished_name = req_distinguished_name
x509_extensions    = x509_ext

[ req_distinguished_name ]

# Note that the following are in 'reverse order' to what you'd expect to see.

countryName = gb
organizationName = Test
commonName = Test Root CA

[ x509_ext ]

basicConstraints=critical,CA:true,pathlen:0
keyUsage=critical,keyCertSign,cRLSign

You should replace organizationName and commonName with something related to your project and something you will remember lately.

Next switch to the command line and go into your cert folder you created before and run:

openssl req -x509 -new -keyout root.key -out root.cer -config root.cnf

The script will ask for a PEM pass phrase – enter something – it should be secure and you should remember it.

Create the server.cnf #

Next, create a file called server.cnf with the following content in the certs folder:

# OpenSSL configuration for end-entity cert

[ req ]

prompt             = no
string_mask        = default

# The size of the keys in bits:
default_bits       = 2048
distinguished_name = req_distinguished_name

x509_extensions    = x509_ext

[ req_distinguished_name ]

# Note that the following are in 'reverse order' to what you'd expect to see.

countryName = gb
organizationName = Test
commonName = localhost

[ x509_ext ]

keyUsage=critical,digitalSignature,keyAgreement

subjectAltName = @alt_names

# Multiple Alternate Names are possible
[alt_names]
DNS.1 = justmarkup.localhost
DNS.2 = justmarkup.test

You have to change the following things here. First, change organizationName to the same name you have set in your root.cnf. Next, change DNS.1 to your local domain name. You can also use multiple here by using DNS.2, DNS.3 and so on.

After saving the file, open your command line again and run the following:

openssl req -nodes -new -keyout server.key -out server.csr -config server.cnf

Generate the certificate #

Stay in the command line and run the following next:

openssl x509 -days 3650 -req -in server.csr -CA root.cer -CAkey root.key -set_serial 123 -out server.cer -extfile server.cnf -extensions x509_ext

Here you are required to enter the pass phrase you entered before, I hope you still remember it. Otherwise, you sadly have to start again.

Great, we now have an SSL certificate valid for ten years.

Setting up Node.js and a HTTPS server #

If you haven’t installed npm and node yet, you should do now to follow along. Here are instructions for MacOS, Linux, Windows and Linux subystem on Windows.

So, now we have npm and node installed we first have to init the project. Open your command line and move to your projects folder and init npm with:

npm init

This will create a package.json file. Next, we need to install express.

npm i express -g --save

This will add express as a dependency to our project. Now open your index.js (The entry point you selected before when using npm init – it is index.js by default if you didn’t select another one before) and add the following:

const express = require('express');
const app = express();
const fs = require('fs');
const https = require('https');

const sslOptions = {
    key: fs.readFileSync("./cert/server.key"),
    cert: fs.readFileSync("./cert/server.cer")
};

https.createServer(sslOptions, app).listen(3001);

app.get('/', (req, res) => res.send('Hello SSL!'))

Now go back to your command line and run:

node index.js

If you now open https://justmarkup.localhost:3001 (replace justmarkup.localhost with the name of your local domain) in your browser you should see “Hello SSL!”. There is still one problem, while we can serve the local domain now via https it is still considered invalid by browsers, so let’s change this.

Install the Certificate Authority #

On every OS there are different ways, how to install the Certificate Authority. Please see this post to find out how to install it on your OS. Note that for Firefox you need an additional installation as they use their own certificate authority store.

In all cases you need to install the root.cer and not the server.cer – took me some time to figure this out.

After installing it and restarting the browser, the ceritificate is now valid and you can test everything related to https on your local machine. 🎉

Note: I got most of the information from this post on stackexchange and this post. Thanks a lot for providing the information and giving me the starting point for this article.

Update 07.02.2018: Updated the example and included the -days option as mentioned by Josh Walcher. Using this with a value of 3650 means you don’t have to renew the certificate every month as it will be valid for 10 years.

Collection of CSS snippets

2018-03-27T02:45:05+02:00

Some time ago I asked on twitter about the favorite CSS snippets people use regularly.

What’s you favorite CSS snippets which you use again and again?

Rules:
– Has to fit in one tweet
– Has to be vanilla CSS (not Sass, Less…)
– You don’t have to include vendor prefixes

Go!

— Michael Scharnagl (@justmarkup) 16. März 2018

A lot of people replied with great snippets. So, without further ado, here are the most mentioned ones:

“Responsive” media #

img,
video,
audio {
  max-width: 100%;
  height: auto;
}

Using this all the img, video and audio elements won’t be larger than 100% of the container width. This prevents a common issue where an image is larger than the width of the container and therefore causes an overflow. This is the easiest way to implement responsive images, but we have great support for picture and srcset now and should make use of them. Read more about it in this great series where responsive images are explained in great detail.

Text selection #

::selection {
  color: #000;
  background: #fbd404;
}

If you want to change the default browser style how a text looks when selected you can use the ::selection pseudo-element. Support is pretty good. Read more about it on MDN.

Clearfix #

.clearfix::after {
  content: "";
  display: table;
  clear: both;
}

That’s one I have used in one or another form for many years. For older browsers we used some hacks, but nowadays we don’t need them anymore and can use this version. Some noted in the thread that clear is not needed anymore, as we have Flexbox and Grid now, but I have to disagree on this as float and clear still has its place and may ever have. In the future we may use display: flow-root; instead of clear though.

Box sizing #

html {
  box-sizing: border-box;
}

*,
*::before,
*::after {
  box-sizing: inherit;
}

The box-sizing property can make building CSS layouts easier and a lot more intuitive. There is even an International box-sizing Awareness Day. Setting the value to border-box for box-sizing tells the browser to account for any border and padding in the values you specify for an element’s width and height. This means if you set an element’s width to 20em, it’s padding to 1em and it’s border-width to 10px, the element will still be 20em width in total.

Flexbox/Grid #

There were some answers mentioning Flexbox or Grid, like this ones:

.fukol-grid {
  display: flex;
  flex-wrap: wrap;
  margin: -0.5em;
}
.fukol-grid > * {
  flex: 1 0 5em;
  margin: 0.5em;
}

.class {
  display: flex;
  justify-content: space-between;
}

::root {
  --min-col-width: 250px;
}

.overview {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(var(--min-col-width), 1fr));
}

We have come a long way with defining layout using CSS. If you want to learn more about Flexbox and Grid I recommend Grid by Example, the Flexbox Guide on MDN, the Grid and Flexbox guides on CSS-Tricks and everything Rachel Andrew and Jen Simmons have ever written and said about Grid and Flexbox.

Center elements #

Another one, many mentioned was some form of centering an element. When you look at all the stupid jokes made about CSS, it seems it is impossible to center elements in CSS. It may have been hard 10 years ago, but today there are many ways to center element vertically and horizontally.

Here are some of the replies mentioning centering.

.🦄 {
  display: flex;
  align-items: center;
  justify-content: center;
}

body {
  display: grid;
  place-items: center;
  height: 100vh;
}

.foo {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate (-50%, -50%);
}

There are even more ways to center elements as you can read in this guide.

Aspect ratio #

.video-wrapper {
  position: relative;
  padding-bottom: 56.25%; /* 16:9 */
  padding-top: 25px;
  height: 0;
}
.video-wrapper iframe {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

.wrapper {
  /* 16:9 */
  --ratio-h: 16;
  --ratio-v: 9;

  height: 0;
  overflow: hidden;
  padding-top: calc(var(--ratio-v) / var(--ratio-h) * 100%);
  position: relative;
}

.wrapper > .element {
  height: auto;
  position: absolute;
  width: 100%;
}

div {
  --ratio-x: 16;
  --ratio-y: 9;
  position: relative;
}

div::before {
  display: block;
  content: "";
  padding-top: calc(var(--ratio-y) / var(--ratio-x) * 100%);
}

The padding-bottom hack (also called Instrinsic Ratios or Aspect Ratio Boxes) has been used for many years now and even now and then people also come up with new ways like this one using CSS Grid and SVG.

cursor:pointer #

label, 
button, 
input, 
select { 
    cursor: pointer; 
}

label[for] {cursor: pointer;}

I first replied to this that it may not be a good idea to change the default cursor styles for form elements, but I am not sure anymore as many people mentioned that most people expect the pointer cursor for all interactive elements and not only for links.

Truncation #

.ellipsis { 
    max-width: 200px; 
    overflow: hidden; 
    text-overflow: ellipsis; 
    white-space: nowrap; 
}

.truncated {
  display: block;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
  max-width: 15rem;
}

At first this looks like a smart way, but truncating text with CSS can have many side-effects, as you may end up with unwanted words. I know that this is used often, but you should try to find another way if possible. I wrote about how to deal with long words here.

Max-width #

.container {
  width: calc(100% - 40px);
  max-width: 1200px;
  margin: 0 auto;
}

p {
  max-width: 75ch;
}

p {
  max-width: 38em;
}

Max-width and max-height are as their name says for defining the maximal width/height an element should be. I use this a lot for containers and also for text to keep line length at around 50 to 75 characerts. Here, the ch unit comes in handy.

Reduced motion #

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none !important;
    transition: none !important;
  }
}

On iOS and MacOS user can reduce motion via settings and we can and should react to this preference in our CSS and JavaScript Code. You can read more about it in this article by Val Head.

Responsive font-size #

:root {
  font-size: 12px;
}
@media (min-width: 768px) {
  :root {
    font-size: 14px;
  }
}
@media (min-width: 992px) {
  :root {
    font-size: 16px;
  }
}
@media (min-width: 1200px) {
  :root {
    font-size: 18px;
  }
}

.class {
  font-size: calc(1em + 1vw);
}

A combination of vw and em is great here as it will scale the text and at the same time won’t disable browser zoom.

Print external URLs #

@media print { 
    a { 
        text-decoration: underline; 
    } 
    [href]:not([href^="#"]):after { 
        content: ' ('attr(href)') '; 
    } 
}

Web pages are still printed sometimes and with this snippet you can make the URL of Links visible.

.visually-hidden { 
    clip: rect(1px, 1px, 1px, 1px); 
    height: 1px; 
    overflow: hidden; 
    position: absolute; 
    white-space: nowrap; 
    width: 1px; 
}

This is another one I have used since the very beginning of me using CSS. This way you can make text available to screen readers while hiding it visually.

Normalize #

abbr[title],
acronym[title],
dfn {
  cursor: help;
}

img {
  font-style: italic;
}

textarea {
  resize: vertical;
}

[disabled] {
  cursor: default;
}

[aria-disabled="true"] {
  cursor: default;
  pointer-events: none;
}

.no-js button[type="button"] {
  display: none;
}

svg {
  fill: currentColor;
}

sub,
sup {
  line-height: 0;
}

img {
  vertical-align: middle;
}

body {
  overscroll-behavior: none;
}

I mostly use normalize.css as a starting point and copy all needed code from there. There is also modern normalize.

Debugging #

* {
    border: 1px solid red:
}

img:not([alt]),
img[alt=""] {
  outline: 5px solid red;
}

Setting a red outline/border is the console.log of CSS debugging. If you want to find accessibility issues, there is a11y.css and if you want to find bad HTML there is revenge.css.

Box shadow #

.classname {
  box-shadow: 0 10px 20px rgba(0, 0, 0, 0.19), 0 6px 6px rgba(0, 0, 0, 0.23);
}

Seems like people really like the box shadows defined in Material Design.

Outline #

Various people also mentioned that they reset the outline property for all elements. This is a bad idea if you don’t have other focus styles for all elements in place; Please never do this and always test the site using only your keyboard to find issues with :focus.

tel: Links #

a[href^="tel"] {
  white-space: nowrap;
  pointer-events: none;
  text-decoration: none;
  color: inherit;
}
@media (max-width: 30em) {
  a[href^="tel"] {
    pointer-events: auto;
    text-decoration: underline;
  }
}

I wish there would be a way to detect if an OS or and App installed there offers the option to make use of tel: links. Assuming bigger screens means that they can’t handle tel: links is not always true.

HTML for Emails #

.★:not(#★){ /* for targeting AOL */} 
@media yahoo{/* for targeting Yahoo */} 
u+ .body .foo{/* for targeting Gmail */} 
#MessageWebViewDiv .foo{/* for targeting Samsung mail */} 
[OWA] .foo{/* for targeting http://Outlook.com  */}

I didn’t need to write any HTML for emails for year, but looks like this is still a mess and requires lots of hacks for different clients; Crazy stuff.

All snippets #

I haven’t mentioned all snippets here. If you want to see all snippets have a look at the twitter thread or you can read also most of them in a curated summary article by Ahmed Abdelsalam.

Do Not Track user preference

2018-03-01T14:09:26+01:00

Recently, I got reminded about the Do Not Track (DNT) request header. As a user, you can enable DNT in various browsers and as a website this setting should be respected. In reality very few websites honor DNT as there are no legal or technological requirements to do so and sadly most prefer to collect as much data as possible instead of respecting privacy.

What many of these websites may not realize is that they are already not able to track most of the users which have DNT enabled, as many of them also use Ad blocker or other extensions to block tracking scripts. So, why not honor the DNT and don’t load the analytics script if it is enabled by a user.

You can check if a user has DNT enabled either on the server-side or on the client-side.

Client-side #

We can use JavaScript to check for DNT on the client-side. Here is an example, which only loads Google Analytics if DNT is not enabled.

var doNotTrack = (navigator.doNotTrack === "1" || navigator.doNotTrack === "yes" || navigator.msDoNotTrack === "1" || window.doNotTrack === "1");

if (!doNotTrack) {
    var _gaq = [['_setAccount', 'UA-XXXXX-X'], ['_trackPageview']];
    (function(d, t) {
        var g = d.createElement(t),
            s = d.getElementsByTagName(t)[0];
        g.src = 'https://ssl.google-analytics.com/ga.js';
        s.parentNode.insertBefore(g, s);
    }(document, 'script'));
}

The standard way to test for DNT is using navigator.doNotTrack, which either returns “1” if DNT is enabled or “0” if not. However, some browsers use non-standard properties and values, that’s why we have to extend the test to cover all of them.

Server-side #

Even better than checking it on the client-side is checking it directly on the server-side, as there are many ways JavaScript could fail to execute.

PHP #

If you are using PHP, the information is available in the $_SERVER array:

$donottrack= (isset($_SERVER['HTTP_DNT']) && $_SERVER['HTTP_DNT'] == 1); if (!$donottrack) {echo 'embed analytics script'; }

Node.js #

In Node.js it is available via req.header.dnt. Here is an example using Express.

app.get('/', function (req, res) {
    const donottrack = (req.header.dnt && req.header.dnt == '1) ? true : false;
    res.render("index", {
        dnt: donottrack
    });
});

And now you can check for the dnt variable in the template.

if !dnt
    script(src="analytics.js")

Conclusion #

Implementing a solution to honor DNT is a relatively small effort (it took less than five minutes for me to implement it here, to only load analytics/ads if DNT is not enabled). Many websites will fear to implement this, as they want to track all users. However, for most websites the numbers won’t really change after implementing DNT as they are already not able to track most of them.

Update 19.02.2019: Safari removed support for DNT in Technology Preview 75, because some sites used it for tracking users – oh the irony.

Gifhancement – convert GIF to video and embed responsible

2018-02-26T07:21:26+01:00

In 2017, the average transfer size for websites was 3,4 MB. A big part of it (on average 1.8 MB) are images. Especially on article sites, many of these images may be GIFs. Some of these GIFs are multiple MBs and while looking at GIFs can be really funny, it is less so if you watch them on a slow device or when exceeding your available data by reading only one article. In this article, I will show how to convert GIF to MP4 to save data, how to embed the video responsible, how to react to the Save-Data header, how to enhance it using the IntersectionObserver and how to use MP4 as source for an image in supported browsers.

Converting GIF to MP4 #

First we have to convert our existing GIF files to MP4. There are multiple options available.

Use FFmpeg and the command line #

First you have to download and install FFmpeg, and after that, you can run ffmpeg -i source.gif output.mp4 in your terminal to convert a GIF with the name source to a MP4 with the name output to the same folder. You can also batch convert a directory of GIFs. Installing FFmpeg can be a challenge, so let’s see what other options we have.

Online converter #

There are multiple Services available online to convert GIF to MP4 and many also allow you to convert multiple at once.

Cloudinary #

If you are already using Cloudinary, you can replace .gif with .mp4 and they will dynamically convert it

Giphy #

When using a GIF from Giphy you can download a GIF and a MP4 version directly there.

There are other options available, but let’s move on to embedding the video on a site.

Use <video> as default #

We start with using the video element:

<video muted controls playsinline data-gif preload="metadata">
    <source src="file.mp4" type="video/mp4">
    Your browser doesn't support playing videos, but you can download it  instead. 
    <a href="file.gif">Download as GIF (1000kB)</a>  
    <a href="file.mp4">Download as Video(100kB)</a>
</video>

I added preload="metadata" to avoid that the browser will preload the whole video, and also the controls attribute to show the video controls and playsinline so the video will play inline and not fullscreen on iOS. This way the user can decide if they want to view the video or not. In addition, I added a fallback text for unsupported browsers and links to download the file as GIF or MP4. This is, however, not really a replacement for a GIF, so let`s move on.

Autoplay video if supported #

GIFs are autoplaying and to make our video react like a GIF we want the video to start immediately and also loop. First we check if the browser is capable of autoplaying videos:

// https://git.io/vH4Ek
var supports_video_autoplay = function(callback) {

    var v = document.createElement("video");
    v.paused = true;
    var p = false;
    try {
        p = "play" in v && v.play();
    } catch (err) {

    }
    typeof callback === "function" && callback(!v.paused || "Promise" in window && p instanceof Promise);

};

supports_video_autoplay(function(supportsAutoplay) {
    // supports video autoplay and querySelector
    if (supportsAutoplay && 'querySelector' in document) {
        var videos = document.querySelectorAll('[data-gif]');

        [].forEach.call(videos, function(video) {
            video.removeAttribute('controls');
            video.setAttribute('autoplay', true);
            video.setAttribute('loop', true);
        });
    } else {
        // no video autoplay support :(
    }
});

I found this test after looking at the Modernizr repository and seeing this solution by Paul O’Rely. If the browser supports autoplay we get all our “GIF videos”, remove the controls attribute and add the autoplay and loop attributes. This way the videos will now autoplay and loop like a GIF.

Use IntersectionObserver #

So, now all our GIF videos start automatically if autoplay is supported. We may use several of these videos on a page and playing them all at once means the browser has to download them all and this may also make the site unresponsive. So, as a next step we only play videos if they are actually in the Viewport using the Intersection Observer API.

if (supportsAutoplay && 'IntersectionObserver' in window) {
    var videos = document.querySelectorAll('[data-gif]');

    observer = new IntersectionObserver(entries => {
        entries.forEach(entry => {
            var video = entry.target;
            if (entry.intersectionRatio > 0) {
                // video is in the viewport - start it
                if (!video.hasAttribute('autoplay')) {
                    video.setAttribute('autoplay', true);
                    video.setAttribute('loop', true);
                }
                video.play();
            } else {
                // video is outside the viewport - pause it
                video.pause();
            }
        });
    });

    [].forEach.call(videos, function(video) {
        video.removeAttribute('controls');

        observer.observe(video);
    });
}

First we change our feature test and check if IntersectionObserver is supported. Next we define a new IntersectionObserver. If entry.intersectionRatio is bigger than 0, the video is in the viewport. In this case we add the autoplay and loop attributes if they were not already added and play the video. Otherwise, we will pause the video.

You may have noticed that by changing our feature test, now only browsers which support IntersectionObserver will get the autoplay feature. Support for IntersectionObserver is pretty good, and as people using older browsers also often use slower hardware I prefer to not play all videos at once for them and instead giving them a choice.

Save-data header #

There is another case where we shouldn’t autoplay any video, when the Save-data header is present.

We should use the Save-Data client hint request header to reduce the initial transfer size for users who have opted-in to “data savings” mode in their browser.

We can either get the info if a user has turned on Save-data on the server-side. Here is an example using PHP, which will set the data-save-data attribute on the html element if the header returns true.

$saveData = (isset($_SERVER["HTTP_SAVE_DATA"]) && stristr($_SERVER["HTTP_SAVE_DATA"], "on") !== false) ? true : false;
<html <?php if($saveData === true) : echo("data-save-data"); endif; ?>">

We can also check for Save-data on the client-side.

var saveData =  navigator.connection && navigator.connection.saveData;

So, we extend our test and check for saveData. If a user opt-in to saveData we will not autoplay the videos.

var saveData =  navigator.connection && navigator.connection.saveData;
if (supported && 'IntersectionObserver' in window && !saveData) {
    // autoplay videos
}

Enhance with serving MP4 via <img> #

The latest Safari Technology Preview now has support for using MP4 as the source for an img <img src="file.mp4" alt="">. Early tests show that using img instead of video to deliver MP4 files result in 20x faster display and 7x faster decoding time. Let’s see how we can improve our code to use img instead of video to show the video file.

First we need a feature test to check if the MP4 format is supported for img:

var supports_mp4_in_img = function(callback) {

    var image = new Image();

    image.onload = function() {
        var isSupported = image.width > 0 && image.height > 0;
        callback(isSupported);
    };

    image.onerror = function() {
        callback(false);
    };

    image.src = "data:video/mp4;base64,AAAAIGZ0eXBpc29tAAACAGlzb21pc28yYXZjMW1wNDEAAAAIZnJlZQAAAs1tZGF0AAACrgYF//+q3EXpvebZSLeWLNgg2SPu73gyNjQgLSBjb3JlIDE0OCByMjYwMSBhMGNkN2QzIC0gSC4yNjQvTVBFRy00IEFWQyBjb2RlYyAtIENvcHlsZWZ0IDIwMDMtMjAxNSAtIGh0dHA6Ly93d3cudmlkZW9sYW4ub3JnL3gyNjQuaHRtbCAtIG9wdGlvbnM6IGNhYmFjPTEgcmVmPTMgZGVibG9jaz0xOjA6MCBhbmFseXNlPTB4MzoweDExMyBtZT1oZXggc3VibWU9NyBwc3k9MSBwc3lfcmQ9MS4wMDowLjAwIG1peGVkX3JlZj0xIG1lX3JhbmdlPTE2IGNocm9tYV9tZT0xIHRyZWxsaXM9MSA4eDhkY3Q9MSBjcW09MCBkZWFkem9uZT0yMSwxMSBmYXN0X3Bza2lwPTEgY2hyb21hX3FwX29mZnNldD0tMiB0aHJlYWRzPTEgbG9va2FoZWFkX3RocmVhZHM9MSBzbGljZWRfdGhyZWFkcz0wIG5yPTAgZGVjaW1hdGU9MSBpbnRlcmxhY2VkPTAgYmx1cmF5X2NvbXBhdD0wIGNvbnN0cmFpbmVkX2ludHJhPTAgYmZyYW1lcz0zIGJfcHlyYW1pZD0yIGJfYWRhcHQ9MSBiX2JpYXM9MCBkaXJlY3Q9MSB3ZWlnaHRiPTEgb3Blbl9nb3A9MCB3ZWlnaHRwPTIga2V5aW50PTI1MCBrZXlpbnRfbWluPTEwIHNjZW5lY3V0PTQwIGludHJhX3JlZnJlc2g9MCByY19sb29rYWhlYWQ9NDAgcmM9Y3JmIG1idHJlZT0xIGNyZj0yMy4wIHFjb21wPTAuNjAgcXBtaW49MCBxcG1heD02OSBxcHN0ZXA9NCBpcF9yYXRpbz0xLjQwIGFxPTE6MS4wMACAAAAAD2WIhAA3//728P4FNjuZQQAAAu5tb292AAAAbG12aGQAAAAAAAAAAAAAAAAAAAPoAAAAZAABAAABAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACGHRyYWsAAABcdGtoZAAAAAMAAAAAAAAAAAAAAAEAAAAAAAAAZAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAEAAAAAAAgAAAAIAAAAAACRlZHRzAAAAHGVsc3QAAAAAAAAAAQAAAGQAAAAAAAEAAAAAAZBtZGlhAAAAIG1kaGQAAAAAAAAAAAAAAAAAACgAAAAEAFXEAAAAAAAtaGRscgAAAAAAAAAAdmlkZQAAAAAAAAAAAAAAAFZpZGVvSGFuZGxlcgAAAAE7bWluZgAAABR2bWhkAAAAAQAAAAAAAAAAAAAAJGRpbmYAAAAcZHJlZgAAAAAAAAABAAAADHVybCAAAAABAAAA+3N0YmwAAACXc3RzZAAAAAAAAAABAAAAh2F2YzEAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAgACAEgAAABIAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY//8AAAAxYXZjQwFkAAr/4QAYZ2QACqzZX4iIhAAAAwAEAAADAFA8SJZYAQAGaOvjyyLAAAAAGHN0dHMAAAAAAAAAAQAAAAEAAAQAAAAAHHN0c2MAAAAAAAAAAQAAAAEAAAABAAAAAQAAABRzdHN6AAAAAAAAAsUAAAABAAAAFHN0Y28AAAAAAAAAAQAAADAAAABidWR0YQAAAFptZXRhAAAAAAAAACFoZGxyAAAAAAAAAABtZGlyYXBwbAAAAAAAAAAAAAAAAC1pbHN0AAAAJal0b28AAAAdZGF0YQAAAAEAAAAATGF2ZjU2LjQwLjEwMQ==";
}

For our test we define a new Image(), use a small base64 encoded mp4 file and check onload if the width and height are bigger than 0. If yes the browser supports mp4 files for images. If not or if there was an error it doesn’t support it.

supports_mp4_in_img(function(supportsMP4InImg) {
    if (supportsMP4InImg) {
        var videos = document.querySelectorAll('[data-gif]');

        [].forEach.call(videos, function(video) {
            var img = new Image();
            img.src = video.querySelector('source').src;
            img.setAttribute('alt', "");
            if (img.decode) {
                img.decode().then(function() { video.parentNode.replaceChild(img, video); });
            } else {
                img.onload = function() {
                    video.parentNode.replaceChild(img, video);
                }
            }

        });
    }  else {
    // use as described before
    }
})

Next, we call the test function and if the callback returns true we can change our videos to images. We loop over all our videos and for every video found create a new img and replace the video with it. We also add the alt attribute for the img here. As the latest Safari version also supports the decode method for img, I added a test here to use this instead of onload when supported. The decode method is great because it ensures that the image can be appended to the DOM without causing a decoding delay on the next frame.

Last fallback #

According to Can I use about 94% of all actively used browsers support the <video> element. My first idea was to use <img src="cat.gif" alt=""> as a fallback inside the <video> element, but after some testing I found that modern browser, with support for the video element will download the img defined inside. So this is a no-go as our goal is to decrease transferred file size and not increasing it even more.

Use <object> #

As <img> is not a solution, I next tried with <object>.

<video muted autoplay loop playsinline>
    <source src="file.mp4" type="video/mp4">
    <object data="file.gif" type="image/gif">Alternative text</object>
    <a href="file.gif">Download as GIF (1000kB)</a>
    <a href="file.mp4">Download as Video(100kB)</a>
</video>

Using <object> only browsers not supporting <video> will request the file. That’s at least what my test confirmed, but as there are many more browsers and I can`t test in all I am not 100% sure this will always be the case. This way all browsers not supporting the video element will use the object and show the GIF as a fallback. I also added alternative text inside the object and two links after it to be able to easily download the GIF or video.

The advantage of this is that all users will immediately see the GIF/video, but it also feels hacky and as users using old browsers often also use slow hardware and slow connections, forcing them to download and parse all this data may be too much for their browser. So, I would say using the links to download should be enough. If the user want to see the GIF, they can always download it.

Conclusion #

Using <img src="file.gif" alt=""> is sure the easiest way to embed a GIF, but by doing so we force the user to download lots o unneeded data and slow down their device. In the future we may use <img src="file.mp4" alt=""> in all browsers, but it will take time until all browsers support this and until old browsers without support are not used anymore. Until, we can use an approach like shown here. This takes time to implement and I know this is not possible for everybody, but if you can do it consider doing it; Your users will thank you.

You can find the final demo here and you can also have a look at the final code on Github.

Resources #

Enhancing a login form – from basic to validation to reveal password

2018-02-13T08:09:39+01:00

Over the years I have implemented dozens of login forms and used thousands of them on the web. A login form mostly consists of a user/email field and a password field. It seems really basic, but there are many ways to make a login form unusable and as many ways to enhance it. In this article, I will share an approach of building and enhancing a login form.

HTTPS #

Before we start implementing, we should ensure that our site uses HTTPS and redirects every HTTP request to HTTPS. This is especially important for a site with a login form, but every website should use HTTPS for security. Using HTTP will also decrease SEO and some browsers also show a warning in the address bar if a login form is used and the site is not using HTTPS. If security, privacy and SEO are not enough to convince a client to use HTTPS, I don’t know.

Fun (not at all fun) fact: Some sites try to get around the warning by using a font-family only consisting of asterisk (*) now. If you count all the effort that went into implementing this, they could probably spend the same on moving completely to HTTPS and a SSL certificate for the next 10 years. Use HTTPS everywhere please and don’t try to play games with users.

The basic version #

Let’s start with the front-end implementation and our basic version, a HTML form with an email field, a password field and a submit button:

<form action="/login" method="post">
    <label for="email">Email</label>
    <input id="email" type="text" name="email">

    <label for="password">Password</label>
    <input id="password" type="text" name="password">

    <input type="submit" value="Login">
</form>

This will work in every browser, if the back-end is also implemented. Yes, also in Lynx. From here we start adding enhancements without breaking the basic version.

Here is a demo of the basic version and you can find the source code on Github.

Enhance with HTML #

While the basic HTML form works fine, we should enhance it by providing validation and hints.

<form action="/login" method="post">
    <div class="form__element">
        <label class="form__label" for="email">
            Email
            <span class="form__required">required</span>
        </label>
        <input class="form__input" id="email" type="text" name="email" required pattern="[^]+@[^]+[.][a-z]{2,63}$" autocomplete="email">
    </div>

    <div class="form__element">
        <label class="form__label" for="password">
            Password
            <span class="form__required">required</span>
        </label>
        <input class="form__input" id="password" type="password" name="password" required minlength="8" aria-describedby="passwordHint" autocomplete="current-password">
        <p class="form__hint" id="passwordHint">The password must be at least 8 characters long.</p>
    </div>

    <a href="/forgotPassword">Forgot password?</a>
    <input class="form__submit" type="submit" value="Login">
</form>

Let’s go through this step-by-step.

First I added <span>required</span> inside the label elements, to make it clear that the input fields are required. Additionally, I added the required attribute to the input fields. This way, a user won’t be able to submit the form in supported browsers if the value of an input is empty.

For the password field I also added an extra hint, so the users knows that the password must be at least 8 characters long. To make this accessible I use the aria-describedby attribute on the input and set the value to the id of our hint. To improve validation, I also added the minlength attribute to the password.

You may notice that I added a pattern attribute for the email field and may wonder why I didn’t use type="email". The reason is that type="email" works great in theory, but has some issues I want to avoid. The biggest problems I have with type="email" is that international email addresses are not working as you may expect and that email addresses like foo@bar are considered valid. While this is technically true, all back-end validations I ever used don’t validate such an address which means you end up with different validation on the front-end and the back-end. So, that’s the reason that I use a pattern here. I know that this regular expression is far from bulletproof, but it more or less matches my back-end validation and I am happy with it.

I also added the autocomplete attribute for both fields, so password manager will offer autocomplete. By naming the input email and password they would probably already handle this correctly, but with the autocomplete attribute we are on the safe side.

Last, I added a link to request a new password.

Here is a demo of the enhanced HTML version and you can find the source code on Github.

Enhance with CSS #

While our form now has form validation and uses proper HTML it doesn’t look appealing. So, let’s add some CSS.

.form__element {
    margin: 0 0 1em 0;
}

.form__label {
    font-size: 1.2em;
    display: block;
    margin: 0 0 0.4em 0;
}

.form__input {
    width: 100%;
    padding: 0.6em;
    font-size: 1.3em;
}

.form__required {
    float: right;
    font-size: 0.8em;
    background: #ddd;
    padding: 0.3em;
}

.form__hint {
    margin: 0;
    font-size: 1.1em;
}

.form__hint:before {
    content: "\1F6C8";
    font-size: 1.2em;
    margin: 0 0.2em 0 0;
}

.form__submit {
    background: #326f10;
    color: #fff;
    border: none;
    padding: 0.6em;
    font-size: 1.4em;
    float: right;
}

First, I added some space between the label/input groups wrapped by .form__element to make clear what groups belong together. Next, I set the label to display: block so it will be above the input. I also increased the font-size and added some spacing between it and the following input. For the input itself, I set it’s width to 100% of the width of the container and also increased font-size there and added some padding.

Next, I moved the required text to the right and gave it a light background. For the form hint about the password length I added an info icon using :before and aligned it directly under the input. Finally, I styled the submit button by giving it a remarkable background color, some padding and a big font size.

Note: I could also use Flexbox or Grid here instead of floating, but in this case it doesn’t make much sense, as it would mean more code as I would have to provide the fallback anyway.

With that in place our form now looks rather nice.

Here is a demo of the enhanced CSS version and you can find the source code on Github.

Feedback messages #

Our form now has native validation, looks good and is accessible. Let’s improve this even more with feedback messages.
The first case is that a user enters all data correctly and gets logged in. In this case, a redirect happens on the server-side to a page only accessible by logged-in users. I prefer to add a success message on top of the page so the user knows immediately that the login was successful.

<div class="message message--success" data-message>
    <p class="message__text">You have successfully logged in. Welcome back!</p>
    <button class="message__close" hidden data-closenotification>
        <span class="message__closetext">Close message</span>
    </button>
</div>

Let’s go through the HTML used for the feedback message. On the wrapper I set a data attribute, which I will later us in JavaScript, and some classes for styling it.

Next, we have the text, followed by a button. This button has the hidden attribute initially set, as the button only works when JavaScript is available and should therefore be hidden until we are sure JavaScript can be used. Browser support for the hidden attribute is pretty good, but you should add [hidden] {display: none} in CSS, so it will also be hidden in unsupported browsers.

Let’s move to the JavaScript part:

// cut the mustard

if('querySelector' in document) {

    // get all messages
    var messageComponents = document.querySelectorAll("[data-message]");

    // if at least one message is in the DOM
    if (messageComponents.length > 0) {
        // loop over each message
        [].forEach.call(messageComponents, function (message) {
            var messageButton = message.querySelector("[data-closenotification]");
            // show the close button 
            messageButton.removeAttribute('hidden');

            // on click hide the message
            messageButton.addEventListener("click", function () {
                this.parentElement.hidden = true;
            });
        });
    }
}

First, I added a simple Cut the mustard test to ensure browsers not knowing about querySelector won’t execute the JavaScript inside. Next, I used querySelectorAll to get all messages, followed by a check to ensure at least one message is present on the site. After that, I used a loop to go through every message one by one. Therein the hidden attribute gets removed to show it to the user. The following eventListener makes sure to hide the complete message after clicking the close button.

There can also be an authentication error, in which case we can also use the same markup as for the success message, but add role=”alertdialog” and aria-labelledby to give the dialog an accessible name.

<div role="alertdialog" aria-labelledby="passwordError" class="message message--error" data-message>
    <p class="message__text" id="passwordError">The provided password doesn't match!</p>
    <button class="message__close" hidden data-closenotification>
        <span class="message__closetext">Close message</span>
    </button>
</div>

The next case is showing inline validation errors. While we already use native validation, it all happens on the client-side and can therefore easily be altered by a user. So, we should plan for this and handle validation errors if the back-end catches them.

<div class="form__element has-error">
    <label class="form__label" for="email">
        Email
        <span class="form__required">required</span>
    </label>
    <input class="form__input" id="email" type="text" name="email" aria-describedby="errorEmail" required pattern="[^]+@[^]+[.][a-z]{2,63}$" autocomplete="email">
    <p role="alert" class="form__error" id="errorEmail">Please use a valid email address.</p>
</div>

On the server-side I check if there is a validation error and if yes, then show the alert message in the HTML. If you are curious, here is how this can be done using Node.js and Pug.

On the error message we set role=”alert”, and on the input we use aria-describedby with the id of the error message to connect them.

With this in place, a user will always get notified when an error occurs, no matter what browser they are using or what way they find to change the client-side code.

Here is a demo showing a simulated validation message from the back-end and you can find the source code on Github.

Enhance client-side validation #

So far we have a nice looking form, have ensured that validation is in place on the back-end and front-end and that all is accessible and usable. However, there is always a way to enhance something. So, let’s use some JavaScript to validate inputs immediately after moving on.

// cut the mustard
var form = document.createElement('form');
if ('checkValidity' in form && 'querySelector' in document && 'classList' in document.documentElement) {

    // get all inputs
    var inputs = document.querySelectorAll("[data-error]");

    if (inputs.length > 0) {

        var toggleErrorMessage = function(input, hasError) {
            var message = (input.value === '') ? input.dataset.empty : input.dataset.error;
            var oldMessage = document.getElementById("alert-" + input.name);
            var newMessage;

            if (hasError) {
                if (!oldMessage) {
                    newMessage = document.createElement("p");
                    newMessage.setAttribute('role', 'alert');
                    newMessage.classList.add('form__error');
                    newMessage.setAttribute('id', 'alert-' + input.name);
                } else {
                    newMessage = oldMessage;
                }

                newMessage.innerText = message;

                input.setAttribute('aria-describedby', 'alert-' + input.name);
                input.parentElement.appendChild(newMessage);

                input.parentElement.classList.add('has-error');
            } else {

                if (oldMessage) {
                    input.parentElement.removeChild(oldMessage);
                    input.removeAttribute('aria-describedby');
                    input.parentElement.classList.remove('has-error');
                }

            }
        };
        // loop over each input
        [].forEach.call(inputs, function(input) {

            // check validation on blur
            input.addEventListener("blur", function(event) {
                input.checkValidity();

                if (input.checkValidity()) {
                    input.classList.remove("error");
                    input.setAttribute("aria-invalid", "false");
                    toggleErrorMessage(input, false);
                } else {
                    input.classList.add("error");
                    input.setAttribute("aria-invalid", "true");
                    toggleErrorMessage(input, true);
                }
            });
        });
    }
}

Let’s go through this step-by-step.

First we have a future test to check if all needed features are supported in the browser. Next we get all input elements with the attribute data-error and add a check to ensure at least one input is present. Next is the toggleErrorMessage function we will later execute on the blur event.

In this function, I first check which message we want to show – if the value is empty we show the message defined in data-empty, else the one defined in data-error. Next, I added a reference for the oldMessage and newMessage. After that, we check if the form has an error or not by checking the hasError parameter. If there is an error, we first check if there is already an old message added. If it is not we create a new element, otherwise we will use the existing one. If it as a new message, we set role="alert", class="form__error" and the id attribute. After that, we set the text for the message element and set aria-describedby for the input field with the same value or the id of the message.

If there is no error and a message was added before, we remove the message from the DOM and also remove the aria-describedby from the input field.

Next, we loop over all inputs on the form. There we first define an eventListener for the blur event. Therein we first use checkValidity() to check validation. If no validation error is found, we remove the error class and aria-invalid attribute on the input and call toggleErrorMessage to hide the error message as described above. If there is an error, we set the error class and aria-invalid attribute and show the message.

![The password field after entered ](https://justmarkup.com/log/wp-content/uploads/2018/02/7.png)

You can read more about happier form validation from Dave Rupert. I also got the inspiration for my example above from there, so thanks Dave for writing this.

Here is a demo of the enhanced validation version and you can find the source code on Github.

Show/Hide password #

We enhanced the validation now all the way, while still ensuring that it is still usable for everyone. As the final step of our enhancements we will integrate a pattern to show or hide the entered password.

First we modify the HTML of our login form and add a <button></button> to switch the password field between type="password" and type="text".

<div class="form__elment-inner">
    <input data-toggle-password-field class="form__input" id="password" type="password" name="password" required minlength="8" aria-describedby="passwordHint" autocomplete="current-password" data-error="Please use a password with at least 8 characters."
        data-empty="Please fill out this field">
    <button type="button" hidden aria-pressed="false" class="form__toggle-password" data-toggle-password>
        <span>Show password</span>
    </button>
</div>

On the button I set the hidden attribute to hide it initially and set aria-pressed to false. As before I also set a data attribute for a reference in JavaScript and a span element containing the text »Show password«.

Let’s move on to Javascript.

var togglePasswordButton = document.querySelector('[data-toggle-password]');

if (togglePasswordButton) {
    var togglePasswordButtonText = togglePasswordButton.querySelector('span');
    var passwordField = document.querySelector('[data-toggle-password-field]');
    togglePasswordButton.removeAttribute('hidden');


    togglePasswordButton.addEventListener('click', function() {
        var isPressed = JSON.parse(this.getAttribute('aria-pressed'));

        if (isPressed) {
            passwordField.setAttribute('type', 'password');
            this.setAttribute('aria-pressed', false);
            togglePasswordButtonText.textContent = 'Show password';
        } else {
            passwordField.setAttribute('type', 'text');
            this.setAttribute('aria-pressed', true);
            togglePasswordButtonText.textContent = 'Hide password';
        }
    });
}

First, we add a reference for our button. If there is a button, we define a variable for the span element with the text and the password input. Next, we show the button by removing the hidden attribute.

After that, we define an eventListener for the button triggered on click. There we define a variable called isPressed, which will either be true or false depending on the aria-pressed attribute. I used JSON.parse here as we need a Boolean here, while the aria-pressed attribute is a String.

If it is true (meaning the password is visually shown), we set the type attribute back to password, aria-pressed to false and change the text to »Show password«. Otherwise, we set the type attribute to text, aria-pressed to true and change the text to »Hide password«.

With that in place, the user now can visually show and hide the password value.

![The password field with the password ](https://justmarkup.com/log/wp-content/uploads/2018/02/8.png)

Here is a demo of the show/hide password version and you can find the source code on Github.

Server-side #

Until now we mostly covered the client-side. You should always remember that a user can change everything on the client-side. So, while we have client-side validation it doesn’t mean that it will prevent a user from sending invalid data. That’s why you should add the same validation we added on the client-side also on the server-side. You can find a working demo with the server-side part on Glitch.

As you can see there are many ways to enhance a login form, making it more accessible and more convenient to use. While I covered many things here, this is not the »best login form ever«. There are always ways to improve it and make things differently. You should however, always think about potential errors, keep it accessible, be prepared for unexpected problems and never trust client-side only.

Here is a demo of the final version and you can find the source code including the client-side Github and all code including the server-side on Glitch.

Resources #

PWA on desktop

2018-02-05T06:54:49+01:00

Last week I twittered a poll asking which browser will be the first to bring full support for Progressive Web Apps (PWA) to desktop. Here are the results:

Wonder which browser will be the first* to bring full support for PWA to desktop.

*Yes, Samsung Internet for DeX already does, but would say it is not traditional desktop.

— Michael Scharnagl (@justmarkup) 31. Januar 2018

54% think Chrome will be the first, 27% see Firefox as the leader, 18% bet on Edge and only 1% think Safari will be the first one to ship.

Personally, I think that either Edge or Chrome will be the first to ship this spring and that Firefox will probably follow later the year. I am not sure about Safari, I was already surprised that they shipped Service Worker and other PWA features some time ago, so maybe we will see PWA support on desktop soon too.

The term PWA is a marketing term for me. When a browser says it fully supports PWA, what does this even mean? Does it mean that a prompt is showing to install a site, does it mean that technical features like Service Worker (including BackgroundSync, Push Notification…) are fully supported, does it mean that the Web App Manifest is fully supported, does it mean that the site will work offline or all of it?

As various people asked what I mean by full support, I would like to use this post to share what full support means for me and how I would like to experience PWA on desktop.

Installable #

To turn a website into a PWA it has to be installable. This can mean many things. Firstly, the browser should offer a menu item to install a website to the desktop. In addition to this the browser should offer some sort of prompting or ambient badging. On desktop I think ambient badging may work best. Browsers could show a PWA icon in the URL bar if the website meets all the requirements. A prompt can get annoying pretty soon (It already annoys me on Android sometimes), but I also think that browsers are still trying to find the best way when to show a prompt and when not, so maybe this can also work.

App Stores and Marketplaces #

I hear many people saying that there is no need for App Stores, because a PWA lives on the web and can be installed directly from there. While this is certainly true, I personally think that PWA should show up in the App Stores of the systems in addition to showing up in extra PWA app stores. I know a lot of websites, who used PhoneGap or Cordova to transform their existing site to an App, for the only reason to show up in the App Store. If it would be possible to index a PWA in the store, they wouldn’t need to do this and would have more/time to improve their acctual site. I am, however, not for automatic indexing – I think every website should choose on their one if they want to be listed in a store or not.

There is one open question with the default App Stores though. If I want to list my PWA there what browser engine will it use, will it use Webkit on MacOs and EdgeHTML on Windows or can the user choose, or will it be the engine of the default browser the user set?

I also wonder what the requirements will be, so a site can be listed in a Store. Does it have to work offline? Does it need a Ligthouse Score of > 80?

Integrated in the system #

Once an PWA is installed it should be easily findable on the system. Like a native app, it could have an icon on the desktop and should be findable via Search and Explorer. There should be no difference from a Electron App for example. The icon should be on its own and not with a small browser logo attached to it. It should also respect the display property defined in the Manifest. If the value is standalone it should open as a standalone window, while if the value is browser it should open a new browser window with the URL bar and all other browser UI visible.

Current state #

As of today (05.02.2018), Chrome has experimental support for PWA on desktop (Linux, Windows, Mac and Chrome OS).

You can enable it by visiting chrome://flags/#enable-desktop-pwas and enabling it there. After a restart you will see “Add to desktop…” in the menu. After clicking there, the app will be added to the desktop and will be discoverable like a native App. There is no prompt or ambient badging at the moment, so not sure if it will be added once this makes this into stable.

The icon on the desktop already looks like a native app icon though and doesn’t have a reference that it was added via Chrome.

If the site has a display value of “desktop” defined in the Manifest it does open a new browser window, but there is one empty tab and one with the actual site. As it is all experimental I am sure they will fix this though.

Conclusion #

I think PWA could replace many Electron Apps in the future, the same as many Cordova/PhoneGap Apps are currently replaced by Progressive Web Apps, as they are often only used as a wrapper. I also think that PWA will make it into App Stores, whereas Edge and Microsoft will probably be the first one to do so.

That all said, PWA are certainly not always the best option. There will always be the need for native apps. PWA’s will find their place on the desktop, but there are still a lot of open questions browsers need to think of to make this a great experience for users.

Update from 06.02.2018: Microsoft just announced their plan to bring PWA to Microsoft Edge and Windows 10

Quick fix

2018-01-22T05:47:34+01:00

When viewing code you will most likely come around a note along the lines of // Quick fix. Todo: Cleanup later at some point. There are many reasons developers went for a quick fix instead of a proper fix.

A critical bug was detected after a new release which needs to be fixed immediately, and there is no option to revert to an older version. Or a feature needs to be released tomorrow and you found a bug last minute and there is simple no way to postpone the feature and not enough time to do a proper fix.

Web comic by CommitStrip. Original comic can be found here

Avoiding quick fixes #

There are many ways to avoid quick fixes at the first place. As I mostly do Front-end development I will focus on CSS, HTML and JavaScript here.

HTML #

Browsers try everything to fix HTML errors, but it is of course still possible to mess it up. You could forget to close an HTML element, or you could use wrong attributes or you could use a different closing tag as intended. The first thing you can do is validating your HTML. While the validator does give you good idea what is wrong and should be fixed it can’t handle everything.

Some HTML problems may only appear after interacting with the site, so manual testing is still required for checking HTML errors.

CSS #

All CSS features have different browser support, there are still features which require a Prefix in certain browsers and there are also features which need a different syntax in different browsers. On top of that browsers will handle certain CSS differently. There are different ways to handle this:

First, we can make use of the fact that browsers will ignore CSS properties and values they are not aware of.

.element {
    color: red;
    color: hsl(0, 100%, 50%);
}

All browsers not aware of hsl() will use the value red here for color, while all other will use the hsl() value.

To handle Prefixes we can use autoprefixer in our build process so we don’t have to write all the Prefixes by ourselves.

Next, we can use feature queries.

.element {
    // code that will run in every browsers, define the fallback for CSS Grid here
}

@supports (display: grid) {
    // code that will only run if CSS Grid is supported by the browser 
}

This way we can use new CSS features for supported browsers and still ensure that older browsers look okay, by providing the fallback before defining the new CSS inside @supports.

Finally, we should use min-width/max-width instead of an explicit width to ensure it doesn’t break for long words or content. We should also build mobile first so in the worst case a user will see the mobile styling.

Automatic testing of CSS is possible, but in my opinion not practical. There are some tools to compare screenshots before/after a deploy, but there are hundreds of browsers out there used on thousands of different devices with lots of different screen sizes. The web is not print, we cannot exactly say how a website will look in any browser, but we can use feature detection and robust CSS to ensure that the site doesn’t look broken in a browser.

So, for CSS, manual testing is still the way to go. You should test early and in various browsers on various screen sizes. If you already have statistics you could check there the top 10 browsers and screen sizes and ensure that your tests at least cover these.

JavaScript #

Same time ago a client reported a bug, which made some parts of the site unusable for them. They were using Safari on an iPhone 6 in this case. I first tried to reproduce the error in an emulator, next on an iPhone 5 with the same Safari version, but it worked fine for me in both cases. Eventually I met the client and tested directly on their device. There I could finally reproduce it, but still had no idea why this would only fail on this device on not on another one using the same browser. To make a long story short, they were using Safari in incognito mode and our localStorage detection failed in this case.

So before using localStorage, we used this check:

if ('localStorage' in window) {
    // localStorage is supported, run the code
}

At first this looks like it will work. The problem is that by using the incognito mode in Safari, ‘localStorage’ was available, but once you use localStorage.setItem() it will throw an ecxeption because of security reasons.

After changing our feature detection to:

var isLocalStorageSupported = function () {
var mod = 'test';
    try {
        localStorage.setItem(mod, mod);
        localStorage.removeItem(mod);
        return true;
    } catch(e) {
        return false;
    }
}

it worked fine again. You can find more details about this in the Modernizr feature detection script.

So, before using a JavaScript feature you should always add a check to ensure the browser actually knows how to handle it. I don’t use Modernizr, but I often check the code for feature detects there. Often there are browser bugs or other issues and the Modernizr detect mostly handles these correctly to ensure the check will only be successful if the browser really supports the feature.

Furthermore, you should write robust JavaScript. Mathia⁠s Schäf⁠er wrote a fantastic developer guide about robust Client-Side JavaScript, where he writes about Progressive enhancement, How JavaScript might fail and How to prevent failure. You should read it and came back later to continue reading here.

Automatic testing #

There are various solutions available to automatically test code. There are test libraries for Accessibility , JavaScript and many more.

I won’t go in to details here, but you should always add tests to find errors before a user will find them. Personally, I don’t do enough testing at the moment, but it is on top of my priority list to change it this year and get better at it.

It should be noted that even the best automatic testing solution will not catch all errors, so be sure to always test manually in as many browsers and on as many devices as possible.

Refactoring quick fixes #

Tests help to prevent a lot of potential bugs, but even with the best test setup and lots of manual testing it is still possible that bugs make it into production. Bugs occurring in production happens to everyone.

I remember some years ago, Google shipped the landing page for the Chrome browser with a JavaScript error, which made the download button unusable for all users. When something like this happens you don’t want to waste time and get a fix out as soon as possible.

Once the fix is done, the first thing you should do is open a new issue/ticket to refactor it and find the real issue behind it. This ticket has to get the highest priority and you should start working on it immediately the next day even if you have other things planned.
Some project manager might not see the value of doing a proper fix at first – “It works now, why should we invest more time in it…”. After explaing to them that a quick fix will sooner or later result in more bugs, which will cost a lot of time and money, they mostly understand and will give you time to do the proper fix now.

Writing a comment that it should be properly refactored is not enough. Go search your current project for »Quick fix« or »Fix later« and you will probably find some and will also notice that some of these comments were added a long time ago and that there is no open issue about it.

A quick fix has to be done sometimes, but you should always react immediately after the fix is out and do a proper rewrite. You should also find the real issue why the problem occured and add a new test so this won’t happen again. And you should always use future-friendly and robust HTML, CSS and JavaScript.

Keeping track

2017-12-12T07:03:45+01:00

I wrote about how I keep track of my working time for @humanthemachine. You can read the full article on superyesmore.com.

Writing for the web

2017-11-16T06:34:53+01:00

tl;dr: Don’t share bad practise. Be responsible. Be nice. Thanks.

Some time ago I sent a tweet which got quite a lot of interactions:

If you publish articles/demos/experiments, please make them accessible.

– Use <img> -> add alt text
– Use <input> -> use associated label
– Use <span class=".btn"> – use <button>
…

Many will use/copy these. Don't share bad practise. Be responsible. Be nice. Thanks.

— Michael Scharnagl (@justmarkup) 1. November 2017

I read a lot of articles related to web development (HTML, CSS, JavaScript), which I discover via twitter, RSS or one of the many newsletters I am subscribed to; I enjoy reading them and I learn a lot from them.

Many of these articles include code examples and this is the point where I get sad sometimes. I am sad because these examples use bad practice: Inaccessible patterns, non-semantic HTML, –prefix-only CSS or JavaScript without feature tests.

Responsibility #

When publishing articles for the web we have a responsibility. Many developers will read them, many will copy the examples and many will use the code you shared. If the example demonstrates bad practise, people will adopt them, people will think it is okay to use an <img> without an alt attribute.

Sometimes, there is a note before or after the example:

Normally, we wouldn’t do this, but to keep it simple for this demo…

This is even worse; Knowing that you are sharing bad practice, but still sharing it instead of showing how it can be done better.

Nobody knows everything, that’s good. But, if you know how to do something correctly, why not share this instead of a bad example which may be shorter or simpler.

Be responsible when you share content.

Awareness #

Quite often when I see an inaccessible code example or any other bad practice I am aware of, I try to reach out to the author. I know many other developers doing the same and this is really useful. Useful for the author who isn’t aware the issue and learned something new and useful for all readers reading the corrected example because they won’t copy bad practise.

Proofreading #

When writing about new APIs or Code I am unfamiliar with I often try to reach out to other developers and ask them if they can proofread an article. This often helped me sharing bad practise because they told me how to do something better. And often they also will learn something new when reading your article. Again, nobody knows everything.

It is often hard to find someone to proofread, so I thought about setting up a slack channel or something for proofreading. If you think this would be helpful for you too, please let me know and we will try to figure it out.

Catch insensitive, inconsiderate writing #

Most people will run grammar checks on their content before publishing, but there can be other issues with text, most tools don’t catch: insensitive, inconsiderate writing. When I write, I mostly use my code editor (VS code at the moment) and write in markdown.

Before publishing an article, I run the text through Alex to find insensitive or inconsiderate phrasing. You can try it on their website and it is also available on the command line or via one of the available integration.

Clear and concise #

We shouldn’t try to be clever and use long sentences full of uncommon phrases. There is no need to impress people with your language skills. Writing clear and concise sentences will help many people. You can use a free tool to check the readability of your text.

You should also avoid [words](http://blog.stoyanstefanov.com/technical-writing-checklist/ rel=) like just and easy when describing technical details. It may be easy for you, but this doesn’t mean it is also easy for everyone else.

Text alternatives for images #

When using images you should always use meaningful text alternatives. You should also avoid images of text, as this makes the text uncopyable and untranslatable. Furthermore, it decreases the performance and you have to put effort in it to make these images accessible. There are cases where it is fine to include an image with text, for example a screenshot of a website (with an additional link to the pictured site).

If you can write it down or already have – why use an image of the same text.

This is a good example where one can clearly see that using an accessible version (text) instead of an inaccessible (text in images) is better for all. It is not only great for accessibility, but also improves user experience, SEO (Search Engine Optimization) and performance.

Vanilla code #

When using code examples, use vanilla code. I often see examples where they use Sass for CSS or jQuery for JavaScript code. If you write about a jQuery specific issue you should of course use jQuery, but when writing about JavaScript not so. You can always add an additional example using your preferred framework/plugin/tool, but we should not assume everyone else also prefers your choice. By providing vanilla code everyone can use them and adapt them to their needs.

Assumptions #

Another issue I often see is authors assuming the reader already knows about X. When using new features not directly related to the article it is always a good idea to link to other articles explaining the feature. This way readers unfamiliar with the feature can read about it before and won’t get stuck when seeing new, unexplained code.

Browser support #

Web features have different browser support and it should be mentioned in the article. I use Can I use to get browser support information and add the info to my articles. There are also various plugins/tools to embed the data from Can I use directly in the article, so the information stays up-to-date.

Outdated information #

The specification and implementation of new web features can change over time. The first thing you should do is to show the publish date of an article good visible on the site. It is also a good idea to indicate at the beginning of an article that it may be outdated. For example, I add the following info/warning for technical articles older than one year on my site:

This article has been updated the last time on January 3, 2016 and the given information may be not accurate anymore. Feel free to contact me on twitter to get more details.

Low contrast #

There was a trend to use very light, small and grey text on white background – I never understood it, but many people use this for their article pages. My eye-sight is very good, but even for me it is really hard to read many of these pages. Please always use a good Contrast ratio for all elements on your site.

Tools, Guides and Tips #

Bottom line #

Sharing good practice with accessibility in mind on a page (which itself is accessible) may take more time than sharing »simple« inaccessible demos, but it is really worth the effort. The same goes with the content of the article itself, by using clear and concise sentences many more people can read them.

Nobody is perfect and no website, article or example will ever be perfect, but you should really avoid publishing bad practice. Be responsible.

I also encourage everybody to write and publish articles. I recently had a problem, googled it and found an old article of mine where I described how to solve it. Back then I also had the problem, did research and wrote about my findings. Now, years later I was able to use this and solve the problem again.

Network based image loading using the Network Information API in Service Worker

2017-11-02T10:15:30+01:00

Recently, Chromium improved their implementation of navigator.connection by adding three new attributes: effectiveType, downlink and rtt.

Before that, the available attributes were downLinkMax and type. With these two attributes you couldn’t really tell if the connection was fast or slow. The navigator.connection.type may tell us a user is using WiFi, but this doesn’t say anything about the real connection speed, as they may be using a hot spot and the connection is in fact 2G.

With the addition of effectiveType we are finally able to get the real connection type. There are four different types (slow-2g, 2g, 3g and 4g) and they are described this way by the Web Incubator Community Group:

slow-2g: The network is suited for small transfers only such as text-only pages.
2g: The network is suited for transfers of small images.
3g: The network is suited for transfers of large assets such as high resolution images, audio, and SD video.
4g: The network is suited for HD video, real-time video, etc.

Let’s see how we can improve user experience by delivering images based on available connection speed.

Demo #

In this demo we will use the Network Information API in our Service Worker to handle image requests based on connection.

First, we register the Service Worker in our HTML file:

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('sw.js', {
        scope: './'
    });
}

Now, let’s have a look at our Service Worker file (sw.js) we registered.

const connectionEffectiveType = 'connection' in navigator;

self.addEventListener('fetch', function(event) {
    // check if the request is an image
    if (/\.jpg$|.png$|.webp$/.test(event.request.url)) {
        // check if navigator.connection is supported
        if (navigatorConnectionSupported) {
            const connectionEffectiveType = navigator.connection.effectiveType;

            // check if effectiveType is supported
            if (connectionEffectiveType) {
                const req = event.request.clone();
                let imageResolution = '';

                switch (connectionEffectiveType) {
                    case "slow-2g":
                    case "2g":
                        imageResolution = '_low';
                        break;
                    case "4g":
                        imageResolution = '_high';
                        break;
                    default:
                        imageResolution = '';
                }

                // Build the image we want to return based on connection
                const returnUrl = req.url.substr(0, req.url.lastIndexOf(".")) + imageResolution + "." + req.url.split('.').pop();

                event.respondWith(
                    fetch(returnUrl, {
                        mode: 'no-cors'
                    })
                );

            }

        }
    }
});

Let’s go through the code step-by-step.

First we define a feature test for Network Information API. Next, we define an EventListener for the FetchEvent. Therein the first check ensures we only intercept requests for images (every file ending with .jpg, .png or .webp). Next we have check if the Network Information API is supported and another test to check if also the effectiveType attribute is defined.

If both checks are successful we use a switch statement to decide when to use which image. In this case, we want to show low-resolution images for slow-2g and 2g connections, the default one for 3g and the high-resolution for 4g connections. At the end we build our new image url and respond with it instead of the original request. In our case this means if the connection is 4g and the file name is image.jpg we will instead request our high-resolution image that is available as image_high.jpg, for 2g on the other hand we deliver the low-resolution image which we have saved as image_low.jpg.

You can find the code on Github and a Demo is also available on Github pages.

We could enhance this even further, for example adding a download link for the high-resolution image underneath each image and only loading a tiny placeholder image for slow-2g. This way the images won’t be loaded on very slow connections and thus save a lot of data, but users would still be able to see/download the image if they want to.

Note: You may have noticed that you always get the default image when opening the demo for the first time. This is because on first visit the Service Worker is not yet registered and we can’t intercept the fetch request. The enhancement happens once the Service Worker is installed. At this point we can intercept the image requests and deliver the appropriate image.

Devtools #

While testing navigator.connection.effectiveType, I thought I could use the network throttle option in Chrome to imitate other connection types, but even when I used “Slow 3G”, navigator.connection.effectiveType still told me I am on 4g. After searching on crbug.com, I found the following issue. I hope this will be fixed soon, so we can test this via the network throttle tool.

The saveData attribute #

There is one more attribute defined in the Network Information API, which is saveData. If defined, it returns true when the user has requested a reduced data usage mode and otherwise false.

This isn’t available in any browser at the moment (November 2017), but may be available soon in Chromium.

Once available we can extend our code and not only check for effectiveType, but also check for saveData and only return high-resolution images if the connection is 4g and the user hasn’t requested a reduced data usage.

Browser support #

Browser support for navigator.connection is pretty bad as of now (November 2017). But, by using the API as shown in the examples above, no user will get a worse experience; On the other hand, some users using a supported browser on slow connections will benefit.

I hope that more browsers will support the Network Information API in the future. In combination with Service Worker this is a great way to enhance user experiences and decrease load times for users on slow connections.

Bottom line #

The Network Information API and especially effectiveType is great to deliver content based on network connection.

Although the API isn’t widely supported at the moment we can still use it to improve the loading experience for some users; Progressive enhancement is never a bad thing.

In the example above we handle image requests, but we can also use this for video, audio or other heavy assets. Looking forward to seeing more examples using the Network Information API. If you build something with it, please share it with me via twitter or email.

Update 4.11.2017: Moved future test for the Network Information API outside the fetch handler as suggested by Thomas Steiner

My approach on using id, class and data attributes in HTML, CSS and JavaScript

2017-07-05T05:48:40+02:00

Have you ever changed a class name in HTML and some time later got a bug report that a JavaScript functionality was not working anymore? I did and the issue was that the className was not only used as an attribute in HTML and as a selector in CSS, but has also been used by another developer in JavaScript. Over the years, working as a Frontend Developer I realized how important it is when and how to use id, class and data attributes in HTML, CSS and JavaScript.

So, I thought I share my current practise of using them.

id #

Let’s start with the id attribute. According to the Specification the value must be unique amongst all the IDs in the element’s home subtree and must contain at least one character.

While this is true in theory and will throw an error when validating HTML with two identical id`s, the page will render fine without an error in every browser and you can also style multiple id`s with the same value in CSS and even use document.querySelectorAll('#id'); and it will work fine as you can see in this demo. Nevertheless, you should never use multiple id`s with the same value on a page.

With that in mind, let’s have a look where the id attribute is useful and why.

Fragment identifier #

The first use case for the id attribute is using it as a fragment identifier. This is really helpful to link to specific areas of a page, for example if you want to link to this section of this article you can add #fragment-identifier to the url and link to it.

<h4 id="fragment-identifier">Fragment identifier</h4>

Another pattern where this is often used is a “back-to-top” link, you can add an id with the value of top to an element at the beginning of the page and add a link referencing it. The page will scroll to the top by clicking the link.

<a href="#top">Back to top</a>

ARIA #

Another case where I use the id attribute is ARIA, for example aria-labelledby and aria-describedby.

<div>
    <label for="username">Your username</label>
    <input type="text" id="username" aria-describedby="username-tip" required>
    <div role="tooltip" id="username-tip">Your username is your email address</div>
</div>

Here is an example from Heydon Pickering showing this in action.

Form elments #

As you can see in the example above the id attribute is also used for form elements. By using an id on the input/textarea and an for attribute with same name for the label you associate both.

class #

As said in the beginning, I often used classNames as a selector in JavaScript which works fine most of the time but can lead to problems if you later change a className without remembering that it also has to be changed in JavaScript.

That’s why I use classNames only for styling.

.class {
    display: flex;
}

data attributes #

I primarily use it in JavaScript, but also in CSS for different states.

var element = document.querySelector('[data-toggle]');

element.addEventListener('click', function () {
    if (this.hasAttribute("data-active")) {
    this.removeAttribute("data-active");
    } else {
    this.setAttribute("data-active", true);
    }
});

If I want to change a state in JavaScript I add/remove a data attribute, which I will use in CSS to define additional styles for it:

[data-active] {
    color: pink;
}

This way, I can immediately see which parts in HTML and CSS are dependent from JavaScript.

Conclusion #

Lately many people prefer to have HTML, CSS and JavaScript in one place, but I still prefer to separate them and with my current approach of using id, class and data attributes I can easily see in every file which part belongs to which language.

This approach alone won’t help much if you don’t have documentation in place, so be sure to always document your code in a way that the information will be available for every developer.

CSS and progressive enhancement

2017-02-13T13:33:50+01:00

When people talk about progressive enhancement it is often reduced to JavaScript. It involves much more – accessibility, performance, robustness… and also CSS. Badly written CSS can make a site as usable as a JavaScript error or using non-semantic HTML.

Let’s see why CSS can fail, why fallbacks are important and how to progressively enhance CSS.

Fallbacks #

CSS has changed a lot in the last years. More and more properties were added and while some are now supported in all modern browsers some only work in one or two browsers. In any way, we can often make use of the architecture of CSS. If a browser doesn’t know a property it will simple skip it without throwing an error. Let’s have a look at an example to demonstrate this:

h2 {
	color: black;
	color: rgba(0,0,0,0.9);
}

In this case all browsers supporting rgba() will use the rgba() value for the color property. However, browsers not supporting rgba() will ignore this and use the value “black” for the color. In this example there won’t be much harm for users as the default value for color for h2 is already black, so browsers not supporting rgba() would still show the h2 in black, but there are other cases where this can lead to unusable content or unreadable text.

h2 {
	background: rgba(0,0,0,0.9);
	color: white;
}

Let’s see how different browsers handle this example. Modern browsers supporting rgba() will show a white headline on a semi-transparent black background; Great. Browsers not supporting rgba() will show a white headline on a white background (assuming you haven’t changed the background-color of the element or parent elements), which means it won’t be visually shown for these users; Not great at all.

You probably don’t need to set a fallback for every new CSS property, but you should make sure that the content is still usable in browsers where the new CSS property is not supported. If not sure, better use a fallback.

Feature tests #

Lately, there was a new rule defined in CSS – the @supports rule. You can think of it like a feature query. It gives you the possibility to check in CSS if a CSS feature is supported. Let’s have a look at an example:

header h1 {
	font-size: 70px;
	color: green;
	padding: 0;
	margin: 0;
	text-align: center;
}

@supports (mix-blend-mode: screen) {
	header {
		padding: 0;
		background-image: url(https://justmarkup.com/iceland/img/l/DSCF3732.JPG);
		background-size: cover;
		background-repeat: no-repeat;
		width: 100%;
		min-height: 56vw;
		display: flex;
		align-items: center;
		justify-content: center;
	}
	header h1 {
		color: rgba(55,255,255,0.8);
		mix-blend-mode: screen;
		line-height: 0.5;
	}
}

Our default (not enhanced) style for our main headline is a big, green font.

This looks okay, but we want to enhance this with new CSS features – in our case with mix-blend-mode and a background. To do this, we first define our feature test @supports (mix-blend-mode: screen) {}. If the browser supports @supports and mix-blend-mode the CSS defined within our feature test will be applied. In this case, we set a background image, define the height to 56vw (so the image will maintain 16/9 ratio), add mix-blend-mode to the text and adapt the line-height as well as centering the text.

By using feature queries we can provide an enhanced version without breaking the site for unsupported browsers. Exactly, how I think progressive enhancement should work.

Here is the demo as a JS Bin if you want to see it in action.

You can find more information about using feature queries in this great article by Jen Simmons.

Custom properties #

Some new CSS properties only make sense to use for certain scenarios – custom properties (CSS variables) are a good example.

:root {--theme-color: gray;}
.element {
	background-color: gray;
	background-color: var(--theme-color, gray);
}

In this example, we first set our --theme-color to gray, next in the selector .element we first define a fallback for browsers not supporting custom-properties and after that set the background-color to our defined –theme-color. If you wonder why I defined gray inside var() var(--theme-color, gray) here, that’s because if we would not have defined –theme-color in :root before it would fallback to the value after the comma, in this case “gray”. To use CSS with custom properties responsible today (as there are still a lot of browsers not supporting custom properties), we would have to define a fallback and a custom property with another fallback.

So if you only want to store values in CSS you better use pre/post processing as they give you the same result in every browser whereas with custom properties you would either need to set a fallback every time or only modern browser would get the styles you defined with custom properties. But, if you want to have advanced features like property changes and changing properties depending on the cascade go for custom properties.

If you want to implement the option to change the theme of your site, custom properties are a great way for this. You define the custom properties in CSS, all with a fallback to the default theme values, use JavaScript on your site to check if the browser supports custom properties and if this is the case offer an interface for users to change colors, sizes… A great enhancement without harm for any user.

CSS only #

As someone working on the front-end you have probably heard of css-only or pure CSS. It is mostly used to show what amazing things can be done with CSS only. Mostly they also require HTML and should better be called No-JavaScript examples. The biggest problem many of this examples have is that the CSS is used for interactivity and often is not accessible. They often use the Checkbox Hack or make use of :target.

Don`t get me wrong, I am often very impressed by some of the examples, but the same way you shouldn’t use JavaScript to imitate HTML elements you shouldn’t use CSS for parts where JavaScript should be used.

<span onclick="javascript:window.location.href='https://justmarkup.com'; return false;">justmarkup.com</span>

I have been guilty this myself and used :target for expandable navigation, but now prefer to deliver a full shown navigation as a fallback and use JavaScript and ARIA to enhance the navigation and make it expandable. You can improve the style as much as you wan,t but you should be careful when trying to add interactivity with CSS.

ads.css #

Imagine a developer wrote a lot of styles and now names the file ads.css. If you wonder about the name, the developer speaks german and “ads” stands for “alle diese styles” (“all these styles”). It is all working fine until someone reports that the styles are not loading for them. The developer tries to reproduce it by testing in various browsers, with different extensions, on different network connections… but couldn’t find out why it is not loading for some users. After some time he finds the problem, these users are using an adblocker which blocks the loading of ads.css because of the name “Ads”.

While I haven’t seen this case in production, I saw bug reports from sites, where a developer used body class="ad"> and the site was showing a white screen instead of the content because of an adblocker blocking every content inside elements with the class ad, ads or advertisement. Better avoid naming anything in your CSS, HTML, JavaScript related to ads if it has nothing to do with ads.

The takeaway here is that anything can happen and it is not guaranteed that your CSS will always be loaded (bad connection, CDN being down…) and applied (extension interfering for example). That’s why the HTML used is not only important for SEO, screen readers, … but also if the CSS will have no effect.

HTML structure #

Using <h2>Headline</h2> will not only add semantics, but will also be visually remarkable as a headline without CSS because of the default styles the h2 gets from the browser, using <p class="h2">Headline</p> on the other hand will be shown as a paragraph with no hint that it is a headline if the CSS fails to load.

Change order with CSS #

Sometimes, we want to visually change the order of elements with CSS. We can do that with various properties (flexbox, grid, position…). As an example, let’s say we have a content area and a sidebar. On small devices we want to show the content area first and the sidebar underneath it, on bigger screens we want to show the sidebar on the left side of the screen and the content area on the right side.

When writing the HTML we should always ask how the logical order should be. In this case, we want to have the content first and the sidebar after that because the content is the most important part and the sidebar contains additional information.

By changing the order with CSS it won’t change the DOM order and it will also not effect the accessibility tree. This means, screen readers for example, will always get the information of the content area first and the one of the sidebar after that.

Note: It can get confusing for keyboard users, as by changing the order with CSS the visual presentation changes, but not the tab order, which means there may be a lot of jumping from here to there to there when using the keyboard.

Conclusion #

As with every other part on the web (and everywhere else) it is important to act responsible. While it is unlikely that a missing fallback or using an unknown CSS property will break the whole site, there is a good chance some parts won’t work as expected for some users. This is not about delivering the same styles and experience in every browser – it is about not completely breaking it for some users.

CSS can fail too, be prepared.

Implementing push notifications on the front-end and back-end

2017-02-07T16:43:07+01:00

As promised in my article introducing iss-observer.com here are the technical details about implementing push notifications. Originally, I wanted to focus on the specific issues I encountered on iss-observer.com but thought it may be more useful to show a minimal version and mention some issues as a side note. It should also be noted that some parts of the front-end are based on this tutorial

Info: If studying actual code is more your thing, you can find the code on Github and there is also a working demo showing the code in action.

Front-end #

Let’s start with the front-end part. First we add a feature test to check if the browser supports push notifications, and if it does load our JavaScript.

if ('serviceWorker' in navigator && 'PushManager' in window) {
  var s = document.createElement('script');
  s.src = '/script/push.js';
  s.async = true;
  document.head.appendChild(s);
}

Before starting with coding we need some prerequisites. We will need Application Server Keys (VAPID Key). You can get them either via this site or by installing the web-push library (which we will need later on the back-end) with npm install -g web-push and executing web-push generate-vapid-keys on the terminal. In both cases you will get a public key and a private key, which you should save at safe place.

Note on GCM #

Before the application server key / VAPID spec has been defined the first browser (Chrome, Opera) adding support for push notifications used GCM (Google Cloud Messaging) for handling notifications. All latest browser versions except for Samsung Internet now support VAPID. In this article, we won’t cover GCM, if you want to add support for current Samsung Internet (Version 5) and older versions of Chrome or Opera you can learn about more about it here.

With that in place, have a look at the JavaScript file “push.js” where we will handle the Service Worker Registration and the subscription of notifications:

'use strict';

const appServerKey = 'BHLCrsFGJQIVgg-XNp8F59C8UFF49GAVxvYMvyCURim3nMYI5TMdsOcrh-yJM7KbtZ3psi5FhfvaJbU_11jwtPY';

const pushWrapper = document.querySelector('.push-wrapper');
const pushButton = document.querySelector('.push-button');

let hasSubscription = false;
let serviceWorkerRegistration = null;
let subscriptionData = false;

function urlB64ToUint8Array(base64String) {
  const padding = '='.repeat((4 - base64String.length % 4) % 4);
  const base64 = (base64String + padding)
    .replace(/\-/g, '+')
    .replace(/_/g, '/');

  const rawData = window.atob(base64);
  const outputArray = new Uint8Array(rawData.length);

  for (let i = 0; i < rawData.length; ++i) {
    outputArray[i] = rawData.charCodeAt(i);
  }
  return outputArray;
}

function updatePushButton() {
  pushWrapper.classList.remove('hidden');
  
  if (hasSubscription) {
    pushButton.textContent = `Disable Push Notifications`;
  } else {
    pushButton.textContent = `Enable Push Notifications`;
  }
}

function subscribeUser() {
  serviceWorkerRegistration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: urlB64ToUint8Array(appServerKey)
  })
  .then(function(subscription) {

    fetch('/push/subscribe',{
      method: "POST",
      headers: {
          'Content-Type': 'application/json'
      },
      body: JSON.stringify(subscription)
    })
    .then(function(response) {
      return response;
    })
    .then(function(text) {
      console.log('User is subscribed.');
      hasSubscription = true;

      updatePushButton();
    })
    .catch(function(error) {
      hasSubscription = false;
      console.error('error fetching subscribe', error);
    });
    
  })
  .catch(function(err) {
    console.log('Failed to subscribe the user: ', err);
  });
}

function unsubscribeUser() {
  serviceWorkerRegistration.pushManager.getSubscription()
  .then(function(subscription) {
    if (subscription) {
      subscriptionData = {
        endpoint: subscription.endpoint
      };
      
      fetch('/push/unsubscribe',{
        method: "POST",
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify(subscriptionData)
      })
      .then(function(response) {
        return response;
      })
      .then(function(text) {
        hasSubscription = false;

        updatePushButton();
      })
      .catch(function(error) {
        hasSubscription = true;
        console.error('error fetching subscribe', error);
      });

      hasSubscription = false;

      updatePushButton();
      return subscription.unsubscribe();
    }
  });
}

function initPush() {

  pushButton.addEventListener('click', function() {
    if (hasSubscription) {
      unsubscribeUser();
    } else {
      subscribeUser();
    }
  });

  // Set the initial subscription value
  serviceWorkerRegistration.pushManager.getSubscription()
  .then(function(subscription) {
    hasSubscription = !(subscription === null);

    updatePushButton();
  });
}

navigator.serviceWorker.register('sw.js')
.then(function(sw) {
  serviceWorkerRegistration = sw;
  initPush();
})
.catch(function(error) {
  console.error('Service Worker Error', error);
});

First, we define the appServerKey (the public VAPID Key mentioned above) and some elements and variables. Next, we add a function called "urlB64ToUint8Array" we will later use to convert the public key, which is base 64 URL safe encoded, to a UInt8Array.

After that, we define a function called "updatePushButton" - we will call this every time the status of the notifications changes and update our UI according to it.

Next, we have the function "subscribeUser" to subscribe users. You may notice that we already defined serviceWorkerRegistration at the beginning of the file. If you go to the end of the file you will see that we override this when registering the service worker so it contains the service worker registration.

serviceWorkerRegistration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: urlB64ToUint8Array(appServerKey)
})

The subscribe() method of the PushManager returns a Promise and needs two configuration parameters:
userVisibleOnly: A Boolean indicating that the returned push subscription will only be used for messages whose effect is made visible to the user. It is required to set this to true.
applicationServerKey: The public key (we generated above) your push server will use to send messages to client apps via a push server. This needs to be a UInt8Array so we use our function mentioned before to convert our key.

.then(function(subscription) {
  fetch('/push/subscribe',{
    method: "POST",
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(subscription)
  })

Next, we send the push subscription details to the server. We can safely use the Fetch API here as every browser who supports push notifications also supports fetch. After we got back the response, we update the UI to show that the subscription was successfull or not. This is also the best place to send additional info to the user. For example, on iss-observer a user can decide if they want to receive notifications for sightings and the morning or/and evening and I also send the information about the country, region and city they want to get notifications to the server where I save the information and use them when deciding if a notification should be send.

After that, we define the unsubscribe function called "unsubscribeUser". Here, we are using the getSubscription() method of the PushManager to get the current subscription details and send it to the server via the fetch API to remove the subscription from the database.

Next, we define our init function "initPush". Here, we have an EventListener for our push button, which will either call the subscribe or unsubscribe function depending on if we already have a subscription or not. There we also set the initial subscription value.

You can find the full code used used here on Github.

Last in our file we register the service worker.

The Service Worker #

Here we will focus on the two events, "push" and "nofificationclick" we will need to handle notifications.

self.addEventListener('push', function(event) {

  let notificationData = {};

  try {
    notificationData = event.data.json();
  } catch (e) {
    notificationData = {
      title: 'Default title',
      body: 'Default message',
      icon: '/default-icon.png'
    };
  }

  event.waitUntil(
    self.registration.showNotification(notificationData.title, {
      body: notificationData.body,
      icon: notificationData.icon
    })
  );

});

First we have a look at the "push" event in our service worker. There we check if we get a payload (title, body, icon..) from the server and if not fall back to a default message. After that, we use the showNotification() method to show the notification to the user.

Note: In addition to title, body and icon the payload can also have other options like badge, tag or vibrate. At the time of writing this (February 2017) many of these are only available in some browsers. Therefore we will concentrate on title, body and icon which are supported in all browsers supporting push notifications.

self.addEventListener('notificationclick', function(event) {

  // close the notification
  event.notification.close();

  // see if the current is open and if it is focus it
  // otherwise open new tab
  event.waitUntil(

    self.clients.matchAll().then(function(clientList) {
  
      if (clientList.length > 0) {
        return clientList[0].focus();
      }
  
      return self.clients.openWindow('/');
    })
  );
});

The notificationclick event will be triggered once the user clicks on the notification. We first close the notification. Next we check if the user has already a page open and focus it or otherwise open a new window with our site.

Back-end #

Moving on to the back-end where I used the Web Push library. We will use the Node.js version, but there are also libraries for PHP, Java and C# available if you prefer any of these languages.

Note: I assume you have basic knowledge of Node.js and have used Express before. If this is new to you, I recommend reading about it first.

Okay, first of all we install the Web Push library with npm install web-push --save and require it in our app with const webPush = require('web-push');.

webPush.setVapidDetails(
  'mailto:hallo@justmarkup.com',
  "YOUR_PUBLIC_VAPID_KEY", // process.env.VAPID_PUBLIC_KEY,
  "YOUR_PRIVATE_VAPID_KEY", // process.env.VAPID_PRIVATE_KEY
);

Next, we define the VAPID Details, these are the keys we generated at the beginning. In addition to this, we need to either set an email adress with the prefix mailto: or the URL of our site - this is in case a push service has to contact you for whatever reason. As you can see in the comments in the code I prefer to save these values as an environment variable process.env.VAPID_PUBLIC_KEY - you may use other methods to save and get these values but the private key should always be saved safely and should never be exposed to the public; There is a reason it is called private key.

Next, have a look at our subscribe function:

app.post('/push/subscribe', function (req, res) {

  const subscription = {
    endpoint: req.body.endpoint,
    keys: {
      p256dh: req.body.keys.p256dh,
      auth: req.body.keys.auth
    }
  };
  
  const payload = JSON.stringify({
    title: 'Welcome',
    body: 'Thank you for enabling push notifications',
    icon: '/android-chrome-192x192.png'
  });

  const options = {
    TTL: 3600 // 1sec * 60 * 60 = 1h
  };

  webPush.sendNotification(
    subscription, 
    payload,
    options
    ).then(function() {
      console.log("Send welcome push notification");
      res.status(200).send('subscribe');
      return;
    }).catch(err => {
      console.error("Unable to send welcome push notification", err );
      res.status(500).send('subscription not possible');
      return;
  });

})

By sending the subscription details to the sever we will get the endpoint and the p256dh and auth keys. To keep this example short I will not show how to save the data in a database. For example, in my demo I used Mongo DB to save the subscriptions.

Here we will return a first notification welcoming the user once they subscribed. sendNotification() accepts three arguments: the subscription details we got from the browser, payload (title, body, icon...) and options. You can read more about the possible options here.

Info: The default TTL (Time To Live) defined by the web push library is four weeks. This means if you send a notification and the user is offline for two weeks and goes online again they will still get the notification. It is probably a good idea to change this to a shorter period as getting weeks old push notifications (which should always be important and time relevant) is probably not what you want.

app.post('/push/unsubscribe', function (req, res) {

  // remove from database
  Push.findOneAndRemove({endpoint: endpoint}, function (err,data){
    if(err) { 
      console.error('error with unsubscribe', error);
      res.status(500).send('unsubscription not possible'); 
    }
    console.log('unsubscribed');
    res.status(200).send('unsubscribe');
  });

})

When a user unsubscribes we remove the saved entry from our database so we know we don't need to try sending notifications to them again.

More information #

You will probably have different use cases and you can't and shouldn't copy paste this, but I hope this tutorial showed you how to implement push notifications on the front-end and back-end.

Here is the live demo used in this article and I also published the code on Github.

If you want to learn more about Web Push I highly recommend this free book or have a look at the examples on servicewore.rs.

If you have any issues implementing push notifications feel free to contact me on twitter or via Email.

Introducing 🚀 iss-observer.com

2017-02-02T14:14:17+01:00

Since last year I watched the ISS (International Space Station) fly over various time since reading a tweet about Spot the Station from the NASA. There, you can enter your location and find out when you can see the ISS. You can also set alerts, to get notified via Email/SMS when the ISS flies over your location. Mostly this works fine, but I found that they are also sending notifications if the weather is really bad and you actually can’t see it and also if you can see it only for a very short time period.

Later that year, I learned more about Push Notifications and started building a web app where you can search for your location, get data about ISS sightings combined with weather information and being able to receive push notifications.

I had a first version ready pretty quick, but hesitated to launch the site as I knew it is not perfect. I had to remind myself that a website is never done, there are always possible improvements and if I would wait for all the enhancements I have in my mind the site would probably never go public.

So, without further ado, let me introduce you to iss-observer.com.

Push notifications #

The main feature why I build the site is to be able to receive push notifications on my phone. On the technical site, I used the Web Push library for Node.js on the Back-end. This helped me a lot in implementing it. However, I also had some issues along the way, which I will write more about in a separate article.

You can choose if you want to get notifications in the morning or/and evening and I tried to make clear that you will only receive a notification if the sky is clear enough to see it and if the time period is long enough.

Performance #

I tried my best to get a great performance and on the front-end I am doing pretty well. On PageSpeed Insights the site gets 100 out of 100 on mobile and desktop.

Running the Lighthouse audit tool shows me 91 out of 100 possible points.

The main reason why I don’t get 100 points is that the server-side can be pretty slow. When you search for a location I need to get the live data from the NASA as well as the weather information and unfortunately this can take some time until I get all the data. I am still looking for a way to improve this though.

If you find any issues or want a new feature or enhancement added please write me an Email, send me a tweet or file an issue on Github. Thanks!

I have already various enhancements planned and I am currently working on something which may or may not involve Augmented Reality. Stay tuned.

Handling states on resize using CSS custom properties

2017-01-24T10:31:50+01:00

Last week, Scott Jehl asked: Have your a11y assumptions/practices evolved w RWD?, which reminded me to re-evaluate my current practise of handling states on resize. My current approach is importing CSS breakpoints into JavaScript and handle the JavaScript based on the values from the :before pseudo elements defined in CSS. This way I don’t need to define the width/height where the elements should change in CSS and JavaScript, but only in CSS. While this is a great solution, it is also a hack and I think custom properties are better here.

So, let’s see how we can improve this using CSS custom properties.

Throughout this article, we will use an expandable menu as our example. The idea is that the menu is fully visible on big screens and transforms into an expandable menu on small screens. Our basic markup looks like this:

<header role="banner">
	<a class="logo" href="/" title="Home">Logo</a>

	<nav role="navigation" id="menu" class="js-menu js--expandable">
		<ul>
			<li><a href="/">Link 1</a></li>
			<li><a href="/">Another Link</a></li>
			...
		</ul>
	</nav>
</header>

So, we have a header with our Logo and a navigation with multiple navigation items. I also added an id to the nav and two classes, which we will need later.

With this basic markup and some styles our header will look like the following on big screens and small screens. Users of old browsers will also get this along with the case where JavaScript fails.

Now, let’s have a look at the JavaScript.

//CTM
if (window.CSS && CSS.supports('color', 'var(--primary)')) {

	var expandableElement = document.querySelector('.js--expandable');
	var header = document.querySelector('header');
	var menu = document.querySelector('.js-menu');
	var menuButton = document.createElement('button');
	var hasRun = false;

	function observeMenu() {

		var isExpandable = window.getComputedStyle(expandableElement).getPropertyValue('--expandable').trim();
		
		// check if --expandable is set to true
		if (isExpandable === 'true') {
						// add menu toggle button and eventListener if not already happened before
			if (!hasRun) {
				initToggleMenu();
			}
						// hide menu and show button
			menu.setAttribute('hidden', true);
			menuButton.removeAttribute('hidden');
			menu.setAttribute('aria-labelledby', 'menu-button');
		} else {
						// hide button and show menu
			menuButton.setAttribute('hidden', true);
			menu.removeAttribute('hidden');
			menu.removeAttribute('aria-labelledby');
		}

	};

	function initToggleMenu () {

		// Button properties
		menuButton.classList.add('menu-button');
		menuButton.setAttribute('id', 'menu-button');
		menuButton.setAttribute('aria-expanded', 'false');
		menuButton.setAttribute('aria-controls', 'menu');
		menuButton.innerHTML = 'Menu';
		
		// Menu properties
		menu.setAttribute('hidden', true);
		menu.setAttribute('aria-labelledby', 'menu-button');
		menu.classList.add(' is--expandable');
		
		// Add menu button to DOM
		header.insertBefore(menuButton, menu);


		// handle click on menu button
		menuButton.addEventListener('click', function () {

			if (!menu.hasAttribute('hidden')) {
				// Hide
				menu.setAttribute('hidden', true);
				menuButton.setAttribute('aria-expanded', 'false');
			} else {
				// Show
				menu.removeAttribute('hidden');
				menuButton.setAttribute('aria-expanded', 'true');
			}
		}, false);

		hasRun = true;

	};

	observeMenu();
	
	window.addEventListener('resize', observeMenu, true);
	
}

It is pretty long, so let’s go through this step by step. First, we have a Cut the mustard check, so only supported browsers will run the JavaScript. Next, we define some variables with our needed elements as well as a Boolean value we will use later to check if the button has already been created.

After that, we create a function called observeMenu which we will execute on page load and on every resize. Within the function we first get the CSS custom property named --expandable, based on which we will decide if the menu should be expandable or not.

Here is the CSS we use to set the custom property. On small screens we set it to true and once there is enough space to show it in one line, we set it to false

.js--expandable {
	--expandable: true;
}

@media all and (min-width: 50em) {
	.js--expandable {
		--expandable: false;
	}
}

Back in our observeMenu function, if isExpandable is true, we first check if we already added the menu, and if not add it. Futhermore we change some attributes based on the isExpandable variable.

Next, we have a function called initToggleMenu, within we create the menu button to toggle the menu and also add an click event listener for our button.
Lastly in the function we set the variable hasRun to true so the menu button only gets added once. Add the end we call our observeMenu function and listen to it onresize.

With that in place our menu is now expandable on small screens (if the browser supports custom properties) while still looking the same in other browsers and on big screens.

Here is a Demo and the code is also available on Github.

Conclusion #

While this solution may not always be the best option, due to browser support of CSS custom properties it is great as an enhancement for menus or other components. I already have some use cases in my mind that I am looking forward to use in upcoming projects.

Overall, I think this is a great use case for custom properties and it feels a lot less hacky than using :before pseudo elements.

Early adopters – Using new web platform features

2017-01-20T15:05:28+01:00

In this article I would like to go through the why and when of using new features, ways to use features early and the responsibility of early adopters.

What are the benefits? #

Before using a new web platform feature, you should always ask: What are the benefits? Will this increase the experience for your users? Will your company benefit from it by saving money, development time…?

You should also have a look at your statistics, to see how many users will benefit from the new feature now, in 6 months, in 2 years. Furthermore, you should find out if the new feature is a Draft or Recommendation? Also, how many browsers show interest in the new feature, how many browsers have already implemented it and how many browsers have it on their road map to implement it in the near future?

Finally, you should find out it the feature, can be used as an enhancement, or with a fallback.

If a feature is a Draft, one browser has implemented it (about 20% of your users), no other browser shows real interest, you could also implement a solution without using the feature and the time to implement it would be 40 hours it probably makes no sense to use the new feature.

If a feature is a Recommendation, two browsers have implemented it, one is working on it and one shows interest, you couldn’t achieve it with existing technologies and the time to implement it will be 20 hours it probably makes sense – but only if you answered the questions above and see a benefit for your users/your company.

Using a new feature just because it is “cool” is not really smart. Find out the cost vs. benefit ratio and based on that decide for every feature if you should implement it now, later or never.

After talking about why and when to use new features, let’s have a look how to use new features.

-prefix #

CSS Vendor Prefixes have been proposed by Mike Wexler from Adobe in September 1998. While it seemed like a good idea to ship experimental features with prefixes, in the end they didn’t work out so well .

Because of developers using prefix-only CSS, some browsers even had to add support for prefixes from other browsers because web sites look broken in these browsers.

Nowadays, there are tools like autoprefixer to automatically add all needed prefixes based on a defined browser matrix. Even if these features would have existed from the beginning of prefixes, there would always be developers not using such a tool and there will always be sites not updating their CSS and we would still have sites using wrong prefixes or even worse prefix-only CSS.

While we still have to deal with prefixes for some time, I think there won’t be any (at least none I am aware of) new features shipped with a prefix. So, moving away from prefixes, let’s have a look what our options are to try out experimental/new features and ways to use them in production early on.

Flags #

After learning from the negative impact of prefixes, many browsers like Firefox, Chrome and Opera are now adding experimental features behind user-controlled flags.

With flags, developers can test new features and learn about them so they can use the feature as soon as browsers start to ship to all users. Using feature detection they can also implement a feature now, although it isn’t shipped without a flag in any user and once available without flag users can benefit from it. So, when using features shipped behind flags always be sure to test with flags disabled as this is what the majority of your users get.

Testing features behind flags gives developers also time to find bugs and report them early in the process (more on that later), and browsers and spec writers time to fix these before shipping it to all users.

Origin Trials #

Origin Trials is an approach to enable safe experimentation with web platform features.

At the moment (January 2017), Chrome is the only browsers using Origin Trials for some experimental features, but I hope more browsers will start using them in the future.

Before you are able to use a feature shipped with Origin Trials, you have to request a Token for your site (origin). You can only participate if your site is available over HTTPS.

After some time (up to 24hours) you will get an email with the Token. For example, the meta tag for using the Web Share API looks like this:

<meta http-equiv="origin-trial" data-feature="Web Share" data-expires="2017-02-15" content="YOURTOKEN">

Once you have implemented the meta tag on your site you will be able to use the new feature and ship it to all users with a supporting browser. Every 2 months you have to renew your Token and also answer some questions about what you like/dislike about the feature. This information is very important for browsers, so they can change the implementation early on, based on findings from early adopters.

What I like about Origin Trials is that developers have to use them careful, have to update their Token and most important have to give feedback to the browsers with the benefit of being able to ship new features to all supported browsers early on.

Developers using new web platform features from the beginning have the responsibility to challenge the features and report bugs and issues to the browsers and specification authors. While specification authors and browser developers try to think about every use case and edge case there are often cases they didn’t take into account and this is where we as developers can help.

*Every* browser has a page to report bugs and you can also open an issue on the Github pages from the W3C for many new features.

Conclusion #

When using new platform features, keep in mind that you are an Alpha/Beta user. Be aware that things may change or even break in the future. When using new features from the beginning, be sure to report bugs and issues.

And always keep in mind that you don’t have to use/know about every new feature and that it often makes no sense to implement a new feature only because you can. Use featurs wisely!

As always, these information may be out of date by the time you are reading this. Futhermore there may be more usable information I am/was not aware of. In both cases it would be great if you could let me know via Email or on twitter.; Thanks.

Truncating and revealing text – The Show More and Read More patterns

2017-01-12T17:28:18+01:00

Truncating text and revealing text on the web is very common and I have to deal with these patterns almost on every project I work on. There are many situations where people want to have expandable text. In this article, I will cover the Show More pattern (toggling text on user gesture) and the Read More pattern (Show full content on user gesture).

Show More #

Let’s start with the Show More Pattern – where you have a short text and a button to reveal the longer text. Without the markup needed for the reveal function the HTML may look like this:

<article>
	<h2>Headline</h2>
	<p>Some text. Some text. Some text.</p>
	<div>
		<p>Some more text. Some more text. Some more text. Some more text.
		Some more text. Some more text. Some more text.</p>
		<p>Some more text. Some more text. Some more text. Some more text.
		Some more text. Some more text. Some more text.</p>
	</div>
</article>

We can use a JavaScript or CSS-based method to add the toggle functionality. First, let’s see how we can achieve it with JavaScript.

Using JavaScript #

To start with, we modify the HTML and add a button to toggle the content and an id attribute on the “full text” wrapper element to associate it with the toggle button.

<article>
	<h2>Headline</h2>
	<p>Some text</p>
	<div id="more-1" class="fulltext">
		<p>Some more text</p>
	</div>
	<button aria-expanded="false" aria-controls="more-1" class="toggle-content" hidden><span class="text">Show More</span> <span class="visually-hidden">about Headline</span></button>
</article>

On the button we add two attributes aria-expanded="false" and aria-controls="more-1" for better accessibility. We also set the attribute hidden so the button is hidden by default when the full text is not hidden as well. We also add some extra text for context, more on this later.

With that in place, it will still look and behave the same as before (featured text and full text shown, toggle button hidden). This means that when JavaScript fails/is not available the user will still be able to read the full text.

Now, we add some JavaScript to enhance this and toggle the full text.

// cut the mustard
if ('querySelector' in document && 
	'addEventListener' in window) {

	var toggleButtons = document.querySelectorAll('.toggle-content');
	var fullTextWrappers = document.querySelectorAll('.fulltext');
	var fullText;
	var toggleButtonText;
	

	[].forEach.call(fullTextWrappers, function(fullTextWrapper) {
		// hide all full text on load
		fullTextWrapper.setAttribute('hidden', true);
	});

	[].forEach.call(toggleButtons, function(toggleButton) {
		// show toggle more buttons
		toggleButton.removeAttribute('hidden');

		// add listener for each button
		toggleButton.addEventListener('click', function () {

			fullTextWrapper = this.parentElement.querySelector('.fulltext');
			toggleButtonText = this.querySelector('.text');

			// change attributes and text if full text is shown/hidden
			if (!fullTextWrapper.hasAttribute('hidden')) {
				toggleButtonText.innerText = 'Show More';
				fullTextWrapper.setAttribute('hidden', true);
				toggleButton.setAttribute('aria-expanded', false);
			} else {
				toggleButtonText.innerText = 'Show Less';
				fullTextWrapper.removeAttribute('hidden');
				toggleButton.setAttribute('aria-expanded', true);
			}
		});
	});
}

We start by cutting the mustard, so users using old browsers not supporting querySelector or addEventListener will get the “No-JavaScript Version” and can still read everything, while all other will get the enhanced version.

Next, we define some variables we will need later and go through all full-text elements and hide them. After that, we loop over every toggle button, show it and add an listener. Within the listener, we check if the full text is hidden or not and based on this show/hide the text and change the text and aria-expanded attribute of the button.

Demo: Using JavaScript to toggle content, there is also a version with jQuery

Code: Using JavaScript and the one using jQuery

Next, we have a look at how to achieve the same functionality without JavaScript.

Using :target #

For this, we make use of the Target Trick to show/hide content based on the fragment identifier (hash) of the URL.

First, we change the Markup of our initial example:

<article id="less-1">
	<h2>Headline</h2>
	<p>Text.</p>

	<div class="fulltext" id="more-1">
		<a class="more" href="#more-1">Show more <span class="visually-hidden">about Headline</span></a>

		<p>More Text</p>

		<a class="less" href="#less-1">Show less <span class="visually-hidden">about Headline</span></a>

	</div>
</article>

Here, we add an id attribute to the outer article element (to jump back there when hidding the content), an id attribute to the full text and two links (one to show and one to hide the full text).

Next, we add some CSS:

.fulltext p,
.less {
	display: none;
}

.fulltext:target p,
.fulltext:target .less {
	display: block;
}

.fulltext:target .more {
	display: none;
}

Per default, we hide the full text and the Show Less link. If the full text container is targeted (.fulltext:target) we show the full text and Show Less link and hide the Show More link.

Example: Using :target to toggle content
Code: of the :target version on Github

Note: You could also use the Checkbox Hack to achieve a toggle content pattern without JavaScript.

Summary #

For this pattern I personally prefer a progressive enhanced JavaScript-based version because there won’t be the page jump as with the :target version and while I enjoy tricks/hacks with CSS I think that behaviour should be done in JavaScript if there are no disadvantages over a CSS solution.

Whatever solution you choose, be sure to test if it is accessible and what happens if the something goes wrong.

Cutting text #

Truncating text on the web often seems an easy job at a first glance, but there are many ways to solve it and a lot of things which can go wrong.

“Very important person is dead…Read More”
while the whole sentence would be
“Very important person is dead serious about solving the problem.”

While I haven’t seen exactly this example, I have seen many examples where truncating text completely changed the meaning of a word or sentence. Sometimes this is funny, but it can also be abusive and offensive.

That’s why you shouldn’t truncate text automatically if possible. In many CMS authors can define the featured text and where the Read More should appear. This way you will always know where the text is truncated and won’t run into a shitstorm because of wrongly truncated text. If manual truncating is not possible, at least truncate after sentences.

Providing context #

As shown in all examples above, I added an extra text for all Read/Show More/Less buttons and links with the class .visually-hidden.

<a class="more" href="/article/#more">Read Mor <span class="visually-hidden">about Article</span></a>

.visually-hidden {
	clip: rect(1px, 1px, 1px, 1px);
	height: 1px;
	overflow: hidden;
	position: absolute;
	white-space: nowrap;
	width: 1px;
}
a:hover .visually-hidden,
a:focus .visually-hidden,
button:hover .visually-hidden,
button:focus .visually-hidden {
	position: relative;
	margin: 0;
}

This text is visually hidden, but will be announced by screen readers. This is really useful as otherwise they may hear “Read More” multiple times, but don’t know where the link will lead to as the context is missing. For the examples above, I also decided to show the text if you hover or focus any of the links or buttons to see what text you are going to hide/show if there are multiple.

Conclusion #

Be nice to your users, try to avoid automatic text truncation and always think about cases where something can go wrong. You don’t want to have hidden text which can’t be expanded because of a JavaScript error.

Distrusting certificates – Time to act if you use a StartCom (StartSSL) or WoSign certificate

2016-12-20T16:37:28+01:00

Info: If you are using a certificate from StartCom (for example the free StartSSL certificate) or WoSign you should start switching to another certificate (from Let’s Encrypt or any other trusted one). Otherwise, your site will be marked as insecure and might not be accessible to users in the next stable Version of Chrome (56) and Firefox (51) which will both be released at the beginning of 2017.

This month my SSL certificate from StartSSL for justmarkup.com had to be renewed. This task is normally done pretty quick and I didn’t expect any problem. Some days later I updated my Chrome to Version 56 and suddenly my site was marked as insecure and I had to explicitly allow it to access it.

Chrome 56 showing justmarkup.com as insecure because of a StartSSL certificate. Screenshot by Anselm Hannemann

I tried to access it in other browsers, but they all showed the site as secure and after some debugging and trying to find the problem I came across an article by the Google security team. As you can read there, as of Chrome 56 (and also Firefox 51 as I later found out) certificates from StartCom (including their free StartSSL certificates) and WoSign will no longer be accepted and sites using them will be marked as insecure.

Before Let’s encrypt came out a lot of people got their certificate from StartCom as they were one of the only ones available for free. I expect a lot of people still use them and I hope they find out about the problem soon enough so their sites will still be available after the next stable releases.

Thanks to Anselm Hannemann for reminding me about the issue yesterday, so I finally took the time to switch servers and to Let’s Encrypt.

Improving performance by Caching and Storing – article for Performance Calendar 2016

2016-12-14T06:30:11+01:00

I had the honour to publish an article for the Performance Calendar 2016 about ways to improve performance by caching and storing. I write about ways to enhance performance for first and returning visits and explain the advantages of different caching and storing options.

You can read the original article over at http://calendar.perfplanet.com.

You should also have a look at the other entries.

Browsers should be more intolerant and punish bad practice

2016-11-01T12:51:53+01:00

As of October 15, 2016 the average web page is about 2.5MB. The size is increasing and increasing. Five years ago it was 830kb and I don’t want to think of how big it will be in five years from now. In the past five years browsers changed a lot, among other things they also got a lot fast. So, on hand hand browsers get faster on the other we build heavier sites; It is a cat-and-mouse game.

It’s pretty crazy when you think about it. Browsers get faster, we have new technologies (responsive images, new image formats, Service Worker, HTTP/2…) and still surfing the web often feels as slow or even slower as five years ago. The main reason is that we build sites that are bloated and not optimized.

There are many reasons why slow and inaccessible web sites are launched day by day: Time, Budget, uninformed developers, false assumptions …

And there is another reason, I think has an impact: Browsers, browsers being tolerant and letting you load a 5MB background image, browsers being tolerant and letting you listen to events on inaccessible elements. You can throw a lot of *bad* things at browsers and they will not complain. Instead, they will do everything they can to clean up the mess.

Security #

In some way browsers are already pushing developers in the right direction. Powerful features will be has been deprecated on Insecure Origins. Furthermore, browsers started/will start to indicate/warn about insecure sites and also search engines will punish sites not using SSL by giving them a worse ranking. This is fantastic for security and privacy.

So, when browsers can convince developers/site owners to secure their sites wouldn’t it also be great if they can convince them to build faster and more accessible sites.

Warn and punish #

I know it can be hard for browsers do decide what is bad and what is still okay? Is a web site loading one 2MB image bad or is that okay? What about a web site loading 50 images with 800kB? And, it will be even harder if not all browsers will agree on being more strict. You surely don’t want to be the browser where things will not work anymore because you started to be more strict and the others are not following.

Regardless the concerns, I think it would be really great if browsers would start to log errors for bad things: Huge images, accessibility issues, performance issues…

Here is an example of what this could look like in the console:

This way, it will be a lot harder for developers to ignore these issues. Also, clients and site owners may then realize that not everything is possible with the time and budget they considered. That they may not build yet another useless feature, but instead focus on speed and accessibility.

After some time of warning they could put this into practise and refuse to load big images or ignore events on inaccessible elements.

Conclusion #

Many people do a great job and build fast and accessible sites and many people blame slow and inaccessible sites and try to educate others to do better, but I have the feeling this is not enough. For one or another reason there will always be slow and inaccessible sites.

I know it will be a huge step for browsers, but I think it is about time browsers start to be more strict and prevent this.

What do you think? Should browsers start to be more strict and intolerant?

Using the Web Share API to enhance a static share link

2016-10-21T05:56:26+02:00

The Web Share API is an experiment in Chrome and the origin trial will end in April 2017. Although I try to keep my articles up-to-date, the information here will likely be outdated at some point. For more info please visit developers.google.com

Since Chrome 55 (Beta as of October 2016) you can use the Web Share API as an Origin Trail on Android. In this article, I would like to show, how to enhance your current share button with the Web Share API.

Requirements #

As I said, the Web Share API is an origin trail until April 2017. So, you first need to sign up to get a trail token. After about 1 day (it took ~4hours in my case) you will get an email with the Origin Trial Token for your site.

Next you have to include the token on your site:

<meta http-equiv="origin-trial" data-feature="Web Share" data-expires="2016-12-01" content="TOKEN">

Further requirements are:

Your site needs to be served via https
You can call navigator.share() only on user gesture, eg. click.
All property values must be strings

With that in place we can now use the Web Share API.

Demo time #

First, we will include a static share link for twitter:

<a class="share" href="https://twitter.com/intent/tweet?text=Using%20the%20Web%20Share%20API%20https%3A//justmarkup.com/log/2016/10/using-the-web-share-api/">Share via Twitter</a>

This way everybody using a browser not supporting the API will get a link (which may or may not look like a button) to share the site on twitter.

Next, we add a script at the bottom of our site to enhance the link using the Share API:

if (navigator.share !== undefined) {
	const SHARE_BTN = document.querySelector('.share');

	SHARE_BTN.textContent = 'Share';

	SHARE_BTN.addEventListener('click', function (ev) {

		navigator.share({
			title: document.title,
			url: document.querySelector('link[rel=canonical]') ? document.querySelector('link[rel=canonical]').href : window.location.href
		}).then(() => console.log('Successful share'))
		.catch((error) => console.log('Error sharing:', error));

		ev.preventDefault();
	});
}

Let’s go through the code one by one. First, we add a feature test to check if navigator.share is supported. If this is the case, we change the text of our share link from “Share via Twitter” to “Share” to show that you can share with various services.

Next, we add an EventListener for our share link, to call navigator.share on click. There we define properties for title and url. You can also add a text property here. For the url we first check if there is a canonical link and use that, otherwise we use the current url.

Last, we call ev.preventDefault(); to prevent the default action of the link.

Everyone using a browser supporting the Share API can now easily share the site via all services/apps they have installed on their device and all others still get the twitter link or can copy the URL and share with their favorite service.

Here is a demo and you can also find the code on Github.

Note: To enhance the sharing for browsers not supporting the Web Share API you can also use responsible social share links and load the share dialog in a pop-up.

Conclusion #

It takes some preparation to use the Share API, but once you have completed them you can use it with some lines of JavaScript.

The Web Share API will be a trail at least until April 2017, after that there may be another trail or it may be implemented by default. It also only works on Android for now. Still, I like the idea – it is a great example of browsers implementing features many sites already use. This gives users an enhanced experience without the overhead of loading lots of JavaScript as it currently the case on many sites.

Happy sharing!

Fast on my machine

2016-10-20T07:07:57+02:00

Yesterday at Polymer Summit, Alex Russell gave a fantastic talk about adapting to the Mobile Web; You should watch it!

“You need to be interactive in about 3 seconds, on 3G, on a $200 phone. Then, in less than 1 second on next visit”

He talked about that we are not succeeding on the mobile web at the moment mostly because our sites are too slow. After watching the video I thought a lot about the past, present and future of the web.

Let’s have a look at the last couple of years in web development.

Responsive Design #

in 2010, Ethan Marcotte wrote about Responsive Web Design. We were *all* excited about it, but also a little bit afraid because we realized that there is more than “Desktop”. We realized that we have to adapt to lots of different situations – browser, screen sizes, input…

More importantly, we realized that websites doesn’t need to look the same in every browser and most importantly, many also thought a lot more about accessibility. We wrongly assumed that *all* users use a keyboard and a mouse. After realizing that, we not only made our sites better usable for touch devices, but also for all other including keyboard and screen readers. As a really nice side-effect, we improved the accessibility of our sites.

In short, Responsive Design brought us better usability and accessibility. Great!

Mobile First – Content First #

In 2009, Luke Wroblewski talked about Mobile First. The core part of Mobile First is that we should focus only on the most important data and actions.

We realized that we should focus on the core part of our site. We realized that we should not bloat our sites with unnecessary content and actions they don’t care about.

In short, Mobile First brought us better content. Great!

Progressive Web Apps #

In 2015, Alex Russell wrote about a new concept, called Progressive Web Apps.

A Progressive Web App should be Responsive, Connectivity independent, Fresh, Safe, Discoverable, Re-engageable, Installable, Linkable and should have App-like-interactions. As you can see, Performance, is not part of the definition, but many techniques behind it will improve the performance of your site.

Some days ago, Jason Grigsby wrote about why The Washington Post’s Progressive Web App increased engagement on iOS?. The short answer is, the Progressive Web App is much faster than the old mobile site. I wouldn’t say that transforming your site into a Progressive Web App automatically makes it faster, but I think many will realize that the performance of their current site is bad and that they should improve it.

In short, Progressive Web Apps brings us better performance. I hope so.

Conclusion #

We are consistently improving and we often have to realize that our assumptions are wrong. The history showed that new approaches often came with positive side-effects. They brought us better accessibility, better content and now hopefully also better performance.

If you want an interactive site in 3 seconds on 3G on an average phone on first visit you probably have to rethink, you have to realize that the phone and computer you own are not representative. We have to realize that most people use *slow* devices on *slow* connections. While we realized that “works on my machine” was wrong, we also have to realize that “fast on my machine” is wrong as well.

We can argue about progressive enhancement forever or we can realize that many parts (server-side rendering on first visit, using appropriate HTML…) give us also the benefit of being fast.

PS: I tried to find the earliest mentions of the different concepts, but may have missed something, so please let me know if it is not correct. Thanks!

My reply to ” Progressive enhancement isn’t dead, but it smells funny” by Nolan Lawson

2016-10-13T15:41:39+02:00

Here is the post, you should read first before reading my thoughts,

This is a cross-post, the content I wrote down here is the same as in the original comment I left on his site.

First of all, thanks for writing down your thoughts. While I agree with some points I also can’t really agree with some.

(Spoiler alert: many top websites do not bother to make their core functionality work without JavaScript.)

Yes, many top websites only work with JavaScript, which I don’t think is a practise we should all follow. At least not, if we define JavaScript as client-side JavaScript and don’t involve sever-side JavaScript. Many big sites are also not optimized, eg https://twitter.com/molily/status/783767319470374916 and, I think you agree here, that we shouldn’t build our sites by following that.

As Jake Archibald pointed out, it’s not really about users who have disabled JavaScript, so who exactly are we helping when we make our websites work without it?

Everyone who uses an ad blocker, which may prevent your JavaScript from running, everyone on a poor connection where the JavaScript takes to long on the first load and many more. It is not about “no JavaScript”, it is about, what happens when the JavaScript doesn’t work for the user.

Offline-first is a form of progressive enhancement that directly targets the baseline experience that a high-quality progressive web app ought to support, rather than focusing on the more reductionist mindset of “first HTML, then CSS, then JavaScript.”

I am all for offline-first (although I don’t really like the term, as it is only true for second visit) but this doesn’t mean we shouldn’t focus on the the core principles of PE anymore. I really like Service Worker for example, one of the reasons why I really like it is that this is a perfect example of PE for me. If a browser supports Service Worker you get a performance boost if done right, if the browser doesn’t support it they will get the same experience as before. Nobody harmed, but some (many more in the future) get an enhanced experience.

My question to Jeremy, however, is: why? Why is it considered an unqualified good to make a website that works without JavaScript? Is it possible that this mindset – “start with HTML, add CSS, sprinkle on JavaScript” – is only a best practice in a world of incapable browsers (such as IE6) hooked up to stable desktop connections, and now that we’re in a world of smart, JavaScript-enabled browsers with unreliable connections, we need to re-evaluate our thinking?

From what I understand, Jeremy doesn’t mean “works without JavaScript”, but rather “render the core content if JavaScript fails”. For me this means, that on first load you should always render the core content server-side (be it static HTML, via PHP or via Node.js). A smart, JavaScript-enabled browser is only smart if the JavaScript works perfectly fine, otherwise the browser is rather dump.

I am all for optimizing for unreliable connections, and rendering the core content server-side on first load will always be faster so why not use this instead of rendering it client-side with JavaScript.

We as a community need to realize that the question of “JavaScript – yes or no?” is less about access and ubiquity, and more about performance and robustness.

Yes, it is about performance and robustness but more important about accessibility and being prepared for failures. And JavaScript often fails and all optimizations won’t help the user in that case as they simple can’t use the site anymore if you are not prepared for that scenario.

To sum up my thoughts:

Render the core part of the site server-side (and of course this can also be done with JavaScript, eg. Node.js) on first view. From there on you can render additional content with JavaScript. And, of course you can enhance the regular links on your site and can use JavaScript to transitions between pages.
Never try to imitate native HTML with JavaScript.
Accessility should always be more important than performance or other constraints.
Use JavaScript, but use it wisely and don’t assume it will always work.
Be nice!

Thanks again for writing this and keep up this nice conversation between different mindsets.

Enhancing a comment form - From basic to custom error message to BackgroundSync

2016-10-10T12:12:04+02:00

When building a web site, sooner or later, you will probably have to implement a form, be it a login form or a comment form. I have done it many times before, and the last time I had to create a comment form, I thought about how far I can enhance it. After adding one enhancement, another enhancement crossed my mind and after implementing that yet another one.

That’s why I would like to show you how you can enhance a form (in this case consisting of an <input> for the name, a <textarea> for the message and a submit <button>) from the most basic version to an EnhancedEnhanced™ Version with BackgroundSync.

Basic Version #

We start with the basic version, a HTML form:

<form action="./" method="post">
	<label for="name">Name</label>
	<input type="text" name="name" id="name">

	<label for="comment">Comment</label>
	<textarea name="comment" id="comment"></textarea>

	<button type="submit">Publish</button>
</form>

This will work in *every* browser. From here we start adding enhancements without breaking the basic version.

Here is a demo of the basic version.

Enhanced HTML version #

The first thing we do is adding an required attribute to our Textarea and as it should never be empty. If the browser supports HTML form validation we get validation out of the box without using JavaScript. We shouldn’t, however, rely on it (not supported browsers, browser bugs, …) so it is always a good idea to validate form values on the server side.

<form action="./" method="post">
	<label for="name">Name</label>
	<input type="text" name="name" id="name">

	<label for="comment">Comment</label>
	<textarea required placeholder="What's on your mind?" name="comment" id="comment"></textarea>

	<button type="submit">Publish</button>
</form>

Next, we add an placeholder attribute as a nice extra touch. Always keep in mind that you should never replace a label with a placeholder, it’s a great enhancement, but not a replacement.

Here is a demo of the enhanced HTML version.

Cut the mustard #

For further enhancements we will use JavaScript. First, we add a cut the mustard test to the <head> of our page. We are using a technique I first encountered in the article Enhancing optimistically by the Filament Group.

if( 'visibilityState' in document ) {
	// include loadJS here...
	function loadJS( src ){ ... }

	// This is a capable browser, let's improve the UI further!
	var docElem = window.document.documentElement;

	// the class we'll use to enhance the UI
	var enhancedClass = "enhanced";
	var enhancedScriptPath = "enhanced.js";

	// add enhanced class
	function addClass(){
		docElem.className += " " + enhancedClass;
	}

	// remove enhanced class
	function removeClass(){
		docElem.className = docElem.className.replace( enhancedClass, " " );
	}

	// Let's enhance optimistically...
	addClass();

	// load enhanced JS file
	var script = loadJS( enhancedScriptPath );

	// if script hasn't loaded after 8 seconds, remove the enhanced class
	var fallback = setTimeout( removeClass, 8000 );

	// when the script loads, clear the timer out and add the class again just in case
	script.onload = function(){
		// clear the fallback timer
		clearTimeout( fallback ); 
		// add this class, just in case it was removed already (we can't cancel this request so it might arrive any time)
		addClass();
	};
}

Custom error messages #

With our feature test in place we will add custom error messages, as “Please fill out this field.” isn’t a really nice message. In our enhanced.js script (which will only be loaded in capable browsers) we add the following to define a custom message:

// set a custom text for the error message
var commentArea = document.querySelector("#comment");

commentArea.addEventListener('invalid', function (e) {
	e.target.setCustomValidity("");
	if (!e.target.validity.valid) {
		e.target.setCustomValidity("Please enter a comment.");
	}
});

commentArea.addEventListener('input', function (e) {
	e.target.setCustomValidity("");
});

In this case we show the message “Please enter a comment” when a user submits the form without a comment. You may have noticed that I haven’t talked about styling the error messages so far. That’s because currently there is now way to style them with CSS. There used to be ::-webkit-validation-bubble for webkit-based browsers, but it has been removed. If you really want to style them you need to build your own validation bubble but be aware that there are many things which may go wrong so I would advise using the default bubbles as they give you all for free.

Here is a demo of the custom error message version.

Ajaxify #

All modern browsers now get a custom error message when the user tries to submit an empty comment, but if they enter a comment the form is still submitted server-side and therefore a page reload is necessary. Let’s enhance it by posting the comment via JavaScript.

// send form data with JavaScript
if( window.FormData) {

	var appendComment = function (nameValue, commentValue) {
		var comment = document.createElement('li');
		var commentName = document.createElement('h4');
		var commentComment = document.createElement('p');
		var commentWrapper = document.querySelector('.comments');
		commentName.innerText = nameValue;
		commentComment.innerText = commentValue;
		nameValue ? comment.appendChild(commentName) : '';
		comment.appendChild(commentComment);
		commentWrapper.appendChild(comment);
	};

	form.addEventListener('submit', function (ev) {
		var formData = new FormData(form);
		commentValue = commentArea.value;
		nameValue = nameInput.value;

		var xhr = new XMLHttpRequest();
		// save the comment in the database
		xhr.open('POST', './save', true);
		xhr.onload = function () {
			appendComment(nameValue, commentValue);
		};
		xhr.send(formData);

		// always call preventDefault at the end, see: http://molily.de/javascript-failure/
		ev.preventDefault();
	});
}

First we check if the browser supports FormData, an advanced XMLHttpRequest feature. If it does, we define a function appendComment() to append the new comment to the other comments. Next, we add and eventListener to our form to make an XMLHttpRequest on submit. If the request was successfull we append the comment. At the very end we call preventDefault to prevent the default behaviour of the form. It is important to call preventDefault at the end as we cannot be sure if the JavaScript might fail.

With that in place, our form ideally submits the comment without page load, but still works for unsupported browsers.

At this point you may wonder why I didn’t use Fetch. The reason is, I wanted to support as many modern browsers as possible without requiring a polyfill or only support the latest browsers.

Here is a demo of the ajaxified version.

Auto-expand the Textarea #

If you want to write a longer comment you currently have to scroll up and down if you want to recheck what you wrote. We can improve this by auto-expanding our Textarea.

For this, we are going to implement a solution I found on CodePen.

commentArea.addEventListener('keydown', autosize);

function autosize(){
	var el = this;
	setTimeout(function(){
		el.style.cssText = 'height:auto;';
		el.style.cssText = 'height:' + el.scrollHeight + 'px';
	},0);
}

With that in place the Textarea now adapts to the length of the comment and makes it easier to check what you wrote.

Here is a demo of the auto-expand version.

Prepare for success, error and poor connection #

So far we added HTML enhancements (placeholder and required attribute), defined custom error messages, ajaxified our form and added auto-expand for the Textarea.

Next, we will enhance the experience by showing when the comment was posted successfully or not and also show an indicator if it takes longer.

<p class="message" id="feedback"></p>
<button type="submit">Publish</button>

First we add a new element to our form to show messages.

var messageElement = document.querySelector('#feedback');
...
form.addEventListener('submit', function (ev) {
...
	xhr.onerror = function (error) {
		messageElement.className = 'message error';
		messageElement.textContent = 'There was an error posting the comment. Please try again.';
	};
	xhr.upload.onprogress = function (evt) {
		messageElement.textContent = 'Uploading: ' + evt.loaded/evt.total*100;
	};
	xhr.upload.onloadend = function (evt) {
		messageElement.className = 'message success';
		messageElement.textContent = 'Your comment was posted sucessfully.';
	};
...

If the comment is not successful for whatever reason we show an error message as defined in the error event, otherwise we show a success message as defined in the loadend event. In the progress event we add an indicator showing how many % of the comment are already uploaded. On fast connections you won’t see the indicator, but if you write a long comment and are on the go using a poor connection this helps to show that there is something happening and that the comment will be uploaded sooner or later.

Here is a demo of the progress version.

Service Worker and BackgroundSync #

Now, that we improved the experience with poor connections let’s enhance the experience for unusable connections.

// check for service worker support
if ('serviceWorker' in navigator) {
	// register the service worker
	navigator.serviceWorker.register('./service-worker.js');

	form.addEventListener('submit', function (ev) {

		let formData = new FormData(form);
		// send message via BackgroundSync
		navigator.serviceWorker.ready.then(function(swRegistration) {

			idbKeyval.set('comment', commentArea.value);
			idbKeyval.set('name', nameInput.value ? nameInput.value : false);
			messageElement.className = 'message info';
			messageElement.textContent = 'It seems you are offline. Comment will be published automatically once you are online again.';
			
			return swRegistration.sync.register('form-post');
		}); 

		// always call preventDefault at the end, see: http://molily.de/javascript-failure/
		ev.preventDefault();
	});

	// event to receive messages send by service worker
	navigator.serviceWorker.addEventListener('message', function(event){
		if (event.data == 'success') {
			messageElement.className = 'message success';
			messageElement.textContent = 'Your comment was posted sucessfully.';
			let nameValue = false;
			idbKeyval.get('name').then(function (data) {
				nameValue = data;
				let commentValue = '';
				idbKeyval.get('comment').then(function (data) {
					commentValue = data;
					appendComment(nameValue, commentValue);
				});
			});
			
		} else if (event.data == 'error') {
			messageElement.className = 'message error';
			messageElement.textContent = 'There was an error posting the comment. Please try again later.';
		}
	});


} else if ( window.FormData) {

First, we check if Service Worker is supported by the browser. If it does, we use BackgroundSync to post the comment, otherwise we will post the comment via an XMLHttpRequest as shown above in the Ajax version.

Let’s have a look at the code and what it does. On submitting the form we save the value for the name and comment in IndexedDB. In my case I am using a helper, a promise-based keyval store implemented with IndexedDB by Jake Archibald. We will also show a message that you are offline and the comment will automatically be published once you are online again. You won’t see this message when you have an usable connection and the form can be published immediately. Finally, we register a BackgroundSync with the tag “form-post”.

Next, we define an EventListener which checks for messages coming from the Service Worker to show if the comment was posted successful or not.

Now, let’s have a look what our service-worker.js looks like.

importScripts('idb-keyval.js');

const VERSION = 'v1'

self.addEventListener('install', function(event) {
	self.skipWaiting();
	event.waitUntil(
		caches.open(VERSION).then(function(cache) {
			return cache.addAll([
				'./',
				'./index.html',
				'../style.css',
				'enhanced.js'
			]);
		})
	);
});

self.addEventListener('fetch', function(event) {
	let request = event.request;
	if (request.method !== 'GET') {
		return;
	}
});

self.addEventListener('activate', function(event) {
	if (self.clients && clients.claim) {
		clients.claim();
	}
});

self.addEventListener('sync', function(event) {
	if (event.tag == 'form-post') {
		event.waitUntil(postComment());
	}
});

function postComment() {

	let formData = new FormData();

	idbKeyval.get('name').then(function (data) {
		formData.append( "name", data );
	});
	idbKeyval.get('comment').then(function (data) {
		formData.append( "comment", data );
	});

	fetch("./save",
	{
		method: "POST",
		mode: 'cors',
		body: formData
	})
	.then(function(response) {
		return response;
	})
	.then(function(text) {
		send_message_to_all_clients('success');
	})
	.catch(function(error) {
		send_message_to_all_clients('error');
	});
}

function send_message_to_client(client, msg){
	return new Promise(function(resolve, reject){
		var msg_chan = new MessageChannel();

		msg_chan.port1.onmessage = function(event){
			if(event.data.error){
				reject(event.data.error);
			}else{
				resolve(event.data);
			}
		};

		client.postMessage(msg, [msg_chan.port2]);
	});
}

function send_message_to_all_clients(msg){
	clients.matchAll().then(clients => {
		clients.forEach(client => {
			send_message_to_client(client, msg).then(m => console.log("SW Received Message: "+m));
		})
	})
}

Here, we first import the promise-based keyval store we also used in the enhanced.js to handle IndexedDB. Next, we define a const for the cache version and add functions to handle the install (add assets to cache), fetch (handle requests) and activation events. The relevant part starts with the sync version. Here, we first check if the tag is “form-post”, as it is the one we registered before in enhanced.js with swRegistration.sync.register('form-post'). If the tag matches, we call event.waitUntil(postComment());. This means that postComment will be executed as soon as there is an usable connection.

In our postComment function we define a new FormData and append the values for the name and comment which we get from IndexedDB. Next we use fetch to save the comment. When the comment was posted we will send a message back to the page to show an success/error message.

With that in place, the comment will now always be posted. If you are online it will be send straight away and if you are offline it will send as soon as you have an usable connection again, even if you already closed the page with the form.

Here is the demo of the EnhancedEnhanced™ version.

Note: if you want to test the offline functionality of the final version, please be aware that there is currently a bug in Chrome and using the “offline mode” in DevTools doesn’t work. You have to really go offline to test it.

Conclusion #

As you can see there are many ways to enhance a form and there are various other possible enhancements I didn’t mention. There are many ways to enhance it with CSS, which I didn’t mention at all here, but also many more ways to enhance via JavaScript. The great thing is, by using progressive enhancement *every* browser is supported. Some get a better experience than others, but all are able to perform the task of posting a comment.

Only a few people will get the EnhancedEnhanced™ version, but under certain circumstances every single of them may only get the basic version.

Here is the final demo of the EnhancedEnhanced™ version.

If you have any improvements or found a bug in the code please open an issue on Github.

Ways To Reduce Content Shifting On Page Load – article for Smashing Magazine

2016-08-29T13:00:06+02:00

My first article on Smashing Magazine got published 🙂

Read the original article on Smashing Magazine

Progressive enhancement all the things

2016-08-23T13:49:13+02:00

I am currently working on a project where I have to build an interactive graph to accompany some content (text, images). I made sure it is accessible, but what if the JavaScript fails (an error in our JavaScript, connection timeout or because of another reason? For the last few days I wondered if I should make the content of the graph somehow available if the JavaScript fails or if the graph is not part of the core content and therefore an enhancement.

What is the core part of my page? #

In this case we decided that the graph is not part of the core content and can fail in certain cases. More precisely, we decided to show the graph only if the browser is capable of doing so (Opera Mini and other proxy browsers are not) and also to hide it if the JavaScript fails.

Today, the client came back to us and decided that this graphs should also be available via an extra page where only the graphs are shown. Great, now the enhancement is clearly the core.

Conclusion #

When a user opens your site and sees nothing, you either have no content or you are doing it wrong. Apart from that, it is not always easy to decide which parts are an enhancement and which parts belong to the core of a site.

What I like to do is removing all the enhancements and see if the site still makes sense and is usable. If not, the enhancement should be part of the core experience.

How do you decide if something is an enhancement or part of the core experience?

Indicating offline

2016-08-18T05:25:25+02:00

Developers have been able to make a site available for offline usage for some years using Application Cache, but it has some downsides and hasn’t been really popular.

With the raise of Progressive Web Apps, and more and more sites using, and browser implementing Service Workers we will see a lot of sites being “ready for offline” in the upcoming months and years.

Many users don’t know that websites can also work offline like native Apps. If a user doesn’t have an internet connection they assume a website won’t work and that’s why I think it is important to indicate that the site/app will work offline and also which parts are only usable when online.

Tell the user that the site works offline #

When a user visits your site for the first time, and you have implemented a Service Worker to make it “offline-ready” we can show the user a message saying that “The site is ready to work offline”.

Ready to work offline message (Screenshot from SVGOMG)

To do this, we listen to the statechange event and if the ServiceWorker.state is activated show the message. This way the message will only be shown on first registration and we don’t annoy users with showing it on every page load.

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('sw.js').then(function(registration) {
    // Registration was successful
    
    var newWorker = registration.installing;
    
    // statechange fires every time the ServiceWorker.state changes
    newWorker.onstatechange = function() {
      // show the message on activation
      if (newWorker.state == 'activated' && !navigator.serviceWorker.controller) {
        document.querySelector('.offline-ready').classList.add('active');
      }
    };
  }).catch(function(err) {
    // registration failed :(
  });
}

In the future users may expect a site to work offline after visiting again, but until this happens, I think it is a good idea to let the users know about this feature.

Tell users that they are offline/online #

Some things, like every network request for new stuff, will never work when offline.

We can use online and offline events to indicate to a user that they are currently offline or online again.

window.addEventListener('load', function() {
  function updateOnlineStatus(event) {
    var condition = navigator.onLine ? "Live" : "Currently offline";

    document.querySelector('.connection').innerHTML = condition;
  }

  window.addEventListener('online',  updateOnlineStatus);
  window.addEventListener('offline', updateOnlineStatus);
});

Let’s say we have a live ticker which gets updated automatically when new content arrives. If the user is online, we can show “Live” to indicate that new content will be shown automatically. If the user is offline on the other hand we can show the message “Currently offline” to point out that the live ticker won’t update until the user is online again.

Grey-out things not available offline #

Some areas of a site/app won’t work when a user is offline because we don’t have a cached version yet. To find out which parts are already cached we can use the Cache API, which is available in Web Workers, Window and Service Workers in supported Browers.

First, we register a Service Worker if it is supported.

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('service-worker.js');
}

Next, we switch to our service-worker.js. I am using the sw-toolbox here. If the request contains “article-” we store the response in the cache with the name “articles” which we later can use in our window.

// match every request ending with download
global.toolbox.router.get(/article-/, global.toolbox.cacheFirst, {
  // Use a dedicated cache for the responses, separate from the default cache.
  cache: {
    name: 'articles',
    // Store up to 10 articles in that cache.
    maxEntries: 30
  }
});

Back to our main site, where we first check if the cache API is supported. If it does, we loop over each link on our site and if the value of the href is present in the cache with the name “articles” we add the class “available-offline” to the link.

// check if the cache API is supported
if('caches' in window) {

  // forEach for NodeList
  NodeList.prototype.forEach = Array.prototype.forEach;

  // loop over each link and add class "available-offline" if src is already in cache
  var downloadLinks = document.querySelectorAll('a').forEach(function(el) {
    caches.open('articles').then(function(cache) { 
      cache.match(el.getAttribute('href')).then(function(matchedResponse) {
        if (matchedResponse) {
          el.classList.add('available-offline');
        }
      });	
    });
  });
}

Next, we add EventListener for the online/offline events to add/remove the class “is-offline” to our html element and also add the hint Offline/Online for our users.

// add "is-offline" class to the html element if user is offline and remove when online again
window.addEventListener('load', function() {
  function updateOnlineStatus(event) {
    if (navigator.onLine) {
      document.documentElement.classList.remove('is-offline');
      document.querySelector('.connection-status').innerHTML = 'Online';
    } else {
      document.documentElement.classList.add('is-offline');
      document.querySelector('.connection-status').innerHTML = 'Offline';
    }
  }

  window.addEventListener('online',  updateOnlineStatus);
  window.addEventListener('offline', updateOnlineStatus);
});

Next, we add some styles. If the user if offline and the class “is-offline” is present at the html element we grey-out all links expect for the links we already have cached and which we gave the class “available-offline” in the code part above. We will also remove the pointer cursor and add a default one for all links not working offline to give users one more hint that these links will not load as expected.

.is-offline a {
  color: grey;
  cursor: default;
}

.is-offline .available-offline {
  color: black;
  cursor: pointer;
}

If you want to try it yourself, here is a demo and the code is on Github.

Conclusion #

I think we still have a long way to go until “offline-ready” won’t be a feature, but the standard way of serving websites. And it will take time to educate users that websites can work offline like native Apps. Someday, users may assume that a website works offline on repeated visits and you don’t want to have one of the websites not ready, so it is a good idea get yourself comfortable with Service Workers and the cache API.

Progressive web apps – let’s not repeat the errors from the beginning of responsive web design

2016-06-07T03:51:41+02:00

6 years ago, Ethan Marcotte published the article Responsive Web Design. It was a new concept, it was exciting, we all needed to learn how to adapt responsive design for our sites, we all made a lot of mistakes by doing so and are still learning.

Now, in 2016, there is a new term – Progressive Web Apps (PWA) – a “umbrella” term for responsive, connectivity independent, fresh, safe, discoverable, re-engageable, installable, linkable Apps/web sites with app-like interactions. Once again, we all need to learn how to integrate the concept of PWA’s, we need to find out what makes sense for our sites and we need to discuss and exchange a lot – we need to avoid the errors we made at the beginning of responsive web design.

iphone.css #

When people learned about responsive design, there were many wrong assumptions. The iPhone and early Android phones *all* had the same screen size (320x480px) and people thought it is a good idea to change the design based on these device-specific sizes. Some even named the css iphone.css :-(.

@media only screen 
and (min-device-width : 320px) 
and (max-device-width : 480px) 
and (orientation : portrait) { /* Styles for iPhone in portrait mode */ }

I never want to see that again. Device specific CSS, for i*-only. A nightmare nobody should wake up to anymore.

Beyond Responsive #

After my first experience with responsive design, I realized that designing and programming for specific devices is a No-Go. None of my first attempts made it into a production-ready site, but many others did. Nowadays, most people use mobile-first and add a media query if the design “breaks”. Great.

If I think about responsive now, it means much more than media queries and flexible content. While working on responsive sites my awareness for accessibility, performance, content and people increased more and more. I realized that a responsive web site is useless if you forget about accessibility and performance. I prefer a fast and accessible site which doesn’t adapt the design to screen sizes over an overloaded, inaccessible, responsive web site every time.

The same goes for Service Worker, while I first thought it is only about offline, I realized it is a lot more about performance and a way to make sites more accessible and better usable.

Be progressive – not only name it progressive #

A progressive web app – being responsive, connectivity independent, fresh, safe, discoverable, re-engageable, installable, linkable Apps (basically web sites) with app-like interactions is fantastic, but there is one word in there we should never forget; Progressive.

I understand that it is hard to sell progressive enhancement, so I think naming them Progressive Web Apps is great. My hope is that many more people will make progressive web sites. That clients will say: “Can you please make our site progressive”. That progressive enhancement is not only a term anymore, but the way everybody wants their site to be.

Progressive web apps are an opportunity #

We are still at the beginning of learning about the best ways to build Progressive Web Apps. I hope it will make many more people aware of progressive enhancement. I hope that nobody makes the error again and concentrates on the device part. Responsive design changed my way of building sites, I now think a lot more about the content, a lot more about accessibility, a lot more about performance and a lot more about people. I hope building PWAs will make a lot more people aware of the “basics” of the web.

Let’s not make the same errors again. A PWA which only works for specific devices is wrong. Let’s build Progressive Web Apps where we concentrate on the progressive part and not on the app part.

Google to reward sites with service worker (offline ready) in search rankings

2016-04-22T09:29:35+02:00

While this headline is not true now (April 2016) it may be a headline of the near future. This morning one of my clients asked for switching to https for their site. I tried to convince many clients, including this one, over the last years to use https for all their sites saying that it will prevent many security and privacy issues, users will have more trust in a https site and so on; They didn’t really care. At least not until Google announced to reward sites with https in search rankings. From that moment they all wanted https and they also didn’t care how much it would cost them anymore.

Interesting but also sad to see that many web site owner only switch to https because they heard Google will prioritize them in search.

— Michael Scharnagl (@justmarkup) April 22, 2016

SEO, SEO, SEO, SEO #

I have many clients who tell me regularly that they got a call or even visit from a “SEO Expert” who tries to sell them something so their sites will get a better Google ranking. Most of the advices they want to sell them are completely irrelevant (Use exactly 12 keywords per site) or even very bad (eg. Don’t use more than 3 headlines per site). Aside from that, whenever Google announces to reward sites using a specific technology they say them they have to use this technology now or they will get a worse ranking.

This happened when Google announced to reward mobile-friendly (responsive) sites, this happens now as Google rewards sites using https and it will happen in the future with other technologies like service workers.

And, this makes me a bit sad.

All of these website owners don’t care about the user, all they care about is a top rank in the search results. They don’t care if users are surfing the web on different devices and want to have a great experience with the site on all of them, they don’t care about security or privacy, they don’t care about performance or making the site “offline-ready”. You can tell them all the time about the benefits of a responsive website, about a secure website; They don’t care. However, they care immediately when this will affect their page rank.

The power of Google #

Google, as a search engine has a lot of power. In Germany more than 90% are using Google search and every web site owner wants to be on top of the search results. If tomorrow, Google would announce that they will reward all sites passing an accessibility check, all the “SEO experts” will throw away their old advices and will tell clients, to make this and this, to make it pass the accessibility test. All the site owners will call their web master (or Web Ninja or whatever the cool kids say today) and tell them their site has to pass the test.

Even if the clients don’t ask for it I try to make every site as much accessible as possible – I would feel bad otherwise. Many other don’t feel bad obviously and that’s why we have a lot of inaccessible sites – if Google would penalize these sites we would probably have a lot more accessible sites.

So, yes I think, Google will reward sites using service worker in the near future as they really want to push progressive web apps and “offline-ready” sites and with rewarding such sites, many many sites will do so.

Add to homescreen and the app banner

2016-04-09T11:44:42+02:00

Note: Some of the information in this article is outdated, for latest info see this article on developers.google.com

Last week I wrote about discoverability of progressive web apps and as part of this I also thought about current ways a site gets promoted as an app by browsers.

In Chrome for Android there will be shown an app banner for your site to engage users to add the site to the homescreen. The app banner will only be shown if the site meets certain requirements and if a user visits the site regularly, where regularly (at the moment) means at least two visits with five minutes apart. (Note: The time frame already changed over time and may change again)

Requirements #

To get the app banner with the “Add to homescreen” dialog for your site it needs to meet some criteria. The site needs a valid manifest, a service worker and the site has to be served over https.

Manifest #

First you need a valid manifest for your site. To integrate the manifest you need to link to it via a meta tag with the attribute manifest:

<link rel="manifest" href="/manifest.json" />

Here is an example of a manifest:

{
  "short_name": "Short Name",
  "name": "The long name of the app",
  "start_url": "./",
  "icons": [
    {
      "src": "/images/icon-128x128.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/images/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {  
      "src": "/images/icon-256x256.png",  
      "sizes": "256x256",  
      "type": "image/png"  
    }, 
    {
      "src": "/images/icon-384x384.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "/images/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "background_color": "#FFFFFF",
  "theme_color": "#AA0F0F",
  "display": "standalone",
  "orientation": "portrait"
}

From some testing it seems you need at least an icon with 192×192 to get the app banner, but I would suggest to also add at least the 384×384 and 512×512 icons.

128dp at 1x (160dpi) = 128px
128dp at 1.5x (240dpi) = 192px
128dp at 2x (320dpi) = 256px
128dp at 3x (480dpi) = 384px
128dp at 4x (640dpi) = 512px

* dp = density-independent pixels and dpi = pixels per inch

Read more about the ideal sizes on developers.google.com/.

Service Worker #

You also need a Service Worker to get the app banner. As Service Worker also requires TLS your site also needs to be served over https, which it should anyway.

Testing #

To test “Add to homescreen” open Chrome and Devtools. Next activate the Device Mode (Ctrl + Shift + M) and open the menu on the top right of the screen. Click “Request app banner…” and you will get a dialog to add the site to the shelf (Desktop). If you don’t get the prompt have a look in the console. For example, if the icon is not suited you will get the following message: “App banner not shown: manifest does not contain a suitable icon – PNG format of at least 144x144px is required, and the sizes attribute must be set”.

If you don’t see the “Request app banner…” entry, try the following:

* Update Chrome to the latest version
* Enable the flag for “Devtools Experiments” chrome://flags/#enable-devtools-experiments and restart Chrome
* Enable the option “App banner support” in Devtools -> Settings -> Experiments (If you don’t see it, press Shift six times there to get all experiments)
* Enable the flag for “Add to shelf” chrome://flags/#enable-add-to-shelf

There is also a Manifest Validator to test your Manifest and find potential errors.

One of the most asked question is if it is possible to show the app banner on user interaction. In short, NO. The long answer is that it is and will probably never be possible, mainly because of the fear of abuse. You may all remember the pop-ups we saw on iOS and also Android to show users how to add the site to the home screen. This can be really annoying and therefore browser vendors try their best to only show the app banner if a user is likely to visit the site again and therefore has the need for an extra icon on the homescreen.

I also would like to have the option to trigger the app banner on user interaction, but I fully understand that this would lead to every site doing it. After some time, most users will be annoyed by all the prompts and will think only negatively about app banner. That’s why we better leave it to the browser when to show the app banner.

Bottom line #

If your site meets all the requirements and a user visits your site regularly you will get the automatically shown app banner. As far as I know the app banner is only shown on Chrome for Android at the moment (April 2016) but I am sure other browsers will add something similar in the future. If you build a progressive web app be sure to test if you meet all the criteria.

Discoverability of progressive web apps

2016-04-05T13:27:52+02:00

Today I was curious to find out if there is a photo editor I could use in my browser. My requirements are that it should work offline, be responsive and progressive – so basically a progressive web app (pwa).

404 – not found #

My first try was to google for “photo editor web app” but none of the “apps” shown there met my requirements. Next, I tried to change the keywords to get a result, but after 372332 a lot of attempts I figured out that either there is no such web app or I miss anything. At that point I wanted to give up when I discovered the “Apps tab” hidden under “More” – I had hope for a moment to have found a way until I saw that there are only “native apps” listed.

Next, I remembered that there are sites which list web apps. While I like to surf on these sites and see what great web apps are available it doesn’t really help if you search for an app for something specific. Also, at the moment there are only a few progressive web apps, but what if there are millions of them next year – nobody will be able to keep such a site up-to-date.

Search engines, please! #

I don’t know a lot about how search engines index web pages, but it shouldn’t be that hard to check if the web page has a manifest, runs over HTTPS, uses a service worker (checking for offline may be harder) and tag the page as “progressive web app”.

This image shows a screenshot of the google search, after searching for “photo editor” and switching to the “Apps” tab. Now, imagine if a web page was tagged as “pwa” it would be shown there – this would solve the discoverability. Furthermore, there is already a filter to search for OS, Google could easily add Web here to filter only progressive web apps.

I talked about the Google search engine here the whole time, but this could be the same for every search engine, be it Bing, DuckDuckGo or Yahoo!. This way we don’t need a centralized site/store but the user can decide which way they prefer to search.

CSS containment

2016-04-05T08:04:11+02:00

I haven’t heard about the contain property until some weeks ago when I asked about use cases for container queries on twitter and David Baron mentioned it in a response saying that contain: strict; can avoid many of the theoretical problems of container queries. Since then I read the specification and everything I found about it trying to understand it; Here is what I learned.

The contain property #

It’s a primitive for isolating style, layout, and paint. The contain property allows developers to limit a specific DOM sub-tree and the rest of the document; You can think of it like an iframe. Much like an iframe, this boundary establishes a new layout root, ensuring that DOM changes in the sub-tree never trigger reflows in the parent document.

The contain property allows an author to indicate that an element and its contents are, as much as possible, independent of the rest of the document tree.

— From the W3C Specification

none | strict | layout | style | paint | size | contain #

There are seven different values for the contain property.

none no effect
layout turns on layout containment
style turns on style containment
paint turns on paint containment
size turns on size containment
content all, except size containment
strict layout, style and paint combined

Use cases #

So far we know that by using CSS containment we can isolate elements from the rest of the document to mark them as independent parts. To show you where this can be helpful here are some use cases:

Widgets #

When integrating third-party widgets you mostly don’t have much control and they can decrease the site performance dramatically by doing expensive layout, style or paint operations. To make them independent from our site we can set contain: strict; for the most outer element of the third-party widget. This way, they won’t affect the performance of all the other parts of the page.

Off-Screen #

If you build a off-screen navigation or similar, the browser paints the content completely although it is not visible on load. By setting contain: paint; the user agent can skip the paint off the off-screen element and therefore paint all the other content faster.

Container queries #

As I already mentioned in the beginning, contain: strict; can avoid many of the problems of container queries. One of the “problems” of container queries is that the children and their content can have an effect on the size of the container. This can be avoided by using CSS containment.

Why can’t the browser do it automatically #

Browser engines already make a lot of optimization under the hood when possible, but each engine has its differences. Using containment provides a standard way for applications to indicate to the user agent that it can optimize certain layout cases, which browser would otherwise not be able to optimize.

Bottom line #

If you build simple sites without tons of DOM nodes and widgets you probably don’t have to care about CSS containment. On the other hand, if you build more complex sites CSS containment will help to optimize the performance. It is also a good idea to set contain: strict; for third-party widgets to protect the performance of your site.

As always – test, test and test again. And not only test with fast network on a high-end machine, but test with old hardware and slow network. To get an idea how otheres experience your site you can also emulate the network speed and the CPU with Chrome Devtools.

Note: At the moment (April 2016) it is only supported in Chrome.

Update 06.04.2016: You need to turn on the flag chrome://flags/#enable-experimental-web-platform-features in Chrome at the moment to test CSS containment.

Update 20.05.2016: Now enabled by default in Chrome 52

Update 02.08.2016: Added the values “size” and “content” from the last update from the specification

On browser support

2016-03-22T09:17:52+01:00

*Every* time a new platform feature gets announced/implemented it doesn’t take long until people moan about not being able to use it because of the poor browser support. Shortly after people will blame browsers for not implementing the feature right away. Accompanied by complaints that the web sucks, browsers are stupid, specifications are **** and other useless statements. If you want a feature to be implemented in a browser – write about it, explain why you need it, prepare use cases, help finding bugs – be helpful and not another troll.

We can’t use feature X because it is not supported in browser Y. “By too many developers”

For me, a web platform feature falls into one of these categories:

Use as an enhancement
Use with fallback
Use with polyfill
Wait

Use as an enhancement #

A lot of new web platform features can be used straightaway when used as an enhancement. CSS transitions, border-radius, box-shadow, @font-face, form validation, Geolocation, Service Worker, new input types, – to name a few – can all be used as an enhancement. Where enhancement means that you don’t need any fallback or polyfill. If the feature is not available, the site still works, but may not look as fancy, or may not offer the “little helper” other users with other browser will see/get; That’s totally fine.

Use with fallback #

Other features can be used with a fallback. Be it new CSS color values, SVG or Gradients.

p {
    color: #111; 
    color: hsl(236, 100%, 4%);
}

Use with polyfill #

Most of ES5/ES6 can be used with a polyfill. Same for requestAnimationFrame or Drag and Drop. You should however be aware that polyfills can reduce the performance and therefore should not be used extensively.

For me, this means I rather use a fallback to make it usable and accessible for these users instead of slowing their browsers with massive use of polyfills. For example: For audio or video you could also add a polyfill, although I would recommend using it as an enhancement and provide simple links to the files as a fallback.

Wait #

Some features get implemented by one browser before there is a *final* specification or a consent between browser vendors. Sometimes they are only available behind flags or only usable with prefixes. If you can/want to use it as an enhancement you may still use it, but you should be aware that the syntax will probably change in the future or that the feature will be removed after some time.

Every browser vendor has a web platform status page nowadays where you can see how likely a browser will implement a feature. If all but one browser are very skeptical about a feature you may better wait before implementing the feature.

Bottom line #

Today, I am defining browser support for modules and not for the whole page. Just because a browser doesn’t support feature X it doesn’t mean we have to stop people from using our site.

And, yes I know there are cases where this is hard – if you build a game with WebGL and the browser doesn’t support WebGL you can’t really do anything, but you should still show the intro (what is the game about, a video/screencast about the game…) which is probably in HTML anyway and show a hint for users without WebGL so they can decide if they are willing to switch/update the browser. If you show a *warning” before showing any content users will most probably never come back to your site.

Use cases for container queries

2016-02-20T14:40:49+01:00

Container queries – formerly known as element queries – are one of the features I really want to see implemented in 2016. That’s why I would like to show some use cases for container queries.

Note: I use the CSS-Element-Queries Polyfill for all demos here, as it supports only min-width, min-height, max-width and max-height (which the native solution will probably also do) and is pretty well tested. I added links to other polyfills at the end of the article. Also, the syntax used by the polyfill will be different from the final solution.

Modular components #

The ideal responsive website is a system of flexible, modular components that can be repurposed to serve in multiple contexts.
Mat Marquis on A List Apart

Using media queries we need to check a module in very area of the site in different screen sizes and add a breakpoint every time the design *breaks*. By using container queries on the other hand the module is independent from the viewport size and we could define styles and container query breakpoints once based on the container size and reuse it everywhere.

Let’s start with a demo of a Login form. This may be used in various areas of a site, be it the header, the sidebar or the main area. In this demo the input fields are among each other on narrow screens and next to each other on bigger (> 600px) screens.

form[max-width~="600px"] label,
form[max-width~="600px"] input[type="submit"] {
    margin: 0.6em 0 0.2em 0;
    display: block;
}

Demo and Code

Product items #

Next, we have a list of items – in this case products. On narrow screens they are shown among one another, if the container size is between 600px and 800px they are still among one another, but the image floats and the headline and text are shown alongside and if the container size is bigger than 800px the items are shown next to each other. By using container queries we can use the product list everywhere on our site and only need to define container breakpoints once – using mediaqueries we would have to use new breakpoints for every new context.

.products ul {
    margin: 0;
    padding: 0;
    list-style: none;
    display: flex;
    flex-wrap: wrap;
}

.products[min-width~="600px"] img {
    width: 50%;
    float: left;
    margin: 0 2em 2em 0;
}

.products[min-width~="800px"] ul {
    display: flex;
    flex-wrap: nowrap;
    justify-content: space-between;
}

.products[min-width~="800px"] li {
    width: 32%;
}

.products[min-width~="800px"] li:nth-child(1):nth-last-child(1) {
    width: 100%;
}

/* two items */
.products[min-width~="800px"] li:nth-child(1):nth-last-child(2),
.products[min-width~="800px"] li:nth-child(2):nth-last-child(1) {
    width: 49%;
}

.products[min-width~="800px"] img {
    width: 100%;
    float: none;
    margin: 0;
}

Demo and Code

Widgets #

Another use case will be widgets, mostly third-party widgets. Think about advertising, social media buttons and widgets, community widgets (comments, forum) or all sorts of forms. When building a third-party widget you never know in which context the code will be integrated, which makes it pretty hard to deliver a responsive version. With container queries developers will be able to react to the surrounding container and deliver a great looking version in every possible case.

Third-party iframe #

Here is an example of a third-party iframe we use in different parts of our website, in this case once in the main area and once in a sidebar. The developer of the widget here changes the background-color of an element from blue to red for narrow (=< 300px) containers.

div {
    background-color: blue;
}

div[max-width~="300px"] {
    background-color: red;
}

Demo and Code

Advertisement #

Next is an example of an advertisement, inserted into our page with JavaScript. Within the JavaScript of the ad a stylesheet gets inserted, with some styles for the ads. Using container queries the developer changes the font-size from 1em to 1.4em if the container is bigger than 500px.

.ad {
    font-size: 1em;
}

.ad[min-width~="500px"] {
    font-size: 1.4em;
}

Demo and Code

Responsive images #

Wouldn’t it be great if you could define sizes based on container sizes instead of viewport size, I thought so too, but it seems impossible. Yoav Weiss told me:

`sizes` can’t be based on layout info, since it’s needed before. EQ based images would have to suffer some delay.

Which makes sense after thinking about it, the browser don’t know the size of the container until the layout is *ready* and therefore it would take some time until the browser can decide which image should be shown.

We most likely won’t get container based sizes, but one never knows. So, I made an example nevertheless using the pollyfill to show the benefits.

<div data-responsive-image>
    <img data-src="http://lorempixel.com/350/150/sports/350x150/">
    <img min-width="350" data-src="http://lorempixel.com/700/300/sports/700x300/">
    <img min-width="700" data-src="http://lorempixel.com/1400/600/sports/1400x600/">
</div>

Demo and Code

Problems and Questions #

When creating all the demos here I also had the idea for a navigation which items change from among each other to side by side if they all fit in one line. It did this by setting a container breakpoint if the nav is higher than 80px and therefore spreads across two lines. If this is the case, the nav items will all be among one another. Using the pollyfill this worked somehow, meaning you would get the right design onload and if you resize from big to small. But it won’t work when resizing from small to big, as the nav will always be higher than 80px. I don’t really know how this could be solved, but maybe you do – here is the demo?

Yes, there are a lot of questions to be asked and a lot of problems to be addressed, but I am still very optimistic we will see a first draft of container queries by the end of the year.

Demos #

Here is a list of all demos, also available on Github.

Pollyfills (incomplete list) #

CSS-Element-Queries Polyfill by Marc J. Schmidt
Elementary by Scott Jehl
ElementQuery by Tyson Matanich
EQ.js by Sam Richards
Prolyfill for CSS Container Queries by Martin Auswöger

Theme switcher using CSS custom properties

2016-02-15T11:37:45+01:00

CSS custom properties have been around for a while now and are currently supported in three browser engines (as of February 2016). When I first heard about CSS variables I was skeptical as I thought they will offer the same functionality as variables in pre-/post-processors. Some month later I stumbled across the spec and was pretty excited to find out that they are not really variables, but rather properties which are dynamic and scoped to the DOM. To show this in action I build a simple theme switcher demo.

Feature detect #

As we will use JavaScript to modify custom properties, the first thing we do is adding a detect to decide whether we will show the theme switcher or not.

if (window.CSS && window.CSS.supports && window.CSS.supports('--a', 0)) {
	// CSS custom properties supported.
} else {
	// CSS custom properties not supported
}

Setting custom properties in CSS #

Next we define some custom properties in our CSS. Here we have a –baseColor, –brandColor and –bgColor which we will use for various elements later in the CSS.

:root {
	--baseColor: #111;
	--brandColor: green;
	--bgColor: #eee;
}

h1 {
	color: green; /* provide fallback */
	color: var(--brandColor);
}

Modifying custom properties with JavaScript #

When selecting a theme we will change the properties with JavaScript, as shown here:

var root = document.querySelector(':root');
var htmlStyle = window.getComputedStyle(root);
htmlStyle.getPropertyValue('--baseColor');  // get the custom property --baseColor
root.style.setProperty("--baseColor", "red"); // set --baseColor to red

Full example #

Here is the HTML of the theme switcher, which is hidden by default and will be set to visible once the feature detect above returns true.

<label id="theme-changer" hidden>
	Choose theme
	<select name="theme" id="theme">
		<option data-baseColor="#111" data-bgColor="#eee" data-brandColor="green" value="default">default</option>
		<option data-baseColor="#444" data-bgColor="white" data-brandColor="#222" value="light">light</option>
		<option data-baseColor="white" data-bgColor="black" data-brandColor="#eee" value="dark">dark</option>
	</select>
</label>

Here is the full JavaScript for the theme switcher. As you can see I also save the current chosen theme in localStorage so users will get the selected theme on future visits.

// test for localStorage support
var hasLocalStorage = function () {
	var mod = 'a';
	try {
		localStorage.setItem(mod, mod);
		localStorage.removeItem(mod);
		return true;
	} catch (e) {
		return false;
	}
};

// test for CSS custom properties support
if (hasLocalStorage() && window.CSS && window.CSS.supports && window.CSS.supports('--a', 0)) {

	var themeChanger = document.querySelector('#theme-changer'),
			root = document.querySelector(':root'),
			themeInput = document.querySelector('#theme'),
			currentTheme = {
				baseColor: localStorage.getItem("baseColor") || '#111',
				bgColor: localStorage.getItem("bgColor") || '#eee',
				brandColor: localStorage.getItem("brandColor") || 'green'
			},
			selectOption;


	// show the theme changer
	themeChanger.classList.remove('hidden');
	themeChanger.removeAttribute('hidden');

	// change colors and save to localStorage
	themeInput.addEventListener('change', function (e) {

		// get selected option
		selectOption = this.options[this.selectedIndex];

		// change values to current theme
		currentTheme = {
			baseColor: selectOption.getAttribute('data-baseColor'),
			bgColor: selectOption.getAttribute('data-bgColor'),
			brandColor: selectOption.getAttribute('data-brandColor')
		};

		// change values of custom properties and save to localStorage
		for (var key in currentTheme) {
			root.style.setProperty("--" + key, currentTheme[key]);
			localStorage.setItem(key, currentTheme[key]);
		}
	});

	// set theme to previous choosen one
	window.onload = function(e) {

		// set option of current theme to selected
		document.querySelector('[data-baseColor="' + currentTheme.baseColor + '"]').selected = true;

		// get values of custom properties and apply
		for (var key in currentTheme) {
			root.style.setProperty("--" + key, currentTheme[key]);
		}
	}

} else {
	// CSS custom properties not supported - don't show the theme switcher
}

You can find the full demo here and the code is also available on Github.

Update 20.02.2016: Change styles based on different className #

As Tomáš Kapler points out in the comments you could also change the html class with JavaScript and change the properties based on the className:

:root {
	--baseColor: #111;
	--brandColor: green;
	--bgColor: #eee;
}
:root.light {
	--baseColor: #444;
	--bgColor: white;
	--brandColor: #222;
}
:root.dark {
	--baseColor: white;
	--brandColor: #eee;
	--bgColor: black;
}

Here is a demo using this method.

Conclusion #

As you can see, you can already use CSS custom properties as an enhancement today, but you should always provide a fallback and be careful when using them. If you only need static and lexically scoped variables you are probably better of by using a preprocessor until more browsers support custom properties.

This should be really easy to implement

2016-02-05T16:50:21+01:00

Some time ago I wrote about why I think every browser should show the alternative text while images are loading. I opened issues for every major browser engine and was looking forward to hear positive replies as I was really sure there couldn’t be a negative aspect about it. Some kindly people replied, said they already tested it and the user experience was not improved, pointed me to edge cases I haven’t thought about and made me rethink. It’s one of the cases where I say to myself “Hey, this should be really easy to implement” without thinking about the whole picture.

There is no easy #

At a first glance many things look easy to implement/fix, but in the end it is probably not easy, but really hard. So before you shout “Implement this now, that’s easy” make sure you really thought about all possible use and egde cases. I also have been complaining about browsers not implementing a feature, often because I needed the feature for a special use case right now and thought everybody wants this and it shouldn’t be more than a day of work for an engineer to implement it. I have to say I was wrong every single time. If you really want to have a feature implemented do a lot of research first: What’s the use cases for the feature? Are there any edge cases which makes it hard/impossible to implement? Do other people also want this feature or is something you probably only need now for the current project you are working on?

Thanks to everyone working on browsers; Thank you!

Rethinking setting class=”js” to hide elements if JavaScript is available

2016-02-01T14:38:11+01:00

Last month a client reported an issue with their website, saying that the navigation isn’t working on his new iPhone 6s Plus. After getting all browser details, I started to reproduce the error, but neither on my iPad with an identical iOS and Safari version nor on any emulator on browserstack.com the error occurred. So, I arranged a meeting with the client and debugged directly on his smartphone. After some testing I noticed an JavaScript exception QUOTA_EXCEEDED_ERR:DOM Exception 22. I checked the code and found the error was caused by using localStorage.setItem();. While we checked if localStorage is available 'localStorage' in window we didn’t check for setItem(); properly and therefore our complete JavaScript failed.

This made me rethink my strategy of hiding elements when JavaScript is available. Typically I change the className of <html> from .no-js to .js in the <head> with JavaScript to avoid the FOUC. The problem with this method is if an error occurs, like described before, this will fail and probalby make parts of the site unusable.

Example #

To demonstrate it here is an example of a responsive navigation.

Navigation on big screens

Navigation with JavaScript disabled/unusable

JavaScript usable and navigation closed

JavaScript usable and navigation open

If you view the demo on a small screen you can see that the navigation is hidden and the button to trigger the navigation is visible if JavaScript is usable. If JavaScript is disabled or unusable the navigation is hidden and the navigation is shown.

Here is the same demo with a JavaScript error added. As you can see in this case the navigation is displayed the same way it would be if JavaScript was disabled. So whatever error may stop your JavaScript from working the site will still be usable.

Conclusion #

To avoid cases where JavaScript is available, but not usable I will use the following code in the future.

document.documentElement.className = document.documentElement.className.replace(/\bno-js\b/,'js');
window.onerror = function () {
  document.documentElement.className = document.documentElement.className.replace(/\bjs\b/,'no-js');
}

Additional I will use Cut the mustard to check for features.

if('querySelector' in document && 'addEventListener' in window) {
  // code here
} else {
  document.documentElement.className = document.documentElement.className.replace(/\bjs\b/,'no-js');
}

There are many ways where JavaScript is not available or executed in a browser and by using window.onerror we can handle them and show the same layout/functionality which would be shown for users who disabled JavaScript.

Showing the alternative text while images are loading

2016-01-20T06:54:22+01:00

Some days ago Šime Vidas tweeted: Why don’t Chrome, Safari reserve space for <img> with height attribute in responsive layouts? As part of the discussion and after some testing in different browsers I found that Firefox is the only browser at the moment who shows the alt attribute while images are loading. I think it would be great if every browser would show the alternative text while images are loading – especially on slow connections this would be very helpful.

Slow connections #

When browsing web sites, especially on slow connections, it takes some time until all images are loaded. In addition to defining aspect ratio for images to prevent the jump effect, it would be great if the alternative text would be shown so I could decide more easily if I think it is worth to wait for the image or move on scrolling and reading.

Improve accessibility #

I think this would also improve accessibility. If authors would see the value of the alt attribute every time they open their site they would more likely add an alternative text for every image. Adding useful alternative text is something many Authors forget and don’t check before publishing an article. Some CMS also pre-fill the alternative text with information they extract from the image, like the name of the camera. My hope is that by making the alternative text more present many authors will think about it and provide useful information for images.

Styling the alternative text #

You can also style the alternative text with CSS. Here is an example of an invalid image where I styled the alternative text.

Feature requests #

Because I really want this feature in every browser I opened requests for Chrome (Blink), IE/Edge and Safari (WebKit).

Chrome
Internet Explorer / Edge
WebKit

Let’s see what they think.

On the Safari 9.1 release

2016-01-14T07:12:52+01:00

Earlier this week – January 11, 2016 – Apple announced the release of Safari 9.1 which will be available soon is available now. It ships with exciting features – picture element, fast-tap, CSS variables – to name a few. I was as surprised, as other web developers to see this happen and it makes me happy.

Safari is the new IE #

Many web developers have the feeling that Safari is lagging behind other browsers nowadays. On of the reasons is the release cycle of Safari. Until now, a new version of Safari was released only once a year. While other browser vendors release a new version every other month, we – as web developers – had to wait for a long time until features and fixes would land in Safari. I am pleased to see a change happening here and I am looking forward to see more frequent releases in the future.

I am even optimistic now to see Service Worker coming to Safari this year which I wouldn’t have thought it would ever happen a month ago.

And don’t worry, I am sure the internet crowd will soon find another thing which is the new IE.

The death IE8, IE9 and IE10

2016-01-12T12:58:12+01:00

As of today, January 12, 2016, Microsoft will no longer support older versions (8, 9 and 10) of Internet Explorer. Many people are celebrating the “death” of these browsers and seem to be very relieved that they no longer have to support these outdated browsers. It seems for many it is all or nothing, black or white, no support or support and I am not very happy with this thinking.

Core experience #

Don’t get me wrong, I am also pleased to see that outdated browsers will no longer be supported and many users will probably switch to modern browsers, but this doesn’t mean we should stop delivering our core experience for users still using older browsers.

For me this means, I will update my cut the mustard tests and handle IE9 and IE10 as HTML4 browsers in the future like I already do with IE8. HTML4 browser means these browsers will get the core experience, but I won’t invest extra time to deliver an enhanced version for them.

This also means old browsers shouldn’t stop you from using new web features or adding enhancements for modern browsers, it means that we shouldn’t exclude users with outdated browsers as they often don’t have the possibility to update and still want to use your website.

Be future-friendly and stop the all-or-nothing thinking.

Every web site has to start with server-side rendered HTML – no exceptions.

2016-01-07T12:22:25+01:00

If I open an URL and all I get is a blank page – be it because I turned JavaScript off, use an Adblocker, use an outdated browser or anything else – the developer building the site failed – no excuses. This is the case for every type of web site/app/whateveryoucallit – be it a WebGL game, a single-page application, an article or a cat gallery.

Don’t get me wrong, you shouldn’t and often couldn’t build features without using modern web technologies relying on JavaScript, a modern browser or a fast device. However, this doesn’t stop you to start with well-structured HTML in the first place.

No content #

When you open ROME (3 Dreams of Black ), a great semi-interactive film, without JavaScript you will see a black page and nothing else. This could also happen under different circumstances – it’s not about people surfing the web without JavaScript. If you view the source of the site you won’t see any content (apart from some meta tags like Title, Description and Open Graph) – it contains of a link to a CSS file, a script linking to a JavaScript file and Google Analytics.

When viewing the site with JavaScript turned on you will see an animated background (using canvas), an image (containing also text), Links and Share Buttons (Facebook and Twitter). To render that it loads 696 KB, which results in a Speedindex of 6568 and takes 7sec (on 3G) to show the first visible content.

The basics #

It’s not terrible bad, but still way to much KB and load time to show static content – the only element where JavaScript is needed is the animated background. I took the generated HTML from DevTools, changed the base href and tested the site again on WebPagetest and the full content (minus the animated background) was visible after ~4s – to be fair the web font failed to load in this test but if you would improve the HTML structure and load the CSS inline you would reach a similar result.

Apart from the animated background the site looks and works the same without using JavaScript. There is no need to render the initial content on the client-side and also no need to exclude anyone from viewing it. After the first view loads you could enter the “main” site which requires modern web technologies not everybody has. If a users browser doesn’t have all the needed features integrated you could show a notice, list what’s missing to have a perfect experience and suggest browsers the user could switch to.

Start every site you build with well-structured HTML and everybody wins.

Note: I don’t want to blame the developers of ROME here, but if you are reading this maybe you can change the site and start with server-rendered HTML. Please.

Syntax highlighting as an enhancement

2016-01-05T08:49:08+01:00

I never had syntax highlighting for my code examples on this site and thought it is finally time to add one. After looking at some solutions I decided to use Prism as it is well tested and maintained and extensible.

Implementation #

Do use Prism you need to include the CSS and JavaScript files you get from the Download page. In my case I saved the CSS I got as prism.scss under the folder vendor and afer running it through Grunt it got compiled with the other SCSS files, compressed and inlined in the head of the site.

After that I added the JavaScript in my footer.php at the very end:

<script defer src="https://justmarkup.com/log/wp-content/themes/justmarkup.com/dist/js/prism.min.js"></script>

Note: I first tried it with the async attribute but this doesn’t work with Prism so I used the defer attribute instead.

With this in place I went through my articles and added class="language-xxx"> to every code element where I want to have syntax highlighting. Finally some pretty code examples on my site. And if the JavaScript doesn’t load for whatever reason, the code blocks are still readable fine, like it was before – in two words – progressive enhancement.

Examples #

CSS

.code {border: 1px solid green;}

JavaScript

var Prism = true;

Add Service Worker for WordPress

2016-01-01T15:17:54+01:00

As part of the open redesign of this WordPress site I also added a Service Worker – to improve performance and to offer an offline experience. I encountered some problems along the way so I thought it is a good idea to write about my findings. As a starting point I used this basic implementation by Brandon Rozek.

Register the Service Worker #

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/log/sw.min.js', {scope: '/log/'});
}

First of all you have to register the Service Worker, at WordPress themes you normally have a footer.php where you can add this.

My blog is running on justmarkup.com/log/, that’s why I use scope: '/log/' here as the scope as I only want to use this Service Worker for my blog and not for every part (for example: Piwik, hosted on /piwik/) running on the domain. If your WordPress installation is on the root, you should use scope: './'.

Usually, you have your theme files under /wp-content/themes/YOURTHEME/ and also have all your JavaScript files (and therefore also the Service Worker file) in this directory. The problem is that the Service Worker file has to be in the root directory of WordPress (in my case this is /log/) to be able to control and work with every part of your WordPress site. So, the Service Worker can only control everything in the directory it is served from and every directory beneath it. I was rather confused about it the first time, but it makes sense now, as otherwise you would be able to control every site on a shared hosting (think of Github pages).

To get around the issue on my WordPress site, I created a symbolic link (symlink) – where I link the Service Worker file in my theme folder to the root folder. This way I can work on the Service Worker file in my themes folder and have it automatically linked to the root folder.

ln -s /var/www/log/wp-content/themes/justmarkup.com/dist/js/sw.min.js /var/www/log/sw.min.js

Another way to handle this would be a .htaccess redirect rule, but I personally prefer using a symlink.

Handle admin and preview pages #

With this in place my Service Worker was working fine until I was working on a new article and finding out that changes where sometimes not saved correctly and the preview was not accurate anymore. So, I added a conditional statement to not intercept the fetch when the URL contains wp-admin (the admin area of WordPress) or if the URL contains preview=true (the preview page).

self.addEventListener("fetch", function(event) {
    //This service worker won't touch the admin area and preview pages
    if (event.request.url.match(/wp-admin/) || event.request.url.match(/preview=true/)) {
    return;
    }
});

Bottom line #

Service Worker are great and an enhancement for every site. While I first thought it is mainly about adding an offline experience I am far more excited about the performance impact and all the other exciting things you can use it for.

The Service Worker file currently in use on this site.

If you want to use Service Worker on your WordPress site, I hope this article helps you to implement it without making the errors I made. If you use Service Worker in your WordPress site and found other solutions for the mentioned problems or other ways to improve it, please let me know.

Front-end wishlist for 2016

2015-12-22T06:59:18+01:00

The end of the year is around the corner and it’s time to look into the future of Front-end. In this post I will talk about my wishes for 2016 and why I would love to see these three features implemented.

Container queries #

Jonathan Snook wrote a great article called Being responsive to the small things for this year’s 24ways advent calendar about the current state of container queries and JavaScript-based solutions to use them today. Container queries, also known as element queries comes with a lot of challenges for specification editors, browser vendors and everybody involved in adding new browser features, but it looks like it will be possible to implement them. While I know it’s challenging to implement it I am optimistic 2016 will be the year where container queries will make it to a browser near you. So, why do I want to use container queries, isn’t media queries enough?

We’re not designing pages, we’re designing systems of components. – Stephen Hay

With media queries for every container our component lives in, we need to specify how to rearrange things in that context. By using container queries we can specify CSS for a component based on the dimensions of the container. This means your components are not dependent on the screen size, but on the container; Fantastic.

Service Worker ships in Safari and Edge #

I am really excited about Service Worker (probably not as excited as Jake Archibald, but still) and can’t wait until Safari and Microsoft Edge will implement Service Worker. I am pretty sure it will come to Edge in 2016, although they still have it listed as Under Consideration at the moment. You should vote for it.

To be honest, I am not so enthusiastic about Safari – Service Worker is on the 5-year plan of WebKit – but even if it will ship to WebKit next year it doesn’t mean it will be shipped in Safari.

Nevertheless, why I really like Service Worker is that it plays along nicely with progressive enhancement, offers not only an offline experience – but improves performance and all the other exciting things you can use it for.

If you want to see Service Worker in every major browser next year the best is to make a lot of noise about it, by using Service Worker today in as many sites as possible and by writing about it again and again.

Parent and previous sibling selector #

Parent selectors and previous sibling selector have been on the wish list of Front-end developers for years. The main points they are not implemented yet is that they are too expensive to implement and that they are pretty inefficient.

While this may still be the case I think now is the time to implement them as an experimental feature and see what developers will make of it and how inefficient it really is. If the performance is not acceptable either some clever browser developers can change that or it will be removed again. If it turns of to be more efficient than expected it can be shipped without using an experimental flag; This would make many developers very happy.

What features do you want to see in browsers in 2016? #

What HTML, CSS or JavaScript features do you want to see shipped in 2016? Whatever it is, the best way to get a feature implemented is to make noise; Write about it, tell everyone why you need the feature, write about it again.

Scale an element without changing the size of its child elements

2015-11-27T10:55:43+01:00

This morning I asked on twitter for help with using transform: scale(); The first problem was that I wanted to animate the box the same way with scale(); as with changing the width/height of the element. The problem here was I wrongly set transform-origin: 0 0; only on :hover but not for the inital state; Thanks to Sven Wolfermann for the hint.

Don’t scale the children #

The second problem was that I wanted to change the size of the element but not the size of its children (text). My first attempt was using transform: scale(2); for the box (div) and transform: scale(0.5); for the child element (p). This way the text had the same size before and after the transition but slightly changed the size during the animation and also looked very blur and ugly along the way as you can see in this example.

After some different approaches I thought about using ::before to achive the same effect. I first thought it doesn’t work (was confused regarding box model and layers – see below) but it turned out to achive exactly what I wanted; Scale an element without effecting the size of its child elements.

div {
  width: 100px;
  height: 100px;
  margin: 100px;
  position: relative;
}
div:before {
  z-index: -1;
  content: "";
  position: absolute;
  left: 0;
  top: 0;
  width: 100px;
  height: 100px;
  background: red;
  transform-origin: 0 0;
  transition: all 8s;
}

div:hover:before {
  transform: scale(2);
}

Here is an example showing the animation using scale on the div itself (first box) and using scale on div:before (second box).

Bottom line #

By setting transform on the element the element gets an own layer which does not effect the size of the box model. This means an element with width: 100px; transform: scale(2); will still have an offsetWidth and getAttribute("width") of 100px; as you can see in the console output here.

If you really want to change the content width/content height of a box you have to change a property effecting the box model (width/height, margin, padding, border). They all trigger layout and repaint and are therefore expensive to animate so if you only want to “visually” change the size of an element use transform.

Definining aspect ratio to prevent reflow

2015-11-25T11:21:50+01:00

When browsing the web (especially on a slow connection) it takes some time until images are loaded and the browser is able to calculate the necessary space needed. I often open an URL, start reading and half way down when the images are finally loaded, I lose the current position and have to scroll down and search the position I have been; This is frustrating.

Here is an example showing the Reflow effect using Chrome and Network throttling set to 3G.

Screencast showing the jump effect

There are different ways to prevent this jump effect. While you can avoid it by setting an explicit width and height for every image in your HTML we will concentrate on solutions suitable for responsive web sites where images don’t have a fixed width and height.

padding-bottom hack #

.aspect-ratio-container {
  position: relative;
  padding-bottom: 56.25%; /* 16/9 aspect ratio */
  height: 0;
}

.aspect-ratio-container > * {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  background-color: #eee; /* you could also define a background image as a placeholder here */
}

Example on jsbin.

The padding-bottom hack – intrinsic ratios – has been around for a while now. The only downside is that you need a container to wrap the element.

calc()/vw based workaround #

body {
  width: 75em;
  max-width: 90vw;
  margin: 0 auto
}

img {
  width: 100%;
  height: auto;
  height: calc(9 * 90vw / 16);
  object-fit: cover;
  background-color: #eee;
}

@media all and (min-width: 75em) {
  img {
    max-width: 100%;
    height: auto;
    height: calc(9 * 75em / 16);
    object-fit: cover;
  }
}

Example on jsbin.

After trying several ways to set an aspect ratio without the need of a container I came up with a workaround using calc() and the vw (viewport width) unit.

The biggest disadvantage is that it only works for images spreading to the full width of the screen size.

Browser support is pretty good for calc() and vw.

The aspect-ratio property #

/* set 16/9 aspect ratio for all images */
img {
  aspect-ratio: 16/9;
}

Tab Atkins already proposed a draft for an aspect-ratio CSS property in 2012. According to Tab the CSSWG does want to address it, but it’s been low priority for years. He also mentioned that the proposal has some serious problems:

If you want to have this property, write a reply to this thread on Specifiction to show your desire.

Other elements #

There are other elements like video/iframe and ads (inserted asynchronous and expanding the space) which can trigger an unwanted reflow. I recommend setting an aspect ratio for these elements as well. For banners you often have fixed units which gets inserted into the page according to screen size. Here is an example how you could handle this with CSS:

/* On small screens show 320x50 banner */
.ad-container {
  width: 320px;
  height: 50px;
}

/* On medium screens show 728x90 banner */
@media all and (min-width: 800px) {
  .ad-container {
    width: 728px;
    height: 90px;
  }
}

/* On large screens show 970x90 banner */
@media all and (min-width: 1000px) {
  .ad-container {
    width: 970px;
    height: 90px;
  }
}

Bottom line #

If you are able to set a container the padding-bottom hack is a good way to prevent a Reflow. For images not having an extra container the calc()/vw solution is a good alternative. Until we have a native CSS solution to handle aspect ratios the mentioned workarounds are great to prevent the jump effect.

Open redesign

2015-11-12T14:47:34+01:00

I wanted to update the design for this site for years but whenever I started, other projects came in the way. I have at least 10 unfinished designs which will never go live. That’s why I am starting an open redesign now.

Planned improvements (in random order) #

Make it fast, then make it even faster – Load JavaScript async – pretty happy with the performance now.
Improve Accessibility – Fixed labels for forms, Made svg logo accessible by adding a title attribute, changed heading structure, fixed bad contrast for code element – marking this as done is probably wrong as I am sure here and there is eg. an alt description not perfect but all the main things are fixed.
Add last updated at for technical articles
Service Worker integration – 13.11.2015 – Basic implementation is live: Code and article
Push notification integration with WordPress – 18.11.2015 – Initially I thought it might be a great idea to offer notifications every time I post a new article but that’s what RSS is for. You should only show notifications if it’s important and urgent which is not the case for a new post.
Responsive Images – On by default in all newer posts
Add to homescreen – 13.11.2015 – Code
Use em instead of px – 01.01.2016 – Commit
Add logo animation – 19.11.2015 – Commit
Add code highlighter as an enhancement – added prismjs (commit)
…

You can find the code of the WordPress Theme on Github. If you have any other ideas for improvements or found a bug feel free to open an issue.

I will write about some improvement along the way. If there is anything you would like to see integrated or anything you would like me to write about, let me know on twitter or write me an email.

Articles about it #

Add Service Worker for WordPress
Syntax highlighting as an enhancement

Using text-shadow instead of font-weight bold to avoid jumping

2015-11-02T06:55:32+01:00

When using font-weight: bold for :hover states on links the width of the element changes as the character width gets increased. This can result in a jump effect as shown in this example.

Workaround #

a:hover {
  text-shadow: 1px 0 0 currentColor;
}

To prevent the jump effect we can use text-shadow to fake font-weight: bold. Browser support for text-shadow is good for most browsers, except in Internet Explorer where it isn’t supported prior to Version 10. As you want to define :hover states for older IE versions as well you may use conditional comments:

Conditional comments #

<!--[if lt IE 9]> <html class="old-ie" lang="en"> <![endif]-->
<!--[if IE 9]> <html class="old-ie" lang="en"> <![endif]-->
<!--[if !IE]><!--> <html lang="en"> <!--<![endif]-->

a:hover {
  text-shadow: 1px 0 0 currentColor;
}

.old-ie a:hover {
  font-weight: bold;
}

Example using conditional comments.

CSS Feature Queries #

Or you could use @supports to target only browsers which support CSS Feature Queries and text-shadow:

a:hover {
  font-weight: bold;
}

@supports (text-shadow: 1px 0 0 #000) {
  a:hover {
    font-weight: normal;
    text-shadow: 1px 0 0 currentColor;
  }
}

Example using @supports.

I prefer using @supports as it is future-friendly and although it is not supported in IE11 it is supported in Edge and every other modern browser.

Audio - The preload attribute

2015-08-11T10:18:46+02:00

I recently worked on a site where the audio element is used to provide extra information. After testing some article pages with many audio elements I noticed that browsers download the audio source without interacting with it. In some cases, this summed up to 10MB of downloaded data. Visiting such a site with a data plan can be very expensive. After visiting MDN and reading more about the audio element I found out about the preload attribute and started testing it.

Preload attribute #

If we look at the description defined in the W3C specification we can see that there are three keywords defined for the preload attribute:

preload=”none”: hints that either the author thinks that the user won’t need to consult that audio or that the server wants to minimize its traffic; in others terms this hint indicates that the audio should not be cached;
preload=”metadata”: hints that though the author thinks that the user won’t need to consult that audio, fetching the metadata (e.g. length) is reasonable;
preload=”auto”: hints that the user needs have priority; in others terms this hint indicated that, if needed, the whole audio could be downloaded, even if the user is not expected to use it;
the empty string: which is a synonym of the auto value.

Note: I tested in IE9, IE10, IE11, Edge, Chrome, Firefox, Opera, Safari, iOS Safari 8, Opera Mobile and Android 5 on real devices as Device Emulation and BrowserStack both showed the wrong results for mobile browsers. I used mp3 and Ogg sources for the tests, as every browser supporting the audio element supports at least one of them. To check for differences between using mp3 or Ogg first in the source, I tested this as well.

preload=”none” #

<audio controls preload="none">
    <source src="mp3.mp3" type="audio/mpeg">
    <source src="ogg.ogg" type="audio/ogg">
</audio>

I tested with various browsers and combination of source order (ogg first, mp3 first) and no browser downloaded a file. There is however one major issue: IE9 doesn’t show the audio player at all when using preload=”none”. It will only show the player after a right click on the invisible audio player and a click on play.

preload=”metadata” #

<audio controls preload="metadata">
    <source src="mp3.mp3" type="audio/mpeg">
    <source src="ogg.ogg" type="audio/ogg">
</audio>

Here it gets more interesting. On desktop browsers between 50kb and ~800kb of data gets downloaded from a 40MB file. Mobile browsers only download some kilobytes, only the metadata gets downloaded.

preload=”auto” #

<audio controls preload="auto">
    <source src="mp3.mp3" type="audio/mpeg">
    <source src="ogg.ogg" type="audio/ogg">
</audio>

On desktop browsers 2MB up to 40MB gets downloaded from a 40MB file. For mobile browsers it’s the same as for preload=”metadata” – only some kilobytes gets downloaded.

No preload attribute or preload=”foo” #

<audio controls>
    <source src="mp3.mp3" type="audio/mpeg"> 
    <source src="ogg.ogg" type="audio/ogg">
</audio>

According to the specification no preload attribute is a synonym for preload=”auto”. The same goes for invalid keywords like preload=”foo”. My tests shows that all browsers requests the same amount of data for preload=”foo”, no preload attribute or preload=”auto”.

What preload attribute should I use? #

Before discovering the issue with IE9 and preload=”none” I would have said preload=”none” is the best solution. No unnecessary data gets downloaded beforehand and the users can decide if they want to hear the audio and download the data. There is also another issue with preload=”none” – you won’t get the information of the audio duration before the audio gets played. You may get this information via server side but it may still be a dealbreaker from some.

As there is no way (at least none I found) to fix the issue with IE9 and preload=”none” I would go with preload=”metadata”. By doing so less data gets downloaded beforehand and you still can get all the meta information of the audio. Mobile browsers already manage this quite well by not downloading much data (regardless of the preload attribute). But, I also tested using a desktop browser connected to a mobile hotspot and there was no difference between 3G or Wifi.

Do sum it up – Don’t waste data of users, the web is already too bloated and we should respect that connections can be slow and data expensive.

Resources #

Test page
Specification
MDN

Dealing with long words in CSS

2015-07-31T11:54:41+02:00

The web consists of content, content consists of words and words can be long, very long. Everyone involved with the web will sooner or later have to deal with long words.

Demo

Browsing the web on my mobile device daily I see all kind of “failures” with long words – broken layouts, cropped words and situations like the one in the image above.

Hyphens #

The first solution for long words is using hyphens.

Demo

.hyphens {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    -ms-hyphens: auto;
    hyphens: auto;
}

Browser support: CSS Hyphenation is supported in every major browser, except from all blink-based browsers (Chrome, Opera, Android) – Chromium bug. I also tested Safari 5.1 for Windows where hyphens are added but in my test words they were all on the wrong position and made no sense.

Furthermore, hyphens is language-sensitive. You have to define the lang attribute on the parent element and you should be aware that non-english languages are not supported very well across browsers.

You could also use a JavaScript library like Hyphenator.js which works with many languages and in lots of browsers. The downside is that you have to load a lot of extra JavaScript and especially for longer text it will hurt the performance.

word-break #

As browser support for hyphens isn’t really good, let’s try word-break – a CSS property to specify whether to break lines within words.

Demo

.word-break {
    -ms-word-break: break-all;
    word-break: break-all;
    word-break: break-word;
}

Browser support: CSS word-break is supported in every browser, except from Opera Mini and old presto-based Opera browsers. I also found some bugs when using word-break in combination with hyphens – more on that later.

Overflow-wrap #

The next solution is using word-wrap (overflow-wrap), another property to specify whether or not the browser may break lines within words.

Demo

.word-wrap {
    word-wrap: break-word;
    overflow-wrap: break-word;
}

Browser support: CSS overflow-wrap is supported in every (at least all I tested and listed on Can I use) browser. Note: Some browsers require the legacy name “word-wrap” (rather than “overflow-wrap”) to work.

Ellipsis #

Another option to handle long words is truncating.

Demo

.ellipsis {
    overflow:hidden; 
    white-space: nowrap;
    text-overflow: ellipsis;
}

Browser support: Text-overflow is supported in every major browser.

While this technique sounds like a good fit at a first glance it comes with disadvantages. First of all it will truncate every text after one line even if you use short words which would fit perfectly and would break in more lines. Furthermore, words could be truncated in a way that the original word will get another meaning – which may be funny at best or offensive at worst.

Please, don’t use text-overflow: ellipsis at all – truncating is not a job for CSS. If you really need it do it on the server side and only truncate after full words.

Conclusion #

I tested all the examples above and combinations of them in IE7, IE8, IE9, IE10, IE11, Edge, Firefox 39 (Windows, Linux, Mac), Chrome 44 (Windows, Linux, Mac), Opera 30 (Windows, Mac), Safari 8 (Mac), Safari 5.1 (Windows), Android 5 (Nexus 6), Android 4.4 (Nexus 5), Android 2.3 (Galaxy S2), iOS 8.3 (iPhone 6), iOS 7 (iPhone 5S), iOS 6 (iPhone5), Opera Mini (Android 5), Opera Classic (Android 5), Opera Mobile (Android 5) and Windows Phone 8.1 (Lumia 930) using real devices and BrowserStack – Here is a list of all 26 browsers and their results.

When searching the web you probably will find the following solution:

.hyphenate {
    -ms-word-break: break-all;
    word-break: break-all;
    word-break: break-word;

    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    hyphens: auto;
}

While this works great in most cases, I found out that in Firefox hyphens won’t work (altough supported) in combination with word-break. Also, as word-break is not supported in Opera Mini it won’t work there.

As browser support for overflow-wrap is fantastic I tested the following, using overflow-wrap and hyphens:

Final solution #

.hyphenate {
    overflow-wrap: break-word;
    word-wrap: break-word;
    -webkit-hyphens: auto;
    -ms-hyphens: auto;
    -moz-hyphens: auto;
    hyphens: auto;
}

This solution will show hyphens for every browser supporting it and will break lines in every other browser – perfect. Altough I have tested this solution in 26 different browsers I am still not sure this will work 100% – if you find any edge case please let me know.

Update 28.09.2015
Some people asked why I didn’t mention HTML soft hyphens. There are two reasons. First of all, this post is about solutions using CSS and not HTML and second and more important is that I think it’s impractical to define possible hyphens in the text itself and almost impossible for editors to do that by hand.

The Full Tools Developer

2015-07-23T07:35:40+02:00

Last week I attended the Meet the TAG Meet-Up, a Q&A Panel with lots of great discussions between W3C TAG members and the audience – I even meet Sir Tim Berners-Lee; A wonderful evening. After the event, I talked to a student and he told me that one part of his studies is to build a “web app”. He decided to build an application for a museum showing interactive elements for exhibits. We started talking about how he plans to structure the project and what web technologies he plans to use when he said:

» Originally I planned to use AngularJS to build the app, but my professor said I should better use React «

What?! If now even professors teach students to use tool X, framework Y or library Z instead of telling them about “the basics” CSS, HTML, JavaScript, Accessibility, Progressive Enhancement, etc. we can all shout “The web sucks” and learn Swift. That’s like teaching an apprentice chef how to use kitchen equipment X (also known as jCook) instead of teaching them how to really cook.

PSA: I think React is good, but pointing beginners w/o great understanding of HTML/CSS to a JavaScript-based UI library…not so much.

— fantastic ms. (@fox) July 23, 2015

I don’t hate tools, I just don’t like the way most people use them #

If you know me, you know my opinion about using frameworks – let’s politely say I don’t like them very much. I don’t hate frameworks but seeing how these tools are used every day is just wrong in my opinion.
If you use jQuery to hide/show elements and for nothing else – that’s wrong.
If you use React because it’s cool to use it with no real benefits for the user and developers – that’s wrong.
If you use Bootstrap because everybody else does – that’s wrong.

But I also see developers using tools because it helps them to improve site performance, user experience and reduce developer time and costs – that’s great. I also use jQuery quite a lot, because it’s often the best choice for a project. If you use a tool, to me a favour and think about if you really need it for a project and use it responsible.

Learn the basics, teach the basics, use the basics #

I see a problem here, developers who knows how to use tool X or how to ask a question to get a full working code example back but may don’t know what to do if nobody is answering or if tool X isn’t the cool tool anymore. So the next time someone asks you what a beginner should learn say HTML, CSS, JavaScript – one after another.

Maybe I am just a grumpy old chap not ready for a new tool every day; I am okay with that!

Introducing bugspencer.com

2015-07-16T11:50:54+02:00

Browser bugs are annoying, reporting them can be even more frustrating. It can be quite hard to find information about the right place to report browser bugs and I see questions about this pop up on twitter here and there.

That’s why I started bugspencer.com.

A place to find information about bug trackers and status pages of various browsers, articles around browser bugs and other useful resources. It’s still in his early state as you can see, but it will hopefully improve over time.

If you found an error on the site, want to add an article or resource or even want to help me improve the design (Hint: Logo) let me know @justmarkup or open an issue – Your help is highly appreciated.

If you are wondering about the name – Bugspencer – I was quite a big fan of Bud Spencer and his movies, which used to be broadcasted every Sunday in Austria so I changed Bud to Bug and hence the name.

Defining browser support

2015-07-09T15:03:14+02:00

I attended a meeting this week where we talked about optimising the “web process” for an agency – Among other topics we also had a great discussion about browser support.

When working with clients you usually set up a contract, where you often define the browser support for the project. From my experience, this often reads as “We support the latest 2 versions of all popular desktop and mobile browsers” or “We support IE9 and above, Chrome 36 and above, iOS6 and above, etc.”

While this sounds reasonable at a first glance you will have a hard time if you find out that a special feature won’t work in some of the stated browsers and you have to explain that to your client. This can happen quite often, for example, some features/modules are not fully defined at the start of a project and may require a technology some of the browsers don’t support.

Browser support by feature #

Instead of stating browser support for the whole site I think it makes more sense to define browser support for every feature/module.

Here is an example I put on jsbin to show what this might look like:

Do find out the browser support for a module you can use caniuse.com. Search for all front-end technologies you need and collect the data in a table/spreadsheet.

CSS filter effects support table from caniuse.com

This way, you have a good overview of browser support for all your modules and everybody involved with the project will have a handy reference. Furthermore, you can include notes describing what “full support” or “no support” means for a specific module. You can even go one step further and define multiple versions of a module and their support. If we take the video example, this could mean core function is a link to the video, enhanced version means HTML5 video player, enhanced enhanced version means full customized HTML5 player.

While I am fully aware that this may be hard to explain to clients I think it’s worth the time and will help everybody in the end.

Update: 13.07.2015
As Alexis Deveria points out it’s possible to search for multiple features at once on caniuse.com – If your module needs dom-range, mp3 and css zoom you can use this link and scroll down to summary to see support for all features.

What’s your approach of defining browser support for your projects? Let me know @justmarkup.

A web developer and a surfer went on a Safari – What happend next will shock you.

2015-07-07T06:16:40+02:00

A surfer and a web developer, both familiar with going on Safari, went on a trip the other day. This time they decided to go with the vendor Banana.

Apple bananas

After sitting in the Safari SUV (called the mighty Browser by locals) for some time, the surfer praised the smooth experience on the way and that the car hasn’t broken yet like with other vendors before. It’s such a smart and powerful way to go on Safari with Banana, he said. Furthermore, as Banana is the only company available for this region – it all feels so native, very inimitable, he added. That’s amazing, isn’t it, he asked the web developer.

The web developer (front) and surfer (back).

The web developer, taking a deep breath, before replying in his loudest voice, NO! Don’t you see that all the features, we had with other vendors, are missing on this trip? One company even managed to deliver a great experience after the car went out of petrol, that was awesome, he added.

And thereby ends the story of a grumpy web developer and a happy surfer.

* Not related to recent articles and discussion about Safari (web browser), isn’t it? Also, I am strictly against Linkbait!

Browsers and Bugs - The last issue

2015-07-06T15:48:58+02:00

I have been publishing a new issue of Browsers and Bugs every Friday for 24 weeks in a row until my vacation two weeks ago. After the break, I wanted to start collecting links and deciding what’s worth adding to the list again these days, but it doesn’t feel right anymore.

I got next to nothing on feedback for any of the published articles and don’t know anymore how to justify 2-4 hours of work a week I usually spent on this. Don’t get me wrong, I never expected a lot of feedback and never thought about turning it viral or making money out of it – I wanted to share links I thought are worth reading, inform people about fixed browser bugs, new browser features, tips for testing and debugging and overall all about Browsers and Bugs.

It was fun, always informing, mostly interesting and never boring to read all the articles, tips and videos and to decide what content fits into Browsers and Bugs.

Looks like it didn’t work as expected.

Maybe it was the name.
Maybe I listed links everybody already read.
Maybe I should have added personal notes for all links.
Maybe I should have published it on another day or time.
Maybe it was me.
Maybe it was you.
Maybe I use maybe too often.

I still have a lot of ideas about Browsers and Bugs and how it might return someday, but right now, I feel better to work on other side projects for the next time.

Have a nice day and please don’t stop writing bug reports, testing new features and share your knowledge to make browsers even better.

Sincerely,
Michael

Progressive enhancement is not…

2015-07-03T08:50:33+02:00

… an add-on.
… adding a fallback for every feature you want to use.
… about thinking in browser versions.
… about making it work without JavaScript.
… the answer to the universe life and everything – that’s 42.
…

I couldn’t attend EdgeConf last weekend as I was on holiday but reading through my twitter stream it looks like there was a lot of great discussions about Progressive Enhancement – Baseline, Assumptions, Unpredictability, Availability.

I, for myself, like to define Progressive Enhancement as use-case oriented programming™.

What does that mean? Let’s start with a sample used by many sites – showing a video. For me, this means first of all I would add plain old HTML with the transcript of the video making it accessible to as many people as possible – that’s our baseline. Next, I would a link in HTML to the video source (preferable different formats/qualities if you have them), so every device, browser, whatever able to render HTML will show the link and give the user the possibility to download it. Next I would add the download attribute to the link so browsers supporting this attribute will directly open the “Save as…” dialog on click. As the next step, I would then add the HTML video element, with sources to all available formats I have for the video, so users surfing with a newer browser will be able to watch the video right away. As a final step, I could add some JavaScript (only loaded if the browser Cuts the mustard for the features I want to use), to enhance the player functionality.

Note, that I don’t add any fallback (Flash, Silverlight…) here as this would mean loading Polyfills or most likely using a library which adds a fallback for flash for older browsers. There is absolutely no need here for spending time in development to fully support all the browsers with a video player. We already have a “fallback”, it’s just not a fallback it’s our baseline – a transcript of the video in HTML. Do web sites need to look the same in every browser – NO. Do web sites need to have the same non-core functionalities in every browser – NO.

This is Progressive Enhancement for me, start with thinking about the use-case – in this example, “User should be able to consume the content of the video”. If this baseline is in place you can enhance to whatever level you think is right.

I would like to know your opinion, let’s talk @justmarkup.

Browsers and Bugs 24/2015

2015-06-18T13:32:49+02:00

Hello and welcome to issue 24 of Browsers and Bugs. As I am in Brighton for Responsive Day Out tomorrow you can enjoy this issue already today. Furthermore, as I am on holiday on an island in Italy starting next week for 10 days there won’t be a new issue the next 2 weeks. Enjoy the summer.

Browsers, Bugs and Workarounds #

Building a more interoperable Web with Microsoft Edge #

Why user agents are an ever-growing pack of lies; on browsers working around developer errors (eg. correcting charset=”utf8″ to charset=”utf-8″) and much more.

From ASM.JS to WebAssembly #

Browser vendors are collaborating on a WebAssembly standard. You can find some more information and FAQ’s in the Gitub Repo.

Firefox; Bug 366324 #

SVG site icons (favicons, shortcut icons) support

Debugging, Testing and more #

Chrome DevTools, Front to Back #

Talk from Katie Fenn presented at ScotlandJS

BrowserRemote #

Debug your user’s browser remotely via Chrome DevTools. Read more about in the blog post from Kenneth Auchenberg.

BrowserStack #

You can no test Microsoft Edge on BrowserStack.

View jQuery and jQuery Live events in Firefox DevTools #

Browsers and Bugs 23/2015

2015-06-12T06:02:57+02:00

Hello and welcome to issue 23 of Browsers and Bugs. Happy testing.

Browsers, Bugs and Workarounds #

What’s new in Safari 9 #

CSS Scroll Snapping, Backdrop Filters, Responsive Design Mode, @support, Unprefixed CSS Properties and ECMAScript 6 Enhancements. If you prefer watching there is also a Video.

Opera Mini for Windows Phone #

First stable version of Opera Mini for Windows Phone 8.1 is now available in the Windows Phone App Store.

Introducing srcset in Microsoft Edge #

Windows 10 Insider builds recently introduced support for srcset, our first step on the path to fully supporting the picture element for responsive images. Support for the width descriptor in srcset, and the sizes attribute is not yet implemented but will land in the near future.

Opera 30 #

The autocapitalize HTML attribute, Cache API, Permissions API, JavaScript-powered copy/cut functionality and much more.

translate3d(0,0,0) #

WebKit will ignore “translateZ(0), translate3d(0,0,0)…” on devices with 512MB or less.

Debugging, Testing and more #

Debugging Promises with DevTools #

In this episode of Totally Tooling Tips, Addy Osmani and Matt Gaunt walk through how to debug ES6 Promises using the brand new Promises debugger in Chrome DevTools.

Devtool tricks for when I forget #

Remy Sharp demonstrates how to capture XHR results and retrieve results from the ether.

PageSpeed Insights #

Setting up PageSpeed Insights within existing gulp projects.

tota11y #

tota11y is a tool which helps visualize how your site performs with assistive technologies.

Browsers and Bugs 22/2015

2015-06-05T04:21:05+02:00

It’s friday and thus a new round of Browsers and Bugs is ready for you. Hello and welcome to issue 22. Happy bug reporting.

Browsers, Bugs and Workarounds #

Chrome 44 Beta #

Improvements to Notifications API and promoted add to homescreen

Opera Browsers Overview #

There are lots of different Opera browsers with different engines and platform availability – this is a great overview of all of them.

Firefox platform rendering #

An overview of features the Firefox platform team is working on.

Debugging, Testing and more #

Performance Tools in Firefox DevTools #

Firefox Developer Edition features a new performance tool that gives developers a better understanding of what is happening from a performance standpoint within their applications.

Scroll Performance #

Sometimes a simple border-radius: 4px can cause scrolling performance issues.

The most exciting part of computer programming #

Optimize JavaScript with DevTools #

A screencast on how to use the new performance tools in Firefox Devtools to optimize JavaScript.

Heroes of JavaScript and Testing #

Please Update Picturefill #

If you’re using a version of Picturefill from prior to 2.3.1, please update right away – this is important for the web.

Browsers and Bugs 21/2015

2015-05-29T06:18:07+02:00

Hello and welcome to issue 21 of Browsers and Bugs. Happy bug reporting!

Browsers, Bugs and Workarounds #

Flexbox bugs #

Flexbox gotchas for Android 2.1 – 4.3 (stock browser).

CSS Transform Module Level 2 #

Intent to Implement: Independent Properties for CSS Transforms (scale, translate, rotate) in Chromium.

SVG sprite #

Tests and notes about browser support for referencing an external SVG file in HTML.

Assistive Technologies #

Update for IE with future considerations for Assistive Technologies and integrated Accessibility API support in Windows 10 with Edge.

Debugging, Testing and more #

W3C developer tools #

Various tools and validators to test your site.

Browser testing #

So to put it in glib terms, I support every browser …but I optimise for none.

Throttled Thursdays #

Throttle your internet connection once a week to embrace the pain of slow sites and improve performance.

ConsoleBot #

Allows savvy developers to chat to a website owner via the browser console.

Friefox DevTools #

Access MDN directly within the Firefox DevTools.

Browsers and Bugs 20/2015

2015-05-22T03:58:35+02:00

Hello and welcome to issue 20 of Browsers and Bugs. Happy bug fixing!

Browsers, Bugs and Workarounds #

Opera Mini #

Opera Mini consumes 14% less battery and 89% less data on an average than other mobile browsers

Fixing the scrollTop bug #

…they have to copy WebKit/Blink’s bugs in order to be compatible with the Web.

Windows Preview Build 10122 #

Support for date/week/month inputs and news CSS3 cursor values among others.

Delivering fast JavaScript performance in Microsoft Edge #

Debugging, Testing and more #

What’s new in Firefox 40 DevTools #

Always active network monitoring, CSS rules filtering, and much more

How to make useful bug reports #

Getting bug reports lacking information is really frustrating – this article describes how to do it better. For getting browser details I shameless recommend this tool my clients use frequently.

PerfBar #

Simple way to collect and look at your website performance metrics quickly, that supports budgeting and adding custom metrics.

Time-Travel Debugging for JavaScript/HTML Applications #

This video from Microsoft Research describes an experimental time-traveling debugger inside the next-generation Microsoft Edge web browser.

DevTools snippets #

Not the newest collection but still very useful.

Monitor load time performance with Piwik

2015-05-20T08:53:58+02:00

Yesterday I came across this great article about Browser Monitoring at Github and how they use the Navigation Timing API to monitor page performance.

As I use Piwik to analyze and monitor the traffic on my site I thought about a way to combine both to monitor the load time of my site. After some testing, I came up with the following solution.

First of all we define a function to get the load time using the Navigation Timing API:

function getPerfTiming() {
    if ( !('performance' in window) || !('timing' in window.performance) || !('navigation' in window.performance)) {
        return false;
    } else {
        var timing = window.performance.timing,
            now = new Date().getTime(),
            start = timing.navigationStart,
            loadTime;

        loadTime = (now - start) + "ms";

        return {
            loadTime: loadTime
        }
    }
}

Use Piwik to save results #

Next we need to change the Piwik code used on the site. We need to define a custom variable before calling piwikTracker.trackPageView().

Using the function from above this looks like the following:

if (getPerfTiming()) {
    piwikTracker.setCustomVariable(
    1, // slot ID - up to 5 custom variables can be used
    "loadTime", // name of the custom variable
    getPerfTiming().loadTime, // value of the custom variable
    "page" // scope - page means it gets send on every page load
    );
}
piwikTracker.trackPageView();

Monitor results on your Piwik instance #

After logging into your Piwik instance, you can go to Visitors -> Custom Variables to all the variables you defined with piwikTracker.setCustomVariable

I implemented this today on my site and I am already really curious how the load time will differ for the users. To monitor other performance aspects like first paint, you can use additional custom variables if you like.

Browsers and Bugs 19/2015

2015-05-16T07:45:17+02:00

Hello and welcome to issue 19 of Browsers and Bugs. Happy bug reporting!

Browsers, Bugs and Workarounds #

Firefox 38 for developers #

Ships with Responsive Image Support and lots of bug fixes.

Spec allows use of AppCache to provide fallback for ServiceWorker #

More info in the Chromium and Firefox bug tracker.

This is for everyone with a certificate #

Jeremy Keith about deprecating HTTP in favour of HTTPS.

What’s new in the F12 Developer Tools #

Video from the Microsoft Edge Web Summit.

Debugging, Testing and more #

Reducing Memory Leaks when Working with Animations #

Responsive Design Dashboard #

Great tool from Speedcurve

Firefox DevTools #

Attributes change animation

Browsers and Bugs 18/2015

2015-05-08T06:24:48+02:00

It’s friday and thus a new round of Browsers and Bugs is ready for you. Hello and welcome to issue 18. Happy bug fixing!

Browsers, Bugs and Workarounds #

Copy/Paste via JavaScript #

After Chrome and IE also Firefox is shipping document.execCommand(“cut”/”copy”).

Microsoft Edge Web Summit 2015 #

All videos from the summit are online now.

IE Guides #

Developer Guides for IE7 – Edge

Firefox OS for TV UX Overview #

Debugging, Testing and more #

Chrome DevTools: Front to Back #

Great slides from Katie Fenn

F12 developer tools #

Using the F12 developer tools, you can debug, test, and speed up your webpages.

Cross-Browser Source Maps #

Enhance Your JavaScript Debugging with Cross-Browser Source Maps

Filmstrip View #

Starting with Chrome 44 you can generate filmstrips with Chrome DevTools

Vorlon.JS #

An open source, extensible, platform-agnostic tool for remotely debugging and testing your JavaScript.

Browsers and Bugs 17/2015

2015-05-01T06:43:17+02:00

Another friday, another new issue of Browsers and Bugs. Hello and welcome to number 17. Happy bug reporting!

Browsers, Bugs and Workarounds #

Hello my name is Edge, Microsoft Edge. #

Except from the name they also announced that you will be able to install Chrome/Firefox extension. If you want to know more do a image search 🙂

Dev channel for Chrome on Android #

Chrome’s Dev channel allows you to test out your sites using an early version of Chrome to find bugs. If you find a browser bug you might consider reporting it on the Chromium bug tracker.

Opera Turbo #

The new version of Opera for Android comes with Opera Turbo mode, automatic text-wrap and other new features.

WebKit Web Platform Status #

After Chromium and Internet Explorer now also WebKit has a web platform status page.

Pointer Events #

Pointer Events will be enabled in Firefox Nightly builds within the next few weeks.

Debugging, Testing and more #

Chrome DevTools #

A list of upcoming features including Layout mode, Animations and Color Picker.

Jank Free #

Great resources for building smooth web sites.

Chromium accessibility bugs #

If you want to get notified about all accessibility bugs in Chromium, here is the way to subscribe.

iOS WebKit Debug Proxy #

A DevTools proxy (WebKit Remote Debugging Protocol) for iOS devices (Safari Remote Web Inspector).

Browsers and Bugs 16/2015

2015-04-24T07:40:21+02:00

Hello and welcome to issue 16 of Browsers and Bugs. May your bug reports be as clear and sunny as the weather here in Berlin. Happy bug fixing!

Browsers, Bugs and Workarounds #

NCSA Mosaic #

The first web browser with the ability to display text and images inline, was released on 22.4.1993 – 22 years ago!

New features in Project Spartan #

Including Media Capture/getUserMeda, ASM.js & Generators and a lots more.

Client-Hints #

Yoav Weiss is going to implement Client-Hints in WebKit.

Web manifest #

Web manifest obtainer landed in Gecko

Debugging, Testing and more #

Ghostlab 2 #

Using Chrome DevTools to Debug JavaScript in Any Browser with Ghostlab 2.

Is Anyone Testing On Mobile? #

Debugging the Mobile Web #

Slides from Mike Taylor and Dan Callahan from their talk at Fluent conference.

DevTools Timeline: Now Providing the Full Story #

aViewer #

The accessibility inspection tool from the Paciello Group is now available as open source on Github.

Browsers and Bugs 15/2015

2015-04-17T08:09:06+02:00

Hello and welcome to issue 15 of Browsers and Bugs. Happy debugging!

Browsers, Bugs and Workarounds #

Insecure HTTP #

Both Chrome and Firefox will mark HTTP as Non-Secure in the future.

Chrome 43 #

Connecting to MIDI devices from the web, Permissions API, Upgrading legacy sites to HTTPS and more.

Opera Mini Update #

The browser’s update adds a refined menu, a private-browsing mode, and a scalable interface that allows for support on tablets and smartphones.

Emulate push events #

In Chrome DevTools there will soon be an “Emulate push event” button.

A 10-year journey of internet on a phone #

Debugging, Testing and more #

Responsive Design Mode #

Tips from Ethan Marcotte about using the Responsive Design Mode in Firefox

DevTools Terminal #

Using Your Terminal from Chrome DevTools.

WebPageTest-mapper #

A wrapper for WebPageTest-API that transforms the JSON result data into intuitive and informative human-readable formats.

Building 60 FPS Web Apps #

A free course from Paul Lewis about Browser Rendering Optimization.

Firefox OS #

You can now debug Firefox OS via WIFI.

Browsers and Bugs 14/2015

2015-04-10T04:18:44+02:00

Hello and welcome to issue 14 of Browsers and Bugs. The spring is coming here in Europe – so, go out, enjoy the sun and watch some real bugs!

Browsers, Bugs and Workarounds #

When will a fix ship in Chrome? #

A quick guide on how to track Blink changes as they make their way to releases of Chrome.

#

After Opera, Chrome, Safari/iOS and Firefox is now also supported in Project Spartan.

Mozilla and the Shadow DOM #

Brainstorming about Shadow DOM and components in general.

Debugging, Testing and more #

Dev Tips Daily #

A developer tip, in the form of a gif, in your inbox 5 days a week.

Colorblind Design #

A Firefox Add-on to simulate color blindness – great way to test if your site’s colors are accessible.

Chrome’s Console API #

Lots of useful tips on how to use the Console API. Most of this can also be used in Firefox, Opera… by the way.

How to Test for Internet Explorer on Android, iOS, and Mac OS X #

A web accessibility evaluation tool that applies the rules from a selected ruleset, and organizes the results by Rule Categories or WCAG Guidelines.

Browsers and Bugs 13/2015

2015-04-03T06:25:00+02:00

Hello and welcome to issue 13 of Browsers and Bugs. Happy debugging and may you find lots of easter eggs this weekend!

Browsers, Bugs and Workarounds #

Firefox 37 #

A new version of Firefox was released. Among small new features and bug fixes, they also fixed a 15-year-old bug regarding relative positioning of table cells

WebRTC in WebKit #

WebKit is working on implementing WebRTC in WebKit.

Opera for Android #

Opera for Android 29 beta replaces off-road mode with a new Turbo mode, offering full HTML5 experience & new compression.

Debugging, Testing and more #

Advanced Performance Audits With DevTools #

Paul Irish spent some time recently profiling real-world mobile websites including CNet, Time and Google Play.

Browser CSS/JS loading capabilities #

Great table showing which browsers support onload, onerror,….

Rendering Performance #

A fantastic guide on optimizing Rendering Performance by Paul Lewis

DevTools Console #

Chrome DevTools now supports syntax highlighting & improved styling for console.warn & console.error.

Browsers and Bugs 12/2015

2015-03-27T16:52:23+01:00

It’s friday and thus a new round of Browsers and Bugs is ready for you. Hello and welcome to issue 12. Happy bug reporting!

Browsers, Bugs and Workarounds #

[Intent to Implement: Pointer Events #

](https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/ODWmcKNQl0I)

After a lot of feedback, Chrome is now considering to implement Pointer Events. Meanwhile in Cupertino, Apple invents new events for force touch.

Partnering with Adobe #

Adobe have provided contributions in partnership with engineers on the IE team. Good to see that IE is opening a bit and looking for contributions from outside.

Status page for WebKit #

After Blink and Internet Explorer also WebKit is considering building a status page. Would be great to get more information about features in WebKit.

New CSS parser for Blink #

On most stylesheets, the new parser performed 15-25% faster.

Debugging, Testing and more #

What do you want from your DevTools? #

Have an idea to improve Firefox DevTools? You can submit your idea on UserVoice.

IE Diagnostics Adapter #

A proxy to use Chrome Devtools to debug and diagnose IE.

Third-parties #

Third-party scripts do all kind of nasty stuff, like requesting fourth-party scripts. Here is a tool to find out which hosts gets requested on your site.

Scratch JS #

A browser extension to write and execute ES6 with Chrome DevTools.

Remove console and debugger statements for production with gulp/grunt

2015-03-26T12:05:25+01:00

While writing JavaScript you will most likely use either console (console.log, console.error…), debugger; or even alert() (I hope you don’t anymore) at some point to debug your code. Showing these messages on your development server is not a problem as only »you« will see them, but if they show up on your production server everybody will see them.

Whereas console messages and debugger are only visible if DevTools are open alert() will always show up and even prompt a modal dialog. So, you most probably (*always*) want to remove these statements before pushing new code to production.

Let’s make use of our preferred build tool and remove all debug statements before deploying code to production.

Gulp #

For Gulp we can use gulp-strip-debug by Sindre Sorhus.

Here is what the task will look like if you have all your JavaScript files in src/js and want to save the cleaned up versions in dist/js.

var gulp = require('gulp');
var stripDebug = require('gulp-strip-debug');
	
gulp.task('strip-debug', function () {
	return gulp.src('src/js/*')
		.pipe(stripDebug())
		.pipe(gulp.dest('dist/js/'));
});

Grunt #

Sindre Sorhus also made a Grunt Plugin we can use.

Once again, Here is what the task will look like if you have all your JavaScript files in src/js and want to save the cleaned up versions in dist/js.

module.exports = function(grunt){

	require('load-grunt-tasks')(grunt); // npm install --save-dev load-grunt-tasks

	grunt.initConfig({
		stripDebug: {
			dist: {
					files: grunt.file.expandMapping(['src/js/*.js'], 'dist/js/', {
					flatten: true,
					rename: function(destBase, destPath) {
						return destBase+destPath;
					}
				})
			}
		}
	});

	grunt.registerTask('default', ['stripDebug']);

};

Last but not least, there is also a Broccoli Plugin if this is your preferred tool.

Conclusion #

Removing console messages before deploying code to production is nothing we should do manually – that’s a task for a build tool.

Browsers and Bugs 11/2015

2015-03-20T10:18:28+01:00

Hello and welcome to #11 of Browsers and Bugs. Happy bug reporting!

Browsers, Bugs and Workarounds #

Opera Mini #

All Opera Mini servers were upgraded to a new version – now comes with support for HTML5 input types and Flexbox \o/.

remote.ie #

Rendering engine updates in March for the Windows 10 Technical Preview.

Bug from the past #

Some things take 14 years, like event.offsetX/Y in Gecko – via @molily.

The sad state of matrix transforms #

All, but IE, fail miserably on scaling and rotating.

Debugging, Testing and more #

DevTools: State Of The Union 2015 #

Slides from @addyosmani showing new demos for Chrome DevTools. Some awesome stuff in there. Video of the talk will be available in the near future.

Fetch API #

Using the Firefox DevTools to Debug fetch() on GitHub.

Parsing errors #

Internet Explorer logs HTML parsing errors in the console. Nice!

RemoteDebug and cross-browser DevTools. One year later. #

Browsers and Bugs 10/2015

2015-03-13T13:19:56+01:00

It’s Friday and thus time for a new issue of Browsers and Bugs. Hello and Welcome to number 10. Happy debugging!

Browsers, Bugs and Workarounds #

Chrome 42 Beta #

Among other new features and bugfixes it ships with Push Notifications and an enhanced Add to homescreen function.

Opera 28 #

What’s new in Opera 28 (based on Chromium 41) for Mac, Windows, Linux and Android.

Break Up Width IE8 #

IE8 is already 6 years old and I agree that it’s time to stop supporting it.

Null-check the responsive selector in images #

This crashed some sites using img srcset. Aleady fixed in Firefox 38.

Debugging, Testing and more #

Dev Consoles Considered Harmful (…for learning) by Kyle Simpson #

The dev console in browsers is great, but it’s particularly harmful to the purposes of accurately learning JS. We need a new real-JavaScript-REPL tool, and it needs to land in a browser soon.

Animation Timeline [Video] #

Will be available soon in Chrome DevTools.

Firefox DevTools #

Developers can now inspect/debug any Firefox Popup.

Chrome Devtools Experiments #

To try out the experiments open chrome://flags -> Enable Developer Tools experiments and click “Relaunch Now” at the bottom. After restart, open Devtools, go to settings and have a look at the Experiments Tab. If you want to see all experiments, press Shift 6 times (yes 6, not 7 to activate Developer Options on Android :-)) while the experiments tab is open.

DOMListener #

A Chrome DevTools Extension to monitor, browse and filter all DOM changes.

Dynamic responsive background images

2015-03-12T08:57:39+01:00

This morning I saw a Tweet from Anselm Hannemann asking »What’s the best way to add dynamic responsive background images?« and after some quick tests I came up with the following solution.

Here is the HTML:

<div class="bg-image">
  <h1>Dynamic Background</h1>
</div>

Then we add some general CSS:

.bg-image {
  position: relative;
  background-size: cover;
  height: 20em;
}

And now comes the interesting part, let’s assume we use PHP and have access to the following dynamic background images and sizes we then can use in our HTML:

$image['small'] // contains the value for the small image for a post, eg. '/postid/small.jpg'
$image['big'] // contains the value for the big image for a post, eg. '/postid/big.jpg'

Now we can add an <style> element to the <head> of our site defining the different background images for different sizes:

@media all and (min-width: 501px) {
  .bg-image {
    background: url(<?php echo $image['big'] ?>) no-repeat 0 0;
  }
}
@media all and (max-width: 500px) {
  .bg-image {
    background: url(<?php echo $image['small'] ?>) no-repeat 0 0;
  }
}

By using min-width and max-width media queries we ensure that only the appropriate image is loaded. For more info see this test by Tim Kadlec.

In this example, I used PHP (yes old style, but simplest for me to set up the tests), but you can use this technique also with other languages and also on static sites (eg. Jekyll).

I also put together a demo on jsbin to demonstrate it. If you find any disadvantages or improvements of this technique please let me know on twitter.

Browsers and Bugs 09/2015

2015-03-06T09:00:50+01:00

Hello and Welcome to issue 9 of Browsers and Bugs. Happy testing!

Browsers, Bugs and Workarounds #

Opera Mini #

First look at the new Opera Mini beta for Android

Firefox Developer Edition 38 #

App install banners #

Blink – Intent to Implement: API to support web/native app install banners

Mozilla Location Services to replace Google’s geolocation service in Firefox #

Shadow DOM #

Blink – Intent to Implement: Shadow DOM – closed mode

Debugging, Testing and more #

Blackbox JavaScript Source Files #

Useful if you want to skip third-party Code while debugging in Chrome

Amok #

Live Edit JavaScript with Amok

Konsole.js #

Konsole.js is a On-Screen Debugger/Logger and (optionally) default browser console replacement.

High performance touch interactions #

Demo - Responsive Pop-out Menu

2015-03-03T14:31:57+01:00

I am currently redesigning my website and therefore also the navigation. There are loads of different navigation pattern and I made many myself in the last years. However, I searched for a different solution again as none of the patterns I know offers the following points I had in mind:

It should work well without JavaScript.
On small screens, all menu items should be easily reachable
Important menu items should always stay in the beginning

1) Should work without JavaScript #

This is simple to achieve, I used the Cut the Mustard technique to only serve JavaScript to modern browsers and then add class=”js” to the html element to be able to style the menu differently. I also add EventListener to open/close the menu.

Here is the complete JavaScript:

(function (doc) {
	// CTM, only init JavaScript for modern browsers
	if ('visibilityState' in doc) { 

		// Add class to html elment once js is available
		doc.documentElement.className = 'js';
		
		// Add Eventlistener to open/close menu
		var menuLayer = doc.getElementById('is--menu-layer'),
			menuClose = doc.getElementById('is--menu-close'),
			menuOpen = doc.getElementById('is--menu-open');
		
		function openMenu () {
			menuLayer.className = 'is--menu-opened';
		}

		function closeMenu () {
			menuLayer.className = '';
		}

		menuClose.addEventListener("click", closeMenu, false);
		menuOpen.addEventListener("click", openMenu, false);
	}
}(document));

On older browsers and devices without JavaScript the menu items will always stay visible and will align to the left.

Smartphones are getting bigger and bigger and thus it becomes quite hard to reach menu items in the upper-left corner. Thus, I made an wrapper around the menu list and set it to position: fixed (yes, this is dangerous on some devices but with the CTM technique above this only applies to browsers where support is good enough). Next, I set the menu list to position: absolute and position it down in the right corner. This way all the items are reachable quite easily with one thumb.

While all the items are now aligned at the bottom, the most important items (usually first in order) are still at the top. To change it, I used this technique to reverse the order of the items and, therefore, show the most important item at the very bottom.

.js .navigation ul {
	-webkit-transform: rotate(180deg);
	-ms-transform: rotate(180deg);
	transform: rotate(180deg);
}
.js .navigation li{
	-webkit-transform: rotate(-180deg);
	-ms-transform: rotate(-180deg);
	transform: rotate(-180deg);
}

Here is a screenshot of the opened menu on Android:

Code #

Here is the demo and you can find all the demo files on Github.

If you find any bug please open an issue on Github.

Browsers and Bugs 08/2015

2015-02-27T07:49:40+01:00

Hello and Welcome to issue 8 of Browsers and Bugs. Happy testing!

Browsers, Bugs and Workarounds #

The Pointer Events specification became a W3C Recommendation. #

Posts on standards & Apple’s influence: Tired of Safari by PPK, Apple’s Web by Tim Kadlec and Apple, Business, and Standards by Aaron Gustafson.

Firefox Version 36.0 #

Unicode-range, object-fit, will-change & Promise inspection arrive in Firefox

Fetch Event support in Firefox Nightly #

A break from the past #

The birth of Microsoft’s new web rendering engine

Bug 330884 #

This privacy flaw has caused my fiancé and I to break-up after having dated for 5 years.

Spartan To Remove The 300ms Delay, Pointer Events Become W3C Recommendation #

PolyBrowser #

New browser build on top of Firefox

Debugging, Testing and more #

DevTools for Designers #

Explore what Chrome DevTools could do for designers.

Node reordering by drag/drop in Firefox DevTools inspector! #

Will soon land in Firefox Nightly Builds.

cubic-bezier #

Editable cubic-bezier easing graphs (plus frames view) now in Chrome Canary.

Promise debugging support now in Firefox Devtools #

Chrome Devtools extensions for ClojureScript developers #

Cut the mustard revisited

2015-02-26T09:49:02+01:00

Cutting the mustard is a term coined by the BBC team (post) to group browsers into »modern« browsers and »old« browsers. This is not done by sniffing the User Agent but by using Browser Feature Detection. Here is the JavaScript that decides whether the browser is modern or old.

if('querySelector' in document && 'localStorage' in window && 'addEventListener' in window) {
     // Modern browser. Let's add JavaScript functionality
}

With this in place, we have two groups of browsers, modern (IE9+, Fx, Safari, Opera, Chrome, iOS, Android 2.1+, …) and old (IE8-, Blackberry, …). I used the same check in the last years. I don’t have to care about JavaScript implementation and errors in old browsers as I only serve JavaScript to modern browsers and I know which JavaScript features I can use safely. It works out great most of the time.

However, this morning I saw a tweet from Jake Archibald which made me think about my current CTM check.

if (!('visibilityState' in document)) return; A nice way to prevent your JS running in IE<10 and Android WebKit http://t.co/yjbUnyaobV

— Jake Archibald (@jaffathecake) February 26, 2015

Looking at the browser support of Page Visibility and some statistics in recent projects I can say that only adding JavaScript for this group of browsers makes more sense nowadays than the old check. Android-4, IE9, and others lack support for many features we want and can use today and if you start a project now the percentage of users using such a browser will be even lower than they are already.

While the check mentioned by Jake is great, I immediately thought about extending it and adding a check for ServiceWorker to improve performance for browsers supporting it and for adding offline support. So here is my new check I will use in most of my projects from now on:

if ('visibilityState' in document) { 
    // Modern browser. Let's load JavaScript
    if ('serviceWorker' in navigator) {
        // Let's add offline support
        navigator.serviceWorker.register('sw.js', {
            scope: './'
        });
    }
}

If you are unfamiliar with ServiceWorker, I recommend this interactive introduction and if you are searching for a way to generate service worker code, I can recommend this node module that will precache specific resources.

Conclusion #

So, can or should I also use this CTM check? Often, well probably most of the time, it depends! It depends on your audience (study your statistics), it depends on the functionality used on your website or application – it depends on many things. However, using Cut the Mustard (in this way or another) is a perfect example of Progressive Enhancement. Web sites doesn’t need to look exactly the same in every browser and old browsers don’t need all the functionality modern browsers offer as long as the same content is available for all. Don’t bloat old browsers with tons of polyfills to get modern JavaScript features working there and make your life as a web developer unnecessary hard by trying to learn an old car flying.

Follow me on twitter

[Share via Twitter](https://twitter.com/intent/tweet?text=Cut the mustard revisited%20https://justmarkup.com/log/2015/02/cut-the-mustard-revisited/)

Browsers and Bugs 07/2015

2015-02-20T10:00:41+01:00

It’s Friday and this means a new roundup of Browsers and Bugs. Welcome to issue number 7. Happy debugging!

Browsers, Bugs and Workarounds #

asm.js #

Bringing asm.js to the Chakra JavaScript engine in Windows 10

Responsive Images #

Srcset attribute and picture element for responsive images will land in Firefox 38

SVG Webkit Bugs #

I still can’t believe it but looks like Safari is finally listening to Developers \o/ So better add your bugs now!

Bug 1134506 #

Mark “Superfish, Inc.” root certificate as untrusted in NSS. You can find more info about Superfish here.

State of Blink #

Keynote about the current state and future of Blink

HTTP Strict Transport Security comes to Internet Explorer #

Debugging, Testing and more #

Chrome Devtools Tips and Tricks Part I #

Pick color with an eye dropper straight from Dev Tools #

Paul Kinlan demoes the color picker in Chrome DevTools

Tenon.io #

Solve WCAG 2.0 & Section 508 issues before they happen with our robust, flexible, and easy API

Stetho: A new debugging platform for Android #

Browsers and Bugs 06/2015

2015-02-14T08:40:48+01:00

Hello and welcome to #6 of Browsers and Bugs. Happy bug reporting!

Browsers, Bugs and Workarounds #

Hello HTTP/2, Goodbye SPDY #

Chrome plans to gradually roll out support for HTTP/2 in Chrome 40 in the upcoming weeks.

Internet Explorer in the Windows 10 Technical Preview for phones #

First preview of Project Spartan for Windows phones.

How browser developers should seek feedback from Web developers #

Introducing Firefox Service Worker Builds #

Test an early implementation of Service Worker in Firefox and help find bugs

Contributing to Chromium: an illustrated guide #

Debugging, Testing and more #

Media Query inspector #

In Chrome DevTools, toggle Media Query inspector to see media queries from your stylesheets. Right-click for source.

CSS Shapes Editor for Opera DevTools #

#a11y inspection functionality #

Work in progress to include Accessibility Developer Tools functionality into Chrome DevTools

How to Use Bugzilla to Efficiently Squash Bugs #

Input type email – better don’t use it!

2015-02-13T11:07:51+01:00

Last update: 21.03.2017 – updated browser support for Chrome, added info about punycode in Chrome

tl;dr If you want to use input type=”email”, be aware that international email addresses (containing Umlaut, non-latin characters…) are not supported in every browsers and you may exclude users using such an email address from using your service. Furthermore, the current version (56) of Chrome translates international addresses to punycode, so if a user registers with test@ö.at, the value you will receive will be test@ö.at in Chrome but test@ö.at in all other browsers supporting international email addresses. So, think twice and be careful using it!

According to a survey by Peter-Paul Koch input type=”email” is the most used advanced input type. Which makes sense in my opinion as almost every site using a form also has a field for email. So, at a first glance it seems perfect to use it, browsers who support it will validate it, most mobile browsers will add the @ sign to the keyboard and most importantly, if a browser doesn’t support it, it falls back to type=”text”.

However, at a second glance, you will find out that it comes with some disadvantages and unexpected behaviors.

Validation #

You can use type=”email” to validate the value of the input. I put together a simple test to find out which browsers accept which values for input type=”email”.

Here are the values I tested:

test
test@
test@test
test@127.0.0.1
test@test.test
test.O’test@test.com
test@testä.com
test@郵件.商務
test@मोहन.ईन्फो
testρ@εχαμπλε.ψομ
!#$%&’*+-/=?^_`.{|}~@test.com
user+mailbox/department=shipping@example.com

Expect from 1 and 2 (which are invalid email addresses in any case), most browsers (expect from Firefox and Chrome – see Note 1) also invalidates 7 (Umlaut), 8 (Chinese), 9 (Hindi) and 10 (Greek). This list is far from complete, there are lots of languages with different writing systems.

Image by George Tsiagalakis [CC BY-SA 3.0], via Wikimedia Commons

* Note 1: Firefox added support for international emails in Version 26 and Chrome also supports them (at least since version 56 – couldn’t find exact information when it was added).

Unexpected values #

In the latest Chrome version (56) international email addresses are now supported, but Chrome handles it different from Firefox. Chrome is transforming international email addresses to punycode, so if the input value is test@ö.at the value will be test@ö.at.

You can test it yourself in this jsbin.

This can lead to a lot of trouble, imagine a user registers with test@ö.at in Chrome, you will save test@ö.at as the email in the database. Now, the next time the user is using Firefox to login to your site using test@ö.at and the correct password, access will be denied as in Firefox the value send is test@ö.at (which you don’t know about) and not test@ö.at. The only way this can be solved is by checking if the value contains punycode on the server side and decode it there.

As far as I interpret the Specification the way Chrome is handling it is correct, but I may misread this.

In any case we have different behaviours in different browsers at the moment and if you don’t want to handle it on the server side you better avoid input type="email" for the time being.

A regex a day… #

If you want to validate against international email addresses and exclude domains with no TLD input type=”email” is not really our best bet. So, RegExp to the rescue you may say. Well, I thought so too but soon realized that a regular expression for this is way over my head. So, I asked Mathias Bynens for help on twitter and he pointed me to a StackOverflow answer where he shows how to generate regular expression for different Unicode writing styles.

While in theory it is probably possible to generate a Regex which matches every valid international email address I won’t still not trust it. Which brings me to the following conclusion – please do not use a pattern for email validation. Every regular expression for email validation is missing something. Lots of people gone through the process with the conclusion, that it is nearly impossible to get a perfect validation. If you don’t care about international email addresses use type=”email” without the pattern attribute.

For reference here is the regular expression defined by the W3C for a valid email address (this does not include international email addresses):

/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

Conclusion #

From my part, I will not use input type=”email” anymore in any of my projects. Preventing potential users for signing up with their email address (which may contain umlaut, non-latin characters…) is for me more important than semantic, validation and the @ on some virtual keyboards.

If you would like to see international email address validation for input[type=email] in Microsoft Edge, please vote for it on Windows Uservoice, thanks!

Browsers and Bugs 05/2015

2015-02-06T12:05:00+01:00

Welcome to issue 5 of Browsers and Bugs. Happy testing!

Browsers, Bugs and Workarounds #

display: contents #

Intent to ship: CSS display:contents in Firefox

A message From Opera to Google #

Security Bug in IE11 #

Serious bug in fully patched Internet Explorer puts user credentials at risk

Chrome continues to fall apart at brisk pace #

There are loads of different Chromium-based Android default browsers

Windows Substitutes Helvetica for Arial #

Debugging, Testing and more #

Introducing node-firefox #

A post explaining what node-firefox is and how can it help you superturbocharge your Firefox OS app development

A new release of the Web Accessibility Toolbar for Internet Explorer

Empty Cache & Hard Reload options in Chrome #

The curious case of the disappearing Polish S #

One keyboard bug three decades in the making

Prioritize loading of background images

2015-02-02T16:37:47+01:00

Last Update: 12.05.2015

Initially, I wanted to find a way to lazy-load background images, but all my tests confused me completely and I thought I should better move on with my daily tasks. Some days later, however, I was reading an article on medium.com and while the page was loading I recognized that the big background image was not appearing until the page has loaded completely. And there it hits me, is there a way to prioritize the loading of a background image so it will be shown earlier? So, I set up some more test and found out there is indeed a solution for it.

Tests, Tests, Tests #

I made all in all 9 tests and ran each one against 5 different browser/bandwidth combinations on Webpagetest (Chrome on Cable, Chrome on 3G, IE10 on DSL, Firefox on Cable and Chrome Mobile on 3G). I put together a site with all the results and details about every test.

How it works #

Let’s have a look at some code to see how prioritizing the loading of background images works.

Here is the HTML for the header image:

<div class="header-img"><img style="display: none;" src="images/header-img.jpg" alt=""></div>

And here is the CSS:

.header-img {
    width: 100%;
    height: 500px;
    background-size: cover;
    background-image: url(images/header-img.jpg);
}

First of all we insert an image element and set the src attribute to the same image file as the background image we want to use. We also hide the image with display: none;. This avoids that the image gets shown visually while still ensuring that the image gets requested by the browser. This means that the image is already available before any other background image gets loaded. Thanks to the browser preloader!

Video comparison #

Here is one of the video comparison from my tests, the one in the middle (test2) uses the »preload background image via img« approach and as you can see the image is visually completed before the others.

.embed-container { position: relative; padding-bottom: 33%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

Conclusion #

What I like most about this approach is that no JavaScript is needed. You can like or hate the trend of showing big background images on websites but if you use it and want to make it visible as fast as possible this technique may be the solution. Furthermore, it seems that this technique also improves overall performance of page load – have to test this in more detail though.

I hope this technique is reasonably and that I haven’t missed anything. Otherwise, please let me know.

Update 12.05.2015 – adding responsive image example #

As @clmnsk mentioned on twitter, this technique can also be used in combination with responsive images, more accurately by using srcset and media queries. Here is the example from above using three different images for three different screen sizes:

Here is the HTML for the header image:

<img src="images/header-img_small.jpg" srcset="images/header-img_small.jpg 600w, images/header-img_medium.jpg 900w, images/header-img_large.jpg 1200w" alt="">

And here is the CSS:

.header-img {
    width: 100%;
    height: 500px;
    background-size: cover;
    background-image: url(images/header-img_small.jpg);
}
@media all and (min-width: 600px) {
    .header-img {background-image: url(images/header-img_medium.jpg);}
}
@media all and (min-width: 900px) {
    .header-img {background-image: url(images/header-img_large.jpg);}
}

Browsers and Bugs 04/2015

2015-01-30T11:09:09+01:00

Hello and welcome to the fourth issue of Browsers and Bugs. The biggest news this week definitely was the announcement of “Project Spartan”, a great move in the right direction from Microsoft. Happy debugging!

Browsers, Bugs and Workarounds #

Project Spartan #

Microsoft announced that Windows 10 will ship with a brand new browser, codenamed “Project Spartan.” You can test it on modern.ie.

Changeset 179132 #

WebKit fixed the issue with querySelectorAll and camelCase elements like SVG’s linearGradient.

Firefox Bug 1052417 #

Default `sizes` attribute value for `srcset` should be 100vw

Vivaldi #

Ex-Opera CEO composes Vivaldi, a new Web browser

All of This Has Happened Before and Will Happen Again #

The horror of a WebKit-only world.

How Browsers Work: Behind the scenes of modern web browsers #

A must-read for every web developer

Debugging, Testing and more #

F12 developer tools #

Updates for the F12 developer tools in the Windows 10 January Technical Preview

Using ARIA 1.0 and the WebKit Accessibility Node Inspector #

Using the FirefoxDevTools to understand CSS demos #

The 5 Stages of Debugging #

via [@abt_programming](via https://twitter.com/abt_programming/status/556088278886383617/photo/1)

Restart CSS Animation (using CSS to trigger a reflow)

2015-01-26T18:13:34+01:00

Lately, I wanted to run an animation on page load and the same animation again on :hover. After some debugging I figured out this doesn’t work as expected.

Here is the simplified CSS showing my problem:

/* a simple animation */
@keyframes test {
  0% {background: red;}
  100% {background: blue;}
}

div {
  animation: test 4s ease-out;
}

/* run the animation again on hover, won't work this way */
div:hover {
  animation: test 4s ease-out;
}

After a quick search, I came across this article on css-tricks.com where Chris and Oli show techniques to solve this problem. The conclusion is that you can either use JavaScript or as Oli Studholme researched, use an identical @keyframes animation with a different name for :hover. As the article and research are quite old (in terms of web development 4 years is actually really old) I started a new jsbin and tried to find a different solution. After some trial and error, I found another way using CSS.

So here it is:

/* a simple animation */
@keyframes test {
  0% {background: red;}
  100% {background: blue;}
}

/* Trigger reflow */
@-webkit-keyframes test1 {
  to {width: auto;}
}

div {
  animation: test 4s ease-out;
}

/* run the animation again and again on hover, check! */
div:hover {
  animation-name: test1;
}

The trick is to add a second animation, which animates the width (can also be auto as you can see, so the width won’t change actually) to trigger reflow, to :hover. Try it out on jsbin.

It’s working in Firefox, Opera, Chrome and IE10 upwards.

Any question? Contact me.

Browsers and Bugs 03/2015

2015-01-22T15:33:35+01:00

As I will be in Oslo this weekend starting from tomorrow, you can enjoy this weeks Browsers and Bugs already on Thursday. Happy bug fixing!

Bugs and Workarounds #

Filing browser bugs #

by Steve Faulkner

Parallel JS #

PJS will be removed from the SpiderMonkey code base

We have fixed the crazy fixed-background scrolling-jitters bug in Internet Explorer. #

via @jonathansampson

Force page zoomability via settings on Firefox for Android #

Bugzilla and the Future of Firefox Development #

New Opera Beta for Linux #

Mostly minor changes and a fix for an annoying Facebook bug

Debugging, Testing and more #

Discover DevTools #

Interactive course for Chrome DevTools

New in Firefox Nightly DevTools #

View scheduled AudioParam automation values

What bug? There is no bug #

via @CommitStrip

Load module-dependent JavaScript with basket.js

2015-01-19T14:13:11+01:00

I tried different scripts, here is a spreadsheet of some of the JavaScript loaders available, but in the end I went with basket.js. Mostly because it uses local storage, it can order dependencies and supports loading of multiple scripts.

Code #

Here is my approach to load JavaScript for page modules:

var version = 1,
  isModern = 'querySelector' in document && 'localStorage' in window && 'addEventListener' in window;
if (isModern) {
  /* "HTML5" browsers */
  document.documentElement.className = 'js';
    /* load scripts/libs necessary for all pages */
    basket
      .require({url:"dist/js/base.min.js", unique: version})
        .then(function(){
          /* load fonts, see http://bdadam.com/blog/loading-webfonts-with-high-performance.html */
          basket.require({url:"dist/js/fonts.js", unique: version});

          [].forEach.call(document.querySelectorAll('.js-module'), function(module) {
            /* load js for every module present on the current page
            * example: class="js-module js-module-gallery" data-module-name="module-gallery"
            */
            var src = 'dist/js/modules/' + module.dataset.moduleName + '.js';
            basket.require({url: src, unique: version});
          });
        })
  });
} else {
  /* "HTML4" browsers */
}

Here is what the HTML looks like for a module (in this case an embed tweet).

<div class="js-module js-module-twitter" data-module-name="module-twitter">
  <blockquote class="twitter-tweet" lang="en">
    <p>DevTools Wishlist: emulate (low) RAM, GPU and CPU</p>
    Michael (@justmarkup) 
    <a href="https://twitter.com/justmarkup/status/555801249866854400">January 15, 2015</a>
  </blockquote>
</div>

And in the JavaScript file dist/js/modules/module-twitter.js the widgets.js from Twitter will be loaded to change the static blockquote into the interactive tweet version.

Advantages #

JavaScript is loaded async
On repeated view the scripts are served from local storage (decreases requests)
Module-dependent JavaScript only gets loaded if module is visible on the page (Eg. you probably don’t need the twitter embed widget on every site)
Progressive enhanced (if a user uses an old browser, JavaScript is not available or fails to load you still get to see the content)

Further improvements #

If you use modules with a lot of extra CSS, you may also want to load this CSS dependent on your module, here is an example showing how you can achieve this with basket.js.

What do you think? #

I am really curious what you think about my way of loading JavaScript for page modules. Are there any disadvantages I miss? Let me know!

Browsers and Bugs 02/2015

2015-01-16T10:29:17+01:00

It’s Friday and this means a new roundup of Browsers and Bugs. Happy debugging!

Bugs and Workarounds #

Letterspacing disables OpenType features in Chrome and Opera #

Demo and explanation on Codepen

Firefox 35 was released #

Besides lots of bug fixes it comes with support for WOFF2 fonts and the CSS Font Loading API (although still behind a flag)

Bug Life Cycle and Reporting Guidelines #

Tips for reporting bugs in Chromium

ally.js by Rodney Rehm is a library to help applications with accessibility concerns. Among other things it includes fixes for working around browser bugs

Sad Bugreporter of the week #

Debugging and Testing #

Accessibility Developer Tools #

An Addon for Chrome DevTools

Understanding your website through the IE11 F12 tools #

Conference talk by Martin Beeby about DevTools in Internet Explorer

New animation inspector panel in Firefox 37 #

Firefox will integrate animation inspector into DevTools starting with version 37.

The download attribute

2015-01-13T08:38:38+01:00

The download attribute indicates the browser that a link should trigger the “Save as…” dialog instead of opening the file directly in the browser.

Here is an example:

<a href="/363946739467/64634.jpg" download="custom-filename">Link</a>

As you can see you can specifiy the filename (in the example custom-filename) the file should be saved as, the extension will be added automatically.

Use cases #

There are various handy ways to use this attribute. You can use if for pdf files (which in some browsers get opened directly in browsers), which you want to be saved locally, eg. tickets. Another use case could be a Download-Section for your logos or link to music files. It is also great if you have a gallery and want to offer a “download fullsize image” link.

Demo #

Demo-Link without download attribute
Demo-Link with download attribute (filename set to justmarkup)

Browser Support #

See support on Can I use. It’s currently (Jan 2015) not supported in Internet Explorer (Under Consideration) and Safari and there are some problems on Linux (Known issues). But as it’s not breaking anything if a browser doesn’t support it, you can use it safely today.

Show filesize #

When providing a Download-Link you should also consider showing the size of the file. This will help the user to decide if it’s worth to download the file. Always remember that a user may use Roaming (and yes also on Laptops) and don’t want to waste his limited bandwidth. Detecting the file size is not possible on the client-side but can easily be done server-side.
Here is an example for php:

<?php echo filesize($filename); ?>

And if you use Node.js you can use the following code:

function getFilesizeInBytes(filename) {
    var stats = fs.statSync(filename)
    var fileSizeInBytes = stats["size"]
    return fileSizeInBytes
}

Conclusion #

The download attribute is really helpful and can be used in many ways to enhance the user experience. You should consider using it when linking to big files or files which should be downloaded.

Browsers and Bugs 01/2015

2015-01-09T08:24:41+01:00

There are probably more browser bugs than real bugs so I thought why not collect them and give a shout-out to the best ones crossing my way. So, this marks the beginning of a weekly roundup of my favorite browser bugs, best workarounds and other browser bugs related issues. Enjoy! As an extra, I will share tips/features/improvements for testing at the end.

Bugs and Workarounds #

Flexbugs #

Let’s start with a fantastic list of cross-browser flexbox issues and their known workarounds by Philip Walton.
Article and Github Repo

The Chrome CSS Bug That Crashed Our Site #

Chrome has issue calculating inset box-shadows with large numbers. Fix will probably land in Chrome 40.

Bug writing guidelines for Firefox #

Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.

Bugreport from the past (still open) #

Bug 129986 (from 2002) – Cached Gif animations don’t reset on reload.

Happy Bugreporter of the week #

Debugging and Testing #

Animation controls in Devtools (Chrome Canary) #

Val Head shares a sceencast showing how to use the animation play/pause and speed control in Devtools.

IE test VMs on modern.IE get a refresh #

VMs to help web developers test versions of Internet Explorer

Give forms some extra attention

2015-01-06T09:24:20+01:00

Some weeks ago I saw a great example of a login form with a lovely extra. On this login site, once the password field is focused, the owl, sitting on top of the form, hides her eyes, showing that the password can not be seen by others and therefore is private. I had to grin the first time I saw it and I am still impressed by the perfect association with privacy.

Thinking about other ways to enhance an input experience I came up with some ideas by myself.

Show a special cursor #

We can use the cursor property to show a “closed” eye once you hover over the password field. This can be done with the following CSS:

.field-password {
    cursor: url(https://justmarkup.com/images/journal/eye-blocked.png), auto;
}

Here is the example on jsbin.

Show fun facts #

Let’s say you have a sport site where users have to register to interact (eg. to comment on an article). Also assume you have a field for birthday in your form. Wouldn’t it be great if you could use a database of famous athletes and their birthdays (which you may already have) and once the user inserts his birthday, you could show a hint like “You are born the same day as Michael Jordan”. It’s a great association with the interest of your site and the user and furthermore gives the form some personality.

Show days until next birthday #

I have seen this already somewhere on a live site, but couldn’t remember where (if you know of an example, please let me know). The idea is to show the user the amount of days until her/his next birthday. You could use for example JavaScript to calculate the days and show it in a little hint after the user inserts the date of birth. You could even take this one step further and show a little birthday animation if the day really happens to be the birthday of the user.

Conclusion #

As you can see there a many ways to enhance forms. It’s the little big details that will make your site outstanding.
I think it’s really worth to go the extra mile and enhance your form with a nice feature. We all have to enter data into forms every day and all know how boring this can be. Giving your forms an outstanding characteristic will make them unique, more fun and pleasant to use.

If you know any other forms with a neat extra, please let me know @justmarkup

Share quotes via twitter

2014-12-18T12:08:19+01:00

Some days ago Christian Heilmann (@codepo8) wrote “Great publishing works with the medium, not against it”, where he argues against posting images with quotes on twitter. I totally agree with him, images with text included are a bad way to spread the word.

This reminded me about an idea I had some months ago. The idea is to have a classic tweet link (http://www.twitter.com/share) at the bottom of the page and once you select a text, the text gets highlighted and you see a share button above the text.

After clicking “Tweet” you will get redirected to twitter with the selected text filled in the textarea. Furthermore you will notice that after selecting a text, the text will be added to the hash of the url. This way I can later reference the tweet with the text you selected, even if you decide to shorten/change the text of your tweet.

Where is the quote? #

This is in fact not a new idea, medium.com and feedly, just to name two, already use similar share buttons. The new part about my script happens once somebody clicks the link you posted on twitter. After the page opens, the script grabs the quote from the hash, highlights the text and scrolls directly to the emphasized text. This way you can share quotes without the need of making a screenshot of the selected text and posting that as an image. Pretty neat, eh?

The nice thing is that the highlight part works in almost every browser (if JavaScript is available).

Furthermore if you are on a touch device or any older browser where the selection is not available there is still the tweet button sitting at the bottom ready to use.

It needs more testing though, but I am quite happy with the current state, here is an example.

The code is on Github and any help is more than welcome. Especially tests for older browsers, ways to get the selection part working on touch devices and accessibility improvements.

Reverse order of elements with CSS

2014-11-28T11:41:11+01:00

Reverse with transform #

This is done by setting transform: rotate(180deg); for the ol, and transform: rotate(-180deg); for every li element.

Transform was certainly not build for this task, but it is animatable and browser support is very good.

Specification: W3C Working Draft
Browsersupport: Can I use
Animatable: yes
Example (hover over list to reverse order): http://jsbin.com/diqata/1

Reverse with flex-direction #

After posting my example with transform on twitter, Sven Wolfermann suggested using flexbox, more specific flex-direction: column-reverse; for this task.

I haven’t used flexbox very often and obviously not thought about it. If you look it up on MDN it says » Behaves the same as row but the main-start and main-end points are permuted. « . Exactly what we want, no hack involved and thus perfect for our use case.

But it also has some disadvantages: It isn’t animatable and browser support is currently not as good (IE10+) as for transforms.

Specification: W3C Working Draft
Browsersupport: Can I use
Animatable: no
Example (hover over list to reverse order): http://jsbin.com/diqata/1

Conclusion #

If you are already using flexbox, flex-direction is probably the right choice. Though, if you want transitions or broader browser support the transform trick is a good alternative.

Know any other ways to reverse order with CSS, please let me know.

Overview of Static Map solutions

2014-05-27T07:53:57+02:00

For a recent redesign we mananged to reduce the page size to under 500kB for almost every part, expect the sections where we included a dynamic map. The size of an average dynamic map was about 600kbB, thus we had to find different ways to show a map and came across Static Maps, which turned out to be the perfect solution for us.

Static Maps are relatively lightweight, can be customized and are the ideal candidate for progressive enhancement.

I found the following solutions:

Google Maps
OpenStreetMap
Nokia HERE
Yandex

Google Maps #

First of all, Google Maps. As described in the Developer Guide there are quite a few options to change the style of the map, add markers, paths and polygons. There are also various Map Generators available to help get you started.

Example:

Code:

http://maps.googleapis.com/maps/api/staticmap?center=Brooklyn+Bridge,New+York,NY&zoom=13&size=600x300&maptype=roadmap
&markers=color:blue%7Clabel:S%7C40.702147,-74.015794&markers=color:green%7Clabel:G%7C40.711614,-74.012318
&markers=color:red%7Clabel:C%7C40.718217,-73.998284&sensor=false

Restrictions #

The maximum image size is 640×640 (or 1280×1280 if you use scale=2) for the free version and 2048×2048 for the Business version.

The maximum quota per day is 1000 Static Maps image requests per IP address per 24 hour period and 25 000 Static Maps image requests per day if you use the Google Maps API for Business.

OpenStreetMap #

There are different ways to use OpenStreetMap Static Maps. As with Google Map all of these options comes with ways to customize the map. In most cases I would recommend either setting up your own web service or using the free online services available. If you however want to use a very specific map there are also paid plans available.

staticMapLite PHP webservice
Tyler Python webservice
MapQuest Online Service (Free)
MapBox Online Service (Free Plan available)

Code:

http://open.mapquestapi.com/staticmap/v4/getmap?key=Kmjtd%7Cluu7n162n1%2C22%3Do5-h61wh&size=600,200&zoom=3¢er=35.60395,-98.906248&type=sat&pois=yellow_1,33.748867,-84.388185,0,0|yellow_1,29.763066,-95.363351,0,0

Restrictions #

The solutions staticMapLite and Tyler which you can host on your own server comes with no restrictions.
If you use Mapquest the maximum image size is 3840×3840 and there is no quota as far as I can see.
MapBox has a size limit of 1280×1280 and the quota depends on your plan (3000/month for the free plan).

Nokia HERE #

Nokia HERE also offers a Static Map solution. To use it you have to create an API Key.
As you can see in the examples there are various ways to style a map, including heat maps and picture-in-picture maps.

Example:

Code:

http://image.maps.cit.api.here.com/mia/1.6/mapview?app_id=DemoAppId01082013GAL&app_code=AJKnXv84fjrb0KIHawS0Tg&c=62.24167616,25.74536193&h=300&w=400&z=8&pip

Restrictions #

The free plan has a limit of 10,000 requests / day and as far as I can see there are no restrictions regarding image size.

Yandex #

Last but not least also Yandex offers a Static Map API. It also offers basic options to set markers, define lines and polygons but lacks support for different styles.

Example:

Code:

http://static-maps.yandex.ru/1.x/?lang=en-US&ll=32.810152,39.889847& \ 
size=450,450&z=10&l=map&pt=32.810152,39.889847,pm2rdl1~32.870152,39.869847,pm2rdl99

Restrictions #

The maximum size allowed for the map display is 650×450 pixels and the maximum requests per day is 25,000.

Conclusion #

Every solution has pros and cons and it’s up to you which solution works best for you and if you are either willing to pay or can live with the restrictions. If you however want no restrictions and be independent the best way is to host one of the OpenStreetMap solutions by yourself.

Maphancement – progressive enhanced Google Map

2014-05-11T11:50:39+02:00

For most websites I build these days I have to integrate a map, mostly as a bonus for the contact page. Until now I simple used an Iframe loading a Google Map with the desired address centered. This however comes with a cost, even a realativeley small map loads ~600 KB (See this example of a 400×200 map).

That’s why I searched for a way to show the address in a visual way without loading unnecessary data and stumbled across Static Maps. Showing the example from above as a static map, we save ~550 KB, which is fantastic for news for performance.

![Static map of Brooklyn Bridge, New York, USA](https://maps.googleapis.com/maps/api/staticmap?center=Brooklyn+Bridge,New+York,NY&zoom=13&size=600x300&maptype=roadmap&markers=color:blue|label:S|40.702147,-74.015794&markers=color:green|label:G|40.711614-74.012318 &markers=color:red%7Clabel:C%7C40.718217,-73.998284&sensor=false)
Example of a Static Map

Ok, problem solved? Well, you could offer an additional link to the full map to give users a way to navigate through the map and you are probably good to go. Thinking about some of clients I know, this isn’t enough, they want a dynamic map directly on their site. And that’s way I created Maphancement (silly play of words from map and enhanced). It is a tiny JavaScript code which converts the static map into a dynamic map once the user interacts (clicks, drags) with the map. This way we still loose ~90% of KB on first page load, whereas we can still offer a dynamic map if desired.

You can find more infos and the code in the Github Repo.

Notify me … the Notification API in use

2013-09-24T10:14:15+02:00

In this article I am going to show you the current status of the Notification API, explain different browser implementations and show off how to use the API.

Browser Support #

At the moment (August 2013) the following browsers support the Notification API. For further details, check the current status on caniuse.com.

Firefox 22+
Chrome 5+
Safari 6+ (only on Mountain Lion)
Blackberry 10
Firefox for Android
Firefox OS

Introduction #

The Notification API allows you to display notifications to users outside of a web page without the need of any interaction by the user. This way you can notify the user even if the browser is currently not in focus, and remind him of new emails, tweets or whatever you may think the user needs to know right now.

Check for support #

Well, if we would only want to know if a browser fulfils the official W3C Specification, we could simple check for

"Notification" in window

, but as old WebKit browsers and Firefox for mobile have different implemenations, the final check is:

var NotificationIsSupported = !!(window.Notification /* W3C Specification */ || win.webkitNotifications /* old WebKit Browsers */ || navigator.mozNotification /* Firefox for Android and Firefox OS */) {}

Ask for permission #

Before we can show a Notification users have to grant permission. On Firefox OS this can be done within the manifest.webapp by setting the appropriate permssion for Desktop Notifications.

"permissions": { "desktop-notification": { "description" : "To show notifications" } }

On every other browser we have to attach the requestPermission() function to an event handler, like click or mousedown. It is important to mention, that it is not possible to ask for permission and show notifications without any interaction from the user.

Altough Chrome 23 supports window.Notification.requestPermission it will break the browser, so we first have to check for the old WebKit implemantation to get it successfully running there. Here is the cross-browser way to ask for permission.

var askForPermission = document.getElementById('askforpermission'); 

askForPermission.addEventListener('click', function () { 
	if (window.webkitNotifications && window.webkitNotifications.checkPermission) { 
		window.webkitNotifications.requestPermission(); 
	} else if (window.Notification && window.Notification.requestPermission) { 
		window.Notification.requestPermission(); 
	} 
});

Check permission level #

After requesting permission we have to check the permission level. There are three possible values we may get after asking for permission:

0 (WebKit) or “default” (W3C) – User hasn’t reacted yet
1 (WebKit) or “granted” (W3C) – User allowed us to show notifications
2 (WebKit) or “denied” (W3C) – User did NOT allow us to show noticiations

As you can see, the values in old WebKit implementations are quite different. Therefore and since the permission on Firefox OS will always be granted our final check looks like this.

var PERMISSION_DEFAULT = "default", 
	PERMISSION_GRANTED = "granted", 
	PERMISSION_DENIED = "denied", 
	PERMISSION = [PERMISSION_GRANTED, PERMISSION_DEFAULT, PERMISSION_DENIED]; 

function checkPermission() { 
	var permission; 
	if (window.webkitNotifications && window.webkitNotifications.checkPermission) {
		permission = PERMISSION[window.webkitNotifications.checkPermission()]; 
	} else if (navigator.mozNotification) { 
		permission = PERMISSION_GRANTED; 
	} else if (window.Notification && window.Notification.permission) {
		permission = window.Notification.permission; } return permission; 
	}
};

Show the notification #

After handling the permission we can finally start showing notifications. Here is the rather long cross-browser code to do so.

function showNotification (title, options) { 
	var notification; 
	if (checkPermission() === PERMISSION_GRANTED) { 
		if (window.Notification) { 
			notification = new window.Notification(title, { 
				icon: options.icon || "", 
				body: options.body || "", 
				tag: options.tag || ""
			});
		} else if (window.webkitNotifications) { 
			notification = window.webkitNotifications.createNotification(options.icon, title, options.body); 
			notification.show(); 
		} else if (navigator.mozNotification) { 
			notification = navigator.mozNotification.createNotification(title, options.body, options.icon); 
			notification.show(); 
		} 
		return notification; 
	} 
} 

var showNotificationButton = document.getElementById('shownotificationbutton'); 
showNotificationButton.addEventListener('click', function () { 
	showNotification("Title", { 
		body: "Body",
		icon: "icon.ico", 
		tag: "tag",
		dir: "ltr",
		lang: "en-US"
	}
);

Let me explain it step by step.

First of all we define a function (here it is called showNotification), to handle the different browser implementations.
Within this function we first have to make sure that we are able to show notifications by checking against the function checkPermission, defined further above (checkPermission() === PERMISSION_GRANTED).

If the check is true, we define a new Notification Object, where we pass one or more of the following parameters:

Title (necessary)
Body (optional)
Icon (optional)
Tag (optional, only in the W3C Spec)
Dir (optional, only in the W3C Spec)
Lang (optional, only in the W3C Spec)

The Last step is to attach the function to an event handler and pass the parameters we want to show to the user.

Résumé #

The Notification API in his final form is relatively new and therefore browser support is not that great at the moment, but as I see this API only as a nice to have feature, there speaks nothing against not using it today. As the old WebKit implementation and the Firefox OS implementation will be around for a while, I definitely would use a Pollyfill, to avoid the headache I had, trying to get it running on different browser.

Demo #

If you want to see it in action check out the Demo made by Tsvetan Tsvetkov.

There is a bug

2013-06-24T17:25:09+02:00

Almost every day I get emails like “Hey Michael, on site bla.com something looks odd” or “Hello, can you please fix the site bla.com, it looks strange on my computer”. Well, sometimes they are more detailed “Bug Reports” than the ones mentioned, but nevertheless, without getting more details about the OS, Browser, … I mostly couldn’t help them in the first step.

So I used to respond them, asking what Browser, Browserversion, OS… they are using to reproduce the error they wanted to tell me, but I soon realized that it’s really hard for most people to provide me with all the details and very time consuming for me to ask again and again.

Therefore I started a little project called “Bugreporter”, which makes it easy for everybody, supplying all the details to me. Nowadays I respond them with “Hey, can you please visit bugspencer.com/bugreport/, copy the url and send it back to me”. Once I get the feedback, I simple open the url in my browser and can see all information I want from them.

This simple site is not perfect at the moment, as it’s still missing some detection and I haven’t yet tested it in some older browsers, but it’s already a time and frustration saver for me.

So, if you also get these sort of emails, feel free to fork Bugreporter, adjust the logo and the style to your corporate identity and get browser details the easy way.

Just my test setup

2013-02-03T15:45:58+01:00

From time to time people ask me on which devices and with which browsers I usually do testing. Simple answer: It depends – There are just too many aspects involved to give a straight answer. Nevertheless, within the last months I defined myself a basic test setup, which works out really well so far. It consists of four parts – Mockups, Design, User Interface and Final Check.

Mockups #

To get a first glimpse how the site should look like I usally start by producing Mockups with HTML and CSS. This part is taking place completely in the desktop browser, I prefer Firefox, because I love the “Responsive Design” feature. I usually test them starting from about 280 – 320px up to ~ 1600px. I try to spend not to much time in details in this step, it’s really just to get a basic idea.

Design #

With the mockups in place, it’s time to go and do the actual design. That’s the stage where my little device friends enter the game. In my case that’s a Samsung Galaxy Ace running Android 2.2 (The old Droid) an iPad running iOS 6 (The Princess) and a Nexus 7 running Android 4.2 (The Fudge). Adding Firefox and Internet Explorer 7 via Browserstack and my test setup for the design part is complete.

You may argue that you can to the design part completely in your desktop browser using Responsive Design View and eg. Browserstack as an addition, but by doing so you will for sure overlook many critical design parts. Just think about different pixel densities and screen contrasts. Start testing on real devices early in the process is crucial and avoids the problem of overseeing wrong design decisions, which may be a pain in the ass if you stick to your desktop at this part.

User Interface #

The term Responsive Design may sound that it’s mostly about design, but in fact that’s just a tiny part of the process. Just think about input types – keyboard, mouse, finger, keypad, game controller, remote control, just to name some. Testing a design by actually using different devices, with different input types, shapes and forms is a very important part for everyone.

My test setup consists of the same as in the design part, but most of the time I add an phone with a Trackwheel and a Keyboard. In some projects I also use the Opera TV Emulator, not just because I like the virtual remote control, but mostly to get a harsh dent what it feels like to surf on such a device. So in summary, in this process I actually do a lot of testing, sometimes I also switch from my personal phone to another for a longer period to get a better feeling of the device.

Final Check #

So, the design looks gorgeous, surfing around the site works like a charm and you are ready to ship the baby. Before releasing a new site however, be sure not to miss the beloved testing fun. I can’t help myself, but I really enjoy the final testing part. That’s the time where I mostly hang around at the Open Device Lab berlin and spend hours of testing and debugging on as many devices I can get my fingers on. Furthermore I also try to test not only on the pre installed browsers but also on other available browsers, you shouldn’t miss Opera Mini for example. The great thing is that their isn’t so much debugging involved, simple because I already tested a lot the whole way through and fixed issues early.

So, what is your test setup?

Responsive Images – what? width! this? no, this! hä?

2013-01-16T20:37:22+01:00

2012, the year where reponsive Images got mainstream and became the rockstar of many dramas just ended some time ago and I am sure you are looking forward to 2013 for the next “responsive Image affair”. I have never planned to attend this show, but just today, while walking through Berlin, I couldn’t think of anything else.

Why do we deliver images based on the maximal window width and NOT on the actual available container width?

Do make this more clear, have a look at an example, showing a simple layout on different resolutions.

The first one shows a site on a 480x320px screen, the second is 645x415px and the last 1001x514px. Ok, so lets have a look at an example using picturefill:

<div data-picture data-alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">  
    <div data-src="small.jpg"></div>  
    <div data-src="medium.jpg"     data-media="(min-width: 400px)"></div>  
    <div data-src="large.jpg"      data-media="(min-width: 640px)"></div>  
    <div data-src="extralarge.jpg" data-media="(min-width: 1000px)"></div>  

    <!-- Fallback content for non-JS browsers. Same img src as the initial, unqualified source element. -->  
    <noscript>  
        <img src="external/imgs/small.jpg" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia">  
    </noscript>  
</div>

Using this, our first screen will get the medium img, the second the large.jpg and the last one the extralarge.jpg. And here is the problem, because the site with 645x415px has only room to show an image which is 386px width, while the smallest resolution (480x320px) can show an 405px width image. Understand my concerns? In a perfect world we should have shown the small.jpg for the 645x415px screen, instead of delivering an way too big image, shouldn’t we?

I couldn’t find any reference sharing my concerns, there is nothing about it in the W3C draft nor could I find any post in the Respimg Group. I couldn’t be the first one thinking about this problem, and I am sure many people shared there thoughts – so please tell me where I can find references, discussions, … as I would like to know the advantages and disadvantages of checking for window/container width. Thanks.

Every web design is broken

2013-01-08T08:58:42+01:00

What an attention-grabbing title, isn’t it. Actually it’s how the web works, belief it or not. Just to be clear, I don’t talk about websites looking different on different browsers, OS, screen resolution – whatever, a website looking different is actually a great thing, every website should look diverse on different platforms. Point.

What I mean is, that every single website out there is broken in one or another browser, just because you will never ever be able to test on every single browser still in use. At the latest after looking at this diagram of web browsers it should be clear, even if you only want to test on all browsers released in the past 3 years, 24 hours a day won’t be sufficient.

Hey, I am the web, I change my clothes more often than Madonna #

Last year, Brad Frost shared a screenshot showing google.com on loads of different android browsers, and as you can see, even a simple page like google.com looks broken on one browser, in this case Skyfire. So, hey if even a global player like Google, serves a broken landingpage to one or another browser.

Works on all devices is plain bullshit #

Thinking of 2012, this is probably the most stupid marketing slogan I heard. Every time someone claims this, I opened up the site/app/whatevermarketingguyscallit on Opera Mini and boom, in 90% of all cases, it didn’t work. Ah, I thought, that’s marketing language, “all” means iOS and Android Stock Browser only, ah how stupid of me thinking that “all”, actually means “all”, you know, marketing is not my passion I guess.

But, eehm, shouldn’t we change this #

As the article comes to an end, and you probably learned nothing, besides that I am not the best friend of marketing slogans, I don’t want to leave you back without some simple advices. The web is unpredictable, is moving forward faster than a spaceship while still being the good old companion we loved, hated and loved again for ages. Your web design is broken and will broke again and again. New browsers emerge, while old for year outdated browsers are still in use. You can’t change this, but you can make the most out of it.

The best way, to reduce the amount of browsers, where something may be broken, is building a website in a future-friendly way, using progressive enhancement and accessibility always in mind. And, please don’t blame users using an old browser or a tiny screen. The only one you can blame, is yourself, if you look out browsers using ua sniffing or whatever, yes I am looking at you Google Maps. And now, after reading a lot of words for a simple thought, go out there and make the awesome web even more awesome.

Be carefull when using input type=”url”

2012-12-28T17:56:30+01:00

Over the last weeks I became somehow frustrated with the HTML input type “url”. While going through registration forms, I often got the error message “Please enter a valid url” after filling in www.justmarkup.com.

As a developer, I immediately looked at the source code and was not surprised to find that they used the required attribute in combination with type=”url”.

<label for="url">Url:</label><input type="url" required aria-required="true" name="url"/>

What’s going on here #

As I was curious now, I opened the form with Opera (the browser with the most advanced HTML5 Forms Support) and found out that www.justmarkup.com validates just fine. (Note: By checking the ValidityState via “element.validity.typeMismatch” it returns true in Opera as well.). Therefore I tried to find some tests about how browsers handle validation of input type=”url” in combination with required, and as I couldn’t find one I made some by myself, which can be found here.. All tested browsers won’t validate “url”, “url.de” and “www.url.de”, but all the other tested values, strangely also “url:”.

I couldn’t find any reference in the w3 docs about when an url is defined as valid or invalid. If you found one, please let me know via twitter as I would be highly interested if the browser manufacturer have integrated it the wrong way or if the spec may be misleading.

Let’s fix this #

Fortunately we can quite easily fix the wrong browser behaviour by adding a pattern attribute. I am sure there may be a better Regex, but mine is “^(https?://)?([a-zA-Z0-9]([a-zA-ZäöüÄÖÜ0-9\-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,6}$”. The main part is from html5pattern.com, I just added the (https?://)? part and support for “umlaute”. I made a test here and as you can see it validates all the values I want it to. If you have a better Regex please share it in the comments.

<label for="url">Url:</label><input type="url" required aria-required="true" pattern="^(https?://)?([a-zA-Z0-9]([a-zA-ZäöüÄÖÜ0-9\-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,6}$" name="url"/>

Conclusion #

All in all it’s really annoying that we, as developers, have to fix, in my opinion “wrong” browser behaviour. Thankfully, it’s easy to change the behaviour and I really encourage everybody to add the pattern part to avoid frustration for your users.

Update 07-01-13 #

Rodney Rehm just commented a way better and safer regular expression than the one I used. Thanks.

Clean up – random thoughts

2012-12-07T13:04:40+01:00

To be honest I never really liked my old design but at that time I just wanted to push it live, so I can start blogging and show something off. After several month of doing nothing I finally had the time to rebuild everything from scratch. This year I learned a lot about building websites, how to test, optimize and build for different devices. This site is not at all perfect and probably, like in my opinion every other page, will never be, but right now I am totally happy delivering it, as it is. If you have feedback, good or bad, I would be very pleased if you yould either Tweet me or write me an Email.

Webdesign #

This site uses a really elementary layout and no fancy JavaScript, it’s simple and clean. If you build such a site nowadays and don’t build it responsive, you may better look for another job, seriously. Don’t get me wrong, I know that it is really hard work to get a sophisticated site using a complex layouts and tons of JavaScript responsive, but for simple sites it has to be the standard way, no the only way. And as a side note, if an user zooms your site and the design breaks, your site is not responsive, or in other words, avoid fixed units, please try to avoid it.

Optimize #

On of the best giveaways of responsive design is that people more and more become aware of, that websites should not only look great, but which is in my opinion much more important, should be lightweight and accessible. So, when talking about optimization, the first thing everyone should do, is compressing all images. This is such an easy step, with tools like jpegoptim or tinypng, you can reduce the overall size, in most cases, dramatically. You may argue now, that everybody is aware of this, but it can’t be repeated too often until everybody really does it.

An even easier step is to use a proper .htaccess. I mostly go with the one from the HTML5 Boilerplate and it works like a charm. With this simple steps in place, head over to Google Pagespeed, if your score is above 90, well done, otherwise follow the advises until you are at this level.

Testing is fun, fun, fun #

I love testing, man I really love testing. Firing up a website on dozens of different browsers and platforms to see if your code actually works as expected, is fantastic. At the start of every project I usually define one device as “The old man standing”, a device which still has quite a big user base, but has lots of limitations according to CSS, Html and JavaScript and comes with quite a small screen (like 280 x 400 for example).

I normally test my code concurrently while coding in “The old man standing”, Firefox with responsive View enabled, one average Android and iOS phone/tablet. By checking your site all the time on different platforms, while working on it, wrong decisions can be detected right away and therefore rebuild for the better. If you go the other way and test your site only at the end of the build process you most probably end up, with a lot of time consuming debugging, with a bunch of ugly bugfixes and all together with messier code, as if you would have by testing from the first day.

Performance is the key #

Tim Kadlec wrote exactly whats in my mind since month in his article Responsive Responsive Design. Your site may be the best looking site ever, but if it takes ages to load, it may also be the worst site ever. As already said above, optimization is in many ways really easy to achieve, and there is no excuse to load unoptimized content.

Random thoughts at the end #

After one year reading, writing, learning about responsive Design I personally more and more get the feeling, that many people don’t get the idea of responsive Design. Every time I see a iphone.css I really have to force myself not flipping out and telling the developer really bad words. There are so many smart people telling us that we shouldn’t develop for devices but for content, that responsive design doesn’t work without optimization, and still there are so many “Webdevelopers”, which seems like, never heard of all this.

I often get upset when seeing “crimes”, like the iphone.css and in the future I often shouted at them and telling them “Your are doing everything wrong!!!”, but I realized that this doesn’t help anybody. Therefore I have a new tactic now, every time I see a bad developed site, I simple write them an email, addressing my concerns, pointing out errors made and most important telling them how they can fix it. So the next time you shake your head after seeing some sourcecode, write them an email and say them what they did wrong and how this can be changed, thanks.

Want to be the first hearing about new posts here, you may follow me or grab the Rss feed.

Testing your responsive site – using Ubuntu

2012-08-23T10:12:35+02:00

This post is all about setting up and using tools and extensions, useful for testing your Responsive Design. I work with Ubuntu, so most of the instructions will be for Ubuntu, but I guess everyone else will get the idea.

Browsers #

Firefox #

The current Firefox Nightly comes with a fantastic tool for testing your Mediaqueries. They call it “Responsive Design View”, and you name it, it’s for testing a site on different screen resolutions. With this tool you can easily resize your site both vertically and horizontally or choose one of the redefined screen sizes to test the most common ones. Sooner or later this tool will be build in Firefox Stable, but until then you can download Firefox Nightly, which runs site by site with the stable Version.

Furthermore you can install Firefox Fennec, downloadable on mozilla.org. There you will find handy install instructions, to get it running within minutes. I don’t use Fennec that often anymore, as I use Firefox Nightly now for testing initial mockups, but it’s a great browser for testing “touch”, as there is, for example, no hover event.

Opera #

Opera offers Emulators for Opera Mobile and Opera Mini. Especially the Opera Mini Emulator is great, as the the browser is not only used by many feature phones user, but also has some JavaScript limitations you should be aware of.

Opera not only has browsers for desktop and mobile, but also serves the needs for TV consumers – Opera TV. You can find more out about setting it up in this post. I don’t use the emulator on a daily basis, but playing around with a web-based remote control is not just pure debugging fun, but more important, gives you a good feeling about another available input control.

Remote Web Inspector #

Weinre #

If you are into mobile development you probably heard of Adobe Shadow. There is no Linux Version, but we can instead simply use Weinre, the package, Adobe is using under his hat. You only need node.js running on your computer, the program itself can installed via the npm package manager. Once everything is done, you can remotely debug any webkit-based browser (Android, iOs, Blackberry …). It’s awesome – use it!

Firefox mobile #

Not long ago, Firefox implemented an easy way to debug Firefox Mobile remotely. Check out the Demo as well.

Chrome #

Directly with the start of Chrome for Mobile they added the possibility to debug remotely. The latest Android Version ships with Chrome as the default browser, so their will be a big crowd using it in the near future. It’s elementary to set it up with some simple steps

Opera Mobile #

Last but not least is Opera. Remote debugging for Opera is already around since 2008, as far as I can see. Definitely another awesome option to test your responsive Design. You can find instructions about the set up in this post.

Conclusion #

As you can see, there are already fantastic tools lying around to debug your site remotely, as well as testing your responsive design on your desktop, and I am pretty sure there will be even more possibilities in the near future. I love testing, and with this tools in my hand it’s even more awesome. You can also see, that it’s not a big deal to set up most of the tools presented, and that there is something for almost every browser engine out there, although I don’t know about any tools to debug on windows mobile, anyone?

If you know of any other tool, useful for testing a responsive site, please let me know in the comments.

Responsive Multi Level Navigation – let’s try.

2012-06-19T15:16:59+02:00

Lots of fantastic people already put their hands on building a responsive navigation, and they came up with sweet ideas, like this Tutorial on .net by Aaron Gustafson.

And there is also a neat overview about “all” responsive navigation patterns by Brad Frost where he points out the cons and pros in a detailed way.

However most of these patterns are not really applicably when dealing with “large” navigations or multi-level navigations and thus I tried to develop one which also doesn’t need JavaScript.

If you are wondering, the navigation structure is the one used on a german newspaper, as I wanted to test it with a real world example.

Before finally diving into my example, I have to admit that I am still searching for a “perfect” solution, as each of the following has some drawbacks, you may see as a deal breaker in your project.

The “I don’t care” or “Do nothing” pattern #

Let’s start with the simplest pattern you can imagine, which is in other words doing nothing. Surprisingly there are also some advantages, especially that it works in nearly every browser.

Have a look at the demo

Advantages #

The top level navigation is accessible with one click/tap for almost every browser
It doesn’t depend on JavaScript

Disadvantges #

Sub-Navigation is only accessible at once by non-touch devices, but as we show the current Sub-Navigation for all browsers, you can reach the sub navigation with two clicks on touch devices as well.
Especially on small screens lots of space is “wasted”

The “Priority” pattern #

Next I want to show you the “Priority” pattern, which tries to reduce the wasted space, but is nevertheless still not able to give “everybody” direct access to sub level elements.

Have a look at the demo

These technique basically has the same advantages and disadvantages as the previous one, but comes with the great benefit not wasting that much space.

The “Priority +” pattern #

Going one step further I tried to improve the previous example by making the Sub-Navigation also available with one click/tap, but came to the conclusion that it’s not really possible by just using CSS. If you expand the top navigation to all elements and try to access the Sub-Navigation via [+] all the “less-prio” list-items will be hidden again. You may can avoid it by using some fake elements and the nth-child() selector but I didn’t really want to go that nasty.

Have a look at the demo

Conclusion #

As already mentioned in the beginning I couldn’t really find the clever solution, but I personally would use the “Priority” pattern as it’s a clean way with great browser support, although you get to see the Sub-Navigation only after taping twice on touch devices. The “Priority +” pattern somehow solves the “double tap problem”, but is on the other hand irritating and not really user friendly.

That said, I would in the end use some JavaScript to imitate the :hover Effect for touch devices, as it’s, as far as I can see, the only way to make that work in a clean way.

Should we really worry that much.

2012-04-05T11:58:42+02:00

As soon as the new Ipad was released, many people started thinking about the best way to serve high-resolution images to it.

Apple itself implemented this technique, which has not been thought through, mainly because of the increased total size. When surfing apple.com with your shiny new Ipad you have to download 2.13MB instead of 502.90K, or in other words 4x the size. This may be fine if you are using WIFI or LTE (which is not usable at all in many countries), but not for people surfing on low bandwidth.

Speed me up #

So is it really worth to worry about serving high-resolution images until we can reliable get the connections details. I definitely say no, just think about the following case.

” Someone surfs apple.com with the new Ipad, but has to rely on EDGE. It will take up to 10 seconds just to download the images. I guess lots of people will already cancel way before the 10 seconds, and before even seeing a glimpse of your high-resolution images. ”

And this will not just happen to 1% of your Ipad users, but probably for many, many more. While travelling through Germany, you see many people surfing on their Ipad, and if you count in the low bandwidth they are relying on, it gets clear why speed should be one of your highest priorities in all your web projects.

Is there a solution #

In my opinion Apple has failed in this case. What they did, can be compared to shipping a new “resolutinary” television screen, without thinking about that their will be no films available at this point, which can take advantage of the new screen. What I want to say is, they should have spend time in developing a bandwidth detection API way before the new Ipad was released.

Let’s say they were clever and presented a reliable solution, integrated in mobile safari 6-8 month before the release. This would have been a huge effect. I am pretty sure, if the solution would have been acceptable and usable for developers and browser manufacturer, Google, Firefox, Opera and even Windows (the know they will ship tablets with windows 8 and a high resolution display later this year) would have implemented (or at least would do now) a bandwidth detection API in their browsers. At some point it would have been a de facto “standard”, so W3C would even have standardised the API.

I don’t want to blame Apple, but it really annoys me, that we as developers now have to think about a way to serve high-resolution images to people surfing on low bandwidth, which is just not possible.

So please stop solving problems you don’t yet have and enjoy easter.

Take this you mobile wannabe!

2012-04-02T13:55:45+02:00

While we, as developers, think about best ways to serve images to different devices and resolutions or about how we can adapt the navigation to various screen sizes, many people get more and more annoyed by the mobile “experience” they have to deal with.

An URI is unique and everywhere the same, isn’t it? #

Dear websites, every time you redirect me to your “mobile” site and just cut off the path of my URL, a kitten dies.

— Thomas Fuchs (@thomasfuchs) February 6, 2012

Thomas Fuchs puts it in a nutshell, it’s just a pain in the ass if you don’t serve the content the user wants to see. This users will think twice the next time before clicking your link and of course will never ever share your link. So, if you don’t have the requested content available on your mobile site, do yourself a favour and show the user your “normal” site instead.

Don’t crop your cont… #

Just because somebody is using a smaller device to view you site, it doesn’t mean they also want to see a stripped-down version of your content. Some days ago I saw a conversation on reddit.com where somebody says, that he prefers desktop sites over “mobile” sites, because some of his favourite sites show a neutered version on his phone.

Therefore, always keep in mind that there is no excuse to serve a stripped-down version, never ever. Never!

In your App #

Another really annoying practice is showing a Pop-up where the user gets invited to “Download the brand new and super shiny App NOW”. Providing native App’s is great and it’s also understandable that you want to promote it, but please choose another way. Many users, including me, just don’t have the nerve to close these Pop-up’s.

Once again if you don’t have adapted your site for mobile, just serve us your “desktop” site. If you have good content, I may read it on a regular basis anyway and may also prefer to install your App someday, but I will never install an App just to get to see the content I want to see now.

Conclusion #

Just because “everybody” is really exited about mobile, and Responsive Design seems to be the new Web 2.0, do yourself a favour and don’t act too hastily to get your site ready for mobile. A bad mobile site is much more bothersome than serving a “desktop” site to all devices.

That said, I would never advise someone, not going responsive, but you can see at the examples above, how “easy” it is to loose potential users.

Why sharing a picture goes pear-shaped in many cases

2012-03-07T10:10:48+01:00

As it happens a lot that you get a link from a friend saying “Look at this cute cat” and once you open the picture you actually get to see a “big pink dog”, I went on and tested some of the most visited news sites in Germany to see if it’s possible to share a specific image out of a gallery just by copying the URL from the address field.

Here is what I came up with.

spiegel.de #

The link I tested on this site was this one. Sharing on non-mobile devices works well however once viewing this link on mobile you get this. #fail

bild.de #

I tried to share Image 4 in this gallery. Impossible as you always get to see the first image. #fail

welt.de #

Here I tried to share Image 6 from this gallery. Nope, again no chance to share this specific image. #fail

sueddeutsche.de #

On this site I wanted to share this image of a wale. And surprise, surprise this is the first image I can share between different devices. #good

stern.de #

Seems like we now have a run. Sharing this picture works like a charm as well. #good

focus.de #

Oh look at the tiger on picture 4. What you actually see is not a tiger at all but some other animals. On my Android 2.3 device you even have to close 2 Pop-ups (asking if you want to install the App) before you get to the article, but no wonder still no tigers. #fail

zeit.de #

Here I tried to share picture 13. Unfortunately this is not possible, as you always get to see the first picture, on mobile the same of course. #fail

Results are frustrating #

To sum it up, out of 7 tested sites only 2 provided me with a link to a specific image which I could share with whatever device I like. One (spiegel.de) is doing his job on desktop, but once you go mobile they fail completely. As a side note – sueddeutsche.de was the only gallery where you could use your keyboard to navigate through the images, which is a terrible quota.

I really don’t know why so many sites have problems changing the URL while clicking through there “fancy” JavaScript Gallery. It’s just some lines of JavaScript, to add a different hash to the URL for every image and on the other hand checking if a hash is present to show the image the user asked for. If you don’t like hashes in your url you can also use the HTML5 History API like this cross-browser Solution.

Conclusion #

I am really the only one who is pissed of, that fancy effects seems way more important than some of the basics? I absolutely hope not.

What we can’t test

2012-03-02T16:53:22+01:00

We all do our best to test our sites in lots of different browsers, screen resolutions and input/output devices. But to be honest we just can’t test everything.

Screen resolution #

Unless you have the opportunity and money to sit in front of a 42″ or even bigger screen you are not able to test your design on big screens. Scaling down your browser window is easy, but increasing it over your max. resolution available is just impossible.

Browsers #

I really don’t know how many browsers exists and how many of them are actually used but I just checked some stats and there were over 100 different browser versions listed. And as this svg on wikipedia shows there are actually a lot more, especially as I know at least of two (Chrome for Android and Dolphin Browser) not listed there.

Who has ever tested his site in SeaMonkey (which is in some of my stats much more popular then IE6) or on Opera TV?

With the fast release circles nowadays and as Paul Irish said growing numbers of Browser versions this task is simple impossible. Nobody can test in 100’s of different browsers/versions and continue to test all his sites with every new browser/version coming out.

Connection Speed #

I guess you all know that at the moment of writing this, there is no way to test the connection speed the user are running on. And even if there would be a test, the only way to make users happy is to serve your page as fast as possible, as every millisecond is important.

External influences #

Another thing you can’t test reliable is for example “light irradiation”. If you ever used your laptop while sitting outside in the sun you know what I mean. It gets really hard to read a website unless the contrast is very high. That’s just an example but many people will get pissed of, if they can’t read your great news, that’s why we always should design with high contrasts and big enough font sizes.

Another example of external influence is, that we don’t know if the user is just sitting on his couch with lots of time or if he/she is just running to a meeting while trying to read the latest gossip. Once again we can’t test all this situations.

And many more… #

You know there are many other things we can’t really test like all the input/output devices, all the different Screenreaders and so on…

That’s why we all should develop futurefriend.ly, so we don’t have to worry that much if Microsoft is going to release “mIE5” for Android tomorrow.

Don’t think in statistics – the future is already the past.

2012-02-21T11:40:40+01:00

Let’s say you are thinking about a relaunch of your site. One of the first things you may do is checking your Analytics Data to get a feeling what Browser, OS, Screen resolutions, Plugins, … your users actually use.

After finishing your evaluation you may define which browsers you have to support definitely and on the other hand which browsers you may just ignore as they only count for ~ 1% of your visits.

Don’t trust them #

Let me explain why checking statistics is a good addition but not the ideal solution for your new project. First of all you can’t really trust your statistics, as the tracking may fail in some cases, you can’t really ensure tracking on all devices and you don’t get all data from users without JavaScript (unless you use server-side tracking).

Furthermore statistics only shows you the data from the time being, but you still don’t have no clue what the statistics will look like in one month, one year or the next day?. They may be already completely different at the time you are ready to relaunch your new site. This is also the point where you have to realise that statistic data are a great way to give you a feeling of what’s going on now, however they are not carved in stone, can change fast and often lies.

Prototyping like a BOSS #

So after realising that statistics data are not reliable and should be just a small part of your browser evaluation, we have to rethink the concept. So lets bring in the terms “future-friendly” and “progressive enhancement” as these are not just buzz words, but the way you should start your new project.

As the browser is (at least for me) now the new photoshop/fireworks, we should go even one step further and force ourself to build the first protoype of our webpage without using any CSS3, HTML5 and JavaScript.

I know its hard to forget for a moment about all the fancy CSS3 and the cool HTML5/JavaScript Technics but this is, in my opinion, the perfect start to ensure that your page will be usable, readable and accessible in all browser/device combination you may not even imagine they (will) exist. Developing for the future by using technics from the past may sound weird, but thinking like the old old IE6 really helps to set up your first prototype.

Don’t get me wrong, I love to use all the new technics and properties available, but you should never ever use them without a fallback solution, because there is nothing more annoying then a website not usable/readable or even completely broken in older browsers. And by starting with the “fallback” solution, as explained above, you will be absolutely sure the site works and even more important will work in whatever browser/device will come.

Mobile isn’t mobile

2012-02-13T21:38:40+01:00

Today on twitter the amazing Brad Frost wrote a great article, exactly speaking out what’s in my mind – “Native vs Web is total bullshit.

That’s absolutely true, because you can’t compare apples and oranges.

Poles apart #

I surf the web with my mobile devices on a daily basis, often following some links from social networks or reading local/international news. What irritates me most, but unfortunately happens quite often is that news site offering some “fancy” iphone/ipad/whateverosordevice app but no mobile web experience at all. That makes me cry, because in my opinion their mobile strategy is just completely wrong. They spent lots of time and money to make an iphone app, just to find out a year later they have to build an ipad app, just to find out they need an android app, …. ending in an loop of building and rebuilding apps for whatever will come.

I can’t find any argument why news sites think apps are the way to go for their business. They loose customers like me, who doesn’t want to install an app for every damn site out there, loose money in advertising by accepting the share for “in-app” advertising, loose money for every new device/os combination they want to support in the future. To conclude it every business focusing on content will have a huge benefit buy building mobile first responsive websites. And If they can afford it, I don’t care if they still build additional native apps, to enhance the experience for power user.

Play with me #

On the other hand there are also many use cases were a native app is the way to go, just think about games. Of course you could build a game with html5 as well, but this way you have to deal with way to much difficulties like offline usage, cpu performanece… To be honest I don’t know much about developing games but I think it’s much easier to build an app as building it with html5 and dealing with all the device/os disparities. Point.

Think future friendly #

To sum it up, I have to say that it’s way to frustrating for me to surf on news site this days, just because they thought/think offering an app is the best mobile user experience they can afford. That’s also the reason why I often email to this sites complaining about and on the other hand demonstrating why they will love future friendly websites.

Furthermore I don’t convict anyone building an native app, but if your main focus is publishing content, you shouldn’t do it unless you ensured your website looks great on every screen size / device you can imagine.

What do you think?

Let’s start with the basics.

2012-02-08T13:08:56+01:00

At the moment the whole world (ok maybe only we frontend people) speaks about responsive design. If we divide the opinions we come up with three approaches.

People who don’t care at all about responsive design and just continue coding like the years before.
Frenetic elation – people trying to convince everybody to use it now.
People who remark criticism about responsive design.

IE will never be dead #

Starring at your statistics with the hope old IE’s won’t appear anymore will not happen in the near future. Of course every frontend developer will have a giant party if the world of browsers would only consist of up to date browsers providing the same experience.

Waking up from the dream we have to realise that there are not only different browsers, but also different screen sizes, people using all sort of input and output devices and so on.

Avoid known mistakes #

Lot of failures were made in the past, just think about the browser war in the 90’s were most developers either optimised for Internet Explorer or Netscape. Later on we tried to optimise for every single browser available, which was and is a pain in the ass, because it costs a lot of time, money and nerves until a page looks pixelperfect in every browser. This is just not acceptable, but more important, it’s also not to drop support for older browsers. Now, while you may think I am completely insane, saying that either option A nor option B is the way to go, let me talk about option C.

Start with the basics #

The key “feature” from option C is the solid basement. Starting with the basics of web design helps to avoid lots of problems in the next steps. The idea is to kickoff with a fundamental fluid layout, using no css3 or html5 fanciness. This will be our basic layout shown to older browsers and mobile phones. You may also define this as the fallback solution, but it’s a solid, fast, accessible (hope you haven’t forgot about this by the way) basement and can be viewed with nearly every device/browser combination available.

Climb the mountain #

Once ready with the basics, leave the base camp and move forward to “camp smartphone”. At this point we can start bringing in some lovely css3 styles. Adjust fonts, elements … for the actual screen size using media queries and after a fast look back in the base camp assuring everything is still fine down there we already reached the next step.

Now in higher atmosphere some problems seems harder to solve, think about the pain with responsive images and videos, but as we trained a lot the years before, I am sure we will find a way to solve it, a good approach for responsive images is for example using JavaScript to find out the screen size, and then serve the right image, always providing some fallback if user has Javascript/Cookies disabled of course.

Enjoy the outlook #

Some camps later you will finally reach the peak. Take your time, celebrate the ascent of your private peak and always think about how easily the way back is, that at the very bottom is still a solid base waiting for you and you that can always climb the mountain again using another route if you are not really happy with your current way.

Let’s discuss #

After reading this you may wonder why I mentioned the list of different approaches at the beginning. As I said there are lots of people arguing against responsive design, many mentioning the fear of additional work and expense.

But if we develop with fallback/mobile first this argument doesn’t longer has any effect, since it’s much more work to maintain css files for old browsers than just starting with one basic css file and adding shine for up to date browsers. This way it’s also a lot easier to adjust your css in the feature when even more css3 is availabe.

Happy climbing!

Loading… and how css can help

2012-02-05T15:27:05+01:00

The simplest form of showing an animated Loading… has been around since the early days of Internet Explorer. The marquee element and his counterpart the even worse blink element has never been part of the w3c specifications because of their terrible usability and accessibility.

Nevertheless at least the marquee still works in most browsers nowadays.

Please have a look (don’t try it at home):

Loading…

Loading… the right way? #

After playing around a bit with css3 animations and pseudo elements here is my solution. Have a look at the dabblet if you wanna play around with it.

Loading, please wait

@keyframes load {
	0% {left: 0; background-color: #ddd}
	50% {left: 80px; opacity: 0.8; width: 70px}
	100% {left: 200px; width: 20px; opacity: 1; background-color: #ddd}
}

@keyframes hideload {
	0% {background-color: #fff}
	100% {background-color: #fff}
}

#progress:before {
	position: absolute;
	z-index: 1;
	content: "";
	width: 300px;
	height: 20px;
	animation: hideload 2400ms infinite alternate
}

#progress:after {
	content: "";
	z-index: 2;
	position: absolute;
	left: 0;
	border-radius: 4px;
	width: 20px;
	height: 20px;
	animation: load 2400ms infinite alternate
}

You probably have seen much more fancy loading bars but I wanted a solution which is also compatible with older browsers and more accessible. If you remove the animations from the pseudo elements you will see how it looks like in older browsers and although not tested how screen readers will read it.

Just the phrase “Loading, please wait”.

To achieve that I used the simple trick to hide the text via the animation on :after immediately. This way all browsers with no support for animation simple see the phrase while browsers with support see the loading animation.

What’s your solution?

Servus

2012-01-31T16:39:12+01:00

Welcome to justmarkup.com. Just my log.

justmarkup

Thirteen years

This site #

Social #

Not sharing GIFs

Twelve years

Writing #

Social #

Eleven years

Writing #

Social #

Book – Engineering Management for the Rest of Us

Review and takeaway #

Summary and remarks #

Values – individual, company, and team values. #

Trust and vulnerability. #

Your team is not them, your team is we. #

Happiness and drive #

Long-term care of employees #

Career laddering #

1:1s are critical #

Communicating as a manager #

Change management #

Giving and receiving feedback #

Prioritizing your teams work #

Scope down PRs #

Speed of execution #

Split time between product and engineering work #

Prioritizing #

Boundaries #

Lazy loading HTML includes

HTML includes #

How would this work? #

Lazy loading #

Make it happen #

Building a house

The building #

The issue #

Before not after #

Stop supporting Internet Explorer!

Ways to support a browser #

Support Internet Explorer #

Resources #

Ten years 🎉

Keeping up-to-date with web development

Learn forms course on web.dev

100 days - 100 HTML elements in a tweet

Overenhancement

Hamburger #

Tabs #

It depends™ #

The Void

Reduce your client-side JavaScript in Next.js

Disable client-side JavaScript #

Use Preact #

Preload #

Conclusion #

Resources #

Nine years

Integrate Pocket in Eleventy

Get a consumer key from Pocket #

Obtain the access token #

Fetch data from Pocket #

Integrate in your template #

Extra (automatic deploys, caching) #

My Bookmarks #

Make the page count of a 3D book visible using CSS custom properties

3D Book in CSS #

Customize via CSS custom properties #

Resources #

Loading and replacing HTML parts with HTML

The idea #

Let the browser do the job #

Accessibility build-in #

Easily enhanceable #

Enhance with JavaScript #

Enhance with CSS #

Enhance with request header #

Conclusion #

References #