Re: content property

Bert Bos wrote:
> :before and :after are meant for adding `small' things before and
after
> an element. `Small' probably means something like `inline boxes.' You
> won't be able to insert a complete paragraph. 
> 
> I'd very much like to keep them underpowered like this, since I'm
very
> hesitant about generated content. I can see that some generated
content

Content should be large enough to hold a small string. It would be
silly to allow generated content such as section numbers and deny
related text such as "Section ".

> can be classified as `style' or `decoration,' but it is easy to see
how
> generating content from within the style sheet can also lead to
one-line
> HTML files, with all the content in the style sheet (as already
happens
> with scripts sometimes).

I've written 'calculator' scripts with _all_ content generated. You
can't get an answer until you've entered the problem. But I doubt we'll
see a rash of self-hangings using CSS for rope, and I think it's a
mistake to fall into a 'big-brother' mindset where you cripple
capabilities to protect the stupid. There are more effective ways than
CSS to "unknowingly make important information inaccessible to others".

> And I also believe that a tool that constrains you may be frustrating
> once in a (long) while, but that most of the time it makes things a
lot
> easier. (That, IMHO, is the real reason that Java is better than
C/C++:
> who cares about the speed of execution; it's the speed of development
> that counts.)

I used to program in MASM. C code produced depressingly inefficient
executables.

> When the :before pseudo-element is added, designers can chose: either
> use `display:list-item' and the limited, but easy-to-use
possibilities
> of `list-style', or use `display:block' and craft you own list
markers
> with :before.

Oh, no! More caveats? Copious curses on corruption of consistency!

If we could consider list-item to have a :before pseudo-element by
default, we could streamline CSS by eliminating the need for list-item
display type. The list marker is no problem if ('list-style-type'
values || url || strings || counters) can be used as values for the
'content' property. Unfortunately, though, the 'list-style-position'
property is a major impediment.

> The idea is that counters are declared with an @-rule, and can then
be
> used in the `content' property. Counters must be declared explicitly,
> since it is impossible to predict what kinds of things you might want
to
> count.

Hold the rope, give em a virus! Doesn't this violate purity laws?

> We've looked at ways to avoid introducing arbitrary counters, but no
> predeclared set of counters seemed able to do the job.

Did you consider giving each element a counter property for use by its
children, and adding keywords 'counter' and 'parent-counter'?
(accessing counter causes an increment, accessing parent-counter does
not)

For example,

...

BODY      { counter-type: decimal;
            counter-initial: 1 }
H1:before { content: "Section " counter ": " }

DIV       { counter-type: lower-alpha;
            counter-initial: a }
H2:before { content: "Subsection " parent-counter counter ": " }
...
<BODY>
<H1>Headings</H1>
<DIV>
<H2>Subheadings</H2>
<H2>Using the div counter</H2>
</DIV>
<H1>Using the body counter</H1>
<DIV>
<H2>Subheadings</H2>
<H2>Using the div counter</H2>
</DIV>
</BODY>
...

Displayed as:
----------------------
Section 1: Headings

Subsection 1a: Subheadings

Subsection 1b: Using the div counter

Section 2: Using the body counter

Subsection 2a: Subheadings

Subsection 2b: Using the div counter
----------------------

H1 uses the counter of the parent BODY, H2 uses the counter of the
parent DIV.

Here's an ordered list:
...

OL        { counter-type: decimal;
            counter-initial: 1 }
LI        { display-type: block;
            margin-left: 3em }
LI:before { float: left;
            margin-left: -3em;
            content: counter "." }
...

<OL>
<LI>Item one
<LI>Item two with<BR>a line break
</OL>
...

Displayed as:
----------------------
1. Item one

2. Item two with
   a line break
----------------------

There's a problem with the above example in that another class of LI
would have to be defined for unordered lists, with a content of 'disk',
'url', or other marker. Could inherited list-style be used as content?
As in:
...
UL        { list-style-image: url(sumimg.gif);
            list-style-type: disk }
LI        { display-type: block;
            margin-left: 3em }
LI:before { float: left;
            margin-left: -3em;
            content: list-style }
...
?

David Perrell

Received on Tuesday, 6 May 1997 17:40:33 UTC