W3C home > Mailing lists > Public > www-html@w3.org > March 2007

Re: Control Text-file Embedding in HTML-docs

From: Tina Holmboe <tina@greytower.net>
Date: Sat, 31 Mar 2007 17:13:11 +0200 (CEST)
To: www-html@w3.org
Message-ID: <tkrat.460e13cbde188766@greytower.net>

On 31 Mar, sunil vanmullem wrote:

> communities the ability to litigate. Though this shouldn't be allowed
> to act as a hindrance to invention, innovation or the ability to
> progress.

  This topic has nothing to do with setting up roadblocks for invention,
  innovation or progress, and everything with what job of a markup
  language should be: to structure information and supply hooks for
  semantic interpretation. We can discuss whether THAT applies, still.

  The straw-man argument that is the stick-in-the-mud defense doesn't
  even apply here.

  There is NO progress involved in re-inventing the FRAME tag and
  calling it DIV - we've been there before, and the exact same problems
  exist, the more unpleasant ones - in my view - being that

   * The UA must be able to assemble a single source document from
     multiple references (Lynx' method is good, but hardly accessible.
     Imagine reading a document that way. Out loud or by braille)

   * The actually /content/ depends on multiple HTTP requests, some of
     which may fail. (If half the document fail to load, it's a problem,

   * Multiple connections add to the cost, and to the server load;
     neither, of course, accessibility problems per se.

> It doesn't necessarily follow that the lowest common denominator
> should have the highest influence. i.e. the assertion about being
> back to square one.

  The assertion referred to the SRC attribute having the same problem
  today as when first introduced for FRAME - not to 'lowest common
  denominators' of browsers.

  Unless an author wish to say "This is the minimum requirement for an
  UA used to access my content", then a document needs be built on the
  server - and that means we are back to square one with reference to
  the topic we are discussing.

  As Shane points out: XHTML 2 isn't designed to be backwards
  compatible, but regardless. Still there exist issues that ought be
  raised. Personally I'd /not/ be happy if my XHTML 2 browser on my PDA
  had to make multiple GPRS connections to create one document when it
  could have been done on the server. Money is a-wastin'.

> If the end user chooses not to use certified browsers, that is their
> choice and at some point in time they would need to upgrade as
> applications evolve.

  You are making an assumption that the end user (a) can make the choice
  to 'upgrade', and (b) that a 'certified' browser is available.

  There /are/ problems with client-side 'embedding' of documents or
  document fragments - both in principle and in practice. It cannot be
  solved by "Oh, well, it's the user's duty to stay abreast of

  No, I don't think XHTML 2 should allow SRC on everything.

 -       Tina Holmboe                           Greytower Technologies
       tina@greytower.net                      http://www.greytower.net
        +46 708 557 905
Received on Saturday, 31 March 2007 15:13:35 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 30 April 2020 16:21:01 UTC