Re: Control Text-file Embedding in HTML-docs

On 31 Mar, David Woolley wrote:

> the intended use is for replaceable content, i.e. <div src="foo.html"
> /> is wrong because it  has no content and therefore implies that it
> is not essential for the document.  Replaceable content should have a
> richer (normally presentationally richer) replacement, but should
> carry the document meaning even without replacement.

  How would you suggest doing this for

    <p src="uri">
     ...
    </p>

  then? XHTML 2 is making it possible for authors who /still/ don't
  understand what a "paragraph" /is/ to build documents that consist of
  paragraphs pulled from external sources - and we are to believe that
  if those external sources fail the document should /still/ carry the
  meaning?

  I rather fail to see how anyone expect the 'replacement' content to be
  unlike the 'included' content and still carry the same meaning.
  Studying the difficulty people have with IMG and ALT ought prove that
  point rather quickly.




> keep the size of each page down, but commercial use has resulted in
> severe bloat, and, as a result, there is a benefit in assembling the

  I disagree. /Uneducated/ use of, in particular, HTML as a layout
  language has resulted in severe bloat. Education on this topic has
  failed - clearly - when you, in 2007, can find

    <div class="header1">

  in markup produced this year. The proof, as they say, is in the
  pudding. I doubt we need to add complexity that will increase server
  load by multiple connections, reduce download times - yes, multiple
  connections will increase the time it takes to load the document - and
  reduce accessibility by chopping up the content into tiny pieces and
  hope that the UA can assemble it.

  We don't live in an ideal world.



> - as a server feature, the ability to use them is often an added cost
>   option, so not available on cheap hosting services, as, for example,
>   bundled by ISPs;

  A logistics problem. Doing this properly may not be cheap; that's a
  fact of life; if authors want to play the game they might find they
  also have to pay.
  


> - most implementations don't set a sensible Last-Modified-Date, so the
>   page is never cached;

  An implementation problem.



> - configuring any option to set Last-Modified-Date is going to be
>   ignored, as an unnecessary technicality, by most authors, even if it
>   exists.

  An educational problem. The two latter points of your list will apply
  equally, if not even more so, to included content: a smart browser can
  keep documents cached in their full form, but with a number of
  includes whereof most don't set sensible Last-Modified-Dates means
  it'll have to be rebuilt all the time.



> object, for the purists, is a generalisation of img, and <div src= is
> a generalisation of object.  All of them are, conceptually, links, and
> in non-visual browsers, e.g. Lynx, are physically rendered as links.

  Which is really a shame. It's a reasonable approach, but I do wish
  Lynx would, instead, assemble the document. However, the IMG tag
  should, as one would hope we all agree on, link to graphical elements
  which can be represented in a fairly limited ALT-text.

  XHTML 2 gives the power to split entire paragraphs of text out, and
  I'm damned if I can see how good alternatives will be provided without
  including /exactly/ the same content in the document itself.

  It might be that the browser writers are, for once, one step ahead of
  the standards development: a FRAME, by any other name, is still a
  FRAME.


-- 
 -       Tina Holmboe                           Greytower Technologies
       tina@greytower.net                      http://www.greytower.net
        +46 708 557 905

Received on Saturday, 31 March 2007 15:29:26 UTC