Last week a poll about CSS did the rounds with a question about the cascade. It got me thinking about CSS and overlapping skills in front-end development.

Is the cascade more complex than other concepts?

The question was, given two class selectors applied to two elements which had the order of classes as their only difference, what they would look like. Many respondents got it wrong. CSS nerds replied that the question was fairly basic, JS nerds replied CSS is shit. Ok, that was likely a troll. There were also sentiments like ‘you don’t get web development if you don’t understand the cascade’ or ‘you don’t get web development if you do like doing CSS’. Oh oh, social media… why am I on it?

Before continuing, I do want to defend CSS. It is a pretty smart and well-considered language. It is not a programming language by design. Concepts like the cascade are complex, but they aid the simplicity of the language, which was an important design principle.

Admittedly, it takes time to grasp such concepts before you can take full advantage of them. But isn’t that the case for most concepts in web development? Component lifecycle hooks, accessibility trees, dockerisation, OIDC, Lambda functions, writing mode agnostic (logical) properties, Content-Security Policies, DNS entries, git rebase… they all make complex-to-understand things available in simple-to-use ways. About many of these, I was frustated at first, but happy and excited ever after.

CSS may (seem to) miss some of the determinism, scoping and typing that many programmming languages offer, but I believe it is precisely the lack of those sorts of things that makes it extremely accessible to learn and use. It is by design that you can’t know what you HTML will look like. And we’re able to use JavaScript to add such features ourselves, if our codebase or team is of a size that requires them.

Overlapping skills

As people who make websites, we all specialise in different things. They often overlap. Some of us are markup nerds, server side rendering nerds, svg nerds, sysadmin nerds, security nerds, network nerds, Grid Layout nerds, webfonts nerds… most are a combination of many of these things. Some of us aren’t even nerds. It’s all good. In my view, it is unlikely any person overlaps with all the things, although there are people who get dangerously close.

If I learned anything from reading the comments, besides ‘don’t read the comments’, it is this: I need to remind myself that we can all learn so much from each other, because skills overlap. That requires not a ‘X is shit’ attitude, but a ‘how does X work?’ one.

Originally posted as Overlapping skills in front-end development on Hidde's blog.

Reply via email

The heading structure of a web page is like its table of contents. It gives people who can’t see your page a way to navigate it without reading everything.

To be clear, by ‘heading structure’ in this post, I mean the heading elements in your HTML: <h1> to <h6> . These elements can be strongly intertwined with what they look like, but for our purposes it is the markup that matters.

The best analogy I’ve been able to come up with for heading structures, is the feature in Microsoft Word that lets users generate a table of contents automatically. It is used a lot by all kinds of people, in all kinds of environments (in long corporate documents, but also in academia). If you’ve set document headings correctly, it lists all sections and subsections. It even remembers, and updates, which page they are on.

Example of the automagic table of contents feature in Pages. It even lets you select which heading levels to include!

All websites have this too, as a similar feature is built into most screenreaders. In VoiceOver, for example, users can press a button to see a list of all headings and use this to navigate a page. In fact, this is a common way for screenreader users to get around your page without reading everything.

The headings feature in action on Wikipedia. Note that Wikipedia also lists the headings explicitly, with section numbering.

Only use headings to identify sections

To let users get the best navigate-by-headings experience, only use heading elements for content that actually identifies a section. Ask ‘would this be useful in my table of contents?’, and if the answer is no, best choose a different HTML element. This way, only table of contents material makes it into your heading structure.

For this reason, by the way, I recommend to avoid having headings be part of user generated content (as in: content added not by content specialist, but by users of your site). If you offer Markdown for comments, for example, headings in those comments could mess with the usability of your heading structure.

If you choose something to be a header, make sure it describes the section underneath it. This can be hard to get right, you might have great puns in your headings, or maybe they were written by a SEO expert.

Visually hidden headings

Not all sections have headings, often the visual design makes it clear that something is a distinct piece of content. That’s great, but it doesn’t have to stop a section from also showing up in your table of contents. Hidden headings to the rescue!

A hidden heading is one that is ‘visually hidden’, this is content that is not visual on screen, but it exists in your markup and screenreaders can use it:

<h2 class="visually-hidden">Contact information</h2>
<!-- some content that looks visually a lot like contact
     information, with icons and a receptionist stock
     photo that makes it all very obvious-->

(More about CSS to visually hide)

The heading goes into your virtual table of contents, but it is not visible on screen.

Note that visible headings are much preferred to hidden headings. There are two problems in particular with hidden headings:

• Like with other hidden content, it can easily be forgotten about by your future self or the next team member. Hidden content that is not up to date with the visible content is unhelpful, so it is a bit of a risk.
• Serving slightly different content may cause confusing conversations, for example if an AT user and a sighted user discuss a page and only one of them knows that there is a heading.

‘Don’t skip heading levels’

Although WCAG 2 does not explicitly forbid skipping heading levels, and this is controversial, I would say it is best not to skip heading levels.

If a contract has clause 2.4.2, it would be weird for there not to be a 2.4 — the former is a subclause of the latter. It would be weird for the subclause to exist without the main clause.

The most common reason why people skip headings is for styling purposes: they want the style that comes with a certain heading and that happens to be the wrong level for structural purposes. There are two strategies to avoid this:

• have agreement across the team about how heading levels work
• use .h1, .h2, .h3 classes, so that you can have correct heading levels, but style them however you like

The former is what I prefer, on many levels, but if it is a choice between weird CSS and happy users, that’s an easy one to make.

Automatically correct headings

The outline algorithm mentioned in HTML specifications is a clever idea in theory. It would let you use any headings you’d like within a section of content; the browser would take care of assigning the correct levels. Browsers would determine these levels by looking at ‘sectioning elements’. A sectioning element would open a new section, browsers would assume sections in sections to be subsections, and headings within them lower level headings.

There is no browser implementing the outline algorithm in a way that the above works. One could theoretically have automated heading levels with clever React components. I like that idea, although I would hesitate adding it into my codebases. That leaves us with manually choosing plain old headings level, from 1 to 6.

Conclusion

Heading structures give screenreader users and others a table of contents for our sites. By being conscious of that, we can make better choices about heading levels and their contents.

Originally posted as Heading structures are tables of contents on Hidde's blog.

Reply via email

In Benjamin’s poll, the second most voted reason to avoid Grid Layout was supporting Internet Explorer users. I think it all depends on how we want to support users. Of any browser. Warning: opinions ahead.

What lack of Grid Layout means

Let’s look at what a browser that does not support Grid Layout actually means.

What it is not

To be very clear, let’s all agree this is not the case:

• Browsers that support Grid Layout: users see a great layout
• Browsers that don’t support Grid Layout: users see a blank page

That would be bad. Luckily, it is not that bad. CSS comes with a cascade, which includes the mechanism that the values of style rules are always set to something. Rules have a default value, which is usually what browsers will apply for you. It can be overridden by a website’s stylesheet, which in turn can also be overridden by user stylesheets. Because of the design of CSS, properties always compute to some value.

What it is

When turning an element on the page into a grid, we apply display: grid to it. At that point, it becomes a grid container and we can apply grid properties to it (and its children). If we set display: grid in an unsupported browser, the element will simply not become a grid container, and it will not get any of the grid properties you set applied. The display property will be whatever it was, usually inline or block, different elements have different defaults.

A little sideline: per spec, if you use floats (or clear), they will be ignored on children of grid containers. This is great for fallbacks.

Without Grid Layout, you still get your content, typography, imagery, colours, shadows, all of that. It will likely be displayed in a linear fashion, so it will be more or less like most mobile views. That is a perfectly ok starting point and it is good-looking content that we can serve to everyone.

Serving users good-looking content

I think our goal, rather than supporting specific browsers or specific CSS properties, should always be this: to serve users good-looking content and usable interfaces that are on-brand. I think good-looking and usable do not depend on how griddy your layout is. On-brand might, though. Some brand design guidelines come with specific grids that content needs to be layed out in. But aren’t we already used to stretching such guidelines, building responsive interfaces that work across viewports? Shouldn’t we let go, because we cannot control a user’s browser?

If for some small proportion of our users, we let go of the specific grid we created with grid layout, that will not hurt them. Likely not without any fallback, but definitely not with a simple fallback based on floats, inline-block or maybe flex and/or feature queries. But keep it simple. As Jeremy Keith wrote:

You could jump through hoops to try to get your grid layout working in IE11, […] but at that point, the amount of effort you’re putting in negates the time-saving benefits of using CSS grid in the first place.

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere. We already do this across devices of different sizes. For responsive design, we’ve already accepted this inevitability. This whole thing is a communication issue, more than a technical issue.

Save costs and sanity

If we succeed in the communication part, we can spend less time on fallbacks, now and in the future (I’m not saying no time, we want good-looking content). An example: that mixin we created to automatically fallback grid to flex to inline-block might look like a great piece of engineering now, it may later become a piece of hard to comprehend code. Solving the communication issue instead of the technical one, will save time in initial development costs and help prevent technical debt.

Originally posted as Let's serve everyone good-looking content on Hidde's blog.

Reply via email

Having been long interested in artificial intelligence, it was one of my focus areas in university, I looked for theoretical background beyond the hype. If it is also summer where you are, you may have some extra reading time, too. So, I present you: an AI reading list.

This list is mostly about the philosophy of AI: what intelligence means, how it can be represented, what the ethical implications are of teaching machines, those kinds of questions. Expect to read about psychology, mathematics, linguistics, philosophy and computer science. It’s all of those things together that the field is made up of.

A common theme in these books is that AI application aren’t that intelligent yet or anywhere near ready to replace human intelligence. Phew. I discovered this myself looking for recent books on philosophy and AI. Online bookstore search engines (or category pages) were not that helpful for finding what I was looking for. Look in the ‘philosophy’ department and a book by Plato is listed first. Who reads Plato just by themselves? Book review pages in newspapers, blogs and humans in book stores helped more. Yes, humans!

The New Dark Age

In The Guardian’s review of this book they said enjoyment of it depends on whether you are a glass half full or half empty kind of person. Very much true, I think. The New Dark Age describes a lot of dark consequences of what Bridle calls ‘computational thinking’, the idea of throwing tech at every problem. This thinking seems prominent in Silicon Valley and it is dangerous, Bridle explains, because our problems are less about what we know (data) and much more about what we do and think. This book is not just about AI, it is also a lot about the impact of technology on society. We should think twice if we want to outsource decision making to systems, Bridle warns. Buy from the publisher to get a free e-book with your hardback.

Plato and the Nerd

Is AI ‘our biggest existential threat’, as Elon Musk once claimed? Edward Ashford Lee, writer of Plato and the Nerd doesn’t think so. What is more likely to happen and what we should want to happen, he explains in this book, is that humans and machines complement each other. We are creative, they can crunch lots of data at mesmerising speeds. We may not be more than just neurons (Lee isn’t a dualist), but it is unlikely we’ll ever be able to reconstruct human brains and minds in machines. If we’re making abstractions, like Plato did with his theory of Ideas, we should be careful not to confuse the map with the territory. This book brilliantly explains machines from semiconductors to programming languages to mathematical possibilities. It gets very technical and mathy at points. Lee shows how engineers are creative rather than technical: the most technical layers are abstracted away from them. He also talks about the relationship between tech and society: ‘I do not see how a true humanist today can understand society without understanding technology’, he says and I could not agree more.

From Bacteria to Bach: The Evolution of Mind

From Bacteria to Bach by philosopher Daniel Dennett is about evolution, what it means to (not) understand something (explained with the interesting notion of ‘competence without comprehension’) and how that changes our view on artificial intelligence, language, culture, consciousness and much more. The book is full of anecdotes and side steps, which for me at some point started to prevent Dennett from clearly getting his point across, it was a bit overwhelming. But then again, the book is full of interesting analysis of where the fields of philosophy, psychology and computer science have overlap. See also The Guardian’s review, who said this about the book:

This is an infuriating book – too long and self-referential – but underlying it all is an interesting argument

Common sense, the Turing test and the quest for real AI

In 2018 many of us think of adaptive machine learning (AML) if we think about AI. In Common sense, the Turing test and the quest for real AI, Hector J. Levesque takes us back to what it all started with: good old-fashioned artificial intelligence (GOFAI). It goes into detail about what can’t really be learned by machines: common sense. He explains Winograd Schemas, which is his modern equivalent of the Turing test: they can be used to figure out if a machine is ‘making it or faking it’. I liked how concise and lucid this book is.

Turing’s Vision

Turing’s Vision, which I raved about before, is about one of Alan Turing’s most interesting papers, in which he tries to prove the mathematician Hilbert wrong. That paper shines new light on something called the ‘decision problem’ (‘whether we can write algorithms that can decide if certain mathematical statements are true or false’). This book is fairly technical, I had to skip parts because I had not enough intelligence. Your mileage may vary.

That’s all for now, happy reading! I’d love to hear what others are reading in comments or e-mail.

Originally posted as An AI reading list on Hidde's blog.

Reply via email

According to WCAG 2.4.2 pages should have titles. How to go about this in a single page world?

What are titles for?

Pages have titles so that people can recognise where they are. They are like a plaquette on a meeting room door, signposts that mark the platform in a train station or the signage for a supermarket aisle. They help people figure out where they are.

Additionally, page titles also signify uniquely what’s on a URL. This is helpful for search engines, they display the title. Or for social media platforms, they display it when you share a link. People using screenreaders hear the title, it lets them figure out what a page is when they land on it.

Titling pages, the traditional way

In a site with multiple pages, you can put different content in the <title> element for each different page. This is trivial if you build each page separately, it is a little more work when the value comes out of a CMS, but still fairly straightforward.

Titling pages in Single Page Apps

In a Single Page App (SPA), the user never leaves the page. There is no new page with a new title. Instead, you’ll have to update this manually by changing the value or document.title , which is where the page title is in the DOM.

Changing pages in SPAs is often done with routers like react-router and vue-router . I was surprised to see that, by default, those two only update content and the URL, not the document title.

You can update the page title manually, though. In React, you can do it in the componentDidMount() of a route, and there is a react-document-title package that does it for you. If you want to update more meta info than just the title, there is React Helmet.

In Vue, I had luck doing it in beforeEach of the router:

router.beforeEach((to, from, next) => {
  document.title = `${to.name} - Your site`;
  next();
});

But if you’d like to abstract this further and update the page’s title along with other things in the head of your document, there is Vue Helmet or Vue Meta.

(Update 2 June 2020) In Svelte, you can set page titles using the special <svelte:head> element in the components that you use as a route, like so:

<!-- MyPage.svelte -->
<svelte:head>
  <title>Page Title goes here</title>
</svelte:head>

Announcing titles

In screenreaders, when a user goes to a new page, it will read out the title of that page. In a Single Page App world, you can update the title with document.title , but, sadly, that change does not trigger a screenreader announcement. It is helpful to do this manually, for example by putting content into a live region (the on demand live region abstracts this).

There are different strategies as to what to read out on a route. In an SPA, you could choose to set focus to the top of the document when you do a route, this would make it feel like a multi page application. Users would have to use skip links to get back to the content, just like in multi page applications. But maybe you only update one section, and your strategy is to move focus to the new content. In this case, you could ensure the title of whatever is new is read out, rather than the updated page title. For example, if you replace the main by something new and then focus the new content, convey to assistive technologies what the title of the newly focused content is, for example by having its first heading announced.

Does this mean the title is irrelevant in SPAs? Not really, it is still useful to have an up to date title , for example for people switch between tabs or when you turn on Server Side Rendering.

TL;DR

Giving pages unique titles aids accessibility and is compulsory if you are after WCAG 2 AA compliance. If you build a single page app, update the title manually, but also look at having something useful announced when new content is inserted. It could make more sense for this to be a section title than the document’s title, depending on what you’re building.

Originally posted as Accessible page titles in a Single Page App on Hidde's blog.

Reply via email