- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 3 Jan 2010 08:58:22 -0600
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: www-style list <www-style@w3.org>
On Sun, Jan 3, 2010 at 1:49 AM, Brad Kemper <brad.kemper@gmail.com> wrote: > Well that's why I suggested that it be limited to individual text nodes, not > to text that crossed into (or were broken by) other elements. Even with that > limitation, it would still be powerful and very useful (especially if you > could use regular expressions). Ah, okay. That makes it relatively simple to deal with, then. There's still some cases you have to handle, though - how would the following display? <p>foo bar baz</p> p { color: black; } p::text("foo") { color: red; } p::text("foo bar") { color: blue; } p::text("bar baz") { color: green; } That's one simple nesting, and one non-trivial overlap. >> Don't line breaks get normalized to spaces during the >> whitespace-collapsing step? >> In that case this code still wouldn't >> work, as it'd miss those linebreaks. > > That sounds like like you just refuted your own argument. If a line break is > turned into a space in the DOM, and that space is selected with the > pseudo-element and not displayed, then what's the problem? Whitespace isn't collapsed in the DOM, it's collapsed as a display effect only. (CRLFs get normalized during parsing, but that's it.) If ::text() operates on the DOM, it will miss the linebreaks, which will subsequently get turned into spaces for display. To make this work you'd need a full regexp so you can select all whitespace. >> Something like ::text certainly has some >> uses I can think of, > > I find myself often wishing for it, especially when styling HTML that I > can't edit myself. Indeed, I have many cases where it would be useful, where I'm currently just adding completely meaningless spans around arbitrary groups of text because of how I want it to display. For example, the heading at http://webportal.igofigure.com/webportal has four pretty unnecessary inline elements to generate the desired effect for the text. >> but I'd rather solve the issue of whitespace >> handling more directly. > > Well, sure, I'd like both too. But if I were to choose which I wanted more, > it'd be the more powerful thing that fulfill do both roles if need be. It can't fulfill both roles, though - it's not capable of duplicating the other values for white-space-collapse. I'd rather not decide which one I want more - I want them all. ^_^ ~TJ
Received on Sunday, 3 January 2010 14:58:54 UTC