Layout Team Meeting Notes (Austin, Texas - 2017/12/15)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Layout Team Meeting Notes (Austin, Texas - 2017/12/15)

Jet Villegas-2
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 <[hidden email]>
Date: Sun, Dec 17, 2017 at 8:28 AM
Subject: DRAFT Layout Team Austin Notes
To: Jet Villegas <[hidden email]>

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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout