This example illustrates the loss of image alt text during microformats parsing.

<div class="h-entry">
  <p class="p-name e-content">Hello World</p>
  <img class="u-photo" src="globe.gif" alt="spinning globe animation">
</div>

    {
      "type": [
        "h-entry"
      ],
      "properties": {
        "name": [
          "Hello World"
        ],
        "photo": [
          "http://example.com/globe.gif"
        ],
        "content": [
          {
            "html": "Hello World",
            "value": "Hello World"
          }
        ]
      }
    }

This will occur any time the <img> tag appears outside of other microformats properties.

This means it's impossible for a consumer of the parsed h-entry to reconstruct a representation of the post that includes the alt text.

This is blocking https://github.com/w3c/micropub/issues/34

This sounds similar to the language parsing brainstorm at: http://microformats.org/wiki/microformats2-parsing-brainstorming#Parse_language_information

lang like alt is additional data that needs to be carried through, although a more complex one since it's inherited while this one isn't inherited.

Continuing on the brainstorming around how to include languages one could imagine:

<img class="u-photo" src="globe.gif" alt="spinning globe animation" lang="en">

Parsed as:

{
  "photo": [
    {
      "value": "http://example.com/globe.gif",
      "alt": "spinning globe animation",
      "lang": "en"
    }
  ]
}

As all implementations should already have the expectation of receiving an object rather than a string and to use the value of that object rather than the string, so adding such an additional alt value would be totally backwards compatible.

Important for parsing libraries to also distinguish between an empty alt and a unspecified alt as that has significantly different meanings.

I know @glennjones has already implemented experimental lang parsing: glennjones/microformat-shiv#22

And @gRegorLove made a lang PR for php-mf2 parser: indieweb/php-mf2#97

So there's something to build upon there experience wise.

After some discussion I'm not as sure anymore on the similarity in parsing – could be that this is rather a special case of fallback content for embedded content: https://html.spec.whatwg.org/multipage/dom.html#fallback-content

One should maybe consider <video>, <audio>, <object>and other embeddable content in addition to <img> when solving this.

The resulting value from whatever parsing one ends up with could probably though be represented similarly as has been suggested for lang– as an alt, fallback or similarly named key on an object similarly constructed as those for e-* type properties.

To preserve alt text (and indeed all accessibility markup) you can use e-content.

First, I think "can use e-content" is not solving the problem, but rather "kicking the can down the road". It is not a solution for the parsing of alt text problem, but instead a way of procrastinating responsibility of parsing for alt text to every microformats JSON consuming application, which is unreasonable since the reason a microformats JSON consuming application is using microformats JSON in the first place is because they do not want to have to parse the HTML. Thus saying "just parse the HTML from e-content" (which is essentially what saying "you can use e-content ... To preserve alt text (and indeed all accessibility markup)" is saying is ignoring the very context of incentives of the microformats JSON consuming application in the first place.

Second, lang and alt are similar in that they are both extra information on the element, but the resemblance stops there. "lang" is both rarely used (in comparison to "alt"), and can often be auto-implied from the content, whereas "alt" can nearly never be implied, and is thus more important to solve. That being said, if a solution for "alt" works for "lang", that would be a nice side effect (but it's not a "must have").

I'm not sure how much to brainstorm in a GH issue and how much to recommend a specific course of action. Feels weird to brainstorm in a threaded medium (GitHub issue) which is the opposite of what you want (collaborative iteration in-place on a brainstorm). @aaronpk suggested a hybrid approach of collborative iterative brainstorming on the wiki.

Here is a start on some specific ideas for approaches (and problems therein):
http://microformats.org/wiki/microformats2-parsing-brainstorming#Parse_img_alt

The change as described in the brainstorm conversation here:
http://microformats.org/wiki/microformats2-parsing-brainstorming#Parse_img_alt

Any implementation of this change would (should) be paired with a major version # change to give consumers a chance to adjust their consuming code

Of the current options in the brainstorming section, everyone who has commented there agrees on the following:

• If a u-* property is parsed on an element with a non-empty 'alt' attribute, then:
  • Create a structure similar to the e-content nested structure that provides the "value" as the URL, and an "alt" as the text alternative.

The original example I gave would end up looking like this:

<div class="h-entry">
  <p class="p-name e-content">Hello World</p>
  <img class="u-photo" src="globe.gif" alt="spinning globe animation">
</div>

    {
      "type": [
        "h-entry"
      ],
      "properties": {
        "name": [
          "Hello World"
        ],
        "photo": [
          {
            "value": "http://example.com/globe.gif",
            "alt": "spinning globe animation"
          }
        ],
        "content": [
          {
            "html": "Hello World",
            "value": "Hello World"
          }
        ]
      }
    }

If there is no non-empty alt attribute should the original parsed format be used?

Secondly, does this not in some way conflict with the use of "value" in e-* type parsing where value is a plaintext representation and html is the actual representation?

@kartikprabhu wrote:

If there is no non-empty alt attribute

Then existing behavior.

does this not in some way conflict with the use of "value" in e-* type parsing where value is a plaintext representation and html is the actual representation?

I don't see what you are talking about. Can you provide a code example that demonstrates this conflict?

@tantek Consider the following example

<div class="h-entry">
  <p class="p-name e-content"><span>Hello World</span></p>
  <img class="u-photo" src="globe.gif" alt="spinning globe animation">
</div>

which under the new rules would give the parsed mf2 as

{
      "type": [
        "h-entry"
      ],
      "properties": {
        "name": [
          "Hello World"
        ],
        "photo": [
          {
            "value": "http://example.com/globe.gif",
            "alt": "spinning globe animation"
          }
        ],
        "content": [
          {
            "html": "<span>Hello World</span>",
            "value": "Hello World"
          }
        ]
      }
    }

from the above one can see that for e-content the plain-text alternative is in the value but for u-photo value is not the plain-text alternative but is the URL while the alt attribute gives the plain-text.

I remember @notenoughneon built a system that uses HTML files with Microformats as a data store: PURR I'd love to get her feedback on whether this new data structure would cause any problems with that model.

That's interesting, @kartikprabhu. I had not really thought of it as an alternative, but more of a default. For content I think the default makes sense as plaintext. For photo I think the default makes sense as a URL. Consumers can then delve into properties like alt if they want more information.

My understanding of the parsing rules was that value is supposed to be what the property would have been if it were not an object. So for content, p-content results in a plaintext value, but e-content turns it into an object where value is the plaintext and html is the special parsed version. It follows that for images, typically u-photo results in the single string value, and if there is alt text, value holds that plain string.

Basically as a consumer, you can always use the value in value as a fallback if you don't understand the object as a whole.

@gRegorLove @aaronpk good points. I guess I was thinking of value in a different way. If @aaronpk 's interpretation of value is documented somewhere then my objection is resolved.

It sounds like we have a fairly good consensus around a particular proposal, and any apparent conflicts have been explained or resolved. Would someone like to take a crack at suggested minimal spec edits to implement the proposal?

Re: @voxpelli point / question / counterproposal for "fallback", this isn't about "fallback" this is about capturing what the author authored, specifically on the element with the microformats property name being parsed.

re: audio & video - they don't do content based fallback, their contents are only for older browsers that have no support for those elements at all.

re: object - it's a different case entirely since its contents allow rich markup. if you want an object's contents, can already get them with an "e-*" property on the object.

if there are others with specific use-cases, we can address them as necessary.

@tantek I'm not really against the solution, it was after all what I proposed initially.

The discussion I referenced above, but failed to link, was this one: https://chat.indieweb.org/microformats/2016-07-12#t1468345415448000

After there having "considered the difference" I concluded that the difference between lang and alt is that lang is a global attribute while alt is the img-specific implementation of fallback content – "content that is to be used when the external resource cannot be used".

It specifically says the following in that spec about alt on img:

the value of the alt attribute provides equivalent content for those who cannot process images or who have image loading disabled (i.e. it is the img element's fallback content)

So fallback content is still about what the author has authored – if the author has given specific fallback content then that fallback content should be forwarded – we are talking about the same thing..

In practice it probably makes sense to use alt as the name.

I still do wonder though why it wouldn't work to just say that a u-* that has specified fallback content should include that fallback content as an alt? So that the following two should result in the same parsed result:

<img class="u-photo" src="foo.svg" alt="A pink flower" />
<object class="u-photo" data="foo.svg">A pink flower</object>

And actually even this:

<object class="u-photo" data="foo.svg"><img src="foo.png" alt="A pink flower" /></object>

Don't they all convey the very same thing from the perspective of HTML?

It makes sense to use "alt" as the name because it's a 1:1 mapping of the value of the alt attribute.

<object class="u-photo" data="foo.svg">A pink flower</object>

Is an artificial example, not real world, you would just use an img.

<object class="u-photo" data="foo.svg"><img src="foo.png" alt="A pink flower" /></object>

Would be properly marked up by putting u-photo on both photos provided:

<object class="u-photo" data="foo.svg"><img class="u-photo" src="foo.png" alt="A pink flower" /></object>

which would then provide the alt for the second photo.

I'm okay with just doing the img alt parsing as it makes for a simpler mf2 parsing spec. I still don't fully understand the criticism in regards to the alt text not being fallback content, but let's leave that.

(The object tag linking to an SVG is not an artificial example but one usually brought up as one of the major ways to include SVG. See eg: https://css-tricks.com/using-svg/#article-header-id-11)