#microformats 2019-09-29

2019-09-29 UTC
KartikPrabhu, nitot, tsrtiv^, NeroprojektDisco, vendan and jgmac1106 joined the channel
#
jamietanna[m] Reposting from #indieweb:
#
jamietanna[m] [indienews] New post: "Proposing a Microformats2 Markup for Licensing Information" https://www.jvt.me/posts/2019/09/28/microformats-licensing/
#
aaronpk jamietanna[m] minor nit on that post, you probably want to add a property like "u-license" or "p-license" in addition to the new h-license you're proposing
#
aaronpk So it'd be class="p-license h-license"
#
jamietanna[m] Aaronpk oh yes, good shout
#
aaronpk check out the difference in the parsed result after adding that
[frank], [aaronpk], nitot, [schmarty], [Rose], [tonz] and [tantek] joined the channel
#
[tantek] dougbeal no with h-event. there's a barely supported RDATE property in hCalendar that has some support (H2VX)
#
[tantek] problem is the syntax is very obtuse, so not something that feels dependable to standardize
nitot joined the channel
#
[tantek] jamietanna - interesting h-license brainstorm. I think it's a good exploration. Only suggestion I have is to try starting even more minimal, e.g. *only* adding a u-license property to the URL of the license that applies to the containing h-* object. That may be enough to work for the consuming code scenarios of most of the use-cases you've documented
#
[tantek] and it's a lot less work for publishers and consumers to only deal with a single property u-license
#
[tantek] nice thing is, if there are more complex needs to express licensing information beyond a URL, the use of u-license can be expanded with "u-license h-license", similar to how we use u-in-reply-to and then optionally extend it with h-cite e.g. "u-in-reply-to h-cite"
#
jamietanna[m] OK, interesting. I was thinking about using the SPDX ID as that's a unique identifier we can use for identification, but agreed that a u-license is more web-oriented idea
#
jamietanna[m] As I say, my main use case (and that others see too) is that there can be multiple licenses for things within an h-*
#
[tantek] multiple licenses can be indicated with multiple u-license properties
jgmac1106 and [jgmac1106] joined the channel
#
jamietanna[m] sure. what do you think a license for a specific image could look like?
#
jgmac1106 jaimetanna maybe somethign like this: https://gist.github.com/jgmac1106/2e7110cef5d41e00978151da90e03c19
#
jgmac1106 without the spelling errors
[Rose] joined the channel
#
[tantek] there's nothing about that markup that makes it clear that the license is for a specific image vs the entire h-entry
#
[tantek] maybe discuss the approach first rather than jumping to code?
[jgmac1106]1 joined the channel
#
jgmac1106 well my assumptions would be mutliple images on the page , just fooling around I just stick stick different licesenses in my footer to give people different place to ignore them
[Lewis_Cowles], AceFaceDiscord[m, mrcatmann, jgmac1106, [jgmac1106] and [tantek] joined the channel
#
[tantek] multiple images like a multiphoto post?
[frank], [grantcodes], [schmarty], nitot, jacki, [mapkyca], [aaronpk], cheim, jgmac1106 and [jgmac1106] joined the channel
#
[jgmac1106] yeah like a gallery page
#
[jgmac1106] just following the pattern of people nesting collection of images in an h-entry, in that scenario and using rel=license couldn't each photo have a different license?
jgmac1106 and [Marten] joined the channel
#
Zegnat It could. I am just not sure wrapping every image you post in its own h-entry is something people are likely to do. Most of the time I would not personally treat singular images within a post as their own posts
[grantcodes] joined the channel
#
[grantcodes] I kind of do as collections. It means each photo has it's own url that people can respond to, and have a separate title, description, location etc. But I don't think there is anything that does a good job of consuming that. So I also mark it up as a multi photo post which work in readers and whatnot
#
jamietanna[m] What format should a Microformats2 datetime be? Conversation I had earlier at IWC Amsterdam about it with schmarty, based on https://tantek.com/2019/275/e1/homebrew-website-club-sf which is not (to my knowledge) an ISO 8601 timestamp. Is this something we've defined, or is it likely to be different formats that we need to account for?
#
jamietanna[m] https://php.microformats.io/?url=https%3A%2F%2Ftantek.com%2F2019%2F275%2Fe1%2Fhomebrew-website-club-sf shows it as `2019-10-02 18:30-0700` with a space instead of a `T` and not with seconds
#
Zegnat I think we have always been pretty liberal in what is accepted. I think some people have dt-bday without a year, for instance.
#
Zegnat Personally I stick to using timestamps defined by the HTML specification whenever I use <time datetime>
#
sknebel jamietanna[m]: that's a valid timestamp according to HTML
#
sknebel IMHO, you should be prepared to handle what can be in a HTML datetime attribute (of course as long as it makes sense for your application - a yearless date makes sense for a birthday, but porbalby not for dt-published)
#
jamietanna[m] Gotcha, ok. Hugo wants a rigid ISO 8601 format, so I'd need to do something to convert that date to a format that's usable, ta
#
Zegnat Now I wonder if the HTML spec defines what 18:30 means. Whether that means 18:30:00 or is actually defined as only being precise to the minute
jgmac1106 joined the channel
#
sknebel it specifies it as :00 seconds, strictly speaking
#
jamietanna[m] I thanks, I was digging through the spec to see
#
jamietanna[m] *ah thanks
#
KartikPrabhu what happens to miliseconds!!??
#
sknebel seconds can be a a non-integer
#
jamietanna[m] I guess they are also converted to 0 unless specified?
#
KartikPrabhu all this artificial precision!!
#
sknebel !!!!11
#
sknebel :P
#
Zegnat miliseconds are not converted to 0, in that there is no miliseconds part of time. Just fractional seconds, and seconds default to int 0
#
Zegnat Also, can only have up to 3 decimals on those seconds
#
jamietanna[m] ah ok. I think I may just error out for now if the date format isn't liked :joy
#
sknebel (I know some people here prefer to not imply seconds, and I think that typically makes sense, especially since it's mostly display purposes - If a source doesn't give you seconds, it's typically fine to not display them instead of saying "ok, but they mean :00, so I'll show :00.0000 :D)
#
jamietanna[m] * 😂
#
jamietanna[m] It's only for my Micropub
#
Zegnat That is 1 0 too many after the decimal separator, sknebel ;)
#
Zegnat https://html.spec.whatwg.org/#yearless-dates - looks like yearless bdays are OK?
#
sknebel yes
#
sknebel but might not make sense for your specific application
#
sknebel Zegnat: does it limit the number of digits after the dot?
#
Zegnat Yes, to 3
#
sknebel indeed
#
Zegnat Interesting enough: parsing does not put a limit on it
[frank], [Rose] and [tantek] joined the channel
#
[tantek] ISO 8601 allows all kinds of varying levels of precision. It’s bad/lazy specs/libraries that insist on artificial precision
#
[tantek] Eg the W3C datetime note is crap
#
jamietanna[m] 👍️ fair enough!
nitot, [aaronpk], [schmarty], [tonz] and jgmac1106 joined the channel
#
Zegnat Thank you time-questions. I have opened some issues towards how HTML describes seconds and their fractions: https://github.com/whatwg/html/issues/4948 https://github.com/whatwg/html/issues/4949
KartikPrabhu, [sebsel], [aaronpk], cheim, [jgmac1106], nitot, bitwinery, ivc, jgmac1106 and galaxie joined the channel