Archives: Notes

• started looking at how SVG and CSS complete each other
• SVG can be use to extend the capabilities of CSS
• there are seven ways to include SVG on a web page
• there are tools for using SVG
• there is no reason not to use SVG on websites today
• Sara is interested in how people are using SVG, which of the seven ways
• SVG background sprites are inflexible, each new colour must be created in the sprite sheet
• the use, defs ,g and symbol elements allows you to change the colour and make other variations with CSS
• the viewBox attribute is required for making SVG’s responsive, so make sure it’s there
• the use element cloned into the shadow dom, it can’t be accessed via CSS selectors
• to style the element on a cloned SVG you need to set the style using CSS variables and define the variable on the use element.

use {
  --primary-color: blue;
  --secondary-color: red;
}

// variables are used to style the SVG

• undefined variables will use the default fallback colour, see Sara’s article on Styling SVG using use.
• don’t use icon fonts!
• while icons can be styled in CSS, you can only style them using the font styles. It’s limited.
• SVG allows multiple colours, it’s sharper
• Web fonts can be blocked by ad-blockers, this can affect icon font and the user may end up getting unrelated emoji
• Icon fonts are not accessible
• SVG icons have accessibility backed in
• Use Grumpicon! Support will be extended back to IE6.
• There are plenty of tools around to help you use SVG, the time to switch away from icon fonts has passed
• There are a number of filters available in CSS to alter images
• Use trial and error when trying blend modes, it’s more reliable than knowing what will happen
• CSS filters can be extended to apply SVG filters
• CSS clip paths accept either basic CSS shapes or can take an SVG clipPath element.
• clipPath’s can be animated
• Clipping videos (and other HTML elements) can be done via foreign objects in SVG, but it’s buggy in webkit/blink
• using SVG filters we can create text effects that can’t be created by CSS alone. text-shadow is limited
• As long as the text is not converted to an outline, text within an SVG will be searchable
• SVG will allow you to create advanced poster like layouts without worrying about the flow
• You will need to convert SVG text to outline if you’re using specific, non-websafe fonts. Eg branding types
• You can make an image responsive with a single SVG
• SVG is a replaced element, you are going to need to set a width/height img,object {width:100%} will make it responsive
• The SVG viewport size can be used in media queries, the MQ applies to the SVG’s size only and is essentially an element query

Rocking #respond16 for the home town over the next couple of days. Spoiler: an excellent show to come!

RT @Independent: ‘What I discovered about homophobia by holding hands with another man in public’ http://www.clickhole.com/video/eye-opening-these-guys-lived-15-minutes-homeless-s-2415

I can’t say this better, come along if you’re in Melbourne

Had a rad time at #respond16. Huge ups to the @webdirections crew. Psyched to do it all over again at home!

— Michael Mifsud (@xzyfer) April 9, 2016

My plans tonight are to watch the latest Survivor & fall asleep on the couch reading Dalton Ross. Good to be home.

• The web is its own medium; a medium defined by its fluidity.
• It’s available on any device, one web. As long as we don’t break it.
• One web is:
  • One content
  • One url
  • One team
  • One release schedule
  • One codebase
• One web sounds a lot like responsive.
• The phrase adaptive is magic.
• No one seems know what adaptive means.
• An m-dot site is dedicated site served to mobile users, but it’s easy to server the wrong content.
• Adaptive is often used to means: serves something different to different devices. It may mean
  • A limited of media queries where the width jumps rather than fluidly grows
  • Serving something different, the url remains the same but the content is served differently
• Karen McGrane prefers the latter definition.
• Adaptive content is server side, the server detects the device and serves something different.
• Google is the one company most invested in your site serving the same content at the same url all the time.
• If the home page is political, serve a different home page and keep the rest of the site responsive. Do it, go adaptive on the home page.
• Adaptive doesn’t need to be per page, it can be per component. Fidelity used two versions of markup for adaptive tables based on the screen site.
• Don’t get the server involved with content when it’s a client side problem.
• Karen McGrane has spoken about adaptive for five years, since discussing COPE.
• There is a great value in storing chunks of granular content rather than massive blobs.
• It makes it easy for people to conclude they should be targeting different users with different content.
• One way of targeting is based on the users device.
• There are other ways. Context: information that can be gleaned from the devices sensors, the time, location, velocity, barometer, temperature.
• Think about this, when does it make sense to serve different content based on the device vs different content based on the users context?
• Device: support pages based on the users operating system.
• Even based on device selection, prioritise the content rather than exclude the content. An iOS user may be helping their Android using friend.
• Often people make assumption to adapt on device that are stretching it’s suitability, to assume the input mechanism, for example.
• Microsoft think there is no difference between what mobile & desktop users desires.
• Karen’s definition of context (device sensors) are the closest we can get to guess the users context.
• Modern hearing aids can switch to car mode when travelling over 10mph. This is a good but imperfect solution (could be a human canon ball).
• Restaurants can be displayed according to the user’s location, this is a good contextual cue.
• Language may not be a good contextual cue for language, this can be flawed – visitors arriving in a foreign country.
• Device detection is flawed, there is no correlation between being away from home and using a mobile device.
• Device type will always be the least reliable form of estimating context.
• Expedia found that responsive was better than context targeting. A travel company.
• Adaptive and responsive are not in competition, they work together. RWD will solve 95% of your problems, adaptive may cover the remaining 5%.

• How do we adapt the things we make to different spaces?
• We used to think about the web in pages, back when RWD became first defined.
• We now think about components.
• On average a large site may have 200+ media queries.
• We are trapped, media queries are defined by pages.
• We think about components, and less frequently about pages.
• The element query would allow us to adapt content to the size of the content.
• The element query is great for how we think now.
• The element query is great for circular dependancies.
• It’s the circular dependency that killed the element query.
• The element query became the container query, it’s a problem that needs to be solved.
• It’s possible to use “element flow” to hack container queries.
• Flex-grow can change how content displays as element grows and shrinks, regardless of the page.
• display: container can be used to allow use to use flex-box order to content based on the containers size.
• Nesting the picture element as foreign object in an SVG give the picture element a container query.
• The best thing to do to get a container query is to get involved in the RICG.

<picture> perfect: designing with responsive images

• about half the room is using responsive images
• smashing magazine twitter survey found 58% of people didn’t use them
• responsive images allow us to support a range of devices, the best image for a device is delivered
• img[srcset] takes a definition of image sources, the browser selects the best image to use
• img[sizes] allows us to define when sizes at which the image is displayed, provide hints to the browser
• srcset is pretty well supported in browsers
• the picture element is designed for art directions
• picture element is used as a wrapper around existing image fallback
• picture element gives the author a lot more control over the image displayed
• the author can modify the crop to be appropriate for the users’s device
• picture element can be used to select image types based on images format: eg webp, jp2
• image type selection allows the browser to use less bandwidth in possible
• picturefill provides a great polyfill
• Coding the picture element can get complicated:

I never want to make anything that even remotely resembles this. pic.twitter.com/QsfusOtxkI

— Brad Frost (@brad_frost) May 16, 2015

Building accessible web components without tears

• Four painful questions
  • have you tried to navigate your site with only keyboard?
  • could you perform every action on that site? (everyone put there hand down)
  • did the tab order make sense?
  • did you always see the element in focus?
• “full stack” devs seems to have forgotten some of the fundamentals of the web
• paragraphs, headings are terminal block elements: they can’t contain other block elements
• accessibility: enables hearing impaired, vision impaired, motor impaired users and more to access the web.
• accessibility: allows your users to use their input device of choice. More than keyboards, mouses and screen-readers
• WAI ARIA: Web accessibility initiative, accessible rich internet applications
• We can use roles and states to describe the elements to assistive technologies
• Screen readers require notification when content changes within the document using aria-live
• aria-live can be used for anything is intended to be used for important information: error alerts, resorting tables
• aria-live has three values: off, polite and assertive
  • off: will wait until the screen reader loops over the content
  • polite: will notify the user after the current action finishes
  • assertive: is poorly supported but in theory will interupt the current action
• role=alert is used to tell a user of really important
• Two main modes screen readers use:
  • read mode, standard mode can navigate the page
  • forms mode, can interact with form elements… but there is a catch… content that is not directly related to the form (eg p tags with alert messages) will not be read-aloud.
• Form control error messages can be inaccessible, if it is not programatically related to the field (again, in a p-tag)
  • we can not use colour alone to define a form field is invalid
  • the error message needs to be programatically linked to the form
  • including the error message inside the label is a simple method of associating
• when submitting forms, if an error occurs the user should be focused to the top of the form where there will be a description of the form
• A good wrapper for errors prepares the page for the error while keeping them invisible to users
• models have problems
  • keyboard users can tab outside the model, the model is active and it can be confusing
  • screen readers may not be notified of the model
  • screen readers may not be made aware of the purpose of the model
  • closing the model may move the user away from the locations in which they navigated to the model
• fixing models
  • hide the model from assistive technologies, once they open hide the pages remaining content
  • set focus to the model itself, not content within the model
  • limit the tab key to the model for keyboard navigation
  • explain to the user what each element will do when they close a model, submit a form in the model, etc.
  • make a smart decision about where to position the user once the model closees

Models are shit but we can make them less shit

• in page tabs
  • relationship between tabs and each panels content may not be clear
  • keyboard only navigation may not work on tabs
  • tab and arrow navigation (arrow to choose tab to display) is preferred
  • define the tabs as role=tabpanel, links as role=tab
  • define tab as aria-selelected=true/false, panel as aria-hidden
• there is a lot to do around accessibility, but there are quick wins available to make the application accessible.
• don’t be overwhelmed
• this to do
  • test with keyboard only
  • test with one or more screen-readers
  • test screen-readers in different browsers, different bugs appear in diff browsers
  • get specialists in to help you
• the ideal time to focus on accessibility is when you’re building the individual components, when you’re building pattern libraries.

My @webdirections #respond16 slides are available at http://pwcc.cc/respond/slides