- From: James Elmore <James.Elmore@cox.net>
- Date: Mon, 21 Aug 2006 12:46:10 -0700
- To: www-style@w3.org
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 possible: &(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): > >111111111111111111111111111111111 > 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 Email James.Elmore@cox.net
Received on Tuesday, 22 August 2006 03:01:52 UTC