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? GiovanniReceived on Monday, 23 March 2009 17:30:16 GMT
This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:17 GMT