Názory k článku Mozilla Firefox 1.0 CZ - Nejlepší webový prohlížeč
-
Č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 -
Dusan (neregistrovaný)
Tak nevim mne prijde Firefox jako free barevnejsi verze MSIE. Oproti te zoufalosti od Microsoftu je to asi pokrok, nicmene ze by to mne jako uzivatele Opery donutilo k prechodu, to teda ne. Vzdyt to vubec nic neumi. OK, kdyz stravim pulku dne shanenim a testovanim pluginu, tak to mozna zacne byt pouzitelne, ale proc by to clovek delal ...
-
Jerry (bez trojky) (neregistrovaný)
Protože opeřích tisíc featur nepotřebuju, to co umí Firefox (plus pár pluginů pro vývoj, které pro změnu nejsou dostupné pro Operu) mi bohatě stačí? A protože nechci cracknutý software ani pruh s reklamou? A protože přece jen ještě o něco lépe podporuje standardy?
Předem podotýkám - nikomu ho nenutím, jen odpovídám na otázku...;-) -
Nikola Ciprich (neregistrovaný)
ja si osobne myslim ze lepsi je galeon. orezani kvuli rychlosti je sice dobre, ale abych si i pro nastaveni downloadovaciho programu musel hledat plugin, tak to uz mi prijde jak za dob exploderu...
proste mam pocit ze firefox mi nemuze oproti galeonu nabidnout vubec nic - stranky mi zobrazi stejne (stejne jadro), a je mnohem mene konfigurovatelny -
Pavel M (neregistrovaný)
Existuje (alespon pro verze FF do 1.0Pre1, 1.0 jeste nemam nainstalovanu), ale jedna se opet o plugin, ktery se musi doinstalovat - Download statusbar. Nejen ze ukazuje progressbar, ale cinni tak (vcetne tooltipu) pro kazdy download v liste pod strankou. Nalezt ho lze na http://downbar.mozdev.org/
-
Nikola Ciprich (neregistrovaný)
jiste, ja taky nejsem zastancem toho, nekomu neco nutit. ale omezovat take ne. a (zde si neodpustim reklamu) od doby kdy jsem poprve vyzkousel d4x (www.krasu.ru/soft/chuchelo) mi proste jednoduchy progressbar v mozille nestaci. na nektere funkce se proste dobre zvyka - moznost pohodlne za behu omezovat rychlost stahovani i pro ruzne fronty zvlast, omezeni max. poctu downloadu zaroven, bezproblemove pause/resume atd. nerikam ze tohle vsechno nejde udelat i ve wgetu, ale to pohodli d4x je proste parada. az me prekvapuje ze se o nem tak malo vi...
a integrace do galeonu je dilem chvilicky, stejne jako usporadani panelu, podle toho co casto vyuzivam (vyhledavani googlem, slovnik, freshemat), kategorie zalozel, to jsou veci ktere proste mozilla ani firefox nenabizi...
tim ovsem nechci vyvojare nijak hanet, nebyt mozilly, neni ani galeon a spousta dalsich projektu. -
gmmns (neregistrovaný)
Hlavne mam ale pocit, ze FlashGet neni portovany *nixy - coz cloveka, ktery pouziva Galeon, jiste zamrzi. Dost dobre vypada treba projekt Aria (je pro Linux), ktery FlashGot take podporuje - krome jinych. A krome FlashGotu existuje treba rozsireni DownloadWith, ikdyz to jsem videl v akci jenom pod "velkou" Mozillou.
-
Jerry (neregistrovaný)
Proč ne, je to vaše volba, mně Galeon nevyhovuje (teda - naposledy jsem ho viděl někdy před půl rokem, takže dnes může vypadat úplně jinak), ale nevidím důvod proč ho někomu brát. Jinak jako download manager používám pod Windows Leechget - a pod Linuxem wget ;-)
Jak jsem už napsal, je to čistě moje hledisko a nikomu ho necpu. Byla by to nuda, kdyby byli všichni stejní...;-) -
gmmns (neregistrovaný)
Kdysi jsem taky pouzival Galeon - v te dobe byla Mozilla (tenkrat se merilo jeste milnikama) pomala a ja jsem mel slaby stroj, Galeon ale umel uzasne veci a byl daleko rychlejsi. Byl ale pomerne nestabilni a zkompilovat ho byl problem. Proto se vyvojari pustili do vyvoje nove vetve - ale ta vetev umela tak slabou ctvrtinu toho, co ta puvodni (ze ktere v prubehu vyvoje taky par uzitecnych veci ubylo). A co hur - "novy" Galeon padal, podobne jako ten puvodni. Pokud se da v dnesni dobe pouzivat, je to skvele, ja se k nemu ale asi uz nevratim.
-
Maverick (neregistrovaný)
Ikdyz uzivatel Opery, musim souhlasit. Opera je v defaultni instalaci nesnesitelne skinovana, neprehledna a neefektnivne plochu vyuzivajici. Nicmene kdyz si clovek trosku vyhraje (stejne tak s Firefoxem), dostane z ni plnohodnotny nastroj. Kdyz clovek pronikne trosku pod kuzi, muze si udelat i vlastni "instalator" - ja mam zazipovany archiv, ktery mam na svem FTP, ma neco kolem 3MB a kdyz potrebuju, stahnu, spoustim a oblibeny prohlizec mam pripraveny k pouziti vcetne vsech zalozek, nastaveni oken, posty apod.
Jednim z duvodu pro pouzivani Opery u me byly navykove mysi zkratky, ktere napr. dnes pouziva i Mozilla. Ale asi nejvetsi plus z meho pohledu je prave pristup "all in one", vcetne nezvykle filozofie emailoveho klienta. A treba "Opera show" s moznosti vytvareni na HTML postavene prezentaci, kterou jednoduse vystrcim na web v plne validni forme zatim neni nicim prekonana (doufam ze Firefox brzo prijde s podporou CSS: page-break-after)
... nechci vyvolavat flame, pouze par postrehu ohledne dalsi alternativy k IE (ktera neni vubec nezaplatitelna, ikdyz neni free).
kazdopadne ocenuju VELKY KUS PRACE, ktery lide okolo Firefoxu udelali, predevsim jejich (celkem uspesnou) snahu o zboreni mytu "Internet = Internet explorer" a osvetu v oblasti bezpecnosti internetu - ikdyz pro nektere uzivatele musi clovek puvabnou pandu skryt osklivym modrym antivitaminem e ;o) -
Michal Kubeček (neregistrovaný)
Mně začala Mozilla šíleně padat po přechodu SuSE 9.1 (jádro 2.6 a NPTL). Stačilo naklikat tak 30 obrázků v nových tabech, pak je po jednom pozavírat, to celé dvakrát až třikrát zopakovat a spolehlivě šla do vývrtky. Nastavení LD_ASSUME_KERNEL trochu pomohlo, ale ne moc Firefox si překládám sám (oficiální build pro x86_64 neexistuje) a tyhle problémy zatím nemám.
-
Petr Ježek (neregistrovaný)
Já pod Mandrakem (nyní 10.1 community) nikdy z Firefoxem (dříve Phoenixem a Firebirdem) neměl "padací" potíže. Kromě jedné situace, kdy se mi pokousaly po reinstalaci buildy - běžné verze vždy běhaly OK. Padání bych přisoudil spíše kontraproduktivní tvořivosti uživatele...
-
Michal Kubeček (neregistrovaný)
Dřív jsem měl podobné zkušenosti, ale od verze 1.0PR se mi FireFox zdá podstatně stabilnější než klasická Mozilla (verze 1.7* a 1.8a?). S tou mám od přechodu na jádro 2.6 obrovské problémy. Na druhou stranu je ale potřeba si zvyknout na to, že některé funkce, které umí Mozilla standardně, jsou u FireFoxe součástí rozšíření.
-
Bubak (neregistrovaný)
Pouzivam Mozillu i Firefox doma, u znamych i v praci a v ruznych verzich a nepamatuju se, ze by mi kdy nektery z nich padnul. Je fakt, ze nelezu po strankach, ktery me nase.ou uz tim, ze na zacatku je debilita ve flashi a bez ni se clovek nedostane dal nebo jsou tam nejake nesmyslne graficke splantaniny, takze asi nejsem ten spravny sample uzivatele:-)))
-
Lubos "herrman" Moscovic (neregistrovaný)
No, mozillu pouzivam na debiane uz hodne dlho asi tak od verzie niekde okolo 0.6 7 neviem... To je jedno uz je to davno a je pravda, ze niektore verzie mali nachylnost padat pri otvoreni nie statickych stranok, cize zahucali napr aj na root.cz ci linuxzone.cz. Sranda bolo, ze sa to dialo v nepravidelnych intervaloch. Obcas zahucal obcas nie. Obcas fungoval 2 dni bez problemov obcas spadol 3x po sebe...
Ale uz sa mi to nestalo peknych par mesiacov. -
Mikulas Patocka (neregistrovaný)
Mne by zajimalo, v cem je Firefox lepsi nez standardni Mozilla. Pod vahou reklamy jsem ho taky zkusil, ale pripada mi to spise jako oklestena Mozilla, bez spousty nastaveni. Rychlost zobrazovani stranek se nezvysila, rychlost reakce prvku v dialogovych oknech taky ne. Rychlost startu se zvysila.
Tak jsem to zase smazal. -
Michal Kubeček (neregistrovaný)
AFAIK má být lepší právě v tom, že obsahuje jen ten nezbytný základ, tj. vlastní prohlížeč. Postradatelné featury jsou realizovány jako samostatné extensions a každý si nainstaluje jen ty, které potřebuje. Proto by měl být menší, rychleji startovat a zabírat méně paměti. Ale jak moc se rozdíl opravdu projeví, to jsem zatím důkladně nezkoumal.
-
Michal Kubeček (neregistrovaný)
Asi jste v mém příspěvku přehlédl dvě maličkosti: za prvé v předposlední větě píšu "by měl", ne "má". Za druhé v poslední větě výslovně upozorňuji, že jsem zatím netestoval, jestli tomu tak opravdu je a v jaké míře.
Ve vašem případě bych ale přinejmenším nejprve ověřil, jestli používáte aspoň přibližně stejné verze renderovacího jádra a jestli máte podobnou konfiguraci např. ohledně cache. -
pc (neregistrovaný)
Fakt? to zni docela neuveritelne - zda se ze by to znamenalo ze se prace na tech jadrech dela vlastne dvakrat, nebo se musi neustale nejak mergovat, pricemz se muze stat ze se na spoustu bugfixu zapomene. Da se k tomu najit nejaky oficialni dokument? Samozrejme nechci zpochybnovat verohodnost predchoziho prispevku, jen me to zajima.
-
Peto_MiG (neregistrovaný)
Pozri si na stranke Mozilla.org v sekcii Developers stranku Roadmap. Tam je to vysvetlene, ale po anglicky.
Ak som to spravne pochopil, tak v zasade ide o to, ze zaklad (Gecko) sa vyvija spolocne a vsetky aplikacie z neho cerpaju, hoci mozno nie vzdy z tej istej verzie. Napriklad sucasny Firefox cerpa z Gecka ktore bolo uvolnene v Mozilla 1.7.3
Aplikacie Firefox, Thunderbird, Sunbird, Nvu su sice postavene na spolocnom zaklade (Gecko), ale su vyvijane prakticky od zaciatku. Jednak kvoli modernejsim nastrojom a lepsej integracii s nativnym prostredim tej ktorej platformy, a jednak preto, ze Mozilla Suite ako balik je uz prilis komplikovany a aplikacie su prerastene navzajom. Tazko sa v tom orientuje, tazko sa vyvija a tazko sa hladaju chyby. Naviac je to kolos zaberajuci hafo pamate.
Takze prislo radikalne rozhodnutie a aby sa nemuseli pracne osetrovat povodne obmedzenia, padlo perspektivnejsie vyzerajuce rozhodnutie napisat to odznovu, nad spolocnym zakladom, ktorym je Gecko.
Cakam, ci sa este aspon to Gecko postupne nevycleni z jednotlivych aplikacii a nezacne byt distribuovane ako samostatna kniznica, aby naozaj kazda aplikacia netahala so sebou svoju vlastnu verziu.. -
vs (neregistrovaný)
Jestli myslite jadro ciste jako zobrazovaci, tak to maji Mozilla i Firefox skoro stejne, ale kazdy svoji vlastni kopii (to firefoxi je v mnoha ohledech asi tak tri ctvrte roku pozadu). Pokud myslite zpusob fungovani programu, tak Firefox je krok zpet oproti puvodnim planum (i kdyz je kvuli tomu rychlejsi): Mozilla (stejne jako tusim posledni Netscape) bezi nad GRE, takze s ni teoreticky muzete v pohode provozovat jakoukoli dalsi aplikaci nad GRE postavenou, Firefox a Thunderbird jsou monoliticke, na vymenu jadra bez vymeny cele aplikace muzete vesele zapomenout. Plany jsou AFAIK porad stejne - vsechno by melo v budoucnu bezet nad GRE (abyste s kazdou dalsi aplikaci netahali a nepousteli porad znovu to same jadro jenom v jine inkarnaci), ale jak se to bude prave s Firefoxem a spol. resit se odlozilo az do budoucna a jestli nekdo tusi, jak to dopadne...
-
Tux (neregistrovaný)
Taky jsem to moc nepochopil. Přijde mi to jako killer Internet Exploderu pro lidi, kteri nikdy neviděli Netscape 4. Já jakožto dlouholety uzivatel Netscape se svoji mozilly vzdám tak možná, až ji mozilla.org přestane vyvíjet (jak naznačuje už asi od začátku vývoje FF, takže to asi zas tak móóc brzo nebude). Navíc představa, jak se mi po disku (později v paměti) válí 4-6 Gecko jader, kde jedno je pro FF, druhé pro TB, a třetí pro já nevím co, mě fakt neláká
-
Jan Vybiral (neregistrovaný)
Mne Firefox 1.0 na Debianu padal tak dlouho, dokud jsem nenainstaloval novou verzi libgtk2.0-0. Presneji 2.4.13-1 misto 2.0.2-5woody2. Pokud vam to pada kvuli chybe "Gdk-CRITICAL **: file gdkpixmap-x11.c line 218...." nebo nejake podobne, tak se zkuste zamerit timdle smerem :-)
-
Navi (neregistrovaný)
mi pripadaji dost "hype", jako by to psal nekdo kdo si predtim slehl neco pro hodne dobrou naladu...
pri vynechani vsech slov "nejlepsi"... by to byl normalni clanek, takhle muze akorat provokovat k flame, co je lepsi...
protoze vsichni vime, ze nejlepsi je mozilla, ze :)
(pro me urcite) -
Mystic (neregistrovaný)
Firefox není ani rychlejší...
http://vbnet.aspweb.cz/msie/maze/maze.htm
http://vbnet.aspweb.cz/msie/maze/demo.htm
..ani technicky vyspělejší, než MSIE
http://vbnet.aspweb.cz/msie/sound.htm
http://vbnet.aspweb.cz/msie/cradle.htm
http://vbnet.aspweb.cz/msie/vml.htm
http://vbnet.aspweb.cz/msie/tree.htm
O vybavení MSIE free pluginy lze podiskutovat na CrazyBrowserem, AvantBrowserem, nebo konečně Maxtonem (býv. MyIE2) (mouse gestures, tabbed browsing, download managery a pod. věci, které nepotřebuji). Kompatibilita pluginů pro Firefox je naopak dosti špatná (většina z nich verze k verzi přestane fungovat).
Řekněme tedy, že FireFox je po okrajovém Lynxu a neúspěšné Mozille první OpenSource browser, použitelný v širším okruhu laické veřejnosti - ale to je asi tak vše. Vše ostatní je dosti hlučná marketingová masáž. -
Petr Mach (neregistrovaný)
IE ma radu chyb i v naprostych zakladech jako CSS nebo DOM, stupidni UI, sptane implementovany JavaScript, radu bezpencnostnich der na ktere nejsou zaplaty a nebo jen pro XP (SP2), takze uzivatele w2k maji holt smulu, atd. atd. Dokad na tomhle MS nezapracuje, a nevypada to, ze by se mu chtelo, nema smysl se IE zabyvat, je to stary a mrtvy prohlizec.
-
hrabje (neregistrovaný)
Souhlasim s tim, ze navrhuju stranky tak aby fungovaly i v M$IE, ale v prvni rade je testuju pod Mozillou. Ovsem existujou lidi, ktery navrhujou stranky, ktery chodej jenom v M$IE a na ty podle me ani nema smysl se divat. Zvlast kdyz nemam IE, ze? Dobre mam, ale ne doma a abych si pamatoval adresy a dival se na ne v praci za to mi zdaleka nestojej. Horsi prohlizec jak M$IE jsem jeste nevidel.
-
Lumpy (neregistrovaný)
"Firefox není ani rychlejší...
..ani technicky vyspělejší, než MSIE "
1. Na základě 2 pochybných stránek se rychlost prohlížečů neporovnává.
2. Firefox *JE* technicky vyspělejší než IE, protože podporuje webové standardy:
http://www.mozilla.org/why/users-features.html#standards
Protože je IE zaostalý a zastaralý, zobrazuje všechny níže odkazované stránky (oproti všem moderním prohlížečům) špatně:
http://www.mozilla.org/start/1.0/demos/eagle-sun.html
http://www.mozilla.org/start/1.0/demos/credits.html
http://www.meyerweb.com/eric/css/edge/
http://www.meyerweb.com/eric/css/edge/complexspiral/demo.html
http://www.meyerweb.com/eric/css/edge/complexspiral/glassy.html
http://www.meyerweb.com/eric/css/edge/menus/demo.html
http://www.meyerweb.com/eric/css/edge/slantastic/demo.html
http://www.meyerweb.com/eric/css/edge/slantastic/holiday.html
http://www.csszengarden.com/?cssfile=http://www.peachbunny.com/organic_desire/organic_desire.css
http://www.csszengarden.com/?cssfile=http://void.printf.net/~bredroll/zen/zaurus.css
http://www.csszengarden.com/?cssfile=http://adjustafresh.com/zen/mozattack.css
http://www.csszengarden.com/?cssfile=http://www.oursours.net/CSSZenGarden/sample.css
http://www.csszengarden.com/?cssfile=http://www.my-website.nl/dev/czg/01.css
http://www.csszengarden.com/?cssfile=http://magasvari.fx3.hu/zen/zen.css
http://www.csszengarden.com/?cssfile=http://www.danikkdesign.com/zengarden/text.css
http://www.csszengarden.com/?cssfile=http://dev.simanage.com/download/zen-marbles/zen.css
http://www.csszengarden.com/?cssfile=http://www.timpelen.com/extra/zen/zengarden.css
http://www.csszengarden.com/?cssfile=http://www.qviri.net/zen/styl.css
http://www.csszengarden.com/?cssfile=http://ukdotcafe.com/zengarden/001.css
http://www.csszengarden.com/?cssfile=http://www.splintered.co.uk/portfolio/source/zengarden/door_to_my_garden/style.css
http://www.csszengarden.com/?cssfile=http://www.mycgiserver.com/~jamesnpope/css/jnp.css -
gmmns (neregistrovaný)
No jo, tak ma IE rychlejsi JavaScript, no. Tyhle dve stranky uz jsem nekde videl - budto to bylo od stejneho cloveka, nebo je to soucast MS propagandy. Ale na normalnim webu se takove veci nenachazeji - nastesti, takze to neni moc relevantni argument. Dulezita je rychlost nacitani beznych stranek a tam to u IE asi az tak ruzove nebude.
-
Dave (neregistrovaný)
Pokud se nemylim, VBScript je taky "vyrobek" MS, kterej mel za cil jenom uskodit JavaScriptu (umi to samy co JS, jenom je to v jinym obalu), skoro nikdo to nepouziva. Navic je logicky, ze ukazka ktera ma slouzit pro demonstraci funkci VBS v IE nebude asi fungovat uplne nejrychlejc v jinych browserech.
-
GM (neregistrovaný)
Tak co jsem se to dozvěděl:
Nejlepší webový prohlížeč - zajímavé, to je ale každý prohlížeč, přečtěte si jakoukoli jinou tiskovou zprávu.
Rychlejší prohlížení webu - a ještě zajímavější, tohle taky umí každý prohlížeč. Pro Firefox hraje to, co jsem se před časem dočet tuším tady na rootu. Stačí k tomu prej jenom maličkost, výkoný procesor a dostatek paměti. Kdo by to byl čekal, že s něčím takovým může jet něco i svižně.
Ochrana před spyware, viry a obtěžujícím chováním webových stránek - vynikající! Konečně nebudu muset vyhazovat peníze za antiviry ani já ani zaměstnavatel, hned půjdu navrhnout šéfům přechod.
Tyhle kecy už znám leta, jsou to běžné (všemi nenáviděné) praktiky MS. Takže třikrát hurá! -
Jerry (neregistrovaný)
Co se týče nároků na HW, je na tom lépe Opera nebo Konqueror. Ale ty zase nejsou tak dobré v podpoře standardů, občas některé věci vykreslují blbě (i když se neustále lepší - a nějaké ty mušky má ostatně i Gecko).
Nicméně na vašem PC by měl v pohodě běžet i Firefox; samozřejmě záleží na tom jaký používáte OS a co všechno je zároveň spuštěno. Pod XP vám bude swapovat jakákoli aplikace, pod Linuxem s nějakým nenáročným okenním managerem byste měl být relativně v pohodě. Na každý pád bych i kvůli dalším aplikacím doporučil pustit těch pár korun na dalších 128MB RAM. Procesor je bezproblémový, i na 333MHz Celeronu s 256MB RAM se Firefox (pod Gentoo) choval slušně. -
Lumpy (neregistrovaný)
"Tyhle kecy už znám leta, jsou to běžné (všemi nenáviděné) praktiky MS. Takže třikrát hurá!"
Než začnete nějaký produkt (nebo tiskovou zprávu) odsuzovat, měl byste provést úvahu o tom, zda jsou ty informac pravdivé. A ani skutečně pravdivé jsou:
Firefox má kvalitní bezpečnostní koncepci...
http://www.czilla.cz/articles/bezpecnost-mozilly-a-odvozenych-prohlizecu.html
...s reálnými výsledky
http://secunia.com/product/11/
http://secunia.com/product/3256/
Firefox má plnou řadu funkcí a dobře navržené uživatelské rozhraní, jako žádný jiný prohlížeč:
http://www.rebron.org/mozilla/stuff/
- datasheet-firefox.pdf
- Firefox-Reviewers-Guide.doc/pdf -
Jirka (neregistrovaný)
KB k fungovani nedonutis - ta nema internetove bankovnictvi v pravem slova smyslu. Defacto ti nainstaluje tenkeho klienta napsaneho v MS Jave. Funguje to stezi v IE. Ja jsem od nic z tohohle duvodu odesel.
CS sporitelna sice prudi, ze mam spatny prohlizec, ale pusti mne dovnitr a vse funguje. -
Vlastimil Ott (neregistrovaný)
Přesně tak, s tím bookmarkem.
Servis24 používám už pár let, od té doby, co ho rozjeli také bez kalkulátoru. Není s tím žádný problém, pouze ty hlášky na začátku. No, vlastně je malý problém. Celý ten mechanismus je náročný na spojení - když je špatné, celé to vyhnije. Zejména na wifině mě to takhle v noci, když padne mlha nebo prší, vždy potěší. Končí to stavem, že odhlášení trvá třeba 20 minut - nebo to skončí timeoutem. -
Pavel Riha (neregistrovaný)
Kvuli par zhorsujicim se vecem na me oblibene Opere, jsem se rozhodl nedavno na FF jakoby prejit.
To co mi zlobilo v opere, to ve FF funguje dobre, nicmene uplne happy z neho nejsem.
Jasne ze je to lepsi nez IE (ale horsi to uz snad byt preci nemuze ne?), ma to pravda i par zajimavych features, ale takova ta zakladni pouzitelnost (ovladani) to je trosku problem. Musel jsem nainstalovat asi 15 pluginu a pul dne to konfigurovat, abych se aspon trochu priblizil tomu na co jsem zvykly z opery, ale porad to neni ono. A kdyz jsem si FF nainstaloval v praci, tak abych to delal nanovo?! To se mi vubec nechce, ale hole je to uplne na hovno jako IE.
No, ie to o pluginech, diky nim to muze byt jednou lepsi nez opera. -
Kysela (neregistrovaný)
..."Ne, Firefox opravdu neumí CSS nejlépe, i když tuto demagogii slyším dnes a denně. Podívejte se třeba na příklady Marka Schenka, či Literary Moose. Drtivá většina tohoto velmi pokročilého CSS samozřejmě nefunguje v MSIE, ale ani ve Firefoxu"...
http://hulan.info/blog/?item=firefox-neumi-css
http://www.markschenk.com/cssexp/
http://www.literarymoose.info/=/css.xhtml -
Per Tomeš (neregistrovaný)
"Firefox neumí CSS..."
... je zavádějící a nepodložené tvrzení.
Vyvovozovat jakékoliv závěry o kvalitě podpory CSS mezi prohlížeči na základě 2 stránek s příklady je ostuda. Na objektivní otestování podpory tak rozsáhlé technologie, jakou je CSS, by se muselo připravit několik set/tisíců stránek s příklady. -
poxman (neregistrovaný)
Tak jsem si dal praci s tim, abych to cele precetl a diskuze to je vskutku zajimava. FF urcite zkusim.
Vim, ze tohle sem tak trochu nepatri, presto bych chtel poprosit nekoho z redakce root.cz, jestli by nejak nemohl zmenit styl, jakym se zobrazuji diskuze, protoze debata "kavol vs. Michal Kubeček" se mi v IE postupne tak zuzovala, ze jsem mel ke konci jen jedno slovo na "radku." Jak uz byko receno, vyska je zavisla na sirce, a tak si asi dovedete predstavit, jak velky jsem mel scrollbar. Dekuji ;-) -
Petr Skoda (neregistrovaný)
Slychavam stale jak se vsichni rozohnuji jak je Mozilla (potazmo) FF genialni, maluji si tricka a poradaji party, ale mam pocit, ze se tady (implicitne) smesuji 2 veci - jsem naprosty Mozilli laik, protoze ji poustim jen kdyz chci cist web a nemam cas na nastavovani:
To co vsichni opevuji a radi vyhodit MSIE je FF for Windows, zatimco FF for Linux je na tom o hodne hur s kompatibilitou. Ciste moje pozorovani - Kdyz chci vytisknout cesky vetsinu stranek "optimalizovanych pro MSIE" vetsinou generovanych nejakym udelatkem typu FP, dostanu sice cesky text
ale za kazdym akcentovanym pismem je mezera (a to musi printserver renderovat pres GS, primo se to po PS fronty tiskarny poslat neda). Kvuli tiskum z Mozilly (FF)musime mit zvlastni frontu se zvlastnimi filtry ktere upravuji ten jeji zmrseny PS. Kolega kdyz si chtel vytisknou clanky z abclinuxu musel vse natahnout do openoffice a odtamtud tisknout. Sekretarka oddeleni, kdyz si chce vytisknout vetsinu (pro ni) zajimaveho cteni (viz FP generated apod) se vzdycky dopali kdyz vidi paskvil z tiskarny - nojo tady je jen ten Linux, nic tu nemuze fungovat, ja si to vytisknu u kolegu na MSWin.
Ptam se proc tohle musim akceptovat ?
Uz stary Netscape vyzadoval slozity a dlouhy filtr s PS preambly aby slo tisknout cesky - a pritom se vsichni chvastali, jak je lokalizovany.
Z meho pohledu je situace stale stejna a nic se ani v novem jadru FF nezmenilo.
Navic se prestaly ve FF zobrazovat nektere stranky s JavaScriptem (ruzne obchodni domy, ale ted treba i web Grantove agentury CR). To co driv chodilo na Mozille z RedHat linuxu od jiste doby
ve FF nechodi.
Pritom je to podle me zcela jasne mateni lidi ve stylu MS - Firefox je nejlepsi, nejkompatibilnejsi apod (ale nikde nerekne na MS Win - tchan ji ma a vim, ze je to uplne neco jineho). Navic me jako uzivatele nezajima, jestli to funguje podle standardu jak ma, ja proste nemuzu cist co jsem chtel a dostat danou informaci.
Podle me vyvojari na nektere funkce kaslou a zavolaji WinAPI (napr GDI) apod a pak se jim to trumfuje. Ale implementaci na jinych platformach nechavaji byt jak je. Na tom se slava nenadela.
A pak spousta lidi jen papouskuje marketingove vykriky bez rozumne uvahy.
Mozna jsme blbi, neumime to, ale tiskove servery v oddeleni uz instalovalo nekolik velmi schopnych lidi a na tisku z NS a Mozilly vzdy skoncili napul - neco z toho obcas leze, slusne stranky pochopitelne uplne korektne (to to honime jeste pres ruzne aps filtry - vice stranek na list apod), ale vetsina komercniho "cteni" proste leze blbe.
Me osobne uz prestalo bavit instalovat vsechno od zacatku (pote co se objevil WWW jsem nadsene prispival do listu vyvoje lynxu, radoval se nadsene z grafickych moznosti Mosaicy, kterou jsem musel kompilovat ze zdrojaku a rozciloval se, ze nemam penize na aktualni Motif apod ...)
A taky me nebavi stravit den prizpusobovanim systemu (stahovanim pluginu , konfiguraci list apod, i kdyz chapu, ze jsou lide, kteri to povazuji za hlavni vyhodu napr KDE a naplacaji si animovane nesmysly pres 24bitovy obrazek root okna a divi se, ze je ten stroj nejaky pomaly ;-)
Proto jsem se domnival, ze misto administrace se budu venovat vede (po letech snad poradne) a na takovou trivialitu jako prohlizec jsou balicky do debiana a bude klid. Zda se ze neni :-(
Je mi jasne, ze vyvolam tezkou flame (typu tak se na takove stranky nedivejte, vemte si MSWin kdyz bez nich nemuzete byt apod),
Ale to preziju - chci konkretni ujisteni ,ze se mylim, ze je neco blbe nastavene apod.
Zatim jsem jej nedostal ani kdyz jsem se kdysi v linux konferenci ptal na problemy zobrazovani cestiny, malosti fontu a hlavne onech problemu s tiskem.
Tak se do me pustte !
