CSS sector targeting error for nested DIVs

HTML & CSS
1

I am familiar with the concept of inheritance but cannot determine how to fix my CSS. Because I’m using an iframe tag, it appears that unless I set the desired height attribute for head, body, div (the one marked with ID content), and iframe to 98% (or any other desired number), the presentation collapses. Each tag seems to requires the height attribute. (This is my first use of the iframe tag.)

When I tried to introduce another div for the two anchors - nested within the wrapper div and at the same rank as content, it too inherited the 98% height attribute. All of my attempts to separately target the nav and content divs failed. The current code seems to work only if the height attribute is assigned to div (i.e., all divs).

I recognize that I could drop the wrapper div, move the wrapper css to the body, and then encompass the anchor elements in a separate div, but I prefer to retain the wrapper structure and learn what is needed to separately target the nav and content divs (or otherwise prevent the iframe from collapsing).

As newly-signed up user, I ran into difficulties including the code here (number of links limited); the code can be found at: https://susepaste.org/70406440

2

Hi,

To understand the concept of percentage height in terms of css the first thing you need to know is that you can only base a percentage height on a parent that has a height defined (other than auto or content height). If the parent has no height defined then the child will default to height:auto even if you said height:100%.

If the parent of your element also has a height defined in percentage then the same holds true and it’s parent must also have a height defined. If the parent height is not a fixed height (eg px) but a percentage height then you need an unbroken chain on height:100% all the way back to and including the html element.

Obviously that approach is pretty much unworkable and indeed in your example you were getting only 98% height of each parent so I’ve no idea what the end result would have been. :slight_smile:

The problem with that approach is that you are also limiting all those elements to a fixed percentage height which means that they can in fact never grow and expand with content. 99.9% of the time you do not want to apply a fixed height to content that is going to hold text content anyway.

You could use min-height instead but unfortunately you cannot base a percentage height on a min-height element so you are back to square one.

Luckily the vh unit was introduced which stands for ‘Viewport Height’ and allows an element to be based on the size of the viewport without needing an unbroken chain of elements back to html with height defined. height:100vh means take up 100% of the viewport height. height:10vh means take up 10% of the viewport height.

Therefore to answer your question you could set the height of your iframe height:98vh and get a 98% viewport height. You could then lose all the heights that you had defined.

html,
body {
  margin: 0;
}
#wrapper {
  width: 100%;
  max-width: 40em;
  margin: 0 auto;
}
iframe {
  display: block;
  width: 100%;
  height: 80vh; /* use vh units*/
  border: none;
}

https://codepen.io/paulobrien/pen/LYGdPNy

However, this opens another can of worms in that your 98vh refers to the viewport height but your iframe is not at the top of the viewport and therefore will extend below the fold because you have content above the iframe taking up viewport space. You need to think carefully about the use that you want from your iframe in relation to the content that surrounds it.

The second problem with your approach is that generally iframes have an aspect ratio like images and simply setting a height and a fluid width will mean the iframe no longer maintains its aspect ratio. This may be OK where the iframe is holding content but if the iframe is a video then that approach will be bad and a proper aspect ratio approach would be needed. However, as you did not specify what the iframe content was I will leave that as a question for another day.

1 Like
3

Paul -

Thank you for your very thorough reply. I need to carefully review your detailed comments before I can reply in a meaningful fashion.

Briefly, I set the heights to 98% to allow space for the links at the top of the screen, which I originally intended to place in a div. And that’s where I ran into trouble.

The content of the frame is text only with an occasional chart - all in html, so the aspect ratio is not a concern. The project is a book - chapter by chapter - which I need to render properly on any device. So far, it works - desktop and mobile devices down to a 400px-wide viewport.

I will now go through your discussion and then get back to you. Thank you again for your time and comments.

1 Like
4

You’re welcome :slight_smile:

It’s a common mistake and indeed some experienced web designers do not understand the concept of percentage height properly.:slight_smile:

The question you need to ask yourself (and I alluded to in my answer) is how exactly do you want this iframe element to behave in respect of the content above it and in relation to the viewport?

You said you tried 98% height so that allows apace at the tops for links but here you have introduced the magic number concept and expect your content to fit into 2% height when clearly it won’t fit and if it did fit it would not remain that size if text wrapped or a user zoomed the text size.

Magic numbers are generally a bad thing because they are a guesstimate that may work for a single use case and sometimes only on the device that the user created the design with.

What you need to be looking at is some automatic sizing that will adjust automatically to the content without requiring a specific height to be applied.

Of course there is no harm in having an iframe at a fixed height and if you aren’t specifically trying to keep it in the viewport then its not a problem. It all depends on what you intend to do next and what you are expecting the end result to look like?

For example using flex you could make the iframe just take up the rest of the space of the viewport without any magic numbers. Here’s a very rough and ready example.


(View full size on codepen)

That may not be what you are after anyway but shows the technique required.

5

Paul -

I’ve had a chance to go through your two posts and do some research. Thanks for the example in codepen.

First, the vh units did the trick - thank you. And as you indicated, it simplified the height declarations in CSS.

Second, I mentioned that the project is a series of internal html documents I wish present on the site. While I initially focused on iframes, I note from various sites that content can also be embedded with the object tag (see W3C spec, HTML 5.2 recommendation, sec. 4.7 embedded content, discussing the various tags [https://www.w3.org/TR/html52/semantics-embedded-content.html#semantics-embedded-content]). While the presentation using either the iframe tag or object tag seems to the be the same, I recognize that these tags have different properties and purposes (e.g., the sandbox attribute in iframes). Nevertheless, perhaps there is no difference when the content is purely HTML and the various tag-specific features are not of interest, but I don’t have enough experience with either tag to know whether this is the case. Please let me know if you would recommend one over the other.

Third, the object tag brings up another issue. Notwithstanding the introduction of HTML5, I have been coding in XHTML 1.0 Strict for some time and have had no issues to date. As best as I can tell, XHTML 1.0 Strict is still supported by many browsers and some folks maintain it is preferable in some instances (e.g., older devices). Since the iframe tag is not supported in XHTML 1.0 Strict, I would need to keep the project on HTML5 if I wished to use the iframe tag. I would be interested in your thoughts on this.

6

It always sets alarm bells ringing for me when users want to display html content in iframes or object tags as I have difficulty in understanding the logic. Why not display the content in the page to start with in the normal way and get and get a regular indexable and accessible page?

If the content is important then it should be in the page to start with.

I realise that sometimes we may be working with already created pages but wouldn’t it be better to put those pages in your site to start with (assuming they are under your control).

Sometimes users use iframes so that they can swap the content while staying on the same page but that is just mimicking html Frames and no one uses frames these days due to their accessibility issues. That’s one of the reasons that iframes were deprecated in xhtml but brought back in html5 to cater for things like videos etc where it make sense for them to be frames.

Html doesn’t need to be framed and indeed you could fetch the snippets of html with js if you wanted live updates (ajax) but then again you don’t really have an indexable or accessible site if all you do is swap content in and out of one page.

It may indeed be that your use case is indeed valid for iframe usage which is fine but generally I find that it is developers being slightly lazy and not doing it correctly from the start.

Regarding xhtml then yes it is stricter than html5 and for that reason ‘old school coders’ like it better than html5 but the fact that it is better for older browsers is nonsense. Html5 will work just as well as long as you don’t use any of the new tags. However if I asked you to use your television without using electricity then you would say I was stupid.:slight_smile: You can’t support everything that went before and indeed if you do encourage people with older browsers to not update then they risk their security as all the ransomeware attacks of the last few years have been targeted against old and vulnerable browsers. We need to let any browser that is not supported by its current vendor to fade away.:slight_smile:

Note that xhtml is generally fake xhtml anyway but that’s an argument for another day ;).

2 Likes
7

Paul -

Thank you for your reply.

1 Like
8

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.