petermolnarI need some CSS help: apparently my footnotes link look different on Chrome, as they are not inline but number. [gap line] [link in next line] and I have no idea why
voxpelliMarkdown over Micropub isn't really possible – right? One either transfer plain text or HTML and the plain text should be exactly that, not some kind of hidden format like Markdown – right?
voxpelliIf one were to transfer Markdown over Micropub, then one would really have to do it the same way as HTML is transferred, right? And explicitly define it as being Markdown?
voxpelliaaronpk: but how do a server know that the client intended it to be markdown or plain text? an endpoint that treats all plain text as markdown will have a hard time with clients that doesn't send markdown'
voxpelliI guess eg. OwnYourGram sends plain text – an endpoint that would support markdown in plain texts would then all of the sudden start parsing OwnYourGram notes as markdown then?
voxpellias markdown can require some text to be escaped to be presented correctly and that text will appear incorrectly if not sent through a Markdown processor it would be hard for a Micropub client to support both Markdown and non-Markdown endpoints with the same content
voxpelliMy decision was to convert my Markdown to HTML, send it as supported mark up over Micropub and then if I wanted to save it as Markdown in my endpoint as well, so that the data was always transfered in standard markup
voxpelliI'm also not sure what the strict advantage would be to support alternative markup languages over Micropub – wouldn't it just be better if everyone used HTML?
voxpellisebsel: so if you connect to OwnYourGram and add a typical Instagram post that's just hashtags all over, then you will get a somewhat unexpected result ;)
voxpellisure, if both you and a micropub client both support markdown, then that wouldn't be necessary, but you would still need to do it if you would want to support clients that save HTML-content, right?
sebselvoxpelli I don't use OwnYourGram, but had the problem with import, yeah. For the script I only check "#<space>", not just "#". And I have a pre-markdown filter, which converts hashtags to links (and categories), so I don't have the problem anymore.
sknebelcurrent state (I think) is "Markdown is a plaintext format, a client that just can edit any plaintext can edit markdown, if you want to make a markdown specific client take care to only use it with endpoints that do markdown when you give them plain tex"
LoqiMarkdown is a way of writing and interpreting plain text so that it can optionally be converted to more explicitly meaningful or richly styled text (e.g https://indieweb.org/markdown
voxpellisknebel: but that means that either an endpoint will have to treat everything as markdown or nothing as markdown and that will, if markdown gets popular, that all clients will have to expect their plain text to be handled as markdown
aaronpkAlso just keep in mind your backend doesn't have to store everything the same. My posts are stored in either plaintext, markdown, or HTML, and there's a property on the post that indicates the content type
sknebelaaronpk: since that was where I got stuck, is there a decided way to indicate support for micropub extensions in queries? when posting I can check the query-endpoint for a special value to discover server support and then use an mp-… property, but while querying?
voxpelliaaronpk: but how do you know when to save somethingas plain text or markdown if it's not indicated – how do you know when a "*" is meant to be interpreted as Markdown or not?
voxpelli(if one would standardize support it would probably make sense to standardize on CommonMark as Common Mark tried to standardize all the different Markdown variants)
voxpelliSo if I always interpret plain text as markdown and then try to post a code snippet as a note in Quill I will get something very unexpected at my site unless Quill escapes the code so that it's Markdown compatible
[aaronpk]I haven't actually found it necessary yet, I either post text notes or HTML from quill and if I'm writing a markdown post I usually am writing it by hand in my storage
voxpelli> After the next version of the Micro.blog iOS app ships, Micro.blog will start requiring Markdown and escaping HTML tags from Micropub, just as it currently does from the web interface.
voxpelliIf that's where he wants to go I'm failing at pointing him in a good direction – I don't think plainly sending markdown as plain text is a good long term solution
[aaronpk]Do you know if he's actually using the HTML feature of Micropub or is he incorrectly not currently escaping HTML tags sent in Micropub plaintext requests?
voxpelliI haven't looked either, but I think it's just text from the app – there are no formatting possibilities at all there (apart from maybe Markdown)
voxpelliit do highlight the fact that one may want to indicate to eg. Quill that one doesn't support HTML at all and/or be able to communicate to Quill when an unsupported HTML-feature is used
voxpelliand actually be preferable I think – if one could whitelist eg. links, bold, italic but communicate that everything else if forbidden, then that should work for most scenarios
[aaronpk]The trick with the capability indicator is id want that to be optional and an upgrade thing, so that someone building a server doesn't have to build that just to get going
voxpellione problem I noticed is that in https://www.w3.org/TR/micropub/#html-content it says that unless the content is HTML a string should always be returned, and in the case of eg. markdown or some other data extension (like languages which we have talked about) it would still have to be an object
sknebeland for querying the question is how to indicate support in the query. if mp-… can be used as a command for queries it could just be an added mp-<magic word>=true
sknebelvoxpelli: yes, I only thought about a general way of doing it and offering a list, since I'd be fine with just a dropdown on the client to choose how my text is interpreted serverside. then defining a specific name to use for e.g. commonmark is just a tiny extra piece
voxpellisknebel: I'm thinking that commonmark won't be a custom format that needs any description text etc but rather a standardized format that all who supports it already knows what it is
sknebelso everything gets an id and a text and people then can say "ok, we will always give commonmark the id "commonmark" and that's commonmark support standardized
voxpelliUnless you want it to also support fully custom formats, like me doing a VoxPelliScript for my posts and me wanting to expose that custom format to Quill etc, then any possible future format could just do the same thing as commonmark does and everyone supporting that would know what it is as well
sknebelvoxpelli: of course, but that doesn't matter IMHO. point is, I'd want to have a description text for fully custom formats, and commonmark then can just a be speical case of that
sknebelvoxpelli: well, I don't care about commonmark and want custom formats with a note what they exactly were, so that's why I choose that design. one could of course say "if it'sjust a string, that's the id" and thus allow giving just well-known ids instead
voxpellisknebel: yeah, sounded like we were proposing the same thing initially, but now I see that we aren't so we have two different use cases to solve and then maybe two different designs that needs dogfooding and proof :)
[aaronpk]voxpelli: we originally had just a string for syndicate-to and then changed it to id/name because we realized clients would want to show more friendly text
voxpellisknebel: you want to be able to select a format in an editor, I just wants a client to know whether it can send markdown to an endpoint or not and react to that however it choses
voxpellisknebel: HTML is already supported as an explicit format, no reason markdown can't as well, and no reason custom formats can't be supported if markdown is supported explicitly as wlel, so they can both be proven and implemented individually
voxpellisknebel: I would be very hesitant to support custom formats as top level keys, so that eg. a "formats": ["random-id"] would be used as: "content": {"random-id": "value"}, as the values of an object can be extended by other extensions – adding eg. language support etc
voxpellisknebel: so then the design would have to be something like "content": {"value": "text", "format": "random-id"}, and that looks much more verbose than "content": {"markdown": "text"}
voxpelliif the key in the content object should be a top level key, then it should be standardized and documented so that other extensions can know whether its reasonable to expect a conflict with an existing name or not. Arbitrary keys should not be put in there, such values should be limited to values
voxpellito me it doesn't as it shows how the custom formats are a more complex solution than just standardizing markdown/commonmark as a new format on the same level of the existing html format + to define a mechanism for discovering which such formats athat are supported
sknebelbut custom formats also is just a mechanism to discovering which formats are supported and then sending some indication which of those formats you want?
sknebeland if you say that saying "format":"markdown" isntead of "markdown":"text" is noticably "more complex" then I guess we just have to disagree on that
sknebel(I'd probably be fine with putting the arbitrary keys in the content object, if a server operator creates a conflict with another extension there that's their problem and one they can easily solve
voxpellisknebel: one maps to the existing style of html, the other constructs a new style, and such a new style needs to have a reason for it, and I'm just saying that proving and dogfooding that can be separate from finding a solution to supporting markdown
sknebelsince new keys can only happen there if a server supports it, and the server is the authority on the list I think it'd be tolerable, but agreed that avoiding it is better
voxpelliI mean: The javascript standard had to change contains() to includes() for checking a value in an array just because Mootools or something had claimed contains() way back, so compatibility would break with all those sites otherwise
sknebelit only becomes a problem if said server wants to support a conflicting extension as well, and then they'll can easily rename their special format if it's really just one server. and if its more than one they totally should "reserve" that name as a "micropub extension"
voxpelliBoth suggestions has merits and both needs to get implementations and traction and if custom formats gain traction in such a way that it makes sense for markdown to use it, then great, otherwise it feels like the markdown case on it own isn't enough to justify a full custom formats feature
sknebeland if people work out different ways of doing markdown and doing custom formats, now everyone who wants to support both (clients and servers) has to handle both cases
tantekmiklb `**bold**` and `*italic*` is one of the dumbest things in markdwon, because nearly no one did that in plain text before it got added to markdown, violating the first principle of markdown
tanteklol, if you have to give a separate id or "type" for Markdown "content" then your markdown has failed. it's supposed to "just work" as plain text
singpolymamarkdown is what I turn HTML emails back into so I can read them. works about 60% of the time (when there aren't tables-in-tables-in-tables for layout in the html)
sknebel(pretty sure the ** and * were in reStructuredText as well, and I think even it's predecessor Structured Text. but yes, no need to reheat that particular discussion)
voxpellitantek: the issue isn't that Markdown doesn't work as text, the issue is that text doesn't necessarily work as Markdown, so you need to be sure that someone doesn't interpret something as Markdown when they are not intended to :/
tantekmiklb lol fair. I'm postponing the greater markdown battle for now, more important things to build first. In the mean time I'll just keep replacing my own need for md with an ever enhanced autolinker
voxpellitantek: the page as a whole? I just found it and felt that was the correct place to but a brainstorm, haven't really looked at the other stuff there
tantekvoxpelli: no I mean just load the page from the top and start reading. besides the overlapping text, it just immediately deep dives into very detailed issues without any overview
voxpellitantek: yeah, feels like some suggestions was moved over there to be able to close down issues in GitHub, like eg. my user-facing error ones, could be that it was done in a hurry and then haven't gotten a makeover
tantekaaronpk I'm still confused by what problem is being solved by explicitly typing commonmark, rather than just, on your server, treating your "plain text" as markdown
LoqiAn autolink is a hyperlink that was automatically added to some text to link that text to an obvious or useful destination, like hyperlinking a URL in plaintext to the URL itself, linking hashtags to search results, and @-names to their profile pages https://indieweb.org/autolink
LoqiAn autoembed is an embedding of media, typically of an image or video, that was automatically added from a URL to that media, to provide immediate viewing and or direct interaction with that media https://indieweb.org/autoembed
voxpelliI think most developers who have ever forgot to escape a piece of code when writing Markdown can relate to that example, so it's very much real
tantekvoxpelli happens to me in like ~50% of my github comments (seriously) and it just makes me that much more critical of markdown and wanting to avoid ever depending on it
voxpellitantek: totally, this issue is mainly about avoiding Markdown becoming the unofficial standard of plain text data in Micropub by making support for it explicit rather than implicit
voxpellitantek: as it was triggered by Micro.blog thinking about moving to 100% Markdown and me then thinking that wow, this will cause issues when using it with eg. Quill to send notes such as in that example
tantekaaronpk said "markdown started as that, and has changed" - and I feel like we really need to name those two differently so we can talk about them specifically rather than the whole family history of markdown
kodfabrik.seedited /Micropub-brainstorming (+92) "/* Additional data formats */ Restructure + add criticism section to encourage documentation of criticism against additional data formats" (view diff)
[kevinmarks]if manton is going to converge on a variant he should pick one and name it accordingly. Using commonmark makes sense to me, as it is not specified to be ambiguous, unlike Gruberian markdown.
tantekmiklb, I am particularly interested in your opinions of HTML, and especially in the context of "what has been lost". We may have more in common there than not. I have long term "HTML: The Good Parts" (book) draft I'm working on.
gRegorLove Indeed
www.boffosocko.com edited /Indieweb_for_Education (+340) "article: A Domain of One's Own in a Post-Ownership Society" (view diff)
@markku Interesting approach to online social discussions that isn't limited to a platform or technology. https://allinthehead.com/retro/378/implementing-webmentions (twitter.com/_/status/889775868775616512)
petermolnar !tell tantek re "zip in zip" 42.zip -> http://www.unforgettable.dk/
[kevinmarks] Aaron can call his zip in zip structure a zipblockchain and get vc funding
Zegnat petermolnar: http://imgur.com/XBv7IdR
sebsel petermolnar Zegnat Chromium seems fine, but, sorry, Chrome not. https://seblog.nl/temp/media-endpoint/2e61b5-chrome.jpg
@MetrotechsInc Implementing Webmentions - https://www.metrotechs.net/implementing-webmentions/ (twitter.com/_/status/889835248552476672)
@riteart #Implementing Webmentions http://rite.ly/jz1g https://twitter.com/riteart/status/889837526130843648/photo/1 (twitter.com/_/status/889837526130843648)
voxpelli I was triggered by this discussion with Manton and his thoughts on moving to a 100% Markdown Micropub + escaping HTML: https://twitter.com/voxpelli/status/889840961265827840
@voxpelli @manton2 But how will you be able to transfer Markdown over Micropub? Micropub data is either plain text or HTML? How will you indicate its Markdown? (twitter.com/_/status/889840961265827840)
Loqi Markdown is a way of writing and interpreting plain text so that it can optionally be converted to more explicitly meaningful or richly styled text (e.g https://indieweb.org/markdown
loqi.me created /IndieWebCamp_Dortmund (+66) "prompted by sknebel and dfn added by sknebel" (view diff)
@drewm Refactored my webmention likes and reposts to use a facepile. https://allinthehead.com/retro/378/implementing-webmentions (twitter.com/_/status/889856605910687744)
[miklb] hmm. So [this idea](https://example.com) needs to be treated differently than [thought] https://example.com (idea)
kodfabrik.se edited /Micropub-brainstorming (+1717) "Adding initial brainstorm about additional data formats" (view diff)
tantek aaronpk, as long as it is a mess like https://chat.indieweb.org/dev/2017-07-25/1500996683064000
singpolyma markdown is what I turn HTML emails back into so I can read them. works about 60% of the time (when there aren't tables-in-tables-in-tables for layout in the html)
aaronpk first version of the page: https://indieweb.org/wiki/index.php?title=Micropub-brainstorming&oldid=15180
[grantcodes] what is nanopub?
ascraeus.org created /nanopub (+164) "Created page with "[https://github.com/dg01d/nanopub Nanopub] is a micropub server for use in static blog engines, written by [https://indieweb.org/User:Ascraeus.org Daniel Goldsmith]"" (view diff)
@molovo I’m about to tweet a post to test webmentions. I’d appreciate a few likes/retweets/replies so I can make sure they work. Thanks folks (twitter.com/_/status/889935695900442624)
@DavidDarnes Interested to see if @molovo can get webmentions working on his Jekyll site, testing by sharing this! https://molovo.co/writing/getting-it-wrong/ (twitter.com/_/status/889941754115485701)
tantek.com edited /Loqi (+965) "/* IndieWeb x Loqi Dominate the Day */ add responses for a few" (view diff)