💾 Archived View for 9til.de › lobsters › v1yooo.gmi captured on 2023-11-14 at 07:47:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
.----------------. | .--------------. | | | _____ | | | | |_ _| | | | | | | | | | | | | _ | | | | _| |__/ | | | | | |________| | | | | | | | '--------------' | '----------------'
Viewing comments for "Proposal: an HTML element for spoilers"
---
ojii commented [18]:
I wish it were possible to look up any medical issue without
being exposed to the most graphic photographs ever taken by
man or beast.
I couldn't agree more with this. I wish browsers had a
global "disable all images" toggle somewhere for exactly
this use-case.
> 0x2ba22e11 commented [8]:
Firefox definitely used to have this. I've used it before
as options - content - untuck "automatically load images".
I think it still does but it may have been taken out of the
main menus.
First couple search results claim there's an about:config
setting called "permissions.default.images" which you can
set to 2 instead of 1, but I'm not at a desktop right now
to check.
> Seirdy commented [4]:
I can confirm it works well. I use it regularly in the
Tor Browser as part of my Fediverse moderation work. It's
invaluable whenever I get a report of an instance permitting
lots of, uh, "legally risky media".
> stip commented [7]:
Same, but also for phobias. Searching for any phobia always
shows dozens of photos that trigger said phobia ..
> ojii commented [1]:
after a "disable all images" toggle, a "disable all images
of this phobia" (maybe with LLMs we have the tech for this
now?) toggle would be my second most desired feature. (also,
phobia options for video games please)
> coby commented [2]:
As someone with a mild visual phobia this would be amazing!
> david_chisnall commented [6]:
This used to be a standard browser feature, back when a
typical user used a 9,600 baud modem (14.4 kbps if they
were fancy) and a plain HTML page took several seconds to
download. I remember browsing on the university connection
(which could download at 300 KiB/s!) and realising, for
the first time, I could browse with auto loading images by
default and it not be slow.
The past was a bit rubbish, but I do sometimes miss that
button. It's in the Develop menu on Safari, so I don't miss
it that much.
> xnacly commented [5]:
Ublock origin has exactly that, for disabling external
fonts, media and scripts on a page.
jcm1 commented [6]:
Not mentioned in the list of use cases is puzzle solutions,
the puzzle/riddle/puzzle game community would really benefit
from this.
freddyb commented [4]:
This is a great write-up for making the case. But isn't the
bar for a new HTML element much higher?
It seems to me, all of this can be done without new
elements.
> kornel commented [8]:
Is it so high though? In my days HTML5 used to be pretty
open to adding new elements and attributes. It's got a
bunch of niche less-used elements, like <mark>,
<hgroup>, <dfn>, and <meter>. HTML5
also added elements like <header>, <main>, and
<search> for predefined ARIA roles.
So I don't think the current set is some holy perfection
that shouldn't be disturbed. If there's a common use-
case, which does something useful in user-agents and search
indexes, then it could be easily added.
> xigoi commented [3]:
I think <meter> would be more useful if it was
possible to style it without unstandardized vendor prefixes
that don't work half of the time.
> Seirdy commented [2]:
Around a month or two ago, we got search. But that wasn't a
big ask since it filled a hole in HTML for an ARIA role with
no corresponding HTML element.
> JohnDeHope commented [1]:
A lot of programming languages and data format specs could
use a little deprecation and cleanup. An HTML 6 that cleans
house with respect to some of the tags you mentioned would
be nice. Backwards compatibility to the early 80s can become
a liability, not an asset.
> gerikson commented [1]:
early 80s
Wow, HTML is older than I thought!
> kornel commented [3]:
SGML is. The Web was created in 1990.
> JohnDeHope commented [1]:
Okay, you're right .. early 90s ..
https://www.w3.org/wiki/HTML/Specifications
Still, a long time ago, long enough that maybe the original
specs aren't worth adhering to any longer, in every single
detail.
> gerikson commented [1]:
I'd hate for the stuff I wrote for the web in the mid-90s to
no longer be readable in modern browsers, but maybe that's
just me being vain.
> olliej commented [4]:
indeed, if anything this would be a new ARIA role
> kevincox commented [4]:
I think it can for any one site but I think it can be much
more powerful if this was native to the browser.
Consistent interfaces, from simple like click-to-reveal to
more complex like keyboard shortcuts.
Ability for the user to select what content they want
hidden by default and what they want shown by default (but
hopefully not revealed to the website so it doesn't add to
their fingerprint).
Possibly better interaction with accessibility tools, and
almost certainly better by default.
No need to re-implement on every different site.
No need for JS.
JohnDeHope commented [3]:
While a disclosure widget exists to allow toggling
information, a spoiler exists to make information
inaccessible without consent: invisible, inaudible,
unreadable. A disclosure widget helps divert user's
attention away from hidden text; a spoiler protects users
from hidden text.
The question shouldn't be "can I think of a semantic
distinction". If that's the bar, every conceivable HTML
element will be introduced. For my money, the details
element should get a much stronger sales pitch as the
solution to this problem.
> Seirdy commented [2]:
Yes, this wasn't the only reason. The primary reason
was that it already had such widespread use, but no
standardization and inconsistent accessibility+behavior.
epilys commented [2]:
A screen-reader user could chime in: would this require
interaction by the user? (e.g. using a command to read the
spoiler content). Is that user friendly?
> hauleth commented [5]:
On the other hand, for screen reader there is currently no
way to mark something as a spoiler right now. So if person
with sight disabilities tries to read community channels
about their favourite book series or something they are
stepping into minefield of spoilers that their readers
cannot prevent.
> repl commented [1]:
Isn't this already solved how we solve it in real life
discussions? By adding a little warning that says "There are
spoilers ahead!"?
> hauleth commented [2]:
Sure, but what if only part is spoiler? Like it often
happens on Reddit or Discord.
> tigerstyping commented [3]:
I think this is where the idea has the most potential
value-- being able to say "this is where spoilers end" is
just as important as saying "this is where spoilers start."
Being able to know that without reading, hearing, or seeing
the parts in between is ideal.
toastal commented [2]:
How would you propose a TUI browser & print mode best
handle this element?
(Also, how best to subscribe to updates to this? ..I
want to see some revisions in action while I mull over my
<callout> proposal & the changelog is great idea)
> easrng commented [1]:
For printouts, behavior should mirror details. Print hidden
if it's hidden in the browser, and print revealed if it's
been revealed in the browser.
for tui browsers the spoiler should be focusable just like a
button or link or whatever
david_chisnall commented [2]:
Note that, although details is a block-level element, you
can use the inline block display mode to present it as
something inline. I use this in my publications page to
provide 'BibTeX' and 'abstract' links in the bibliography
and have them turn into block-level things when expanded.
I'm not convinced that there's a downside to doing this with
summary/details and a spoiler class.
> Seirdy commented [1]:
I describe other differences: different find-in-page
behavior, the optional-ness of the spoiler child, preventing
the revealing of spoiler contents before preview text has
been read, etc.
> david_chisnall commented [1]:
I'm not sure that I'd want find-in-page to find things in
spoilers, that would accidentally reveal them. At least
in Safari, it doesn't look in details. I don't really see
anything in your list that can't be controlled via CSS.
In general, I'm in favour of better semantic markup, but
that ship sailed with HTML5 and the push from Google to
avoid any clean separation between content and ads.
> Seirdy commented [3]:
It appears that Chromium expands details for in-page search,
and I imagine that some assistive technologies may open
a details element when jumping to a link or heading. The
specification doesn't forbid such behavior. For a spoiler,
it would.
JohnDeHope commented [0]:
An interesting situation cropped up reading this
blog post .. the use of the world 'children' needed
disambiguation in a few places. Are we talking about young
human people, or enclosed HTML elements? There were a few
places where I had to pause to think about it. I'm not
normally a big fan of policing language, but in this case
I can see how re-using common words sometimes makes things
more confusing.
---
Served by Pollux Gemini Server.