oodaniis it legal for a micropub media endpoint to modify the file it receives before storing it, such as converting it to a different format? in particular, i'm pondering uploading .bmp files from a 3ds, which is incapable of converting to .png - would it be acceptable for the media endpoint to perform the conversion to .png instead?
oodanithe spec does say that the server is permitted to ignore the provided filename, but not whether it's allowed to ignore/change/whatever the provided file type
tantek__, cweiske, Ben6422, ski777715, ecx86, u1dzer029 and PlasmaStar6 joined the channel
Zegnatoodani, my personal feeling is that the media server should not convert things. What if I am uploading a .bmp file to use as an example in a blogpost about the 3DS? But it is an interesting usecase for sure. mmmmm
[grantcodes]I think converting formats would be fine, if it's an image and you return a url to an image file that will work in a src attribute, that shouldn't really cause issues.
ZegnatAccording to RFC 7231 it is perfectly valid to return a 201 Created status even if you have created multiple files (say: a bmp and png). The Location header should link to the “primary resource”, which I would say is the file the user was uploading (the bmp), but you are allowed to point at alternates (the png) in the same response.
ZegnatFor 300 Multiple Choices the RFC mentions using Link headers (with rel alternate) to point at other options. I see no reason you couldn’t do that for 201 responses too. Link headers can contain media types (e.g. image/png). It will then be up to the uploading application to see if it would rather use an available rel-alternate or the actual file it uploaded.
ZegnatYou could, maybe, even extend the Link header to include the `sizes` parameter (as seen in the HTML standard) if you want the server to tell the client it has already generated some thumbnails.
petermolnarI have a confession to make... I ditched server side syntax highlighting and went back to prism.js. The output of codehilite is sooooo verbose it boosted my pages with +60KB of text
ZegnatOr you can just pick the one that makes sense. The actual Micropub client is going to know best what the purpose of its current post is, [kevinmarks]
ZegnatWritten up a proposal for allowing Link headers, and included the basis I think it has in HTTP spec. Given the BMP&PNG example as well as the multiple image sizes example. https://github.com/w3c/Micropub/issues/113
jgmac1106well I got webmention endpoints, webmention discovery, and sinatra gems installed…think that is as far as I am going to make it today, still no app or views yet, but atleast all my gems in place…need a static site gem…
jgmac1106okay giving up for the day, trying to get my local dev environment going and ruby tells me my OpenSSL cert is out of date but everytime I run brew install openssl I am told I am up to date…I am both out of and up to date….that means kit kat break
[grantcodes]!tell schmarty Being the only other user of the PostrChild extension that I know of, let me know if you get the new version and it still works for you 🙂
Loqischmarty: [grantcodes] left you a message 57 minutes ago: Being the only other user of the PostrChild extension that I know of, let me know if you get the new version and it still works for you 🙂
[grantcodes]Hmm, yeah that might be difficult. If your micropub endpoint returns markdown from the source query it would get loaded into the editor, but the update request would wrap it with a `p` tag at minimum just now
[dougbeal], tantek__, jgmac1106, jackjamieson, [jgmac1106], eli_oat, [chrisaldrich], [cleverdevil], [Khurt_Williams] and chrisaldrich joined the channel
Loqi[google] data-transfer-project: The Data Transfer Project makes it easy for people to transfer their data between online service providers. We are establishing a common framework, including data models and protocols, to enable direct transfer of data both into and out of participating online service providers.
tantek__and a big opportunity for Bridgy to participate IMO, as importer and exporter on behalf of the user - or perhaps a different Bridgy-like service
ZegnatIt is not so much that images are being syndicated to Twitter. But if you put an image inside a post’s content, the plain text parsing of microformats2 will replace it with its alt text.
ZegnatTrying to keep the content complete in its plain text version. E.g. if you are including an image in a comment but the receiving site only displays plain text comments it might make more sense to show the proper alt value than to leave out part of your comment.
sknebel<a href="https://www.brid.gy/publish/twitter"></a><p class="p-bridgy-twitter-content" style="display:none"><meta property="og:image" name="twitter:image" content="https://dougbeal.com/wp-content/uploads/2018/07/hwc_558x558.png" /><img class="u-featured alignleft" src="https://dougbeal.com/wp-content/uploads/2018/07/hwc_558x558.png" alt="Homebrew Website Club Logo by Malcolm Blaney" />Homebrew Website Club - Seattle Area - August 8th
ZegnatStill, I think the solution is to move the images outside of the content property if you do not think they are supposed to show as inline-content.
ZegnatYou can probably move the <img class="u-featured"> to outside of the p-bridgy-twitter-content div and just give it a style="display:none;". I expect Bridgy will pick it up as the featured image of the URL, no need for it to be nested as it is.
sknebeland the image in the excerpt? then I think the answer for now is have the image with alt="", or use some other way to get u-featured on the image
ZegnatCould you use a picture element for the SVG and put the IMG to the PNG in there as fallback? Then you could add the featured class to the nested IMG for mf2 parsers to pick up on. Then you may be able to get rid of the special Twitter excerpt entirely?
ZegnatBridgy runs an mf2 parser. That shouldn’t have any issue finding the img.u-featured no matter where you put it. The trick is just to not give it an alt *and* put it inside .e-content if you do not want the alt as part of the page content :)
LoqiWelcome, heinrich599111. We've had an influx of IRC spam recently, and you were not yet recognized as a non-spammer. Your previous message wasn't sent to the channel, but I'm repeating it below so everyone can see it. You are now marked as verified, so your future messages will be sent as normal.