Vlákno názorů k článku Mozilla Firefox 1.0 CZ - Nejlepší webový prohlížeč od d.f.h - "nejlepsi webovy prohlizec..." jeste jste zapomneli napsat, ze je...
-
Článek je starý, nové názory již nelze přidávat.
-
d.f.h (neregistrovaný)
"nejlepsi webovy prohlizec..."
jeste jste zapomneli napsat, ze je to "nejlepsi webovy prohlizec na svete". nic proti firefoxu, sam ho (resp. jeste mozillu) pouzivam uz nekolik let, ale podobny prirovnani mi vzdycky pripomenou deti na pisecku, jak na sebe rvou: "muj tatinek je vetsi!" "ne, muj je nejvetsi!" "a muj tatinek je nejvetsi na svete a vsechny vas prepere!"
jestli je neco nejlepsi, to je prece vec nazoru kazdyho z nas, ne? neslo by napsat neco ve smyslu "kvalitni a bezbecny webovy prohlizec?"
samozrejme, i o tom by se dalo polemizovat... -
lubos (neregistrovaný)
Ja ho pouzivam od verzie asi 0.5, a uz vtedy bol plne pouzitelny. Adblock bol plne pouzitelny niekedy ked bol na svete verzia 0.7 a odvtedy ja osobne nemam moc potrebu upgradovat, pretoze mi postacuje.
Mrzi ma ale, ze je z tohto taka udalost, pretoze ja nevidim na to dovod. Co z toho kto ma. Len sa snazia nalakat IE pozitivnych ludi na firefox, lenze tym utrpia ti, ktori ho doteraz bez vsetkeho pouzivali. Pretoze, ti, co hladaju diery a problemy sa zacnu zameriavat na FF, a takisto reklamy zacnu skusat obchadzat rozne blokovacie zalezitosti v FF. A urcite nieco najdu a z toho nemam dobry pocit. No, nastastie ale FF nie je nutne pouzivat na MS like OS. -
kavol (neregistrovaný)
> Co se procentuálně udané výšky týká, tam, ať se
> vám to líbí nebo ne, je zobrazení Gecka správné.
> Gecko, a to mu chválím, se snaží zobrazovat
> podle standardu,
prosím, ukažte mi v nějakém ze zainsteresovaných standardů místo, které říká, že výška IFRAME v níže uvedeném příkladu má být 150 px
a při té příležitosti mi vysvětlete, jaktože pro šířku se Firefox chová jinak, ačkoliv její výpočet je definován prakticky na slovo stejně, jako výpočet výšky?
**********
soubor iframe-testcase.html
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<body style="background-color: silver;">
<iframe src="iframe.html" style="height: 100%; width: 100%;" />
</body>
</html>
**********
soubor iframe.html
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<body style="background-color: white;">
<p>Hello world!</p>
</body>
</html> -
Michal Kubeček (neregistrovaný)
Nikde není definováno, že to bude 150px. Ale vzhledem k tomu, že není explicitně zadána výška containing boxu, není od čeho výšku iframe odvodit, takže jako byste ji nezadal (resp. použil 'auto'). Výška se skutečně počítá podle jiných pravidel než šířika. Doporučuji nastudovat příslušnou pasáž specifikace CSS Level 2 (hlavně sekci 10.5).
-
kavol (neregistrovaný)
> Nikde není definováno, že to bude 150px.
fajn, tak proč tuto hodnotu Gecko používá?
> Ale vzhledem k tomu, že není explicitně zadána
> výška containing boxu,
...
> takže jako byste ji nezadal (resp. použil 'auto').
ok, to sedí -
10.5 Content height: the 'height' property
<percentage>
Specifies a percentage height. The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), the value is interpreted like 'auto'.
> není od čeho výšku iframe odvodit,
ale je -
10.5 Content height: the 'height' property
auto - The height depends on the values of other properties. See the prose below.
10.6 Computing heights and margins
10.6.2 Inline, replaced elements block-level, replaced elements in normal flow, and floating, replaced elements
If 'top', 'bottom', 'margin-top', or 'margin-bottom' are 'auto', their computed value is 0. If 'height' is 'auto', the computed value is the intrinsic height.
3.1 Definitions
Intrinsic dimensions
The width and height as defined by the element itself, not imposed by the surroundings. In CSS2 it is assumed that all replaced elements -- and only replaced elements -- come with intrinsic dimensions.
... hm, tak a kdepak máme napsáno, že pro iframe je "height as defined by the element itself" rovno právě 150 px? já bych tomu teda rozuměl, v duchu normy, že výška záleží na obsahu inline replaced elementu - funguje to tak například u obrázků (img), pokud jsou rozměry "auto", pak výška odpovídá skutečné výšce obrázku - v tomto případě se tedy chová Gesko inkonsistentně, dle logiky jakou se snažíte uplatnit pro iframe by veškeré img bez udaných rozměrů měly být vysoké taktéž 150 px (či jinou náhodnou konstantu, co si vývojáři zvolili)
tož to by bylo co se týče pohledu přes CSS ... jenže Gecko se chová úplně stejně (resp. chovalo když jsem to naposledy zkoušel) i když je procentuální výška zadána jako HTML atribut a ne ve stylesheetu, pro což ovšem platí něco zcela jiného:
16.5 Inline frames: the IFRAME element
<!ATTLIST IFRAME
...
height %Length; #IMPLIED -- frame height --
...
height = length [CN]
The height of the inline frame.
6.6 Lengths
2. Length: The value (%Length; in the DTD) may be either a %Pixel; or a percentage of the available horizontal or vertical space. Thus, the value "50%" means half of the available space.
přičemž available space je dáno velikostí elementu, v němž je iframe obsažen, která mj. může záviset na velikosti viewportu, ovšem změna velikosti okna (ergo kladívko viewportu) v tomto případě Gecko vůbec nezajímá ...
> Výška se skutečně počítá podle jiných pravidel
> než šířika.
omlouvám se za nepřesnost, shoda v definici platí v případě "The percentage is calculated with respect to the height/width of the generated box's containing block.", kdy je daný rozměr explicitně definován ... a mám pocit, že to Gecko taky nezvládá, ale jsem líný teď se psát s testcasem (nebo jej hledat) :-p -
Michal Kubeček (neregistrovaný)
Element iframe bych rozhodně nepovažoval za replaced element, protože nemá obsah, a tedy ani přirozené rozměry. On tedy obsah pochopitelně má, ale protože jeho obsahem je samostatný dokument, nedají se pro rendering stránky použít - na ten druhý dokument můžete také dvě minuty čekat a pak dostat 404... Navíc se při renderování HTML počítá s tím, že máte šířku danou a výška "nějak vyjde". Proto z pohledu HTML/CSS iframe žádný obsah nemá a měl by tedy mít výšku nulovou. Protože se ale očekává, že v iframu něco bude, Gecko pravděpodobně v takové situaci použije nějakou defaultní hodnotu; pochybuji, že by vám více vyhovovalo striktně standardní chování, které tomu iframu dá nulovou výšku.
Rozdíl mezi šířkou a výškou je dán tím, že zatímco containing box, kterým je tady pravděpodobně element body, má definovanou šířku, jeho výška je dána obsahem. Takže u šířky máte z čeho počítat procenta, ale u výšky ne.
Jediné, co vám mohu poradit, je definovat u iframe výšku a nenechávat to na libovůli prohlížeče. Nebo se používání iframe vyhnout. -
kavol (neregistrovaný)
> Element iframe bych rozhodně nepovažoval za
> replaced element,
v tom případě by muselo platit:
10.6.1 Inline, non-replaced elements
... The 'height' property doesn't apply, but the height of the box is given by the 'line-height' property.
což zjevně také neplatí
> On tedy obsah pochopitelně má, ale protože jeho
> obsahem je samostatný dokument, nedají se pro
> rendering stránky použít - na ten druhý dokument
> můžete také dvě minuty čekat a pak dostat 404...
to není argument, samostatný dokument je obsah jako každý jiný
- jednak čekat dvě minuty lze na cokoliv, na obrázky, na jiné objekty (např. flash), i na ten dokument, do kterého se inkluduje (aneb který [grafický] browser [kromě links -g] stránku několikrát nepřekreslí, než ji natáhne kompletní?)
- druhak možnost chyby není důvodem k omezování autora (zakázal už někdo auta, protože občas bourají?)
> Proto z pohledu HTML/CSS iframe žádný obsah nemá
...
tak už se rozhodněte, má obsah nebo nemá? :-)
představme si zjednodušený (!) příklad:
<html>
<body style="margin: 0;">
<p style="margin: 0;"><img src="obrazek" style="height: 200px; margin: 0;" /></p>
</body>
</html>
- dá se o tomto rozhodnout, jak to bude vysoké?
> Jediné, co vám mohu poradit, je definovat
> u iframe výšku a nenechávat to na libovůli
> prohlížeče.
ano, já se snažím výšku definovat, avšak prohlížeč (Gecko) ji dle své libovůle nahrazuje hodnotou 150 px ... resp. 150 obrazových bodů, nikoliv px jak jsou px definovány (http://www.w3.org/TR/CSS2/syndata.html#value-def-length) -
Michal Kubeček (neregistrovaný)
Iframe přeci není inline element, to nemůžete myslet vážně. Aplikuje se sekce 10.6.3 (block-level non-replaced elements in normal flow) a pokud byste ji aplikoval opravdu striktně, bude výška nulová.
> tak už se rozhodněte, má obsah nebo nemá? :-)
Ha ha, to jsem se zasmál. Pro případ, že byste to opravdu nepochopil, iframe nemá z pohledu "document tree" žádný obsah - protože jeho obsahem je samostatný dokument a ten nemusí být vůbec v HTML (může to být třeba XML nebo něco úplně jiného). Při rozhodování o layoutu vnějšího dokumentu se proto nebere obsah toho iframu v úvahu. Naopak, vnější dokument definuje rozměry viewportu, do kterého se bude renderovat obsah toho iframu.
> ano, já se snažím výšku definovat, avšak...
Ne, nesnažíte. Jak už jsem vám jednou vysvětlil, vzhledem k tomu, že containing box (pravděpodobně element body) nemá explicitně definovanou výšku, je vašich '100%' (nebo jakákoli jiná procentuální výška) ekvivalentní hodnotě 'auto', tedy svým způsobem "nechám to na prohlížeči".
Takže ještě jednou: jediné, co můžete Gecku vyčítat, je to, že místo správné hodnoty 0 použije ve vašem příkladu pro výšku defaultní hodnotu 150px. Jestli vám hodnota 0 bude vyhovovat lépe, zkuste to reportovat takto. -
kavol (neregistrovaný)
> Iframe přeci není inline element, to nemůžete
> myslet vážně.
http://www.w3.org/TR/html4/present/frames.html#h-16.5
16.5 Inline frames: the IFRAME element
<!ELEMENT IFRAME - - (%flow;)* -- inline subwindow -->
http://www.w3.org/TR/html4/sgml/loosedtd.html#flow
<!ENTITY % flow "%block; | %inline;">
zdá se, že to nemyslí vážně autoři DTD pro HTML 4.01 Transitional ... mě z výše uvedeného jasně vyplývá, že iframe může být jak block-level, tak inline ...
ale hluboce se omlouvám za překlep, v dříve uvedeném testcase jsem zapomněl iframe uzavřít do odstavce (mezi <p> a </p>), aby v daném kontextu šlo o inline užití ... ovšem v praxi je to jedno, Gecko se k výšce iframe chová pokaždé stejně
> Pro případ, že byste to opravdu nepochopil,
> iframe nemá z pohledu "document tree" žádný
> obsah - protože jeho obsahem je samostatný
> dokument a ten nemusí být vůbec v HTML (může
> to být třeba XML nebo něco úplně jiného). Při
> rozhodování o layoutu vnějšího dokumentu se
> proto nebere obsah toho iframu v úvahu.
zkusím přeformulovat otázku: jaký je z hlediska "document tree" rozdíl mezi iframe a např. img?
("a ten nemusí být vůbec v HTML (může to být třeba XML nebo něco úplně jiného)" - a ten nemusí být vůbec v JPEG (může to být třeba PNG nebo něco úplně jiného) (resp. obrázky se nemusí zobrazovat vůbec - paralela s výše uvedeným příkladem 404 Not found pro iframe))
- proč se obsah img v úvahu brát může a obsah iframe nikoliv? kde norma definuje, že se má browser pro jeden replaced element chovat jinak než pro jiný? -
Michal Kubeček (neregistrovaný)
Rozdíl je v tom, že obrázek má vždy definovány oba rozměry. Správně byste je měl definovat přímo atributy width a height, když to neuděláte, určí se podle samotného obrázku. Není-li k dispozici obrázek, zobrazí se obsah jeho atributu alt, není-li ani ten, použije se náhradní ikona. Naproti tomu dokument vložený pomocí iframe většinou žádné přirozené rozměry nemá, naopak, renderuje se do obdélníkové oblasti, která je mu přidělena zvenku. Tentýž dokument může mít rozměry 200x400px nebo 400x200px - a nebo se klidně vyrenderuje do 150x150px (se scrollbarem). To, že dokument může mít pevně definovaný vlastní rozměr, je spíše výjimečná situace, a po pravdě řečeno, vzorová ukázka toho, jak by se weby dělat neměly.
-
Adam (neregistrovaný)
At uz je gecko jake je, pointa je, ze pod linuxem mozilla (i firefox) startuje neuveritelne dlouho a nacita pomalu a pod windows zase svevolne prestava fungovat (ne ze by se to netykalo i jinych windows programu :)) zatimco opera je rychla a spolehlive funkcni (pro spoustu lidi je navic plus i to ze je postavena na QT) a konqueror zase plne integrovany s KDE a startujici casto pod vterinu :)
Mam dojem ze pri vyvoji Mozilly se vice politikari nez programuje, ale at si kazdy pouziva co chce ;) -
kavol (neregistrovaný)
> Rozdíl je v tom, že obrázek má vždy definovány
> oba rozměry.
... stejně jako může mít iframe, ale Gecko nerozlišuje, kdy definovány jsou a kdy ne (ve kterémžto případě by použití defaultní hodnoty bylo akceptovatelné, jen kdyby ta hodnota aspoň závisela na konkrétním rozlišení a nastavení velikosti fontu ...)
> Není-li k dispozici obrázek, zobrazí se obsah
> jeho atributu alt,
- aha, a výška fontu, kterým se to zobrazí, a šířka, na kterou to vyjde, je definována oč lépe, nežli u textu obsaženého v iframe?
... se mi zdá, že vaříte z vody
> To, že dokument může mít pevně definovaný
> vlastní rozměr, je spíše výjimečná situace,
> a po pravdě řečeno, vzorová ukázka toho, jak by
> se weby dělat neměly.
nechápu proč - budu-li mít přesný rozměr v em (ex), může si to čtenář naškálovat dle potřeby, zvětšit, aby to pro něj bylo čitelné, nebo zmenšit, třeba aby nemusel zbytečně scrollovat ... pro mě je vzorovým negativním příkladem naopak když tam Gecko vrazí pevnou výšku v obrazových bodech (vždy stejnou, viz výše)
a jinak za vyjímečnou situaci to nepovažuju - např. když bude obsahem jen text v jednoduchém layoutu, pak výšky řádků jsou jasně definované (z velikosti fontu), paddingy, marginy a bordery taky, jaký je problém vše sečíst a dozvědět se vertikální rozměr? - imho je to problém asi tak na úrovni právě jako dekódovat obrázek a zjistit jeho výšku ... -
Michal Kubeček (neregistrovaný)
<i>... stejně jako může mít iframe, ale Gecko nerozlišuje, kdy definovány jsou a kdy ne</i>
<p>
Tím jste si vlastně odpověděl sám. Obrázek je má, iframe je určitou shodou okolností může náhodou mít také, ale je to spíše výjimka.
<p>
<i>- aha, a výška fontu, kterým se to zobrazí, a šířka, na kterou to vyjde, je definována oč lépe, nežli u textu obsaženého v iframe?</i>
<p>
Je zobrazován stejně, jako by tam opravdu byl ten text. Takže renderer ví naprosto přesně, jak to má zobrazit - ty informace jsou buď v aktuálním dokumentu nebo jeho stylesheetu. U iframe jsou úplně jinde - pořád přehlížíte, že obsah iframe může renderovat někdo úplně cizí, třeba nějaký plugin. A hlavně: pokud se zobrazuje obsah atributu alt, zobrazuje se opravdu tak, jako by tam místo elementu img byl ten text - tedy nikoli jako replaced element.
<p>
<i>nechápu proč - budu-li mít přesný rozměr v em (ex), může si to čtenář naškálovat dle potřeby, zvětšit, aby to pro něj bylo čitelné, nebo zmenšit, třeba aby nemusel zbytečně scrollovat</i>
<p>
Pokud to nebylo jasné, bavil jsem se o rozměrech toho dokumentu, ne viewportu, do kterého se bude zobrazovat. Zadávat explicitně oba rozměry pro HTML dokument je chybný přístup - bez ohledu na jednotky. Základní filosofie renderování HTML vychází z toho, že předepíšete šířku a výška vyjde podle obsahu a dalších parametrů. Znovu opakuji: HTML dokument nemá přirozené rozměry a pokud je náhodou má, je to mimořádná situace, ne něco, s čím by se dalo nebo mělo počítat.
<p>
<i>imho je to problém asi tak na úrovni právě jako dekódovat obrázek a zjistit jeho výšku ...</i>
<p>
Není. Za prvé stále znovu a znovu ignorujete fakt, že iframe nemusí a priori obsahovat HTML, on může obsahovat i věci, kterým prohlížeč sám vůbec nerozumí. Za druhé HTML dokument nemá na rozdíl od obrázku (obecně) přirozené rozměry. Za třetí i když používání elementu img bez atributů width a height není striktně vzato chyba, je doporučováno je používat vždy. -
kavol (neregistrovaný)
chjo, nebaví mě to rozebírat, je to o voze a deseti kozách ... :-(
takže otázka: když má iframe známé rozměry(*), proč je Gecko ignoruje(**)?
(*) je mi úplně jedno, co je v iframe obsaženo, engine renderující obsah dokumentu se může na rozměry obsahu iframe zeptat enginu (nebo jak říkáte pluginu), který zpracovává obsah iframe (+), stejně tak, jako se ptá na rozměr enginu dekódujícího img
(+) podotýkám znovu: _jakýkoliv obsah_, o html jsem mluvil pro jednoduchost a protože je to asi nejčastější případ
(**) ... když by je ignorovat neměl, jak bylo doloženo výše uvedenými odkazy na CSS -
Michal Kubeček (neregistrovaný)
1. Protože obecně známé nejsou, takže se s tím nedá počítat. Proto iframe není replaced element. Protože iframe není replaced element, počítají se jeho rozměry jako u non-replaced elementu. V tomto konkrétním případě to znamená, že výška je nula.
2. Obrázky v obvyklých formátech zobrazuje přímo prohlížeč, jiný obsah může zobrazovat plugin. Pokud nevidíte, jaký je v tom rozdíl, asi nemá smysl pokračovat.
3. Nemá-li containing box explicitně zadanou výšku, což zde nemá, je procentuální hodnota atributu height nahrazena hodnotou auto. V tomto konkrétním případě (non-replaced block element in normal flow) znamená auto ve výsledku nulu, jak bylo doloženo odkazy na specifikaci CSS Level 2. Jak už jsem řekl, jediné, na co si ve vašem příkladu můžete stěžovat, je to, že Gecko použije výšku nenulovou. Pochybuji, že zrovna tohle by vám vadilo.
4. Končím s touto nesmyslnou snahou. Na něco jste se zeptal, odpověděl jsem vám. Nepochopil jste, pokusil jsem se vám to vysvětlit. Pokusil jsem se o to celkem asi sedmkrát, ale nikam to nevede. Srozumitelněji to už vysvětlit nedokážu. Buď to pochopit nechcete nebo nedokážete, tak či onak mi už došla marnost mého počínání, a proto v něm nebudu nadále pokračovat.
Howgh -
kavol (neregistrovaný)
původně jsem to taktéž chtěl minulým příspěvkem uzavřít, ale kdyby to tu náhodou někdo četl, nerad bych ho nechal v omylu :-)
ad 1.
> Protože obecně známé nejsou, takže se s tím nedá počítat.
stále stejný dotaz: to, že se s tím nedá počítat vždy, opravňuje engine chovat se nekorektně, pokud to definováno je?
... dotaz budiž jako námět k zamyšlení, odpověď již nečekám
> Proto iframe není replaced element.
iframe imho replaced element je (http://www.w3.org/TR/CSS21/conform.html#replaced-element)
pokud by nebyl, pak platí sekce CSS2 10.6.1 Inline, non-replaced elements, která definuje height pomocí line-height, viz výše v diskusi, tedy opět nikoliv jako nulu (nebo 150 bodů :-)
ad 2.
> Obrázky v obvyklých formátech zobrazuje přímo
> prohlížeč, jiný obsah může zobrazovat plugin.
ovšem vložený dokument zobrazuje taktéž přímo prohlížeč a obrázek může zobrazovat plugin ... takže co z toho jako má plynout?
... "?" jako výše
> Pokud nevidíte, jaký je v tom rozdíl, asi nemá
> smysl pokračovat.
dovoluji si podotknout, že element iframe je určen pro vložení "dokumentu", viz http://www.w3.org/TR/html401/present/frames.html#edef-IFRAME a http://www.w3.org/TR/html401/struct/objects.html#h-13.1, "jiný obsah" může mít element object
... Pokud nevidíte, jaký je v tom rozdíl, asi nemá smysl pokračovat.
ad 3.
> V tomto konkrétním případě (non-replaced block
> element in normal flow) znamená auto ve výsledku
> nulu, jak bylo doloženo odkazy na specifikaci
> CSS Level 2.
v tomto konkrétním případě je výška závislá na obsahu, tedy alespoň pokud mluvíte o 10.6.3 Block-level, non-replaced elements in normal flow, and floating, non-replaced elements (http://www.w3.org/TR/CSS2/visudet.html#q17)
- praví se tam "If 'height' is 'auto', the height depends on whether ...", kde jste si vybájil tu nulu opravdu nechápu ...
nicméně, případ block-level se mi nechtělo rozebírat, chybu v testcase jsem zmínil a omluvil se za ni ...
ad 4.
> Na něco jste se zeptal, odpověděl jsem vám.
na začátku nestál můj dotaz, ale Vaše nepravdivé tvrzení, že se v případě výšky iframe chová Gecko podle standardů
- pletete si strany, i když jsem použil několik dotazovacích vět, nejsem ten, kdo by neměl v otázce výpočtu výšky iframe jasno podle standardů; zatímco Vy se tvrdošíjně odmítáte nechat vyvést z omylu a z jakési posice "absolutní pravdy" zde hlásáte své názory, jejichž správnost jste ovšem za celou dobu diskuse nepodložil ani jednou citací z relevatních specifikací nebo konkrétním (!) odkazem na ně
HOWGH
