Autor Zpráva
Knopi
Profil
Má nějaký zvláštní význam v hlavičce tag title co se týče pořadí?

Ukázka:

<html>
<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<link href="css/screen.css" media="screen" rel="stylesheet" type="text/css" />

<title>Tomáš Rosický: novinky, aktuální informace</title>

</head>
...

Neměl by být "title" spíše co nejvýše? Protože vyhledávače prohlížejí hlavně začátek dokumentu a styly podle mého názoru nejsou z tohoto pohledu důležitější?

2. Ukázka

<html>
<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title>Tomáš Rosický: novinky, aktuální informace</title>

<link href="css/screen.css" media="screen" rel="stylesheet" type="text/css" />

</head>
...

Dále bych měl otázku, kde se mi možná širší populace webdesignerů zasměje. Myslíte, že systém a pořádek v css kódu může mít za to, že stránka se rychleji načte a bude vykreslována od základů do úplnosti. Co tím myslím. Jsem zastánce filozofie, že když např. zadám pro

body {
background: silver;
min-width: 751px;
text-align: center;
font-family: Tahoma, "Geneva CE", lucida, sans-serif;
font-size: 83%;
color: black;
line-height: 1.5;
}

Jak by měli se načítat vlastnosti za sebou! Asi by byla blbost dát na začátek css vlastnost (font-family), když základem je pozadí. Navíc jsou to kaskády..., děkuju mnohokrát za názory, doufám odbornější. Hezký den přeju.
djlj
Profil
Title by měl být za informací o kódování. Jinak je úplně fuk, kam si ho dáš, robot to z toho umí vyparsovat, i když to bude na konci dokumentu.
quinux
Profil
1. IMHO ne
2. taky ne a navíc, pokud píšeš styly zvlášť na každý řádek tak tím jen zvyšuješ datovou velikost takže je to pak pomalejší
Hugo
Profil
Protože vyhledávače prohlížejí hlavně začátek dokumentu

To bych netvrdil. Vetsina prohlizecu bere cely dokument.
thingwath
Profil
Pořadí prvků je někdy určené, ale když není, tak na něm nesejde (a upřímně si myslím, že by na něm nemělo záležet téměř nikdy, pokud to není vyloženě nutné, tedy vyžadovat hlavičku před tělem mi nedává moc smysl). V každém případě pokud jde o HTTP, klient nemá žádnou rozumnou možnost říct si, že chce jenom prvních sto znaků, může si je stáhnout a potom ukončit spojení, ale kdo by takovou magořinu dělal.

Co se týče toho CSS, to taky nedává moc smysl. Jednak nevím, jestli prohlížeče zpracovávají neúplné CSS (řekl bych, že ne) a pak, kolik má průměrný stylesheet? Řekl bych, že je hodně velká šance, že ho prohlížeč dostane celý najednou. A pokud jde o například uvádění pozadí před písmem, to může být hezký zvyk jak si pro sebe ty zápisy zpřehlednit, ale význam z hlediska prohlížeče je zcela bezpečně roven nule. Ta kaskádovitost je daná něčím jiným.
Knopi
Profil
Díky...

Hugo: To jo, ale na důležité věci koukají vyhledávače jinak, když jsou dole a jinak, když jsou nahoře...
DJ Miky
Profil
To jo, ale na důležité věci koukají vyhledávače jinak, když jsou dole a jinak, když jsou nahoře...

To platí IMHO jen pro tělo (body) dokumentu.
Bubák
Profil
Deklarace pro "body" bývá na začátku CSS. Informace nechodí po písmenkách, ale po paketech, takže celá deklarace pro "body" přijde "najednou". jediný "problém" by dělalo případné obrázkové pozadí, což je další HTTP požadavek.
nothrem
Profil
ad Bubák: Data se stahují po 32kB packetech do kterých se většina css souborů vejde...

Ale i kdybys udělal extra dlouhý css, který by se načítal několik sekund v několika packetech, tak většina prohlížečů před vykreslením počká, až se stáhne celý css - dokonce včetně všech odkazovaných souborů (@import). (max třeba zobrazí dokument bez css)

Pouze v případě, že by se přísun dat zastavil - třeba když je css generováno php skriptem a ten musí čekat na otevření/stažení konfiguračního souboru - některé prohlížeče zobrazí dokument s neúplným css - ale pouze ty definice, které jsou kompletně stažené, takže pokud třeba stáhne, že odstavec má mít písmo arial a 2cm okraj, ale už nedostane koncovou "}", nepoužije tuto definici (ale třeba IE i v tomto případě dokument nevykreslí).

A co se samotného vykreslování týče: css se nejprve rozparsuje a rozdělí podle potřeby, takže i když background-color napíšeš až na konec za všechno ostatní, bude se vykreslovat jako první.
(neni v silách žádného programu nebo počítače, aby nejprve napsal text a pak okolo něj a do mezer doplňoval barvu pozadí)
thingwath
Profil
nothrem
32kB je prosím odkud vzaté číslo? Přijde mi to děsivě velké. Na linkové vrstvě třeba ethernet omezuje velikost rámce na 1500 bajtů. Posílat 32kB velké IP pakety je pak docela hloupé. Ztratíte jeden rámec a vysíláte znova celý paket.
nothrem
Profil
thingwath: no, řekněme, že sem si to třeba vymyslel. Ale někde se tu už o tom mluvilo a tam těch 32kB padlo. Hlavní pointa je ta, že velikost většiny css se pohybuje řádově v bajtech nebo jednotkách kilobajtů, takže přijdou "najednou" v jediném packetu...
thingwath
Profil
To už jsem říkal :-) Ale velikost toho paketu bych čekal o poznání menší :-) Asi takovou, že je dost reálná šance, že se do ní jeden css soubor nevejde. Ale vážně si nemyslím, že by prohlížeč načítal CSS po částech, spíš si počká až to bude mít celé.
nothrem
Profil
:-)
thingwath
Profil
No, třeba já se svojí wi-fi linkou při ztrátě paketů kolem deseti procent (a to platí pro lepší dny, jednoznačně) bych při velikosti paketů 32kB jenom smutně koukal, protože bych si statisticky vzato nestáhl asi nikdy nic.
nothrem
Profil
No, já bych naopak řekl, že jestliže packet musí v hlaviččce obsahovat spoustu informací (odkud jde, kam směřuje, kudy chce jít, jaké obsahuje data, ...) tak by při velikosti packetu v řádech bajtů byl internet dost ztrátový...
thingwath
Profil
nothrem
Tady začíná ta pravá sranda v telekomunikacích a informatice. Velký paket je velké riziko, že se nám z něj kousek ztratí a to znamená, že je v háji celý. Při 20 bajtech IP hlavičky (a dalších 20 TCP hlavičky) se nám naopak nevyplatí posílat to příliš malé. Asi bych si měl důkladněji ty protokoly prostudovat jak to řeší, nedával jsem na to moc pozor, což je chyba.
nothrem
Profil
Podle téhle stránky http://www.freesoft.org/CIE/Course/Section3/7.htm je v hlavičce packetu pro "total length" rezervováno 16 bitů, takže technická hranice velikosti je 65kB a za druhé to znamená, že velikost packetu se může měnit...

I samotná hlavička může měnit délku v rozmezí 20B - 64B
thingwath
Profil
No jistě. Nebude si nikdo vymýšlet kilobajt vaty aby zarovnal velikost paketu na nějakou pevně stanovené číslo :-)
Knopi
Profil
Já jsem se snažil jen logicky uvažovat. :-) Tak koukám, že to vážně funguje jinak...
nothrem
Profil
No v počítači je to naštěstí tak, že "vata" (odborně se to jmenuje JUNK) se nevymýšlí, ale vyplňuje nulami ;)

A divil by ses, kolik v počítači té vaty je... počínaje třeba tím, že když potřebuješ zapsat "1" do 4 bajtů, tak tam je 31 "zbytečných" nul (klidně by to šlo uložit jen jako "1", ale pak by se to moc pomalu četlo)

Ale to už se dostáváme do oblasti kódování, komprese apod. což rozhodně nejsou "problémy v začátcích"
thingwath
Profil
Odborně se to jmenuje vata :-] Ale ty nuly ve tvém příkladu vata nejsou, to je prostě reprezentace toho čísla. A pevné hranice se celkem hodí, stejně musíme vedět jak široké to je. Jak bychom pak třeba dělali čísla se znaménkem. Bylo by ovšem dost hloupé používat tento přístup v telekomunikacích, kde to není nutné. Někde se pevné hranice vyplatí, u datové části asi ne.
Toto téma je uzamčeno. Odpověď nelze zaslat.