[webkit-dev] Feature Announcement: Adding <iframe seamless>

[Eric Seidel]

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 <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"
> 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 <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
>> 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 <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
>> >
>> >
>
>