<igalia> for people to call in https://meetings.igalia.com/cssw
<igalia> oops wrong link it seems https://meetings.igalia.com/csswg
<rego> present
<TabAtkins> ScribeNick: TabAtkins
github: https://github.com/w3c/csswg-drafts/issues/4689
rachelandrew: New issue, but
refers back to a previous issue; trying to wrap up.
... Previous Multicol said that in continuous media,
column-fill is only used if height of columns is constrained;
otherwise they're balanced.
... Was commented out in 2012.
... Chrome and WK implemented column-fill as if that line was
there; Firefox implemented without.
... We put the line back in in #3224, to match Chrome, but in
#4036 we reverted based on dbaron's issue.
... dbaron suggested we change the line to say "in continous
context, and last fragment in fragmented contexts...", and I
updated the table accordingly
... So we need to figur eout what to do when column-fill:auto
and unconstrained height
... If we honor it, that means all the content goes into the
first column.
... This is only outstanding issue in multicol.
florian: In addition to Firefox
vs WK, there was browser vs print aspect
... Wanted consistency between multiple things.
... "browser when screen" and "browser when printing" should
act the same
... Shouldn't ranodmly become different, people don't
test
... And also didn't want browsers and print formatters to do
different things
... It seemd 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...
... There were two constraints.
... One was we dont' want the rules between continuous and
fragmented contexts to be different, such that you get
different results if you ahve a small multicol in a fragmented
context that is small enough to not fragment.
... Second is making the behavior of print formatters, and
browsers when printing, consistent.
... I think shortest path to satisfy both and be sensible is
Chrome and WK changing their behavior, I think to the Gecko
one.
... I think if we look at continouous context behavior, it
woudl 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 colum-fill:auto and height:auto means
iank_: Morten's fine, yes. Depending on how diffiuclt, 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.
... Morten was concerned about, once we make that change,
there's more that needs to be defined more clearly.
... so I think we agreed on the behavior we wanted, but then
needed to follow up with issues to make it more fully
defined.
... Resolution was "revert #3224, and add spec issues to define
this"
... So I think our resolution was reverting, and then there
were other issues that aren't fullyd efined and need to be
defined.
... 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
rachelandrew: All riht, so I'll
need to talk to Morten to see what he was really wanting to be
defined
... Can we have a clear resolution confirming this
position?
iank_: Yeah, could we have fully defined behavior before we make the change?
RESOLUTION: Confirm that we do indeed want (at least generally) Firefox's behavior, and get Morten to confirm exactly what he wants clarified in further issues.
<fantasai> ScribenicK: fantasai
<TabAtkins> ScribeNick: TabAtkins
rachelandrew: As part of this
work I've been going thru the testsuite
... Some are quite old, going back to old Opera tests
... I've been inlining the tests as I go to see what's tested
and not
... I've got a whole bunch of tests now that are Fragmentation,
not Multicol, or Box Alignment.
... Dont' have anywhere for them to live.
... 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 backgrounds), you don't need to link
that spec.
... 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
ocmmit
... 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.
<fantasai> ScribeNick: fantasai
<TabAtkins> 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
... He's thought in detail about what it would take to add
something to Grid to accomplish Masonry layout
... It's lots of detailed from implementer perspective
... So what is Masonry layout?
... It's a popular idea of how to lay out content on the Web,
e.g. on Pintrest
... People wanted to do it with Grid, but you can't really,
still have to use JS
... works fast on Pintrest because they put a lot of money and
effort into it
... others use this library
... Here's what the layout looks like [shows outline]
... Why not do it with flexbox? well that would give the wrong
content order
... Don't want the early things to be below the fold with late
things up at top in the later columns
... also makes a problem with lazy loading, would rejigger
layout
... Order ppl need is going across
... This version of Masonry, the most common one, is that as it
goes to fill in the rest of the pieces of content
... puts next item into the column that is the shortest, so
always closest to the top
... Other option is to go from 1st column to last column
always
... but skip columns that are too full to keep things roughly
in order
... Mats believes he's figured out how to do it in Grid
... That's the issue
... I think it would be popular and ppl would be super happy to
have
TabAtkins: Yes, this has been
requested for like 15 years
... Overall, love the proposal, think it's great, lots of
detail in it
... Only concern, making it part of Grid instead of its own
display type
... Think we should make it display: masonry, copy over
concepts from Grid
<heycam> fantasai: any examples of things you're concerned about?
<heycam> fantasai: this is somewhat similar in that subgrid is also kind of like a mode
<heycam> ... which creates a different way of laying out items in the grid
<heycam> ... masonry is a different model for doing the rows
TabAtkins: Sugrid is fundamenally
a grid still
... but Masonry is different
... Example, Mats suggests an align-tracks property that only
applies to masonry
<heycam> fantasai: what's it do?
TabAtkins: it aligns the Masonry
stuff within their track
... So there are a few different layout concepts
... that don't apply to Masonry in Grid
... and that don't apply to Grid in Masonry
... So I think we should re-use as many concepts as
possible
<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
TabAtkins: but separate out as a
distinct display type
... that has a clear signal for what applies here vs in
Grid
florian: For align-tracks property, if we did have different modes, could we use an existing alignment property to do this?
<heycam> fantasai: if I understand correctly, you have a box, then some masonry tracks
<heycam> ... each individual track aligning its content to the bottom
<heycam> ... rather than taking the entire masonry chunk and sliding it to the bottom
<heycam> ... isn't this exactly what justify-content does in flexbox? why not just reuse align-content?
<heycam> TabAtkins: only given an hour thought to this
<heycam> fantasai: I think it's premature to split it out, it's its own layout model, but which should think about that
<heycam> ... 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
... What are we trying to get out of this discussion?
heycam: Wanted to get temperature
of the room, see if there's interest
... and also get thoughts on integration
bkardell_: Of course I want
this
... Want to say same thing as Grid and Flexbox, we should stop
and solve the a11y problem with content reordering
... I have concerns about that, that's all
rachelandrew: I would really like
to see Masonry solved
... I also agree we should look at content reordering
proble
... Don't think it should be part of Grid
... Trying to teach it, it's not a grid
<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: 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
emilio: I don't know if should be
separate model
... but multicol changes layout model quite a lot, this still
mostly fits within grid layout paradigm
... can share a lot of code
... so not quite like multicol
jensimmons: I think these are
great issues to bring up
... taking of introducer hat
... this is jen
... I was also concerned about a11y order
<astearns> tantek: I doubt it would be feasible to to baseline alignment when there are not grid lines in the block direction
jensimmons: but aftter
explaining, I think it's less of a problem than Grid
... It does seem like ppl are tabbing through DOM order, focus
rings
... Easier because content doesn't go below the fold
... I do feel like this belongs as grid
... there are 2 axes, and this only works in one axis
... do this in row directly, have all power of grid in column
direction
... Things when it comes to subgrid and nesting a grid inside a
grid, might want things to interact
<tantek> would https://flickr.com/photos/tags/csswg be an example of doing it in the "row direction"?
jensimmons: things interact
... Just choose how you want to treat other axis
... ...
iank_: I'll try and channel Adam
Argyle
... He previously worked in industry and built lots and lots of
Masonry layouts
<TabAtkins> Ah, I remember why *-content can't work for distributing the items in a masonry track!
iank_: he had similar reaction that might fit better as a separate layout model
<Zakim> dbaron, you wanted to ask about which grid properties apply sensibly given the placement algorithm
dbaron: Jen was talking about,
and think this might relate to Tab's comment on IRC, applying
grid properties in vertical axis in masonry
... One thing I was wondering is how many interact with
placement concept of Masonry
... e.g. if you have align-content in the vertical axis
... space-around, you want even gaps
... you don't know how many items until you place them
... 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
<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
<heycam> TabAtkins: align-content is a different thing, it moves the whole grid
<heycam> ... 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
... but masonry tracks don't have such a size
<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
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
... wrt 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
... Has example of Flickr, wants to ask if that's also Masonry
layout
<tantek> specifically with the resizing of items in the masonry layout
<tantek> yes dbaron
Rossen__: This is a multiline flex
<Zakim> astearns, you wanted to surface my side convo with tantek
jensimmons: Flickr decides how
many photos to put in a row
... then makes the outer edges to match the container
<tantek> it's not just flex. it's about resizing the images automatically to fit them in the row
jensimmons: then changes the
height of the row to match
... it's weird and complicated and totally done in JS
dbaron: each image is sized based on other photos in the row
<tantek> anyway the point is due to the brick-like layout, this is *also* called masonry
jensimmons: If you [...] then you
get basically that layout, but the images are cropped by
object-fit
... they use JS to avoid cropping the images
... and Masonry is a whole different layout
<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
Rossen__: In summary, I'm hearing
a lot of support for this proposal
... reminds me of early days of Grid, when we proposed
something
... and 2nd model was proposed to add to it, at first seemed
unlikely to fit
... but ended up with a harmonious merge
... Let's get something in a more spec-like proposal
... then decide if it should fit into Grid, or should be its
own thing
<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__: Are there parts that
should be extensions to Grid?
... I think it will take some time to figure out
... 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
... might be Grid, might be something else
... 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.
RESOLUTION: Adopt Masonry layout proposal, editors fantasai and Tab, and Mats if he's convinceable, and Jen if she's allows
bkardell_: Masonry isn't in content order
<dbaron> and Jen?
florian: yes and no, it's not a
1D thing, they're in 2D space
... 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
fantasai: Do we want to wait for Amelia?
TabAtkins: I agree with Amelia, so can represent her position
[agenda-wrangling]
<Rossen__> github:https://github.com/w3c/csswg-drafts/issues/3973
cbiesinger: Seems to be
disagreement between me and dbaron
... For a long time min-content/max-content/fit-content were
defiend to work in the block axis
... 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
... Chrome had implemented this
... This is also essentially the same size that Flexbox uses
for min-height: auto
... At one point spec was changed to say that block axis just
computes to auto, and Chrome removed it
... However I think this is a useful thing to have
... Intrinsic size in the block axis at the specified
width
... I would like to have that feature back
... 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
<inserted> ScribeNick: heycam
fantasai: in the block axis, by
saying it becomes auto, we're saying it becomes the max-content
size
... the max content size, min content size, and auto size, are
exactly the same
cbiesinger: it doesn't work for min/max-height this doesnt work right now
fantasai: and in that case, defining them to be teh same in the spe cdoesn't cause any problems
dbaron: except the auto height of
the block is a concept at layout time after you know the
width
... whereas min/max content heights dont have a width to
use
... and min/max content are referecned all over these other
specs without saying it's at a particular width
... a particular block has a unique min content height
... 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 iwdth
dbaron: you have many widths.
available width?
... intrinsic size of an orthogonal float...
fantasai: that's defined in
Wriitng Modes
... 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 to use it for both?
cbiesinger: you could say it uses the width in the current layout mode
dbaron: it's hard for me to argue this witout 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 ot be auto, if min/max content
and auto size in block axis were always equal, it wouldn't
matter
... but the problem is that in grid and flex, they have
different emanings
... you get a different size, content lays out differently, in
the block axis
... 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 dervied from widths
... but layout systems define these all over without saying
what width to use
... cbiesinger and I agree that tihis 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 doubel down on the previous resolution
dbaron: I think it's a huge
arthicetctureal change for our layout code
... I want it to be important and clearly defined before doing
that
... 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
... 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 worth
with orthogonal flows
... I think the architectural changes is whether you do this or
not, and you already have to do it
dbaron: right now in code hte
functions that compute intrinsci size don't take a width
argument
... and if these things are a function of width we need to work
out what width to use for every caller
... some of this is complicated because intrinsic size is
recursive
... it depends on all its descendants
... in some of these non-recurisve cases it could depend on
layout, but we need to say what these cases are
... 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 intrinsci size wihtout doing
layout
... might be best to close the discussion today until we have
details
... Christian has the action to write this up
<fantasai> ScribeNick: fantasai
<TabAtkins> ScribeNick: TabAtkins
<fantasai> 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
... as far as i understand, this issue was the most blocking
for the feature
... Since then, Blink shipped LayoutNG. I didn't reimplement
this in LayoutNG yet.
... Currently this test fails in all browsers.
... I don't see a way to solve this properly
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 ipmlement. That's normal, right?
<heycam> 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
... 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.
<rego> are these the tests? https://wpt.fyi/results/css/css-rhythm?label=experimental&label=master&aligned
koji: But if I understand
correctly, florian and astearns consider this a critical
blocking issue.
... From my perspective, any solution can't avoid accidental
double-spacing in some cases.
... 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.
... So either you break the rhythm and let some lines get
bigger, or you double size the line to keep the rhythm.
... Can't avoid one or the other. What you can avoid is
double-size when you don't need them to be.
... So if we have a mode where we double-size some of the time,
making sure it doesn't happen gratuitiously, or in a brittle
UA-dependent way, is the essential issue.
... 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?
... 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 ahve multiple specs addressing this problem.
... My feeling is that the most realistic part of this story is
block-step-sizing; easiest and least brittle.
<fantasai> TabAtkins: Not going to break your layout if all your blocks are slightly larger in one browser than another
<fantasai> TabAtkins: but very broken if every line is double-spaced
<fantasai> faceless2: This only applies when line-height is normal?
faceless2: This only applies when line-height is normal, correct?
florian: Different concepts here.
block-step-sizing ahs the problem without line-height.
... 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.
... block-step-sizing doesn't have this sensitivity to inline
layout or font rendering.
... So I think we could point to a wpt revision that had those
tests, but I don't think we shoudl highlight failures before we
have agreement on the concept at all.
... 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.
... So because we have this discrepancy, almost all the time we
trigger the double-spacing.
... 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.
... Really just want to know if we should even be thinking
about imlementing 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...
... 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 th efeature 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.
... 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.
... AH have an implementation as well.
... We've got it too.
... 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.
... For line-grid, there are concerns, but no issue yet.
astearns: I can add the
warning.
... "We haven't figured everything out yet, but don't try to
ipmlement blind assuming it's stable. Please give feedback if
you're okay with working on bleeding edge."
<fantasai> <br>
https://twitter.com/tabatkins/status/1219936010961915905
<emilio> ScribeNick: emilio
<astearns> github: https://github.com/w3c/csswg-drafts/issues/2513
TabAtkins: so the poll I started
yesterday about mod has ended
... had some fair results, and the contradictory results I
expected
... so 3/2 in favor of JS, 9/1 in favor of math if you ask them
about a basic computation, depending on how you ask
... so the conclusion is that most people just write buggy code
and they think / want math semantics
<fantasai> /JS/JS semantics if you ask directly/
TabAtkins: there's also a lot of discussion in the replies about use-cases
<jensimmons> link to poll??
TabAtkins: and it seems math is a better suit to fix those use cases
jfkthame: would people be better off with explicit is-odd / even functions
<fantasai> https://twitter.com/tabatkins/status/1219936010961915905
<fantasai> https://twitter.com/tabatkins/status/1219936010961915905
TabAtkins: they sometimes use it as a proxy for odd / even, but it's not general of course
<TabAtkins> https://twitter.com/tabatkins/status/1219939184682717184
TabAtkins: so no decision for now
yet unless the room is convinced, but worth thinking about it
and we can peek this up at a later call
... how does the room feel? Did anyone change their mind?
myles_: I guess there's a third option which is not defining what negatives does
TabAtkins: that's what C++ does and that's evil
myles_: I didn't mean to return unicorns but just explicitly return 0 or something
TabAtkins: it seems negatives could be common, I wouldn't want that
Rossen: seems not many opinions have changed so let's move on
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4662
TabAtkins: the definition seems
to not make sense
... the origin and size of the box are not related
... says that the origin of the coordinate space is the viewbox
start
... and the size is the size of the viewbox
... so for example if you have a viewbox="20 20 100 100"
... the origin of the coordinate space is outside of the
viewport, such as the origin is at (-20, -20)
... so that the viewbox is based off a rectangle outside of the
svg's viewport
heycam: so before CSS transforms,
in svg you couldn't use percents inside transform so this was a
non-issue
... I wonder if the issue is the way we're defining this
rectangle
... Maybe it doesn't make sense to define that rect
emilio: for percents in transforms you just need a basis so you don't need any origin right?
fantasai: yeah but other stuff references the view-box
TabAtkins: and the origin matters for rotations and scales
emilio: fair
myles_: pretend you use transform-box: view-box and rotate by 3deg or something, what would you expect?
TabAtkins: multiple acceptable answers, but the issue is that the size and the origin are not related, unlike other boxes
fantasai: the issue is that this
is how transforms have been defined in SVG
... [reads AmeliaBR's comment in the issue]
https://github.com/w3c/csswg-drafts/issues/4662#issuecomment-576496516
TabAtkins: ok if it's what SVG
uses by default then sure, whatever
... but I'd like it to be called out explicitly
faceless2: The way we see the
viewbox is just a translate transform
... I'm not sure it's as confusing as it sounds
TabAtkins: my issue is that if
you choose transform-origin: 100% 100% the point you get makes
no sense
... but sure if it's legacy then fine, I thought it was
invented recently as it was added after other changes
... so I'm ok with the behavior but I want to clarify that this
is legacy svg behavior
fantasai: there are other specs
that reference these values somewhat inconsistently
... we copied them all out into the box model module
<TabAtkins> https://drafts.csswg.org/css-box/#keywords
fantasai: I want to change the
definition of viewbox to account for this and then change all
specs to reference those definitions
... any objections to doing that?
RossenF2F: it seems something we
should do, and seems we should close this with no change
... with the note added to the spec explaining why
TabAtkins: I guess we'll add it to the box spec
RossenF2F: sure
fantasai: do we need another keyword to reference the box tab was talking about? (size of viewbox at the position of viewbox?)
RossenF2F: probably not
... objections to the proposed resolution?
RESOLUTION: No change to the behavior, add a note to the spec
RESOLUTION: move the box keyword definitions on css-box and publish a new working draft
RESOLUTION: rebase the rest of the specs referring to these definitions to point to css-box
fantasai: I propose to move the only non-css2 feature in css-box (margin-trim) to level 4 and move this to CR and co. fast so that other specs can depend on it
RossenF2F: sounds reasonable, objections?
<fantasai> s/spe referring/specs referring/
RESOLUTION: Move margin-trim to css-box-4 before republishing
github: https://github.com/w3c/csswg-drafts/issues/4674
cbiesinger: we're interested in
implementing this: there's a lot of values for this property,
but a lot of values didn't seem that useful to me
... florian came with some use cases but I'm not sure they're
useful enough?
iank_: we probably only want to implement stable
florian: the other values were
solving issues raised by google
... we should explain them better in the spec
... but I'd be sad if we removed it
cbiesinger: I think your explanation makes sense
fantasai: seems to me this feature belongs on css-scrollbars, not css-ui
florian: don't care, though I'm not an editor of css-scrollbars, so if you want me to keep editing that feature I should become an editor
<tantek> huh?
RossenF2F: objections to move from css-ui to css-scrollbars and adding florian as an editor?
<tantek> sorry I'm joining midconversation so I'm unaware of context
<heycam> from css-overflow, not css-ui
<fantasai> tantek, context is https://github.com/w3c/csswg-drafts/issues/4674
<TabAtkins> tantek, moving scrollbar-gutter to css-scrollbars
RESOLUTION: Move scrollbar-gutter to the scrollbars spec, add florian as an editor
<tantek> thanks fantasai
myles_: we did a review with some
people that know more about design than me
... this feature fundamentally breaks overlay scrollbars
... but we also understand that there's a real problem
here
... and you don't want the scrollbar to cover things
<tantek> myles++ has a very good point
myles_: there's also another
issue (#4691) which proposes adding an environment variable
with the width of the native scrollbars
... it seems that'd allow authors to peek
florian: I don't think the stable value changes anything with overlay scrollbars, it's the force value what's problematic for you right?
myles_: any property that says "all elements should not be covered by overlay scrollbars" is problematic
hober: we like the idea of moving active elements but we don't want to encourage authors to try to inset everything
cbiesinger: the env variable seems a better case for the google use case
florian: I don't think it would because an env variable is for the entire page, so it doesn't depend on whether there actually are scrollbars
cbiesinger: I meant the combination of the env variable with the stable value
fantasai: but florian's point
means that scrollbar width may change
... and you don't know the scrollbar width
myles_: the wide value is not really that wide, so probably just the wide one would be enough
<tantek> we deliberately removed explicit numeric width from scrollbar-width. there's also no "wide" value
<tantek> https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width
<cbiesinger> https://github.com/w3c/csswg-drafts/issues/4691
<tantek> just: auto | thin | none
myles_: I think the value should be zero for non-overlay scrollbars
fantasai: we need both to align non-scrollable elements to scrollbars
myles_: isn't that a problem now?
florian: yes, but that's
something that `scrollbar-gutter` solves
... the `always` toggle let you get the scrollbar gutter on
elements that are not scrollable
<fantasai> The example is is a toolbar which is not scrollable over a scrollable box. The author wants the rightmost item in the toolbar to align with the rightmost item in the scrollable box.
florian: which lets you fix that
hober: in a world with that value and overlay scrollbars then that'd be zero
<tantek> there is no "thick"
myles_: [[discussing with florian on the whiteboard]]
<tantek> scrollbar-width: auto
<tantek> is what I think people are trying to say?
myles_: so you mean that we need two environment variables, one per scrollbar-width value?
<fantasai> The discussion is about how to know how thick to make the padding on the toolbar if the scroller has a 'scrollbar-width: thin' declaration - the solution currently is to say 'scrollbar-width: thin; scrollbar-gutter: always force' on the toolbar
<tantek> examples?
<tantek> agreed with myles
florian: the thing that would fix this is `always`, people are already moving stuff away from the scrollbars, just guessing how wide they are
hober: so a variable that tells you how wide it is?
<tantek> good I want to hear Jensimmons's thoughts
florian: as long as you can do that then I'm fine
myles_: there are too many values
<Zakim> tantek, you wanted to ask if Blink also intends to implement scrollbar-color and scrollbar-width? if not, then it doesn't make sense to merge scrollbar-gutter with those
<tantek> re: https://github.com/w3c/csswg-drafts/issues/4674"Blink is interested in implementing/shipping scrollbar-gutter"
TabAtkins: some of them could be named better
tantek: I'd like to ask Google which other values besides stable is Blink interested in implementing, and is blink interested in implementing scrollbar-{width,color}?
cbiesinger: def. interested in stable and the env variable, not so much in others
<TabAtkins> Okay, so I remember why we did "always" - "stable" means that authors still have to ensure their designs work on both widths. "always" was meant to be a "let authors safely be a little lazier" value.
tantek: makes sense, and I tend to agree with myles_ that there's if there's no implementor interest and no use case maybe should be dropped
cbiesinger: scrollbar-{width,color} is not on the roadmap
iank_: not meaning we won't implement, but not on the roadmap
<TabAtkins> I feel strongly that if we do stable, we *need* force; that's the use-case Florian illustrated and it's very valuable I think.
tantek: then I'd probably advocate for undoing the move to the scrollbars spec
<hober> hober: why not put them in different levels of the same spec?
tantek: we'd have to do a lot of gymnastics
<TabAtkins> We can maybe drop "both" - it had use-cases that I think were mostly based on "always".
fantasai: I think there's a benefit to readers to have related features in the same spec
<TabAtkins> So perhaps an `auto | [ stable && force? ]` grammar reduction.
fantasai: keeping it in overflow doesn't make much sense
tantek: I don't think there's any benefit of moving it
<bkardell_> what about what hober said?
RossenF2F: I don't think we should do busywork just for the sake of doing it, but I do think that we should have scrollbar-related properties together to move them for the REC track, and for readers
<fantasai> hober, scrollbar-color and scrollbar-width already have one implementation
<fantasai> hober, scrollbar-gutter has an intent from Chrome
RossenF2F: this is why we have modules and levels
<fantasai> hober, it's not clear which is further ahead in that respect
<fantasai> hober, and we're not even in CR, so there's no reason to drop anything atm
RossenF2F: so we probably can still make a level of scrollbars be on the REC track with color/width
tantek: given the fact that there's disagreement on what implementors are interested in I think that trumps the cosmetic use case
<bkardell_> "interest" and "priority" aren't the same though
tantek: that practical divergence should override the cosmetic thing
fantasai: but it's a WD
tantek: right that's why I think
busywork is not warranted
... hearing from WebKit that they're interested in all three,
otherwise just leave it alone?
RossenF2F: let's try to avoid discussing process too much... Do you want to undo the previous resolution?
tantek: yes, because the lack of interest from blink in scrollbar-width/color means we shouldn't do it
iank_: that's a misrepresentation
<fantasai> I want to point out that oveflow-4 is otherwise completely experimental stuff and is not an appropriate place for a feature that is being imminently implemented
<tantek> fantasai then move the experimental stuff in overflow-4 to overfow-5
jensimmons: interest is not the same as saying not on the roadmap
<tantek> don't make extra busy work for multiple specs
<fantasai> tantek, it's not an overflow feature, it's a scrollbar feature
iank_: It just meant not in the roadmap at the moment
<fantasai> tantek, it doesn't belong in that module
iank_: that may change in the future
<tantek> overflow and scrolling are tightly related
<TabAtkins> tantek, stop objecting to other people volunteering to do work
<tantek> fantasai quit making an aesthetic argument
cbiesinger: I'm more skeptical about the scrollbar width use case, we just don't plan to implement it soon
<fantasai> tantek, it's a usability argument. I want our specs to not be GCPM-style hodgepodgs
<tantek> I'm saying postpone until we get positive signals from implementers for all three properties
RossenF2F: there are other implementors other than google :-)
<tantek> I'm arguing for more modularity not less
<tantek> anyway my objection to the previous resolution is recorded
<TabAtkins> tantek, one property per spec?
TabAtkins: yeah we try to be extremely clear when objecting because we understand it's a powerful statement
<tantek> TabAtkins: no I'm not interested in strawman like that or fantasai's "GCPM-style hodgepodgs"
<tantek> seriously, not good faith arguments
florian: I heard calls for dropping values and I'd like to push back. We designed this for years in response to use cases. I'm happy to document what the use cases were and maybe rename values so they're better names
<tantek> starting by removing things that lack a reason is the right thing to do
florian: but until that's done I don't think we should drop values
<tantek> hober++
hober: that's some work in order to chop things, i'd rather spare you the work and chop them now
<tantek> I'm really not sympathetic to features without examples/explanations up front
florian: it's just some examples, and I'm sure we won't chop it off
dbaron: I'd say that's a reason why specs should have explainers with what they're trying to solve
myles_: I don't think that actually conflicts with the env variable proposal
<tantek> if you can't link to the examples / explanations, consider them non-existent
florian: I recall people saying there are no use cases but they were, and I'll spend some time cleaning up this and investigate dropping these after we remember what they're for?
<tantek> florian: if you want to postpone dropping, then why not postpone merging also? why is that kind of tentative reasoning good for one postponement and not another?
<tantek> feels pretty inconsistent
TabAtkins: I think we agree that
stable or something that implements that is good, and that env
doesn't solve it
... I think `force stable` seems reasonable too
... as that is what you can use to align
... non-scrollable things to scrollable things
cbiesinger: you can use that with the env variable right?
TabAtkins: yes
florian: don't you need a media query for overlay scrollbars?
emilio: env variable would be zero in that case
TabAtkins: always is the one you were more skeptical about
<tantek> TabAtkins: "I could see dropping this for now"
TabAtkins: it's done so that you
can consistently design stuff across systems
... I could see us dropping always for now
... `both` is intended for always and it seems to be a lot less
valuable with stable
... and I think we can drop it for now too
... so we can probably drop them and use `stable` with the
`force` keyword, or with the `env()` variable
myles_: sounds reasonable
fantasai++
florian: my proposal is to
revisit this in a week or three
... once we have the cases described and alternatives clear
<tantek> if you're postponing dropping, then postpone merging
<tantek> why is postponing ok for one and not the other?
<TabAtkins> tantek, I'm not happy with you apparently misquoting me to make a point opposite what I'm supporting
hober: I wanted to reply to
tab
... you said that you're ok dropping always and both, and then
between stable + force, or stable + env() you're indifferent
right?
... I prefer the env variable
... I think it should be an exceptional thing done with
particular descendants, and the env variable encourages this a
bit more
TabAtkins: are you ok with adding more than two values for different widths?
hober: we can get to that once it comes up
cbiesinger: I agree with hober though for different reasons. I think env() is more understandable for authors than `stable force`
<tantek> I agree with cbiesinger, so don't bother with moving a dead property into a different spec
RossenF2F: so next steps florian brings the use cases for the current design
<cbiesinger> well the property isn't dead, just maybe some values of it
<hober> hober: i think we have multi-engine agreement here, which seems worth noting
<tantek> Thanks Rossen for clarifying purpose of scrollbars spec. You're right we should have started there
<tantek> Rossen++ for upleveling the conversation
RossenF2F: Re. merging,
scrollbar-width/color just styles controls... scrollbar-gutter
is more about the box model
... so let's not move everything to scrollbars yet until we
know what will remain there
<tantek> That sounds like I need to better document scope in the Scrollbars spec
RossenF2F: next call we'll see whether we stick to that resolution
<tantek> TabAtkins: I've grown very intolerant of time-wasting aesthetics.
jensimmons: I like it when this group is able to have discussions and make space for each other instead of going back and forth
<TabAtkins> ScribeNick: TabAtkins
<RossenF2F> github:https://github.com/w3c/csswg-drafts/issues/4670
emilio: there's no explicit area
in env() spec about how safe-area-inset behaves in
iframes
... ipmls disagree. We're doing some related work, would like
it clarified.
... If iframes are nested, they may not care about safe areas,
etc.
TabAtkins: Who's responsible for this spec?
heycam: dino and you
TabAtkins: I'm there for processing model, not values. ^_^
hober: I'm happy to bug dean about this.
TabAtkins: Can you (emilio) tag dino into the thread?
emilio: Yes
<RossenF2F> github:https://github.com/w3c/csswg-drafts/issues/3153
fantasai: I thought we resolved
this topic last year. I think we should be marking these
properties as discretely aniamtable? (nav-up, user-select,
etc)
... Stuff in the UI spec.
dbaron: I think we've only marked things as non-animatable when there are technical problems, like animation-* or display.
<tantek> is that really the right default?
fantasai: That's my understanding, so I think we just close this issue?
florian: I agree we only make
things impossible when it's technically hard, and I don't that
the css-ui things are that. I think they should be switched to
discrete explicitlyh.
... So if anything in CSS UI is still marked as non-animatable,
we should fix that to say "discrete"
tantek: Something dbaron said
about non-animatable.
... I agree that's been our historical default, but I'm
wondering if that's acutally desirable.
... At minimum, every time we mark something animatable, that
implies we need tests for that, that the animation works.
... So those are all costs. So is that rule a sufficient
default? In this particular case, it feels kinda weird to
animate these particular proeprties.
... I want to know florian's opinion on this. But my intuition
is that there's no use-case for these particular
properties.
dbaron: As far as use-cases,
peopel use animations in contexts where they animate some UI in
from not being there, then "turn it on".
... I could imagine setting nav-up as part of turning it on.
Maybe it could have been there all the time, but it seems
plausible to do.
tantek: That's the kind of
reasoning I'm happy to have on the record.
... If you're animating layout, you might need to animate the
nav-* props; seems weird but I've seen weirder.
TabAtkins: And Lea has brought up examples in the past of odd-seeming animations; I think there's probably an example for everything.
heycam: I think there's value in
having the blanket rule of "animatable unless impossible" vs
lots of use-case analysis.
... And if something's not animatable we ahve to write tests
for that anyway, so same amoutn of work.
florian: Agree on testing.
<tantek> good point heycam
florian: And note it's also about transitions. "animate or not" tells you whether the transition happens at the middle or at the beginning (or end? don't remember). So it has to switch anyway.
<tantek> is there a use-case for user-select animating?
florian: display, animation, etc can't be switched at all for technical reasons, but everything else we're just deciding where in the animation it switches, and there's no good reason to ban it from choosing where to switch.
<tantek> (figured I'd just ask in IRC instead of q+ for that)
<tantek> what are we making user-select consistent with?
florian: I agree that user-select doesn't appear to ahve a use-case, but for aforestated reasons having an exception here doesn't seem to be useful; we stil have to pick one way or the other.
<heycam> tantek, perhaps for similar reasons as dbaron mentioned about some UI animating in. maybe you want it not to respond to user interaction until the animation is done, or at a certain point
<fantasai> all other properties in CSS that use keyword values
<tantek> ok heycam. good enough for now.
tantek, more importantly to florian's point, transitioning the property makes it swap at some point regardless, its 'justa bout whether it's possible to choose where it transitions or not.
RossenF2F: So close as accepted? Any objections?
RESOLUTION: Mark user-select as discretely animatable, not non-animatable.
<tantek> TabAtkins, ok that's the consistency I was looking for. thanks.
heycam: Spec is currently in wicg
emilio: Resolution to put it in
cssom
... Discussion about whether to put it in level 2, or a diff
spec, or same document. I'd prefer it same document.
TabAtkins: We can ask Rakina if she wants to do the work or let you do it. I agree putting it in CSSOM1 is best.
RossenF2F: Any objections?
RESOLUTION: CSS() is merged into CSSOM1 (either emilio or rakina doing so)
<RossenF2F> github: https://github.com/WICG/construct-stylesheets/issues/45
heycam: context of me raising
this is that we'd like to ship soon. there's a bunch of issues,
but these four seem most worth discussing.
... last time this was discussed, there was a hope that tc39
would define some new mechanism for array-like things.
... Last comment in the issue was that some small aspect would
be introduced, but not the whole use-case.
... I'm not happy with FrozenArray either, and hopefully we can
move to a better compat model in the future.
... But I'd like to see if we're definitely not going to move
to an explicit .add()/.remove() methods
hober: Speaking for Ryosuke...
<tantek> heycam, could you comment in https://github.com/WICG/construct-stylesheets/issues/45 accordingly? I didn't see any reference to TC39 there
hober: He's very opposed to FrozenArray, and wants to move back to add/remove methods
<hober> https://github.com/w3c/webcomponents/issues/759#issuecomment-521053064
hober: He says FrozenArray
encourages racy code.
... (example above)
TabAtkins: Now that Domenic has left TC39, we don't have anyone really pushing for it anymore.
heycam: I'd be happy to change away from frozenarray, but I want to make sure that, since Chrome is shipping right now, they'd be okay with changing.
TabAtkins: I think we're fine with changing since it's an early change, but FrozenARray is what IDL is recommending right now, and there's advice to explicitly not add new listish collections.
<tantek> TabAtkins, since you attend both CSSWG TC39, and I did once, should one of us pick up liaisoning?
emilio: I don't think we need a new collection; we can add functions to document.shadowRoot, like .insertAdoptedStylesheet() and .removeAdoptedStylesheet(), and maybe just .appendAdoptedStylesheet().
<tantek> I just want to make sure that if we (CSSWG) want something from TC39, that we capture that in our issue, and that one of us commit to filing a respective issue in a TC39 repo (I can help with this, but also happy to defer to TabAtkins)
TabAtkins: Not to get too in the weeds, but how would the adopted sheets be exposed?
hober: Just a CSSStylesheetList, still hanging off of .adoptedStylesheets
<fantasai> ScribeNick: fantasai
TabAtkins: I think that's OK, sure
hober: I wanted to follow up on
what emilio said seems fine
... Problem here, we all agree, CSSOM is not great
... What I like about the resolution isn't that it contnues
CSSOM parts we don't like
... It's a feature addition to CSSOM that's compatible with
CSSOM, but does not prevent us from coming back and fixing all
of CSSOM
... Let's make all the same mistakes we've always made
... even though it's not a design we're not crazy about
... and come back and fix it all later
TabAtkins: Are we sure that CSSStyleSheetList can be upgraded to an Arraylike?
hober: idk
bkardell_: CSSOM.next context?
TabAtkins: Yes. I think we
can
... would be nice to know for sure
heycam: Depends on particular
solution
... Emilio's suggestion is to add the mutating methods on the
shadow root and not on the style sheet list object,
right?
... A little weird and different that the object that exposes
the list of items is not the same object on which you have the
mutating methods
emilio: How different from CSSGroupingRule having ?? or CSSStyleSheetRule having ?.insertRule()
heycam: You're right, it's already weird!
Proposed: Make adopted stylesheets a CSSStyleSheetList and add the appropriate add/remove methods to the document or shadowRoot interface
<tantek> Is there any outstanding request for TC39? Or did that get dropped?
heycam: Compared to CSSStyleSheetRule, there's no append method?
emilio: but I mentioned append because I suspect that's what more people would do
<TabAtkins> tantek, we believe we can still upgrade the CSSSTyleSheetList into an ArrayLike in the future.
hober: Tantek raises question, should we communicate our continued interest in this problem to TC39? And how?
TabAtkins: We need a champion,
interest isn't enough.
... I'm overloaded, so I can't do it
... for Arraylikes
hober: We can ask our reps on the group to mention it
<tantek> Can we capture in an issue at least? Even without a champion?
<tantek> Thanks hober
<scribe> ACTION: hober, TabAtkins, heycam to Ask TC39 reps to advocate Arraylike
<TabAtkins> tantek, without a champion nothing will move
RESOLUTION: Make adopted stylesheets a CSSStyleSheetList and add the appropriate add/remove methods to the document or shadowRoot interface
<br type=lunch>
<tantek> TabAtkins, I'm ok with filing an issue to at least capture it and maybe a champion finding that after
<TabAtkins> tantek, And I've clearly communicated our desire for it several times over the last several years. ^_^
<TabAtkins> github-bot: end topic
<tantek> "clearly communicated"? meaning you already filed an issue? or in-person in TC39?
<tantek> I don't want to duplicate your work to be clear :)
<RossenF2F> github-bot, end topic
<heycam> in person
<heycam> there's already an issue
<astearns> Ah, github-bot didn't comment on the issue because it's a WICG one
<astearns> waiting for enough people to get back in the room to resume
<TabAtkins> tantek, yeah, in person. talked to a bunch of the active editors/champions about this over the years
<emilio> https://usercontent.irccloud-cdn.com/file/xHjVjvtb/csswg.png
<astearns> dbaron, can you make the bot aware of the WICG repo?
<stantonm> ScribeNick: stantonm
<TabAtkins> "the WICG repo" doesn't exist, it's a ton of repos. But yeah it would be good to be allowed to comment on repos in that user.
<tantek> Thanks TabAtkins, this is not a priority for me so I'll defer to your experience here. If you decide you want liaison help on this, I may have some cycles (and interest in helping TC39 / CSSWG comms)
<TabAtkins> whoever your tc39 manager is, just talk to them about this. i'll be talking to shu.
<tantek> I need a link for "this" to do that 😂
<tantek> Yulia is our TC39 lead
<dbaron> github-bot, reboot
<astearns> github: https://github.com/WICG/construct-stylesheets/issues/105
github: https://github.com/WICG/construct-stylesheets/issues/105
... https://github.com/WICG/construct-stylesheets/issues/105
heycam: css stylesheet interface
has constructor, allows to set various things on the
stylesheet
... seems like allows combinations of things that are not
valid
... specifically creating stylesheet with empty title
emilio: only use for title and
alternate is compute disabled bit
... don't see anything useful
TabAtkins: so your saying we should just remove it?
emilio: yes
chris: don't need it not necessary
emilio: title attribute sets
preferred stylesheet list, why it doesn't apply in shadow
dom
... don't know what it means for ransom constructible
stylesheet
... just use .disabled attribute
heycam: remove constructor, and force .disabled?
emilio: title doesn't work in
shadow dom
... reason title is useful is because browsers provide UI for
switching
... .disable is still fine
christ: used to be more visible for, but some functionality moved away
RESOLUTION: remove title and alternate from constructor
<astearns> github: https://github.com/WICG/construct-stylesheets/issues/95
heycam: regular non-constructable style sheets have url to resolve other stylesheets
with constructable, no facility to provide url
scribe: regular urls are resolved
against document
... you might want to be able to specify
TabAtkins: web component wants
css to also be relative to some 3rd party url?
... can't hardcode deployment url, how do you use to it to get
relative url
... when user says background.png, want it to use 3rd party
load path - currently uses first party
heycam: read issue as today there's not a good way to do this
TabAtkins: splitting parts of
URL, base part still might be hard to obtain
... url is hardcoded somewhere...just elsewhere than your
stylesheet pipeline
hober: probably fine to set base and location as specified
heycam: not speficying url of sheet itself
hober: yes, sheet url is same as document url
RESOLUTION: add base URL constructor argument for sole purpose of resolving relative URLs in stylesheet, and location of the stylesheet remains that of the document
<TabAtkins> TabAtkins: And do we need to note the security concerns that bz raised, like with file:// etc?
<TabAtkins> hober: Those are addressed by instead doing this as just a relative-url resolver, and keeping the stylesheet location the same.
<TabAtkins> TabAtkins: Cool.
<astearns> github: https://github.com/WICG/construct-stylesheets/issues/93
github: https://github.com/WICG/construct-stylesheets/issues/93
heycam: spec says orderering of stylesheets should be ?, but actually should it be other way around?
<heycam> https://github.com/WICG/construct-stylesheets/issues/93#issuecomment-487772869
TabAtkins: my comment says make sense to put after
emilio: don't think there's a strong reason for one or other
hober: agree, but is there consistency arguments?
TabAtkins: maybe related to @font-face, which is after
bkardell_: talking about shadow
root and document styles, strangely related - some things bleed
through, some blocked
... not sure I get what ordering means
... would like them to come before
... different use cases, adopt styles from outside
TabAtkins: all sheets that come from markup come before adopted style sheets
bkardell_: we want to use these for UA equivilent, seems like not the right move
TabAtkins: adopted style sheets
help when people put things directly in shadow dom
... component usage will move to adopted style sheets, gives
full control
... if you use style inline, it's baked into the template
... similar to link style sheet in head, where you override
with adopted
... both ordering can make sense, no strong argument
bkardell_: we don't know which is correct
hober: if we don't know, ask the
author
... implies two sets of adopted style sheets, seems
complex
... not sure if additional complexity is worth it
TabAtkins: don't need two sets, just move from shadow root to adopted
bkardell_: can you do adopted style sheets outside shadow dom
TabAtkins: yes
hober: summarizing = after, if they want before have to specify
RESOLUTION: constructed style sheets to always go after
<TabAtkins> astearns: And if we realize that authors do ahve common need to put the adopted ones first, we're free to add a knob for that.
chris: color-5 is ready, it's a delta spec with color modification
<florian> +1
RESOLUTION: publish first public working draft of color-5
hober: FPWD of transforms-2
RESOLUTION: publish FPWD of transforms-2
dbaron: no objections, maybe it makes sense to publish transforms-1 at same time
fantasai: transforms-1 is in good
shape, it's in CR
... media-queries-5
RESOLUTION: resolved to publish media-queries-5
dbaron: does publishing delta spec break tools?
TabAtkins: bikeshed will remove
things
... there's no quick fix
chris: color-5 is entirely new feature, it's useful to have delta
TabAtkins: un-delta for publishing
fantasai: that's hard, we need to have goal to publish more specs
dbaron: add a thing that both versions maintained in single doc
TabAtkins: no quick solution
fantasai: can we publish resize-observer
<rego> https://drafts.csswg.org/resize-observer/
dbaron: any concerns with it being in WICG
florian: double IPR for contributions
fantasai: in practice doesn't matter if they're also in CSSWG
TabAtkins: same boat, we're good
astearns: only asking to publish resize-observer yourself
chris: have to file issue saying to publish FPWD
RESOLUTION: publish FPWD of resize-observer
fantasai: css-conditional level 4
RESOLUTION: publish FPWD of css-conditional-4
fantasai: css-highlight-1
hober: some disagreement
... with FPWD we want to make sure we have good idea of what
were doing
... event API is missing
... in current would rather not publish, we should at least
stub it out before publishing
florian: gives different signals to lawyers if it's incomplete
hober: I can commit to stub it out
RESOLUTION: stub out events API, then publish FPWD of css-highlights-1
fantasai: any other drafts?
<tantek> I'll be ready to republish CSS Scrollbars soon
<tantek> Just one issue/edit remaining
florian: text-decoration-4
fantasai: need to check through issues first
<tantek> (thanks to fantasai nudging me last week)
fantasai: any other working drafts we should publish?
astearns: do we need to request before?
fantasai: depends on time frame, not normally
heycam: maybe scroll anchoring
TabAtkins: I can own, and publish
RESOLUTION: FPWD of scroll-anchoring level 1
florian: scroll bars?
fantasai: tantek just said he has some more issues to fix
<tantek> other than that issue 3315, draft and changes section is up to date but still regenerating (re-bikeshedding?) https://drafts.csswg.org/css-scrollbars-1/#changes
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4573
myles: unicode-range takes bunch of code-points
<dbaron> the addition of those two agenda items was https://wiki.csswg.org/planning/galicia-2020?do=diff&rev2%5B0%5D=1569210305&rev2%5B1%5D=1570141384&difftype=sidebyside
myles: bad for a couple reasons,
lots of numbers and not clear what they mean
... also when adding some like emoji, you can list all unicode
points - but it changes over time
... proposal to add keyword that lets the browsers define the
code points
florian: what are the keywords
myles: issue says use pull keywords from ISO
hober: we shouldn't define these things, reference something in unicode
myles: different languages use
some common code points
... keywords shouldn't be a partition, there will be
overlaps
... space character will be in most of them
fantasai: two factors, script
extensions list - some of these are assigned to common
script
... we should be looking up script extensions
... other case is super common things - numbers, space,
etc
... alot of things assigned to common script
... probably makes sense to include common by default, but have
opt out
myles: we should resolve that we would like keywords, but not resolve on the actual keywords
fantasai: we should rely on iso
faceless2: rely on existing registry
astearns: should we have everything in the registry
heycam: do the names in the registry match normal css conventions?
TabAtkins: looks like no?
fantasai: should be a list of keywords 4 chars long
<faceless2> https://www.unicode.org/Public/12.1.0/ucd/Scripts.txt
<astearns> `Zsye 993: Emoji`
TabAtkins: if we're confident they are 4 letters, we can take directly
fantasai: think that should be fine, they need to maintain compat
<faceless2> example values : "Hebrew", "Devanagari", "Common"
myles: we may get it wrong, can we tentatively resolve to try something out first
florian: go with 4 letter name of long name? or not deciding
faceless2: where did four letter name come from?
florian: long name has hyphens, 4 letter is defined somewhere else
TabAtkins: casing shouldn't be important
<dbaron> The 4 letter script codes are always letters and come from ISO15924: https://tools.ietf.org/html/rfc5646#section-2.2.3
astearns: leave it to the fonts editors to define what keywords we pull, don't need to resolve on that now
myles: I'll also contact unicode
jfkthame: should there also be exclusion values?
hober: if you could exclude a range, you could exclude common range
myles: be careful we don't turn this into a full language
chris: even if you do a good job,
when unicode adds new values you may unintentionally exclude
things
... shift burden of defining onto external body
<dbaron> also see https://unicode.org/iso15924/iso15924-codes.html
RESOLUTION: we are going to create keywords for unicode ranges
<dbaron> "Zsye" is for Emoji, I think :-/
<dbaron> I think that's a little unfortunate.
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4606
chris: first had these thoughts
in CSS2, said cursive matched cyrillic (?)
... how similar is kaiti to cursive
... would like to see more comments from people who read
chinese
myles: can we ask i18n
chris: we should reference clreq
fantasai: usage of kaiti is
similar to how english uses italics, not really cursive
... switching to cursive english font in middle of kaiti feels
inappropriate
heycam: see kaiti in childrens books
fantasai: something like comic
sans
... not fully connected writing
florian: mapping english words
like cursive doesn't always make sense in other language
... inconsistent mapping
chris: we don't provide
typography for free, better to use font-family name
... if you want something specific say something specific
fantasai: high-level switching
can be nice, distinguish paragraphs
... think we do need some kind of syntax
florian: should not map all
keywords we have to other language
... how far do we need to go? not sure
astearns: we should ask clreq for this issue
florian: what do we want to ask
astearns: do we need a keyword for kaiti, or can it map to existing keywords
chris: followed spec in good faith, browser implementers may need to back things out if we change
s/authors followed/followed/
myles: valuable for us to have criteria on when to add new generic font keywords
astearns: open page on wiki for requirements of new keywords
dbaron: it's useful to have that in the spec, fine to have non-normative explaining why the spec is this way
<Zakim> dbaron, you wanted to comment on whether data indicating which category a font falls in exists in the font or the OS
hober: lets people know how to change it if they see it in spec
astearns: put in wiki as scratch space
dbaron: can we extract metadata from fonts to help derive these keyworks
myles: most existing generic font families fail that test
jfkthame: in theory panose should work, but in pratice usually not there
myles: some criteria for naming,
needs to map to more than just one font file
... useful for installed fonts, OS's need to have installed
fonts that match
... other criteria is that at least two OS support a font for
that generic
chris: not always helpful in underrepresented languages
astearns: but we already resolved to do work on that front
fantasai: so then it's with appropriate language pack installed
<fantasai> for some appropriate definition of language pack
myles: computers don't know, browser dev needs to manually type in list
<Zakim> fantasai, you wanted to say that the threshold is, are typographers regularly using a distinction in font stylistic groupings to make a semantic distinction in their publications
fantasai: threshold should be
whether typographers in typical publications are using
distinctions between different groups of fonts
... example is italic vs normal vs bold in latin
... sans-serif, serif, monospace makes a semantic
distinction
dbaron: does serif/sans-serif meet that criteria
hober: good to come up with criteria, stuck with the ones we already have
<scribe> ... new criteria should just work going forward, may not fit existing perfectly
fantasai: there are stylistic distinctions sometimes, but can also be semantic in many others
florian: criteria is useful for prioritizing, but hard to say yes/no
fantasai: if we meet the criteria, should add; if we don't, we may add
<fantasai> it's a sufficient but not necessary criteria
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4680
<astearns> github: none
<astearns> github: https://github.com/w3c/csswg-drafts/issues/982
chris: css object model has not
clear text about how to construct these color strings
... color-4 should obsolete that part of the model
... do people agree? or do we think it needs
serialization
... even if you have rgb with percentage, some bits get thrown
away
... should it be in color-4 or OM
emilio: as long as its well defined I don't care
TabAtkins: prefer color spec
leaverou: remove it from css OM and just point to color-4
florian: agree, color-4 now has appropriate infomation to represent that spec
RESOLUTION: move serialization into color-4
fantasai: before we remove from OM should we publish it
TabAtkins: publish both after the move
<astearns> github: https://github.com/w3c/csswg-drafts/issues/480
chris: dean raised how does the
color function get serialized
... whats a good serialization, for all the new ones they need
to be floats
... any problems with that in OM
TabAtkins: if it's not int it will serialize property, as long as data model underneath is number
chris: for color you can use 0-1,
or 0-100%
... 0-1 was simpler
emilio: consistent with alpha
RESOLUTION: color() functions, if they have a choice between percentage and number, they should use number
chris: lightness is a percent, how do we handle that specific one
TabAtkins: percentage and number
equilivence is defined as 0-1 equals 0-100%
... so we can't just accept number
... in the color function, just follow the rules - which is
0-1
fantasai: agree with tab
florian: for match function we take 0-100?
christ: eventually caved to just take percent
TabAtkins: could be this one color space takes 0-400, so doesn't matter
chris: some people use equipment that gives back L in 0 to 100 range and no percent
fantasai: adding the percent sign makes sense
TabAtkins: don't do the weird thing with lab and percentages (?)
chris: did it for rgb, so we
argued it might make sense for lab
... it's longer so not being used as much
<AmeliaBR> We already have RGB functions where percentages map to 0-255 in integers. Because that's the convention for that data type. If integer 0-100 is the convention for lab.
<AmeliaBR> ... maybe makes sense to follow.
<fantasai> in the color() function?
<AmeliaBR> Ummm… I don't know which syntaxes are allowed there.
<TabAtkins> Proposed Resolution: the `color(lab ...)` function, like the rest of the color() values, are in the 0-1 (or 0% - 100%) range. And they serialize the same as other color() values (as a 0-1 number).
RESOLUTION: the `color(lab ...)` function, like the rest of the color() values, are in the 0-1 (or 0% - 100%) range. And they serialize the same as other color() values (as a 0-1 number).
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4645
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4645
<fantasai> ScribeNick: fantasai
TabAtkins: Dialog layout
description, two modes
... 2nd one is a very long run-on sentence that's weird and not
described in CSS
... Behavior is useful, but unfortunate not in CSS
... So a few things to do
... First question, is this worth trying to put into CSS?
... Next, quick description of what it is and what might be
involved, to get an idea of how it would work
<AmeliaBR> Define in CSS please!
TabAtkins: Thoughts on whether to describe in CSS, or treat as a special one-off case in HTML
florian: In general, think it's
better to do in CSS
... but if extremely complicated * low value, maybe not
smfr: Authors might want to use
the same type of positioning for their own fake dialogs
... so better to have in CSS
<AmeliaBR> Defining in CSS also makes it easier to modify / override with CSS (e.g., by media queries, interactions with other CSS).
TabAtkins: Aim to get a
resolution to add this to CSS, does anyone object to me putting
this into some spec, probably css-position?
... I'm taking the silence as assent
tantek: Any security considerations wrt lowering barriers to making fake dialogs?
TabAtkins: Can do in JS
already
... So can we take a resolution to that?
RESOLUTION: Define dialog positioning in CSS terms, probably in css-position, with aim of replacing HTML's one-off description
fantasai: ...
TabAtkins: ...
emilio: It's a stateful position, because you don't want to reposition the dialog when you scroll or relayout
TabAtkins: here's the basic
description
... Ignoring stacking context aspect
... but for positioning bit
... It's basically abspos
... where we figure out the offset to apply when it first comes
into existence
... such that it's safe-centered into viewport
... from that point on, it's just abspos -- you scroll the
page, it scrolls off
... if you dismiss the dialog and regenerate, it will
recalculate its position
... interesting question is when do we clock thispoint in
time?
... Answer should be when animation starts
iank_: Another way to define is
in the DOM layer
... for the DIALOG element it could query what the layout is
and set the top directly via CSS
TabAtkins: Essentially built-in JS
iank_: We do this for other things
<tantek> is it not fixedpos? huh
iank_: It's not great, but might be simpler
<TabAtkins> nope, it scrolls if you scrol lthe page
emilio: My objection wrt when
boxes are created is that engines create boxes at different
times
... When you change the display value, Blink will reposition,
because it destroys the box and loses the state
TabAtkins: If you go from not
having boxes to having boxes, you reposition. Having boxes to
having boxes, you don't reposition
... Ian's description was also quite good, smfr what do you
think?
<inserted> scribenick: heycam
fantasai: to describe Ian's
suggestion, at the point the dialog is launched, the UA sets
the top/bottom/left/right to be an absolute position edges of
the viewport
... and then, we use the alignment properties to center it
within that area
... then you don't have to calculate the centering
... just use the inset properties to bring the abspos range to
match the current viewport range when the dialog is
launched
smfr: sounds like you're snapshotting the layout viewport
fantasai: you're assigning abspos inset properties so that you're creating a box that overlaps exactly the fixedpos containing block
smfr: wondering if it should be defined in terms of the layout viewport somehow
TabAtkins: the HTML spec does
require recalculating the position if the viewport changes
size
... guess that's still possible, it's just a ResizeObserver on
the window
smfr: another question is if the user zooms. same behavior as fixpos?
fantasai: as abspos, if the user wants to zoom in to see the dialog they should be able to
TabAtkins: don't want fixpos magic. abspos with magic setting at a particular time
fantasai: I think that this works
and is simpler than creating a new magic model with timing
implications
... question I have is, if you have a dialog that's inside one
of these containing block trapping elements, how do you get
this element to escape and become contained byt the containing
block
TabAtkins: that's answered by
top-layer
... in this mode it's always kicked into that
... do need to specify top layer rendering
fantasai: putting something there changes stacking context and containing block?
TabAtkins: yes
... abspos containing block becomes the root
fantasai: how does that interact with transforms or contain layout?
TabAtkins: layout containgment
should still be fine with escaping
... and transforms it changes its parent
... it's no longer transformed
iank_: yes. it's weird
fantasai: so it sounds like what we're doing is defining a way to put something into the top layer, out of the box tree, into this parallel box tree (list) where the containing block is the size of the entire page
TabAtkins: I think that's the
right thing
... think it's the whole page
heycam: interactions with full screen? they'll both be in the top layer
TabAtkins: we'll need to deal
with that
... separate but intersecting topics
smfr: top layers will stack
up
... if you have full screen and dialog
fantasai: what's the stacking order?
smfr: whichever's created
first
... but we need to define that
fantasai: it's not as much of a mess as fieldset/legend...
iank_: painting wise this is more interesting
smfr: part of me wonders if we
need to maintain compat with dialog layout. is this sensible
behavior in HTML? or should we define something different
... think only Chrome has shipped
TabAtkins: I've used dialogs in personal projects and enjoyed it
iank_: are we the only ones shipping it?
TabAtkins: I think so
iank_: I would be up for
potentially investigating what compat risk there is if there's
a more sane model that we think we can ship
... the compat thing will be the question
... Simon what caused you to start investigating this?
smfr: I was just looking at how
the implementation would work in WebKit
... and I dug into the Blink code and found a function deep
down
... in block layout
... didn't want to do the same thing
RESOLUTION: Define dialog in terms of top layer and a snapshotted abspos position and alignment property for centering
smfr: can we also resolve on
specifying top layer behavior in CSS somewhere?
... it needs to live along with paint order and z-index
... wherever CSS 2.2 Appendix E will go
fantasai: probably CSS Position?
smfr: or a new spec
... I feel like a paint order spec is probably necessary
dbaron: I think we need a spec
for a bunch of rendering stuff, including common
terminology
... if you remember the big table of horrible test cases for
stacking contexts, etc., we need a spec to cover that
fantasai: so new spec for the painting order
<tantek_> perhaps that could include hit-testing which is directly related to stacking order etc.
dbaron: CSS Rendering Model or CSS Painting Model?
<tantek_> more than just painting, the stacking order affects hit-testing
<fantasai> scribenick: fantasai
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4680
smfr: Running into some issues with how nesting scrolling works, and differences between browsers
[display fragments into weird pieces]
smfr: I look example showing when the events are received
<tantek_> me more Mondrian than Picasso TBH
<bkardell_> https://codepen.io/smfr/pen/RwNvVPj
<bkardell_> ^^^
<smfr> https://codepen.io/smfr/full/rQZqxo
smfr: First question is, if your
pointer is over the border of the element
... and you initiate scrolling
... do you scroll that element's overflow region?
... in WebKit, yes
... in Firefox, answer is yes
... in Chrome, answer is no
... My pointer over the border of the element, I scroll the
main page in Chrome
... Difference #1
... Other interesting thing about Chrome, notice the element is
still receiving wheel events
... even though I'm not scrolling it
... so disconnect between when an element receives scroll
events and when it actually gets scrolled
... I think it's reasonable that browsers may have assumed that
users only want to scroll when the mouse is actually in the
content
<bkardell_> what about :hover - does it work on the border?
smfr: Things also get interesting when you start nesting scrollers
bkardell_, yes
smfr: Now, same thing, parent
scroller here
... it has two descendant elements, but those elements are
absolutely-positioned, and the scroller is not their containing
block
... when I scroll the left abspos, it's a DOM descendant of the
big scroller, and the big scroller receives wheel events becaue
of DOM propoagation
... but when I reach the end of the little scroller, the big
scroller does not scroll
... in WebKit and Chrome
... but in Firefox, the big scroller scrolls after I reach the
end of the little scroller
dbaron: That seems wrong to
me
... I would expect it to scroll the ancestor only if ...
smfr: Seems that scroll propagation should follow containing block containment
dbaron: I'm not sure
... If you have somehting with overflow: scroll
... I'll invent the term "containing block child", to descrie
it more as a tree for this discussion
... An element with overflow:scroll might have containing block
children that move when it scrolls, and containing block
children that don't move when it scrolls?
... or do they all move when it scrolls?
smfr: I think they all move when it scrolls
<heycam> fantasai: I think that's true since I don't know how you'd fix the element to any scroll port other than that viewport's
dbaron: Concerned about
sticky
... or abspos
... maybe containing-block-ness is right
... I would expect scrolling to propogate the scrolling up to
the next thing that would cause the thing where your mouse is
to move
smfr: I think that makes sense
dbaron: This might be something Mats has an opinion about
emilio: Following regular box order is more similar to what the events do
smfr: Prolem with that is that it's easy to construct content where you might mask scroll ... end up scrolling something unrelated on the page just because it happens to be in the DOM parentage
dbaron: with DOM events you also have the ability to look at what the event target is
fantasai: Do we want to resolve the question about borders first? Seems simper.
smfr: Which do people prefer?
dbaron: I was surprised when you showed me what Firefox does
heycam: the border should move if I'm hovering over it and try to scroll
iank_: I think that's why we have this behavior
AmeliaBR: From the DOM
perspective, seems reasonable that event going to element
should cause it to scroll
... maybe from user perpective preferred behavior is
different
... but if doing it that way, maybe give script some
affordances to figure out what's happening
... because right now would have to evaluate the coords against
layout and stuff
... I think it's weird to have the default behavior that we
cannot recreate with script, if you want to do something else
in response to wheel events
iank_: Subtracting borders from the rectangle, lots of libraries for these types of calculations
<heycam> fantasai: I don't think it's that weird from a user perspective for it to scroll
<heycam> ... for a similar reason, if hovering over the scrollbar, it scrolled
<heycam> ... the scrollbar doesn't move
<heycam> fantasai: the thumb does but the scrollbar itself doesn't
<heycam> ... I'm not convinced frmo a user perspective it's that terrible for the element's contents to scroll when hovered over the border
<heycam> smfr: if you were interacting through touch rather than pointer would you have the same opinion
<heycam> ... with touch users have an expectation that the thing under the finger moves
<heycam> ... I think it's less obvious then that you want to scroll the content rather than everything else
<heycam> fantasai: it's less obvious, but unless the border was absolutely huge, I probably wouldn't be surprised or notice
astearns: Not hearing much consensus
<heycam> smfr: I would prefer that you only scroll when you're in the scrollable part of the content
smfr: I would prefer you only scroll over the scrollable part of the conent, withint he padding box
astearns: I think it's a little weird to scroll when your cursor is over the right border, which is outside the scrollbar itself, but top / left / bottom seems fine to me. So I'm mixed.
iank_: From our perpective, I don't have full back story, but I'm guessing that someone did this for a good reason at some point
smfr: I think you inherited it from WebKit
iank_: We've changed a lot of stuff in this area
astearns: thought webkit does scroll over the border area and Blink does not
iank_: Right, I expect somebody intentionally made the change
smfr: Not sure we need to resolve
now, but one thing I would like maybe to resolve on is that
there isn't a simple relationship between an element receiving
a wheel event and scrolling happening in that element
... both because of the border issue and also the containing
block issue
astearns: We could resolve on that, but then without the pariculars, not sure what use that resolution is
smfr: maybe that's not something to resolve on, but something to use as basis for future discussions
iank_: Sounded like smfr you
preferred our behavior?
... Sounded like dbaron and heycam, you also did?
heycam: I think so. I don't feel super strongly about it
astearns: OK, then let's try to resolve that when the cursor is over the border area, mousewheel events will not scroll the content area. Anyone object?
fantasai: I don't feel strongly about it
RESOLUTION: Over the border area, doesn't scroll the content area
astearns: second part
... has the border case and also the content area case
iank_: ...
smfr: I've seen some odd behaviors where sometimes scrolling over the border of an abspos child causes its parent that's not in the containing block chain to scroll....
bkardell_: Should any child, if
you're on the border, you're technically inside
... you're on the border, does it scroll the parent?
iank_: I can try and rationalize
what potentially happens
... wheel events get delivered even when the element isn't
scrolling, to the element directly under the pointer, and they
bubble up
... you can create applications which don't necessarily scroll,
but they do intercept wheel events
... following that logic, makes sense to still deliver wheel
events on the border box
smfr: I think so
... Nothing I've said is about propoagating wheel events. The
should follow normal DOM propagation and hit-testing rules
iank_: So your concern is mainly around abspos
smfr: My concern was that when
use rinteraction with mouse wheel events triggers scrolling,
disassociated with DOM wheel events, and different between
browsers
... would like it to be more specified
... User interface aspect of when /how scrolls propagate,
somewhat ndependent of event propagation
iank_: so concern is hwere the actual scroll propoagates to an dwhen
smfr: I think there's nothing to change about how wheel events change, nothing to do there.
astearns: so proposed resolution would be that actual scrolling behavior only propagates through the DOM tree if the pointer is over the content area of the scroller, is that correct?
smfr: I think it has to be
described in terms of conaining block
... assuming dbaron consideres gecko behavior a bug, with ...
once you reach the end of the ...
<AmeliaBR> astearns version makes the most sense to me. The event propagates, but the scroll container checks the mouse position before actually scrolling or propagating further.
smfr: ONe thing that does not
happen, you don't do a deep hit test, and find some ancestor
becuase it happens to be under the mouse cursor, but covered by
something else
... you find the most descendant scroller, then ancestors
scroll depending on whether in the ancestor containing block
chain
... For example, my testcase has the righthand element, which
is not scrollable
<AmeliaBR> But what happens if the element that gets the event *isn't* a decendent of the scroller that is behind it…
smfr: if my mouse is over this
half of it, scrolling will scroll he page.
...
... webkit has bugs because some parts uses conaining block
chain, and some parts uses DOM ancestry, and when they don't
match you get bugs
astearns: summarize proposed resolution?
smfr: Scroll propagation between nested overflow: scroll propagates through containing block chain
iank_: potential nasties
... scrolling the left box, and cursor for brief amount of time
is over the big scroller
... and we currently don't scroll that, if that makes sense
smfr: Talking about latching,
decide which element is scrolling at the beginning
... not scrolling other things even though mouse has
moved
... next gesture, choose the thing to scroll again
https://www.w3.org/TR/css-display-3/#containing-block-chain
iank_: right
smfr: So that's another thing that's completely unspecified, and maybe there should be some words in the spec about it
astearns: So proposed resolution is that scroll behavior propagates through the containing block chain
iank_: I think that's fine, I think that's what our current impl does
astearns: Concerns from other
implementers?
... Alright, now objections? Anyone want to object?
RESOLUTION: So proposed resolution is that scroll behavior propagates through the containing block chain
ACTION smfr File open issue against latching behavior
smfr: Does this go into cssom-view or what?
heycam: Seems like most relevant spec
<inserted> emilio: maybe css-overflow?
<heycam> fantasai: overflow doesn't do anything with events. cssom view has some scrolling stuff, some scroll apis
<heycam> ... don't know what extent it really fits in with either, but would go with CSSOM since it's talking about DOM stuff
astearns: OK, we'll put in
cssom-view. Which doesn't have an editor.
... smfr can I add you as editor?
RESOLUTION: Add these rules to cssom-view, add smfr as editor
heycam: Another question, which
element's pointer-events values do we look at to decide if it's
going to scroll or not?
... especially wrt looking at ancestors to see what to
scroll
smfr: I think we evaluate
pointer-events when we do the hit testing, so only when finding
the element to scroll
... unsure about abspos and stuff
astearns: Good question, maybe open an issue?
heycam nods
astearns: Anything more on scrolling today?
smfr: That's all I have
astearns: Thanks for calling
in
... Let's go through Motion issues, because we have Amelia on
the line
<myles> ScribeNick: myles
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3468
AmeliaBR: for the various
properties that use shape(), some only care about the outline
of the shape. Others care about the actual fill area of the
shape
... So for motion-path, you only care about the outline, but
for clip-path, you care about which parts are inside and
outside. This is an issue when you have polygons or paths with
cris-crossing lines and inside/outside isn't so clear
... Enter fill-rule. even-odd and nonzero.
... It was originally defined as polygon(keyword, ...)
... path() was defined in motion-path, and didn't include the
keyword
... Things get complicated with <path> because this had 2
separate properties for the fill rule. Filling vs what's the
effect when it's in a clip-path.
... How do we deal with this conflict between having a keyword
as part of the shape function vs having a separate property
which doesn't make sense for <clipPath>
... I came up with a couple options. The one that seemed to
have people most support is that the keyword within the shape
function includes "auto" as the default, and the default would
look up the other SVG properties. But if you set the value
otherwise, it would override the old SVG properties and we
maybe eventually deprecate the SVG properties.
... If you specify a fill-rule keyword in motion-path, it's
ignored, but that's not a problem. The only place where it's a
problem with <shape> where it gets filled. We're
specifying where if you set a fill rule in the function, it
overrules the fill-rule property.
... The default behavior is defined in all other cases to match
the current behavior.
heycam: I like that. I'm not sure we need an explicit "auto" as opposed to just its absence.
TabAtkins: We do, for ... some
case. There is a case related to <path>
... If path() takes a keyword, where the winding rule is
determined by context, you need to be able to say "go grab from
the other property explicitly"
<fantasai> +1 to heycam
heycam: This is a component of one value, and it's optional, can we just use its optionality?
AmeliaBR: So the auto behavior is the "no keyword specified" behavior
TabAtkins: That would work. It just runs into my dislike of having omitted values being unwritable
heycam: There are a lot of properties that have optional keywords
fantasai: <lists them>
TabAtkins: Most of them are
booleans, but when more than one value tetchy
... I won't fight it
AmeliaBR: The benefit of heycam's approach is that shipping for shapes in clip-path and shape-outside, we don't need to change anything, because the change would only come in paths where the author behavior is different from the current default behavior
heycam: Are their other elements other than <path> where we might want to have a default value that's not "go and look at the fill-rule property"?
AmeliaBR: All the other cases the default value will be to just use one of the existing keywords.
TabAtkins: even-odd is the default
heycam: There's no value in adding an explicit auto keyword to say "look at the fill-rule property" for these other cases?
TabAtkins: Those other cases don't have a property.
AmeliaBR: It wouldn't make sense to have a div with both a clip-path and a shape-outside and also set a fill-rule in another property. That would be confusing
TabAtkins: There's only the two
things that have the information defined by another property,
and there isn't a use case to have arbitrary things rely on
those two, it's just due to SVG's existing behavior to rely on
those two
... and that's it.
astearns: The proposed resolution is to make this an optional keyword with just the two values, and default to even-odd or "lookup depending on context"
AmeliaBR: Withing the context of d= then not specifying the keyword would the the SVG legacy beahvior. Specifying the keyword behavior would mean "ignore the fill-rule and clip-rule properties"
astearns: Any objections?
RESOLUTION: make an optional keyword with just the two values, and default to even-odd or "lookup depending on context"
<astearns> github: https://github.com/w3c/fxtf-drafts/issues/369
TabAtkins: There's not actually a
definition of what containing box to use for ray(). It just
says "the containing box" and that's not a term. It doesn't
mean any thing. So what's the box? So we know how long the ray
is. Where the 100% point is. There's a few possibilities
... We could just choose one. Maybe the containing block of the
abspos. Or we can alter the grammar of the property a bit to
have its containing box specified like how shape() does
... If we did so, we would be referring to the box of the
parent element, not the box of the element being
motion-pathed
chris: i prefer the second one
TabAtkins: me too
AmeliaBR: Would this also affect other ways of defining the path? So the path shape would also be repositioned to be relative to the containing block instead of relative to the initial position of the element that you're actually moving?
TabAtkins: Yes. That's what ewilligers is suggesting. URLs, rays, and paths also gain the ability to have an optional box
AmeliaBR: Is this a breaking change?
TabAtkins: Shapes already have this, that's part of the grammar. For paths, we can choose the default appropriately so paths don't change behavior. Whatever value that is, ray() should work the same way. IDR which value that is.
AmeliaBR: How does that apply to
SVG if we're going up to the parent element
... Are we going to the literal parent element like <g>?
Or relative to the view box?
heycam: Does this come back to the previous discussion about the box keyword that we moved into a different spec?
TabAtkins: We've already altered this spec for using the box keyword
heycam: So that should define how this works for SVG
AmeliaBR: It might not be the most intuitive if the parent is <g> then the fill-box of that group might be a bit weird. But if we define it early before there's too much content using these properties ...
heycam: Was ray() added for rounded display?
TabAtkins: yes
heycam: If we have control over what box, then that satisfies that use case?
TabAtkins: I believe so.
astearns: Do we have a way forward here?
heycam: It feels slightly overkill having these keywords everywhere, but it's okay.
TabAtkins: My own objection to that is that they're all the same, shapes and paths and rays are all the same. I would like CSS to do it consistently right from the start
heycam: If you can specify the box in some, then it should be all...
<fantasai> +1
TabAtkins: Yeah.
astearns: Proposed resolution:
All of the offset-path values allow a coordinate box, treated
the same as today's basic shape (which I know is
under-defined)
... It is well-defined, it's just in a weird part of the spec,
i will fix)
RESOLUTION: All of the offset-path values allow a coordinate box, treated the same as today's basic shape
TabAtkins: shane is no longer part of CSSWG, can I replace him as an editor?
astearns: Will you actually be able to spend time on it?
TabAtkins: I'd like to fix it up. I can spend more than 0 time.
astearns: okay
RESOLUTION: move shane to former editors, add TabAtkins as a current editor
<fantasai> ScribeNick: fantasai
<astearns> github: https://github.com/w3c/csswg-drafts/issues/4108
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/4108
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4108
TabAtkins: When I originally
drafted the font-display values, the last one, optional, I
intended to be as much as possible "make the user's experience
smooth even if they don't get pretty fonts"
... Wasn't super clear in the spec, and implementers came up
with answers that don't satisfy that goal
... Within first 100ms or less, still creates a layout
jump
... Jake was running into the same problem
... wanted smooth page display without any layout jank, and
wasn't getting it
... I believe the current text addresses it, perhaps with an
extra comment
... Would like some discussion from y'all
<TabAtkins> https://drafts.csswg.org/css-fonts-4/#valdef-font-face-font-display-optional
TabAtkins: My text atm, if font
can be loaded "immediately", can be used, otherwise ignore
it
... can't be used for the rest of the page's lifetime. Refresh
page, can try again
... Paried with some additional info
... MUSTNOT cause the layout of the page to jump
... allowed to delay initial rendering if needed to load the
font
... specifically, we have some issues wrt how to do in Chrome,
can put more detail in the spec
... Anyone have comments on details?
... If in memory cache for tab, use the font. Otherwise we go
to disk, takes too long, skip it
... Once loaded, may ro may not be present for future
navigation depending on cache state
... Cannot depend on font ever being there
... Want to make sure that all font pre-loads bring the font
into the memcache
... track which fonts are there
... When preloaded font is optional, delay loading to give time
to get off disk -- or extremely fastnetwork
... otherwise, don't delay
... If you don't do anything special on your page, just say
font is optional
... almost guaranteed to not have font on first page load
... chance of available on future page loads, but not
guaranteeed, e.g. if on device with small memory
... If it's a preloaded font, then very likely to be load on
future navigations because we will delay rendering to load into
memory cache
... because preloading is a hin that something is important
enough to kick of load asap
... That seems to satisfy the use cases for optional that we
want to hit
... allowing pl to have completely jank-free font-optional
experience
... Try your best to use it, but prioritize no jank
heycam: not sure how much is
normative vs heuristics
... but seems a bit weird to me that you have two different
behaviors wrt disk cache
... without preloaded fonts, disk cache is deemed too slow, but
link rel=preload it's ok?
TabAtkins: Not so much it's too slow, but don't want to incur cost of delaying rendering unless indication that it's important to you
heycam: is this because checking whether the font is in the disk cache is also slow? is it the checking, not the loading?
TabAtkins: in our implementation, memcache check is fast enough to be synchronous, whereas disk cache is async, we kick off without loading
heycam: disk cache can be very fast when it's not too big
TabAtkins: definitely cool to
keep things vague enough that UAs can adjust
... but want preload to cause delay
heycam: Other thing I was going to say is I'm not really a big fan of optional
myles: I have a lot to say so
split into pieces
... Firstly, wnat to make sure it's clear that WebKit will
never ever defer first load. So that has to be not a case.
that's our philosophy
... Can you be super clear about which, you listed like 3 main
pieces
... one is deleted number 100ms and replaced with words
... one is never cause layout jank
... last one was about preloading
... which are normative
TabAtkins: first two are
normative, in the spec
... third one I would like to put in the spec
myles: The spec shouldn't use
words mem cache and disk cache, those are impl details
... still not guaranteed to get the font even if preload
... there's nothing testable here
... So I think this should be evangelism, not in a spec
... "for our browser, you will get better results if you
preload"
TabAtkins: Talking to internal
customers who want no jank on initial load
... if they don't get it, and instead block loading page,
that's a worse user experience
... so having some reasonable assurance of similar behavior
among browsers would be worthwhile
... ultimately stochastic, cna't depend on it, but difference
between 80% and 10%
myles: Are your internal customers only considering Chrome, or also other browsers?
[unminuted]
myles: Other piece I want to
mention, dbaron brought up a super valuable point
... I think it supports what heycam said as is last
sentence
dbaron: One of my concerns with
this is that a lot of stuff around downloadable fonts is
designed to deal with the possibility that you have a pretty
large number of faces for various reasons
... You might have fonts egmented by character range, multiple
weights 4-6 of them, a lot of the mechanisms around
downloadable fonts were designed to load lazily
... define a library, fetch the ones you need
... so some of this pre-loading stuff...
... there are cases where you just use one font
... those cases probably bias towards symbol font hacks, and
text that is all Latin
... and maybe things are more complicated in non-Latin
languages, or things that use more weghts and stuff like
that
... one of my big concerns about font-display is that it is
per-face
... can have situation where your regular font cached and bold
font isn't
... and using downloadable font permanently for regular weight
and local font for bold might be worse than all of the other
cases (including flashing, or fallback for all the fonts)
TabAtkins: Those can still totally happen is the font load just doesn't occur
dbaron: if you have network failures can happen
myles: optional makes it more likely that it fails
<myles> q_
fremy: As an author, at this
point, with current proposal for optional, I would be very
unlikely to use it. Because more likely to not get your font
than to get it
... why bother?
... Only if user keeps using your site regularly, not going to
be in memory
... not unless constantly in use
myles: no, it's valuable for web sites while you're navigating through mutiple pages on the site
TabAtkins: won't work on single-page app, don't use it in one
fremy: You're extremely unlikely to get the font, then why bother? You are going to download the font anyway.
TabAtkins: Your case is a
single-page app that gets closed and reopneed every day
... preload signal intention is that, if it's still in your
disk cache, it will likely get used the 2nd day and subsequent
days, because giving it enough time fo rthat
fremy: Safari said they don't want to block rendering
myles: Internal clients care that
usage gets up to 80%, but we're absolutely not going to block
rendering
... That's not going to work in Safari
TabAtkins: assuming ppl aren't using optional, then comfortable with janky 2 frames and then stable layout
myles: I'm OK with you've shown the page with fallback font then never show the page with loaded fonts
TabAtkins: ...
... If it's likely that optional will never give them assurance
to see font, then they'll use JS to delay rendering
manually
... or will use one of the values that wll cause jank
anyway
myles: This is an intractable
problem. We can't never delay rendering and have the disk cache
be able to serve tehse requests
... given that these customers will never get what they're
aiming for, I don't think that the association with preloading
makes sense
TabAtkins: Want to check
understanding
... website authors using fallback, getting a couple frames in
one font and then frames in other font, it's better than
getting a few frames of nothing and then getting the page?
AmeliaBR: I've heard a lot of
confusion of what's the purpose of this value
... Tab said the goal was to avoid jank
... If that's the goal then maybe other smarter ways this can
happen, like waiting until doing a major repaint anywan and
then block in the font
... catches the single-page app update situation
... but I don't kno if that's the best
... As a user, the idea of downloading fonts but then not using
them unless I happen to close the page and re=-open it before
it gets lost from the cache, that's not a great use of my data
plan
TabAtkins: UA is allowed to skip downloading if it thinks that's reasonable in the circumstances, and metered data is definitely such a circumstance.
astearns: Done for today
Meeting closed.
<cbiesinger> github-bot: end topic
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/timeless/faceless/ Succeeded: s/convinceable/convinceable, and Jen if she's allows/ Succeeded: i/fantasai: in the block axis, by saying/ScribeNick: heycam Succeeded: s/close this/close the discussion today/ Succeeded: s/favor of math/favor of math if you ask them about a basic computation/ FAILED: s/spe referring/specs referring/ Succeeded: s/spec referring/specs referring/ Succeeded: s/and a lot/but a lot/ Succeeded: s/keep editing it/keep editing that feature/ Succeeded: s/4619/4691/ Succeeded: s/non-// Succeeded: s/guessing/guessing how wide they are/ Succeeded: s/benefit/benefit to readers/ Succeeded: s/we'd rather do that now/i'd rather spare you the work and chop them now/ Succeeded: s/explainers should/specs should/ Succeeded: s/cases/cases described/ Succeeded: s/the reasoning/the record/ Succeeded: s/TabAtkins:/TabAtkins,/ Succeeded: s/??/.insertRule()/ Succeeded: s/appendment/append method/ Succeeded: s/.../ but I mentioned append because I suspect that's what more people would do/ Succeeded: s/not/no/ Succeeded: s/has/just said he has/ FAILED: s/authors followed/followed/ Succeeded: s/people/browser implementers/ Succeeded: s/word/work/ Succeeded: s/word/work/ Succeeded: s/florian/fantasai/ Succeeded: s/if we don't meet criteria we shouldn't add, if we meet it we *may* add/if we meet the criteria, should add; if we don't, we may add/ Succeeded: s/can/can't/ Succeeded: s/gives back percent/gives back L in 0 to 100 range and no percent/ Succeeded: s/imp/simp/ Succeeded: i/fantasai: to describe Ian/scribenick: heycam Succeeded: s/in block rendering/in block layout/ Succeeded: s/.../I think it's reasonable that browsers may have assumed that users only want to scroll when the mouse is actually in the content/ Succeeded: s/Firefox/Chrome/ Succeeded: s/dbaron/smfr/ Succeeded: s/element/viewport/ Succeeded: s/aout/about/ Succeeded: s/it/is/ Succeeded: i/fantasai/emilio: maybe css-overflow? Succeeded: s/pointer/pointer-events/ Succeeded: s/touchy/tetchy/ Succeeded: s/I get/Most of them are booleans, but when more than one value/ Succeeded: s/the default/all/ Succeeded: s/small cache/small memory/ Succeeded: s/other cases/other cases (including flashing, or fallback for all the fonts)/ Succeeded: s/thn/then/ Default Present: (no_one) Present: (no_one) bkardell_ rachelandrew cbiesinger stantonm skk dbaron heycam Rossen__ jensimmons hober fremy jfkthame faceless2 iank_ emilio florian rego TabAtkins oriol fantasai myles chris + tantek Found ScribeNick: TabAtkins Found ScribeNick: fantasai WARNING: No scribe lines found matching ScribeNick pattern: <fantasai> ... Found ScribeNick: TabAtkins Found ScribeNick: fantasai Found ScribeNick: heycam Found ScribeNick: fantasai Found ScribeNick: TabAtkins Found ScribeNick: emilio Found ScribeNick: TabAtkins Found ScribeNick: fantasai Found ScribeNick: stantonm Found ScribeNick: fantasai Found ScribeNick: heycam Found ScribeNick: fantasai Found ScribeNick: myles Found ScribeNick: fantasai Inferring Scribes: TabAtkins, fantasai, heycam, emilio, stantonm, myles Scribes: TabAtkins, fantasai, heycam, emilio, stantonm, myles ScribeNicks: TabAtkins, fantasai, heycam, emilio, stantonm, myles WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: heycam hober tabatkins WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]
