Hacker News Reader

Comment by fairpx | Hacker News Reader

As a UI designer, I dream of strikeheadlessstrike chromeless browsers, where the UI appears when you need it, intuitively, even when NOT in full screen. The top bar simply takes too much unnecessary space. If there's any dev that wants to collaborate on this, let me know :)

View on HN

A small nomenclature clarification seems to be in order:

"Headless" means without output. It is often used to describe servers without any attached monitors (the monitor would be the head that it is missing), but can similarly be used to describe browsers that do not even create a window on your desktop. It simply runs as a service that can be scripted.

What you are looking for, I would rather call "chromeless". The browser is there, but it has no visible UI-components outside of the webpage.

> What you are looking for, I would rather call "chromeless". The browser is there, but it has no visible UI-components outside of the webpage.

Why "chromless" and not just "Full screen"? The latter is what that mode has been known by for decades? Or is it a subtle distinction that "Full screen" mode can show the location bar by moving the mouse to that edge of the screen (at least in Firefox 55), while "chromless" never lets you see the location bar?

Those are two orthogonal concerns. A (theoretical) browser in full screen mode might or might not display UI elements/browser chrome. A windowed browser might or might not display browser chrome.

A chromeless windowed browser would look something like QuickTime in macOS, if that helps you; the window consists entirely of the playing video until you mouse over it.

I really hate this trend in UI design. I have to scroll back half way up the page in iOS Safari to get the menu bar to display again, for example. I've watched a lot of non-technical users struggle to figure out what magic they have to perform to get an app's controls to even appear.

Your job is to make things usable & functional, not pretty.

That's not headless, it's chromeless.

Anyway, IE11 on Windows 8 (tablet mode) had that, and it was amazing (assuming you used the touch screen, that is - the UX wasn't so fantastic with a mouse).

It's the only thing from Windows 8 I miss in Windows 10.

From a security POV, the URL being displayed at all times is absolutely necessary in order to avoid phishing.

I think there are certain elements that can be displayed differently. So maybe semi-headless is the solution.

Sounds like any browser when full-screened on macOS.

Or popups? Just imagine how realistic I could make a popup box seem know people will just think that it is from the operating system which I can also detect in another headless window along with another transparent window for bitcoin mining...I think you get the idea. UX yeah this is neat for appliances it will make for more seamless experiences, lets just hope you all are sanitizing inputs and building in secure methods of auth to make the experience worth the risk.

No it isn't, the URL is unreliable source of truth with Unicode spoofing attacks and things like that. Safari only shows the domain at this point; the URL is an unimportant implementation detail.

It would be cool if browsers could highlight URLs that contain the kind of characters which are commonly used to spoof, though I suppose it would lead people to a false sense of security.

Just set your browser to always show punycode. On Firefox,

  network.IDN_show_punycode = true

URLs are no place for unicode characters to hide in. An xn-- prefix is all the warning you need.

Your claims are false for the majority of the world's population (which lives in non-English speaking countries and may well want to visit sites whose names make sense in their own language).

That's why Firefox detects if the URL mixes together symbols from different languages:

https://wiki.mozilla.org/IDN_Display_Algorithm

Much better than showing punycode all the time.

So sites such as bücher.de (I originally had a link here to the site, but HN punycodes that: http://xn--bcher-kva.de/ ) shouldn’t exist?

That’s a very america-centric world, it’s like enforcing only US-ASCII on all websites. Most of the world doesn’t speak English, and browsers showing domains punycoded leads to mistrust, especially if it’s a legitimate retailer (the one mentioned above actually added a redirect to a romanized version of the URL due to that)

Firefox [0] and Chrome [1] have policies for when to show Unicode and when to show raw punycode. You can also set flags to force them to show punycode all the time.

[0] https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm

[1] https://www.chromium.org/developers/design-documents/idn-in-...

Cyrillic Er looks exactly like Latin P, so writing apple with Cyrillic "Er"s would likely be spoofing. But if you highlight all instances of Cyrillic Er, you also have to highlight every P, since the URL of a Russian bank spelt with Cyrillic Er could be spoofed with Latin P.

In the end, you would just highlight nearly everything. A more useful approach would be to highlight when you switch script inside a domain name. That seems to be what firefox does for non-whitelisted domains (with some more rules to allow eg www.stマイクロ.jp (ST Microelectronics in japanese))

How would you differentiate say: "http://googlemail.buyviagra.com"

From: "https://mail.google.com"

If they looked the same.

Urls to be shown punycoded at all times. Not pretty but might be necessary. This should gain some momentum before emoji urls go mainstream

You mean, before the 90% of the global population that doesn’t speak english as first language goes online, right?

Because the #1 use case for this isn’t emoji, but sites such as bücher.de (I originally had a link here to the site, but HN punycodes that: http://xn--bcher-kva.de/ ) (which nowadays had to redirect, because the URL displayed in punycode made people believe it was a phishing attempt)

Useful. Neither ideal nor necessary, though.

A full source reputation, authentication, and integrity capability strikes me as far more useful.

If you want this, just press F11 on firefox. Or select from the menu: View / Full Screen. But this has nothing to do with a headless browser.

I used to achieve this by using a tiling window manager (i3).

In i3, if you run firefox normally it opens up in a pane, if you choose full screen (f11) inside firefox, it fills up the entire pane. In the other panes you can still keep your other windows, such as emacs, file browser, terminal etc.

Granted, this is not the "headless" they're talking about, but rather "chrome-less" (chrome being the browser UI frame around the page itself)..

JavaScript Fullscreen API: https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_...

Cross-browser polyfill: https://github.com/sindresorhus/screenfull.js

I'm working on some thoughts in a related, if not entirely similar, vein:

https://www.reddit.com/r/dredmorbius/comments/6bgowu/what_if...

F11?

F11 is full screen, not headless. Headless means you can't see the browser or the website content, it's built for scripting purposes (automated web testing and web scraping). The only time you can see the content is if your script requests a screen capture.

I know what headless means, but if fairpx is really referring to headless (he seems to have changed his post) then I have no idea what this means:

> where the UI appears when you need it, intuitively, even when NOT in full screen

or how it relates to a headless browser.

Replying to myself.. ok the poster was confused between headless and chromeless (by which he really meant full screen), that explains it.. sorry.

Sounds like a great idea. My skills aren't quite up to UI design collaboration standards but I guess I am curious as to how you would build and implement such a browser?

Reply on news.ycombinator.com