On 16/10/2014 13:56, Robert O'Callahan wrote:
On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch
wrote:
There are also "interesting" height computation issues that I'm pretty sure
HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a
function of the box model, considering it's not
在 2014年10月17日星期五UTC+8下午2时39分54秒，Yonggang Luo写道：
> There is a lost of falt in XUL, but still have something good, such as tree
> and the XBL binding, besides, the window elements is also important, because
> we need it to implement chromeless window, and titlebar, there is no
> equivalent in HTML
There is a lost of falt in XUL, but still have something good, such as tree and
the XBL binding, besides, the window elements is also important, because we
need it to implement chromeless window, and titlebar, there is no equivalent in
HTML/JS, that's must be considerate when propose the removal
On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch
wrote:
There are also "interesting" height computation issues that I'm pretty sure
> HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a
> function of the box model, considering it's not an issue with flexbox...
>
Yeah. XUL layout
On 16/10/2014 06:15, Boris Zbarsky wrote:
On 10/16/14, 5:30 AM, Neil wrote:
Out of interest, what does it do that complicates layout? You mentioned
the box model of course, but what else is there?
There's a bunch of listbox-related frame constructor complexity (and for
a while it was a quite l
On 2014-10-16, 1:44 PM, David Rajchenbach-Teller wrote:
On 16/10/14 12:54, Ehsan Akhgari wrote:
It can be implemented in JS, right?
Indeed.
I meant, as a JS library by web developers who feel like it's needed,
not by us. :-)
FWIW I think that XUL overlays are a terrible way of extending
On 16/10/14 12:54, Ehsan Akhgari wrote:
> It can be implemented in JS, right?
Indeed.
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.m
On 2014-10-16, 7:02 AM, David Rajchenbach-Teller wrote:
Which actually looks pretty good to me and should perhaps be (re)discussed.
It can be implemented in JS, right?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla
On 10/16/14, 5:30 AM, Neil wrote:
Out of interest, what does it do that complicates layout? You mentioned
the box model of course, but what else is there?
There's a bunch of listbox-related frame constructor complexity (and for
a while it was a quite lively source of security bugs, too).
But
Which actually looks pretty good to me and should perhaps be (re)discussed.
I wonder if something like HTMLoverlays (certainly extended with a
mechanism to help with unloading) could be made part of the Add-on SDK.
Cheers,
David
On 16/10/14 04:53, Gervase Markham wrote:
> Although glazou did p
Boris Zbarsky wrote:
The situation is that we have a bunch of unmaintained code that
complicates layout.
Out of interest, what does it do that complicates layout? You mentioned
the box model of course, but what else is there?
--
Warning: May contain traces of nuts.
_
On 15/10/14 14:24, Boris Zbarsky wrote:
> I haven't thought much about #3; it's somewhat in its own little world
> and has no web tech equivalent.
Although glazou did propose one a decade ago:
http://disruptive-innovations.com/zoo/20040830/HTMLoverlays.html
Gerv
_
On Wednesday 2014-10-15 09:24 -0400, Boris Zbarsky wrote:
> "XUL" covers a variety of somewhat-unrelated features, including at least:
>
> 1) The XUL box model.
> 2) The built-in XUL elements (with C++ implementations). for
> example.
> 3) The overlay system.
> 4) XBL and the bindings pr
On 10/15/14, 9:03 AM, Boris Zbarsky wrote:
The situation is that we have a bunch of unmaintained code that
complicates layout.
I feel like I should expand on this.
"XUL" covers a variety of somewhat-unrelated features, including at least:
1) The XUL box model.
2) The built-in XUL elements (
This is one of the reasons I started to breathe new life in the Chromeless
project[1], but with a grander scope this time around.
I’d like to facilitate a pragmatic migration route to building desktop apps
with XULRunner using only the latest Web technologies, including asm.js and
WebGL+WebVR.
On 10/15/14, 5:01 AM, glazou wrote:
w/o even trying to discuss with
them the situation, the possibilities, the alternatives, the ETA,
the transition plan.
The situation is that we have a bunch of unmaintained code that
complicates layout. And layout needs no extra complications; it has
enoug
On 10/15/14, 3:40 AM, glazou wrote:
Guys, you understand there is an ecosystem - even if it is a small one - of
companies relying on XUL for their businesses?
Yes, including Mozilla, via Firefox.
1. does Mozilla still care about us?
I can't answer this question. On a personal level, I car
Le mercredi 15 octobre 2014 10:18:19 UTC+2, Bobby Holley a écrit :
> I agree that the current state of affairs sucks for XUL embedders, and you
> have our sympathy. But if we translate that sympathy into strategy, we will
> lose much bigger battles.
I have the feeling "sucks" is a bit far from re
On Wed, Oct 15, 2014 at 9:40 AM, glazou wrote:
> 1. does Mozilla still care about us?
In terms of the goals of the organization, I think it's pretty clear that
XUL embeddings are not a priority - they're pretty orthogonal to the
Mozilla Mission (which is about the Internet and the Web - not des
Le mardi 14 octobre 2014 14:29:04 UTC+2, Boris Zbarsky a écrit :
> On 10/13/14, 11:28 PM, Yonggang Luo wrote:
>
> > If the XUL is truly dead, then mozilla community should consider to remove
> > it totally from the codebase
>
>
>
> Working on it. It's a big project. ;)
Seriously ?!?
Guys,
在 2014年10月14日星期二UTC+8下午8时29分04秒，Boris Zbarsky写道：
> On 10/13/14, 11:28 PM, Yonggang Luo wrote:
>
> > If the XUL is truly dead, then mozilla community should consider to remove
> > it totally from the codebase
>
>
>
> Working on it. It's a big project. ;)
Well, indeed, i've seen so much simula
On 10/14/2014 5:12 PM, Robert O'Callahan wrote:
On Tue, Oct 14, 2014 at 4:56 PM, Joshua Cranmer 🐧
wrote:
From another point of view: Mozilla, for over a decade, provided a
relatively featureful toolkit for building UIs known as XUL. If the
argument is that we should be using HTML instead of X
On Tue, Oct 14, 2014 at 4:56 PM, Joshua Cranmer 🐧
wrote:
> From another point of view: Mozilla, for over a decade, provided a
> relatively featureful toolkit for building UIs known as XUL. If the
> argument is that we should be using HTML instead of XUL, then wouldn't it
> make sense to provide a
On Tue, Oct 14, 2014 at 2:29 PM, Boris Zbarsky wrote:
> Working on it. It's a big project. ;)
Is there a tracker for this?
Cheers,
Dirkjan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 10/13/14, 11:28 PM, Yonggang Luo wrote:
If the XUL is truly dead, then mozilla community should consider to remove it
totally from the codebase
Working on it. It's a big project. ;)
-Boris
___
dev-platform mailing list
dev-platform@lists.mozill
On Mon, Oct 13, 2014 at 8:56 PM, Joshua Cranmer 🐧 wrote:
> From another point of view: Mozilla, for over a decade, provided a
> relatively featureful toolkit for building UIs known as XUL. If the argument
> is that we should be using HTML instead of XUL, then wouldn't it make sense
> to provide an
On 10/13/2014 10:10 PM, Andrew Sutherland wrote:
On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote:
I nominally agree with this sentiment, but there are a few caveats:
1. nsITreeView and exist and are usable in Mozilla code
today. No HTML-based alternative to these are so easily usable.
There a
I know there is so much alternative for tree in HTML/JS, but the simplest way
is to improve tree directly when you have already use it.
If the XUL is truly dead, then mozilla community should consider to remove it
totally from the codebase, but not reject to improve it.
在 2014年10月14日星期二UTC+8上午1
On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote:
I nominally agree with this sentiment, but there are a few caveats:
1. nsITreeView and exist and are usable in Mozilla code
today. No HTML-based alternative to these are so easily usable.
There are many lazy-rendering infinite tree/table/infinit
On Tue, Oct 14, 2014 at 12:06 PM, Joshua Cranmer 🐧
wrote:
I nominally agree with this sentiment, but there are a few caveats:
> 1. nsITreeView and exist and are usable in Mozilla code today.
> No HTML-based alternative to these are so easily usable.
> 2. The main rationale for this feature (bug
On 10/13/2014 5:28 PM, Robert O'Callahan wrote:
Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
desire for these features, but I do not think we should take these patches,
nor any other patches adding features to XUL. XUL is a dead-end technology
and investment in XUL
On Tuesday 2014-10-14 11:28 +1300, Robert O'Callahan wrote:
> Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
> desire for these features, but I do not think we should take these patches,
> nor any other patches adding features to XUL. XUL is a dead-end technology
> and
Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
desire for these features, but I do not think we should take these patches,
nor any other patches adding features to XUL. XUL is a dead-end technology
and investment in XUL provides minimal returns --- this includes effort
33 matches
Mail list logo
