non sarebbe male dedicare un post per ogni errore riscontrato e rispettiva soluzione adottata, nel caso di validazioni delle pagine:
![]()
non sarebbe male dedicare un post per ogni errore riscontrato e rispettiva soluzione adottata, nel caso di validazioni delle pagine:
![]()
Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
Inchinatevi difronte al Prof! Nacchio!
A me pare che l'uomo vada avanti con la retromarcia
character "" not allowed in prolog ??<?xml version="1.0" encoding="UTF-8"?>
mi ha fatto dannare, veniva segnalato all'inizio del codice, nella posizione precedente a col1 riga1 ...cioè praticamente un carattere non esistente in una posizione non esistente![]()
soluzione
nel codice, prima del prologo c'erano degli include che inserivano codice php, probabilmente non salvati in UTF-8 no BOM e soprattutto con un dannato particolare: il codice php incluso era scritto <?php .... ?>{+ riga vuota} e quest'ultima generava l'errore, probabilmente insieme alla non corretta codifica
Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
Inchinatevi difronte al Prof! Nacchio!
A me pare che l'uomo vada avanti con la retromarcia
tag proprietario di IE
per esempio UNSELECTABLE svalida i documenti...quindi? lo abbandoniamo o bisogna passare a JavaScript? so bene che non è standard ma il pensiero che almeno su IE facesse non mi dispiaceva
soluzione
con Javascript c'è onselect="this.blur()" ma è valido solo dentro tag TEXTAREA e/o INPUT
![]()
Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
Inchinatevi difronte al Prof! Nacchio!
A me pare che l'uomo vada avanti con la retromarcia
<A target="_blank" ...>
target si può usare solo con il DTD dei frame
soluzione
<A onclick="this.target='_blank'" ...>
altrimenti sul web si trovano soluzioni più articolate:
codice:Vai a pagina 2 <script type="text/javascript"> <!-- function intercetta() { for (var i=0; i<document.links.length; i++) if (document.links[i].className=="blank") { document.links[i].target="_blank"; } } window.onload = intercetta; //--> </script>
Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
Inchinatevi difronte al Prof! Nacchio!
A me pare che l'uomo vada avanti con la retromarcia
Attribute Minimization Is Forbidden: the name and VI delimiter can be omitted from an attribute specification only if SHORTTAG YES is specified
le singole parole che spesso usiamo come attributi negli elementi dei form non vanno più bene
soluzione
ripeti la parola in questo modo:
compact="compact"
checked="checked"
declare="declare"
readonly="readonly"
disabled="disabled"
selected="selected"
defer="defer"
ismap="ismap"
nohref="nohref"
noshade="noshade"
nowrap="nowrap"
multiple="multiple"
noresize="noresize"
Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
Inchinatevi difronte al Prof! Nacchio!
A me pare che l'uomo vada avanti con la retromarcia
document type does not allow element "input" here; missing one of "ins", "del", "h1", "h2", "h3", "h4", "h5", "h6", "p", "div", "address", "fieldset" start-tag
sembra che i form non accettino i classici elementi dei form come figli diretti, ma vogliano almeno un elemento contenitore...bah a me pare una fesseria...già il form di suo creava degli spazi noiosi da gestire, mettiamoci dentro anche un div e siamo apposto....
soluzionecodice:<form ....> <input ... /> </form>
codice:<form ....> <div> <input ... /> </div> </form>
Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
Inchinatevi difronte al Prof! Nacchio!
A me pare che l'uomo vada avanti con la retromarcia
$_POST restituisce un valore vuoto
non è un errore di validazione, ma un mancato funzionamento che nessuno cita, dovuto a 2 motivi:
- si dice che in XHTML1.1 il "name" scompare e si deve usare "id"
- si diceva che in HTML l'enctype è "text/plain" o "multipart/form-data" nel caso di invio file
soluzione
- si deve continuare ad usare "name" per i form ...insieme al "id"
- le altenative del enctype adesso sono: "application/x-www-form-urlencoded" e "multipart/form-data" come specificato qui
il casino è che la guida del sito parla di "text/plain" per HTML, invece non è standard e non deve essere usato, ed in XHTML1.1 non funziona proprio. In ogni caso il vero dafult è "application/x-www-form-urlencoded", meglio lasciare stare questo parametro, così mette da sè il default
Farmacia di Jarno - le mie pillole: Cookie [#780810], Dom4Php4 [#1123236], Fade [#1139489], getCssProperty [#1152911]
Inchinatevi difronte al Prof! Nacchio!
A me pare che l'uomo vada avanti con la retromarcia
in realtà è sufficiente scrivere i form correttamente usando l'apposito tag fieldset come figlio del tag formOriginariamente inviato da Jarno
document type does not allow element "input" here; missing one of "ins", "del", "h1", "h2", "h3", "h4", "h5", "h6", "p", "div", "address", "fieldset" start-tag![]()
Chicco Ravaglia per sempre con noi!
Esatto. Per approfondire, suggerisco la lettura - nell'ordine - di questi tre bellissimi testi:Originariamente inviato da zoom
in realtà è sufficiente scrivere i form correttamente usando l'apposito tag fieldset come figlio del tag form![]()
- http://www.webstandards.org/learn/tu...orms/beginner/
- http://www.webstandards.org/learn/tu.../intermediate/
- http://www.webstandards.org/learn/tu...orms/advanced/
Leading the Web to Its Full Potential...
www.pierofix.it | www.w3.org | www.zeldman.com/externals | http://browsehappy.com | www.alistapart.com | www.webstandards.org | www.flickr.com/photos/pierofix/
ma se si usa name in Xhtml 1.1 il codice nn è più valido?Originariamente inviato da Jarno
[...]
soluzione
- si deve continuare ad usare "name" per i form ...insieme al "id"
[...]