Floating images


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'

# 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
    if image_count == 2
      div.set_attribute('class', 'sidebyside')
      if div_class == 'left'        
        div.set_attribute('class', div_class)
        div_class = 'right'
        div.set_attribute('class', div_class)
        div_class = 'left'

# 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;

Consistent attribute syntax

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? :smirk:


You mean like:

![foo](/url "title").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.


I’m very sorry, but you totally miss my point.

Your solution would not allow the following:

![I want to be left](/url) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris hendrerit felis in.

![I want to be left as well](/url) 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">![I want to be left](/url)</span> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris hendrerit felis in

<span class="float-left">![I want also to be left](/url)</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 ![image](/url).But when would this happen? And if it is needed you can write ![image](/url)\.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, ![altText](image.png "title"){.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):


I think this is much more acceptable than needing to:


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.


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. :slight_smile:


[quote=“lumio, post:24, topic:266, full:true”]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.

After browsing the forum some more, it seems the plan is not to change the core Markdown very much:

So our discussion about whether this should be in the core appears to already have been decided.

As an extension for handling explict image alignments, I suggest a solution closer to @rwzy’s suggestion. This would avoid including presentional elements in Markdown.

[I am not float](http://foo.com/bar.png){ .right }

The above is developer friendly but I certainly do not find that to be user friendly.

![alt text](/path/to/image.png#center)

The above approach has two issues. When images are linked as ![][1] the alignment information is tucked away in the footer. It also poses the problem that users have to learn to add fragments which is tricky if the URL has a query string. foo.com?a=b#frag is invalid.

I am not sure if I am getting this right, but I feel Markdown should be targeted to lay persons and not just the SO community. A lot of the feedback seems to be developer-centric (editing URL fragments or appending CSS classes).

Image alignments have been discussed in the floating images topic.

Yes, I saw that thread. I’ll leave my proposed solution here since I find to be the most usable way of aligning images. I have been using it for over a year and the users love it. In fact, we have even extended it further to fit our purposes:

[ I am right floated](http://foo.com/bar.png)```
[  I am right squeezed](http://foo.com/bar.png)```
[   I am right squeezed even more](http://foo.com/bar.png)

This makes it very easy for the rendered HTML to wrap text around well proportioned images in a manner that is befitting. It has transformed for us the quality of content publishing since floated images within text is a very common scenario, even mandatory for most publishers.


I’m in agreement that developer-centric syntax is best be avoided, or should be a last resort. Presentational information should be avoided in HTML and Markdown too. Image alignments are definitely presentational information that may differ across different websites and applications. There were some arguments put forward earlier in this topic that extra image information (such as alignment) sometimes needs to be explicitly defined. Hence the proposal for consistent attribute syntax. This would at least avoid requiring presentational information (you could give the class name a more semantic meaning), but it isn’t ideal.

Such features have been requested, however I do question their necessity. There are other ways of defining image properties. These could be in a predefined pattern for image alignments defined by the application. Or pulled from a separate place (a YAML file or a database table), keeping the Markdown document clean of additional properties. Perhaps another markup language could contain presentational information and applied to images mentioned in a Markdown document after the draft is complete. Separation of concerns between the author and “document formatter”.


By the way, you can style specific images (or other elements) in CSS based on their position in the document. Here’s an example showing how to align the first image to the left, the second image to the right:

img:nth-child(1) {  
  float: left;
img:nth-child(2) {  
  float: right;

In this example there is no need for ids, classes, or alignment attributes to be added to the HTML or Markdown directly; everything is done through CSS. The main problem is that the position of the images could change with subsequent editing, whereas giving the image an id “anchors” it to the related styling.