If you don’t care about the semantic in your message, and I agree that this is mostly the case in chat messages, then why bother using mark* at all?
And in any case, it’s just two characters, is this really such a big deal as to introduce a significant departure from the original MD? I don’t think so.
Even if writer leaves the alt tag blank, the square brackets at least reinforce the value that there should be an alt tag. It may get the writer to think “this document may be read by blind people and I am making a conscious decision to ignore that potential need.” A subtle reminder without being authoritarian about it.
The point of requiring brackets before the parenthesis is to reduce the possibility that plain text be mistaken for markup. Perhaps @mb21 was trying to say that in the second sentance of his response: the risk is compatibility. I really don’t think it has have anything to do with reminding users to specify alt strings to make accommodations for blind people.
Allowing omission of empty brackets wouldn’t save much typing anyway, when compared to the work needed to put a an image URL inside the parens. Right?
One way to think about extensions to Markdown syntax is that each has two sides, risk and reward. For this proposal, I think the risk significantly outweighs the reward, and it introduces no new capabilities people are clamoring for. So my vote (if polled) would be no, it’s not reasonable.
Just my opinion, hope it helps…
[quote=“Burt_Harris, post:10, topic:617”]I really don’t think it has have anything to do with reminding users to specify alt strings to make accommodations for blind people.
[/quote]
That was probably not a design intention, but it might have the effect of reminding someone.
I think it is more a matter of aesthetics. Empty brackets are extra noise for the reader to process.
That’s not an abstract question of 2 chars. Problem is, that this 2 chars have special meaning. I don’t mind to type 2 extra chars, but it irritates to type empty alt - looks like doing useless job.
I think that really misses the point. The OP didn’t ask what would look best, he asked why not…?
I suggest that most readers shouldn’t be looking at the raw text (and URLs) in the first place, they want to see the images, right? The markup languages are for authors and editors, people for whom seeing a little markup is justified. If someone wants to author or edit with higher aesthetics, that’s no reason to muck with a markup language syntax we’re trying to stabilize, WYSIWYG/GUI editing tool seems the way to go.
To write/edit a document you also need to be able read it. My point is that readability/aesthetic concerns should be considered here, even if they are not the deciding factor.
No. You rely on assumption, that users are consuming content. In systems like forums, users are producing content.
See above. Term “authors” is applicable when you have some requirements to content quality. At forums, blog comments and so on - there are no technically skilled authors, who care about markdown ideology, html validation and other things. They are just ordinary users, who whish to quickly type text with easy markup.
But they are clever enougth to understand markdown syntax. WISYWIG is bad idea here, because is does not help to type fast, and right implementations are very heavy and buggy, that a reality. Light implementations like ACE / CodeMirror are lines-based (not dom-based), and ideal for markdown.
My stance is that markdown’s strength is the minimalistic syntax, so the smaller amount of concept we need to memorize the better.
If we treat ! as an inline directive signifier that calls !default directive, which then redirects to !image or !video based on content in url (e.g. .png or .mp4). Then it could make sense to make [], () & {} optional.
As in, all !extName directives are represented as a function call !extName[](){} internally (So it’s not a hard coded syntax of a picture, but rather an updatable and extend-able function call).
Thus with that thought above. !( url ) can make sense as long as it is internally represented as !default[ "" ]( "url" ){ "" } (where " ... " is the string data passed to function). This would make implementation of flexible extensions within the parser easier. And allows for consistency in syntax.
But I am still of the camp that  should be encouraged. Thus I would strongly recommend that
!( url ) would throw a warning/recommendation to add an alt descriptor or at least make it explicitly blank via [] (I think we need a warning/recommendation system. No error system needed however). This is so that the author is at least reminded to fix it (While still allowing for those who prefer !( url )
With that in mind, we might need a warning system: http://talk.commonmark.org/t/warnings-recommendation-system-option/
If @mofosyne’s warning system suggestion is accepted, perhaps we could make () [] and {} all optional, but with warnings if valid HTML is not generated. This would allow looser systems to accept the !(filename.jpg) syntax. These systems could fill in the HTML alt, width, and height attributes from other sources (or not, depending on the CMS designer’s requirements). I agree that alt tags should be encouraged, but a warning message is probably better at encouraging this than enforcing empty square brackets.
These “ordinary users” you mention should care if blind (amongst other) people are incapable to see their messages.
If they don’t care about that, then I most definitely don’t care about their needs. At all.
[alt] text is for users, not for robots.
Markdown on the other hand has a goal of being a simple text file syntax where what you write in a text file gets turned into what you mean in HTML. Part of that meaning is the [alt] text.
zzzzBov, What do you think about just allowing !(url), but with a warning "Recommended to include [alt] text in ![](){}, for accessibility for blind users.". This would at least provide the choice/freedom to write freely, while encouraging good practices. And help keep to the philosophy of LeastSurprises(TM)
I think it’s ridiculous to design a syntax that users would be explicitly warned against using.
the relative cost to the user of typing  vs !(image.png) is not worth the relative cost to the implementers to try to support and standardize a feature that we don’t actually want them to use to begin with.
My vote is to axe this extension. The premise of
Usually, nobody adds alt text to images in ordinary posts.
is flawed as it’s a failing of the author, not of the syntax.
Some content management systems might let the user fill in the HTML alt, width, and height attributes in another part of the system. So the author would still be adding the alt tag, just not using Markdown.
If the system is going to automatically generate the alt text, then the following would make sense:
Explicitly empty [alt]: system provides alt text
renders as
<img src="/path/to/img.png" alt="image alt text"/>
Provided [alt]: overrides system alt text
renders as
<img src="/path/to/img.png" alt="custom alt text"/>
In neither case is the removal of [] necessary.
I basically agree with the method you described for adding the alt text from another source. The main reason for making [] optional is that !(file.png) looks cleaner than . So while the removal of [] is unnecessary, from an aesthetic perspective it might be beneficial. Maybe as an extension?
Probably not necessary to make it an extension if we use generic directive syntax. Since !(file.png)is just shorthand for !default[](file.png){} function. Which in javascript would be defaultExtention("","file.png","");.
Basically order of [] & () & {} is not important, and if any is missing, it is automatically added in as an empty bracket.
Sorry to continue this old conversation, but here’s my 2 cents.
I completely agree that alt should be optional. Alt attribute is misunderstood for the most part. Yes, it is required. But for many, if not most images on the web, it serves no value to say specifically what the image is. Rather than that, it should just describe what this image is in general, like icon, logo etc.
Markdown, in any use case other than a full-packed CMS, is meant to express images just decorating the content. It feels too weird to deliver the alt text for images like memes or visualisations of what we just said. Justifications stating that “HTML5 requires it” are not explaining why users should type it. They could, and imo should be automatically generated if omitted, to either fragment of a post, just something general, or empty string.
You can use the content block syntax to create an image without an alt tag. It’s an easier to write syntax as well. So, perhaps the regular image syntax doesn’t need to be changed?