In order to quote text, you normally have to highlight the text and the click the “Quote” button that appears. However, you cannot highlight text blurred by a spoiler tag, so you cannot quote the spoiler text (without quoting the whole post). Ideally you should be able to quote the spoiler text, and have it still have surrounded by spoiler tags.
It’s not uncommon to respond to spoiler text though. As long as quoting it automatically wraps it in a spoiler tag, I don’t see why you’d want to block that functionality.
While you may not be able to quote the spoiler using the highlight-quote method, you can quote the whole post using the “Quote whole post” button in the composer, and then edit it down to what you want (you may also want to remove the , full:true part of the quote code to get the full context available in the quote, but it’s not critical). You would click the Reply button on the post you are interested in quoting, then press this button:
Okay, then re-categorizing it (as I see someone just did) is fine. Bug or feature request, it’s still something that I think should be changed and would benefit users.
AFAIK it’s a browser situation not something that Discourse can currently do anything about with any consistent success.
If you know of a way to write some HTML that behaves the way you think it should be I’m interested in seeing it. Else I think it would be the browsers that need to be petitioned to come to a consensus and then support it.
I just checked the styles being used for the spoiler text and it includes the style user-select: none. I imagine simply removing the code that added that style would work, though obviously I don’t know the details of how the site works or if that would cause any side effects.
EDIT: That change would just be to get the text to highlight of course. If this feature was implemented, there’d obviously be more work to make sure the quoted text was properly wrapped in spoiler tags.
It can be used in a way that results in valid well-formed HTML and behaves as expected. And it can be used incorrectly resulting in invalid not well-formed HTML that can not be expected to behave as though it were used correctly.
IMHO, removing a feature because it can break when used incorrectly seems a bit unfair to those that want to use it as it should be used.
If you’re suggesting to have code “determine what should have been done and rewrite errors” I don’t think AI is up to that task.
I honestly have no idea what you’re talking about. If you’re directly responding to my comment saying “All the more reason not to use it”, I guess one of us misunderstood the other. In seemed to me like you were saying that the user-select CSS is experimental, so it seemed like you were making my argument for me: to not use it. Considering that Discourse is using this experimental CSS right now (from looking at the HTML elements used for spoiler text), that was the only conclusion I could come to.
Now to your actual response. What about my feature request to allow you to quote spoiler text would result in the removal of another feature? And what is the well-formed and not well-formed HTML that you’re talking about? Finally, I have no idea what “determine what should have been done and rewrite errors” means. Any clarification would be appreciated.
I misread your post that you were suggesting adding user-select: text, instead of removing user-select: none (which indeed is being added by script). Hence I thought you were suggesting removing the spoiler feature.
Posts with quoted post content of course follow the original post. But if the spoiler was easily made visible, it could defeat the original members intent of spoilering.
A problem is the reply - quote post pulls in the raw, while the select copy to clipboard captures the rendered. AFAIK, clipboard can not be made to do otherwise.
As for the invalid HTML, the current cooked HTML is like
I have seen a website insert additional text onto a page briefly when the user copies so that it’s included in the clipboard. The text was never visible to the user, but it still probably isn’t a particularly practical solution. I also don’t know of a better way to do this.
Ideally this is how I’d like it to work:
Text in existing post:
First Text
Second Text
Third Text
If I highlight everything and click the Quote button (not whole post), I’d like my post to be filled with:
First Text
[spoiler]Second Text[/spoiler]
Third Text
Similarly, if I only highlight part of the spoiler text, I might get something like this:
First Text
[spoiler]Seco[/spoiler]
As I said, that’s how I’d ideally like it to work, but between the clipboard issue and the fact that the spoiler text is a plugin, I understand that it may not be simple to do. I could try to fork the plugin to look into the user-select part, but understandably everyone doesn’t want to make it easy to copy spoiler text in a way that makes it plain text. So unless the highlight quote functionality was also updated to do something like what I described above (adding the spoiler tag to the spoiler part of the quoted post), it probably wouldn’t make sense.
Technically our reverse HTML -> Markdown that @vinothkannans wrote could special case this. We already preserve a ton of stuff on quote due to the reverse conversion. If is it a very simple change I support it.
Great, thanks! Seems to work pretty much as expected. Because of the user-select: none, I can’t actually highlight the spoiler text directly. So it seems like I can only quote spoiler text when I highlight something before it and then drag my mouse over the spoiler text. This means that I can’t highlight spoiler text if the post starts with it (highlighting the text after it and dragging my mouse over the spoiler text from there doesn’t seem to work).
The “ideal” version I mentioned above with partial highlighting of spoiler text also doesn’t work of course, but I didn’t expect it to given the user-select: none situation. While that would be nice, it’s certainly less important than just getting the spoiler tags in general. I do wonder how the spoiler feature would work without the user-select: none, but I wasn’t able to test it just by removing it in the console since the JS code adds it back right away.
Anyway, I just wanted to give some follow up information from my brief testing. Thanks again!