[tantek], KartikPrabhu, [chrisaldrich], [miklb], tantek, KevinMarks, nitot, strugee, webchat213, nitot_, barpthewire and [eddie] joined the channel
#ZegnatReading through the mf2 parsing brainstorm page it seems like every property except dt-* may be upgraded to an object at some later date?
#Zegnatu-* might result in {value:'',alt:''} on IMG elements, h-* and e-* in {value:'',lang:'',id:''} on elements with lang- and id-attributes, and p-* in {value:'',lang:''} as well (pronouns given as example).
#ZegnatAfter dinner I will also write up a brainstorm for adding mime / content type on u-*. This would give parity with jf2, JSON Feed, and OpenGraph for e.g. u-video.
#ZegnatI was hesitating because it would introduce another nested objects, but it seems like nested objects might turn into the norm for mf2? Is there some global reason against objects for property values that I am missing?
[kevinmarks] joined the channel
#Zegnatstarts a draft brainstorm while waiting on his pizza
tantek joined the channel
#[kevinmarks]It adds complexity, though them being optional does in another way. The original idea of the rel-urls was a way to get the properties of a u-* that had more info
#[kevinmarks]So rel-urls should have the content type in it already, if you use a rel.
#[kevinmarks]Maybe extend that to have entries for u- properties that don't have rels (ie the rels would be an empty list, but the hreflang, type, title and text could be populated)
#tantekZegnat, rather than parity with other formats, are there specific use-cases you have found with HTML markup with mime / content type on u-*?
#tantekparity with other formats is not necessarily a good way to design better formats. often time the opposite, it tends bring extra baggage that complexifies a format for no good reason (use-case)
[eddie], KartikPrabhu, [asteres], KevinMarks, nitot, tantek, [kevinmarks] and vivus joined the channel