News for hackers. Stuff that matters.
Re:uBlock Origin: Address first-party tracker blocking by folkrav on Thursday November 21, 2019 @12:26AM (#21591678)
"Dealing with it" basically means re-building a browser rendering engine inside the browser renderer.
Re:uBlock Origin: Address first-party tracker blocking by naniwaduni on Thursday November 21, 2019 @02:16AM (#21592053)
You don't need to build a browser rendering engine, with everything that entails; you only need to render your content. This is a much easier problem.
Re:uBlock Origin: Address first-party tracker blocking by folkrav on Monday November 25, 2019 @10:26AM (#21628879)
For accessibility compliance, you _need_ text and a DOM. Screen readers rely on HTML element semantics, ARIA attributes, and text content. The only way to make a canvas element (which is what you'd typically need to render custom UI) accessible is to have a textual fallback.

Outside accessibility there's also the issue of responsive design, huge SEO impacts, rendering performance... I'm probably missing a bunch.

Lifting a sedan with my bare hands is obviously easier than lifting a 10 wheeler, but it's still a massive problem. Rendering stuff is not the biggest issue.

Re:uBlock Origin: Address first-party tracker blocking by EvanAnderson on Monday November 25, 2019 @07:39PM (#21634529)
Embed a browser with all that stuff into a page. Whatever APIs are missing to make the "inner browser" unable to fulfill all the requirements that the "outer browser" will eventually be filled-in by well-meaning developers who want the Javascript VM in the "outer browser" to be able to host general purpose applications.