Re: Question re:"allowtransparency" attribute in iframes

thanks again...your answers are informative and helpful, if not still 
slightly disapointing to me. My problem is I am decent Flash developer 
and interactive website designer in general, but often I want to create 
more traditional sites in many cases, that can load extremely fast, 
have simple straight forward html code with CSS, and can still have 
good looking graphics and presentation. If I cannot use some of these 
attributes, in conjunction with CSS, it makes html seem more useless to 
me as a tool for presentation on the web. This I still fail to 
understand fully, and what the alternative is. I suppose I should check 
out the XHTML 2.0 stuff more...thanks again -
Ryan McVinney

> 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:
> 
> <h1>Heading</h1>
> 
> 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.
> 
> http://www.w3.org/TR/xhtml2/
> http://whatwg.org/
> 
> > 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://lachy.id.au/
> http://GetFirefox.com/     Rediscover the Web
> http://GetThunderbird.com/ Reclaim your Inbox
> 
> 

-- 
C. Ryan McVinney
Owner/Partner
The Music Gym & Get Nice Records
617-438-0320
ryan@getnicestudios.com
www.getnicestudios.com

Received on Thursday, 7 April 2005 19:29:07 UTC