btremThere are several cases where authors should or must must alt="". There are a few cases -- maybe not quite edge, but certainly unusual -- where the author can omit the alt attribute.
[jacky]and a compatible parser could _generate_ those hashes independently (a client-side parser that uses an hash algo compatible with a non-browser based one)
[jacky]> However the colons ":" separating the hours and minutes of any timezone offset are optional and discouraged. If the offset uses XX:YY format, remove the colon so it is XXYY format. Omitting the colon makes it less likely that a timezone offset will be confused for a time.
Loqi[preview] I mentioned before how this is a upstream blocker to get the Rust library fully compatible. That's changed but normalization would simplify the act of parsing (and testing) date values, thus me throwing my vote in favor of it and curious to hear if a...
[tantek]alright I've reviewed the comments on #4 #8 #12 and believe there are no objections except one from Zegnat which I think is mistaken about the impact of the changes described therein (all implied dates and timezones are scoped to properties in the same object. e.g. a timezone (or date) on a dt-* property in one object cannot affect / imply a timezone (or date) on a dt-* property in another object, and no one is mixing floating timezone and
[tantek]which means next step for these issues per the mf2 parser change control is "Encourage and get 1+ implementation(s). Encourage, get, and document 1+ implementation(s) of implementation affecting aspects of a proposed resolution, preferably with a test case if applicable."
[tantek]to be more clear, we already have "Encourage and get 1+ implementation(s)." on #4 and #8 so for those I need to do the next step "Resolve by implementation verified rough consensus" and write up a resolution on those and share that in #microformats
Loqi[preview] [gRegorLove] I found some more edge cases that this spec update should cover:
> * if the value has a specific ISO8601 date, time, and timezone, use those and stop looking for "value" elements.
```html
<div class="h-event">
<span class="dt-start">
<...
jkingwebI had been struggling how to understand how to fix some problems in the PHP parser, and in my quest to understand I ended up just writing a whole parser. 😛
[tantek]then I need to answer Zegnat's question/issue/concern, then wait to see if others agree (rough consensus), and then I think we can declare a Resolution on all three (#4 #8 #12) all at once and I can edit the spec accordingly!
[tantek]gRegor do you have a pref for whether the "T" is normalized to a space or not or the ":" removed from a timezone in the cases you noted in your comment I just linked ^ ?
jkingweb[tantek] Were you asking how I handle ISO 8601 date-times with "T" separator? The date is parsed into components and output with a space separator instead. I thought the VCP steps were clear in saying that you stop _looking_ for dates, not that you stop processing. The normalization steps are separate from the parsing steps (they're not in the bullet list), so they should be done in all cases.
jkingwebI'm in favour of omitting colons in zone offsets, too, by the way. My parser normalizes with colons currently, but only because it made more tests pass.
jkingwebRationale: it would cut the number of date/time formats downstream consumers of the JSON have to deal with from seven to five, with no loss of information.
btrem [tantek] There are issues specifically on alt="" and missing alt in the living spec.
[schmarty] possibly heavy but that seems like it would be effective!!
[tantek] Given the consistent support for this change, I believe there is the possibility of parsers taking the initiative with normalizing datetimes: https://github.com/microformats/microformats2-parsing/issues/12
gRegor jkingweb++ nice, didn't realize you had a parser. Add it to https://microformats.org/wiki/microformats2#Parsers! Let me know if you get any edit issues about adding external links