We would like to see Webkit implement this attribute on Iframes.
Would you be willing to explain why you need it? Everything in HTML5 is certainly considered for implementation, but knowing that there is a specific reason for Web developers to want a particular feature helps prioritize development.
Thank you for taking our request into account. In our product we make an extensive use of iframes for DOM fragmentation purposes. All of them are loading the same local page and share several CSS stylesheets. Having the possibility to inherit stylesheets from a single parent page, instead of loading them everytime an iframe is created, would greatly increase our product performances and simplify the loading process.
I agree Mirko, implementing this feature would definitely make it less painfull using iframes. Especially when the iframe you're loading is _not_ under your control and you still want it to integrate *seamlessly* into your page.
Created attachment 134694 [details] first pass at some tests
Tests which I still need to add include: - http-based seamless test (separate origin) - normal navigation (navigates _top implicitly) - target="_self" override
(In reply to comment #2) > Thank you for taking our request into account. > > In our product we make an extensive use of iframes for DOM fragmentation purposes. > All of them are loading the same local page and share several CSS stylesheets. > Having the possibility to inherit stylesheets from a single parent page, instead of loading them everytime an iframe is created, would greatly increase our product performances and simplify the loading process. Browsers should be caching your stylesheets (assuming you have your cache headers set correctly), thus making the loads effectively no-ops (direct from memory/disk). So seamless will not change the specific issue you raise there. :)
Development can be tracked here: https://github.com/eseidel/webkit/compare/master...seamless Will post a patch (patches?) here once everything is working and ready to land on trunk.
Basic size negotiation works: https://github.com/eseidel/webkit/compare/master...seamless inline and floated seamless iframes still need fixes.
My branch works great, and passes all tests with the exception of the float/inline case where the calculated height is off by 4 pixels!? Still tracking down that bug, but plan to start posting patches for landing on Monday. :)
OK. My branch work is done. I'll be uploading patches on dependent bugs. I'll land the feature behind a flag which folks can disable on their release branches if for some reason they do not wish to ship seamless at this time (since based on webkit-dev comments it sounds like Apple is preparing an imminent release).
Per the original proposal, I've removed the feature flag from these patches, as this should be enabled on all ports, and with timely reviews could easily be fully landed as soon as end-of-day tomorrow.
As far as I can see, there is nothing in this implementation so far that affects screen readers. The spec says that seamless iframes should "not be announced as new browsing context" (or something like that). Am I wrong about this not being part of the current solution, or is a new bug needed?
There has been no work on <iframe seamless> accessibility. I would encourage you to file bugs about such once the feature is landed (and this bug is closed). If you CC me I'm happy to CC appropriate Accessibility engineers.
Eric, I'm surprised that you don't consider accessibility as part of "implement a feature" master bug. It seems more central than inheriting stylesheets featurette, for instance.
I'm wondering the following - the HTML5 spec says this about "seamless": "The attribute can be set or removed dynamically, with the rendering updating in tandem." Currently if I remove the "seamless" attribute through the inspector, the styles of the parent page are still applied inside the iframe. When I then disable certain styles from the main page, the iframe is *not* updated. As I understand from this sentence of the spec, the iframe should lose its styles inherited from the parent page as soon as the attribute is removed. Is this possibly a bug? (I'm not sure if this is an appropriate comment here, my apologies if it is not.)
If you file a bug (and ideally attach a test case), I'm happy to look on monday.
I really appreciate the feedback pimvdb. :)
(In reply to comment #13) > There has been no work on <iframe seamless> accessibility. I would encourage you to file bugs about such once the feature is landed (and this bug is closed). If you CC me I'm happy to CC appropriate Accessibility engineers. Filed bug 86317
We believe seamless works well enough to ship, so it may be time to close this and move all remaining open bugs over to a "polish seamless until it shines" metabug.
Seamless is unfortunately no longer near the top of my priority list. It has a couple bugs remaining, but until we have someone signed up to own it, we may consider disabling it on stable builds, or trunk. Although I think it highly likely that other browsers will implement seamless, they have not yet -- it's likely that our implementation will need to change when they do. I think it's a small amount of work to make seamless truly "ship-able" and a small amount of future work to adjust it with the evolving HTML5 spec. Unfortunately I can't sign up for either at this point.
Comment on attachment 134694 [details] first pass at some tests Attachment 134694 [details] did not pass chromium-ews (chromium-xvfb): Output: http://webkit-commit-queue.appspot.com/results/17117041 New failing tests: fast/frames/seamless/seamless-basic.html fast/frames/seamless/seamless-nested.html fast/frames/seamless/seamless-sandbox-flag.html fast/frames/seamless/seamless-css-cascade.html
Comment on attachment 134694 [details] first pass at some tests Attachment 134694 [details] did not pass mac-ews (mac): Output: http://webkit-commit-queue.appspot.com/results/17167040 New failing tests: fast/frames/seamless/seamless-basic.html fast/frames/seamless/seamless-nested.html fast/frames/seamless/seamless-sandbox-flag.html fast/frames/seamless/seamless-css-cascade.html
Comment on attachment 134694 [details] first pass at some tests Attachment 134694 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-commit-queue.appspot.com/results/17113501 New failing tests: fast/frames/seamless/seamless-nested.html fast/frames/seamless/seamless-basic.html fast/frames/seamless/seamless-sandbox-flag.html fast/frames/seamless/seamless-css-cascade.html
seamless iframe support was removed in this commit: https://github.com/WebKit/WebKit/commit/3e2010a853456a8ad1e097897ef35ff5b54b2877 I am going to mark this and dependent open bug as "RESOLVED WONTFIX"? Thanks!