Re: CSS3 missing selector

2009/3/23 Brad Kemper <brad.kemper@gmail.com>:
>
> On Mar 23, 2009, at 9:16 AM, Giovanni Campagna wrote:
>
>> 2009/3/23 Brad Kemper <brad.kemper@gmail.com>:
>>>
>>> On Mar 23, 2009, at 6:15 AM, Giovanni Campagna wrote:
>>>
>>>> 2009/3/23 Dave Smith <smithd7@tcd.ie>:
>>>>>
>>>>> Hi www-style
>>>>>
>>>>> I believe there is a useful and yet missing selector. I'll explain by a
>>>>> rough example:
>>>>>
>>>>> <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)
>
> Examples on a mailing list tend to need to be pretty short. I think the
> general idea is to be able to separately style the content that the heading
> refers to. In this case its not really indent he wants (even though he used
> that word), its margin-left, which could be for tables, lists, DIVs, etc.

I agree with you about margin != indent. Anyway, the fact that margin
should be applied to paragraphs or tables seems more a matter of
personal opinions.

>>>> (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?
>
>
> <section>
>    <anon for="h1::content-parent">
>        <h1>My section heading</h1>
>        <p>Para</p>
>        <p>Para</p>
>        <p>Para</p>
>        <p>Para</p>
>    </anon>
> </section>
>
> <section>
>    <h1>My section heading</h1>
>    <anon for="h1::content">
>        <p>Para</p>
>        <p>Para</p>
>        <p>Para</p>
>        <p>Para</p>
>    </anon>
> </section>
>

I see what you mean. I imagined something like that, but I wasn't sure.
But, since you're only talking about ::content (not :heading)... how
would you select content and content-parent when sectioning is not
explicit, ie when dealing with numbered headers like

<body>
<h1>Title
<p>text 1
<h2>Subtitle
<p>Text 2
<p>Text 3
<h3>Sub-subtitle
<h4>Sub-sub-subtitle
<p>Text 4
<h3>Sub-subtitle 2
<p>Text 5
<h1>Title 2
</body>

What is ::content for h3?
Would it include <h4>?
What if I used <h7>?
What if "::content" was used in conjuction with a non heading element
(like p::content)?
What does "::content" mean on its own? Does it wrap all children of :root?

Secondly, what are the use cases for "::content-parent" not achieved
by :matches?

>>>> 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.
>>
>>>> :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
>>>>
>>>>> 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,
>
> I am. I deal with a site with hundreds of pages, and when it is time for a
> redesign, it is mostly in the CSS file. I sometimes have to do a "find and
> replace" on snippets of HTML that occur throughout the site, but clearly
> that is the less desirable thing to do, and mostly has to do with very old
> code, or a change in non-strictly-presentational elements. The modern ideal
> is for presentational styling to be all in the CSS, so that CSS is all you
> need to change to do a redesign (aside from redesigning the navigation,
> etc.).

I agree that changing only CSS is a goal we should try our best to achieve.

> I also have to sometimes create CSS files for partner sites, where I have NO
> control over the HTML, but can provide style sheets for the look, feel, and
> branding (the sales reps always say "it can look just like it is part of
> your existing site!").
>
>> and consider that in plain HTML4 it is easier
>> to write "h4" than ":heading(4)",
>
> I don't understand your point here.

h4 is always the forth level heading in HTML4. So :heading(4) and h4
match the same elements ( :heading(4):not(h4) matches none) This means
that, in pure HTML4, writing h4 or :heading(4) is the same.

>> but this is definitely not relevant:
>> once a feature is specified and implemented, it can be used
>> everywhere.
>
> Right. What matters is the feature being in common UAs, not so much about
> old HTML documents.
>

Exactly.

>>
>>
>>>>> 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.
>
> So, apparently csswg.org disagrees with you.

I'm not part of the CSSWG and I have no control on that site. This is
my personal opinion about Selectors Level 4 or 5 or 6.

>>
>> Selectors Level 3 are yet to finish.
>
> This is a well known statement of fact, yes. But they are nearly finished,
> and it is good to know that ideas for CSS4 selectors are not being ignored.

I hope that no proposal in this mailing list is ever ignored, altough
it may be delayed indefinitely.

What I mean is not that we should not put this feature in Selectors
Level 4 (I hope it will be included), just we should not focus on
Selectors Level 4 now and rather end existing work first: there are
many wonderful features in CSS3 that are given Low Priority, what will
be of them if we start now with CSS4?

Giovanni

Received on Monday, 23 March 2009 17:30:16 UTC