Re: [mediaqueries] overflow-block/inline

> On Feb 25, 2016, at 05:53, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
> On 02/07/2016 10:19 PM, Florian Rivoal wrote:
>> 
>>> 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.
> 
> Okay. I think we should prioritize the block overflow aspect, then,
> and give it an easy-to-use name. :)

If you've got a better pair of names to suggest, I'm all ears.

> Making assumptions about inline overflow is of course not perfectly
> accurate--I'm not saying it is--but definitely not as significant
> from an authoring perspective. I would even go so far as to suggest
> that it be deferred until there is some demand for it, but I wouldn't
> object to leaving it in the draft.

I'd rather have it in, at least to make sure we get the pair right,
even if we end up prioritizing implementation differently.

 - Florian

Received on Friday, 26 February 2016 10:54:53 UTC