[shaners][ben_thatmustbeme] Thanks! Would you mind transferring your forked gh repo to the mf org please? And then I’ll wire up the Heroku auto-deploy parts.
ZegnatgRegorLove interesting catch on the implied photo on h-app! aaronpk was there a reason why h-app uses a logo property instead of a photo property?
ZegnatAlso re: a discussion I just saw in #indieweb-dev about rel-icon `sizes` parsing in the mf2 parser; I brought that up completely separate from the indieauth client discovery thing. We include rel parsing in mf2, and if people want to use mf2 parsers to also parse link relationships it makes sense to me to not give them useless results (like a list of icons without a way to select the right one)
Zegnat“Users must have repository creation permissions within the receiving organization before they can transfer a repository that they individually own. If Allow members to create repositories for this organization has been disabled in the receiving organization, only organization owners can transfer repositories into the organization.”
Loqi[[shaners]] [ben_thatmustbeme] Thanks! Would you mind transferring your forked gh repo to the mf org please? And then I’ll wire up the Heroku auto-deploy parts.
ZegnatWell, if it is just to get node.microformats.io going again, that might not be the biggest problem? But then we should rename it not to advertise the repo as a standalone parser
ZegnatCool! That might warrant some looking into. If any actively developed project is using the parser, those are the people most likely to possibly start maintaining a fork
ZegnatBut as mf-shiv isn’t really getting updates at the moment anyway, I don’t know if it would matter that us updating tests may block Mozilla from updating mf-shiv?
ZegnatThat has just him writing it right? Not sure if that qualifies as a community project? Though we haven’t set any real guidelines for being included in the org yet, I thought something about that was mentioned
willnorris ben_thatmustbeme: regarding the go parser, I'm no opposed to moving it into the microformats org. The thing I care more about is the go import path. In go, import paths are effectively URLs, and use a "go-import" meta tag to point to the source control repo (e.g. view source of https://willnorris.com/go/microformats and search for "go-import"). This provides a level of indirection that would let us move the repo
willnorriswithout affecting the import path. Or alternately, we could change the import path to something under microformats.org, though with the recent instability of the site, I worry about that, since when the site is down, you can't easily install the package using `go get`. The thing I don't want to do is have an import path of "github.com/....", since that's just another form of sharecropping.
KartikPrabhusknebel: my original thought was that since it is a "breaking" change it should be under a flag and hopefully by v2.0.0 it will be in the spec
Loqi[kartikprabhu] as proof of concept, this has been implemented in experimental version of mf2py for **explicit** `u-photo` parsing.
## Example 0
```html
<div class="h-entry">
<p class="p-name e-content"><span>Hello World</span></p>
<img class="u-photo"...
willnorrisbehind a flag, but in the main released branch? I've been trying to figure out how to handle that... implementing proposed changes that have not yet been accepted. I was considering doing it in a separate, unreleased git branch. I don't yet have a great way to pass flags to the parser, though it wouldn't be hard to add
ZegnatThe problem is that we are forced to use a class instance just to get {} in the final JSON. PHP is weird in that there isn't a dictionary type we can use.
ZegnatWe may just want to see if we can't move the conversion to empty objects right before we json_encode. We might be doing it too early and it could come back to bite us later.
@stephaniehobson↩️ I remember microformats blowing my mind back in 2007. I'd like to have updated info on the state of microformats/microdata/schema and who and how they're consumed. (twitter.com/_/status/1032714998139650048)
KartikPrabhuthe include pattern is quite the anomaly because it it "non-local" i.e. depends on the entire document. It would totally fail if someone used a part of the HTML which is valid mf1 but the included bit is no longer in that part
willnorrisKartikPrabhu: it really is an anomaly. given that we can't seem to find any use of it in the wild, do we just remove the tests entirely? Is it worth specifically excluding from mf2 backcompat parsing? Or is that implied given that its never explicitly called out for inclusion?
KartikPrabhuwillnorris: I thought since it never is mentioned in backcompat it shouldn't be parsed. But I only found about the include-pattern a few days ago!