At State of the Browser in London, a one day event in Conway Hall, organised by the London Web Standards team, eight speakers talked about recent developments in the web and web browsers. Topics included Service Workers, performance, responsive images, web ‘apps’ and new CSS features for responsive web design.

These are my notes of the day.

Fernando Campo & Borja Salguero – Firefox OS: not only promises

In their talk, Fernando and Borja of Telefónica’s Firefox OS team discussed what they have been working on and what their priorities are in terms of new features.

They said the phone is slow, as they focused first on getting it launched and focus now on making it better. It also has few apps, missing features and is hard to debug, but the team is working hard on making it better, faster and stronger.

Recent improvements

What they’ve been doing in the last half year to improve Firefox OS:

• There is an app manager which can be used from Firefox nightly. It helps to check the manifest file amongst other things. There is also a simulator, debugger (which works with either the simulator or a real device if you have one) and profiler (with which you can profile actions).
• In addition to that, two new measuring tools were launched that can help Firefox OS devs to improve performance: Datazilla and Eideticker (with which you can analyse ‘real’ fps)
• They have also introduced more APIs.

Ideas behind Firefox OS

Firefox OS is a project to push the web forward

Firefox OS, Borja explained, is really a project to push the web forward. To do this, Mozilla/Telefónica work together with a lot of partners. One improvement they want to achieve is the exchange of information between apps. Their solution for this is “Inter App Communication”, which helps apps ‘talk to each other’.

In the newest version, your phone will not be a thing you install apps on, it will be more like a browser. Because that is what Mozilla is good at, making browsers. The OS that doesn’t require you to install apps, completely changes the way we work with devices.

More is coming from the makers of Firefox OS, including FirefoxAccounts, your settings in the cloud, and project ‘Loop’ that employs WebRTC to let users call for free. There is also Project ‘Mulet’, which allows developers to do all things related to Firefox OS from the browser.

If we want to know more, Borja explained, there is a lot of documentation available on the Mozilla Developer Network, including screencasts.

At the end of the year new 25 USD devices will be introduced, with all the power of the web, aiming to open the web to people that could previously not afford devices with the same acces to the web.

Andreas Bovens – Intro to @viewport & other new Responsive Web Design CSS features

Andreas discussed some of the lesser known features for responsive web design that are in browsers already, but not used so much yet.

First, Andreas showed the various different browsers that Opera currently offers. There are Chromium-based browsers for Android, Opera Mini based on Presto and the experimental UX of Coast for iOS.

He then discussed four CSS features that are ideal in responsive design.

1. @viewports

The web started off fluid, there was hardly any way to do fixed layouts. Then table layouts came in and fixed CSS widths. Some years later, liquid layout made a comeback, using percentages, max-widths and min-widths. Then, along the lines of the fluid trend, came responsive web design, employing use of media queries and encouring thinking more about different devices. It is now an established way of working.

Karl Gernstner introduced the notion of ‘design programme‘, a set of rules for constructing a range of visual solutions. See also: Lupton, Thinking with type; Kerstner, Programme entwerfen.

Two technologies make RWD possible: media queries and the meta viewport tag. Media queries allow developers to apply CSS rules conditionally, the meta viewport tag allows setting the zoom level (most browsers ‘zoom out’ to display legacy, non-mobile-optimised ). With the meta viewport tag in a page, media queries work as intended.

The whole zooming out to the page width thing started in mobile Safari, and they added the meta viewport tag to allow developers to circumvent the zooming. Soon after, it got implemented in most other modern browsers.

Not a standard

A bad thing about the meta viewport tag: it was not a standard, so people started confusing syntax, e.g. adding semicolons instead of commas (eventually both ended up being supported). As there was no standard, edge cases are now handled different by each browser. Some features are not supported everywhere, e.g. user-scalable=no, so you’re never sure whether things will work or not. Android added target-densitydpi, which Opera also added. Internet Explorer implemented device-width as 320px as that was the original iPhone width. Safari zooms in 1.333% in landscape mode, which could be avoid by (their propriety) initial-scale:1 rule. Then Apple came up with minimal-ui properties. Anyway, end of rant, Opera decided to write a spec for viewport.

To standardise the things the viewport meta element did, Opera wrote @viewport as a CSS spec. Settings that you can set with the meta element can now be set in CSS. [Sidenote Yoav Weiss added to his talk: if you use @viewport in CSS, set it an inline <style> -element, as otherwise it will mess with things, including responsive images].

Example:

@viewport {
  width: auto;
}

In some senses @viewport is better than the original meta tag, and for sure it is better documented as it is a standard.

If you want to try it out now, you turn it on in Opera or Chrome flags and you can play with it. Currently, it would be advisable to use both as support for @viewport has hardly landed in browsers.

2. Resolution media queries

When devices with higher pixel densities came about, they started interpreting 1px in CSS as 2px on the device, for example iPhone 4 interpreted 1 CSS-pixel as 4 device-pixels. This makes fonts and vector graphics look very pretty, but can make bitmap graphics look blurry.

Resolution media queries can use ‘dots per px’ units (dppx).

Example:

@media (screen and min-resolution: 2dppx) {
  .thing {
    background-size: 50%; 
  }
}

@media (screen and min-resolution: 3dppx) {
  .thing {
    background-size: 33.33%; 
  }
}

<p>This technique is similar to <code>device-pixel-ratio</code> that works in some browsers, except this one is standardised. It is in some browsers, and not behind flags so can be used today (but it is not available everywhere yet). </p>

<h3>3. object-fit</h3>

<p>New <span class="caps">CSS</span> rules: </p>


```css
object-fit: fill;

object-fit: contain;

object-fit: cover; 
overflow: hidden;

These features are very useful to make small adjustments to images. They were already possible on background images, but not on inline images.

4. Viewport percentage widths/heights

Units: vw, vh, vmin, vmax

Think of your canvas as a 100 by 100 units, then vw and vh are those units, e.g. 50vw would be half of the width of your canvas.

Opera was heavily involved in all four, both at spec level and implementation level.

Ruth John – Browsers at play

Ruth builds interactive prototypes at 02. At State of the Browser, she showed some great things she built.

VJ’ing with CSS Animations and WebAudio API

When she was at uni, Ruth used to be a VJ. Recently, she thought, with all the cool things now possible in the web (CSS animations, WebAudio API), can I recreate the visuals of those days in the browser?

Ruth showed various demoes, including one that heavily used the Web Audio API (recommended reading: O’Reilly’s book on this subject). It allows you to control volume, create sound and analyse sound. The latter, Ruth used to create graphics that responded to changes in a music file.

With getUserMedia, microphone input can be analysed in JavaScript, using the Web Audio API. Ruth showed a cool demo in which graphics responded to her voice.

Demoes online: dancing.rumyra.com/shake-n-track dancing.rumyra.com/vibrate

Jake Archibald – Network connectivity: optional

The web is in a state where developers do dirty tricks to get you to go to download their native apps. “Why is that, why are mobile apps still preferred to the web versions?”, Jake asked.

Some reasons:

• availability offline
• server push
• background synchronisation
• geo fencing
• payments
• performance
• ‘app presence’

The web is really exciting, said Jake, as people are currently working on implementation of all of the above.

To improve performance, the 300ms double tap delay was removed from Chrome and Opera (soon to be removed in Firefox), for whenever a screen is small and the device-width meta tag is used.

To improve presence, so that the app can be in start menus, home screens, status bars, etc, the app manifest spec is being written at the moment, describing a way to have a json file with properties of apps, to make all the different <meta> elements that are currently used to do the same, obsolete.

Service workers

To improve offline availability, service workers are coming! There was, of course, AppCache. It tried to create shortcuts for a destination it didn’t know, it was hard to know what to expect from it and its API was too complicated.

We should treat online as a progressive enhancement to offline, and work ‘offline first’. That way, cached content is shown first, whilst making a request to the network for fresh content. When that network request fails, the cached content will still be there; if it succeeds, there will be fresh content.

Service Workers are reactive, not predictive, as AppCache was. It will try stuff and see what happens. The advantage of that is: if the thing it tried does not work, fallbacks can be added, making it very suitable for progressive enhancement.

What the web can do vs what apps can do

Native app developers can do everything, the web can sometimes feel like a massive can’t. Packaged apps are not the solution, they are interim, until the web has improved and become better. Native will always be better on their platform, the web will not win on that front. But it will win in being more accessible and much more widely available.

Martin Beeby – High-performance web platform

Martin Beeby, developer evangelist for Microsoft’s Internet Explorer, explained how to improve performance of websites, and what to keep in mind when building for Internet Explorer 11.

Things limiting speed on the web are bandwidth, latency and data plans.

Perceived performance is the most important to optimise. An important part of this is the use of memory. Inefficient use of memory can be a problem for performance, but also for the user’s hard drive life expectancy. Most of the memory websites take up is taken up by images.

Power consumption is something to think about as well, as it is about the user’s battery.

New website: status.modern.ie to give community more insight in what features the IE team considers supporting, as well as what’s already built in.

Microsoft built two tools to measure performance: the F12 dev tools, in IE10 and more even in IE11 this has improved a lot. There is also the Windows Performance Toolkit, which can be used to measure any app on Windows.

Performance improvements that can be made:

• One of the most important performance optimisations are in images: often images for mobile do not have the right size and this can take a long time (not only downloading the images, but also image decoding).
• Defer script execution: put scripts in the footer, or, if you put them in the top, add the async/defer attributes.
• Reduce number of frameworks: not only because they would have to be downloaded, but also because they have to be garbage collected
• To fix items don’t add timers or events, they fire at the wrong timing or too often (e.g. scroll), use requestAnimationFrame (fires whenever the browser is ready to paint the screen, and can therefore be a lot smoother than something that fires each time the user scrolls)
• use CSS animations, not JS animations where possible
• use JPG instead of PNG where possible, JPGs have a huge performance benefit
• keep in mind: download size vs memory size. Memory size needed to store an image is often bigger than the image download size: width * height * 4, roughly. Copying an image from memory to gpu can relatively take quite a lot of time. In IE11, JPGs are hardware accelerated.
• when you develop on mobile, use a ‘low end first’ approach.

Yoav Weiss – Brace yourselves – responsive images are coming

Responsive images is to ‘efficiently load propertly dimensionsed images that fit the pages design’. My main concern is with performance here, we cannot be developing websites for 550$ smartphones only.

vs srcset

<picture> was thought up by the responsive images working group, Hixie of WHATWG did not like it and added, without much public discussion, the srcset idea. Two years later, both will be implemented.

Tab Atkins came up with src-n, apparently over a bottle of wine. It was great for discussion, this time amongst browser vendors, which was good. Then, the original picture syntax was redefined, with a new proposal that can make everyone happy. Now the Responsive Images Community Group and WHATWG are working on it together.

Yoav is implementing it in Blink, Mozilla are also working on implementing it it. Should be there in a couple of months.

picture 2.0

Usecase 1: bigger images for high resolution devices / the ‘retina’ use case

<picture>
  <source media=”mq” srcset=”/path”>
  <img/>
</picture>

There can be multiple <source> elements, the srcset attribute can have more than one image.

In Chrome, the srcset attribute works on <img> elements today.

Use case 2: art direction, in case you need multiple images to be properly cropped for different layout)
Use case 3: mime type fallbacks (jpgr, webp, jpeg2000 are formats that only work in some browsers, they would need a fallback)

An image element is always required, otherwise the picture will not display.

The sizes attribute, variable widths

Use case 4: variable width images

‘Picture is a magical span, nothing more’ said Tab Atkins. You should not try to style it using CSS.

When looking up what ‘w’ means, look at the picture spec, as the ‘old’ syntax is quite different.

If you want to play with <picture> and srcset today, there is a polyfill available: Picturefill 2.0 was released by the Filament Group, it is officially spec compliant.

Dan Donald – What it means to be flexible

Dan Donald explored what it means to build websites in a flexible manner.

Responsive web design is a recipe for managing and constraining the fluidity of the web. It is a recipe in the sense that it leads to a lot of improvements to the web, like responsive images.

An example of flexibility: the nature of breakpoints. They are a tool to describe change. Are we designing for content or devices? One can use device-oriented breakpoints, but they make the assumption that we can rely on devices having the same widths. Another option is content oriented breakpoints.

When using device breakpoints, we get a conflict with the universality principle of the web. There’s little to no correlation between viewport width alone and devices.

We have a breakpoint purpose mash-up. We work in a world of assumption, but what do we really know? E.g., the user agent string we get on the service side, is full of lie.

An important concept within building flexible pages, is the ‘element media query’. It does not currently exist in a standardised form or in browser implementation, but that did not stop various developers from building their own JavaScript solutions. Dan showed us his.

Chris Heilmann – Open web apps

Chris talked about the open web, and about what Firefox OS can mean within the context of the open web.

Open Web Apps: manifest file that says what your app is/does. Apps are a better form factor for devices (then URLs).

What makes a good app? Why do people download a calculator app, rather than typing their calculation into an online tool like Google?

• focused (it is full screen)
• mobile (it works offline)
• contained (you can delete the icon to delete the app, you can send it as one thing)
• integrated (it works together with the OS and has hardware access)
• it is responsive and fast

Can all of the things that make apps great be done in HTML?

A great app does one thing and do that one thing well. Simplicity is what makes app so popular.

Service workers is the most important thing at the moment, offline viewing is a very important thing that needs to be solved.

Go low in your testing, do not test on too fast connections, as the web is universal and it would be bad preventing people with low bandwidth connections from accessing your website.

Everyone with an FTP connection and text editor can work on Open Web Apps, not just rich kids in Sillicon Valley that can pay 99 dollars and buy the newest devices to test on. That’s not the web!

Q&A

Throughout the day, attendees could ask questions via Twitter and to the organisers. After the last talk, Daniel Appelquist confronted the speakers with some of the questions that were asked.

(Answers are based on my notes, and should not be considered to be literally what the panelists said).

Q: How will HTTP2 change any of the thinking about responsive web design thinking?

With HTTP2, combining all your JS into one file will become an anti pattern […] the same goes for sprited images

Jake: HTTP2 will turn a lot of good practices into bad practices, for example, starting a new request would be less of a deal. Combining all your JS into one file will become an anti pattern, lots of small files will work much better. The same goes for sprited images.

Yoav: Today, the browser has to download everything to get started, which today is good because it saves HTTP requests, but if that is no longer needed, it will be better to have many small files.

Andreas: I agree, best practices like sprites will have to be rethought. This will mostly be an education problem, we will have to ‘unevangelise’.

Chris: Most people use build processes nowadays, and an advantage of that problems like this can be solved by adjusting those tools. These things are already abstractions, so we only need to adjust the abstractions.

Q: How can we be a web industry that women don’t feel alieniated in?

Martin: All I can do is not be a dick, that is the only thing I can have control over.

Ruth: It is an issue. I have been lucky, as in most places where I worked, people weren’t dicks. I think it is mostly a social problem. I’ve had sexism and it isn’t nice, but there are worse problems in this world.

Chris: Sites like Codebabes are blatant trolling, they’re not much more than a clickbait. We are not going to solve social problems on the internet by clickbaits. We should not give them a lot of attention in tweets.

Ruth: listen to ‘the science of the sexes’ podcast, it is a great resource.

Q: Everyone keeps talking about “the web platform“, what is a platform and should we want the web to be a “platform”?

Chris: The web is an opportunity for people to publish on, it is a way to spread information in a world wide manner. It is a set of technologies.

Andreas: It is just a matter of naming. We have called it ‘web standards’, and later internally at Opera we called it ‘the web stack’. Some use the word ‘HTML5’, maybe ‘platform’ is a better term for it all. Whether it means something deeper than that, I’m not sure.

Q: How can we make the web platform a better platform for games?

Ruth: That’s a really good question, but very difficult to answer. We already have things that are amazing at games, like Xbox and Playstation. I think we need to build a lot more to show what is possible. The Audio API and Vibration API i talked about seem great for games.

Martin: we [at Microsoft] go to lots of game developers, at big companies, but also indie game developers. I don’t know much about game development, it is a very different world. Interesting is what is happening with WebGL, not just for games but for parallel computing in general, it it has implications for lots of things outside gaming as well. It is very complicated though, hard to learn.

Chris: It is a different world, like native vs web. Gaming is a speed test, if we can get games running on web technology, we can learn from it for other applications of the web.

Q: How will Web Components change the way we work on the web?

Chris: Web Components are an amazing opportunity, they allow us to write proper widgets on the web. Whatever HTML you were missing, you can now actually write and publish yourself. It allows for widgets that are running with the browser and not against it. They becomes part of the browser. Jake had a talk about a tabs component some years ago, that is one to watch again. [I think Chris meant Jake’s talk ‘Reusable code: for good and for awesome’ at Fronteers 2010. Video / transcript and slides

Jake: Web Components are an important part of the extensible web. For someone new to HTML, it was weird that

and

looked different — CSS helped to explain why this is. Developer tools in modern browsers to this with things like performance waterfalls. Service Workers does a similar things to help understand the network. Web Components will help to show why things render the way they do. Libraries like jQuery UI that change a <div> into a widget will no longer be needed, you could just have a new element doing a widget.

Yoav: I’m slightly worried about performance of Web Components, for example in terms of blocking rendering. The browser has to download the import and files within that file and files within that file. We have to make sure it will not become the next @import of CSS.

Q: What is the future state of deep linking from web apps? And into web apps?

Barjo: Haida does that for Firefox OS, it will make the flow more natural for the user, linking will feel more natural like it is in the native OS already.

Jake: We can’t lose the URL.

Andreas: I agree. URLs are the power of the web and an advantage of the web over native apps. The web can link to apps, but URLs can also be used to link from an app to the web.

Conclusion

I’ve had a great day in London, and enjoyed this very affordable conference a lot. There was plenty to learn and it is exciting to know that a lot of the stuff presented today, will be in browsers in the not too distant future.

Thanks Krijn and Mathias for pointing me at spelling errors in previous drafts of this post.

---

Originally posted as State of the Browser 2014 on Hidde's blog.

Reply via email

Many videos on the web are hosted at third parties and included through an <iframe>. This can be a problem for flexible width sites, as an <iframe> with 100% width will not automatically have a height that respects the aspect ratio of the embedded content.

Forcing an aspect ratio-respecting height

The embedded content will, it its simplest form, be like:

<iframe/>

The width of the video can be adjusted to the width of its container or viewport by setting a width: 100% to the <iframe>, Because the width is not set on the video element itself, as it can be with inline <img> or <video> elements, the browser doesn’t know what the height should be, as there can be any number of elements in your <iframe>.

Let’s wrap the <iframe> in its own container.

<div class="embed-holder">
  <iframe/>
</div>

The embed-holder will be positioned relatively, so that it flows with the page. Its max-width will be 100% and its overflow will be set to hidden. We add a padding-top to the container to reserve some space for the YouTube player.

Now comes the trick¹: the embed-holder will get a padding-bottom of 56.25%. Using a percentage for the padding forces a height that is relative to the width of the element. If we want the embed to stick to the aspect ratio of 16:9, we need to express that ratio as 100:x. We can calculate that by dividing 100 by 16, then multiplying the answer with 9.

Let’s for now assume videos in the ratio of 16:9. Using the following CSS, .embed-holder will have the correct aspect ratio in any container or viewport.

.embed-holder {
  max-width: 100%;
  overflow: hidden;
  padding-top: 30px;
  padding-bottom: 56.25%; /* ensuring 16:9 aspect ratio; 
use 75% for a 4:3 ratio */
}

<p>The last step is to fit the video into the container.</p>

```css
.embed-holder iframe {
  position: absolute;
  left: 0;
  top: 0;
  width: 100%;
  height: 100%;
}

The .embed-holder acts as the positioning context for the <iframe>. The width and height will be that of .embed-holder, so it will have the correct ratio.

Extra step for WordPress users

If you want to do this in WordPress, one extra step is required.

By default, WordPress creates embeds from any URLs to video services like YouTube and Vimeo. Rightfully, it does not add an extra wrapping element to your code, which is what we need in this particular situation.

To do this, simply add a filter² to the embedding function in your functions.php :

add_filter('embed_oembed_html', 'wrap_embedded_els', 99, 4);
function wrap_embedded_els($html, $url, $attr, $post_id) {
  return '<div class="embed-holder">' . $html . '</div>';
}

This wraps the WordPress-generated embeds into a container, to which the above CSS can be applied.

Please note: this wraps all embeds, including some you may not want to apply a different aspect ratio to, such as SoundCloud.

Notes

¹ This is not my own idea, it has been explained by others. Original idea by Thierry Koblentz on A List Apart (May 2009)

² Function via cubecolour , who also made a WordPress plugin to add both the CSS and the filter)

---

Originally posted as Embedded video in responsive lay-outs on Hidde's blog.

Reply via email

When Bruce Lawson tweeted about an opportunity to meet the TAG, I managed, at the last minute, to get a ticket and joined a room full of very smart people discussing some technical aspects of the web medium.

Although Bruce and Jeremy have already written a much better summary of this fascinating evening, I will share my thoughts nonetheless.

The TAG?

‘TAG’ is an abbreviation of ‘Technical Architecture Group’. They are a special working group within the W3C, overseeing which web standards are developed and thinking about the general direction of the web.

The meeting

The meeting took place in the form of a Q&A session at the Google Campus in London, followed by beers. The atmophere was good, the TAG members interesting and the audience interested.

Archeology

When I entered the room, sorry I was late, there was a discussion about which design principles the TAG has. The web and its possibilities have extended tremendously over the past years, and the main concern of the TAG is making sure that the capabilities of the web ‘platform’ are well documented. Many things a web browser needs to do are not formally described by a spec, but nonetheless, they need doing. Those who put web standards together have to do some sort of ‘archeology’ into what browsers do to find consensus.

DRM

Then, someone asked a question about a drm. An extension of HTML, agreed upon by the W3C, provides APIs ‘to control playback of protected content’. It has been called unethical and bad for the web. In response to the question, the TAG pointed out that they are merely responsible for technical architecture, not for policy. However, individual TAG members did respond. Anne van Kesteren said he personally thinks DRM does not work and is bad for the web. Tim Berners-Lee, after explaining DRM is already in a lot of things that almost all of us use, pointed out the DRM issue is not simple and goes much beyond just technical problems. Many little procedures that make the web work and resulted in its popularity have a social aspect as well as a technical aspect. Someone in the audience noted that the technical DRM discussion ought to be preceded by another, about how, as a society, we want to value content creators. Because surely, we all want to read great books and watch interesting films, and no one would deny the makers of these things to do it for free. I agreed, this discussion has implications beyond tech.

Web Components

In the HTML5 spec, a number of new elements were introduced. Commonly used classnames, like header, footer and section had gotten there own element. When those new HTML5 elements were introduced, they appeared to have been carefully chosen, to make sure the standard remained simple yet effective. With Web Components, it will be possible for developers to use any element they like. Then, asked Jeremy Keith, with some irony, ‘what do we need standards bodies for?’ Now of course it is still good to standardise commonly used elements. Web Components are not meant to create your own <div>-like elements, although you can. They are meant to create the kind of elements that have extra features, like <input type="range">. For standard elements, the browser has APIs to ‘do’ those features. If you make them with a web component, you provide the API yourself, with JavaScript. Then, if some web components become very common, the W3C may decide standardise them, so that they can be used declaratively. In the future, commonly used Components and their JS APIs could be standardised and become part of browsers, just like commonly used classnames were standardised as elements. Now the web is being used more and more as a platform, some developers serve empty <body> elements with a lot of JS. With Web Components, they can serve <body> elements containing meaningful custom elements.

URLs

As the very last question, Andrew Betts brought up an issue that he had with the web product he works on. He felt it was not always possible to represent what was on the page with its URL. One concern he mentioned is that context is not always taken into account. In his organisation, some teams wanted to have different content in different contexts, and there is nothing in URLs that can help specify which context is currently used. The assumption of different web contexts have been argued to be wrong , but Andrew’s case was interesting and lead to the TAG’s final conclusion: ‘we all love URLs!’

---

Originally posted as Meeting the TAG on Hidde's blog.

Reply via email

In this article, I describe a way to add icons to descriptive links, and one that makes icons by themselves more accessible.

Icons are often employed to provide a visual description of an action. In some recent projects, I have treated such descriptive icons as merely enhancements of descriptive text. Because surely, text that describes some action is a basic yet functional substitute for an icon that describes that same action.

Icons preceding descriptive links

For example: an RSS link. In its most basic form, it would be:

<a href="http://site.com/feed" class="icon icon-rss">RSS</a>

The link with just the word ‘RSS’ is sufficient, it does the job of pointing the user to the RSS feed. Or the finely tuned searchbot, a browser plug-in that looks for RSS feeds or even a screenreader.

In its enhanced form, it would have a super sharp, retina proof vector icon in front of it.

Now, as we already made sure everyone is pointed to the RSS feed in a basic way, we have already included almost everyone, we can apply the enhancement to only the browsers that understand it.

The icon would be a character from an icon font. Let’s add the character with a pseudo element in CSS:

.icon-rss:before {
 content: 'foo'; /* character in your icon font, preferably 
one from Unicode's private use areas */
}

Icons with descriptive fallbacks

Sometimes, a web interface uses an icon by itself, without a label. In this case, it does not come with a useful descriptive text out-of-the-box. Adding it with generated content would exclude users whose browsers don’t understand :before or :after.

Support for generated content can be detected by Modernizr. Taking advantage of the class Modernizr adds, we could show or hide descriptive alternatives for generated content.

<span class="generatedcontent-alt">Enlarge text</span>

.generatedcontent .generatedcontent-alt {
  position: absolute; 
  overflow: hidden; 
  clip: rect(0 0 0 0); 
  height: 1px; 
  width: 1px; 
  margin: -1px; 
  padding: 0; 
  border: 0; 
}

This will “visually” hide the alternative in the case it is no longer needed, when generated content support has been detected by Modernizr.

Another example:

<a href="printversion.html" class="icon icon-print">
  <span class="generatedcontent-alt">Print</span>
</a>

The text ‘Print’ is no longer needed if the print icon is there. If generated content is not supported, the text provides an acceptable alternative.

Text as the most basic alternative

Icons have great advantages, and can help users finding their way around a website. But there will be cases in which the icons don’t work, for example if your web font fails, generated content is not supported or your user only processes text (e.g. Googlebot or a blind user).

With text, you can be sure you reach almost all web users. This makes it the ideal alternative, that is always good to have it in place, even if you (visually) hide it from most users.

---

Originally posted as Unobtrusive icons on Hidde's blog.

Reply via email

In this post I’m going to go through some highlights of Handheld 2013, which started of with the Welsh anthem being played on an electric guitar.

The conference

Generally, I much enjoyed Handheld. If I’m right, it was meant for people who make things for handheld devices. This year, it seemed, the speakers were mostly talking about the web. Which is good, and important. I can imagine some people missed talks about app development, but I didn’t.

A common theme of this year’s Handheld was communication with clients. These days, to make sure our sites work on a big range of devices, most web designers have started using responsive web design (RWD) in some way or another. With RWD, the uncertainty of what a web design is going to look like has become more apparent than ever. It was always the case that websites could not look the same in every browser, but now that we attempt to optimise for more than just a few desktop browsers, we have to come up with ways to explain this to our clients. This is a lot about building trust, confidence and that sort of thing, in addition to crafting great designs.

Having just recovered from co-organising my own conference , I may have had a biased view here, but there were some things I did not like about the practical side of things, including the waiting at registration and the somewhat too visible sponsor involvement.

Some talks I loved

The long web

Jeremy Keith talked about the web, a medium which he clearly loves (and who doesn’t?) He loves it for reasons such as its backwards compatible design, allowing for websites to be built in layers of structure, style and functionality. He also loves it for its URL system, providing a great and multi-purpose way for developers to make content available.

The biggest change in working on the web recently must have been the ‘mobile first’ paradigm, or ’content first’. According to Jeremy, you could work URL first, so that you start thinking about how to address the content before you even think about navigation. A clever way he mentioned to create a website from content is to break it into bits of content, components. Creating a library of components can help a lot. Jeremy created Pattern Primer as a handy way to show patterns and their HTML. And there is of course Anna Debenham’s book on style guides.

Content first also works through in code. You could put the content as (one of) the first thing(s) in your code, and the navigation at the very end.

Jeremy pleaded for progressive enhancement and rightly so. It almost ‘follows’ from working starting with (structured) content first. Progressive enhancement is often thought of being there for users that ‘have their JavaScript turned of‘. Although it does probably help those people, progressive enhancement has more to it. It helps anticipating those things that you did not expect, like a bug in one of your JavaScript files. It is about dealing with technology failing, rather than it not being supported.

Do not outsource your [website’s] performance to a third party.

A great example Jeremy mentioned is that of the social sharing button thingies that many sites use these days. The social media sites often offer those as a <script>-element that they ask you to drop in the middle of a page. Now if you imagine a Twitter widget in the middle of a page: if a user in China opens that page, it may stop loading when it gets to the Twitter widget, because Twitter is blocked in China so its script is never found. Your website’s speed is its most important UX feature, Jeremy warned, “do not outsource your performance to a third party.”

How to call your client an idiot without being fired

Andy Clarke’s talk was about how to communicate about design with clients.

We should avoid setting the wrong expectations

Old-fashioned ways of wireframing and design comps is that they might cause us to set the wrong expectations. When a client is shown a wireframe that already has some basic lay-out, as wireframes often do, they might expect the visual design to look like that lay-out. If the client is shown static design comps, they may assume that the final website will look exactly like them on any browser or device ever used.

What we design, Andy says, is not how we design, but how we communicate our designs. It does not matter which tool you like to create designs, as long as you make sure you set the right expectations.

According to Andy, the waterfall method is one of the main causes to problems related to expectations. To be able to set expectations right, we should start working in agile teams. That way, designers, developers and clients work together. In the process, everyone involved will know what is being worked on, and big surprises at the end are avoided. Working together, team members will feel more accountable.

To improve the way we design websites, we could improve the way we ask for our client’s feedback. If they work alongside designers and developers, we already avoided ‘the big reveal’. There are some other ways to improve the feedback process. At Andy’s company, they try to make it easier to control the feedback conversation, by insisting on face-to-face feedback, not allowing feedback by phone or email. They also try to control the environment in which the design is presented, by making sure everyone who can decide about it is in the meeting. They also find it important to leave their personality at the door: it is about the integrity of the design, not about that of the person who made it or gives feedback about it.

Data poetry

Brendan Dawes had a great talk about data. Now data can have two appearances, Brendan showed. There is the ‘raw’ format of just plain csv of JSON files in a text editor. They look boring and do not invite people to interact with them. They don’t look sexy. But when using data as an input for graphic design, it can come to life. Data represented in a graphical way can show give us new insights. It can help us see connections that we would not have noticed in the csv, although technically they were in there.

Data needs poetry

In his talk, Brendan showed heaps of examples of cool things he had done with data, including many new ways of representing data that was already there. These examples really nderlined his point that data ultimately comes to life when it is put in a graphical form. “Data needs poetry,” Brendan concluded.

And more…

And there were other talks I did not mention.

Syd Lawrence opened up with an entertaining live show, which involved people texting details to a phone number that were later used for playing ‘Guess who?’.

Ling Valentine argued that for information-rich web sites like her own it makes sense to stay away from responsive web design and use a simple, yet annoying mobile page to get people to your desktop site asap.

The prophet of web standards Jeffrey Zeldman gave his ‘ten commandments of web design’, often using his own A List Apart as an example. He loves the web as much as Jeremy does.

Mark Boulton explained how as a designer of RWD projects, you have to worry about content as it is such an integral part of what the design is made of. He illustrated this with stories about some projects he did, like Al Jazeera, CERN, UCL and World Skills London.

Jon Hicks talked about the pros and cons of icon fonts and showed how to make one. He also briefly discussed some alternatives to using icon fonts, like SVG sprites.

Eddie Machado made the Handheld site and explained how. I found he brought a lot of tools in that, imho, he could have done without (eg Sass for icon fonts), and ‘dirty’ tricks like </code>-elements inside a <div> instead of a <video> so that he could conditionally load them in a video.

There were not only talks at Handheld. There was also Bruce singing web standard classics such as ‘Like a rounded corner’ and a new (?) song callde ‘Living standard’, and Aral who announced the next phase of his Project Prometheus, now known as Indie.

Handheld conference was a great and varied day. There will be no Handheld next year, but the organisers have plans for another event. I’m going to keep an eye on this.

---

Originally posted as Handheld 2013: the web's structure, expectations and data poetry on Hidde's blog.

Reply via email