4 ms·

AFAICT, there's not a way to get those nice hover effects with a <map>, at least not without a bunch of JS.

Groxx 4y ago
Yeah, my first thought was <map>, then I moused over it and noticed how utterly trivial this would be to re-style in comparison. This is a good approach, I think. It's kinda fine-tuned for reMarkable output, as it's mostly pure black or white pixels, but clearly they're fine with that. And the end result works quite well, and seems as easy or easier to implement. This is all also kinda made moot by there being a link to an excellent transcript at the bottom. Accessibility needs are better covered by a straightforward alternate page than <map> alone.
saghm 4y ago
Not sure if I triggered some sort of race with fast mouse movement or my mouse being over the link before it appeared or something, but for me on Firefox on Linux, the blue color went away when I hovered my mouse over a link. I'm not sure if that's really a benefit; it honestly confused me and made me think that I wasn't actually hovering over a link at first, since that's not how traditional links work.
- LukeShu 4y ago
  (Also on Firefox on Linux) I can't begin fathom how that could happen. It's not some fancy JS thing, it's a very simple CSS effect: a:hover { filter: opacity(0.5) !important; } .post a { background-color: #35c; mix-blend-mode: screen; position: absolute; display: block; } Do you maybe have a user-stylesheet that overrides something about links? But I can't think of anything that makes sense that wouldn't also break the non-hovering version too. Does opacity() combined with mix-blend-mode maybe not work right on your box? I'm not sure why it wouldn't, but you can convince me of just about anything by saying "Firefox does weird things on some GPUs".
  - saghm 4y ago
    I do have some custom CSS stylesheets installed, but none of them seem to be active on that URL. I did do some messing with my GTK and Gnome shell themes a few weeks ago, and I noticed that it strangely seemed to have some parts of the NY Times crossword site use a dark background where they didn't before, so maybe that's affecting it somehow?
  - chrismorgan 4y ago
    Blending stuff is a particularly unreliable part of the web platform, because GPU drivers are astonishingly bad, and a lot of the functionality is poorly exercised. The situation has improved enormously in the past decade as a few things have started to use the GPU and so there’s been more attention to it all. For Firefox, the Quantum Render project ironed out almost all the problems so that bugs are now fairly rare. For web content in general and especially in other browsers, I suspect that Google Maps switching to WebGL single-handedly drove most of the improvement that has happened (even when it comes to identifying and blacklisting bad drivers and deliberately falling back to a software implementation). But quite seriously, rejoice that you’re using Firefox. It has very few blending issues in general. I’ve found the Chromium family to be vastly buggier in this area, and I’ve learned when doing almost anything with filters and blending to develop with Chromium—previously I developed with Firefox and everything would just work, and then I’d test it in Chromium and discover some important bug or fundamental undocumented limitation in Chromium which meant I had to start again with a different approach, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=992398 https://bugs.chromium.org/p/chromium/issues/detail?id=992398 where a perfectly normal combination of things just stopped rendering the page after 8,192 pixels (which isn’t all that much); or for something more recent (earlier this year) look at the source of https://temp.chrismorgan.info/2022-10-03-hand-drawn-with-links-demo.html https://temp.chrismorgan.info/2022-10-03-hand-drawn-with-lin... and see some of the compromises I made for Chromium.

Yeah, my first thought was <map>, then I moused over it and noticed how utterly trivial this would be to re-style in comparison. This is a good approach, I think. It's kinda fine-tuned for reMarkable output, as it's mostly pure black or white pixels, but clearly they're fine with that. And the end result works quite well, and seems as easy or easier to implement. This is all also kinda made moot by there being a link to an excellent transcript at the bottom. Accessibility needs are better covered by a straightforward alternate page than <map> alone.

saghm 4y ago

Not sure if I triggered some sort of race with fast mouse movement or my mouse being over the link before it appeared or something, but for me on Firefox on Linux, the blue color went away when I hovered my mouse over a link. I'm not sure if that's really a benefit; it honestly confused me and made me think that I wasn't actually hovering over a link at first, since that's not how traditional links work.

LukeShu 4y ago
(Also on Firefox on Linux) I can't begin fathom how that could happen. It's not some fancy JS thing, it's a very simple CSS effect: a:hover { filter: opacity(0.5) !important; } .post a { background-color: #35c; mix-blend-mode: screen; position: absolute; display: block; } Do you maybe have a user-stylesheet that overrides something about links? But I can't think of anything that makes sense that wouldn't also break the non-hovering version too. Does opacity() combined with mix-blend-mode maybe not work right on your box? I'm not sure why it wouldn't, but you can convince me of just about anything by saying "Firefox does weird things on some GPUs".
- saghm 4y ago
  I do have some custom CSS stylesheets installed, but none of them seem to be active on that URL. I did do some messing with my GTK and Gnome shell themes a few weeks ago, and I noticed that it strangely seemed to have some parts of the NY Times crossword site use a dark background where they didn't before, so maybe that's affecting it somehow?
- chrismorgan 4y ago
  Blending stuff is a particularly unreliable part of the web platform, because GPU drivers are astonishingly bad, and a lot of the functionality is poorly exercised. The situation has improved enormously in the past decade as a few things have started to use the GPU and so there’s been more attention to it all. For Firefox, the Quantum Render project ironed out almost all the problems so that bugs are now fairly rare. For web content in general and especially in other browsers, I suspect that Google Maps switching to WebGL single-handedly drove most of the improvement that has happened (even when it comes to identifying and blacklisting bad drivers and deliberately falling back to a software implementation). But quite seriously, rejoice that you’re using Firefox. It has very few blending issues in general. I’ve found the Chromium family to be vastly buggier in this area, and I’ve learned when doing almost anything with filters and blending to develop with Chromium—previously I developed with Firefox and everything would just work, and then I’d test it in Chromium and discover some important bug or fundamental undocumented limitation in Chromium which meant I had to start again with a different approach, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=992398 https://bugs.chromium.org/p/chromium/issues/detail?id=992398 where a perfectly normal combination of things just stopped rendering the page after 8,192 pixels (which isn’t all that much); or for something more recent (earlier this year) look at the source of https://temp.chrismorgan.info/2022-10-03-hand-drawn-with-links-demo.html https://temp.chrismorgan.info/2022-10-03-hand-drawn-with-lin... and see some of the compromises I made for Chromium.