Mine displays the elements as nested blocks, instead of printing a tree.
I actually posted https://select.pink/ to HN ages ago, but it died in `new`: https://news.ycombinator.com/item?id=24959045
OP's game has some nice features. The timing is neat, and to be honest I didn't even consider using the source as the visualization.
(You could write <input/>, the old XML syntax for self-closing tags, but I strongly recommend against doing that because it teaches a wrong mental model: that trailing slash is permitted in HTML syntax on void elements for XHTML compatibility but does not close an element: it’s just ignored.)
What's wrong with using XML as the underlying mental-model for HTML5 (HTML "Living Standard", etc)? HTML still supports XHTML and (to my knowledge) the only appreciable difference between HTML and XHTML is the requirement that the HTML tag soup be a well-formed XML document. That's it. XHTML is still valid HTML, and XML's model is simple and easy to understand and covers 100% of HTML's use-cases.
The difference between XHTML today vs. back in 2005 was that the W3C grossly underestimated the extent at which modern tooling will continue to generate invalid HTML markup (let alone any truly semantic HTML markup either), so web-browsers and scrapers needed to be more forgiving in their input processing and also standardise how they interpreted invalid HTML. None of that precludes us from writing software to a higher standard: software which generates valid XHTML which allows HTML to be handled by existing XML-processing infrastructure (and even serialized to JSON if you're crazy). What's "wrong" about any of that?
What I observe is that it’s quite common for people to put in the trailing slash on void elements, but that it’s almost never (<1%) applied consistently (you’ll see some <link/> and some <link>) so that any XML syntax compatibility argument is void, and I’ve come across at least one person who thought it was necessary and at least one person who thought it closed tags (and thus could be applied to non-void elements) and was surprised that it didn’t.
XHTML is dead. XML syntax for HTML is on indefinite life support (with no prospect of being either revived or removed). HTML is not XML: the HTML and XML syntaxes are mutually incompatible (e.g. <noscript> isn’t possible in XML syntax, and <script>"&"</script> produces a different result). Writing your HTML in more XMLy ways isn’t about higher standards, but about making it something that it’s not. It’s wrong to use XML processing infrastructure on HTML documents unless they’re marked as XML syntax, because even if it doesn’t fail, it may interpret things incorrectly.
I feel like there should be another scoring axis rather than just time. I think selector length would be wrong, but something like selector complexity, or how robust the selector is to updates.
I scored 3m 50s, but felt like some of my selectors were a bit 'dirty'.
The intended solution is just :enabled. This is where I think this project has failed badly in its stated goal to “improve your CSS knowledge”, because all it offers in that direction is a little hint link; to actually teach, it needs a set of proposed solutions, and at the end show you any where you differed.
Such a thing might also help suggesting just [data-item] instead of the needlessly-more-specific span[data-item]. And also whether :nth-child(2n+3) was the intended solution on one of them.
#one, #three, #five, #six, #nine
It feels like it is missing ways to help you get to understand things on your own, so a bit more like a test than a real game. Maybe a codegolf scoring (number of characters) and/or semantic scoring (number of atomic expressions used) would help?
As somebody who's doing frontend excessively rarely, it would feel more rewarding to see it compared to some good practices answers. Maybe store the results so you could display the most frequent answers in a future iteration?
Took 16 minutes, trying to understand more than to speedrun. Btw, link of hint 10 is broken (there's an extraneous comma).
The dynamic selection dots are quite neatly done. I found it quite fun and it seems like there are many ways to add interesting features!
it was the first time for me using elem ~ elem and elem + elem selectors for example
Wish it had the answer as well, not just hint.
0. li:first-child
1. p:not(.foo)
2. li:nth-child(2n+3)
3. div > *
4. span[data-item]
5. p ~ span
6. form > *:enabled
7. #one, #two, #five, #six, #nine
8. a + span
9. #foo > .foo
10. div > div > span + code:not(.foo)
The use of `:not` is way more powerful that I usually remember. For example, the second exercise asks to select all the <p> except the one with class="foo"
<div>
<p></p>
<p class="foo"></p>
<p></p>
<p></p>
</div>
p:not(.foo)
:not(div, .foo)> Using two selectors at the same time is not yet supported in all browsers. Example: :not(.foo, .bar). For wider support you could use, :not(.foo):not(.bar)
It would have been nice to see what the intended solutions after because otherwise I have no way of finding out that using :enabled was the intended way and not input:not(disabled), button:not(disabled). Realized after I could have used an :is there but I don't use :is often in work due to browser support for IE so it didn't cross my mind at the time. It would also be nice to see that #one, #three, #five, #nine (or whatever the ID's where for that puzzle) was indeed the "intended" answer as a kind of trick question.
Without reading HN I would not have learned I was meant to use :enabled.
I too was using :not(:disabled) and learned :enabled only by reading the parent comment.
Thanks.
It would be good if there was a way I could have seen other users' answers, so I could learn new tricks.
p + p {
border-top: 1px;
}
I rarely use `~` though, but it has its uses.
I would extend its usefulness by rewarding shorter answers, as you could cheat a lot by using long nth-child selectors for everything which is basically unusable in actual stylesheets