Re: Missing Functionality: Include

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.

Received on Monday, 11 May 2009 05:53:04 UTC