Loģisks un strukturāls (X)HTML
Sākumā vienosimies, ka mēs abstrahējamies no pārlūku savietojamības problēmām.
Šeit es Jums (tiem, kurus interesē) paprovēšu parādīt, ko es teorētiski domāju par nepelnīti piemirstajām (X)HTML bagātībām - sarakstiem (piem., ul un li)
Mani nebeidz mākt viena doma. Es naktīs murgoju (gadās:) par to. Iedomāsimies, ka mums ir ieraksts, kuram ir jāpievieno klāt kaut kādā veidā divi parametri - datums, autors un komentāru skaits. Lielākoties cilvēki ko tādu veido šādi:
<p class="entrydescr">
<span class="date">2002. gada 15. janvārī</span>
<span class="author">Vārds Uzvārds</span>
<span class="comments">6 komentāri</span>
</p>
Ir skaidrs, ka tādējādi tiek grupēti kopā vienādas loģiskās nozīmes lauki. Bet vai tad tam nav domāti saraksti? Jo kas tad tas ir, ja ne saraksts? Tad kālab lai mēs neizmantotu ul un li elementus, lai to visu arī semantiski padarītu par sarakstu?
<ul class="entrydescr">
<li class="date">2002. gada 15. janvārī</li>
<li class="author">Vārds Uzvārds</li>
<li class="comments">6 komentāri</li>
</ul>
Sekojošais kods katram ul.entrydescr saraksta elementam labajā pusē piekārto 1em lielu atkāpi un padarot šos elementus par inline, novieto tos vienu otram blakus:
ul.entrydescr li {
display: inline;
margin-left: 1em;
}
Es labprātāk būtu margin-left: 1em novietojis atsevišķā selektorā:
div.entry ul.entrydescr li {
display: inline;
}
div.entry ul.entrydescr li+li {
margin-right: 1em;
}
Kāpēc? Tīrības mīlestības dēļ :) Pirmajā variantā katram li elementam kreisajā pusē pieliekas klāt 1em liela atstarpe. Taču, loģiski, ka pēdējam elementam man šo atstarpi vairs nevajag, ne? Tāpēc, es labprātāk pielieku labajā pusē 1em lielu atkāpi katram li elementam, pirms kura ir li elements.
Aizmirstam par sākumā aizmirsto. IE nesaprot...
Kā jau viegli nojaust, li+li selektors nevar tikt izmantots, ja ir vēlme Firebird identisku izskatu iegūt arīdzan Internet Explorer pārlūkā. Jā, kārtējo reizi IE mums piedāvā savu jauko spēju nesaprast to, kas tik labi noderētu.
Attiecīgi, zināmas grūtības (bet ar pāris viltībām arī tās var apiet!) rada, piem., horizontālu svītriņu ieviešana starp šī saraksta elementiem, bet ne pirmā elementa kreisajā un pēdējā elementa labajā pusē. Bet kas tad ir kvalitatīva, loģiska, strukturēta, arī koda līmenī pievilcīga weba veidošana, ja ne zināmu un ne tik ļoti grūtību pārvarēšana?
2004. gada 27. janvārī, plkst. 16:20
jautājums, kas kuram saraksts. es šo sauktu par tabulu :))) bet nu jā, principā jau taisnību Tu saki.
2004. gada 27. janvārī, plkst. 16:22
misame: Kāpēc par tabulu? IMHO tas viennozīmīgi ir //propertiju// saraksts. To, protams, var attēlot tabulārā veidā, ja ir megaluste :)
2004. gada 27. janvārī, plkst. 16:28
Man patīk <p> birkas lietojuma apšaubīšana. Tā tik tiešām nav rindkopa. <table> arī nebūtu nekorekta birka, ja tā labi padomā.
2004. gada 27. janvārī, plkst. 16:29
tas viss ir labi un skaisti tikai... kur ir robeža ? kas ir/nav lists ? ja tu uzskati ka datums, autors un komentāru skaits ir lists tad varbūt uzskatam ka visi bloga ieraksti arī ir lists ? katrā ziņā ar mani neviens izņemot jb4 par to negribēja runāt... http://php.lv/f/index.php?showtopic=623
2004. gada 27. janvārī, plkst. 16:36
CryRat: Loģiski padomājot par konkrēto piemēru manuprāt vienīgā atbilde ir: "saraksts". Tāpēc, ka ideoloģiski:
Ieraksti (posti) ir tādas kā dienasgrāmatas (bloga) saimnieces. Vienības, kurām tiek pakārtoti to apakšpropertiji - norāde uz ieraksta veikšanas / modificēšanas laiku, norāde uz komentāriem, norāde uz ieraksta autoru, etc.
Minētos ieraksta propertijus parasti pozicionē kā vienu īpašību grupu, tātad kā sarakstu, jo tām pakārtots vairs nav nekas (abstrakti domājot, protams;).
Protams, ka lielā mērā ņemot, arī ieraksti ir saraksts un to propertiji ir saraksta elementiem piekārtots saraksts.
Taču, tu taču grāmatas nodaļas un apakšnodaļas neuztver kā nodaļu sarakstu, jo tās tomēr ir pārāk lielas vienības, lai par tādu kļūtu :)
2004. gada 27. janvārī, plkst. 16:39
Jāzeps: Starp citu, es nepiesienos, bet laikam jau sagribējās mazliet pastrīdēties.
Tags (tegs) [Tu lieto vārdu birka] ir <tags>. Noslēdzošais tags ir </tags>.
Svaukārt, ja mēs atsaucamies uz //tags//, tad to jau sauc par elementu "tags". Tas, IMHO, ir loģiskāk.
2004. gada 27. janvārī, plkst. 16:54
strīdēties ir čokāli. jo īpaši, ja pamatoti un ja tas mazina neskaidrības nākotnē.
jā, īsti korekti vēl neesmu iemācījies to lietot. paldies, ka norādi. Cik saprotu, pareizi būtu:
<strong> = birka/tags (atverošā, sākumbirka. ?) </strong> = birka/tags (aizverošā, noslēdzošā,?) <strong>saturs</strong> = elements ( ar domu: XML dokumenta struktūrelements) un vēl, kā saukt "<" un ">" ?
2004. gada 27. janvārī, plkst. 16:55
Moš semantiku HTMLā tikļoti nevajag meklēt, jo var neatrast?
dajebkāds XML + CSS drīz nebūs? Manliekas, ka w3c rekomendācijās jau ir. IE arī kaitko atbalsta as XSLT piemaucot HTMLu.
2004. gada 27. janvārī, plkst. 16:58
Smejmoon, ir jau labu laiku. Pārlūki(Opera) un developeri bremzē.
2004. gada 27. janvārī, plkst. 17:18
laacz: yeah... nu ir jau tev taisnība... bet tomēr tā robeža man ne vienmēr ir skaidri redzama...
Smejmoon: tas ir vēl viens jautājums par kuru ar mani neviens negribēja runāt (http://php.lv/f/index.php?showtopic=647)... bet cik tas drīz būs gan nezinu ja paskatās ka Opera tādu XSL vispār neņem vērā un ka Data Islands ( tjipa XML iekļaušana (X)HTMLā ) iekš Mozilla nestrādā tad... nu nezinu... bet tā jau tas XML + XSLT mani stipri interesē...
2004. gada 27. janvārī, plkst. 18:19
Nu Tavi jautājumi tur ir offtopiks. Mož Jāzeps un vēl 3 zēni par to domā, ja domā, tad nesaka. :(
HTMLu var uztaisīt tā, ka izskatās strukturēts un vajag. Realitātē ātri vien iekrāsosies stūrī un nāksies principus lauzt. Tapēc taisi savus datus loģiskus, bet to reprezentāciju browserim smuku. Kad browseri(un citas programmas) attīstīsies, tad nebūs grūti uztaisīt citu reprezentāciju.
2004. gada 27. janvārī, plkst. 18:34
Skatos, ka esat aizmirsuši par elementu //dl// jebšu "definition list". Tas, manuprāt ir vislabākais //propertiju// loģiskās struktūras attlēlojums, jo: 1) tas ir saraksts; 2) tas satur ne tikai //propertija// vērtību (//dd//), bet arī tā nosaukumu (//dt//). Turklāt mums jau nav problēmu nerādīt //propertija// nosaukumu, jebshu //dt// elementu, ja mēs to nevēlamies (display:none), un rādīt tikai elementu //dd//, tieši tāpat kā tomēr //dt// rādīt, ja nu mēs pārdomājam. Protams, ja mēs aizmirstam par to, ko aizmirsām :)
2004. gada 27. janvārī, plkst. 18:45
Docent, good one :) Žetonc ;)
Taču, manis ieteiktais ieteiktais variants (protams, ka dziļš IMHO) ir labs vidusceļš. Kāpēc? Jo, lietojot //definition list// sanāk mērens //overhead//. Pēc Tevis ieteiktās metodes nākas rakstīt sekojoši (lai būtu pilnīga //keisa coverage// [kas par elitāru frāzi:)]):
<dl class="entrydescr"> <dt class="date">Datums</dt> <dd class="date">2002. gada 15. janvārī</dd> <dt class="author">Author</dt> <dd class="author">Vārds Uzvārds</dd> <dt class="comments">Komentāridt> <dd class="comments">6 komentāri</dd> </dl>Var jau protams, katram no attiecīgajiem //dd// neminēt klasi, bet gan stailošanai izmantot selektoru //dt.klase + dt//.
Bet visādi citādi, neslikts ieteikums ;)
2004. gada 28. janvārī, plkst. 08:48
Docent, manu pārdomu rezultāts par definīciju sarakstiem. Tā kā jamie ir domāti kā propertiju piekārtošanas metode kaut kam, tad teorētiski var darīt tā:
<dl> <dt>Posts</dt> <dd>Datums</dd> <dd>Autors</dd> <dd>Komentāri</dd> <dt>Posts</dt> <dd>Datums</dd> <dd>Autors</dd> <dd>Komentāri</dd> <dt>Posts</dt> <dd>Datums</dd> <dd>Autors</dd> <dd>Komentāri</dd> </dl>:)
2004. gada 28. janvārī, plkst. 09:43
Laacz, nu nez :) Mans teorētiskais variants:
<ul> <li> <dl> <dt>Datums/laiks</dt> <dd>2003-01-28 09:42</dd> <dt>Autors</dt> <dd>Vārds Uzvārds</dd> <dt>Posts</dt> <dd>Kaut kāds blabla</dd> </dl> </li> <li> <dl> <dt>Datums</dt> <dd>2003-01-28 10:57</dd> <dt>Autors</dt> <dd>CitsVārds CitsUzvārds</dd> <dt>Posts</dt> <dd>Savādāks blabla</dd> </dl> </li> </ul>Posti - tas ir saraksts parastākajā izpratnē, t.i., ul. Savukārt katram postam ir propertiji, ko mēs attēlojam ar dl.
2004. gada 28. janvārī, plkst. 10:10
Ak, jā, runājot par overheadu. CSS3 ļauj darīt šitā: dt:contains("Datums"){ color: green; } dt:contains("Datums")+dd{ color: red; } līdz ar to, atkrīt vajadzība pēc klašu definēšanas katram elementam. Protams, atkal teorētiski, jo nedomājam par to, ko Tu aizmirsi rakstā ;)
2004. gada 28. janvārī, plkst. 10:25
Man aizvien vairāk sāk iepatikties doma par mazu bannerīti "Designed not for Micro$oft Internet sExplorer" vai taml. Īpaši smukās vietās iekļaujot citātu no www.pods.lv - "Ar vecu pārlūku tālu netiksim..." Par M$IE un w3c varētu runāt, runāt un runāt, diemžēl tikai neko labu :(
2004. gada 28. janvārī, plkst. 10:50
MZM, Tu tak nejēdz ko runā. Ne par IE še galvenā runa un IE ar W3C labāk vienā grozā nemet. IE 6.0 pirms diviem gadiem bija spicākais pārlūks un tai laikā neviens neturēja tam līdzi. Tagad vienkārši jaunas versijas nav nākušas, jo nabagi nodarbojas ar caurumu lāpīšanu un nevis fīčošanu. Tas ir normāli. Neko nezini, tik brauc virsū MS bara iespaidā.
2004. gada 28. janvārī, plkst. 11:42
List-o-māni.
2004. gada 28. janvārī, plkst. 13:01
IMHO jau diezgan sen spicākais pārlūks irad Mozilla un pirms pāris gadiem daudzi par ūberpārlūku uzskatīja Opera, bet ka kāds M$IE par tādu uzskatītu - žēl man tā cilvēka.
Un, diemžēl, runa te ir atkal jau par M$IE, jo tu vari taisīt cik vien pareizu un glītu kodu vēlies, bet M$IE atkal jau visu pasākumu pie*.
2004. gada 28. janvārī, plkst. 15:53
mzm: IE ir kāds ir, taču visi to lieto, tātad jātaisa lapa lai tā nevis tur būtu super duper valīda bet gan lai CILVĒKI varētu to APSKATĪT - daiz vai ar kādu citu mērki lapas maz veido. Ja rocinas +/- taisnas tad var izveidot ciešamu kodu kas strādā normāli uz lielākās daļas pārlūku. Šitajā rakstā runa gāja par to kā teorētiski tie listi būtu jālieto (iekš alistapart weba ir dafiga raksti par šito tēmu) nevis par to kurš browsers sūkā kurš ne
2004. gada 29. janvārī, plkst. 13:59
Par Definition listēm ir svaigs raksts: http://www.maxdesign.com.au/presentation/definition/
2008. gada 21. novembrī, plkst. 19:50
kas ir html? xD