3 ms·

I've been thinking many times that maybe Mozilla could do an experiment with a rendering pipeline that chucks out everything that is just backwards compatibili

I've been thinking many times that maybe Mozilla could do an experiment with a rendering pipeline that chucks out everything that is just backwards compatibility at this point - and then maybe some - and make a much smaller and simpler pipeline that can only render modern and simple documents. Call it htmlcore or something. This would run in parallel with the existing one and would trigger based on some meta tag or something, kind of like I understood asm.js did. Maybe also pair it with some work on the JS engine to limit the JS engine significantly for such documents by only allowing a low number of JS operations pr user input. We already have something similar (although admittedly imperfect) today for audio were a web page can only play media as a response to a user action I think. Would this be for every website? No, strictly opt in, but if it succeeded those who did would have significantly better performance. And with time, maybe we'd see people asking themselves: why isn't this news site available as htmlcore? And maybe it becomes a competitive advantage. But back to rendering Firefox: Such a limited, high performance form of html could maybe also be a better way to run Firefox UI? If necessary with whitelisting of certain parts that would need to run JS without the limitations I mentioned above?

adastra22 4y ago
Or—I know this sounds crazy but—maybe just use the fast, optimized native UI widgets for UI controls?
- lenkite 4y ago
  But which one ? WinUI ? GTK ? SwiftUI ? Qt ?. What about if I want custom components and cross platform ?
  - TeMPOraL 4y ago
    Let's start with native Windows and MacOS controls, and let the fraction of users running Linux sort their GUI framework mess on their own, without blocking the majority of users from a sensible, consistent and performant UI experience.
- lelanthran 4y ago
  > Or—I know this sounds crazy but—maybe just use the fast, optimized native UI widgets for UI controls? You mean native widgets on whichever system? Probably not possible; you still need to do all the computations of CSS and layout before drawing an actual widget on the screen. The reason that HTML elements are rendered slower than native might be due to all the processing that has to go on to figure out what each widget should look like and where on the screen it must be placed for each frame that is rendered @ (say) 60fps. And the reason you have to continually do it for each frame is because it may change due to CSS animation, or javascript which adds/removes new widgets, or javascript which changes the CSS for that element, or the widget might be reparented or removed, or a user event might cause different properties to trigger on the widget (changing the actual width, changing the opacity/color, etc). And of course, the renderer then has to propagate the changes down to child widgets for all properties that are inherited, and propagate all events upwards, for all events that a generated. Native widgets are generally quite customisable as well, but it rarely happens at runtime and so they perform better because each widget is not continuously changing its properties at runtime.
  - adastra22 4y ago
    We are clearly not talking about the same thing XUL in Firefox was used for the browser user interface elements, e.g. the url bar, bookmarks and history panes, etc. these are native UI elements in the traditional sense. XUL was not used for forms in the html frame.
- reitanqild 4y ago
  Sure, but then they would have to sacrifice a number of other desirable characteristics.
- c-smile 4y ago
  That's generally impossible as native UI widgets are windows. Consider this: <div style="overflow:hidden"> <input type="text" /> </div> In order to clip out that input in case overflow the container must be a window too. This leads to situation when all DOM elements must be windows. That's too much.
  - adastra22 4y ago
    XUL wasn’t used for the DOM. It was used for the UI interfaces of the browser itself—the url bar, the history pane, the menu bar, etc.
    - rafram 4y ago
      It still is. The entire Firefox UI exists in the DOM -- the URL bar is an HTML input, the toolbar buttons are XUL <toolbarbutton>s. The box model can even be used from normal web pages! Just add this CSS to an element: display: -moz-box; and then you can -moz-box-flex it to your heart's content. The box model will no longer function once the patches that this blog post describes make it into a release, but XUL elements themselves are still around.
emodendroket 4y ago
I feel like this is basically what XHTML tried and failed to do. Users don’t blame the Web site if a page loads on other browsers but not on yours.
phonon 4y ago
Isn't that what Servo was supposed to be?
- cxr 4y ago
  No.
kbrosnan 4y ago
This was done with the HTML (5) parser. https://hsivonen.fi/html5-gecko-build/ https://hsivonen.fi/html5-gecko-build/ There is the standards based code path and the quirks path.

adastra22 4y ago

Or—I know this sounds crazy but—maybe just use the fast, optimized native UI widgets for UI controls?

lenkite 4y ago
But which one ? WinUI ? GTK ? SwiftUI ? Qt ?. What about if I want custom components and cross platform ?
- TeMPOraL 4y ago
  Let's start with native Windows and MacOS controls, and let the fraction of users running Linux sort their GUI framework mess on their own, without blocking the majority of users from a sensible, consistent and performant UI experience.
lelanthran 4y ago
> Or—I know this sounds crazy but—maybe just use the fast, optimized native UI widgets for UI controls? You mean native widgets on whichever system? Probably not possible; you still need to do all the computations of CSS and layout before drawing an actual widget on the screen. The reason that HTML elements are rendered slower than native might be due to all the processing that has to go on to figure out what each widget should look like and where on the screen it must be placed for each frame that is rendered @ (say) 60fps. And the reason you have to continually do it for each frame is because it may change due to CSS animation, or javascript which adds/removes new widgets, or javascript which changes the CSS for that element, or the widget might be reparented or removed, or a user event might cause different properties to trigger on the widget (changing the actual width, changing the opacity/color, etc). And of course, the renderer then has to propagate the changes down to child widgets for all properties that are inherited, and propagate all events upwards, for all events that a generated. Native widgets are generally quite customisable as well, but it rarely happens at runtime and so they perform better because each widget is not continuously changing its properties at runtime.
- adastra22 4y ago
  We are clearly not talking about the same thing XUL in Firefox was used for the browser user interface elements, e.g. the url bar, bookmarks and history panes, etc. these are native UI elements in the traditional sense. XUL was not used for forms in the html frame.
reitanqild 4y ago
Sure, but then they would have to sacrifice a number of other desirable characteristics.
c-smile 4y ago
That's generally impossible as native UI widgets are windows. Consider this: <div style="overflow:hidden"> <input type="text" /> </div> In order to clip out that input in case overflow the container must be a window too. This leads to situation when all DOM elements must be windows. That's too much.
- adastra22 4y ago
  XUL wasn’t used for the DOM. It was used for the UI interfaces of the browser itself—the url bar, the history pane, the menu bar, etc.
  - rafram 4y ago
    It still is. The entire Firefox UI exists in the DOM -- the URL bar is an HTML input, the toolbar buttons are XUL <toolbarbutton>s. The box model can even be used from normal web pages! Just add this CSS to an element: display: -moz-box; and then you can -moz-box-flex it to your heart's content. The box model will no longer function once the patches that this blog post describes make it into a release, but XUL elements themselves are still around.

emodendroket 4y ago

I feel like this is basically what XHTML tried and failed to do. Users don’t blame the Web site if a page loads on other browsers but not on yours.

phonon 4y ago

Isn't that what Servo was supposed to be?

cxr 4y ago
No.

kbrosnan 4y ago

This was done with the HTML (5) parser. https://hsivonen.fi/html5-gecko-build/ https://hsivonen.fi/html5-gecko-build/ There is the standards based code path and the quirks path.