Allow pages to grow arbitrarily horizontally

Oblomov · 2015-05-15

There is an essential disparity in current implementations between the horizontal and vertical directions. While the overall document height is automatically extended to accommodate content, the overall document width in automatic computations is implicitly clamped to the initial containing block (i.e. viewport) width. Consider for example this simple document:

<!DOCTYPE html>
<html>
<head>
<title>Horizontal width limit</title>
<style>
html {
width: auto; max-width: none;
border: 1px solid black;
}
body {
width: auto; max-width: none;
border: 1px solid red;
}
div {
width: auto; max-width: none;
display: inline-block;
border: 1px solid blue;
height: 12ex;
max-height: 12ex;
column-width: 60em;
-o-column-width: 60em;
-moz-column-width: 60em;
-webkit-column-width: 60em;
}
</style>
</head>
<body>
<div>
</div>
</body>
</html>

where the actual div content is omitted, and where the width and max-width specifications have been made explicit even though they are the initial values.

The expected result in this example would be to have the div (and consequently the body) expand horizontally to accommodate the content, with columns added as needed. Combined with some max-height binding, this would allow to have a infinite horizontally scrolling canvas not unlike the “standard” vertically scrolling one. However, on all present user agents the above document renders as if the html and body width were clamped by the viewport width. The div columns end up overflowing the limited size, which is shown by the border location. In fact, the unbound horizontal document cannot be achieved currently.

I would like to propose this limitation to be removed, and to treat both the horizontal and vertical directions in essentially the same way. For compatibility with existing documents, this cannot be done arbitrarily, but a possible solution that is backwards compatibility is to specify that documents have a initial value of max-width: 100% on the document root, and to allow it to be overridden with a max-width: none to allow automatic horizontal expansion. The implicit initial max-width:100% specification would be on the :root pseudo-element, which has higher specificity than the html and isn’t a fully published standard yet.

tabatkins · 2015-05-15

There’s an important reason why width and height are asymmetric right now: people don’t like to scroll in two directions at once. More specifically, people don’t like having to scroll back and forth to read continuous content. (This is why the current implementation of MultiCol on the web is broken; long multicol documents require you to scroll up and down repeatedly as you finish each column.)

If you did change this, you have to change a bunch more of CSS, too. A lot of things depend on the fact that the available space in the inline axis (the width axis) is always finite. When this assumption is violated, they break. Currently, this only happens if you use the writing-mode property to mix horizontal and vertical writing modes, and we have explicit patches in the layout algorithms to handle this, by limiting the inline size to the viewport size (so text will wrap at a half-reasonable width) and forcing multicol (so long documents won’t cause the page to scroll horizontally).

There are several ways to get around this, but ultimately the web’s layout algorithms are going to be biased towards infinite-height/finite-width, because that’s better for laying out text.

Oblomov · 2015-05-16

That’s some very useful insight, thanks. I agree that having to scroll in two directions is extremely unpleasant: heck, even pages that use a fixed horizontal width can be affected by this, if they force huge widths.

However, in this way it becomes impossible (I think) to design a page that develops arbitrarily in width, at a fixed (viewport-limited) height. You mention:

There are several ways to get around this

but everything I’ve tried requires manual tuning of the width, since simply relying on the possibility for overflow completely messes up the block decorations. I’ve also tried the experimental support in Firefox for writing-mode by setting to to vertical-lr for html and body, but the div still gets blocked at the viewport. I’m guessing this is the “explicit patches in the layout algorithms” that you mention, but I still think this involves too much second-guessing and ultimately prevents things that should be possible otherwise. Could you mention one way to achieve a fixed-height, horizontally developing, column-based layout?

ultimately the web’s layout algorithms are going to be biased towards infinite-height/finite-width, because that’s better for laying out text.

Well, that’s only true for western text, and even then it’s only true in the sense that we don’t want lines of arbitrary length, which is solved with columns.