Who/what are you referring to?
- Why?
- Have what the other way around?
Read the post about mine 
“about mine”? I read your first post?
If we follow the syntax in 272, then inline images should have the same syntax as a block image by itself. So maybe you should push for that.
Still don’t know what you mean by “have it the other way around” though.
I was talking about this post
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.
div.left {
width: 298px;
float: left;
}
div.right {
width: 298px;
float: right;
}
div.sidebyside {
width: 621px;
}
I know that it would be a posibility to achieve this with pure CSS but as from the perspective of an Editor I see myself in an odd situation.
Where is the problem from allowing classnames directly appending to images like I wrote above? 
You mean like:
.float-left
? 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.
1 Like
I’m very sorry, but you totally miss my point.
Your solution would not allow the following:
 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.
A usual editor who writes articles is not only a content editor but he/she also controls how his/her article looks.
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).
To add the floatLeft class, {.floatLeft} seems like a good syntax to me. Especially since it’s already implemented in Markdown Extra and in light of a generic and consistent syntax for attributes.
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.
1 Like
Websites can easily strip away or ignore any attributes if they don’t want it. Markdown already allows adding in attributes since it allows raw html too. HTML sanitization should be kept out of the spec and left to the website. It shouldn’t be a means to prevent useful syntax into the sepc.
No it isn’t. It’s irrelevant what “they’re thinking to do with the image”, that can be handled by whatever cms/system/website they’re using stmd in.
I’m arguing that the spec should allow for a way to include attributes with the syntax proposed in 272 as it is very useful, already commonly used and much easier than resorting to html. Since if you decide later to add in an attribute to an element, you could simply append it wrapped in curly braces, without the need to rearrange the ![]() part to html tag syntax.
Agreed about sanitisation. I’m thinking along the lines of websites implementing the full set of the core Markdown/CommonMark tags (not HTML tags). If a site supports CommonMark, users might expect particular features to be allowed. These would be the commonly used tags.
With more complexity added, many sites will just remove the extra tags/attributes via sanitisation, creating sites that only support a subset of CommonMark. This is essentially creating a separate flavour. Perhaps this is not a problem, but doesn’t it go against the mission somewhat? And if so, would it not be better to keep the core set small?
Thing is, markdown has always supported raw html to be mixed in with it, but implementations across websites (for things likes comments) have always only stuck with the very basics and sanitised out anything non-core-markdown. And that makes sense for them of course, because they don’t need nor want any of that.
In my opinion, yes, websites supporting only a subset of commonmark isn’t a problem because that is what will always be done (for security purposes at the least). We can’t stop them from doing that, but that shouldn’t hinder the commonmark spec.
Okay, after a while and after some frustration I think of having (at least) two specifications. The Basic Common Markdown and The Extended Common Markdown.
Since most websites need only a few features of Markdown it doesn’t make sense to allow a syntax for attributes. But maybe for other use cases it would make great sense.
So therefor I would pledge to have two standards. One with the real core of Markdown. The other we could extend in the way to have at least attributes available.
For me the solution with braces is fine. I thought it would be nice to have a shorthand version for the class attribute.
I believe what you suggest already exists in the form of ‘core specification’ and the ‘extension’ category. 