Re: breaking overflow

On Jan 2, 2010, at 9:52 PM, "Tab Atkins Jr." <jackalmage@gmail.com>  
wrote:

> On Sat, Jan 2, 2010 at 11:19 PM, Brad Kemper <brad.kemper@gmail.com>  
> wrote:
>> On Jan 2, 2010, at 7:01 PM, Tab Atkins Jr. wrote:
>> On the other hand, if there was a pseudo-element to select a string  
>> of text wherever it occurred, then that would be powerful, and  
>> could also handle suppressing spaces. For instance, lets say you  
>> had something like this (with the optional second argument, "i",  
>> meaning "case insensitive"):
>>
>> p::text("bar",i) { font-weight: bold; }
>>
>> <p>Foo Bar Baz</p>
>>
>> Then "Bar" would be bold.
>
> That suffers from the same problems that are currently keeping us from
> putting ::selection in a draft: what precisely is the sane thing to do
> when you have that selector and the code is <p>foo ba<i>r ba</i>z</p>?

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).

>
>> So to suppress spaces between each inline-block LI in a UL, you  
>> could just use this:
>>
>> ul::text(" ") { display: none; }
>> li::text(" ") { display: inline; }
>>
>> This could be limited to text within the same text node, to avoid  
>> some of the problems with pseudo-elements like "::first-line".
>
> 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?

> Even if it did work, it's a pretty ugly solution imo to something
> solved much more simply and elegantly with the white-space-collapse
> property you pointed out.

Agreed...

> 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.

> 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.

Received on Sunday, 3 January 2010 07:50:02 UTC