Skip to content
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.

Iframe seamless #35

Closed
AndySky21 opened this issue Jan 23, 2016 · 1 comment
Closed

Iframe seamless #35

AndySky21 opened this issue Jan 23, 2016 · 1 comment
Assignees

Comments

@AndySky21
Copy link

Is it in W3C plans to remove seamless attribute from <iframe> element as it has been done in WHATWG draft?

If that's the case, will authors have to explicitly link stylesheets/embed <style> elements inside srcdoc documents in order for them to look more integrated with the containing document?

@AndySky21
Copy link
Author

The label says all, I guess.

However, note that, in order for authors to embed srcdoc documents and avoid making them look like something out of context, they will have to insert inline style or link rel=stylesheet elements. The implications are:

  1. There will be more calls to the server in link or style-import scenario, or longer srcdoc snippets in inline style scenario.
    • in order for authors to keep embedded stylesheets lighter, they will feel forced to make specific stylesheets.
  2. The srcdoc document will have to be manipulated from the source, instead of being inserted as-is (like in current examples)
  3. For srcdoc documents embedded in xml files, in order to honor the requirement for xml document, there will be the need to complete the srcdoc document with a root HTML element to serve as root, or use style scoped for the sole purpose of making it conforming to content model requirements.

Of course this only involves the dumb part of "seamless". The really interesting parts of seamless, such as extending MQs, events, seamless speech rendering, top-level browsing context, will be lost altogether (as they currently are, for what I know, as the support for "seamless" was so complicated that vendors decided to avoid/drop implementing it altogether).

The big issue with seamless, for what I know, is the dimension requirement: the height of pages depends on the seamless iframe document height, which depends on its width, which in turn depends on the embedder document dimensions. In my limited experience, though it can be useful and pretty avoiding internal scrollbars, this is not necessarily "seamless", as any element can have an overflow CSS property forcing scrollbars, especially on portable devices.

Why not simply dropping that part of seamless algorithm or maybe splitting it into two or more levels?

  • seamless=properties, for media queries, link target and so on
  • seamless=seamless, extends seamless=properties and applies visual styles to the Iframe document
  • seamless=frame, extends seamless=seamless and forces the embedder document to calculate dimensions according to embedded document

The second option could also imply resizable iframe so that users accommodate it to their tastes.

Is it viable?

EDIT: I didn't read this before, I swear: whatwg/html#331 (comment)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants