Missing Functionality: Include
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
 |
Missing Functionality: Include
by Elliot Jenner
::
Rate this Message:
Coming from programming languages like C++ and Python, I naturally
expected that it would be similarly simple to move redundant parts of the page into external files and then include them back in. After extensive searching, I determined that this basic functionality is missing from the language, and requires such hefty workarounds as server-side-scripting or PHP. It should not be necessary to go to a completely different language to perform such a necessary task, particularly languages that require the added complication of a web server just to see if your code is functioning properly, and the added worry that some servers may not support the scripting. Am I alone in wishing for a simple <include url('file.html')/> element or something similar that allows this to be accomplished easily? In my opinion this is a completely basic function that any language should have. How did CSS, which was developed later, obtain the <link> tag, meanwhile the older HTML standard still lacks it? Particularly on a website, there will always be bits of code that are common to all the various pages that make it up, for example the navigation and copy write/contact code. |
|
|
Re: Missing Functionality: Include
by Dustin Boyd
::
Rate this Message:
On Fri, May 8, 2009 at 23:14, Elliot Jenner <void2258@...> wrote:
> > Coming from programming languages like C++ and Python, I naturally > expected that it would be similarly simple to move redundant parts > of the page into external files and then include them back in. After > extensive searching, I determined that this basic functionality is > missing from the language, and requires such hefty workarounds as > server-side-scripting or PHP. It should not be necessary to go to a > completely different language to perform such a necessary task, > particularly languages that require the added complication of a web > server just to see if your code is functioning properly, and the > added worry that some servers may not support the scripting. > > Am I alone in wishing for a simple <include url('file.html')/> > element or something similar that allows this to be accomplished > easily? You must not have known about frames [1], something that HTML has had for a long time in one form or another. The exact same technology also exists in XHTML 1.0 via the frameset DTD [2], albeit with a couple of changes that affect XHTML in general rather than frames specifically. Another possibility is the IFRAME element [3]. The OBJECT element [4] works too, with some minor caveats in the area of client-side scripting such as JavaScript. > In my opinion this is a completely basic function that any language > should have. How did CSS, which was developed later, obtain the > <link> tag, meanwhile the older HTML standard still lacks it? Actually, the LINK element is a part of HTML (and XHTML) [5]. It is simply used to create a relationship between an HTML document and a CSS document. CSS defines style sheet rules; HTML/XHTML defines elements. They are completely different languages, though it may appear as if they all go together because they're used together so often. > Particularly on a website, there will always be bits of code that > are common to all the various pages that make it up, for example the > navigation and copy write/contact code. This is why frames are a great tool when you don't have more useful solutions like server-side scripting/programming available. However, there are usability issues with frames, something that server-side scripting fixes (or server-side includes at the very least). I've personally never used the OBJECT element as a replacement for frames, but I haven't heard about any bad experiences with it other than scripting as previously mentioned. Then again, with as much JavaScript as there is in use these days, I am not surprised that I hear so little about replacing frames using OBJECT. On the other hand, it has been over a year since I've heard anything about OBJECT as a replacement for IFRAME, which is already a replacement for the not-very-usable HTML framesets that I pointed out at first. You can see a live example of using OBJECT as an alternative to IFRAME [6], though I'm not exactly sure how old (or reliable) it is. Again, there might be scripting issues so stay guarded. [1] - http://www.w3.org/TR/html4/present/frames.html [2] - http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Frameset [3] - http://www.w3.org/TR/html4/present/frames.html#h-16.5 [4] - http://www.w3.org/TR/html4/struct/objects.html#h-13.3 [5] - http://www.w3.org/TR/html4/struct/links.html#h-12.3 [6] - http://intranation.com/test-cases/object-vs-iframe/ |
|
|
Re: Missing Functionality: Include
by Jukka K. Korpela
::
Rate this Message:
Dustin Boyd wrote:
> On Fri, May 8, 2009 at 23:14, Elliot Jenner <void2258@...> > wrote: >> >> Coming from programming languages like C++ and Python, I naturally >> expected that it would be similarly simple to move redundant parts >> of the page into external files and then include them back in. In the good old days, people used to refer to FAQs in matters like this. > You must not have known about frames [1], Good for him. > This is why frames are a great tool You are trolling ín a rather primitive manner. The technically correct answer would be that entities offered the mechanism of simple inclusion in HTML, but browser vendors never bothered implementing them. Frames are a different beast, and an ugly one. -- Yucca, http://www.cs.tut.fi/~jkorpela/ |
|
|
Re: Missing Functionality: Include
by Molte
::
Rate this Message:
When using frames the URL in the browser address bar will not change when you navigate around the site. Therefore a specific page cannot be identified by the URL. So using frames would probably not be a good idea.
Then, of course, you have iframes. But with an iframe you restrict the content of the included page to a specific area - that is not to keep layout and structure separated. You also refer to a solution using the object element, though, it would need some scripting. It should be possible to include a page without. All the possible solutions, you refer to, are certainly usable, but when you think about it: Who uses them? Doesn't everybody use a server-side feature for the thing instead? There is probably an explanation to that. Anyway, wouldn't you be able to include a page using the HTML 5 embed tag (I ask because I do not know)? ---- Molte 2009/5/9 Dustin Boyd <rpgfan3233@...>
|
|
|
Re: Missing Functionality: Include
by François REMY
::
Rate this Message:
I know it (may) seems very bad solution, but it's
possible to make an "incude" in JavaScript, which is the client-side scripting
language (which HTML is not).
It is a good way to save client-server transfer
because you can cache small parts of a web page and don't send them after that
to the same user.
They are two way to do it :
* Synchronal system
<script><!--
(function() {
var xhr = new
XMLHttpRequest();
xhr.open("GET", "/menu.part.html", false);
xhr.send(null);
document.write(xhr.responseText);
})();
--></script>
If you use a good cache policy on your server for
the specified "part.html" file, you can save the transfer of the menu (except
the first time the user loads your page).
But it still have the problem it can slow down your
page's loading the first time the user loads it.
* Asynchronal system
<div id="menu"><span
class="loading">Loading...</span></div>
<script><!--
(function() {
var xhr = new
XMLHttpRequest();
xhr.open("GET", "/menu.part.html",
true);
xhr.onreadystatechange = function() { if
(xhr.readyState==4) { document.getElementById("menu").innerHTML =
xhr.responseText; }
}
xhr.send(null);
})();
--></script>
It have the advantage it don't make your page's
first load slower, but it have the disavantage that the menu can be not present
during some time the first time you use the page.
Depending on the size of the data you want to
cache, using one method or the other can be envisaged.
Regards,
Fremy From: molte93@...
Sent: Sunday, May 10, 2009 11:07 AM
To: rpgfan3233@...
Cc: www-html@...
Subject: Re: Missing Functionality: Include Then, of course, you have iframes. But with an iframe you restrict the content of the included page to a specific area - that is not to keep layout and structure separated. You also refer to a solution using the object element, though, it would need some scripting. It should be possible to include a page without. All the possible solutions, you refer to, are certainly usable, but when you think about it: Who uses them? Doesn't everybody use a server-side feature for the thing instead? There is probably an explanation to that. Anyway, wouldn't you be able to include a page using the HTML 5 embed tag (I ask because I do not know)? ---- Molte 2009/5/9 Dustin Boyd <rpgfan3233@...>
|
|
|
|
|
|
Re: Missing Functionality: Include
by Aryeh Gregor-2
::
Rate this Message:
On Sun, May 10, 2009 at 7:37 PM, Elliot Jenner <void2258@...> wrote:
> Virtually the sole purpose of the link element is to include CSS. Since it > is almost never used for anything else, I consider it part of CSS for all > intents and purposes. Have you read the HTML spec? <link> has a great many uses. For instance, in the HTML for the Gmail page I'm on right now, I find: <link rel="shortcut icon" href="/mail/images/favicon.ico" type="image/x-icon"> <link rel="alternate" type="application/atom+xml" title="Gmail Atom Feed" href="feed/atom" /> I'm not sure if stylesheets are even the single most common use of <link>. <style> is probably used as often, and feeds and favicons are very common. The more esoteric links like "next" and whatnot are used by some pretty major websites too (e.g., Wikipedia). > What I am suggesting for a future version (and hopefully a backport) is a > simple tag command, say <include href="file" /> that takes the contents of > the file in question and places it into the position it occupies, similar to > what a <link href="file" type="text/css" /> does now for CSS, but without > any type of formatting. In other words the parser reaches it, jumps to the > other file, reads the HTML as it, then jumps back when the file ends and > continues. This could also be used to import scripts that are duplicated as > well. The type requirement is not as practical in this instance and could be > omitted entirely if it is problematic; users advanced enough to be inserting > scripts should be able to put enough in the include files to make it work on > just a raw copy anyway. Obviously the page would have to block while retrieving the <link>, so latency would be higher for the first request. Other than that, I think this serves a possibly important use-case: compactness of markup. Minimizing the length of markup has the potential to reduce both bandwidth costs (on both ends) and latency on requests other than the first. This would serve a similar purpose to Google's SDCH: http://sdch.googlegroups.com/web/Shared_Dictionary_Compression_over_HTTP.pdf Most pages have very repetitive headers and so on. If these could all be compressed into a single <link> tag that's only served once, that might be good for performance. Of course, the HTML documented that's inserted to replace the <link> tag would follow normal caching rules -- for this to be very useful, it would have to be served with lengthy Expires headers. Otherwise you would increase latency on every request just to get a 304 response. I don't think this would be a great idea solely for the stated reason, by the way, because of that. It's all very well to include another file just for tidiness when that file resides on the local disk, or hopefully even in RAM, where retrieving it is maybe even (in the case of compiled languages) a one-time cost. It's quite another thing to go and fetch lots of includes when they're all the way on the other end of the Internet. Includes in HTML would need to be used with care, and only if there's a clear benefit. I also don't think <link> is appropriate for this. <link> indicates relationships between documents, it's not a processing instruction. A name like <include> might be better. A few further thoughts: 1) The included content (which is probably critical to the page's meaning) would completely fail to render for legacy user-agents. Graceful fallback would be difficult, since the whole point is to avoid including extra code. Of course, authors could just wait for all important browsers to support the feature, or do some autodetection magic and serve different pages. 2) The security implications would be more severe than seamless iframes, etc. It would have to be restricted to same-origin. 3) On the first request, all parsing would have to stop when the include is encountered. This might not be much worse than <script> tags, in practice -- but <script> tags would likely be among the things commonly put *in* these includes, so it could be compounded. (By contrast, <script>s usually don't attempt to include other <script>s, at least if well-written.) 4) The way that fast loading of a page that's almost the same as the current one is currently implemented is generally AJAX. Allowing sites to avoid JavaScript for this would be a good thing. 5) Presumably JavaScript could add includes when the user clicks a button to open up a reply form, view more comments, etc. Currently there are only two ways to do this: a) Code the needed HTML into the page source or a script include. This increases the weight of every page load, or at least the first, even though the overwhelming majority of viewers might not be interested in the functionality. b) Fetch the needed HTML dynamically when needed. But in this case, it's not cached, unless it's specifically added to localStorage. Including content with a proper Expires header would allow the content to be cached transparently by the browser as space permits, simplifying work for authors and making more efficient use of disk space (since the browser can clear its own cache freely, but not localStorage). This seems like an interesting proposal. Perhaps it should be considered for inclusion into HTML5, or at least HTML6. It must have been suggested before at some point, though . . . |
|
|
Re: Missing Functionality: Include
by David Woolley (E.L)
::
Rate this Message:
Elliot Jenner wrote:
> Virtually the sole purpose of the link element is to include CSS. Since > it is almost never used for anything else, I consider it part of CSS for > all intents and purposes. Using link for CSS was added quite late. The main problem with link was that it was that the market leading GUI browsers failed to implement it, probably because there was no author controlled rendering, and they were in the WYSIWYG market not the true HTML market. > > As to frames and the object usage, these have a tendency to fail at best > and be outright mishandled by servers at worst. I realize that these > exist, and have used them, but I have been frustrated by the spotty > functionality and the difficulty of implementation. I don't understand why you think people have problems with frames. When frames came out, almost ever commercial web site used them. That they are less used now is probably the result of education. Frames are incompatible with the URL concept, because you cannot link to a framed page after an internal link has been followed. The big problem with object was that it was hijacked by Microsoft for supporting ActiveX embedded applications, and their implementation of basic object inclusion was poor. > > > What I am suggesting for a future version (and hopefully a backport) is > a simple tag command, say <include href="file" /> that takes the This is an element, not a tag, and elements should always be declarative, never commands. Although I'm not sure that inclusion would be a valid use, commands should be implemented using processing instructions, not elements. However, as already hinted, HTML, as an application of SGML, has had an inclusion facility from the beginning. The problem was that browser developers did not see fit to actually implement it. The mechanism that is used to give symbolic names to characters is actually being used for only a very special case, and should be usable to include whole fragments of text. As the SGML specifications are not free, and I haven't had a business need to buy them, I can't be completely sure that markup is allowed in external entities, but that would be a relatively small and consistent extension, even if it isn't naturally available. The external entity mechanism has the advantage that the entities are declared near the start of the document, so a fetch for them can be started before they are actually used. Frames, though, better fitted with the market demand for something presentational and stateful, even though they are incompatible with the fundamentals of the web. In my view, the way of implementing contents sidebars that actually fitted in with the concept the gave birth to the web would have been for browsers to automatically open and keep open a window onto any page referenced by <link rev="contents"....>. This is a non-starter now, as it it takes away control of the visual presentation and behaviour from the author, which is good for the reader, but the market is driven by authors, not readers. One final point is that, if you look at typical commercial web sites, they are so bloated with style attributes, embedded style sheets and Javascript libraries, that is clear that the authoring community doesn't actually care about keeping transmitted page sizes down. Cleanly written semantic HTML is actually rather compact and fast to load. -- David Woolley Emails are not formal business letters, whatever businesses may want. RFC1855 says there should be an address here, but, in a world of spam, that is no longer good advice, as archive address hiding may not work. |
|
|
Re: Missing Functionality: Include
by Roland Bluethgen
::
Rate this Message:
Elliot Jenner wrote:
> Virtually the sole purpose of the link element is to include CSS. Since > it is almost never used for anything else, I consider it part of CSS for > all intents and purposes. This is a misunderstanding at your side. The link element doesn't /include/. It carries /information about a relationship/ to other documents. So to speak, other documents are /assigned/ to the document in question. It is entirely up to the user agent how to respond to getting knowledge of such relationship. In the case of CSS and a UA capable of processing CSS, it would normally request the CSS document and apply its rules to the representation of the document. Aryeh has informed you about other widely deployed uses of the element. > What I am suggesting for a future version (and hopefully a backport) is > a simple tag command, say <include href="file" /> that takes the > contents of the file in question and places it into the position it > occupies, similar to what a <link href="file" type="text/css" /> does > now for CSS, but without any type of formatting. I notice the absence of the rel attribute in your example, again indicating the misunderstanding of the link element. The style sheet assignment is not denoted by type="text/css", it is denoted by naming the kind of relationship to the CSS document, i.e. rel="stylesheet". Regarding the introduction of some kind of inclusion mechanism to HTML, I predict the story would go like this: After agreeing on an <?include?> processing instruction, the next inevitable extensions would be conditional statements and variables, because people feel the urgent need to implement hierarchical menus with the current item highlighted. (But we already have that, it is called server side includes, only that SSI is a server-side technique.) Then people want to more cleanly separate content and presentation and thus need a variety of loops and the possibility of loading data files or querying an RDBMS. (Again we have that, it's called PHP, and it also works without a server environment.) Soon we would have another full-blown programming language -- or several such languages, because people tend to develop strong feelings about what would be the right[tm] syntax for all this stuff. So we would separate the programming from HTML again and only do some kind of designating or referencing within HTML. Yet again, we already have this, just in the other direction: we would designate HTML chunks and programming statements from within a build provision called Makefile. And so I approach the practical part of your question (how to get your problem solved). I suggest you deploy some kind of preprocessor in conjunction with the build system of your choice. As for the preprocessor, you could use CPP, which you already know from C++, but I'm afraid it is syntactically unpleasant within HTML. A good choice imho would be PHP. Indeed, this task is the original purpose of PHP (and imho the only application which it is good for). It has a simple C-like syntax and all the control structures you need. And an include statement, too. Then there was a very interesting project called Website Meta Langauge, featuring file inclusion, macro expansion, embedded Perl and output splitting. Unfortunately it appears to have been abandoned. When I once tried, I didn't even manage to make it build. Otherwise this would be my favourite for the task. http://thewml.org/ As for the build system, there's an abundance available these days. http://en.wikipedia.org/wiki/List_of_build_automation_software At the end of the day, HTML is not meant to be a programming language, it's meant to markup text. |
|
|
Re: Missing Functionality: Include
by Aryeh Gregor-2
::
Rate this Message:
On Mon, May 11, 2009 at 1:52 AM, David Woolley
<forums@...> wrote: > One final point is that, if you look at typical commercial web sites, they > are so bloated with style attributes, embedded style sheets and Javascript > libraries, that is clear that the authoring community doesn't actually care > about keeping transmitted page sizes down. Cleanly written semantic HTML is > actually rather compact and fast to load. This is true for most websites, but there are a lot of websites (especially those based on major software packages, rather than built in-house) that do try to minimize loading time. Semantic HTML only gets you so far: there are still usually large chunks of repeated HTML on every page, for navigation bars and so on. I admittedly haven't benchmarked the actual performance difference from a 20% reduction in the size of a fairly large HTML page, say -- it might not be too large. In that case, this is probably more complexity than it's worth, especially given its inflexibility. As Roland rightly points out, it wouldn't work well if you want to highlight the current location or whatnot, which is common. <iframe seamless> from HTML5 would replicate almost all of the functionality anyway, and AJAX can minimize downloaded content better than any sort of declarative include like this. |
|
|
Re: Missing Functionality: Include
by Jim Jewett
::
Rate this Message:
Aryeh Gregor wrote:
> Semantic HTML only gets you so far: there are still usually large > chunks of repeated HTML on every page, for navigation bars and > so on. This is annoying from an aesthetic standpoint, but may not matter except on very limited devices, such as mobile browsers. > I admittedly haven't benchmarked the actual performance > difference from a 20% reduction in the size of a fairly large > HTML page, say -- it might not be too large. I think this might be somewhat covered by the microscape benchmark. http://www.w3.org/Protocols/HTTP/Performance/microscape/ While the results I read are out of date, I wouldn't be surprised to discover that the following points still hold: (a) Total number of requests often matters more than total number of bytes. So splitting something into separate includes may be counterproductive. (Thus the yahoo UI libraries come pre-bundled.) (b) If the page is slow enough that people notice, getting rid of the text entirely won't save as much as better compression (or elimination) of images. -jJ |
|
|
RE: Missing Functionality: Include
by John Foliot - WATS.ca
::
Rate this Message:
Elliot Jenner wrote:
> > Coming from programming languages like C++ and Python, I naturally > expected that it would be similarly simple to move redundant parts of > the page into external files and then include them back in. After > extensive searching, I determined that this basic functionality is > missing from the language, and requires such hefty workarounds as > server-side-scripting or PHP. Perhaps it is because HTML is not a *programming* language, but rather a mark-up language, two very different animals. HTML (Hyper Text Markup Language) is about applying structure and meaning to text, and not about spinning wheels, dancing flames or other wondrous adventures; it is about conveying meaning to your data and information. > It should not be necessary to go to a > completely different language to perform such a necessary task, > particularly languages that require the added complication of a web > server just to see if your code is functioning properly, and the added > worry that some servers may not support the scripting. Say what? Hefty? At the most basic level, Apache web servers allowed you to do just this since nearly the beginning of time itself, simply by adding: <!--#include virtual="/foo.html" --> And ensuring that your server (your compiler as it were) was configured to respect that command. See: http://httpd.apache.org/docs/1.3/howto/ssi.html Subsequently, with PHP it is as simple as: <?php include ("/foo.html"); ?> And again ensuring that your server is configured correctly. Pretty much every installation of Apache today offers PHP support out of the box. Not using Apache? IIS also allows for server-side inclusion via ASP: <!-- #INCLUDE FILE="../includes/foo.asp" --> <!-- #INCLUDE VIRTUAL="/myweb/includes/foo.asp" --> Again out of the box. These are 'hefty'? As for testing; if you are looking to use PHP, investigate XAMPP (windows) or XAMPP for Mac OS X - both allow for local testing without the need to 'upload' anything. Want Windows testing, try starting here: http://support.microsoft.com/kb/839013 > > Am I alone in wishing for a simple <include url('file.html')/> element > or something similar that allows this to be accomplished easily? See above (SSI). The three 'planks' of modern web development continue to be HTML for semantic structure, CSS for 'display', and scripting (client side or server side) for 'functionality', and I for one hope it remains this way. As an aside, while server-side scripting *does* have a higher cost to the developer (server and bandwidth), it is also a more predictable method, and as such is likely the better choice for functionality such as what you are seeking (IMHO). I'm still not a big AJAX guy, but believe that there is a means using xmlhttprequest to also do something similar > In my > opinion this is a completely basic function that any language should > have. How did CSS, which was developed later, obtain the <link> tag, > meanwhile the older HTML standard still lacks it? As others have pointed out, <link> in HTML existed prior to CSS, and was simply used in the early days to link an external CSS file to an HTML document. We also now have @import... > Particularly on a > website, there will always be bits of code that are common to all the > various pages that make it up, for example the navigation and copy > write/contact code. Yep, those requirements have been around for some time now (certainly the decade or so that I've been playing here), but understanding the history of what came before will hopefully clarify both reasoning and current methodologies better. Cheers! JF |
| Free embeddable forum powered by Nabble | Forum Help |
