Skip to content

Instantly share code, notes, and snippets.

@lilith

lilith/alternate.md

Last active December 12, 2015 03:19
Download ZIP

Revisions

  1. lilith revised this gist Feb 6, 2013. 1 changed file with 9 additions and 5 deletions.
    14 changes: 9 additions & 5 deletions alternate.md
    View file
    Original file line number Diff line number Diff line change
    @@ -23,11 +23,15 @@ This means more work for RICG, as we need to specify a reccomended selection alg

    ## New syntax (css)

    @media (min-width: 18em) picture{
    max-width:320px;
    @media (min-width: 18em){
    picture{
    max-width:320px;
    }
    }
    @media (min-width: 45em) picture{
    max-width:800px;
    @media (min-width: 45em){
    picture{
    max-width:800px;
    }
    }

    ## New syntax (html)
    @@ -57,7 +61,7 @@ This means more work for RICG, as we need to specify a reccomended selection alg

    These preconditions seem easily achieved, and in an optimal scenario would only delay prefetching by ~15ms. Since absolute dimensions are provided, layout (and even render, for some UAs) can occur earlier than would be possible with the original design. The time till fully loaded could still be affected, but seems unlikely, considering the average responsive site (in my experience) uses over 35 assets and the pipeline would be full anyway.

    In a worst-case scenario, image prefetching would be delayed until CSS was downloaded, but it would *not* be delayed until after layout, *unless percentage units were used*.
    In a worst-case scenario, image prefetching would be delayed until CSS was downloaded, but it would *not* be delayed until after layout, *unless percentage units were used*. Performance in an average scenario should be identical to CSS background images.

    I think the original proposal is guilty of premature optimization. Reaching a wider user base with a simpler solution (which can be optimized) seems more in-line with the goals of HTML.

  2. lilith revised this gist Feb 5, 2013. 1 changed file with 9 additions and 3 deletions.
    12 changes: 9 additions & 3 deletions alternate.md
    View file
    Original file line number Diff line number Diff line change
    @@ -49,10 +49,17 @@ This means more work for RICG, as we need to specify a reccomended selection alg

    ## Prefetch considerations

    We know browser vendors would prefer to prefetch images before CSS downloading completes, but I propose that goal be suspended for a moment. Delaying the prefetching of multi-source images until *after* css (or a portion thereof \*) has been parsed would offer many advantages; I also don't see how the UA would be able to make an intelligent choice concerning resolution until layout has been somewhat established.
    (Nearly) as efficient image prefetching should still be possible under the following conditions:

    \* An otherwise null-op CSS property (like "allow-picture-select: now;" could signal to the browser when image source selection can safely be made. I don't like the idea of such a property, but it could resolve the prefetching issue if it's sufficiently important, and we could suggest that picture rules be placed at the beginning of CSS, like we do with fonts.
    1. The CSS breakpoint rules do not use percentages values for `min-width`, `min-height`, `max-width`, or `max-height`.
    2. Those CSS rules are placed at the beginning of the CSS file, with the fonts.
    3. (optional, for small gain) The last breakpoint rule includes a CSS flag precluding additional rules, such as `picture-select:now;`.

    These preconditions seem easily achieved, and in an optimal scenario would only delay prefetching by ~15ms. Since absolute dimensions are provided, layout (and even render, for some UAs) can occur earlier than would be possible with the original design. The time till fully loaded could still be affected, but seems unlikely, considering the average responsive site (in my experience) uses over 35 assets and the pipeline would be full anyway.

    In a worst-case scenario, image prefetching would be delayed until CSS was downloaded, but it would *not* be delayed until after layout, *unless percentage units were used*.

    I think the original proposal is guilty of premature optimization. Reaching a wider user base with a simpler solution (which can be optimized) seems more in-line with the goals of HTML.

    ### Addressed use-cases

    @@ -130,4 +137,3 @@ From the use cases I have seen, this solution solves 95% of use cases with much
    It also does not preclude the remaining 5% of use cases, as shown by Solution A & B.



  3. lilith revised this gist Feb 5, 2013. 1 changed file with 6 additions and 4 deletions.
    10 changes: 6 additions & 4 deletions alternate.md
    View file
    Original file line number Diff line number Diff line change
    @@ -45,7 +45,7 @@ This means more work for RICG, as we need to specify a reccomended selection alg
    * DRY and separation of concern - breakpoints do not have to be specified in-markup
    * Fewer image variations have to be described - pixel density is handled intrinsically (large is typically a hi-res version of medium, etc)
    * No complicated parsing. One value per attribute - simple!
    * Highly forward-flexible - We can invent CSS properties such as 'picture-select: favor-large` to provide browsers with suggestions or overrides (logos, for example, we might prefer to always be highres, while content pictures can degrade on slow connections, etc). Browser vendors have shown CSS is much easier to innovate with than markup.
    * Highly forward-flexible - CSS properties such as 'picture-select: favor-large` can be added to provide browsers with suggestions or overrides (logos, for example, we might prefer to always be highres, while content pictures can degrade on slow connections, etc). Browser vendors have shown CSS is much easier to innovate with than markup.

    ## Prefetch considerations

    @@ -78,8 +78,6 @@ Look at the [media query spec](http://www.w3.org/TR/css3-mediaqueries/).

    All the media features are essentially resolution indicators. Combining them into sane rules is not simple, and duplicating those rules for every element (versus in a CSS file) does not make sense.

    Markup authors will be more successful when CSS developers can provide them with a handful of classes, than when they attempt to structure media queries themselves. The new solution is something a WYSIWYG editor could support, while the old solution would be excessively difficult to implement without a CMS module of some kind.

    The only media features that don't end up as resolution indicators are:

    * 4.8. color
    @@ -123,9 +121,13 @@ I wonder if this single use-case deserves such an inflated and over-generic `<pi

    #### Solution B

    We restore the `media` attribute to the the `source` element, but suggest that it only be used non-resolution related queries.
    We restore the `media` attribute to the the `source` element, but suggest that it only be used for non-resolution related queries. We will still have to define the interaction of rules in this case - so this could delay the spec.

    ### Summary

    From the use cases I have seen, this solution solves 95% of use cases with much simpler markup and better presentation/markup separation. It is also much more accessible to markup authors and content editing tools, as it is just a "list of images and description". The CSS class of the picture element permits pre-designed layout rules to be used, so that content authors can provide responsive images without a full understanding of media queries and layout rules.

    It also does not preclude the remaining 5% of use cases, as shown by Solution A & B.



  4. lilith revised this gist Feb 5, 2013. 1 changed file with 28 additions and 1 deletion.
    29 changes: 28 additions & 1 deletion alternate.md
    View file
    Original file line number Diff line number Diff line change
    @@ -94,10 +94,37 @@ If, in the future, 48-bit color becomes the norm, then I could see a use case fo

    **`monochrome` is the only non-resolution media query with a current, valid, use-case, AFAIK.**

    As mentioned in the use-case specification, many images require completely alernate imaging (and as such, will likely require alternate alternate text and perhaps alternate associated captions).
    As mentioned in the use-case specification, many monochrome images require completely alernate imaging (and as such, will likely require alternate alternate text and perhaps alternate associated captions). I don't anticipate monochrome versions being provided frequently for other scenarios, as current UAs (Kindle, Nook, even 1996 eBookwise) are quite capable of converting color to grayscale.

    I wonder if this single use-case deserves such an inflated and over-generic `<picture>` element?

    #### Solution A (css)

    @media all and (monochrome) picture.monochrome{
    display:inline;
    }
    @media all and (monochrome) picture.non-monochrome{
    display:none;
    }


    #### Solution A (html)

    <picture class="monochrome" alt="Description of monochrome alternative .">
    <source src="monochrome-list.jpg" width="300" height="200" />
    <img src="small.jpg" alt="Description of image subject.">
    </picture>
    <picture class="non-monochrome" alt="Description of image subject.">
    <source src="color-pie-chart.jpg" width="300" height="200" />
    <img src="small.jpg" alt="Description of image subject.">
    </picture>


    #### Solution B

    We restore the `media` attribute to the the `source` element, but suggest that it only be used non-resolution related queries.




  5. lilith revised this gist Feb 5, 2013. 1 changed file with 55 additions and 11 deletions.
    66 changes: 55 additions & 11 deletions alternate.md
    View file
    Original file line number Diff line number Diff line change
    @@ -2,16 +2,15 @@

    **What if media queries and breakpoints could stay in the .css file?**

    **What if the image source was chosen based on the dimensions of the `<picture>` element instead?**
    **What if the image source was chosen based on the `min-width, max-width, min-height, and max-height` of the `<picture>` element instead?**

    Media queries would apply size restrictions to images based on css classes.

    The element itself would only be responsible for providing a collection of URLs, described by their size, in pixels, and their mime-type.

    The UA would be able to choose the best match based on the pixel density muliplier and available bandwidth.

    This means more work for RICG, as we need to specify a reccomended selection algorithm, but I believe that's something we need to do anyway.

    This means more work for RICG, as we need to specify a reccomended selection algorithm, but I believe that's something we need to do anyway.

    ## Old syntax

    @@ -28,25 +27,25 @@ This means more work for RICG, as we need to specify a reccomended selection alg
    max-width:320px;
    }
    @media (min-width: 45em) picture{
    max-width:800px
    max-width:800px;
    }

    ## New syntax (html)

    <picture alt="Description of image subject.">
    <source src="small.jpg" width="300" height="200" type="image/jpeg" />
    <source src="med.jpg" width="600" height="400" type="image/jpeg" />
    <source src="large.jpg" width="1200" height="800" type="image/jpeg" />
    <source src="small.jpg" width="300" height="200" />
    <source src="med.jpg" width="600" height="400" />
    <source src="large.webp" width="1200" height="800" type="image/webp" />
    <source src="large.jpg" width="1200" height="800" />
    <img src="small.jpg" alt="Description of image subject.">
    </picture>

    # Benefits

    * DRY and separation of concern - breakpoints do not have to be specified in-markup
    * Fewer image variations have to be described - pixel density is handled intrinsically (large is hi-res version of medium, etc)
    * Fewer image variations have to be described - pixel density is handled intrinsically (large is typically a hi-res version of medium, etc)
    * No complicated parsing. One value per attribute - simple!
    * Highly forward-flexible - We can invent CSS properties such as 'picture-select: highres` to provide browsers with suggestions or overrides (logos, for example, we might prefer to always be highres, while content pictures can degrade on slow connections, etc)
    * Highly forward-flexible - We can invent CSS properties such as 'picture-select: favor-large` to provide browsers with suggestions or overrides (logos, for example, we might prefer to always be highres, while content pictures can degrade on slow connections, etc). Browser vendors have shown CSS is much easier to innovate with than markup.

    ## Prefetch considerations

    @@ -55,6 +54,51 @@ We know browser vendors would prefer to prefetch images before CSS downloading c
    \* An otherwise null-op CSS property (like "allow-picture-select: now;" could signal to the browser when image source selection can safely be made. I don't like the idea of such a property, but it could resolve the prefetching issue if it's sufficiently important, and we could suggest that picture rules be placed at the beginning of CSS, like we do with fonts.


    ### Disclaimer
    ### Addressed use-cases

    See [the Use Cases document](http://usecases.responsiveimages.org/)

    * 3.1 Resolution-switching - UA knows the multiplier, and can evaluate whether to apply it or not
    * 3.2 Art-direction based - Full control based on element max-width and max-height from CSS media queries
    * 3.3 Design breakpoints - Much better support than existing proposal, as they go where they belong - in CSS
    * 3.5 Relative units - inherently addressed
    * 3.6 API to manipulate sources - Vastly simplified vs. original proposal.
    * 3.8 User control over sources - not affected

    ### Nearly addressed use-cases

    * 3.4 Matching Media Features and Media Types
    * 4.1 The solution MUST afford developers the ability to match image sources with particular media features and/or media types - and have the user agent update the source of an image as the media features and media types of the browser environment change dynamically.

    ### Solutions to 3.4 and related 4.1

    This solution proposes resolution-based selection as the primary mechanism instead (or in combination with - see below) of a more generic 'media feature' query.

    Look at the [media query spec](http://www.w3.org/TR/css3-mediaqueries/).

    All the media features are essentially resolution indicators. Combining them into sane rules is not simple, and duplicating those rules for every element (versus in a CSS file) does not make sense.

    Markup authors will be more successful when CSS developers can provide them with a handful of classes, than when they attempt to structure media queries themselves. The new solution is something a WYSIWYG editor could support, while the old solution would be excessively difficult to implement without a CMS module of some kind.

    The only media features that don't end up as resolution indicators are:

    * 4.8. color
    * 4.9. color-index
    * 4.10. monochrome
    * 4.12. scan
    * 4.13. grid

    I cannot invent any use-cases for `scan`, `grid`, or `color-index`.

    If, in the future, 48-bit color becomes the norm, then I could see a use case for `color`

    **`monochrome` is the only non-resolution media query with a current, valid, use-case, AFAIK.**

    As mentioned in the use-case specification, many images require completely alernate imaging (and as such, will likely require alternate alternate text and perhaps alternate associated captions).

    I wonder if this single use-case deserves such an inflated and over-generic `<picture>` element?





    This idea popped into my head around 3am, as I was reading the mailing list feed. Since I wrote it before becoming fully awake, there's a strong possibility I overlooked something important. Please comment!
  6. lilith revised this gist Feb 4, 2013. 1 changed file with 4 additions and 4 deletions.
    8 changes: 4 additions & 4 deletions alternate.md
    View file
    Original file line number Diff line number Diff line change
    @@ -34,10 +34,10 @@ This means more work for RICG, as we need to specify a reccomended selection alg
    ## New syntax (html)

    <picture alt="Description of image subject.">
    <source src="small.jpg" width=300 height=200 type="image/jpeg" />
    <source src="med.jpg" width=600 height=400 type="image/jpeg" />
    <source src="large.jpg" width=1200 height=800 type="image/jpeg" />
    <source src="large.webp" width=1200 height=800 type="image/webp" />
    <source src="small.jpg" width="300" height="200" type="image/jpeg" />
    <source src="med.jpg" width="600" height="400" type="image/jpeg" />
    <source src="large.jpg" width="1200" height="800" type="image/jpeg" />
    <source src="large.webp" width="1200" height="800" type="image/webp" />
    <img src="small.jpg" alt="Description of image subject.">
    </picture>

  7. lilith revised this gist Feb 4, 2013. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion alternate.md
    View file
    Original file line number Diff line number Diff line change
    @@ -2,7 +2,7 @@

    **What if media queries and breakpoints could stay in the .css file?**

    **What if the image source was chosen based on the dimensions of the '<picture>` element instead?**
    **What if the image source was chosen based on the dimensions of the `<picture>` element instead?**

    Media queries would apply size restrictions to images based on css classes.

    @@ -55,4 +55,6 @@ We know browser vendors would prefer to prefetch images before CSS downloading c
    \* An otherwise null-op CSS property (like "allow-picture-select: now;" could signal to the browser when image source selection can safely be made. I don't like the idea of such a property, but it could resolve the prefetching issue if it's sufficiently important, and we could suggest that picture rules be placed at the beginning of CSS, like we do with fonts.


    ### Disclaimer

    This idea popped into my head around 3am, as I was reading the mailing list feed. Since I wrote it before becoming fully awake, there's a strong possibility I overlooked something important. Please comment!
  8. lilith created this gist Feb 4, 2013.
    58 changes: 58 additions & 0 deletions alternate.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,58 @@
    # Proposal

    **What if media queries and breakpoints could stay in the .css file?**

    **What if the image source was chosen based on the dimensions of the '<picture>` element instead?**

    Media queries would apply size restrictions to images based on css classes.

    The element itself would only be responsible for providing a collection of URLs, described by their size, in pixels, and their mime-type.

    The UA would be able to choose the best match based on the pixel density muliplier and available bandwidth.

    This means more work for RICG, as we need to specify a reccomended selection algorithm, but I believe that's something we need to do anyway.


    ## Old syntax

    <picture alt="Description of image subject.">
    <source srcset="small.jpg 1x, small-highres.jpg 2x">
    <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x">
    <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg 2x">
    <img src="small.jpg" alt="Description of image subject.">
    </picture>

    ## New syntax (css)

    @media (min-width: 18em) picture{
    max-width:320px;
    }
    @media (min-width: 45em) picture{
    max-width:800px
    }

    ## New syntax (html)

    <picture alt="Description of image subject.">
    <source src="small.jpg" width=300 height=200 type="image/jpeg" />
    <source src="med.jpg" width=600 height=400 type="image/jpeg" />
    <source src="large.jpg" width=1200 height=800 type="image/jpeg" />
    <source src="large.webp" width=1200 height=800 type="image/webp" />
    <img src="small.jpg" alt="Description of image subject.">
    </picture>

    # Benefits

    * DRY and separation of concern - breakpoints do not have to be specified in-markup
    * Fewer image variations have to be described - pixel density is handled intrinsically (large is hi-res version of medium, etc)
    * No complicated parsing. One value per attribute - simple!
    * Highly forward-flexible - We can invent CSS properties such as 'picture-select: highres` to provide browsers with suggestions or overrides (logos, for example, we might prefer to always be highres, while content pictures can degrade on slow connections, etc)

    ## Prefetch considerations

    We know browser vendors would prefer to prefetch images before CSS downloading completes, but I propose that goal be suspended for a moment. Delaying the prefetching of multi-source images until *after* css (or a portion thereof \*) has been parsed would offer many advantages; I also don't see how the UA would be able to make an intelligent choice concerning resolution until layout has been somewhat established.

    \* An otherwise null-op CSS property (like "allow-picture-select: now;" could signal to the browser when image source selection can safely be made. I don't like the idea of such a property, but it could resolve the prefetching issue if it's sufficiently important, and we could suggest that picture rules be placed at the beginning of CSS, like we do with fonts.