W3C home > Mailing lists > Public > www-style@w3.org > January 2010

Re: Text selector [was Re: breaking overflow]

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 4 Jan 2010 10:05:49 -0800
Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
Message-Id: <2B911FB4-93A1-4973-9CCA-1E49F654CF1C@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Jan 4, 2010, at 8:52 AM, Tab Atkins Jr. wrote:

>> Note that I'm OK with ::text not matching across element boundaries, at
>> first glance, and not entirely convinced we want a ::text at all, but if we
>> _do_ have it, I think it should have restrictions similar to first-line at
>> least.
> 
> If we *don't* allow it to match across element boundaries, then is
> there a good reason for the restrictions?  I don't believe there is.
> I'm not seeing anything wrong with, say, turning an arbitrary span of
> text into a display:table-cell as long as it can be wrapped in a
> single pseudoelement box.  There is significant power to be gained by
> allowing the full suite of properties on ::text, which is a very
> strong argument for not allowing it to cross element boundaries.

This is my feeling exactly.

On Jan 4, 2010, at 8:05 AM, Boris Zbarsky wrote:

>> <p>foo<i>bar</i>  baz</p>
>> p::text("foo b") { display: block; }
> 
> Hold on.  Why would we ever allow ::text to have a 'display' property set?  What are the use cases?  I have been assuming that ::text would have restrictions similar to first-letter and first-line.

I think there are all sorts of use cases. Here is one:

::text("Example \d: *\n") {
   display: block;
   padding: .5em;
   margin: 1 em 0;
   border: 1px solid #999;
   background-color: #eee;
}

(The "\n" part is assuming that a "<BR>" would be recognized as a newline, but that is not central to this part of the discussion.)




Received on Monday, 4 January 2010 18:06:26 GMT

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