6 ms·

Safari already has :has(), Chrome and Firefox do not. :has() is actually useful, Chrome pushes features that are largely a waste.

rektide 4y ago
From https://chromestatus.com/feature/5794378545102848 https://chromestatus.com/feature/5794378545102848 : > Unlike other selectors, :has pseudo class gives a way to apply a style rule to preceding elements (preceding siblings / ancestors / preceding siblings of ancestors) of a certain elements. > This difference is attractive to web developers, but also it generates lots of concerns mainly about performance and complexity. So there have been discussion about these over the years, but it was difficult to get those discussion moving forward. > It is true that it can generate performance issues and complex cases. But it is also true that there have been clear demands for the usage. > We thought that, clarifying those concerns would be helpful for the discussion. So we started to check feasibility on blink, and were able to get some meaningful and reasonable results from this step. Based on the results, we are going to move forward by prototyping. Right now the estimate is that they can ship in Chrome 105, but this still in advance. I often hear Safari-defenders say their browser is faster, that Chrome is bloated, and I think this is a great case demonstrating an opposite direction, showing a Chrome that is very focused on making sure the web stays healthy & doesn't have pitfalls & doesn't accidentally get slow. But Chrome is willing to play ball, has acknowledged the lack of this feature hurts, and has come around & tried to meet developer desire, rather than stay fast, & has followed what Safari has pushed for. Roberto, I had a really frustrating & negative time dealing with your pro-Safari anti-Chrome skepticisms[1] yesterday, which I felt were aimed primarily at snubbing & shorting. I hope if we engage again this time we can have a more earnest & forthright discourse. [1] https://news.ycombinator.com/item?id=31647980 https://news.ycombinator.com/item?id=31647980
- robertoandred 4y ago
  Has Safari pushed for it? Or is it simply that Google is slow to adopt the spec? If Safari is faster with features than Chrome is without, maybe it’s Chrome that’s the problem, and we shouldn’t let it hold back the web.
  - rektide 4y ago
    It comes from Safari. No one else advocated for it. Firefox hasn't registered a position on it, has nothing underway. > Google is slow > Safari is faster with features > maybe it’s Chrome that’s the problem? Again you seem to be slanting everything very highly. And using endlessless questions? This is really some dogshit disingenuous debating, that looks like the dissembling crap you pulled yesterday. Please sir, man up & quit this crap.
    - robertoandred 4y ago
      What makes you think Apple created it? It’s been in the draft spec for four years. Google’s been working on it for a year at least. But Apple did get it first and now we’re waiting on Google.
      - rektide 4y ago
        Let's just dive in to what the real status: According to still-current PRs[1], :has() psuedo-selector is optional and at risk. The working group then noted "no one has figured out how to do it in a performant way," and there's still no clear evidence this capability will indeed be safe & free of pitfalls in any browser (and plenty of counter-evidence against). But Safari is implementing (risking performance pitfalls), & Chrome has decided that the risk of killing performance is an acceptable trade-off for the feature. They began some very early prototyping a year ago, to explore[2]. > It’s been in the draft spec for four years. First, that's a draft spec. Not published. Safari typically doesn't even start implementing until features are published, so this is all pretty different than where we normally are. Second, it's been in draft for >8 years[3]. It's barely been touched or worked on. It's a huge scary dangerous feature, that Apple has pushed, only recently. But you're right: I don't think Apple created it. I'm not sure where the suggestion came from; a Google editor wrote it initially but that doesn't mean it was their idea. I think it's misrepresentative to state this as a clear & surefire win. To keep score over a matter of months for a standard which is risky, in draft, and has been outstanding for 8 years seems like a high definition of petty scorekeeping. Trying to portray this like a real win is for-sure too-soon & risking bullshit. We don't even know that delivering it is going to actually be ok: it's still at risk, we might find it is as dangerous as Chrome said, csswg might remove it from the draft. [1] https://github.com/w3c/csswg-drafts/pull/4733 https://github.com/w3c/csswg-drafts/pull/4733 [2] https://groups.google.com/u/0/a/chromium.org/g/blink-dev/c/hqkcKdDrhXE?pli=1 https://groups.google.com/u/0/a/chromium.org/g/blink-dev/c/h... [3] https://github.com/w3c/csswg-drafts/commit/248f22c92839a65048e429506826dda5145493e5 https://github.com/w3c/csswg-drafts/commit/248f22c92839a6504...

rektide 4y ago

From https://chromestatus.com/feature/5794378545102848 https://chromestatus.com/feature/5794378545102848 : > Unlike other selectors, :has pseudo class gives a way to apply a style rule to preceding elements (preceding siblings / ancestors / preceding siblings of ancestors) of a certain elements. > This difference is attractive to web developers, but also it generates lots of concerns mainly about performance and complexity. So there have been discussion about these over the years, but it was difficult to get those discussion moving forward. > It is true that it can generate performance issues and complex cases. But it is also true that there have been clear demands for the usage. > We thought that, clarifying those concerns would be helpful for the discussion. So we started to check feasibility on blink, and were able to get some meaningful and reasonable results from this step. Based on the results, we are going to move forward by prototyping. Right now the estimate is that they can ship in Chrome 105, but this still in advance. I often hear Safari-defenders say their browser is faster, that Chrome is bloated, and I think this is a great case demonstrating an opposite direction, showing a Chrome that is very focused on making sure the web stays healthy & doesn't have pitfalls & doesn't accidentally get slow. But Chrome is willing to play ball, has acknowledged the lack of this feature hurts, and has come around & tried to meet developer desire, rather than stay fast, & has followed what Safari has pushed for. Roberto, I had a really frustrating & negative time dealing with your pro-Safari anti-Chrome skepticisms[1] yesterday, which I felt were aimed primarily at snubbing & shorting. I hope if we engage again this time we can have a more earnest & forthright discourse. [1] https://news.ycombinator.com/item?id=31647980 https://news.ycombinator.com/item?id=31647980

robertoandred 4y ago
Has Safari pushed for it? Or is it simply that Google is slow to adopt the spec? If Safari is faster with features than Chrome is without, maybe it’s Chrome that’s the problem, and we shouldn’t let it hold back the web.
- rektide 4y ago
  It comes from Safari. No one else advocated for it. Firefox hasn't registered a position on it, has nothing underway. > Google is slow > Safari is faster with features > maybe it’s Chrome that’s the problem? Again you seem to be slanting everything very highly. And using endlessless questions? This is really some dogshit disingenuous debating, that looks like the dissembling crap you pulled yesterday. Please sir, man up & quit this crap.
  - robertoandred 4y ago
    What makes you think Apple created it? It’s been in the draft spec for four years. Google’s been working on it for a year at least. But Apple did get it first and now we’re waiting on Google.
    - rektide 4y ago
      Let's just dive in to what the real status: According to still-current PRs[1], :has() psuedo-selector is optional and at risk. The working group then noted "no one has figured out how to do it in a performant way," and there's still no clear evidence this capability will indeed be safe & free of pitfalls in any browser (and plenty of counter-evidence against). But Safari is implementing (risking performance pitfalls), & Chrome has decided that the risk of killing performance is an acceptable trade-off for the feature. They began some very early prototyping a year ago, to explore[2]. > It’s been in the draft spec for four years. First, that's a draft spec. Not published. Safari typically doesn't even start implementing until features are published, so this is all pretty different than where we normally are. Second, it's been in draft for >8 years[3]. It's barely been touched or worked on. It's a huge scary dangerous feature, that Apple has pushed, only recently. But you're right: I don't think Apple created it. I'm not sure where the suggestion came from; a Google editor wrote it initially but that doesn't mean it was their idea. I think it's misrepresentative to state this as a clear & surefire win. To keep score over a matter of months for a standard which is risky, in draft, and has been outstanding for 8 years seems like a high definition of petty scorekeeping. Trying to portray this like a real win is for-sure too-soon & risking bullshit. We don't even know that delivering it is going to actually be ok: it's still at risk, we might find it is as dangerous as Chrome said, csswg might remove it from the draft. [1] https://github.com/w3c/csswg-drafts/pull/4733 https://github.com/w3c/csswg-drafts/pull/4733 [2] https://groups.google.com/u/0/a/chromium.org/g/blink-dev/c/hqkcKdDrhXE?pli=1 https://groups.google.com/u/0/a/chromium.org/g/blink-dev/c/h... [3] https://github.com/w3c/csswg-drafts/commit/248f22c92839a65048e429506826dda5145493e5 https://github.com/w3c/csswg-drafts/commit/248f22c92839a6504...