6 ms·

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 tha

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...
    - robertoandred 4y ago
      > “At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. And your “that no one has figured out how” quote is from three years ago, and was followed by “If a browser figures out how to do it we'd be happy” So, sounds like Safari has figured out a way and is pushing the web forward. That’s good, right? Or is it only good when Google wants a browser to have access to serial devices?
      - rektide 4y ago
        Incorrectly confident without reservation, undermining in mis-truthful ways. Again. This is not playing straight, & is taking too much rope. Google's warning in their Intent to Ship[1] is still clear: > Ergonomics risks: Authors can easily increase complexity of selector query or style invalidation by using ':has()' pseudo classes. This could still fail. Safari hasn't "figured out a way to do it." (And their implementation is significantly less complete at that.) They're taking a gamble, a bet, that this feature will be Good-Enough and Not-Too-Bad. This bet could hurt the web badly. We should not jump to conclusions on this. You are counting the chickens before they hatch. Again, to seek to award points here, to say either company is doing better: it seems a misdeed (the releases are, relatively speaking, very near each other) and premature (this could be a fast or slow catastrophe). I feel like you continue to play up bad side of Brandolini's Law[2], which I had hoped we could avoid tonight unlike last night. "The amount of energy needed to refute bullshit is an order of magnitude larger than is needed to produce it." You have some ok-ish areas of inquiry, but they're always intricately inter-woven with hyper-politization point-scoring sabotage. The question establishes legitemacy, then the nails of doubt & questioning shatter any established said facts: this is not to understand, it's to spread confusion/doubt. Never have you acknowledged a single point said, only spread more doubt. [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/bRsbl3wLuyk/m/mt3iSKNHBQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/bRsbl... [2] https://en.wikipedia.org/wiki/Brandolini%27s_law https://en.wikipedia.org/wiki/Brandolini%27s_law
        dmitriid 4y ago
        > This bet could hurt the web badly. But not when Chrome does it, right? Not when Chrome implements an avalanche of non-standards from incomplete pre-draft specs authored by no one else but Google? Then it's "pushing the web forward" and it's the "backwards Safari that is holding the web back"?

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...
  - robertoandred 4y ago
    > “At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. And your “that no one has figured out how” quote is from three years ago, and was followed by “If a browser figures out how to do it we'd be happy” So, sounds like Safari has figured out a way and is pushing the web forward. That’s good, right? Or is it only good when Google wants a browser to have access to serial devices?
    - rektide 4y ago
      Incorrectly confident without reservation, undermining in mis-truthful ways. Again. This is not playing straight, & is taking too much rope. Google's warning in their Intent to Ship[1] is still clear: > Ergonomics risks: Authors can easily increase complexity of selector query or style invalidation by using ':has()' pseudo classes. This could still fail. Safari hasn't "figured out a way to do it." (And their implementation is significantly less complete at that.) They're taking a gamble, a bet, that this feature will be Good-Enough and Not-Too-Bad. This bet could hurt the web badly. We should not jump to conclusions on this. You are counting the chickens before they hatch. Again, to seek to award points here, to say either company is doing better: it seems a misdeed (the releases are, relatively speaking, very near each other) and premature (this could be a fast or slow catastrophe). I feel like you continue to play up bad side of Brandolini's Law[2], which I had hoped we could avoid tonight unlike last night. "The amount of energy needed to refute bullshit is an order of magnitude larger than is needed to produce it." You have some ok-ish areas of inquiry, but they're always intricately inter-woven with hyper-politization point-scoring sabotage. The question establishes legitemacy, then the nails of doubt & questioning shatter any established said facts: this is not to understand, it's to spread confusion/doubt. Never have you acknowledged a single point said, only spread more doubt. [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/bRsbl3wLuyk/m/mt3iSKNHBQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/bRsbl... [2] https://en.wikipedia.org/wiki/Brandolini%27s_law https://en.wikipedia.org/wiki/Brandolini%27s_law
      - dmitriid 4y ago
        > This bet could hurt the web badly. But not when Chrome does it, right? Not when Chrome implements an avalanche of non-standards from incomplete pre-draft specs authored by no one else but Google? Then it's "pushing the web forward" and it's the "backwards Safari that is holding the web back"?