-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC2184: Allow the use of the HTML <details> tag #2184
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank for the detailed MSC! It's worth mentioning that the HTML restrictions in the spec are just recommendations (albeit strong ones) rather than requirements. This does change the language of the MSC slightly, but not drastically enough to warrant fixing I don't think.
Signed-off-by: Alexander Olofsson <ace@haxalot.com>
I'm getting myself into the habit of queuing things into the FCP queue: @mscbot fcp merge |
Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people: No concerns currently listed. Once at least 75% of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
I am torn - on one hand, i really like the idea. on the other hand, i can see it being quite painful for those (e.g. Riot/iOS and Riot/Android and Seaglass) who are wrapping their own HTML renderer currently. And as @ananace quite rightly notes in the MSC, it does collide with #1767, which in theory could provide equivalent behaviour without depending on HTML to do it, and be more flexible in terms of allowing all sorts of different content/fallbacks to be togglable on & off. What do others think? |
my perspective is that MSC1767 is a great thing we should definitely do, however in the interest of progress we should shove this one through. The spec does not have a requirement on any of the HTML rendering, it just leaves it as a strong recommendation. This does technically mean that implementations could just add support if they wanted to without the spec, however this seems trivial enough to just merge into the spec's recommendation. |
I also realized that I forgot to mention that one difference between this MSC and MSC1767 is that As a small example of how that could be used for bot responses; (here as an imaginary message in response to some kind of monitoring query - or a notification) <details>
<summary>Host: <b>UP</b>, CPU: <b>CRIT</b>, Load: <b>WARN</b></summary>
<b>CPU</b>: 100%<br/>
<b>Load</b>: 15.04 7.4 4.2<br/>
<b>RAM</b>: 24%<br/>
<details>
<summary><b>Disk</b>: 20%</summary>
<ul>
<li><b>/</b>: 12% 500GB</li>
<li><b>/home</b>: 24% 1TB</li>
<li><b>/var/log</b>: 74% 32MB</li>
</ul>
</details>
</details> |
I agree with @turt2live in that I don't want to block this on extensible events like so many other things. We shouldn't block clients from using this just because some have chosen technologies which make ti difficult to implement. |
I, too, am torn on this. I fully see the value of that tag but, aside from overlapping (I wouldn't say "colliding") with extensible events, this tag only appeared in HTML5 (I know, I know...) and, as far as I can see, With that said, the fallback is pretty clear: stripping the One alternative to consider is to allow an attribute in |
OOI, is there a way of implementing similar behaviour that is easier in Qt5? If not then I'd be tempted to allow this and hop/assume that future Qt version start supporting |
Not really. The best way to emulate this in Qt would probably be parse HTML (ew), find the Regarding "if not" - well, the trouble is that the basic HTML subset used by Qt for simple markup inside its widgets (as opposed to full-blown web-pages that can be displayed using Qt Web Engine, which is a wrapper around Chromium) is considered a thing in itself that "happens" to be a subset of HTML4. How much they would even want to update this basic HTML engine is beyond my knowledge. In a lucky case, Qt 6 will have it, almost surely not in 6.0 though. As it stands, I'm preparing to resort to one of the methods from the previous paragraph; however, since a similar trouble occurs across a few platforms, I wonder how much it's worth it. |
I just wanted to chip in that I work in a few communities that make heavy use of content warnings, and a feature like this would be perfect for that usecase. The current alternative would be using spoilers and just add text like (CW: some content warning) before, which isn't a super intuitive way of doing it. A feature like this that makes it intuitive to add content warnings would be super helpful, and greatly appreciated (especially if clients starting selling it as content warnings, which I think could have a great effect for normalizing cws across the ecosystem, like on masto, but that might be too much to ask for :p ) |
To follow up on my own whinings on the topic - I ended up making the HTML parser (with whichever tools Qt provides) in Quaternion; it's (hopefully) generic enough to (hopefully) be reused across C++/Qt ecosystem (and Qt 6 apparently has all the necessary ingredients), so it unblocks more than just myself. Moreover, the actual hands-on experience on converting between Matrix and Qt subsets tells me that conversions/wrappers of that kind are not terribly bad; so I added my tick to this. |
Can we PLEASE get this to FCP? I don't believe there are any concerns outstanding. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. |
Implements MSC2184 (matrix-org/matrix-spec-proposals#2184) Signed-off-by: Tulir Asokan <tulir@maunium.net>
merged 🎉 |
MSC2184: Allow the use of the HTML <details> tag
MSC2184: Allow the use of the HTML <details> tag
Rendered
Fixes #2182