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
for scribing.
******************************************************************
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.
******************************************************************
Thanks,
--Jet
---------- Forwarded message ----------
From: fantasai <fanta...@inkedblade.net>
Date: Sun, Dec 17, 2017 at 8:28 AM
Subject: DRAFT Layout Team Austin Notes
To: Jet Villegas <j...@mozilla.com>
Discussion Lead: Jet Villegas
Layout Architecture
===================
Scribe: Jet Villegas
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
removal)
- pcwalton gave a overview of bottom-up frame construction
- not much to problematic, seems feasible
- will likely not share code with servo
Parallel layout
- 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,
getBoundingClientRect())
Parallelizing nsBlockFrame::Reflow
- 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.)
Parallelizing nsBlockFrame::ReflowDirtyLines
- 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
cost.
- 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.
Flexbox/Grid Parallelizing
- 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
CSS Containment
- 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
Fragmentation
- 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
breaks
-- 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.
Containment
- 1. normative requirements
- 2. perf optimizations
- should do both
CSS Houdini APIs
================
Scribe: fantasai
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
vehicle
jet: State of feature? mattwoodrow?
Paint API
---------
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
parts.
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
done
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
properties
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
property values
dbaron: Other point of canvas, is it's canvas 2D API, but designed to be
subset
of API that doesn't have to be backed by a bitmap
mattwoodrow: You can record drawing commands, do whatever you want with
those
jet: Spec as designed, we thought it can be subset of canvas2D API, you
get a
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]
[presume yes]
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
examples
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
chan
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
classes
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
much
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
difficult.
dbaron: Just lots of interfaces and deal with lots of pieces
jet: Ok, but haven't started yet, so need a name for that.
Worklets
--------
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
prototype
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
pipeline
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
main thread
baku: Yeah
mattwoodrow: I don't think we need to run off the main thread at this
point
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
General Considerations
----------------------
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
extended later?
mattwoodrow: yeah
heycam: Anything in the design atm that would be a red flag?
mattwoodrow: no
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
threat
that they'll deploy on youtube or gmail and we'll have to implement
it
yesterday
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
complex
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
browser.
tantek: They clearly want something like this, and are trying to not make
it
proprietary stuff
tantek: They want to give their property dev tools to make more
performant effects
dholbert: complex example comes to mind is one Google material design,
where
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
stuff
look better
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
create
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
same input?
mattwoodrow: yeah
mattwoodrow: was discussion about storing some global state between
iterations
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
between
worklets
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
scratch
mattwoodrow: so don't want to recreate ever time
dholbert: so may or may not have variables left behind from last worklet
run
dholbert: you could produce unpredictable results
dholbert: by relying on it
dholbert: Google is intending to write code such they switch to a random
global,
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
creating
new clean global would be high. But ideally, if it were fast,
would want
a new one each time
Planning
--------
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
landing
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
of
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
rendering stack
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
much
work done
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
square,
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
follow
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
getting
into something like intersection observer
xidorn: ...
bz: I don't remember it having any deep interactions with DOM things.
Just need
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
more wins
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
style system?
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
readonly)
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?
bz: Maybe?
jet adds devtool to the list:
P & V landing = jyc?
Typed OM tbd
Context2D Matt
worklet done
painting matt
devtool tbd
bz: when you use JS debugger on script in a webpage, JS debugger spins a
nested
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
the world
bz: at point we're running the worklet code, not clear rest of browser is
OK
with us spinning the event loop
bz: so for that reason might be useful to not be on the main thread,
otherwise
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.
CSS & Design Tools
==================
Scribe: heycam
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
Chrome/Webkit/Edge
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
requested
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
something
jet: text-decoration-skip
tantek: this is the one that's a typography fidelity thing, where the
decoration
skips descenders/ascenders
tantek: it's something that should look nicer by default, not sure if we
need
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
shrink-wrapped
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: dunno
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
this
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
thing it
exposes
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
added;
but it's not super critical
jet: can unprefix without it?
fantasai: yes
fantasai: CSSWG was resolved years ago to allow unprefixing of *-content
keywords
fantasai: one thing not marked as stable was what become stretch keyword,
but
that was pushed to L4
jet: containment
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
we went,
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
need it,
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
itself
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
your
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
mostly
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
rewrite them
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
things,
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
anything
that changed
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
are a
collection of small bits, like Text. Others have one big
feature and
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
stroke properties
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
pbro: yes
jet: calc(attr()) does that need one?
tantek: would it help authors if they had a calc expression authoring
tool?
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
management
dbaron: that's a higher priority on higher-end macs
dbaron: where we look bad compared to Safari, because we don't do colours
right
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
stuff
the settings are pretty straight forward, UA does most of the
math
fantasai: so there's not much to offer for tooling, compared to other
things
like flex or grid or even just intrinsic sizing that bz
mentioned
dbaron: I think maybe we should check the existing layout inspector tool
shows
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
the value
tantek: tooling could help with pseudo-element vs property --
::first-letter,
vs initial-letter
tantek: I think a tool could help you out if you're trying to design with
fallback
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
whole
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
browser
differences
fantasai: closing the loop on interop, improving the model, that's spec
work
tantek: I agree with higher fidelity typo needs, some of this needs spec
work,
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
there is,
not tied to features
dbaron: I think one of the areas we should be looking at is dev tools for
perf
dbaron: what we have for perf, is good ways to tell what subsystem the
time is
spent in, but not debugging subsystem perf
dbaron: you can find out you're spending a lot of time in styling, or
layout,
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
build
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
layout
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
to style
pbro: so quite specialized tools
jet: even a view within your page, showing you reflowed this thing 17
times
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
they've
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
animations
jet: I've seen a demo with a clock
heycam: relatedly, there's the issue of transform *attribute* vs.
transform
*property* and how they interact
heycam: and they have different semantics, and we're starting to look at
how
to combine them
heycam: and it's a lot of work & requires thinking about SMIL animations
etc
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
features:
whether or not you have hover, whether you're on a touchpad or
mouse
fantasai: right now people are working around that by guessing from
screen size,
weird heuristics
fantasai: fixing that would make it possible to make responsive designs
without
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
syntax
tantek: if we had a MQ constructor tool, to help you construct a MQ that
could
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
would
be useful
fantasai: yeah, pretend you don't have hover ability
jet: container query prereqs, any more of those?
tantek: potentially
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
some
more light here
tantek: the flipside is that there's a community of devs trying to
organise,
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
could
implement
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
sidebar,
and the overall page has given me a width, and inside depending
on
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
efficient
fantasai: what if we had conditional @rule hooked up to reading a JS
toggle?
bz: evaluating JS has the drawback that if it's not isolated, you must
specify
when the JS executes
fantasai: I'm suggesting a global JS switch that toggles which sheets are
applied
bz: no way to read a JS variable without side effects
fantasai: can you read it from the browser without executing JS?
bz: sometimes
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
all,
extra dimensions
tantek: our print fidelity sucks, so does every other browser
tantek: but our browser fidelity is so much higher this is a chance for
us to
leapfrog others
jet: we're freshening up our print support, removing cairo, we haven't
thought
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
flips
between them
jet: [discusses priorities on the board]
Proposed features sorted by Layout Team's general enthusiasm:
- Variable fonts
...
- Fragmentation
- Printing
_______________________________________________
dev-tech-layout mailing list
dev-tech-layout@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-layout
