Querying an nsIFrame for layout data

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

Querying an nsIFrame for layout data

Henri Sivonen
I need to get the following layout data for an element, and I think
getting it directly off the primary nsIFrame of the element is probably
the way to go. (Is it?)
 * Whether the element is being rendered (display: none; or visibility:
hidden;)
 * The rendering width and height of the element's box in CSS px.
 * The font size in px.

For font size, I see code like this around the codebase:
const nsStyleText* styleText = frame->GetStyleText();

Yet, by searching LXR and grepping my CVS sandbox I can't find the
definition of the GetStyleText() method. What am I missing?

For the width and height, I suppose I should use GetSize(). Am I right?
What's the right way to convert twips into CSS px or vice versa?

What's the right way to query display: none; and visibility: hidden;?
Does an element even have a primary nsIFrame if it has display: none;?

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

Re: Querying an nsIFrame for layout data

L. David Baron
On Friday 2006-06-02 00:00 +0300, Henri Sivonen wrote:
> Yet, by searching LXR and grepping my CVS sandbox I can't find the
> definition of the GetStyleText() method. What am I missing?

It's defined by defining the STYLE_STRUCT macro and including
nsStyleStructList.h:
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsIFrame.h#597

> For the width and height, I suppose I should use GetSize(). Am I right?

It depends what it is you want.  That gives you the border-box width,
although it can give you interesting results for display types that are
represented by multiple frames that are descendants of each other (e.g.,
'overflow:scroll', 'display:table-cell').

> What's the right way to convert twips into CSS px or vice versa?

Multiply by nsPresContext::TwipsToPixels().

> What's the right way to query display: none; and visibility: hidden;?
> Does an element even have a primary nsIFrame if it has display: none;?

Frames that are 'display:none' and their descendants are not created
when they are 'display:none'.  For visibility, GetStyleVisibility() (and
see nsStyleStruct.h.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Querying an nsIFrame for layout data

Boris Zbarsky
In reply to this post by Henri Sivonen
Henri Sivonen wrote:
> I need to get the following layout data for an element

Who is "I"?  That is, where does this code live?  nsIFrame is not exactly a
public API...

Furthermore, how do you want to handle elements that are rendered in multiple
places at once (eg <area> elements).

> and I think getting it directly off the primary nsIFrame of the element is probably
> the way to go.

What if there is no frame?

>  * Whether the element is being rendered (display: none; or visibility:
> hidden;)

Those are two very different things, for what it's worth....

>  * The rendering width and height of the element's box in CSS px.

This is assuming this box exists, right?  What if it doesn't?

>  * The font size in px.

Is this conditional on the CSS box existing?

> For font size, I see code like this around the codebase:
> const nsStyleText* styleText = frame->GetStyleText();
>
> Yet, by searching LXR and grepping my CVS sandbox I can't find the
> definition of the GetStyleText() method. What am I missing?

It's defined by a macro.  See
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsIFrame.h#598

> For the width and height, I suppose I should use GetSize(). Am I right?

This is conditional to the answers to my question above.

> What's the right way to convert twips into CSS px or vice versa?

NSTwipsToFloatPixels or NSTwipsToIntPixels, both of which need a scaling factor
off the prescontext.  Also see NSFloatPixelsToTwips and NSIntPixelsToTwips.  For
CSS px you want the ScaledPixels thing on prescontext.

> What's the right way to query display: none; and visibility: hidden;?

Again, depends on your answers to my questions above.

> Does an element even have a primary nsIFrame if it has display: none;?

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: Querying an nsIFrame for layout data

Henri Sivonen
In article <[hidden email]>,
 Boris Zbarsky <[hidden email]> wrote:

> Henri Sivonen wrote:
> > I need to get the following layout data for an element
>
> Who is "I"?  That is, where does this code live?  nsIFrame is not exactly a
> public API...

Right now the code lives (for my convenience) in my private copy of
layout/inspector/src/inDOMUtils.cpp. I wouldn't be too surprised if it
was eventually placed somewhere else.

The idea is to implement the algorithm from
https://bugzilla.mozilla.org/show_bug.cgi?id=31961
in C++.

> Furthermore, how do you want to handle elements that are rendered in multiple
> places at once (eg <area> elements).

Getting some reasonably sane data for <area> without crashing is good
enough, because there usually aren't significant subtrees rooted at
<area>.
 
> > and I think getting it directly off the primary nsIFrame of the element is
> > probably
> > the way to go.
>
> What if there is no frame?

But there are for (at least non-SVG) elements that are being rendered,
right?
 
> >  * Whether the element is being rendered (display: none; or visibility:
> > hidden;)
>
> Those are two very different things, for what it's worth....

I realize that. I just don't walk into subtrees that don't render.

> >  * The rendering width and height of the element's box in CSS px.
>
> This is assuming this box exists, right?  What if it doesn't?

I am assuming it always exists for elements that have a defined and
non-null contentDocument property and are neither display: none; nor
visibility: hidden;.

Is that a wrong assumption?

> >  * The font size in px.
>
> Is this conditional on the CSS box existing?

I am only interested in the font size for elements that aren't in
non-rendering (display: none; nor visibility: hidden;) subtrees.

> > For font size, I see code like this around the codebase:
> > const nsStyleText* styleText = frame->GetStyleText();
> >
> > Yet, by searching LXR and grepping my CVS sandbox I can't find the
> > definition of the GetStyleText() method. What am I missing?
>
> It's defined by a macro.  See
> http://lxr.mozilla.org/seamonkey/source/layout/generic/nsIFrame.h#598

Thanks.

> > For the width and height, I suppose I should use GetSize(). Am I right?
>
> This is conditional to the answers to my question above.

The idea is to check if an element that has a contentDocument is "small"
in the sense that its width or height is less than 130px. (This
heuristic should catch most ad <iframe>s.)

> > What's the right way to convert twips into CSS px or vice versa?
>
> NSTwipsToFloatPixels or NSTwipsToIntPixels, both of which need a scaling
> factor
> off the prescontext.  Also see NSFloatPixelsToTwips and NSIntPixelsToTwips.  
> For
> CSS px you want the ScaledPixels thing on prescontext.

Thanks.

> > Does an element even have a primary nsIFrame if it has display: none;?
>
> No.

That's a sufficient test then?

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

Re: Querying an nsIFrame for layout data

L. David Baron
On Friday 2006-06-02 01:25 +0300, Henri Sivonen wrote:
> The idea is to implement the algorithm from
> https://bugzilla.mozilla.org/show_bug.cgi?id=31961
> in C++.

We shouldn't do that until we have real zoom rather than text zoom.
Text zoom breaks properly-designed pages.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Querying an nsIFrame for layout data

L. David Baron
On Thursday 2006-06-01 15:33 -0700, L. David Baron wrote:
> On Friday 2006-06-02 01:25 +0300, Henri Sivonen wrote:
> > The idea is to implement the algorithm from
> > https://bugzilla.mozilla.org/show_bug.cgi?id=31961
> > in C++.
>
> We shouldn't do that until we have real zoom rather than text zoom.
> Text zoom breaks properly-designed pages.

Or at least we shouldn't do it by default.  And I think we should
consider doing it by default for 1.9.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Querying an nsIFrame for layout data

L. David Baron
In reply to this post by Henri Sivonen
On Friday 2006-06-02 01:25 +0300, Henri Sivonen wrote:
> Right now the code lives (for my convenience) in my private copy of
> layout/inspector/src/inDOMUtils.cpp. I wouldn't be too surprised if it
> was eventually placed somewhere else.
>
> The idea is to implement the algorithm from
> https://bugzilla.mozilla.org/show_bug.cgi?id=31961
> in C++.

Something like this should probably live on nsIMarkupDocumentViewer /
nsDocumentViewer.

> I am assuming it always exists for elements that have a defined and
> non-null contentDocument property and are neither display: none; nor
> visibility: hidden;.

visibility:hidden isn't particularly interesting and you probably don't
want to treat it specially.

> The idea is to check if an element that has a contentDocument is "small"
> in the sense that its width or height is less than 130px. (This
> heuristic should catch most ad <iframe>s.)

Why not just zoom each document independently?

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Querying an nsIFrame for layout data

Boris Zbarsky
In reply to this post by Henri Sivonen
Henri Sivonen wrote:
>> What if there is no frame?
>
> But there are for (at least non-SVG) elements that are being rendered,
> right?

Yes.

>>>  * Whether the element is being rendered (display: none; or visibility:
>>> hidden;)
>> Those are two very different things, for what it's worth....
>
> I realize that. I just don't walk into subtrees that don't render.

A visibility:hidden frame can have descendants that render.

>>>  * The rendering width and height of the element's box in CSS px.
>> This is assuming this box exists, right?  What if it doesn't?
>
> I am assuming it always exists for elements that have a defined and
> non-null contentDocument property and are neither display: none; nor
> visibility: hidden;.
>
> Is that a wrong assumption?

Yes.  HTML iframes that are kids of an SVG element will have a defined and
non-null contentDocument, and may have any values of display and visibility.

> I am only interested in the font size for elements that aren't in
> non-rendering (display: none; nor visibility: hidden;) subtrees.

Again, visibility:hidden only affects the rendering of the element itself, not
necessarily its descendants.  And again, display on its own doesn't guarantee
that a subtree is "rendered" when SVG gets involved.

>>> Does an element even have a primary nsIFrame if it has display: none;?
>> No.
>
> That's a sufficient test then?

Test for what?

-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: Querying an nsIFrame for layout data

Henri Sivonen
In article <[hidden email]>,
 Boris Zbarsky <[hidden email]> wrote:

> Henri Sivonen wrote:
> >> What if there is no frame?
> >
> > But there are for (at least non-SVG) elements that are being rendered,
> > right?
>
> Yes.

Good.

> A visibility:hidden frame can have descendants that render.

OK. I guess I'll drop the visibility: hidden; test.

> > I am assuming it always exists for elements that have a defined and
> > non-null contentDocument property and are neither display: none; nor
> > visibility: hidden;.
> >
> > Is that a wrong assumption?
>
> Yes.  HTML iframes that are kids of an SVG element will have a defined and
> non-null contentDocument, and may have any values of display and visibility.

OK, but I am not walking into SVG subtrees anyway.

> >>> Does an element even have a primary nsIFrame if it has display: none;?
> >> No.
> >
> > That's a sufficient test then?
>
> Test for what?

For testing that the element and the subtree is being rendered
(excluding cases that have SVG ancestry).

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

Re: Querying an nsIFrame for layout data

Boris Zbarsky
Henri Sivonen wrote:
> OK, but I am not walking into SVG subtrees anyway.

OK, but do you want to assume that no other languages like that are added?

>>>>> Does an element even have a primary nsIFrame if it has display: none;?
>>>> No.
>>> That's a sufficient test then?
>> Test for what?
>
> For testing that the element and the subtree is being rendered

You've never defined what you mean by "rendered", so I have no idea.

-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: Querying an nsIFrame for layout data

Henri Sivonen
In article <[hidden email]>,
 Boris Zbarsky <[hidden email]> wrote:

> Henri Sivonen wrote:
> > OK, but I am not walking into SVG subtrees anyway.
>
> OK, but do you want to assume that no other languages like that are added?

I'm not sure what kind of forward-looking precautions should be taken.
The alternative is, of course, that this code needs to be revised if
such a substantial change is made to the engine.

Is there a stable API that exposes the same data as getComputedStyle but
without converting the style system data to strings? The reason why I am
looking at nsIFrame is to avoid the overhead of going via string
representations of data that exists as numbers and enumerations.

> >>>>> Does an element even have a primary nsIFrame if it has display: none;?
> >>>> No.
> >>> That's a sufficient test then?
> >> Test for what?
> >
> > For testing that the element and the subtree is being rendered
>
> You've never defined what you mean by "rendered", so I have no idea.

For the purpose of what I am interested in for this feature, an element
is rendered if its non-whitespace text content was visible (assuming
different color and background) to the user if the view port was tall
enough not to clip the canvas at all. If the CSS boxes of elements
overlap, I'd preliminarily consider the elements that are left behind
the other boxes to be "rendered", but I don't care that much if the API
I end up using does not consider them to be rendered.

So "rendered" only needs to fit reasonably well with an intuitive
understanding of what is visible on the page (if scrolled). This is used
for a heuristic, so it is pragmatic to let the data that is exposed by
the available interfaces to dictate the details.

I haven't explored how XBL affects an nsIFrame-based approach.

And so far, I have no idea how to deal with SVG except by not walking
into SVG subtrees at all.

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

Re: Querying an nsIFrame for layout data

Boris Zbarsky
Henri Sivonen wrote:
> I'm not sure what kind of forward-looking precautions should be taken.

If it's easy to take, it should.  It significantly reduces complexity and
developer brain-print if people don't have to remember to check whether your
code needs fixing every time they make changes to frame construction.

> The alternative is, of course, that this code needs to be revised if
> such a substantial change is made to the engine.

Or even if some aspect of frame construction changes such that frames are or are
not created in various cases (something we do for SVG already, and might want to
do for XUL, and do in some cases for tables but want to stop, etc).

> Is there a stable API that exposes the same data as getComputedStyle but
> without converting the style system data to strings?

No.  What would the interface actually output?  The actual values stored in the
style data are an internal implementation detail and are NOT stable, so any
stable API would need to convert from those to something else.

> The reason why I am looking at nsIFrame is to avoid the overhead of going via string
> representations of data that exists as numbers and enumerations.

How significant is this overhead in your case, compared to the other things
going on?

> For the purpose of what I am interested in for this feature, an element
> is rendered if its non-whitespace text content was visible (assuming
> different color and background)

So something with "opacity:0" is not "rendered", right?  And a node that has no
non-whitespace textnode descendants (eg a table of images) is not "rendered" either?

Your definition of "rendered" does, more or less, have having an nsIFrame as a
prerequisite (SVG aside).  Having an nsIFrame doesn't guarantee "rendered", of
course, as per the above examples.

> So "rendered" only needs to fit reasonably well with an intuitive
> understanding of what is visible on the page (if scrolled). This is used
> for a heuristic, so it is pragmatic to let the data that is exposed by
> the available interfaces to dictate the details.

OK.

-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: Querying an nsIFrame for layout data

Henri Sivonen
In article <[hidden email]>,
 Boris Zbarsky <[hidden email]> wrote:

> Henri Sivonen wrote:

> > Is there a stable API that exposes the same data as getComputedStyle but
> > without converting the style system data to strings?
>
> No.  What would the interface actually output?

I was thinking of using an enum as the style property input and
enumerations as output for stuff like display and floats (in twips or
better yet, in CSS px) for lengths.

> > The reason why I am looking at nsIFrame is to avoid the overhead of going
> > via string
> > representations of data that exists as numbers and enumerations.
>
> How significant is this overhead in your case, compared to the other things
> going on?

I don't know really.

Walking the DOM should be pretty fast as it only touches nodes and does
not create any. Unless, of course, queryInterface in XPCOM instantiates
interface proxies at that point or something like that. Presumably, the
JavaScript side is actually allocating wrapper object at this point,
right? For reference, I timed Java code walking the DOM of the Web Apps
1.0 test case (without comment nodes) using the Xerces DOM and the walk
took 7 milliseconds on average with warmed caches on dualcore 2GHz
PowerMac G5. (If I have understood correctly, the Java case genuinely
only involves pointer dereferencing without memory allocation during the
walk.)

Going with strings would involve allocation overhead, whereas nsIFrame
returns pointers to structs that are already there, so that might make a
notable difference, assuming that the DOM walk does not actually
allocate memory. But even so, the difference in wall clock time could be
negligible.

But this is only speculation. I have no idea and I am not at all
familiar with the actual overhead of XPCOM DOM access.

> > For the purpose of what I am interested in for this feature, an element
> > is rendered if its non-whitespace text content was visible (assuming
> > different color and background)
>
> So something with "opacity:0" is not "rendered", right?  

According to my definition, not, but the heuristic may not need to care.

> And a node that has
> no
> non-whitespace textnode descendants (eg a table of images) is not "rendered"
> either?

Well, not in any sense that is of interest to the heuristic.

> Your definition of "rendered" does, more or less, have having an nsIFrame as
> a prerequisite (SVG aside).

Excellent

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

Re: Querying an nsIFrame for layout data

Boris Zbarsky
Henri Sivonen wrote:
> Walking the DOM should be pretty fast as it only touches nodes and does
> not create any.

It has to create a bunch of wrappers (two per node), lots of JS functions if
you're walking the DOM yourself, etc.  Of course if you walk in C++ it's faster.

> Unless, of course, queryInterface in XPCOM instantiates
> interface proxies at that point or something like that.

For some interfaces, we do use tearoffs.  Stuff like nsIDOM3Node.

> Presumably, the JavaScript side is actually allocating wrapper object at this point,
> right?

Two wrappers, since you're chrome touching content.  And this is done in
XPConnect, not JavaScript.

> For reference, I timed Java code walking the DOM of the Web Apps
> 1.0 test case (without comment nodes) using the Xerces DOM

Almost irrelevant, since we have a different DOM impl, etc.

> Going with strings would involve allocation overhead, whereas nsIFrame
> returns pointers to structs that are already there, so that might make a
> notable difference, assuming that the DOM walk does not actually
> allocate memory. But even so, the difference in wall clock time could be
> negligible.

Testing or profiling are the way to go, imo.  As in, get it working, test, then
optimize as needed.

-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: Querying an nsIFrame for layout data

Henri Sivonen
In reply to this post by Henri Sivonen
In article
<[hidden email]>,
 "L. David Baron" <[hidden email]> wrote:

> On Friday 2006-06-02 01:25 +0300, Henri Sivonen wrote:
> > Right now the code lives (for my convenience) in my private copy of
> > layout/inspector/src/inDOMUtils.cpp. I wouldn't be too surprised if it
> > was eventually placed somewhere else.
> >
> > The idea is to implement the algorithm from
> > https://bugzilla.mozilla.org/show bug.cgi?id=31961
> > in C++.
>
> Something like this should probably live on nsIMarkupDocumentViewer /
> nsDocumentViewer.

My current patch is at
https://bugzilla.mozilla.org/attachment.cgi?id=224534

Should I move the rest of my JS changes to the C++ side and add an
autoZoom() method to nsIMarkupDocumentViewer / nsDocumentViewer instead
of adding a scriptable method for getting the dominant size? If I move
the code over, what's the right way to get the presShell for the
nsIDOMDocument? I assume it is not OK for nsDocumentViewer to depend on
DOM Inspector.

Of course, one could active the autozoom when a negative value is used
as the zoom level, which would keep the interface as is, but that seem
dirty. How big a deal is the addition of a method to
nsIMarkupDocumentViewer which is visible to extensions?

> > I am assuming it always exists for elements that have a defined and
> > non-null contentDocument property and are neither display: none; nor
> > visibility: hidden;.
>
> visibility:hidden isn't particularly interesting and you probably don't
> want to treat it specially.

OK. Not caring about it.

> > The idea is to check if an element that has a contentDocument is "small"
> > in the sense that its width or height is less than 130px. (This
> > heuristic should catch most ad <iframe>s.)
>
> Why not just zoom each document independently?

It didn't occur to me, because I didn't know different frames can be
zoomed independently. Back in the pre-Firefox days, there was the UI
option for zooming to a custom level, so I was thinking of picking that
number automatically.

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

Re: Querying an nsIFrame for layout data

Henri Sivonen
In reply to this post by L. David Baron
In article
<[hidden email]>,
 "L. David Baron" <[hidden email]> wrote:

> On Thursday 2006-06-01 15:33 -0700, L. David Baron wrote:
> > On Friday 2006-06-02 01:25 +0300, Henri Sivonen wrote:
> > > The idea is to implement the algorithm from
> > > https://bugzilla.mozilla.org/show bug.cgi?id=31961
> > > in C++.
> >
> > We shouldn't do that until we have real zoom rather than text zoom.
> > Text zoom breaks properly-designed pages.
>
> Or at least we shouldn't do it by default.  And I think we should
> consider doing it by default for 1.9.

This is in no way intended to happen by default. As an user-invokable
zoom command, it will not cause any more breakage than providing a text
zoom in the first place. It the user needs to zoom, (s)he probably cares
more about zooming than about layout breakage.

On the other hand, doing it by default would risk page authors taking
counter measures, which would cause an arms race. I think features like
this should be extremely easy for the user to invoke, but, by default,
the UA should please page authors in order to avoid counter measures.

And I think a font zoom has merit compared to an Opera-style "real"
zoom. (Opera's zoom has merit, too.) Many times Opera's zoom causes
horizontal scrolling where a font zoom does not.

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout