Today’s browsers root in an environment where there were only websites and PCs. A browser’s purpose was simply to make the bits and bytes describing pages visible to users on their screens.
However, the internet changed. Today we’re seeing the so-called Web 2.0. Browsers adjusted to new standards coming up over time and thus implemented new features. A lot of things became easier to develop thanks to modern tools like HTML5 and CSS3.
But the web changed more than that. There’s not only a website and a screen anymore.
Nowadays, in most cases, there are extensions in between this linkage manipulating what will be shown of the original code to the user. Not every user does have a whole set of extensions installed, but only a minority of users browses completely without them (e.g. ad blockers).
So how did browsers react to this new component?
In short: they didn’t :right:
There are a few limited APIs that are not available to websites, but to extensions exclusively. That’s it!
Developing my own extensions, I more than once resigned because of incompatibilities between extensions or between one extension and some specific websites.
IMHO there’s a bunch of alterations to a modern browser’s structure that would be necessary to solve those issues and this post is going to elaborate on my view of a modern extension system a bit :up: …
The current ways of treating manipulations by extensions is the following:
- website’s code gets downloaded
- code gets parsed
- extensions need to hook themselves into the parsing process
Or to sum it up: they aren’t really part of the whole process.
If you think about what extensions do, however, you’ll notice, that they often play a man-in-the-middle-role.
As a consequence, the process to show a website should look more like
- website’s code gets downloaded
- extensions make their adjustments to it
- parser interprets the final code
extensions must be given the opportunity to specify the context they are supposed to run in. Either per website like the current implementation is now or per window/tab instead
There are two to the power of 32 = 4294967296 (in most browsers) possible layers to position content on a webpage and extensions are forced to use the same ones. Why not specify a set of layers exclusively for extensions to make sure, you can always position extension content behind and – more importantly – on top of every website element? It wouldn’t hurt if there were e.g. only 2^8 = 65536 layers available to website developers, would it?
<html> <head>...</head> <body>...</body> </html>
And what about extensions? Where do they appear in there?
Well, if injected content needs to be positioned inline, it has to be in the body of course to show up at the right spot, but if the positioning will be absolute / fixed, it would make sense to separate the extension’s code from the website’s one, e.g. by moving extensions into a single container like this:
<html> <extensions> <ext1></ext1> <ext2></ext2> ... </extensions> <head>...</head> <body>...</body> </html>
Did you ever wrap your head around what happens behind the scenes? Think about the HTML5 video tag for example:
You only specify a source for a video and the result of it is a full-fledged video-player right inside your page. It has a timeline, pause/play buttons, a volume slider…
Where do those elements come from…?
These sub-elements are usually referred to as “shadow”-DOM and are automatically added by your browser.
Hence, they may and do look slightly different in each of them.
I think extension should be given access to this shadow-DOM to alter the look and feel of elements. I’m sure that this power would lead to astonishing results which nobody of us can imagine right now :yes:
side note: WebKit/Blink even allows some shadow-DOM-manipulation: There’s e.g. a CSS-pseudo-selector ::-webkit-scrollbar that lets you specify the appearance of the scroll bars :up:
Have a look at Lauren’s comment for further details.
Now it’s your turn. Let me know about your thoughts on it in the comments 🙂