|
in reply to Adding details with summary html tags
G'day Lady Aleena,
Given you indicated in "Re^2: Adding details with summary html tags" that you were generally unfamiliar with <spoiler>
— forgot it existed; didn't know its purpose; didn't know how it worked —
I suggest reading "Perl Monks Approved HTML tags".
Having seen quite a few of your previous posts, you seem reasonably familiar with HTML5,
so the differences (elements, attributes, functionality) should hopefully be fairly obvious to you.
I think that any proposal of this nature should also address such differences; for instance,
what subset of the attributes used in HTML5 would you like implemented
(I don't think all of them would be appropriate).
What you're proposing is, as ++LanX indicated,
already handled for the most part by <spoiler>.
Because of this, I don't support your proposal to introduce two new elements.
Having said that, I would support (at least in principle)
a proposal to add a mechanism to <spoiler> that allowed it to be hidden after it had been revealed:
basically, some sort of Show/Hide toggle switch.
|
Re^2: Adding details with summary html tags
by LanX (Saint) on May 23, 2020 at 13:57 UTC
|
IMHO the best solution for overly long code sections would be an "automatic/DWIM" shrink to 10-15 lines on display of <code></code> using CSS and/or JS.
Any toggle would be simple to implement then.
This could even be configured by display settings and wouldn't require learning any new tags.
I think I've seen this before elsewhere.
This is just a suggestion, I can't volunteer implementing it right now.
| [reply]
[d/l] |
|
|
Firstly, I have no problems with what you've written.
I did just want to clarify that I wasn't advocating the introduction of a Show/Hide mechanism;
rather, that I would "support (at least in principle)" a proposal to do so.
To be honest, I only very rarely want to hide <spoiler> content after I've revealed it
— the last time was probably more than a year ago —
so, for me personally, the absence of a Show/Hide mechanism is of little concern.
| [reply]
[d/l] |
|
|
> To be honest, I only very rarely want to hide content after I've revealed it
I'm afraid I wasn't clear enough. My idea is to shrink every long code section and to provide a toggle.
Values for max-length and min-shrink could be individually set by the reading user.
Another approach would be a limited div with scrollbars, I think github is using this.
| [reply] |
|
|
Re^2: Adding details with summary html tags
by Lady_Aleena (Priest) on May 23, 2020 at 14:00 UTC
|
I went and refamiliarized myself with the <spoiler> tag. It does hide the text within it, however, the difference between <spoiler> and <details> is that <details> does not require the page to be reloaded. As the world moves to more mobile devices and plans that might have data limits, reloading pages is not optimal. Also, long blocks of code are not semantically spoilers. While my site is not the best when it comes to being easy for those using assistive technologies, I do try. So, this is not only a way to keep page loads down to a minimum, it is also more correct to use the proper HTML tag. I created a sample of <details> with <summary> so you can see how they work.
As for other HTML5 elements, I don't see any use for them here either. If we ever get <img>, then <figure> and <figcaption> might be nice. They could also be used around blockquotes, like the one I used below.
It might be a good idea to drop <font> as one day browsers might drop it.
This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.
- from MDN <font>
So to wrap up, <details> along with <summary> would hide large blocks of code nicely, is more semantically correct, and does not reload the page to see the large blocks of code as <spoiler> does.
My OS is Debian 10 (Buster); my perl version is 5.28.1.
No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!
Lady Aleena
| [reply]
[d/l]
[select] |
|
|
You wrote:
"Also, long blocks of code are not semantically spoilers."
That is an additional use for them. In "Writeup Formatting Tips", you'll see:
"If you want to obscure some text for some reason (like the punchline for a joke, or the answer to a tricky question) then you should use <spoiler> tags."
Furthermore, given you've brought up semantics, the word "details" is hardly semantically correct for an element which, by default, does not show details.
You wrote:
"... it is also more correct to use the proper HTML tag."
No, that's just wrong. In "Markup in the Monastery", you'll see:
"PM markup code is NOT entirely w3c html 4.01 standard nor is it XHTML, so even if you're expert please scan these notes."
Reading the notes that follow will show it's NOT any other HTML version either.
There's also more information about spoilers.
You wrote:
"It might be a good idea to drop <font> as one day browsers might drop it."
In "Writeup Formatting Tips", you'll find:
"Almost any use of <font> tags will be wrong for at least some users, so you shouldn't use them. At all. The only reason <font> is allowed is for backwards compatibility."
[As I've included quotes from multiple sources, I've added 'You wrote:'
in multiple places to separate the parts of your reply to which I was responding.
In the initial preview without those, I thought there might be some confusion.
Except as an aid to sectioning, the emboldening is not significant.]
| [reply]
[d/l]
[select] |
|
|
My concern is usability and return of investment.
Why are you expecting users to learn two new intertwined markups while you yourself were already ignoring the spoiler tag?
I'm afraid in the end this will cost more time to implement than time invested applying it.
As I said i'm in favour of adding an automatic JS toggle to long code sections and shortening them by default if they exceed a certain limit.
No one will need to learn new markup and everybody could adjust it to his taste in the display settings.
Same with overly wide code, btw.
Edit: Alone the spared considerations to edit those posts will help justify the investment.
| [reply] |
|
|
I have my reasons for ignoring the spoiler tag.
- I don't believe in spoiler warnings, they are redundant on the web. Everything one reads, hears, and watches on the web comes with an automatic spoiler warning. (I quit Twitter for nearly a year only to have the end of the battle on Avengers: Endgame spoiled by watching the wrong YouTube video.)
- It is not valid html. (Yes, I know <readmore> isn't either.)
There is a way to make it so that people won't have to learn a new tag, and I can still have <details>. How about instead of using a <div>, <span>, or <table> with a <td> with the class of spoiler to make the spoiler tag, use the details tag instead with <spoiler> having Spoiler as the default <summary? <readmore> could use <details> also.
Another thing that would need to be changed is <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> to <!DOCTYPE html>.
I did not realize that asking for this would cause this much discussion. I did not think this would be a controversial idea.
My OS is Debian 10 (Buster); my perl version is 5.28.1.
No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!
Lady Aleena
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
"As the world moves to more mobile devices and plans that might have data limits, reloading pages is not optimal"
Nor is loading all of the content when the reader may not be interested. Requiring an additional click for the curious to find out, rather than loading it all anyway seems preferable to me.
| [reply] |
|
|
