Cleaning up BoxObjects

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Cleaning up BoxObjects

SmauG-2
I've spent now sometime reading box object code.
it can be cleaned up a bit and made a bit faster too, I think.

So the question is that is someone else doing this, or
will for example reflow branch affect that (I guess no).

If no, I'll do something. At least remove unnecessary box object
interfaces. (All depends on how much time I have for this, ofc.)

br,

-Smaug
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up BoxObjects

Neil Deakin
smaug wrote:
> I've spent now sometime reading box object code.
> it can be cleaned up a bit and made a bit faster too, I think.
>

Just improve the underlying code, or change interfaces? An improved and
well designed set of properties/methods for reading and modifying
position, size and other layout related specifics is much needed.

> So the question is that is someone else doing this, or
> will for example reflow branch affect that (I guess no).

I've currently changed the popup and menu box object code.

/ Neil
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up BoxObjects

Boris Zbarsky
In reply to this post by SmauG-2
smaug wrote:
> So the question is that is someone else doing this, or
> will for example reflow branch affect that (I guess no).

Shouldn't really affect the reflow branch, no.

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up BoxObjects

Robert O'Callahan-3
In reply to this post by SmauG-2
smaug wrote:
> I've spent now sometime reading box object code.
> it can be cleaned up a bit and made a bit faster too, I think.
>
> So the question is that is someone else doing this, or
> will for example reflow branch affect that (I guess no).
>
> If no, I'll do something. At least remove unnecessary box object
> interfaces. (All depends on how much time I have for this, ofc.)

If we're changing interfaces, can we just remove the boxobject
interfaces and move their methods to elements just like regular DOM
elements?

I realize the answer is "no", but really I think boxobjects were a
design error.

Rob
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up BoxObjects

Robert O'Callahan-3
In reply to this post by Neil Deakin
Neil Deakin wrote:
> Just improve the underlying code, or change interfaces? An improved and
> well designed set of properties/methods for reading and modifying
> position, size and other layout related specifics is much needed.

Not sure what you mean by "modifying"...

We're probably going to implement getBoundingClientRect and
getClientRects for all elements. These are IE-ish APIs that we will
implement in a cleaned up way. Basically a "client rect" for an element
is a rectangle in CSS pixels, representing the border-box of the
element, relative to the top-left of the viewport, assuming everything
is scrolled to its default position. getClientRects handles the case
where an element is displayed in multiple frames.

Rob
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up BoxObjects

Neil Deakin
In reply to this post by Robert O'Callahan-3
Robert O'Callahan wrote:

> smaug wrote:
>> I've spent now sometime reading box object code.
>> it can be cleaned up a bit and made a bit faster too, I think.
>>
>> So the question is that is someone else doing this, or
>> will for example reflow branch affect that (I guess no).
>>
>> If no, I'll do something. At least remove unnecessary box object
>> interfaces. (All depends on how much time I have for this, ofc.)
>
> If we're changing interfaces, can we just remove the boxobject
> interfaces and move their methods to elements just like regular DOM
> elements?
>

We should do that for the nsIBoxObject and nsIScrollBoxObject. I don't
think it's possible for the others (tree, popup, etc) unless either we
don't mind adding a pile of methods to every element, or some way of
attaching the methods onto any kind of element.

/ Neil
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up BoxObjects

Robert O'Callahan-3
Neil Deakin wrote:
> We should do that for the nsIBoxObject and nsIScrollBoxObject. I don't
> think it's possible for the others (tree, popup, etc) unless either we
> don't mind adding a pile of methods to every element, or some way of
> attaching the methods onto any kind of element.

We only have to add tree and popup methods to tree and popup elements,
right?

I realize that all XUL elements are implemented by nsXULElement, but
there must be a way to get around this. Heck, XBL can do it.

Rob
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up BoxObjects

Neil Deakin
Robert O'Callahan wrote:

> We only have to add tree and popup methods to tree and popup elements,
> right?

There's a desire among many people to support the xul widgets in other
types of content such as html. There isn't anything preventing this
currently, apart from hardcoded tag references, or code that expects to
call functions available only to XUL Documents.

Ideally, the popup methods would be available in some form for any
element with display: -moz-popup

/ Neil
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up BoxObjects

Robert O'Callahan-3
Neil Deakin wrote:
> Robert O'Callahan wrote:
>
>> We only have to add tree and popup methods to tree and popup elements,
>> right?
>
> There's a desire among many people to support the xul widgets in other
> types of content such as html. There isn't anything preventing this
> currently, apart from hardcoded tag references, or code that expects to
> call functions available only to XUL Documents.

I hope you're talking about Web Forms 2.

> Ideally, the popup methods would be available in some form for any
> element with display: -moz-popup

I strongly believe that such widgets should be implemented as new
element types (possibly implemented by mapping XUL elements to HTML
aliases via XBL or XTF), not as magic display types.

Rob
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout