67739 - Implement :-moz-outliner-xxx(a,b,c,etc..) pseudoelements

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[David Hyatt]

Tracking bug for the implementation of pseudo-elements for rapid style matching 
in the new tree widget.

Comment 1

[David Hyatt]

Attachment: Patch to add support for pseudoelement to parser and to add capability to specify a comparator on pseudo-element resolution..

Comment 2

[David Hyatt]

Patch is ready for some review.  I'd like r= from pierre and marc, sr from 
brendan.

Comment 3

[Brendan Eich [:brendan]]

What's the target milestone for this?  mozilla0.8 freezes tomorrow at midnight
and I'm pushing to get some 0.8-targeted stuff reviewed and finished.

/be

Comment 4

[David Hyatt]

It can wait until 0.9

Comment 5

[Marc Attinasi]

CC'd Daniel Glazman as he has been mucking about int he parser lately... I'm
looking over the changes now as well.

Comment 6

[Marc Attinasi]

Hey David, this looks great. I was thinking maybe we could generalize the
parsing of the arguments in the '()' for future pseudoelements, but this can be
factored later. Also, is there any value in having an atom for ':-moz-outliner-'
and using it in IsOutlinerPseudoElement? r=attinasi

Comment 7

[David Hyatt]

Not really, since you have to do a substring compare of the first n characters,
and you'd have to convert the atom to a string anyway.

Comment 8

[rbs]

Do you mind explaining how this latest is supposed to work... and letting other
make use of it too :-) I am wondering if its semantics could be relevant to a
peculiar MathML problem that has been bugging me for quite some time w.r.t. to
the current setup of the Style System.

Comment 9

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Being Cc:ed, I took a look at the patch and appreciated a lot (and learned from)
your implem, but still don't understand the purpose of this new pseudo-element.
Could you please give us more hints about it ?

Furthermore, you store the arguments of your pseudo in the list of
pseudo-classes, taking advantage of the way pseudo-elements are stored :
fictional elements preceded by a childhood combinator ; their pseudo-class list
is then always empty...
But :lang() pseudo-**CLASS** and some new css 3 pseudos also accept an argument.
Such an argument can even be (in case of :not()) a simple selector... Then we
probably need for this (or these) argument(s) a storage independant of the list
of pseudo-classes.

Comment 10

[David Hyatt]

I needed to store my results in an atom list.  It is convenient to leverage the
existing pseudoclass list, because I didn't want to create additional storage
for my list (thereby bloating all CSS selectors).

There is no danger of accidental matching, since the pseudoclass list isn't even
checked in any normal case because the tag name (which is the pseudoelement)
will never match anything in a page.

Currently pseudoclasses can't apply to pseudoelements, and even if this changes
in the future, I'm ok with my pseudoelement not supporting pseudoclasses.

Comment 11

[David Hyatt]

And yes, you make a good point that nothing I've really done will help that much
with implementing :lang (except maybe demonstrating a bit how easy the parser is
to use), since you will probably want to store the value inside the () in some
other location (since you won't be able to use the pseudoclass).

Comment 12

[David Hyatt]

The usage of the pseudoelement I'll explain when I write up the tree widget.
The basic idea is that I ditch the entire content model for the tree widget and
rely on pseudoelements to style the widget.

e.g.,

:-moz-outliner-row(open) {
  ...
}

would style all open rows.

:-moz-outliner-row(unread,flagged)
{
...
}

would style an unread and flagged message.

For each row/cell in the tree I ask a back end for a list of properties that are
set on that row/cell, such as open, unread, flagged, etc.  The pseudoelement is
then matched if, for each item in the selector's pseudoclass list, the item is
found in the list of properties supplied by the back end.

So for example, an open and flagged mail/news object would match

:-moz-outliner-row(open)
{
}

or

:-moz-outliner-row(unread)
{
}

Comment 13

[David Hyatt]

That should have been "an open and unread" not "an open and flagged"

Comment 14

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Hmmmm. Reading your explanations,  your -moz-outliner-*** pseudo seems to be a
pseudo-class, not a pseudo-element. Elements are matched against one or more of
their intrinsic properties, which is the definition of a pseudo-class.
Pseudo-elements are "a part" of an element, and I don't see that in your text.

Am I completely wrong ?

Comment 15

[David Hyatt]

The properties inside the () behave like pseudoclasses, but the actual object
itself is a pseudoelement.  e.g.,

:-moz-outliner-row

is a pseudoelement that represents a row object in the tree.  It is not
enhancing any existing content node.  It is conceptually its own object that is
contained inside the tree, e.g.,

outliner::-moz-outliner-row

is conceptually similar to

outliner > -moz-outliner-row

What makes the pseudoelement special is that it can be adorned with a set of
properties inside a parenthetical list, and those properties behave like
*pseudoclasses* that are attached to a pseudoelement.

If it were legal for me to attach pseudoclasses to a pseudoelement in CSS, I'd
have no need to enhance the system at all, but it isn't legal to do this, so
I've come up with a syntax that ends up being simpler anyway (since you can omit
the -moz-outliner-blah that you'd have to put in front of all the pseudoclasses
like open, unread, or flagged.

Comment 16

[David Hyatt]

Fixed.

Comment 17

[Hixie (not reading bugmail)]

verified, it must be working since we now use it in the skins...