Gargron
https://github.com/Gargron
•
Jul 6
Yep I just discovered that. Could just remove those particular tests...
Posts with no CW would end up with just a content property. According to the new parsing rules, those look just like normal content-only posts and sites don't see a name property and treat them as normal text/microblog/toot/tweet posts.
A change in the Microformats parsing spec from a few months ago reduced the cases where parsers would auto-generate a name property if there wasn't one in the original markup.
Previously, when the name was autogenerated, people ended up having to add an explicit name property to the HTML in order to avoid weird broken-looking names. Now that this change is approved and implemented in a couple parsers, things are working a lot better. I believe the Ruby parser has not yet implemented this change, but it's in the Python and PHP ones.
Certainly one option is Mastodon could just remove the p-name class, since the newer parsers would end up seeing those posts with just the summary and content properties.
Since afaik no Microformats consumers have the concept of CW/spoiler posts yet, this does raise the issue of how to provide a good fallback behavior for consumers that don't understand spoiler posts. My thought with moving the p-name class to the same element as p-summary is that the current consumers will see it as an "article", most likely only showing the name of the article. Here's an example of how my site renders comments that have a name (whether or not there is also summary or content)
Similarly, here's what my site shows when I'm replying to a post that has a name:
If the p-name class is used only for the CW/spoiler preview text, then my site wouldn't show the full content in either the reply context or as a comment, which seems like the safest fallback behavior.
Jamey Sharp
https://toot.cat/@jamey
•
Jul 5
I want to build a quick little web site for a thing and I'm facing analysis paralysis over which programming language to write it in, augh 😠
Carl Hancock 🚀
http://www.gravityforms.com
•
Jul 5
DΛVID V3.0.5
https://davidwolfpaw.com/
•
Jul 5
Phew! After long awaited anticipation, I’ve built in a draft version of automated webmentions into my site, so now when I like and reply things from my Social Reader my site will send out a webmention immediately. No more 1-2 delays in my replies 😁🎉
cactus
https://github.com/cactus
•
Jul 4
go-camo was indeed originally intended to proxy only images, for two reasons: 1) the camo project it was inspired by only proxied images 2) my use-case at the time only required proxying of images
Later, a fork was created by a user to additionally proxy fonts and css. I wasn't comfortable including those in go-camo -- see discussion on https://github.com/cactus/go-camo/issues/20.
In my experience, video files are "usually" either linked (by url, no content warning), uploaded (service hosts it, so no content warning), or inlined from some hosting service (eg. youtube, vimeo; ssl provided by service). Video files are also generally much larger than image content.
Can you further describe your use-case/requirements for proxying video?
Ah, I can see why css/js could be an issue for some uses.
I'm using this on the server side of my new social reader application so that all image/video URLs presented to the reader apps are https and from the same origin. The videos come from either Instagram, Twitter, or peoples' own blogs hosting video files directly. Because the majority of the content is twitter-like short posts, the video files are normally always under a minute long so they aren't actually that big.
sknebel
https://github.com/sknebel
•
Jul 4
Looking at this again, I'm not sure what a good spot for a general note would be.
If you ok it I'd prepare a pull request adding the header to the examples?
At the very least adding the Accept header to the examples is a good place to start, go for it!
