Layout Team Meeting Notes (Austin, Texas - 2017/12/15)
Happy New Year! The following are notes from Layout Discussions at a F2F
meeting in Austin, Texas on 2017/12/15. Many thanks to fantasai and heycam
These are unofficial notes from an informal discussion.
They do not constitute an intent-to-implement.
They are not a commitment going forward.
They are not publishable quality and might not make much sense.
We're posting them to share Layout Team's yallhands discussions
with the rest of the Gecko Layout / Mozilla community.
---------- Forwarded message ----------
From: fantasai <[hidden email]>
Date: Sun, Dec 17, 2017 at 8:28 AM
Subject: DRAFT Layout Team Austin Notes
To: Jet Villegas <[hidden email]>
What short term follow-ups from stylo to improve existing code
- generating style structs from rust definitions
- remove duplication from C++
- code size reduction (emilio/manish)
- stylo-chrome bugs
Parallel frame construction (bobby/bz in Q2/Q3, depends on C++ style system
- pcwalton gave a overview of bottom-up frame construction
- not much to problematic, seems feasible
- will likely not share code with servo
- open question: unclear if it will work as servo envisioned
- what is the ideal handling of parallel layout?
---> mbrubeck / pcwalton will experiment
- figure out floats
- grid/flexbox - find someone else to experiment here
Difficult to plunk in all of servo code into Firefox
- current Layout code in Servo doesn't work correctly
- floats are very problematic
- maybe worth investigating BFC-level parallelism
- try to sort that out
- Servo Layout is still missing a LOT of features in Gecko
- missing properties
- Style System LOC Gecko 150K Stylo 100K
- Layout LOC Gecko 400-500K Servo 15-25K
- parallelize Layout coming across the other way
-- e.g., intrinsic sizing in parallel
-- e.g., text shaping/measurement voa harfbuzz ( need to measure how good
that is )
--- harfbuzz currently used on all Gecko platforms but not for all fonts
- concurrent Layout
-- layout on its own thread outside script
-- not sure if that's a win (e.g., when script asks for Layout,
- large amount of work
- pagination is different
- enter/exit reflow are different
- are we using Servo reflow or different?
- nsBlockFrame in Rust?
-- but behave like Gecko?
-- maybe not the best place to start, we may end up building the same thing
we already have (but in Rust.)
- protocol setup state to reflow other frames
- dealing with inputs, then outputs
- doesn't magically go away with a Rust rewrite
- probably could make it a fcus for perf, but different for Parallel layout
- also simple cases when it's not parallelizable
- parallel process across lines, might have to be sequential anyway
How much do we want to investigate text run creation in parallel
if we don't know what Layout will look like.
Measure memory bandwidth vs. CPU before parallelizing.
You can parallelize smaller chunks (e.g., header, sidebar, main text.)
- or parallelize Grid and Flexbox elements
- Grid layout and semantics
- Parallelize across things that don't interact with each other
Is it OK if a bunch of unsafe code has to run in parallel?
- measure elapsed times for layout calculation vs. setup for frames, etc.
- setting up the inputs and calling functions is a significant part of the
- e.g., 70 functions to compute an unneeded value is wasteful
- reflowInput setup takes a long time
- WebKit has different setup (lower cost from function calls)
- When need to figure out what's the architecture.
- how would you structure?
- side effects for measuring reflows?
- use what IE does? separate tracking of sizes and dirty states?
- WebKit has overrides for frame properties for intrinsic sizes
- can use similar architecture (parallelized)
Static Analysis for Stylo?
- can we catch Containment at the S.A. stage?
How does parallelization affect fragmentation?
- what is the right way to do fragmentation?
- Houdini Layout APIs have breaking/fragmentation
- leaning towards what Blink does vs. Gecko -- i.e., it's not great.
- variable size fragmentainers
- Hard to figure out in Fragmentation what invariants it's supposed to keep.
--> 6 or 7 regressions from recent changes
--> which one of the things was wrong?
--> most fragmentation code assumes no incremental reflow
- How does it actually behave in Gecko?
- Need a solid understanding on how fragmentation is supposed to work
- Some code assumes there's only one nsBlockFrame to represent a box
- widows/orphans + page-break-* depends on that
- reimplement over nsReflowStatus
Fragmenting Grid/Flex/Table where heights are interdependent among siblings.
- fragmentation changes the height of the auto height of a box
which affects things before/after it (hard part)
- untangle assumptions that different fragments have the same width across
-- if you specify different margins across different pages, that can happen
- can have boxes with different widths across pages
- tables that spread across EM widths
- defined in Fragmentation spec
- intrinsic sizes(min. max) are calculated as a constant across pages
- using a shrink-to-fit formula combines these effects
Patrick/Matt should consider Fragmentation in their design.
- roc was encouraging that. We should too.
- 1. normative requirements
- 2. perf optimizations
- should do both
jet: Want to get someone to describe current state of feature,
where the spec is and where our code is
jet: and then build out to-do list and milestones, potential release
jet: State of feature? mattwoodrow?
mattwoodrow: Start with Paint. Feeling stable, Google is ready to ship,
not yet but soon.
mattwoodrow: So we should make an impl so we can give feedback before
they lock in
emilio: They sent intent to ship
dbaron: They might claim it's frozen once they ship
emilio: Does the spec have a way to draw text? That's one of the hardest
mattwoodrow: It's subset of canvas2D API
jet: Spec for paint has invalidation model, describes paint worklet,
describes how to register worklet, and diff btw 2D canvas and
Houdini Paint APIs
jet: You're feeling is that all of those are stable?
fantasai: IIRC they were gonna request CR soon, since they think they're
with the spec mostly
jet: Typed OM?
mattwoodrow: Register a worklet when browser wants to paint an element,
and you can pass info to it via properties
mattwoodrow: computed values of properties new worklet function
mattwoodrow: You get pretty much canvas 2D API, can use values of the
to draw whatever you want
jet: typed OM, can only use typed?
dholbert: Interaction with typedOM is to make it easier/faster to read the
dbaron: Other point of canvas, is it's canvas 2D API, but designed to be
of API that doesn't have to be backed by a bitmap
mattwoodrow: You can record drawing commands, do whatever you want with
jet: Spec as designed, we thought it can be subset of canvas2D API, you
rectangle, can do whatever you want with that rectangle. Don't get
intrinsic sizes outside that rectangle
jet: Is that still true?
[didn't hear response]
jet: We stubbed out JS API API for the paint api
mattwoodrow: I don't think that landed, though
jet: so that needs review then landing
mattwoodrow: Basically splitting canvas code so we can extract subset
that we need
jet: So properties and values in Typed OM is perf optimization?
mattwoodrow: custom properties if you want custom drawing, most of the
are custom properties that feed into drawing
dholbert: custom properties provides the arguments for your drawing
heycam: Can you use unregistered properties?
dholbert: That would be strings, so slower...
dholbert: not sure
mattwoodrow: worklet doesn't get access to global
Properties and Values API
jet: Properties and Values impl?
dholbert: We have a patch stack in servo/servo from an intern jonathan
from the summer
dholbert: Ready for review at the end of the summer, works for servo and
for stylo Firefox
dholbert: Emilio gave a bunch of review feedback, and then jonathan had
and hasn't got back to that yet. Don't know if he will or not
fantasai: Now would be a good time to ask, since finals are wrapping up.
dbaron: If not landed by January, someone else should pick it up.
heycam: wrt paint API, argument passed in property values is a style map,
which was one of the new typed OM objects
dholbert: So paint API depends on the typed OM stuff
heycam: we don't have any typed OM impl yet
jet: Can we get away with just implementing styleMap?
fantasai: point of typedOM is to have structured values, not strings,
for property values, styleMap would be using that. So you're
basically pulling it all in that way
jet: Should we do this within layout team or ask DOM for help?
jet: I don't have a sense for how much work it is
heycam: I think it's pretty self-contained, could be done here without
help from DOM team
heycam: Might be some IDL things needed but...
dbaron: I suspect it's a decent amount of work, but not conceptually
dbaron: Just lots of interfaces and deal with lots of pieces
jet: Ok, but haven't started yet, so need a name for that.
jet: So Worklets.
jet: Where are we with worklets in general, and use cases?
baku: Not too much, 2016 I landed a bunch of code that implements a
of worklet, so possible to create a worklet.
baku: currently runs on main thread only, doesn't really do anything atm
baku: I spoke with web audio team, they want to use worklet for similar
things... want a web audio worklet to execute JS in the audio
baku: but is done
baku: main problem is, do we want to have something that runs out of main
thread or no?
baku: Not DOM interface, but code inside the worklet
baku: Introduces some problems with garbage collector and so on
heycam: You're asking whether we'd want to ship custom paint just on the
mattwoodrow: I don't think we need to run off the main thread at this
baku: That makes everything extremely simple.
mattwoodrow: Long term would be nice
baku: Try to avoid implementing worklet logic twice, so good to work
together with web audio team
baku: avoid creating something and then revising later because web audio
needs to do something else
baku: but otherwise, ok
jet: So before getting too far into missing pieces of impl
jet: Can anyone comment on the programming model of houdini custom paint
as a good thing?
jet: Google ppl think it's the bestest thing
jet: but should this be the way to do custom painting on the Web?
mattwoodrow: I would like to see more hard examples from Google and in the
Houdini spec, there's a few example of simple things
mattwoodrow: to see how useful it is for solving hard problems
mattwoodrow: not choosing pixel access
mattwoodrow: record paint and then paint later, hard to evaluate whether
it's a good tradeoff
mattwoodrow: guess we just need to wait and see what authors do with it
heycam: if that would be one potential limitation, design could be
heycam: Anything in the design atm that would be a red flag?
mattwoodrow: I think it can be extended later if needed
jet: Different q
jet: one main reason I was more supportive of work on houdini, was the
that they'll deploy on youtube or gmail and we'll have to implement
jet: have we seen houdini in their properties?
fantasai: Haven't shipped yet, so they can't
tantek: Haven't seen anything public yet
tantek: To answer about complex examples, they've informally shared
tantek: from google docs and other google properties.
tantek: They have a lot of JS to make that work, and Houdini is a piece of
making that more performant by pushing more work into the
tantek: They clearly want something like this, and are trying to not make
tantek: They want to give their property dev tools to make more
dholbert: complex example comes to mind is one Google material design,
paint fills a button from the click point (animated)
dholbert: That would be easy to create with CSS paint, harder to do with
canvas underneath a transparent button
dholbert: Would also degrade gracefully, but would look material design
tantek: They shipped web components on youtube, and it's faster on Chrome
because they don't have to polyfill
jet: When Matt and I talked about doing rendering on this in the past,
correct if wrong, you were thinking we'd create display list objects
in the same web flow we have
jet: rather than canvas 2D context somewhere
mattwoodrow: Both, really.
mattwoodrow: custom paint element, and then display it, call to JS to
canvas and call to JS to create worklet
jet: but no true canvas2D context with bitmap the size of the object
mattwoodrow: with OMTP, we'd do a moz2D recording
jet: maybe dbaron was talking about no bitmap storage
* fantasai falls behind
emilio: Are worklets guaranteed to produce the same output, given the
mattwoodrow: was discussion about storing some global state between
emilio: but that would ?
mattwoodrow: Worker can't get guarantee about which one it would get
mattwoodrow: try to stop authors from relying on state being maintained
mattwoodrow: not supposed to maintain state, but impl-wise it might
mattwoodrow: spec tries to make it unreliable
dholbert: global js objects are expensive to get rid of and recreate from
mattwoodrow: so don't want to recreate ever time
dholbert: so may or may not have variables left behind from last worklet
dholbert: you could produce unpredictable results
dholbert: by relying on it
dholbert: Google is intending to write code such they switch to a random
so authors can't depend on any particular behavior
dholbert: if everyone has something like that then prevent authors from
relying on it
dbaron: I think they were planning to switch between two, because cost of
new clean global would be high. But ideally, if it were fast,
a new one each time
jet: Let's write down the plan then
jet: Properties and Values, this needs landing
jet: Typed OM needs a full impl, spec review,
jet: Context2D, have an implementation that's a bit bitrotted, but needs
jet: Worklet hooks, we think we have what we need?
baku: I guess so
jet: What we don't have is enough typed OM to pass into the worklet
jet: Then there's actual paintng
jet: Last time we looked at this, before 57 train derailed it
jet: plan was to land context2D so that we can use Worklet and get enough
Painting going so that we can see if this will be quick enough
jet: performant enough that ppl would use it, or are there issues with our
jet: would GC kill reflow times? etc.
jet: That may still be the plan
mattwoodrow: we should be able to get at least initial numbers with that
dholbert: With different context2D API since we don't have typedOM?
jet: Stub out enough of API to do actual painting... if just a blue
don't know if you have perf
jet: who's doing these
mattwoodrow will do both context2D landing and the painting
jet: So Properties and Values, we'll try to get jonathan to land or else
up in January
jet: bz, did DOM discuss typedOM?
bz: Didn't come up this week in conversations
bz: need to figure out
jet: Seems we might be able to do it here, but don't want it to end up
into something like intersection observer
bz: I don't remember it having any deep interactions with DOM things.
bindings for it.
bz: Maybe some perf for some of it
bz: Way it's specced, would want to evaluate perf of some parts
bz: if that's an issue, nodelist access, we've spent time optimizing so
would be hard
bz: walking through lists are proxies, not that great
bz: until we have data showing it's a problem, wouldn't worry about it
bz: so needs webIDL work and stylo work
bz: Ideal world, copy webIDL from spec to tree and then boom
heycam: was wondering if it uses any esoteric webIDL
heycam: but doesn't seem to
jet: Would this be a good first bug for someone who hasn't worked on
emilio: What are you meant to be able to do with this API?
emilio: just get / set style values?
heycam: Yes, it's an alternative way to inspect declarations
dbaron: It can operate on both specified and computed styles (latter is
jet: Maybe premature to talk about milestones
bz: Debugging. Devtools around this stuff.
bz: Page has a layout worklet. Now what
heycam: How does debugging work in webkit?
bz: debug server runs on worker, and then client sends in ?
bz: It works the same as it works everywhere else
heycam: Would worklets be able to do it the same wya
baku: Wouldn't need complexity if we're on the main thread
baku: Connected with window, so should just work with a bit of log tools
bz: Not rocket science, but it'll be work
heycam: would we want more paint API-specific debugging tools?
jet adds devtool to the list:
P & V landing = jyc?
Typed OM tbd
bz: when you use JS debugger on script in a webpage, JS debugger spins a
event loop, suppresses event delivery, sends messages back and forth
bz: suppressing the messages is somewhat best effort
bz: you're running script, re-enter script, something happens not end of
bz: at point we're running the worklet code, not clear rest of browser is
with us spinning the event loop
bz: so for that reason might be useful to not be on the main thread,
might block the main thread
jet: Did that come up win audio?
baku: They also want to run off-thread
jet: Further investigation on that. But devtool discussion is bigger deal
bz: Yeah, was just thinking through... this is bad.
Tantek collected some potential work items on https://wiki.mozilla.org/CSS jet: looking at the list, we have CSS shapes, which will have a dev tool
jet: we have subgrid, which will have a design tool
jet: we have box alignment stuff
* fantasai really wants https://bugzilla.mozilla.org/s how_bug.cgi?id=1398482
fixed since this'll end up being an interop problem given
will are all shipping the new syntax
jet: scroll snap, this is a feature we implemented a while back, the spec
has changed a bit, we'll need to go back and fix it
jet: did we talk about a tool?
pbro: I remember filing a bug, don't know if a tool would be useful
jet: the next one is scrollbar styling
jet: this one is about a feature other browsers have, pretty highly
jet: does that need a dev tool?
dbaron: the existing style inspector should be enough
tantek: they'll see the changing color
jryans: you have to turn on some pref
devtools.show-anonymous-content or something
dbaron: if you're inspecting the element with the scrollbar, you'll see
tantek: this is the one that's a typography fidelity thing, where the
tantek: it's something that should look nicer by default, not sure if we
tools for that
jet: then there's CSS sizing 3
bz: I have a devtools comment on that stuff
bz: to figure out what's going on with CSS sizing, if you have a
thing, it'd be nice if there's a devtool to look at min/pref sizes
bz: even better if it told you why (more so for min)
bz: for min there's usually one thing forcing you to that width
bz: be nice to know what that is
jet: a visual tool?
bz: I have a box, would like to know what its min/pref sizes are
bz: and given the min size, I want to know what is the child that forces
min size upon me, so I can smite it
jryans: sounds related to the layout bug thing we've been thinking about
tantek: several of these could be addressed by layout debugger
tantek: if you're working on that already, this could just be another
jet: what's missing from our implementation of CSS Sizing 3?
fantasai: did we remove the -moz prefixes from the keywords?
dholbert: not yet
fantasai: we added the fit-content() functional notation [to the spec]
fantasai: we have that as a keyword, but not with the parens, that was
but it's not super critical
jet: can unprefix without it?
fantasai: CSSWG was resolved years ago to allow unprefixing of *-content
fantasai: one thing not marked as stable was what become stretch keyword,
that was pushed to L4
jet: we'd tried to implement paint containment
jet: paint or layout containing that we tried?
dbaron: I don't remmeber
dholbert: we had an intern try to implement all, but the spec changed as
and the patches weren't finished
jet: since then, I've not had someone asking for containment
dholbert: I think chrome is soon to ship it
dholbert: this is the sort of thing that web developers don't know they
but it's something we can offer them
dholbert: if they have certain slow layouts
harald: chrome is shipping it
harald: I commented on the bug that it'd be good for the perf of devtools
dholbert: it'd be rare if a site would break if we didn't implement it
dholbert: probably people are using it in a way that has graceful fallback
dholbert: I think it's straightforward enough that we should implement it
jet: if you know your layout constraints to this rectangle, you could do
parallel layout limited to that
jet: do we want to resurrect those old patches? or revisit this feature
dholbert: the current patches are mostly in the style system, which is
in the code we're about to remove
dholbert: so we'd have to rewrite in rust anyway
dholbert: I think the spec has changed a bit since then anyway
dholbert: the old patches will be a good reference, but we'd need to
jet: as far as containment, is it all or nothing to implement?
dbaron: I'd be hesitant not to implement all the 3/4 values at once
dbaron: the other piece of containment is that it's a prereq for other
like container queries, which are more highly demanded
dbaron: so I think that's a reason to pursue containment
dbaron: (and think about container queries while doing it)
jet: next, multicol
jet: we're doing column-span. what else do we need?
jet: some fragmentation features, it looks like?
jen: there's probably just bugs
jen: as the spec is cleaned up, we should see what we want to do about
jet: next is Fonts
jet: variable width fonts
jet: can we get away with just this subfeature?
jet: L4 currently has a bunch of stuff in there
dbaron: that's fine
dbaron: no need to implement all the features in L4 at once
tantek: it's cherry picking, but it's highly in demand from developers
jen: also in the minds of authors, the other things in the spec they don't
think of them as related to variable fonts
jet: is that common?
fantasai: yes, sometimes
fantasai: Some specs are one large integrated feature, like Grid. Others
collection of small bits, like Text. Others have one big
a pile of smaller things. (Like Fonts 4)
tantek: the N+1 spec is often a bucket, sometimes
jen: authors care about features, not about specs
jet: there's Values & Units 3
tantek: there's demand for calc() in attr()
jet: are we the last one in the game to that one?
birtles: we have some web compat issues with calc(), we don't do it in SVG
birtles: some sites don't look right
dholbert: re attr(), caniuse says nobody implements it
jen: I think Chrome is working on it
jen: they've been punting for a while, but now looking at it
<dholbert> Chrome is not currently working on implementing attr(),
per last few comments on
https://bugs.chromium.org/p/chromium/issues/detail?id=246571 ("We're not working on it right now, no." a week or so ago)
fantasai: I think flexbox fixes should be on the list somewhere
fantasai: there's a whole bunch of small things that aren't working right
jet: there's a critical fixes list
jet: I know dholbert is pushing on such things
jet: multicol does that need a devtool
jet: calc(attr()) does that need one?
tantek: would it help authors if they had a calc expression authoring
jryans: maybe, not sure
jet: next is CSS Color 4
dbaron: there's some important in Level 2 or 3 to do, like proper color
dbaron: that's a higher priority on higher-end macs
dbaron: where we look bad compared to Safari, because we don't do colours
jet: maybe on the wiki it should just say CSS Color then, rather than L4
jet: next, initial-letter
jet: jeremychen started working on it
jeremychen: there were some spec issues, but they've been resolved
jeremychen: I haven't had a chance to get back to it
jeremychen: I'm not sure if it has any blockers still
jet: so half way done
jet: is that something that would need a devtool?
pbro: anything that's very visual, I'd tend to say yes
pbro: something showing baseline, text blocks, etc. could be useful
fantasai: I don't think there's too much of a need, the initial-letter
the settings are pretty straight forward, UA does most of the
fantasai: so there's not much to offer for tooling, compared to other
like flex or grid or even just intrinsic sizing that bz
dbaron: I think maybe we should check the existing layout inspector tool
the right thing for it, but don't think it needs a separate tool
jen: it's not that we have no tool, we have the simple tool of setting
tantek: tooling could help with pseudo-element vs property --
tantek: I think a tool could help you out if you're trying to design with
dbaron: that's also a hard too to build
dbaron: for fallback you need to know how it behaves in other browsers
fantasai: @supports is your friend there
jen: it's something to look at
tantek: designers like to tweak differently for different letters
tanteK: I could easily see something with richer initial-letter support,
designers would expect even more control about how it looks
tantek: it's an opportunity
jet: is that the only inline layout feature we are looking at?
fantasai: only other one is fixing inline layout in general, there are a
bunch of problems with the inline layout model
fantasai: which we want to improve
fantasai: baseline to baseline descendants, making that regular
fantasai: the CSS model is not that conducive to that, but there's also
fantasai: closing the loop on interop, improving the model, that's spec
tantek: I agree with higher fidelity typo needs, some of this needs spec
but also I want to see a list of critical bugs for fidelity
dbaron: it's still floating around in the WG, so not for us this year
dbaron: it's also worth think about what other high priority devtools
not tied to features
dbaron: I think one of the areas we should be looking at is dev tools for
dbaron: what we have for perf, is good ways to tell what subsystem the
spent in, but not debugging subsystem perf
dbaron: you can find out you're spending a lot of time in styling, or
but not why
dbaron: to the point where most engineers can't even answer that question
dbaron: and I think that's something that would be valuable for us to
dbaron: I think there's simple things that's not a huge amount of work,
and more complicated things to build on top of that
dbaron: I think a bunch of that would require collab between devtools and
harald: we were working on that for QF
harald: exposing more info on why certain things were expensive
dbaron: this wouldn't fit in the perf-html UI
dbaron: you'd want to examine a tree, see which elements were expensive
pbro: so quite specialized tools
jet: even a view within your page, showing you reflowed this thing 17
jet: next, SVG properties in CSS
tantek: we've had some demand from devs
heycam: recently at confs I've seen demos of things in chrome where
uplifted a bunch of SVG geometry attrs to be properties
heycam: with e.g. cx and cy in circles
heycam: and the the advantage is you can control these using css
jet: I've seen a demo with a clock
heycam: relatedly, there's the issue of transform *attribute* vs.
*property* and how they interact
heycam: and they have different semantics, and we're starting to look at
to combine them
heycam: and it's a lot of work & requires thinking about SMIL animations
birtles: motion path, you can change SVG paths from CSS
pbro: the CSS property value would be a path?
pbro: we could totally re-use the path tool we're using for CSS shapes
jwatt: did chrome remove their animVal support?
birtles: I think webkit did it
jwatt: we should look at that
<emilio> birtles: <line stroke-dasharray="calc(5)" .. /> wfm
<emilio> animations may be buggy though
jet: next, MQ 4
fantasai: I think the most important thing in that is interaction
whether or not you have hover, whether you're on a touchpad or
fantasai: right now people are working around that by guessing from
fantasai: fixing that would make it possible to make responsive designs
weird heuristics (that don't always return the right answer)
dbaron: I think the syntax changes are also kind of important
dbaron: they can use <= and >=
dbaron: so they don't need to leave gaps in their widths
jet: is that straightforward?
tantek: the syntax changes we need that first
dbaron: they're independent, but the syntax changes are straightforward
fantasai: the new features are just keywords, aren't dependent on new
tantek: if we had a MQ constructor tool, to help you construct a MQ that
be an area to leverage with the new syntax
birtles: we also talked about doing prefers-reduced-motion, from L5
birtles: in safari, you can toggle that in devtools
birtles: somewhere in devtools being able to toggle device capabilities
fantasai: yeah, pretend you don't have hover ability
jet: container query prereqs, any more of those?
tantek: this is the most requested feature I've heard
tantek: but also the most underdefined
tantek: dbaron mentioned getting the containment stuff will help us shed
more light here
tantek: the flipside is that there's a community of devs trying to
I'm working that side
tantek:there are draft specs written by web devs, which are a bit wishful
thinking, but they've polyfilled their work
tantek: but would be nearly impossible for us to implement
fantasai: the key issue is that it interlaces cascade & layout
jen: I keep hearing web devs that they desparately need this
jen: and hearing from WG / browsers it's impossible!
jen: we should look and see if it is impossible
jen: if so, we should so it's never going to happen
jen: but if it is possible, we should do this investigation work
tantek: we need to gather data, see what web devs want, see what slice we
jen: the community has felt stop energy from browsers
dbaron: I think there are things we could do to fix perf characteristics
dholbert: does resize observer address this use case?
fantasai: container queries, you have an element in some subtree like a
and the overall page has given me a width, and inside depending
that I'm running a MQ to see how wide I am
fantasai: kind of like a MQ but based on parent width
dbaron: resize observer might make it a bit more efficient, but not much
dbaron: they would still need to dynamically add/remove style sheets
jet: a new feature?
bz: no, just that we could make style sheets turning on or off more
fantasai: what if we had conditional @rule hooked up to reading a JS
bz: evaluating JS has the drawback that if it's not isolated, you must
when the JS executes
fantasai: I'm suggesting a global JS switch that toggles which sheets are
bz: no way to read a JS variable without side effects
fantasai: can you read it from the browser without executing JS?
jet: last thing, better print support
fantasai: most of the printing bugs are fragmentation bugs
tantek: this is a whole range of things
tantek: there's paged media, there's fragmentation, there's dimensions at
tantek: our print fidelity sucks, so does every other browser
tantek: but our browser fidelity is so much higher this is a chance for
jet: we're freshening up our print support, removing cairo, we haven't
about picking up paged media features in there
jet: would like to see a sorted list here
tantek: needs exploration
tantek: I added a critical fixes section after talking to jen simmons
tantek: if anyone else has nominations for that, please put them up there
jen: I have a list I'll put on there
tantek: or just link to it
birtles: two more specs to add to the list
birtles: first is motion path
birtles: which obviously we want to do devtools for
birtles: other is CSS Images 3
birtles: still missing a few features from that, like crossfade
birtles: in webkit/blink animating fades between, and in firefox just
jet: [discusses priorities on the board]