Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

Subgroup: Text and Media

Jump to bottom
Eric Bollens edited this page Oct 9, 2013 · 7 revisions

The Text and Media Subgroup focuses on issues around responsive text and media. Some of the topics this group will look at include responsive tables, images and video, as well as font assets and print stylesheets.

Participants

Please add your name and email to the list if you are interested in engaging with this subgroup

Topics

Responsive Tables

For current research on responsive tables, see:

To add to this discussion, please edit the wiki page. Currently, the two proposed approaches in the issue tracker include #164 Linearized Table and #165 Scrollable Table.

Responsive Images

For current research on responsive images, see:

To add to this research, please fork and edit the document and issue a pull request for @loganfranken.

Current Plans

img[srcset]

The img[srcset] element is current draft status in the W3C:

A polyfill with conformance tests is available:

See "picture" for more details about the differences from the other element in question.

Support has been added for this with picturefill Package master branch tracking WebBlocks 1.1

picture

The picture element is currently draft status in the W3C:

This article provides good guidance regarding the difference between picture and img[srcset]:

The srcset attribute allows authors to define various image resources and “hints” that assist a user agent in determining the most appropriate image source to display. Given a set of image resources, the user agent has the option of either following or overriding the author’s declarations to optimize the user experience based on criteria such as display density, connection type, user preferences, and so on.

The picture element defines conditions under which the UA should follow the author's explicit instructions when selecting which resource to display. This includes image sources with inherent sizes designed to align with layout variations specified in CSS media queries ( see: design breakpoints, media features and types and relative units ) or content variations for increased clarity and focus based on the client’s display size.

Further research on this element and available polyfills:

Support has been added for this with srcset Package master branch tracking WebBlocks 1.1

Adaptive Images Integration

Adaptive Images provides a server-side mechanism for producing images suited to the device in question:

The JS integration code is trivial and could be added to a package assembler for Adaptive Images:

<script>document.cookie='resolution='+Math.max(screen.width,screen.height)+'; path=/';</script>

Research is still needed to determine if there're any additional client-side steps required, but belief to this point is that the rest is probably left to just providing information about how to get it working via the docs.

Alternative server-side approaches are covered here:

Support has been added for this with adaptiveimages Package master branch tracking WebBlocks 1.1

Client-Hints

A new set of client hints regarding browser capabilities has been proposed:

A Javascript implementation (limited to second request - same as the problem MWF got around with the redirect logic) exists:

Support has been added for this with httpclienthints Package master branch tracking WebBlocks 1.1

Flexible Video

The max-width technique works well for images, but not always for video players. The FitVids.js library, developed by Chris Coyier and the Paravel team, allows video players to resize on the fly, scaling while preserving proportions. This library is based on the Intrinsic Ratios for Video method by Thierry Koblentz.

Support has been added for this with fitvids Package master branch tracking WebBlocks 1.1

Text Issues

The following issues are known to exist around text:

Font Assets

The following deficits are currently recognized:

  1. The compiler does not currently provide a way to package font assets
  2. WebBlocks does not provide assistance regarding @font-face definitions
  3. Fonts packaged should be split into all needed formats for various browsers/OSes
Print Stylesheet

Currently, printing pages that use the WebBlocks grid result in a non-opitimal display. Further research is needed to determine the root cause of this issue and suggest an approach that allows for WebBlocks pages to print with reasonable formatting.

In preparation for actual development work, Eric presented two approaches for this at Meeting 2013-09-16:

  • A -print suffixed file compiled into a separate print sheet
  • The use of a @media print query within the primary sheet

Group consensus was to use the media query. Logan viewed this as simpler; Brian stated that it is the approach Stanford already uses; and Eric liked it because it avoids adding additional conventions and constituents to the file structure.

rem Unit Type

The CSS Values and Units Module Level 3 (Candidate Recommendation as of July 2013) defines the rem unit type as:

Equal to the computed value of ‘font-size’ on the root element. When specified on the ‘font-size’ property of the root element, the ‘rem’ units refer to the property's initial value.

Snook does a good job of summarizing the issue with the em unit type:

The technique modifies the base font-size on the body using a percentage...The problem with em-based font sizing is that the font size compounds. A list within a list isn't 14px, it's 20px. Go another level deeper and it's 27px! These issues can be worked around by declaring any child elements to use 1em, avoiding the compounding effect http://snook.ca/archives/html_and_css/font-size-with-rem

At least one polyfill exists to accomplish this:

However, the performance and viability of this polyfill needs to be studied, and alternatives should be looked at as well.

Code Syntax Highlighting

This is a nicety that many presentational frameworks provide. A number of libraries exist that could be leveraged directly as packages and integrated into a semantic within WebBlocks. Further research is needed to decide on which package we should be looking at to start. Ideally, it should be one that is simple, lightweight, responsive-aware and language extensible with good support out of the gate for common languages.

Drawing

At this point, the goal of this segment hasn't been defined firmly and is in early discovery, but a few things that might be of interest here:

  • SVG polyfill
  • Canvas polyfill
  • Canvas abstraction like Paper.js
  • WebGL polyfill
  • WebGL abstraction like PhiloGL
Clone this wiki locally