I have a file which contains component definitions, along with their
x/y coordinates and width and height. Examples for components are a
short text string, a text entry field, a date entry field, a
selection box, a checkbox.
The aim is to produce an HTML page that looks like those definitions
specify.
So I computed a grid which covers all the corners of all components
(actually only top left corners) and created an HTML table with
appropriate row heights and column widths. Into that table I
positioned all the elements and gave them the right width and height.
So far, so good.
Now, comes along a new kind of component, a frame. It has the usual
location and dimension attributes, plus some text, which is used as a
title, like so:
+-example frame--------+
| |
| |
| |
+----------------------+
I hope you can see the ascii graphics.
The idea behind the frame is that the frame frames all of the
components that are inside it.
(What happens when a component overlaps a frame border is
unspecified. They are drawn on top of each other, I guess. I'd
rather ignore this problem and pretend that all components will be
either fully inside a frame, or fully outside it.)
A logical implementation for this kind of frame would be the an HTML
table with a border. But this implementation doesn't fit the current
grid implementation too well. A way to deal with this is to do a
kind of a recursive layout, where I figure out which components are
inside the frame and then recursively call my table-building
algorithm for those.
Can you think of a clever HTML trick that would help me to avoid this?
For example, it might be possible to decompose the frame into the four
sides, and to consider each of them a separate component. Then I
could compute table rows and columns normally for the four sides. But
I'm afraid that the lines for the sides would then not join
correctly. (How to draw horizontal and vertical lines in HTML?)
Another approach might be to use absolute positioning with CSS. It
would lead to a simple algorithm, since the input is close to the
output. But if the browser doesn't grok absolute positioning, then
this approach will show nothing useful, whereas the table approach
might produce something that at least topologically looks like the
specification. Thus, I decided against the absolute positioning
approach. WDYT?
Kai
x/y coordinates and width and height. Examples for components are a
short text string, a text entry field, a date entry field, a
selection box, a checkbox.
The aim is to produce an HTML page that looks like those definitions
specify.
So I computed a grid which covers all the corners of all components
(actually only top left corners) and created an HTML table with
appropriate row heights and column widths. Into that table I
positioned all the elements and gave them the right width and height.
So far, so good.
Now, comes along a new kind of component, a frame. It has the usual
location and dimension attributes, plus some text, which is used as a
title, like so:
+-example frame--------+
| |
| |
| |
+----------------------+
I hope you can see the ascii graphics.
The idea behind the frame is that the frame frames all of the
components that are inside it.
(What happens when a component overlaps a frame border is
unspecified. They are drawn on top of each other, I guess. I'd
rather ignore this problem and pretend that all components will be
either fully inside a frame, or fully outside it.)
A logical implementation for this kind of frame would be the an HTML
table with a border. But this implementation doesn't fit the current
grid implementation too well. A way to deal with this is to do a
kind of a recursive layout, where I figure out which components are
inside the frame and then recursively call my table-building
algorithm for those.
Can you think of a clever HTML trick that would help me to avoid this?
For example, it might be possible to decompose the frame into the four
sides, and to consider each of them a separate component. Then I
could compute table rows and columns normally for the four sides. But
I'm afraid that the lines for the sides would then not join
correctly. (How to draw horizontal and vertical lines in HTML?)
Another approach might be to use absolute positioning with CSS. It
would lead to a simple algorithm, since the input is close to the
output. But if the browser doesn't grok absolute positioning, then
this approach will show nothing useful, whereas the table approach
might produce something that at least topologically looks like the
specification. Thus, I decided against the absolute positioning
approach. WDYT?
Kai
Comment