- This topic is empty.
-
AuthorPosts
-
January 15, 2015 at 10:33 pm #193395spz1stParticipant
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?
As I said before that it depends on how you define the element. If an element were define as an area to display something, then margin would certainly a part of the element. The element can have margin, border, padding and/or content per se, all optional.
January 15, 2015 at 11:10 pm #193396ShikkedielParticipantAnd it’s justly defined as not being a part of the element nor is it actually being displayed or clickable. Your approach would make margin superfluous altogether.
You can’t say – be 100% width, add empty space but still be 100% width anyway. Use CSS calc in your example. No JavaScript needed.
January 15, 2015 at 11:47 pm #193397ShikkedielParticipantNow if your suggestion were to add a new layer to the box model – for example ‘sphere’ which would be similar to padding but outside the border that could be interesting. One wouldn’t need a parent then in some cases. Too much to lose to reduce margin to this though…
January 16, 2015 at 8:00 am #193430spz1stParticipantAnd it’s justly defined as not being a part of the element nor is it actually being displayed or clickable. Your approach would make margin superfluous altogether.
You could keep the behavior of margin the way it is now (for example not clickable) except it’s added within width/height boundary.
You can’t say – be 100% width, add empty space but still be 100% width anyway. Use CSS calc in your example. No JavaScript needed.
That’s exactly because width doesn’t include margin. It makes it impossible to achieve certain layouts and causes lots of troubles for achieving many others.
January 16, 2015 at 8:20 am #193435spz1stParticipantNow if your suggestion were to add a new layer to the box model – for example ‘sphere’ which would be similar to padding but outside the border that could be interesting. One wouldn’t need a parent then in some cases. Too much to lose to reduce margin to this though…
I had proposed to add a new property for box-sizing, say all-box, to have margin get the same treatment as border/padding with border-box (see my earlier posts). All-box should also include border-box. As I said before, I’m certainly not seeking to redefine everything (width/height, margin, border, and padding) now. It’s certainly unthinkable to redefine them now. But I hope to get a remedy to it. Here I’m trying to show that it’d be much simpler and easier to achieve many layouts if width/height included margin/border/padding. As someone said he’s happy to use box-sizing for all his pages. I bet many people would be happy if a similar treatment were available for margin. Surely people use box-sizing to eliminate problems with border/padding, but the same problem is still there with margin.
January 16, 2015 at 11:22 pm #193467ShikkedielParticipantLet me throw in another one. Something I hadn’t noticed before but what seems to me a serious flaw with box-sizing. Padding and border aren’t included in the actual dimension when it is transferred to a child element. Here you can see that the parent has dimensions as specified, even with padding and border applied. But if you set the child to 100% width and height, the properties are suddenly subtracted!
That’s just weird. And frankly a bit annoying.
Edit – coming back on the previous discussion, let’s include outline to box-sizing as an alternative…
January 17, 2015 at 8:35 am #193488SenffParticipantBut if you set the child to 100% width and height, the properties are suddenly subtracted!
Not really weird, that’s by design. Child elements do not inherit a parent’s
box-sizing
property, so that’s expected behavior. The parent element has a width of 300px, but due to the padding and the border, the available space inside is 180px, so that’s what the child gets.January 17, 2015 at 8:41 am #193489spz1stParticipantLet me throw in another one. Something I hadn’t noticed before but what seems to me a serious flaw with box-sizing. Padding and border aren’t included in the actual dimension when it is transferred to a child element. Here you can see that the parent has dimensions as specified, even with padding and border applied. But if you set the child to 100% width and height, the properties are suddenly subtracted!
Seems to me it’s expected behavior. For #one, after taking out border and padding, what’s left is for content per se. Suppose you replace the div #two with some text, the text should be enclosed in a box of 180 x 30. So what’s available for #two should have the same dimension.
January 17, 2015 at 10:51 am #193490ShikkedielParticipantYeah, based on the content box but in my mind undesirable…
January 17, 2015 at 12:43 pm #193495ShikkedielParticipantNo doubt it has a reason but it’s not very handy if you want to make a box-sized hover menu. You get the same kind of issue it was ‘invented’ for in the first place (only in reverse) :
http://codepen.io/Shikkediel/pen/LEyYpp
Maybe spz1st can include a style addition in the new spec. ;-)
#child { width 100% border-box }
January 17, 2015 at 2:07 pm #193498spz1stParticipantIf you’re going to start making up your own definitions for things, then there’s no point in continuing this discussion.
When I asked if you had a specific question earlier, it was so I could determine if there was anything I could actually help you with. If you only want to share your opinion, you have done so. I don’t agree. That’s OK.
As I said when I started this thread, I brought up the issue for discussion or debate on pros and cons of width/height not including margin/border/padding, and hopefully a remedy may be devised to deal with the cons (I proposed to have a new property for box-sizing to include margin in width/height). So far I only see cons. And as I see here, the argument against width/height including margin/border/padding is purely based on the narrow definition of an element to be the part of content per se. This is just a conceptional or theoretical issue and can be easily dealt with by viewing the element differently.
As to if I have a specific problem to deal with, I’ve given an example in one of my earlier posts.
January 17, 2015 at 2:16 pm #193499spz1stParticipantNo doubt it has a reason but it’s not very handy if you want to make a box-sized hover menu. You get the same kind of issue it was ‘invented’ for in the first place (only in reverse) :
Not sure if I understand your intention here, can you put the hover on the parent?
January 17, 2015 at 2:55 pm #193500ShikkedielParticipantOn my turn, I don’t know what that means. Lol.
But as you can see on the pen, using box sizing I can’t access the parent’s actual width easily to position the sub elements (100% from the top and the next level 100% from the left). It’s subtle because only a 1px border is used but these have to be accounted for again.
Exactly what one would try to avoid with box-sizing. -
AuthorPosts
- The forum ‘Other’ is closed to new topics and replies.