Boris,
> use cases that the W3C wants to discourage ...
That W3C mindset promotes no greater good; it just imposes an idea of
what use cases should and shouldn't specify. Might as wellwrite popuo
removal into HTML5.
> The use cases can still be addressed with <iframe> and a bit of pain
if resizing is desired, as far as I can tell.
I quoted Andrew Fedoniouk
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html),
"There are use cases when frames are good. As an example: online (and
offline) help systems ... In such cases they provide level of usability
higher than any other method of presenting content of such type."
I've not seen a counterexample. Have you?
>So this is all about assuming that the bit of pain will be enough of
an inconvenience
>for authors that they will either address the use case in some way not
involving iframes
>at all (and which presumably has a lower pain threshild; what is this
way?)
As above, no-one seems able to point to a non-frameset solution.
>or not address
>the use case at all (unlikely, since they're being paid to address it).
IMO money has no place in this discussion.
> Since UAs must continue supporting framesets anyway, the reasoning
behind removing them seems somewhat weak to me.
Yes.
PB
-----
Boris Zbarsky wrote:
On 10/9/09 2:55 PM, Peter Brawley wrote:
Framesets are part of the current HTML standard and should remain.
This isn't really a convincing argument. There are various other
things that are part of HTML 4.01 that are worth removing and have
been removed.
That said, I'm not sure why there's a worry about what's in the
standard given the
http://www.artfulsoftware.com/infotree/mysqlquerytree.php example
(which doesn't actually validate per the HTML 4.01 standard, since
it's missing a doctype).
On a general note, though, the reasoning behind removing framesets
seems to be that they make it very easy to address specific authoring
use cases that the W3C wants to discourage, right? The use cases can
still be addressed with <iframe> and a bit of pain if resizing is
desired, as far as I can tell. So this is all about assuming that the
bit of pain will be enough of an inconvenience for authors that they
will either address the use case in some way not involving iframes at
all (and which presumably has a lower pain threshild; what is this
way?) or not address the use case at all (unlikely, since they're
being paid to address it). Since UAs must continue supporting
framesets anyway, the reasoning behind removing them seems somewhat
weak to me.
-Boris
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.421 / Virus Database: 270.14.8/2425 - Release Date: 10/09/09 08:10:00
