[HN Gopher] Things I Learned Reading Webkit's UA Stylesheet
___________________________________________________________________
Things I Learned Reading Webkit's UA Stylesheet
Author : headalgorithm
Score : 56 points
Date : 2021-07-19 15:26 UTC (7 hours ago)
(HTM) web link (blog.jim-nielsen.com)
(TXT) w3m dump (blog.jim-nielsen.com)
| [deleted]
| [deleted]
| nayuki wrote:
| > :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.
| SahAssar wrote:
| > 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?
| sitharus wrote:
| 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.
| SahAssar wrote:
| 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?
| CarelessExpert wrote:
| 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...
| com2kid wrote:
| 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!
| CarelessExpert wrote:
| 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!
| toxik wrote:
| XHTML was a neat idea, replaced by something much less elegant.
| sigg3 wrote:
| DHTML and ASP?
| blooalien wrote:
| 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).
| awestroke wrote:
| 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
| arthur2e5 wrote:
| 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!
| nicoburns wrote:
| > 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.
| azinman2 wrote:
| 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!
| nicoburns wrote:
| 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).
| lights0123 wrote:
| 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.
| no_way wrote:
| 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.
| Hello71 wrote:
| 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.
| EMM_386 wrote:
| Just surround anything prefixed with a "-" in quotes.
|
| "-webkit-match-parent"
| blooalien wrote:
| 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. ;)
| [deleted]
| [deleted]
| denysvitali wrote:
| > 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...
___________________________________________________________________
(page generated 2021-07-19 23:01 UTC)