- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 4 Nov 2015 09:44:01 -0800
- To: Jonathan Kew <jfkthame@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, Koji Ishii <kojiishi@gmail.com>, "www-style@w3.org" <www-style@w3.org>, ratan@microsoft.com, "Elika J. Etemad" <fantasai@inkedblade.net>, Johannes Wilm <johanneswilm@vivliostyle.com>
> 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