Responsive images and markdown
Sherwood Botsford
sgbotsford at gmail.com
Sat Mar 30 10:56:19 EDT 2019
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20190330/402082de/attachment-0001.html>
More information about the Markdown-Discuss
mailing list