Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

"value" of nested microformats when no matching property exists #151

Closed
sknebel opened this issue Mar 14, 2018 · 1 comment
Closed

"value" of nested microformats when no matching property exists #151

sknebel opened this issue Mar 14, 2018 · 1 comment

Comments

@sknebel
Copy link
Member

sknebel commented Mar 14, 2018

When a nested microformat is parsed, the spec says to set the value property as such:

if it's a p-* property element, use the first p-name of the h-* child
else if it's an e-* property element, re-use its { } structure with existing value: inside.
else if it's a u-* property element and the h-* child has a u-url, use the first such u-url
else use the parsed property value per p-,u-,dt-* parsing respectively

The last step does not seem to be done for p- and dt- properties. (before the recent changes, there always was an implied name, so this happened less often)

I noticed this on http://pin13.net/mf2/?url=https%3A%2F%2Faaronparecki.com%2F2018%2F03%2F14%2F3%2F, where the "location" now has an empty value (admittedly, due to the weather being in there it wasn't great before either)

small test cases:
dt-

<div class="h-entry">
<div class="dt-dummy h-dummy">1997-12-12</div>
</div>

Output:

"properties": {
                "dummy": [
                    {
                        "type": [
                            "h-dummy"
                        ],
                        "properties": {
                            "name": [
                                "1997-12-12"
                            ]
                        }
                    }

The nested object has no value key at all!

p-

<div class="h-entry">
<div class="p-dummy h-dummy"><span class="p-kill-implied-name">foobar</span></div>
</div>

Output:

 {
            "type": [
                "h-entry"
            ],
            "properties": {
                "dummy": [
                    {
                        "type": [
                            "h-dummy"
                        ],
                        "properties": {
                            "kill-implied-name": [
                                "foobar"
                            ]
                        },
                        "value": ""
                    }
                ]
            }
        }

empty value, where it should be foobar.

u- work correctly.
@gRegorLove
Copy link
Member

gRegorLove commented Mar 15, 2018 •
edited
Loading

EDIT: @tantek answered in chat:

No it’s not the same. Because there’s explicit p-* markup around the whole thing. Therefore that’s author / publisher intent

I'm working on this currently. I have it working for dt-.

For p- I'm wondering if this is the desired effect. It basically brings back the issue of messy implied p-name, but in the nested microformat's value instead.

For @aaronpk's post the location h-adr value would be:
Portland,\r\n Oregon\r\n \r\n \u2022\r\n \r\n 44\u00b0F

Should this be a spec clarification? Perhaps something like:

if it's a p-* property element, use the first p-name of the h-* child or empty string if no p-name of the h-* child

gRegorLove added a commit to gRegorLove/php-mf2 that referenced this issue Mar 15, 2018
@gRegorLove
Add tests and fix for microformats#151
08952f7
@gRegorLove gRegorLove mentioned this issue Mar 15, 2018
Merged
aaronpk pushed a commit that referenced this issue Mar 15, 2018
@gRegorLove @aaronpk
Add tests and fix for #151 (#152)
8a7db43 
* Add tests and fix for #151

* Re-commit combined tests without the whitespace changes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@sknebel @gRegorLove