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

On Mon, Oct 5, 2015 at 11:21 PM, Jonathan Kew <jfkthame@gmail.com> wrote:

> On 5/10/15 14:25, Koji Ishii wrote:
>
>> On Fri, Oct 2, 2015 at 9:12 PM, Jonathan Kew <jfkthame@gmail.com
>> <mailto: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?
>>
>
> For 2-dimensional properties, however, it may be unclear to authors
> whether 'start' and 'end' refer to the inline or block direction.
>

I actually agree here.

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.
>

I think, however, 'text-align: start' and 'float: inline-start' is a bit
confusing, so to me, whichever has pros and cons.

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'?
>

To me, it's not much confusing; I'd just think that the default is 'inline'.

I'm a bit concerned that when a property changes 1-dimensional to 2, or
vice versa, we'll see a confusion. This might happen overtime, including
the cases like "1 dimensional is fine for level 1 but may extend to
2-dimensional in future if use cases arose," or "we designed 2-dimensional
marked at risk but 1-dimensional is important."

This concern adds my point to 'start' and 'end'.

But if the WG in general prefers the plain 'start' and 'end', obviously we
> can do it that way.


I'm not strong, agree to follow WG consensus.


>
>         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.
>>
>
> It would be really helpful to have some clarity here; we have people
> asking for these values in order to make layouts more bidi-ready, and the
> only thing holding up implementation is the question of whether the names
> are stable.
>

Sent an "Agenda+" to the WG.

/koji