Reading List
The most recent articles from a list of feeds I subscribe to.
150
This blog has now reached the somewhat random milestone of 150 posts. When I asked around what post #150 should be about, the Twitterverse said “blogging”. Well, OK!
Fun fact, this isn’t my first blog: from 2008 to 2014, I had a travel blog, where I tried to write funny posts about my trips abroad for family and friends. This blog is different as I try to, ahem, add “something” to the field of web development, I fact-check, look for previous work to credit and try to keep posts with technical recommendations up to date.
Why personal blogs are great
The fact that so many people publish their thoughts and share knowledge, is something I’ve always loved about the web. Whether it is practical stuff about how to solve a coding issue or some kind of opinion… everyone’s brain is wired differently. It may resonate, it may not, that’s also fine.
People’s blogs are what helped me get started in this industry and get a feeling for the kinds of problems we’re trying to solve. I started doing web development around 2006, and at that time, lots of people blogged. Many of the conversations happened on blogs. Since 2013, this blog is my attempt to join some of the conversations.
Blogging is like “a kind of catharsis”, said Bruce Lawson once in 2005:
In the old days, people used to shout at passers-by in the street; these days, we blog.
(Don’t follow the link and read about his other analogies to blogging)
Writing in public feels great, even if no one reads it, says Sara Soueidan in her post Just write:
Just write.
Even if only one person learns something from your article, you’ll feel great, and that you’ve contributed — even if just a little bit — to this amazing community that we’re all constantly learning from. And if no one reads your article, then that’s also okay.
It is ideal to do this on your own website. Matthias Ott put it beautifully in his post Into the Personal-Website-Verse—personal websites are about expressing and exploring yourself:
Personal websites are called personal websites because they are just that: personal. Thus, the primary objective still is to have a place to express ourselves, to explore ourselves, a place that lasts while the daily storms pass by. A place of consideration, and yes, a place of proudly sharing what we do, what we think, and what we care about. A place to contribute your voice and help others. A home on the internet. A place to tell your story.
This resonates so much.
Why blog
Social media is hard to search
Do you ever think “there was this tweet by X about Y” and attempt to find it? This can be really hard, as new tweets appear all the time in this endless stream of opinions, thoughts, jokes and anger. You may want to go to a person’s profile and look for the tweet, but with the endless loading that breaks CTRL/⌘ + F, I usually wish my past self had saved a direct link.
In contrast, your blog is “a place that lasts”, as Matthias says above. If you take those tweets and put them into context on your blog, that will make the conversation easier to find them later.
Social media is not optimised for organising thoughts
Not only do posts on social media fade away over time, they also have character limits. While you save words, you likely leave out nuance. Threads exist, of course, but on your website, people don’t have to click to try and expand more content. You get all the space you need.
Own your content
When you publish on your site, you own your content in a way not available on any of the centralised platforms, like Twitter or Medium.
Khoi Vinh says about this in an interview:
I personally can’t imagine handing over all of my labor to a centralized platform where it’s chopped up and shuffled together with content from countless other sources, only to be exploited at the current whims of the platform owners’ volatile business models.
Ana Rodrigues lists this and many other advantages of owning your own content in her fantastic post Autonomy online: a case for the IndieWeb, which also contrasts the IndieWeb with the Corporate Web.
What I write about
This blog isn’t particularly structured, but scrolling through the past 149 posts, I did find some common themes. I had forgotten about a lot of the stuff. Warning: there are a lot of links below.
Summaries of events
Sometimes, I write summaries of the conferences I attend, like when I met the TAG, attended ConfConf and joined MozFest. This requires me to hold my phone while listening, frantically taking notes, while being focused on what is being said. After the event, I structure my writings and try to piece together summaries per talk, adding links, sometimes revisiting slide decks if they’re available. This is exhausting, but helps me personally process what I’ve learned. It usually also leaves me with many tabs open and a bunch of self doubt about properly representing the speakers’ points.
Opinions
I’ve also published some ‘hot takes’. The one I’m now most embarrassed by is the clickbaitily titled Bootstrap considered harmful. Let’s say I had not read Eric Meyer’s awesome “Considered Harmful” Essays Considered Harmful yet, and I was younger. I also wrote about Web Components and which kinds we need, overengineering CSS, “your mom” jokes in corporate culture, why Uber’s for everyone isn’t like Timbl’s and why slowness of websites is optional.
Components
In the last 10 years component systems ruled front-end development. Before that, it would not be uncommon to be hired to build some full pages. Those times are gone. Components have been a favourite subject to write about. Recently this was about accessibility claims of third-party components, before that I wrote about baking accessibility into components, frameworks and standards, Web Components and native elements, the websites as an instance of a design system, grids and components and accessibility in pattern libraries.
Reading lists
I did some reading lists, too, with recommendations about AI, equality, tech and society and more equality.
Accessibility
Some of my more technical articles are about accessibility. I wrote about how accessibility trees work, alternative text and when you don’t need it, accessible names and focus traps. There were also posts about testing pattern library accessibility, inline error messages and making websites more mobile friendly.
CSS
I praised the wonders of CSS in many of the posts. It lets you style things that don’t even exist yet, has simplicity as its core principle and can be used to rebuild awesome posters. To me, the cascade is a feature, not a bug and I feel simple fallbacks for Grid Layout are preferred to complex ones.
My favourite local conference is CSS Day in Amsterdam and I did write-ups for CSS Day 2019, CSS Day 2017.
Progressive enhancement
One of my first posts about progressive enhancement was about an approach for progressive enhancement with data--attributes and I did a follow-up on initialising script from mark-up. More recently I wrote about the merits of separating HTML, CSS and JS.
Here’s to the years to come!
There are lots of things I would like to do better. One is to write better, maybe by writing more. Maybe also by submitting to other publications, so that I can get more feedback on my writing. There’s so much to learn about writing and it’s hard to learn alone. I would also like to write more interesting content (don’t we all? 🤓). So far I noticed something interesting can come out when I don’t expect it, and write something short that I never really planned to write about. Probably think about it less?
Anyway… I’ve really enjoyed having my own blog and I hope to continue posting for many years to come. Thanks everyone for support and encouragement, you know who you are! I hope to be back soon with a post that is more useful than this one.
Originally posted as 150 on Hidde's blog.
Criticism pushes the web forward
This week, a friend shared a blog post that critiqued a popular framework for CSS. Twitter started to discuss if it’s okay to criticise tools. In this post, I’ll say it is not just okay, it is also important.
I was a little disappointed to see the replies to this tweet. Among the many replies, the person who came up with the framework exclaimed seeing the post shared by her “ruined” his day. Note: the post was not about him, it was about the framework (the one that, on its homepage, criticises other people’s CSS methodologies) . Other commenters said the article was “not worth sharing”, “you’re just starting of fights” and “why would you amplify that?”.
I’m not interested in attacking anyone here, or going into the merits or faults of The Post, but would like to answer that last question. Or, in fact, a more generic one: “is it okay to criticise tools?”
Listening helps
The short answer is: yes. As long as it is aimed at the tool, not the person that created it, it is better to share criticisms than not. I have never been involved in the development of frameworks for the web, but in standards for the web, like HTML, CSS and ARIA, there is lots of criticism. People poke holes in each other’s assumptions, suggest ways to make features better and explain why things don’t work well for them. Good standards require diverse perspectives.
Again, the kind of criticism I’m talking about here is criticism of the content, not a person. Is some proposal vague? Should we really call that property “left justify” or number-form seems counterintuitive as a property name–just two examples of critiques of the first version of CSS, in 1995. They’ve made CSS better, because we’ve ended up with better names. Thanks to the people who took the time to send in comments. This is, for over 25 years, how we’ve evolved the web: by listening to each other and not taking critical comments personal.
Can we “just not use it”?
Maybe web standards like CSS are different. The web is built on it and you cannot not use CSS when you build a website. Browsers have stylesheets. But if we’re honest, the most popular tools and frameworks also impact all of us. Most web developers don’t always get to choose their own tools and frameworks, they join a team with existing code or have team members with other opinions.
I’ve never included Bootstrap in a project myself, but have contributed code to many projects that did. Just like it is helpful to comment on web standards, it is helpful to comment on tools and frameworks, because they too affect us all. This goes both for whether to use the thing at all, and for features the thing has or lacks.
Like critical thinking pushes the world of ideas forward, I mean in philosophy, criticism of ideas for standards, tools and frameworks pushes the web forward. We should give feedback respectfully and constructively, but we should give feedback. And open up to feedback, not demand it to go away. It may not be easy, but it is important to include perspectives outside your own.
The post Criticism pushes the web forward was first posted on hiddedevries.nl blog | Reply via email
Criticism pushes the web forward
This week, a friend shared a blog post that critiqued a popular framework for CSS. Twitter started to discuss if it’s okay to criticise tools. In this post, I’ll say it is not just okay, it is also important.
I was a little disappointed to see the replies to this tweet. Among the many replies, the person who came up with the framework exclaimed seeing the post shared by her “ruined” his day. Note: the post was not about him, it was about the framework (the one that, on its homepage, criticises other people’s CSS methodologies) . Other commenters said the article was “not worth sharing”, “you’re just starting of fights” and “why would you amplify that?”.
I’m not interested in attacking anyone here, or going into the merits or faults of The Post, but would like to answer that last question. Or, in fact, a more generic one: “is it okay to criticise tools?”
Listening helps
The short answer is: yes. As long as it is aimed at the tool, not the person that created it, it is better to share criticisms than not. I have never been involved in the development of frameworks for the web, but in standards for the web, like HTML, CSS and ARIA, there is lots of criticism. People poke holes in each other’s assumptions, suggest ways to make features better and explain why things don’t work well for them. Good standards require diverse perspectives.
Again, the kind of criticism I’m talking about here is criticism of the content, not a person. Is some proposal vague? Should we really call that property “left justify” or number-form seems counterintuitive as a property name–just two examples of critiques of the first version of CSS, in 1995. They’ve made CSS better, because we’ve ended up with better names. Thanks to the people who took the time to send in comments. This is, for over 25 years, how we’ve evolved the web: by listening to each other and not taking critical comments personal.
Can we “just not use it”?
Maybe web standards like CSS are different. The web is built on it and you cannot not use CSS when you build a website. Browsers have stylesheets. But if we’re honest, the most popular tools and frameworks also impact all of us. Most web developers don’t always get to choose their own tools and frameworks, they join a team with existing code or have team members with other opinions.
I’ve never included Bootstrap in a project myself, but have contributed code to many projects that did. Just like it is helpful to comment on web standards, it is helpful to comment on tools and frameworks, because they too affect us all. This goes both for whether to use the thing at all, and for features the thing has or lacks.
Like critical thinking pushes the world of ideas forward, I mean in philosophy, criticism of ideas for standards, tools and frameworks pushes the web forward. We should give feedback respectfully and constructively, but we should give feedback. And open up to feedback, not demand it to go away. It may not be easy, but it is important to include perspectives outside your own.
Originally posted as Criticism pushes the web forward on Hidde's blog.
What's ‘normative’ in WCAG?
I’m currently involved in a project to make some of the WCAG guidance more clear. One of the distinctions we’re hoping to clarify is: what’s normative in WCAG?
‘Normative’, meaning something like ‘required to meet the norm’, is a common phrase in (web) specifications. You’ll find it in WCAG, but also in HTML, CSS and many others. Specifications say what we should do (‘do X’), in a way that can be evaluated afterwards (‘was X done?’).
For instance, the normative sentence ‘Web pages have titles that describe topic or purpose’ (from: Page titled) can be evaluated: if a web page has a title and it describes topic or purpose, it’s a pass. Otherwise, it’s a fail.
The opposite of ‘normative’ is ‘informative’, it is something that is not required for conformance to the norm. You may also find it is called ‘non-normative’, ‘not required’ or descriptive in some places.
As an aside, the words ‘may’, ‘must’, ‘must not’, ‘not recommended’, ‘recommended’, ‘should’ and ‘should not’ have special meaning in the context of specifications like WCAG. This meaning is defined in a document called RFC 2119.
What’s normative in WCAG
The part of WCAG that is normative is the main WCAG text itself: the Principles, the Guidelines and the Success Criteria.
What’s not normative in WCAG
Some of the WCAG text is not normative, like the Introduction section. It is marked as such (“This section is non-normative”).
There is also a number of documents to help use WCAG, including Techniques and Understanding documents. These documents are not normative either. They are additional information, context and examples, but not requirements to meet the norm (see 5.1, Interpreting Normative Requirements).
For instance, if you would evaluate whether a website meets the WCAG criteria, what matters for conformance is the text of the relevant criterion. The text in a Technique or Understanding document can help understand the intents and purposes of the norm, but it is not the norm. You don’t need to follow any specific Technique to be conformant.
The same goes for pages like ARIA Authoring Practices Guide, which is a Working Group Note. For more info on different kinds of see also Documents published at W3C.
The norm is the core
In most standards, the part that has become the norm was discussed and tweaked by many people over an extended time. Working Groups often spend years ensuring a wide variety of people was consulted and many views heard. There are likely many other things that could have made it in, but this was the text on which the Working Group reached consensus: it was supported by a substantial part of the group, and no formal objection was registered.
That leads me to an important point regarding WCAG: the normative part is the minimum to make your site work for users with disabilities. There are lots of best practices outside WCAG scope that benefit actual people–absolutely do find and use those!
Conclusion
In WCAG, the main text is normative, which means it is required to meet the standard. Other texts like Techniques, Understanding documents and ARIA Authoring Practices are not, they provide useful context, examples, background information and more.
The post What's ‘normative’ in WCAG? was first posted on hiddedevries.nl blog | Reply via email
What's ‘normative’ in WCAG?
I’m currently involved in a project to make some of the WCAG guidance more clear. One of the distinctions we’re hoping to clarify is: what’s normative in WCAG?
‘Normative’, meaning something like ‘required to meet the norm’, is a common phrase in (web) specifications. You’ll find it in WCAG, but also in HTML, CSS and many others. Specifications say what we should do (‘do X’), in a way that can be evaluated afterwards (‘was X done?’).
For instance, the normative sentence ‘Web pages have titles that describe topic or purpose’ (from: Page titled) can be evaluated: if a web page has a title and it describes topic or purpose, it’s a pass. Otherwise, it’s a fail.
The opposite of ‘normative’ is ‘informative’, it is something that is not required for conformance to the norm. You may also find it is called ‘non-normative’, ‘not required’ or descriptive in some places.
As an aside, the words ‘may’, ‘must’, ‘must not’, ‘not recommended’, ‘recommended’, ‘should’ and ‘should not’ have special meaning in the context of specifications like WCAG. This meaning is defined in a document called RFC 2119.
What’s normative in WCAG
The part of WCAG that is normative is the main WCAG text itself: the Principles, the Guidelines and the Success Criteria.
What’s not normative in WCAG
Some of the WCAG text is not normative, like the Introduction section. It is marked as such (“This section is non-normative”).
There is also a number of documents to help use WCAG, including Techniques and Understanding documents. These documents are not normative either. They are additional information, context and examples, but not requirements to meet the norm (see 5.1, Interpreting Normative Requirements).
For instance, if you would evaluate whether a website meets the WCAG criteria, what matters for conformance is the text of the relevant criterion. The text in a Technique or Understanding document can help understand the intents and purposes of the norm, but it is not the norm. You don’t need to follow any specific Technique to be conformant.
The same goes for pages like ARIA Authoring Practices Guide, which is a Working Group Note. For more info on different kinds of see also Documents published at W3C.
The norm is the core
In most standards, the part that has become the norm was discussed and tweaked by many people over an extended time. Working Groups often spend years ensuring a wide variety of people was consulted and many views heard. There are likely many other things that could have made it in, but this was the text on which the Working Group reached consensus: it was supported by a substantial part of the group, and no formal objection was registered.
That leads me to an important point regarding WCAG: the normative part is the minimum to make your site work for users with disabilities. There are lots of best practices outside WCAG scope that benefit actual people–absolutely do find and use those!
Conclusion
In WCAG, the main text is normative, which means it is required to meet the standard. Other texts like Techniques, Understanding documents and ARIA Authoring Practices are not, they provide useful context, examples, background information and more.
Originally posted as What's ‘normative’ in WCAG? on Hidde's blog.