I tried to create a simple invoice for Spain, and it was impossible. I need to be able to add a different tax which is actually negative (-15%) but can't be done.
Looks amazing, but its too rigid.
I think the default target is expecting a smaller screen mobile device, hence the 13px default. This is a good idea, and any other screen sizes that see smaller text can still zoom in using default browser behaviors.
I disagree with your disagreement, for example HN is readable but the linked site feels too small for my eyes on a 21.5" 1080p monitor. It also doesn't respect browser preferences, unless you enforce a minimum font size (which can break display elements on other sites):
There's no reason why you couldn't have smaller font while still respecting browser scaling. However, they might also want to just leave it at 1 rem and let the folks that prefer higher information density to customize their own browser settings, since those are what most well developed sites should respect and it might be more accessible by default on most devices (for my eyes, at the very least).
As for targeting specific screen sizes for non-standard font scaling, media queries also would help!
In regards to missing information dense pages, try changing your browser font settings, it might actually be quite pleasant for you to see many sites respecting that preference!
I agree that too many sites now will narrow the text area and pad too much. The issue here is a fixed pixel size that will look quite different depending on the specific monitor setup you have.
And honestly if this type of thing bothers you as much as it does me, unfortunately it means adding a bunch of stylus sheets everywhere...
Thin Black Bar
Occasionally, there will be a thin black bar at the top of the top bar, in memoriam of a significant figure in the tech/science community dying. A Hacker News submission about the death will usually be on the front page at that time.
> i was thinking "You need to use the backend the info shouldn't be traveling to the client"....
If it leaves the server, it’s available to anyone who has access to the display device.
And if it’s meant to be displayed to the end user - as this content is - it needs to leave the server.
There is just no other way to have the user see that info.
That’s the same no matter what you want to serve up, be it dollar values or images. Nothing prevents a person who has full control of the display device from copying it or gaining access to it.
I’ve run into that problem before, most notably with a client who - back in the 90s, so the very early web - desperately wanted a website with large, stunning photographs of the product his company was making, but he wanted 100% assurances that no photo could ever be copied locally and “stolen” off of this website. In the end, I had to tell him that anything that is visible to an end user is fully copyable and “stealable”, and there is nothing that provides even a fractional assurance, much less a complete assurance against “theft”. Because that’s the fundamental nature of any website.
Even in today’s web environment, screenshotting the display utterly circumvents whatever display protections may exist against copying content, because screenshotting occurs outside of the web browser.
What OP’s solution is, however, is a protection against shoulder surfing, and nothing more. It’s the result of a flag that the user can enable so that others in the vicinity aren’t going to be able to visually snoop. And for that objective, this font is ideal, especially since the raw values still need to be summable by the client-side code. And client-side code that works with text values is utterly unaffected by font choice.
This is to protect against shoulder-surfing. Having the information present on the client and accessible to the user while appearing redacted is very much the point.
reply