From protection at firewicca.com Sat Mar 16 11:43:33 2019 From: protection at firewicca.com (=?utf-8?B?QW1iam9lcm7gv4dTa29lbGTwn5Sl?=) Date: Sat, 16 Mar 2019 15:43:33 +0000 Subject: Markdown Message-ID: Markdown ? E.S.A?Security?Protection ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgbotsford at gmail.com Wed Mar 27 10:22:10 2019 From: sgbotsford at gmail.com (Sherwood Botsford) Date: Wed, 27 Mar 2019 08:22:10 -0600 Subject: Responsive images and markdown Message-ID: 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
![Shelterbelt-12][2] Planting a shelterbelt, or any tree project... ***
[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 element, combined with the srcset and size attributes. This turns what used to be a simple img tag into this: Human At this point, I'm looking at having to roll my own solution much along this line: * Replace
with
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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at jumpingrock.net Wed Mar 27 19:07:27 2019 From: tom at jumpingrock.net (Tom Humiston) Date: Wed, 27 Mar 2019 19:07:27 -0400 Subject: Responsive images and markdown In-Reply-To: References: Message-ID: <8D09DA40-328B-45C4-9D21-D55FCA2CB763@jumpingrock.net> 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 `` 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 `` 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: ![Human](stick-original.png)[^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 `` 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 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 > >
> > ![Shelterbelt-12][2] > > Planting a shelterbelt, or any tree project... > > *** > >
> [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 element, combined with the srcset and size attributes. This turns what used to be a simple img tag into this: > > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png 138w"> > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w"> > > Human > > > At this point, I'm looking at having to roll my own solution much along this line: > > * Replace
with
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 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 From sgbotsford at gmail.com Fri Mar 29 07:44:24 2019 From: sgbotsford at gmail.com (Sherwood Botsford) Date: Fri, 29 Mar 2019 05:44:24 -0600 Subject: Responsive images and markdown In-Reply-To: <8D09DA40-328B-45C4-9D21-D55FCA2CB763@jumpingrock.net> References: <8D09DA40-328B-45C4-9D21-D55FCA2CB763@jumpingrock.net> Message-ID: 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
versus
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 ![Alt text here](/path/to/image.jpg) 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 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 `` 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 > `` 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: > > ![Human](stick-original.png)[^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 `` > 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 > 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 > > > >
> > > > ![Shelterbelt-12][2] > > > > Planting a shelterbelt, or any tree project... > > > > *** > > > >
> > [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 element, combined with the srcset and > size attributes. This turns what used to be a simple img tag into this: > > > > > > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png > 138w"> > > > > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w"> > > > > Human > > > > > > At this point, I'm looking at having to roll my own solution much along > this line: > > > > * Replace
with
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 > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at jumpingrock.net Fri Mar 29 22:41:30 2019 From: tom at jumpingrock.net (Tom Humiston) Date: Fri, 29 Mar 2019 22:41:30 -0400 Subject: Responsive images and markdown In-Reply-To: References: <8D09DA40-328B-45C4-9D21-D55FCA2CB763@jumpingrock.net> Message-ID: Maybe I misunderstand you but I think one or the other of these will work: ![Alt text here](/path/to/image.jpg){.parse_me} ![Alt text here](/path/to/image.jpg '700 500 50 10 138, 1400 1000 100 50 416') 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: Alt text here Alt text here 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 > > ![Alt text here](/path/to/image.jpg) 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 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
versus
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 > > ![Alt text here](/path/to/image.jpg) 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 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 `` 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 `` 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: > > ![Human](stick-original.png)[^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 `` 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 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 > > > >
> > > > ![Shelterbelt-12][2] > > > > Planting a shelterbelt, or any tree project... > > > > *** > > > >
> > [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 element, combined with the srcset and size attributes. This turns what used to be a simple img tag into this: > > > > > > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png 138w"> > > > > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w"> > > > > Human > > > > > > At this point, I'm looking at having to roll my own solution much along this line: > > > > * Replace
with
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 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 From sgbotsford at gmail.com Sat Mar 30 10:56:19 2019 From: sgbotsford at gmail.com (Sherwood Botsford) Date: Sat, 30 Mar 2019 08:56:19 -0600 Subject: Responsive images and markdown In-Reply-To: References: <8D09DA40-328B-45C4-9D21-D55FCA2CB763@jumpingrock.net> Message-ID: 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
to
is a lot easier than editing every image reference. Regards Sherwood On Fri, 29 Mar 2019 at 20:41, Tom Humiston wrote: > Maybe I misunderstand you but I think one or the other of these will work: > > > ![Alt text here](/path/to/image.jpg){.parse_me} > > ![Alt text here](/path/to/image.jpg '700 500 50 10 138, 1400 1000 100 > 50 416') > > > 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: > > > Alt text here > > Alt text here > > > 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 > > > > ![Alt text here](/path/to/image.jpg) 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 > 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
versus
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 > > > > ![Alt text here](/path/to/image.jpg) 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 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 `` 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 > `` 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: > > > > ![Human](stick-original.png)[^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 > `` 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 > 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 > > > > > >
> > > > > > ![Shelterbelt-12][2] > > > > > > Planting a shelterbelt, or any tree project... > > > > > > *** > > > > > >
> > > [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 element, combined with the srcset > and size attributes. This turns what used to be a simple img tag into > this: > > > > > > > > > > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png > 138w"> > > > > > > > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w"> > > > > > > Human > > > > > > > > > At this point, I'm looking at having to roll my own solution much > along this line: > > > > > > * Replace
with
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 > 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: From tom at jumpingrock.net Sat Mar 30 23:35:42 2019 From: tom at jumpingrock.net (Tom Humiston) Date: Sat, 30 Mar 2019 23:35:42 -0400 Subject: Responsive images and markdown In-Reply-To: References: <8D09DA40-328B-45C4-9D21-D55FCA2CB763@jumpingrock.net> Message-ID: <3BB2B91D-993D-4132-841A-8096DC700750@jumpingrock.net> 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 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
to
is a lot easier than editing every image reference. > > > Regards > > Sherwood > > > > On Fri, 29 Mar 2019 at 20:41, Tom Humiston wrote: > Maybe I misunderstand you but I think one or the other of these will work: > > > ![Alt text here](/path/to/image.jpg){.parse_me} > > ![Alt text here](/path/to/image.jpg '700 500 50 10 138, 1400 1000 100 50 416') > > > 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: > > > Alt text here > > Alt text here > > > 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 > > > > ![Alt text here](/path/to/image.jpg) 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 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
versus
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 > > > > ![Alt text here](/path/to/image.jpg) 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 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 `` 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 `` 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: > > > > ![Human](stick-original.png)[^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 `` 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 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 > > > > > >
> > > > > > ![Shelterbelt-12][2] > > > > > > Planting a shelterbelt, or any tree project... > > > > > > *** > > > > > >
> > > [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 element, combined with the srcset and size attributes. This turns what used to be a simple img tag into this: > > > > > > > > > > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png 138w"> > > > > > > > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w"> > > > > > > Human > > > > > > > > > At this point, I'm looking at having to roll my own solution much along this line: > > > > > > * Replace
with
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 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 From sgbotsford at gmail.com Sun Mar 31 09:05:36 2019 From: sgbotsford at gmail.com (Sherwood Botsford) Date: Sun, 31 Mar 2019 07:05:36 -0600 Subject: Responsive images and markdown In-Reply-To: <3BB2B91D-993D-4132-841A-8096DC700750@jumpingrock.net> References: <8D09DA40-328B-45C4-9D21-D55FCA2CB763@jumpingrock.net> <3BB2B91D-993D-4132-841A-8096DC700750@jumpingrock.net> Message-ID: 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
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
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 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 > 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
to
is a lot > easier than editing every image reference. > > > > > > Regards > > > > Sherwood > > > > > > > > On Fri, 29 Mar 2019 at 20:41, Tom Humiston wrote: > > Maybe I misunderstand you but I think one or the other of these will > work: > > > > > > ![Alt text here](/path/to/image.jpg){.parse_me} > > > > ![Alt text here](/path/to/image.jpg '700 500 50 10 138, 1400 1000 > 100 50 416') > > > > > > 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: > > > > > > Alt text here > > > > Alt text here > > > > > > 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 > > > > > > ![Alt text here](/path/to/image.jpg) 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 > 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
versus
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 > > > > > > ![Alt text here](/path/to/image.jpg) 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 > 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 `` 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 > `` 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: > > > > > > ![Human](stick-original.png)[^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 > `` 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 > 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 > > > > > > > >
> > > > > > > > ![Shelterbelt-12][2] > > > > > > > > Planting a shelterbelt, or any tree project... > > > > > > > > *** > > > > > > > >
> > > > [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 element, combined with the srcset > and size attributes. This turns what used to be a simple img tag into > this: > > > > > > > > > > > > > > > srcset="stick-figure-narrow.png 138w, stick-figure-hd-narrow.png > 138w"> > > > > > > > > > > > srcset="stick-figure.png 416w, stick-figure-hd.png 416w"> > > > > > > > > Human > > > > > > > > > > > > At this point, I'm looking at having to roll my own solution much > along this line: > > > > > > > > * Replace
with
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 > 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: From tom at jumpingrock.net Sun Mar 31 23:35:45 2019 From: tom at jumpingrock.net (Tom Humiston) Date: Sun, 31 Mar 2019 23:35:45 -0400 Subject: Responsive images and markdown In-Reply-To: References: <8D09DA40-328B-45C4-9D21-D55FCA2CB763@jumpingrock.net> <3BB2B91D-993D-4132-841A-8096DC700750@jumpingrock.net> Message-ID: Just a follow-up note to readers of this thread: When I said that I "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)", it was an unwarranted slander against PHP Markdown Extra. I happened to re-read the [documentation][1] and discovered Michel Fortin has already built a config option into MDE, called 'fn_id_prefix', that allows one to pass an identifier for each blog post that is processed. [1]: https://michelf.ca/projects/php-markdown/configuration/#markdown-extra Cheers, TH