Re: content property

David Perrell wrote:
> 
> Hakon Lie wrote:
> !> ... There is a proposal to add this capability
> !> in the future, e.g.:
> !>
> !>   Q:before { content: "«" }
> !>   Q:after { content: "»" }
> 
> Are "before" and "after" 'added-content' pseudo-elements, as BR is an
> added-content element? Will the "content" property apply only to such
> added-content elements?

: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
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).

It's not just that people will `hang themselves when given the rope,' it
is also the case that they might unknowingly make important information
inaccessible to others, both to people on different systems and to
people on future systems. (In a way, and perhaps paradoxically, the
ultimate goal of CSS is to make it possible for HTML files to be easily
readable in Notepad.)

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

Furthermore, the more text there is in these generated boxes, the harder
it is to edit in pseudo-WYSIWYG mode.

But back to `:before' and `:after':

Current working hypothesis is as follows:

:before and :after apply to as many elements as possible, and whether
they apply depends on the `display' property. (By now, the readers of
this list will understand that `display' is modeled on DSSSL's flow
objects, and we can thus say, approximately, that :before and :after are
somewhat like two extra `ports' on certain flow objects.)

> 
> Where would "LI:before" appear relative to a list-item marker? Or would
> the list-item marker be considered a default "before" pseudo-element
> such that styling could be applied to the marker (eliminating the need
> for a more specific marker pseudo-element)?

When we added the `list-style' marker to CSS1 we were aware that we
would have to change the handling of list labels later, but we decided
that `list-style' was such an easy match with HTML and covered so many
cases, that we should just keep it as a special case.

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.

> 
> !> The new 'content' property would also be useful for e.g. automatic
> !> numbering of elements.
> 
> How? Are incrementable variables part of the proposal?

Correct.

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.

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



Bert

Received on Tuesday, 6 May 1997 05:06:23 UTC