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