https://drafts.css-houdini.org/css-properties-values-api/#example-1

I found this bit confusing:

* {
    transform: translate(var(--translate-x), var(--translate-y)) rotate(var(--rotate)) scale(var(--scale-x), var(--scale-y));
}

…is it meant to be there? It seems to be doing the same job as registerApplyHook.

It might be desirable to have images loaded implicitly in a paint function, without having them loaded via. a custom property.

For example performing a network request, or a pull from the main execution context, to receive an image to use.

Thought: Are there any existing properties today which do this?

During last meeting, Tab told that to accomodate changes made in the ApplyHook of css-propvals, a new round of style computation and resolution would happen to fix anything that would not be computed-compatible added by the hook.

To me, this means we've made something which is not a primitive of the web browser, but a new feature that will add more complexity to the system.

I propose we mark the ApplyHook as at-risk until we develop a ComputedStyle TypedOM and restrict the value of properties set in the ApplyHook to those values, in order to avoid any style recalc after this step.

(sorry for really bad description).

The CanvasRenderingContext2d (or similar) should place its 0x0 at the fragment top, left. Drawing into the visual overflow (if present) is done by drawing outside of the bounds of the canvas.

The specification needs to clearly state that apply gets called every time any of the inputs change.

As above.

For example if:
requestAnimationFrame(function() {
someElement.styleMap.set('--my-custom-prop', 42);
});

if "someElement" is within the visual viewport then before paint occurs the paint function should be called.

This is so that script doesn't have to be run to load code into an isolated worker. User agents can also do standard tricks like pre-fetching before html document is parsed.

This probably wants to be done with something like a tag. I.e.

<link href="paint.js" rel="paint-worker" />

 #myElement {
    --circle-color: red;
    background-image: paint(circle);
}

Shouldn't this be paint(var(--circle-color))?

For example instead of requiring (as in the current spec) to paint the whole area each time the paint function is called - be able to pass in a dirty region, and just requiring the paint function just to paint the required area?

This was in the spec initially as a problem so I'm converting it to an issue so I can pull it out of the spec.

The apply model means that you can't have two custom properties that apply to the same used values coexisting on the same element. This is especially important to point out since our expectation is for these APIs to be utilized by libs and authors may not be aware of the conflicts.

registerProperty({
  name: '--layout',
  syntax: '<string>',
  inherit: false,
  initialValue: 'none',
  apply: function(used, value) {
    if (value == 'grid') {
        used.width = '500px';
    }
  }
});
registerProperty({
  name: '--extraBorder',
  syntax: '<length>',
  inherit: false,
  initialValue: '0px',
  apply: function(used, value) {
    used.width += value;
  }
});

Custom paint contents are not accessible to things like screen-readers (for example drawText). Authors should they communicate any useful information through regular a11y APIs.

This should be the same as normal javascript for UAs. If something is running long, show unresponsive page script.

UAs will probably provide developer tooling to gain insight for authors into how expensive their paint functions are.

As part of understanding what we need for Compositing/UI Workers/Scroll API, it would be good to list the types of effects we're planning to enable. Rick and Ian have already mentioned:

• pull to refresh
• rubber banding
• hidey bars
• sticky positioning
• scroll snap points
• parallax

Some real work examples that are pretty interesting are:

• the top bar on twitter user pages (e.g https://twitter.com/LEGO_Group)
• the reading progress on avclub.com (http://www.avclub.com/review/weeknd-navigates-trippy-perception-and-pop-reality-224412)

What are others?

Specifically what the in initial crop, fillStyle, etc. (should be same as the default canvasrenderingcontext).

For visual overflow what is the origin of the canvas? ( (0,0) should be position at the top,left of the fragment, draw into -ve space for overflow behaviour).

It may be desirable for authors to control the clip/opacity/etc of all the background layers for example. This has been referenced as a "configureContext" method. This isn't a level 1 feature, but should be mentioned as desirable for a future version of the spec.

The specification doesn't say this yet...

Is it fine if the paint function is allowed to be called multiple times if its inputs don't change?

• Probably yes as we want UAs to be able to dispose of results to reduce memory.

Is it fine if the paint function is allowed to be called multiple times within the same frame if its inputs don't change?

• Maybe? I don't have strong arguments for or against here.

We need to be ability to report this error to a monitoring server or similar.

There should be an "onerror" handler on the main script handle for the worker(s).

For example:

// IsolatedWorkerGlobalScope
throw new Error('hi!');

// main execution context.
window.paintWorker.addEventListener('error', function(event) {
  // Do something with the error here. Report to a monitoring server or similar.
});

Currently missing from draft. All console APIs should be available.

This would allow for things like:

• border-image.
• tiling of background image.
• keeping aspect ratio.

Should this be declared ahead of time, or set within a callback?

The apply hook's inputProperties list needs to be able to accept references to parent/ancestor elements.

We explicitly don't want some APIs which currently exist on the CanvasRenderingContext2d object.

Specifically these APIs:

partial interface CanvasRenderingContext2D {
    readonly attribute HTMLCanvasElement canvas;

    void drawFocusIfNeeded(Element element);
    void drawFocusIfNeeded(Path2D path, Element element);

    void addHitRegion(optional HitRegionOptions options);
    void removeHitRegion(DOMString id);
    void clearHitRegions();

    ImageData getImageData(float sx, float sy, float sw, float sh);
};

Currently the specification defines parsing for a subset of types. The computed value of these types is then passed into an apply function, but there's no information about what the computed value for each type will be.

To complement the list of scrolling use cases that's been started, it would be nice to build a list of non-scrolling effects that might be enabled via something like CompositorWorker.

Here are some examples to get the ball rolling:

• Simple side-drawers which can be dragged out from the side, sticking to the finger
• Simple custom panning that sticks to the finger and can fling in arbitrary directions (eg. google maps)
• Drag-and-drop interfaces where elements “skootch” out of the way to make room for the dragged element (or other animations to illustrate potential drop targets).
• Animating force-directed, springy/physical application layout. For example, drawers with inertia/friction or even more exotic, physics-based interfaces like BumpTop.
• Animating constraint based application layout transitions (eg, responding to the addition of new views to a Cassowary layout).
• Applications where the compositor thread is the control thread.
• If access to input is available, input filtering.

This is so that if you stash a reference to a CanvasRenderingContext, and use it on a subsequent callback, nothing happens.

The CSS property cursor accepts an <image>. Is there implementation complexity if we allow cursor to be invalidated every frame? Should cursor just have the opportunity just to paint once?

Make note of complexities.

.. but we're supposed to raise github issues.

Based off: http://bfgeek.com/css-houdini-drafts/css-script-api/Overview.html

Show in this example how a custom property controls the 'randomness' of the heading paint behavior.

The current proposal https://lists.w3.org/Archives/Public/public-houdini/2015Aug/0004.html cannot accurately represent things like:

width: calc(var(--a) * var(--b));
--a: 3;
--b: 5px;

I think the TypedOM proposal is stuck somewhere between the specified and the computed style. Both need a possibly different OM, even if converting from the latter one to the first one is trivial and should be natively supported by the API.

Under this proposal, the Computed.CalcPercentLength would only contain "px" and "percent", while the Specified.CalcPercentLength would contain something more abstract which can contains additions, products, etc... We could allow user agents to simplify those calculations to pixels and percentages when it is possible to do so without impacting the result (calc(3px + 3cm) could be memorized as calc(158px)).

Anyway, this needs further thought.

[EDIT] Another option would be to support only the ComputedValue Typed OM and have one extra value ({value:string}) which would be returned for specified styles which cannot accurately be converted to a value of the ComputedValue Typed OM. Or we could just disallow this entirely and mark the specified style write-only.

Should this present the data currently written?
Should this present no data?

If on the CanvasRenderingContext you set:
ctx.font = 'somthing';

As above.

The spec doesn't say this yet.

This could have an impact on other scripts running in the background worker.
Should we restart the environement after such an error or not?

That's important to know for scripts which may want to share data because if the worker can be restarted during a single-frame step, there's no way to accurately pass information from one script to another (or one run to another).

Currently, if two custom properties try to call registerApplyHook() and identify the same output property, then the second call will fail with an exception. This is because the two properties might be used on the same element, in which case we don't know which order to apply the apply hooks in (and the order matters because both want to change the same property).

However, this is too inflexible. It seems very likely that multiple (e.g.) layout frameworks will want to register similar outputs with an expectation that they don't get used simultaneously on the same element.

We should consider switching the error detection to the point of application - i.e. if 2 applyHooks try to write to the same output property for a given element then deliver an error to window.onError. A downside here is that we are giving up the static guarantee that the custom properties were interoperable, and instead failing based on runtime state.

Need to make sure we write in spec that calling this doesn't necessarily mean that paint will get called.

One potential issue: does it make sense to have a separate list of properties on which the paint overflow becomes invalidated? Probably not, this might just be a micro-optimization.

We need to define the pipeline for not only authors but discussions during the meeting. When will the apply hooks be called, for example.

Additionally, we should show dependencies from one piece to another to help prioritize.

Authors may want the ability to create additional CanvasRenderingContexts to draw into ahead of time, and then in the paint callback perform cheap operations to update the immediate mode primary rendering context based on these additional contexts.

Should this be in Level 1 of spec or in future version?

This specification would define how things like CustomPaint, the ApplyHook and other things like CustomLayout declaratively define their dependencies to css properties, layout properties and/or properties of the environment (parents, etc...).

In addition, I believe we should provide a StyleMutationObserver interface to the main javascript thread, with a behavior similar to the HTML MutationObserver, and which would allow to bind events for instance for when a CustomPaint needs input information but can't get access to it directly (the script running on the main thread may update the value of css custom properties to accurately update the painting to the current state).

This would also allow to trivially implement a querySelectorLive function, which is something a lot of people would like to have. Currently, most implementation rely on polling and other tricks to achieve this effect.

Should developers be required to explicitly flag properties that need access to parent computed style for the apply phase?

The most basic information needed is the width and height of the fragment you are currently painting.

Other information that might be desirable is:
sibling fragment information - for example you want to know your position relative to you siblings so that you can paint an effect that spans multiple fragments.
previous sibling fragment information only - same as above, but you only receive your previous sibling fragment information.
children fragment information - you want to know your children fragments so that you can paint effects like a line between them (or something).

It is probably desirable to (upon registering the custom paint class) to decide which type of information here you are interested in. For example invalidating a polyfill of conic-gradient based on children fragment information isn't optimal.

For example, being able to specify "<width>" or "<background-color>" as a syntax string.

Issue 1: this gates on the Typed OM specifying object representations of the values.

Issue 2: what should we do with "<width>|<font-size>"? "<font-size>|<width>"? Options:

• don't allow this
• allow this but try in-order parsing, so the first one would always return a width

This could either happen in the class constructor, or a separate initialize function.

The paint function may want to perform some pre-work ahead of being used. For example, drawing some data to a sub-canvas for re-use, etc.