Floating images

Hello everyone,

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):

![foo](/url "title")

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

1 Like

Floating images should be part of the stylesheet.

If standard markdown had classes you could use:

![foo](/url "title") {.dropcap}

and a css with

.dropcap {float: right;}

PS In MD Extra I create standard class .right and .left accordingly floated and additional margin for images.

4 Likes

I agree.

But I would go with the class shortcut since some might find those braces needless and confusing:

![foo](/url "title").float-left

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.

But now we would have two problems…

  1. we can’t insert inline icons
  2. what if we want to have it the other way around?

Who/what are you referring to?

  1. Why?
  2. Have what the other way around?

Read the post about mine :wink:

“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? :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):

![Image](img.png)\{.text}

I think this is much more acceptable than needing to:

![Image](img.png)\.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