CSS selectors-4 issues

CSS
1

I can’t see selectors-4 on any of the popular accounts on github to raise issues there.

However there are a lot of unanswered questions on the specification and I just wondered where the best place to discuss them is (Obviously I’m aware of the mailing list however sometimes it doesn’t seem the best place until the idea actually has more weight than “I think it should have this syntax”, “Yeah, well I like this syntax”).

Issue 11 was the one I was currently interested in:

It seems that :blank may be a little ambiguous however is more specific than :-moz-whitespace-only which implies the element can’t be empty.

The best I could think of would be add :space which would match only elements with spaces in them, then to get :blank functionality you could use: el:matches(:space, :empty).

I considered something off the wall like :trim where most languages would see whitespace or not as acceptable, however I think it is more confusing than :blank. I also considered :collapsable but again confusing.

I guess the prefix should match whatever gets settled for text-space-collapse vs white-space-collapse, unless this has been removed completely.

There is some bikeshedding for you all, I know how much you all like it hah.

1 Like
2

I think this forum (Specifiction) is preferred over GitHub for discussions about web standards.

3

I thought that too, I like to check if there is one already then realised I couldn’t even find it on github.

4

I’m okay with :blank, not sure I see the value of using :whitespace-only or something else.

Also, I like the current semantics of :blank, equal to :matches(:empty, :whitespace-only). I’ve never had the use case of selecting an element that must contain a text node which must contain only whitespace. What I’ve had is trying to use :empty with an intent of “there is no non-whitespace text or child element”, and seeing it fail. :smile:

5

Instead of adding additional special-case keywords, why not add a :text pseudo for generalised pattern matching of text content, based on a limited regular expression syntax?

E.g. *:text('\s*') would match all elements containing whitespace (or nothing)

td:text('NA') would match all table cell elements containing only the text “NA”, etc.

6

I was thinking the same myself, however I was thinking around just about putting a better name to the current usage. The only previous mention of such implementation was :contains() which got dropped and this appears to be the last mention of it by @tabatkins - https://lists.w3.org/Archives/Public/www-style/2012Apr/0380.html

I don’t think there is better semantics than separating the space out and uses matches for both, as @fvsch says though I don’t really see the use case of space on it’s own.

7

I don’t like anything that requires :matches() for the common case; I don’t think there’s really a use-case for selecting things that contain only whitespace characters.

8

@tabatkins I don’t like both either to be honest - just bikeshedding to get the conversation out there :smiley:

I’m not really seeing anything better than :blank.

Am I right in thinking the :contains() got shelved through lack of interest in implementers?

9

That, plus the aforementioned performance issues. I haven’t felt the urge to put it into the spec under the Complete profile yet.

10

@tabatkins so issue resolved, there isn’t a better name :smiley:

Is this the preferred place to discuss the issues on specs then?

Do all editors drafts not go onto github yet?

As an aside I’m really excited by the new approach to specifications: http://w3c.github.io/modern-tooling/

11

Here, or on the www-style@w3.org mailing list.

All of the CSSWG drafts are on GitHub - https://github.com/w3c/csswg-drafts/. Using GitHub issues to report bugs is fine, but we prefer substantive conversation happen on the mailing list.

12

Thanks I missed that one.

Yeah I read the mailing list a lot but rarely see any worth in adding threads there as that to me feels reserved for large sweeping changes or well structured research. I have never felt comfortable to discuss pointless things like this on the mailing list.

I guess this all comes out of the modern tooling which @robin is leading.