[webkit-dev] Feature Announcement: Adding <iframe seamless>
eric at webkit.org
Sun Apr 1 16:28:07 PDT 2012
Adding ENABLE, skipping tests, and reverting any non-passing tests,
proved complicated. So I've reverted my work on trunk:
and I'll be doing my <iframe seamless> work on GitHub. Interested
parties can follow my fork/branch here:
Thank you all for your feedback.
On Fri, Mar 30, 2012 at 8:11 PM, Darin Fisher <darin at chromium.org> wrote:
> [Oops, I meant to reply on list.]
> I think it is a risky practice for WebKit to have half-baked "webkit"
> features enabled by default on trunk. It puts the burden on all WebKit
> 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
> 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?
> On Fri, Mar 30, 2012 at 6:34 PM, Eric Seidel <eric at 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
>> 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.)
>> On Fri, Mar 30, 2012 at 4:59 PM, Darin Fisher <darin at chromium.org> wrote:
>> > On Fri, Mar 30, 2012 at 4:01 PM, Eric Seidel <eric at 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 at lists.webkit.org
>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
More information about the webkit-dev