> I find it better to keep meanings of elements.  <p> means "a =
paragraph".  If=20
> suddenly, <ps> means "either a section, or a paragraph, or whatever =
the=20
> author wanted it to mean", then nobody knows what it is anymore.

> Otherwise you might as well replace every element with a single=20
> <block-of-text> element, since you can argue almost any element is =
against=20
> the idea of "generic" markup (list items could be <ps> too, if inside =
a <ul>=20
> or <ol> element.)

I don't want <ps> to be "a paragraph or a section". I think it should be =
"a structural group of text", because both <p> and <section> group text =
in a similiar way. The only difference is that <p> is the lowest-level =
grouping, and <section> builds all the other levels.
Of course, if you think the semantics of a paragraph are not only to =
group a bit of text but also anything else, we should keep <p>.

> Never mind that XPath isn't part of CSS.  Even if browsers knew XPath, =
how=20
> would they happen to know this obscure instance of it being mixed with =
CSS=20
> which isn't, and probably never will be, in any standards?

I didn't want to use XPath inside of CSS but I meant that a browser =
could internally use XPath to determine the difference between =
paragraph-like <ps> (rendered as paragraph (e.g. with margins)) and =
section-like <ps> (normally no special rendering, but gives ability to =
find out about the structure) without the need of much extra code.

> The general idea of having to look ahead to the next element to =
determine=20
> rendering on the current element, has been considered bad for years =
now.

Of course, this is a strong argument for a <p>-element, which is, as =
said above, the LOWEST-level grouping and so you know that there will be =
no <p> or <section> child.

Yours,
Daniel Kraft