Compatibility: non-standard -webkit- properties

[JayPanoz]

I’m taking the liberty to cc @frivoal since we’re in contact for the project I’m currently leading.

To sum things up, we have quite some issue in EPUB-land: forcing the column axis for pagination when the writing-mode is vertical. It would indeed be kind of weird if “pages” (achieved through the use of CSS3 multicol) were laid out on top of each other (spread view).

In other words, the following is not really the result we’re trying to get.

That is probably what is expected by authors when using columns in their stylesheet but I’m really not so sure about that by the way. After reading a lot of articles on vertical writing, it seems some authors might resolve to horizontal writing because pseudo-pagination with vertical scroll feels super unnatural, apparently. See for example “7. Stick with horizontal” in this article.

The result we’d like to get is this one:

Unfortunately, there’s no way to force the column axis. Or so I thought…

It turns out there’s a proprietary way to do it. So for the sake of compatibility – and I hope level 2 –, I’ll try to document two webkit-specific properties:

• -webkit-column-axis;
• -webkit-column-progression.

A little bit of history

Those properties first appeared in Safari 7.0, it seems to facilitate the creation of a setPagination API – Apple having interests in the ebook market, it’s not so surprising they wanted to extend columns a little bit to deal with this problem.

I took a quick look at all the CSS3 multicol drafts and didn’t find anything related to axis and progression, which is why “extend columns a little bit” in the previous paragraph. I may be wrong about that so please feel free to correct me if that is the case.

Three years ago, Chromium removed them because they had no use for it. It is however unclear if they tried to collect feedback from authors. Also, the following:

and it's assumed that these properties serve no purpose on their own. (source)

is debatable. More on that later.

What’s their purpose?

Those properties were created to:

1. Allow column progression to be independent of writing mode (axis);
2. Allow column progression direction to be set independently of writing direction (progression).

When using columns with vertical writing, you’ll get something like this.

To clarify, overflow on the y-axis as columns are laid out on top of one another.

But when using -webkit-column-axis, this will have some significant effect in Safari.

You now have overflow on the x-axis as columns are laid out next to one another.

Then -webkit-column-progression can be reversed so that, for instance, bottom to top vertical text can be managed “naturally”: first column at the bottom, last column at the top.

How those properties work

-webkit-column-axis

Values can be auto, vertical, or horizontal.

-webkit-column-progression

Values can be normal, or reversed.

Impact on standard properties

It looks like impact on column-width and column-count is pretty huge. It looks like the column-width will simply use the value of the computed width or height of the container, depending on the axis – for instance, if you want two vertical columns in this demo, you must change :root’s height. As for column-count, it is entirely ignored – as a matter of fact, you can even get rid of your columns declaration and it will work as expected.

Consequently, if you want two visible columns with -webkit-column-axis: horizontal, you need to constraint the width of the container in vertical-rl, and columns will then overflow.

Then if you also set -webkit-column-progression: reverse, then columns will overflow in the opposite direction of the writing-mode. So, for vertical-rl for instance, they will overflow left to right instead of right to left.

Hope this can help as we (ebooks) have a use case for this. I really can’t tell if web authors would like to have those properties standardized but do feel like it could be worth checking with them, especially after researching Japanese typography a little bit.

After all, having such properties for columns would be consistent with flex-direction for instance.

[Edit] Added link to horizontal mode with vertical-axis demo as impact on other properties is quite significant. It’s like switching from columns to pages, where the element’s width or height is overriding the columns property.

[JayPanoz]

And to be complete, here is the setPagination API mapping. It’s just an educated guess though.

pageLength

Given I don’t really know the impact of paginationMode on other properties, my best guess is that it will set width (horizontal) or height (vertical) for :root. The column-width value would then be the same size as the container’s in any case. At least it would make sense they’re managing it this way.

gapBetweenPages

This obviously is column-gap.

paginationMode

Values can be UIWebPaginationModeUnpaginated (a.k.a. scroll), UIWebPaginationModeLeftToRight, UIWebPaginationModeRightToLeft, UIWebPaginationModeTopToBottom, or UIWebPaginationModeBottomToTop.

To the best of my knowledge, you can only set one value.

This is probably making use of -webkit-column-axis and -webkit-column-progression, depending on the writing-mode set for the document. Thus values would be set dynamically when the paginationMode set is not the default for the writing-mode.

paginationBreakingMode

Values can be UIWebPaginationBreakingModePage or UIWebPaginationBreakingModeColumn.

Probably switch from page-break-* properties to -webkit-column-break-* properties for fragmentation.

pageCount

Returns the number of pages/columns generated. As far as I can tell, there’s nothing in the spec for that.

[JayPanoz]

TL;DR: you can think of -webkit-column-axis as a proto version of overflow: -webkit-paged-*.

Unfortunately, paged overflow implementations are so buggy and half-backed (it won’t work in iframes on iOS for instance) that they have been unusable in production since their availability.

The Financial Times wanted to explore it at some point but I guess that, if they took a look, they probably witnessed how unreliable it were.

The worst part for ebooks though, is that it looks like Chromium is thinking about deprecating and removing -webkit-paged-*.

So we’re clearly outscoping the CSS multicol spec there, although it is worth noting that paginated overflow is columns in disguise. I don’t know whether you might want to take that into account as editors of this spec but, in practice, browser vendors clearly outgrew its original use-cases.

[rachelandrew]

Thanks so much for documenting all of this. I'd love to look at what web authors using vertical writing modes would make of it. I'll see if I can poke some people who I know have interest (and more knowledge than I have) in that regard. It's a L2 thing at this stage, or is it really a fragmentation thing? But you've given a good use case. Thanks again!

[dauwhe]

Found an example of multicol in vertical writing mode in JLREQ, where there's an upper column and a lower column.

[frivoal]

There was once upon a time a discussion about whether we should add a property along the lines suggested here, to be able to decide whether overflow columns go in the inline axis (as they do now), or create a second multicol container below and keep going there. The general consensus at the time was that:

• This ability would be very useful
• This didn't seem to be multicol specific, and we needed a generic way to have control over where overflow stuff goes.

The intent is/was that fragmentation on overflow, as drafted in overflow level 4 would be how we'd get this ability.

As far as I know, we haven't given up on that plan, but nobody has put significant energy into it for a while, so not much has happened.

Solving this would be fantastic, as it would solve the problem raised here, and many more. Now that we've gotten grid out, maybe it's the right time to look into this. Nonetheless, this is significantly more complex than what a multicol-specific would be, so we may need to weight the pros and cons again. Also, maybe there's an hybrid design that lets us solve if for multicol relatively simply, in a way that can be explained by the more generic mechanism once we have it.

[frivoal]

The rest of the things documented here (paginationMode / paginationBreakingMode / pageCount) feel quite a bit more hacky. Ultimately, columns are not pages. Both are fragmentainers, so they share many caracteristics (and underlying implementation), and when trying to simulate a paginated experience in a UA that doesn't support it, columns get you pretty far.

I do not think we should be adding things that let you pretend columns are pages. Adding features to the specification to work around the fact that implementations haven't implemented other parts of the specification yet is rarely a good way forward.

On the other hand, there may well be things that are currently specific to pages, and that could be generalized to any kind of fragmentainer (page counters, for instance). That's worth looking into.

[JayPanoz]

Oh yeah, it’s very hacky. The way -webkit-column-axis locks columns (1 col full-width) is surprising, to say the least. It really broke my expectations of how it should work. If I hadn’t taken a look at this paginationMode (UIWebView in UI Kit), I wouldn’t have seen you had to switch to width and height to size the columns. To be honest, it makes me kinda uncomfortable as it breaks my conceptual model of columns.

Anyways, I agree this is not multicol specific, especially as this implementation is a little bit too weird to my taste. Actually, it’s so weird that it may show that it doesn’t belong to the multicol spec.

My educated guess is that they needed something real quick to paginate contents at the time. Safari 7 was released on October 22, 2013, so that’s MacOS 9 Mavericks, which coincides with the release of iBooks MacOS. Then maybe they would switch to overflow: paged-* – but it probably didn’t happen.

Having researched fragmentation a little bit, I must admit that it blows my mind to discover how it is related to multicol in some significant ways. See this thread about CSS regions for instance, which becomes a discussion about multicol pretty quickly. It might also explain why nobody has put significant energy into overflow/fragmentation for a while.

[JayPanoz]

@dauwhe hum interesting, thanks.

When using a 10–12" tablet in portrait for instance, it would be reasonable to think users might want to switch to a spread (2-col view) since the line-length must be constrained anyway and they will end up with a lot of whitespace in a single-page view. I’ve seen files in which authors constrained the height of html so it would make sense to do so.

What would feel unnatural though, is scrolling/progressing on the y-axis.

[JayPanoz]

For the record, after further overflow: -webkit-paged-x experiments, my educated guess is that it actually allowed the property to work as expected with vertical-rl documents in Chrome.

Since this outscopes the multicol discussion, I think it will be better to give Florian further details about overflow: paged-* during our F2F on Monday in order to avoir creating noise on this issue.