Re: shrink-wrap

On Tue, 4 Apr 2000 20:50:59 -0400, "Joe Hewitt" <joe@joehewitt.com>
wrote:

>Has anyone out there been thinking about the shrink-wrap dilemma that has
>been discussed before?

This is a "no problem".

>Lots and lots of developers are going to get flustered,
>as shrink-wrap is a handy tool.

"Lots and lots of developers" may want to study available CSS specs too.
Especially the parts that describes the _real_ fundament of CSS, as in
"The CSS Box Rendering Model"

>We need to install something like this into CSS before it's too late for
>Mozilla.

It's already there, _if_ I read your problem description correctly.

The secret is in the 'display' property.

(Sorry for posting source examples here instead of uploading, but right
at this minute it is simpler for me to do just that)

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
  <HTML>
    <HEAD>
      <TITLE>"Shrink wrap" test</TITLE>
      <STYLE TYPE="text/css">
        H1.a { display: block;
               margin: 5px;
               border: solid 2px #ff0000;
               padding: 5px; }
        H1.b { display: inline;
               margin: 5px;
               border: solid 2px #ff0000;
               padding: 5px; }
      </STYLE>
    </HEAD>
    <BODY>
      <H1 class="a">A block header</H1>
      <P>Some text, etc... Some text, etc... Some text, etc...
        Some text, etc... Some text, etc... Some text, etc...</P>
      <H1 class="b">An inline header</H1>
      <P>Some text, etc... Some text, etc... Some text, etc...
        Some text, etc... Some text, etc... Some text, etc...</P>
    </BODY>
  </HTML>

Run this through M14 and then tell us if it is what you where looking
for, and then move on to find that you have already got a valid CSS1
suggestion on the list, on how not to wrap text.
(and it's all CSS1, no "fancy" stuff needed :)

At times I guess one may find use for the 'clear' property on successive
elements too, but I have not tested that part as of now.

>It's simply not acceptable for all block-level elements with
>"width: auto" or "height: auto" to automatically take the size
>of their containing block.

In this is probably where the "big misunderstanding" is to be found.

Users/authors seems to think that there is some kind of 'divine rule'
that governs the life and existence of certain elements.

It is not of course. What is at hand is a DTD for some (almost) defined
application of a markup model, where the designer of that DTD once
thought that the *processing expectation* of a certain element should be
'block' or 'inline', as it comes out in RFC1866 in its words on "typical
rendering" suggestions.

But as DTD design is only about creating a syntactical and verifiable
(as in a restrained) model of the language at hand, that design work can
only deal with "content models" (and correct spelling of course)
i.e. which element is allowed inside another one.

Elements "processing expectations" can not be carried in a DTD (element
names are just *names*, i.e. nouns, not verbs) the whole responsibility
to fulfill those "processing expectations" instead comes to fall on the
programmer that makes a user agent come to life.

Mozilla is no exception here, maybe except for the fact that all of it's
initial "processing expectations" are realized through user configurable
style sheets and config files.

M follows, in its delivered state, the original intention of "processing
expectations" as was once laid down for HTML elements, but leaves it
open to you as a user/author to _cascade_ your own "override suggestion"
on top of its root level ua.css

Your key is in the CSS specs, where the "Box Rendering Model" is the
absolute most important section to study.

Blocks/Inlines de-mystified, hopefully :)

-- 
Jan Roland Eriksson <jrexon@newsguy.com>
<URL:http://member.newsguy.com/%7Ejrexon/>

Received on Wednesday, 5 April 2000 14:41:07 UTC