W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [mediaqueries] overflow-block/inline

From: Florian Rivoal <florian@rivoal.net>
Date: Mon, 8 Feb 2016 12:19:54 +0900
Cc: "www-style@w3.org" <www-style@w3.org>
Message-Id: <47C2A5B1-484C-4C6B-95F5-FA1863AB9D64@rivoal.net>
To: fantasai <fantasai.lists@inkedblade.net>

> On Feb 6, 2016, at 03:25, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
> While I'm sympathetic to the differences between block and inline overflow,
> and it may indeed be necessary sometimes to query them independently,
> I think it's probably easier for authors if we provide a simple 'overflow'
> query:
> 
> overflow: none | scroll | scroll-page | page
> 
> where the author assumption is that if it's 'page', then there's no
> inline scrolling, although the UA may allow it.
> 
> Also, I suggest the following renamings:
> paged -> page for grammatic consistency with scroll
> optional-paged -> scroll-page because it does both, it's not just paging

I think overflow-inline is secondary to overflow-block, so picking favorites
and calling overflow-block overflow may be reasonable.

But whether we want it now or later, the inline direction also has differences,
and they are not reliably guessed from the block direction. Block scroll does
not necessarily imply inline scroll, nor does block page necessarily imply a
lack of inline scrolling. For instance:

* A unix terminal or a roll printer are scroll in the block direction,
  but not in the inline direction

* an interactive ebook reader can be paged in the block direction, while still
  offering a scrolling metaphor in the inline direction if something overflows.

I don't have a big issue prioritizing one over the other, or working on the naming,
but I don't think we can drop the overflow-inline aspect entirely and still cover
the problem space.

 - Florian
Received on Monday, 8 February 2016 03:20:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC