selectors4

[Raynos]

Having full compliance of http://www.w3.org/TR/selectors4/ in a seperate file.

I see you already have a seperate file for some things. It would be worth adding full selectors4 support as an optional add on (I expect it would be expensive in terms of filesize).

[chjj]

Certain things like the reference combinator (since it's the syntactically weirdest combinator so far) and the subject selector will require internal changes. They can't be done from the outside as an addon. That's fine though, I kind of want to support all selectors anyway. I only put things I consider to be useless (in a DOM) in the extra.js file.

Anyway, the last time I went to implement some, the draft had only a few. I haven't been paying as much attention to the www-style and css world as I usually do. It would be nice to get an idea of how stable things are becoming. Part of the reason I went back and fourth on implementing the subject selector is because they've changed it about 3(?) times now, on top of that I originally implemented it as a pseudo-class as per the original proposal (:subject).

[Raynos]

I forgot to mention personal motivation says I need someone to implement a selectors4 QSA shim that's efficient and trustable.

The way I write shims is implement everything in the editors draft and periodically rage when things change. I'll help out with any difficult features.

[chjj]

The CSSWG seems to have changed the subject selector again: http://dev.w3.org/csswg/selectors4/ .

[Raynos]

1. RAGE AT CSSWG
2. ???
3. Code complies to selectors4

[arextar]

I think stuff like the subject selector and case-sensititivity would be best done in the main file, but I think implementing various pseudo selectors wouldn't be too hard. I'd be happy to help if you want.

[chjj]

@arexkun, I'm definitely doing them in the main file. I just noticed the case insensitivity attribute selector too (I must have missed it the first time, but it's interesting that they added this and not a regex attribute selector, i.e. [attr/=hello/i]).

Zest is missing pseudo classes: current, past, future, default, valid, invalid, column, nth-column, nth-last-column, nth-last-child, nth-last-of-type ( https://github.com/chjj/zest/blob/master/lib/zest.js#L283 ). I want to implement these eventually, but I'm actually in the middle of restructuring the compiler to be faster. Also, fixing some more bug(s)/misbehavior. If anyone makes progress on them, feel free to throw up a pull request.

[chjj]

A lot more has been implemented.

Although, I'm not sure if the :past/:current/:future pseudoclasses are possible to implement. The :column pseudoclasses seem like they would be slightly complicated to implement; having to take into account td, th, col, colgroup, each one's colspan, etc. It's a lot of code, and it's slow. You're essentially writing an interpreter for the table model.

If the TR and the editor's draft for selectors 4 ever agree, I'll enable the subject selector again. The syntax in the editor's draft, simple-selector!, is actually easier and faster to implement. Honestly, I hope they go with that. I might just enable ! now.

[arextar]

I think the :column pseudoclasses would be good for a plugin because, while useful, they don't seem like something one would use very often (plus- as you mentioned- it'd be a lot of code). :past/:current/:future aren't really worth implementing in javascript even if possible.

I think the subject feature is definitely something that should be implemented soon because of the sheer usefulness of it. It allows combinators to be used much more effectively.

[chjj]

I tried writing up a rough implementation of :column, and it was roughly ~100 lines. That is for a robust implementation that takes into account everything in the table model. It's really easy to make a naive implementation and leave it at that, since most people don't bother with thead, tbody, tfoot, cols, colgroups, or colgroups with nested cols. Still not sure what to do there.

I just enabled the subject selector using the simple! syntax in the editor's draft. I really hope they keep that syntax, it looks the best and works the best.

[arextar]

I think that if :column is to be implemented, it should be a low priority and a plugin. I think it's more important that everything else is as optimized and up-to-date as possible.

I think the ! is probably going to stick around because not only does it look nice, but it makes a lot more sense than $ or ?.

[chjj]

The only thing really missing now is :column. I have an implementation written up, but it needs to be tested.

[cscott]

The :scope pseudo-selector seems pretty useful, too.