|
|
|
|
|
|
by mattkahl
3753 days ago
|
|
|
The "You name a critical .js bundle something related to ads" point is something toward which I'm particularly unsympathetic. The fact that most ad blockers (a) are whitelist-based and (b) contain blunt-edge/naive implementations leads me to believe that false positives are the problem of the ad blocker developer and ad blocker user, not the developer of the website. If Joe or Jane developer of Acme Demolition Inc. names a Javascript file `ad_main.js`, the burden of resolving the my-ad-blocker-is-blocking-this-file problem is not on them. This is why I've yet to find an ad blocker that I would recommend to anyone without web development knowledge. |
|
|
People will bend the Web to suit their goals. You as a web dev with a need for ads revenue focus on that. Me as a web user with a need for information and pathological hatred of anything distracting, focus on my needs. Users with visual and motor disabilities (I support a community of same) are quite actively thwarted by many revenue-positive factors.
My fix for a bunch of Web gunk is to have a default set of client-side CSS that kills, well, a bunch of crap. Flyovers, modals, interstitials, fixed header/footer elements, and a slew of other stuff. Ello's front-end guy pretty understandably said it voided my warranty for the World Wide Web. And he's not wrong.
But man does it make things suck ever so much less.
Which gets to the point: much of the stylesheet is glob-match patterns on descriptors that are frequently annoying as fuck-all. Which was why I'd showed it to him. That sheet, or others like it, are going to be in the client world, and soon, and if you're putting flyover and modal keywords in your selectors, they're going to get blocked.
Yes, it's an iterative arms race. Your turn.
(And: ultimately the solution is to fix the revenue/compensation model for published works. Online and elsewhere. That'll take a while, but it'll also fix very nearly everything wrong with the present iteration of the Web.)