Tags: markup

412

sparkline

Tuesday, August 21st, 2018

The Web I Want - DEV Community 👩‍💻👨‍💻

Scores of people who just want to deliver their content and have it look vaguely nice are convinced you need every web technology under the sun to deliver text.

This is very lawnoffgetting but I can relate.

I made my first website about 20 years ago and it delivered as much content as most websites today. It was more accessible, ran faster and easier to develop then 90% of the stuff you’ll read on here.

20 years later I browse the Internet with a few tabs open and I have somehow downloaded many megabytes of data, my laptop is on fire and yet in terms of actual content delivery nothing has really changed.

Monday, August 20th, 2018

Front-End Performance Checklist

A handy pre-launch go/no-go checklist to run through before your countdown.

Friday, August 10th, 2018

Understanding why Semantic HTML is important, as told by TypeScript.

Oh, this is such a good analogy from Mandy! Choosing the right HTML element is like choosing the right data type in a strongly typed programming language.

Get to know the HTML elements available to you, and use the appropriate one for your content. Make the most it, like you would any language you choose to code with.

Thursday, August 2nd, 2018

Accessibility: Start with the foundations | susan jean robertson

I encourage you to think about and make sure you are using the right elements at the right time. Sometimes I overthink this, but that’s because it’s that important to me - I want to make sure that the markup I use helps people understand the content, and doesn’t hinder them.

Friday, July 27th, 2018

Designing for Everyone: Building Great Web Experiences for Any Device

The slides and video from a really great well-rounded talk by Aaron, filled with practical examples illustrating concepts like progressive enhancement and inclusive design.

Monday, July 23rd, 2018

On Designing and Building Toggle Switches

Sara shows a few different approaches to building accessible toggle switches:

Always, always start thinking about the markup and accessibility when building components, regardless of how small or simple they seem.

Friday, July 20th, 2018

Short note on progressive ARIA by The Paciello Group

Léonie makes a really good point here: if you’re adding aria attributes to indicate interactions you’re making available through JavaScript, then make sure you also use JavaScript to add those aria attributes.

Tuesday, July 10th, 2018

Web Components in 2018 - Blog | SitePen

A good explanation of web components, complete with some code examples.

Web Components are not a single technology. Instead, they are series of browser standards defined by the W3C allowing developers to build components in a way the browser can natively understand. These standards include:

  • HTML Templates and Slots – Reusable HTML markup with entry points for user-specific markup
  • Shadow DOM – DOM encapsulation for markup and styles
  • Custom Elements – Defining named custom HTML elements with specific behaviour

Components and concerns

We tend to like false dichotomies in the world of web design and web development. I’ve noticed one recently that keeps coming up in the realm of design systems and components.

It’s about separation of concerns. The web has a long history of separating structure, presentation, and behaviour through HTML, CSS, and JavaScript. It has served us very well. If you build in that order, ensuring that something works (to some extent) before adding the next layer, the result will be robust and resilient.

But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:

Rather than separating concerns by languages (such as HTML, CSS, and JavaScript), we’re are working towards a model of separating concerns at the component level.

This echoes a point made previously in a slidedeck by Cristiano Rastelli.

Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?

There’s nothing in the “traditonal” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages. In fact, I would say it works best when it’s applied on smaller scales.

In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:

Your starting point should always be well-structured markup.

This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.

That’s basically an application of starting with the rule of least power.

In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:

We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”

There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.

My point is this:

  • Separating structure, presentation, and behaviour is a good idea.
  • Separating an interface into components is a good idea.

Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.

Sunday, July 1st, 2018

Wednesday, June 20th, 2018

Don’t Use The Placeholder Attribute — Smashing Magazine

A lot of the issues here are with abuses of the placeholder attribute—using it as a label, using it for additional information, etc.—whereas using it quite literally as a placeholder can be thought of as an enhancement (I almost always preface mine with “e.g.”).

Still, there’s no getting around that terrible colour contrast issue: if the contrast were greater, it would look too much like an actual pre-filled value, and that’s potentially worse.

Monday, June 11th, 2018

Designing Web Content for watchOS - WWDC 2018 - Videos - Apple Developer

If you don’t fancy watching this video, Eric Runyon has written down the salient points about what it means for developers now that websites can be viewed on the Apple Watch. Basically, as long as you’re writing good, meaningful markup and you’ve got a sensible font stack, you’re all set.

Or, as Tim puts it:

When we build our sites in a way that allows people using less-capable devices, slower networks and other less than ideal circumstances, we end up better prepared for whatever crazy device or technology comes along next.

Thursday, May 31st, 2018

Know your ARIA: ‘Hidden’ vs ‘None’ | scottohara.me

When to use aria-hidden="true", and when you might need display: none:

aria-hidden by itself is not enough to completely hide an element from all users, if that is the end goal.

When to use role="presentation" (or role="none"):

Where aria-hidden can be used to completely hide content from assistive technology, modifying an element’s role to “none” or “presentation” removes the semantics of the element, but does not hide the content from assistive technologies.

Saturday, May 26th, 2018

CSS and Markup in Javascript is an Evolutionary Dead End

The bet to make is that we’re going to see more use of specialized languages. And HTML and CSS are the grandaddy specialized languages that have enough social consensus and capital investment to be the seeds of the next generation.

Wednesday, May 9th, 2018

CodePen Challenge - May 2018 - HTML Buddies

I really like this month’s CodePen challenge, all about HTML elements that go well together. First up: del and ins.

Monday, April 23rd, 2018

Animating Progress - Snook.ca

Jonathan goes down the rabbit hole of trying to animate a progress element.

Monday, April 16th, 2018

inessential: The View-Source Web

Lesson learned: the discoverable and understandable web is still do-able — it’s there waiting to be discovered. It just needs some commitment from the people who make websites.

Thursday, April 12th, 2018

Notes on `lang` by Taylor Hunt on CodePen

A really deep dive into the lang attribute, and the :lang() pseudo-class (hitherto unknown to me). This is all proving really useful for a little side project I’m working on.

Wednesday, March 28th, 2018

Quick Reminder that Details/Summary is the Easiest Way Ever to Make an Accordion | CSS-Tricks

Hells, yeah! Want to make an accordion widget? Use the details element as your starting point and progressively enhance from there.