W3C home > Mailing lists > Public > public-html-comments@w3.org > April 2013

Re: HTML Feature Suggestion

From: Jukka K. Korpela <jukka.k.korpela@kolumbus.fi>
Date: Wed, 17 Apr 2013 10:52:49 +0300
Message-ID: <516E54D1.5070401@kolumbus.fi>
To: public-html-comments@w3.org
2013-04-16 15:40, Scott Ferguson wrote:
> On 16/04/13 21:59, Betty Shirley wrote:
>> Two questions:
>>
>> 1. Why are HTML Frames deprecated?
Well, frames are technically not deprecated in HTML 4, and HTML5 does 
not have the “deprecated” term at all (it flames with the term 
“obsolete” instead). HTML 4 has, however, from the beginning (1997) , 
declared the target attribute as declared, and there is little point in 
using frames without that attribute.

> They:-
> ;are contrary to the the basic concept of a "Web" composed of
> individual pages

So do single-page applications, too, for example.

The simplistic concept of individual pages has its merit in many 
contexts, but there is no reason to force everything into that model.
> ;are hard to bookmark
A specific state of a frameset cannot be directly bookmarked. The same 
applies to a specific state of a single-page application. There are 
solutions to both problems. Instead of making this a counter-argument, 
it should be handled as a technical challenge.

> ;don't render well in all browsers
There were some browsers in the 1990s that did not support frames. You 
will have hard time in finding such a browser in use nowadays.

> ;break accessibility
Almost any technology can break accessibility, especially when used 
wrong way. When frames were more popular than these days, the most 
common comment about them from blind people that I head was “why can’t 
they give their frames meaningful names?” There’s a difference between 
“left” and “navigation”, even though users learn to guess right in 
things like this.

> ;are a pain to maintain
One of key reasons for using frames has been ease of maintenance, in 
situations where the user has to work with “HTML only”, without 
server-side tools. You put navigation in one frame, and then you can 
change the navigation by editing a single file.

Frames have lost much of their popularity, since people have found other 
tools more suitable. But this does not mean that they could not still 
have meaningful use.

> ;tend to break navigation

This is part of the same basic issue as bookmarkability, and a solvable 
problem.
> ;don't resize nicely

It depends, especially on authors’ attempts at preventing resizing. Such 
attempts are not limited to frames.

To return to the issue raised by the original poster:

>
>> Discussion: I have been building an encyclopedia-style website for
>> 12 years using frames: http://www.nhmountainhiking.com/ I
>> recognize some frame-related issues, but believe I have addressed
>> them.

The site as a whole does not seem to use frames (the main page is not a 
frameset), but e.g.
http://www.nhmountainhiking.com/hike/lists/best_photos/frame.html
uses frames to show a thumbnail gallery in one frame, an enlargened 
image (with associated text) in another. This is a rather common setup, 
though it is increasingly implemented using more modern technology, like 
a single-page application that simply modifies the page content by 
replacing some of its content when a thumbnail is clicked on. On the 
other hand, using frames works with pure HTML (well, with impure HTML, 
in some people’s opinion…), without needing JavaScript.

>> Deprecating != Prohibiting
>>
>> But it is *recommended* that cars designed for high speed racing
>> aren't used on roads where high speed racing is prohibited. If you
>> want to drive around with your race tuned Elf engine in first gear,
>> with plain rubber slicks and your suspension lowered to catch every
>> bump (and bottom out on speed bumps) - as long as the vehicle is
>> street legal, you can. :)

You lost me there. I’m not good at understanding parables.

As far as HTML5 drafts go, frames are prohibited, but support to them is 
required. That is, the documents say that authors must not use frames 
and that browsers must implement them (i.e. existing browser must not 
drop support, and new browsers must be created to have them).

>>
>> Recommendation: Please consider re-approving frames in HTML 5,
>> perhaps including a short paragraph with recommended use.
>
The status of frames isn’t really being changed much. They are not 
formally deprecated in HTML 4, but the target attribute is. HTML5 
declares them obsolete, but it has <iframe> as a normal element and 
target as a normal attribute. This means that you could convert a 
frameset page to an HTML5-conformant page by using e.g. a table that 
contains <iframe> elements in its cells. It would be more rigid (because 
tables are no resizable in the sense that framesets are) and a rather 
pointless exercise.

I second the suggestion to make frames allowed in HTML 5.x (it’s 
obviously too late to get them into HTML 5.0). There is no reason to 
declare an existing and well-supported technology as “obsolete”, 
especially since it means “forbidding” it, to the extent that a 
specification can forbid anything. There are alternative technologies 
that may work better in some cases, but so what?

I wouldn’t even suggest adding a short paragraph with recommended use. 
It would be too much of an opinion, or a compromise of opinions.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/
Received on Wednesday, 17 April 2013 07:53:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:29 UTC