reduce instances where photo is implied

[aaronpk]

Like #6, a similar thing is happening with the photo property.

I have a blocking issue on XRay where this is causing problems: https://github.com/aaronpk/XRay/issues/55

Here is a URL with this problem: https://collect.readwriterespond.com/zenpress/

[sknebel]

The example in https://github.com/aaronpk/XRay/issues/55 is rule

else if .h-x>:only-child:not[.h-*]>img[src]:only-of-type:not[.h-*], then use that img’s src for photo

while https://collect.readwriterespond.com/zenpress/ triggers an even simpler step

else if .h-x>img[src]:only-of-type:not[.h-*] then use that img src for photo

[Zegnat]

On Aaron’s site it seems to accidentally catch the header graphic. But I wonder if there aren’t other examples of accidentally implied photos are out in the wild. Some things I can think of:

• The implied rules do not exclude images that already have other explicit properties on them. An <img> with class="u-featured" could thus easily also be picked up for the photo property.
• Are there examples – maybe from WordPress as well – where the only image on the page is a share button or logo of a site the post has been syndicated too? Those may also be picked up by this.

[gRegorLove]

I have an example of this where an element with an explicit u-logo is also being parsed as implied photo. This is is an h-card for an organization, so I don't think it should have a photo property. Below is actual markup for the organization, but with generic contact info.

<div class="h-card">
    <img src="/logo.png" class="u-logo" alt="">

    <p>
        <b class="p-name p-org">Organization Name</b><br>
        <span class="p-street-address">1234 Example</span><br>
        <span class="p-locality">City</span>, <span class="p-region">State</span> <span class="p-postal-code">12345</span> <span class="p-country">US</span>
    </p>

    <p>
        Phone: <a href="tel:1234567890" class="p-tel">(123) 456-7890</a><br>
        Fax: (234) 567-8901
        Email: <a href="mailto:info@example.com" class="u-email">info@example.com</a>
    </p>
</div>

{
    "items": [
        {
            "type": [
                "h-card"
            ],
            "properties": {
                "name": [
                    "Organization Name"
                ],
                "org": [
                    "Organization Name"
                ],
                "street-address": [
                    "1234 Example"
                ],
                "locality": [
                    "City"
                ],
                "region": [
                    "State"
                ],
                "postal-code": [
                    "12345"
                ],
                "country": [
                    "US"
                ],
                "tel": [
                    "(123) 456-7890"
                ],
                "logo": [
                    "/logo.png"
                ],
                "email": [
                    "mailto:info@example.com"
                ],
                "photo": [
                    "/logo.png"
                ]
            }
        }
    ],
    "rels": {},
    "rel-urls": {},
    "debug": {
        "package": "https://packagist.org/packages/mf2/mf2",
        "version": "v0.4.3",
        "note": [
            "This output was generated from the php-mf2 library available at https://github.com/indieweb/php-mf2",
            "Using the masterminds/html5 HTML parser",
            "Please file any issues with the parser at https://github.com/indieweb/php-mf2/issues"
        ]
    }
}

[sknebel]

Proposed resolution per IRC discussion right now: Following the example of #36, replace

if no explicit "photo" property,

with

if no explicit "photo" property, and no other explicit u-* properties, and no nested microformats,

[tantek]

Resolution: proposal accepted.

No objections in above discussion, and positive opinions (👍) from three implementors on the proposal.

Proposal implementation in mf2py per https://github.com/microformats/mf2py/issues/135 is sufficient to demonstrate implementability.

Editing specification accordingly.

(Originally published at: http://tantek.com/2018/358/t2/)