Skip to content
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

Open
nainar opened this issue Feb 5, 2018 · 6 comments
Open

Restrict workers that CSSStyleValue is exposed to #632

nainar opened this issue Feb 5, 2018 · 6 comments

Comments

@nainar
Copy link
Contributor

nainar commented Feb 5, 2018

Originally filed by @slightlyoff here: w3ctag/design-reviews#223 (comment)

@darrnshn
Copy link
Collaborator

darrnshn commented Feb 5, 2018

Hi @tabatkins , any reason why things are exposed to all worker types (e.g. ServiceWorkers)?

@tabatkins
Copy link
Member

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.

@nainar
Copy link
Contributor Author

nainar commented Feb 12, 2018

ah - then let's retain it. Better extensible than restrictive.

@annevk
Copy link
Member

annevk commented Feb 23, 2018

I'm going to reopen this since I disagree with the rationale. Once we have a need we should expose them, but not before.

@annevk annevk reopened this Feb 23, 2018
@annevk
Copy link
Member

annevk commented Feb 23, 2018

Note that if you really want this you better support them from day one and have tests for all the different worker types.

@css-meeting-bot
Copy link
Member

The Working Group just discussed Which Workers to expose to?, and agreed to the following resolutions:

  • RESOLVED: restrict to just window and css worklets
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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants