Time to change from HTML? March 5, 2020 8:21 AM Subscribe
I'm not sure if this has been discussed before recently, but are there any plans to change or add on text coding options beyond HTML? Like Markdown or rich text?
I've noticed that a lot more platforms (Slack, Reddit, Discord) are using Markdown instead of HTML. I even see people on Facebook trying it, which makes me think that they've become pretty used to doing that elsewhere.
I access Metafilter on mobile a lot and while I see the buttons for HTML tags it can get pretty clunky (especially for links - you paste the link in the pop-up, but then you have to make sure your cursor is in the right place when you write the link text. Other places that do this let you put in the link text in the same or another pop-up so I'm not sure why Mefi does it this way).
Also I feel like knowledge of HTML is going the way of the dinosaur, given that people aren't really handcoding sites as much and they're using CSS for formatting. We've talked before about making Mefi more inclusive and this small thing could be a barrier to entry.
I've noticed that a lot more platforms (Slack, Reddit, Discord) are using Markdown instead of HTML. I even see people on Facebook trying it, which makes me think that they've become pretty used to doing that elsewhere.
I access Metafilter on mobile a lot and while I see the buttons for HTML tags it can get pretty clunky (especially for links - you paste the link in the pop-up, but then you have to make sure your cursor is in the right place when you write the link text. Other places that do this let you put in the link text in the same or another pop-up so I'm not sure why Mefi does it this way).
Also I feel like knowledge of HTML is going the way of the dinosaur, given that people aren't really handcoding sites as much and they're using CSS for formatting. We've talked before about making Mefi more inclusive and this small thing could be a barrier to entry.
The usability of the formatting buttons (on mobile) is just abysmal. You don't need to completely overhaul how formatting is done technically to just make those buttons usable.
posted by bleep at 8:32 AM on March 5, 2020 [4 favorites]
posted by bleep at 8:32 AM on March 5, 2020 [4 favorites]
I agree that we're past the age of HTML
The Time of the Orc has come!
posted by thelonius at 8:58 AM on March 5, 2020 [5 favorites]
The Time of the Orc has come!
posted by thelonius at 8:58 AM on March 5, 2020 [5 favorites]
I would be 100% behind a Markdown option. Trying to use formatting on mobile is a hellish experience right now, up to and including either the browser or MeFi often auto-closing or trying to auto-complete things (god forbid you try to hand-type a close tag!).
posted by tocts at 9:44 AM on March 5, 2020 [4 favorites]
posted by tocts at 9:44 AM on March 5, 2020 [4 favorites]
Markdown would be nice and by default it already accepts html so the current buttons would still work.
The downsides include needing to implement and maintain additional markup support in comments, needing to train/support site members on use and pitfalls of that (a lot of Markdown stuff takes the form of common literal punctuation people use *not* expecting markup to be applied), sorting out whether and how to either firewall off new markup rules from the archives or cope with the effects of it applying retroactively, etc.
If you're set in maintaining html support, I'd parse the markdown and save the compiled html in the database as you're already doing. It wouldn't break the archives and any future user-formatting change would be easy to make since it's all html in the end.
In any case, please don't add WYSIWYG, it's possibly the worst thing Slack has done lately. A preview box is more than fine.
posted by simmering octagon at 10:01 AM on March 5, 2020 [5 favorites]
The downsides include needing to implement and maintain additional markup support in comments, needing to train/support site members on use and pitfalls of that (a lot of Markdown stuff takes the form of common literal punctuation people use *not* expecting markup to be applied), sorting out whether and how to either firewall off new markup rules from the archives or cope with the effects of it applying retroactively, etc.
If you're set in maintaining html support, I'd parse the markdown and save the compiled html in the database as you're already doing. It wouldn't break the archives and any future user-formatting change would be easy to make since it's all html in the end.
In any case, please don't add WYSIWYG, it's possibly the worst thing Slack has done lately. A preview box is more than fine.
posted by simmering octagon at 10:01 AM on March 5, 2020 [5 favorites]
This is a little bit of a derail, but on an iPhone the text box takes up the top half of the screen and the keyboard takes up the bottom half, and sometimes when I try to mark text in the box the screen scrolls upward. I noticed this when you guys increased the text box size but maybe I just started commenting more then.
posted by Huffy Puffy at 10:07 AM on March 5, 2020 [4 favorites]
posted by Huffy Puffy at 10:07 AM on March 5, 2020 [4 favorites]
I feel like this sort of thing is a very low priority compared with the community, diversity, sustainability and funding infrastructure work the site needs. And it's seductive, because it's wonky and there's always an argument for an upgrade and people can talk about it forever and ever and enjoy that conversation. It may be worth considering the ways in which tech talk serves as a distraction.
posted by Miko at 10:50 AM on March 5, 2020 [9 favorites]
posted by Miko at 10:50 AM on March 5, 2020 [9 favorites]
That is a pretty uncharitable reading of this request, to say it's a distraction. A better experience commenting on the site on mobile in particular is not exactly orthogonal to growing the community beyond the historically tech-focused, desktop computer focused crowd already here.
posted by tocts at 10:56 AM on March 5, 2020 [11 favorites]
posted by tocts at 10:56 AM on March 5, 2020 [11 favorites]
Gotta say that on mobile the distinction between the / button and the I button is not great. This might be a Classic layout issue though?
posted by EndsOfInvention at 11:00 AM on March 5, 2020 [3 favorites]
posted by EndsOfInvention at 11:00 AM on March 5, 2020 [3 favorites]
Miko: as a marginalised user of Metafilter who has been very, very vocal about the need for this site to be more inclusive, especially around race and non-US-ness, I would really appreciate it if you don't dismiss my post as a "distraction". Us marginalised folk can care about more than one thing. Even in the post itself I talked about the reliance on HTML knowledge being an access barrier, given how link-centric this site is.
If you're not marginalised yourself, your comment just comes off as white-knighty to the point of silencing.
posted by divabat at 11:10 AM on March 5, 2020 [10 favorites]
If you're not marginalised yourself, your comment just comes off as white-knighty to the point of silencing.
posted by divabat at 11:10 AM on March 5, 2020 [10 favorites]
There is a science forum where I participate a lot, where there are pre-Markdown posts, and post-Markdown posts, and it is clear which is which because of odd rendering problems with old posts, where new markup rules are applied uniformly to how the site is presented. All of which is to say that I like Markdown, like the idea, use markup like Markdown and reST everywhere for my job, but implementation of new formatting rules can be tricky when a site has a history of content. It might not matter so much for Metafilter, but for other forums where, say, you're looking up older content and formatting matters, it could be an issue to think about.
posted by They sucked his brains out! at 12:03 PM on March 5, 2020 [1 favorite]
posted by They sucked his brains out! at 12:03 PM on March 5, 2020 [1 favorite]
As an aside, and speaking of old, I just noticed that the "HTML help" page contains a Flash video. Ha.
posted by gwint at 1:08 PM on March 5, 2020 [5 favorites]
posted by gwint at 1:08 PM on March 5, 2020 [5 favorites]
Just noting that this is where a lot of MeFi energy has tended to go in the past, while other things went undone. More a note for owners than users.
posted by Miko at 1:34 PM on March 5, 2020 [9 favorites]
posted by Miko at 1:34 PM on March 5, 2020 [9 favorites]
I really just think it needs an easier way to make links (admittedly annoying on mobile). Thats the only formatting you really need at MeFi. The extremely-lightly-formatted nature of MeFi in general is something I like about it compared to most sites these days.
posted by thefoxgod at 1:50 PM on March 5, 2020 [13 favorites]
posted by thefoxgod at 1:50 PM on March 5, 2020 [13 favorites]
bbcode or bust!
posted by Literaryhero at 2:50 PM on March 5, 2020 [7 favorites]
posted by Literaryhero at 2:50 PM on March 5, 2020 [7 favorites]
I really just think it needs an easier way to make links (admittedly annoying on mobile).
Very much. Doing a link in a comment on a mobile is ... well, more times than not I've just given up and not commented. HTML is ugh no for this.
posted by Wordshore at 2:54 PM on March 5, 2020 [2 favorites]
Very much. Doing a link in a comment on a mobile is ... well, more times than not I've just given up and not commented. HTML is ugh no for this.
posted by Wordshore at 2:54 PM on March 5, 2020 [2 favorites]
If this is a poll, I *like* HTML, and I _dislike_ Markup.
posted by General Malaise at 3:31 PM on March 5, 2020 [10 favorites]
posted by General Malaise at 3:31 PM on March 5, 2020 [10 favorites]
I seem to remember a plugin that allows markdown for Mefi. What ever became of it?
posted by Obscure Reference at 3:42 PM on March 5, 2020
posted by Obscure Reference at 3:42 PM on March 5, 2020
The Markdown for MeFi plugin for Safari, Chrome and Firefox is still available on Github.
posted by mandolin conspiracy at 3:48 PM on March 5, 2020 [3 favorites]
posted by mandolin conspiracy at 3:48 PM on March 5, 2020 [3 favorites]
Hold my beer:
Provide a drop-down of supported format-type. On Post/Preview check that the body doesn't start with ESC. Store temorarily 'ESC;format;format-type;body'. On Preview/Edit, check for the ESC and if needed do the FormatTypeToHTML | StripHTML for what you display, set the pull-down appropriately and put the formatted text back in the edit box.
You need to keep this ESC code around during the EditWindow, but a cron job or something can go through new Posts/Comments and find the ones that can't be edited anymore and do a final Convert/Strip and store the plain-HTML without any ESC header.
Old posts/comments without the ESC are just HTML. Only the posts/comments still in the Preview/EditWindow need the special treatment. A single byte check for the ESC determines whether any sort of Convert/Strip needs to happen.
This could be optimized away for closed threads, posts older than the EditWindow (if you keep up with Convert/Strip for out of EditWindow things). Or just keeping track of the oldest post/comment that is eligible for special treatment (assuming that everything older has been Convert/Strip and stored as plain-HTML).
LivePreview would be borked for anything other than HTML probably, but it's sorta already borked. Turn it off for non-HTML format choice.
About the worst that this could get is a byte-check on comments before sending to determine if you need to Convert/Strip before sending. But even that should be able to be optimized by splitting the ordered comments and finding the possible ESC codes from the most recent comment back to the first non-ESC comment. But it's only a byte check and most comments would sail right by into direct sending.
posted by zengargoyle at 4:20 PM on March 5, 2020
Provide a drop-down of supported format-type. On Post/Preview check that the body doesn't start with ESC. Store temorarily 'ESC;format;format-type;body'. On Preview/Edit, check for the ESC and if needed do the FormatTypeToHTML | StripHTML for what you display, set the pull-down appropriately and put the formatted text back in the edit box.
You need to keep this ESC code around during the EditWindow, but a cron job or something can go through new Posts/Comments and find the ones that can't be edited anymore and do a final Convert/Strip and store the plain-HTML without any ESC header.
Old posts/comments without the ESC are just HTML. Only the posts/comments still in the Preview/EditWindow need the special treatment. A single byte check for the ESC determines whether any sort of Convert/Strip needs to happen.
This could be optimized away for closed threads, posts older than the EditWindow (if you keep up with Convert/Strip for out of EditWindow things). Or just keeping track of the oldest post/comment that is eligible for special treatment (assuming that everything older has been Convert/Strip and stored as plain-HTML).
LivePreview would be borked for anything other than HTML probably, but it's sorta already borked. Turn it off for non-HTML format choice.
About the worst that this could get is a byte-check on comments before sending to determine if you need to Convert/Strip before sending. But even that should be able to be optimized by splitting the ordered comments and finding the possible ESC codes from the most recent comment back to the first non-ESC comment. But it's only a byte check and most comments would sail right by into direct sending.
posted by zengargoyle at 4:20 PM on March 5, 2020
HTML 4 EVA!
posted by kevinbelt at 5:00 PM on March 5, 2020 [1 favorite]
posted by kevinbelt at 5:00 PM on March 5, 2020 [1 favorite]
This would be a very good thing. Maybe it it could be a profile option so people who like html can keep using it.
especially for links - you paste the link in the pop-up, but then you have to make sure your cursor is in the right place when you write the link text. Other places that do this let you put in the link text in the same or another pop-up so I'm not sure why Mefi does it this way
I really like the way the link button turns whatever text is selected when you click it into link text. It might be different on mobile, but writing metafilter comments on mobile is so exquisitely painful (for a number of reasons, but mostly html) that I rarely bother.
posted by A Thousand Baited Hooks at 5:01 PM on March 5, 2020
especially for links - you paste the link in the pop-up, but then you have to make sure your cursor is in the right place when you write the link text. Other places that do this let you put in the link text in the same or another pop-up so I'm not sure why Mefi does it this way
I really like the way the link button turns whatever text is selected when you click it into link text. It might be different on mobile, but writing metafilter comments on mobile is so exquisitely painful (for a number of reasons, but mostly html) that I rarely bother.
posted by A Thousand Baited Hooks at 5:01 PM on March 5, 2020
This isn't the *most* practical suggestion, but for iPhone linkers, you can set up text replacement for the HTML tags. When I taught myself to code a couple of years ago and I was still in the lightbulb phase where I'd want to jot down ideas I'd have, I created shortcuts so that typing "startphp" would go to "<?php " and "endphp" would go to "?>". You could do the same thing with the '<a href="' and '/a>' parts of the link, which would make the rest of the link creation fairly simple. Which, OK, yeah, that's pretty nerdy.
posted by kevinbelt at 5:06 PM on March 5, 2020 [2 favorites]
posted by kevinbelt at 5:06 PM on March 5, 2020 [2 favorites]
If you're set in maintaining html support, I'd parse the markdown and save the compiled html in the database as you're already doing. It wouldn't break the archives and any future user-formatting change would be easy to make since it's all html in the end.This makes sense to me. The posting system already does some parsing to strip unsupported html, close tags etc. so it *should* in principle be able to support some kind of simple markdown, right? (I've never looked at the site's source code so it may be a lot harder than it sounds, of course.) Even if it was just a simple way to add italics, bold, blockquote and links, like the way reddit does it.
posted by A Thousand Baited Hooks at 5:14 PM on March 5, 2020 [2 favorites]
Personally, I much prefer html. I already screw up the random markdown conventions on several message boards and four different wiki platforms daily. At least here there's a standard that has some connection to the rest of the world. But, I'd have no objection to both. Especially if it doesn't require escaping every third character in order to actually display them. (Slack and Reddit are perfect examples of how to implement it badly, if you ask me.)
posted by eotvos at 5:26 PM on March 5, 2020 [4 favorites]
posted by eotvos at 5:26 PM on March 5, 2020 [4 favorites]
If you're set in maintaining html support, I'd parse the markdown and save the compiled html in the database as you're already doing. It wouldn't break the archives and any future user-formatting change would be easy to make since it's all html in the end.
This is why you have to store the user chosen format at least until the end of the EditWindow. It's no good if you Preview/Edit and your chosen format is now only HTML and the text you typed is gone. Store the plain-HTML after the EditWindow has closed. No archive breakage needed.
posted by zengargoyle at 5:55 PM on March 5, 2020
This is why you have to store the user chosen format at least until the end of the EditWindow. It's no good if you Preview/Edit and your chosen format is now only HTML and the text you typed is gone. Store the plain-HTML after the EditWindow has closed. No archive breakage needed.
posted by zengargoyle at 5:55 PM on March 5, 2020
If you really wanted to, you could store something like:
ESC;rendered;the post as displayed.ESC;format;format-type;the post as entered by the user.
That would take some space, but varchar and all that. But it would also let the display phase skip the Convert/Strip cycle. Unless there is an Edit.
posted by zengargoyle at 6:01 PM on March 5, 2020
ESC;rendered;the post as displayed.ESC;format;format-type;the post as entered by the user.
That would take some space, but varchar and all that. But it would also let the display phase skip the Convert/Strip cycle. Unless there is an Edit.
posted by zengargoyle at 6:01 PM on March 5, 2020
I think it should be easier for people to make links in the mobile view of this site. I don't particularly care for Markdown but as long as HTML isn't going away (and I am confident it won't) it would be nice to see the site's usability improving.
posted by jessamyn (temp) at 6:07 PM on March 5, 2020 [9 favorites]
posted by jessamyn (temp) at 6:07 PM on March 5, 2020 [9 favorites]
I was a late adopter of smartphones and I don’t really have any problem making links on mobile. I just open the page I want in a tab, copy the URL, flip back to here, highlight the link text, click the button and paste. It seems like a lot of steps because it needs a lot of steps. Unless you’re typing the URL from memory they are all pretty mandatory, and a lot of the fiddly bits of tabs etc is really a mobile browser UI issue, not a MeFi issue.
Clearly I am a weirdo outlier but I thought I’d lodge my minority dissent. I even find the MeFi system easier on mobile than markdown (eg as used on Reddit) or Wiki markup.
posted by SaltySalticid at 7:59 PM on March 5, 2020 [7 favorites]
Clearly I am a weirdo outlier but I thought I’d lodge my minority dissent. I even find the MeFi system easier on mobile than markdown (eg as used on Reddit) or Wiki markup.
posted by SaltySalticid at 7:59 PM on March 5, 2020 [7 favorites]
This exact same proposal feels like less of a big deal to me if you don't think of it as supporting an alternate format, or even necessarily mention that it's markdown. Like what if I put it like this:
Would you like the option of having certain text in your comment converted to html automatically? On submit:
posted by john hadron collider at 8:08 PM on March 5, 2020 [2 favorites]
Would you like the option of having certain text in your comment converted to html automatically? On submit:
- *this* or _this_ would be converted to italics
- **this** or __this__ would be converted to bold
- [link text](url) would be converted to a link
- lines starting with - or * would be converted to an unordered list
- lines starting with 1. would be converted to an ordered list
- lines starting with > would be converted to a block quote
- use \ if you need to avoid the conversion (like \*this\* comes out as *this* instead of italics)
- other than those rules, your comment box would continue to work exactly as it does now.
posted by john hadron collider at 8:08 PM on March 5, 2020 [2 favorites]
I’m super not into learning another set of arcane symbols and incantations at this point, but posting links on mobIle could stand to be less Sisyphean.
posted by rodlymight at 8:23 PM on March 5, 2020 [4 favorites]
posted by rodlymight at 8:23 PM on March 5, 2020 [4 favorites]
Congratulations, you've invented yet another site specific markup language. Better to be able to point to the commonly known (or at least what we implement) markup (as implemented by Library) with the note that the generated HTML is stripped to a certain level (of no evil script tags, etc.) and leave it at that. Then your documentation (and implementation) is done by others and is consistent. Do or do not, there is no try to come up with some half-baked measure.
Still want LaTeX, MathJax, KaTeX, etc.
posted by zengargoyle at 8:24 PM on March 5, 2020 [1 favorite]
Still want LaTeX, MathJax, KaTeX, etc.
posted by zengargoyle at 8:24 PM on March 5, 2020 [1 favorite]
One of the things I've always just assumed is happening when people just provide a plain-text URL sans hyperlink in a comment is that the mobile UI just makes it a bit too much of a pain-in-the-ass-at-the-moment to hyperlink some text.
It's worth thinking of this as a "desire path" of user behaviour, and design the mobile experience (in particular) accordingly since that user behaviour speaks volumes about how people engage (and don't engage) with the UI on mobile when posting or commenting.
And I say this as someone who's very comfortable with HTML-only posting (I tried Markdown for an extended period and found it wasn't for me personally because HTML was already a standards-based thingy I could understand).
So for me it comes down to a better OS-agnostic user experience on mobile for posting/commenting while keeping it simple, stripped-down HMTL. YMMV.
posted by mandolin conspiracy at 8:29 PM on March 5, 2020 [3 favorites]
It's worth thinking of this as a "desire path" of user behaviour, and design the mobile experience (in particular) accordingly since that user behaviour speaks volumes about how people engage (and don't engage) with the UI on mobile when posting or commenting.
And I say this as someone who's very comfortable with HTML-only posting (I tried Markdown for an extended period and found it wasn't for me personally because HTML was already a standards-based thingy I could understand).
So for me it comes down to a better OS-agnostic user experience on mobile for posting/commenting while keeping it simple, stripped-down HMTL. YMMV.
posted by mandolin conspiracy at 8:29 PM on March 5, 2020 [3 favorites]
John hadron collider's example is all basic Markdown, not some arcane Mefi-specific version.
The people I see who attempt Markdown on Facebook won't call themselves tech-savvy (the fact that they're trying to do Markdown on Facebook is proof of that, especially with links, even though their syntax is correct). HTML would likely escape them or be too "coder" for them (a lot of them are artists and there's a weird community thing about Artists and Techies being two separate species but there's a whole other discussion). However, they're usually very adept and knowledgeable in their own fields and have a lot to share. They'd be excellent Mefites if they weren't so flummoxed by HTML. It's people like them that I had in mind when I wrote this post.
Side note: I hadn't heard about the trick to select a word and then press the link button - and hey it works on Chrome for Android! However, I've noticed that sometimes the select function goes haywire on my phone (Google Pixel 3) so it'd be good to have options that aren't reliant on that.
posted by divabat at 8:36 PM on March 5, 2020
The people I see who attempt Markdown on Facebook won't call themselves tech-savvy (the fact that they're trying to do Markdown on Facebook is proof of that, especially with links, even though their syntax is correct). HTML would likely escape them or be too "coder" for them (a lot of them are artists and there's a weird community thing about Artists and Techies being two separate species but there's a whole other discussion). However, they're usually very adept and knowledgeable in their own fields and have a lot to share. They'd be excellent Mefites if they weren't so flummoxed by HTML. It's people like them that I had in mind when I wrote this post.
Side note: I hadn't heard about the trick to select a word and then press the link button - and hey it works on Chrome for Android! However, I've noticed that sometimes the select function goes haywire on my phone (Google Pixel 3) so it'd be good to have options that aren't reliant on that.
posted by divabat at 8:36 PM on March 5, 2020
This exact same proposal feels like less of a big deal to me if you don't think of it as supporting an alternate format, or even necessarily mention that it's markdown.Yes! I'm honestly rather baffled by the opposition to adding this as an option. Aside from the work involved in implementing and supporting it - and until we hear otherwise there's no obvious reason to think this would be very large - it would just be a shortcut to trigger html functions that the site already has, and seems like one of the lowest-hanging fruit for making the site more useful (and, hopefully, more used). It would definitely be better than some kind of WYSIWYG javascript monstrosity.
Congratulations, you've invented yet another site specific markup language.That's just the simplest and most useful parts of reddit markdown without the annoying stuff. I see no problem with that and I bet it would cover 99% of the cases where people now use html.
One of the things I've always just assumed is happening when people just provide a plain-text URL sans hyperlink in a comment is that the mobile UI just makes it a bit too much of a pain-in-the-ass-at-the-moment to hyperlink some text.In my case, most of the buttons on the mobile interface just don't work. Or they do work, but 15 seconds after I press them at which time I no longer want them to. Or they make the browser window suddenly jump to the top of the page. It seems to be random. Selecting text in the comment box is also a huge pain.
posted by A Thousand Baited Hooks at 8:52 PM on March 5, 2020 [1 favorite]
Implementing that subset would be more work than using a library to implement the full specification of choice. That would be more work for the mods in documenting the subset, implementing the subset, and maintaining the subset.Congratulations, you've invented yet another site specific markup language.
That's just the simplest and most useful parts of reddit markdown without the annoying stuff. I see no problem with that and I bet it would cover 99% of the cases where people now use html.
Do the whole thing and you get to use a library that does all of that for you, and you get to point a link to the syntax of the supported format instead of writing it yourself, and somebody else gets to fix the bugs in the implementation. Reduce, Reuse, Recycle, Stand on the Shoulders of Giants, Don't Reinvent the Wheel, etc.
There's no need for the mods to do anything more than integrate already existing FooFormatToHTML libraries created and maintained by others into Metafilter proper. Don't saddle them with creating and maintaining a Metafilter specific version of most-useful-of-X markup.
posted by zengargoyle at 10:09 PM on March 5, 2020 [2 favorites]
Heh, asking for a minature pony is worse than just asking for a regular pony.
posted by zengargoyle at 10:15 PM on March 5, 2020 [3 favorites]
posted by zengargoyle at 10:15 PM on March 5, 2020 [3 favorites]
One improvement that could be made for mobile users (and I'd use it on desktop too) would to to make the Bold and Italic buttons be, um... sort of on/off switches. You hit the button, it inserts the start tag, you keep typing, you get to the end, you hit the button again, it inserts the end tag. No need to select text, just turn the function on and off. Maybe have the background of the button be darker while it's on, or something.
I agree that this small change would make it much easier.
posted by value of information at 10:34 PM on March 5, 2020
I agree that this small change would make it much easier.
posted by value of information at 10:34 PM on March 5, 2020
I'm with SaltySalticid - count me as another user who has a pretty decent and straightforward experience on mobile, using mid- to low-end devices.
I think it would be helpful, when saying that the mobile experience sucks, to describe in some detail what your individual process is and what specific problems you run into so that they can be addressed and so the main pain points can be understood. I read comments saying commenting on mobile is painful and much of the time I'm confused as to why, aside from built-in issues like screen size or the joys of mobile keyboards.
It seems like on mobile anything that requires careful selection of text can be a problem and would ideally be avoided, since cursor movement on mobile is so finicky (at least on Android).
I like hippybear's suggestions above, and would add one more: an Undo button. Sometimes you apply formatting to the wrong place or regret a link choice, and it's a bit of a pain to erase the tags manually.
I don't love markdown. Also on mobile, where most relevant punctuation is a step or more away from the main layout on most keyboards, you'd still want buttons for usability so I'm not sure it would really change the experience much.
posted by trig at 2:24 AM on March 6, 2020 [2 favorites]
I think it would be helpful, when saying that the mobile experience sucks, to describe in some detail what your individual process is and what specific problems you run into so that they can be addressed and so the main pain points can be understood. I read comments saying commenting on mobile is painful and much of the time I'm confused as to why, aside from built-in issues like screen size or the joys of mobile keyboards.
It seems like on mobile anything that requires careful selection of text can be a problem and would ideally be avoided, since cursor movement on mobile is so finicky (at least on Android).
I like hippybear's suggestions above, and would add one more: an Undo button. Sometimes you apply formatting to the wrong place or regret a link choice, and it's a bit of a pain to erase the tags manually.
I don't love markdown. Also on mobile, where most relevant punctuation is a step or more away from the main layout on most keyboards, you'd still want buttons for usability so I'm not sure it would really change the experience much.
posted by trig at 2:24 AM on March 6, 2020 [2 favorites]
Congratulations, you've invented yet another site specific markup language.
MeFi HTML is already a site-specific markup language. It's HTML, but only some HTML, and only a subset of what is allowed is even indicated in the UI (you just have to know the other things you're allowed to do, basically a hidden menu of options new users aren't even aware they're missing).
I'd also like to say that I think your repeated jump to very low-level technical details is not helping this thread. It feels like noise and it would be nice if you could let the conversation happen around whether people would like a change and in what ways it might help them without throwing down to try to define an encoding scheme, argue for libraries vs. internal implementation, etc.
I think it would be helpful, when saying that the mobile experience sucks, to describe in some detail what your individual process is and what specific problems you run into so that they can be addressed and so the main pain points can be understood.
The things I run into:
Anything requiring precision text selection is very iffy (as you mention). Sometimes it's damn near impossible to get it to work, particularly near the edges of the screen. This makes using the buttons (precisely select text, hit button) not great.
Additionally, I have also frequently tried just typing HTML tags directly. This has a few problems. As the mobile button set indicates, some of it is that there's special keys that are not easy to get to on most mobile keyboards. However, I've also had a bunch of cases where trying to type an end tag results in basically a forced auto-correct that deletes it with no way to reverse it (this has happened on multiple Android phones in the past few years). I don't know if it's the phones (I've had LG phones repeatedly) or something going on in MeFi JS, but it's been true for a long time.
Meanwhile, I use Slack daily and even though its subset of markdown for basic formatting (bold, italics) does require "special" characters, it is orders of magnitude more user friendly. Because it only requires a single character at the start and end of a sequence, it has never bothered me that I have to go to the secondary set of characters on my keyboard for it (compared to "1 special character, 2-5 regular characters, 1 special character" for HTML). I literally don't even notice it, it's basically a totally smooth experience.
posted by tocts at 4:42 AM on March 6, 2020 [2 favorites]
MeFi HTML is already a site-specific markup language. It's HTML, but only some HTML, and only a subset of what is allowed is even indicated in the UI (you just have to know the other things you're allowed to do, basically a hidden menu of options new users aren't even aware they're missing).
I'd also like to say that I think your repeated jump to very low-level technical details is not helping this thread. It feels like noise and it would be nice if you could let the conversation happen around whether people would like a change and in what ways it might help them without throwing down to try to define an encoding scheme, argue for libraries vs. internal implementation, etc.
I think it would be helpful, when saying that the mobile experience sucks, to describe in some detail what your individual process is and what specific problems you run into so that they can be addressed and so the main pain points can be understood.
The things I run into:
Anything requiring precision text selection is very iffy (as you mention). Sometimes it's damn near impossible to get it to work, particularly near the edges of the screen. This makes using the buttons (precisely select text, hit button) not great.
Additionally, I have also frequently tried just typing HTML tags directly. This has a few problems. As the mobile button set indicates, some of it is that there's special keys that are not easy to get to on most mobile keyboards. However, I've also had a bunch of cases where trying to type an end tag results in basically a forced auto-correct that deletes it with no way to reverse it (this has happened on multiple Android phones in the past few years). I don't know if it's the phones (I've had LG phones repeatedly) or something going on in MeFi JS, but it's been true for a long time.
Meanwhile, I use Slack daily and even though its subset of markdown for basic formatting (bold, italics) does require "special" characters, it is orders of magnitude more user friendly. Because it only requires a single character at the start and end of a sequence, it has never bothered me that I have to go to the secondary set of characters on my keyboard for it (compared to "1 special character, 2-5 regular characters, 1 special character" for HTML). I literally don't even notice it, it's basically a totally smooth experience.
posted by tocts at 4:42 AM on March 6, 2020 [2 favorites]
Yes to be clear what makes MeFi links easier for me than markdown links is markdown requires I go hunting for parens and brackets— two of each!— on my shitty iOS keyboard. Using the link button only requires regular character typing and copy/paste, which is easier on my old thumbs and brain.
posted by SaltySalticid at 5:16 AM on March 6, 2020
posted by SaltySalticid at 5:16 AM on March 6, 2020
While we're considering this stuff, can we please please please add some padding to the Description and Extended Description input boxes on the New Post page? Comment boxes across the site have sensible padding, but the New Post textareas make me feel like I'm trying to paint trim in the corner of a room.
posted by oulipian at 6:58 AM on March 6, 2020
posted by oulipian at 6:58 AM on March 6, 2020
Humbug.
posted by RolandOfEld at 7:03 AM on March 6, 2020
posted by RolandOfEld at 7:03 AM on March 6, 2020
Yeah that "blank link on a line gets HTML-ized" feature already exists in MeFi Mail, would be helpful here too I think.
posted by jessamyn (temp) at 8:35 AM on March 6, 2020 [5 favorites]
posted by jessamyn (temp) at 8:35 AM on March 6, 2020 [5 favorites]
My subjective feeling is that there has been less of a move from e.g. HTML to Markdown as there has been a move from any explicit inline markup language to tool-based or WYSIWYG markup processes that abstract away the formatting entirely
Slack (mentioned in the original post), for instance, rolled out a new WYSIWYG mode recently. They even went so far as to make it mandatory until the sizeable contingent of software developers who use Slack complained (myself included) and forced them to add an opt-out. Reddit similarly defaults to WYSIWYG with an opt-out to use Markdown instead.
So I definitely agree that there's essentially no advantage from an inclusion standpoint to switching from HTML to Markdown, given that the internet as a whole is moving away from supporting any form of user markup at all and towards WYSIWYG editors. Even if the average internetter now is very familiar with Markdown (which I actually doubt, but let's assume that for the sake of the argument), I'd argue that the average internetter even a year or two in the future will find Markdown just as alien as HTML, rendering the advantages of implementing it totally moot.
OTOH, improvements to make the existing tag buttons more usable would provide evergreen benefits.
posted by tobascodagama at 8:47 AM on March 6, 2020
Slack (mentioned in the original post), for instance, rolled out a new WYSIWYG mode recently. They even went so far as to make it mandatory until the sizeable contingent of software developers who use Slack complained (myself included) and forced them to add an opt-out. Reddit similarly defaults to WYSIWYG with an opt-out to use Markdown instead.
So I definitely agree that there's essentially no advantage from an inclusion standpoint to switching from HTML to Markdown, given that the internet as a whole is moving away from supporting any form of user markup at all and towards WYSIWYG editors. Even if the average internetter now is very familiar with Markdown (which I actually doubt, but let's assume that for the sake of the argument), I'd argue that the average internetter even a year or two in the future will find Markdown just as alien as HTML, rendering the advantages of implementing it totally moot.
OTOH, improvements to make the existing tag buttons more usable would provide evergreen benefits.
posted by tobascodagama at 8:47 AM on March 6, 2020
I would like markdown availability, or failing that, the turn on/turn off buttons for italics. Sometimes it can be nearly impossible to get the cursor between the pair of HTML tags to paste in the stuff I want to italicize on iOS.
I don’t have huge issues with posting links on mobile/iOS—sure it’s more of a hassle than on a computer, but as others have said, dismiss keyboard, flip to new page in Safari, search for link, copy, go back to original MeFi window, highlight word, click link button, paste in link, is not terrible. Sometimes highlighting more than one word in the already-written text is super-frustrating, but that’s not MeFi’s problem. That’s just that selecting on iOS can be flaky.
posted by leahwrenn at 9:01 AM on March 6, 2020
I don’t have huge issues with posting links on mobile/iOS—sure it’s more of a hassle than on a computer, but as others have said, dismiss keyboard, flip to new page in Safari, search for link, copy, go back to original MeFi window, highlight word, click link button, paste in link, is not terrible. Sometimes highlighting more than one word in the already-written text is super-frustrating, but that’s not MeFi’s problem. That’s just that selecting on iOS can be flaky.
posted by leahwrenn at 9:01 AM on March 6, 2020
I think it would be helpful, when saying that the mobile experience sucks, to describe in some detail what your individual process is and what specific problems you run into so that they can be addressed and so the main pain points can be understood.
I don’t have any issues with the process of highlighting a thing and pressing a button in theory, but shit can get wacky with the selectioning.
What happens is when selecting text, often the whole page will scroll rapidly upward, which makes things kind of difficult. I suspect this is due to mobiles generally having a bad time with embedded text boxes as I’ve seen similar freakouts on different pages with embedded scrollable content areas.
.
posted by rodlymight at 9:10 AM on March 6, 2020 [3 favorites]
I don’t have any issues with the process of highlighting a thing and pressing a button in theory, but shit can get wacky with the selectioning.
What happens is when selecting text, often the whole page will scroll rapidly upward, which makes things kind of difficult. I suspect this is due to mobiles generally having a bad time with embedded text boxes as I’ve seen similar freakouts on different pages with embedded scrollable content areas.
.
posted by rodlymight at 9:10 AM on March 6, 2020 [3 favorites]
#BringBackTheBlinkTag
posted by grumpybear69 at 9:18 AM on March 6, 2020 [7 favorites]
posted by grumpybear69 at 9:18 AM on March 6, 2020 [7 favorites]
I would like to take this moment to note that Metafilter's mobile platform for bold/italics/etc is probably the best interface I see on the web, and that includes Discord/Slack/etc. I say this because I find Markdown insufferable on mobile because the asterisks and underscores it relies on for emphasis are incredibly frustrating to switch keyboards to get to on mobile. By contrast, MeFi's current layout means that I can just tap once and then there's the formatting I want and all the difficult symbols are right there waiting for me.
If we institute other forms of rich text/Markdown, I would like to request that the interface similarly provide the keys on mobile views so that emphasis is easier to manage.
posted by sciatrix at 10:06 AM on March 6, 2020 [2 favorites]
If we institute other forms of rich text/Markdown, I would like to request that the interface similarly provide the keys on mobile views so that emphasis is easier to manage.
posted by sciatrix at 10:06 AM on March 6, 2020 [2 favorites]
All I want is an added button for blockquote, please.
posted by jeather at 10:09 AM on March 6, 2020 [13 favorites]
posted by jeather at 10:09 AM on March 6, 2020 [13 favorites]
Sometimes it can be nearly impossible to get the cursor between the pair of HTML tags to paste in the stuff I want to italicize on iOS.
Since there was a comment above about not knowing that you can highlight text and use the Link button to linkify it: do many people here use the Bold/Italic buttons not by first selecting text and then formatting it, but by first adding the formatting tags and only then inserting the text between the tags?
That is, is adding tags first and only then inserting text between them a common approach for people?
posted by trig at 11:15 AM on March 6, 2020
Since there was a comment above about not knowing that you can highlight text and use the Link button to linkify it: do many people here use the Bold/Italic buttons not by first selecting text and then formatting it, but by first adding the formatting tags and only then inserting the text between the tags?
That is, is adding tags first and only then inserting text between them a common approach for people?
posted by trig at 11:15 AM on March 6, 2020
Wait, on mobile, doesn't using the buttons for B/I/Link leave the cursor in the right place to start typing like it does on the desktop?
posted by zengargoyle at 2:41 PM on March 6, 2020
posted by zengargoyle at 2:41 PM on March 6, 2020
Phones' handling of text entry is terrible and there's not a whole lot I think MetaFilter can do to solve that. At least on Android, I've never had a phone that gives me a way to precisely move a few characters left or right, making it impossible for me to place the cursor between the tags that the MeFi mobile UI creates in order to paste text. But that's a problem for phone designers, not MetaFilter. That said, I think hippybear's suggestion is brilliant and would dramatically improve my mobile user experience.
Personally I like Markdown but I don't think it's worth MeFi trying to support it. If the goal is to lower the barrier to entry, rich text fields would be more effective and allow the internal HTML representation to be unchanged. For Markdown fans, that might allow the use of the Markdown Here browser extension, as well.
I still vote for adding support for MathJax, though.
posted by biogeo at 5:42 PM on March 6, 2020 [3 favorites]
Personally I like Markdown but I don't think it's worth MeFi trying to support it. If the goal is to lower the barrier to entry, rich text fields would be more effective and allow the internal HTML representation to be unchanged. For Markdown fans, that might allow the use of the Markdown Here browser extension, as well.
I still vote for adding support for MathJax, though.
posted by biogeo at 5:42 PM on March 6, 2020 [3 favorites]
I think the link thing is worth exploring- I usually just type an a href tag rather than the link button, but recognise that html is like my programming heart language. Making it easier for mobile users to post links would be good.
Regarding converting ** etc to mark up, I don't like it when these things change automatically when you don't expect them to-
*Looks around* has a different meaning to Looks around . I like the old timey feel of punctuation for different tones of voice and emphasis. A vote against autoswap for sure, would be open to a markdown mode, like the extension, but of course on mobile it's hard to run extensions!
posted by freethefeet at 6:00 PM on March 6, 2020 [2 favorites]
Regarding converting ** etc to mark up, I don't like it when these things change automatically when you don't expect them to-
*Looks around* has a different meaning to Looks around . I like the old timey feel of punctuation for different tones of voice and emphasis. A vote against autoswap for sure, would be open to a markdown mode, like the extension, but of course on mobile it's hard to run extensions!
posted by freethefeet at 6:00 PM on March 6, 2020 [2 favorites]
I still vote for adding support for MathJax, though.
I was going to say how hard MathJax would be to implement well on Metafilter. Then I had the crazy idea of ... what if there was a web page that took a URL and enabled MathJax for that page? Then I did some Google and what do you know ... not exactly, but almost close enough ...
MathJax Bookmarklet
You totally can turn on MathJax on a page on demand by clicking a bookmarklet. You can do it after the page is loaded. Metafilter should they so desire could check the Tags of a post for 'mathjax' and add a link in the post to load MathJax should a user so desire. New Pony!
posted by zengargoyle at 7:56 PM on March 6, 2020
I was going to say how hard MathJax would be to implement well on Metafilter. Then I had the crazy idea of ... what if there was a web page that took a URL and enabled MathJax for that page? Then I did some Google and what do you know ... not exactly, but almost close enough ...
MathJax Bookmarklet
You totally can turn on MathJax on a page on demand by clicking a bookmarklet. You can do it after the page is loaded. Metafilter should they so desire could check the Tags of a post for 'mathjax' and add a link in the post to load MathJax should a user so desire. New Pony!
posted by zengargoyle at 7:56 PM on March 6, 2020
biogeo, I don't know if this works on all phones but on my Android device, an LG G5, and I think on iOS devices, long pressing on the spacebar brings up a single line of text with little arrows to move left and right by single characters. It's far from a perfect solution to navigating text on mobile but it gets the job done.
posted by Mister_Sleight_of_Hand at 1:33 AM on March 7, 2020 [1 favorite]
posted by Mister_Sleight_of_Hand at 1:33 AM on March 7, 2020 [1 favorite]
And speaking of bookmarklets, I meant to post this yesterday but didn't get around to it. I had some time yesterday so I wrote a bookmarklet implementing a very basic version of hippybear's suggestion above.
It replaces the standard html shortcut buttons with new ones (and an added 'Quote' button for blockquotes.) First click adds an opening tag, second click adds a closing tag. The 'Link' button prompts for a URL before adding the opening tag.
A few things:
This is quick and dirty and not really intended as a long term solution just something for people to play with. If people like it I can maybe look into making something a bit more robust like a firefox extension and make the code available so it can be ported to other browsers.
I've tested it on Firefox and Chrome on desktop and Android. The code is straight-forward so I don't see why it wouldn't work on other browsers but I can't guarantee it.
It doesn't do any parsing or checking for matching tags so you're still responsible for opening and closing tags appropriately. If you open a tag and then delete it and then press the button again you're still going to get a closing tag.
It doesn't do anything at all with selected text. That could probably be added though.
Posting a comment refreshes the page which re-instates Mefi's standard buttons which means you'll have to click the bookmarklet for every comment. Which isn't so bad on desktop but might be a pain on mobile.
Currently only works on the comment box and not for new posts or anywhere else on Mefi.
So, with those points in mind, here are html toggle buttons for MeFi. You can play with it at that page and then try it here. On desktop drag the link at that page to your bookmarks bar and then come back here and click it. Bookmarklets on mobile are a bit more of a pain but they can be used, at least in firefox and chrome on Android: Bookmark the link and then over here, click on the address bar and type 'mefi' and the bookmark should be visible on your auto-complete suggestions. Click it and the new buttons should show up.
(Note: the default buttons at the test page don't do anything but the substituted buttons do.)
posted by Mister_Sleight_of_Hand at 2:37 AM on March 7, 2020 [1 favorite]
It replaces the standard html shortcut buttons with new ones (and an added 'Quote' button for blockquotes.) First click adds an opening tag, second click adds a closing tag. The 'Link' button prompts for a URL before adding the opening tag.
A few things:
This is quick and dirty and not really intended as a long term solution just something for people to play with. If people like it I can maybe look into making something a bit more robust like a firefox extension and make the code available so it can be ported to other browsers.
I've tested it on Firefox and Chrome on desktop and Android. The code is straight-forward so I don't see why it wouldn't work on other browsers but I can't guarantee it.
It doesn't do any parsing or checking for matching tags so you're still responsible for opening and closing tags appropriately. If you open a tag and then delete it and then press the button again you're still going to get a closing tag.
It doesn't do anything at all with selected text. That could probably be added though.
Posting a comment refreshes the page which re-instates Mefi's standard buttons which means you'll have to click the bookmarklet for every comment. Which isn't so bad on desktop but might be a pain on mobile.
Currently only works on the comment box and not for new posts or anywhere else on Mefi.
So, with those points in mind, here are html toggle buttons for MeFi. You can play with it at that page and then try it here. On desktop drag the link at that page to your bookmarks bar and then come back here and click it. Bookmarklets on mobile are a bit more of a pain but they can be used, at least in firefox and chrome on Android: Bookmark the link and then over here, click on the address bar and type 'mefi' and the bookmark should be visible on your auto-complete suggestions. Click it and the new buttons should show up.
(Note: the default buttons at the test page don't do anything but the substituted buttons do.)
posted by Mister_Sleight_of_Hand at 2:37 AM on March 7, 2020 [1 favorite]
Okay, I don't know how feasible this is but thinking about the mobile text selection problem, this seemed like an ideal hypothetical workflow for the situation where you want to apply formatting or linkage to text you've already written (i.e., a situation start/stop buttons doesn't deal with):
1. Tap on the word you want to be first in your selection. Doesn't matter where in the word your cursor lands.
2. Hit a button that starts selection or formatting at the beginning of that word.
3. Tap on the word you want to be the last word in your selection. Doesn't matter where in the word your cursor lands.
4. Hit a button that ends selection or formatting at the end of that word.
Still a little tricky in the case of one- or two- character words, but otherwise it eliminates the need for careful and accurate selection which is so painful on mobile. For short words the only solution might be actual arrow buttons for cursor movement, which might actually be great in general for editing, if annoying conceptually.
posted by trig at 11:56 PM on March 7, 2020
1. Tap on the word you want to be first in your selection. Doesn't matter where in the word your cursor lands.
2. Hit a button that starts selection or formatting at the beginning of that word.
3. Tap on the word you want to be the last word in your selection. Doesn't matter where in the word your cursor lands.
4. Hit a button that ends selection or formatting at the end of that word.
Still a little tricky in the case of one- or two- character words, but otherwise it eliminates the need for careful and accurate selection which is so painful on mobile. For short words the only solution might be actual arrow buttons for cursor movement, which might actually be great in general for editing, if annoying conceptually.
posted by trig at 11:56 PM on March 7, 2020
I don’t want markdown to be added and the mobile buttons work well as is.
posted by michaelh at 3:11 AM on March 8, 2020
posted by michaelh at 3:11 AM on March 8, 2020
I guess I'm the only person who uses the non-mobile (and classic) version on my iPhone and just types the HTML?
posted by hydropsyche at 7:04 AM on March 8, 2020
posted by hydropsyche at 7:04 AM on March 8, 2020
I also often type out the HTML code directly, though it takes forever. It also relies on knowledge that isn't necessarily intuitive (why do links use an "a" tag rather than a "link" tag?) - at least I know enough HTML to get by but a lot of people won't.
posted by divabat at 7:41 AM on March 8, 2020
posted by divabat at 7:41 AM on March 8, 2020
IIRC, the a stands for anchor and the href stands for hypertext reference. It was a design decision made when HTML was first introduced. Link implied going to a different page whereas anchor could be a place within the page OR outside of the page.
For example: https://metatalk.metafilter.com/25484/Time-to-change-from-HTML#1361077 anchors right on to your comment, based on the #1361077.
I could be remembering the history all wrong, but I am 90% sure anchors and links were considered distinct items.
posted by a non mouse, a cow herd at 8:14 AM on March 10, 2020
For example: https://metatalk.metafilter.com/25484/Time-to-change-from-HTML#1361077 anchors right on to your comment, based on the #1361077.
I could be remembering the history all wrong, but I am 90% sure anchors and links were considered distinct items.
posted by a non mouse, a cow herd at 8:14 AM on March 10, 2020
From the HTML 2.0 RFC:
So it's A instead of LINK because hyperlinks are used for more than just clickable navigation elements.
posted by tobascodagama at 12:01 PM on March 10, 2020
The <LINK> element represents a hyperlink (see 7, "Hyperlinks"). AnyWhereas:
number of LINK elements may occur in the $lt;HEAD$gt; element of an HTML
document.
The <A> element indicates a hyperlink anchor (see 7, "Hyperlinks").It doesn't actually have anything to do with page anchors, as far as I can tell, except that A is a body tag and thus gets rendered as part of the page whereas LINK is a header tag and does not get rendered. Section 7 on Hyperlinks seems to use "anchor" as a term referring to an element that can be activated to trigger navigation. LINKs don't trigger navigation, instead the browser follows them to obtain additional resources required to render the page. (Indeed, the almost exclusive use of LINK tags in HTML these days is to direct the browser to the stylesheet for a page.)
At least one of the NAME and HREF attributes should be present.
So it's A instead of LINK because hyperlinks are used for more than just clickable navigation elements.
posted by tobascodagama at 12:01 PM on March 10, 2020
Fellow iOS/iPadOS users: you do know the spacebar trick, right? Hold down the spacebar until it give a little haptic buzz, then use it almost like a mouse to maneuver the cursor wherever you need in the current textbox? Precision placement made easy.
posted by lhauser at 7:33 PM on March 10, 2020 [5 favorites]
posted by lhauser at 7:33 PM on March 10, 2020 [5 favorites]
Back in 2015, evand created Markdown for MeFi browser extensions for Safari, Firefox, and Chrome desktop browsers.
evand announces availability in Metatalk
Download the extensions and read the FAQ at evand’s Github: http://evan-dickinson.github.io/md4mefi/
Safari no longer supports the *.safariextz format, so that’s out.
It’s working great for me in Firefox Quantum on Mac.
I have no experience with Chrome-based browsers.
posted by Jesse the K at 4:31 PM on March 11, 2020
evand announces availability in Metatalk
Download the extensions and read the FAQ at evand’s Github: http://evan-dickinson.github.io/md4mefi/
Safari no longer supports the *.safariextz format, so that’s out.
It’s working great for me in Firefox Quantum on Mac.
I have no experience with Chrome-based browsers.
posted by Jesse the K at 4:31 PM on March 11, 2020
Fellow iOS/iPadOS users: you do know the spacebar trick, right? Hold down the spacebar until it give a little haptic buzz, then use it almost like a mouse to maneuver the cursor wherever you need in the current textbox? Precision placement made easy.
Woah. No, I didn't. Life-changing.
posted by mosst at 7:20 AM on March 12, 2020 [2 favorites]
Woah. No, I didn't. Life-changing.
posted by mosst at 7:20 AM on March 12, 2020 [2 favorites]
You are not logged in, either login or create an account to post comments
1. Adding alternate formatting options like Markdown or rich text
It's something we could consider but haven't looked closely at recently. I definitely hear you on the potential upside of supporting some more contemporary formatting approach: if it's easier for members to successfully render what they meant to on the first go, great!
The downsides include needing to implement and maintain additional markup support in comments, needing to train/support site members on use and pitfalls of that (a lot of Markdown stuff takes the form of common literal punctuation people use *not* expecting markup to be applied), sorting out whether and how to either firewall off new markup rules from the archives or cope with the effects of it applying retroactively, etc.
My subjective feeling is that there has been less of a move from e.g. HTML to Markdown as there has been a move from any explicit inline markup language to tool-based or WYSIWYG markup processes that abstract away the formatting entirely (as well as maybe an abandonment of much of the markup culture that was once more common in a lot of internet writing, especially because of short-form social media like twitter and instagram). In that sense for me the more appealing focus would be not additional/alternative markup but easier to use tools for rendering formatting on a MeFi comment in whatever markup is operating under the hood.
But I am curious to hear from folks in the community about their thoughts/feelings/experiences with this stuff.
2. Moving away from HTML
This I don't see happening.
I agree that we're past the age of HTML as the lingua franca of nerd-ish online conversation. MeFi itself is no longer so centered around blogging (RIP) the way it was back in the early 2000s. It remains common knowledge for a lot of folks, and for a lot of other folks it is a thing they know about more because it exists than because they particularly care to know it. If we were designing MeFi today, we might consider a different approach entirely to public-facing formatting on the site.
But MeFi was designed 20+ years ago around some pretty strong assumptions about HTML as an integral part of the commenting and posting process; it's baked in to a whole lot of the site. It's also baked in to a whole lot of MeFite's expectations about how the site works, and as much as HTML as a common formatting preference has declined, it's how the site's functioned and how people have learned to use it for a couple decades. I don't see any real path toward actually excising or retiring it, vs. potentially supplementing it.
3. Revisiting the link button functionality
I think this is a good call! We've talked occasionally about trying to rework that but it hasn't risen to the top of the priority list; I'd be fine talking in a little more detail about how a change there could work well for mobile and desktop users alike. As with many things on MeFi, the main reason it behaves the way it currently does is...that's how Matt put it together a long time ago when the web and MeFi were different. Giving it another pass is probably due and then some if we can find a good improvement.
There's some aspects of that on the implementation side that are more of a frimble thing, so I'd need their input on any notional change.
posted by cortex (staff) at 8:25 AM on March 5, 2020 [6 favorites]