在 2016/2/27 1:55, Myk Melez 写道:
Benjamin Francis <mailto:bfran...@mozilla.com>
2016 February 26 at 05:15
I mainly propose the change of syntax because this transition period
seems
like an opportunity to make a clean break, get rid of the vendor
prefixes
and define a long term, explicitly separate to standard HTML,
chrome-only
solution with a cleaner API and without having to worry about backwards
compatibility because the mozBrowser API could exist in parallel
until we
phase it out.
I'd like to see this too, if only because <webview> is more ergonomic
and easier to distinguish from the existing <iframe mozbrowser> API.
However, the isolated <iframe mozbrowser> from bug 1238160 is
reasonable and a great start.
But I think a more important piece than webview is the ability to
execute a
Gecko-based user agent with HTML-based chrome without having to run
it on
top of the Firefox binary.
I like this idea in theory. But I want to understand how it's
different from Electron, besides simply using different underlying
technology. In other words: what makes it unique that justifies the
effort? Is there something that Gecko can provide that Chromium cannot
(or is unlikely to)? Are there parts of the Electron stack that are
encumbered in some way? Are there architectural choices that make
Electron unsuitable or suboptimal for valuable use cases?
One of our project switched from Electron to XULRunner about half a year
ago, because:
* MathML. Our project is a slide editor for education, so MathML is
important. Google rejected to implement MathML so Electron and NW.js are
out of luck.
We tried to use mathml.css in Electron but you know the result is
suboptimal. MathJax is suitable for presenting but not for editing.
* Auto update. We found that build-in auto updating of XULRunner is easy
to use and robust. Electron and NW.js has no such mature solution yet.
* Windows XP support. Our project has to support XP for an extended
time, however Chromium will drop XP support this year, and Electron
never runs on XP.
Unfortunately, we might be force to switch back to Electron or NW.js in
future because XULRunner was remove from Mozilla's code base and there
is no foreseen alternative.
Our company is small and has not enough resource to maitain XULRunner by
ourselves (We even don't known whether it is tecnically feasible). A
HTML-based "XULRunner successor" is definitely interesting to us!
(You can argue that developers having two options is by itself
beneficial. And I agree, in general. But I'm not yet convinced that we
should therefore invest the effort to build the second option.)
If we no longer have XULRunner, if mozApps is
phased out and B2G loses platform support we're really running out of
options for how to use Gecko for non-Firefox projects. At what point
does
the platform stop being a platform and just becomes Firefox?
That point is well in the past, as Gecko development post-Netscape has
focused on the Web platform and integration with Firefox. Other uses,
like XULRunner and embedding in native apps, have been second-class
citizens, at best.
How are we
promoting innovation if we're effectively forcing alternative user
agents
to use WebKit?
Mozilla's mission is to promote "openness, innovation & opportunity on
the Web." Mitchell clarified in 2007 that Mozilla's key platform is
the Open Web
<https://blog.lizardwrangler.com/2007/04/19/the-open-web-as-platform/>.
I happen to think that making Gecko a great platform for building
products like (but not limited to) Firefox indirectly benefits that
mission. But doing so would still be in service to that mission, a way
to help fulfill it, and not the actual mission itself.
-myk
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform