Re: Proposed ::last-line and ::last-letter selectors

I found some use cases which I think would be generally helpful:

     If a number is negative, print it in red.
     If a name (IBM) appears in a page, make the word's font larger and blue.
     Display all (American) monetary values with a dollar sign ($), a decimal 
point (.) and cents ("$f8.2" for example).

I recognize that this can be done with Javascript, but so can changing the style 
on MouseOver or on Focus. My thought was that CSS should handle formatting 
(style) and this ability is not present in the standard. As more web pages are 
dynamic, this could become very useful, to people creating mashups, for example.

The current pseudo-elements can be included as special cases of this ability:

	first-line	({^.*$}1)
	first-letter	(^.)
	before		(^)
	after		($)

Once the current pseudo-elements are included as special cases, almost anything 
is possible, including:

	last-letter	(.$)
	last-line	({^.*$}n)

I can think of many other use cases where this ability would assist in styling a 
document and (since there are many regex engines available) it might even make 
the coding of the functionality simpler. Recognizing that this adds the very 
complexity Christoph is concerned with, is this worth pursuing? My preference is 
to include flexibility, so that, when a user thinks of some use case we never 
considered, there is a way for that user to produce the desired effect. However, 
I know that this opens a large can of worms. (How much of the full pattern match 
will CSS support? What special characters will be used? (*/?+{} ...) What rules 
will be necessary to keep the pseudo-elements from conflicting with existing 
elements? And probably many others.

This next is partially off topic, and I apologize in advance if it trespasses 
the group's etiquette:

I believe the encoding scheme for pseudo-elements (using '::') will cause 
confusion and become prone to errors. I would recommend selecting some other 
character(s). (I might suggest the '&' character, as it is a representation of 
'Et' and could be considered mnemonic for element.)

The reason for this change is that I would like to use the above mentioned 
pattern match as pseudo-classes, as well as pseudo-elements. If a paragraph 
contains the string 'IBM' change the background to lightblue, if it contains 
'Exxon', change the background to lightgreen, etc. This would make the following 

	&(IBM)	{ color: blue; }
	:{IBM}	{ background-color: lightblue; }

The first creates a pseudo-element and applies the style to it. The second 
locates an element which contains that text and applies the style to that 
(existing) element.

Sorry to come to the party so late. Thanks for your consideration of a newbie.

 >*Philip TAYLOR*:
 >> 111111111111111111111111111
 >>      2222222222222222222222222222
 >>      3333333333333333333333333333
 >>      4444444444444444444444444444
 >>           5555555555555555555555555555
 >> This is used (for example) in typesetting
 >> very long chapter headings, and for typesetting
 >> very long entries in Tables of Contents and
 >> in Indices.
 >I wanted to write this would rather be an argument for a counterpart
 >of |text-indent| (|text-outdent|?), but that is the case only if the
 >desired layout was (assuming "text-align: justify", and left-to-right
 >text obviously):
 >      2222222222222222222222222222
 >      3333333333333333333333333333
 >      4444444444444444444444444444
 >      555555555555555555555555555555555
 >Most use cases I can think of can alternatively be done with
 >|::after| or another element, depending whether EOT markers etc. are
 >considered style or content.
 >Following the symmetry / consistency argument, we would probably have
 >to introduce |::nth-line()| and |::nth-letter()|, too. Do we really
 >want to go down that road? How about |::letter()| then, which would
 >take a one character string as an argument? Or rather |::regexp()|?
 >Let's wait for CSS 4 or 5 with stuff like that, please.

James Elmore
22162 Windward Way
Lake Forest, CA 92630
Home	(949) 830-9534

Received on Tuesday, 22 August 2006 03:01:52 UTC