W3C home > Mailing lists > Public > www-style@w3.org > April 2016

Re: [css-step-sizing] Offline spec review in Tokyo

From: Hiroshi Sakakibara <sakakibara.hiroshi@bpsinc.jp>
Date: Tue, 19 Apr 2016 17:03:22 +0900
To: Koji Ishii <kojiishi@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-Id: <20160419170321.7DD6.147D1882@bpsinc.jp>
Below is the brief minutes. 

If ambiguous, please let me know! 

------------------------------------------------------------
# Meeting dates & place & aim 
- 14 Apr 2016 @ BPS inc. 
- Discussion about step sizing spec, in Tokyo. 

# terms
- snap-height == line-height-step
- snap-width == inline-size-step

# Summary
- The <integer> value for 'line-height-step' property is not
  straightforward (referring to <baseline position>). It might be
  better allowing the user to specify both 'percent' and 'length'.
  - [CONCLUDED] Leave the feature as is, due to convenience of
    implementation. Regarding the representation, we can discuss
    further, e.g. to change the values 1-100 to percent.

- Association between 'line-height-step' and 'line-height'. 
  - When 'line-height-step' is used, it expects 'line-height' to be 1,
    or at least a value smaller than the one used for snap-height. 
    - This is because giving the same value for 'line-height-step' and
      'line-height' may result in reserving a large space that equals
      to two lines, when the line has mixture of characters in
      different ascent/descent.
  - While it needs more usability (currently not), changing the spec
    may produce side effects in the matter of specification and
    implementation.
  - [CONCLUDED] Keep the spec as is. However, the spec should put an
    eye-catching note saying 'Be sure to set line-height to a small
    value when using snap-height', together with examples of what
    happens if you don't. 

- About the term 'inline-size-step' > 'available inline size'. 
  - While it could read as if the box itself shrinks, actually what
    shrinks is the content only.
  - [CONCLUDED] Revise the description in the English spec. 

- 'inline-size-step' interactions to alignment. 
  - As available inline size gets smaller, the text shifts toward
    left. Center-alignment or right-alignment are needed.
  - This won't be a big problem, because under typical usage, the
    range for adjustment is below 1em.
  - [CONCLUDED] Let's leave this issue for Level 2. 

- In koji's experimental implementation in chromium [1], inline-size-step
  doesn't work under multicol.
  - Actually not implemented. 
  - It should not have effect for a table. 
  - [CONCLUDED] When it is applied to 'multicol', it should define a
    special behavior such as it is applied to the column box. It
    should not affect for the gap.

[1] https://codereview.chromium.org/1737453002

# (Roughly) Full Minutes 

## Attendees
- Koji Ishii
- Florian Rivoal 
- Takao Baba
- Shinyu Murakami
- Toru Kawakubo
- Hiroshi Sakakibara 

## The <integer> value for 'line-height-step' property is not straightforward (referring to <baseline position>).

To my (Shinyu's) intuition, what I might understand is giving '1'
would move it upward and giving 100 downward. It is actually wrong.

- (Koji) Since this determines the position of the reference baseline
  for each 'step'. It is correct as is.
- (murakami) Does it correspond to the dominant-baseline? 
- (koji) I'm not certain about how dominant-baseline works for
  this. It should be meaningful to investigate later.  

## Why are the available values 1 to 100? Wouldn't it be more convenient and useful to allow '%' or <length>? If possible, the values need to be taken automatically from the font metrics.

- (Koji) It's given in integer in order to save memory space. Decimals
  like '0.0 to '1.0' and '%' should work too, as it is merely a matter
  of syntax.
- (baba) For clarity, the values and usage should be somewhat alike to
  'baseline shift'.
- (koji)
  - '%' may be acceptable, however 'length' costs memory usage and
    everybody will not be happy.
  - It is difficult to read from font. Currently, everything is
    treated all in a cascade stage of CSS, computed value is
    immediately determined.
  - Specification about fonts will not be determined until later
    phases, therefore we must remain to give up the operating
    speed. (i.e. It's not handled easily)
- (murakami) Then, I will leave font and length for Level 2.  
- [CONCLUDED] Do not add features. The representation '1' to '100'
  needs some discussion.

## line-height-step and line-height

Giving a similar value to 'line-height' at the same time of setting a
value for 'line-height-step' will result in feeding two lines.

- (koji) Is there an overflow in ascent/descent? It seems to be a
  normal behavior because the setting depends on each character,
  therefore a text consisting of mixture of Japanese and English in
  one line will get a result like that.
- (murakami/florian) But it is not good for use. Do you insist that
  it's required for the author to set 'line-height' to '1' or
  something, whenever used 'line-height-step' is set?
- (koji) yes
- (florian) It's inconvenient. Because, people used to rely on '
  line-height' when they wanted to create a content whose lines look
  like aligned with line-height-step, for browsers that don't support it.
- (baba) @support will solve it
- (florian) No, it should allow a progressive enhancement to look like
  natural. What if setting line-height-step will automatically set
  line-height to '1'?
- (koji) May produce a large influence. I'm not for.
- (murakami) 'line-height' has been intended both for the size of a
  line and interval of the lines. So we are splitting them as
  'line-height' for 'size of a line' and 'line-height-step' for 'interval
  between lines'?
- (koji) yes
- (florian) It involves a change in the property usage. Authors may be
  in confusion, because what 'line-height' performed is replaced by
  'line-height-step'.
- (long discussion...)
- [CONCLUDED] Do not change the spec. However, the spec should put an
  eye-catching note saying 'Set line-height to 1 when using
  line-height-step'.

- (Takao thinks, this could be simply a bug in the
  implementation. Asking koji. ) 

## About the term 'inline-size-step' > 'available inline size'. 

> When this property is set to a positive <length> and the available inline
> size is definite, the available inline size is rounded down to the closest
> multiple of the specified <length> before it is used.

- (murakami/baba) The expression "vailable inline size is rounded
  down" is difficult to understand. Basically, the term 'available
  size' is typically used when laying out something. The current
  expression is taken as if the specific box would shrink, however it
  actually means that its content will shrink.
- [CONCLUDED] Revise the description in the English spec. 


## 'inline-size-step' interactions to alignment. 

(Shinyu) As available inline size gets smaller, the text shifts toward
left, I want to do this for the center- and right-justified. 

- (murakami) start, center, end keywords are able to add such support.
- (koji) There are various layout rules, such as normal flow, table,
  multicol, flexbox, etc.  Introducing exceptions can make both the
  specifications and the implementation complex. The current one looks
  good as it seems to be the most simple.
- (florian) What if reacts with text-align?
- (baba, koji) I'm not for. 'text-align' should not give an effect for
  the alignment of a block level element.
- (koji) The gap to be adjusted should be, as long as used naturally,
  only 1em or smaller. You can't tell it's shifted to right or left
  anyway.
- (murakami) This function is wanted. But if it introduces complexity,
  we can leave it for Level 2.
- [CONCLUDED] Let's leave it for an issue for Level 2. 

##  'inline-size-step' interactions to multicol. 

(shinyu) Does not work well with 'multicol' element. 

- (koji) How does it behave? Will multicol box shrink?
- (murakami) It acts the same as if no value is specified. Nobody will
  be happy if multicol box is to to shrink. Instead, we want 'column
  box' to shrink.
- (koji) it certainly is. We need to implement it so.
- (florian) 'column box' doesn't have padding. Can we adjust it with
  'column gap'?
- (takao) It's not what 'gap' originally meant to be. Also, the
  interactions with implementations for '-webkit-column-axis' and so
  on may cause difficulty. It should be better to give a virtual
  padding or something.
- It should not have effect for a table. 
- [CONCLUDED] When it is applied to 'multicol', it should define a
  special behavior such as it is applied to the column box. It should
  not effective for the gap.

## Since 'p' and 'h1' have margins by default, without giving it '0'
   the content will not look like grid. Will it be OK to leave it as a
   limitation?   

- (koji) OK, limitation.
- (baba) Not a disagreement, but I suggest to put a note at an
  introducing part.
- [CONCLUDED] Add the note about this limitation. 
------------------------------------------------------------


- Hiroshi 

On Sun, 17 Apr 2016 18:21:09 +0900
Hiroshi Sakakibara <sakakibara.hiroshi@bpsinc.jp> wrote:

> There was a good discussion in Tokyo!
> 
> Takao created brief minutes in Japanese. Tomorrow, I'll be able to
> send it in English.
> 
> - Hiroshi 
> 
> On Fri, 15 Apr 2016 02:26:19 +0900
> Koji Ishii <kojiishi@gmail.com> wrote:
> 
> > JFYI, Hiroshi hosted an offline spec review session for CSS Step Sizing in
> > Tokyo today. Florian, Murakami-san, Hiroshi, Baba-san, and a couple of more
> > from BPS, Hiroshi's company joined the session.
> > 
> > Most of over 2 hours of the session were spent on Q&A for the better mutual
> > understanding. There were some good feedback too and attendees said they
> > will send the feedback to www-style.
> > 
> > So much thank you to Hiroshi for hosting and to all attendees for pointing
> > out how bad my communication was ;) we solved several misunderstanding and
> > I hope the session helps more active discussions at this ML and the WG.
> > 
> > /koji
> 
> 
> --
> Sakakibara Hiroshi (skk@bpsinc.jp)
> Beyond Perspective Solutions Co., Ltd. 
> Tel: +81-3-6279-4320 Fax: +81-3-6279-4450
> Web: http://www.bpsinc.jp/
> 

--
Sakakibara Hiroshi (skk@bpsinc.jp)
Beyond Perspective Solutions Co., Ltd. 
Tel: +81-3-6279-4320 Fax: +81-3-6279-4450
Web: http://www.bpsinc.jp/
Received on Tuesday, 19 April 2016 08:03:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC