image alt text is lost during parsing

[aaronpk]

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 w3c/Micropub#34

[voxpelli]

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: microformats/php-mf2#97

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

[voxpelli]

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.

[kevinmarks]

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

[tantek]

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").

[tantek]

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

[bear]

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

[aaronpk]

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"
          }
        ]
      }
    }

[kartikprabhu]

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?

[tantek]

@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?

[kartikprabhu]

@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.

[aaronpk]

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.

[gRegorLove]

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.

[aaronpk]

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.