Closed thisisdano closed 7 years ago
@jeremyzilar Take a look at this image processing solution. I can also chat more about it if you'd like.
Could or should the include
support the following attributes?
Could we also simplify the include
itself in any way?
{% media img="DigitalGov_Horizontal" alt="digital.gov" %}
Where media
references the include files that are needed? Not sure what is possible here...
I know I could include all those attributes, but I'll have to look into the include
thing.
Should this tag be used to insert YouTube videos as well? There is a case to be made that videos need alt text and caption text as well.
No, I'm pretty sure we'll want a different tag for videos.
Rebuilt this to use srcset
instead of picture. The art direction use case for picture
was overkill for our needs (so far) and srcset
is simpler. We'll forego the webp
versions as well, since we can't do type switching in srcset
— too bad, since webp
is a lot smaller. But them's the breaks.
srcset
calculates the minimum image resolution necessary to fit the image width and device resolution. So, it serves smaller images to mobile than it would to retina desktop. (There aren't great solutions for optimizing for bandwidth rn.)
Input:
{% include components/image.html
img="lunch-team"
style="full-column"
orignalwidth=1200
alt="Women workers employed as wipers in the roundhouse having lunch in their rest room"
caption='Women workers employed as wipers in the roundhouse having lunch in their rest room. April, 1943.'
credit='Jack Delano, photographer. Courtesy Library of Congress.'
title='Join our _fabulous_ team'
%}
Output:
<figure>
<h6 class="figure-title">Join our <em>fabulous</em> team</h6>
<img class="full-column"
srcset="/preview/gsa/digital.gov/dw-gulp-img/assets/img/dist/lunch-team-200w.jpg 200w,
/preview/gsa/digital.gov/dw-gulp-img/assets/img/dist/lunch-team-400w.jpg 400w,
/preview/gsa/digital.gov/dw-gulp-img/assets/img/dist/lunch-team-600w.jpg 600w,
/preview/gsa/digital.gov/dw-gulp-img/assets/img/dist/lunch-team-800w.jpg 800w,
/preview/gsa/digital.gov/dw-gulp-img/assets/img/dist/lunch-team-1200w.jpg 1200w"
sizes="(min-width: 768px) 720px,100w"
alt="Women workers employed as wipers in the roundhouse having lunch in their rest room">
<div class="figure-credit">Jack Delano, photographer. Courtesy Library of Congress.</div>
<figcaption><p>Women workers employed as wipers in the roundhouse having lunch in their rest room. April, 1943.</p>
</figcaption>
</figure>
title
, caption
and credit
attributes/props accept markdown.orignalwidth
indicates the width of the original image in pixels. This prop prevents the component from asking for a resolution higher than the original.style
will indicate the kind of figure we're adding. I've added the full-column
attribute as an example of a full-column-width image, but these are very subject to change.In action at https://federalist.fr.cloud.gov/preview/gsa/digital.gov/dw-gulp-img/join/
And it looks like custom tags are possible. See here: https://blog.sverrirs.com/2016/04/custom-jekyll-tags.html
But I don't know if it's worth the time to learn how to write it...
On further thought, I'm more sure I don't want to use custom tags. includes
are pretty consistent and portable, and the syntax isn't much more complicated.
Could we merge the style
and include
paths together to both save chars and provide editors with template selection abilities?
It might look like include images/full-column.html
or include images/inline-right.html
Could we also remove the orignalwidth
param as well and just do checks within the templates for the max image size? I guess if the image doesn't meet the min-width then it can resort to including the template that would work? Just trying to get the whole thinking around what size this photo is out of the process and focus only on where it needs to be in the layout — similar to how Medium handles images.
Could we merge the
style
andinclude
paths together to both save chars and provide editors with template selection abilities?It might look like include
images/full-column.html
or includeimages/inline-right.html
Yeah, I think that seems good.
Could we also remove the orignalwidth param as well and just do checks within the templates for the max image size?
I didn't see a way to do this — there didn't seem to be a simple way to do it inside jekyll/liquid, and once we start getting into Ruby programming (which maybe could be possible in a custom tag) I'm no longer competent.
I completely agree wrt simplicity but I don't know how to get there right now, and I don't want it to hold up development much longer.
One way could be to pause on responsive images right now and just stick to vanilla images. Perhaps that's the best way to go to keep this all moving.
OK — stripped out the responsive bits for now. We can and should add them down the road as we get more experience.
Input:
{% include image/full-width.html
img="lunch-team.png"
alt="Women workers employed as wipers in the roundhouse having lunch in their rest room"
caption='Women workers employed as wipers in the roundhouse having lunch in their rest room. April, 1943.'
credit='Jack Delano, photographer. Courtesy Library of Congress.'
title='Join our _fabulous_ team'
%}
Output:
<figure class="full-width">
<h6 class="figure-title">Join our <em>fabulous</em> team</h6>
<img srcset="/assets/img/raw/lunch-team.png" alt="Women workers employed as wipers in the roundhouse having lunch in their rest room">
<div class="figure-credit">Jack Delano, photographer. Courtesy Library of Congress.</div>
<figcaption>
<p>Women workers employed as wipers in the roundhouse having lunch in their rest room. April, 1943.</p>
</figcaption>
</figure>
This gets us up and running, and should provide the baseline for further enhancement.
It looks like it doesn't make it that much easier, but I _do_ think the include format is simpler than full html cut/paste.
PR requires a new
npm install
This PR does a few things.
I was experimenting with the
jekyll-picture-tag
plugin — which worked OK locally, but would not run on Federalist, perhaps because of an ImageMagick dependency. However, even without ImageMagick, I'd decided against this path so we could avoid plugins where possible to give us some more flexibility with future generators.I'm not 100% sure this is the best course, but since I could replicate the functionality without a plugin, I wanted to go for it.
Also, the plugin generates directly to the
_site
folder, and uses a hash to determine which files to process and which have already been processed. Since Federalist builds a new instance each time we push, that would mean (I think!) doing all the image transformations with each push. Not so bad with only a couple images. Perhaps more serious with >1500.My current solution uses a gulp task to process images from an "inbox" (
assets/img/_to-process
) to a few common sizes used for responsive images. Then I useinclude
s to build the picture element from a few common variables, like so:outputs to
This picture
include
is very simple for now, but I can give it more sophistication and configuration options. The gulp task is possibly overkill in that it will generate more variants than may be needed, but this too could be controlled with some more programming sophistication down the road.This solution may also put more of a burden on our repo, since the image variants will be tracked in github. I don't know the implications of this.
This PR also cleans up a couple other things:
.hidden
attribute from working properly, so I added it directly to thehead
and gave it an!important
. I'm not %100 on this solution, but it fixes both an issue with the subnav appearing, and that "gray flash at the beginning of page load" issue as well.picturefill
polyfill to thehead
to polyfill the picture elementCheers! 🍻