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

On Fri, Oct 2, 2015 at 9:12 PM, Jonathan Kew <jfkthame@gmail.com> wrote:

> Following up on this query from a couple of weeks ago:
>
>
> On 17/9/15 17:17, Jonathan Kew wrote:
>
>> CSS Logical Properties[1] introduces new 'inline-start' and 'inline-end'
>> values, as an alternative to the existing 'left' and 'right' (which are
>> treated as line-left and line-right for vertical modes, AIUI).
>>
>> We're ready to support these in Gecko[2], but in view of "issue 1" in
>> the current ED:
>>
>> # Is this a 2-directional property? Should these just be 'start'/'end'?
>>
>> we'd like to check whether these values can be regarded as stable enough
>> to implement?
>>
>> (FWIW, I think it's preferable to retain the 'inline-' on these values,
>> both for consistency with lots of other logical-direction terminology,
>> and because it seems very plausible that we may want additional values
>> for 'float' in the future, at which point we might deeply regret using
>> bare 'start' and 'end' values here.)
>>
>
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?

A second point I'd like to clarify is that the [inline-]{start,end}
>> values for 'float' are resolved according to the writing-mode and
>> direction of the float's containing block, not those of the float
>> itself. I believe this is what CSS Writing Modes normally expects, and
>> is the more reasonable and useful behavior.
>>
>
I agree on this point.

Any comments, corrections, clarifications, contradictions, ...?
>>
>> JK
>>
>>
>> [1] https://drafts.csswg.org/css-logical-props/#float-clear
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1122918
>>
>
>
> As we have patches here that are ready to land in Gecko, I'd like to ask
> for the WG's (and/or the spec editors') opinions: can we go ahead and
> implement the inline-{start,end} values as currently drafted, which implies
> we're considering Issue 1 in CSS Logical Properties to be closed with no
> change? Or do people want to bikeshed the names here before we ship these
> values?
>

Maybe we should add this to the agenda for the conf call, though, I'm not
sure if we can get a concrete resolution as we haven't discussed on this
for a while.

/koji