Re: [css-logical-properties] the 'inline-{start,end}' values for 'float' and 'clear' [css-page-floats]

> On Nov 4, 2015, at 8:13 AM, Jonathan Kew <jfkthame@gmail.com> wrote:
> 
>> On 6/10/15 21:14, fantasai wrote:
>>> On 10/05/2015 10:21 AM, Jonathan Kew wrote:
>>>> On 5/10/15 14:25, Koji Ishii wrote:
>>>> 
>>>> I'm personally in mild preference to use 'start' and 'end' for inline
>>>> regardless of 1 or 2 dimensional. That's another way not to regret,
>>>> isn't that?
>>> 
>>> For 2-dimensional properties, however, it may be unclear to authors
>>> whether 'start' and 'end' refer to the inline or block direction.
>>> 
>>> In the case of 'text-align', which already accepts 'start' and 'end'
>>> values, it's pretty clear that only the inline direction is relevant.
>>> But I think it's much less obvious that 'float: start' would necessarily
>>> refer to inline-start. We don't currently have block-direction options
>>> for 'float', but in principle they seem like a reasonable possibility.
>>> 
>>> If we use 'start' and 'end' now, and later extend 'float' to two
>>> dimensions, I could see us ending up with 'float: start | end  |
>>> block-start | block-end', which seems unfortunate. ISTM that using
>>> the inline-prefixed names from the beginning is preferable. Or would
>>> you suggest some entirely different names for the block-direction
>>> analogs of inline 'start' and 'end'?
>> 
>> I think this makes sense. I'll note though, that for <position>, I
>> ended up concluding that unprefixed keywords and requiring a particular
>> order was much cleaner: easier to read and author.
>>   https://drafts.csswg.org/css-backgrounds-4/#the-background-position
> 
> Returning to this thread.... where are we now with regard to the logical values for 'float' and 'clear'?
> 
> We're ready to land an implementation of these logical values in Gecko -- indeed, we have been for some time now -- but face the question of whether to proceed with 'inline-start' and 'inline-end', as per the current draft text at [1], or to use plain 'start' and 'end' as suggested by Issue 1 there.
> 
> Opinions have been expressed on both sides, but it's still unclear to me what the CSSWG's conclusions are.
> 
> Help?
> 
> Thanks,
> 
> JK
> 
> [1] https://drafts.csswg.org/css-logical-props/#float-clear

I am ambivalent. I like the simpler, shorter values, but agree it would be odd if later we got 'float:block-start'. 

But here is another possibility: float axis could be determined by property name, instead of value. Thus, 'float' would be longhand for 'float-x' ('float-inline' in horizontal writing), and eventually we could have 'float-v' ('float-block' in horizontal writing). That would allow us to keep start and end as values for all. 

This would be in line with logical equivalents of overflow-x and overflow-y, and could extend to background-position-x and background-position-y. 

The full longhand for float would take two values, either logical or physical. So 'float: left' would really be the same as 'float: left none', 'float: top' would be the same as 'float: none top', 'float: start' would be the same as 'float: start none', and (maybe?) 'float: start top' would be the same as 'float-inline: start; float-y: top' (possibly causing float-y to override float-inline' in vertical writing?). 

Snapping, as in the page floats draft [1], could be with a 'float-snap' property added to the longhand. So, for example:

float-inline: start;
float-block: start;
float-snap-inline: 2em;

...could also be written as this:

float: start start;
float-snap: 2em 0;

...or:

float: start 2em start 0;

...or just:

float: start 2em start;


1) https://drafts.csswg.org/css-page-floats

Received on Wednesday, 4 November 2015 17:44:56 UTC