Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
mastodon.world is one of the many independent Mastodon servers you can use to participate in the fediverse.
Generic Mastodon server for anyone to use.

Administered by:

Server stats:

9.5K
active users

mastodon.world: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#autocomplete

1 post1 participant0 posts today
Public *
Ecologia Digital

AI can't do your job
"By firing #skilledhumanworkers and replacing them with spicy #autocomplete, #Musk is assuming his final form as both the kind of boss who can be conned into replacing you with a defective chatbot and as the fast-talking sales rep who cons your boss. Musk is transforming key #gov functions into high-speed error-generating machines whose human minders are only the payroll to take the fall for the coming tsunami of #robotfuckups."
@pluralistic
pluralistic.net/2025/03/18/asb

pluralistic.netPluralistic: AI can’t do your job (18 Mar 2025) – Pluralistic: Daily links from Cory Doctorow
Public *
minioctt

superipertesti con spacc di testo in putto (HTML autocomplete su mobile)

I problemi con l’HTML, quelli veri, non finiscono veramente mai… ma in generale con i browser, perché non è manco tanto la sintassi #HTML il problema, ma il che cazzo i navigatori combinano con dei certi elementi fantastici ed attributi che lo sono un po’ meno. Per la puntata di oggi: le caselle di inserimento di testo custom su #mobile sono un troiaio assoluto, e la confusione attorno all’argomento non fa che peggiorare la mia già forte pazzia!!! 😩😭

C’è una serie di problemi (mica uno solo!) per cui su mobile (e nello specifico mi interessa su #Android, visto che non ho lo spiacere di usare iOS), ci sono glitch nell’interazione tra tastiere virtuali e campi di testo non-vanilla, come le <textarea> usate dal Monaco Editor ed Xterm.js. Beh, se per un editor di codice c’è Ace Editor come sostituto perfetto, mi trovavo in difficoltà sull’avere un emulatore terminale funzionante, visto che Xterm.js è l’unico che si trova in giro… e di implementarne uno a metà io che funziona peggio non ho voglia. Quindi, via di provine, a questo punto. 🧨

TLDR: per gli elementi di input testuale, esiste l’attributo stringa #autocomplete, che quando non specificato è tipo su “on“, può assumere una caterva di valori intermedi supportati solo da alcuni browser solo in alcune circostanze, e ciò che davvero interessa è settarlo su “off” per suggerire all’user-agent di non fare autocompletamento del testo, quindi non anticipare l’utente con le parole e idealmente non (dis)correggerlo. E la rogna è che di suggerimento si tratta, perché a quanto pare su mobile ognuno fa il cazzo che vuole, a partire dal browser e a finire con la tastiera… ☢️

Dai miei test devo decretare che Firefox se ne frega completamente dell’attributo, sia su <input type="text"> che su <textarea>. Su Chromium e derivati sembra funzionare, invece, in quanto l’applicazione imposta la tastiera virtuale in modalità textNoSuggestions, cosa che si evince anche dal fatto che sparisce la barra dei suggerimenti… o almeno, ci prova, ma sembra non funzionare su tutte le tastiere; per esempio, su quella di Samsung non sparisce… ma, allo stesso tempo, anche senza autocomplete="off", quella è una delle poche che non ha comunque i #bug di inserimento. ☕

Qui in video, infatti, si vede (vedersi è un parolone, perché la MIUI censura la tastiera nelle registrazioni schermo, ma gli #input si notano) la differenza tra Firefox e Chromium con OpenBoard, derivata della tastiera AOSP, che sul cellulare è l’unica che trovo veramente comoda, mentre sul tablet Samsung la predefinita è OK. (GBoard merda, ma in ogni caso ha gli stessi problemi di questa, la codebase è la stessa… l’unica altra che so funzionare bene è Hacker’s Keyboard, ma è scomodissima.) Xterm.js sempre con autocomplete="off", ma la volpe se ne frega. 🤡

Ma comunque, i bug sono in ogni caso infiniti qui, almeno assumendo la tastiera AOSP. Pure con questo aggiustamento, Xterm.js mi si mangia un carattere di spazio a sinistra quando premo invio per andare a capo, come se assieme alla newline venisse inviato un backspace, cosa che su desktop non succede… E poi, ovviamente, su Monaco non funziona il backspace su caratteri di whitespace, ed ho il sospetto che sia perché nella <textarea> invisibile usata per gestire l’input il testo viene segmentato, e i token di whitespace non vengono inseriti, e qualcosa fa si che i backspace non vengano registrati su una casella dunque vuota… ma se lo tenga pure Microsoft, il suo editor sminchiato. 💩

La cosa più strana però, in tutta questa storia, è un’altra: essendoci di mezzo tutti questi casi limite, nessuno si è reso conto che la cosa minima da fare è impostare autocomplete="off" sui campi di testo che usano handling custom. Su Firefox non funziona, OK, ma finché Mozilla non si sveglia useremo semplicemente Chromium. Non so per Monaco, ma per Xterm.js qualcuno aveva suggerito di fare questa cosa (#2403:529574475), ma alla fine non è stata mai fatta, perché ad altra gente non funzionava, e quindi l’hanno derubricata. Però poi, entrambi i progetti mettono altri attributi inutili… 👹

Vedete perché si dice che fare volontariamente sviluppo web è sintomo di malattia mentale? In entrambi i progetti, le <textarea> nascoste implementano l’attributo autocorrect="off", che sono abbastanza sicura sia frutto di un’allucinazione collettiva. Documentandosi un minimo, si scopre non solo che è non-standard (ma questo sembrano saperlo tutti), ma che è supportato solo da Safari, dove però supporta solo “true” e “false“, non “on” e “off“. L’attributo che certamente non funziona lo mettono tutti, ma quello che forse funziona nessuno… vi prego, salvatemi da questo #web di incompetenti!!! 💉

#autocomplete
Public
Habr

Почему ты не должен использовать onChange в React

Недавно, работая с компонентом ввода номера телефона в форме регистрации, я столкнулся с весьма неочевидной особенностью работы различных обработчиков событий. Связано это непосредственно с onChange , onPaste и onInput . Мне пришлось провести достаточно глубокий ресерч, чтобы разобраться в особенностях, которые я встретил. Начнем по порядку.

habr.com/ru/articles/874874/

ХабрПочему ты не должен использовать onChange в ReactНедавно, работая с компонентом ввода номера телефона в форме регистрации, я столкнулся с весьма неочевидной особенностью работы различных обработчиков событий. Связано это непосредственно с onChange ,...
#onChange#onInput#input
Public *
Adam Beer

Okay, one more time for the people in the back.

The "AI" (🤮) craze of the past few years is all about Large Language Models. This immediately tells us that the only thing these systems "know" is trends/patterns in the ways that people write, to the extent that those patterns are expressed in the text that was used to train the model. Even the common term, "hallucination," gives these things far too much credit: a hallucination is a departure from reality, but an LLM has no concept of reality to depart from!

An LLM does exactly one thing: you give it a chunk of text, and it predicts which word will come next after the end of the chunk. That's it. An LLM-powered chatbot will then stick that word onto the end of the chunk and feed the resulting, slightly longer chunk back into the model to predict the next word, and then do it again for the next, etc. Such a chatbot's output is unreliable by design, because there are many linguistically valid continuations to any chunk of text, and the model usually reflects that by having an output that means, "There is a 63% chance that the next word is X, a 14% chance that it's Y, etc." The text produced by these chatbots is often not even correlated with factual correctness, because the models are trained on works of fiction and non-fiction alike.

For example, when you ask a chatbot what 2 + 2 is, it will usually say it's 4, but not because the model knows anything about math. It's because when people write about asking that question, the text that they write next is usually a statement that the answer is 4. But if the model's training data includes Orwell's Nineteen Eighty-Four (or certain texts that discuss the book or its ideas), then the chatbot will very rarely say that the answer is 5 instead, because convincing people that that is the answer is a plot point in the book.

If you're still having trouble, you can think of it this way: when you ask one of these chatbots a question, it does not give you the answer; it gives you an example of what—linguistically speaking—an answer might look like. Or, to put it even more succinctly: these things are not the Star Trek ship's computer; they are very impressive autocomplete.

So LLMs are fundamentally a poor fit for any task that is some form of, "producing factually correct information." But if you really wanted to try to force it and damn the torpedos, then I'd say you basically have two options. I'll tell you what they are in a reply. 🧵

#AI#AIHype#autoComplete
Public
Erwin

I’ve been pleasantly surprised by how good word suggestions are when typing in the current iOS. It seems to take into account the context of what has been written already, sometimes several sentences earlier, and sometimes when those typed words were deleted to rewrite the sentence differently. I don’t know if this is “Apple Intelligence” (these are not the latest devices) or just better autocomplete. Either way, good job Apple!

#ios#apple#ai
ExploreLive feeds
About