[HN Gopher] Using: Has() as a CSS Parent Selector and much more
___________________________________________________________________
Using: Has() as a CSS Parent Selector and much more
Author : samwillis
Score : 185 points
Date : 2022-08-20 06:53 UTC (16 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| radiojasper wrote:
| I wish firefox `has()` this soon.
| marcosdumay wrote:
| It's already optional on the nightly. It's coming.
| lucideer wrote:
| Many commenters praising this here but parent selectors have been
| in discussion almost since the creation of CSS and the repeated
| conclusion has always been that they're a performance nightmare
| by definition.
|
| What's changed in that regard?
| eyelidlessness wrote:
| > What's changed in that regard?
|
| The CSS WG spent quite a lot of time and effort deliberating on
| a standard which wouldn't have a significant performance
| impact. They only support a subset of selectors as arguments,
| to minimize their complexity.
| pwdisswordfish9 wrote:
| My guess: nobody cares about performance any more.
| amichal wrote:
| True in the sense that you mean and alao in pure CS theory
| terms but also the TFA also links to some serious
| documentation on practical solutions to many real world
| performance problems and browser codebases have most of the
| underlying complexity for other less obvious performance
| issues. E.g. https://github.com/Igalia/explainers/blob/main/c
| ss/has/has-s...
| lucideer wrote:
| Thanks for the deeplink, I should spend some time digging
| in.
|
| Though as far a pre-existing complexity in modern engines
| goes: engine performance has regressed (in absolute end-
| user terms), and engine conplexity is also a barrier to
| entry for competing/new engines. So this isn't exactly
| "good".
| lucideer wrote:
| That's my sense, though if anyone still does it's been the
| WebKit team, so this does seem a little unusual at least.
| oblak wrote:
| About time, though I wonder what's the impact on performance. I
| realize these are not the jquery days where most people would
| write stupid selectors over and over again but nothing is free
| and I feel it's important have performance in mind even when it
| seems most of the web don't.
| jiggywiggy wrote:
| Yeah we lost the battle of performance, mac m1 chrome easily
| runs 2-4gb with few tabs open.
| rahkiin wrote:
| Did you try with Safari instead?
| Cyberdog wrote:
| As someone who primarily uses Safari on an 8GB Mac mini and
| 8GB MBA, I've found there's two things which reliably cause
| memory to spike.
|
| One is opening the developer tools. Have more than a couple
| tabs with the dev tools open and I can easily have Safari
| itself go over 8GB and I start to feel the thrashing when
| switching between apps and stuff. Closing dev tools for
| certain tabs when I no longer need them helps.
|
| Two, for whatever reason, is streaming YouTube videos - not
| playing pre-recorded ones but watching livestreams. I
| suspect the culprit is actually the chat box but I'm not
| sure. For now, if I want to watch a YouTube stream for more
| than a couple minutes, I'll usually pass it to Streamlink
| which allows me to watch the stream through VLC and bypass
| the web interface entirely - I don't participate in or care
| about the chats anyway.
|
| https://streamlink.github.io
|
| I even set up a Zsh function I can invoke with "sl" which
| automatically fires up Streamlink with whatever URL I
| currently have in my clipboard.
|
| https://github.com/GarrettAlbright/Dotfiles/blob/master/.zs
| h...
|
| Incidentally, if you open up Activity Monitor and go to the
| Memory tab, it'll show you how much memory each Safari tab
| is using... well, sort of. It uses the domain name of the
| site as the "Process Name," but that's not very useful if
| you have more than one tab open with a page from the same
| domain name. I really wish they'd put the full page title
| and/or URL in there and/or let you switch directly to the
| offending tab from Activity Monitor.
|
| All that being said... Naturally, Safari is the most well-
| integrated and performant macOS browser, and it puzzles me
| why even self-described Mac fans would use anything else
| for anything other than testing.
| FractalHQ wrote:
| I don't use Safari because it breaks more random stuff on
| websites than any other browser, has horrible support for
| WebGL, struggles to render gradient / animated SVG under
| many circumstances, has a terrible extension ecosystem,
| and has a lot of random bugs that annoy me. I also have 0
| performance problems with browsers because I have the
| luxury of owning many powerful machines, each with 64gb
| ram.
| julienreszka wrote:
| LOL this is so cool
|
| Check this out ```css
| figure:has(input[type="checkbox"]:checked) figcaption {
| /\* if a figure has a checkbox checked, apply this to
| its figcaption... \*/ font-size: 90%; font-style:
| italic; margin: 0.6rem 0 0.1rem; } ```
|
| https://codepen.io/julienreszka/pen/yLKZRRX
| bawolff wrote:
| The demo where you can have different themes for your site ws
| pretty cool. I wonder if this will put even more stuff currently
| in the realm of js into css.
| vnm wrote:
| I wish Safari developers would spend their valuable time on
| fixing the horror Safari is. It's literally the new Internet
| Explorer. If you work on building web apps with complex
| interactions, animations, etc, you get to hate Safari with all
| your heart in a very short amount of time.
|
| There are things they've done that are amazing, and which I
| respect (like JavaScriptCore), but overall Safari is the worst
| popular browser. I don't get how people can stand it, but again I
| don't get how people can stand iOS either.
| elevaet wrote:
| It's not _literally_ the new IE, but it is the new IE.
| wixyu wrote:
| Uhm this is exactly what :has is, fixing the 'horror'. This is
| such an outdated idea, the WebKit team have been killing it the
| past 12-18 months as evidenced by the efforts on interop 2022.
| https://wpt.fyi/interop-2022
| kitsunesoba wrote:
| A vanishingly small percentage of the web I make regular use of
| has any legitimate need for anything beyond what web browsers
| were capable of 4-6 years ago. In the odd case that I run into
| a site that's broken in Safari, I can usually find an
| alternative that works fine in a few seconds.
|
| What has the biggest impact on me as a user isn't the quantity
| of bells and whistles the browser's engine has, but how
| efficient it is because nobody likes battery vampire apps and
| how much the browser tilts the balance of control in favor of
| the user, because third parties on the web are best treated as
| adversarial until proven otherwise.
|
| Chrome provides a nice experience for devs, but its user
| experience continues to slip.
| tannhaeuser wrote:
| > Safari is [...] literally the new Internet Explorer.
|
| > _But do you ever see a "Best viewed with Safari" notice? No,
| you don't. Another browser takes that special place in web
| developers' hearts and minds._
|
| > _Chrome is the new IE, but in reverse._ [1]
|
| [1]: https://news.ycombinator.com/item?id=28156818
| dannyobrien wrote:
| I think it's noteworthy that feature was pursued and implemented
| by Igalia, an independent open source dev house whose HQ is in
| Spain, and is run as a co-operative. They've built up quite a
| powerhouse of core browser experts.
|
| https://www.igalia.com/about/values
| solardev wrote:
| I wish more places ran as employee-owned coops!
| julienreszka wrote:
| Why tho?
| solardev wrote:
| Why co-ops? Because the profit goes back to the people who
| work there instead of shareholders, and they get a say in
| their own management. It shares control of the company
| between those who work there. It's a much better
| environment to work in vs something like Activision or EA
| where you're just an abused cog in the machine.
|
| At least on paper. In reality, the smaller coops don't grow
| big enough and so can be resourced starved and kinda get
| stuck in a death spiral as people leave to pursue other
| alternatives while the remaining members hoard power and
| control for themselves and make new employees basically not
| full owners but minions, etc.
|
| There's no perfect system but I'd rather take the risks of
| equality than work under an oppressive hierarchy.
|
| Not everyone cares about that though. Some would rather
| earn the big bucks, be led by execs, and not have to worry
| about the rest of the business.
| julienreszka wrote:
| Thank you for your balanced opinion it's so rare on the
| internets
| TingPing wrote:
| Igalia shares equal ownership and all new employees are
| expected to become owners eventually. It's been growing
| faster too lately. WebKit Team is hiring :)
| beltsazar wrote:
| It's especially useful for blocking ads or unwanted elements of a
| website that has cryptic and ever-changing IDs and classes. With
| the :has() selector, you can now block an element by its
| structure, instead of IDs or classes. Some of my personal uBlock
| filters that might be useful for others: ! Hide
| question suggestions www.quora.com##div.qu-
| borderAll:has(div:has-text(/^Questions for you$/)) !
| Hide space suggestions www.quora.com##div.qu-
| borderAll:has(div:has-text(/^Discover New Spaces$/)) !
| Hide 1) left nav bar, 2) footer (clap, comment), 3) right side
| bar medium.com##div:has(> nav) medium.com##div:has(>
| div:has(> article)) ~ div:last-child medium.com##div:has(>
| div:has(> div:has(> div:has(>
| a[href^="https://help.medium.com"])))) ! Hide non-
| relevant seach results www.youtube.com##ytd-search ytd-
| shelf-renderer:has(h2:has-text(People also watched))
| www.youtube.com##ytd-search ytd-shelf-renderer:has(h2:has-
| text(For you)) www.youtube.com##ytd-search ytd-shelf-
| renderer:has(h2:has-text(Previously watched))
| www.youtube.com##ytd-search ytd-shelf-renderer:has(h2:has-
| text(Results for similar searches)) www.youtube.com##ytd-
| search ytd-shelf-renderer:has(h2:has-text(New for you))
| ! Hide unused buttons (useful for vertical monitors)
| www.youtube.com##ytd-toggle-button-renderer:has(yt-formatted-
| string:has-text(Dislike)) www.youtube.com##ytd-button-
| renderer:has(yt-formatted-string:has-text(Share))
| www.youtube.com##ytd-button-renderer:has(yt-formatted-string:has-
| text(Thanks)) www.youtube.com##ytd-button-renderer:has(yt-
| formatted-string:has-text(Clip))
| azeirah wrote:
| Is that :has-text psuedoselector a UBlock-specific feature? I
| can't find anything on it, I would love to have that in regular
| css
| js2 wrote:
| It looks like it:
|
| https://github.com/gorhill/uBlock/blob/72bb89495ba0928042b8c.
| ..
|
| https://github.com/gorhill/uBlock/blob/72bb89495ba0928042b8c.
| ..
| [deleted]
| ketzu wrote:
| I used ublock origin for removing recommendations and trending
| topics on sites like twitter, but it never occured to me how
| easy I can create them using has().
| eurasiantiger wrote:
| I still think this is a bad idea, because it leads to
| parent:child combinatorial explosion.
|
| Instead, try to avoid the need to define styles that way. Learn
| to rely on the cascade. Pick an authoring style for sizing,
| margins and paddings and stick to it. I tend to prefer h-margin
| and v-padding on containers and v-margins and h-padding on
| content.
| Wowfunhappy wrote:
| Possibly stupid question, is there a reason they went with
| parent:has(child)
|
| Instead of parent < child
|
| Which seems a bit more intuitive to me given that the inverse is
| a thing.
| henrikeh wrote:
| The article gives a few examples where a pseudo-class fits
| better with how CSS normally works. For example, the selector
| matches the last item in the selector. With '<' it would match
| 'parent' in your case.
|
| You can also match descendants of something with the :has()
| selector. It really is more than a "parent selector"
| silvestrov wrote:
| Example of this:
|
| div:has(b) a
|
| which matches a link inside a div that also contains bold
| text. The important part is that 'b' and 'a' can be very
| different places in the hierachy, they don't need to be same
| like like a 'b + a' selector.
| jruz wrote:
| Totally unnecessary feature that will do just harm to slow
| devices than to move the web forward. Lazy developers rejoice.
| uallo wrote:
| Can you elaborate or is this just an uninformed rant?
|
| The article that you are commenting on explicitly mentions the
| focus on performance while considering this feature. They even
| state to have been able to achieve "fantastic performance, even
| in the presence of large DOM trees and large numbers of :has()
| selectors".
| oblak wrote:
| With all due respect, it looks to me you're the one sharing
| an uninformed opinion. Have you seen any benchmarks, tried
| some? No? Your claims are based on what the authors say. That
| is not enough. Never has been.
|
| The idea is not new at all. People have been asking for
| something like this for many years. You know why it never
| happened? Because it would be slow. Maybe the webkit devs
| have found a really fast and clever way to do it. But
| shitting on people for voicing their well founded skepticism
| is not a good sign. Especially when all we have is their
| word.
| uallo wrote:
| I was neither sharing an opinion nor did I claim anything.
| I asked OP to elaborate and referred them to content of the
| article.
|
| > You know why it never happened?
|
| Yes, I do.
|
| > Especially when all we have is their word.
|
| Does that mean you don't trust their word? Good. Would you
| trust their own benchmark? No? The parent selector has been
| in Safari 15.4 since March, 2022. So feel free to do your
| own benchmark. There is not _just_ their word.
|
| You might also find the lengthy explainer of Igalia, where
| performance is discussed, interesting:
| https://github.com/Igalia/explainers/tree/main/css/has
|
| Being skeptic is not a bad thing. But (uninformed)
| criticism without any specifics is far from "well founded
| skepticism". JavaScript interpreters used to be very slow
| twenty years ago, now they are extremely fast. That can
| happen to CSS evaluation, too.
| oblak wrote:
| March 2022 you say? Great. Are there any benchmarks?
| Nothing fancy, just some 3rd party comparisons to other
| selectors or combinations. Because that would be
| preferable to buying myself a safari capable device just
| to prove point that I wasn't making in the first place
| uallo wrote:
| I'm not aware of any benchmarks. Neither am I aware of
| any performance deterioration in Safari 15.4+.
|
| What _is_ your point exactly? That performance should be
| one of the most important aspects in browser engine
| development? I agree. Hence, I asked OP to elaborate
| their claim that this selector harms slow devices. And I
| 'm not interested in the (outdated?) historical concerns
| of a parent selector. But the actual effect of the
| specific selector implementation in WebKit which this
| discussion is about.
| eurasiantiger wrote:
| Those words are meaningless without the actual benchmark
| data.
| samwillis wrote:
| I think :has() is probably the most anticipated addition to CSS
| 25 years (although rounded corners is probably also up there).
| I'm really looking forward to being able to use it. However it's
| almost a shame it took so long, I'm not sure how it will fit in
| with utility class frameworks that are so in vogue. It's much
| more closely aligned with the traditional separation of concerns.
|
| Also very happy to see Apple and the Safari team push web
| standards forward!
| gkilmain wrote:
| Rounded corners really were all the rage for a while and we
| needed support for it! I remember in the early days cobbling
| together elements with top-left, top-right, etc image slices.
| Want't really too long ago.. maybe 10 years?
| omneity wrote:
| Maybe try 20ish years? Those are the days of php-nuke and
| what you described was a common technique for building themes
| back then.
| czx4f4bd wrote:
| MDN says border-radius was added to Chrome in 2010 and
| Firefox in 2011, and Chrome added the prefixed version in
| 2008. https://developer.mozilla.org/en-
| US/docs/Web/CSS/border-radi...
| omneity wrote:
| I am referring to the image slicing technique and
| rendering fancy buttons and sidebar "blocks" using tables
| in the likes of PHP-Nuke and other content management
| systems of the time.
|
| > I remember in the early days cobbling together elements
| with top-left, top-right, etc image slices. Want't really
| too long ago.. maybe 10 years?
|
| To me this is core ajax and php era, so ~2002-2006 which
| would be about 18 years ago.
|
| By the time CSS standards for rounding corners arrived a
| lot of pain has been inflicted on us developers, but by
| now it feels as if this era never existed (same with
| pre/post flex to take another CSS milestone)
| samwillis wrote:
| Safari and WebKit had it from 2008 but prefixed. Chrome,
| back then based on WebKit pre forking it, will have had
| prefixed support from launch.
|
| Firefox had it from 2006, prefixed.
|
| IE was the holdout, not having it until v9 in 2011.
|
| https://caniuse.com/border-radius
| achairapart wrote:
| Yes, border-radius was available since ~2007/2008 except
| for IE (I remember using some hack involving HTC files,
| maybe CSS3PIE[0]).
|
| [0]: http://css3pie.com/
| samwillis wrote:
| I remember in the late 90s building content boxes with 3x3
| tables, outer cells containing image slices for the border,
| drop shadow and rounded corners. Macromedia Fireworks had
| brilliant tools for both creating these sort of graphics, but
| also slicing them up for use in tables. I still miss
| Fireworks, Adobe killed it though as they perceived that it
| competed with Photoshop when it really didn't. It's the
| spiritual precursor to all ui/ux design tools like Figma and
| Sketch.
| lelandfe wrote:
| Some classic webmaster nostalgia:
|
| Sliding door technique:
| https://alistapart.com/article/slidingdoors/
|
| Bulletproof buttons: https://www.456bereastreet.com/archive
| /200705/creating_bulle...
| gernb wrote:
| It's already in Chrome Beta meaning "has" will be shipping in
| Chrome within 1-4 weeks. It's not like Safari are leading with
| this feature and others are catching up.
|
| Leading is when you implement something and no one else as
| started. Example, Firefox and Chrome shipped WebGL2 and Safari
| did nothing for 4 years.
|
| When multiple browsers are implementing the same standard at
| the same time and one ships a couple of weeks earlier that's
| not leading. Leading implies followers. Maybe in this case
| Firefox will follow both Chrome and Safari since Firefox has
| (no "has" support in Firefox Nightly)
| alwillis wrote:
| _It 's not like Safari are leading with this feature and
| others are catching up._
|
| With this particular feature, that's exactly what's
| happening. It's not the first time Apple shipped a new web
| platform feature before Google and Mozilla; it's the fact
| that it's been the most highly anticipated CSS feature in the
| recent history of the web platform.
|
| _Leading implies followers._
|
| Apple shipped :has() December 2021 in Safari Technology
| Preview 137; it's been shipping in production since March 14,
| 2022 with Safari 15.4. That's a big gap in web time before
| Chrome ships in production.
| samwillis wrote:
| I didn't use the word "leading" or imply they were...
|
| I'm happy that Safari, who have been at times been criticised
| for not keeping up, are on this occasion helping to push web
| standards forward. That has nothing to do with who was
| "first", but in this case they happen to have been. If they
| were two weeks behind I would have made the same comment on a
| thread about a blog post on their own blog.
| bobwaycott wrote:
| > _It 's not like Safari are leading with this feature and
| others are catching up._
|
| You seem to be reacting with some anti-WebKit bias here,
| didn't read the article about the history of this feature, or
| are taking a very odd view of "leading" to avoid giving
| credit to the WebKit team.
|
| The article gives the history, and links you to it:
|
| - eyeo approached Igalia to sponsor work on has:() in early
| 2021 (Igalia blogged about it May 2021, after having been
| working on it for a little while)
|
| - Igalia worked on early prototypes to collect data and write
| tests to drive the conversation around :has() forward
|
| - the WebKit team at Apple picked it up and started doing the
| hard work of a real and powerful implementation
|
| - they shipped :has() in Safari Technology Preview 137 in
| December 2021
|
| - they shipped :has() in Safari 15.4 on March 14, 2022
|
| - Igalia did the engineering work to implement :has() in
| Chromium, which will ship in Chrome 105 on August 30, 2022
|
| - the Chrome issue for :has(), which was created in May,
| you'll see it openly references using WebKit's work and
| approach
|
| - other browsers built on Chromium won't be far behind
|
| - Mozilla is currently working on the Firefox implementation
|
| > _It 's not like Safari are leading with this feature and
| others are catching up. Leading is when you implement
| something and no one else as started._
|
| I think, given the timeline and everyone who is actively
| involved referencing WebKit with the real-world proven and
| shipped implementation, it's _exactly like that_.
|
| > _When multiple browsers are implementing the same standard
| at the same time and one ships a couple of weeks earlier that
| 's not leading. Leading implies followers._
|
| This isn't a couple-week lag. WebKit has (and continues to)
| lag in areas--but :has() isn't one of them, as WebKit is
| literally the reference implementation here, was in Tech
| Preview _8 months ago_ , and has been released in Safari for
| _5 months_. I think it's fair and accurate to acknowledge
| that WebKit :has(followers).
| capitainenemo wrote:
| Well, it's there in firefox, it's just off by default, just
| like it was in chrome until this release.. about:config
|
| layout.css.has-selector.enabled
|
| The off by default is presumably due to fact that spec was
| not exactly settled yet, at least judging by discussion here:
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=418039#c44
| clairity wrote:
| thanks! i was just last week looking for what the config
| might be to turn this on for firefox and didn't find it
| (didn't try very hard tho).
|
| i tried using firefox's experimental :has() on my personal
| css framework that's using all the latest features css
| features like :has(). on first glance, it looks like there
| are some bugs with firefox, but i'm excited that they're
| working on it. the simple parent selector case seems to
| work, but complex layout seems to confuse the layout
| engine.
|
| :has() is easily my most anticipated css feature since grid
| at least (wish safari would support subgrid!).
| Tistron wrote:
| The most surprising thing for me is that Safari is first with
| this.
|
| Am I in a HN bubble where everyone are always complaining about
| safari, or is that genuinely unusual?
| akira2501 wrote:
| They're behind on features _and_ you have to work around their
| aggressive privacy choices. It's my least favorite testing
| phase in any release.
| matheusmoreira wrote:
| > you have to work around their aggressive privacy choices
|
| There are work arounds? Looks like they need to be even more
| aggressive.
| akira2501 wrote:
| I remember a time when this site didn't take the most
| uncharitable reading of everything all the time.
|
| And yes. Making a streaming application. The CDN that the
| media is provided through uses cookies to coordinate "side
| band" metadata. On Safari, there's no way to get at the
| metadata due to the cookie policy. So, you get the media,
| but literally no metadata or features associated with it.
| It's a worse experience for any Safari user and doesn't
| actually enhance their privacy in any way whatsoever.
|
| The workaround was to get the streaming provider to allow
| the correlation ID that would normally be conveyed through
| a cookie to be conveyed through URL parameters instead.
|
| So.. to the extent that I could track you between two
| sessions, the workaround means I still can. Not that I need
| to track you, but because I need to correlate two streams
| between two different servers onto one device.
| akie wrote:
| I love their aggressive privacy choices.
| drawfloat wrote:
| I love them to an extent. There should be some sort of
| request API available for temporarily disabling the more
| stringent media restrictions for a session.
|
| I worked on a media heavy fashion site a few years ago and
| dealing with Safari not allowing you to dynamically add new
| audio/video elements with auto play (or to auto play at all
| in low battery mode) was a real headache. By default it's
| great, just offer the option to get permission for
| experiences that require it.
| matheusmoreira wrote:
| Auto playing media is not something that should ever be
| allowed anyway. Apple forcing sites to respect their
| users is actually a great reason to buy Apple products.
| solardev wrote:
| It seems so fake... Apple adds "privacy" by crippling their
| competitors, then turns around and adds a bunch of their
| own intrusive advertising. They don't care about you, they
| just want to be the next Google
| tambourine_man wrote:
| It's not. Safari is just not always blindly adopting whatever
| Chrome does and their priorities are very different.
|
| Safari has consistently been the fastest, more battery and
| privacy concerned browser.
|
| Safari is WebKit, which historically has given us a lot of the
| CSS standard niceties we take for granted.
| 6510 wrote:
| webp and lazy loading are so powerful that having to do
| things without it really feels like IE. The big difference is
| that IE users for some reason failed to install something
| better. Safari users are locked in.
| tambourine_man wrote:
| Safari supports lazy image loading, which is probably what
| you want. Just not iFrame lazyloading, which you shouldn't
| be using all that much anyway.
|
| It also supports webp, even though I never use it. It's a
| Google thing, not widely supported by image editors and
| which fails to be consistently better than a properly
| optimized jpeg.
|
| If you thing you need webp try running it through MozJPEG
| first
| solardev wrote:
| Side note: Webp isn't terribly useful for replacing JPEG,
| but it IS a very good alternative to PNGs with
| transparencies (alpha channels).
| tambourine_man wrote:
| Again, have you seen crushPNG and similar tools?
|
| To me, a format must offer significant advantages to
| overtake decades old standards.
| Cyberdog wrote:
| MozJPEG is truly magical. My image editor of choice Acorn
| added it and I've been using it heavily ever since when I
| want to share a screenshot of reasonable fidelity but
| would rather it not be 3.8MB.
|
| https://flyingmeat.com/acorn/
|
| I would like to see a decent true successor to JPEG which
| does stuff like alpha channels, but the annoying extend-
| embrace-extinguish approach Google used with WebP has
| turned me off of considering it very seriously.
| no_way wrote:
| They are first but it's not like other browsers are far behind,
| Chrome is already shipping :has, being first for one feature
| doesn't mean much while you are years behind implementing non
| controversial features already in other browsers, not even
| talking about Safari bugs..
| MatthiasPortzel wrote:
| Because Chrome has such a dominant market share, Safari doesn't
| get credit when they implement features first. No one's going
| to use or even hear about a Safari-only feature because the
| people who are making the websites are using Chrome.
|
| On the other hand, if Safari doesn't support a feature Chrome
| supports, then that's a problem for Safari because developers
| are going to be using that feature.
|
| There's this sort of naive attitude that "all browsers should
| just implement all the specifications." But in reality all
| browsers take a fair amount of leeway with what specifications
| they implement, what timeline they implement them in, and etc.
| There are plenty of fundamental differences between engines
| that effect browser compatibility, that haven't been addressed
| for years.
|
| "Safari is behind Chrome" is just way too linear of a
| narrative. Web compatibility is a patchwork of over a thousand
| specifications.
| solardev wrote:
| Why can't Safari just use Blink? What's the value of having
| more than one engine?
| wixyu wrote:
| See the moribund state of web development from
| approximately 2003 - 2013 when the web was bound to a
| monoculture of Internet Explorer. Current the Blink team
| are running behind both WebKit and Mozilla in meeting the
| agreed upon goals for interop 2022.
| https://wpt.fyi/interop-2022
| solardev wrote:
| > See the moribund state of web development from
| approximately 2003 - 2013 when the web was bound to a
| monoculture of Internet Explorer.
|
| I think that's a bit of an exaggeration/retconning.
| Between NetCaptor, Maxthon, etc., that's the era that
| gave us huge innovations: tabbed browsing, popup
| blockers, ad blocking, site groups, search in the URL
| bar, and so much more. And CSS, and GeoCities, and
| streaming video and animated applets/games/Flash...
|
| There was so much innovation going on, the real
| difficulty was in being able to display your content to
| your audiences. CanIUse wasn't around then and there were
| huge incompatibilities between IE, Netscape, Opera,
| eventually Phoenix, etc.
|
| It wasn't the diversity in engines that allowed
| innovation, it was the market exploring different
| features and eventually converging on the ones that
| people really wanted. If anything, having redundant
| engines slowed down actual development. IE6 was king for
| a few short years, and in those few years the web was
| more stable than it ever was before or since, and content
| was king instead of engine differences.
|
| For now Chrome has the best of both worlds: market
| dominance and rapid innovation. They have no meaningful
| challengers anymore... Firefox/Gecko is dead and WebKit
| is only a thing because of iOS, and thankfully it at
| least shares a heritage with Blink.
|
| I think your link proves the opposite point: that the web
| ecosystem is wasting time on interop instead of actual
| features. We don't need three renderers that do roughly
| the same thing, but nothing exactly the same. It was
| Chrome's hegemony over the last 5-10 years that actually
| gave us huge leaps in web usability, dev specialization,
| best practices, and content creation. The real
| changemaker was making Javascript safe and fast enough
| that native in-browser programming became a reality.
|
| There is no such thing as web standards in reality, only
| Blink and WebKit's mostly-compatible implementations. If
| we could move past that delusion and just converge
| resources on Blink/V8 and just evolve that, the web would
| be better off for it.
| malepoon wrote:
| Remember (P)NaCl? Or WebSQL? Google has a bad reputation
| for pushing poorly designed web "standards".
|
| Thanks to Mozilla we then got asm.js, wich evolved into
| Wasm and ultimately replaced NaCl.
|
| Now imagine there was one engine and Google could
| implement whatever they wanted? RIP privacy and well-
| designed standards.
| solardev wrote:
| Why can't similar debates happen around a single engine?
|
| Mozilla is largely Google funded anyhow. If they wanted
| to drop funding and go their own way they could do so
| anytime.
| kitsunesoba wrote:
| Google has far too much power over the direction of Blink
| for any meaningful debate to take place. They have a
| tendency to steamroll through already and this behavior
| would no doubt intensify if Blink were the only game in
| town.
|
| It would have a far better chance of working if the
| Chrome/Blink team were spun out of Google into a
| nonprofit that is protected from the financial influence
| of Google.
| nwienert wrote:
| Wow, hard to disagree with a post more.
|
| Chrome has been doing some terribly shady stuff with
| Blink whether we look at their various tracking
| proposals, "portals" which are a blatant attempt at
| ossifying Google as basically the internet itself, or the
| extreme standard-stuffing they continue to participate in
| to ensure no further competitors can pop up.
|
| But beyond that nearly every point you raise here is
| completely off.
|
| WebKit is superior to Blink, in almost all ways. It's
| simply a much better browser and has been for a couple
| years now. Faster, lighter, and supports nearly
| everything you need. Every time I'm forced use Chrome,
| it's like having to walk through a shady neighborhood - I
| literally can't wait to close it. That thing sucks memory
| and battery in a way no app should, and Googles numerous
| shady tactics in trying to get you to login so they can
| avoid your privacy settings is downright hostile.
|
| Leaps in best practices? Is that a joke? Web Components
| pushed by them is one of the worst things to happen to
| the web. Half of the standards they've pushed are
| actually regressions.
|
| And again, Chrome is much slower and more bloated. If
| anything Safari is far better today for delivering a more
| native experience.
|
| And your last paragraph is very much the kicker. The
| funny thing is the Safari thing is the only thing keeping
| Chrome in check. If this is what they've tried to get
| away with with Safari, I don't understand how you can be
| advocating for even less competition. Interop is an
| incredible project that will save developers massive
| amounts of time, while ensuring we don't end up with the
| most privacy invasive and manipulative company of all
| time controlling the web for the next 1000 years. Thank
| god for Safari.
| dragonwriter wrote:
| > Why can't Safari just use Blink?
|
| Given the history of those two, that's amusing.
| masswerk wrote:
| Historically, the question is to be asked the other way
| round. (So why Blink?)
| ayushnix wrote:
| > What's the value of having more than one engine?
|
| I, for one, wouldn't like using the web with a web browser
| built by an advertising company pushing for Manifest V3 and
| killing adblockers as a result.
| Cyberdog wrote:
| Why can't computers just use Windows? What's the value of
| having more than one operating system?
| swatcoder wrote:
| The browser is _the_ pipe between enterprises and users on
| the web.
|
| You might want an advertising company to have unilateral
| control over the shape of that pipe, but some of us feel
| more comfortable knowing there's a viable alternative with
| competing priorities.
| iaml wrote:
| Safari team is really strange with their priorities, most of
| the time they are dead set on implementing specs last, but
| every once in a while they decide a feature is important and
| they implement it faster than everyone else. For example,
| backdrop-filter was supported in safari way back in 2015, while
| other browsers added it multiple years later.
| easrng wrote:
| Safari is also ahead on color space support.
| samwillis wrote:
| I suspect it is the influence internally from other product
| teams. WebKit is used in so many places within MacOS and iOS,
| someone recently wrote a blog post looking at the CSS used by
| Apple, :has() and some other WebKit only css was heavily
| used.
| zarzavat wrote:
| This is how we got <canvas>. Apple needed it for the MacOS.
| Dashboard feature.
| have_faith wrote:
| You're not wrong, Safari is often behind on features. Unless
| Apple deem that feature important of course.
| have_faith wrote:
| It looks extremely useful. It's slightly different to what I
| imagined a parent selector to be many years ago. When I think of
| "parent selector" I imagine putting the logic with the sibling
| and not the parent e.g. "if I'm in a hover state make my parent
| green, regardless of who/what the parent is". It's a small
| difference that in reality can be achieved with :has and
| collocating logic higher up but it's an interesting difference.
| uallo wrote:
| :has() can be described as "elements whose children match some
| selectors". Your expectation would have been (if I understand
| it correctly) "match elements with some selectors and get their
| (direct?) parent". Aside from reversing the logic, it seems to
| me that it is the exact same thing, isn't it? The selector
| could have been called "children pseudo-class selector" or
| similar, though.
|
| Personally, I prefer the actual syntax over your expecation.
| The first thing in the selector are actual elements that will
| be styled if certain conditions are met. That also matches how
| the existing pseudo-classes have been applied.
|
| > "if I'm in a hover state make my parent green, regardless of
| who/what the parent is" *:has(> *:hover)
| samwillis wrote:
| I think what they are suggesting, to invent some syntax, is
| this:
|
| :hover:parent()
|
| So it's a post fix to go back up the tree.
|
| I prefer the flexibility of :has().
| 0x69420 wrote:
| stuff like this really brings us closer to the dream we all had
| back when we served largely-static content with some scripts
| thrown in -- of being able to say what we meant in the css and
| keeping the markup ~semantic~
|
| now that we throw our hands in the air, say "fuck it", and
| first&foremost serve "apps", single-page or not, styled with
| utility class systems like tailwind, it feels a lot less
| meaningful to the average poor sap hired to make web frontends
| Cyberdog wrote:
| Oh hell yes. Remember "progressive enhancement?"
|
| It feels like the last ten years of web dev has been the entire
| industry giving up on the idea that web pages are supposed to
| be _pages._
| jeroenhd wrote:
| I love having access to the has() selector as a user for custom
| CSS on shitty websites. Ad blocker cleaning rules can get a lot
| better with this selector.
|
| However, for actual CSS, I don't think this is a good idea. You
| shouldn't need the has() selector if you write your own CSS and
| HTML.
| yohannparis wrote:
| I disagree, so many times I had to do what the examples show on
| the article: having component displaying slightly differently
| based on content. Could be a simple as margins/padding, etc.,
| or even colour based on the designer's choices.
|
| So now, instead of adding class to an element to choose how to
| display those differences of content, I can just use :has()
| selector. Thus removing even more design concerns from the HTML
| back into the CSS where it belongs.
| frosted-flakes wrote:
| Another one is div:has(:focus-visible)
|
| for showing the focus state on a parent element. This is
| otherwise impossible without using JavaScript.
| woutr_be wrote:
| Why not? The figure example seems like a perfectly valid use-
| case. How else would you do something like that?
|
| Edit; I actually had a use case were I was building an
| expanding menu, without JavaScript, it involved a ~ and >
| selector on a checkbox to get that to work. The :has selector
| would've made it straight forward.
| jeroenhd wrote:
| When you use "has()" you can be pretty sure that you also
| have the context to just use a class name. Using CSS to
| traverse a tree of elements rather than structure the
| elements in a way to make your CSS makes sense just feels
| like backwards design to me. Your CSS should describe how the
| HTML looks, it shouldn't be trying to figure out what you did
| to the poor DOM tree to find the right style to apply.
| samwillis wrote:
| I think the article shows brilliant examples of where that
| isn't really possible, and uses where it replaces
| JavaScript. It also stops you needing to repeat yourself,
| the figure example for example with your suggestion would
| need both a class and a caption tag.
|
| Also going back to the roots of CSS, :has() is ideal for
| semantic markup where you don't want or need to use
| excessive class names. Obviously with class heavy
| frameworks and methodologies that are in vogue :has() is
| less relevant.
|
| There is more than one way to use CSS.
|
| > Your CSS should describe how the HTML looks
|
| That's literally what :has() does, based on the structure
| of the document.
| woutr_be wrote:
| Maybe i'm either misinterpreting you, or misunderstanding
| the article, but figure:has(figurecaption) perfectly
| describes a valid DOM tree, it's not trying to do anything
| weird. I'm sure it can be abuses, just like anything else.
| Cyberdog wrote:
| You have a point, but there _are_ cases where designers are
| doing something like styling CMS output and either don 't
| have the skills or the possibility of doing something like
| adding classes conditionally to its output. Or perhaps
| asking a developer something like "Hey, can you add a class
| to X whenever it contains Y?" involves filing a ticket and
| waiting patiently for stakeholders to decide if and when
| it's necessary enough to devote developer resources to.
|
| And at any rate, removing classes and IDs as much as
| possible and just having a page full of semantic tags is
| generally a goal for a certain school of web development.
| jacobp100 wrote:
| It's got some really good niche features - like
| `:has(:invalid)`. The new selector is is the best way to
| achieve that
|
| But yea you're right that it's not going to be really common
| VPenkov wrote:
| Very exciting. I wonder if :focus-within is on its way out as a
| result of this. Granted, it would have a lower specificity than,
| say, .bordered:has(input:focus).
| fomine3 wrote:
| Praise for Igalia!
___________________________________________________________________
(page generated 2022-08-20 23:02 UTC)