Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> We’ve got <iframe>, which technically is a pure HTML solution, but they are bad for overall performance, accessibility, and generally extremely awkward here

What does this mean? This is a pure HTML solution, not just "technically" but in reality. (And before iframe there were frames and frameset). Just because the author doesn't like them don't make them non-existent.



What do you mean what does it mean?

An iframe is a window into another webpage, and is bounded as such both visually and in terms of DOM interfaces. A simple example would be that an iframe header can't have drop-down menus that overlap content from the page hosting it.

They are categorically not the same DX/UX as SSI et al. and it's absolutely bizarre to me that there's so many comments making this complaint.


The real problem with iframes is that their size is set by the parent document only.

They would be a lot more useful if we could write e.g. <iframe src=abc.html height=auto width=100> so the height of the iframe element is set by the abc.html document instead of the parent document.


You could do this with js in the child document, if its important to keep js out of the parent.


no, not if it is cross site URL.

Then you need a postMessage to send body size to parent frame which then needs to listen for messages and resize the iframe element.


Totally! I thought we were talking about the same site case.


You can achieve that with js in the parent document.


You can achieve everything with JS in the parent document, it doesn’t mean it should be required or even recommended


We could also achieve it with single tape Turing machines, but with js in the parent document it takes just a few lines and is practical to do.


No way. You can't make a decent single web page by iframing a bunch of components together.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: