- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Jul 2017 21:03:06 +0000
- To: public-houdini-archive@w3.org
Again, **we don't have any constructors that require CSS parsing**. All the constructors take the relevant data directly, in JS datatypes. CSS parsing is done in factory methods instead. We can exclude those for now, as most browser have trouble with this, and expose them later. URL parsing is already done in workers *somehow* (whether with a proxy to a dedicated thread, or with a thread-safe parser), so the constructors that require URL parsing are kosher. Shane jumped a bit in the topic, which has confused both Boris and Anne, but the only other "problematic" constructors are those that fetch an external resource. We don't want to allow an external communication channel like that in worklets, so for these objects, we're defining that if you construct one in a worklet, it sticks in an "unloaded" state while it "lives" in the worklet. (It can start loading later, after it's been set to some style and the main thread has taken over.) A detail of that is, if Gecko's URL-parsing-thru-thread-proxy is troublesome to do in worklets, we're okay with moving the URL parsing slightly later in the construction algorithm, so that it doesn't occur until the object attempts to switch to the "pending" state (at which point, if the URL is invalid, it'll instead switch to the "error" state). Does Gecko have a preference here? -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/237#issuecomment-318485772 using your GitHub account
Received on Thursday, 27 July 2017 21:03:10 UTC