Arricchimento culturale in Svezia in corso
Ad
https://www.breitbart.com/europe/2019/01/04/patient-placed-in-quarantine-after-suspected-ebola-case-in-sweden/
The Emergency Room of a Swedish hospital was closed down Friday morning after a patient recently returned from Africa arrived vomiting blood, a possible symptom of the deadly and contagious Ebola virus.
☺
- Scritto da: altg
> um.. adesso capisco chi c'e` al W3.
> In maggioranza sviluppatori di firefox.
> Temo ci sia un conflitto d'interesse.
> Con tanto di leggi ad-browser.
Non credo, perché il problema a cui mi riferivo era un problema di comportamento proprio di Firefox. In pratica una cosa da un giorno all'altro aveva smesso di funzionare come era funzionata dalla versione 0 di Firefox in su... e questo perché il W3 ha scelto un'implementazione diversa (ed estremamente illogica, cosa che gli ho fatto notare e infatti mi hanno risposto che hanno scelto l'altra implementazione più o meno tirando la monetina e senza rendersi conto che questo poteva in effetti essere un problema).
Anzi, alcuni di loro mi hanno addirittura risposto "abbiamo scelto l'implementazione di IE"
☺
> E` un campo di testo con un pulsante di fianco.
Size si applica solo ai campi testuali, perciò si applica solo alla parte testuale del componente. Non ha un significato grafico. Width ha un significato grafico e si dovrebbe usare quello. L'HTML4 era bacato, ora è stato aggiustato con l'HTML5.
Un browser vocale, per esempio, potrebbe usare l'attributo size per leggere a voce tot-caratteri. Per esempio, dicendo size="20", il browser vocale potrebbe leggere un "preview" di 20 caratteri e poi permettere all'utente di approfondire ulteriormente. Come vedi, nel caso del browser vocale, l'attributo size ha un significato ben preciso ed è utile. Mentre l'attributo width non ha alcun significato o utilità. Ho fatto solo un esempio scemo e non so se è questa la ragione che ha spinto il W3 a _tenere_ l'attributo size, ma ti mostra come i due attributi abbiano significati diversi.
> se ho ragione ho ragione,
> se avevo torto avro` ragione,
Guarda, è come le regole della strada. Non è questione di ragione o torto. Può non piacerti che su quella strada ci sia il 50Km/h, puoi anche usare la logica e dire "cazzo, non c'è nessuno, perché devo andare a 50Km/h?". A quel punto acceleri. Nel caso migliore ti becchi solo la multa. Nel caso peggiore un bambino ti attraversa la strada da un'uscita che tu non avevi visto e considerato e l'ammazzi.
Stessa cosa per lo standard. Lo standard è lì per un motivo. Possono sembrarti assurde le sue scelte, in tal caso puoi andare sulla loro mailing-list o sul loro bugzilla e discuterle... ma dovresti rispettarle, per evitare nel frattempo di fare un macello.
Il W3 ha deciso così, e non puoi prendertela con Firefox se fa quello che il W3 ha stabilito.
> Width e` ignorata da firefox per gli input di
> tipo file.
Vero. Ma non è colpa di Firefox.
> su quel cazzo di browser l'unico
> modo per ottenerla e` approssimarla con
> l'attributo SIZE.
Non è colpa di Firefox. È come se ti incazzassi con il vigile che ti ha dato la multa perché hai posteggiato in doppia fila. Il vigile ha solo applicato il codice della strada.
> In HTML4 aveva chiaramente motivazioni grafiche,
L'HTML4 non esiste più. È interamente deprecato.
> Bene, allora come lo dimensiono?
Non puoi. Il dimensionamento non è previsto.
Usa uno dei trucchetti che trovi sul web. Non so che dirti.
> Sbagliando, perche` nel corso di questi strani
> eoni c'e` sempre
> stato.
Tempo fa ho fatto notare che un'altra cosa aveva cambiato comportamento. Lo detto al W3, il W3 mi ha risposto: "si, lo sappiamo. La ragione per cui _PRIMA_ funzionava è che i browser potevano fare quel cazzo che volevano visto che l'HTML era vago, ora non più... gli algoritmi di interpretazione dell'HTML sono stabiliti da ora in poi dal W3 e i browser si devono adeguare".
> Gli altri poveracci hanno voluto
È irrilevante perché PRIMA l'HTML era fornito come un set di regole vaghe. Ora l'HTML è fornito con tanto di algoritmi di interpretazione fissi del W3. In altre parole, prima, i browser potevano fare quel che volevano, ora non possono più permettersi questo lusso... non se vogliono attenersi allo standard.
Size si applica solo ai campi testuali, perciò si applica solo alla parte testuale del componente. Non ha un significato grafico. Width ha un significato grafico e si dovrebbe usare quello. L'HTML4 era bacato, ora è stato aggiustato con l'HTML5.
Un browser vocale, per esempio, potrebbe usare l'attributo size per leggere a voce tot-caratteri. Per esempio, dicendo size="20", il browser vocale potrebbe leggere un "preview" di 20 caratteri e poi permettere all'utente di approfondire ulteriormente. Come vedi, nel caso del browser vocale, l'attributo size ha un significato ben preciso ed è utile. Mentre l'attributo width non ha alcun significato o utilità. Ho fatto solo un esempio scemo e non so se è questa la ragione che ha spinto il W3 a _tenere_ l'attributo size, ma ti mostra come i due attributi abbiano significati diversi.
> se ho ragione ho ragione,
> se avevo torto avro` ragione,
Guarda, è come le regole della strada. Non è questione di ragione o torto. Può non piacerti che su quella strada ci sia il 50Km/h, puoi anche usare la logica e dire "cazzo, non c'è nessuno, perché devo andare a 50Km/h?". A quel punto acceleri. Nel caso migliore ti becchi solo la multa. Nel caso peggiore un bambino ti attraversa la strada da un'uscita che tu non avevi visto e considerato e l'ammazzi.
Stessa cosa per lo standard. Lo standard è lì per un motivo. Possono sembrarti assurde le sue scelte, in tal caso puoi andare sulla loro mailing-list o sul loro bugzilla e discuterle... ma dovresti rispettarle, per evitare nel frattempo di fare un macello.
Il W3 ha deciso così, e non puoi prendertela con Firefox se fa quello che il W3 ha stabilito.
> Width e` ignorata da firefox per gli input di
> tipo file.
Vero. Ma non è colpa di Firefox.
> su quel cazzo di browser l'unico
> modo per ottenerla e` approssimarla con
> l'attributo SIZE.
Non è colpa di Firefox. È come se ti incazzassi con il vigile che ti ha dato la multa perché hai posteggiato in doppia fila. Il vigile ha solo applicato il codice della strada.
> In HTML4 aveva chiaramente motivazioni grafiche,
L'HTML4 non esiste più. È interamente deprecato.
> Bene, allora come lo dimensiono?
Non puoi. Il dimensionamento non è previsto.
Usa uno dei trucchetti che trovi sul web. Non so che dirti.
> Sbagliando, perche` nel corso di questi strani
> eoni c'e` sempre
> stato.
Tempo fa ho fatto notare che un'altra cosa aveva cambiato comportamento. Lo detto al W3, il W3 mi ha risposto: "si, lo sappiamo. La ragione per cui _PRIMA_ funzionava è che i browser potevano fare quel cazzo che volevano visto che l'HTML era vago, ora non più... gli algoritmi di interpretazione dell'HTML sono stabiliti da ora in poi dal W3 e i browser si devono adeguare".
> Gli altri poveracci hanno voluto
È irrilevante perché PRIMA l'HTML era fornito come un set di regole vaghe. Ora l'HTML è fornito con tanto di algoritmi di interpretazione fissi del W3. In altre parole, prima, i browser potevano fare quel che volevano, ora non possono più permettersi questo lusso... non se vogliono attenersi allo standard.
Il coraggio degli asiatici
Ad
https://imgur.com/iYd5ZkJ
Cinesi salvano Gatto Selvaggio da sicuro annegamento, altro che musulmani!
☺
Proc di Catania
Mathew Berger lo scopritore di questa nuova razza. Dovrebbe avere 12 anni oggi
☺
- Scritto da: altg
> Allora non ci siamo capiti.
> In questo thread non e` un fatto di colorazione,
> bordi
> eccetera.
Io sto parlando di stili. Fra gli stili ci sono bordi, colori, dimensioni, ecc.
> E` un fatto di width, di larghezza.
Cioè di dimensioni, ovvero di stile.
Il CSS1-2-3 non si applica ai controlli composti. Ergo nemmeno il width e l'height.
> Parte dello stile, parte dei coreattrs.
> E firefox non la accetta.
E fa bene. Come potrebbe? Il CSS1-2-3 non tratta quel componente e non vi si applica. Non è che _una parte_ del CSS non si applica a quei controlli... no... proprio _tutto_ il CSS non si applica.
> E nell'html4 sbaglia anche a definirla a partire
> dall'attributo "size" perche` la interpreta in
> caratteri e non in
> pixels.
http://www.w3schools.com/html5/att_input_size.asp
The size attribute specifies the width, in characters, of an input field.
>
>
http://www.w3.org/TR/html4/interact/forms.html#h-1
> dice:
>
> size = cdata [CN]
> This attribute tells the user agent the initial
> width of the control. The width is given in
> pixels except when type attribute has the value
> "text" or "password". In that case, its value
> refers to the (integer) number of
> characters.
http://www.w3.org/TR/html5/common-input-element-at...
In HTML5 "size" si riferisce solo alla dimensione in caratteri.
La specifica HTML4 non va più presa in considerazione, diverse cose in HTML5 sono cambiate.
> E` in pixels eccetto quando l'input e` di tipo
> text o
> password.
> File non e` text ne` password, quindi dev'essere
> interpretata in
> pixels.
Vero in HTML4, ma ora i browser implementano l'HTML5.
> Ma firefox la interpreta in caratteri.
Proprio come dice la specifica.
> Mica e` la fine del mondo, ma e` fuori standard e
> devono
> fixarlo.
Si, Opera lo è.
> Dal 2000. Da quando si chiamava PHOENIX
> rompe le scatole con questa
> interpetazione.
Devi usare la logica.
Tutti i campi di tipo _testuale_ si misurano in _caratteri_. Fanno eccezione i campi _grafici_ che invece si misuravano in pixel.
L'input di tipo FILE è un campo di tipo _testuale_ perciò il size si misura in caratteri.
Questa era probabilmente la logica che ha sempre spinto firefox dietro la sua interpretazione delle specifiche. È una logica giusta e infatti il W3 gli ha dato ragione.
Ad ogni modo qui tu stai confondendo SIZE e WIDTH. Width si misura in pixel/em/ecc e fa parte del CSS, Size che non fa parte del CSS invece si misura in caratteri.
Mentre il width ha un significato strettamente grafico, il size ha un significato non necessariamente grafico.
È un po' come la differenza che passa fra il tag B e il tag STRONG. Sono simili, ma il primo è deprecato perché è meramente grafico, il secondo invece no, anzi, è incoraggiato lì dove serve.
In altre parole tu vuoi usare il SIZE per motivi grafici, sbagliando, perché il SIZE non ha motivazioni grafiche. Il Width si, ma il Width si specifica nel CSS (lì dove previsto dallo standard e l'input type="file" non è previsto nel CSS).
Ora, torniamo al discorso "perché il width viene ignorato da Firefox?".
Ho già detto che il width non fa parte delle specifiche CSS sull'input type FILE. Quindi come dovrebbe interpretarlo Firefox? A quale parte del componente si riferisce? Al campo testuale? Al pulsante? A entrambe? In che rapporto dovrebbe essere tenuta la dimensione pulsante/campo testuale? Deve tenere conto di bordi interni? La risposta a tutte queste domande è la stessa: boh. Non esiste una specifica che dica chiaramente a che si riferisce il width nel caso dei componenti composti, firefox ha dunque scelto di non implementarlo proprio, onde evitare, fra 5/10/15 anni di aver contribuito a rompere tutti i siti WEB che da un giorno all'altro si troveranno con dimensioni sbagliate perché il W3 ha preso una scelta diversa.
> Allora non ci siamo capiti.
> In questo thread non e` un fatto di colorazione,
> bordi
> eccetera.
Io sto parlando di stili. Fra gli stili ci sono bordi, colori, dimensioni, ecc.
> E` un fatto di width, di larghezza.
Cioè di dimensioni, ovvero di stile.
Il CSS1-2-3 non si applica ai controlli composti. Ergo nemmeno il width e l'height.
> Parte dello stile, parte dei coreattrs.
> E firefox non la accetta.
E fa bene. Come potrebbe? Il CSS1-2-3 non tratta quel componente e non vi si applica. Non è che _una parte_ del CSS non si applica a quei controlli... no... proprio _tutto_ il CSS non si applica.
> E nell'html4 sbaglia anche a definirla a partire
> dall'attributo "size" perche` la interpreta in
> caratteri e non in
> pixels.
http://www.w3schools.com/html5/att_input_size.asp
The size attribute specifies the width, in characters, of an input field.
>
>
> dice:
>
> size = cdata [CN]
> This attribute tells the user agent the initial
> width of the control. The width is given in
> pixels except when type attribute has the value
> "text" or "password". In that case, its value
> refers to the (integer) number of
> characters.
In HTML5 "size" si riferisce solo alla dimensione in caratteri.
La specifica HTML4 non va più presa in considerazione, diverse cose in HTML5 sono cambiate.
> E` in pixels eccetto quando l'input e` di tipo
> text o
> password.
> File non e` text ne` password, quindi dev'essere
> interpretata in
> pixels.
Vero in HTML4, ma ora i browser implementano l'HTML5.
> Ma firefox la interpreta in caratteri.
Proprio come dice la specifica.
> Mica e` la fine del mondo, ma e` fuori standard e
> devono
> fixarlo.
Si, Opera lo è.
> Dal 2000. Da quando si chiamava PHOENIX
> rompe le scatole con questa
> interpetazione.
Devi usare la logica.
Tutti i campi di tipo _testuale_ si misurano in _caratteri_. Fanno eccezione i campi _grafici_ che invece si misuravano in pixel.
L'input di tipo FILE è un campo di tipo _testuale_ perciò il size si misura in caratteri.
Questa era probabilmente la logica che ha sempre spinto firefox dietro la sua interpretazione delle specifiche. È una logica giusta e infatti il W3 gli ha dato ragione.
Ad ogni modo qui tu stai confondendo SIZE e WIDTH. Width si misura in pixel/em/ecc e fa parte del CSS, Size che non fa parte del CSS invece si misura in caratteri.
Mentre il width ha un significato strettamente grafico, il size ha un significato non necessariamente grafico.
È un po' come la differenza che passa fra il tag B e il tag STRONG. Sono simili, ma il primo è deprecato perché è meramente grafico, il secondo invece no, anzi, è incoraggiato lì dove serve.
In altre parole tu vuoi usare il SIZE per motivi grafici, sbagliando, perché il SIZE non ha motivazioni grafiche. Il Width si, ma il Width si specifica nel CSS (lì dove previsto dallo standard e l'input type="file" non è previsto nel CSS).
Ora, torniamo al discorso "perché il width viene ignorato da Firefox?".
Ho già detto che il width non fa parte delle specifiche CSS sull'input type FILE. Quindi come dovrebbe interpretarlo Firefox? A quale parte del componente si riferisce? Al campo testuale? Al pulsante? A entrambe? In che rapporto dovrebbe essere tenuta la dimensione pulsante/campo testuale? Deve tenere conto di bordi interni? La risposta a tutte queste domande è la stessa: boh. Non esiste una specifica che dica chiaramente a che si riferisce il width nel caso dei componenti composti, firefox ha dunque scelto di non implementarlo proprio, onde evitare, fra 5/10/15 anni di aver contribuito a rompere tutti i siti WEB che da un giorno all'altro si troveranno con dimensioni sbagliate perché il W3 ha preso una scelta diversa.
Vieni anche tu a scuola in Svezia!
Ad
https://www.breitbart.com/europe/2019/01/11/swedish-journalist-teachers-have-given-up-rising-school-violence/
Qui accettiamo qualunque tipo di animale! Non facciamo discriminazioni noi! Mica siamo razzisti!!!
☺
- Scritto da:
> >
> >
> > Specifica CSS3 (Scope).
> > In addition, this document does not
> > attempt to solve all user interface related
> > issues / features that can be found in modern
> > user interfaces. Perhaps future versions may
> > attempt to solve these. For
> > example:
> >
> > * Complex or composite controls (e.g. the HTML4
> > <INPUT type="file"> and the <ISINDEX>
> > elements).
> > * The appearance, styling and coloring of
> > scrollbars.
> > [CUT]
> >
> > Quindi né i componenti composti né le scrollbar
> > sono stati presi in considerazione dalla
> > specifica del CC3 (e di conseguenza nemmeno
> dalle
> > precedenti).
> > Non è quindi Firefox a non essersi adattato allo
> > standard CSS... ma è lo standard CSS a non
> > applicarsi, per ora, quelle due
> > componenti.
> >
> > In altre parole, Firefox si comporta
> > correttamente quando non ti lascia mettere uno
> > stile a quelle componenti, se lo facesse si
> > starebbe inventando uno standard tutto suo e
> > potrebbe portarti a creare siti che potrebbero
> > non funzionare su altri browser o potrebbero
> > comportarsi in modo difforme dallo standard CSS
> > futuro. Se gli altri browser ti lasciano stilare
> > quei campi e componenti si tratta di un loro
> > bug.
> >
> > È fastidioso, lo so, anche io avrei voluto poter
> > stilare il campo input type="file" più di una
> > volta... ma non si può fare... nemmeno le cose
> > base, perché il CSS si applica a tutti i
> > componenti... TRANNE quelli che esclude
> > esplicitamente, e questi sono quelli
> > esclusi.
> >
> > Se vuoi puoi usare librerie e trucchi vari, ma
> > non puoi dare la colpa a Firefox per non
> > implementare qualcosa che è esplicitamente
> > escluso dallo standard (il perché non lo so,
> > immagino ci siano ragioni di sicurezza dietro o
> > complessità varie che ancora non sono state
> > indirizzate dal W3C).
>
> Sì ma nulla vieterebbe al W3C di decidere uno
> standard per lo stile dei controlli finora
> esclusi e pubblicarlo, nel frattempo, in una
> bozza di una versione CSS successiva in modo che
> i produttori di browser possano
> regolarsi.
Il CSS3 oramai non può essere toccato se non per piccoli aggiustamenti a quello che già prevede. Non possono aggiungere cose al CSS3. Puoi però sperare che, una volta che il CSS3 è stato finalizzato, queste caratteristiche vengano aggiunte nel CSS4.
Francamente non ho idea del perché il CSS3 non tratta i componenti composti, probabilmente ci sono complicazioni che noi, esterni, non vediamo.
Ad ogni modo puoi suggerirgli la cosa
In "severity" metti "enhancement", Hardware "All", OS "All". Come titolo potresti mettere "Styling Composite/Complex Controls".
Spiega che è oramai dal 2000 che si sta cercando di stilare i componenti tipo input type="file" e che sarebbe anche ora che facessero qualcosa al riguardo.
☺
Specifica CSS3 (Scope).
In addition, this document does not attempt to solve all user interface related issues / features that can be found in modern user interfaces. Perhaps future versions may attempt to solve these. For example:
* Complex or composite controls (e.g. the HTML4 <INPUT type="file"> and the <ISINDEX> elements).
* The appearance, styling and coloring of scrollbars.
[CUT]
Quindi né i componenti composti né le scrollbar sono stati presi in considerazione dalla specifica del CC3 (e di conseguenza nemmeno dalle precedenti).
Non è quindi Firefox a non essersi adattato allo standard CSS... ma è lo standard CSS a non applicarsi, per ora, quelle due componenti.
In altre parole, Firefox si comporta correttamente quando non ti lascia mettere uno stile a quelle componenti, se lo facesse si starebbe inventando uno standard tutto suo e potrebbe portarti a creare siti che potrebbero non funzionare su altri browser o potrebbero comportarsi in modo difforme dallo standard CSS futuro. Se gli altri browser ti lasciano stilare quei campi e componenti si tratta di un loro bug.
È fastidioso, lo so, anche io avrei voluto poter stilare il campo input type="file" più di una volta... ma non si può fare... nemmeno le cose base, perché il CSS si applica a tutti i componenti... TRANNE quelli che esclude esplicitamente, e questi sono quelli esclusi.
Se vuoi puoi usare librerie e trucchi vari, ma non puoi dare la colpa a Firefox per non implementare qualcosa che è esplicitamente escluso dallo standard (il perché non lo so, immagino ci siano ragioni di sicurezza dietro o complessità varie che ancora non sono state indirizzate dal W3C).
☺
- Scritto da:
> A tenere aperte le applicazioni anche da spento?
> La roba in RAM la copia anche sull'hd?
>
Due soluzioni:
1) non è spento, continua ad alimentare la RAM ed è pronto a ripartire immediatamente appena il clock è ristabilito al processore. In altre parole è in stand-by.
2) è in ibernazione. È spento, ma il contenuto della RAM è scritto sul disco. All'avvio la RAM viene ripescata, ricostruita dal disco e il tutto riprende da lì.
L'ibernazione è particolarmente dannosa da un punto di vista della privacy. I dati che finiscono sul disco spesso lì restano, anche per giorni, settimane, mesi.
☺
- Scritto da:
> A nessuno interessa il cosplay?
Femmina; too old.
> Dove sono finiti
> i pedoni?
Femmina; too old.
> Dopo le furiose liti dei giorni scorsi
> sono spariti tutti?
>
Femmina; too old.
> A nessuno interessa il cosplay?
Femmina; too old.
> Dove sono finiti
> i pedoni?
Femmina; too old.
> Dopo le furiose liti dei giorni scorsi
> sono spariti tutti?
>
Femmina; too old.
AH SI ma NO Non lo so
Ad
http://sallo.it
LO SAI? Allora NON fa per te. NON LO SAI? Allora non ti serve.
☺
- Scritto da: Giambo
> Li volete leggere questi PVT o cosa
?!?!Non mi vuoi bene...
a me non hai scritto nulla 
☺
- Scritto da: exsinistro
>
>
> Alla manifestazione dei disabili contro il
> governo, molti ciechi ci sono andati in auto,
> potevano farlo visto che avevano la
> patente.
> Alcuni sordomuti urlavano slogan contro
> Berlusconi, alcuni paraplegici correvano
> lanciando
> sassi.
Già, perché i disabili veri non esistono, esistono solo i truffatori...
☺
- Scritto da: altg
> Perche` non lo considerano importante.
Semplicemente non sanno come fare.
Il comportamento dei controlli dipende dal W3C.
Se il W3C non descrive come questi debbano rispondere al CSS i vari browser non sono autorizzati a farlo al posto loro. In particolare, nel caso specifico, probabilmente, non vogliono rischiare che attraverso degli stili l'utente possa essere ingannato nel caricare un file su un sito malevolo. Probabilmente quindi non vogliono prendersi la responsabilità di toccare qualcosa che il W3C non vuole modificare e che potrebbe portare a furto di dati.
Ad ogni modo esistono modi per bypassare questo limite... questo è uno dei più conosciuti:
http://www.quirksmode.org/dom/inputfile.html
>
> Importance: -- minor with 89 votes
> (vote)
>
> Non ho mai avuto una gran compatibilita` di
> vedute su cosa abbiano considerato importante nel
> corso della loro storia. Per esempio per me la
> velocita` a cui si aggiorna una pagina con F5, o
> quella a cui parte il browser, sarebbe
> importante. Per loro pare di no. Ricordo come
> firefox fosse lento come un pachiderma con la
> labirintite, sull'Eee a 900 MHz, dove Opera
> andava tranquillo come qui sull'iMac. Poi perche`
> uso Opera? mah, chissa`... forse perche` li ho
> sempre visti, ma sempre, da sempre, un tantino
> piu` attenti a quel che fanno? certo non hanno
> tutti quei cosini che la gente aggiunge a firefox
> (per incasinarlo un po' di piu`?): una gran
> perdita...
>
☺
- Scritto da: dada_216
>
> - Scritto da: Daisuke Niwa
> >
> > - Scritto da: dada_216
> > > enciclopedia del basic e enciclopedia di
> > > elettronica e informatica della jackson
> > > libri....
> > >
> > > solo che a quella basic mancano i volumi con i
> > > programmi.
> >
> > Si, belink?
>
> tira giù il prezzo trattando via emmmail,
> rispondo un po io un po un
> altro...
>
> http://www.comicsclub.net/store/product.php?produc
>
>
> http://www.comicsclub.net/store/product.php?produc
Hmmm 40 euro per l'enciclopedia del basic, è un po' tantino. Ma d'altra parte è dell'82. Potrebbe essere interessante, cmq ora no. Vedo che ce l'hanno anche su ebay più o meno a quel prezzo.
Invece quella di elettronica di che anno è?
Anche io ho un'enciclopedia di Elettronica e Informatica della Jackson ma la copertina è diversa. La mia è composta di 9 volumi teorici più 4 di progetti e tecniche. È del 1995.
I 9 volumi sono:
- Comunicazioni
- Elettronica Analogica 1
- Elettronica Analogica 2
- Hardware dei PC e Reti
- Microprocessori
- Elettronica Digitale 1
- Elettronica Digitale 2
- Elettrotecnica
- Progetti
Mentre i 4 pratici sono:
- Montacci Vol 1
- Montacci Vol 2
- Montacci Vol 3
- Tecniche
Fa tutto parte di un'unica enciclopedia.
☺
- Scritto da:
>
> - Scritto da: Daisuke Niwa
> >
> > - Scritto da:
> > >
> > > - Scritto da: Daisuke Niwa
> > > >
> > > > - Scritto da:
> > > > >
> > > > > - Scritto da: Daisuke Niwa
> > > > > > 18:16 <@caeleste> nathan...
> > > > > > 18:16 <@caeleste> ....lie to me
> > > > > > 18:16 < fastwebbaro> i like pussy
> > > > > >
> > > > > > CVD.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> ???????????????????????
(ne> > > > >
> > > >
> > > >
> > > > Quanto avevi in inglese?
> > > >
> > > > Caeleste ha chiesto a Nathan di dirle una
> > bugia.
> > > > Nathan (fastwebbaro) le ha risposto che gli
> > > piace
> > > > la
> > > > figa.
> > >
> > > e dove è scritto che
> nathan=fastwebbaro
> >
> > Nessun altro si chiamerebbe così. Cmq dovresti
> > capirlo dal fatto che caeleste ha chiamato
> > "nathan" e ha risposto fastwebbaro (che è
> > nathan).
>
> ah già, sono proprio un coglione figlio di puttana
Si.