Skip to topic | Skip to bottom
Home

TechWeb08
TechWeb08.TagSpecialir1.32 - 21 May 2008 - 16:52 - ValeriaBaldellitopic end

Start of topic | Skip to actions

Tag Speciali: convenzioni ed uso

Direi di iniziare a discutere quali tag speciali usare in modo da implementare il Data Formatter con gi i tag inseriti. Da una discussione precedente sono stati proposti i seguenti Tag:

Discussioni sui singoli elementi

Navigazione

Un elemento che contenga sostanzialmente un insieme di link.

Ricerca completa

Il form di ricerca completo.

Ricerca veloce

Il form di ricerca ridotto, per esempio per poterlo "embeddare" (argh!) in ogni pagina.

Extra

Un elemento con contenuto libero.

Cambio di layout

Blocco dedicato ai comandi per il cambio di layout e skin.

Logo

Logo del sito.

Contenuto

Dice al formatter di mettere il testo nel blocco riservato al contenuto. Utile, in una giungla di tag speciali. Inoltre non tutti i layout metono il contenuto nello stesso posto.

Header

Intestazione della pagina. C' chi la mette in alto a sinistra, chi in alto a destra, chi in alto a tutta pagina, chi di fianco perch cinese.

Secondo me se l'AC specifica questo elemento fa una decisione presentazionale che e' di sola competenza del formatter. Mi spiego: nei concetti di "intestazione" e "pie' di pagina" sono intrinseche le informazioni "sta in alto" e "sta in basso". Se creare un elemento "header" o "footer" dovrebbe essere compentenza del formatter, che decide quali elementi speciali mettere in queste aree.

Esempio di richiesta di formattazione che ritengo sbagliata:

...
<div class="special-block" name="footer">
   <p>Note di compatibilita' dei browser: bla bla bla IE cacca bla bla bla</p>
   <p>Autori: bla bla bla bla</p>
</div>
...

Come lo farei:

<div class="special-block" name="page-notes">
   <p>Note di compatibilita' dei browser: bla bla bla IE cacca bla bla bla</p>
   <p>Autori: bla bla bla bla</p>
</div>

Nel secondo caso il formatter sa qual'e' il contenuto dell'elemento speciale (sono note riguardo alla pagina) e puo' decidere di farne cio' che vuole: metterlo in un footer, in un header, in un box a lato, etc. etc. etc.

Se invece dico "footer" il formatter sa solo che "questa roba deve metterla in basso", ovvero gli do un ordine su questione che sarebbero di sua competenza. Di piu' nella discussione generale in fondo alla pagina.
-- GiacomoRitucci - 16 May 2008

Footer

Pi di pagina. C' chi la mette in basso a sinistra, chi in basso a destra, chi in basso a tutta pagina, chi di fianco perch cinese.

Idem come header.
-- GiacomoRitucci - 16 May 2008

Menu

Menu di navigazione

Io avevo proposto l'elemento "Navigazione" proprio come "menu di navigazione", quindi questo sarebbe un duplicato.
-- GiacomoRitucci - 16 May 2008

Discussione generale

Io proporrei, come gia stato fatto notare in una discussione precedente, di non considerarli tag bens attributi. L'ideale sarebbe inserirli all'interno dei vari tag come id, ad esempio:

<div id="attributo-speciale"> ... </div>

In questo modo possibile utilizzare gli attributi speciali in modo indipendente dal tag. Per identificare univocamente ogni tag direi di assegnare una numerazione progressiva e "non soggetta a troppi errori di scrittura" all'attributo usato, ad esempio.

<div id="attributo-speciale_att001"> ... </div>
<div id="attributo-speciale_att002"> ... </div>
<div id="attributo-speciale_att003"> ... </div>

O qualcosa di simile...

E ora avanti con idee e proposte...

Che tipi di blocchi speciali inserire

Credo sia importantissimo che i nomi dei blocchi speciali specifichino il tipo di contenuto, non la posizione del contenuto, perche' quest'ultima e' competenza del formatter.

Immaginiamo un formatter come un magazziniere. E' come se passassimo al formatter delle scatole chiuse con sopra scritto: "marmellata", "miele", "frutta secca", "legumi", etc. Ogni formatter in base al contenuto dichiarato dall'etichetta decide dove mettere il contenuto della scatola: il mio formatter puo' mettere il miele nello scaffale in alto, un altro lo mette in cantina, un altro ancora lo butta direttamente nel rusco, etc.

Per questo sono contrario a blocchi come contenuto, header e footer: e' come passare al formatter una scatola con l'etichetta "va in cantina". Un formatter scontroso potrebbe dire "dimmi ben che roba e', che decido io dove va".

(scusate l'esempio ma questo m'e' venuto in mente)

Oppure i blocchi "header", "footer" e "contenuto" rispondono a esigenze che non sono soddisfacibili in altro modo?

-- GiacomoRitucci - 16 May 2008

Secondo me invece i blocchi "header", "footer" e "contenuto" appartengono alla categoria "dimmi che roba ", nel senso che non si sta facendo formattazione ma si sta semplicemente indicando il tipo del blocco. Ad esempio che l'header debba stare in alto solo una convenzione.. magari in Cina o in Giappone l'header sta in basso!!!

-- IntelMax- 17 May 2008

Il problema resta perche' se per esempio in Cina o in Giappone "header" vuol dire "questa roba mettila a destra", e' comunque e' una decisione posizionale che spetta al formatter.

Noi dovremmo dire "queste sono delle note", "questo e' l'autore", "questo e' il titolo", etc. Sta poi al formatter decidere che, per esempio, autore e titolo vanno in un header e le note in un footer; in particolare un formatter cinese mette l'header come sono abituati in cina, etc.

Inserire questi elementi spezza la distinzione "contenuto / disposizione" che c'e' tra AC e DF: l'AC deve conoscere solo il contenuto, il formatter deve disporlo. Questa separazione di responsabilita' e' importante e la "romperei" solo se strettamente necessario.

-- GiacomoRitucci - 17 May 2008

Io concordo con Giacomo riguardo il fatto di non poter indicare nomi come "header" e "footer", in quanto hanno intrinsicamente un significato presentazionale. Proporrei di indicarli rispettivamente con nomi tipo "titolo" e "note-pagina".

Come votato all'ultimo WG queste parti "speciali" di ogni pagina saranno identificate da DIV, che, se non ho capito male, dovranno essere caratterizzati da un id riservato e noto a tutti i gruppi (serve un accordo per far dialogare AL e DF di gruppi differenti).

Vi propongo alcuni nomi, giusto per avere una base comune. (e' un'idea di massima, fatemi sapere se qualcosa non vi va bene)

  • Contenuto. Identificato dall' id reserved_contenuto. Contiene il contenuto della pagina (sostanzialmente codice XHTML).
  • Titolo. Identificato dall'id reserved_titolo. Contiene il testo che deve essere visualizzato come titolo.
  • Menu di naviagione. Identificato dall'id reserved_menu_navigazione. Contiene una lista (UL) di link alle pagine speciali (esempio: ricerca, creazione nuova pagina, aggiunta di un commento pagina attuale,... ciascun gruppo e' poi libero di introdurre quelle che ritiene opportune).
  • Scelta layout/skin. Identificato dall'id reserved_layout_skin. Contiene le informazioni alle coppie layout/skin disponibili. Dovremmo accordarci sul contenuto.
  • Ricerca Rapida. Identificato dall'id reserved_ricerca_rapida. Consente di fare ricerche direttamente dalla pagina attuale, senza dover richiamare (mediante il Menu di navigazione), la pagina speciale associata alle ricerche.
  • Extra. Identificato dall'id reserved_extra. Utilizzato a discrezione del gruppo. (ad esempio, potrebbe contenere una lista di ricerche correlate. Dipende dall'AL).
  • Note_pagina. Identificato dall'id reserved_note_pagina.
  • Logo. Identificato dall'id reserved_logo.

Non indicherei un elemento ricerca completa, in quanto immagino ci sia una pagina speciale a questo scopo.

Usare dei div con id riservati e noti a tutti consente ad ogni formatter di posizionare queste parti della pagina . Tuttavia, per poter lavorare a livello di contenuto di questi div speciali, dovremmo anche accordarci su cosa contengono. Ad esempio per Menu di navigazione, sapere che il contenuto del div associato e' una lista non ordinata, consentira' al formatter di decidere se proporre i vari link come lista di link piuttosto che come menu a tendina (e' solo per fare un esempio). Credo (ma potrei sbagliarmi) che se non c'e' questo accordo, il lavoro del formatter si limiterebbe a posizionare queste parti della pagina, e a gestire la skin (mediante un css per il codice XHTML presente).

-- CristianArmentano - 17 May 2008

Ciao, perdonatemi se sono sempre in disaccordo, ma se gi dite che "header", "footer", ecc... non vanno bene perch hanno un significato intrinseco presentazionale, mettersi d'accrodo che il men debba essere una lista non ordinata non forse attribuire formattazione (e stavolta non intrinseco)? Tornando all'esempio del men, io sono del parere che ogni formatter possa gestirsi a suo piacimento la presentazione del men, formattando gli elementi che conosce all'interno del div.

-- IntelMax- 17 May 2008

Tutti gli elementi XHTML che usiamo sono strutturali e non presentazionali, ul e' strutturale, b e i sono presentazionali e non li usiamo. ul non dice che i li vanno sopra all'altro, dice semplicemente che il contenuto e' strutturato in vari elementi li. Occhio a non confondere il significato del tag con il rendering di default che viene effettuato dal browser.

Questi div che identificano i blocchi speciali, proprio in quanto div xhtml, non possono avere un content-model specificato da noi, quindi il contenuto e' essenzialmente libero e i formatter devono farsi furbi e aspettarsi di_tutto.

-- GiacomoRitucci - 17 May 2008

Allora, per quanto la mia proposta di indicare il contenuto del menu' come una lista, era solo per indicare in qualche modo il "susseguirsi" di voci. In questo modo il formatter sa cosa aspettarsi e puo' attribuire un aspetto presentazionale anche molto diverso dalla lista data in ingresso. Il punto e' che, a mio parere, se il formatter non sa cosa c'e' nei vari div speciali, l'unica cosa che puo' riuscire a fare e' posizionarli, e formattare gli elementi XHTML all'interno degli stessi. Se il contenuto di questi div e' completamente arbitrario, a mio modo di vedere il formatter non puo' intervenire piu' di tanto (e questo e' il motivo principale per cui al WG avevo votato per usare elementi appositi della grammatica, con un content model ben preciso, piuttosto che dei div; anche se poi la richiesta NON e' passata). Riprendiamo l'esempio del menu'; se il formatter sa che dall'AL ricevera', ad esempio, un div con id= reserved_menu_navigazione contente una lista formata da riferimenti a pagine speciali, potra' sbizzarrirsi: potrebbe fare una formattazione semplice, riproponendo semplicemente un elenco di riferimenti, oppure un menu' a tendina, oppure posizionare le voci orizzontalmente sopra al contenuto della pagina. Se invece il contenuto di questi div "speciali" e' completamente arbitrario, potra' solo dare il proprio significato presentazionale al XHTML contenuto in essi (mi sembra cosi' di dare "troppa responsabilita' all' AL" la quale genera il codice XHTML contenuto in questi div speciali, ma forse e' solo una mia impressione).

Spero di avere chiarito la mia proposta di fissare alcuni di questi content model. Tuttavia gia' al WG quando avevo provato a muovere questa obiezione ho visto che molti erano perplessi, dunque se non vi va bene non c'e' nessun problema, teniamoli pure tutti completamente arbitrari. Volevo solo recuperare alcuni pareri a rigaurdo.

-- CristianArmentano - 17 May 2008

Sono pienamente d'accordo con Cristian, D'altronde ho gi fatto la stessa proposta in "Proposte per la sessione di marted 13/05/08".

-- DavideCandita - 18 May 2008

Concordo in pieno! Sapere gi cosa ci si pu aspettare senz'altro meglio che andare alla cieca e tentare di indovinare...

-- StefanoFranzoso - 18 May 2008

Noi abbiamo avuto modo di parlare con Di Iorio e ci ha consigliato di evitare tag come footer ed header proprio per i motivi gia esposti, essi indicano una posizione precisa nella pagina che deve essere decisa dal data formatter. Mi associo inoltre anche io a Cristian, i tag speciali non possono essere arbitrari in quanto significherebbe complicare a dismisura il data formatter col rischio di dimenticarsi dei casi... Se siete tutti d'accordo, rendiamo ufficiale l'adozione dei tags indicati da Cristian...

-- RiccardoVolante2 - 19 May 2008

Non sono d'accordo solo su "contenuto", c'e' gia' body (oppure non ho capito cosa "contenuto" faccia di piu' rispetto a body).

Se vogliamo imporre un content model ai blocchi speciali, bisogna proporre di definire i blocchi speciali come tag a parte e non come div con attributi riservati, e questo va fatto in sede di proposte per il wg di domani. Visto che l'idea mi piace, raccolgo le idee e propongo a brevissimo (siamo gia' fuori le 24 ore di distanza speriamo il chair sia magnanimo).

-- GiacomoRitucci - 19 May 2008

Per rispondere a Giacomo, sappi che la mia idea iniziale era proprio quella di usare elementi e non dei div generici con id riservati, proprio per fissare univocamente il content model almeno di alcuni di essi (fra cui certamente avrei messo menu e box di scelta per layout e skin... mi stava poi bene che ad esempio 'extra' potesse avere content model generico XHTML). Avevo infatti votato in questo modo durante il WG (mi sembra di essere stato l'unico, o al massimo eravamo in 2). Sta di fatto pero' che l'opzione di usare div e' stata preferita dalla maggioranza.

Nonostante cio', ho fatto il mio intervento solo per sentire i pareri degli altri gruppi riguardo questo punto. Ma io sono il primo a non essere entusiasta di fissare "sotto banco" il contenuto di elementi div di XHTML!

Direi anch'io comunque che a questo punto e' opportuno parlarne al WG di domani.

-- CristianArmentano - 19 May 2008

Si, mi ricordo che me ne avevi parlato smile

Mi ero sbagliato, il wg e' dopodomani quindi c'e' tempo di mostrare e discutere la proposta.

Spero di aver interpretato bene, in caso di problemi, modificate, discutete e correggete pure.

-- GiacomoRitucci - 19 May 2008

Stando a quanto ci ha detto Vitali, il discorso tag/attributi speciali non una discussione di cui il WG pu parlare, nel senso che non rientra nei suoi argomenti. Per questo stata inserita a parte. L'idea di usare tag div con id speciali deriva dal fatto che la pagina finale deve contenere tag XHTML puri e non un misto tra tag reali e tag speciali da noi decisi, senza contare che la loro traduzione in relativi tag XHTML complicherebbe non poco le cose.

-- RiccardoVolante2 - 19 May 2008
to top


Copyright © Fabio Vitali 2022 Last update of TagSpeciali on 21 May 2008 - 16:52 by ValeriaBaldelli