Új hozzászólás Aktív témák
-
martonx
veterán
válasz
lanszelot
#7769
üzenetére
Ma reggel végre jobban ráértem, és megnéztem, és igazam volt
A hosting szolgáltatód a szar. Az egyik videó 85 kbyte, a másik 10 mbyte. És döbbenet, de a 10 mbyte-os videó kiszolgálása gyakorlatilag kifog az esetek többségében a garázs hostingon (nálam pl. most azóta képtelen vagyok letölteni a videót, pedig bizonyításképpen feldobtam volna Azure Storage-ba), mióta írom ezt a hosszú választ.![;]](//cdn.rios.hu/dl/s/v1.gif)
Ez megmagyarázza azt is, hogy van akinek, és van amikor működik (pláne, ha egyszer be is cachelte a böngészője). Mert olyankor a garázs hostingnál éppen megy az internet, éppen működik a Józsi lába mellett lévő Intel Pentium I-es szervernek kinevezett gép.
Máskor meg lemegy az áram a garázsban, Józsi véletlenül belerúg a 20 éves gépbe a lábánál, olyankor meg a 10 mbyte-os videó kiszolgálása meghaladja a garázs hosting képességeit.
Könyörgök, ne legyél hülye, töltsd fel felhőbe (Azure Storage, vagy AWS S3 vagy Google Cloud Storage) és hidd el, amellett, hogy ingyenes, még csodát is fogsz látni, hogy jéé működni fog a nagy videód is
Sőt mi több, a normális felhős hosztingok használatával egy csomó szívástól, megmagyarázhatatlan furaságtól meg fogod kímélni magad, és így mindenki mást is.
-
martonx
veterán
válasz
lanszelot
#7759
üzenetére
De ha mp4-ként stabilan mindenkinél jól működik (ellenőriztem, nálam is működik), akkor miért görcsölsz a webm-en?
Autoplayhez segítség: Autoplay guide for media and Web Audio APIs - Web media technologies | MDN (mozilla.org)
Megnéztem a hyperphp hostingot, az egy vicc a felhős szolgáltatókhoz képest. Ez a hosting tényleg vagy működik vagy nem, vagy gyors vagy nem. Ahogy nyomkodtam a videóidat óriási szórást mutatott, hogy a noname hyperphp hajlandó volt-e éppen gyorsan kiszolgálni a média lekérést vagy éppen megmakacsolta magát.
[ Szerkesztve ]
-
martonx
veterán
válasz
lanszelot
#7762
üzenetére
"Illetve ha gombbal töltöd be akkor bele se kell tekerni." - nem, a videó nem működik.
"Illetve ha gombbal töltöd be akkor bele se kell tekerni." - írtam, hogy gombbal betöltéskor sem jó, nem tudom nálad olyankor miért jó. Akkor ismét leírom, nem ilyenkor sem jó, mert a videó nem jó
"Mind a két linket feltettem, az oldal betöltést és a gombnyomást is." - bizony, mindkettő pont ugyanúgy működik, mégpedig, hogy a második videó nem jelenik meg, mert nem jó a második videó.
"Hogy oldja meg a videó problémát egy gomb?" - sehogy, ugyanis a második videó nem jó.Remélem így már átment az üzenet, és elkezded reálisabban látni a helyzetet? Ennél konkrétabban nem tudok rámutatni, hogy hol a probléma
Egy a kérdés, hogy nálad a gombbal betöltésnél vajon miért működik. Lehet valami spéci böngészőt használsz, valami fura oprendszerrel, vagy ki tudja, mert semmi részletet nem küldtél, csak a saját hülyeségedet szajkózod.
Én windows 11, latest Chrome-al írtam a fenti észrevételeket. -
martonx
veterán
válasz
lanszelot
#7758
üzenetére
Pont ugyanúgy nem működik ezt sem. Nem kifogott mindenkin, hanem leszarod, hogy mit pofázunk. A második videóval valami kurvára nem jó, de szard le nyugodtan, csak akkor meg ne várd, hogy megoldódik.
Másold be az url-jét simán a böngészőbe, akkor se töltődik be Ééééérted? -
martonx
veterán
válasz
lanszelot
#7752
üzenetére
Nézd, ha simán a két videó url-jét beírod a böngésző címsorába, akkor látszik, hogy az első bejön, a második nem jön be.
Hogy miért nem azt mi nem fogjuk tudni neked megmondani. Talán mert nincs ott az útvonalon (bár ekkor 404-et kellene kapjunk), vagy tudomisén, lehet meg kellene kérdezni a garázshosting cégedet, hogy szerintük miért nem érhető el ez a videó. -
martonx
veterán
Pont, hogy marhára nem az osztályokon, és a js szintakszison múlik. Mostanra pl. egész jól lehet js-ben is OOP elveket használni, nem ettől szar még mindig. Hanem az egy szálon futástól, meg a html bindolási lehetőségek teljes hiánya miatt (bár már ez sem teljesen igaz, mióta kijött a Webcomponent js-be).
-
martonx
veterán
Uh, a react még mindig mennyire undorító szintaktikájú (számomra legalábbis, tudom másoknak meg pont ez a katyvasz fos jön be)
Ráadásul ez a példa is de béna, már miért kellene mindent annyiszor leírni react nélkül, ahány todo elemet jelenítünk meg
Ettől még bőven van létjogosultsága a reactnak, csak ezen a konkrét magyarázaton röhögök, -
martonx
veterán
Hol van az oldal leírása? Simán előfordul, hogy a meta tag-et ignorálja a google.
Hogy mikor mit rak ki, az nem büntetésből van, mikor mit gondol éppen relevánsnak.
Jól látod duplikált tartalomhoz ez a tag a megoldás. Mondok egy példát.
Webshopban van egy terméked, aminek van 10 különböző színű változata, de igaziból mind a 10-hez ugyanaz a szöveg, minden ugyanaz van feltöltve, kivéve a képet, meg mondjuk a termék nevét (férfi ing piros, férfi ing zöld stb...).
Ekkor a google hátrébb fog sorolni, mondván, hogy te direkt optimalizálni akarsz a férfi ing szavakra, csináltál csomó kamu url-t, miközben mindegyiken ugyanaz van, azaz szerinte csalni akarsz.
Ekkor jön jól, hogy a canonical tag-el meg tudod mondani, hogy ezek összetartoznak, és jelezni tudod, hogy melyik az indexelendő, és melyek az ismert "duplikátumok".
Vagy másik példa mikor egy oldalad van, de az X nyelven Y url-en elérhető, és igaziból mindegyik pont ugyanazt tartalmazza. Ekkor is jól jön, hogy meg tudod határozni, hogy melyik az igazi.Ennek ismeretében döntsd el te, hogy neked ez kell-e vagy sem.
-
martonx
veterán
Az XMLHttpRequest a legrosszabb választás. Az axios elméletben lehet jó választás, ha tudod mire kell, és mi az a plusz funkciója, ami miatt mindenképpen szükséged van rá (nodejs világban azaz szerver oldalon szokták automatikusan behúzni, mert ott lényegtelen plusz 20kbyte bundle size, illetve rémlik, hogy abban nincs a böngészős Fetch API).
Kliens oldalon, ahol minden kbyte js számít(hat) a pagespeed miatt, eléggé életbevágó tud lenni, hogy behúzol-e plusz 20kbyte-ot, csak azért, amire egyébként ott van a Fetch API.
És ezzel meg is válaszoltam, hogy igen a Fetch API használata a jó megoldás böngészőben. -
-
martonx
veterán
"Vagy ilyenkor az a teendő, hogy oké, átdobom a főoldalra, de nézem, milyen linkről érkezik, és ha van ilyenem (JS által kezelve), akkor módosítom az URL-t, kvázi beírom vissza, miután már a főoldalra került, plusz az aloldal-1-hez tartozó JS-t is futtatom, hogy "azt a látszatot keltse", mintha valóban az aloldal-1-re navigált volna?"
Nem átdobod, hanem ilyenkor a főoldalt küldöd vissza szerver oldalról, azaz az url nem is fog változni
Sőt, ettől kezdve már nem is lesz semmi másod csak a főoldalad.
Utána a többi stimmel, mivel az url nem is változott, a főoldalon futtatod a JS-edet, ami úgy fog tenni, mintha az aloldal-1-re navigált volna, ebben a kliens oldali routeolásban tud nagy segítség lenni a többször emlegetett page.js (hiszen végülis pont ez történt, az url nem is változott, eleve ezt az oldalt kérte az ember, hiszen ezt az url-t írta be).
Ezt a működést hívják SPA-nak: Single Page App-nak. -
martonx
veterán
válasz
laracroft
#7580
üzenetére
Semmi oka nincs, szvsz ez vagy hiba a szabványban, vagy a Chromium implementálja hibásan a szabványt.
Nem próbáltam ki Firefox-ban (mivel az az egyetlen nem Chromium-ra épülő böngésző), ha az is enged 6 karaktert beírni, akkor a szabvány a hibás.
De lehet, hogy csak jövőtálló megoldást akartak, hogy mondjuk 123456-dik évben is működjenek az évszámok... -
martonx
veterán
Szerintem ezt keresed: Using the viewport meta tag to control layout on mobile browsers - HTML: HyperText Markup Language | MDN (mozilla.org)
És igen ez alap böngésző tudás, amit ezzel tudsz szabályozni, hogy mit is csináljon. -
martonx
veterán
Két dolgot javaslok:
1. koncepcionálisan felejtsd el ezeket a szuper spéci kontrolokat. Minél natívabb html-el oldod meg, annál biztosabban fog működni mindenen is
2. ha mégis valami spéci kell, akkor állj bele, és csináld meg magadnak nulláról pl. ul-li-kkel felépítve, körbe css-ezve, legvégső esetben js-el megtámogatva. -
#7541
martonx
veterán
BigBlackDog
#7540
martonx
veterán
válasz
BigBlackDog
#7540
üzenetére
css grid vagy flexbox
-
martonx
veterán
"Valójában a lementés módja lett volna kérdéses"
Http request beesik a szerverre, ebben van egy querystring paraméter, amit kiszedsz belőle, és lemented egy adatbázisba. Ennél konkrétabban majd az általad használt szerver oldali nyelv topikjában fogják tudni elmondani neked (bár legjobb lenne magadtól utána olvasnod), hogy adott nyelven hogy kell adatbázist használni.
-
martonx
veterán
Gondolom ezt a trackinget bizonyos kampányaikba elhelyezett linkjeiknél használják. Ezután szerver oldalon nincs más feladat, mint figyelni a beeső http requestet, és logolni, hogy melyik tracking kóddal mennyien érkeznek. Így az oldal tulajdonosa a későbbiekben ki tudja elemezni, hogy melyik kampánya volt a legeredményesebb, mire érdemes költenie, és mi csak pénzkidobás.
-
martonx
veterán
rel="canonical"
Teljesen másra szolgál. Ez arra való, hogy a Google SEO ne pontozzon le azért mert duplikáltnak véli a tartalmadat, miközben te csak más termék variánsnál jeleníted meg ugyanazt a szöveget, vagy csak az url-ben más egy szegmens pl. nyelvesítés miatt.
Nagyon jó, hogy próbáltok egymásnak segíteni, de ez így erősen vak vezet világtalant helyzet. Ha valamiről fogalmad sincs, akkor nem kötelező megpróbálni válaszolni. Mondjuk azt se bánnám, ha rajtam kívül mások is aktívabban segítenének a kezdőknek.
-
martonx
veterán
"Lehet, tévedek, de szerintem azok az oldalak nem a kiterjesztést "tüntetik el", hanem az egész fájlnevet."
Részben tévedsz. A normális routinggal rendelkező webappoknál eleve értelmezhetetlen az egy file egy url felálllás. Aztán, hogy ez egy SPA-ságból fakad, vagy olyan backend frameworköt használunk, aminek van routingja, az mindegy is.
-
martonx
veterán
Ez pontosan így van, nem véletlenül külön ágak a backend, frontend, designer a webfejlesztésen belül. Én mondjuk fullstack vagyok, de aki azt mondja, hogy úgy fullstack, hogy mindenhez IS ért, az vagy nem tudja miről beszél, vagy hazudik
Azért nagy szerencséd, hogy az utóbbi 1-2 évben drasztikusan fejlődött a böngészők kompatibilitása, illetve maga a CSS is. Pár évvel ezelőtt CSS-ezni full agyfasz volt.
Bonyolult esetekbe még manapság is bele lehet persze szaladni, de egyre ritkábban. -
martonx
veterán
Átalakítottam ilyenre: Edit fiddle - JSFiddle - Code Playground
Nem jó gyakorlat br-t használni távtartásra. Illetve ne használj mindenre id-t, mikor másféleképpen is tudsz rá hivatkozni.
A magyarázat pedig itt van leírva: display - CSS: Cascading Style Sheets | MDN (mozilla.org)
Nem szégyen dokumentációt olvasni (egyébként én se tudom a választ, nem vagyok egy nagy CSS guru, én is MDN-ből szoktam puskázni ). -
martonx
veterán
De miért ehhez form???
Hidd el, a keresés akkor is fog működni, ha nem formozol. És akkor nem kell meghágni az onsubmit-ot sem, sem azon aggódni, hogy mi lesz, ha több form is lesz az oldalon
Mert ha jól gondolom, úgyis a gomb nyomására küldöd el az inputban lévő szöveget a szerver oldalnak ajax-al.
Ehhez nem kell form[ Szerkesztve ]
-
martonx
veterán
Mindegyik fontnál van lassulás. Ez alól az egyetlen kivétel a web safe fontok. Mivel azokat letölteni sem kell
Viszont ezekkel a lassulásokkal azért együtt lehet élni (mármint a variable fontokéval, a normál web fontok engem zavarnak).Vannak azért ingyenesek is: Variable Fonts: A 101 Introduction (+ Free Variable Fonts to Try) | Design Shack
-
martonx
veterán
2021-et írunk. Csakis Variable Fontokkal fuss neki bárminek is. Ezek előnye, hogy a böngészőnek csak egyszer kell letöltenie, és utána kedvedre gyurmázhatod.
Az egyéb normál fontokat ugyan kicsivel kisebb méretűek, mint egy variable font, viszont ezekből kismillió verziót kell letöltenie a böngészőnek.
Pl. variable font 200kbyte, ezt egyszer kell letölteni. Sima font csak 150kbyte de külön le kell tölteni a 150kbyte-ot, normál szöveghez, dőlt szöveghez, vastagított szöveghez stb...A web safe fontok is jó választás lehet, viszont borzasztó limitált az olyan font, ami minden gépen ott van.
variable font választó pl: Variable Fonts (v-fonts.com)
-
martonx
veterán
Ez így vajon milyen? Edit fiddle - JSFiddle - Code Playground
Flex-el igazítottam, meg kicsit a html struktúrát is átdolgoztam, olyan fura, hogy ha egy elemen belülre akarsz rakni valamit, és te hozod létre a html struktúrát, akkor miért nem rakod bele ténylegesen a belerakandó div-et? Miért vele egy szintre rakod, és utólag pozícionálgatod?[ Szerkesztve ]
-
martonx
veterán
-
martonx
veterán
Pedig ideje lenne elkezdeni
Találtam egy ilyen oldalt, ha nem is a legnaprakészebb, de elég jó átfogó képet ad a mobil eszközök felbontásaihoz:
Viewport Size by Device / Phone Screen Dimensions | Viewport Sizer ToolEnnek a megoldásnak az energiakímélés, gyorsabb működés a lényege. A telefonnak elég csak pl. 360X640-es felbontáson kiszámolnia, hogy hogyan is fog kinézni az adott weboldal, és utána ezt felskálázza a fizikai megjelenítőre. Könnyű belátni, hogy mennyivel gyorsabban ki tud renderelni 360X640 pixelt, mint 1440X2560 pixelt (hogy a linkem legelső példájánál maradjunk).
-
martonx
veterán
A head-be rakni bad practice. Miért?
Mert a script feldolgozás mindig lassú, és addig az egész utána következő html feldolgozás, css alapján rendering beblokkolódik. Mondjuk ez az async defer kapcsolókkal elvileg kezelhető. De ha több scripted van, amiknél fontos lenne az egymásra épülés, akkor az async defer-el csak megszívatod magad.
Szóval az a tuti, ha a body végére rakod a scriptjeidet. Ettől még az async defer-t ekkor is érdemes lehet használni.
De ettől még nyilván teheted head-be, nem depreciated, csak a fentiek alapján rossz gyakorlat. -
martonx
veterán
válasz
gyulank
#7368
üzenetére
Szerinted tényleg tudnunk kellene az 1-es pontra válaszolni? Ha te szerkeszted a hang.hu-t, akkor nyilván semmi nem gátol abban, hogy behúzz plusz egy css-t, amivel overrideolod, amit jólesik.
Ha nem te vagy a hang.hu szerkesztője, sincs minden veszve!
Csak fel kell törnöd a rendszerüket, és átírnod a kódjukat, hogy kezdje el használni az odacsempészett extra css file-t. Elnézést, ha hülye kérdésre hülye válasz született. -
-
martonx
veterán
Ja, hogy még mindig ez a baj?
Egyrészt a Facebooknak van egy egész jó tool-ja, amivel meg tudod nézni, hogy mit fog látni FB a belinkelt oldaladból: Sharing Debugger - Facebook for Developers
Másrészt, miért lenne már broken az og:image? Ha szétnézel, mindenhol ezt használják, FB is ezt használja, neked is ezt kell használnod. De ez szépen fog látszódni a fentebb linkelt FB Sharing Debuggerrel.
Ez amit most használsz: og:image:secure_url szerintem sehova nem kell.
-
martonx
veterán
válasz
lanszelot
#7315
üzenetére
Innen indultunk: [link]
Erre mondtuk, hogy ezt így nem lehet megcsinálni, ráadásul valószínűleg illegális is. Te meg végül tök mást csináltál (autoplay-el megy a videó, és abszolút sehol, semmire nem lehet kattintani), és azóta is büszke vagy rá, hogy végülis ez is megteszi, az se baj, ha esetleg illegális.Szóval neked hála megint sikerült így éreznem magam: [link]
-
martonx
veterán
válasz
lanszelot
#7308
üzenetére
És ki is próbáltad ezeket a generátorokat? Mert én igen, és ezek sem tudják letiltani azt, amit 2018 óta a YT nem enged
Nahát. Szóval továbbra is várok tőled linket, hogy lássam mindezt működni. Vagy valami szörnyű félreértés áldozatai vagyunk, és még mindig nem fogtuk fel, hogy mit szeretnél. De végülis már mindegy is, ha közben megtaláltad a működő megoldást. -
martonx
veterán
Szólok, hogy már jó pár éve nem a Microsoft miatt kell aggódni, hanem az Apple miatt. Azaz, amit Chrome-ra fejlesztesz, szinte biztos, hogy az újabb Edge-ekben szépen menni fog. Ellenben, amikor megnézed iphone-on, akkor jön a bazdmegelés.
A Safari korunk Internet Explorere. -
martonx
veterán
Fogsz egy képet, ami mondjuk egy gif. Alapból elrejted (display: none; ). Ha várni kell megjeleníted. A megjelenítés 1 sor javascript.
document.getElementById('valami').style.display = 'block';
Ha pedig már nem kell várni, megint elrejted:
document.getElementById('valami').style.display = 'none';
Nem tudom, ez mennyire számít programozásnak, szerintem ennél egyszerűbb megoldás nincs.
-
martonx
veterán
válasz
agoka07
#7246
üzenetére
A html emailnél nincs nagyobb szívás. Szerencsére vannak hozzá elég jó szerkesztők, mint pl ez: https://www.litmus.com/
Pontosítok, ezek fizetősek, de van egy elég hosszú trial időszakuk, az bőven elég összehozni az aláírást. -
martonx
veterán
"Azért HTM jelenleg, mert nincs PHP szerver telepítve a gépre (nem is lesz) és nem akarom minden módosítás után feltölteni a Web-re, hogy lefuttatva lássam, mit is b***tam el. Így HTM-be csinálom meg az alapot, ha az jó, akkor váltom át PHP-re és írom meg a PHP tartalmat."
Hát ez így rohadtul hatékonynak tűnik
-
martonx
veterán
1. el kellene kezdened ismerkedni a javascripttel is
2. passz PHP-s kókányoláshoz nem értek, hátha majd valaki más
3. ezt nem értem mi lóg ki, viszont a footert érdemes lenne a lap aljára "ragasztanod", a scrollozást meg engedni.
4. erre jól jönne egy jsfiddle példa
5. nem akarok beleokoskodni, de nem-e jobb lenne elkezdeni több kisebb txt file-t használnod?Önképzésre egyébként teljesen jó amit csinálsz, én mégis javasolnám, hogy állj át egy static site generátorra, ugyanazt fogja tudni, mint a te mostani megoldásod, csak profibban. Illetve ha ezt az oldalt a publikumnak szánod, akkor én a helyedben nagyon komolyan rámennék a SEO-ra.
-
-
-
#7150
martonx
veterán
E.Kaufmann
#7149
martonx
veterán
válasz
E.Kaufmann
#7149
üzenetére
A tudomány jelenlegi állása szerint a html <table> pont az ilyen problémák miatt eléggé kiment a divatból. Helyette a css3 grid layout a menő: [link]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- A fociról könnyedén, egy baráti társaságban
- Fűzzük össze a szavakat :)
- Áprilisban várható az iOS 18.4
- Budapest és környéke adok-veszek-beszélgetek
- One otthoni szolgáltatások (TV, internet, telefon)
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Bittorrent topik
- Ukrajnai háború
- Vivo X200 Pro - a kétszázát!
- Politika
- További aktív témák...
- Apple iPhone 13 Mini 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 13 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Apple II, kompakt Macintosh javítása
- LENOVO THINKPAD E16 G1 - Ryzen 5 7530U, 16, 512 GB, 16GB, Fémházas üzleti laptop 16" kijelzővel
- AMD Konfig - MSI X470, Ryzen 7 3800x, Vega 56, 32 GB RAM, 512 GB SSD