Anything starting '-' won't show up on Google, it will literally give you empty results, so that's why -webkit-match-parent gives nothing and webkit-match-parent works.
Ya beat me to it. There's all kinda good little search tricks like that besides just the quotes, too. Really effective search engine research skills are almost an art-form these days. ;)
this reminds me of https://nautil.us/blog/impossibly-hungry-judges: google has the majority of github repos indexed (although isn't always great at giving you the best result), and webkit is a pretty popular software. unless this parameter was added to the codebase literally minutes ago, google should have at least some results. the fact that absolutely no results show up means that something is either wrong with google, or more likely, your query.
It's not that the "-" prefix is just a harmless undocumented feature that only (a few) people who know about it use, it's more that it's an insidious undocumented foot gun that shoots (most) people who don't know about it when they use it accidentally.
Google should at least show a user friendly help message at the top of the page, that actually teaches users about the filtering feature, and lets you turn it off, like:
Results containing "webkit-match-parent" omitted because of "-" prefix. (Click to include.)
But that would reduce the ad surface area by a tiny amount, so oh well...
They'd probably solve most of their problems by simply recognizing that a single term with a - isn't an exclusion, because it returns no results. That's like... a 10 minute regex fix
Specifically, prefixing a term with a "-" excludes results with that term, though I would expect for it to be ignored if it's the only term in the query.
Developers going without knowing what preprocessors do is… getting unfortunately common. Back in the olden days some people were using the C preprocessor on JavaScript. Being bilingual helps in programming too, everyone!
Compiler macros are not unique to C, and are even in “modern” languages like Swift and NIM. They solve specific problems usefully that often have no other good solution.
Sure, but macros in other languages are hygienic rather than copy-paste systems, and are therefore much safer (and easier to use for complex use cases, although the C preprocessor might be easier for really simple cases).
I'm guessing, but if I had to bet, @namespace is almost certainly a holdover from those bad ol' pre-HTML5 days when the W3C was still pushing XHTML.
I'll be honest, I miss the consistency and regularity of XHTML. And being able to hook into the XML ecosystem is really attractive. But, at this point, it seems likely to remain in the dustbin of technology history...
I could actually totally see that @namespace thing bein' useful if you're embedding SVG directly into your HTML (which is entirely possible, and even useful sometimes).
> The :is selector is pretty damn cool. Given the combinatorial nature of these groupings, writing something like this in CSS before :is would’ve been insane:
> /* keep going _forever_ */
In this case, there would have been 4^5 = 1024 selectors. Large enough to be annoying to a human, but small enough to be parsed and stored in memory.
> I don’t think it will surprise you to learn that handling legacy browser quirks is a common theme in the UA stylesheet.
That's the last place I'd expect legacy hacks. The UA stylesheet runs in the exact browser and version it was designed for, why does it need legacy support?
Or am I misunderstanding the paragraph and it's really about emulating legacy browser behavior?
It’s not legacy behaviour for Safari, it’s legacy behaviour for the web. Browsers support all sorts of issues created by old browsers and loose html specs - see the comment about the special value to centre text like Netscape 4 did.
That's why I added the question saying "Or am I misunderstanding the paragraph and it's really about emulating legacy browser behavior?"
Still feels to me like that would be the last place to require apple-specific properties or variables, since if it emulates old browsers it should not ever change, right?
They use Apple-specific properties because these are non-spec behaviours that nobody should be using. Since there’s no official way of invoking these legacy behaviours they’re placed behind vendor properties. Firefox does the same thing.
> Many of these are so custom to the webkit codebase, you won’t even find any results for them in Google
It's on Google, you just searched incorrectly