Re: [css-logical-props] Is this spec ready to ship?

On Wed, Dec 14, 2016 at 12:19:20PM -0500, Christian Biesinger wrote:
> https://drafts.csswg.org/css-logical-props/
> 
> There's some discussion on blink-dev on whether we should ship
> {min,max}-{block,inline}-size and perhaps {block,inline}-size. However
> the spec is only an Editor's Draft right now. Does the WG think these
> properties are stable enough to ship?
> 
> Note: Firefox has shipped them already.

Firefox shipping unprefixed something that doesn't even have a WD,
without even posting a message to www-style as Christian has done?

In the Firefox discussion linked to from the blink-dev thread mentioned,
Jonathon Kew wrote:

JK> given that prefixing is now out of fashion,

As far as I know, the current prefixing guidelines for web browsers are at
  
  https://www.w3.org/TR/CSS/#future-proofing

which still requires CSSWG discussion and concensus before releasing
unstable features unprefixed.

In the current case, logical-props is a feature that really needs input
from the experience from authors -- and then changes in response to that
experience.

(I too have implemented the size, padding, border & margin props from the
spec as written, and only realized their usability problems once I looked
at starting to use the properties.)

Prefixing has its warts (maybe we should go with one of those prefixing
proposals that give something like a spec version rather than a vendor
prefix), but this situation definitely benefits from the "this stuff is
experimental" part of prefixing.

JK> and that the WG seems to be happy with the properties in the current ED 

I don't know what the above is based on, but it would seem premature to think
that it's had much review when it hasn't even had a first WD.

JK> the default HTML and UA stylesheets require the use of logical properties
JK> to get reasonable rendering behavior in vertical writing modes for many
JK> elements

Well, that's the thing: most uses in the default HTML stylesheet don't
actually want the side to depend on that element's writing mode, but rather
on the writing mode of the containing block of its boxes.  In some cases,
such as h1..h6, these would essentially always be the same; but e.g. tables
and floats would very often differ.

The only rulesets I can see (without looking too carefully) that might
prefer the margin or border side to be based on self rather than containing
block when they differ is:

   form { margin-block-end: 1em; }

(and even that, I'm not sure of: the use that I was thinking of would be
better achieved with padding rather than margin; so maybe this one should
be containing block too if margin is correct).

It looks as though all other margin or border rulesets in rendering.html
would want the directions of the containing block.

Whereas padding and size properties in rendering.html do want directions
resolved relative to the element's own writing mode rather than containing
block.

The above only directly affects Firefox case rather than Blink's (who are
for the moment only proposing to ship the size properties rather than
margin & border), but it does potentially affect Blink too for the
following reasons:

  - The fact that the logical side in float,clear,caption-side must
    necessarily refer to its containing block rather than self for it to be
    implementable, and that at least margin would prefer containing block
    for it to be useful in mixed-direction documents, would have a cost
    of confusion for authors if "inline-start" is defined in terms of the
    element's own writing mode for some cases and for containing block for
    others.  Possibly we'll simply accept this cost, but if we were to
    address it then it might well affect the size properties.
    
  - Containing block is traditionally a layout concept, which can differ
    between the boxes generated by an element (e.g.  markers with
    list-style-position:inside), and which is not involved in cascading.
    If we were to retain the cascading idea in css-logical-props
    (where the final result of the declarations margin-left:1em and
    margin-inline-start:2em depends on their order, assuming ltr-tb
    writing mode) then that constrains how CSS properties can choose
    containing block.  For example, it would affect mechanisms that play
    with the box tree, such as display:run-in, which wanted the run-in to
    be conditional on certain descendants not being block-level (which
    would be costly to evaluate during cascade time, because we want
    descendant property values to be calculated from their parents); and
    it would affect mechanisms such as the gcpm proposal where whether
    a box floats would depend on column breaking decisions and hence
    column balancing.

    So we might want to drop the cascading idea, and make
    margin-inside-start behave more like margin-inside & margin-outside in
    some print UAs (which choose the side independently for each box
    fragment generated by the element based on whether that box fragment is
    on a :left or :right page).  margin-inside & margin-outside don't alias
    margin-left & -right, they're separate properties that get used instead
    of margin-left/right except in the usual case that the margin-inside
    or -outside property has its default value of 'auto'.

We might or might not change drop the cascade-time resolution idea for
margins, and we might or might not drop it for size properties even if
we did drop it for margin properties, but the point is that there's still
a lot of work to do to make mixed writing modes work well in CSS, which
could well affect the mechanism used for sizing in mixed-direction
documents.

Or, given that one major web browser has already shipped unprefixed, maybe
we'll just stick with what we have for the properties already shipped,
and authors will lose.

[I'm assuming that Firefox hasn't implemented the float,clear,caption-side
 parts of css-logical-props, which need some sort of change to be
 implementable.]

pjrm.

Received on Thursday, 15 December 2016 22:01:24 UTC