Things I Learned Reading Webkit’s UA Stylesheet | Hacker News Reader

Things I Learned Reading Webkit’s UA Stylesheet

blog.jim-nielsen.com

63 pointsheadalgorithm26 comments

The if statements are just cpp, executed at compile time

> 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

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.

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.

Just surround anything prefixed with a "-" in quotes.

"-webkit-match-parent"

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 a Google feature that isn't very smart... adding a dash before a word will exclude results containing that word

I suspect it trips up people that don't know this more than it's actually used.

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

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!

> getting unfortunately common

I would say fortunately common. The sooner the C preprocessor (and C itself for that matter) can die, the better for everybody.

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.

Don’t remove it, improve it!

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...

XHTML was a neat idea, replaced by something much less elegant.

DHTML and ASP?

My main irritation with XHTML was that any tiny mistake in it rendered the document not visible at all.

Oh and how picky the <head> tag had to be specified.

It didn't help that this was all done back in the days when HTML pages were still often hand written.

Now days with HTML being largely framework generated, XHTML would be awesome!

Oh yeah, HTML had ergonomics that made it easier to use by humans and a lot harder to use by computers.

XHTML is basically the opposite.

As a former coder, I support that tradeoff. As a user... well, there's many reasons XHTML failed, and that's definitely one of 'em!

It mostly failed because browser vendors in general didn't care enough, and then Mozilla pushed HTML 5.

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).

> :is(article, aside, nav, section) ...

> 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.

> Many of these are so custom to the webkit codebase, you won’t even find any results for them in Google:

Of course if you search for -something, the result will be... nothing.

The mentioned property appears 5k times on Google Search: https://www.google.com/search?hl=en&q=%22%2Dwebkit%2Dmatch%2...

> 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.

Reply on news.ycombinator.com