7 ms·

I've built that. Just to be clear: this is a personal project, not a mozilla project (even though I'm a mozilla employee). Also - many people find it silly to

I've built that. Just to be clear: this is a personal project, not a mozilla project (even though I'm a mozilla employee). Also - many people find it silly to use HTML instead of the operating system toolkit library. But it's not HTML or native. It can be both. In this case, the HTML code define the layout, and we can draw native widgets inside (look at the <input type=submit> tag in HTML, it's a native widget). For example, if you run the current build on Mac, you'll see that new tabs use Yosemite "vibrancy" effect. Native look and native performance, can, in theory, be achieved.

lucianmarin 12y ago
Why don’t you use SVG instead of PNG for icons? Then you can use CSS to customize them for different themes.
- paulrouget 12y ago
  I want to use SVG. See issue #24. I just don't have the assets.
  - apaprocki 12y ago
    It might even make more sense to just use fonts for the icons and leave SVG out of it entirely. I'm referring to the OpenType COLR/CPAL tables Microsoft is pushing: http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/ http://opentype.info/blog/2013/07/03/color-emoji-in-windows-...
    - talmand 12y ago
      Personally, I'd prefer SVG over fonts unless they change how using font icons is done in HTML and CSS.
    - desdiv 12y ago
      I was looking for a similar solution recently, and came across Stackicons[0], basically icon fonts with multiple color layers, essentially what Microsoft is proposing. But there's a huge flaw with the whole approach: you can't have color gradients. Of course you can still emulate gradients by using lots of layers, but it's going to look like crap when you increase the resolution. [0] http://stackicons.com/ http://stackicons.com/
ANTSANTS 12y ago
> But it's not HTML or native. It can be both. In this case, the HTML code define the layout, and we can draw native widgets inside (look at the <input type=submit> tag in HTML, it's a native widget). No troll, I thought that was what XUL was.
- chadzawistowski 12y ago
  Problem being that XUL is quite long in the tooth? There might be other advantages of replacing XUL with HTML, rather than developing them in parallel.
  - reubenmorais 12y ago
    The problem (or at least one of them) is that maintaining XUL and HTML is expensive. XUL, like HTML, has a bunch of weird corner cases, tricky layout behavior, complex interaction between elements, etc. The focus of the platform developers at Mozilla is obviously on the Web, so XUL has been in a crappy maintenance mode for a long time now. Doing the Firefox chrome (heh) in HTML is another way to put our money where our mouth is, like the Firefox OS and Web App Runtime efforts. There's a more detailed explanation of the situation of XUL here: https://lists.mozilla.org/pipermail/dev-platform/2014-October/007160.html https://lists.mozilla.org/pipermail/dev-platform/2014-Octobe...
- pawelk 12y ago
  I've always conceptualized XUL as something similar to what is now known as Web Components + a native touch.
alex_duf 12y ago
Between that, rust and servo, it seems we have a new experimental technology stack shaping for the future of firefox. It may or may not be used in the end, but I'm excited by the potential.
- kibwen 12y ago
  One of Rust's goals for 2015 is to ship a tiny Rust-based component in Firefox (e.g. an image decoder), so we'll find out within the coming year. :)
- cpeterso 12y ago
  Mozilla is also experimenting with Boot2Servo, a possible future for Boot2Gecko (Firefox OS): https://github.com/servo/servo/wiki/Workweek-boot-2-servo https://github.com/servo/servo/wiki/Workweek-boot-2-servo
valarauca1 12y ago
As a guy who works with primarily back end server code. I hate UI stuff primarily because even creating small input UI windows requires jumping though hoops of fire it feels like with strange API calls, and documentation that says, "Just follow the example it'll all be fine in a couple minutes." But I'm 8 inheritance levels deep trying to figure out why my text box isn't rendering. I've often wondered why OS's just don't host browser render engines internally and draw their UI with that. Well I don't for long, I know HTML is much younger then X. Also browser engines are massive resource hogs. But with the advent of 8-16+ GB of ram in consumer computers can we really say 2-3GB for windows rendering is heavy? Especially if it offers that much empowerment to developers.
- recursive 12y ago
  > I've often wondered why OS's just don't host browser render engines internally and draw their UI with that. I believe Windows 8 can do this.
  - barkingcat 12y ago
    Didn't Windows use to do this until they got dinged by the anti-trust suit? MSFT had to spend a lot of engineering time decoupling IE from being a critical component in rendering basic file explorer views
    - Elv13 12y ago
      And the "active" Windows desktop itself (as part of explorer.exe) http://en.wikipedia.org/wiki/Active_Desktop http://en.wikipedia.org/wiki/Active_Desktop
- rancur 12y ago
  no more software layers please! my PC was much faster when my programs were native. Apps rendered with chrome rendered with webkit...8GB used to be enough, then all these "developers" with their "development machines" who think it's no big deal that their Hangouts implementation takes 200MB when Pidgin takes 20. people used to complain about Firefox hogging memory, I think it's Chrome we should be worried about...
Sophistifunk 12y ago
What's the license on this? I'd like to steal your tab bar for something I'm building :)
- striking 12y ago
  Likely MPL because it derives from the Mozilla browser design

lucianmarin 12y ago

Why don’t you use SVG instead of PNG for icons? Then you can use CSS to customize them for different themes.

paulrouget 12y ago
I want to use SVG. See issue #24. I just don't have the assets.
- apaprocki 12y ago
  It might even make more sense to just use fonts for the icons and leave SVG out of it entirely. I'm referring to the OpenType COLR/CPAL tables Microsoft is pushing: http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/ http://opentype.info/blog/2013/07/03/color-emoji-in-windows-...
  - talmand 12y ago
    Personally, I'd prefer SVG over fonts unless they change how using font icons is done in HTML and CSS.
  - desdiv 12y ago
    I was looking for a similar solution recently, and came across Stackicons[0], basically icon fonts with multiple color layers, essentially what Microsoft is proposing. But there's a huge flaw with the whole approach: you can't have color gradients. Of course you can still emulate gradients by using lots of layers, but it's going to look like crap when you increase the resolution. [0] http://stackicons.com/ http://stackicons.com/

ANTSANTS 12y ago

> But it's not HTML or native. It can be both. In this case, the HTML code define the layout, and we can draw native widgets inside (look at the <input type=submit> tag in HTML, it's a native widget). No troll, I thought that was what XUL was.

chadzawistowski 12y ago
Problem being that XUL is quite long in the tooth? There might be other advantages of replacing XUL with HTML, rather than developing them in parallel.
- reubenmorais 12y ago
  The problem (or at least one of them) is that maintaining XUL and HTML is expensive. XUL, like HTML, has a bunch of weird corner cases, tricky layout behavior, complex interaction between elements, etc. The focus of the platform developers at Mozilla is obviously on the Web, so XUL has been in a crappy maintenance mode for a long time now. Doing the Firefox chrome (heh) in HTML is another way to put our money where our mouth is, like the Firefox OS and Web App Runtime efforts. There's a more detailed explanation of the situation of XUL here: https://lists.mozilla.org/pipermail/dev-platform/2014-October/007160.html https://lists.mozilla.org/pipermail/dev-platform/2014-Octobe...
pawelk 12y ago
I've always conceptualized XUL as something similar to what is now known as Web Components + a native touch.

alex_duf 12y ago

Between that, rust and servo, it seems we have a new experimental technology stack shaping for the future of firefox. It may or may not be used in the end, but I'm excited by the potential.

kibwen 12y ago
One of Rust's goals for 2015 is to ship a tiny Rust-based component in Firefox (e.g. an image decoder), so we'll find out within the coming year. :)
cpeterso 12y ago
Mozilla is also experimenting with Boot2Servo, a possible future for Boot2Gecko (Firefox OS): https://github.com/servo/servo/wiki/Workweek-boot-2-servo https://github.com/servo/servo/wiki/Workweek-boot-2-servo

valarauca1 12y ago

As a guy who works with primarily back end server code. I hate UI stuff primarily because even creating small input UI windows requires jumping though hoops of fire it feels like with strange API calls, and documentation that says, "Just follow the example it'll all be fine in a couple minutes." But I'm 8 inheritance levels deep trying to figure out why my text box isn't rendering. I've often wondered why OS's just don't host browser render engines internally and draw their UI with that. Well I don't for long, I know HTML is much younger then X. Also browser engines are massive resource hogs. But with the advent of 8-16+ GB of ram in consumer computers can we really say 2-3GB for windows rendering is heavy? Especially if it offers that much empowerment to developers.

recursive 12y ago
> I've often wondered why OS's just don't host browser render engines internally and draw their UI with that. I believe Windows 8 can do this.
- barkingcat 12y ago
  Didn't Windows use to do this until they got dinged by the anti-trust suit? MSFT had to spend a lot of engineering time decoupling IE from being a critical component in rendering basic file explorer views
  - Elv13 12y ago
    And the "active" Windows desktop itself (as part of explorer.exe) http://en.wikipedia.org/wiki/Active_Desktop http://en.wikipedia.org/wiki/Active_Desktop
rancur 12y ago
no more software layers please! my PC was much faster when my programs were native. Apps rendered with chrome rendered with webkit...8GB used to be enough, then all these "developers" with their "development machines" who think it's no big deal that their Hangouts implementation takes 200MB when Pidgin takes 20. people used to complain about Firefox hogging memory, I think it's Chrome we should be worried about...

Sophistifunk 12y ago

What's the license on this? I'd like to steal your tab bar for something I'm building :)

striking 12y ago
Likely MPL because it derives from the Mozilla browser design