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

[Darin Fisher]

[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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120330/ef2d320c/attachment.html>