W3C home > Mailing lists > Public > www-style@w3.org > March 2009

Re: CSS3 missing selector

From: Eduard Pascual <herenvardo@gmail.com>
Date: Mon, 23 Mar 2009 17:39:45 +0100
Message-ID: <6ea53250903230939y7cb6626exf244cecd65a6735@mail.gmail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, Dave Smith <smithd7@tcd.ie>, www-style@w3.org
On Mon, Mar 23, 2009 at 5:16 PM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
> [...]
>>>> <section>
>>>> <h1 or h>My section heading</h1 or h>
>>>> <p>Para</p>
>>>> <p>Para</p>
>>>> <p>Para</p>
>>>> <p>Para</p>
>>>> </section>
>>>>
>>>> Given the above, to style the section content so that it is indented by
>>>> 20px, but leave the heading with no margin can be done with:
>>>>
>>>> ..section > *:not(h1) {margin-left:20px;}
>>>
>>> You could also use ".section > p"
>>
>> Not unless you are sure that all of the block-level content at that level is
>> going to be paragraphs, on all of the pages you apply the style sheet to.
>
> His example was rather short and specific (and usually you want to
> indent paragraphs, not tables)

When dealing with sections, you'd normally want to indent everything,
since one of the typical purposes of the indentation is to serve as a
visual hint on the section structure/hierarchy of the document (sure,
heading levels help with that, but if you aren't seeing all of them at
once, they aren't enough to know how deep you are in the page).

>>
>>> (or negative margins, or text-indent, but this is not relevant to the
>>> selector)
>>>
>>>> but what if the following could be done:
>>>>
>>>> h1:content {margin-left:20px;}
>>>> A pseudo element wraps the content, based on heading scope, and is then
>>>> styled.
>>>>
>>>> and
>>>>
>>>> h1:section { }
>>>> A pseudo element wraps the heading and content, based on heading scope,
>>>> and
>>>> is then styled.
>>>
>>> 1) Pseudo-elements use two colons: "::section" and "::content"
>>> 2) It should always be avoided having pseudo-elements targeting real
>>> elements (instead of CSS generated ones)
>>
>> It could just as easily be a CSS generated wrapper that was more similar to
>> h1:content , but also included the heading.
>
> What do you mean wiht "also included the heading"? What boxes should
> the pseudo-element target / create and what should the resulting CSS
> tree look like?

Honestly, I'd prefer using pseudo-classes rather than pseudo-elements
(actually, my proposal back in november used pseudo-classes).

>>> 3) Something similar to this was already proposed [1]:
>>
>> Usually when the same general idea keeps coming up from different people, it
>> is because there is a perceived need or benefit.
>
> In fact, I do agree that I would be a very good feature to have.

I'd like to point out that this is a need, rather than a convenience.
I already gave some explanation of this on my original proposal, but
to summarize: try to come with a selector that matches any 3rd-level
heading on a HTML5 document (it is achievable). Once you get it (if
you get it right), take a look at what you have and think if something
like :heading(3) or any other direct notation wouldn't make the whole
language more usable.

>>> :heading(<level>)
>>> pseudo-class to select elements that estabilish an heading at that
>>> level (according to the relative language)
>>>
>>> :section(<level>)
>>> pseudo-class to select elements that estabilish a section at that
>>> level (according to the relative language)
>>>
>>> For example, :heading(2) matches "h2" or  "section > section > h" in
>>> XHTML2
>>> :section(1) matches "body" in HTML5

Just a small incise, on my original proposal :section(1) wouldn't
match body on HTML5 (:section(0) would): it would actually match the
main section of the body (probably excluding navigation, aside, and
footer blocks, although it's quite document-dependant). I don't want
to enter into the details of my proposal itself, but just to highlight
the complexity of HTML5's sectioning algorythm, which is one of the
sources of a need for this kind of selector.

>>>
>>>> Apart from being easy to read, one possible advantage is in backwards
>>>> compatibility with old documents (without section elements) that they
>>>> could
>>>> be styled just as easily as new ones. Plus it just feels good, at least
>>>> to
>>>> me.
>>>
>>> Well, old documents don't use new features, so they won''t get much
>>> benefits from this.
>>
>> Sure they do. All the time. It is often possible to have a new CSS file when
>> it is not possible to replace all the HTML on an entire site.
>
> I'm not sure about that, and consider that in plain HTML4 it is easier
> to write "h4" than ":heading(4)", but this is definitely not relevant:
> once a feature is specified and implemented, it can be used
> everywhere.

A site that used to publish pages on HTML4 and later switches to HTML5
would definitely enjoy the ability to keep stylesheets centralized,
rather than having a sheet for "old" content and one for "not-so-old"
content.

>>>> all the best
>>>> Dave
>>>> ---
>>>> Dave Smith, 01 896 3976, smithd7@tcd.ie, Trinity Web Office
>>>> Please CC the Web Office, webdes@tcd.ie, in correspondence
>>>> Please note that electronic mail to, from, or within the College may be
>>>> the
>>>> subject of a request under the Freedom of information Act
>>>>
>>>
>>> Anyway, Selectors Level 3 is currently a Last Call WD, so new features
>>> won't be accepted. You should wait until Selectors Level 4.
>>
>> Its not too arly to start making a list of things we'd like to see in
>> Selectors Level 4, is it?
>
> Well, there is already one at <http://wiki.csswg.org/spec/selectors4>
> but I still think that it is too early to talk about Level 4.
> Selectors Level 3 are yet to finish.

Selectors Level 3 are yet to finish, sure... but they are already
quite set in stone, so a need like this can't be addressed by them. So
definitelly it's not early to talk about Level 4, since that is the
earliest level that could hopefully solve current needs.


Greetings,
Eduard Pascual
Received on Monday, 23 March 2009 16:40:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:17 GMT