W3C home > Mailing lists > Public > public-html@w3.org > July 2010

Re: WebKit feedback on ISSUE-100 (remove srcdoc)

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 19 Jul 2010 02:35:24 -0700
Message-ID: <AANLkTik4ouRtmRIj4asp6kRM8Uet4DcDfb1Xma4VkUQd@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: HTML WG <public-html@w3.org>, Sam Weinig <weinig@apple.com>
On Sun, Jul 18, 2010 at 10:55 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/17/10 6:37 PM, Adam Barth wrote:
>> 5) The implementation burden for @srcdoc is very light.  We estimate
>> that an experienced WebKit engineer could implement the feature in
>> about a day.
> Honestly, given the way the spec is written right now, just checking that an
> implementation is correct would take more than a day... For example, I
> _think_ the character encoding of the srcdoc document ends up being
> "UTF-16"... but I'm not sure.  And I'm not even sure how much of the spec
> one would have to read to be sure.
> For that matter, it's not clear to me whether behavior is sanely defined if
> the scrdoc document contains <meta charset=""> stuff.
>> Also, ongoing maintenance seems minimal.
> That depends on how other parts of the spec get modified...  Since srcdoc
> support in the spec is a matter of a sentence here and there in other sorts
> of parts of the spec (the HTML parser, the code that assigns origins to
> documents, the code that handles loading iframes), changes to srcdoc can
> lead to changes in spec text and code all over the place. And changes to
> those other parts of the spec can affect srcdoc support.
> I agree that a simple and "probably mostly correct" implementation of srcdoc
> is not a big implementation burden.  I think a "I'm very sure this is what
> the spec says" implementation is.

One of the challenges with implementing HTML5 incrementally is
deciding when "probably mostly correct" is good enough.  As
implementations converge towards representations that more closely
match the models in the spec, these sorts of things become easier.

> P.S.  Of course in other UAs the implementation burden can also be greater
> depending on what infrastructure is in place already.  For example, Gecko
> hasn't really had to have an infrastructure for loading random data into
> browsers while making it look like a navigation to a url, sort of, so tat
> would have to be created to implement srcdoc.

Isn't that the problem that WYCIWYG solves in Gecko?  We need to
implement a similar mechanism in WebKit to get the back button to work
properly with JavaScript URLs.

You're right, though, that my estimate of the implementation effort
might be off by a bit.  It's hard to predict time to implementations
before you actually do the work.

Received on Monday, 19 July 2010 09:36:31 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:03 UTC