W3C home > Mailing lists > Public > www-html@w3.org > February 2004

Re: Headline: Styles pondering desertion to Content!

From: Wingnut <wingnut@winternet.com>
Date: Wed, 04 Feb 2004 11:27:58 -0600
Message-ID: <40212B9E.4000409@winternet.com>
To: www-html@w3.org

Hi Gang!  The noisy nun here again.  Um, after sending an email to a 
fine style tech, I realized that I needed to take this proposal a bit 
further... even if some of you DO yell "spam!".  Regarding the proposal 
to move border, along with underline, linethru, and overline... out to 
becoming CONTENT, possibly made with OBJECT tags...

...this new "floating, bound, re-useable, object-tag-made border" does 
one OTHER drastic thing to the CSS spec. It opens the possibility of 
removing all MARGIN settings from all containers and box models.  Let me 
try to explain how.

This hypothetical new object-tag-made-border, heretofore "OTMB", is 
something that is "binded" to one or more selector-found box models in 
the document.  When its "elastics" parameter is set to {50%, 50%, 50%, 
50%} the border exactly straddles the intersection of a box model's 
content edge, and its container's padding edge.  It borrows HALF of its 
width from the content's padding, and HALF of its width from the 
container object's padding.  I am leaving "margin" OUT of the talk at 
this time, for a reason.  Pretend the margin is set to ZERO on the 
content box model.  Now, let's set the OTMB's elastics={50%, 40%, 50%, 
40%}.  This setting indicates that the border is willing to stretch 
"outward" to a 50%/50% straddle of the content/padding intersection ON 
THE TOP AND BOTTOM, but it is only willing to stretch-out to a 40%/60% 
content/padding straddle ON THE SIDES!  Ok, now apply this 
"stretch-to-almost-fit" border to a line of adjacent inline box models, 
and what do you get?  Bordered "cells" with a small space in-between the 
side-borders of adjacent cells.  The adjacent cells' CONTENT actually 
butts-up against one another... their innerTEXT's distance set by each 
box model's PADDING setting.  BUT, the new floating border allows the 
side borders on each cell... to be shunted short-of the content edge... 
giving the APPEARANCE of margin-separated adjacent inline cells.  But 
only their (floating, stretch-to-almost-fit) borders make them appear 
separated by space.  And yes, this creates a brand new problem for 
BACKGROUND COLOR, because we might see two background colors intersect 
between each cell of the inlines.  That MIGHT be a show-stopper to this 
idea.  Box model background colors and images will need to have a 
"visible outside the border? true/false" on them, I suppose. All in all, 
though, I wanted to try to show that these new floating, 
non-padding-interfering borders (OTMB's) could eliminate the MARGIN 
parameter of CSS... and thus solve yet another "little tug-o-war" that 
seems to happen between a container's padding and a contained-element's 
margin.

This "OTMB binding" is another story.  I envision a certain type of OTMB 
to be reuseable, and "stretch-to-fit" for many onscreen box models, much 
like a style is reuseable for all elements of a given selector.  We 
would NEVER want to do an absolute positioning of an OTMB.  It IS 
absolutely positioned in a certain place "atop" all box models its 
bound-to, though.  Its sizing params ALWAYS uses "percent of stretch 
across content-container/content-padding intersection" and 
avoids/disallows hard-set absolute positions/sizings.  The upper left 
corner of these floating borders is "bound" (in stretch-related, 
slightly-variable positions) to the upper left corner of various box 
models onscreen.  Therefore, it is my opinion that even though these 
borders are floating, they are "bound" to that (and maybe many) element, 
and will therefore not suffer from bad scaling during window resizings. 
Page reflows should be fine as well.  The border (or its "type") will 
travel with the element just like its style does.  Now, though, its out 
of the way of the true stylers.  It floats, and therefore can no longer 
cause content intersection problems.  Then, if margin leaves, 
content/container intersection certainly gets a fresh dose of 
"all-box-model tables are indeed a possibility again" vitamins.  Now, 
lets get going on building that "Visible outside of bound borders?" 
setting for box model background colors and images, huh? :)

Best wishes!
Wingnut
Received on Wednesday, 4 February 2004 12:31:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:19:04 UTC