-1

I'm trying to understand inline and block level elements fully.

Can someone please explain the below behavior?

p {
    border: 1px solid black;
}

span {
    border: 1px solid red;
}
<body>
    <span>
        <p>hello</p>
    </span>
</body>

Why is the p element overflowing the span?

to my understating block-level elements take the full width of their container.

the container of the p element is the span. but the p element is taking the full width of the screen.

why is causing this behavior?

Liam Anderson
  • 47
  • 3
  • 3
    Because `` is not _container (block) element_ – Justinas Oct 30 '22 at 16:11
  • 2
    because it is an invalid markup. `span` is an inline element and only allows inline-content. `p` is a block-level element and as such not an allowed child element of a span. An inline-element by default has no defined width. It's width is calculated to `fit-content`. The `p` however has a width of 100% which means 100% of the parent's width. In this case it would be 100% of undefined and as such gives an error that causes an overflow. – tacoshy Oct 30 '22 at 16:14
  • the linked question tells what the behavior is, but doesn't explain the theory behind it. my question is why does the

    element overflow the span element?

     – Liam Anderson Oct 30 '22 at 16:17
  • The p element in this case, is taking the width of the span's parent, which is body is this case. is there a reason why it does that? – Liam Anderson Oct 30 '22 at 16:20
  • 1
    None of this matters because such HTML is invalid. A `` element cannot contain a `

    ` element.

     – Rob Oct 30 '22 at 16:43
  • @Rob - You could replace the `` element with an `` element. You'd get exactly the same rendering behaviour, and the HTML would be valid. – Alohci Oct 30 '22 at 16:46
  • @Alohci One can change his markup in all kinds of ways but it's not part of his question and, therefore, why I brought it up. – Rob Oct 30 '22 at 16:47

1 Answers1

1

From the CSS 2 specification:

When an inline box contains an in-flow block-level box, the inline box ... is broken around the block-level box ..., splitting the inline box into two boxes ..., one on each side of the block-level box(es). The line boxes before the break and after the break are enclosed in anonymous block boxes, and the block-level box becomes a sibling of those anonymous boxes.

So the <p> element isn't overflowing the <span> element, it's breaking it in two.

Alohci
  • 78,296
  • 16
  • 112
  • 156
  • 1
    It doesn't matter because it's invalid HTML. – Rob Oct 30 '22 at 16:43
  • Whether the HTML is valid or not is irrelevant. Browsers don't care whether HTML is valid or not. The behaviour is entirely mechanical. – Alohci Oct 30 '22 at 16:50
  • 1
    That's an amateur's comment that encourages bad behavior. I am shocked you would say such a thing. You should know better than that. – Rob Oct 30 '22 at 16:52
  • 1
    Nope. The OP is asking about how to understand browser behaviour. I'm not here to police their authoring practices. – Alohci Oct 30 '22 at 16:54
  • 1
    @Rob what you suggest is that the browser should stop working when there is an invalid code but it's not the case. The browser will always *try* to produce an output whatever the code you give and a lot of developers spent hours implementing such behavior so it doesn't hurt if we explain the effort done behind the scenes. There are a lot of cases where an invalid code produce a strange result that has an explanation somewhere. – Temani Afif Oct 30 '22 at 19:47
  • @TemaniAfif I said no such thing. I said incorrect markup is wrong and should be corrected and not used. Any attempts to help someone with incorrect/invalid markup only encourages bad behavior and bad code. Where in all that do you get that I said a browser should stop working? – Rob Oct 30 '22 at 23:40
  • So I figured this out. In this case the answer to the question can be found at https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block meaning that the containing block of the p element is actually the body in this case. – Liam Anderson Nov 02 '22 at 21:00