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

[Eric Seidel]

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 <eric at 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 <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
>>> >
>>> >
>>
>>