- This topic is empty.
-
AuthorPosts
-
January 13, 2015 at 12:17 pm #193109
spz1st
ParticipantThis is meant for discussion or debate. I’m not sure if it’s appropriate to post this here or if it has been brought up before.
I find the relation between width/height settings and margin/padding/border settings is not only sort of against intuition, but also makes it hard (if not impossible) to achieve certain page layouts.
I think the margin/padding/border should be subtracted from the width and height of the element instead of adding into it. That is, if I set a width and/or height for a div, then if I also set a margin and/or padding for the div, the margin/padding should be part of the width/height. For example, suppose I have a page with two divs, one to the left, one to the right. I set the width to be 100% for body, 30% for the left div and 70% for the right div, and I want the two divs to cover the entire page horizontally without scrollbars (within the limit of the content size). As shown in the demo at the links below, with no margin, padding and border, the left div and right div are aligned next to each other and cover the entire page as expected. But if I set a margin or padding to the divs, the margin or padding should be set aside inside the divs without expanding the divs or adding spaces outside the divs. But in the current implementation, if I set a margin, padding or even a border, spaces are added to the divs (either inside or outside of the divs) and the layout is destroyed. In this case, there’s no way for me to achieve what I want without resorting to javascript (the width percentage for at least one of the divs have to be calculated precisely and recalculated every time the window is resized.
If margin/padding/border were part of the width/height, there would be no such problem. I think that except width and height, all other stylings should only affect the element itself, not its parent elements. The width and height should set a sandbox for the element and whatever you do to the element should not spill out of the sandbox. This way, it would be much easier to design the layout of a page. Each block element is a sandbox once its width and height are set, you wouldn’t need to worry that it might throw your overall layout off when you style it.
demo without border: http://arvha.com/layout1.html
demo with border:
http://arvha.com/layout2.htmlJanuary 13, 2015 at 12:41 pm #193113Shikkediel
ParticipantThat’s what we have
box-sizing: border-box
for. :-)Edit – doesn’t include margin though (but justly so).
January 13, 2015 at 2:49 pm #193123spz1st
ParticipantRight, there’s box-sizing to deal with padding and border. But my point is that the width and height should include margin/padding/border by default. This way it would be much easier to layout elements. It’s a natural way to consider width and height first for each element so they can be fitted into the page nicely, then you set the margin/padding/border individually for each element. If width and height included margin/padding/border, you would be able to set margin/padding/border freely without having to worry about their effect on the overall layout and adjusting width/height every time you change margin/padding/border in order to preserve the original overall layout (currently not always possible to preserve the original overall layout as shown in my demo examples). This is more in accordance with real life experiences. For example, the page size includes margins.
January 13, 2015 at 3:05 pm #193124spz1st
ParticipantNow of course there’s no way (and not good at all) to redefine width and height (it’d break all the current pages), but I like to propose to add a new value to box-sizing, say all-box (or just all) to have width/height contain margin/padding/border. I’m sure if it’s implemented, people will use it in most, if not all, cases.
January 13, 2015 at 3:40 pm #193129Shikkediel
ParticipantI agree there, margin is ’empty’ space while border and padding are part of the content itself. But default CSS is a bit counterintuitive.
January 13, 2015 at 4:47 pm #193143spz1st
ParticipantIt depends on how you view the element. You can view the element as an area where you display contents (text, image, etc.) in certain ways, such as with or without a margin, a border, and/or a padding. Then width and height are used to set the size of the area (element).
Had margins been included in width and height from the begin, a css type (say such as “float: 0 center;”, or use placement instead of float) could have been defined to achieve what current “margin: 0 auto” may achieve.
I like to add that the current way of rendering with respect to width/height and margin/padding/border is not only counterintuitive, but also makes it harder, if not impossible, to get a desired layout.
January 13, 2015 at 5:25 pm #193147Senff
ParticipantA border and padding are existential parts of the element itself. Which is why they are part of box-sizing:border-box.
The margin however, is specifically defined as “space NEXT to an element where it’s a ‘no-go’ area“. Not in those exact words (duh) but it defines the margin as something that’s not part of the element itself, which is why it’s not part of box-sizing:border-box.
(Pretty deep!)
January 13, 2015 at 5:35 pm #193148spz1st
ParticipantI certainly agree that different people have different views on the matter and I’ve given mine. ;-) But I do hope that there’ll be a new css type to have margins included in width/height. In so many occasions that I wished margins were part of width/height. That would make it much much easier to achieve certain layouts. In many cases it’s impossible to achieve a precise layout with css styling and I had to do with a compromise (such as accepting scrollbars where there were no need for them at all because a margin pushed the total width or height beyond the window’s size) or resort to javascript to achieve a precise layout. All those problems would go away if I had a way to have margins included in width/height.
January 13, 2015 at 6:23 pm #193154spz1st
ParticipantAs I said earlier that it depends on how you view/define an element. If an element had been defined as an area to display something in certain ways and width and height were defined to set the size of the area, then margins could be part of width and height because width and height here were used to set the size of the area, not the size of the content per se. Then within the area, you could set the margin, border, and/or padding for the content to be displayed in the area. Certainly I’m not seeking to redefine the element, width/height, margin now. But I do hope to have a new css type to direct the browser to include margins in width/height. When you design a web page, it’s so natural to just set width and height first for various elements to get the desired layout (you can set the background of the elements with different colors to visualize them). Once you get the layout worked out, you will begin to style each element one by one. But currently you can’t style individual elements without having to worry about ruining the original layout (sometimes you have no way to prevent it) and you have to change width/height every time you set/change the margin for an element. If margins were included in width/height, you wouldn’t have such problem and the page setting would be much simpler and easier.
January 14, 2015 at 2:26 pm #193256spz1st
ParticipantHere is a case of inconsistence of width/height definition and/or implementation. One of the arguments why width/height should not include margins is that an element does not include margins and width and height are set for the element, therefore they should not include margins. Now I have an element of 100px for width and height and with a blue background. According to this argument, if I position this element, say at left: 100px; top: 100px;, and I add a margin, say 10px in thickness, to the element, the upper-left corner of the blue square should still stay at 100,100, right? That is, the upper-left corner of the margin should be at 90,90. Yet the two browsers (chrome and safari) I use pushed the blue square to 110,110 and the upper-left margin is at 100,100. Clearly here the margin is considered as the part of the element.
Here is the demo page: http://www.arvha.com/position.html
January 14, 2015 at 4:58 pm #193263spz1st
ParticipantThe issue here is whether or not an element include margins. Whether or not it has a fixed position is irrelevant. Here I positioned the element as a square block to a specific point. If the margin is not considered as a part of the element, then adding a margin should not move the block. Why should the added margin take the position of the element if it’s not a part of the element?
January 14, 2015 at 5:34 pm #193270Shikkediel
ParticipantIt’s not related to itself but to the parent or neighbour.
January 15, 2015 at 7:10 am #193327spz1st
ParticipantThe issue here is the margin a part of the element or not? If yes, then why the width and height set for the element don’t include it? If no, then why it takes the spot set for the element? Of course you may answer yes or no. Then you just prove my point that it’s inconsistent with respect to the treatment of margin.
Any way, no matter how do you view it, my point is that in practice, it would make layout setting much much simpler and easier if width and height included margin, border and padding. Currently it not only make it hard to do layouts (for example, if you adjust margins/border/padding, you also have to adjust width/height to preserve the original layout), but also make many desirable layouts impossible to achieve (unless you use javascript).
January 15, 2015 at 9:55 am #193340Shikkediel
ParticipantIt’s not related to itself but to the parent or neighbour.
The issue here is the margin a part of the element or not?
So no. In the impossible but hypothetical circumstance where the element would have no parent, margin would not apply. So it’s not an inherent part of the element. Not sure how you’d imagine margin if it were – some inset displacement on itself?
January 15, 2015 at 10:21 pm #193394spz1st
ParticipantThis is the thing I disagree with. Margins should not be included in an element’s measurements. This would make it significantly more difficult to build layouts. For example, in order to get consistent effective margins, you would have to know and adjust the margins of all adjacent elements. “margin collapse” exists for a reason.
Comparing to troubles you have now, what you mentioned is almost nothing. To consistent margins without margin collapses, you can just set the margin the same for all the elements (maybe except for those on the edges of the page). For example, here is a page: http://arvha.com/apage.html. Now try to add some padding/border/margins of different sizes to some or all those elements. Every time you add or change a padding/border/margin, you’ll have to change the width/height to preserve the overall layout. If padding/border/margin were included in width/height, you wouldn’t have such troubles.
Are you having a specific issue? or do you have an example of a layout which suffers from these problems? Perhaps we could help out with a concrete example.
Okay here is an example: http://arvha.com/apage2.html
I want the elements to always cover the whole page horizontally and show no scrollbar when you resize the window. And I want the middle three panels have the exact percentage width. That is, the two blue panels have 25% of the window’s width each and the middle orange panel has 50% of the window’s width. Now try to add some margins to the elements. After margins are added, those three middle panels should still have the same percentage settings (including their margins). And I want the margins kept separate.
Here I want to see 1. if you can achieve it; 2. how much effort you need to achieve it if you do; 3. how much simpler/easier if the width/height included margin (and border/padding). Obviously for 3, it’d be very straight forward to add margin/border/padding should width/height include margin/border/padding.
-
AuthorPosts
- The forum ‘Other’ is closed to new topics and replies.