February 3rd, 2015
So today I discovered that the HTML videos that I made for Educator.com a few years back are being pirated. You can find various torrents all over the internet!
People are willing to break the law to hear me teach! I don’t know why I trust the words of a pirate, but the description of the first one I saw came across to me as high praise.
A nice training session for those who want to learn the dark arts of Proper website building without all the WYSIWYG crapware that’s flying about on the internet….Even the more experienced users will find this interesting….
I made these videos for Educator a long time ago. I figured they’d be mostly forgotten about by now, but I still get ‘thank you’ emails from people who have taken the course and somehow figured out my email address (with a little research it isn’t hard), so clearly people are still watching them. Now that I think of it, I also still get a paycheck from Educator every month, which indicates that at least some people are watching the non-pirated versions on Educator.com.
This isn’t the first flattering but slightly odd realization I’ve had regarding these videos. Have you seen my twitter account? Yep, that’s my name, and that’s a photo of me, but that’s not my account! It’s an impersonator! And it has more followers than my actual twitter account! What does that say about me? (Probably just that I don’t really use twitter.)
The experience that takes the cake, however, was my first celebrity sighting—where I myself was the celebrity! I was working the JPL Open House at the robotics tent when someone came up and said “I took your webmaking course!” I was so surprised I didn’t even know what to say or do. I think celebrities are supposed to want to avoid attention, right? I kind of felt like I was obligated to sneer at her and put on dark sunglasses, but I was so flattered that I wanted to hug her. I guess the right thing to do would have been to get a picture with her. Next time? Will there be a next time?
December 18th, 2014
In the last four websites I’ve built, I’ve used four different jQuery carousel plugins. I’m not really a super fan of carousels, I think they’re kitschy and make for bad UX. They’re the twenty-ten’s version of a flash intro screen. But designers throw them in and clients like them, and I don’t always get to make all the decisions around here.
Since I’m pretty much an expert at it by now, let me tell you about the process of how to find a jQuery carousel that you hate. First, you hit up Google, and pin the command key down while clicking on links until your tabs look like the Nintendo version of the Sierra Nevada mountains in the top of your browser.
Then you sift through all the articles like “500 Great Responsive Carousels” and “25 Carousels that are the Last Carousel You’ll Ever Need” until you have a list of twenty or so GitHub pages. Then you start looking through the demos, most of which won’t work. Then you download the code and see if you can get it working. Most you won’t be able to, so you spend some time looking at the documentation and making adjustments and fixes until you get some of them to work. Then you exclude the ones that make the browser run slowly because they’re so bloated. Then you spend some time figuring out the API’s that the plugin vendors wrote to make it “easy” for you to change up the features. When they prove too much effort, you just rewrite the code yourself, slashing out wide swaths of code you probably don’t need until you’ve got a somewhat lean plugin. Then you spend forever working around the skins that they built in since your carousel needs to look different. In the end, you’ll end up with one plugin that kind of works, but is buggy or broken bloated or otherwise inadequate.
I finally got tired of this process, which is why I have contributed my own addition to the jQuery carousel mess. I call it Gallop, and it’s intentionally very simple, barebones, and featureless. We’re web developers. We know how to tweak some jQuery to get the features that we want working. We can adjust CSS to make things look right. We don’t need massive plugins with complicated mechanisms to control a million possible configurations. Maybe we just want some
divs to slide across the screen, ok? Is that so hard?
No, it turns out it’s not so hard. Less than 100 lines of jQuery, a little more CSS. You just put an unordered list in a
div, and it works. The code is incredibly easy to follow, and if you want to change around the features, you just directly edit the code! If you want an additional feature, you just add it right in!
Anyway, here’s the GitHub page. I even made a fun little demo for it as well. Hopefully this simplifies the jQuery plugin process for some people.
October 25th, 2013
Google has announced that they will be forking WebKit to create a new rendering engine for Chrome called Blink. Google will be able to remove millions of lines of code from Blink that isn’t needed for Chrome, and will be able to work more aggressively to develop Chrome-specific features into Blink.
This won’t unsettle things too much—at least not right away. The latest builds of Canary are already using Blink, and there is no perceptible difference. The CSS
-webkit- prefixes even still work. So how long will it be until we have to switch over to using a
-chrome- prefix for our rounded corners? The answer to that question is: “wrong!” There will be no
-chrome- prefix, or any other vendor prefixes at all, moving forward. Instead, you’ll have to change a setting in your browser to enable experimental CSS features.
Vendor prefixes seemed like a good idea. And maybe they would have worked, if developers had used them as intended. Eric Meyer wrote the seminal article advocating vendor prefixes, Prefix or Posthack. He explained that we could use vendor prefixes to escape the conflicting standards of the bad old days, when the same code was rendered differently by different browsers. Due to Internet Explorers broken box model,
width meant one thing in Trident (IE’s layout engine) and something entirely different in Gecko (FireFox’s layout engine). Furthermore, because these differences were alive and living on the internet, there was no way for either browser to fix (or compromise) its definition to unify the web without breaking existing pages. Internet Explorer eventually fixed it’s box model, but it has been an arduous, difficult journey, one that has not yet reached it’s destination. Despite years of very clever attempts to fix things with the creation of quirks mode, doctype switching, and for IE, conditional comments and the problematic compatibility view (which still persists in IE10!).
With vendor prefixes, none of that would happen, because new CSS features would go through a vetting period, during which the feature could only be accessed by prefixing a code to the property name. After a time of testing, and when the standard was defined more definitively, the browser could begin supporting the property without the prefix, and nobody would have incompatible CSS anymore!
This quickly created a situation where the simple task of rounding some corners turned into this mess:
When it comes to background gradients, things are even worse:
background: -moz-linear-gradient(top, rgba(255,255,255,1) 0%, rgba(255,255,255,0) 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(255,255,255,1)), color-stop(100%,rgba(255,255,255,0))); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top, rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top, rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top, rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* IE10+ */
background: linear-gradient(to bottom, rgba(255,255,255,1) 0%,rgba(255,255,255,0) 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#00ffffff',GradientType=0 ); /* IE6-9 */
or even just:
You can see how this sort of abuse caused problems. Developers got used to Chrome being on the bleeding edge of CSS3 features, and began coding specifically for it without taking the time to check whether other browsers had supported the features yet. Effectively, vendor prefixes had become browser detection all over again, and developers were using this browser detection to block functionality from all browsers except WebKit. As you can imagine, this annoyed other browser vendors, like Opera, who were working hard to keep their browser up to date with CSS3, but which was blocked from applying the styles due to lazy coding. Developers had turned
-webkit- into the very
-beta- prefix which Eric Meyers dismissed in his article.
-beta- prefix was proposed by Peter-Paul Koch as a compromise to his original proposition to abolish vendor prefixes. Koch’s vision was prophetic. In March 2010 he wrote:
Eventually Opera will discover that plenty of sites use
-webkit-transition, but not
-o-transition. Will Opera start to support
Despite a widely circulated call for action to web developers to change their ways and prevent “judgement day,” two years after Koch’s prediction, Opera announced it would support
-webkit- prefixes. Mozilla had been planning to do the same. Microsoft’s massive attempt to change the bad behavior of developers had failed, and they too would follow suit.
It looked like things were going to get really messy. Then suddenly, Opera announced that it was abandoning its rendering engine Presto, and would instead use WebKit. While many saw this as a sad day for the web, the silver lining was that judgement day had been pushed back a little. Furthermore, Opera is adopting Blink with Google, and Mozilla is creating yet another rendering engine called Servo. So we aren’t looking at a rendering engine monoculture or a return to the “bad old days.”
So with all these new rendering engines, what will happen to vendor prefixes? They’re all going to go and live with the
<blink> tag and IE’s broken box model. Mozilla is heading in the same direction as Chrome: “avoiding vendor prefixes by either turning things off before shipping or shipping them un-prefixed if they’re stable enough.” This is where all the vendors are headed, and the W3C working group on CSS has already put together a policy that rang the death knell of vendor prefixes.
This article originally appeared on the shoutleaf.com blog. It was cross posted by permission the owner of Shoutleaf (me) and the author of the article (me).