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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.