I’m not sure if it is the right time to “add features” and blow up the spec, but one thing I really miss from the perspective of someone who writes articles is to be able to have images floating without using HTML.
What about a syntax like the following
Inline image (normal behaviour):
Image floating left:
!<[foo](/url "title")
Image floating right:
!>[foo](/url "title")
This would make it easier to write e.g. articles
What do you guys think? What is the pro and contra
I’ve implemented this by automatically floating the images in a sequential pattern. Every odd numbered image is floated left, every even numbered image to the right. This way the standard Markdown image tag can be used without presentational information being added to it, keeping the content separate from the presentation of that content.
Fail to see the issue still. I’m assuming chrisalley used css selectors (:nth-child(odd/even)) to do this. Therefore to have it the other way around, you would simply change your css to your liking. Either way, as chrisalley says, that’s irrelevant to this markdown spec itself since the css is doing your alignment.
If you don’t want just odd or even, then you’ll need to arbitrarily select the images, which would be possible with the syntax proposed in 272 (by being able to add in your own classes/attributes).
Using CSS selectors is a clean way to implement this. I actually did it by modifying the HTML and adding CSS classes after the Markdown is converted to HTML. Here is some Ruby code which does this, using the Nokogiri gem. It handles inline images as well, just two next to each other side by side. The code assumes all the images are same width however, so it’s not going to fit every solution. And maybe cleaner solutions exist using just CSS.
require 'nokogiri'
html = Nokogiri::HTML.parse(html)
# Replace paragraphs wrapping the images with divs.
html.css('img').each do |img|
img.parent.name = 'div'
end
# Alternate between aligning the divs left, right, or in a side by side container.
div_class = 'left'
html.css('div').each do |div|
unless div.get_attribute('class') == 'footnotes'
image_count = 0
div.css('img').each do |img|
image_count = image_count + 1
end
if image_count == 2
div.set_attribute('class', 'sidebyside')
else
if div_class == 'left'
div.set_attribute('class', div_class)
div_class = 'right'
else
div.set_attribute('class', div_class)
div_class = 'left'
end
end
end
end
# Converts nokogiri variable to html.
html = html.to_html
And then use the following CSS to handle the floating of the image containers and their sizes.
? That might conflict with normal text when the image is inline. Curly braces directly after is more rare in such cases and therefore better (whereas a period is normally appended without any space at the end of a sentence).
Because part of the core philosophy of Markdown is that readability “is emphasized above all else.” Adding class names to Markdown is less readable (for the content writer) than the solution I posted.
 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris hendrerit felis in.
 Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris hendrerit felis in
Now to achieve a proper floating you would need to do this:
<span class="float-left"></span> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris hendrerit felis in
<span class="float-left"></span> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris hendrerit felis in
Or another way would be to write the images as markup.
That’s correct but the chances are very rare. And if it is the case you would be able to escape it. But with your example this would still work:
A sentence (with braces). Would work without problems
This is the worst case scenario with an inline .But when would this happen? And if it is needed you can write \.Your turn.
I’m really sorry, but I don’t see a problem here. The chances are very rare that you would break you markdown with this and it would be a huge win for people who have no programming background.
This might be an odd argument but look at this picture:
Can you spot the braces?
If you want to let the content editor decide how specific images are aligned, then yes, my solution will not work. It only works for the automation of the image alignments.
I see the automation of how the images are aligned as a feature, as this means the content writer can focus on just their content without distractions. If you want to give the content editor control over the image alignments then they are no longer just a content editor - they are a layout designer too. That’s a slippery boundary to cross.
I think @chrisalley’s concern about the separation of content and presentation is valid. That’s why I think we should allow adding classes to images instead of specifying their floating behaviour directly (unfortunately he seems to be also against classes).
Requiring curly braces is less confusing and makes it easy to see that they are indeed attributes related to the image. Yes, an image at the end of a sentence is rare but that doesn’t cover the case for IDs, which start with #, or attributes, key="value". If you actually want a curly brace immediately after the image, then you should be able to escape (the first one only):
\{.text}
I think this is much more acceptable than needing to:
\.text
Not having a keyboard with square brackets/curly braces is, in my opinion, not a good argument to change the syntax to be honest.
Edit: Because it’s much easier to get you to change your keyboard than for everyone else to endure an inferior syntax when you are in the vast minority (of those that don’t have square brackets and curly braces on their keyboards).
Again, it’s not image alignments per se, it’s a method to mark elements as unique or different than the rest. There’s no boundary being crossed with that.
A good question to ask is should they have control over the layout? I think it will depend on the context. For many sites, restricting customisation is a feature.
For GitHub, StackOverflow, Discourse, iA Writer, and other more minimalist content entry software, I’d argue that allowing control of the layout would be detrimental to their goals. It would give the writer too much control. If image alignment becomes part of the core CommonMark spec, these services/software would probably remove the functionality, creating a subset of CommonMark. CommonMark would no longer be a common flavour of Markdown, the subset would be. So I suggest making image alignments and/or classes an extension instead.
That’s quite an abstract point and difficult to communicate to causal writers though. They’re probably thinking of what they’re intending to do differently with the image, not that it is unique/different.
