[Cuis-dev] LayoutMorph separation
Juan Vuletich
juan at cuis.st
Mon Aug 26 07:45:06 PDT 2024
Hi Bernhard,
On 8/25/2024 4:10 PM, Bernhard Pieber via Cuis-dev wrote:
> Hi,
>
> Sorry for the late reply. I just read this thread after a holiday away
> from the keyboard.
>
> It's great that that functionality got integrated. I had the same need
> and proposed a change set in May, see the email thread "LayoutMorph
> separate padding and spacing" [1] and my answer in the thread "morphs
> padding and margin" [2].
>
Apologies. I forgot about your contribution.
> However, instead of an additional boolean instance variable
> (useEdgeSpace) I chose to split separation into padding (inner
> distance to the borders) and spacing (distance between elements). I
> chose the name padding because that's how it's called in the CSS box
> model [3].
This is good. There's no reason to do it differently if what is well
known is perfectly fine, and doing it in our unique way only annoys
people without bringing an improvement.
> I did keep the instance variable separation in the first step, as it
> is currently used in UI-Panel and UI-Click-Select in
> Cuis-Smalltalk-UI. However, I prepared updates for those packages
> after which the instance variable separation should be deleted.
Please post your code for these packages. (see my suggestion below)
> In a third step the instance variable padding could be moved to the
> superclass BoxedMorph and be supplemented by the property margin
> (outer distance to the borders), which is also part of the CSS box
> model [3] and widely used in web design.
>
> I would ike this design because LayoutMorph would become simpler
> again, BoxedMorph would become more flexible and at the same time
> easier to understand for people with knowledge of CSS. What do you think?
I think this should be the first step, actually, as it impacts on the
resulting design for LayoutMorph.
This is my suggestion:
- BoxedMorph would have 2 "Borders": Border and Padding
- Padding is drawn the same as background, i.e. using the morph 'color'
- Padding behaves as an inner part of the current Border. Any code that
needs the boundary between current Border and the "inside" of the morph
would now get the boundary between Padding and the area inside it.
- Margin is only a property that a morph can be queried about, and is
part of its LayoutSpec. It is not considered part of the morph at all.
It is only used by the containing LayoutMorph. This design is consistent
with [1], that states: "Note: The margin property also affects the total
space that the box will take up on the page, but the margin is not
included in the actual size of the box. The box's total width and height
stops at the border."
So, Bernhard, the difference with your design would be:
- Margin is moved from LayoutMorph to the inner morphs, but to their
LayoutSpec. It is to be used in place of "separation" or "spacing".
- Padding is moved up to BorderedMorph as you suggest. LayoutMorphs
would inherit it. This means that any BorderedMorph could have a
non-zero padding of their contents
- LayoutMorph would no longer have 'separation' and 'margin', neither
'useEdgeSpace' nor a specific 'padding'.
I think this would cover all the suggested use cases.
Opinions?
[1] https://www.w3schools.com/css/css_boxmodel.asp
> Cheers,
> Bernhard
>
> [1] https://lists.cuis.st/mailman/archives/cuis-dev/2024-May/008772.html
> [2] https://lists.cuis.st/mailman/archives/cuis-dev/2024-June/009021.html
> [3]
> https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model#margins_padding_and_borders
>
Thanks,
--
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240826/caf2939a/attachment-0001.htm>
More information about the Cuis-dev
mailing list