- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 7 Jun 2016 21:25:06 +0300
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Step-Sizing
-----------
- The group reviewed Koji's proposed spec for snap-sizing
(available here: https://drafts.csswg.org/css-step-sizing/)
and still had a few too many concerns for FPWD. The concerns
included:
- The potential for fonts rendering differently depending on OS.
- Interaction with line-grid being confusing for authors.
- That the proposal breaks the CSS design rule of being robust.
- The spec didn't have enough use cases for the group to
determine if this proposal would solve the problem-space.
CSSOM View
----------
- Brief discussion of changes for handling of empty rects in
getBoundingClientRects()
https://github.com/w3c/csswg-drafts/commit/0e7a5cbdea19397086e9423b508fe6f41decdcec
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/san-francisco-2016#proposed-agenda-topics
Present:
Rossen Atanassov, Microsoft
Tab Atkins, Google
Takao Baba, Beyond Perspective Solutions
L. David Baron, Mozilla
Tantek Çelik, Mozilla
Dave Cramer, Hachette Livre
Elika Etemad, Invited Expert
Daniel Glazman, Disruptive Innovations (only IRC)
Daniel Holbert, Mozilla
Jihye Hong, LG Electronics (only IRC)
Joone Hur, Intel Corporation
Koji Ishii, Google
Brad Kemper, Invited Expert
Ian Kilpatrick, Google
Chris Lilley, W3C
Peter Linss, HPI
Myles Maxfield, Apple
Edward O'Connor, Apple
Simon Pieters, Opera
Florian Rivoal, Vivliostyle Inc.
Andrey Rybka, Bloomberg
Hiroshi Sakakibara, Beyond Perspective Solutions
Simon Sapin, Mozilla (only phone)
Jen Simmons, Mozilla
Geoffrey Sneddon, Invited Expert
Alan Stearns, Adobe
Shane Stephens, Google
Lea Verou, Invited Expert
Greg Whitworth, Microsoft
Regrets:
Dael Jackson, Invited Expert
Hyojin Song, LG Electronics
Scribe: iank
Step-Sizing
-----------
koji: I'm going to demo some experimental builds.
koji: This is a normal multicol with headings and images inline.
koji: Lines don't line up.
koji: When you turn on snap-height, images and headings snap to
the body text height, all lines line up.
koji: Latin text wants to align baseline to the text of the heading.
koji: Not sure what people want for images.
koji: inline-block baseline is the last line.
astearns: For a multiline heading you'll only have last line snap
to the baselines.
koji: For images bottom of the image is the baseline.
<jensimmons> link to this demo? link to a draft spec?
<dauwhe> https://drafts.csswg.org/css-step-sizing/
astearns: Can you remind me of the baseline syntax?
koji: line-height-step has two values, 20pt is size of step, 70 is
within the step where you want to set the baseline to.
koji: The browser will move the baseline around so it is 70 of the
step.
fantasai: Would be nice if that could be derived from the font.
astearns: You are just setting a number.
fantasai: It looks better if you pick a baseline from the font.
astearns: It is responsive to the fonts, instead of the browser
picking the baseline from the font, you are setting the
baseline.
koji: The problem with picking from fonts is need to pick from
primary font. When fallback occurs, fallback may have a tall
ascent, and will jump to next line.
astearns: This gives you first baseline offset, for your block you
can say where the baseline is starting.
<tantek> +1 astearns
Florian: This requires numbers to be set very precisely to avoid
accidentally ending up with lines skipping. Or you have
to set the line-height to be substantially smaller than
the actual line rhythm to avoid that problem.
fantasai: That seems counter-intuitive, you would expect the
line-height and step-sizing to be the same.
koji: Setting the line-height and step-sizing to be the same size
is fragile. CJK fonts this would make every line double.
Florian: Because of the baseline, there are a whole bunch of
reasons for this to be different as things will go wrong.
<liam> [ does this override entirely any line spacing coming from
the font metrics? ]
<astearns> liam - it responds to line spacing, but quantizes the
spacing to a multiple of the step
<liam> thanks. (sorry, should have done q+ but am not on the 'phone)
<liam> [ sounds like what is used is max(step size, font height)
and you can't set text solid; maybe when combined with the
separate line-height property fantasai and dauwhe proposed
in email it would work ]
dbaron: During transitional phase, people will have to use a hack
(setting line-height smaller than what they want) bad for
UAs not supporting feature initially.
dbaron: Concerns about rendering on different OSes, for example
New Yorker currently relying on font-metrics assumption.
astearns: There is not a huge difference between line-height and
snap-sizing, just enough to get enough effect you want.
dbaron: You have to guess right, that might have bad results in
either direction if you guess wrong.
<dbaron> (and you might even get bad results in both ways with the
same number)
<fantasai> http://fantasai.inkedblade.net/weblog/2012/css-layout-evolution/#principles
<fantasai> I think we're violating Robust and Understandable, here
ChrisL: Had to reread the text, 70 is actually a percentage, why
is it not a <percentage>?
koji: Same feedback from Tokyo, I'm open to this.
ChrisL: "by adding the space over" - what is a space over?
koji: Ascent side.
fantasai: "over" means ascent side of the line.
koji: Talking to devs about this feature, they don't want to think
about fallback. Very expensive for web-devs to develop
without this feature.
koji: As long as it requires fallback, cost won't go down.
fantasai: We're not suggesting that the fallback should be
baseline-aligned nicely.
fantasai: Only that it shouldn't be worse than what you would
naively do today.
fantasai: E.g. if I had a double-spaced essay, I would use
line-height: 2.
fantasai: With the new feature, I should be able to add some code
and make it baseline-aligned.
fantasai: But here I have to also set line-height to something
smaller.
fantasai: So that my intention in the old browser is not
preserved: the line-spacing is less than double-spaced.
koji: The catch is that neither line-grid or step-sizing doesn't
work, by just turning on, get bad results, creates lots of
undesired spaces.
koji: When you are talking about fallback, if you want everything
to look good, need to switch everything (margins etc) with
@supports.
astearns: I agree if you want to do the best you possible you can,
with all UAs, it is more costly.
astearns: I think that there are acceptable fallback strategies,
which will look ok.
astearns: Looking okay in older browsers, and looking
exactly how you want in new browsers, is acceptable.
Florian: It's not just a fallback between supports / not, but also
browsers with different font-metrics.
koji: I can't think of a real scenario where a font will exceed
the step.
koji: They don't use step as 1.1 (small value), people will do
1.5,1.8 (large value).
tantek: From a design perspective, how much extra space
above/below a font, is enough to make any finely tuned
design to look good/bad on different OSes. I can't think
of any way to make this look good, unless by undoing what
the OS does.
tantek: Should ask designers how they are dealing with this cross
OSes, serving different stylesheets?
koji: You usually don't that that small line-size.
dbaron: If you have script off for New Yorker, underline is above
the baseline.
<tantek> New Yorker-- for depending on script to have decent
styling
myles: I don't want to have two properties that fight to get the
correct result.
myles: How would this interact with line-grid?
koji: line-grid and step-sizing handle two slightly different
purposes.
koji: line-grid can snap to absolute positions.
astearns: They solve a similar set of problems about lining things
up, with step-sizing you need to control everything
about the layout to get two different elements to line
up, for line-grid everything just aligns.
astearns: line-grid for global, step-sizing for within a
particular element.
myles: I'm worried about properties jumping down by a different
amounts.
astearns: I see it as a tool for getting lines to fit will within
a line-grid.
TabAtkins: I thought this was a simple version of line-grid that
we could go with.
myles: Need clarification of if this is in addition to line-grid
or replace.
astearns: Any out of flow thing, like floats is a problem for
step-sizing.
koji: When you are in normal flow step-sizing works better.
myles: I'm interested when both are being used on the same element.
koji: step-sizing rounds up line height, it just grows, line-grid
moves line box down.
myles: If we specify both numbers, the spec appeared to be moving
line boxes also.
astearns: The baseline moves within the linebox but doesn't move
the linebox itself.
astearns: line-grid does move the linebox.
astearns: If you have both step-sizing and line-grid, with a
baseline you get double spacing.
<Florian> if line grid creation takes its lines from the result of
applying step-sizing, it seems it would work out ok.
* liam wondering if this spec's functionality could be better done
with a function notation for line height
<Florian> Koji: If line grid works from used value of the line
height, then it works since step sizing affects that.
fantasai: I think that at a high level we have a number of design
principles for CSS.
fantasai: One of them is that features should be robust, shouldn't
break down in unexpected conditions.
fantasai: Another is that it should be understandable to the
authors.
fantasai: The tools and syntax that we use to express, they should
be understandable.
fantasai: The way this proposal works breaks both these principles.
koji: Can you specific?
fantasai: The double spacing issue, I need to make the line-height
smaller than I intend to get the result of double spacing.
fantasai: That's confusing for authors.
astearns: For grids there are a particular way to work with grids,
you set up the grid, then get the line-heights to work
with the grid.
fantasai: Why aren't you always setting them to one?
astearns: People set up line-heights to 0 in InDesign for things
to fall on the grid.
fantasai: This seems like a design flaw.
fantasai: I want to solve the problem, but this feels a little bit
like the variables situation.
fantasai: We had many proposals to solve variables, but each time
it felt not quite right, and we didn't adopt it.
fantasai: Then we ended up current variables proposal which works
really well with the way CSS works.
fantasai: I don't think we're there yet
ekimber: It feels to me like this would be one feature.
ekimber: I'm curious where is the origin of the top line defined.
koji: It is always at the top.
koji: Its rounding up heights.
ekimber: What other properties of text depend on the line-height,
what things would be mis-positioned?
ekimber: For example if I'm specifying super/sub-script would be
affected the way I want?
koji: Since this is just rounding up line-heights, if the
super/sub-script it will work, if they don't you'll get
double-spacing.
Florian: If you set line-height to 0?
astearns: Nothing happens.
koji: If you set line-height to 1.2, you get minimum padding
between lines.
TabAtkins: Earlier what are the difference between line-grid. What
cases do we want to use step-sizing instead of line-
grid? (where line-grid would be bad).
koji: You always need to worry about characters aligning to
different elements.
koji: If you offset an element by 2px, then you get next grid.
TabAtkins: Unless you get that element to create a new line gird.
astearns: I think that step-sizing is simpler for the simple case.
TabAtkins: It's simpler because its ignorable. In koji's example,
if you weren't careful, then everything would get
messed up, its very simple, but requires the author to
stay very simple, or carefully manage things.
<tantek> +1 TabAtkins, I'm also confused about line-grid vs.
step-size approach.
Rossen: If you have blocks which can't be step-sized then things
appear wrong.
fantasai: Most of the time people don't mix font sizes in a line.
fantasai: The font size within a particular block element doesn't
change.
fantasai: It would be nice if you created a basic paragraph it
should just work.
* bradk wishes that we had regular leading, even if it made
superiors overlap the previous line.
<liam> bradk, yes
dauwhe: Within blocks I want to say the spacing between line is X,
I'm used to using line-height prop for that, it works some
of the time.
dauwhe: Baseline to baseline distance is X, do that, this is what
I want.
fantasai: In a basic document, the kind we're discussing a lot
here as examples, are two major problems for baseline
rhythm.
fantasai: First one is, if I'm using the same size font throughout
a block (which is by far the common case), want baseline-
to-baseline spacing to be the same throughout.
fantasai: Let's solve that directly, either tweak rules for inline
layout or add a switch if we have to
fantasai: Then the other one is, I have something different: a
heading, a blockquote, an image, whatever; that is
interrupting the flow here
fantasai: And in order to maintain the rhythm, need it to take up
a step-size of the line-box-height.
fantasai: This proposal doesn't solve that. You have to make
things inline-blocks, which is weird, has many other
layout effects.
dauwhe: I can't believe I'm saying this, I would like to see a
wide-variety of layouts, and how we would do them in the
various proposals, and do they meet these usecases,
understandable etc.
fantasai: Headings and block images should just be blocks.
fantasai: Let's solve this directly with step sizing on the margin
box of such blocks.
dauwhe: Would like to see examples in the spec, more multi-line
blocks and how they handle this.
* skk thinks that I agree to TabAtkins opinion. In case I want to
use this feature, the existence of line-grid and step-sizing
is confusing. Is it impossible to make line-grid as step-
sizing's level2?
<myles> skk that is the question i asked earlier - how to upgrade
from one to the other w/o deprecating the old one
<skk> myles, sorry I missed your question. I think one of a
problem is line-grid specification is complicated and
difficult to implement in browser. If such a big
specification can be divided into a few part according to
implementation perspective, that might be helpful for
gradual implementation. It's just a design idea.
dbaron: 1) We did have old proposal, in line-box draft,
line-box-contain, gave you some control over what affects
the line-height.
dbaron: There are some tradeoffs, some of the things that CSS
wants to include in the line box height, as they will vary
between machines, even if line spacing looks fine on your
machine, may differ.
dbaron: 2) It sort of seems fragile.
dbaron: If goal (of authors) is to maintain a consistent grid
between columns, and trying to accomplish that with
heights, everything that is not a height, (margins etc)
need to be consistent with that grid.
dbaron: Makes me feel that this proposal is very fragile.
koji: If the dev doesn't pay enough attention to spaces, it is
true that this proposal will break, for line-grid it will
jump to the next grid.
<dbaron> While line-grid is harder to implement, I don't think
it's all that hard.
Florian: I think that what Tab is saying, in both systems if you
aren't sufficiently careful you have problems.
Florian: When this kind of stuff happens, with line-grid you can
fix it locally.
Florian: With step-sizing you have a local problem, which causes a
global problem.
astearns: Lets wrap up this topic.
<debate about complexity of problems>
astearns: Let's talk about color first, then if we have time lets
come back to it.
koji: Are people fine with FPWD?
astearns: Doesn't sound like we are ready.
Agenda
------
astearns: So, we had a schedule plan where we expected color to be
in the afternoon, for dino calling in.
astearns: Could split out color now. And then everybody comes back
for step-sizing part 2.
astearns: scroll-snap has to happen in the afternoon.
CSSOM View
----------
Topic: getBoundingClientRects()
astearns: So CSSOMView has been handled?
zcorpan: Yes.
zcorpan: A few years ago we got feedback from roc about gBCR when
there is a collapsed range. The spec would not return
anything useful.
zcorpan: Anne fixed it
zcorpan: Blink fixed it, and got feedback from authors when the
range starts with an empty rect and later has a non-empty
rect.
zcorpan: We basically changed the spec to what gecko did.
zcorpan: New behavior is ignore the empty ones, and use the ones
that are not empty.
zcorpan: Previously the first rect was always included.
smfr: Does the first one have a zero size?
TabAtkins: It has a position.
zcorpan: If you have an empty range...
smfr: I just the spec to be clear about zero size vs. zero origin.
<smfr> url pls?
<zcorpan> https://github.com/w3c/csswg-drafts/commit/0e7a5cbdea19397086e9423b508fe6f41decdcec
is the spec change
Received on Tuesday, 7 June 2016 18:26:04 UTC