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

