DEV Community: Thomas C. Haflich

Alignment in CSS: margin & padding

Thomas C. Haflich — Fri, 29 Jul 2022 00:47:20 +0000

Cover photo by Annie Spratt on Unsplash

First, take a look at this tweet:

// Detect dark theme var iframe = document.getElementById('tweet-1163909018114580480-547'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1163909018114580480&theme=dark" }

That's basically what we're doing with this whole series!

What are margins? What is padding? A quick review of the box model

CSS is basically rectangles inside other rectangles.

Sourced from Wikimedia Commons.

💡 Margins define space around the element, padding creates space inside the element. They are separated by the border.

Percent-based margin & padding

Setting a percentage for left/right properties is easy enough:

/* The HORIZONTAL (left/right) properties */
#some-element {
  margin-left: 5%;
  margin-right: 5%;
  padding-left: 5%;
  padding-right: 5%;
}

This does basically what you would expect.

But setting a percentage height is more complicated. Take a moment to guess what happens when you do this:

/* The VERTICAL (top/bottom) properties */
#some-element {
  margin-top: 5%;
  margin-bottom: 5%;
  padding-top: 5%;
  padding-bottom: 5%;
}

The margin and padding properties accept various formats, but when a percent is specified, they use the width of the element. You can use this to make a responsive perfect square, which is cool, but it's pretty annoying when all you want to do is vertically center something.

An interactive example:

💡 When specifying margin or padding in percent, the logical width is always used, even if the property specified was vertical (top or bottom).

Negative margins

If a positive margin is saying to other elements, "give me this much personal space", a negative margin is saying "come this far into my personal space".

Let's take a look at some examples:

💡 There's no such thing as negative padding.

For more examples on using negative margins to align things vertically, check out the Absolute Positioning part of the series.

Automatic margins

If you've looked for ways to center something in CSS, it's likely that you've seen margin: 0 auto before.

💡 This type of declaration ( 0 auto ) is CSS shorthand. It sets the top & bottom margins to zero, and the left & right margins to auto.

The idea is that in this case, the auto property is calculated as "fill remaining space". If the margin is set to auto on both the left and the right, it will divide the remaining space evenly. This effectively centers the element.

🚨 Auto-margins do not work vertically. There is no "remaining height" in this case, since page height can always expand infinitely. When a remaining space cannot be calculated, the auto-margin is evaluated as 0 (no margin). Automatic margins also only apply to block elements.

Alignment in CSS: Absolute positioning

Thomas C. Haflich — Fri, 29 Jul 2022 00:33:38 +0000

Cover photo by Daniel McCullough.

Welcome back to alignment in CSS! Today's post is fake-sponsored by this gif:

By the way, it's pronounced "gif".

More with absolute positioning and translations

Have you ever tried to use a percent for left, right, top, or bottom for positioning something absolutely? You'd think that something like top: 50% would work to vertically center an element...

Normally the top of the child is flush with with top of the parent, so bumping the "baseline" down aligns the top of the child with the middle of the parent, rather than truly centering it.

In order for something to be aligned, we want the middle of the parent and the middle of the child to be along the same axis.

So how do we get the child element's middle to where its top currently is?

If you happen to know the height of your inner element, and your element is positioned outside of the document flow (such as position: absolute; top: 50%;) you can almost certainly use a negative margin to bump it up:

The formula for this is that you want margin-top = -0.5 * $height. That is half the height of the inner container, with the margin being negative to push it in the "up" direction instead of what it would normally do (which is "down").

💡 Why can't I use a margin-top: -50%?

Because CSS is cruel. The margin and padding properties accept various formats, but when a percent is specified, they use the width of the element. You can use this to make a responsive perfect square, which is cool, but it's pretty annoying when all you want to do is vertically center something.

If you don't know what your height is, you can use CSS transforms, particularly translateY. This one doesn't even require any math, you just apply transform: translateY(-50%) to the inner container.

This works just as well, and since it's a 2d transform it's pretty well supported.

JavaScript WTFs explained - Number type and floating point

Thomas C. Haflich — Thu, 28 Jul 2022 23:44:59 +0000

Cover Photo by Tony Tran on Unsplash

Source:

Just started learning JavaScript and have a lot of questions that begin with “Why/How tf”

Jul 26 '22 Author: ievisheleo

See Full Post

About binary and numeric representation

Computers don't have ten fingers to count on - they use a system called binary, which functions very similarly to our base-ten number system, but with only two digits (0 and 1) instead of ten (0 through 9).

Some resources if you need a quick lesson on how this works:

Trevor Storr - How to count in binary

Khan Academy - Adding in binary

Low Level JavaScript - Floating point explained

`9999999999999999` evaluates to `10000000000000000`

This is not specific to JavaScript by any means! It's another consequence of how computers handle numbers and math.

💡 About how computers represent numbers

When you think of a big number, your brain has an advantage over computers. You don't need to reserve a certain amount of space in order to think about that number; you can be as precise or imprecise as you want, without your brain crashing. Probably.

In order for a computer to think about a number, it first needs to know roughly how large and how precise it is, so it can reserve the right amount of space for it in its memory.

Because of how computers represent numbers, if you have a number with a lot of "information" in it (very large, very precise, or both), the computer might run out of "space" for that number. In some circumstances, this just throws an error (the computer gives up). In JavaScript and many other languages, the number is reduced to a version that has less "information" to store.

JavaScript has a maximum number, over which it cannot guarantee precision for integers: Number.MAX_SAFE_INTEGER. You can get a value for this in the console:

> Number.MAX_SAFE_INTEGER
> 9007199254740991

And as you can see, our value of 9999999999999999 is over that threshold, so it will not be guaranteed to be accurate.

`0.5 + 0.1 === 0.6`, but `0.1 + 0.2 !== 0.3`

In JavaScript, when you add 0.1 and 0.2 together in the console, here's what you get:

> 0.30000000000000004

Almost - but not exactly - 0.3.

This is another consequence of how computers handle numbers, and is again not specific to JavaScript - in fact, any language that uses floating point decimals will have this problem.

When you tell a computer about a base-10 number, like 0.5 (one half), it internally is thinking about this number in binary as 0.1 (not one-tenth, since in binary that's the "halves place" and not the "tenths place").

Let's convert all these numbers to binary:

0.1 in base ten => 0.00011[0011...] in binary
0.2 in base ten => 0.00110[0110...] in binary
0.3 in base ten => 0.01001[1001...] in binary
0.5 in base ten => 0.1 in binary
0.6 in base ten => 0.10011[0011...] in binary

You may notice that a lot of those contain infinitely repeating decimals. Computers aren't so great with infinite things, so they just write down however much they can, and stop when they run out of space to store the number.

These infinitely repeating decimals are the core of this particular issue.

Let's look at adding 0.1 and 0.5, which is easy even for us humans, since 0.5 has such a tidy representation in binary.

(The logic for addition in binary is the same in base ten, except you "carry" when you get to two rather than ten. Luckily, this problem doesn't involve any carrying at all!)

  0.00011[0011...] // 0.1
+ 0.1              // 0.5
= 0.10011[0011...] // 0.6

For this one, you could cut off the repeating decimal at any point and the value of 0.1 + 0.2 would have the same representation as 0.3. We can tell this easily because one of the numbers does not infinitely repeat. Therefore, the infinite part of the result must come from the infinite part of the 0.1.

Now let's try 0.1 plus 0.2 (You do need to learn how to carry for this one, sorry):

  0.00011[0011...] // 0.1
+ 0.00110[0110...] // 0.2
= 0.10011[0011...] // 0.3

These are the same if you have the ability to think about infinitely long numbers. But what about a computer? They need to cut off the repeating decimals at some point.

Let's take another look at what happens if we cut it off at, say, seven decimal places:

  0.0001100 // approximately 0.1
+ 0.0011001 // approximately 0.2
= 0.1001101 // close to 0.3, but...
  0.1001100 // this is what 0.3 actually looks like when approximated to 7 decimal places!

💡 All languages that use floating point numbers will have some form of this problem.

Those languages may not face this exact issue - it depends on where exactly the program gives up keeping track of infinitely repeating decimals.

`typeof NaN` is `"number"`

This is partially a language decision, but also partially due to how computers don't do math quite like humans do.

NaN (Not a Number) is typically seen when a numeric system encounters non-numeric data (for example, parseInt("a")). However, it is defined in the IEEE764 floating point spec as any numeric concept or value that doesn't represent a single real number, such as:

A number with a complex component (as in 2 + 3 i, where i is the square root of -1)
A result of a numeric operation of numbers that has an indeterminate result
A result of an invalid mathematical operation
The result of a mathematical operation where one of the operands is NaN

JavaScript's Number type is based on this floating point specification, so it makes sense that the type also includes NaN. Number also includes non-numbers that are more conceptual, such as Infinity.

If you think of Number as "math stuff", it probably makes more sense.

...I do agree that it's hilarious, though.

`Math.max()` is `-Infinity` and `Math.min()` is `Infinity`

These functions both typically take list of arguments, such as:

Math.max(2, 3, 4); // returns 4
Math.min(2, 3, 4); // returns 2

So these are basically the functions being called with an "empty array" of arguments.

If you take the maximum or minimum value of an empty list, what would you expect the result to be? The question itself - what is the smallest value in an empty list of things? - sounds like a question a Zen master would ask. The answer might not have any meaning at all, so it falls to us to make sure it's at least practical.

Let's go over this one by example - if you had an array of numbers (in any language), what sort of algorithm would you use to find the smallest or largest? A bit of pseudo-code for the most common algorithm to replicate Math.max:

given LIST OF ARGUMENTS
variable RESULT
for (each ITEM in the LIST OF ARGUMENTS):
  is the ITEM greater than the current RESULT?
    if so, replace RESULT with the ITEM's value
    otherwise, do nothing; continue on to the next ITEM.
return RESULT

The question here is - what should the initial value of RESULT be? There are two intuitive answers that work well:

It should be an empty value such as null or undefined. This means that you have to update the algorithm a little bit to account for the empty value, and people who use this will need to note that the return value may be empty or zero, and they will need to be careful to not confuse the two.*
It should be something that is always "less than" any finite number. in JavaScript, -Infinity satisfies that logic. The logical consequence to this is that if there is nothing in the list of arguments, the -Infinity will be returned.

* If you've ever coded in PHP, this likely brought back traumatic memories. I'm sorry.

Both of these work just fine, and the only thing that's affected is the (probably rare) case of being called with an empty list of things to compare, and some extremely minor performance differences. Not an important choice in the long run, so I don't blame JavaScript for this one. At least we don't have to check the return value for null every time.

You made it to the end! Thanks for sticking around. Here's a picture of a kitten in a bowtie to show my appreciation (via reddit).

The other half of the Reddit post is discussed here.

JavaScript WTFs explained - Type coercion

Thomas C. Haflich — Thu, 28 Jul 2022 23:44:37 +0000

Cover Photo by Tony Tran on Unsplash

Source:

Just started learning JavaScript and have a lot of questions that begin with “Why/How tf”

Jul 26 '22 Author: ievisheleo

See Full Post

The few examples to follow look pretty unhinged, fair warning.

The factor most at fault is automatic type conversion due to loose typing, but operator overload is also a problem.

The plus `+` operator is overloaded

The + operator in JavaScript has two different functions. As you might expect, it can add numbers together, but it can also concatenate strings.

💡 Concatenation is when two (or more) strings are taped together to form a new, combined string.

For example, concatenating "hello" and "world" results in "helloworld".
This is done with the + operator in JavaScript, but other languages might use other methods, such as a concat() function or a different operator.

When an operator can do multiple different things like this, it is referred to as an overloaded operator.

By contrast, if you look at the minus - operator, it only does math, and doesn't have a defined operation for strings at all. Minus is not overloaded.

Type coercion

JavaScript has two distinct equality operators, one that compares content but not type (==), and one that compares content and type (===).

const a = "2"; // string
const b = 2; // number

a == b; // "2" == "2"
a === b; // "2" === 2

So how does the loose equality operator (==) determine if two variables have the "same" content? It converts one or both values.

Taking a look at "2" == 2, let's go over the process step-by-step.

Check if both values are of the same type. In this case, they aren't, and need to be converted.
Determine the type(s) to convert to. JavaScript's loose equality algorithm determines which values to convert, and to what. In this case, the string is converted to a number.
Compare the converted values. In this case, 2 (converted from string) and 2 (original) are equal, so the return value is true.

Another resource to check for this is the JavaScript Equality Table.

💡 Advanced note on equality for arrays and objects

So far, we've looked at strings and numbers for == and ===, but it functions differently for more complicated constructs like arrays and objects. In these cases, both operators check that the operands have the same reference. For more information, see MDN.

Empty array + empty array

Let's take a look at the first (and easiest to explain), empty array plus empty array.

[]+[]; // evaluates to ""

Here's what's happening:

JavaScript sees the + operator and thinks about what types are valid for this: strings and numbers. Additionally, the two operands should match each other.
- Two strings will be concatenated ("a" + "b" => "ab")
- Two numbers will be added numerically (1 + 2 => 3).
JavaScript looks at what the actual variables used in the operation, and sees if any need to be converted. In this case, both arrays need to be converted, since they aren't strings or numbers. For +, both arguments must be converted to "primitive" values (either a string, number, or boolean).
JavaScript uses a specific set of logic to cast the arguments to the type it wants
- Arrays are converted to a predetermined primitive type, which is a string 📝. An empty array becomes an empty string, "".
Two empty strings concatenated together make an empty string - and there's your result!

📝 How does an array become a string?

In JavaScript, you can test this out by using String([...]) or ([...]).toString() to observe how different arrays are transformed into strings.

The elements in the array are transformed into strings, and those stringified elements are joined together with a comma.
String(["a", "b"]); // "a,b"
String(["a", 2, ["b", 3]]); // "a,2,b,3"
This is much different from the result of JSON.stringify!

Empty array + empty object

This one works very similarly to the above. JavaScript determines that both operands need to be strings in order to continue, and converts them both. As we have seen previously, [] becomes "".

The only difference is that an empty object {}, when cast to a string, becomes "[object Object]".

💡 Why "[object Object]"?

From https://stackoverflow.com/a/25419538

As others have noted, this is the default serialisation of an object. But why is it [object Object] and not just [object]?

That is because there are different types of objects in Javascript!

Object specification

Empty object + empty array

Despite the title of this section, the {} is actually not interpreted as an object.

When used at the start of an expression, and there's no other indication that it ought to be an object, JS decides it's a block statement instead.

Here's what a non-empty block statement looks like:

{
    let foo = 'bar';
    console.log(foo);
}

You've seen these before, though they're usually used with constructs like if-statements, loops, and the like:

if (true) {
    let foo = 'bar';
    console.log(foo);
}

In the case of this particular example, it's interpreted as an empty block statement, which is functionally equivalent to typing nothing.

The reason the previous example was interpreted as an empty object instead of an empty block was that it was being used as a right-hand operand for +. JavaScript supports + being used to cast to number type when used without a left-hand operand:

// left and right
1 + "1"; // "11"

// casting with right-side only
+"1"; // 1
+1; // 1
+true; // 1

Thus, we can reduce the problem to +[].

When JS converts an array to a number, it is effectively the same as casting that same array to a string (as seen in the two previous examples), then casting that string to a number. (Note that casting the array to a string converts values such as null and undefined to empty string as well.)

[].toString(); // ""
Number(""); // 0

["1"].toString(); // "1"
Number("1"); // 1

["1", "2"].toString(); // "1,2"
Number("1,2"); // NaN, can't parse this

["a"].toString(); // "a"
Number("a"); // NaN, can't parse this

So now we can see where the 0 comes from - it's the numeric value of an empty string.

Type coercion with different operators

So far we've worked only with the + operator, which is an overloaded operator: it can be used for more than one thing, depending on the operands. However, the mathematical opposite, -, is only used for mathematical subtraction, and can't be used to manipulate strings at all.

The examples used in the reddit post:

9 + "1"; // "91"
91 - "1"; // 90

Since one of the operands of 9 + "1" is a string, even if it's a numeric string, the + operation results in a string concatenation.

However, since - cannot be used for string concatenation, the "1" is interpreted as numeric.

Here are some more examples of this principle in action:

// two numeric operands is always math
1 + 2; // 3
1 - 2; // -1

// numeric strings are concatenated for addition, and converted for subtraction
1 + "2"; // "12"
"1" + 2; // "12"
"1" + "2"; // "12"
1 - "2"; // -1
"1" - 2; // -1
"1" - "2"; // -1

// non-numeric strings are concatenated for addition, and result in a math error for subtraction
1 + "hello"; // "1hello"
"hello" + 1; // "hello1";
1 - "hello"; // NaN
"hello" - 1; // NaN

When is a `true` a `1`?

true + true + true === 3; // true
true - true; // 0

As in the section dealing with []+[], we know that JavaScript will convert operands if they aren't of the appropriate type. In this case, the boolean value true is cast to a numeric 1, and as we all know, 1 + 1 + 1 is in fact three.

Similarly, 1 - 1 we know to be zero.

Note that these can be cast to the strings "true" and "false", for example when a string is an operand:

1 + "hello" + true + false; // "1hellotruefalse"

When is a `true` not a `1`?

true == 1; // true
true === 1; // false

The numeric value of true is 1, so the loose equality operator sees them as having the same value.

The reddit post lists the following statements:

true == 1; // yes, because true is cast to 1
true === 1; // no, because true and 1 are not the same type
[] == 0; // yes, because empty array is cast to 0 (see empty object + empty array example)

Abusing type coercion for fun and profit

The last example from reddit is basically a gigantic exercise in learning automatic type conversion, so let's break it down.

(!+[]+[]+![]).length; // 9

The first thing we need to ask here is: The length of what, exactly? Let's take a look at what's in those parentheses.

!+[]+[]+![]; // "truefalse"

The .length might have led to you believe that it was an array of length 9, but here we have a string of length 9. Now, let's figure out why we get that string out of that expression.

Let's separate it out a little bit, so it's more readable:

(!+[]) + ([]) + (![]);

That first set of parentheses contains two explicit conversions, which are worked from the "inside out" - the closest conversion to the value goes first, then it works its way outwards. So first, [] is our value, which is converted to a number by +[], which results in 0. Next, the ! converts the number to a boolean value and inverts it - 0 converts to a boolean false, which when inverted results in true.

Let's leave that empty array in the middle for a moment. It isn't being explicitly cast.

On the right, we have ![] - at first glance, it seems like this also ought to be true, since !+[] is true. However, the extra conversion to number makes all the difference! When converted directly to a boolean value, an empty array results in true, which when inverted is false.

Number([]); // 0
Boolean([]); // true
Boolean(0); // false

So now, we have the simplified form of our expression from earlier:

true + [] + false

Now on to that + operand. The choice with + is either numeric plus, or string concatenation, and JavaScript's internal ruleset says that when you are using + with a boolean and an array, both are cast automatically to strings and concatenated. From left to right, we can work this expression out:

// true + [] + false
true + []; // "true"
"true" + false; // "truefalse"

And there you have it.

Wait, so... why?

Why is JavaScript loosely typed, and why does it do automatic type conversion?

Brandon Eich designed the language in 1995 in under two weeks. I don't really think there's a "why" to it, to be honest. Maybe we can blame a lack of sleep on his part.

Why does X convert to Y?

There is an internal logic to all the automatic type conversion JavaScript does - it is, after all, run by a computer, and computers don't just spontaneously decide to do something a little different to mess with you.

You might notice that arrays and objects are tricky, being cast to many different possible primitive values:

// empty arrays
Number([]); // 0
String([]); // ""
Boolean([]); // true

// arrays with stuff in them
Number(["a"]); // NaN
Number([1]); // 1
Number([2]); // 2
Number([1, 2]); // NaN
Number([null]); // 0
Number([true]); // NaN
String(["a"]); // "a"
String(["a", 1]); // "a,1"
String([null]); // ""
Boolean([false]); // true

// empty objects
Number({}); // NaN
String({}); // "[object Object]"
Boolean({}); // true

Most JavaScript-specific WTFery actually depends, deep down, on these conversions.

Final notes

Much of this isn't JavaScript-specific. The many examples of JavaScript shenanigans are often simple floating-point errors, which can be found in any programming language that uses floating point numbers. (Please stop using these as examples of why JavaScript is bad. There's enough wrong about JavaScript to be mad about without bringing in floating point arithmetic.)

The true WTF is not necessarily that JavaScript can do automatic type conversion, but the absolute bonkers scale of how much it will convert, and to what.

What do I even do about this?

If you're coming from a strongly-typed language and/or felt like crying several times during this article, I suggest TypeScript.

If you can't or don't want to use TypeScript, make sure to follow these two rules:

Always use strict equality (===)
Always explicitly convert types, rather than allowing JavaScript to implicitly convert them for you

JavaScript can't break your stuff with automatic type conversion if you've made sure things are the right type to begin with.

You made it to the end! Congrats for wading knee-deep into JavaScript's type system. Have a picture of a squirrel eating at a tiny table for your trouble. (via reddit)

The other half of the Reddit post is discussed here.

Alignment in CSS: text and vertical alignment

Thomas C. Haflich — Sun, 04 Aug 2019 23:11:36 +0000

Cover photo by Alex Wong.

This is the beginning of a long journey to learn how to get things to finally, finally align properly on our webpages.

Today's tutorial is about two properties: text-align and vertical-align. Text align is a very simple property, often the first to be learned by beginners. Vertical align seems to be its simple counterpoint, but can be deceptive due to its complex rules and is an early stumbling block for many.

📌 Text align

The purpose of text-align is to align text horizontally. Play around with it:

If you've worked with any sort of text editor before, these options will be strikingly familiar.

There are more options coming soon - for example, start and end, which depend on the text direction, aligning via a specific character (such as a decimal), and justify-all, which forces the last line of text to be justified. These vary widely in support as of the authoring date (Aug 2019), as they are currently still editor's drafts in terms of specification - so make sure to check compatibility tables before using anything fancy.

References & further reading for text-align:

MDN: text-align

📌 Vertical align

As you might have guessed by the name, the purpose of vertical-align is to align text vertically. In the sample below, I have highlighted some key plant-related phrases; the buttons toggle the vertical align property of these highlights.

If you're applying vertical-align to display: inline or display: inline-block elements, then you will be able to align them with each other. You can align anything that can flow horizontally, as long as it has a valid display property set. Text, images, icons, buttons, inputs...

When using `vertical-align` on inline or inline-block elements, the alignment is relative to sibling elements in a horizontal line, rather than the parent element.

Vertical align also works on tables (as well as elements with display set to table-cell). Here's a sample table to play around with:

An important note:

⚠️ Vertical-align does not align block elements. ⚠️

So if you're thinking... "wait, vertical-align didn't work for me! Why are you telling lies?", look into your element's display property. Vertical-align is not an all-purpose way to align everything. Since block level elements cannot have an in-flow sibling on the same line as them, they will not be aligned. Block elements can, however, have children inherit their vertical-align property; it's not strictly invalid, just useless for positioning.

If you remember the days of table-based layout (way, waaaay back... hopefully), you might remember the valign attribute on table cells. It's speculated that the vertical-align property was created specifically to emulate the behavior of this attribute.

tl;dr

Use this for vertically aligning text, images, icons, or other things that display "in line" with each other horizontally. Unless you're using it in a table, vertical align changes items' behavior relative to each other, rather than with respect to their parent element.

References & further reading for vertical-align:

Bonus vertical align: A tall ghost 👻

Here's a neat trick that uses vertical align. I don't use it in production anymore now that flexbox is well-supported, but it's still a good exploration of how vertical align works.

This trick is an extension of the fact that vertical align works to center inline-block elements with one another.

We have:

An outer container, larger than the inner container
An inner container that we want to center vertically
An invisible "tall ghost" container that only assists with alignment

The important bits:

The tall ghost and inner container are both display: inline-block and vertical-align: middle
The tall ghost is 100% height (that's why it's tall!)
The tall ghost is zero width, to make sure it doesn't throw off alignment (it's invisible)

The invisible aligning element is set to be the height of its parent with height: 100%, so whatever is aligned vertically with the "tall ghost" will happen to align with its parent block element. The two elements inside the container are both inline-block, and so they are available to vertically align with each other. They're both set to vertical-align: middle. And so, the inner container that we want to align (the cat) sits in the middle.

Now, that code is a bit messy, so we can clean it up by using pseudo-elements:

There are a couple other small notes:

The content attribute containing a space is just to make sure the element can render in all browsers.
While the width and height are explicitly set in this example, they do not need to be; as long as the inner content doesn't overflow the parent, this trick will work, since it's based on percentage.
The cat is horizontally centered with text-align: center because I think it looks nice. This is optional.

Anything else you'd like to know about these properties? Any requests for the next entry in the series? I have a lot planned... it turns out CSS has a lot of ways to align stuff. (How come none of them ever work? 🤔)

What is software to you? Day job, passion, hobby, career, something else?

Thomas C. Haflich — Sun, 21 Jul 2019 11:45:29 +0000

Cover photo by Dylan Gillis on Unsplash

We all came to software from different places, and we're all going somewhere different, so I figure we all see it differently as well.

Tell me about how you relate to the field in general, if you would?

Here's how floats work in CSS

Thomas C. Haflich — Sat, 20 Jul 2019 21:36:00 +0000

Cover photo by J A N U P R A S A D via Unsplash.

Does anyone else remember the old days of using floats for layout? We used to have to do our CSS uphill in the snow, barefoot, both ways. Whippersnappers these days with their flexbox and their grids...

In any case, floats are still useful for things that aren't large-scale layout. And even if you don't end up wanting to use them in your newest app, you may end up maintaining an old legacy application that uses a heavy-handed approach to floats. Having a basic knowledge of how they work can come in handy in a variety of situations.

Plus, floats are one of the big CSS fears. Applying a float and having everything on the page suddenly shift (and not knowing why) is something many of us have done. Let's get over that stumbling block today.

So, let's jump right in and examine the mystery of the float.

The basics

This is what floats are best at: Flowing text around other things. Floats are the absolute best way to mimic print layouts when it comes to this.

What is happening is, very simply, this:

The floating element is placed where it would otherwise be
It's removed from the normal document flow and shoved as far left or right as it can go
Elements that come after it will arrange themselves around the floating element

Can I float center?

Nope. I know it would be cool, but it does not work.

I guess imagine how you would implement the text-and-cat-picture version of this. How would you go about breaking the text up neatly? There's no great way to do it. That's probably why it was never implemented.

Floats aren't in the normal document flow? So it's like "position: absolute"?

Not quite. Elements with position: absolute (or a similar property) are removed entirely from the document flow. An absolutely positioned element can often end up on top of or underneath other nearby elements, since they simply ignore each other.

When an element is floated, it's not exactly in the normal document flow, but it does interact with other elements; they are subject to special positioning rules, mostly that they will arrange themselves around it.

Floats don't want to be large

A floating element that doesn't have an explicit size set will "shrink to fit" its content - that is, it will only take up as much width as it needs to. If there's not much content inside of it, it won't be very large; if there's a lot, it gets bigger. You may have seen similar behavior before in position: absolute and position: fixed elements.

Predicting where floats will go

While you were playing around with the Jabberwocky example, did you happen to find something like this?

One of the reasons people tend to avoid floats is that they can seem unpredictable. What happens if a series of floats of different heights overflows its line?

Let's take a look at the specification for how floating elements are positioned:

[...] when an element is floated, it is taken out of the normal flow of the document (though still remaining part of it). It is shifted to the left, or right, until it touches the edge of its containing box, or another floated element.

So when we have something that would fit within our width, all fine and dandy. When it doesn't, it goes downward and floats some more until it hits an edge that it would like to stop at - the edge of its parent container, or another float.

Why didn't the last one move upward to fill in that terrible whitespace?

A float will never position itself above something that comes before it in the HTML order.

It will, however, try to "float" as high as it can, keeping that restriction in mind.

Margins, the box model, and HTML order

In the basic example, were you bothered by this?

What we need here is a margin. You have about a 1/3 chance of guessing which element to apply the margin to if you choose randomly. As much as it feels like random guessing is the essence of CSS, though, let's try to understand what the floats are doing here.

#1 - This is what happens if you add margin-left to the outer container #container - it just shoves everything to the right. This doesn't really fix the problem of the text coming to a hard edge with the floating box. Probably nobody has tried to fix floats this way, except at 3am, crying with desperation. (Who hasn't been there?)

#2 - This is something you might actually have tried - applying a margin-left to the text itself. The text's margin, however, is based on the text's "box" - where the text would be if the float wasn't there. (You can picture it as having a margin "under" the floating element.)

The text itself is still flowing around the float as it was before, but it has a margin left relative to its parent element. The margin property cannot add a "zigzag" margin to the text, and it must have a separation from its parent element represented by the margin, so the separation from the float just won't do.

#3 - The margin is added to the actual floating element, expanding its box. The text will flow around the entire floating box, margin included. So adding margin-right to our left-floating cats and margin-left to our right-floating cats will give the text a bit of space.

In summary - putting the margin on the floating element causes other stuff to flow around the combined float's box, including any margins.

The idea that we're getting at here is this - other stuff on the page moves around the float, rather than the float moving around other stuff on the page.

We can also stack floats next to each other! Floats will sit nicely next to other floats, and the text will keep flowing around them all.

Just note that it's important where in the HTML order the floats are placed. When in doubt, floats come first. Pretend you're the browser, and you're reading the HTML "in order" - you'd want to know where your floating things are first, so you don't have to redraw all the stuff that has to flow around it afterward.

Clearing floats

An element with the clear property on it describes how that element will interact with nearby floating elements. You can put a clear property on both floating things and non-floating things.

The clear property means: I don't want any floats near me, in this direction!

Since it's rude to push other things around the page, the element that has the clear property on it will move downward if there's a conflicting float nearby. Think of a clearing element as being socially awkward and conflict-avoidant.

Floats don't take up space the way you might expect

If you've used floats before, you might have found yourself in this position:

The #container that holds all the floats (and only floats) has collapsed. This is because floating an element removes it from normal document flow, and the surrounding container does not create a new block formatting context.

Remember when I said above:

It's removed from the normal document flow and shoved as far left or right as it can go

"Removed from document flow" has a meaning and technical consequences here!

Due to the rules that our CSS overlords have specified, the height of a container is determined by all of its contents that are "within normal document flow". However, we can also make the container be a "block formatting context" - kind of like a mini-layout within a page - to tell the container that it needs to treat itself as if it's a mini-document, in that it stretches to fit all its contents, even the out-of-flow ones.

We will need to do some convincing to get the container to stretch to fit our floats, but know that we have options.

A couple possible solutions:

1. Create an element that is in-flow, but after the floats

This is the clearfix-type-one solution in the pen above. It's also the "old school" clearfix.

We know now that the container will stretch to fit all elements within its flow, and floats are not in the flow. So we need a non-floating element that's placed just after our floating elements. We can do this using the clear property:

<div id="container">
  <img class="floaty-left" src="https://placekitten.com/100/200">
  <img class="floaty-left" src="https://placekitten.com/100/100">
  <img class="floaty-left" src="https://placekitten.com/160/200">
  <img class="floaty-left" src="https://placekitten.com/100/120">
  <div style="clear: both;"> </div>
</div>

This will cause the container to stretch down to our cleared div.

However, that element will have a bit of its own height (because it's supposed to have some text inside), so we can add something like height: 0 to make sure it doesn't affect the height of the container while continuing to apply the clearfix. Over the years I've seen other ways to do this, such as using max-height and even font-size: 0. ¯\_(ツ)_/¯

Since this is only for display and isn't semantic, we can also move it to an ::after pseudo-element applied to the container.

That's how we end up with something like the following:

  // the "basic" clearfix with after
  &.clearfix-type-one {
    background-color: #644;
    &::after {
      content: " ";
      display: block;
      height: 0;
      clear: both;
      visibility: hidden;
    }
  }

This can be refined even further; there are many similar solutions online. For example, Nicholas Gallagher's micro clearfix from 2011. Clearfix solutions of this type tend to have amazing cross-browser support since they've been around for nearly a decade.

2. Use `overflow: hidden` to create a new block formatting context

(Technically you can use any overflow value that isn't visible, but hidden is the one that tends to work best. Give me a second to explain...)

This is the clearfix-type-two solution in the pen above. From the MDN docs:

A block formatting context contains everything inside of the element creating it.

Thus, forcing the parent container to form a new block formatting context will force it to expand, since it must fully contain all its children. And it's done with just one property, so why isn't this the single best solution? Why is it only number two of three on a list?

Well... you're using overflow: hidden. This isn't consequence-free; you have to deal with having a container that doesn't show anything at all outside of itself. What if we also want to have some rainbow drop shadows on some of our elements that would be clipped, or absolutely positioned glitter outside of our wrapper? It would be madness to get rid of those just to clear our floats.

You can see what a travesty this would be.

And remember how I said earlier that you could use any overflow value that wasn't visible? Well, imagine how crappy that would look with overflow: scroll creating scrollbars on the sides. Big yikes.

3. Use `display: flow-root` to create a new block formatting context

This is the clearfix-type-three solution in the pen above.

Unlike the solutions above, this is meant to work on an inherent level, and isn't a "hack". From the spec:

The element generates a block container box, and lays out its contents using flow layout. It always establishes a new block formatting context for its contents.

So this basically does the same thing as overflow: hidden, but with no side effects. ✨

That sounds like exactly what we want! The reason it isn't used is cross-browser support - it's not currently supported on almost 30% of devices, with Safari and IE/Edge being the problem children as always.

What else do you want to know about floats?

Footer photo by Cristina Gottardi on Unsplash.

A few JavaScript puzzlers

Thomas C. Haflich — Sat, 13 Jul 2019 13:02:13 +0000

Cover photo by Kyle Glenn on Unsplash.

Good morning! 🌥️ How's your weekend going?

I've been sick lately, so haven't had a lot of energy to work on the usual posts. But I've put together a few quick "riddles" specific to JavaScript.

If you get the answers early on, try to not spoil the answers in the comments for those just looking for hints rather than solutions. (Spoiler tags when?)

#1 - Non-reflexive

This one is fairly simple if you know the language "gotchas", but quite a puzzle indeed if you've never seen this behavior before.

x === x; // true
x[+[]] === x[+[]]; // false

There is more than one answer, see if you can find the whole solution space for an additional challenge.

Hint links:

#2 - Reciprocal

Here's another head scratcher:

x === y; // true
1/x === 1/y; // false

Find values of x & y.

The senior JS devs are groaning and probably already know the answer. But for those of you less practiced, here is a hint:

ECMAScript specification

#3 - Prototype

And another one:

var someone = function() {};
someone.prototype.attributes = {};

var alice = new someone();
alice.attributes.name = 'Alice';

var bob = new someone();
bob.attributes.name = 'Bob';

var eve = new someone();

At the end of this code, what is eve.attributes.name?

Your hints are:

Medium
MDN

JavaScript really is quite a puzzling language, isn't it? Which ones did you get immediately, and which did you need to look up?

Have a great weekend, and don't forget to be awesome!

The parable of the turkey: or, The way things have always been done

Thomas C. Haflich — Wed, 26 Jun 2019 23:41:34 +0000

Cover photo by Randy Fath via Unsplash

The story goes:

A young couple, happily married, is celebrating their first Thanksgiving together. The bride wants to cook her husband her family's classic turkey recipe, and asks her mother for the recipe.

Her mother sends her the recipe, and the woman cooks it to perfection. Even the breast-meat is perfectly tender and juicy. However, at the end, her husband remarks: "Darling, where are the legs? I always liked those best."

"There on the side," she tells him.

He picks around the bird, and he seems still confused, so she points them out to him. He asks, "but love, why are they shaped like this? They don't look like drumsticks to me. They're all... squashed-y?"

She says, "It's in the recipe. You take the legs off, take the bones out, and cook the meat on the side."

He still doesn't understand, but the turkey was very tasty, so he leaves it be.

The next day, the woman calls up her mother and asks, "So mom, about that turkey recipe. Why do we take the bones out and cook the meat on the side?"

Her mother replies, "Hm, I don't actually know why. Your grandmother just always did it that way, and it's her recipe."

The mother and grandmother are having a pleasant brunch one morning, and the question of the turkey comes up once more.

"Oh, right," says the mother. "Ma, I gave my daughter your turkey recipe, and she asked about the turkey legs."

"What about them?" asked the grandmother.

"Well, why do we cut them off, take the bones out, and cook the meat on the side?"

The grandmother bursts into gales of laughter. "I did that when you were a kid because my pan was too small to fit the whole turkey!"

At least, that's how it was related to me. There are many variations.

I couldn't find a good way to transition here. I'm making the best of it.

You've probably sussed out the moral of the story by now. But just to make sure we're all on the same page:

Doing what has always been done without knowing why is not a good idea.

Imagine that the young woman had never asked, but instead had to hack some other rig together for her turkey. In several generations, what would this recipe look like? I don't think it would be quite as tasty if all those hasty fixes had been passed down as "I don't know why it works, don't touch it" over the generations.

So if you see some code, and you don't know how it works, you'll get a tastier... program? if you figure it out. It might be on StackOverflow or in your legacy codebase full of technical debt, but consider it your job to learn what it's doing.

Don't fall for the trap of copy-paste driven development!

A width-responsive perfect square in pure CSS

Thomas C. Haflich — Sun, 23 Jun 2019 15:20:01 +0000

Cover photo by Daniel McCullough via Unsplash.

Points of interest

Resizable block-level divs

The resize property - I wasn't aware you could actually control this past textareas, but stumbled upon it when looking for a way to make a user-resizable div without using JavaScript.

How the square is made



#square {
  width: 100%;
  padding-bottom: 100%;
  position: relative;
  background-color: #2980b9;
}

Breaking this down:

width: 100% is to make sure it's defined as having the same width as its outer, resizable container.
padding-bottom: 100% is based on a trick in the CSS spec. When specifying a margin or padding by percentage, it's always based on the width, even if it's a -top or -bottom property. In this way we get a property that's equal to the width.
position: relative is so that I can put stuff inside it without disrupting the padding; any additional content would add content to the box, which would make it a rectangle
background-color is there so you can see where it is ¯\_(ツ)_/¯

How the circle is made

Once you have any square, making a circle is easy enough. The only trick you really need is border-radius: 50%, but let's break down the responsive circle a bit more.



#circle {
  position: absolute;
  top: 0;
  bottom: 0;
  width: 100%;
  height: 100%;
  border-width: 4px;
  border-color: #27ae60;
  border-style: solid;
  border-radius: 50%;
}

position: absolute makes sure that this circle stays within the position: relative square while not adding any in-flow content to it.
top: 0; bottom: 0; width: 100%; height: 100%; constrains the circle to the exact dimensions of the responsive square. At this point, what we have is a position: absolute container that is an inner copy of our square.
The border-* properties are used to build the outline of the circle. We have a 4px green solid border, and it has a radius of half the edge of the square.

Quick geometry recap

Here's an illustration of why 50% is the magic number to make a circle from a square:

The radius of the circle is equal to half the side of the square.

How to actually animate a text gradient in CSS

Thomas C. Haflich — Sat, 22 Jun 2019 23:29:27 +0000

Cover photo by Kristopher Roller via Unsplash.

Since you all liked my iridescent shambling monstrosity, I figured it was worth a second swing. Thanks to @erinjzimmer for letting me know that it's possible to animate the gradient background by animating background-position.

So, instead of writing a humorous article where I make the worst technically-functional CSS possible, let's try to make this thing not terrible. I swear, the only JavaScript I used this time was for the buttons.

I don't have a problem, I can stop whenever I want.

Since we figured out how to get the rainbow text last time, let's jump to the good parts.

Animating background position

To use transitions with this, it's very likely that I would have had to resort to similar tactics as in the previous post (yikes) to make sure that the gradient moved in one direction continuously. But instead of going through all that effort, I decided to use @keyframes, which turned out to be as easy as forgetting to add files before you commit.



@keyframes whoosh {
  0% { background-position-x: 0 }
  100% { background-position-x: 100% }
}

.animated-thing {
  animation-name: whoosh; // references @keyframes name
  animation-duration: 2000ms; // or whatever
  animation-timing-function: linear;
  animation-iteration-count: infinite;
}

There's an important caveat to be mentioned to make this look good, though.

A... catveat? Eh?

The cat image is 200px wide, and the window is either 400px wide or 500px wide. (Click to toggle.) When the container is 400px wide, the animation is smooth and you don't notice it suddenly resetting to the beginning when it loops. When it's 500px wide, the end of the animation is 100px offset and the jump is very noticeable.

Using gifs for illustration:

When the loop resets, it's in the same position as when it started, making the looping is much less noticeable. (There may still be a jump, but it should be very small.)

Despite the cuteness of this fluffy cloud-friend, the jump is very noticeable due to the camera turning downward sharply at the last moment. Would pat cat, would not animate smoothly.

Another issue is that setting the background to be exactly the same width as its container in this case causes it to not animate. I guess CSS thinks it has nowhere to go! So it needs to be some exact fraction or exact multiple, but not equal. And it needs to reset to the exact same position it started in.

Animating background position with gradients

To make CSS actually animate it, I set the background-size to 200% width (and 100% height). That was the easy part.

To get the gradient to animate smoothly was trickier.



  $first-color: #996699;
  $second-color:  #B39500;
  $third-color:  #009980;
  $fourth-color: #006699;
  $angle: 75deg;

  background-image: linear-gradient(
    $angle,
    // so you can see the repetition of colors easily
    $first-color,
    $second-color,
    $third-color,
    $fourth-color,
    // repeat a second time
    $first-color,
    $second-color,
    $third-color,
    $fourth-color,
    // back to the first color
    $first-color
  );
}

This is how the gradient is set up so that it doesn't appear to "jump" when the loop resets. It needs to repeat twice, but also repeat the first bit of the loop. In the final pen, this was turned into a mixin.



@mixin flag-gradient($direction: null, $color-stops...) {
  $grads: $color-stops;
  @each $stop in $color-stops {
    $grads: append($grads, $stop);
  }
  $grads: append($grads, nth(nth($grads, 1), 1));

  // [ clipped ]

  background-image: linear-gradient($direction, $grads);
}

This does all that repetition work for you. It copies the arg list sent in, then loops over it to append each of the new color stops (hmu if you know a better way to do that part), Then picks out the color part of the first color stop and tacks that onto the end. That way you only need to specify your actual flag colors.

Also take note of the angle you put the gradient towards - the steeper it is, the more noticeable the jump will be. Somewhere between 75 and 90 is nearly invisible but still looks tilty enough to be aesthetically pleasing. The smaller the width the sharper this angle needs to be, as well. 90 is safe!

If you're viewing the inline pen on dev.to, you'll see the 90 degree variant, because of this bit:



@mixin flag-gradient($direction: null, $color-stops...) {
  // [ clipped ]

  @if $direction == null {
    $direction: 75deg;
    @media only screen and  (max-width : 800px) {
      $direction: 80deg;
    }
    @media only screen and  (max-width : 500px) {
      $direction: 90deg;
    }
  }

  // [ clipped ]
}

Since the animation quality varies so sharply based on the angle & width, I auto adjusted it if you don't send an override.

Adding more flags 🏳️‍🌈 (refactoring)

After I got the initial rainbow animation going, it seemed... too easy. I needed to work harder in the eternal struggle against CSS. I wondered, was this able to be generalized? Could I show even more pride?

In the bi pride flag, I discovered another interesting caveat. In order to make the jumps less noticeable, the gradient should be as smooth as possible. Using percentage based color stops generally turns out poorly; just plain duplicating the colors turned out to have better results.

Hm, I'd really like to see a text shadow on there to make the white bits not blend into the background so much. White shows up on a few different flags, so it's definitely a general issue.

That went well.

This is actually entirely logical, if you think about it. The entire reason the gradient text trick works in the first place is by making the text itself transparent, and clipping the background; not by actually applying the background to the text.

I did look into fixing this. StackOverflow suggests:

Basically, the idea is to have 2 div overplayed on each other. The lower one provides the background and the shadow. And the the div above just uses a mask to cut out the exact same text from the background image, so that it covers the text of lower element, but not the shadow:

2 div overplayed on each other

Not going down that road again! You can't make me!

Close enough.

After a bit of playing around with various flag designs and colors, I settled on needing four different "themes", based around light/dark and warm/cool. That's what all this is for:



$background-map: (
    light-cool: #ecf0f1,
    light-warm: #f2eded,
    dark-cool: #10181e,
    dark-warm: #0e070a,
);

@function get-opposite-tone($tone) {
  @if $tone == 'light' {
    @return 'dark';
  }
  @return 'light';
}

@mixin set-background($tone: 'light', $temp: 'cool') {
  $primary: null;
  $secondary: null;

  background-color: map-get($background-map, #{$tone}-#{$temp});
  & > #picker > button {
    background-color: map-get($background-map,
      #{get-opposite-tone($tone)}-#{$temp}
    );
    &.highlight {
      @if $tone == 'light' {
        background-color: lighten(map-get($background-map,
        #{get-opposite-tone($tone)}-#{$temp}
      ), 12);
      } @else {
        background-color: darken(map-get($background-map,
          #{get-opposite-tone($tone)}-#{$temp}
        ), 24);
      }
    }
    color: map-get($background-map, #{$tone}-#{$temp});
  }

  // [ clipped ]
}

At this point, all I needed was 8 lines of JavaScript (... plus jQuery) to hook the buttons up.

Wrap-up fun facts

The buttons on the side use CSS Grid for layout and it was extremely easy and convenient
Did you know there's not one standard "lesbian" pride flag? I picked the lipstick lesbian flag because that was easy to find color definitions for and seemed to be the most popular
SCSS arglists are a thing
You can't put an @media query statement inside an @function (lmao I tried just to see if it would work, but the compiler throws an exception)

Today I learned how to animate a text gradient in CSS (and JavaScript)

Thomas C. Haflich — Fri, 21 Jun 2019 00:36:05 +0000

Cover photo by Clem Onojeghuo via Unsplash.

I'm very sorry. And you're welcome.

Look at that bad boy chug. I think I set my CPU on fire making it... poor thing is really doing its best. I see why the CSS overlords didn't want to let me do this now.

Part one: Getting a text gradient 🌈

You might notice this part of the code:



@mixin lead($one, $two, $three, $four, $five, $six) {
  background: linear-gradient(80deg, $one, $two, $three, $four, $five, $six);
  background-clip: text;
  text-fill-color: transparent;
  -webkit-background-clip: text;
  -webkit-text-fill-color: transparent;
}

That's what's generating the actual "rainbow text" part of this disaster.

The background part is just generating the gradient itself; the good old rainbow barf you might have seen elsewhere before. Removing all the background-clip and text-fill shenanigans in that mixin makes it look like this:

It's all that other stuff that makes the text look like the background.

Normally the background-clip property is used to fine-tune the appearance of background around borders and paddings and the like, but the "text" value is highly magical.

The text-fill-color is roughly equivalent to your standard color attribute. (For this pen you could just as easily substitute color: transparent, I tried and it worked.) In this case we can set it to "transparent" so that our background shows through.

So what's going on here to get the "rainbow text" is:

The background is turned into rainbows
The background is clipped so that the only part of it that shows is the part that would normally be covered by text
The text is made transparent so we can see the background through it

Part two: You can animate a background, but you can't make it linear-gradient

This is where everything started to go off the rails. My first approach was to slap a transition on a single container and call it a day; it would have taken about five minutes, and most of that was googling how to make the gradient clip to the background.

However

Time to try another tactic.



<div id="main" class="container lead-red">
  HAPPY PRIDE MONTH
</div>
<div id="fade" class="container lead-orange">
  HAPPY PRIDE MONTH
</div>

Wait, why are there two-

🤔



function intervalFunction() {
  rainbowify();
  setTimeout(intervalFunction, getNextTimeoutDuration());
};

intervalFunction();

What are you doing on an interval-

🤔 ... 🤔 ... 🤔 ...

Oh no.

Here's the gist:

Have two nearly identical HTML elements overlap each other. The first one, #main, is on the bottom layer and is always visible; it "blinks" between gradients at a constant opacity. The second one, #fade, is on the top layer and is constantly blinking in (when aligned) and fading out (to achieve an appearance of transition using opacity).

These two are not on the same "rainbow cycle" - the #fade text is ahead of the #main by one color. JavaScript runs a loop using setInterval to juggle the classes on these two elements to keep the colors moving.

That also didn't work.

Part three: Blink in, fade out

My code looked something like this: During the main setInterval loop, attempt to halt animation with a .halt class that sets the transition-timing property to 0ms (effectively disabling transitions). I would then set the opacity to 1 to get it to "blink in", and remove the .halt class. The I would set the opacity back to 0 and let the transition do its magic. This all happened immediately, on about four lines of code.

Well, CSS transitions do not work that way. It turns out that in order for it to transition, the rendering engine needs a couple milliseconds to get its act together, regardless of what the transition property was on the element at the time.

Adding and then removing a class almost immediately is not, as it turns out, enough time.

I messed around with transition timing and other CSS for awhile before giving up and trying JavaScript. The initial JS hack of using a setTimeout( ... , 20) inside my existing setInterval loop worked... about 95% of the time. Setting the timeout lower would cause it to stutter as the transitions couldn't keep up, and setting the timeout higher would cause highly noticeable pauses in the animation. However, having weird magic numbers lying around and occasional visits from Blinky McBlinkerton weren't where I wanted to leave it...

Part four: Reducing the juddering

The first part I wanted to eliminate was that magic 20ms timeout. I googled for an eternity and came up with this:

Trigger a reflow in between removing and adding the class name.

That explains this bit:



fade.classList.add("halt");
fade.classList.add("hide");
fade.classList.remove("lead-" + rainbow[(i + 1) % ilen]);
fade.classList.add("lead-" + rainbow[(i + 2) % ilen]);

void fade.offsetWidth; // <- this one!

fade.classList.remove("halt");
fade.classList.remove("hide");

The next weird thing I figured I'd plan ahead for was JS timer drift. I've seen this before when building schedules and clocks; one millisecond as specified is not always one millisecond in reality, so any interval will inevitably drift further and further away from accuracy. Since I have the same timeout hardcoded into my SCSS and my JS, it would definitely look nicer if they could consistently line up. This could prevent further pauses, stutters, etc. due to timer drift.

To do this, I use setTimeout instead of setInterval, and have the timeout call a function that calls another timeout (effectively creating an interval out of timeouts). Each timeout notes when it starts, and notes the "drift" from the last timeout, and corrects itself to attempt to more accurately hit a long-term target. This would definitely be useful if I were to pivot to something like @keyframes.

In conclusion:

This is unnecessarily complicated and runs like molasses in winter. Just make a gif or something.

(ETA: Follow-up here. If for some reason you want to actually do this...)

But I did it, CSS overlords. I've beaten you. I've won.

DEV Community: Thomas C. Haflich

Alignment in CSS: margin & padding

What are margins? What is padding? A quick review of the box model

Percent-based margin & padding

Negative margins

Automatic margins

Alignment in CSS: Absolute positioning

More with absolute positioning and translations

JavaScript WTFs explained - Number type and floating point

Just started learning JavaScript and have a lot of questions that begin with “Why/How tf”

About binary and numeric representation

9999999999999999 evaluates to 10000000000000000

0.5 + 0.1 === 0.6, but 0.1 + 0.2 !== 0.3

typeof NaN is "number"

Math.max() is -Infinity and Math.min() is Infinity

JavaScript WTFs explained - Type coercion

Just started learning JavaScript and have a lot of questions that begin with “Why/How tf”

The plus + operator is overloaded

Type coercion

Empty array + empty array

Empty array + empty object

Empty object + empty array

Type coercion with different operators

When is a true a 1?

When is a true not a 1?

Abusing type coercion for fun and profit

Wait, so... why?

Why is JavaScript loosely typed, and why does it do automatic type conversion?

Why does X convert to Y?

Final notes

What do I even do about this?

Alignment in CSS: text and vertical alignment

This is the beginning of a long journey to learn how to get things to finally, finally align properly on our webpages.

📌 Text align

📌 Vertical align

When using vertical-align on inline or inline-block elements, the alignment is relative to sibling elements in a horizontal line, rather than the parent element.

⚠️ Vertical-align does not align block elements. ⚠️

tl;dr

Bonus vertical align: A tall ghost 👻

What is software to you? Day job, passion, hobby, career, something else?

Here's how floats work in CSS

The basics

Can I float center?

Floats aren't in the normal document flow? So it's like "position: absolute"?

Floats don't want to be large

Predicting where floats will go

Why didn't the last one move upward to fill in that terrible whitespace?

Margins, the box model, and HTML order

Clearing floats

The clear property means: I don't want any floats near me, in this direction!

Floats don't take up space the way you might expect

1. Create an element that is in-flow, but after the floats

2. Use overflow: hidden to create a new block formatting context

3. Use display: flow-root to create a new block formatting context

What else do you want to know about floats?

A few JavaScript puzzlers

Good morning! 🌥️ How's your weekend going?

#1 - Non-reflexive

#2 - Reciprocal

#3 - Prototype

The parable of the turkey: or, The way things have always been done

The story goes:

Doing what has always been done without knowing why is not a good idea.

A width-responsive perfect square in pure CSS

Points of interest

Resizable block-level divs

How the square is made

How the circle is made

Quick geometry recap

How to actually animate a text gradient in CSS

Animating background position

Animating background position with gradients

Adding more flags 🏳️‍🌈 (refactoring)

2 div overplayed on each other

2 div overplayed on each other

2 div overplayed on each other

Wrap-up fun facts

Today I learned how to animate a text gradient in CSS (and JavaScript)

I'm very sorry. And you're welcome.

Part one: Getting a text gradient 🌈

`9999999999999999` evaluates to `10000000000000000`

`0.5 + 0.1 === 0.6`, but `0.1 + 0.2 !== 0.3`

`typeof NaN` is `"number"`

`Math.max()` is `-Infinity` and `Math.min()` is `Infinity`

The plus `+` operator is overloaded

When is a `true` a `1`?

When is a `true` not a `1`?

When using `vertical-align` on inline or inline-block elements, the alignment is relative to sibling elements in a horizontal line, rather than the parent element.

2. Use `overflow: hidden` to create a new block formatting context

3. Use `display: flow-root` to create a new block formatting context