Responsive images and markdown
Sherwood Botsford
sgbotsford at gmail.com
Sun Mar 31 09:05:36 EDT 2019
You got it.
I ran it by here to check to see if someone had already invented this
particular wheel.
I work *really* hard to keep content and presentation separate. You can
easily get so wrapped up in tweaking presentation.
So my presentation is all done with CSS. My only concession are the <div>
tags that modify the flow. So:
.picfull is 95% of the container wide. Used for a banner pic at the top of
the page, or at the foot of the page, sometimes used as a section separator
on a long page.
.pic, pic3, pic6 are 40%, 30% and 60% of the container width, and float
left. picr, pic3r and pic6r do the same for the right.
I do have to be careful to not put two that float on the same side too
close together, or they stack up. When that happens, I just move them both
into the same <div>
Nearly everything is sized in rem or in percentages. Makes for a
reasonably responsive website.
But I'm finding that a LOT of my web traffic is coming from mobile devices.
(about 40%) Given that my web site is marginal for a mobile phone in
portrait, I need to make two signficant upgrades.
One is to deliver smaller/more tightly cropped images to mobile devices.
The other is to come up with a cleaner menu on mobile devices.
Regards
Sherwood
On Sat, 30 Mar 2019 at 21:35, Tom Humiston <tom at jumpingrock.net> wrote:
> Okay, Sherwood, I think I'm getting it.
>
> You've got your site source in Markdown format. You want to change the
> images to HTML picture elements, each referring to three files that have a
> standardized naming scheme.
>
> So you're working on how to do the text manipulations with Perl. And you
> wondered if anyone here has a better way to come at it or had already got a
> tool for the job.
>
> I thought you wanted to represent in Markdown syntax _which_ images to
> manipulate and/or their _dimension data_. And then run a script to make the
> change.
>
> Sorry I can't help with Perl. Stack Overflow or a Perl discussion site is
> sure to have folk who can.
>
> I hadn't heard of Template Toolkit; thanks for that. For running my sites
> I use [Void] as a backbone and build it out with tweaks and expansions to
> the PHP and CSS as needed.
>
> [Void]: https://github.com/josephernest/void
>
>
> Cheers,
> Thomas
>
>
>
> > On 30 Mar 2019, at 10:56 AM, Sherwood Botsford <sgbotsford at gmail.com>
> wrote:
> >
> > My parser doesn't support that extra syntax, and I don't understand perl
> well enough to swap parsers in Template Toolkit.
> >
> > I'm not sure how it helps me. While I can add attributes this way, I
> still need to rewrite image.jpg as a series of strings, image-S.jpg;
> image-M.jpg; and image-L.jpg
> >
> > Another key aspect of this: My website at present has 300 pages in it.
> A sed script to turn <DIV class=picture> to <div class=picture> is a lot
> easier than editing every image reference.
> >
> >
> > Regards
> >
> > Sherwood
> >
> >
> >
> > On Fri, 29 Mar 2019 at 20:41, Tom Humiston <tom at jumpingrock.net> wrote:
> > Maybe I misunderstand you but I think one or the other of these will
> work:
> >
> >
> > {.parse_me}
> >
> > 
> >
> >
> > The latter example is standard Markdown, the former adds a class in the
> manner of PHP Markdown Extra (and other parsers as well, I think).
> >
> > If you post-process, what you'll parse isn't much different from that:
> >
> >
> > <img src="/path/to/image.jpg" alt="Alt text here" class="parse_me" />
> >
> > <img src="/path/to/image.jpg" alt="Alt text here" title="700 500 50
> 10 138, 1400 1000 100 50 416" />
> >
> >
> > Whether you parse Markdown or HTML, all your script needs to look for is
> a class (or title) such as 'parse_me' OR a title consisting of numbers.
> Assuming that the filenames to be generated all follow the same pattern.
> >
> > > So all I need to do is write a code snippet that turns
> > >
> > >  into the corresponding set of
> picture and src image tags.
> >
> >
> > Yup, I think we're just talking about two different ways of marking the
> images that your snippet will parse.
> >
> > HTH,
> > T
> >
> >
> >
> > > On 29 Mar 2019, at 7:44 AM, Sherwood Botsford <sgbotsford at gmail.com>
> wrote:
> > >
> > >
> > > Reason I'm more inclined to preprocess is as follows:
> > >
> > > Markdown is visually simpler to parse.
> > >
> > > In template toolkit, I create the navigation system, using a 200 line
> TT2 script. It's messy. TT2 calls a markdown plugin.
> > >
> > > By using the <DIV> versus <div> I have a clear flag to identify where
> I need to work. I think this will be simpler to do without going off the
> rails.
> > >
> > > So all I need to do is write a code snippet that turns
> > >
> > >  into the corresponding set of
> picture and src image tags.
> > >
> > > If I use a variable for the parameters to pass to the srcset criteria,
> then I can change this once for the entire site.
> > >
> > > It will mean creating at least 2 additional images for each currently
> used image.
> > >
> > >
> > >
> > > Regards
> > >
> > > Sherwood
> > >
> > >
> > >
> > > On Wed, 27 Mar 2019 at 17:07, Tom Humiston <tom at jumpingrock.net>
> wrote:
> > > Sherwood, great question and well laid out. If a good solution comes
> up I'll probably want it as well.
> > >
> > > My idea is to _post-process_ the HTML output to convert marked data
> into a picture element, rather than to construct a picture up front that
> can withstand parsing from Markdown into HTML. In the source text, I
> suggest cramming the image's source data into the image's title attribute,
> which then gets unpacked in the post-processing.
> > >
> > > I wrote the following as I was working out the idea.
> > >
> > > ---
> > >
> > > I haven't become familiar with the `<picture>` element but I get the
> idea from what you've presented. As for the CSS presentation, fancier
> things are of course possible but that doesn't change the need for
> well-structured content and good markup.
> > >
> > > Like you, I've got no Javascript background, and I'm happy enough to
> keep it that way. In fact I'm not much of a programmer at all, which may be
> an advantage as I try to always empathize with the non-technical writers
> and readers.
> > >
> > > So I'm looking at the data salad that supports 'picture' and thinking
> it hardly fits into standard prose, and I think one way to come at it is,
> firstly, to pick the appropriate existing Markdown that will tuck the
> structured data into a place it would pose no harm if visible to readers,
> and, secondly, to write a script that will _post-process_ the HTML and
> rewrite the element containing the picture data as a picture element at the
> desired position.
> > >
> > > That is:
> > >
> > > 1. Process your Markdown into HTML.
> > > 2. Post-process the HTML to rewrite instances of picture data as
> `<picture>` elements.
> > >
> > > For the first step, two options that come to mind use extended
> Markdown syntax: the footnote and the description list.
> > >
> > > In either case I suppose you could include a keyword or key bit of
> syntax to mark the data in a way that will cause your bespoke
> post-processing script to recognize and act upon it.
> > >
> > > A __footnote__ would place the structured data _outside the flow of
> the main text_ (suitable if there is no post-processing) and allow almost
> any variety of temporary syntax for arranging that data. Another advantage
> is that the HTML link to the footnote, which would indicate where your
> script should insert the picture, can reside within a block-level element
> just as an `img` now can. (The downside is that the footnote link cannot
> exist _without_ associated block-level content. Oh well.) Note that the
> keyword cannot be the footnote marker itself, as this is processed out by
> the Markdown script (at least in the implementations of which I'm aware).
> > >
> > > A __description list__ would place the data in a DL element,
> structured either as a series of DT-DD pairs, or as the content of a single
> pair which you could again structure in any fashion (as with the footnote).
> A disadvantage is that the data will fall more within the surrounding prose
> than would a footnote, but advantages may exist as well.
> > >
> > > Below are examples of the Markdown I imagine, each using
> `\picture-data\` as the identifier to be recognized in post-processing. To
> structure the data I merely remove the angle brackets and line breaks (to
> minimize Markdown processing) and add semicolons as delimiters. The last
> example builds on the standard Markdown image format and thus does not
> require extended syntax.
> > >
> > >
> > > ## Example 1: Footnote
> > >
> > > A picture[^pic1] will go inside this paragraph.
> > >
> > > [^pic1]: \picture-data\ source media="(max-width: 700px)"
> sizes="(max-width: 500px) 50vw, 10vw" srcset="stick-figure-narrow.png 138w,
> stick-figure-hd-narrow.png 138w"; source media="(max-width: 1400px)"
> sizes="(max-width: 1000px) 100vw, 50vw" srcset="stick-figure.png 416w,
> stick-figure-hd.png 416w"; img src="stick-original.png" alt="Human"
> > >
> > >
> > > ## Example 2: Description List with Single Term
> > >
> > > Lorem ipsum dolor sit amet consectetur adipiscing whatever.
> > >
> > > \\picture-data\\
> > > : source media="(max-width: 700px)" sizes="(max-width: 500px)
> 50vw, 10vw" srcset="stick-figure-narrow.png 138w,
> stick-figure-hd-narrow.png 138w"; source media="(max-width: 1400px)"
> sizes="(max-width: 1000px) 100vw, 50vw" srcset="stick-figure.png 416w,
> stick-figure-hd.png 416w"; img src="stick-original.png" alt="Human"
> > >
> > > Lorem ipsum dolor sit amet consectetur adipiscing more of whatever.
> > >
> > >
> > > ## Example 3: Description List with Multiple Terms
> > >
> > > \\picture-data\\
> > >
> > > source1
> > > : media="(max-width: 700px)" sizes="(max-width: 500px) 50vw, 10vw"
> srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png 138w"
> > >
> > > source2
> > > : media="(max-width: 1400px)" sizes="(max-width: 1000px) 100vw,
> 50vw" srcset="stick-figure.png 416w, stick-figure-hd.png 416w";
> > >
> > > img
> > > : src="stick-original.png" alt="Human"
> > >
> > >
> > > ## Example 4: Image + Footnote
> > >
> > > Presumably you'd like a basic one-size-fits-all-screens 'img' element
> to be displayed in case there is no post-processing to create a picture
> element. Shifting the additional source data (beyond what is required for
> img) into a footnote could still be a good answer:
> > >
> > > [^pic4]
> > >
> > > [^pic4]: \picture-data\ source media="(max-width: 700px)"
> sizes="(max-width: 500px) 50vw, 10vw" srcset="stick-figure-narrow.png 138w,
> stick-figure-hd-narrow.png 138w"; source media="(max-width: 1400px)"
> sizes="(max-width: 1000px) 100vw, 50vw" srcset="stick-figure.png 416w,
> stick-figure-hd.png 416w"
> > >
> > >
> > > ## Example 5: Image with Title
> > >
> > > This variation has the advantage that the additional source info is
> not visible (in ordinary contexts, although it's still part of the HTML
> content):
> > >
> > > ![Human][human]
> > >
> > > [human]: stick-original.png '\picture-data\ source
> media="(max-width: 700px)" sizes="(max-width: 500px) 50vw, 10vw"
> srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png 138w";
> source media="(max-width: 1400px)" sizes="(max-width: 1000px) 100vw, 50vw"
> srcset="stick-figure.png 416w, stick-figure-hd.png 416w"'
> > >
> > > The reference form can be used (i.e. image info moved further down the
> page), as shown above. Either way, however, a distinct disadvantage of the
> img approach is that quotes may need to be escaped, since the value of the
> title attribute must be quoted and the value itself (at least as I've been
> showing it) contains quotes.
> > >
> > > ---
> > >
> > > In each example above, I assumed that your post-processing script will
> look for `\picture-data\` and rewrite the related HTML using the string of
> data that follows.
> > >
> > > In the case of a footnote, the script would need to find the related
> link and insert the picture element there. If HTML5 does not define
> `<picture>` as a block element and you wish it this one to be so, I suppose
> you'd need to add 'block' or something to your picture-data so that it can
> influence the post-processing. CSS classes and IDs can be added as well in
> this fashion.
> > >
> > > Example 5, the image-with-title, is possibly the best of these
> suggestions — unless your preferred Markdown implementation chokes on
> nested quotes in image titles. (The dingus at Daring Fireball renders the
> double-quotes in the example as `"` entities. The parser inside the
> 1Writer app does this in all the examples. Okay, so your post-processor
> converts these back to quotes.)
> > >
> > > Some last thoughts:
> > >
> > > - This sort of post-processing approach frees you from having to write
> any HTML for your picture, let alone HTML with case-sensitive tags.
> > > - Other Markdown options that occurred to me later include a table and
> nested lists, but I see little advantage (beyond some semantic correctness
> if they aren't processed out) and so didn't include them above.
> > > - PHP Markdown Extra allows class and ID to be set on images. (And on
> code blocks. The image-source data, for typical reading purposes, is
> programmatic, i.e. it's code, so that would be semantically appropriate
> markup.) Classes and IDs can aid what we're trying to do here.
> > > - I already use post-processing in my PHP to rewrite footnote links
> (so that they don't conflict with those of other blog posts on the same
> page) and find the lag unnoticeable.
> > >
> > >
> > > Hoping this helps,
> > > Thomas Humiston
> > >
> > >
> > >
> > > > On 27 Mar 2019, at 10:22 AM, Sherwood Botsford <sgbotsford at gmail.com>
> wrote:
> > > >
> > > >
> > > > I like markdown. I use it in combination with Template Toolkit, and
> basically I don't have to write any html. My webpages are static, having
> only the js snippet that Google analytics uses. I would mostly like to
> keep it that way. I have zero javascript experience.
> > > >
> > > > I can do some degree of simple page layout using a handful of
> classes applied to DIVs.
> > > >
> > > > So this
> > > >
> > > > <DIV class=picr3>
> > > >
> > > > ![Shelterbelt-12][2]
> > > >
> > > > Planting a shelterbelt, or any tree project...
> > > >
> > > > ***
> > > >
> > > > </DIV>
> > > > [2]: /Images/Shelterbelt/Shelterbelt-12.jpg
> > > >
> > > > is all the html I need to use to have an image sized to width 30% of
> the Content div floated to the right. The system isn't perfect, but it
> resizes reasonably well, and since the page is static it caches well, and
> is fast to deliver.
> > > >
> > > > More important to me: I can spend time writing content, and very
> little tweaking layout.
> > > >
> > > > The problem: If I serve an nice desktop image to a mobile phone,
> download times are high. If I serve an image of reduced resolution to make
> phone access quick, it looks like crap on a desktop.
> > > >
> > > >
> > > >
> > > > In Html we now have the <picture> element, combined with the srcset
> and size attributes. This turns what used to be a simple img tag into
> this:
> > > >
> > > > <picture>
> > > > <source media="(max-width: 700px)" sizes="(max-width: 500px)
> 50vw, 10vw"
> > > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png
> 138w">
> > > >
> > > > <source media="(max-width: 1400px)" sizes="(max-width: 1000px)
> 100vw, 50vw"
> > > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w">
> > > >
> > > > <img src="stick-original.png" alt="Human">
> > > > </picture>
> > > >
> > > > At this point, I'm looking at having to roll my own solution much
> along this line:
> > > >
> > > > * Replace <DIV> with <div> On my implementation of Markdown, being
> between lower case tags means that the content of that tag is not Markdown
> processed.
> > > >
> > > > * Come up with a standard naming convention, say whateverimage-L.jpg
> for the large version, -M.jpg for the medium version and -S. jpg for the
> small version.
> > > >
> > > > * Pre process the resulting markdown files to generate the full
> <picture> element from the embedded markdown. I think this is within my
> limited perl programming capabilities.
> > > >
> > > > Gotchas?
> > > >
> > > > This wheel has been invented already?
> > > >
> > > > Better ways to approach this? Should I bite the bullet and do this
> with a javascript snippet?
> > > >
> > > > Some other solution I've missing in my wandering of 'a maze of
> twisty passages, all different' that is the internet?
> > > >
> > > >
> > > > Regards
> > > >
> > > > Sherwood
> > > >
> > > > _______________________________________________
> > > > Markdown-Discuss mailing list
> > > > Markdown-Discuss at six.pairlist.net
> > > > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
> > >
> > > _______________________________________________
> > > Markdown-Discuss mailing list
> > > Markdown-Discuss at six.pairlist.net
> > > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
> > > _______________________________________________
> > > Markdown-Discuss mailing list
> > > Markdown-Discuss at six.pairlist.net
> > > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
> >
> > _______________________________________________
> > Markdown-Discuss mailing list
> > Markdown-Discuss at six.pairlist.net
> > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
> > _______________________________________________
> > Markdown-Discuss mailing list
> > Markdown-Discuss at six.pairlist.net
> > https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20190331/3886a908/attachment-0001.html>
More information about the Markdown-Discuss
mailing list