# Teaching: General case first or special cases first?

A common dilemma while teaching (I’m not only talking about teaching in a school or university; talks and workshops are also teaching), is whether it’s better to first teach some easy special cases and then generalize, or first the general case and then present special cases as merely shortcuts.

I’ve been revisiting this dilemma recently, while preparing the slides for my upcoming regular expressions talks. For example: Regex quantifiers.

## 1. General rule first, shortcuts after

You can use {m,n} to control how many times the preceding group can repeat (m = minimum, n = maximum). If you omit n (like {m,}) it’s implied to be infinity (=”at least m times”, with no upper bound).

• {m, m} can also be written as {m}
• {0,1} can also be written as ?
• {0,} can also be written as *
• {1,} can also be written as +

• Harder to understand the general rule, so the student might lose interest before moving on to the shortcuts
• After understanding the general rule, all the shortcuts are then trivial.
• If they only remember one thing, it will be the general rule. That’s good.

## 2. Special cases first, general rule after

• You can add ? after a group to make it optional (it can appear, but it may also not).
• If you don’t care about how many times something appears (if at all), you can use *.
• If you want something to appear at least once, you can use +
• If you want something to be repeated exactly n times, you can use {n}
• If you want to set specific upper and lower bounds, you can use {m,n}. Omit the n for no upper bound.

• Easy to understand the simpler special cases, building up student interest
• More total effort required, as every shortcut seems like a separate new thing until you get to the general rule
• Special cases make it easier to understand the general rule when you get to it

## What usually happens

In most cases, educators seem to favor the second approach. In the example of regex quantifiers, pretty much every regex book or talk explains the shortcuts first and the general rule afterwards. In other disciplines, such as Mathematics, I think both approaches are used just as often.

What do you think? Which approach do you find easier to understand? Which approach do you usually employ while teaching?

# Poll: ¿Is animation-direction a good idea?

## ¿animation-direction?

Lets assume you have a CSS animation for `background-color` that goes from a shade of yellow (#cc0) to a shade of blue (#079) and repeats indefinitely. The code could be something like this:

``````@keyframes color {
from { background: #cc0 }
to { background: #079 }
}

div {
animation: color 3s infinite;
}``````

If we linearize that animation, the progression over time goes like this (showing 3 iterations):

As you can see, the change from the end state to the beginning state of a new iteration is quite abrupt. You could change your keyframes to mitigate this, but there’s a better way. A property with the name `animation-direction` gives a degree of control on the direction of the iterations to smooth this out. It also reverses your timing functions, which makes it even smoother.

In early drafts, only the values `normal` and `alternate` were allowed. `normal` results in the behavior described above, whereas `alternate` flips every other iteration (the 2nd, the 4th, the 6th and so on), resulting in a progression like this (note how the 2nd iteration has been reversed):

The latest draft also adds two more values: `reverse` which reverses every iteration and `alternate-reverse`, which is the combination of both `reverse` and `alternate`. Here is a summary of what kind of progression these four values would create for the animation above:

## The problem

I was excited to see that `reverse` and `alternate-reverse` were finally added to the spec, but something in the syntax just didn’t click. I initially thought the reason was that these four values essentially set 2 toggles:

• ¿Reverse all iterations? yes/no
• ¿Reverse even iterations? yes/no

so it’s pointless cognitive overhead to remember four distinct values. I proposed that they should be split in two keywords instead, which would even result to a simpler grammar too.

The proposal was well received by one of the co-editors of the animations spec (Sylvain Galineau), but there was a dilemma as to whether mixing `normal` with `alternate` or `reverse` would make it easier to learn or more confusing. This is a point where your opinion would be quite useful. Would you expect the following to work, or would you find them confusing?

• `animation-direction: normal alternate;` /* Equivalent to animation-direction: alternate; */
• `animation-direction: alternate normal;` /* Equivalent to animation-direction: alternate; */
• `animation-direction: normal reverse;` /* Equivalent to animation-direction: reverse; */
• `animation-direction: reverse normal;` /* Equivalent to animation-direction: reverse; */

## A better (?) idea

At some point, in the middle of writing this blog post (I started it yesterday), while gazing at the graphic above, I had a lightbulb moment. ¡These values are not two toggles! All four of them control one thing: which iterations are reversed:

• `normal` reverses no iterations
• `reverse` reverses all iterations
• `alternate` reverses even iterations
• `alternate-reverse` reverses odd iterations

The reason it’s so confusing and it took me so long to realize myself, is that the mental model suggested by these keywords is detached from the end result, especially in the case of `alternate-reverse`. You have to realize that it works as if both `alternate` and `reverse` were applied in sequence, so `reverse` first reverses all iterations and then `alternate` reverses the even ones. Even iterations are reversed twice, and are therefore equivalent to the original direction. This leaves the odd ones as being reversed. It’s basically a double negative, making it hard to visualize and understand.

I thought that a property that would reflect this in a much more straightforward way, would be `animation-reverse` (or `animation-iteration-reverse`), accepting the following values:

• `none` (equivalent to animation-direction: normal)
• `all` (equivalent to animation-direction: reverse)
• `even` (equivalent to animation-direction: alternate)
• `odd` (equivalent to animation-direction: alternate-reverse)

Not only this communicates the end result much better, but it’s also more extensible. For example, if in the future it turns out that reversing every 3rd iteration is a common use case, it will be much easier to add expressions to it, similar to the ones :nth-child() accepts.

I knew before proposing it that it’s too late for such drastic backwards-incompatible changes in the Animations module, however I thought it’s so much better that it’s worth fighting for. After all, `animation-direction` isn’t really used that much in the wild.

Unfortunately, it seems that only me and Sylvain thought it’s better, and even he was reluctant to support the change, due to the backwards compatibility issues. So, I started wondering if it’s really as much better as I think. ¿What are your thoughts? ¿Would it make it simpler for you to understand and/or teach? Author feedback is immensely useful for standardization, so please, ¡voice your opinion! Even without justifying it if you don’t have the time or energy. Gathering opinions is incredibly useful.

## TL;DR

1. ¿Is `alternate reverse` and `reverse alternate` (either would be allowed) a better value for `animation-direction` over `alternate-reverse`?
2. ¿If so, should redundant combinations of `normal` with `alternate` or `reverse` also be allowed, such as `normal alternate`?
3. ¿Or maybe we should ditch it altogether and replace it with `animation-reverse`, accepting values of `none`, `all`, `even`, `odd`?

Side note: If you’re wondering about the flipped question and exclamation marks (¿¡) it’s because I believe they improve the usability of the language if widely adopted, so I’m doing my part for it 😉 And no, I don’t speak Spanish.

# Text masking — The standards way

As much as I like .net magazine, I was recently outraged by their “Texturizing Web Type” article. It features a way to apply a texture to text with `-webkit-mask-image`, presenting it as an experimental CSS property and misleading readers. There are even -moz-, -o- and -ms- prefixes for something that is not present in any specification, and is therefore unlikely to ever be supported by any non-WebKit browser, which further contributes to the misdirection. A while back, I wrote about how detrimental to our work and industry such proprietary features can be.

A common response to such complaints is that they are merely philosophical and who cares if the feature works right now and degrades gracefully. This argument could be valid for some cases, when the style is just a minor, gracefully degrading enhancement and no standards compliant alternative is present (for example, I’ve used `::-webkit-scrollbar` styles myself). However, this is not the case here. We have had a standards compliant alternative for this for the past 11 years and it’s called SVG. It can also do much more than masking, if you give it a chance.

# How I got into web development — the long version

I’m often asked how I got into web development, especially from people that haven’t met many women in the field. Other times it’s people with little kids and they are asking for guidance about how to steer them into programming. I promised them that I would write a long post about it at some point, and now that I’m in the verge of some big changes in my life, I’ve started reflecting on the fascinating journey that got me here.

Rebecca Murphey wrote something similar a while back (albeit much shorter and less detailed), and I think it would be nice if more people in the field started posting their stories, especially women. I sure would find them interesting and if you give it a shot, you’ll see it’s quite enjoyable too. I sure had a blast writing this, although it was a bit hard to hit the “Publish” button afterwards.

Keep in mind that this is just my personal story (perhaps in excruciating detail). I’m not going to attempt to give any advice, and I’m not suggesting that my path was ideal. I’ve regretted some of my decisions myself, whereas some others proved to be great, although they seemed like failures at the time. I think I was quite lucky in how certain things turned out and I thank the Flying Spaghetti Monster daily for them.

Warning: This is going to be a very long read (over 3000 words) and there is no tl;dr. Continue reading

# Pure CSS scrolling shadows with background-attachment: local

A few days ago, the incredibly talented Roman Komarov posted an experiment of his with pure CSS “scrolling shadows”. If you’re using Google Reader, you are probably familiar with the effect:

In Roman’s experiment, he is using absolutely positioned pseudoelements to cover the shadows (which are basically radial gradients as background images), taking advantage of the fact that when you scroll a scrollable container, its background does not scroll with it, but absolutely positioned elements within do. Therefore, when you scroll, the shadows are no longer obscured and can show through. Furthermore, these pseudoelements are linear gradients from white to transparent, so that these shadows are uncovered smoothly.

When I saw Roman’s demo, I started wondering whether this is possible with no extra containers at all (pseudoelements included). It seemed like a perfect use case for `background-attachment: local`. Actually, it was the first real use case for it I had ever came up with or seen.

# git commit -m “EVERYTHING”

I was working on a project today, when I realized that I had forgotten to commit for days (local only repo). I switched to my terminal, spent at least five minutes trying to decide on the commit message before settling to the completely uninformative “Another commit”. Embarrassed with myself, I shared my frustration with twitter:

The awkward moment when you realize you forgot to commit for days & you can't pick a commit message as nothing describes all these changes.
@LeaVerou
Lea Verou

Immediately, I started getting a flood of suggestions of what that commit message could have been. Some of them were hilarious, some clever and some both. So, I decided I wouldn’t be selfish and I’d share them. Enjoy: Continue reading

# In defense of reinventing wheels

One of the first things a software engineer learns is “don’t reinvent the wheel”. If something is already made, use that instead of writing your own. “Stand on the shoulders of giants, they know what they’re doing better than you”. Writing your own tools and libraries, even when one already exists, is labelled “NIH syndrome”  and is considered quite bad.

# Flexible multiline definition lists with 2 lines of CSS 2.1

If you’ve used definition lists (`<dl>`) you’re aware of the problem. By default, `<dt>`s and `<dd>`s have `display:block`. In order to turn them into what we want in most cases (each pair of term and definition on one line) we usually employ a number of different techniques:

• Using a different `<dl>` for each pair: Style dictating markup, which is bad
• Floats: Not flexible
• `display: run-in;` on the `<dt>`: Browser support is bad (No Firefox support)
• Adding a `<br>` after each `<dd>` and setting both term and definition as `display:inline`: Invalid markup. Need I say more?

If only adding `<br>`s was valid… Or, even better, what if we could insert `<br>`s from CSS? Actually, we can!

# A List Apart article: Every time you call a proprietary feature “CSS3”, a kitten dies

My first article in ALA was published today, read it here:

Every time you call a proprietary feature “CSS3”, a kitten dies

# Vendor prefixes, the CSS WG and me

The CSS Working Group is recently discussing the very serious problem that vendor prefixes have become. We have reached a point where browsers are seriously considering to implement -webkit- prefixes, just because authors won’t bother using anything else. This is just sad. 🙁 Daniel Glazman, Christian Heilmann and others wrote about it, making very good points and hoping that authors will wake up and start behaving. If you haven’t already, visit those links and read what they are saying. I’m not very optimistic about it, but I’ll do whatever I can to support their efforts.

And that brings us to the other thing that made me sad these days. 2 days ago, the CSS WG published its Minutes (sorta like a meeting) and I was surprised to hear that I’ve been mentioned. My surprise quickly turned into this painful feeling in your stomach when you’re being unfairly accused:

```tantek: Opposite is happening right now. Web standards activists are teaching
people to use -webkit-
tantek: People like Lea Verou.
tantek: Their demos are filled with -webkit-. You will see presentations
```[17:27] <tantek> (ASIDE: regarding using -webkit- prefix, clarification re: Lea Verou - she's advocated using *both* vendor prefixed properties (multiple vendors) and the unprefixed version after them. See her talk http://www.slideshare.net/LeaVerou/css3-a-practical-introduction-ft2010-talk from Front-Trends 2010 for example. An actual example of -webkit- *only* prefix examples (thus implied advocacy) is Google's http://slides.html5rocks.com/ , e.g.