4 ms·
Well a lot of custom controls worked using this technology, including Internet Explorer and the Windows Shell and Explorer themselves. Ultimately though it was
by adzm 3y ago
Well a lot of custom controls worked using this technology, including Internet Explorer and the Windows Shell and Explorer themselves.
Ultimately though it was the web that implemented the end goal of interactive, linked documents and components though.
- kmeisthax 3y agoOnly sort of. <iframe> can embed arbitrary web content, but this power is only available if you're writing bare HTML. Apps like Google Docs which ordinary users can actually use don't actually give you this power. Their internal document models aren't HTML and they don't even render to DOM anymore, they render to canvas. Furthermore there's a growing movement to slowly deprecate certain embedding use cases. Embedded sites could always pop themselves out of the current page, but there's now also HTTP headers that let you explicitly forbid embedding on either end. This is actually considered a security best practice[0] as there are crafty XSRF attacks that could be enabled by, say, layering an invisible iframe in front of your cursor that just so happens to be open and scrolled to the "send all my money to someone" button on your bank account. Timing attacks apparently also rely on embedding, so anyone who wants to use, say, shared-memory multithreading for WASM[1] has to also opt out of both being embedded and being allowed to embed other sites. [0] According to people begging for bug bounty money [1] i.e. Ruffle
- zubairq 3y agoAgreed. Also, IFrames don't really compose well, or give easy communication between parent and child IFrames in the same way that components can set attributes and call methods on each other
- pjmlp 3y agoPresent tense, a lot of custom controls work using this technology. COM has had the spotlight of Windows APIs since Windows Vista took the .NET ideas for Longhorn and re-did them in COM/C++.