Live data from Hacker News

CSS Selectors: A Visual Guide

fffuel.co

41–50 of 59 posts

Re: CSS Selectors: A Visual Guide

#41
Very nice, but some of the examples could do with more elements to indicate what is _not_ selected. For example, the "child selector" image could have some more "div"s which are descendants but not direct children of the ".wrapper" element.

Re: CSS Selectors: A Visual Guide

#44
post #31

Earlier quoted context omitted.

There are no clean designs on a large team. Anyone who tells you otherwise is selling something. Zealots provide solutions that cannot possibly survive contact with actual humans. The rest of the team talks about them behind their backs. > I've seen things like React embedding the CSS directly in with the markup and component logic etc. You were talking about bad designs? Embedded styling is not Cascading Style Sheet…

> Embedded styling is not Cascading Style Sheets I think that's needless pedantry; the contents of the `style` attribute still needs to be valid CSS.

It’s not needless pedantry. Calling it CSS is using a crescent wrench as a hammer and calling it a hammer (a running joke on r/tools). You’ve missed the entire point and someone needs to remind you - and everyone listening in - what the point was.

We had in-line style before we had CSS. We are going back and nobody remembers why we’ve had CSS for twenty years? Read some history.

Re: CSS Selectors: A Visual Guide

#45
post #44

Earlier quoted context omitted.

> Embedded styling is not Cascading Style Sheets I think that's needless pedantry; the contents of the `style` attribute still needs to be valid CSS.

It’s not needless pedantry. Calling it CSS is using a crescent wrench as a hammer and calling it a hammer (a running joke on r/tools). You’ve missed the entire point and someone needs to remind you - and everyone listening in - what the point was. We had in-line style before we had CSS. We are going back and nobody remembers why we’ve had CSS for twenty years? Read some history.

We're not in 2003, though. If you're working on a project with somebody and you insist they refrain from calling the contents of a style attribute CSS because it wasn't always technically CSS, nobody will thank you.

Edit: actually, even when I was working with CSS in 2003 (IIRC, we absolutely were using separate CSS files then), this attitude would have been unhelpful, to say the least.

Re: CSS Selectors: A Visual Guide

#46
post #29
post #27

Now, create a similar page for XPath...

does anyone still use XPath nowdays?

XPath and XSLT are still active, especially in the publishing space where documents are not stored in HTML, but in other formats like JATS or DocBook and need converting to HTML when displaying to the user, or converting to other XML formats when interfacing with other formats/vendors like crossref. It's also still used for things like processing the US bill XML data (e.g. https://www.govinfo.gov/bulkdata/BILLS/resources).

Re: CSS Selectors: A Visual Guide

#47
post #29

Earlier quoted context omitted.

does anyone still use XPath nowdays?

Does anyone still use XML? I would imagine the answer to both is yes. I often wish JSON had something as good as xpath.

The `jq` command line tool has some neat expressions for selecting things from JSON. Not sure if it's a standard though.

Re: CSS Selectors: A Visual Guide

#49

`* + *` works, but I think `:not(:first-child)` is a much clearer way of doing this. (Unless you need to support IE8 for some horrific reason?)

I assume the author is alluding to a certain blog post. https://alistapart.com/article/axiomatic-css-and-lobotomized... To the point, the :not(:first-child) option should similarly be able to minimize the total number of rules.

`:not(:first-child)` has specificity 0.1.0 that is some orders higher than 0.0.0 of `* + *` (since `:first-child` is a pseudoclass), so you'd have to adjust anything that you'd need to override it with.

Strict equivalent of

    * + *
would be

   :where(:not(:first-child))
Post reply on HN