-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restrict workers that CSSStyleValue
is exposed to
#632
Comments
Hi @tabatkins , any reason why things are exposed to all worker types (e.g. ServiceWorkers)? |
Because there was no good reason to disallow them, and we might very well add CSS-related APIs to other workers in the future? I'm fine with removing them, it just means we'd have to do a spec update if we ever do want to expose them there. |
ah - then let's retain it. Better extensible than restrictive. |
I'm going to reopen this since I disagree with the rationale. Once we have a need we should expose them, but not before. |
Note that if you really want this you better support them from day one and have tests for all the different worker types. |
The Working Group just discussed
The full IRC log of that discussion<dael> Topic: Which Workers to expose to?<TabAtkins> GitHub: https://github.com//issues/632 <dael> TabAtkins: Currently we spec that all typed OM objects are exposed to all worker types because why not? It was brought up by the tag why do that we should restrict to those needed. Fine with that, it's just if we need some in the future we have to edit the spec. No reason to disallow because only big contention is not all context can access the CSS parser. It's only a few things allowe din arbitrary context. <dael> dbaron: THings aren't on workers unless you can get to them there? <dbaron> s/THings/I think the norm is that things/ <dael> TabAtkins: Yeah. Reasonable argument. If there's a general policy of on't expose unless there's a reason I'm happy to. <dael> dbaron: They're only on window and worklets. <dael> TabAtkins: Yes. <dael> dbaron: Is it...the other question is if it's exposed on all worklets or just painr worklet and if there should be a base class of all css worklets so we can expose that without interfereing. <dael> iank_: TypedOM we spec we need a workflow. <dael> TabAtkins: We can make a css type fast. <dael> fremy: [missed] <dael> TabAtkins: No, they're not a postable type. There's nothing that prevents us from making it postable. <dael> fremy: If you can send into a worker, that's a reason. <dael> TabAtkins: People would obj to them being in post without a use case. <dael> iank_: Only medium temr thing use the typed OM is the canvas APIs. The font accepting a font query value. But we could expose that if canvas accepts it. <dael> TabAtkins: We can wait for a use case <dael> TabAtkins: Happy to resolve to restrict to just window and css worklets for now. <dael> shane: It does seem to extract tht we're going to great lengths to differentiate worklets. Through impl details the same APIs behave differently accross workers has been a pain. It's a tiny thing that comes back to bite you. <dael> shane: Do we really want to make them all look different? <dael> dbaron: Many platform core APIs are sinlge thread. <dael> shane: I get having the main thread be distinguished. But this is about workers. <dael> dbaron: There are some APIs that distinguish dedicated, shared and service worker. <dael> shane: Is the question do we need to distinguish these workers by the presence of this API? <dael> dbaron: I don't know. WOuld be interesting to talk to JS folks about performance and complexity. It feels good you can only access useful things, but I don't have strong feelings. <dael> shane: I don't have strong feelings, I wanted to do a counter point. <dael> cbiesinger: Do we have the parsing restricted? <dael> TabAtkins: Yes, it's restricted. You can construct values but you cant' use the parsing to do it. <dael> TabAtkins: I still think for now restrict to just window and css worklets. If the discussion tends to being freer with worker exposed APIs we can change in the future. <dael> krit: Note it may change? <dael> TabAtkins: Yeah. <dael> Rossen_: shane you okay? <dael> shane: Yes <dael> Rossen_: Obj? <dael> RESOLVED: restrict to just window and css worklets |
Originally filed by @slightlyoff here: w3ctag/design-reviews#223 (comment)
The text was updated successfully, but these errors were encountered: