I’ve just pushed out an update to Panel View for Keep, bringing it up to version 2.6. This version fixes something that’s been bugging me for a long time.

Download from the Chrome Store
Fork on Github

By itself, the Google Keep website limits the size of individual notes to a percentage of the total height. Here’s an example:

panel_view_keep_default_view

That always bugged me. I really wanted the note to be full height, like this:

panel_view_keep_full_view

It just makes more sense to me; this is also closer to how the Keep app behaves. Getting there, though, was certainly a trip.

Digging through Keep’s markup always blows my mind a little. Most UI/UX systems will have markup by which you can decipher the intent and purpose. For example, Trello is pretty easy:

<div class="window-module u-clearfix">
  <h3>Add</h3>
  <div class="u-clearfix">
    <a class="button-link js-change-card-members" href="#">
      <span class="icon-sm icon-member"></span> Members
    </a>
  </div>
</div>

If you know Trello, it’s pretty evident what this snippet is for. (It’s a section of a card’s “Add” module, where you can add members, tags, etc.) Check out the equivalent in Keep:

<div class="IZ65Hb-INgbqf" role="toolbar">
  <div role="button" class="VIpgJd-LgbsSe Bz112c-LgbsSe  euCgFf  INgbqf-LgbsSe" tabindex="0" aria-label="Share" style="-webkit-user-select: none;"></div>
</div>

The only clue we have as to this markup’s purpose is aria-label. The classes seem to be random strings of text. Upon further investigation, though, they’re not random; they’re the same in each page load. They are dependable, which just means that Google must be running the stylesheet and markup through some sort of obfuscator before rendering. I just need to map the classes out in my override stylesheet to the appropriate styles.

It’s somewhat handy that I moved all my CSS to being generated by Sass, so I can have my styles commented in the dev version. The stylesheet loaded by the extension is compiled without comments and minified.

In my efforts, I ran into a Sass bug. But before I get into that, let me back up. In order to get the note content to take up the full height, I did this:

.IZ65Hb-s2gQvd {
  height: 100%;
}

Simple enough, right? Right. Except there’s a problem: the toolbar was being pushed out of view by the note content, which was taking up the entire page. 100%, of course.

From what I can tell, the toolbar is always the same height. So I set that height to an appropriately named variable (an advantage of Sass ftw). I opted for this, instead of defining the value in the class itself, so I can come back to it and I’ll know what that value is for. (You know I won’t remember six months from now.)

$icon-bar-height: 45px;

Using that, I set the height using the CSS function calc(). This is a CSS function, not a Sass function, so it will result in a dynamic value as the window gets resized.

.IZ65Hb-s2gQvd {
  height: calc(100% - $icon-bar-height);
}

Except it doesn’t work. Why doesn’t it work? I know that Chrome supports calc() (and this is the reason I don’t have a fallback defined, this being in a Chrome extension). Using the value outright, instead of coming from a variable, works just fine.

A quick Google search reveals a Sass bug report. The solution is simple:

You need to interpolate the $var in order to have it print out the [value] there

The amended code is simple enough:

.IZ65Hb-s2gQvd {
  height: calc(100% - #{$icon-bar-height});
}

And voila, it works.

The extension has been pushed out to the Chrome Web Store and the Github repo.


After doing a little digging, I found that apparently Google’s Closure Stylesheets support CSS class renaming. It works in tandem with the Closure Compiler and Templates to update JavaScript and HTML, respectively.

Husband. Daddy. Programmer. Artist. I'm not an expert, I just play one in real life.