Good question! And a good answer:
If you really need it, which you probably don’t,
readonlyis what you want.
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.
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.
It looks like the
async attribute is going to ship in Chrome for
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.
James has been tweaking the accessibility of his site navigation. I’m looking forward to the sequel.
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:
- Be completely devoid of any licensing requirements.
- Be vendor-neutral.
- Be device-neutral and media-neutral.
- Be content-neutral.
- Be radically better than the existing Web.
You come at the king, you best not miss.
Here’s a great free curriculum for teaching HTML and CSS.
A great bit of web history spelunking in search of the first websites that allowed users to interact with data on a server. Applications, if you will. It’s well written, but I take issue with this:
The world wide web wasn’t supposed to be this fun. Berners-Lee imagined the internet as a place to collaborate around text, somewhere to share research data and thesis papers.
This often gets trotted out (“the web was intended for scientists sharing documents”), but it’s simply not true that Tim Berners-Lee was only thinking of his immediate use-case; he deliberately made the WWW project broad enough to allow all sorts of thitherto unforeseen uses. If he hadn’t …well, the web wouldn’t have been able to accommodate all those later developments. It’s not an accident that the web was later used for all sorts of unexpected things—that was the whole idea.
Anyway, apart from that misstep, the rest of the article is a fun piece, well worth reading.
When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
I’ve had a few conversations with members of the Google AMP team, and I do believe they care about making the web better. But given how AMP pages are privileged in Google’s search results, the net effect of the team’s hard, earnest work comes across as a corporate-backed attempt to rewrite HTML in Google’s image. Now, I don’t know if these new permutations of AMP will gain traction among publishers. But I do know that no single company should be able to exert this much influence over the direction of the web.
I quite like this proposal for
geo element in HTML, especially that it has a fallback built in (like
video). I’m guessing the next step is to file an issue and create a web component to demonstrate how this could work.
That brings up another question: what do you name a custom element that you’d like to eventually become part of the spec? You can’t simply name it
geo because you have to include a hyphen.
- Do not depend on color
- Do not block zoom
- Rediscover the alt attribute
- Add subtitles and captions to your videos
- Semantics = accessibility
- Use the right mark-up
- Use roles when necessary
- On hiding elements
- Follow web accessibility standards
- Audit and review
Riffing on Rachel’s talk at Patterns Day:
At the Patterns Day conference last month, Rachel Andrew mentioned something interesting about patterns. She said that working with reusable interface components, where each one has its own page, made her realise that those work quite well as isolated test cases. I feel this also goes for some accessibility tests: there is a number of criteria where isolation aids testing.
Hidde specifically singles out these patterns:
- Collapsible (“Show/hide”)
- Form field
- Video player
Web developers aren’t going to shed many tears for Flash, but as Bruce rightly points out, it led the way for many standards that followed. Flash was the kick up the arse that the web needed.
He also brings up this very important question:
I’m also nervous; one of the central tenets of HTML is to be backwards-compatible and not to break the web. It would be a huge loss if millions of Flash movies become unplayable. How can we preserve this part of our digital heritage?
This is true of the extinction of any format. Perhaps this is an opportunity for us to tackle this problem head on.
I’m looking for work. I’d prefer to work remotely with a product team and to work in the areas I love: accessibility, CSS, and HTML. But it turns out those three things are considered “easy” in the industry right now. Which is fascinating because if you talk to anyone who uses assistive technology to surf the web or who doesn’t use a mouse, or who is accessing content in a different manner, you’ll find out it isn’t so easy.
Somebody hire Susan already!
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
Here’s an interesting proposal to slightly amend the semantics of the
small element so it could apply to the use-case that
hgroup was trying to cover.
This is an excellent proposal from Emil. If we can apply
display: contents to fieldsets, then we would finally have a way of undoing the byzantine browser styles that have hindered adoption of this element. This proposal also ensures backwards compatibility so there’d be no breakage of older sites:
The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But
display: contentsis not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets.
Whaddya say, browser makers?
A look at the feedback needed for a slider control that feels “right”.
You can get most of the behavioural (though not styling) suggestions in HTML by doing this:
<form> <input type="range" min="0" max="100" value="50" onchange="amount.value=this.value" onmousemove="amount.value=this.value"> <output name="amount">50</output> </form>