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

I kind of like it. I think it could go a bit farther, treating FRAMESET as though it was 'display:table' and FRAME as though it was a special type of  'display:table-cell'. Then you could allow other table properties, such as 'border-collapse' and 'border-spacing'. 'Width' and 'height' would work the same as with 'display:table-*' .  The "flow" thing could perhaps be dealt with via CSS 'block-progression' property. You could even use the CSS3 "resize" to determine if the frame was resizable. None of this works this way currently for frames.


On Mar 26, 2010, at 7:25 AM, Axel Dahmen 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.
> 
> 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.
> 
> 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 (independent 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/columns 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. It can be found here:
> 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9337
> 
> RFC,
> Axel Dahmen
> www.axeldahmen.de 
> 
>