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.
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.
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:
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.
When you add an image to your markdown it is rendered into a standalone P tag. This P tag holds nothing else but the image. Since the IMG tag is an “in-line” element, the alignment of the image is controlled by changing the “text-alignment” of the parent (P tag) that holds this IMG.
We can use CSS to select this IMG directly inside a P tag like this p > img.
However, the problem is that we cannot select that P tag directly since all P tags are rendered without any attributes when rendered to HTML. In CSS there is no way to select the PARENT of an element.
Overall, it’s not the image that needs the stying, it’s the parent (P tag ) holding the image that needs a default class to set it apart from the others. Adding the functionality to give this P tag a custom name could be a secondary improvement.
I think that writing the code to output a tag like <p class="md_image"> would be a much quicker implementation. Then, we could look into being able to add another class to this tag like <p class="md_image customClass">
