W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > June 2011

[Richard Ishida] Why do we still not have transclusion in HTML5?

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Wed, 08 Jun 2011 14:49:51 +0100
To: public-xml-processing-model-wg@w3.org
Message-ID: <f5b8vtcl9fk.fsf@calexico.inf.ed.ac.uk>
[forwarded with permission from private list, further discussion wrt
relevance to XML Processor Profiles on this list, please]


attached mail follows:

Copying the IRC thread here and making notes for wider discussion:

[08:38] r12a: mike, one of the things I've never understood about html 
is why it is so difficult to pull html fragments from elsewhere into a 
page, eg. one paragraph - i see that the object tag in html5 is now 
clearly specced to allow html to be included, but it seems to expect a 
whole file, like an iframe - am i missing something ?
[09:15] Liam: r12a: you want transclusion! ted nelson would be proud!
[11:17] Mike5: r12a: the use case for that is not all that clear to me
[11:17] Mike5: I mean the use case for doing transclusion on the client 
side vs doing it on the server side
[11:18] Mike5: the content has to be same-origin anyway

I'm not so concerned about that.  I'm mostly interested for things like 
handling boilerplate text.  The benefit is that you can change 
repetitive parts of the page without having to edit every single page, 
just like the benefit of using style sheets or .js files. Also, if 
translating a page, you can translate all the boilerplate once and just 
focus on the meat from page to page (which is what we do for translation 
of /International articles, but since we use PHP most of our translators 
don't see the translation as it will finally appear on the page).

It also offers a reduction in the footprint of the HTML page, useful for 
mobile devices, and improved download speeds, since you can just pick up 
the boilerplate text from the cache.

[11:19] Mike5: so it's something everybody does now already -- they just 
do it using PHP or whatever

On the contrary, few 'ordinary' people actually have the ability to run 
Apache/PHP on their system or sometime even their server (eg. the guy 
writing the web pages for his local archery club), but may still want to 
do similar things.

[11:20] Mike5: another problem I see with having it on the client side 
is that if you save a file to disk and move it around, you can lose 
large parts of the content
[11:21] Mike5: it's one thing to have a saved file with missing images 
because those didn't get copied over or moved along with the file
[11:21] Mike5: but it's another thing to lose body text due to 
moving/copying a file

Sure, but also doing this via HTML rather than PHP would actually mean 
that it is *possible* to do what you want from a CD or from somewhere 
without a server running.

[11:22] Mike5: and then there's to issue of having nested/recursive 
[11:23] Mike5: anyway, my take on why it's never been added is that it's 
never seemed to have enough real benefits to make it worth it
[11:24] Mike5: the main real benefit seems to just be convenience

Well, I guess I'd argue that it's done a hell of a lot using server-side 
scripting, but that only works if you are dealing with a server, and can 
use scripting, etc...  Doing transclusion would enable 'ordinary' people 
to reap the benefits of this.

[11:26] Mike5: anyway, as far as object, yeah, it's not really transclusion
[11:26] Mike5: it is pretty much like iframe
[11:27] Mike5: in that it creates another browsing context
[11:27] Mike5: nested
[11:29] Mike5: but r12a -- have you read the part of the iframe section 
about the seamless attribute?

No, I missed that, I think.

[11:29] Mike5: I think that as far as rendering that would give you the 
same effect
[11:30] Mike5: also as far as the CSS cascade, etc.
[11:30] Mike5: 
[11:38] Mike5: all that said, it's still not real transclusion, because 
even with the seamless attribute set, the content of the file the the 
iframe pulls in gets parsed as a document
[11:40] Mike5: so if the content of the file is a just a single <p> 
element, it's going to get parsed into <html><head></head><body><p></p> 
etc. € in the DOM

Right. Which is another big reason I actually want proper transclusion. 
  What I want is an HTML mechanism equivalent to PHP's include( ), so 
that the included HTML just becomes part of the page/DOM and inherits 
all the styles, events, etc around it.

I've developed HTML applications since the mid 1990s at Xerox where I 
really wanted this capability for documents we needed to run offline as 
well as online, but had to work around it in one ungainly way or another 
(typically involving XSLT batach processing in those days or framesets).

[17:53] € gerald reads reads Mike5 and r12a chat on transclusion; yes 
please! I have wanted that for a decade+ 
[17:54] gerald: aside from maintenance convenience, I think it would 
help with speed and bandwidth usage, e.g. on blog pages that have 500 
bytes of original text surrounded by 200KB of blogrolls and other 
navigation junk (which could be cached separately)
[17:55] gerald: I have been meaning to try mnot's hinclude to accomplish 
the same thing http://www.mnot.net/javascript/hinclude/


PS: Btw, I came back to this because i noticed that you need to declare 
the encoding of the file being read in by the object tag, otherwise it 
defaults to the browser default, *unless* you stick a UTF-8 BOM at the 
start of the file.

Richard Ishida
Internationalization Activity Lead
W3C (World Wide Web Consortium)


       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
Received on Wednesday, 8 June 2011 13:50:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:49 UTC