This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9337 - Frameset/Frame Specification Amendment
Summary: Frameset/Frame Specification Amendment
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows 2000
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-26 14:18 UTC by Axel Dahmen
Modified: 2010-10-04 14:55 UTC (History)
5 users (show)

See Also:


Attachments
Visualization of frameset/frame specification amendment suggestion. (97.12 KB, application/pdf)
2010-03-26 14:19 UTC, Axel Dahmen
Details

Description Axel Dahmen 2010-03-26 14:18:34 UTC
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.

The current 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 specification result from algorithms put in place before CSS became a wide-spread method of adding presentation to content.

I'd like to suggest to amend the HTML/CSS specification on HTML <frameset> and <frame> elements in order to provide sufficient control over frame rendering to the web site editor.

My suggestions splits into following (independant and disjunct) suggestions:

___________

*  "cols" and "rows" attributes should become deprecated
   in favour of following new attribute:

      flow  (horizontal|vertical) #IMPLIED

Reason:

The number of rows/colums results from the number of frames contained within a frameset. There is no need to duplicate this information by using a separate attribute, which adds unnecessary ambiguity.

It is sufficient to define the direction of frame flow, either horizontally or vertically. The suggested "flow" attribute provides for this.

If flow="horizontal", frames within a frameset are aligned from left to right, equally distributing the available with amongst them.

If flow="vertical", frames within a frameset are aligned from top to bottom, equally distributing the available height amongst them.

___________

*  Leave presentation information to CSS.

I.e.: Following frame attributes should become deprecated:

   -  frameborder
   -  marginwidth
   -  marginheight
   -  scrolling

Reason:

The current specification leaves a gap defining the layout of frames. Instead of trying to fill these gaps, HTML should rely on CSS regarding frame layout.

The CSS properties for border and margin are self-explanatory. Scroll bar visibility should be defined using the CSS "overflow" property applied to the frame/frameset elements.

___________

*  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.

For functional specification, it is sufficient to specify that resizing is allowed and an appropriate NS/EW cursor will be displayed only if:

   a) The gap space is greater than 0
      - and -
   b) None of the affected frames' noresize attribute is
      being set.

___________

I have added a PDF file to this suggestion report, trying to visualize the concept's details.

RFC,
Axel Dahmen
www.axeldahmen.de
Comment 1 Axel Dahmen 2010-03-26 14:19:27 UTC
Created attachment 845 [details]
Visualization of frameset/frame specification amendment suggestion.
Comment 2 Ms2ger 2010-03-26 14:47:52 UTC
(In reply to comment #0)
> Frames are a great way...

No, they aren't.
Comment 4 Axel Dahmen 2010-03-26 23:58:46 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > Frames are a great way...
> 
> No, they aren't.
> 

I believe we should NOT pursue religious kind of discussions here but instead confine on a technical discussion.

Please follow above-mentioned link to a constructive discussion on this topic in the W3C CSS mailing-list.
Comment 5 Ian 'Hixie' Hickson 2010-04-02 06:19:06 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: From the HTML perspective, frames are obsolete (they were deprecated over 11 years ago). I don't think it makes sense to spend any time trying to tweak how they are rendered at this point, given that HTML isn't a layout language anyway.

I recommend dealing with any missing presentation features in the CSS working group.
Comment 6 Axel Dahmen 2010-05-07 03:22:25 UTC
Yes, you're right. It's currently discussed there.