I can also see how it is not necessarily the case, since all models seem plagued by having unique cliche patterns. We all seem to experience the writing smells from the same models. I see 'cleanly' a lot less from GPT 5.5 vs <5.4

(minor nit: release article says "Uint8Array.prototype.fromBase64()" when it's actually "Uint8Array.fromBase64()" per the code sample. Same for .fromHex)

I think that pretty much speaks to how shamefully bad politics has gotten here in the US. I see a couple of comments that jump to speculate that it could be used as a tool of politics, or that they would rather opt-out of knowing about an imminent threat to themselves and/or their fellow American's lives. I think it's selfish, considering smoke and CO2 detectors can't warn you of nuclear attacks. If an office of the state was responsible for calling out a fire in the building, I would want every chance to be informed, regardless of whether or not they were my prefered elected official. Obviously, if the system was abused I would want it to be fixed.

Last I checked you can always give Chrome a stronger hint not to autocomplete using something like this:

    document.querySelectorAll("input[autocomplete=off]")
        .forEach(element =>
            element.autocomplete = window && window.chrome ? "hell-no-chrome" : "off"
        );

If the result was too verbose, you can always handroll your own JS:

    {{constructor.constructor(constructor.name.constructor.fromCharCode(97,108,101,114,116,40,39,120,115,115,39,41))()}}

I think another solution (besides v-pre) to "fixing" it (though you might say that relying on htmlspecialchars() to protect against user-supplied {{vue expressions}} was unwise to begin with) is to replace { and } with { and } after using htmlspecialchars/htmlentities.

EDIT: Another solution would be to pass a different set of delimiters to Vue that uses characters that would be escaped by htmlspecialchars, like demonstrated in [1] or like so:

    Vue.options.delimiters = ['<%', '%>'];

CSS-only for this sort if thing is totally contrived, but making it still proved to be a fun little exercise.

[0]: https://codepen.io/scryptonite/pen/oLGzdj

[1]: https://github.com/you-dont-need/You-Dont-Need-JavaScript

I presume the ones that gave out sooner were manually stopped by whoever maintains them or they hit some sort of memory limit. Good times.

Comments URL: https://news.ycombinator.com/item?id=12730681

Points: 1

# Comments: 0

1: http://codepen.io/scryptonite/pen/oLGzdj?editors=1000

I noticed that the Chrome team also developed a feature called Threaded scrolling in an attempt to improve site UX, but instead (or additionally?) completely ruins the ability to rely on onscroll/onmousewheel events (let alone being able to trust the values pulled from scrollLeft/scrollTop using requestAnimationFrame or similar). This can be seen on these two GIFs, with threaded scrolling enabled (currently the default behavior): https://gfycat.com/DiligentHomelyIndianelephant and with threaded scrolling disabled (behind a chrome flag): https://gfycat.com/SlimDefinitiveErin

The same flag/feature is active on mobile Chrome as well, so the same effect can be seen. The only way to guarantee jank-free work with scroll position (for parallax or w/e) is to implement handling user-input-to-scroll-behavior entirely yourself, which is rather unfortunate imo.

You can play with this yourself: http://jsbin.com/mohehotupe/edit (might need to click "Run with JS" / or tick "Auto-run JS" to start the scroll-listening script)

My take on autocomplete is that the standard says it's something I can disable, so autocomplete="off" is simply something the browser should obey. I have no problems with users using extensions or taking "advantage" of a browser setting to "fix" websites they say have abused this attribute. But there are valid use cases for disabling autocomplete as other comments have mentioned, and all they have done is make it to where I just have to do autocomplete="sudo-off" and it "works". But what happens when other webmasters misuse the attribute again? Might as well just toss support for it if they really can't trust the page to do the right thing.

http://i.imgur.com/FYkxCNS.png

  var a=process.argv,i=a.length,x=0;while(i>2)x-=-a[--i];console.log(x)

I've also noticed some of them used to make requests synchronously (waiting for the previous to finish before making another), but they have adapted to make requests in parallel and add timeouts so they don't have their time wasted quite as long.

I created a log of the ones who stayed connected the longest.

https://gist.github.com/scryptonite/5324724

I don't bother to maintain it anymore, but it was pretty interesting watching them change tactics over time.