#microformats 2017-09-23

2017-09-23 UTC
KartikPrabhu, tantek, [miklb] and [kevinmarks] joined the channel
#
[kevinmarks] It's time to be polite about microdata again?
#
Loqi [kevinmarks]: tantek left you a message 1 week ago: for your review: http://microformats.org/wiki/h-feed#Parser_Compatibility
sebsel joined the channel
#
Zegnat Ah, glorious waking up to work on https://github.com/microformats/microformats2-parsing/issues/10 :D
#
Loqi [Zegnat] #10 u- parsing should always do relative URL resolution
#
Zegnat What made this issue reemerge now?
nitot_ joined the channel
#
sknebel Zegnat: https://chat.indieweb.org/dev/2017-09-22#t1506097367721000
#
Loqi sknebel: tantek left you a message 19 hours, 53 minutes ago: would appreciate your opinion on https://github.com/microformats/microformats2-parsing/issues/4 also
#
Loqi [tantek] [barryf]: looking at the diffs - I've never seen "hidden" used on an <a href> before - is that valid and customary practice somewhere?
#
Zegnat Aaah, thanks for the context sknebel. Somehow I missed that in the logs.
#
Zegnat https://github.com/microformats/microformats2-parsing/issues/9 is marked as a blocker for 10 now. And I am still not 100% clear on what the best solution for it is :(
#
Loqi [sknebel] #9 "return the normalized absolute URL" for invalid URLs?
#
sknebel commented on 10 and 4
#
Zegnat Will check in a bit, brewing tea
#
Zegnat I think your comment on #9 makes a lot of sense sknebel. And is less of a BC break than not returning any value for invalid URLs.
#
Zegnat The implied TZ comment on #10 indeed points at a problem. Floating times (without TZ) will become impossible if a TZ is included on dt-published.
#
Zegnat sknebel++ for saying it all
#
Loqi sknebel has 5 karma in this channel (58 overall)
trendynick joined the channel
#
Zegnat Or, if the TZ argument only applies to dt- from VCP, you could still mix floating and non-floating timestamps. But that would introduce yet another part where VCP diverts from non-VCP times.
davidmead, gRegorLove and [benjamin] joined the channel
#
[benjamin] coincidentally, I came in here to ask—is microdata still being used widely? specifically, does anyone know whether schema.org’s WebSite is worth using to mark up my site?
#
[benjamin] I could simplify my site a little bit if I decided that that microdata wasn’t worth including
#
[benjamin] but I do love that sweet, sweet google placement
#
aaronpk IMO the only reason to use microdata is to use the very specific vocabularies that google explicitly recommends for their fancy display of things. also know that they are likely to change their recommendations again in a couple years based on historical precedent.
#
aaronpk so basically plan on chasing the google recommended markup if you want to always support the new search result stuff theyr'e doing
#
[benjamin] yeah, that was sort of the impression I got
#
[benjamin] I guess I’ll check their docs to see whether they’re actually using `WebSite` data
#
[benjamin] ha! it looks like I had a grand total of two `itemprop`s on this entire page
#
[benjamin] the `name` was just the content of the <title>
#
[benjamin] and the `url` was… the URL
#
[benjamin] so I probably don’t need to keep that markup around
davidmead, gRegorLove and [kevinmarks] joined the channel
#
[kevinmarks] It's not supposed to affect placement, just the search result
davidmead, KartikPrabhu, [miklb] and [benjamin] joined the channel
#
[benjamin] ah, ok. then it’s completely unneeded in my case
#
[benjamin] how surprising, that #microformats talked me out of using microdata ?
#
[benjamin] (I kid)
#
[benjamin] suppose I’ve got blog entries in a structure like this:
#
[benjamin] ```
#
[benjamin] whoops, hang on
#
[benjamin] on my site, the page for an individual blog entry consists mostly of an <article> element. inside that <article> is a <header> with the post’s title and metadata, and following that is the actual post content
#
[benjamin] but there’s no single element that wraps the post content. but I need that if I’m going to use `e-content` from h-entry, right?
#
[benjamin] would it be more semantic to have only the post content wrapped in the <article>? or should I throw in a <div> or something?
#
aaronpk you will need a single element that isolates just the article text
#
aaronpk i think <article> is meant to wrap the whole thing including the header and such, so maybe try <section> for the text? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section
#
aaronpk o maybe not
#
aaronpk "A rule of thumb is that a section should logically appear in the outline of a document" yeah nevermind
#
aaronpk yeah i'd just use a <div>
#
[benjamin] yeah, that occurred to me but it seemed wrong for _the whole thing_ to be a section
#
[benjamin] thanks
#
Zegnat You could use <main>, if you believe in whatwg HTML
#
Zegnat WhatWG living HTML allows multiple <main> elements per document. I believe that should work for <article> content, as you mark-up its main content. Could maybe then put footnotes and stuff in an <aside> even.
[miklb] and [benjamin] joined the channel
#
[benjamin] is it possible to use the `content` of a <meta> tag as the value of a microformats2 property?
#
Zegnat It is not.
#
Zegnat I imagine <meta> is not in the spec to discourage hidden meta data. Though with the advent of <data>, I am not sure if there would be any harm in bringing <meta> in. Might be worth an issue.
#
[benjamin] hmm. some metadata *should* be hidden, I’d argue. my blog articles have summaries (for search engines) but I have no desire to add them to the page in a user-visible way
[kevinmarks] joined the channel
#
[kevinmarks] Meta gets hoisted AFAIK, so it would not be inside body
#
[benjamin] kevinmarks I’ve got `class="h-entry"` on my <html> element so I don’t think that’s the issue
#
[kevinmarks] You can try it, but I expect you'll get inconsistent behaviour from parsers
#
[benjamin] Zegnat: you can use <link> values in microformats2, right? it seems inconsistent not to allow <meta> too
#
[benjamin] although perhaps I should open an issue instead of trying to complain to you ?
#
Zegnat <link> is actually only parsed for their rel values, because mf2 parsers also function as rel-attribute collectors. They are not part of a microformat.
#
[benjamin] kevinmarks Is having `h-entry` (or whatever) on the <html> element not officially supported? or do you just mean that trying to put mf2 properties on <meta> might be supported by some parsers but not others?
#
[benjamin] Zegnat: ah, ok
#
Zegnat [kevinmarks], meta element is simply not included in the mf2 parsing spec. If you see any “inconsistent behaviour” from parsers those would be parser bugs
#
[kevinmarks] I mean that not all html parsers maintain the hierarchy. The python one varies depending on which parser library you use