When I was doing developer relations at Opera, I did everything I could to avoid having to go near the Opera TV part of the business – which was basically an app store of HTML5 websites for “Smart” TVs. This was for three reasons: the world of Smart TVs was a world of closed standards. Secondly, as Patrick Lauke wrote, the chips in the early Smart TVs were cheap and crappy which seriously crippled the web experience.
But the main reason was that I felt Smart TVs were a solution looking for problem.
TVs are big, beautiful screens and good speakers, sitting in a social space. No-one wants to surf Facebook on a screen that mum and dad are also watching, especially controlling it with arrows on a remote control unit.
A cheap device like a Chromecast allows people to control the content with a portable device they already have and know how to use – be it a laptop, tablet or phone, and see the movie/ photos on a big screen with family and friends. TVs are meant to be dumb; your phone is smart and a little USB gizmo connects the two.
So why did Opera have a B2B division developing Smart TV offerings? (And after the dismemberment of Opera, it continues as Vewd). The answer: because TV set manufacturers wanted Smart TV, so would throw money at us. But why did the set manufacturers want it?
A news report last week made it clear: it’s about collecting data off users, hitting the network a lot to phone that data back to HQ, then “monetizing” it, in some cases, advertising to viewers. That helps reduce the cost at sale of TVs. As the Verge puts it: Taking the smarts out of smart TVs would make them more expensive. From their interview with TV manufacturer Vizio’s CTO Bill Baxter:
So look, it’s not just about data collection. It’s about post-purchase monetization of the TV.
This is a cutthroat industry. It’s a 6-percent margin industry, right? I mean, you know it’s pretty ruthless. You could say it’s self-inflicted, or you could say there’s a greater strategy going on here, and there is. The greater strategy is I really don’t need to make money off of the TV. I need to cover my cost.
…there are ways to monetize that TV and data is one, but not only the only one. It’s sort of like a business of singles and doubles, it’s not home runs, right? You make a little money here, a little money there. You sell some movies, you sell some TV shows, you sell some ads, you know.
I have a Smart TV (it’s difficult to find a new one that isn’t). I’ve never connected it to the web, for just this reason.
Best Internet Browsers of 2019 – “After 80 hours of researching and testing, we found Mozilla Firefox is the best overall internet browser because of how fast pages load, how quickly it navigates to websites and, most importantly, how secure this browser is”
W3C Advisory Committee Elects Technical Architecture Group – Alice Boxhall (Google), Theresa O’Connor (Apple) and my ex-Opera colleague Sangwhan Moon (Odd Concepts) join Sir Uncle Timbo’s Enforcement Posse. Thanks and best wishes to Travis Leithead (Microsoft) and Alex Russell (Google) on their retirement.
Dimensions.Guide – “Dimensions.Guide is a comprehensive reference database of dimensioned drawings documenting the standard measurements and sizes of the everyday objects and spaces that make up our world”. This is weirdly fascinating and pleasing.
How To Learn CSS – Auntie Rachel’s primer on fundamental CSS concepts. “There are some fundamental things which will make CSS much easier for you to use. This article aims to guide you along your path”
Why I’m Running for W3C TAG – Alice Boxhall is running for election to the W3C Technical Architecture Group. Now Opera is no more, I have no vote or sway, but she has my full and enthusiastic moral support.
Development Environment Machine Setup Screencast by Simon Owen. “Over the years I’ve noticed time and time again people having various issues with the set up and maintenance of their development environments. I try to keep the videos fairly short and to the point, so you can get through them quickly and learn and profit.”
The Chinese takeover of Indian app ecosystem – “The message is clear for the Chinese — if you want growth, conquer India”. At least some people listened to me! (Joking aside, there’s a lot in this article, especially about India2/ Bharat customers coning online)
2018: A Smashing Year In Review – by my colleagues and me. “We’re not just the publishers of an online magazine or conference organizers, we are people who work in the web industry”
As for HTML, there’s not much to learn right away and you can kind of learn as you go, but before making your first templates, know the difference between in-line elements like <span> and how they differ from block ones like <div>. This will save you a huge amount of headache when fiddling with your CSS code.
What is ‘good’ HTML?
In fact, part of what we commonly call ‘HTML5’ is the Parsing Algorithm which is like an HTML ninja – incredibly powerful, yet rarely noticed. It ensures that all modern browsers construct the same DOM from the same HTML, regardless of whether the HTML is well-formed or not. It’s the greatest fillip to interoperability we’ve ever seen.
By ‘good’ HTML, I mean semantic HTML, a posh term for choosing the right HTML element for the content. This isn’t a philosophical exercise; it has directly observable practical benefits.
For example, consider the <button> element. Using this gives you some browser behaviour for free:
A button is focusssable via the keyboard. I bet you, dear reader, know all the keyboard shortcuts for your IDE; it makes development much faster. Many people use only the keyboard when using a webpage. I do it because I have multiple sclerosis – therefore the fine motor control required to use a mouse can be difficult for me. My neighbour has arthritis, so she prefers to use the keyboard.
Buttons can be activated using the space bar or the enter key; you don’t have to remember to listen for these keypresses in your script.
Here’s another example: semantically linking a <label> to its associated <input> increases usability for a mouse-user or touch-screen user, because clicking in the label focusses into the input field. See this in action (and how to do it) on MDN.
This might be me, with my MS; it might be you, on a touch-screen device on a bumpy train, trying to check a checkbox. How much easier it is if the hit area also includes the label “uncheck to opt out of cancelling us not sending you spam forever”. (Compare the first and second identical-looking examples in a checkbox demo.)
But the point is that by choosing the right element for the job, you’re getting browser behaviour for free that makes your app more usable to a range of different people.
Invisible browser behaviours
With me so far? Good. The browser behaviours associated with the semantics of <button> and <label> are obvious once you know about them – because you can see them.
Other semantics aren’t so obvious to a sighted developer with a desktop machine and a nice big monitor, but they are incredibly useful for those who do need them. Let’s look at some of those.
HTML5 has some semantics that you can use for indicating regions on a page. For example, <nav>, <main>, <header>, <footer>.
If you wrap your main content – that is, the stuff that isn’t navigation, logo and main header etc – in a <main> tag, a screen reader user can jump immediately to it using a keyboard shortcut. Imagine how useful that is – they don’t have to listen to all the content before it, or tab through it to get to the main meat of your page.
And for people who don’t use a screenreader, that <main> element doesn’t get in the way. It has no default styling at all, so there’s nothing for you to remove. For those that need it, it simply works; for those that don’t need it, it’s entirely transparent.
Similarly, using <nav> for your primary navigation provides screenreader users with a shortcut key to jump to the navigation so they can continue exploring your marvellous site. You were probably going to wrap your navigation in a <div class=”nav”> to position it and style it; why not choose <nav> instead (it’s shorter!) and make your site more usable to the 15% of the world who have a disability?
We’re seeing more and more types of devices connecting to the web, and semantic HTML can help these devices display your content in a more usable way to their owners. And if your site is more usable than your competitors’, you win, and your boss will erect a massive gold statue of you in the office car park. (Trust me, your boss told me. They’ve already ordered the plinth.)
We’ve brought Reader to watchOS 5 where it automatically activates when following links to text heavy web pages. It’s important to ensure that Reader draws out the key parts of your web page by using semantic markup to reinforce the meaning and purpose of elements in the document. Let’s walk through an example. First, we indicate which parts of the page are the most important by wrapping it in an article tag.
Specifically, enclosing these header elements inside the article ensure that they all appear in Reader. Reader also styles each header element differently depending on the value of its itemprop attribute. Using itemprop, we’re able to ensure that the author, publication date, title, and subheading are prominently featured.
Many applications from Google, Microsoft, Pinterest, Yandex and others already use these vocabularies to power rich, extensible experiences.
(If you plan to put things into microdata, please note that Apple, being Apple, go their own way, and don’t use a schema.org vocabulary here. Le sigh. See my article Content needs a publication date! for more. Or view source on this page to see how I’m using microdata on this article.)
Apple WatchOS also optimises display of items wrapped in <figure> elements:
Reader recognizes these tags and preserves their semantic styles. For this image, we use figure and figcaption elements to let the Reader know that the image is associated with the below caption. Reader then positions the image alongside its caption.
You probably know that HTML5 greatly increased the number of different <input> types, for example <input type=”email”> on a mobile device shows a keyboard with the “@” symbol and “.” that are in all email addresses; <input type=”tel”> on a mobile device shows a numeric keypad.
On desktop browsers, where you have a physical keyboard, you may get different User Interface benefits, or built-in validation. You don’t need to build any of this; you simply choose the right semantic that best expresses the meaning of your content, and the browser will choose the best display, depending on the device it’s on.
In WatchOS, input types take up the whole watch screen, so choosing the correct one is highly desirable.
First, choose the appropriate type attribute and element tag for your form controls.
WebKit supports a variety of form control types including passwords, numeric and telephone fields, date, time, and select menus. Choosing the most relevant type attribute allows WebKit to present the most appropriate interface to handle user input.
Secondly, it’s important to note that unlike iOS and macOS, input methods on watchOS require full-screen interaction. Label your form controls or specify aria label or placeholder attributes to provide additional context in the status bar when a full-screen input view is presented.
I didn’t choose to use <article> and itemprop and input types because I wanted to support the Apple Watch; I did it before the Apple Watch existed, in order that my code is future-proof. By choosing the right semantics now, a machine that I don’t know about yet can understand my content and display it in the best way for its users. You are opting out of this if you only use <div> or <span> because, by definition, they have “no special meaning at all”.
I hope I’ve shown you that choosing the correct HTML isn’t purely an academic exercise. Perhaps you can’t use all the above (and there’s much more that I haven’t discussed) but when you can, please consider whether there’s an HTML element that you could use to describe parts of your content.
For instance, when building components that emit banners and logos, consider wrapping them in <header> rather than <div>. If your styling relies upon classnames, <header class=”header”> will work just as well as <div class=”header”>.
Semantic HTML will give usability benefits to many users, help to future-proof your work, potentially boost your search engine results, and help people with disabilities use your site.
And, best of all, thinking more about your HTML will stop Dull Old Web Farts like me moaning at you.
What’s not to love? Have a splendid holiday season, whatever you celebrate – and here’s to a semantic 2019!
How to Learn CSS – Rachel Andrew’s on the core concepts of CSS that will help you work with CSS, rather than against it.
The dialog element – intro to this very useful element. browser support is about 70% globally, behind a flag in Firefox. Polyfills are available.
Ways to extract slides – techy post by Remy Sharp. “When you run events, once everything is over, it’s nice to be able to share the slides both as a single link but also for the video production*… this post is reminder for my future self on how to do that.”
Programming CSS by Jezza Keef. “It’s precisely because CSS selectors (and the cascade) are so powerful that we choose to put guard rails in place.”
Open-source wedding site – “Now that my wedding is over, I am open-sourcing it”. fully responsive, RSVP uploads to Google Sheets & emails; Add to Calendar feature; single-tap book Uber to venue; no DB required – uses GitHub pages
Service Workies – “Learn Service Workers inside and out with the new PWA Mastery Game
W3C Strategic Highlights October 2018 – “we believe that having two distinct HTML and DOM specs claiming to be normative is generally harmful for the community”; joint work to be at WHATWG if I understand correctly
Chrome Dev Summit 2018 Day 2 Keynote (YouTube video) –
good news from the Chrome team: frameworks will be 1st class citizens: included in intent to implement notices; $200K of funding to improve performance; collaboration between Chrome team and framework devs
Braces to Pixels – Greg Whitworth explains how broozers take your CSS and make it into what you see on screen. It ain’t easy, and this is why Houdini will be so super – you’ll get all of this for free, and just hook into the bits you want to change.