Re: <iframe doc="">

----- Original Message ----- 
From: "Ian Hickson" <ian@hixie.ch>
To: "Joe D Williams" <joedwil@earthlink.net>
Cc: <public-html@w3.org>
Sent: Sunday, January 17, 2010 1:08 PM
Subject: Re: <iframe doc="">


> On Sun, 17 Jan 2010, Joe D Williams wrote:

>>
>> There are a bunch of good reasons to reject this, I think, but one 
>> is
>> that xml parsers are not wired that way.
>
> Wired which way?

To treat attribute values one way and content another.

> In XML, assuming we make hte attribute take an XML blob,

That is what you have, without special treatment. A possibly xml blob 
that should result in a valid nested context and/or some slang html 
needing fixups that starts =mime escapedcontent until the next 
whatever after the second separator and ends with whatever terminates 
an attribute value.

> you would just start an XML parser and pass it the contents of the 
> attribute, which seems reasonably straight-forward.

Maybe seems reasonable is OK to discuss, but is it really worth the 
effort?

Yes, it is easy, I am sure for the leading parsmeiesters of our times. 
But please perform this task using the best open xml parsers/loaders 
and modelers you have. Just, after the =switch from treating that 
string as an attribute value completely over to treating the string as 
actual content for its parent, then back again just before you find 
whatever terminates the attribute string or find the next </iframe>.

> The reason for specifying this is that a browser vendor asked for it 
> to be specced so that they could implement it experimentally.

OK. Also please include in this discussion considerations for 
processing of @data in <object> and src in <embed>.

I would hope that before any browser vendor asked for a detailed spec 
change they would have at least tried it to see if it could work and 
presented a paper or two on the topic. Really, as far as html and xml 
goes, this is big stuff.

OK, given that we have a couple of browsers that have mastered 
seamless and sandboxed, I would also like to play and see how this 
might work. In the meantime, how about some proofs and development of 
@seamless and @sandbox?

>
>> As usual, I would ask for other examples of this in html5.
>
> Examples of similar "markup within markup" features include any
> URL-accepting attribute (via data:), innerHTML, 
> insertAdjacentHTML(),
> outerHTML, document.write(), <noscript>, <iframe>-fallback, and 
> <script>
> with an XML MIME type.

more back on some of these later, but please eliminate any scripted 
DOM building from this example comparison, Sure a proof of working 
would be that you get the same whether you create it by script or 
include it as what might be called 'inline' html in an attribute 
string.
Sure it is like document.write() in a sense of what has to be the 
result of done.
So now the content management template page benerator can unscript 
this part and add content management content here as an attriburte 
value instead of a url, as an attribute, instead?

Basically, if you already know what should go into the iframe without 
@src then why not just include this content as real html like
<iframe>html5codehere</iframe>
? That is the 'correct' location for content you wish to be parsed and 
rendered.

> <iframe>-fallback

What, we can't find content?

>
>> Essentially, in this, the browser gets to grab that attribute value
>> string and do a document.write except the root of that document 
>> must be
>> the parent iframe.
>
> Not sure what you mean here.

iframe content is a nested context.
The DOM created for iframe may be hidden from the host DOM and 
vice-versa.

Anyway, I think this experiment is out of scope because it slashes too 
deep into xml at this time when the browsers aren't even proving they 
all understand the iframe that is in front of them now.

> > The reason for specifying this is that a browser vendor ...

Let that vendor show mastery of the current iframe space before going 
to entirely new territory. That would be premiere leadership

Thanks and Best Regards,
Joe


>
>
>> Besides, why should the first time we see proposed spec text for 
>> this or
>> any be in the spec?
>
> That's how the group is chartered to work.
>
>
>> Why not show the text for new IDL and propsed defintions here 
>> first.
>
> The IDL would be simple:
>
>   attribute DOMString doc; /* or "body", need to examine that 
> suggestion */
>
> I think the semantics of the attribute have been pretty much 
> described to
> death in this thread by this point, I don't propose to do anything
> different than what has been suggested so far.
>
>
>> To get this New idea in the spec, a couple of browsers should first 
>> be
>> showing this as workable and usable, not the other way around where 
>> the
>> standard is defining somethng that has never? actually worked for 
>> anyone
>> but seems at first sight like it may be novel and might even be 
>> userful.
>
> The reason for specifying this is that a browser vendor asked for it 
> to be
> specced so that they could implement it experimentally.
>
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``. 
> fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\ 
> ;`._ ,.
> Things that are impossible just take longer. 
> `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 17 January 2010 22:22:54 UTC