Problém je, že to používá API, které ve V3 není dostupné. To API není ve V3 dostupné proto, že zpomaluje stránky a neumožňuje to prohlížeči provádět některé optimalizace při zpracování stránek. uBlock Origin by se asi mohl obejít bez toho API, ale pak by neměl tolik možností manipulace se stránkami.
Jenže: když kliknu na menu, chci, aby se prostě rozbalila ta nabídka. To - kupodivu - není příliš složité, ani náročné.
Náročné a složité to je ale ve chvíli, kdy to zároveň ukládá, na co jsem přesně kliknul, kdy, odkud jsem přijel myší - a pak tohle všechno pošle nějakému statistickému enginu, který to, pokud možno, odesílá kamsi na servery k dalšímu statistickému zpracování. (Že to může být použito k fingerptintingu nebo jiným záludnostem pro tentokrát pomíjím - to není podstatné).
Náročné a složité to je ve chvíli, kdy se z obyčejné webové stránky, která skoro vše vyřídí na straně serveru, stane webová aplikace, snažící se celou funkčnost provádět v prohlížeči.
Editace tohoto komentáře je jednoduchá, stačí na to v podstatě skoro obyčejné textové pole.
Taky by tu mohl být náročný WYSIWYG editor - jenže ten vstup se stejně musí na serveru zkontrolovat, parsovat, desinfikovat.
14. 10. 2024, 21:14 editováno autorem komentáře
Ne, i kdyby to ukládalo, kam jste kliknul, to nijak náročné není. Náročné je, když to dělá hodně manipulací s DOMem – protože je to něco složitějšího, než jen zobrazení menu.
U WYSIWYG nejde o to, že to server stejně musí parsovat, ale o to, že uživatel rovnou vidí výsledek a může to snadno editovat, aniž by si musel přečíst, že jde o XHTML a nastudoval si, jak se XHTML používá.
Právě to, že i obyčejné zobrazení menu
se velmi často zvrhne v hodně manipulací s DOMem – protože je to něco složitějšího, než jen zobrazení menu
je to, co mi na mnoha stránkách vadí.
Vtip je v tom, že na editaci a formátování komentářů/diskuse na root.cz není žádný WYSIWYG potřeba, jakož není ani potřeba nastudovat, jak se používá XHTML (protože to beztak server z větší části sežere), leč jen pár povolených XHTML značek, navíc uvedených v nápovědě pod tím editačním polem.
Byť chápu, že většina zde diskutujících se prostě neřadí mezi zcela běžné uživatele, je to prostě vhodně zvolená vstupní metoda.
Výhodou je, že se to nerozbije jen proto, že někdo nemá správně
nastavený prohlížeč, případně že blokuje scripty
.
Zdejší uživatelé jsou s tím srozuměni - a neotravují administrátory neustálými dotazy, proč zrovna jim nefunguje formátování komentářů
. ;o)
Ty složitější manipulace často mají smysl, zlepšují používání stránky pro uživatele. Takže je obecně zatracovat není rozumné.
Potvrdil jste, že když tady chcete použít formátování, musíte vědět, jak se používá XHTML. Bez toho totiž nevíte nic o značkách, takže nemůžete použít ani těch pár povolených značek.
Jak intuitivní to je se můžete přesvědčit, když se podíváte, jak málo často jsou tu správně vyznačené citace. Někdo místo citace použije <pre>, někdo zobáček > jako v e-mailu.
Pokud si někdo rozbije prohlížeč, je to jeho problém. Když se něco interpretuje na cizím zařízení, musí to zařízení splňovat určité standardy, aby to fungovalo. Kdybyste vyřadil některé instrukce procesoru nebo pozměnil jejich chování, nebudou vám fungovat ani nativní programy. A nebude to chyba jejich autorů.
Však já taky zatracuji především ony nesmyslné manipulace.
Když jsme u těch meníček: bojoval jsem s jedním webem, kam musím, protože to je po mně požadováno, ale který prostě odmítal fungovat. Po přihlášení se nezobrazilo menu, ani žádný obsah.
Reálně ta menu byla na principu: zviditelni vygenerovaný nečíslovaný seznam, nastylovaný pomocí CSS, po kliknutí na odkaz něco udělej (načti stránku...)
.
Jenže místo vygenerování toho seznamu se volaly scripty, které postupně v prohlížeči generovaly ten seznam, kde každý řádek menu sledoval eventy, a fakticky nedovolil prosté odkliknutí odkazu, ale volal jiný script, který provedl přesměrování na stránku, ovšem adresu si bral nikoliv z toho odkazu, ale JSONem načteného seznamu někde jinde.
A nesmím zapomenout na odesílání statistik a telemetrie, který ten použitý framework dělal jen tak mimochodem. (A tam také tkvěla příčina oné nefunkčnosti: máme zablokovaný server, kam chodila telemetrie, ale ten script na začátku prostě čekal, až se připojí...)
A v podobném stylu byl generovaný celý obsah stránky!
Prohlížeč v tom byl úplně nevinně - to jen na proxy cestou je zaříznutý ten server s telemetrií a jiným šmírováním.
A naši bezpečáci mi dali jasně na srozuměnou, že mám na výběr mezi možností pracovat z domova, a nutností dostavit se v noci do 30 minut do práce.
Ono je jednoduché ze všeho vinit prohlížeč, ale některé weby nesnesou ani vypnuté cookies třetích stran
, případně jiné nastavení zabezpečení, než všechno povoleno, prohlížeč je tu Pámbu
.
Takže ne: slušný
web musí fungovat i v prohlížeči s běžnými nastaveními, skrz VPN, za NATem a bez jakékoliv nepodstatné telemetrie!
Není třeba hledat vyhrocené příklady. I u počítačů (a odvozených zařízení) lidé záměrně vypínají některé funkčnosti.
Pravda, zpravidla nemění instrukční sady (pominu-li vitruálky), ale naprosto běžně vypínají některé periferie či blokují přístup k částem systému.
Příkladem budiž mobily, kde v Androidu můžete (někdy musíte) odsouhlasit přístup ke kameře, k poloze, k úložišti... Naprosto běžně, pokud člověk nějakou z těch funkčností nepožaduje či přímo odmítá, prostě dané oprávnění programu nedá.
A - také naprosto běžně - ty aplikace pak mohou odmítnout fungovat. Hloupé je, pokud se tak stane nečekaně, u aplikace, kterou potřebujete, ale která se dožaduje například přístupu k mikrofonu (pro hlasové vyhledávání, které nepoužíváte), nebo k poloze (kterou rozhodně nechcete sdílet).
Případně, pokud naprosto jednoduchá jednoúčelová aplikace začne trvat na běhu pouze on-line
, přestože reálně to k ničemu nepotřebuje.
Trvám na tom, že pokud se program nevyrovná s běžnými omezeními, na které lze narazit, je nedokonalý
, případně od počátku rozbitý
.
Není třeba hledat vyhrocené příklady. I u počítačů (a odvozených zařízení) lidé záměrně vypínají některé funkčnosti.
Pravda, zpravidla nemění instrukční sady (pominu-li vitruálky), ale naprosto běžně vypínají některé periferie či blokují přístup k částem systému.
To nejsou vyhrocené příklady. U počítačů můžete vypínat některé funkčnosti – třeba GPS (nebo to počítač vůbec mít nemusí), tiskárnu, reproduktory… To všechno je něco, co počítač může mít a nemusí a počítá se s tím. Stejně to mají i prohlížeče. Ty mohou podporovat geolokaci, notifikace, ukládání souborů – a můžete to zapínat či vypínat, když to chce web použít, prohlížeč se uživatele zeptá. Prohlížeč poskytuje API, přes které se dá zjistit, zda daná funkcionalita je nebo není k dispozici – a web se tomu může přizpůsobit.
Pak můžete dělat to, že si stáhnete a nainstalujete program, pak mu oeditujete binárku nebo smažete nějaké knihovny. A budete se hrozně divit, že ten program nefunguje správně. Bude to úplně to samé, jako když zasahujete do kódu webové stránky.
Trvám na tom, že pokud se program nevyrovná s běžnými omezeními, na které lze narazit, je nedokonalý, případně od počátku rozbitý.
S běžnými omezeními (nedostupnost nějakého API) se webové stránky obvykle vyrovnají. Zásahy do kódu programu ovšem není běžné omezení.
S běžnými omezeními (nedostupnost nějakého API) se webové stránky obvykle vyrovnají. Zásahy do kódu programu ovšem není běžné omezení.
Však já také nikde nepíšu o zasahování do kódu
, ale opravdu o nedostupnosti například nějakého API. (Například příklad s menu, které se nevykreslí bez dostupného trackovacího serveru...)
Žel, mnohé stránky se nevyrovnají ani s tou nedostupností některých serverů.
(Poznámka: sám nepoužívám žádný AdBlock, vystačím si s běžným nastavením prohlížeče a tím, co nám nastavují naší admini na síti.)
Však já také nikde nepíšu o zasahování do kódu, ale opravdu o nedostupnosti například nějakého API. (Například příklad s menu, které se nevykreslí bez dostupného trackovacího serveru...)
Vzhledem k tomu, že volání HTTP požadavků je v prohlížeči asynchronní a jinak to udělat nejde, je pracnější zobrazení menu navázat na výsledek volání trasovací funkce, než to udělat nezávisle. Nenapadá mne, proč by to někdo takto komplikovaně dělal.
Blokovat na úrovni sítě komunikaci webu (navíc bezdůvodně), který musíte používat, je zvláštní firemní politika.
Nenapadá mne, proč by to někdo takto komplikovaně dělal.
To byste se musel zeptat pachatele toho webu. ;oD
Já předpokládám, že prostě použili nějaký framework, který ten kód vygeneroval.
Ono nebylo přímo navázané zobrazování menu na volání trasovací funkce, ale naopak, po volbě položky z menu se na server odeslala nějaká data. Celý problém tkvěl v tom, že na začátku byla nějaká inicializace, která komunikovala s tím telemetrickým serverem - a ta zhavarovala, takže se dál neprovedlo vůbec nic.
Administrátorsky zablokovaná komunikace není přímo komunikací s tou webovou aplikací, zablokovaná komunikace je se servery, které sbírají telemetrii a mohly by provádět fingertprinting
nebo ze sledování parametrů připojených počítačů detekovat topologii a nastavení vnitřní sítě. Je to relativně krátký blacklist - a většinou to vůbec ničemu nevadí.
Takže to blokování není rozhodně bezdůvodné
!
Že se s tím občas svezou weby, postavené na Google službách (Analytics, TagManager...) je jiná věc.
Zbytečně slovíčkaříte. Opravdu není potřeba vědět, jak se používá XHTML, dokonce není třeba ani tušit, co to znamená - úplně stačí ovládnout používání těch pár značek.
A že si lidé pletou <q>, <pre> a <code> jen dokazuje, že mnozí to XHTML opravdu neovládají. ;o)
A pokud pro citace používají >, pak obvykle odpovídají čistě textově - a ani pokročilý editor by jejich počínání nezměnil.
Opravdu není potřeba vědět, jak se používá XHTML, dokonce není třeba ani tušit, co to znamená - úplně stačí ovládnout používání těch pár značek.
Když nevím, jak se XHTML používá, tak značky napíšu třeba jako {code}kód{code} – a nebude to fungovat. Bez znalosti toho, jak se XHTML používá, to zkrátka nejde. Nemusím znát celé XHTML, ale musí umět XHTML používat – vědět, co znamená v XHTML značka a jak se zapisuje.
A pokud pro citace používají
>, pak obvykle odpovídají čistě textově - a ani pokročilý editor by jejich počínání nezměnil.
Tady všichni odpovídají čistě textově, protože tu jiná možnost není. Pokročilý editor se samozřejmě může chovat tak, že když uživatel zadá > na začátku řádku, zapne se styl citace. I velmi jednoduché editory komentářů fungují tak, že označíte kus textu ve zdrojovém komentáři, zmáčknete tlačítko citace a vloží vám to správně zformátovaný citovaný text do editačního pole.
Pořád směšujete znalost používání těch několika vyjmenovaných značek se znalostí (alespoň částečnou) XHTML.
Na to, abych mohl formátovat příspěvky, opravdu nemusím o XHTML nic ani tušit. Dokonce ty značky by ani nemusely z toho XHTML vycházet - setkal jsem se i se zápisem [q], aby se zjednodušila kontrola vstupu.
Pokud by mi pokročilý editor
o své vůli změnil > na začátku řádku na <q>...</q>, považoval bych to za chybu či velmi nechtěnou vlastnost - a varoval bych se něco takového dobrovolně používat!
Ano, jsou případy, kdy to má smysl, ale diskuse na root.cz by tím IMHO zaplevelena být neměla. Jsem velmi rád, že zdejší server funguje i na obskurním menšinovém prohlížeči
, v omezeném prostředí, a s osekanými scripty!
Pořád směšujete znalost používání těch několika vyjmenovaných značek se znalostí (alespoň částečnou) XHTML. Na to, abych mohl formátovat příspěvky, opravdu nemusím o XHTML nic ani tušit.
Ne, já to nesměšuju. Nejprve musíte vědět, že XHTML používá princip nějakých textových značek, jak se v XHTML značky zapisují – a teprve pak můžete řešit znalost či neznalost konkrétních značek. Přičemž které značky tu můžete použít se dozvíte po formulářem přidání komentáře, pokud znáte XHTML, měl byste vědět, jak zjistit, co ty značky dělají. Ale pokud nevíte nic o XHTML, je vám ta poznámka úplně k ničemu.
Dokonce ty značky by ani nemusely z toho XHTML vycházet - setkal jsem se i se zápisem [q], aby se zjednodušila kontrola vstupu.
Ale to je to, o čem celou dobu píšu. Tady nemůžete použít [q], jediná povolená možnost je <q>. Takže musíte vědět, že XHTML jsou nějaké značky v čistém textu a jak se ty značky zapisují.
Pokud by mi pokročilý editor o své vůli změnil > na začátku řádku na
...
, považoval bych to za chybu či velmi nechtěnou vlastnost - a varoval bych se něco takového dobrovolně používat!
To je hezká teorie. Zkuste si všimnout, jak v praxi fungují editory, které uživatelé rádi používají (třeba Notion, Slack, MDX editor).
@ Filip Jirsák
[...] To API není ve V3 dostupné proto, že zpomaluje stránky a neumožňuje to prohlížeči provádět některé optimalizace při zpracování stránek [...]
jeste sem nevidel stranku ktera by byla s V2 uBlockOrigin + V2 PrivacyBadger pomalejsi nez bez nich, naopak s temi rozsirenimi je to casto 10-100x rychlejsi ;-)
"To API není ve V3 dostupné proto, že zpomaluje stránky a neumožňuje to prohlížeči provádět některé optimalizace..."
Nikoliv. To API není ve V3 dostupné proto, aby nikdo nemohl házet Gůglákům vidle do jejich šmírovaní (a na něj navázané reklamy).
Tak, opraveno.
(+ jak už upozornili ostatní: kdyby Gůglákům záleželo na rychlosti, tak nebudou bránit filtrování těch největších zpomlaovačů v podobě internetové reklamy)
14. 10. 2024, 21:23 editováno autorem komentáře
On uBlock Origin Lite je v podstatě podmnožina uBlock Origin, která funguje ve V3.
Mimochodem, v článku je napsáno, že uBlock Origin Lite je od jiného vývojáře -- ale v https://github.com/uBlockOrigin/uBOL-home/commits je jako autor uvedený gorhill (Raymond Hill), což je autor uBlock Originu, takže myslím, že je to od něj.
Testoval jsem Lite asi před dvěma měsíci, když to rušení V2 oznámili.
Bohužel to zatím vypadá, že podoba Lite ve stávající úplně ořezané podobě (on-off per stránka, tři levely blokování) je asi finální.
R. Hill je na Google spíš naštvaný (logicky) a nechce se mu trávit čas paralelním vývojem funkčně schopnějšího uBlock Origin pro Firefox a zároveň vývojem té Lite verze v rámci omezení V3 manifestu.
Což je škoda, protože já nejspíš z Chrome a Blink based browserů neodejdu a v Lite mi chybí spousta věcí, které by neměly být omezené V3 manifestem a v Originu mi usnadňují život. Třeba synchronizace nastavení a whitelistů přes účet Google. Ve whitelistech pak dost často používám regexy, např. na své servery, všechny privátní rozsahy atp. Případně upravená pravidla atp.
Když jsem o tom přemýšlel, klidně bych mu posílal i donation, kdyby se do toho pustil. Protože ty různé alternativy (AdGuard atp.) mě moc dobré nepřišly, ale možná budu ještě dál zkoušet..
Já tam nemám asi žádnou killer feature, kterou bych jednoduše vypíchnul.
Používám Chrome jako primární, Firefox pak jako sekundární prohlížeč. Je tam i nějaká historie, kdy Chrome s Google službami používám opravdu dlouho, mám tam většinu přihlašovacích údajů, co se mi synchronizují napříč platformami - (včetně iOSu, kde se z Chrome můžou brát hesla do ostatních aplikací, což bylo na FF, resp. Lockwise problematické, ale už jsem to nějakou dobu nezkoušel).
Navíc se pracovně setkávám s řadou web. aplikací, které jsou oficiálně vyvíjené a podporované na Chromu (resp. Blink enginech, Electronu). Typově se jedná třeba o webové střižny videa (pracují s lowres videem), různé webové editory na grafiku pro specifické proprietární systémy, webové ovládací panely k zařízením (streamovací krabice). Ne že by to en-bloc nechodilo na FF, ale poměrně zhusta to využívá JS API pro práci s canvasem, médii, někdy i Web Assembly a kolikrát stačí i nějaká drobná implementační odlišnost mezi prohlížeči, kterou nikdo netestoval a neřešil, nemusí to fungovat 100%. Což samozřejmě není ideální, ale je to bohužel realita.
A ano, mohl bych si to samozřejmě otočit, primárně používat FF a až když se mi bude zdát, že něco nejede jak má, tak si vybrané aplikace otevřít v Chrome.
Pak bych možná i přidal, že se mi v Chrome zdá lepší PDF prohlížeč, než ten JS ve FF. Samostatnou aplikaci používám málokdy.
Na druhou stranu FF mi v poslední době přijde také fajn, třeba kontejnery pro izolaci jsou bezva, vestavěný reader mode super, lepší video PiP (které se dá narozdíl od Chrome na Waylandu zapnout always-on-top).
Ale beru, že má každý individuální preference, je tam spousta aspektů.. A věřím, že pro někoho může být klidně rozhodující jeden chybějící doplněk.
@RDa A co je na Chrome tak uzasneho co treba Firefox nema?
tim ze to drive ci pozdeji postihne nejspis vsechny na Chromium zalozene, tak odpovim z me praxe...
na Vivaldi je uzasne vsechno, a vetsinu z toho Firefox nema a nikdy mit nebude ... maximalne neco z toho (uz ma ci mozne nekdy bude) jako 3rd rozsireni
A co je na Chrome tak uzasneho co treba Firefox nema?
Nechce se mi znovu vypisovat vsechny veci co ma at uz je pouzivam nebo ne,
a nedari se mi najit kde sem to (uz nekolikrat) v minulosti vypisoval :-)
Takze jen z prehledu https://vivaldi.com/cs/features
Vypichnu par tech co pouzivam:
# nekonecne moznosti customizace
https://vivaldi.com/blog/10-ways-to-customize-vivaldi/
# seskupovani listu s nekolika moznostmi zobrazeni
https://help.vivaldi.com/desktop/tabs/tab-stacks/
# pracovni prostory
https://vivaldi.com/cs/features/workspaces/
https://help.vivaldi.com/desktop/tabs/workspaces/
# dlazdicovani nekolika listu dohromady
https://vivaldi.com/blog/view-multiple-web-pages-side-by-side-no-extensions/
# poznamky
https://help.vivaldi.com/desktop/panels/notes/
# snimek cele stranky
https://help.vivaldi.com/desktop/tools/capture-a-screenshot/
# meritko stranky (je per stranku, NE per domenu jako firefox)
https://help.vivaldi.com/desktop/tabs/zooming-options-in-vivaldi/
# rychle prikazy pres F2, vcetne definovani skupiny prikazu co se provedou najednou
https://vivaldi.com/blog/quick-commands-guide/
https://help.vivaldi.com/desktop/shortcuts/quick-commands/
https://help.vivaldi.com/desktop/shortcuts/command-chains/
Bodove me napada jester treba:
- urceni kde se otevre novy list, ci kam se ma prepnout po zavreni aktualniho
- obsahuje editor temat, kde si presne urcim jakou barvu chci, polomer zakulaceni, jestli ma
brat barvu accentu ze stranky, atd
- ma podpory gest mysi vcetne editoru vlastnich gest (coz pravda uz nevyuzivam, tim ze roky nepouzivam mys)
- ma editor klavesovych zkratek s moznosti priradit ukonu vice nez 1 zkratku
- ma nativni volbu pro moznosti hibernace nepouzivanych listu
- moznost mit ucha listu zmensovane donekonecna (preferuju), nebo od urcite poctu s posouvanim (jako ff)
- detailni nastaveni co se deje pri prani do adresniho radku, lze vypnout/zapnout ci preorganizovat z ceho bere vysledky (z historie psani, prohlizeni, bookmarku, prezdivek, nejcastejsich, synchronizovanych z jinych zarizeni, atd)
a dalsi tipy treba tady:
https://vivalditips.com/cs
EDIT: tak nakonec sem 2 me souhrny o Vivaldi z minulosti take nasel :-)
1. https://www.abclinuxu.cz/zpravicky/vivaldi-4.1#3
2. https://www.root.cz/zpravicky/chrome-zapina-kontroverzni-privacy-sandbox/nazory/#o1125987
15. 10. 2024, 13:10 editováno autorem komentáře