Re: Frameset/Frame Specification Amendment (HTML+CSS)

On Fri, Mar 26, 2010 at 7:25 AM, Axel Dahmen <brille1@hotmail.com> wrote:
> Frames are a great way for splitting a document into several distinct areas
> and for providing a dynamic, resizable, easy-to-use head/navigation/content
> view.

I will greatly disagree here.  Frames have a number of important and
crippling problems related to user interaction and accessibility, and
it is generally recommended to avoid them.  When you need a consistent
template across a site, the proper way to do this is to use a
server-side language.  Doing so is trivial.

> The current HTML specification describes a rendering scheme that is
> insufficient in regard to control of frameset background, resp. frame gaps
> and borders. (E.g., it is currently not possible to eliminate the gap
> between frames in a frameset or to define a frame's border visualization.)
>
> The assertions made in the current HTML5 specification result from
> algorithms put in place before CSS became a wide-spread method of adding
> presentation to content.

After CSS became a wide-spread method of adding presentation to
content, frames became essentially irrelevant.

> *  "cols" and "rows" attributes should become deprecated
>  in favour of following new attribute:
>
>     flow  (horizontal|vertical) #IMPLIED
[snip]

This is something for the WHATWG or HTMLWG lists, not the CSS Working
Group.  We don't edit the HTML specification.


> *  Leave presentation information to CSS.
>
> I.e.: Following frame attributes should become deprecated:
>
>  -  frameborder
>  -  marginwidth
>  -  marginheight
>  -  scrolling

This is also an HTML issue, in that, if it defines that browsers
should ignore CSS, then CSS can't do anything about it.  Bring this up
on the WHATWG or HTMLWG lists.  Presumably HTML has a good reason to
instruct browsers to ignore CSS on frames.

> *  Changing the value of a frame's "noresize"
>  attribute should not affect layout/presentation of frames.
>
> Reason: Visual feedback on the availability of a resizing option should be
> the responsibility of CSS.

Again, an HTML issue.  If HTML is dictating presentation, and browsers
are paying attention to it, then we can't do anything about it.
Again, probably a good reason for this.

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9337

So I see you've raised this with the HTMLWG.  That's good.  Sorry we
can't really do much for you; this is just outside our sphere of
control.

~TJ

Received on Friday, 26 March 2010 17:57:50 UTC