Disclaimer

This document is not an official 5-year plan for the WebKit project. It was a starting point for discussion at the 2015 WebKit contributors meeting. Opinions expressed here are not necessarily those of the project as a whole, etc.

What have we done?

• Display list experiment
• Optimized offsetWidth/height
• Indexed DB improvement

Loading

• Clean up loading code, for realz
• Page cache cleanup

Standards things

• Maintain status on all the CSS Properties
• Event loop
• Fetch spec and API
• Service Workers
• Event handler attributes
• Intersection observer
• Scroll-linked effects
• Houdini

Page & friends

• Page/Frame/FrameView/FrameLoader disambiguation
• Unify scrolling architecture
  • Get WebKit1 scrolling out of WebCore

Code organization

• PAL

Layout & Rendering

• Readonly render tree?
• Ref-counted renderers?
• Remove Widgets
  • subpixel
  • another useless hierarchy
• Removal of continuations

Compositing

• One compositing update per frame
• Compositing post-display lists

Debuggability

• Logging
• Log channels
• Dumping
• lldb macros
• notifyutil -p com.apple.WebKit.showRenderTree

Simon’s 5 year plan

What have we done

• Hyatt did Optimizing layout
• IndexedDB rewrite in progress

What now?

Every year we say we’re going to do these things.

• Cleaning up the loading code
• Page cache cleanup

Chris worked on page cache and added sanity checks for holding on to cache.

Antii We should get rid of page cache and replace it with something more robust. A WebKit2 level cache.

Long term plan is to eliminate Page Cache. Let’s call it a 5-year plan.

Standards Things

• Maintains status on all the CSS properties
  • Should it be prefixed, iTunes-only flag, other flags
  • We need infrastructure here
  • Could add comments to css-properties.in
  • Chris We have tons of prefixed IDL attributes
• Event Loop
  • DOM event loop spec for event timers, requestAnimationFrame, etc. These should all spawn out of the same code. We should organize our code into a more explicit concept of an event loop.
  • Long term we should see if we agree with the spec
• Fetch API
  • We should do this.
  • Sam Attempt to define loading for the web platform. It has an XHR like API. This is really a pre-req for Service Workers. Sub resource integrity spec and others that are related.
  • Service Workers
    • People think they want it, some of them actually do want it. We should probably do it.
  • Event handler attributes
    • Avoid synchronous touch events. Trackers will do event handlers to track page usage, and it always falls into synchronous touch events.
  • Intersection observer
    • Ad vendors register event listeners when the ad is visible in the viewport
    • Listing for scroll events
    • Allows for detecting when ads are visible
    • don’t have to do forced layouts to give them the answer
    • Other use case: infinite scrolling lists
  • Scroll-linked effects
    • A proposal to allow fast scrolling while having things react on the page to the scroll. Think parallax or video scrubbing while scrolling
  • Houdini proposal
    • UI workers run little isolated scripts that gets scroll position things and can modify scroll position but doesn’t otherwise have access to the DOM

Page & friends

• Page/Frame/FrameView/FrameLoader disambiguation
  • Sam There are spec names that are really long and obnoxious. Curious about what people think?
  • Ted MainFrame is a good term from a retro perspective
  • Sam How this works and the split window makes this complicated
  • Beth Eliminating scroll view/merge it with scrollable area, or combining with FrameView
  • Sam I believe that FrameView isn’t necessary and could be RenderView owning the drawing. What is the value of having both RenderView and FrameView?
  • Simon disagrees.
  • Sam RenderLayer and FrameView knows about scrolling. Overflow scroll is handled separately.
  • RenderLayer should have a ScrollableArea; FrameView has a ScrollableArea.
• Unify scrolling architecture
  • Four scrolling architectures WebKit1 NSScrollView, WK2 ScrollingTree, iOS WK1 uses UIScrollView, iOS WK2 uses UI side compositing. oh and GTK scrolling like WK2 Mac scrolling. ScrollingThread and the slow path. Hit the slow path when hitting the page-up/page-down keys.
• Get WebKit1 scrolling out of WebCore
  • Sam Zero-benefit except for code cleanness
  • Simon may break apps as well

Code Org

• PAL
  • Myles Platform abstraction/library code bits implemented diff on diff platforms. It is the conceptual API between Platform folder and WebCore. This is really for code cleanliness.
  • Simon Benefit is strict layering. Allows unit testing library code that we can’t currently test.
  • Myles Most of the test code is in the platform directory.
  • Simon We’ll want it for Web Animations and Display List
  • Myles Intend to make it over Thanksgiving.

Layout & Rendering

• Simon Zalan thinking render tree immutable and read-only
• Zalan Make it only for layout. We can control layout tree. Decouple as much as possible. Then optimize the layout.
• Ryosuke We’ve had security bugs related to changing Render Tree.
• Antii Generate another tree for box placement, painting operates on that.
• Ryosuke A lot of ops that mutate the render tree. List markers, counters, etc. Problem is all these things are cause of crashes.
• Antii We should organize our code for correctness and security. Solution is more trees.
• Ryosuke There is nothing requiring a render object for style.
• Antii Appears coupled for historic reasons.
• Ryosuke You have DOM tree, Style tree and Layout tree.
• Antii I am working on a refactoring that is
• Ryosuke We should break the render layer block into smaller pieces. Clipping happens all over the place and shouldn’t have to call render layer
• Antii RenderLayer, RenderLayerBacking, GraphicsLayer, RemotePlatformLayer. The layers are too damn high!
• Ryosuke Bit of confusion with respect to SVG, MathML, are we doing top-down or bottom-up? It’s all a hot mess. The minimum width computation. We accommodate this is so many different places. Make that explicit: a bottom-up for intrinsic width, then top-down phase.
• Simon It would be great, if we had two different read-only render trees you could diff them

Remove widgets

• Simon We can shift sub pixel; widget hierarchy is useless
• Sam What happened with plugins?
• Simon RenderTree could host plugins; doesn’t matter who owns them really.
• Ryosuke DOM should own plugins. RenderObject positions them. Should be fairly easy. Only problem may be scrollable pseudo-elements

Continuations

• Simon One of Hyatt’s favorite things.
• Hyatt removing continuations.

Compositing

• Forced Layout updates render tree every frame
• Compositing should happen post-display lists

Debuggability

• Logging
• Add more log channels; wish there was a style log channel
• Different names for WK logging
• Sam Would be nice if logging infrastructure could include channel names
• More TextStream logging becomes very easy to dump hierarchical things with TextStream
• Ideally we would share one logging mechanism instead of JSC PrintStreamer and WC TextStream
• LOG_RESULT() and LOG_WITH_STREAM() We should do more of this.
• Ryosuke Annoying to not know where the logging goes.
• Simon It logs to syslog or stdout
• Ryosuke We should show in stdout where the logging is going.
• Long term goal: Unify PrintStream and TextStream

lldb Macros

• How to debug WebKit on webkit.org

notifyutil -p com.apple.WebKit.showRenderTree

Also, Hyatt should rewrite CSS Parser.

Antoine WebCore could use more web technologies. Web Components for form controls.

Shouldn’t be used for layout. Jumping between JS and C++ would be bad.