[whatwg] [HTML5] A content in <img> elements for ASCII art

[Tab Atkins Jr.]

On Wed, Nov 25, 2009 at 12:19 AM, David Bruant
<bruant at enseirb-matmeca.fr> wrote:
> => I take this argument as a "pro" argument for two reasons :
> - <img> are void elements in every single browser, so, if this "status"
> changes in HTML5, they can all change the behavior of <img> element at
> the same time (which would be harder if some browser had already given a
> meaning to a <img> content)

No, it's still a minus.  Every browser on the planet treats <img> as
void.  Any change to that would be *completely* unusable for a very
long time, as you'd have to wait for every single extant browser to
become irrelevant.  This would be a huge change, and there just isn't
enough benefit to justify this.

> - web developers know that so far, <img> elements were void elements, so
> adding a content to <img> won't make the least retro-compatibility
> problem with what already exists.

Again, that's a strike against.  Every teaching aid or tutorial on the
planet teaches <img> as being a void element.  They will all be wrong
here, confusing new authors when they see a non-void <img>.

> As a consequence, I propose that :
> - the src attribute of the <img> element becomes optional.
> - content is allowed in the <img> element and rendered if the src
> attribute is not present.

This would make the parsing of <img> dependent on whether or not @src
is specified.  This is a big no-no - it should be avoided at nearly
any cost.

The only benefit here is that ASCII art gets to be done with <img>.
That is far from a vital use-case, and is in my opinion in no way
enough to justify such a major change to the language at this point.
It probably would have been better if <img> hadn't been void from the
start, but we're stuck with that unless there's an *extremely* good
reason to change it.

~TJ