Comment by notpachet | Hacker News Reader

Comment by notpachet | Hacker News Reader

Parent Full thread

I was happy to find that this article ended up focusing on the need for better web automation tools specifically. That's a very big problem right now. HTML is becoming more and more impenetrable to the end user. It's essentially just a delivery vehicle to get low-level presentation instructions to the browser. That gives a lot of control to the owners of the web page at the expense of the user. "With software, either the users control the program or the program controls the users", I think is the relevant quote.

HTML's building blocks are too low-level for our contemporary needs. We should gradually move to higher-order representations of the data we're exchanging online, and put pressure on companies/governments to expose their data using these representations. My browser (or the extensions I add to it) should be able to natively determine whether it's looking at a product listing, or a person's bio, or a social media post, because those blocks of information would adhere to a standard schema ("hooks", to use the article's term).

Naturally, companies that are in the business of putting things in front of your eyeballs don't want us to move in this direction, because it gives users much more control over what they see than they have today. If you don't want to see ads, tell your browser to skip rendering the <Advertisement /> element. (And if a company places ads outside of an <Advertisement />... I dunno, fine them?)

(Those of you who've been around long enough are probably wincing and rubbing your RDF scars, or your XML scars, or what have you. Yes, it's the same old fight. We have to just keep pushing until we make some headway.)

A few years ago, I implemented UI automatic tests on a bunch of iOS apps. The Apple go-to framework was UIAutomation. It was a pretty good tool for this job, albeit limited.

What I liked a lot was that the framework relied upon accessibility. To automate the testing of an app, you firstly had to make sure that the app was really accessible and then you could built upon accessibility attributes to add automatic testing.

I found it very smart because developers were incentivized to make their app accessible. Accessibility was, in a way, a tool to describe semantically a UI, so a screen reader, a test framework, the OS could understand how the UI was structured and acted upon.

One of my (really) old post about UIAutomation: http://blog.manbolo.com/2012/04/08/ios-automated-tests-with-...

react-testing-library also emphasises this albeit not so much focused on accessibility, but writing good semantic code with stuff like dom-testing-library https://testing-library.com/docs/dom-testing-library/intro/

> It's essentially just a delivery vehicle to get low-level presentation instructions to the browser.

Nothing about HTML is low-level.

HTML (and most of web tech) suffers from being both not low-level enough and not being high-level enough.

You can't override the browser and provide your own rendering pipeline if you wanted to actually do your UI [1] You can't tell it to batch rendering/update instructions for a subset of elements on the page. You can't compose elements. You can't use existing building blocks to combine them and build a proper new element [2] You look at a web-page funny, and it does a layout re-calculation [3]. And that layout recalc? It's abysmally slow. That's why you can't even animate anything useful. And so on and so forth.

[1] It's now possible wit Canvas and WebGL, but this is not web tech, not really. It's desktop tech that has been around for ages, and is now being bolted on to browsers.

[2] No, not really. Try and make a full dropdown/combo box that is properly customizable, keyboard-accessible, etc. Many have tried, all are abominations.

[3] Even things like border widths and some times even border colors wil cause a layout recalc: https://csstriggers.com

I meant low level in terms of the semantic meaning that HTML can convey.

The examples you gave of places where browsers are high-level in terms of what pixels get put where? I see those as features, not bugs. I'm actually happy that web browsers historically haven't given pages a lot of control over low-level rendering, and I am distressed by the ongoing push by large corporations to increase how much of that control they have access to.

I agree with your point about not being able to compose higher-order elements, though.

But who will enforce these guidelines?

Google said a couple years ago that they would penalize sites with dark patterns (like forcing users to sign-in to view public pages). Doesn't look like Google enforced anything since all the major sites are using the same dark patterns now.

Google can’t really enforce things as much due to the anti-monopoly/competitive political threat. They can adjust search rankings but anything major can be used as an argument to break google up.

Yes but Google already penalizes websites that are slow to load, not secure, using black hat SEO, etc. Google could easily penalize dark patterns under the same approach, but they don’t. Google themselves said they would implement this years ago[1] and it has yet to happen.

1. https://www.fastcompany.com/3063143/google-calls-out-one-of-...

Ideally we'd institute government regulation requiring website operators to offer the user-friendly formats, in the same way that GDPR places certain requirements on sites today.

Has anybody seen a successful version of this with web components? It seems like we should be able to test the theory of higher level web elements and see how far it goes.

Reply on news.ycombinator.com