[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

