Re: Working Group Decision on ISSUE-100 srcdoc

?
--------------------------------------------------
From: "Adam Barth" <w3c@adambarth.com>
Sent: Saturday, October 16, 2010 3:12 PM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>; "Julian Reschke" 
<julian.reschke@gmx.de>; "HTML WG" <public-html@w3.org>
Subject: Re: Working Group Decision on ISSUE-100 srcdoc

> As far as I can tell, everything you mention in your email below has
> been discussed before.  There are lots of tradeoffs in the space, and
> no solution is perfect.  However, cogitating on the issue isn't really
> helpful either, hence the working group decision.
>

In fact pretty much every item that we've discussed recently
was already chewed well before that.
E.g. problem of where to put data, in attributes or in content
was discussed zillion times on many sites and discussions.

Task of embedding various data islands in HTML is topical
now and will be actual in future. From systemic point of view
it is highly desirable to have single and robust mechanism
for that instead of having multiple and different pieces
here and there on that Christmas tree.
Again, nothing new here - good design vs. bad one is beaten
to death already.

Some people were needed inline image data to be embedded
in markup so they come up with data URLs. Now we are getting
situation when we need to embed markup islands into host
markup and we again are trying to use tools (SGML attributes here)
that were simply not designed for that.  That at least creates an impression
of sporadic design to be honest. Especially when we already
have mechanism that allows to do just that - the <script type=...>.

To keep markup human readable and editable the attribute
value should be of 80 chars or so long to fit into string and
ideally they should not be a mix of ' and " quotes.
I think this is obvious too.

Task of having self-sufficient html documents - documents that
have all resources inlined (including HTML subpages) is already
present and critical. Especially in mobile use cases. Take a look for
example on this: 
http://jonathanstark.com/labs/gmail-mobile-web-app-source-decompressed.txt
You will see a perfect example of such self-contained document.

As I said it is highly desirable to come up with some foundation/idea
that will allow to embed various pieces inside HTML in humanistic
manner. Use of elements for that rather than attributes has more power.
At least you have an ability to attribute the data that will help you to
shield included data from the host markup.

For example we can use following approach:

<html>
    <script type="text/html"
           replace="<//script>" replace-by="&lt;/script&gt;" id=secondary >
         <html>
             <script type="text/javascipt">... <//script>
         </html>
    </script>
    <iframe src="#secondary" />
</html>

In text inside all 'replace' sequences has to be replaced by
content of 'replace-by' attribute before that text will be returned
to the consumer.

That will shield the data even from legacy UAs that do not understand
such constructions. I believe that there are other ways of accomplish
this. But please let's try to avoid placing markup or anything potentially
unlimited and complex inside attributes.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Sunday, 17 October 2010 00:27:11 UTC