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