Tags: html

564

sparkline

Sunday, January 21st, 2018

Small Tweaks That Can Make a Huge Impact on Your Website’s Accessibility | CSS-Tricks

What it says on the tin—a few suggestions to ensure the accessibility of your site.

Sunday, January 14th, 2018

Meet the New Dialog Element

Move over, JavaScript alerts; HTML dialogs are here.

Thursday, January 11th, 2018

Turning Design Mockups Into Code With Deep Learning - FloydHub Blog

Training a neural network to do front-end development.

I didn’t understand any of this.

Wednesday, January 10th, 2018

Little UI details from @steveschoger, in HTML and CSS

Suggestions for small interface tweaks.

Saturday, January 6th, 2018

A Sliding Nightmare: Understanding the Range Input | CSS-Tricks

Ana goes into exhaustive detail on all the differences in the shadow DOM and styling of input type="range" across browsers.

I’m totally fine with browsers providing different styling for complex UI elements like this, but I wish they’d at least provide a consistent internal structure and therefore a consistent way of over-riding the default styles. Maybe then people wouldn’t be so quick to abandon native elements like this in favour building their own UI components from scratch—the kind of over-engineering that inevitably ends up being under-engineered.

Friday, January 5th, 2018

Improving the Accessibility of 24 ways | CSS-Tricks

Paul walks us through the process of making some incremental accessibility improvements to this year’s 24 Ways.

Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact.

Friday, December 29th, 2017

The Trials and Tribulations of the Title Attribute - 24 Accessibility

Everything you ever wanted to know about the title attribute in HTML.

What’s hot: using title on inputs, abbrs, and iframes.

What’s not: using title on anything else.

Saturday, December 23rd, 2017

Ubiquity and consistency

I keep thinking about this post from Baldur Bjarnason, Over-engineering is under-engineering. It took me a while to get my head around what he was saying, but now that (I think) I understand it, I find it to be very astute.

Let’s take a single interface element, say, a dropdown menu. This is the example Laura uses in her article for 24 Ways called Accessibility Through Semantic HTML. You’ve got two choices, broadly speaking:

  1. Use the HTML select element.
  2. Create your own dropdown widget using JavaScript (working with divs and spans).

The advantage of the first choice is that it’s lightweight, it works everywhere, and the browser does all the hard work for you.

But…

You don’t get complete control. Because the browser is doing the heavy lifting, you can’t craft the details of the dropdown to look identical on different browser/OS combinations.

That’s where the second option comes in. By scripting your own dropdown, you get complete control over the appearance and behaviour of the widget. The disadvantage is that, because you’re now doing all the work instead of the browser, it’s up to you to do all the work—that means lots of JavaScript, thinking about edge cases, and making the whole thing accessible.

This is the point that Baldur makes: no matter how much you over-engineer your own custom solution, there’ll always be something that falls between the cracks. So, ironically, the over-engineered solution—when compared to the simple under-engineered native browser solution—ends up being under-engineered.

Is it worth it? Rian Rietveld asks:

It is impossible to style select option. But is that really necessary? Is it worth abandoning the native browser behavior for a complete rewrite in JavaScript of the functionality?

The answer, as ever, is it depends. It depends on your priorities. If your priority is having consistent control over the details, then foregoing native browser functionality in favour of scripting everything yourself aligns with your goals.

But I’m reminded of something that Eric often says:

The web does not value consistency. The web values ubiquity.

Ubiquity; universality; accessibility—however you want to label it, it’s what lies at the heart of the World Wide Web. It’s the idea that anyone should be able to access a resource, regardless of technical or personal constraints. It’s an admirable goal, and what’s even more admirable is that the web succeeds in this goal! But sometimes something’s gotta give, and that something is control. Rian again:

The days that a website must be pixel perfect and must look the same in every browser are over. There are so many devices these days, that an identical design for all is not doable. Or we must take a huge effort for custom form elements design.

So far I’ve only been looking at the micro scale of a single interface element, but this tension between ubiquity and consistency plays out at larger scales too. Take page navigations. That’s literally what browsers do. Click on a link, and the browser fetches that URL, displaying progress at it goes. The alternative, as exemplified by single page apps, is to do all of that for yourself using JavaScript: figure out the routing, show some kind of progress, load some JSON, parse it, convert it into HTML, and update the DOM.

Personally, I tend to go for the first option. Partly that’s because I like to apply the rule of least power, but mostly it’s because I’m very lazy (I also have qualms about sending a whole lotta JavaScript down the wire just so the end user gets to do something that their browser would do for them anyway). But I get it. I understand why others might wish for greater control, even if it comes with a price tag of fragility.

I think Jake’s navigation transitions proposal is fascinating. What if there were a browser-native way to get more control over how page navigations happen? I reckon that would cover the justification of 90% of single page apps.

That’s a great way of examining these kinds of decisions and questioning how this tension could be resolved. If people are frustrated by the lack of control in browser-native navigations, let’s figure out a way to give them more control. If people are frustrated by the lack of styling for select elements, maybe we should figure out a way of giving them more control over styling.

Hang on though. I feel like I’ve painted a divisive picture, like you have to make a choice between ubiquity or consistency. But the rather wonderful truth is that, on the web, you can have your cake and eat it. That’s what I was getting at with the three-step approach I describe in Resilient Web Design:

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

Like, say…

  1. The user needs to select an item from a list of options.
  2. Use a select element.
  3. Use JavaScript to replace that native element with a widget of your own devising.

Or…

  1. The user needs to navigate to another page.
  2. Use an a element with an href attribute.
  3. Use JavaScript to intercept that click, add a nice transition, and pull in the content using Ajax.

The pushback I get from people in the control/consistency camp is that this sounds like more work. It kinda is. But honestly, in my experience, it’s not that much more work. Also, and I realise I’m contradicting the part where I said I’m lazy, but that’s why it’s called work. This is our job. It’s not about what we prefer; it’s about serving the needs of the people who use what we build.

Anyway, if I were to rephrase my three-step process in terms of under-engineering and over-engineering, it might look something like this:

  1. Start with user needs.
  2. Build an under-engineered solution—one that might not offer you much control, but that works for everyone.
  3. Layer on a more over-engineered solution—one that might not work for everyone, but that offers you more control.

Ubiquity, then consistency.

Wednesday, November 29th, 2017

Accessible custom styled form elements - Rian Rietveld

An excellent level-headed evaluation of styling and scripting form controls, weighing up the benefits and trade-offs. The more tightly you control the appearance, the less you get to benefit from the functionality (and accessibility) that the browser gives you for free …meaning you’ve now to got to work harder to replace it.

HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, but are they accessible?

Tuesday, November 28th, 2017

i is=”the walrus”

In which Brian takes a long winding route through an explanation of why the is attribute for custom elements is dead before he demonstrates the correct way to use web components:

<!-- instead of writing this -->
<input type="radio" is="x-radio">

<!-- you write this -->
<x-radio>
<input type="radio">
</x-radio>

Sadly, none of the showcase examples I’ve seen for web components do this.

Thursday, November 23rd, 2017

Localisation and Translation on the Web

Practical advice from Ire on localising web pages.

A Content Slider

Brad always said that carousels were way to stop people beating each other up in meetings. I like the way Heydon puts it:

Carousels (or ‘content sliders’) are like men. They are not literally all bad — some are even helpful and considerate. But I don’t trust anyone unwilling to acknowledge a glaring pattern of awfulness. Also like men, I appreciate that many of you would rather just avoid dealing with carousels, but often don’t have the choice. Hence this article.

Monday, November 20th, 2017

Happier HTML5 Form Validation - daverupert.com

Dave uses just a smidgen of JavaScript to whip HTML5’s native form validation into shape.

Instead of being prescriptive about error messaging, we use what the browser natively gives us.

Wednesday, November 8th, 2017

A Responsive Accessible Table | Adrian Roselli

Following on from Richard’s article, here’s a deep dive into making HTML tables that are accessible and responsive.

Wednesday, November 1st, 2017

Web Form Conundrum: disabled or readonly? | Aaron Gustafson

Good question! And a good answer:

If you really need it, which you probably don’t, readonly is what you want.

Tuesday, October 31st, 2017

‘Neopets’: Inside Look at Early 2000s Internet Girl Culture - Rolling Stone

Girls on Neopets took what they needed from the site and used the skills acquired there to further develop a burgeoning digital girls’ culture, whether it be in expanding their guild pages into personal sites, teaching others to code, or exchanging those skills for economic gain in Neopets.

I have anecdotal evidence from a few people that Neopets was their introduction to web design and development.

Netflix functions without client-side React, and it’s a good thing - JakeArchibald.com

A great bucketload of common sense from Jake:

Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.

And here’s a good way of thinking about that:

I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.

All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:

Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.

Monday, October 9th, 2017

“async” attribute on img, and corresponding “ready” event · Issue #1920 · whatwg/html

It looks like the async attribute is going to ship in Chrome for img elements:

This attribute would have two states:

  • “on”: This indicates that the developer prefers responsiveness and performance over atomic presentation of content.
  • “off”: This indicates that the developer prefers atomic presentation of content over responsiveness.

Thursday, October 5th, 2017

Creating accessible menus-Part 1

James has been tweaking the accessibility of his site navigation. I’m looking forward to the sequel.

Tuesday, September 26th, 2017

Occasionally, people e-mail me to say something along the lines of “I’ve come up with something to replace HTML!”.

Five years ago, Hixie outlined the five metrics that a competitor to the web would have to score well in:

  1. Be completely devoid of any licensing requirements.
  2. Be vendor-neutral.
  3. Be device-neutral and media-neutral.
  4. Be content-neutral.
  5. Be radically better than the existing Web.

You come at the king, you best not miss.