ctidd

On the topic of rems, when using them for layout, you'd use a body font size rather than the root element's font size to control the size of text in your page.

At that point the root font size exists only as a scaling factor, decoupled from the base font size of content within the page, but allowing the user to control that scaling factor via their browser's global default font size preference. In fact, you could think of the rem as root scaling factor unit rather than root font size unit. (The use of the font size property to set the scaling factor is a quirk of the spec.)

This solves the concern you noted on maintainability, while allowing a user to globally opt into larger or smaller text and correspondingly scaled layout across the web, arguably a win for enabling an element of accessibility by default on any website.

Cars are designed for humans, then infrastructure is designed for cars.

That step of removal from being designed for humans conflicts with any idea that designing for cars is design for humans by proxy: disproportionately catering to automotive concerns has negative affects on humans relying on their infrastructure to facilitate other forms of transport, or otherwise to not excessively distort either the urban or natural environment they are members of.

I'd recommend spending some dedicated time learning about layout, not leaning on a framework.

CSS layout is largely about the relationship between elements. Instead of looking at it as "I want this element on the right," try to see the relationships between elements. What's the group of elements, and what causes them to be where they are? (Generally, complex layouts are nothing more than nested groups of elements.)

Once you recognize the patterns, CSS layout becomes straightforward. Not easy, but straightforward. It becomes a matter of defining and expressing the relationship between elements, and the constraints that define their layout. Flexbox is really the thing to focus on here. Don't worry about the words if you mix them up -- justify vs align, etc. Just the idea of a spacial relationship between things with rules that define the constraints.

Often times, the relationship winds up being expressed as "I want this group to consist of items with space between them on the current row they wind up on opposite sides of viewport, and when they wrap, I want everything aligned to the left."

Also, really understanding CSS is not about tricks, but if there's one thing that can help you gain an appreciation, it's learning how to write layouts that can handle arbitrary number of elements without any templating logic to add special case classes, e.g. for the first and last column in a grid. To this end, using equal but opposite positive and negative margins (negative on a container, positive on its children) can provide space between elements and allow for arbitrary numbers of elements within a layout where you don't care which is first or last in a given row. Let the elements flow into the layout.

I think there's a pretty definitive set of exercises any developer could work through to learn about the different types of constraints we need to express, and from there, it's generally a matter of recognizing the pattern in a higher-fidelity format.

Your complaint is that you hear about too many opportunities in the "career-limiting" area of .NET development? No .NET developers are looking for work? Sounds like anyone wanting to be employed should get familiar with .NET.

Or do you just disagree with the job title having a language in it?

In my browser it renders as perfect grays, confirmed by the inspector.

It appears to be an attempt to make it easier to find the beginning of the next line after you finish reading a line. However, the effect is much too subtle to be of use, and even if made more prominent, it would still ruin the typographic color and generally confuse readers.

Better solutions include:

Using a more optimal column width. 50-60 characters per line is a commonly suggested range for most media.

Using a more optimal leading (line-height). "Set solid" type (ex. 12px/12px) is almost always a bad idea, particularly so in a long block of text. Depending on the type, media, etc, ratios in the range of 1.2-1.8 are a good starting point for improving readability.

Wow. As an typography enthusiast who's miserable with bezier curves, I've never seen something this straightforward. I love the coordinates it gives you on handles and points. Being able to easily work from metrics forward is a great touch as well.

I gave up on trying to learn with Fontlab's TypeTool because nothing was nearly as clear or usable as this.

This is the perfect entrance to type design, and I see myself wasting a lot of my time with this in the coming weeks.

I would strongly recommend reviewing your 101 WRT what you're calling tags and clarifying that tags represent elements that are interpreted and rendered by the browser. (The browser does not render tags.)

Also, the distinction of semantics and styling should be cleared up a little. Less emphasis on how elements are styled by default, and more on what they represent.

I like the approach of assuming no knowledge, but this requires extra care to introduce concepts without using improper or misleading terminology. As a beginner, there's not much worse than hearing simplifications and thinking they're the whole story.

Good luck with continuing your series!

Regarding your thought, there's an aspect of design known as typography that directly deals with easing and encouraging reading. So I'm inclined to say no -- this is not a common designer anti-pattern -- and to say it is implies the ideal of the design profession lies with the least capable of its practitioners.

That's insincere.

May we please demonstrate respect and professionalism when discussing designers?

Making unsupported assertions about a perceived defect in an entire profession doesn't seem right to me, but I was very tempted to just write, "'Look at those dumb designers' seems to be a common developer anti-pattern." I don't think that sort of comment is necessary.

Thank you for understanding.

Legibility and readability are technical terms in the field of typography.

From what I've seen, the new iOS typography is adequately legible, but somewhat lacking in readability. To proclaim similar descriptions -- which might or might not be exaggerated -- fascicle is very condescending toward typographers and other design professionals.

When people go further in their negative characterizations, the terms stop being used so technically. To call type completely unreadable or illegible is generally an intentional overstatement, and it's understood as such by members of the design community.

It's like calling code shit. Is it literally shit? No -- but saying it is doesn't make a developer incompetent or even wrong. It's a clearly contextual statement, and it's rightly interpreted as such. Please give typographers some credit and don't assume we're somehow overreacting.

Of course -- H&FJ is an excellent foundry, and they're not competing in the same space as, say, Google Web fonts. That's what I mean by not competitive. It's a completely different league, as it sounds like you're well aware.

The people who like H&FJ for the quality will subscribe and use this service, while those looking for a commodity option will avoid it -- perhaps even to the benefit of H&FJ.

I know I'll subscribe shortly, which is why I hope this works for their business. It really is an interesting decision when compared to the providers whose offerings keep dropping in price to compete in a commodity market.

It doesn't seem to provide much in the way of competing directly with Typekit. Still, this is big news for a lot of people.

H&FJ is practically THE type foundry for original typefaces. They compete on quality rather than price or other tangible benefits. Unfortunately, it's been impossible to license H&FJ type for real web use until now.

The most likely group of people who will use this are type enthusiasts who prefer H&FJ type to the competition's. I can predict there are a lot of designers who will use this service for their personal or business sites.

As a competitive offering, though, this doesn't cut it. Buying individual fonts feels outdated to web font users, and the prices don't match up to Typekit (free with Adobe CC) or Monotype/Linotype ($10/month without a ridiculous 5 font cap).

H&FJ has chosen their business model, and they'd like to avoid the brand dilution of having poorly designed sites overusing their type. It's an interesting choice, and I hope it works out for them.

From the article:

Sang has no illusions that even a clever cryptographic font—which you can use in email messages to shield them from snoops and font-recognition bots—will remain encoded for long. They're not meant to be long-term tools with which to combat the NSA. Rather, he views them as an awareness-raising measure.

"This project will not fully solve the problems we are facing now," he writes, " but hopefully will raise some peculiar questions."

You can use "why" to question the context in which the amendment was created, and I even agree with you about that context, but "why" is a broader term, which can be thought, in these circumstances, to include also the intent of the amendment -- why was the amendment created if not to prohibit precisely that which it prohibits? In short, this is a miscommunication based on a word's definition.

That's exactly the point aspensmonster was making by misquoting the amendment to make light of the rayiner's comment.

Not bad kerning either, necessarily. (It's automatically kerned by the type engine regardless of the letter-spacing property.) Just loose tracking. It's fairly common for typographers to track bold text slightly looser than book text so as to lighten its typographic color.

Why does the author assume the reader's gender with terms like "gentlemen" and "brother"?

Firefox / Windows 8.

It only appears to impact the blog post. If I go to your home page, middle clicking works as expected.

Also, I'm getting a character encoding glitch that's rendering gibberish next to your login button.

One last thing: it also looks like Tumblr is adding stuff to the top of your HTML. On the blog, I see two doctype declarations; one's on the first line, and one's at the very end of the second line.

That's a completely false generalization. Brighter than #666 will lean into the danger zone for some readers, but #444 is safe for most type, although very slightly light in perception. In any case, the ideal type color is dependent on the weight of your text.