Fathom: a framework for understanding web pages
hacks.mozilla.org
hacks.mozilla.org
As a web developer, this is exactly what I don't want. Just the other day I got bit by font boosting on Mobile Chrome. Couldn't figure out for the life of me why my h1 was bigger than I had explicitly specified. No traces of anything going on on the desktop either. Turns out, my page was being tampered with because someone at Chrome had a "brilliant" idea for mobile. The fix is to specify max-height to something inconsequential like 1000000px. My page just had a header, but font boosting destroys navigation menus and tiles too. Thank you but no thank you.
There cannot be any conflict between browser and web developer. If we have to fight and hack one another, we're both failing.
Font boosting needs to be explicit. And nothing should be done without the explicit intent of the author of the page.
If the browser wants to provide automatic login, then great. Please outline exactly how to enable it, make it as easy and automated as possible, and help decrease my workload. Thank you and thank you.
It sounds like you're understanding is wrong, You're css is a polite suggestion to the browser, nothing more.
If you want pixel perfect rendering then publish PDF's.
Then having to "politely suggest" max-height: 1000000px is not the right conversation.
But at that point if the customer screws something up, they understand that's on them.
All these features are great. They just need to be made explicit and obvious. Inferring what anyone wants let alone overriding what they said they wanted should just be a standard no no.
The best thing a browser could do for the author and the reader would be to explicitly say why something is broken and how to fix it. For example, "X is broken because of extension Y".
Browsers already have great analysis tools but there could be one more FYI breakdown where the browser would just tell you what it knows about any conflicts or issues it sees, and provide options. Something designed for the average user, but that could be extremely useful for authors also by providing a simple list of issues the browser sees about their page -- from an objective, browser POV. Input is always valuable. Acting on it without permission, not so much.
Perhaps there needs to be a distinction made between "standard web browsers in Standards Mode"—programs that nominally "obey" CSS, and should be chastised for deviating from it—and all other clients, on which you can place no such expectation.
(But even then, it's perfectly within the rules of CSS to apply UA styles at the beginning of the cascade. Usually those are per-browser, but there's no reason there couldn't be per-document ones generated from heuristics. Want to turn them off? Use a CSS Reset.)
The blind person explicitly turns on blind mode. This is not a difficult problem. Trying to guess if the user is blind is a hard problem.
If the user wants bigger fonts, they can zoom. If font boosting is a feature they would like on, then have them turn it on. If the author makes a crappy page it should be on them. The best thing a browser could do is let them know. And to visitors, provide options. But instead, they automatically enable these secret brilliant features that break random things. These are not solutions. These are the cause of many problems.
Automatic login? Great. Have a button. Have a feature. Don't do it in the background. Just let me tell you what I want. And let the page authors embrace those features and tailor them, and not wind up hacking them to tame their functionality.
If someone wants to develop what's essentially "automatic login, even for sites that would hate you if you did that: the browser", is that wrong?
Hell, this is essentially the same argument as the one behind ad-blocking. If someone wants to build a browser that—by default—alters your page to remove ads (surprise: someone does!), and people want to use that browser (probably: everyone), I don't think you have the moral high ground to tell them to stop.
Sure, you might be able to at least insist that they do some sort of feature-negotiation, where they tell you (maybe with feature-headers? a piece-wise replacement for UA-string heuristics, how lovely) what they're going to do to the page, and your server can then choose to do things like just not serving pages to people who have {font boosting, ad-blockers, etc.}; or redirecting to a page telling them their browser is bad and they should feel bad.
It's words like these. We should not be looking to negotiate with anyone -- not as an author, and not as a consumer.
If someone builds an auto-login browser, or an auto-login feature, then fine. But when Mozilla decides to put this in by default without telling everyone, then not fine.
If font boosting was part of some cross browser mobile web standard then fine. But if you're Google and it's a feature specific for your browser, and you turn it on be default, then not fine.
Of course, it seems like the premise is always that your feature can do no harm. But in practice it's always the opposite. There are always edge cases where something is broken or not right, that leads to these features as a cause.
Login is actually extremely important. To tamper with the behavior of the browser when it comes to logins, and to do it automatically, seems extremely dangerous.
But either way, it's about communication, not negotiation. If the user wants to turn it on, great. If the author turns it on, great. If no one turns it on, but the browser developer just "thinks it's a good idea" for every site ever built, then not great.
A) Developers hack their way around to the result they want anyway, or
B) Users of that browser lose a chunk of the experience.
Either way, everyone loses.
When I read a site I want to read it in the colors and fonts I want, not what some designer things looks nice.
The web was designed to work this way.
Web designers think web pages are like magazines, that they get to dictate layout. And most of the development in web browsers and standards lend themselves to that view.
As a user, OTOH, I think of web browser as my User Agent. I accept "polite suggestions" from the website, but ultimately I should have the last word about how it looks. The web was originally designed to work this way.
I'm not sure how to reconcile those views. I'm obviously biased towards the second, and I'd love web developers to be told to bite it. But this, unfortunately, won't work, because there are strong business pressures to the contrary.
I hope that's sarcasm. PDFs are similarly beholden.
Your fix should be to ensure your site continues to work when some of your CSS is ignored.
CSS can be used for many things; that's part of the beauty of an open standard. I don't see what's wrong with those users pushing to maintain their ecosystem on a platform which clearly can support it to create works which benefit everyone.
But as for those use cases... well, it just makes me sad. Obviously people have perverse incentives to make the kind of noise that Mozilla is bemoaning, and those people will find a way to game any system --- especially a highly readable one!
(Author here.) In fact, Fathom isn't particularly coupled to the DOM, apart from the dom() call that acts as the initial source of data and some of its optional utility procedures. With a few tweaks, you could use it for any score-and-rank problem.
If stores using microformats and semantic markup is important then give value added to the places that support it and people will start using. If readability is important start penalizing sites with bad readability indexes. But please don't take over my UX. I can't think of a faster way to stifle innovation.[1]
Try the documentation, much less political https://mozilla.github.io/fathom/intro.html#why
[1] That's an exaggeration. I can think of lots of better ways.
But, how do you think that a browser could theoretically penalize a website?
Easier to do on a search engine. But for a browser they already do: many browsers are or plan to call out sites that don't use HTTPs.
Or as another example: the warning that happens when you try to access a page that uses a self-signed certificate.
Granted the penalty needs to be proportional to the crime. So maybe the penalty and value add go together. If the value add is a useful feature that everyone wants and demands then not having it becomes a penalty to the sites that don't offer it.
That's relatively easy to do when you're Google and you develop both a browser and the most used search engine; not so much when you're Mozilla and have no apparent mean to apply pressure to websites.
The thing is, it's not your UX, it's my UX. The more power I have to easily clean out all the "design" crap websites throw at me, the better my experience and convenience in using the web.
In my opinion, absolutely not true. If a UX annoys you so much that you don't want to use a site... stop using that site. That is the power you have. Vote with your wallet. You have the power to deprive the site of your business. That's it. Not to remove ads, not to change the UX, just to stop using it.
But to be clear. I actually lean towards agreeing with you up to a point. And I think the topic shifted slightly from my original intend.
But it is my opinion that the point you are pushing it on other people (by bundling it with your browser) is where I draw the line. I'm okay if you, TeMPOraL do some post processing of the data but if Mozilla (a browser) or Comcast (an ISP) does it on your behalf without your say and without the content creators say.
Especially considering that I am responsible for customer service on my own site.
> Especially considering that I am responsible for customer service on my own site.
That's a reasonable position I haven't considered. Thanks.
Here's the code in that project which uses Fathom: https://github.com/mozilla/page-metadata-parser/blob/master/...
Certain choices cause divergence, they increase your optionality in the future. Other choices cause convergence to one thing. Convergence is only desired if and only if the one true thing is the one true thing.
So neither divergent nor convergent thinking is good in itself unless you apply another filter on how you see the future. You either see messiness as indicative of the future having possibility, or you see the present as a broken world in need of fixing. (Or isolated areas of perfection needing protection and isolation)
It seems that even though people keep trying to use CFAA for scraping it almost always gets thrown out as long as the source is publicly accessible. Even if the ToS prohibits scraping explicitly.
Seems people have had more luck with just plain old copyright.
But back to this tool in particular... depends entirely on what you are using the data for. Don't use it to gain access to data you wouldn't normally have or give other people access to data they wouldn't normally have and I can't see why CFAA applies.
"on a selection of" its own test cases = lol
> Fathom is a data-flow language like Prolog, so data conveniently “turns up” when there are applicable rules that haven’t yet seen it
Why are you trying to explain the concept of declarative programming without just telling people about declarative programming? Just because it's not common in a scene doesn't make it some proprietary concept you've just introduced there.
> The best part is that Fathom rulesets are data
That's actually kinda nice
> In 70 lines,
Insert that comic about 'just a few lines' masking the function calls that actually don't 'replace' a system, just change where work is being done when flexibility is not needed
Do you have link for that comic? I think haven't seen it. The concept you describe is very important though - abstractions like that are usually about moving complexity around (compare Turing tarpit - all Turing-complete languages are in principle equivalent; the difference is in their distribution of complexity along the axis of programs you want to write).
> "on a selection of"
One has to start somewhere! At this early stage, my aim is to demonstrate that Fathom has value for simplifying the implementation of recognizers, not to claim a polished, production-ready Readability alternative.
Though, frankly, getting to the latter would be a fun project for someone: just write more features (in the ML sense), and add more tuning data. There are lots of low-hanging TODOs in the code around https://github.com/mozilla/fathom/blob/master/examples/reada....