w3c / css-houdini-drafts Goto Github PK
View Code? Open in Web Editor NEWMirror of https://hg.css-houdini.org/drafts
Home Page: https://drafts.css-houdini.org/
License: Other
Mirror of https://hg.css-houdini.org/drafts
Home Page: https://drafts.css-houdini.org/
License: Other
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?
.. but we're supposed to raise github issues.
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).
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.
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?
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?
Currently missing from draft. All console APIs should be available.
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:
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:
Some real work examples that are pretty interesting are:
What are others?
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.
Make note of complexities.
Should this present the data currently written?
Should this present no data?
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);
};
Is it fine if the paint function is allowed to be called multiple times if its inputs don't change?
Is it fine if the paint function is allowed to be called multiple times within the same frame if its inputs don't change?
The specification doesn't say this yet...
If on the CanvasRenderingContext you set:
ctx.font = 'somthing';
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.
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
.
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;
}
});
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.
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.
Show in this example how a custom property controls the 'randomness' of the heading paint behavior.
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.
This would allow for things like:
Should this be declared ahead of time, or set within a callback?
As above.
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" />
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.
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.
});
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.
This is so that if you stash a reference to a CanvasRenderingContext, and use it on a subsequent callback, nothing happens.
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 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?
The spec doesn't say this yet.
As above.
(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 apply hook's inputProperties list needs to be able to accept references to parent/ancestor elements.
Should developers be required to explicitly flag properties that need access to parent computed style for the apply phase?
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.
"<length-and-percentage>" (accepts "50px", "50%" and "calc(50px + 50%)")
"<ident>" (any custom identifier)
"<ident>(auto, none)" (a list of possible idents which the property does accept)
"*" (any input, much like a unregistered custom property)
#myElement {
--circle-color: red;
background-image: paint(circle);
}
Shouldn't this be paint(var(--circle-color))
?
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).
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.
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.
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:
The specification needs to clearly state that apply gets called every time any of the inputs change.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.