Usually, nobody adds alt text to images in ordinary posts. Will it be reasonable to allow skip empty [] for images?
Instead of  -> !(<url>)
That looks compatible with everything else, and less boring for users.
5 Likes
Because the alt attribute is required in valid HTML. Also, all existing implementation will convert no!(really) to <p>no!(really)</p>.
3 Likes
Nobody prohibits to add empty alt, if you need strict valid html. Markdown is for users, not for html validators. Fact is, that most of users don’t use alt for quick messages - alt is needed only in articles-type content. I see no reasons to push them add [].
I uderstand, that existing parsers do not suport this syntax. That’s why this is posted in extentions, not in spec. But it looks very attractive, imho.
1 Like
The CMS that processes the Markdown file may get the alt text from somewhere else anyway. For example, the filename in the Markdown tag could point to an image database record that is attached to the document, acting a key for that image record.
Fact is, that most of users don’t use alt for quick messages - alt is needed only in articles-type content. I see no reasons to push them add
[].
Most users should. For accessibility concerns it is basic politeness to put in an alt. This syntax has the benefit of telling people they really should put in alt (but can still leave it blank), and it is what everyone is used to, and it is the behavior or the original markdown.
I really see no merit in the new proposed syntax.
3 Likes
I agree, it’s just a good habit to always describe your images. E.g. What if the image never loads? Or your reader is blind?
1 Like
I can repeat again, that markdown is for users, not for robots. There are lot of situations, when type speed is more significant, and content value degrades quickly over time. For example, chat messages. There is no need to push user type such content with the same effors as for magazine article.
Ordinary users don’t care about book readers, html5 and other things. They just need to quickly type texts in chats and message boards.
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…
2 Likes
[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.
1 Like
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.
1 Like
tl;dr: Allow this using generic directive syntax, but implement a warning system to encourage good authorship. This will suit vitaly’s need for simple writing, and other’s need for more meta informations.
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/
2 Likes
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.
1 Like
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)