adding h-* to an e-* property loses the "html:" key
tantek opened this issue · 3 comments
Compare how it parses:
<div class="h-entry"><div class="e-content"><p>Hello</p></div></div>
to how it parses:
<div class="h-entry"><div class="h-card e-content"><p>Hello</p></div></div>
Note that in the second example the "html:" key inside content is lost for no reason.
Expected result:
{
"items": [
{
"type": [
"h-entry"
],
"properties": {
"content": [
{
"type": [
"h-card"
],
"properties": {
"name": [
"Hello"
]
},
"html": "<p>Hello<\/p>",
"value": "Hello"
}
],
"name": [
"Hello"
]
}
}
],
"rels": {}
}
Working on adding this now, where exactly is this made explicit in the parsing spec though? Reading through http://microformats.org/wiki/microformats2-parsing I cannot see where this is specified, unless it was missed out from "else if it's an e-* property element, re-use its { } structure with existing value: inside". Should that line read "else if it's an e-* property element, re-use its { } structure with existing value: and html: inside"
I also find the “re-use it’s {} structure” language here a little problematic. Reading the spec it appears to suggest that parsing <div class="h-entry"><span class="p-author h-card">Author Name</span></div>
should result in a h-entry microformat structure with two values for the author property, a string (from the “parse a child element for property class names” step) and also a child microformat (from the “parse a child element for microformats” step). This is of course not the case. I find the parsing spec as it is currently written confusing because of this.
@tantek out of interest, can you remember if there was a real world example which prompted this? I’d be interested to see if if so.