Re: Control Text-file Embedding in HTML-docs

On Sat, 31 Mar 2007 18:26:53 +0200, Shane McCarron <shane@aptest.com>  
wrote:

> The intent of a universal @src is not really so you end up duplicating  
> fallback content for paragraphs.  Obviously you *could* do this, but  
> just because you *can* do a thing does not mean you *should* do a thing.

If authors *can* do a stupid thing, you can pretty much guarantee that  
they *will* do a stupid thing with a language. That being said, I don't  
think external inclusion is an inherently stupid idea, I just don't think  
authors should have it easier available than e.g. server-side include. If  
<iframe> is easier to use by HTML authors than <?php include('...'); ?>,  
they will use <iframe>. That is where we are today. Let's not wade further  
into that territory.

> The intent of @src is to couple it with its associated attributes  
> @srctype and @encoding to provide for a general purpose fallback  
> mechanism.

If that is the case, the specification needs to require that 'src' isn't  
honored without a proper 'srctype', 'encoding' and alternative content.  
How an UA is supposed to go about implementing this is beyond me, but it  
seems that if authors are able to do <html src="...">, they will do it.  
Guaranteed.

> I suppose it could be argued that this is generalism run amok, but...
>  at the core of this generalization is the assertion from the I18N
> community and the accessibility community that @longdesc from HTML 4 /  
> XHTML 1.* is inadequate.   There needs to be a way to provide rich  
> descriptive content in appropriate formats; where the formats selected  
> based upon what the author has offered and what the consumer can handle.

This is all excellent use cases and arguments for such mechanisms, but we  
need to ensure that the same mechanisms aren't exploited to do moronic  
things like the examples Tina has portrayed.

> The HTML 4 object element was a start at addressing this issue, but had  
> some shortcomings and was not felt to be sufficiently generalized nor  
> sufficiently semantically rich.  By exposing these attributes and their  
> behavior everywhere, the content author can have very fine grained  
> control over what gets delivered.

I think you will find that the "fine grained control" in most cases can be  
seen as "incompetent usage". If you give authors the power to be stupid,  
they will be stupid beyond your wildest imagination. I'm not trying to be  
arrogant nor degrading here; I'm just stating my feelings and conclusions  
 from years of observasion.

Programming is, among other things, mastering the art of abstraction. It's  
almost like seeing the code in the Matrix; most people just can't or won't  
do it, because it's too abstract for them. Seeing and understanding the  
semantics in HTML, the implications each element and attribute has on  
readability and accessibility, embracing universability, applicability and  
availability -- is something most HTML authors will never even begin to  
fathom. To them, HTML is just a presentation language their backend  
systems spew out to make it browsable by what they will decide is their  
"target audience".

I'm sorry for being so negative, but we have to be extremely careful of  
placing such a powerful mechanism in the hands of these authors, because  
they will abuse and exploit it in ways you can't even begin to imagine.

> And, just to be clear, this is NOT frames.

In the most concrete way of implementation; yes it is.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

Received on Sunday, 1 April 2007 00:24:43 UTC