meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Content Blocking Primer

Content blockers have arrived, as I’m sure you’re aware by now.  They’re more commonly referred to as ad blockers, but they’re much more than that, really.  In fact, they’re a time machine.

Consider: a user who runs a content blocker can prevent the loading of Javascript, CSS, cookies, and web fonts.  (They can block more than that, but those asset types seem to be the main targets thus far.)  A person loading an article or other page from a web site gets the content, and that’s it, assuming the publisher hasn’t put some sort of “go away” server-side script in place.

Sound familiar?  It should.  We’ve been here before.  It’s 1995 all over again.

And, just as in 1995, publishers are faced with a landscape where they’re not sure how to make money, or even if they can make money.

Content blockers are a two-decade reset button.  We’re right back where we were, twenty years ago.  Except this: we already know a bunch of stuff that doesn’t work.

I don’t mean that ads don’t work.  Ads can work.  We’ve seen small, independent ad networks like The Deck do pretty okay.  They didn’t make anyone a billionaire, but they provided a good audience to advertisers via a low-impact mechanism, and some earnings for those who ran the ads and the network.

The ads that are at risk now are the ones delivered via bloated, badly managed, security-risk mechanisms.  In other words: what’s at risk here is terrible web development.

Granted, the development of these ads was so terrible that it made the entire mobile web ecosystem appear far more broken that it actually is, and prompted multiple attempts to rein it in.  Now we have content blockers, which are basically the nuclear option: if you aren’t going to even attempt to respect your customers, they’re happy to torch your entire infrastructure.

Ethical?  Moral?  Rational?  Hell if I know or care.  Content blockers became the top paid apps within hours of iOS9’s release, and remain so.  The market is speaking incredibly loudly.  It’s almost impossible not to hear it.  The roar is so loud, in fact, it’s difficult to make out what people are actually saying.

I have my interpretation of their shouting, but I’m going to keep it to myself.  The observation I really want to make is this: the entire industry is being given a do-over here.  Not the ad industry; the web industry.

Remember, this isn’t just about ads.  Ads are emblematic of the root problem, but they’re not the actual root problem.  If ads were the sole concern of content blockers, then the blockers (mostly) wouldn’t bother to block web fonts.  It’s possible to use web fonts smartly and efficiently, but most sites don’t, so web fonts are a major culprit in slow mobile load times.  The same is true for Javascript, whether it’s served by an ad network, an analytics engine, or some other source.  So they’re both targeted by blockers—not for enabling ads, but for disabling the web.

Content blockers strip the web back to what it was 20 years ago.  All the same challenges and questions are back, full force.  How do we make sites better, smarter, and cooler?  How do we make money by publishing online?

There are reputations and probably fortunes to be made by learning from our many mistakes and finding new, smarter ways to move forward.  I would advocate that people start with the core principles of the web standards movement, particularly progressive enhancement, but those are starting points, a foundation—just as they always were.

It’s not often that an entire industry gets an almost literal do-over.  We have two decades of hindsight to work with now, as we try to figure out how to (re)build a web where users don’t feel like they need content blockers just to be online.  This is an incredibly rare and exciting juncture.  Let’s not waste it.

The Shape of Things to Come

Software may be eating the world, but we are shaping it.  What we do now—what we build, how we act, what we tolerate—will profoundly influence how society develops over the next few generations.

That’s not because what happens now will change you or me.  We’re unlikely to change much, if at all.  We’re set in our ways, most of us.

Our children are not.

What they see online will seem normal to them, just as what we saw growing up seemed normal to us.  And because there is no meaningful distinction between online and offline, what they come to accept as normal online will be seen as normal offline.

So the way we build our networks matters in the most profound possible way.  If we build networks that make it easy to abuse and harass, and make it difficult to defend against abuse and harassment, our children will come to see that as normal, even desirable.  Similarly, if we build networks where it’s hard to abuse and harass, and easy to defend against such attempts, that will become the norm.

System design is social design.  The question is, what kind of society do we want to design?

And the more important question is, when are we going to start?

This article was originally published at The Pastry Box Project on 2 September 2015.

Dislike

Facebook is emotionally smarter than we give it credit for, though perhaps not as algorithmically smart as it could be.

I’ve been pondering this for a few weeks now, and Zeynep Tufekci’s “Facebook and the Tyranny of the ‘Like’ in a Difficult World” prodded me to consolidate my thoughts.

(Note: This is not about what Tufekci writes about, exactly, and is not meant as a rebuttal to her argument.  I agree with her that post-ranking algorithms need to be smarter.  I also believe there are design solutions needed to compensate for the unthinking nature of those algorithms, but that’s a topic for another time.)

Tufekci’s piece perfectly describes the asymmetrical nature of Facebook’s “engagement” mechanisms, commented on for years: there is no negative mirror for the “Like” button.  As she says:

Of course he cannot like it. Nobody can. How could anyone like such an awful video?

What happens then to the video? Not much. It will mostly get ignored, because my social network has no way to signal to the algorithm that this is something they care about.

What I’ve been thinking of late is that the people in her network can comment as a way to signal their interest, caring, engagement, whatever you want to call it.  When “Like” doesn’t fit, comments are all that’s left, and I think that’s appropriate.

In a situation like Tufekci describes, or any post that deals with the difficult side of life, comments are exactly what’s called for.  Imagine if there were a “Dislike” button.  How many would just click it without commenting?  Before you answer that question, consider: how many click “Like” without commenting?  How many more would use “Dislike” as a way to avoid dealing with the situation at hand?

When someone posts something difficult—about themselves, or someone they care about, or the state of the world—they are most likely seeking the support of their community.  They’re asking to be heard.  Comments fill that need.  In an era of Likes and Faves and Stars and Hearts, a comment (usually) shows at least some measure of thought and consideration.  It shows that the poster has been heard.

Many of those posts can be hard to respond to.  I know, because many of the Facebook posts my wife and I were making two years (and one year) ago right now were doubtless incredibly hard to read.  I remember many people leaving comments along the lines of, “I don’t know what to say, but I’m thinking of you all.”  And even that probably felt awkward and insufficient to those who left such comments.  Crisis and grief and fear in others can make us very uncomfortable.  Pushing past that discomfort to say a few words is a huge show of support.  It matters.

Adding “Dislike” would be a step backward, in terms of emotional intelligence.  It could too easily rob people who post about the difficult parts of life of something they clearly seek.

Marvelous

I’m typing this as North America slowly unwinds below me, fleeing the rising sun that will still overtake us, light-headed and a touch giddy from a sustained shortness of sleep.  If this all sounds a little bit familiar, you’re right, and thank you for following my meanderings over so many months.  Anyone can write, but not everyone is read, and it’s always an honor.

I’m not going to write about my obsessions this time, at least not directly.  But as it happens, I’m watching a movie about someone else’s obsession: Tim’s Vermeer.  In short, it’s about the inventor of Video Toaster and Lightwave, Tim Jenison, and his quest to figure out how Johannes Vermeer did what he did so incredibly well.  Tim hypothesizes that Vermeer used high 16th-Century technology in a novel and long-forgotten fashion.

In the process of making his case, Tim not only reverse-engineers the technique, he decides to recreate Vermeer’s studio, employing 3D CAD modeling and visualization, not to mention computer-driven lathes and mills and routers to build the furniture to exacting precision.  It’s a fascinating contrast to the constraint he sets himself of only using materials that would have been available in the 16th century for the room and the painting itself.  He puts a piece of wood into an industrial tool the size of a 1970s DEC mainframe and sends it commands to fashion a chair leg in the style of 16th-Century Europe, and then picks up a pestle to grind the pigments for his paint by hand.

In the end, he produces a painting that bears all the hallmarks of a Vermeer, a very close copy of The Music Lesson, even though Tim has never studied or even practiced painting of any kind.  In the process, he uncovers a clue in Vermeer’s original, something not noticed in the 350 years since its production, that provides very strong evidence he’s gotten it right.  It’s a really fascinating story.

And there I sat, seven miles above the earth, moving at a significant fraction of the speed of sound, watching the whole story unfold on my iPhone 4S plugged into a compact charging device, the movie streaming over wifi from a media server stowed away somewhere in the airframe.  Far above me, a constellation of beacons circled in polar orbit, helping to keep the plane on course and on time as it hurled itself through the thin air.

Bathed in marvels, I watched a man who had birthed or helped birth some of those marvels resurrect a forgotten marvel and produce a marvel of his own.

Then I cued up Marvel’s Guardians of the Galaxy, because the antics of an anarchic sentient raccoon are never not funny.

This article was originally published at The Pastry Box Project on 2 August 2015.

Medium Trials

Originally published at Medium on July 30th, 2015.

Yesterday, I decided to try importing a story to Medium. I’d hunted around for a way to auto-post to Medium from WordPress, which runs the blog portion of meyerweb (the rest is mostly HTML, with a little PHP here and there), and hadn’t found one. Then I found the “Import story” feature on Medium and thought, Sure, why not?

So I tried it out on my most recent post, which also happened to have some code in it, as my posts sometimes do. The process was, as anyone who’s used it can tell you, very simple. Paste in a URL and the content gets sucked in.

Well, except for code blocks.

Everything was imported without incident except the Javascript. That seems like a metaphor for something.

I’d structured the block with a pre element, as I always do, and yet the line-breaking was stripped away. It looks like my indentation tabs were preserved, but without the linefeeds, they didn’t have nearly the same utility.

The real problem is that the importation of the code block stopped cold at the first <, dropping the rest of the code on the floor. Now, I admit, I didn’t escape or entity-ize the character in my source, and maybe that was the problem. Still, I feel like an import tool should be a little smarter about things like less-than symbols on import. Otherwise, how many less-than-threes will end up as just plain threes?

Fortunately, the fix was simple: I went back to the original post, drag-selected the whole code block, copied, went back to Medium, drag-selected the mangled code, and hit ⌘V. Done. It was properly formatted and no less-than terminations occurred.

Today, I’m experimenting with writing my post on Medium first, after which I’ll repost it at meyerweb. This is likely the only time I’ll do it in that order, given my experience over here. Captions are deucedly hard to edit (at least in my browser of choice, Firefox Nightly), the apparent inability to add simple decorations like border to images, and the apparently intentional, active enforcement of single-space-after-sentence even when editing annoy me deeply. (Yes, that’s how I roll. Let’s not have the spacing argument here, please.)

I can see why Medium appeals to so many. It’s pretty frictionless, a lot more so than almost any other tool of its kind I’ve used. I mean, my WordPress install is pretty frictionless to me, but that’s because I invested a lot of time customizing it to be that way. Much like my browser, mail client, and other essential tools.

So anyway, that’s what I found during import and authoring on Medium. Here’s hoping this posts properly, and without the stray “in” that’s somehow shown up in my post, and which I can’t select, mouse to delete or otherwise remove through non-Inspector means. If only I could prepend an “f”!

It didn’t show up when I posted, fortunately.

P.S. I discovered this was the title just before publishing. It was supposed to be just “Medium”. ¯\_(ツ)_/¯

Undoing oncut/oncopy/onpaste Falsities

Inspired by Ryan Joy’s excellent and deservedly popular tweet, I wrote a small, not-terribly-smart Javascript function to undo cut/copy/paste blocking in HTML.

function fixCCP() {
   var elems = document.getElementsByTagName('*');
   var attrs = ['onpaste','oncopy','oncut'];
   for (i = 0; i < elems.length; i++) {
      for (j = 0; j < attrs.length; j++) {
         if (elems[i].getAttribute(attrs[j])) {
            elems[i].setAttribute(attrs[j],elems[i]
            .getAttribute(attrs[j])
            .replace("return false","return true"));
         }
      }
   }
}

Here it is as a bookmarklet, if you still roll that way (as I do): fixCCP.  Thanks to the Bookmarklet Maker at bookmarklets.org for helping me out with that!

If there are obvious improvements to be made to its functionality, let me know and I’ll throw it up on Github.

Everything Looks Like a Nail

I have recently, perhaps inevitably, taken up woodworking as a hobby.  It’s just clichéd enough to be credible, isn’t it?  Web, wood, maybe it’s in the leading “w”.

A programmer friend and I get together Wednesday evenings to try our hand at what is currently best described as rough carpentry.  The usual reason to take up a “physical-world” hobby like woodworking is to “get away from the computer for a while, man!”  But of course we pull out our iPhones to use as calculators, look up techniques, or find online tools that can help us.  The laptops stay indoors, but computers and the internet still smooth our way.

In web terms, we’re past “hello world” and at about the point where we understand the basics of HTML and have set a few colors and faces with beginner CSS.  We could put up a single-column fan site if that were the goal, but not much more than that.  We’re still at the stage of making a lot of mistakes and not knowing if our problems spring entirely from not knowing how to use our tools, or also from not knowing enough to realize the tools themselves are deficient.  We’re figuring things out as we go, hitting up YouTube for how-to guides on just about everything.  Wikipedia may aspire to be the site of record for Things of Import, but YouTube holds the sum total of humanity’s practical knowledge, hidden amongst all the pop-star and cat videos.

A lot of the best practices map back and forth, too.  Planning ahead is a core competency, and the more you practice, the better you get at it.  Measurement is vital, and cleverness is as useful as it is dangerous.  The importance of quality tools can’t be overstated.  There are a lot of (very) specialized tools available, but you can get really far with the core set of flexible, time-honored basics.  As long as you have a boatload of clamps, that is.

The one major difference is that there is no versioning in woodworking.  It’s like building a project with only the “Save” command—no milestones, no repositories, no undo.  When you do something, you’re committing to altering the project with no take-backs.  If you get it wrong, you have to find a way to patch over the problem.  If you get it really wrong, you have to scrap what you just did and replace the botched part.  And if you get it really, really wrong, all you can do is scrap the whole thing and start over.

So far we haven’t had to scrap anything.  Our first couple of projects were the classic starters: a simple bookshelf, a firewood box, a more complex bookshelf.  For each, we’ve intentionally stepped up the complexity, a bit at a time.  The first bookshelf was just screwed together, but the pieces were all pretty much the right size and properly aligned.  The firewood box was also screwed together, but it involved angled cuts and hinges and sealant.  The second bookshelf involved a wood router in a variety of ways, both structural and decorative.

As in networking, we swore a lot at the router, but it got us where we needed to be.  Eventually, that is, once we figured out how to properly configure it and deal with its quirks.

I can’t deny that there’s a visceral satisfaction in picking up a hammer and whacking on a thing until it’s properly assembled, or disassembled, as the case may be.  There’s definitely a triumph in finding out you did all the measuring and cutting and aligning just right, much like the rush you get when your first major coding project does what you meant it to do, except more so because you’ve wrestled atoms into doing your bidding.  That’s literal orders of magnitude beyond wrangling electrons.

Our next steps are what I assume is the usual second phase: building a wood shop in order to learn how to use a wood shop.  We’re moving up to building fold-down work surfaces with tool storage, custom-fitted wood storage, and braced shelves.  That experience will enable us to move into other, more complicated projects.  Some we already have in mind.  Others will suggest themselves to us.  At every step, we’ll look for new skills to try and practice.

And that, I think, is the real ultimate goal here: to teach ourselves new things, to enrich our skill sets and create useful objects thereby.

So it’s pretty much like working on the web.

Well, except for all the staining.

This article was originally published at The Pastry Box Project on 2 July 2015.

Gradient Flags

With the news today of the Supreme Court’s decision in Obergefell v. Hodges, and my recent completion of the part of CSS:The Definitive Guide that deals with gradients, I thought I’d create a couple of flags using linear gradients.

First, I’ll define the basic box of the flags.  The dimensions are the same as those specified for the U.S. flag, 1:1.9.  I added a couple of box shadows for visual constrast with the background.

div {height: 10em; width: 19em; margin: 3em;
    box-shadow: 0 0 0.5em rgba(0,0,0,0.25),
        0.4em 0.6em 0.5em rgba(0,0,0,0.25);}

Okay, with that set, first up is what’s often called the pride flag, which is to say the “rainbow flag”.  There’s an interesting history to the design of the flag, but I’m going to stick with “the six-color version popular since 1973”, as Wikipedia puts it.

For such a flag, we just need color stripes with hard stops between them.  That means putting the color stops right up against each other, like so:

div#rainbow {
    background: linear-gradient(180deg,
        red 0%, red 16.7%, 
        orange 16.7%, orange 33.3%,
        yellow 33.3%, yellow 50%, 
        green 50%, green 66.7%, 
        blue 66.7%, blue 83.3%, 
        purple 83.3%, purple 100%);
}

The first red 0% isn’t really necessary, nor is the last purple 100%, but I left them in for the sake of consistency.  You could remove them both in order to make the CSS a little smaller, and still get the same result.  I decided to go from red to purple, as the spectrum is usually described, which meant having the gradient ray point from top to bottom.  Thus 180deg, although to bottom would be completely equal in this case.

Now for the US flag.  In this case, things get a little more interesting.  I’ll note right up front that I’m not going to put in any stars, in order to keep this simple and gradient-focused, and yet it’s still interesting.  We could use a repeating linear gradient, like so:

repeating-linear-gradient(180deg,
    #B22234, #B22234 0.77em, white 0.77em, white 1.54em)

That would then cause each red-white pair of stripes to repeat vertically forever.  Because the specified stripes are manually calculated to be 1/13th of the height of the overall flag (10em), they’ll just fit like they should.

The problem there is that if the overall flag size ever changes, like if the height and weight are converted to pixels, the stripes will get out of sync with the dimensions of the flag.  Fortunately, we don’t have to rely on ems here; we can use percentages.  Thus:

repeating-linear-gradient(180deg,
    #B22234, #B22234 7.7%, white 7.7%, white 15.4%)

Ta-da!  The stripes are the right sizes, and scale with any changes to the height and width of the flag, and repeat as required.

That’s all well and good, but we still need the blue canton (as it’s called).  Since the canton will be on top of the stripes, it actually needs to come first in the comma-separated value list for background-image.  That gives us:

background-image:
    linear-gradient(0deg, #3C3B6E, #3C3B6E),
    repeating-linear-gradient(180deg,
        #B22234, #B22234 7.7%, white 7.7%, white 15.4%);

Wait.  A blue-to-blue gradient?  Well, yes.  I want a consistent blue field, and one way to create that is a gradient that doesn’t actually grade.  It’s a quick way to create a solid-color image that can be sized and positioned however we like.

So, now we size and position the canton.  According to the official design specifications for the flag, the canton is the height of seven stripes, or 53.85% the height of the overall flag, and 40% the width of the flag.  That means a background-size of 40% 53.85%.  The stripes we then have to size at 100% 100%, in order to make sure they cover the entire background area of the flag.  Finally, we position the canton in the top left; the stripes we can position anywhere along the top. so we’ll leave them top left as well.

The final result:

div#usa {
    background-image:
        linear-gradient(0deg, #3C3B6E, #3C3B6E),
        repeating-linear-gradient(180deg,
            #B22234, #B22234 7.7%, white 7.7%, white 15.4%);
    background-size: 40% 53.85%, 100% 100%;
    background-repeat: no-repeat;
    background-position: top left;
}

And if you, like Bryan Fischer, believe that morally speaking “6/26 is our 9/11”, you can move the canton from top left to bottom left in order to invert the flag, which is permitted “as a signal of dire distress in instances of extreme danger to life or property”.

(Of course, it’s a lot easier to do that with background positioning since I didn’t include the stars.  If the stars were there, then we’d have left the canton’s position alone and done a rotateX() transform instead.)

So, there you go: two gradient flags.  You can see both (along with the “distress” variant) on this test page.  If you’ve any desire to use any or all of them, go ahead.  No copyright, trademark, patent, etc., etc. is asserted, implied, etc., etc.  I just wanted to have a little fun with gradients, and thought I’d share.

June 2016
SMTWTFS
May  
 1234
567891011
12131415161718
19202122232425
2627282930  

Archives

Feeds

Extras