- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 18 Feb 2020 19:19:37 -0500
- 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.
=========================================
CSS Multicol
------------
- RESOLVED: Confirmed that we do indeed want (at least generally)
Firefox's behavior; get Morten to confirm exactly
what he wants clarified in further issues. (Issue #4689:
column-fill in unconstrained containers)
Masonry Layout
--------------
- Discussed Mats's masonry layout proposal, which builds on the Grid
Layout model. https://github.com/w3c/csswg-drafts/issues/4650
- Open question of whether this is a variant of grid, or a
separate layout mode.
- RESOLVED: Adopt Masonry layout proposal, editors fantasai and Tab,
and Mats if he's convinceable, and Jen if she's allowed.
Exact relationship to Grid TBD.
(Issue #4650: Masonry Layout)
CSS Sizing 3
------------
- Christian will write up the behavior originally implemented by
Chrome for issue #3973 (Why was min-content etc. to be redefined
to be nothing like Block axis?) and then the group will discuss
changing the spec based on that definition.
CSS Rhythm
----------
- Since there are still outstanding issues the group decided to
remove tests and add warnings to line-height-step and line-grid
(Issue #938: Line grid and tests)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/galicia-2020
Present:
Rachel Andrew, Fronteers
Rossen Atanassov, Microsoft
Tab Atkins, Google
L. David Baron, Mozilla
Amelia Bellamy-Royds, Invited Expert
Christian Biesinger, Google
Mike Bremford, BFO
Oriol Brufau, Igalia
Tantek Çelik, Mozilla
Emilio Cobos, Mozilla
Elika Etemad, Invited Expert
Javier Fernandez, Igalia
Koji Ishii, Google
Brian Kardell, Igalia and OpenJSF
Jonathan Kew, Mozilla
Ian Kilpatrick, Google
Chris Lilley, W3C
Stanton Marcum, Amazon
Myles Maxfield, apple
Cameron McCormack, Mozilla
Tess O'Connor, apple
Manuel Rego, Igalia
François REMY, Invited Expert
Florian Rivoal, Invited Expert
Hiroshi Sakakibara, BPS
Jen Simmons, Mozilla
Alan Stearns, Adobe
Lea Verou, Invited Expert
Scribe: TabAtkins
CSS Multicol
============
column-fill in unconstrained containers
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4689
rachelandrew: New issue, but refers back to a previous issue; trying
to wrap up.
rachelandrew: Previous Multicol said that in continuous media,
column-fill is only used if height of columns is
constrained; otherwise they're balanced.
rachelandrew: Was commented out in 2012.
rachelandrew: Chrome and WK implemented column-fill as if that line
was there; Firefox implemented without.
rachelandrew: We put the line back in for #3224, to match Chrome,
but in #4036 we reverted based on dbaron's issue.
rachelandrew: dbaron suggested we change the line to say "in
continuous context, and last fragment in fragmented
contexts...", and I updated the table accordingly
rachelandrew: So we need to figure out what to do when
column-fill:auto and unconstrained height
rachelandrew: If we honor it, that means all the content goes into
the first column.
rachelandrew: This is only outstanding issue in multicol.
florian: In addition to Firefox vs WK, there was browser vs print
aspect
florian: Wanted consistency between multiple things.
florian: "browser when screen" and "browser when printing" should
act the same
florian: Shouldn't randomly become different, people don't test
florian: But also didn't want browsers and print formatters to do
different things
florian: It seemed to me there was only one behavior we could use
that satisfies those
rachelandrew: We resolved to revert the change and put an issue in
the spec in Fukuoka
florian: dbaron, do you remember what the "one harmonious approach"
was?
dbaron: I think our conclusion was...
dbaron: There were two constraints.
dbaron: One was we don't want the rules between continuous and
fragmented contexts to be different, such that you get
different results if you have a small multicol in a
fragmented context that is small enough to not fragment.
dbaron: Second is making the behavior of print formatters, and
browsers when printing, consistent.
dbaron: I think shortest path to satisfy both and be sensible is
Chrome and WK changing their behavior, I think to the Gecko
one.
dbaron: I think if we look at continuous context behavior, it would
involve Chrome and WK matching Gecko. I don't remember about
fragment context
faceless: Prince matches Firefox
florian: Remaining open question is, are Blink and WK willing to do
it?
rachelandrew: Morten says yes, but we'd have to clarify what
column-fill:auto and height:auto means
iank: Morten's fine, yes. Depending on how difficult, we might not
get to it immediately; it might wait for our new fragmenting
impl.
dbaron: I'm reading Fukuoka minutes, but I think we already decided
to do this.
dbaron: Morten was concerned about, once we make that change,
there's more that needs to be defined more clearly.
dbaron: so I think we agreed on the behavior we wanted, but then
needed to follow up with issues to make it more fully
defined.
dbaron: Resolution was "revert #3224, and add spec issues to define
this"
dbaron: So I think our resolution was reverting, and then there were
other issues that aren't fully defined and need to be
defined.
dbaron: I suspect Morten might be the best to remember what that
undefined stuff was.
iank: And I think Morten wanted it to all be done at once rather
than a dripfeed of impl issues, so he'll want it all defined
before he makes the change.
florian: Was the question about min-height:auto, max-height, etc.
dbaron: [reads Morten's comment]
* dbaron was reading
https://github.com/w3c/csswg-drafts/issues/4036#issuecomment-508378790
[ You're asking if I'm okay with #3224 being reverted and
willing to implement it in Blink? Sure, but then we won't
have to clarify what column-fill:auto + height:auto means,
do we? The spec, prior to #3224 said that column-fill:auto
means that we should never balance (except before spanners),
didn't it? ]
rachelandrew: All right, so I'll need to talk to Morten to see what
he was really wanting to be defined
rachelandrew: Can we have a clear resolution confirming this
position?
iank: Yeah, could we have fully defined behavior before we make the
change?
RESOLVED: Confirmed that we do indeed want (at least generally)
Firefox's behavior; get Morten to confirm exactly what
he wants clarified in further issues.
Multicol tests
--------------
rachelandrew: As part of this work I've been going thru the testsuite
rachelandrew: Some are quite old, going back to old Opera tests
rachelandrew: I've been inlining the tests as I go to see what's
tested and not
rachelandrew: I've got a whole bunch of tests now that are
Fragmentation, not Multicol, or Box Alignment.
rachelandrew: Don't have anywhere for them to live.
rachelandrew: What's the process for moving those?
TabAtkins: If those tests belong to Fragmentation or Align, we can
just move those in WPT, right?
rachelandrew: Dunno, got shrugs in #testing before
florian: If it still involves multicol, you can also still link in
the metadata to the part of it that's relevant in Multicol.
You can also include tests in <wpt> that aren't in your
spec's folder, if they're relevant.
fantasai: Yeah I think florian summarized it. Test goes in the
folder of the spec it's primarily testing; if it's testing
interactions you can link those cross-spec sections; if
the test is just using a feature for generic purposes
(like using backgrounds to make sizing effects visible),
you don't link that spec.
fantasai: Some tests you can go either way on whether they're tagged
Multicol or not, but they're definitely fragmentation;
only things like "how wide is a column, etc" are def
multicol.
iank: If you do move a whole bunch of tests, it's easier for us if
you do them in one large commit
iank: We have to update test expectations, etc.
rachelandrew: I've already got a spreadsheet, so I can do it all at
once
iank: How many?
rachelandrew: Dunno, a fair few. Tens.
Masonry Layout
==============
scribe: fantasai
scribe's scribe: heycam
github: https://github.com/w3c/csswg-drafts/issues/4650
jensimmons: Mats Palmgren, layout engineer at Mozilla, over
Christmas break, this is what he did for Christmas
present
jensimmons: He's thought in detail about what it would take to add
something to Grid to accomplish Masonry layout
jensimmons: It's lots of detailed from implementer perspective
jensimmons: So what is Masonry layout?
jensimmons: It's a popular idea of how to lay out content on the
Web, e.g. on Pintrest
jensimmons: People wanted to do it with Grid, but you can't really,
still have to use JS
jensimmons: works fast on Pintrest because they put a lot of money
and effort into it
jensimmons: others use this library [shows library]
jensimmons: Here's what the layout looks like [shows outline]
jensimmons: Why not do it with flexbox? well that would give the
wrong content order
jensimmons: Don't want the early things to be below the fold with
late things up at top in the later columns
jensimmons: also makes a problem with lazy loading, would rejigger
layout
jensimmons: Order people need is going across
jensimmons: This version of Masonry, the most common one, is that as
it goes to fill in the rest of the pieces of content
jensimmons: puts next item into the column that is the shortest, so
always closest to the top
jensimmons: Other option is to go from 1st column to last column
always
jensimmons: but skip columns that are too full to keep things
roughly in order
jensimmons: Mats believes he's figured out how to do it in Grid
jensimmons: That's the issue
jensimmons: I think it would be popular and people would be super
happy to have
TabAtkins: Yes, this has been requested for like 15 years
TabAtkins: Overall, love the proposal, think it's great, lots of
detail in it
TabAtkins: Only concern, making it part of Grid instead of its own
display type
TabAtkins: Think we should make it display: masonry, copy over
concepts from Grid
fantasai: Any examples of things you're concerned about?
fantasai: This is somewhat similar in that subgrid is also kind of
like a mode
fantasai: which creates a different way of laying out items in the
grid
fantasai: Masonry is just a different model for doing the rows
TabAtkins: Subgrid is fundamentally a grid still
TabAtkins: But masonry is different
TabAtkins: Example, Mats suggests an align-tracks property that only
applies to masonry
fantasai: What's it do?
TabAtkins: It aligns the Masonry stuff within their track
TabAtkins: So there are a few different layout concepts
TabAtkins: that don't apply to Masonry in Grid
TabAtkins: and that don't apply to Grid in Masonry
TabAtkins: So I think we should re-use as many concepts as possible
TabAtkins: but separate out as a distinct display type
TabAtkins: that has a clear signal for what applies here vs in Grid
<tantek> Is this orientation specific? I.e. presumably masonry
refers to the overlapping brick like layout. Flickr does
this for displaying photo results, e.g.
https://flickr.com/photos/tags/csswg
florian: For align-tracks property, if we did have different modes,
could we use an existing alignment property to do this?
fantasai: If I understand correctly, you have a box, then some
masonry tracks
fantasai: each individual track aligning its content to the bottom
fantasai: rather than taking the entire masonry chunk and sliding it
to the bottom
fantasai: Isn't this exactly what justify-content does in flexbox?
why not just reuse align-content?
TabAtkins: Only given an hour thought to this
fantasai: I think it's premature to split it out as its own
layout model, but which should think about that
fantasai: for now leaving it as part of grid makes sense until we
have a clearer idea of what doesn't fit
Rossen: Fan of this proposal
Rossen: What are we trying to get out of this discussion?
heycam: Wanted to get temperature of the room, see if there's
interest
heycam: and also get thoughts on integration
bkardell: Of course I want this
bkardell: Want to say same thing as Grid and Flexbox, we should stop
and solve the a11y problem with content reordering
bkardell: I have concerns about that, that's all
<TabAtkins> I think this doesn't introduce any new
content-reordering problems; it's definitely no worse
than "a pile of floats", still according with the
standard "left to right, top to bottom" ordering.
<TabAtkins> (Unless you use 'order', of course.)
rachelandrew: I would really like to see Masonry solved
rachelandrew: I also agree we should look at content reordering
problem
rachelandrew: Don't think it should be part of Grid
rachelandrew: Trying to teach it, it's not a grid
rachelandrew: would make a lot more sense to have a separate layout
model
<tantek> Is there no attempt to do baseline alignment across masonry
items in different columns?
<tantek> That might be one reason to consider it grid-like
<astearns> tantek: I doubt it would be feasible to to baseline
alignment when there are not grid lines in the block
direction
emilio: I don't know if should be separate model
emilio: but multicol changes layout model quite a lot, this still
mostly fits within grid layout paradigm
emilio: can share a lot of code
emilio: so not quite like multicol
jensimmons: I think these are great issues to bring up.
jensimmons: Taking off introducer hat
jensimmons: this is jen
jensimmons: I was also concerned about a11y order
jensimmons: but after explaining, I think it's less of a problem
than Grid
jensimmons: It does seem like people are tabbing through DOM order,
focus rings
jensimmons: Easier because content doesn't go below the fold
jensimmons: I do feel like this belongs as grid
jensimmons: There are 2 axes, and this only works in one axis
jensimmons: Do this in row directly, have all power of grid in
column direction
jensimmons: Things when it comes to subgrid and nesting a grid
inside a grid, might want things to interact
jensimmons: things interact
jensimmons: Just choose how you want to treat other axis
jensimmons: ...
<tantek> would https://flickr.com/photos/tags/csswg be an example of
doing it in the "row direction"?
<astearns> tantek: I don't think the flickr thing is masonry-row.
The content order would go top to bottom in that case,
and it looks to me like the first three pictures in the
first row are in content order
<tantek> astearns, I have heard what Flickr does called "masonry"
layout as well so that likely deserves some clarification
<tantek> in particular, the feature of resizing images to fit like
that
iank: I'll try and channel Adam Argyle
iank: He previously worked in industry and built lots and lots of
Masonry layouts
iank: He had similar reaction that might fit better as a separate
layout model
<TabAtkins> Ah, I remember why *-content can't work for distributing
the items in a masonry track!
dbaron: Jen was talking about, and think this might relate to Tab's
comment on IRC, applying grid properties in vertical axis in
masonry
dbaron: One thing I was wondering is how many interact with
placement concept of Masonry
dbaron: e.g. if you have align-content in the vertical axis
dbaron: space-around, you want even gaps
dbaron: you don't know how many items until you place them
dbaron: and you can't place them until you know the number of gaps
in each column above the item
TabAtkins: Mats answered it by saying you place items before
applying align-content
TabAtkins: align-content is a different thing, it moves the whole
grid
TabAtkins: repeat autofill doesn't work
TabAtkins: But back to fantasai's point about align-content, in Grid
it aligns the entire grid
florian: If you have a grid with sized tracks in the Block axis, and
the size of the tracks is smaller than the container, then
you can align
florian: but masonry tracks don't have such a size
TabAtkins: Track does have a size, it's the sum of all masonry items
in it
myles: Want to jump on bandwagon and say it's really exciting
myles: With regard to the new display type, I think Mats makes a
compelling argument wrt graceful degradation
fremy: You can just say `display: grid; display: masonry` which works
TabAtkins: Especially if we re-use grid-template-columns or
whatever, it's easy fallback
astearns: Side conversation with Tantek on IRC
astearns: Has example of Flickr, wants to ask if that's also Masonry
layout
<tantek> specifically with the resizing of items in the masonry
layout
Rossen: This is a multiline flex
<tantek> it's not just flex. it's about resizing the images
automatically to fit them in the row
jensimmons: Flickr decides how many photos to put in a row
jensimmons: then makes the outer edges to match the container
jensimmons: then changes the height of the row to match
jensimmons: It's weird and complicated and totally done in JS
dbaron: Each image is sized based on other photos in the row
jensimmons: If you [...] then you get basically that layout, but the
images are cropped by object-fit
jensimmons: Flickr uses JS to avoid cropping the images
jensimmons: and Masonry is a whole different layout
<tantek> anyway the point is due to the brick-like layout, this is
*also* called masonry
<tantek> having the row heights adjust automatically is key
<tantek> I'm saying that web developers (some at least) know this as
masonry as well
<tantek> so if you call something masonry, some may/will expect this
to be supported
<jensimmons> The demo I was just talking about:
https://labs.jensimmons.com/2016/examples/image-gallery-flexbox-1.html
It only works in Firefox because of the flexbox sizing
bug of images in Chrome, Edge & Safari.
Rossen: In summary, I'm hearing a lot of support for this proposal
Rossen: reminds me of early days of Grid, when we proposed something
Rossen: and 2nd model was proposed to add to it, at first seemed
unlikely to fit
Rossen: but ended up with a harmonious merge
Rossen: Let's get something in a more spec-like proposal
Rossen: then decide if it should fit into Grid, or should be its own
thing
Rossen: Are there parts that should be extensions to Grid?
Rossen: I think it will take some time to figure out
Rossen: but overall goal of proposal and exposure of topic is
achieved in sense that there's a lot of support and demand
for this, so let's continue working on this in a separate
module for now to bake out the details and decide the next
path forward
Rossen: Might be Grid, might be something else
Rossen: Sound good?
fantasai: +1
<tantek> +1
<bkardell> ... and to double down on solving the general reordering
issue?
Rossen: So I propose we take a resolution to adopt Masonry layout
and move from there.
fantasai: Who's editing?
TabAtkins: I'll co-edit, but not primary edit
Rossen: Mats?
dbaron: We might have to do some convincing.
fantasai: I can edit.
RESOLVED: Adopt Masonry layout proposal, editors fantasai and Tab,
and Mats if he's convinceable, and Jen if she's allowed
bkardell: Masonry isn't in content order
florian: Yes and no, it's not a 1D thing, they're in 2D space
florian: but within that space they're in content order
<astearns> they are always top to bottom, not necessarily left to
right
<bkardell> for the record, not pushing back on 'this' - worried
about the general space
Motion Path
===========
Merging All the Shape Functions
-------------------------------
fantasai: Do we want to wait for Amelia?
TabAtkins: I agree with Amelia, so can represent her position
[agenda-wrangling]
CSS Sizing 3
============
content-sizing keywords in the block axis
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3973
cbiesinger: Seems to be disagreement between me and dbaron
cbiesinger: For a long time min-content/max-content/fit-content were
defined to work in the block axis
cbiesinger: to be the size the item would have if it weren't
explicitly sized
dbaron: Size at what width?
cbiesinger: I know that's your objection to this
cbiesinger: Chrome had implemented this
cbiesinger: This is also essentially the same size that Flexbox uses
for min-height: auto
cbiesinger: At one point spec was changed to say that block axis
just computes to auto, and Chrome removed it
cbiesinger: However I think this is a useful thing to have
cbiesinger: Intrinsic size in the block axis at the specified width
cbiesinger: I would like to have that feature back
cbiesinger: Discuss.
dbaron: You said Chrome implemented it. I'd like to see the
definition of what Chrome implemented
TabAtkins: In particular our resolution was for you to tell us what
you did so we can look at it :)
<TabAtkins> "Leaving the issue open to: hopefully get some info from
@cbiesinger as he promised ^_^"
cbiesinger: Can write it up, but should I talk about it? or write it?
dbaron: I think there are a bunch of gaps in the specs, want to know
how you would fill in the gaps
scribe: heycam
fantasai: For block layout, in the block axis, by saying it becomes
auto, we're saying it becomes the max-content size
fantasai: the max content size, min content size, and auto size, are
exactly the same
cbiesinger: It doesn't work for min/max-height this doesn't work
right now
fantasai: And in that case, defining them to be the same in the spec
doesn't cause any problems.
dbaron: Except the auto height of the block is a concept at layout
time after you know the width
dbaron: whereas min/max content heights don't have a width to use
dbaron: and min/max content are referenced all over these other
specs without saying it's at a particular width
dbaron: A particular block has a unique min content height
dbaron: If min-content and max-content are a function of width, then
every spec that needs to use those concepts need to say what
the width input is
fantasai: I'm pretty sure grid does
dbaron: Pretty sure most specs don't
fantasai: For block, you always have a width
dbaron: You have many widths. Available width?
dbaron: Intrinsic size of an orthogonal float...
fantasai: That's defined in Writing Modes
fantasai: WMs says if you need the width you use viewport size plus
some other calculations
dbaron: Does it say that for intrinsic size? I think it says to do
that for layout, but these are different concepts
fantasai: So you want to WMs to clarify that it's used for both?
cbiesinger: You could say it uses the width in the current layout
mode
dbaron: It's hard for me to argue this without preparation, but the
last time I went through the specs following spec links I
couldn't find out how it was defined
cbiesinger: I don't disagree
fantasai: One thing that we are losing by defining everything to be
auto, if min/max content and auto size in block axis were
always equal, it wouldn't matter
fantasai: but the problem is that in grid and flex, they have
different meanings
fantasai: You get a different size, content lays out differently, in
the block axis, depending on min-content/max-content/auto
fantasai: and being able to request those sizes and being able to
use them within the context of other nested layouts is
useful
dbaron: But the spec right now pretends these are generic concepts
across all layout systems, and not derived from widths
dbaron: but layout systems define these all over without saying what
width to use
dbaron: cbiesinger and I agree that this is not currently defined in
specs
cbiesinger: Are you objecting to the concept of this? Or just the
fact that this is currently not well defined
Rossen: Let's double down on the previous resolution
dbaron: I think it's a huge architectural change for our layout code
dbaron: I want it to be important and clearly defined before doing
that
dbaron: I think this is one of those things where you can get pretty
close with a bunch of hacks, but that's not the same as
following the spec
dbaron: and I still don't know what the spec is
fantasai: You need to do some intrinsic sizing in the wrong axis to
get grid/table to work with orthogonal flows
fantasai: I think the architectural changes is whether you do this
or not, and you already have to do it to handle orthogonal
flows.
dbaron: Right now in code the functions that compute intrinsic size
don't take a width argument
dbaron: and if these things are a function of width we need to work
out what width to use for every caller
dbaron: Some of this is complicated because intrinsic size is
recursive
dbaron: It depends on all its descendants
dbaron: In some of these non-recursive cases it could depend on
layout, but we need to say what these cases are
dbaron: but I think there are cases where there are hundreds of
calls to intrinsic size calculations across our code, we
need to work out what to pass in
Rossen: I agree this is a large change if you are computing
intrinsic size without doing layout
Rossen: Might be best to close the discussion today until we have
details
Rossen: Christian has the action to write this up
CSS Rhythm and Line Grid
========================
Scribe: TabAtkins
Line grid and tests
-------------------
github: https://github.com/w3c/csswg-drafts/issues/938#issuecomment-575499518
koji: We discussed quite a bit on issues for rhythm sizing last time
two years ago
koji: As far as I understand, this issue was the most blocking for
the feature
koji: Since then, Blink shipped LayoutNG. I didn't re-implement this
in LayoutNG yet.
koji: Currently this test fails in all browsers.
koji: I don't see a way to solve this properly
<dbaron> The issue is blocking what?
florian: We talked about multiple solution for the double-sizing.
What is the test assuming?
koji: We just have tests for rhythm-sizing in general.
florian: We have a spec, and tests; you fail because you don't
implement. That's normal, right?
fantasai: What are the tests for? There's block step sizing and line
step sizing
fantasai: Were the tests for block step sizing, or line step sizing?
koji: Line step sizing
<rego> are these the tests?
https://wpt.fyi/results/css/css-rhythm?label=experimental&label=master&aligned
koji: Question isn't about that, tho. I have to admit that I've got
not great confidence on how I understand this accidental
double-spacing issue.
koji: But if I understand correctly, florian and astearns consider
this a critical blocking issue.
koji: From my perspective, any solution can't avoid accidental
double-spacing in some cases.
koji: So if we say accidental double-spacing fundamentally breaks
the feature, we're basically saying CSS won't have this
feature. Is that correct?
florian: Problem here is we want a vertical rhythm where the lines
are the same size, and what to do when you can't have that.
florian: So either you break the rhythm and let some lines get
bigger, or you double size the line to keep the rhythm.
florian: Can't avoid one or the other. What you can avoid is
double-size when you don't need them to be.
florian: So if we have a mode where we double-size some of the time,
making sure it doesn't happen gratuitously, or in a brittle
UA-dependent way, is the essential issue.
florian: So it's not "we can never have double sizing", it's "we
have to be careful and make double-sizing happen
consistently and predictably"
<tantek> rather than "that would be bad", can you state the desired
fallback behavior?
hober: Isn't there a third option?
hober: Enforce the rhythm, and let the line overlap slightly.
florian: I think it's a bad one, but yes.
hober: I think some would prefer that.
florian: Circling back to koji's question, we have multiple specs
addressing this problem.
florian: My feeling is that the most realistic part of this story is
block-step-sizing; easiest and least brittle.
TabAtkins: Not going to break your layout if all your blocks are
slightly larger in one browser than another
TabAtkins: but very broken if every line is double-spaced
faceless2: This only applies when line-height is normal, correct?
florian: Different concepts here. block-step-sizing has the problem
without line-height.
florian: So they overlap to varying degrees.
fantasai: I think neither of these specs should be actively tested
or implemented yet; I don't think we have great consensus
on this as the correct solution yet.
fantasai: Fwiw, block-step-sizing doesn't have this sensitivity to
UA differences in inline layout or font rendering.
fantasai: So I think we could point to a wpt revision that had those
tests, but I don't think we should highlight failures
before we have agreement on the concept at all.
fantasai: I think we need to handle font fallback in a more robust
way. I think there's a lot of work to do to solve rhythmic
sizing well, and a lot of that is solving inline layout
problem generally.
koji: We could just set line-height and it works, tho.
fantasai: Right, but baseline-to-baseline spacing is still
inconsistent.
fantasai: So because we have this discrepancy, almost all the time
we trigger the double-spacing.
fantasai: So we want to clear this up, make the lines naturally
rhythmic, so then when we need to *interrupt* the rhythm
with something significantly different we can invoke
rhythmic sizing.
koji: True for Latin, I don't think it's true for CJK.
koji: Really just want to know if we should even be thinking about
implementing right now.
fantasai: I don't think so, no. If you remove those tests, drop a
link to the last revision with them into the spec.
koji: Ok. But even block sizing has these problems too.
fantasai: I don't think so, no. Rhythmic sizing *will* increase the
size of blocks sometimes.
koji: We will have the same problems as text tho.
florian: How?
TabAtkins: If we have rendering differences in line heights, and the
block height is based on text content, we'll have the
same UA-dependent differences!
florian: If you size with lh unit, then...
florian: Really my issue is just about line-step-height. I don't
think it's about block-step-height, but if you think there
is, go ahead and open an issue about that.
astearns: Elika went over a bit of my comment, but if the feature
isn't in active dev, I think it's perfectly fine to remove
tests from WPT. I just approved a PR to remove all the
Regions tests for this reason.
astearns: I'd prefer if there *was* active development - I don't
think this issue is a blocker to doing work at all.
koji: So I hear consensus to remove the tests, and add warning to
line-height-step and line-grid; block-step is fine.
faceless2: RealObjects have implemented this; I can't speak for how
well.
faceless2: AH have an implementation as well.
faceless2: We've got it too.
faceless2: I think this is all about the differences in what
line-height:normal means between impls.
TabAtkins: I'll note that the ".tentative" substring in the filename
is designed for this - tests that shouldn't be considered
normative yet, but are in development.
Rossen: So current proposal is to remove tests, add warnings to
line-height-step and line-grid.
myles: What will the warning say?
florian: In line-height-step it can link to this issue.
florian: For line-grid, there are concerns, but no issue yet.
astearns: I can add the warning.
astearns: "We haven't figured everything out yet, but don't try to
implement blind assuming it's stable. Please give feedback
if you're okay with working on bleeding edge."
<br>
Received on Wednesday, 19 February 2020 00:20:22 UTC