On 27 Nov 2013, at 12:36, Sarah McHugh <[log in to unmask]> wrote:
>
> In the past we have always made sure our images are small size 300 pixels at longest edge and 72 dpi.
It got a whole lot more complicated than that recently.
See:
http://alistapart.com/article/responsive-images-how-they-almost-worked-and-what-we-need/
and:
http://usecases.responsiveimages.org
Summary:
In HTML, a user agent's environmental conditions are primarily expressed as CSS media features (e.g., pixel-density, orientation, max-width, etc.) and CSS media types (e.g., print, screen, etc.). A responsive image is an image that adapts in response to different environmental conditions: adaptations can include, but are not limited to, changing the dimensions, crop, or even the source of an image.
Many media features are dynamic in nature (e.g., a browser window is re-sized, a device is rotated from portrait to landscape, and so on), thus a user agent constantly responds to events that change the properties of media features. As a document's layout adapts to changes in media features and media type, an image's ability to communicate effectively can be significantly reduced (e.g., images start to show compression artifacts as they are scaled to match the quality of media or some media feature). When this happens, developers rely on variousclient/server-side solutions to present images at different resolutions, or even in different formats. Swapping images provides a means to continue communicating effectively as the features of media change dynamically.
Furthermore, as the number and varieties of high-density screens has increased (both on mobile and desktop devices), web developers have had to create custom techniques for serving images that best match a browser's environmental conditions. For a list of examples of the range of techniques in use in 2012, see Chris Coyier's article "Which responsive images solution should you use?". These techniques have a number of limitations, discussed below, which serve as the motivation to standardize a solution through the W3C and WHATWG).
In formulating the requirements, this document tries to be neutral - it is not predicated on any solution. The document only tries to describe the use cases and what the RICG understands, from practice, would be needed to address the use cases in the form of requirements. The RICG expects that a technical specification can be created to formally address each of therequirements (i.e., the solution).
It’s still a can of worms, so it might be worth waiting a while before rehashing your policies.
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
|