[CSS3] Generated and Replaced Content

Looking through the draft I still can't figure out how one could (is
it possible to) group several elements and style a generated
containing block for the group. This is much similar to a typical
HTML structure:

<H1>
<P>
<H2>
<P>
<H3>
<P>
<H2>
<P>
<P>

So an application processing this document would "generate" the
following containers: one containing the H1 element and everything
bellow, a nested containers for the two H2 elements grouped with
elements following them (delimited by the appearance of the H2
elements), etc. I say "generate" because an application is not
necessary to display the document but only to process the data and
generate an outline (for internal processing use) with the specified
algorithm.

A similar case is with the definition list and DT and DD elements in
HTML:

<DL>
<DT>
<DD>
<DT>
<DD>
<DT>
<DD>
</DL>

It would be nice if CSS could select a DT element grouped with all
next (DD) elements till reaching next DT element and generate a box
to apply some formatting.

--
Stanimir

Stanimir Stamenkov wrote:

Looking through the draft I still can't figure out how one could (is it
possible to) group several elements and style a generated containing
block for the group. This is much similar to a typical HTML structure:

H1
P
H2
P
H3
P
H2
P
P

So an application processing this document would "generate" the
following containers: one containing the H1 element and everything
bellow, a nested containers for the two H2 elements grouped with
elements following them (delimited by the appearance of the H2
elements), etc. I say "generate" because an application is not necessary
to display the document but only to process the data and generate an
outline (for internal processing use) with the specified algorithm.

CSS is about presentation, not about transformation. The latter is the
job of e.g. XSLT. Additionally note, that it is generated _content_ not
generated _structure_.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)

Johannes Koch wrote:

CSS is about presentation, not about transformation. The latter is the
job of e.g. XSLT.

I'm talking about presentation. I've given an example to see in
which direction I'm thinking of.

Additionally note, that it is generated _content_ not
generated _structure_.

So,

E::before
E::after

or

E:utside

are "generated _content_" only and not "generated _structure_"?...
Hmm, I don't agree.

--
Stanimir

On Wed, 29 Oct 2003 13:15:30 +0200,
Stanimir Stamenkov <s7an10 (AT) netscape (DOT) net> wrote:

A similar case is with the definition list and DT and DD elements in
HTML:

DL
DT
DD
DT
DD
DT
DD
/DL

It would be nice if CSS could select a DT element grouped with all
next (DD) elements till reaching next DT element and generate a box
to apply some formatting.

Easy enough to do if you use definition lists in a much *better* way.
Each list as a list of definitions for one thing. You do the grouping
at the DL element (applying a style to it as a whole), not within it.

e.g. <dl>
<dt>A definition title (something to be defined)</dt>
<dd>One possible definition of it.</dd>
<dd>Another possible definition of it.</dd>
<dd>Yet another definition of the same thing.</dd>
</dl>

<dl>
<dt>Something else to be defined</dt>
<dd>One of its definitions.</dd>
<dd>Another of its definitions.</dd>
</dl>

While the specs do give an example in the way that you've done; when you
use that approach, there isn't any defined boundaries as to what dt and
dd elements belong together. It's just sort-of *implied* that a new dt
starts off a new definition.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

Tim wrote:

On Wed, 29 Oct 2003 13:15:30 +0200,
Stanimir Stamenkov <s7an10 (AT) netscape (DOT) net> wrote:

It would be nice if CSS could select a DT element grouped with all
next (DD) elements till reaching next DT element and generate a box
to apply some formatting.

Easy enough to do if you use definition lists in a much *better* way.
Each list as a list of definitions for one thing. You do the grouping
at the DL element (applying a style to it as a whole), not within it.

Thank you for the good example. May be mine wasn't so successful. Do
you have a "solution" for the fist case (with heading elements),
aside from using additional elements to delimit sections?

I'm interested more in this because many times I have to put
additional elements which not necessary delimit logical sections but
are put so they could be styled. An example:

<HEADER/>
<CONTENT/>
<FOOTER/>

So if I want to style the "content" and the "footer" to show a right
border I put:

<HEADER/>
<GENERIC>
<CONTENT/>
<FOOTER/>
</GENERIC>

So I could style the "generic" showing right border. May be some
would argue that I could put right border on both "content" and
"footer", but then they are really separate boxes and I want the
"generic" element box - its height is different which plays
important role in positioning, etc.

If CSS propose extended syntax for specifying such groupings I
wouldn't need to put such extra markup and I would easily group the
"header" and "content" lately when I change my mind about the
general layout.

--
Stanimir

On Thu, 30 Oct 2003 16:15:27 +0200,
Stanimir Stamenkov <s7an10 (AT) netscape (DOT) net> wrote:

Thank you for the good example. May be mine wasn't so successful. Do
you have a "solution" for the first case (with heading elements),
aside from using additional elements to delimit sections?

To be honest, that'd be the easiest approach (and more likely to work in
more browsers - some are quite awful at specialised selections),
especially as there aren't any other special HTML elements that already
do the task.

If you are creating pages where the body has a head, content and foot
section, then I think that you really would want to put in divisions at
the right points, rather than try and make certain groupings of elements
*show* as the divisions, with no actual delineation of the structure
(which is something that you need, the content divided into parts at
specific places, rather than trying to fake separations with a "look").

For instance, if I were making a series of documents that had an
introduction section, an example section, and a summary section, I think
that I'd be explicitly outlining those sections so that I could put any
elements appropriate within them, and not need special styling rules.

e.g. <h1>Blah<h1>

<div class="introduction">
<h2>All about blah</h2>
<p>Blah blah blah.</p>
<p>Blah blah blah.</p>
<p>Blah blah blah.</p>
</div>

<div class="example">
<h2>How to blah.</h2>
<p>Blah blah blah.</p>
<p>Blah blah blah.</p>
</div>

<div class="conclusion">
<h2>Blahing.</h2>
<p>Blah blah blah.</p>
<p>Blah blah blah.</p>
</div>

It's then a simple task to style the three main parts of the page, it's
also a simple task to re-style all the pages, keeping the different
sections consistent, no matter what the actual content was.

That's really all I can think of, since your example isn't that
explicit.

If CSS propose extended syntax for specifying such groupings I
wouldn't need to put such extra markup and I would easily group the
"header" and "content" lately when I change my mind about the
general layout.

I think that'd be harder, you'd have to make rules that certain sections
were made up of certain elements (e.g. a H2 followed by three P
elements), and have to write your HTML in that special way.

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

Tim wrote:

On Thu, 30 Oct 2003 16:15:27 +0200,
Stanimir Stamenkov <s7an10 (AT) netscape (DOT) net> wrote:

If CSS propose extended syntax for specifying such groupings I
wouldn't need to put such extra markup and I would easily group the
"header" and "content" lately when I change my mind about the
general layout.

I think that'd be harder, you'd have to make rules that certain sections
were made up of certain elements (e.g. a H2 followed by three P
elements), and have to write your HTML in that special way.

I've posted the issue on the "www-style" mailing list at w3.org. You
could take a look at the replies if you're interested:

http://lists.w3.org/Archives/Public/...3Oct/0319.html

--
Stanimir

Stanimir Stamenkov <s7an10 (AT) netscape (DOT) net> wrote:

If CSS propose extended syntax for specifying such groupings I
wouldn't need to put such extra markup and I would easily group the
"header" and "content" lately when I change my mind about the
general layout.

Tim wrote:

I think that'd be harder, you'd have to make rules that certain sections
were made up of certain elements (e.g. a H2 followed by three P
elements), and have to write your HTML in that special way.

Stanimir Stamenkov <s7an10 (AT) netscape (DOT) net> wrote:

I've posted the issue on the "www-style" mailing list at w3.org. You
could take a look at the replies if you're interested:

http://lists.w3.org/Archives/Public/...3Oct/0319.html

I've had a look (web forums, yuck - tedious and can't be done off-line),
and the suggestions follow the same train as I made: That if you have
distinct sections to some data, you need to delimit them at the content
(such as classed DIVs in the HTML, or custom XML elements), sub-dividing
the data, itself. You apply the separate styles on top of the delineations.

It'd be hard pressed for something else to figure out where the
separations lay, just by guessing at some of the types of structures
used in each section. Styling should be applied to things based on
content, not the other way around (e.g. style the head, because it's the
head, not guess where a head might be and make it look like one).

--
My "from" address is totally fake. The reply-to address is real, but
may be only temporary. Reply to usenet postings in the same place as
you read the message you're replying to.

Tim wrote:

Stanimir Stamenkov <s7an10 (AT) netscape (DOT) net> wrote:

http://lists.w3.org/Archives/Public/...3Oct/0319.html

I've had a look (web forums, yuck - tedious and can't be done off-line),

Actually, it's a mailing list
<http://www.w3.org/Mail/Lists.html#www-style> and the above are its
archives accessible through the Web.

--
Stanimir

Tim wrote:

Stanimir Stamenkov <s7an10 (AT) netscape (DOT) net> wrote:

http://lists.w3.org/Archives/Public/...3Oct/0319.html

I've had a look (web forums, yuck - tedious and can't be done off-line),
and the suggestions follow the same train as I made: That if you have
distinct sections to some data, you need to delimit them at the content
(such as classed DIVs in the HTML, or custom XML elements), sub-dividing
the data, itself. You apply the separate styles on top of the delineations.

It'd be hard pressed for something else to figure out where the
separations lay, just by guessing at some of the types of structures
used in each section. Styling should be applied to things based on
content, not the other way around (e.g. style the head, because it's the
head, not guess where a head might be and make it look like one).

O.k. A real case I got recently: A have a longer document with TOC
links at the top (just following the main H1 heading) for
faster/easier access. I'm using the :target pseudo-class supported
in Netscape/Mozilla [1] to highlight the current section being
pointed by the fragment id of the URL. So the typical structure is:

<h1/>

<ul/> <!-- TOC links -->

<div class="section">
<h2 id="first-section"/>
<p/>
</div>

etc. I highlight (specify a different background) the whole
"section" block (I want it that way). I have longer sections which
look like this:

<div class="section">
<h2 id="n-th-section">
<ul/> <!-- TOC links for the section -->
<div class="section">
<h3 id="n-th-section-first-subsection"/>
<p/>
</div>
<div class="section">
<h3 id="n-th-section-second-subsection"/>
<p/>
</div>
</div>

In this case I don't want to highlight the whole "H2" section but
only the heading 'h2' and the prolog 'ul' (the TOC) elements. Then
to highlight separate "H3" sections when pointed. I don't think
grouping the heading and any prolog elements would make better/more
proper markup.

Of course I could try to match the 'h2' and 'ul' elements separately
but if I add additional elements to the prolog (a 'p'aragraph of
text, for example) I have to put additional style declarations or
even if I want to achieve style which is dependent on a visual
containing block for all these elements - I wouldn't be able to
achieve it, may be.

[1] http://devedge.netscape.com/viewsour...arget-selector ,
http://www.w3.org/TR/css3-selectors#target-pseudo

--
Stanimir