Stylus Styles for YT Live

make Youtube like you need it…

Stylus is a browser extension for Chrome (and Opera) that allows the user to manage and create "styles" that modify the appearance of web sites. Users may download existing skins/styles from a repository, or write their own. Stylus uses CSS scripting to override the selected site's CSS.

Below is my CSS for Youtube live streams. Most of it improves the chat box.

In Stylus, name your style, click Edit, and paste the following into a Section.

/* For Youtube Live Streams, Rev. 04/09/19
   NOTE: 1080p desplay; Windows zoom: 125%; browser zoom: 150%.
   User will need to adjust some pixel settings to accomodate zoom used.
iframe {
    /* override google font Roboto and use locally-installed unicode font; uncomment if desired */
    /* font-family: "Arial Unicode MS" !important; */
    margin: 0 !important;
    padding: 0 !important;
#masthead-container {
    /* unlock stupid fat fixed top bar so it'll scroll up */
    position: relative !important;
#masthead-positioner-height-offset {
    /* recover space for stupid fat fixed top bar */
    height: 0 !important;
#page-manager {
    margin: 0 !important;
#primary {
    /* recover tons of wasted white-space around video (left column) */
    margin: 0 !important;
    padding: 0 10px 0 0 !important;
ytd-live-chat-frame {
    /* make chat box go to bottom of screen (adjust as needed) */
    height: 500px !important;
    min-height: 500px !important;
yt-live-chat-header-renderer {
    /* make fat "Top Chat/Live Chat" bar skinny */
    height: 16px !important;
    padding: 0 !important;
yt-live-chat-text-message-renderer {
    /* reduce huge (due to 150% browser zoom) font size (adjust as desired) */
    font-size: 12px !important
#secondary {
    /* recover tons of wasted white-space in right column */
    padding: 3px !important;
yt-live-chat-message-input-renderer {
    padding: 3px !important;
#clarify-box {
    display: none;

/* Emoji Picker Box (adjust as desired) */ {
    min-height: 220px;
    max-height: 300px;
    margin: 0 -24px 0 -24px;

/* Set: Applies to: URLs starting with :
	 Click the Add button at the end of that line, then,
   Set: Applies to: URLs starting with :
   Left Column:
   Give the style a name, click Save
   Editing: after making a change, click Save, then switch to the tab
   with the YT live stream to see changes. You do not need to refresh.

To learn more about using Stylus, click its icon and select Wiki.

Enjoy! --KV5R

WordPress and HoverIntent

fixing spastic menus…

The Problem

Don’t you just love all those web sites with pull-down and fly-out menus that unexpectedly flash in your face when you don’t want them, and then disappear when you do want them? Let’s face it: our mouse movements are never perfect, and hover events need to take this into account to avoid irritating the user.

The Fix

The easy fix is a neat little jQuery plug-in called hoverIntent, by Brian Cherne. What it does is add a little delay the mouseOver event, and optionally the mouseOut event, waiting until the user has definitely hovered, or un-hovered, the menu. In effect, it “eats” unintended mouse events. The effect is nice—no more flashing unexpected menus in your face, and no more menus that fly away while you’re trying to use them. Try it on the menu above and see the effects.

Using hoverIntent for WordPress Nav Menus

I’ve used hoverIntent before on hand-made sites, but recently I decided to put it in my WordPress site. But Not So Fast! The way WordPress builds pages has a rather steep learning curve. First of all, you can just edit the header.php file of your theme and put in the link to load the hoverIntent script, followed by some jQuery in a document.ready handler (just under wp_head() ) to make hoverIntent work on the desired menu, in the desired ways:

The Usual Way

<script type='text/javascript' src='/path/to/jquery.min.js'></script>
<script type='text/javascript' src='/path/to/hoverIntent.min.js'></script>
<script type='text/javascript'>
  jQuery('.menu ul li').hoverIntent({over:navover, out:navout, timeout:400});
  function navover(){jQuery(this).children('ul').fadeIn('slow');}
  function navout(){jQuery(this).children('ul').fadeOut('fast');}

Something like that will get it going, after you have disabled the :hover effects in the nav menu portion of your CSS file. But is that really the right way to do it in WordPress? Well… no.

The WordPress Way

WordPress has built-in ways of handling the dependencies and proper load-order of things, so we should do it the WordPress way, which is to make a couple functions in functions.php and then tell it to “enqueue” the hoverIntent script (that comes with WordPress), and also load the instantiation in the head section of the generated page to tell hoverIntent what to do.

I couldn’t find any applicable examples on-line, so after many hours of fiddling I ended up with this, which goes in functions.php in the template:

// make a little function to enqueue hoverIntent:
function enq_hoverIntent() { wp_enqueue_script('hoverIntent'); }
// now make WP run it:
add_action('wp_enqueue_scripts', 'enq_hoverIntent');

// enclose some jQuery script in a php function:
function init_hoverIntent() { ?>
<script type='text/javascript'>
    jQuery('.menu ul li').hoverIntent({
      over : navover,
      out : navout,
      timeout : 400
    // (how to use both fade and slide effects!):
    function navover(){
    function navout(){
<?php }
// now make WP load that into the head section of the html page:
add_action('wp_head', 'init_hoverIntent');

And that’s it! Assuming you already have a working CSS-based drop-down or fly-out menu in your header.php file, you don’t need to add anything else to it. WordPress will now load hoverIntent at the right place (and it will also load jQuery, if not already loaded). And when it runs wp_head() it’ll add your initialization script that ties hoverIntent to your nav menu.


  1. You need to study your document tree a bit to see what tags, IDs, and classes your nav menu uses, which will vary with different themes.
  2. You can’t use $ for jQuery in WordPress—it loads it in “noConflict” mode.
  3. Be sure your CSS (1) hides the sub-menu ULs on page-load, but (2) doesn’t show them on :hover, as that would override the effect and you’ll think it isn’t working.
  4. If you have not defined a custom menu in WordPress Admin, WP will use wp_page_menu() to build the menu when wp_nav_menu() is called. The menu will be built in levels according to the parent and menu order settings of all your pages.
  5. The hoverIntent “timeout” setting refers to the mouseOut delay, which defaults to 0, so you need to instantiate it as shown above to use timeout. 400 (milliseconds) is a decent setting to keep the menu open while you are navigating it and cutting corners along the way.
  6. Since we now have jQuery handy, we might as well add some nice animation to the menu. We could just use show() and hide(), but it’s much more pleasing to use slideDown() slideUp(), or fadeIn() fadeOut(), or even better, both! We could even use jQuery animate() to make the menu display in other neat ways by animating various CSS properties of the drop-down ULs.


Security Certificates

when your browser scares you with the infamous “this site is not trusted”

When you first go to register or log-in on this site, your browser puts a big scary security warning in your face. But really, what does it mean?

Well, two things: (1) it has switched to secure (https:) mode, and is now encrypting all communications, and (2) it’s doing so with my self-signed SSL certificate.

Now, let’s put this into perspective.

First, you can either have an un-encrypted, plain-text connection on http port 80. Or, you can have an encrypted connection, that cannot be intercepted en-route, on https port 443. Anyone and everyone can create their own certificate that enables this transport encryption.

Second, the encryption certificate can come from anyone, or it can be issued (for a whopping fee of $100-$1500 a year) by some “approved” certificate authority (CA). These CA root certs are already in your browser, and if some site has a cert from one of them, you don’t get the nasty warning — but you do know for sure that the identity of the web site has been independently verified. This is a very good thing when you need to be sure that your bank really is your bank!

So we see two things in play: (1) https encryption and, (2) identity verification. Unfortunately, the “power-that-be” have decided that one = other. But does it?

Cases: (1) you go to log into a free site so you can post a comment. Your connection should be https, port 443, encrypted, to keep prying eyes from reading your password. Or, (2) You go to a commerce site to buy something: Your connection should be encrypted, and you should “trust” a “certificate authority” to have verified the “ownership” of the secured connection. I mean, would you really transfer money otherwise?!

In the first case, you are logging into a free site, and no personal or financial information is requested or transmitted. You really don’t need to care about a verified identity, you just want your password hidden en-route. Such sites, like this one, use a self-signed (free) SSL certificate, which causes your browser to go SSL but put that warning in your face. But if you elect to continue, you still get 100% secure mil-grade encryption of the connection. You are not buying anything, and if the site asks you for financial details, you just dump it. Simple!

In the second case, you are buying something (or accessing your financial accounts) and you need both a secure connection and verified identity. In this case, DO NOT continue past the browser’s “not trusted” warning! Any real bank or e-merchant will have the “trusted” certificate, with their identity verified by a CA that is known to your browser. After all, they’re making millions off you and can afford a verified identity at those high prices.

So, the long and short of it is, any site (like this one) can use a free self-signed certificate to encrypt your log-in/registration page, and you browser will show a warning. All that warning means is that the encryption certificate isn’t backed by some CA (at $100-$1500/year rip-off price) — but WTH, it’s just a free log-in, and if you continue, you’ll have an encrypted connection, just as good as any, with which to transmit your log-in or registration.

The opposite side is when you are buying something, plan to enter your CC# — in that case, never, never, never continue past a security warning!

Hey, you’re not buying anything here, we don’t ask you for any financial stuff, and so we don’t pay some CA $100-$1500/year to verify our identity. If we did, we’d have to bill you for access! And if you choose to Donate to this site, well, that’s handled by PayPal and their trusted CA, not us.

In my opinion, combining encryption with identity verification is a big scam: both encryption and identity verification should be free for everyone — or there should be low-cost (non-profit) alternatives for non-commercial sites. Yes, there are few “free” verified SSL certificate providers, but then you get to the fine print: if you even have so much as a Donate button or Google ad on the site, they consider it “commercial” and deny your request! Then they try to up-sell you into one of their expensive commerce certs.

I, for one one of millions, do not have the money to pay to officially “trust” my identity, but you can still enjoy the fruits of my labor, including an encrypted log-in.

Smart web browsing is both an art and a science.

Hope this helps,


times are tough…

When I see one of those “Contribute” buttons on a web site I think, “yeah, like I’m really gonna just send some money to a total stranger…” But this case is different.

Having a chronic illness, I can’t do much, but I can sit at the computer, so I spend thousands of hours attempting to write free articles for total strangers to read and enjoy. And my writing is always based on the idea that good content should be both useful and appreciated, so I tend to cover my subjects in such a way as to take them from beginner to intermediate levels, along with the enthusiasm of new accomplishments.

If you find the articles on this site interesting and useful, please consider a small contribution to help cover expenses. There’s a PayPal button at the bottom of the page (you don’t need a PayPal account, any plastic will do) and you can rest assured that it’s secure.

If you’ve already contributed, I’d like to say a big Thanks! It’s very much appreciated!


1200 Pixels

Twelve Hundred Pixels - The New Size in Websites

by KV5R • © 2012 • Rev. 9/10/12

Are you sick of seeing 760 and 980-pixel sites on your 1920×1080 display? Well, I am! They look like a little ribbon of tiny clutter down the middle (or worse, the far left) of the screen.

Many webmasters still do this because they fear some users are still running low-resolution screens—and 12 years ago designing for the Windows default 800-pixel screen was appropriate, but now it has become just another web tradition with no merit.

According to w3schools survey, the number of browsers now reporting 800 resolution is down to 1 percent, and even 1024 has dropped to 13 percent. That means over 86 percent are running 1280 or higher. Most new laptops are now 1366 and, thanks to the interest in HD videos on computers, most new monitors are 1920.

I switched from designing sites for 800 in 2007 when the percentage of 800-pixel users dropped below 15 percent. Now (2012), the percentage of 1024-pixel users has dropped to 14 percent, and it’s time to start designing for the 1280 and higher monitors.

I built the WordPress theme for this site from the Twenty Eleven theme, and one of the many changes I made was bumping the max-width up from 1000 to 1200. This leaves room for a little background, scroll-bar, and window borders on a 1280 display, and it still looks great on a 1920 display (I’m running both here).

“But what about all those little phones and tablets?” We’ve got that covered! Thanks to new capabilities in CSS-3, there′s a new layout called “responsive” that allows web designers to make sites that re-format their layouts, and even shrink images, when it detects the user is using a phone or tablet display. Shrink your browser down real small on this site, and you’ll get the idea.

Web-Safe is Now Web Stupid

I wrote about the so-called web-safe colors and web-safe fonts a few years ago. I can hardly believe my eyes when I still see web “gurus” promoting them.

Web Safe Colors

This nonsense started about fifteen years ago when a lot of people were still using 256-color displays, and then it became a religion. W3Schools reports that 0% are now using 256 colors, and under 2% are still using 65,536 colors. Over 98% are now using 16.777-million-color displays. I wonder what percentage of web devs are still using only 256 colors?

Web Safe Fonts

This one is really wacky. The “safe” list includes things like Helvetica, which is now installed on 100% of Macs but less than 7% of all Windows machines. Thus, it is a Mac font, yet it is probably the most often one seen first in css font stacks. Why? Tradition! Fortunately, CSS-3 provides the mechanism for browsers to use web-based fonts, so we can start thinking about abandoning the whole idea of users’ installed fonts.

For better font choices, see my New Font Family article, in which I built better (modern) font stacks based on researching the stats at

Coding for Internet Explorer

Speaking of browsers, Firefox passed Internet Explorer in January of 2009 — and get this! — Google Chrome passed Firefox in March of 2012! IE’s share has dropped to 16%! Finally—after web devs spent millions of hours and billions of dollars writing hacks into their code so that web pages would work in both IE and the standards-compliant browsers. And only with the recent version 9 has IE finally started following standards.

I wonder how many more years web coders will keep up the tradition of including IE hacks, in fear of some imagined percentage of users (clients?) still running IE6?

Coding for W3C′s Little Detour

Perhaps the most powerful mojo in the web-dev religion is the Holy XHTML. A few years ago, it was the way to go, and quickly became synonymous with semantic markup and the table-hating Cult of Div. But then, the Consortium turned its attention to HTML-5 and sort of abandoned XHTML, even stating that putting compliant HTML in an XML wrapper served no useful purpose. Furthermore, nearly all public web servers ignore the XML wrapper and serve XHTML as plain HTML text.

Yet we still see a development community pushing XHTML and all that <br /> crapola, even as they move to HTML-5, which doesn′t require a slash on self-closing tags. They wouldn′t be caught dead writing a web page without the deprecated XHTML doctype and DTD declaration, yet they are now peppering their code with HTML-5′s bevvy of new tags, the same degree that they were wrapping everything in hundreds of nested DIVs last year, and hundreds of nested tables before that.

As for me, I′ll just keep on hand-coding (well, except for this blog), and the only thing I′ll do different is use the HTML-5 doctype and learn a few new tags.

Bypassing the fads and traditions sure is fun!