Extensions designed to enrich your browsing experience

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: …

implementation itself:

The current ways of treating manipulations by extensions is the following:

  1. website’s code gets downloaded
  2. code gets parsed
  3. 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

  1. website’s code gets downloaded
  2. extensions make their adjustments to it
  3. parser interprets the final code

context:

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

z-index:

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?

DOM-structure:

<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>

“shadow”-DOM:

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 πŸ™‚

Advertisements

Comments on: "Reimagining the browser-extension-web-correlation" (3)

  1. Acryion said:

    The world would be a so much better place if minor adjustments would be made here and there. But no one does them, unfortunately 😦

  2. laurenbacall said:

    It would be great if browsers gave devs more hooks into the process, UI, etc. It seems that Firefox has always allowed for deeper add-on capabilities than other browsers, at least the XUL type.Custom styled default elements would be really nice, too πŸ˜€ Many elements require hacky solutions to style at all. Youtube's HTML5 video player shows how well it can be done, but having access to all the browser's default styling would be pretty awesome :up:I remember seeing WebKit's scrollbar pseudo-element selectors a few years ago and wishing all browsers had it, and obviously for something like Modern Scroll it would be perfect. Now that Opera is going Blink I wonder if all those selectors will be kept in the fork.

  3. christoph142 said:

    Thanks for sharing that link, Lauren :)I didn't know that WebKit/Blink offers such a variety of pseudo-selectors. Looks like I'm going to have quite some fun as soon as Opera 14 shows up… πŸ˜†

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: