5 ms·

> The current roadmap lists Shadow DOM and CSS Grid as priorities I've been working on the CSS Grid support. About to land "named grid lines and areas" support

> The current roadmap lists Shadow DOM and CSS Grid as priorities I've been working on the CSS Grid support. About to land "named grid lines and areas" support which should make a bunch more websites layout correctly. I'm biased because it's my project, but IMO the approach Servo is using for CSS Grid is pretty cool in that the actual implementation is in an external library (Taffy [0]) that can be used standalone and is widely used accross the Rust UI ecosystem, including in the Blitz [1] web engine (which also uses Taffy for Flexbox and Block layout), the Zed [2] text editor, and the Bevy [3] game engine. I'm hopeful that this approach of breaking down a web engine into independently usable modules with public APIs (which builds upon Servo's earlier work on modular libraries such as Stylo and html5ever) will make it easier for people to get involved in web engine development (as they can understand each piece in isolation), and make it easier for people to create new web engines in future (as they won't have to start completely from scratch). [0]: https://github.com/DioxusLabs/taffy https://github.com/DioxusLabs/taffy [1]: https://github.com/DioxusLabs/blitz https://github.com/DioxusLabs/blitz [2]: https://zed.dev https://zed.dev [3]: https://bevy.org/ https://bevy.org/

fouronnes3 1y ago
Does having experience implementing a web browser engine feature change the way you write HTML or CSS in any way? Do you still google "css grid cheatsheet" three times a week like the rest of us?
- rockwotj 1y ago
  To me, this is like asking if having built a sql engine if you write SQL differently. I think the answer is yes. Having a strong understanding of the underlying engine helps you debug and optimize more quickly Needing reference stuff never changes unless it’s so frequently used.
- nicoburns 1y ago
  > Does having experience implementing a web browser engine feature change the way you write HTML or CSS in any way? I think I'm more concious of what's performant in CSS. In particular, both Flexbox and CSS Grid like to remeasure things a lot by default, but this can be disabled with a couple of tricks: - For Flexbox, always set `flex-basis: 0` and `min-width: 0`/`min-height: 0` if you can without affecting the layout. This allows the algorithm to skip measuring the "intrisic" (content-based) size. - For CSS Grid, the analogous trick is to use `minmax(0, 1fr)` rather than just `1fr`. (I also have a proposal for a new unit that would make it easier to get this performance by default, but I haven't managed to get any traction from the standards people or mainstream browsers yet - probably I need to implement it and write it up first). > Do you still google "css grid cheatsheet" three times a week like the rest of us? Actually no. The process of reading the spec umpteen times because your implementation still doesn't pass the tests after the first N times really ingrains the precise meanings of the properties into your brain
  - nashashmi 1y ago
    How do you propose standards to the web groups? I want to propose CSS-inheritance—by-name (#box {inherit:$(#menu)}) and the reintroduction of marquee tags for horizontal scrolling (a frequently used UI pattern on shopping sites).
    - nicoburns 1y ago
      > How do you propose standards to the web groups? I'm not sure. I tried opening an issue at https://github.com/w3c/csswg-drafts https://github.com/w3c/csswg-drafts but that didn't get me very far. I suspect it's a case of making connections and then getting yourself an invite to present at a meeting.
      - pxeger1 1y ago
        I succeeded with opening an issue and getting something to be supported in browsers (although I think it's not yet in the standard). It was a very small and fairly uncontraversial tweak which was easy to specify, implement, and test, though - bigger things are probably harder. https://github.com/w3c/csswg-drafts/issues/6203 https://github.com/w3c/csswg-drafts/issues/6203
      - spankalee 1y ago
        If you can socialize your idea to a few of the people that show up frequently in the issues, it can really help. See if there's someone with open DMs, tell them you work on CSS in Servo, and ask what they think.
  - dleeftink 1y ago
    (Just say yes, you have to look it up all the time so we don't feel as bad)
  - nielsbot 1y ago
    I wish there was a CSS analyzer that would give tips like this based on your CSS.
piker 1y ago
Do you not worry that instead it will lead to feature bloat and fragmentation? If you’re going to strike at Google, you need laser focus.
- nicoburns 1y ago
  Not really. Everything has a spec, so it's pretty clear what's in scope and what isn't. Also, we don't have time for bloat with our team size. We have to be laser focussed on what actually makes a difference to real websites. It's Chrome that has bloat! Also the specs don't change much (there are additions, but almost always backwards-compatible), so once written the code shouldn't need too much maintenance. I see it as writing a piece of foundational infrastructure. You can write your own HTTP library. But you don't need to: there are high-quality libraries readily available (e.g. curl or hyper). Similarly for HTML parsers or 2D graphics rendering. Nobody's done that for web layout yet (except arguably React Native's Yoga [0], but that's much less ambitious in terms of how much of the spec it attempts to support), so everybody has to write their own. But it's possible so we're doing it. [0]: github.com/facebook/yoga/
- afavour 1y ago
  Shadow DOM and CSS Grid don't strike me as bloat or fragmentation in any way? CSS Grid in particular is table stakes that would be part of any laser focus.
goku12 1y ago
> (Taffy [0]) that can be used standalone and is widely used accross the Rust UI ecosystem, including in the Blitz [1] web engine (which also uses Taffy for Flexbox and Block layout) This is the first time I hear about Blitz. Looks equally interesting and ambitious. It is probably the real undercover web engine. Servo was widely known around when Rust debuted.
- echelon 1y ago
  Questions for the Rust UX experts: Is Dioxus (or Leptos) much more performant than Tauri/Electron? I want to (1) build blindingly fast, low-latency, super performant UX for users, which precludes Tauri/Electron (something I'm currently using and unhappy about), but I also want to (2) maintain developer velocity, (3) have access to nice UX primitives and widgets, and (4) have it look nice and modern. Javascript/browser-oriented frameworks make requirements 2-4 easy, and it has the side benefit of also making hiring easy (not a requirement per se). But the results feel so bloated and anti-Desktop/native. It gobbles up RAM and renders slowly, even when best practices are used. It's the very definition of a double-edged sword. Are these four requirements simply impossible to satisfy together for native Rust UX toolkits right now? Rust's egui looks amazing, but I doubt you'd be able to build a very complicated UX with it. Or if you could, it might take you half a year to deliver. Iced also looks cool, but looks less featureful. Are there any "non-browser" Rust UX toolkits that aren't dated GTK/KDE frameworks, but that can build graphically-oriented (not just text/button widget) programs? If I were building a "slimmed down photoshop", are there any Rust GUI toolkits to reach for? Or if I were incorporating a Bevy or 3D render pane?
  - airstrike 1y ago
    I'm super biased in favor of iced. Yes, there are missing features (it's not even version 1.0 yet!) but I think the number is very small now and the solution is usually to fill in the gaps yourself—which is possible because iced is totally modular I've made a spreadsheet editor and a slideshow editor with it so "slimmed down photoshop" seems feasible although admittedly you will likely need to get deep into the renderer (possibly write your own renderer traits and there), but I suppose you're comfortable with that given your goal. If you're not allergic to Discord, come join us. It's a helpful, awesome tight community IMHO Link for the lazy: https://discord.gg/3xZJ65GAhd https://discord.gg/3xZJ65GAhd Project link: https://iced.rs https://iced.rs
01HNNWZ0MV43FF 1y ago
> breaking down a web engine into independently usable modules with public APIs I love that. Years ago I looked at WebRTC and asked myself, why does it seem like making a crummy Skype knockoff is either 50 lines of JavaScript or a nightmarish week of trying to get half of Chromium to compile in your C++ project? I think there is a WebRTC Rust crate finally, which is good. Web apps shouldn't be the only beneficiaries of all this investment
gr__or 1y ago
That's so fun to hear, I've been using taffy for layouting my little rusty eink calendar

fouronnes3 1y ago

Does having experience implementing a web browser engine feature change the way you write HTML or CSS in any way? Do you still google "css grid cheatsheet" three times a week like the rest of us?

rockwotj 1y ago
To me, this is like asking if having built a sql engine if you write SQL differently. I think the answer is yes. Having a strong understanding of the underlying engine helps you debug and optimize more quickly Needing reference stuff never changes unless it’s so frequently used.
nicoburns 1y ago
> Does having experience implementing a web browser engine feature change the way you write HTML or CSS in any way? I think I'm more concious of what's performant in CSS. In particular, both Flexbox and CSS Grid like to remeasure things a lot by default, but this can be disabled with a couple of tricks: - For Flexbox, always set `flex-basis: 0` and `min-width: 0`/`min-height: 0` if you can without affecting the layout. This allows the algorithm to skip measuring the "intrisic" (content-based) size. - For CSS Grid, the analogous trick is to use `minmax(0, 1fr)` rather than just `1fr`. (I also have a proposal for a new unit that would make it easier to get this performance by default, but I haven't managed to get any traction from the standards people or mainstream browsers yet - probably I need to implement it and write it up first). > Do you still google "css grid cheatsheet" three times a week like the rest of us? Actually no. The process of reading the spec umpteen times because your implementation still doesn't pass the tests after the first N times really ingrains the precise meanings of the properties into your brain
- nashashmi 1y ago
  How do you propose standards to the web groups? I want to propose CSS-inheritance—by-name (#box {inherit:$(#menu)}) and the reintroduction of marquee tags for horizontal scrolling (a frequently used UI pattern on shopping sites).
  - nicoburns 1y ago
    > How do you propose standards to the web groups? I'm not sure. I tried opening an issue at https://github.com/w3c/csswg-drafts https://github.com/w3c/csswg-drafts but that didn't get me very far. I suspect it's a case of making connections and then getting yourself an invite to present at a meeting.
    - pxeger1 1y ago
      I succeeded with opening an issue and getting something to be supported in browsers (although I think it's not yet in the standard). It was a very small and fairly uncontraversial tweak which was easy to specify, implement, and test, though - bigger things are probably harder. https://github.com/w3c/csswg-drafts/issues/6203 https://github.com/w3c/csswg-drafts/issues/6203
    - spankalee 1y ago
      If you can socialize your idea to a few of the people that show up frequently in the issues, it can really help. See if there's someone with open DMs, tell them you work on CSS in Servo, and ask what they think.
- dleeftink 1y ago
  (Just say yes, you have to look it up all the time so we don't feel as bad)
- nielsbot 1y ago
  I wish there was a CSS analyzer that would give tips like this based on your CSS.

piker 1y ago

Do you not worry that instead it will lead to feature bloat and fragmentation? If you’re going to strike at Google, you need laser focus.

nicoburns 1y ago
Not really. Everything has a spec, so it's pretty clear what's in scope and what isn't. Also, we don't have time for bloat with our team size. We have to be laser focussed on what actually makes a difference to real websites. It's Chrome that has bloat! Also the specs don't change much (there are additions, but almost always backwards-compatible), so once written the code shouldn't need too much maintenance. I see it as writing a piece of foundational infrastructure. You can write your own HTTP library. But you don't need to: there are high-quality libraries readily available (e.g. curl or hyper). Similarly for HTML parsers or 2D graphics rendering. Nobody's done that for web layout yet (except arguably React Native's Yoga [0], but that's much less ambitious in terms of how much of the spec it attempts to support), so everybody has to write their own. But it's possible so we're doing it. [0]: github.com/facebook/yoga/
afavour 1y ago
Shadow DOM and CSS Grid don't strike me as bloat or fragmentation in any way? CSS Grid in particular is table stakes that would be part of any laser focus.

goku12 1y ago

> (Taffy [0]) that can be used standalone and is widely used accross the Rust UI ecosystem, including in the Blitz [1] web engine (which also uses Taffy for Flexbox and Block layout) This is the first time I hear about Blitz. Looks equally interesting and ambitious. It is probably the real undercover web engine. Servo was widely known around when Rust debuted.

echelon 1y ago
Questions for the Rust UX experts: Is Dioxus (or Leptos) much more performant than Tauri/Electron? I want to (1) build blindingly fast, low-latency, super performant UX for users, which precludes Tauri/Electron (something I'm currently using and unhappy about), but I also want to (2) maintain developer velocity, (3) have access to nice UX primitives and widgets, and (4) have it look nice and modern. Javascript/browser-oriented frameworks make requirements 2-4 easy, and it has the side benefit of also making hiring easy (not a requirement per se). But the results feel so bloated and anti-Desktop/native. It gobbles up RAM and renders slowly, even when best practices are used. It's the very definition of a double-edged sword. Are these four requirements simply impossible to satisfy together for native Rust UX toolkits right now? Rust's egui looks amazing, but I doubt you'd be able to build a very complicated UX with it. Or if you could, it might take you half a year to deliver. Iced also looks cool, but looks less featureful. Are there any "non-browser" Rust UX toolkits that aren't dated GTK/KDE frameworks, but that can build graphically-oriented (not just text/button widget) programs? If I were building a "slimmed down photoshop", are there any Rust GUI toolkits to reach for? Or if I were incorporating a Bevy or 3D render pane?
- airstrike 1y ago
  I'm super biased in favor of iced. Yes, there are missing features (it's not even version 1.0 yet!) but I think the number is very small now and the solution is usually to fill in the gaps yourself—which is possible because iced is totally modular I've made a spreadsheet editor and a slideshow editor with it so "slimmed down photoshop" seems feasible although admittedly you will likely need to get deep into the renderer (possibly write your own renderer traits and there), but I suppose you're comfortable with that given your goal. If you're not allergic to Discord, come join us. It's a helpful, awesome tight community IMHO Link for the lazy: https://discord.gg/3xZJ65GAhd https://discord.gg/3xZJ65GAhd Project link: https://iced.rs https://iced.rs

01HNNWZ0MV43FF 1y ago

> breaking down a web engine into independently usable modules with public APIs I love that. Years ago I looked at WebRTC and asked myself, why does it seem like making a crummy Skype knockoff is either 50 lines of JavaScript or a nightmarish week of trying to get half of Chromium to compile in your C++ project? I think there is a WebRTC Rust crate finally, which is good. Web apps shouldn't be the only beneficiaries of all this investment

gr__or 1y ago

That's so fun to hear, I've been using taffy for layouting my little rusty eink calendar