Visualizzazione dei risultati da 1 a 8 su 8
  1. #1

    paradosso del noscript - consigli / soluzioni

    Ho già cercato e notato che altri hanno avuto la "brillante" idea di mettere un tag noscript all'interno del tag head.

    Come da specifiche un tag noscript non può stare dentro l'head della pagina, mentre il tag script si, ed allo stesso tempo un tag noscript non può contenere elementi dell'head della pagina, intesi come link o style.

    Questa logica mi sfugge, come sfugge ad una miriade di altre persone, al punto che il nuovo Xhtml 2.0 prevede l'utilizzo di un tag handler capace di gestire anche questa necessità:
    dare un'alternativa per i browsers che non supportano JavaScript.

    Ora, a prescindere dall'utilità della cosa, a mio avviso evidente in questo Web che tende sempre più ad arricchire con interfacce interamente strutturate tramite JS (Interface, Ext, YUI!, Dojo), qualcuno è riuscito a risolvere il problema, sa se magari il validatore automatico sbaglia (capita eh ... non è mica perfetto ...) oppure sa se i gruppi di accessibilità considerano a prescindere un markup invalidato da un noscript in head non conforme con la Stanca o altro ancora?

    No perchè io non ho capito perchè chi ha JS dovrebbe scaricarsi un CSS apposito per chi non ce l'ha e/o vice versa ... come non ho capito perchè questa scelta del noscript che impedisce di andare in contro proprio gli utenti eliminando ad esempio file superflui ed ottimizzando il layout ... cosa attualmente apparentemente infattibile se non con un markup invalidato

    [edit] ricordo inoltre che tutti i browsers de facto supportano il tag noscript all'interno dell'head

    Grazie a tutti per l'eventuale risposta, chiarificazione o consiglio e buona giornata.
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  2. #2

  3. #3
    mentre chiedevo informazioni altrove, perdendo tempo a scrivere nel mio blog, mi è venuta in mente una soluzione al problema, tanto semplice quanto "macchinosa".

    Ovviamente è necessario avere un linguaggio server-side, in questo caso PHP per mostrare un esempio.


    Il tag head non accetta il noscript ma accetta JavaScript.

    Questo significa che basta semplicemente includere una risorsa esterna che punta non ad un vero file JavaScript ma ad una pagina server:
    codice:
    <head>
    <script type="text/javascript" src="cssFilter.php"></script>
    <link rel="stylesheet" media="all" href="myPage.php" />
    </head>
    L'ordine è fondamentale per la riuscita della mia soluzione poichè se non è stata verificata la possibilità del browser di interpretare codice JavaScript non può funzionare alcunchè.

    cssFilter.php
    codice:
    <?php
    session_start();
    $_SESSION['JavaScript'] = true;
    header('Content-Type: text/javascript');
    exit('this;');
    ?>
    a questo punto l'utente avrà un cookie o un SID (Session ID) automaticamente appeso ad ogni richiesta, non resta che sfruttare questa informazione nell'altro elemento, il link dello stile

    myPage.php
    codice:
    <?php
    session_start();
    $output = file_get_contents(
    	isset($_SESSION['JavaScript']) && $_SESSION['JavaScript'] === true ?
    		'scriptEnabled.css':
    		'scriptDisabled.css'
    );
    header('Content-Type: text/css');
    header('Content-Length: '.strlen($output));
    $_SESSION['JavaScript'] = false;
    exit($output);
    ?>
    Per concludere, sfruttando un ob_handler è possibile diminuire le dimensioni del download sfruttando, se possibile, la compressione gz, inserendo solo questo prima dell'avvio di sessione:
    codice:
    ob_start('ob_gzhandler');
    Come vi sembra come soluzione? Non riesco a trovare lati negativi, se non l'utilizzo obbligato di una sessione a prescindere dal tipo di sito.


    P.S. chiedo scusa ai mod se sono andato fuori tema, la soluzione è PHP ma potrebbe tornare utile, come concetti, per qualunque altro linguaggio server. Se lo ritenete necessario spostate pure il tutto dove lo ritenete più utile, grazie

    [edit]
    demo page: http://www.3site.eu/examples/css4js/
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  4. #4
    ... up ...
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  5. #5
    Amministratore L'avatar di Vincent.Zeno
    Registrato dal
    May 2003
    residenza
    Emilia-Romagna (tortellini und cappelletti land!)
    Messaggi
    20,783

    riflessione...

    Secondo W3C ( http://www.w3schools.com/tags/tag_noscript.asp )
    il tag noscript serve SOLO per contenere "testo alternativo " allo script, quindi se ne intuisce una funzione di "avviso ".
    Con questo preambolo è ovvio che, il noscipt, deve trovarsi nella posizione il cui script non può agire. Ecco che qui la tua domanda prende maggior enfasi : "Se in HEAD ho uno script fondamentale per la navigazione, come posso dare un'alternativa?"

    Sebbene la questione da te esposta (ad esempio inviare l'utente su un CSS differente) sia argomento davvero valido, pare non ci sia soluzione; a parte l'interessante esempio da te proposto, purtroppo macchinoso. Se poi la cosa si riesce a semplificare... meglio!
    Anzi: avvisaci!

    La legge Stanca sappiamo che parla della reale accessibilità, e non di cosa si scrive nel codice.
    Non parlo per esperienza diretta... ma credo che se una cosa funziona ma non è validata, all'utente non importi molto. Quello che conta, per certi utenti , è poter usare lo strumento.

    Del resto "Accessibile" e "Validato" non sono proprio la stessa cosa.
    Rimane "aperta" la questione di dare un riferimento univoco al browser per l'interpretazione del codice.

    La mia è solo una riflessione: NON è un invito a non validare !

  6. #6

    Re: riflessione...

    Originariamente inviato da Vincent.Zeno
    è ovvio che, il noscipt, deve trovarsi nella posizione il cui script non può agire.
    la cosa "divertente" è che il W3 consiglia di mettere script nell'head, come stili o altro ... molto più puliti, a mio avviso, di script in chiaro nel body.

    Non si capisce, secondo me, perchè il noscript che è alternativa allo script, non possa stare negli stessi posti dove invece lo script può stare, come non è chiaro perchè il noscript sia, secondo specifiche e non realmente, limitato ... non potendo includere intere risorse dedicate, piuttosto che un banale alt da script ... (infatti anche l'alt è stato criticato molto poichè poco utile nella sua attuale implementazione)


    Originariamente inviato da Vincent.Zeno
    Ecco che qui la tua domanda prende maggior enfasi : "Se in HEAD ho uno script fondamentale per la navigazione, come posso dare un'alternativa?"
    esatto ... ma la domanda secondo me è:
    esiste uno script inutile?
    voglio dire ... se c'è è utile o comunque utilizzato ... secondo quale criterio nell'head dovrebbe essere meno utile che nel body? (riferito al noscript che nel body è ok, nell'head a seguire di uno script no)

    Ci sta che dovendo forzatamente contenere, da specifica, solo testo alternativo ... l'head non può essere un posto adatto per farlo.

    Il paradosso è proprio questo, il noscript, secondo specifiche, non è utilizzabile per migliorare la navigazione degli utenti con o senza JavaScript abilitato ... bella mossa!!!


    Questa è solo una riflessione alla tua riflessione per la quale ti ringrazio
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  7. #7
    Amministratore L'avatar di Vincent.Zeno
    Registrato dal
    May 2003
    residenza
    Emilia-Romagna (tortellini und cappelletti land!)
    Messaggi
    20,783

    Re: Re: riflessione...

    Originariamente inviato da andr3a
    Il paradosso è proprio questo, il noscript, secondo specifiche, non è utilizzabile per migliorare la navigazione degli utenti con o senza JavaScript abilitato ... bella mossa !!!
    Si... oggi possiamo dire bella mossa ...
    ma, evidentemente (al tempo che fu), non pensavano che uno script non avrebbe potuto contenere elementi fondamentali .
    Difatti, il concetto di accessibilità, è nato "più tardi".
    Quindi... attacchiamoci e vediamo gli sviluppi.

    Originariamente inviato da andr3a
    Questa è solo una riflessione alla tua riflessione per la quale ti ringrazio
    ... e continuiamo pure a rifletterci l'un l'altro

  8. #8
    grazie a Mike della libreria JavaScript Ajile siamo arrivati ad una soluzione totalmente client, non basata quindi su sessioni o altro.

    La soluzione sfrutta la rottura del normale flow del documento ... si crea un errore nel layout per ignorare il tag successivo.

    Il succo del discorso è che bisogna usare document.write, specificando prima il link o style che si vuole mostrare per poi aggiungere questo:
    codice:
    document.write('<link hide="');
    Per qualche ragione ogni browser sembra essere compatibie con questo metodo, anche i più datati IE4 e Netscape Navigator.

    Questi sono le nuove pagine di esempio:
    XHTML 1.0 Strict
    HTML 4.01
    quirks mode (non validabile)

    Come ho scritto nei commenti, non sono del tutto soddisfatto di questa soluzione, soprattutto perchè non è compatibile con i nuovi standards.

    Allo stesso tempo va detto che questi avranno la possibilità di sfruttare nuovi tag (handler) capaci di gestire il problema, ergo .... finchè non saranno definitivi e/o supportati, abbiamo almeno una soluzione client a questo problema client.

    Come si è arrivati alla soluzione, se interessati, sta scritto tra i commenti del post nel mio blog :-)

    Buona giornata a tutti
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.