Pagina 2 di 4 primaprima 1 2 3 4 ultimoultimo
Visualizzazione dei risultati da 11 a 20 su 31

Discussione: CMS standard w3c

  1. #11

    Re: Re: Re: Re: Re: CMS standard w3c

    Originariamente inviato da andr3a
    che io sappia anche qui ...
    http://plone.org/

    solo che poi ... l' unico vero e' XHTML 1.0 Transitional ... non un grande sforzo ...

    CSS errato
    WAI-AA di notte
    508 forse

    any - browser ?

    ... e dire che pylone e' uno di quelli che reputo migliori ...

    se invece con typo crei tutto tu allora il discorso e' divero ( e molto piu' interessante )
    Come ti dicevo con Typo3 di bollini non ce ne sono, ti fai il template come lo vuoi tu e poi lo riempi nel modo che preferisci.
    Puoi farlo anche XHTML strict, perchè il lavoro di "riempimento" dei template è totalmente gestito da te nel minimo dettaglio attraverso typoscript .

    Da quel che so con EzPublish è la stessa cosa
    per favore NIENTE PVT TECNICI da sconosciuti

  2. #12
    Utente di HTML.it
    Registrato dal
    Jun 2001
    Messaggi
    229
    scusate se mi intrometto, ma typo3 da quel che avevo visto (avevo provato una demo sul sito) ha gravi problemi di accessibilità nella parte di amministrazione.

  3. #13
    Originariamente inviato da neoty
    scusate se mi intrometto, ma typo3 da quel che avevo visto (avevo provato una demo sul sito) ha gravi problemi di accessibilità nella parte di amministrazione.
    Cosa intendi con problemi di accessibilità?

    Che è difficile da amministrare o che l'interfaccia non è accessibile in senso stretto (nel senso della legge stanca).

    Nel secondo caso è ovvio che sia così, è tutta in javascript, questo le permette di assomigliare ad una vera GUI.

    Ma stiamo parlando del back-end
    per favore NIENTE PVT TECNICI da sconosciuti

  4. #14
    Originariamente inviato da Fabio Heller
    Ma stiamo parlando del back-end
    la legge Stanca parla anche di quello...
    http://www.webaccessibile.org/argome...to.asp?cat=538


    comunque vorrei chiarire una cosa: i bollini WCAG messi di default su di un CMS non hanno senso in quanto l'accessiblità W3C prevede molti punti che non hanno a che fare col codice

    http://www.w3.org/TR/WAI-WEBCONTENT/
    http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html

    un esempio per tutti: il title dei links serve ad aggiungere informazioni al link con l'intento di chiarire a cosa quel collegamento punta...

    non è possibile accertarsi che i title vengano usati correttamente se non si hanno effettivamente a disposizione i title impiegati...

  5. #15
    Originariamente inviato da andrea.paiola
    la legge Stanca parla anche di quello...
    http://www.webaccessibile.org/argome...to.asp?cat=538
    Calma...

    a parte che la legge stanca è criticabile sotto molti punti di vista, non bisogna fare confusione: un conto è l'interfaccia che usa il programmatore per realizzare il sito e un conto quello che io consegno al cliente (inteso nel suo insieme, ovvero la parte visibile a tutti + la parte di amministrazione *per il cliente*)

    Se io per realizzare il sito voglio usare Dreamweaver nessuno può dirmi nulla, sono fatti miei, è il risultato finale che consegno al cliente che conta. Non gli consegno Dreamweaver.

    Typo3 ha una stupefacente interfaccia di amministrazione/editing che fa uso di javascript, ma questa parte serve a chi realizza il sito come potrebbe servirgli Dreamweaver.
    Ma, se voglio fornire al cliente un interfaccia di amministrazione per i contenuti che gli è consentito modificare, non sono obbligato a fargli utilizzare l'interfaccia nativa di Typo3.
    Certo è possibile, e probabilmente il cliente mi ringrazierà, ma non è un obbligo.
    Posso usare Typo3 per creare al cliente un interfaccia che risponda a tutte le caratteristiche necessarie.

    Quando parliamo di cms avanzati dobbiamo dimenticare PHP-Nuke e affini, stiamo parlando di veri e propri framework.
    Il paragone più azzeccato è proprio quello con Dreamweaver: Typo3 è una sorta di Dreamweaver (un po' più complicato) con motore PHP.
    per favore NIENTE PVT TECNICI da sconosciuti

  6. #16
    Originariamente inviato da Fabio Heller
    Calma...

    a parte che la legge stanca è criticabile sotto molti punti di vista, non bisogna fare confusione: un conto è l'interfaccia che usa il programmatore per realizzare il sito e un conto quello che io consegno al cliente (inteso nel suo insieme, ovvero la parte visibile a tutti + la parte di amministrazione *per il cliente*)

    Se io per realizzare il sito voglio usare Dreamweaver nessuno può dirmi nulla, sono fatti miei, è il risultato finale che consegno al cliente che conta. Non gli consegno Dreamweaver.

    Typo3 ha una stupefacente interfaccia di amministrazione/editing che fa uso di javascript, ma questa parte serve a chi realizza il sito come potrebbe servirgli Dreamweaver.
    Ma, se voglio fornire al cliente un interfaccia di amministrazione per i contenuti che gli è consentito modificare, non sono obbligato a fargli utilizzare l'interfaccia nativa di Typo3.
    Certo è possibile, e probabilmente il cliente mi ringrazierà, ma non è un obbligo.
    Posso usare Typo3 per creare al cliente un interfaccia che risponda a tutte le caratteristiche necessarie.

    Quando parliamo di cms avanzati dobbiamo dimenticare PHP-Nuke e affini, stiamo parlando di veri e propri framework.
    Il paragone più azzeccato è proprio quello con Dreamweaver: Typo3 è una sorta di Dreamweaver (un po' più complicato) con motore PHP.
    la confusione l'hai fatta tu e gli altri...perchè non sono stato chiaro io!
    parlo di backend di CMS (Content Management System) da non confondere coi framework... Dreamweaver poi... non è neanche un framework, ma un programma a sè...
    certo i framework sono tutta un'altra cosa dai CMS eh... e questo è uno degli aspetti che li differenzia: nel framework puoi decidere come a livello di codice pubblicarli... coi CMS no!
    Typo3 penso sia un framework...oppure no? [edit]bò lo "vendono" come CMS ma da come ne parli tu sembra un CMS che si appoggia ad un framework...bò magari non ho capito niente...
    comunque sembra molto interessante appena ho un po' di tempo me lo guardo con attenzione...[/edit]

  7. #17
    Originariamente inviato da andrea.paiola
    la confusione l'hai fatta tu e gli altri...perchè non sono stato chiaro io!
    parlo di backend di CMS (Content Management System) da non confondere coi framework... Dreamweaver poi... non è neanche un framework, ma un programma a sè...
    certo i framework sono tutta un'altra cosa dai CMS eh... e questo è uno degli aspetti che li differenzia: nel framework puoi decidere anche quali contenuti e come a livello di codice pubblicarli... coi CMS no!
    Typo3 penso sia un framework...
    Non intendevo dire che stavi facendo confusione, ma che considerando quanto dice la legge non bisogna confondere il back-end del cms con l'interfaccia di amministrazione che io fornisco al cliente.
    Se, come nella maggior parte dei CMS, coincidono allora dobbiamo porci il problema della piena compatibilità del CMS.
    per favore NIENTE PVT TECNICI da sconosciuti

  8. #18
    Originariamente inviato da andrea.paiola
    comunque vorrei chiarire una cosa: i bollini WCAG messi di default su di un CMS non hanno senso in quanto l'accessiblità W3C prevede molti punti che non hanno a che fare col codice

    http://www.w3.org/TR/WAI-WEBCONTENT/
    http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html

    un esempio per tutti: il title dei links serve ad aggiungere informazioni al link con l'intento di chiarire a cosa quel collegamento punta...
    a cosa punta un link ??? ... ad un link ... a che vuoi che punti ?
    cosa vuoi mettere nel title se non "visita questa pagina" o "visita la pagina xxx" ???

    e' un link, gia' il title serve poco a niente , sarebbe molto piu' sensato mettere la descrizione del link come testo linkabile e il link sul title per come la vedo io ... al fine di descrivere testualmente il link e indicare dove l' utente verra' reindirizzato sul title ... non e' che se fai i links a mano , uno per uno, e' meglio ..

    Questo per dire che e' vero che i bollini non possono essere messi a caso, ma e' anche vero che per come la vedi tu e' impossibile rispettare la legge Stanca in un contesto dinamico , e chi e' quel FOLLE che per ogni modifica o aggiornamento da fare al sito del comune , pieno zeppo di roba, si mette a riaggiornare a mano tutte le pagine ???

    non ha senso , perche' se avrebbe senso, mi autodecurterei dalle tasse i soldi per pagare quel / quei c*gli*ni che devono aggiornare tutti i giorni a mano un solo sito !!!

    per assurdo farei causa al comune stesso ... stiamo scherzando ?

    va pensata e fatta bene, no che un CMS non puo' avere bollini, li puo' avere e come.

    E il WCAG 1.0, per altro "vecchio", ha anche lui troppe controversie interne ... vedi le immagini e l' attributo longdesc che non ti permette di usarlo per quello che e' , una descrizione lunga ed ha problemi di compatibilita' ... aspetto fiducioso il WCAG 1.1 sperando che quelli del W3 oltre a predicare razzolino altrettanto ... non come ora che loro stessi non sono in grado di fare una pagina XHTML 1.1 e se usano 1.0 usano il transitional o anche HTML 4.01 , sempre transitional, perche' loro stessi non riescono ad automatizzarsi in modo conforme ...




    Originariamente inviato da andrea.paiola
    non è possibile accertarsi che i title vengano usati correttamente se non si hanno effettivamente a disposizione i title impiegati...
    e chissenefrega , un title e' una decorazione testuale per un link, nuente di piu' ... fossero questi i problemi di accessibilita' ...
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  9. #19
    Utente di HTML.it
    Registrato dal
    Jun 2001
    Messaggi
    229
    Cosa intendi con problemi di accessibilità?

    Che è difficile da amministrare o che l'interfaccia non è accessibile in senso stretto (nel senso della legge stanca).

    Nel secondo caso è ovvio che sia così, è tutta in javascript, questo le permette di assomigliare ad una vera GUI.
    Intendevo il secondo caso. Poi penso anche io che il sito che dai al cliente è un'altra cosa. Cioè, l'importante è il risultato finale. E da quanto ho visto typo ti permette massima libertà di progettazione. Questo è fantastico.

    Ma stiamo parlando del back-end
    Bhè anche un programmatore potrebbe beneficiare di accorgimenti volti a migliorare l'accessibilità.

    ---------------------

    Ho scaricato stamattina l'ultima versione di typo poichè vorrei imparare ad usarlo, mi sembra molto interessante. Alcuni lo hanno confrontato addirittura con Zope.

    Ora magari dirò una cavolata, ma sarebbe interessante cambiare l'interfaccia di amministrazione facendo più attenzione all'accessibilità. Ma ripeto, penso di aver detto una cavolata perchè attualmente non conosco typo. Però ho visto un CMS che per scelta crea codice xhtml strict già nella parte di amministrazione (pxsystem.sourceforge.net). Con questo non voglio comparare typo ad un normale cms, ma potrebbe essere uno spunto per future versioni di typo. Ad esempio per quanto riguarda la comunità Mambo è nato un progetto che si chiama xMambo, che appunto è molto attento a creare codice pulito e standard anche nella parte di amministrazione. Da quanto ne sapevo però li hanno avuto però il risultato di avere due mambo su due binari paralleli, il che non è molto produttivo.

  10. #20
    in area di amministrazione non e' difficile implementare wcag, molto piu' difficile farlo nella parte utente ... solo che, l' area di amministrazione, al 99% utilizza, giustissimamente, JavaScript in modo piu' o meno massiccio , per facilitare l' utente amministratore nella gestione , manutenzione , dei contenuti e/o funzioni del sito .

    Cosa c'e' di strano ?
    C'e' che JavaScript non e' conforme al 100% con il WCAG 1.0 ... altra zappa sui piedi .... tornando al W3 , nemmeno loro fanno pagine dinamiche WCAG 1.0 ... il che e' tutto un dire .


    La pagina di amministrazione che sto' progettando e' al limite del WCAG, proprio perche' usa JS per molte funzioni, tra cui tanti controlli ... ovvio che ci sono anche lato server , ma perche' sprecare tante risore invece di sfruttare JS al fine di non perdere tempo e amministrare in modo semplice ?

    poi non confondiamo codice pulito con accessibilita' ... sono correlati tra loro ma non sono la stessa cosa , xMambo magari fa un output pulito ma non rispetta il WCAG 1.0 ... ed e' MOLTO DIFFICILE rispettarlo quando il CMS ha tanto da offrire, io ci sono riuscito con opzioni veramente basilari, sezioni, contenuti per sezione , immagini , files , tipi di contenuti / paragrafi , form contatti e poco altro ... avessi dovuto affrontare moduli , sotto gerarchie , inserimenti stile HTML Area da validare ci avrei perso minimo 1 mese solo per una form di contenuti ...
    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 © 2026 vBulletin Solutions, Inc. All rights reserved.