Some notes on Firefox's media autoplay settings in practice as of Firefox 124

Re:Some notes on Firefox's media autoplay settings in practi... by dredmorbius on Saturday March 30, 2024 @02:54PM (#39877565)

This is a further issue for those using e-ink devices (tablets, e-book readers, monitors), where rapid animation at higher quality settings is exceedingly disruptive --- stuttering, screen-flashing, and the like. (It is possible to display animations, if desired, at reasonable refresh rates using lower-quality display settings, e-ink offers a trade-off between text quality (resolution, ghosting) and refresh rates. But as if there needed to be additional arguments to put a hard stop on highly-distracting design elements, this really stands out.)

I've also found it ... interesting ... to note that a single Web page often has the memory footprint of an entire book (a few MB for just plain text, though that can balloon upwards with complex typesetting and graphics), and that even a browser optimised for e-ink (Einkbro) has roughly 10x the power consumption of the stock ebook reader (Neoreader) on my Onyx BOOX tablet (labeled as an e-book reader, but in fact an e-ink based Android tablet).

I can read books for days on a single battery charge. I can browse the Web for ... a few hours.

[ Parent | on HN ]

Re:Some notes on Firefox's media autoplay settings in practi... by skydhash on Saturday March 30, 2024 @03:23PM (#39877786)

While the web allows for a lot of creative expressions, I think we should have companion protocols for alternate consumptions methods, something like Gemini for every page. An e-ink reader is good for focused reading, but bad for interactive or animated content. Just like gwern.net allows to add `.page` to every link and get the raw source, you could add `.gemini` to wikipedia pages and get a much simpler document that you can read on e-ink reader or a cli device (should be good for accessibility too).

[ Parent | on HN ]

Re:Some notes on Firefox's media autoplay settings in practi... by csande17 on Saturday March 30, 2024 @03:55PM (#39878052)

Wikipedia kinda has this already:

https://en.wikipedia.org/wiki/Taylor_Swift?action=render

https://en.wikipedia.org/wiki/Taylor_Swift?action=raw

[ Parent | on HN ]

Re:Some notes on Firefox's media autoplay settings in practi... by dredmorbius on Saturday March 30, 2024 @07:10PM (#39879558)

Wikisource as well, where one can choose HTML, ePub, or PDF on most documents.

Other sites permit one to append ".json" for a raw JSON feed.

[ Parent | on HN ]

Re:Some notes on Firefox's media autoplay settings in practi... by dredmorbius on Sunday March 31, 2024 @10:41AM (#39884708)

Update: as I noted in another comment, both Wikipedia and Wikisource of course run MediaWiki as their wiki engine. Not sure if the HTML/PDF capability is baked in there or not.

[ Parent | on HN ]

Re:Some notes on Firefox's media autoplay settings in practi... by dredmorbius on Saturday March 30, 2024 @09:29PM (#39880494)

I'd really like to see something like this and have thought that an online publishing engine which would produce HTML, ePub, PDF, or other output formats or endpoints on demand might be useful.

There are sites already which provide some form of this, notably sites using MediaWiki (which notably powers Wikipedia and Wikisource) offer multiple download options, though I don't think it's quite as flexible as I'd prefer.

Client support would be the other factor, with current Web browsers not being particularly multi-format. Though to be fair, Firefox, Safari, and Chrome all now natively support PDF documents.

I suspect that a render-to-ePub would be a much better alternative to standard HTML for mobile devices. ePub is inherently fluid, and tends to offer a subset of full HTML capabilities. (ePub is of course an archive of HTML, stylesheet, and other elements, though usually it's more strongly textually oriented than the modern Web is.)

For sufficiently large tablets, PDFs are actually a quite good document format.

[ Parent | on HN ]