search

DioxusLabs / blitz

High performance HTML and CSS renderer powered by WGPU
Apache License 2.0
2.12k stars 42 forks source link

Add CSS import support #139

Closed kokoISnoTarget closed 2 weeks ago

kokoISnoTarget commented 2 months ago

This adds support for CSS imports. This also changes the net logic/structure.

kokoISnoTarget commented 3 weeks ago

@nicoburns any thoughts about this? If you feel this is useless/unneeded, I would close it.

nicoburns commented 3 weeks ago

@nicoburns any thoughts about this? If you feel this is useless/unneeded, I would close it.

@kokoISnoTarget Hello! Apologies for letting this sit for so long. I definitely want this feature, although I would not consider it super-high priority.

My main issue with this PR is the introduction of a static variable. I believe it ought to be possible to implement this without it (perhaps using an Arc?). And I would really like to avoid introducing one, as it makes composing modules together much more complex.

I also still think we will want to move the "net" crate to a simpler "url in, bytes out" model. And generally simplify the interface between modules (I don't think all the traits we have currently are necessary, but I haven't quite worked out how it would work without them yet). But that doesn't need to be done here.

I like how this PR moves the net stuff into a net module.

kokoISnoTarget commented 3 weeks ago

I also still think we will want to move the "net" crate to a simpler "url in, bytes out" model.

I wouldn't know what would be responsible for the bytes (I guess the DOM or an implementation using the DOM), we'd also lose the capability to parse something like CSS on the "fetch" thread.

And generally simplify the interface between modules (I don't think all the traits we have currently are necessary, but I haven't quite worked out how it would work without them yet). But that doesn't need to be done here.

If we do the "URL in, bytes out" we could remove RequestHandler and the Callback traits and make the NetProvider a bit simpler.

nicoburns commented 2 weeks ago

Let's keep this out of scope of this PR, but:

I wouldn't know what would be responsible for the bytes (I guess the DOM or an implementation using the DOM), we'd also lose the capability to parse something like CSS on the "fetch" thread.

So I think the idea would be that in the short-term it would just be handled internally by blitz-dom (in the load_resource function I guess). Long-term, I'd like to have a separated blitz-media crate which ends up a "provider" to blitz-dom similar to blitz-net, and could have it's own threadpool. I think it's probably best to keep media decoding and networking threads separate due to their very different workload characteristics (IO-heavy vs CPU-heavy). Async networking shouldn't need too many threads at all!

If we do the "URL in, bytes out" we could remove RequestHandler and the Callback traits and make the NetProvider a bit simpler.

Exactly. I also think it would be possible to make blitz-net suitable for loading the initial HTML document. Which would be really nice as (unlike the current code in our examples) it knows how to load from either the network or the filesystem.