Line-length is not different than any other user preference

So there's a long discussion, which bridges two posts about using fixed-width layouts. However, I think that the whole discussion starts off on a totally silly logical footing: that somehow line-length is somehow different than any other property.

Line length, while not explicitly a CSS property is influenced by the horizontal width of a container it's in. We can assume that if a content container is 450px (or 40em for that matter), then the content will be no wider than 450px (there are a few cases where this might not be the case, but we don't really need to worry about them for this discussion). Furthermore, the application of padding and margins to the content and to it's container will further restrict the line-length.

That's obvious. What's not so obvious is we've implicitly assumed something about the user. A principled, conscientious web developer knows that restricting a user's font-size is a big no-no. The reason is simple, not everyone has the eye-sight, or the screen reading ability of the twenty-to-thirty-something creating the page (ok, some developer's might be older, but whatever). They too realize that lots of people use lower font-size settings on lower resolution to get more content "above the fold" (here, I mean before they have to vertically scroll). So the developer consciously chooses to use ems and percentages of the user's default font-size.

So what's the have to do with line-length? Simple: everything. A user using larger fonts whose content area is limited by a 450px container will have a far poorer reading experience than someone using the font-size a developer assumed the majority use. In addition, someone with a smaller font-size will have far longer lines than intended (probably more likely).

This problem is only somewhat solved using a relative unit like em for the width of the container. It's probably fixed for the user with a small font. Obviously, the line-length will be how the developer intended it. In fact, it would most certainly fall within one of the calculations for line-length. This does make, of course, the assumption that your layout can handle the fluidness of the content column (sounds almost like a fluid design to me). What's a little more difficult is what would happen at larger font-sizes. While the calculations referenced before For the larger font-sizes, a relative sized content container introduces the potential for horizontal scroll.

Whenever there is a fixed width layout, you're going to scroll on someone's screen: low resolutions, not maximized windows, etc. When you relatively size your container, you might in fact make this worse. For someone with large fonts, you potentially create a problem where the line-length might require scrolling both directions to read.

Here in lies the dilemma: by fixing your width you assume you're fixing the line-length problem. This is, by and large, probably true. What it does, though, is violate of the implicit principle rule discussed earlier: end users are the best decision-makers about their own readability requirements. We make that assumption about font-size, why would line-length be any different?

Of course, that's the perfect world scenario. People really don't know, or at least, do know that they know. Likewise, users don't often change they're browser window sizes to help them read better (perhaps because they're not used to being able to decide). This doesn't change the fact that some users do know (especially those that need to for good reason).

Finally, the line length discussion is important, and often overlooked in favor of design and structural considerations. It is important to realize that even in flexible designs, some absolute maximums and absolute minimums are ascertainable. Presumably, no one is going to want 2em widths or 1000em widths. I also believe that max-width and min-width properties solve even more of the problems (ie. width: 40em; max-width: 750px; min-width: 200px;). The lack of support by "the most popular" browser shouldn't prevent developers from implementing them.