Work is complete, fully working. Passing all the tests I could come up with: https://github.com/eseidel/webkit/compare/master...seamless
I'm uploading and landing patches once reviewed again in bugzilla. I do not plan to add an ENABLE, as this work is complete and will all be landed by end of week, assuming timely reviews. -eric On Sun, Apr 1, 2012 at 4:28 PM, Eric Seidel <e...@webkit.org> wrote: > Adding ENABLE, skipping tests, and reverting any non-passing tests, > proved complicated. So I've reverted my work on trunk: > http://trac.webkit.org/changeset/112820 > > and I'll be doing my <iframe seamless> work on GitHub. Interested > parties can follow my fork/branch here: > https://github.com/eseidel/webkit/compare/master...seamless > > Thank you all for your feedback. > > -eric > > On Fri, Mar 30, 2012 at 8:11 PM, Darin Fisher <da...@chromium.org> wrote: >> [Oops, I meant to reply on list.] >> >> I think it is a risky practice for WebKit to have half-baked "webkit" >> prefixed >> features enabled by default on trunk. It puts the burden on all WebKit >> ports >> to know which features are half-baked, whereas individual authors of new >> features would know best how stable their features are. >> >> Once a port ships a feature, however baked the feature may be, if it becomes >> popular (to some degree), we risk having to support it. I don't think web >> developers necessarily understand that they should regard "webkit" prefixed >> features as buyer-beware given that there are so many "webkit" prefixed >> features that we all tell developers to use. How can developers tell the >> difference between the stable ones and unstable ones? >> >> It seems safest to ENABLE-guard all half-baked features on trunk, vendor >> prefixed or otherwise. The only reason to vendor prefix is if there is not >> a >> stable well established spec with multi-vendor support. In the case of >> <iframe seamless>, which seems quite well specified as part of HTML5, >> perhaps there is no need to vendor prefix at all? Just hide behind a guard >> until it is ready? >> >> -Darin >> >> >> On Fri, Mar 30, 2012 at 6:34 PM, Eric Seidel <e...@webkit.org> wrote: >>> >>> We certainly could add an ENABLE. My impression is that we have many >>> half-baked -webkit- features, and that use there-of is buyer-beware >>> anyway? >>> >>> My expectation is that this may be a rather short implementation >>> effort. Ideally I'd be able to finish it next week. Maybe we should >>> revisit this question next Friday? >>> >>> (It's also probably better to discuss this on webkit-dev, but I didn't >>> know if you had intended this email as private.) >>> >>> -eric >>> >>> On Fri, Mar 30, 2012 at 4:59 PM, Darin Fisher <da...@chromium.org> wrote: >>> > >>> > >>> > On Fri, Mar 30, 2012 at 4:01 PM, Eric Seidel <e...@webkit.org> wrote: >>> >> >>> >> Per http://www.webkit.org/coding/adding-features.html >>> >> >>> >> >>> >> I'm working on adding <iframe seamless> support to WebKit. >>> >> http://www.whatwg.org/specs/web-apps/current-work/#dom-iframe-seamless >>> >> >>> >> Folks interested can follow along at home: >>> >> https://bugs.webkit.org/show_bug.cgi?id=45950 >>> >> >>> >> It's currently accessible only via <iframe webkitseamless> / >>> >> iframe.webkitseamless, but once the implementation is complete it will >>> >> move to its spec name "seamless". I have no plans to add a feature >>> >> define, as it should be on for all ports. >>> > >>> > >>> > Wouldn't it be better to hide the feature from shipping products until >>> > it is >>> > complete? >>> > >>> > I realize this complicates testing, but it seems problematic to ship an >>> > incomplete >>> > feature that websites might end up depending on. Once we ship a vendor >>> > prefixed >>> > API, if folks start depending on it, we need to keep supporting it. It >>> > seems safer to >>> > hide the feature until we can ship it unprefixed in this case since the >>> > feature is already >>> > well known and specified in a standard. >>> > >>> > -Darin >>> > >>> >> >>> >> >>> >> Let me know if I can answer any questions! >>> >> >>> >> -eric >>> >> _______________________________________________ >>> >> webkit-dev mailing list >>> >> webkit-dev@lists.webkit.org >>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> > >>> > >> >> _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

