6

I sometimes find it convenient to give the size of an element in terms of the bottom, top, left and right properties, rather than using width and height. This is, for example, the accepted answer here:

CSS 100% height with padding/margin

However, for some reason this doesn't work with an svg element. I've tried the following example with the latest stable Firefox and Chrome. The svg element inexplicably wants to take a size of 300x150:

Fiddle

Why?

Community
  • 1
  • 1
mhelvens
  • 4,225
  • 4
  • 31
  • 55

1 Answers1

9

While it's not mentioned directly in the spec (at least in my knowledge)<svg> is considered as a replaced element (unlike <div> which is a non-replaced block level element).

For absolutely positioned replaced elements, if the values of top/bottom are over-constrained, once you set a value for top, bottom would be ignored. This is true for left/right properties as well.

10.3 Calculating widths and margins / 10.3.8 Absolutely positioned, replaced elements

  1. If at this point the values are over-constrained, ignore the value for either 'left' (in case the 'direction' property of the containing block is 'rtl') or 'right' (in case 'direction' is 'ltr') and solve for that value.

10.6 Calculating heights and margins / 10.6.5 Absolutely positioned, replaced elements

  1. If at this point the values are over-constrained, ignore the value for 'bottom' and solve for that value.

Hence the absolutely positioned <svg> element would be position with the respect to top and left offsets.

Hashem Qolami
  • 97,268
  • 26
  • 150
  • 164
  • Interesting. Yes, that must be it. Thanks! Though I have to say, I don't like how they handled this. **(1)** *"A replaced element often has intrinsic dimensions"*... so not always, and they should respect `right` and `bottom` for elements that don't. **(2)** Even if an element has intrinsic dimensions, isn't it my prerogative to override those? Making `top`/`bottom`/`left`/`right` inconsistent with `width`/`height` does not seem like an elegant move. – mhelvens Oct 03 '14 at 20:00
  • @mhelvens Well, I agree with your point of view but I'm not aware of the actual reason behind this treatment/convention. However for the second question, in fact you *can* [alter/override dimensions](http://jsfiddle.net/Rpdr9/1929/) of the replaced element (via `width`/`height` just like images). The issue is not about the `width`/`height` but it's about how `top`/`bottom` and `left`/`right` properties interact with each other. – Hashem Qolami Oct 03 '14 at 20:56
  • With that second comment I just meant this: There are some basic equations that you'd simply expect to hold: `left + width = right` and `top + height = bottom` (sort of; you know what I mean). But they sort of drew this arbitrary line, where `width`/`height` can override intrinsic dimensions, but `top`/`left`/`right`/`bottom` can't, breaking those basic equations. Furthermore, doing so forces the spec to make the rather arbitrary decision that `top` is more important than `bottom`. – mhelvens Oct 04 '14 at 08:06
  • For completeness sake, the actual equations I meant are `left + width + right = parentContentWidth` and `top + height + bottom = parentContentHeight`. – mhelvens Oct 04 '14 at 08:15
  • @mhelvens Reasons behind conventions are not explained in the spec. I think questions like *"Why do absolutely positioned replaced elements treat like so", "Why isn't margin applicable to table-cells", "Why is a percentage value on top/bottom margin/padding relative to the width of the containing block"*, ... are better asked on [WWW-style mailing list](http://lists.w3.org/Archives/Public/www-style/). There might be a technical reason. Just found a similar topic about behavior of `overflow` property [here](http://stackoverflow.com/q/9943503/1725764). – Hashem Qolami Oct 04 '14 at 21:51