Re: Text selector [was Re: breaking overflow]

On Jan 7, 2010, at 6:00 AM, Tab Atkins Jr. wrote:

>> Follow normal cascading rules for each matched character, as though you were creating individual pseudo-boxes for each character, but adjacent character boxes that have the same pseudo-boxes because of the same rule get merged together into one box after all the text of the element has been otherwise resolved.
>> [...]
> 
> I can't tell if that's the same or not, but if confuses me anyway.

Well, I think the concept should be easy to understand (perhaps moreso for a newbie than for someone thinking in DOM terms): I want the effect that each rule acted like a "find" command on the element's text, applying its rules to that text [1]. Each additional rule that found some of the same text would apply it's formatting to that text too, as though you did an additional "Find" command and applied additional formatting to the matches.

From a "how can that work in the DOM" point of view, it would be as there was three operations (I'm not dealing with resolving white space problems right now, just the more general part of how which pieces get which style):

1. Find the matching text for the rule (strings in the matching element that are not broken by other elements)

2. Next, for each matched string, you act as though the rule was a kind of shorthand for finding each individual character separately, and you make each letter into a pseudo-element. Rule order and specificity replace existing letter boxes.

Repeat steps 1-2 for each ::text() rule, with step one ignoring the pseudo-element boxes and just matching the text as though there were not there.

3. At some point before rendering the element, join together pseudo-elements that are both adjacent and are possessing identically styled pseudo-boxes.

Please let me know which of the above is unclear, if it still is, or impossible to implement in that order. Here are examples (referring to the above steps as "Step 1", "Step 2", or "Step 3"):

<p>ABCDEF</p>
p * { border-style: solid; }
::text("ABCD") { border-color: red; }
::text("CDEF") { border-color: blue; }

So the first rule finds the "ABCD" text (Step 1), and creates 4 pseudo-elements (Step 2): 1 for "A", 1 for "B", etc., like this:

<p><text match="ABCD">A</text><text match="ABCD">B</text><text match="ABCD">C</text><text match="ABCD">D</text>EF</p>

Then the second rule finds the "CDEF" text (Step 1), and creates 4 pseudo-elements (Step 2), with the "C" and "D" having their pseudo-boxes replaced by this later rule, like this:

<p><text match="ABCD">A</text><text match="ABCD">B</text><text match="CDEF">C</text><text match="CDEF">D</text><text match="CDEF">E</text><text match="CDEF">F</text></p>

Once all the rules have been parsed and these temporary new boxes created, the smart merging from step 3 takes place, and you have this:

<p><text match="ABCD">AB</text><text match="CDEF">CDEF</text></p>

...with result that there is now a red border around "AB", and a blue border around "CDEF" (which I consider the most intuitive result for rules that find and style raw text). The style is assigned granularly based on each letter, but final rendering is in chunks so that properties like margin, display, etc. work well.

This also works for your last example:

<p>ABCDEF</p>
p * { border-style: solid; }
::text("ABC") { border -color: red; }
::text("CDF") { border -color: blue; } /* not E */

The first rule finds the "ABC" text (Step 1), and creates 3 pseudo-elements (Step 2): 1 for "A", 1 for "B", 1 for "C", like this:

<p><text match="ABC">A</text><text match="ABC">B</text><text match="ABC">C</text>DEF</p>

The second rule does not find "CDF", so it does not go on to step 2.

Now the boxes around each character are merged, and you get this:

<p><text match="ABC">ABC</text>DEF</p>

...and a red border is drawn around the "ABC" part.


[1] Like if, in Microsoft Word, you used the "Find and Replace" command with it's expanded options, but with no text in the replace part, just formatting from the "Format" pop-up.

Received on Thursday, 7 January 2010 16:58:50 UTC