W3C home > Mailing lists > Public > www-validator@w3.org > April 2005

Re: Question re:"allowtransparency" attribute in iframes

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Fri, 08 Apr 2005 02:02:44 +1000
Message-ID: <425559A4.3000503@lachy.id.au>
To: ryan@getnicestudios.com
CC: www-validator@w3.org

Christopher Ryan McVinney wrote:
> Lachlan Hunt:
> Thank you for your long, thought out response.

Your welcome.

> I must say I still do not understand the w3c's reasoning.

While I am not a member of the W3C, I am only a voluntary contributor, 
so I cannot speak on their behalf, I do believe the reason that many 
extensions, including allowtransparency, will not be added to HTML is 
because HTML is not, and was never intended to be, a presentational 
language.  HTML is designed to markup the semantics of the information 
not it's presentation.  ie. say *what* the content is (eg. heading, 
paragraph, list, abbreviation, etc.), not what it looks like (eg. 
colours, sizes, positioning, etc.).

By marking up the semantics of the document, rather than the 
presentation, it is expected that the document will be accessible to a 
much wider range of user agents, devices and platforms and, thus, 
accessible to users with differing needs.  For example, a user on a 
monochrome screen cannot see colours, and a low powered PDA, even with a 
coloured screen, probably wouldn't have the processing power to 
calculate transparency like a typical desktop computer.

Other kinds of devices, such as aural, tactile, or text-only (DOS-like 
interface, eg. Lynx) devices have no ability to render visual 
presentation (Lynx can do some, but is _very_ limited).  However, there 
are other forms of non-visual presentation which they can render.  For 
example, if a heading were marked up like this:

<font size="7" color="green"><b>Heading</b></font>

How would a non-visual device render that?  What could an aural (eg. 
screen reader/text-to-speech) or tactile (eg. braille) user agent do 
with it?  There is no semantics there, only visual presentation, so 
there is no way to determine a non-visual alternative.  However, marking 
up a heading like this:


Specifies the semantics, while keeping the presentation seperate.  So a 
visual user agent may render it in big, green, bold font, whereas an 
aural user agent may speak it in a louder, deeper tone, and may leave 
longer pauses before and after speaking it.  (Imagine how you would read 
it out loud from a book)

This is why it is so important to keep the strucure and content seperate 
from the presentation.  So that different user agents, platforms, 
devicees and users can make use of it in a way the is most suitable for 
them.  This is also why most presentational extensions were deprecated 
in HTML 4 and have been removed from more recent versions, and why 
presentational extensions will (hopefully) never be added again.

If you are interested in seeing what the current developments in HTML 
are, I suggest you take a look at XHTML 2.0 working draft and the 
WHATWG's unnofficial HTML 5 proposal.


> It seems that the point of the w3c is to create 
> standards that web developers (like myself) should follow,

That is correct.

> mistaken, which I may be. I try to conform as much as possible to these
> standards to be sure my pages display properly and no users have any 
> errors. Unfortunately, Microsoft and many other companies frequently 
> disregard this, and I find it extremely obnoxious of them at times.

While it is true that many extensions have been added to HTML by browser 
vendors in the past, I believe most companies have grown up and will not 
be adding any HTML extensions without going through some form of 
standardisation process first.  The same is true of CSS, although vendor 
prefixes allow them to experement without interfering with the 
standardisation process.

> My issue however is that I do not believe the w3c should be completely 
> ignoring current trends and/or new developments in the industry just 
> because they feel certain attributes are not valid for some reason,

They are not, the allowtransparency attribute and many other extensions 
were created by Microsfot, Netscape and other browser vendors a very 
long time ago, and rejected by the W3C back then too.  These extensions 
are not new, and are in no way current trends.

However, although some of these extensions were not added to HTML, there 
are other, more accessibile and interoperable methods being developed, 
such as CSS (which replaces many proprietary presentataional attributes) 
and the DOM (which replaces many proprietary and incompatible document 
object models. eg. document.getElementById() is the standards compliant 
version of Microsoft's non-standard document.all property.)

So the W3C is listening (mostly) to what users, developers and user 
agent vendors want, and reacting to their needs; perhaps just not in the 
ways you are aware of.

> As you state in your response, there is no way (that I know of either)
> to make a frame transparent using a cascading style sheet, without the
> "allowtransparency=true" attribute set.

There isn't and never will be.

>  This seems as though it should be a basic attribute in 
> html, as it is really not a complex thing.

For an HTML author, it may not seem so.  However, when you begin to 
consider the technical implementation details for user agents, you will 
begin to understand why.  Let me attempt to explain why, as I understand 
it, allowtransparency cannot work interoperably, and would break the way 
CSS currently works if it were added.

A frame within a document is essentially another viewport (the canvas 
where the document is rendered).  Each document has a background colour, 
which is specified through CSS by something like:

html, body { background-color: #fff; }

(or by deprecated attributes on the body element of the document)

Because of this, the background colour of the document is applied to the 
viewport.  Therefore, the background colour of the frame comes from the 
contained document.

However, the allowtransparency attribute is specified in the parent 
document, and means that the background colour of the frame no-longer 
comes from the contained document, but from an external source (ie. the 
parent document).  That breaks the way CSS works, and why there can 
never be such transparency added in an interoperable method.

> In an industry standard, frequently referred to HTML reference book from
> O'Reilly entitled "Dynamic HTML: The Definitive Reference" 2nd Edition,

You should be aware that there is no such thing as Dynamic HTML (DHTML). 
  It is a marketing term invented by Microsoft to describe IE 5's 
implementation and mixture of HTML, CSS, JavaScript and the DOM.  The 
term should not be used because it fails to distinguish the difference 
between the different technologies, and I believe has lead to some 
believing that they are all the same technology, which they are not.

> the corrections for the next addition featured information regarding the 
> use and implementation of the allowtransparency attribute (can be found 
> at this link: http://www.dannyg.com/support/update9.html ).

I wouldn't trust that book too much, because as I just skimmed through 
that document and it seems to make the mistake of referring to some 
elements as tags, which they are not.  Although, it did refer to some 
elements correctly and there was one (almost) correct use of tag that I 
saw.  It also should not teach the use of such non-standard extensions 
either, I'm very disappointed with that book, just from skimming through 
that document.

> In closing, it seems to me that the w3c is dangerously close to becoming
> obsolete if it no longer feels the need to monitor the industry, and
> change occasionally with the advancement of technology.

As I explained above, the W3C is monitoring the industry and reacting to 
changes and requirements.  I'm sorry you feel that way, but I hope my 
explanations have made things clearer for you and that you will change 
your mind.

> widespread attributes that many, many developers wish to use (or already
> do use regardless of the w3c), and which IE, Mozilla, Netscape, Firefox,
> and Safari all support (and yes they do, in response to your question,
> though maybe not every other current browser)

I knew those four supported it, but I was enquring more about the rest 
of the list, some of which I know for a fact do not support many 
proprietary extensions, including allowtransparency.

Lachlan Hunt
http://GetFirefox.com/     Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox
Received on Thursday, 7 April 2005 16:02:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:17:45 UTC