Lets say we want to write some quick html and js thing to test something. We want a text field and a button to login with a username and if logged, some text with the username saying hello.

Ok, we skip all the html, head and body tags and we just write this:

<login>
    <input type="text">
    <button onclick="login()">Log in</button>
</login>

<hello>
    Hello <username>
</hello>

We add and a script tag in the end and we are done (and it works, this is not a joke)

It may not be obvious but we are not following the law of the "Valid custom element names" and if we then define some components with these name you are going to get the "Failed to execute 'define', 'hello' is not a valid custom element name".

Very important check, image this check not being there all the bad things that could happen. Like when you try to create a component "icon" but there is no hyphen there, so you spend all day trying to figure out if "a-icon" or "icon-" is the least ugly of the two, and then you are unable to sleep thinking that there must be some other way to cheat the system... there must be... Thank you whatwg.

done_

Lets assume you have an web app with some sort of login system, and you are testing things on a local web server bound to "localhost" and you want to test multiple logged in users at the same time.

We start by creating multiple "domains" pointing to the localhost via the /ets/hosts file:

127.0.0.1  localhost1
127.0.0.1  localhost2
127.0.0.1  localhost3
127.0.0.1  localhost4
127.0.0.1  localhost5
127.0.0.1  localhost6
127.0.0.1  localhost7
127.0.0.1  localhost8
127.0.0.1  localhost9

Because the session and local storage is instanced per domain name (or even the cookies for the old school) using the localhostX will each be isolated.

Then you fight with your web server that definitely will not like requesting http with something different than localhost, but you can win.

And then you fight with the OAuth callback redirect url and... you lose the fight... and you go back to the firefox containers.

done_