Hirdetés
- iPhone topik
- Megjött a jubileumi Pixel széria
- Xiaomi 14 - párátlanul jó lehetne
- Nothing Phone (3) – tervezett kaotika
- Hamarosan itt az Amazfit T-Rex 3 Pro – fotók, infók az új óráról
- Megdöntheti az iPhone 4 rekordját az iPhone 17
- Xiaomi 13 - felnőni nehéz
- Honor Magic6 Pro - kör közepén számok
- Huawei P30 Pro - teletalálat
- Google Pixel topik
Új hozzászólás Aktív témák
-
#6199
Sk8erPeter
nagyúr
BitMiller
#6198
-
BitMiller
csendes tag
Tiszteletem!
Van olyan HTML szöveg igazítás (mely a DreamWeaver-ben is kattintgatható), hogy "Text Indent". (Beilleszt egy Block Quote részt a kódba). Megadható-e CSS nélkül, tehát simán HTML formátumban az, hogy milyen mértékben (hány pixellel) húzza beljebb a szöveget 1 db Block Quote?
-
#6196
honda 1993
senior tag
PumpkinSeed
#6195
honda 1993
senior tag
válasz
PumpkinSeed
#6195
üzenetére
''Ezt amúgy ne vedd komolyan, csak a szarkazmusom kimutatása végett írtam le. ''
Nos, orulok hogy ezt igy a vegere azert megirtad, mert mikozben olvastam, csak neztem hogy megis mi a pi..-rol beszelsz ? XD
-
#6195
PumpkinSeed
addikt
honda 1993
#6176
PumpkinSeed
addikt
válasz
honda 1993
#6176
üzenetére
Hogy lehet ilyet kérdezni már elnézést?Érdemi megnyilvánulás. Ajánlott úgy megcsinálni, hogy 5 html fájlnál ne legyen több és ha már 5MB főlé megy egy HTML fájl mérete akkor érdemes új állományban írni a további részeket. Ha egy weboldal több mint 5 html fájlból áll akkor érdemes úgy összeállítani, hogy minden állomány egy őt meghatározó mappában legyen. De nagyon ajánlott ezt az 5x5-s szabályt betartani, mert gyorsabb lesz a honlapod.
Ezt amúgy ne vedd komolyan, csak a szarkazmusom kimutatása végett írtam le.
-
#6194
Jim-Y
veterán
honda 1993
#6191
Jim-Y
veterán
válasz
honda 1993
#6191
üzenetére
Röviden, NEM. Meg kéne már érteni -nem neked, hanem úgy anblokk-, hogy nem csak PHP létezik
-
#6193
Sk8erPeter
nagyúr
honda 1993
#6187
Sk8erPeter
nagyúr
válasz
honda 1993
#6187
üzenetére
"Nem tudom hogy mennyire ertheto amit szeretnek mondani"
Mondd el úgy, hogy érthető legyen, mit akarsz mondani.
Egyébként szerintem te nem értetted meg, amit magyaráztam. Mostanában érzem, hogy tök feleslegesen pötyörészek annyit, asszem kicsit megpróbálom inkább passzívan követni a topicot (vagy egyáltalán nem), mert kezd tököm tele lenni a színvonal alattisággal, az értelmetlen és magyartalan mondatokkal, a helyesen írni és kérdezni sem tudással. -
#6192
cidalain
veterán
honda 1993
#6191
cidalain
veterán
válasz
honda 1993
#6191
üzenetére
Figyuz, ha nulla előképzettséged van PHP-ból, és MySQL-ből akkor nem fog menni egy login és egy fórum összerakása. Vagy ha szorgalmasan utánaolvasol, és tanulod a PHP-t, akkor talán két hónap múlva lesz valami használható "izé", aminél mondjuk lehet beírni valamit valahova. (de ez azért messze nem egy fórum még)
Van egy csomó ingyenes fórummotor, letöltöd, kicsomagolod, felmásolod a tárhelyre, és installálod a leírás szerint. És utána használod a leírás szerint. De ezek egy univerzális sablon köré épülnek, szóval nem lesz egyedi fejléc, meg ilyesmi. Ezt neked kell elkészítened, és testre szabnod.
No ez innentől megintcsak nem megy PHP, és MySQL ismeret nélkül, viszont ezeknek a kódja már nem alapszintű, és nem kedveli a motor a buherálást sem. Pl én nem állnék neki bolygatni, pedig láttam már PHP kódot, és írok is folyamatosan. Mondjuk a HTML sablon még "könnyen" módosítható, így ha megelégedsz azzal, hogy van egy fórumod, ami működik ahogy, és kinéz ahogy (esetleg kicsit módosítasz), akkor ez kell neked.
-
#6191
honda 1993
senior tag
cidalain
#6190
honda 1993
senior tag
válasz
cidalain
#6190
üzenetére
Na annak orulok hogy ezt megkerdezted, ugyanis en pont most irtam valamit a php forumba.
A lenyeg hogy nem tudom hogy pontosan hogy is kell ezt elkezdeni.
Pl ha esetleg elmagyaraznad hogy hogy is mukodik az altalad javasolt megoldas, ( forummotor ) segitsegevel. Annak orulnek.
De gondolom valamennyi php kodra igy is ugy is szugseg van nem ?
Mert oszinten szolva szeretnem ha lenne is vele egy kis melo, es nem csak siman fel kellene telepiteni. -
#6190
cidalain
veterán
honda 1993
#6189
cidalain
veterán
válasz
honda 1993
#6189
üzenetére
Biztos hogy saját magad akarsz fejleszteni login részt, és fórumot?
Nem kis falat, persze egy egyszerű motort össze lehet rakni.
Nem gondolkoztál kész fórummotoron, aminél már minden megvan csak fel kell telepíteni? pl PHPBB. -
#6189
honda 1993
senior tag
honda 1993
senior tag
Ertem.
Egyenlore meg egy viszonylag egyszeru kis oldalrol van szo, viszont lassan el akarom kezdeni a logint es a forumot is . ( Persze ezt mar php-val).
-
#6188
cidalain
veterán
honda 1993
#6187
cidalain
veterán
válasz
honda 1993
#6187
üzenetére
Ez független attól hogy hogyan tárolod a képeket, milyen mappában.
Elméleti rész:
Lehet minden fájl egy mappába behányva, de ha ott az 1 db HTML amit néznek nem hív be 1 képet sem, csak kiír valami 1 oldalnyi szöveget akkor az gyors lesz.Illetve lehet szépen rendszerezve minden, de ha az épp megnyitott HTML behív a rendszerezett mappájából 345 db FullHD képet akkor az rohadt lassú lesz.
Ettől függetlenül a saját igényességed miatt, és az átláthatóság miatt továbbra is rendszerezd szépen mappába, hisz így később is hozzá tudsz nyúlni mert amik egy helyre tartoznak azok együtt lesznek.
Tehát nem azon múlik a gyorsaság, hogy az adott tartalmak milyen módon vannak rendezve a szerveren, hanem azon, hogy az éppen megtekinteni kívánt HTML fájlod mennyi adatot próbál megjeleníteni a böngészőben (sok kép, 3000 oldalnyi szöveg, 600 millió soros Javascript kód mérete nagy ezért lassú lesz a betöltődés)
-
#6187
honda 1993
senior tag
Sk8erPeter
#6186
honda 1993
senior tag
válasz
Sk8erPeter
#6186
üzenetére
Hmmm.
Azt hiszem hogy pont ugy csinalom az oldalt, hogy ne fordulhasson elo olyan hogy egyszerre kell az osszes kepet betoltenie akkor, amikor belepnek.
Vannak kulon mappak, amiben azok a html fajlok vannak amik mas temakort tartalmaznak.
Nem tudom hogy mennyire ertheto amit szeretnek mondani . XD
-
#6186
Sk8erPeter
nagyúr
honda 1993
#6176
Sk8erPeter
nagyúr
válasz
honda 1993
#6176
üzenetére
"Van valami szabaly arra vonatkozoan, hogy egy weboldal hany db html fajlbol allhat ?
Persze itt inkabb az amolyan "iratlan szabalyra " gondolok."
Nincs ilyen szabály, mert általában egy normális weboldal nem szanaszéjjel szórt, egymástól független HTML-fájlokból áll, hanem szerveroldalon generálódik hozzá az oldaltartalom. Ami meg ugye adott esetben iszonyatosan nagy mennyiség is lehet. Lásd akár a stackoverflow.com aloldalait. De az ehhez tartozó tartalmat nem meglepő módon mind adatbázisból kotorják ki, az oldal összeállítását pedig az alkalmazás végzi."Ugyanis az oldalam meglehetosen sok, jelenleg is kb 20 db html fajlbol all.
Megpedig azert, mert 20 menupont van az oldalamon, es ezek mindegyikeben mas es mas tartalom talalhato.
illetve megegy kerdes, egy atlagos weboldal mindennel egyutt kb mekkora helyet foglal ?
Nekem jelenleg 2,8 mb."
Nincs ilyen mérce, hogy van egy átlagos weboldal, és az ennyi helyet foglal. Ez teljes mértékben a mögötte lévő kódbázistól függ. Ezt pedig több szerveroldali nyelven is meg lehet írni, még a nyelven belül is számtalan megoldás van, lehet saját kódot írni az egész működtetésére, lehet frameworköt felhasználni a kódtámogatásra, lehet CMS-t továbbfejleszteni, mindegyik teljesen más méreteket jelent. A méret inkább a legenerált kimenetnél érdekes, hogy a kliensnek mekkora adatmennyiséget kell letöltenie a hálózaton keresztül. Ő például a szerveroldali kódjaiddal - jó esetben - nem találkozik, csak a szerveroldalon lévő alkalmazásod által legenerált végső kimenettel (legyen az HTML, JSON vagy akármicsoda). Nyilván nem szerencsés, ha gigantikus méretű képeket kell egyetlen requestre való válaszként letöltenie a kliensnek, mert az elég hosszú ideig tart, és anyázni fog érte. Egyébként a letöltött méretet tudod figyelni az adott böngésző webfejlesztő panelén keresztül is (Ctrl+Shift+I vagy F12, Network fül).(#6185) cidalain :
A blokkszintű elemeket, tehát az általad felsoroltakat nyugodtan vehetjük így is. Annyi kiegészítéssel, hogy a HTML5-ben vannak új sorszintű (inline) elemek is. -
#6185
cidalain
veterán
Sk8erPeter
#6183
cidalain
veterán
válasz
Sk8erPeter
#6183
üzenetére
tulajdonképpen az új elemek (header, nav, section, footer, article) mindegyik egy div, csak kifejezőbb neve van, csak arra használandó amit a neve takar.
ha jól gondolom, nem?
-
#6184
tothjozsi96
addikt
honda 1993
#6180
válasz
honda 1993
#6180
üzenetére
Mert írok egy oldalt és kíváncsi vagyok az előnyeire, meg érdekel eléggé.
Ezért gondoltam úgy hogyha HTML 5 akkor csak az legyen.(#6183) Sk8erPeter
Ez jó ötlet!
Mondjuk így lehetne:<?php
$aktiv_tema = $result["css"]; //sql-ben tárolt szám, felhasználók által beállítátt - mondjuk 1, tehát 1 = default.css
$logo = $aktiv_tema . ".png";
?>
<header><img src="pic/logo/<?=$logo;?>" alt="" /></header> -
#6183
Sk8erPeter
nagyúr
tothjozsi96
#6174
Sk8erPeter
nagyúr
válasz
tothjozsi96
#6174
üzenetére
Már cidalain leírta, hogy a logót inkább illene <img>-ként megadni, mint háttérképként. Amit később mutogatsz, az továbbra is háttérkép, pedig épp előtte írta le a kolléga az instrukciókat, abban a hsz.-ben, amire épp válaszoltál.
Amúgy szerveroldalról is simán visszaküldhetnéd az aktuális logót, az src-attribútumban olyan URL-t megadva, ahol először némi pársoros query-feldolgozás után visszaküldöd a képet (PHP-vel is megteheted, hogy kiolvasol képfájlból, majd megfelelő fejlécekkel kiküldöd).Az egésznek egyébként nem sok köze van a HTML5-újításokhoz. De természetesen úgy a jó, hogy a logó a <header> elemen belül van. De mélyebben beágyazva szokás, nem közvetlenül belerakva, hiszen a header több szekcióból is állhat, például tartalmazza a <nav>-elemet, és a többi... Meg valamilyen többi elemtől szeparáló divbe szokták rakni.
"a HTML5 eléggé kerüli a DIV-ek használatát"
Ez egy óriási baromság! Dehogy kerüli a divek használatát! Egyszerűen a HTML5-ben újabb elemek vannak, amikkel egyrészt rövidebb és szebb lehet a kód, másrészt kifejezőbbek szemantikailag adott esetben, mint a divek (ahol ez érdekes - például a <nav> szebb, mint egy <div id="nav">), ettől függetlenül a div ugyanúgy megmaradt használható blokkszintű csoportosító és elválasztó elemnek. (div --> division)(#6179) tothjozsi96:
"A div már halott ..."
És még egyszer leírja a hülyeséget...
Attól még, mert helyenként mást illik használni HTML5-ös doctype-pal, mint egy sima divet, egyszerűen azért, mert kifejezőbb lesz tőle a kód (így olvashatóbb is, és keresőmotorok vagy egyéb automatizált eszközök által is könnyebben érthető), attól még a divet továbbra is HASZNÁLJÁK, igen, HTML5-nél is!!! Capisce? -
#6182
#81999360
törölt tag
honda 1993
#6180
#81999360
törölt tag
válasz
honda 1993
#6180
üzenetére
Mert az a jövő.
-
#6181
cidalain
veterán
tothjozsi96
#6179
cidalain
veterán
válasz
tothjozsi96
#6179
üzenetére
HTML 5-ösítettem a hondás megoldást
<header><a href="http://valami.com"><img src="valami.png" alt="" /></a></header>CSS-ben:
header { ..... }de amit korábban írtál #6177-ben az jó, csak a kép ne background legyen
-
#6180
honda 1993
senior tag
tothjozsi96
#6179
honda 1993
senior tag
válasz
tothjozsi96
#6179
üzenetére
Na azt nem olvastam ...
Egyebkent miert olyan fontos hogy feltetlenul az legyen ?
-
#6179
tothjozsi96
addikt
honda 1993
#6178
válasz
honda 1993
#6178
üzenetére
Most leírjam még egyszer hogy nekem HTML 5-ös megoldás kell???
A div már halott ...
-
#6178
honda 1993
senior tag
tothjozsi96
#6177
honda 1993
senior tag
válasz
tothjozsi96
#6177
üzenetére
<div class="header"><a href="http://valami.com"><img src="valami.png" alt="" /></a></div>
css: .header{ide pedig a css kod }
Tehat a css-ben kell egy . a header elott.
Ja, majdnem el is felejtettem, hogy a link termeszetesen nem kotelezo hogy benne legyen a kodban, de mivel logorol beszelunk ( legelabb is ha jol ertettem) a linkre is szugseg lehet.
Egyebken sajnos nem egeszen ertem hogy a nekem szant valaszban pontosan mire is gondolsz.
-
#6177
tothjozsi96
addikt
cidalain
#6175
válasz
cidalain
#6175
üzenetére
Az a lényege az egésznek hogy eddig úgy volt hogy:
<div id="logo"></div>És css-ben megvolt adva hogy:
div#logo {
background: url('pic/logo.png');
width: 1000px;
height: 130px;
margin: 0 auto;
}És több kinézet volt, minden kinézethez más fejléc volt készítve, na most arra lennék kíváncsi hogy header-rel hogy?
Most úgy van hogy <header><img src="logo.png"></header>Vagy esetleg a header-t úgy hogy css-ben?!
header {
background: url('pic/logo.png');
width: 1000px;
height: 130px;
margin: 0 auto;
}Tudtommal a header csak a fejléc-hez kell mint HTML 5 tag.
(#6176) honda 1993
Mivel a HTML oldal szerintem teljesen lényegtelen a méret. -
#6176
honda 1993
senior tag
honda 1993
senior tag
Hali.
Egy elegge fura kerdesem lenne.
Van valami szabaly arra vonatkozoan, hogy egy weboldal hany db html fajlbol allhat ?
Persze itt inkabb az amolyan "iratlan szabalyra " gondolok.Ugyanis az oldalam meglehetosen sok, jelenleg is kb 20 db html fajlbol all.
Megpedig azert, mert 20 menupont van az oldalamon, es ezek mindegyikeben mas es mas tartalom talalhato.
illetve megegy kerdes, egy atlagos weboldal mindennel egyutt kb mekkora helyet foglal ?
Nekem jelenleg 2,8 mb. -
#6175
cidalain
veterán
tothjozsi96
#6174
cidalain
veterán
válasz
tothjozsi96
#6174
üzenetére
Véleményem szerint, ha kell kép akkor raksz, ha nem kell akkor nem raksz.
CSS-enként változikot úgy érted, hogy a különböző eszközökön a más struktúra miatt?
Egyszrűen ha már több CSS lesz a reszponzív megjelenés miatt akkor azt a fejlécképet is meg lehet csinálni 3 különböző méretben, nem nagy meló. Persze mobil kijelzőn nem érdemes lepedőnyi képet odatenni. Mobil és tablet esetén egy kis méretű céglogó szerintem bőven jó a fejlécbe, sőt én ajánlanám is.Viszont nem értem miért kéne ID-t rakni a HEADER tagnek, hisz ebből az elemből csak 1 db-ot illene használni minden felbontásban.
Ugyanakkor a céglogót meg nem illik háttérképként betenni, hanem IMG-be, ami ráadásul kattintható link is, és a weboldal főoldalára mutat.
De javítsatok ki ha tévednék.
-
#6174
tothjozsi96
addikt
Most HTML5-ben gondolkodom.
Egy olyan kérdésem lenne hogy ti hogy adnátok meg egy fejléc képet, hogyha CSS-enként változik. Tehát több kinézet lenne.
Tehát kellene hozzá rendelni egy ID-t is.
Kíváncsi lennék arra hogy ez HTML5 szempontjából hogy lenne a legjobb.Mivel a HTML5 eléggé kerüli a DIV-ek használatát, de arra is gondoltom hogy <header id="logo"> de ez se tűnik túl jónak ...
Persze működik csak érdekel hogy lenne ez HTML5 barát ...
-
#6173
martonx
veterán
tothjozsi96
#6171
martonx
veterán
válasz
tothjozsi96
#6171
üzenetére
"de vannak még emberek akik XP-sek" - nos ők azok, akik soha, semmi esetben nem célközönség, maximum akkor, amikor busszal kell utaztatni a közönséget termék bemutatókra...
-
#6172
Sk8erPeter
nagyúr
tothjozsi96
#6171
Sk8erPeter
nagyúr
válasz
tothjozsi96
#6171
üzenetére
Régebbi IE-verziót is tudsz "szimulálni" (F12-vel hozod elő az IE debuggerét, a screenshoton IE11):
-
#6171
tothjozsi96
addikt
Sk8erPeter
#6170
válasz
Sk8erPeter
#6170
üzenetére
Itt az a probléma hogy nem tudtam kipróbálni régebbi Internet Explorer-t, de vannak még emberek akik XP-sek, mondjuk azok nem keresik feltétlen azt a tartalmat amit ezzel az oldallal akarok futtatni, de kíváncsi voltam hogy valójában mit is mutat egy régebbi HTML5-öt nem támogató böngésző.
-
#6170
Sk8erPeter
nagyúr
tothjozsi96
#6167
Sk8erPeter
nagyúr
válasz
tothjozsi96
#6167
üzenetére
Szemantikailag helyesebb a kód úgy, ha kifejezi a tartalmat. Ezekben is segítenek a HTML5-tagek. A kérdésed kb. olyan, mintha egy XML-ben nem értenéd, mire jó, hogy van egy <product> tag, ahelyett, hogy mondjuk <tokmindegy name="product"> lenne...
Remélem, elég szemléletes a kép. Rövidebb, kifejezőbb, olvashatóbb az előbbi megoldás. Természetesen nem csak az a lényeg, hogy a fejlesztő számára olvashatóbb legyen, hanem keresőmotorok és egyéb automatizált eszközök számára is."Gondolom cserébe a régi böngészőkön nem lesz jó"
Pontosan erről volt szó itt, hogy van fallback régi böngészőkre is egy script formájában..."Kíváncsiságból megnéztem egy Firefox 3.6-os verzióval, a menüm össze hullott, hát lehet maradok a <div>-nél inkább."
Ki használ FF 3.6-ot? Egyébként mindegy is, az előző mondatom erre is válasz.
"Kár hogy a régi dolgokra ez nem elérhető." - és erre is...
Mintha nem előtted beszéltük volna meg az egészet. "Próbáltam megnézni Lumia 520-al is de nem engedte valamiért, lehet a WAMP miatt, nem megy ki a port, vagy nem tudom."
Ennek nincs sok értelme, hogy "nem megy ki a port". Tűzfal blokkolhatja az adott (itt: 80-as, HTTP-) portra érkező kéréseket (HTTPS esetén alapértelmezetten 443-as port). Akár a saját gépeden, akár a routeren. A tűzfalat konfigurálhatod úgy, hogy az adott port nyitva legyen. Port forwardingnak hívják azt a módszert, amikor a külső hálózatról az adott portra érkező kéréseket pl. a routereden átirányítod a belső hálózat egyik gépének adott portjára. Itt, meg itt írtam erről valakinek nemrég.
Egyébként belső hálózaton nincs szükség erre, csak ha külső hálózatból is el akarod érni az adott szolgáltatást az adott porton. -
#6169
tothjozsi96
addikt
Zedz
#6168
Értem, így már világos.
Kíváncsiságból megnéztem egy Firefox 3.6-os verzióval, a menüm össze hullott, hát lehet maradok a <div>-nél inkább.
Próbáltam megnézni Lumia 520-al is de nem engedte valamiért, lehet a WAMP miatt, nem megy ki a port, vagy nem tudom.Kár hogy a régi dolgokra ez nem elérhető.
thx! -
#6168
Zedz
addikt
tothjozsi96
#6167
Zedz
addikt
válasz
tothjozsi96
#6167
üzenetére
Olvashatóbb kód, keresőmotorok tudni fogják, hogy az ott egy menü, illetve a listás megoldásnál használt CSS egy része már nem kell ahhoz, hogy valahogy ki is nézzen a menü.
-
#6167
tothjozsi96
addikt
PumpkinSeed
#6166
válasz
PumpkinSeed
#6166
üzenetére
A google féle tárolt verzió jobb, vagy jobban elkülöníti az elemeket?
Mondjuk néha egyszerűbb a használat, például a <footer>.
Nem kell annyit kiírni hogy <div id="footer">.![;]](//cdn.rios.hu/dl/s/v1.gif)
Gondolom cserébe a régi böngészőkön nem lesz jó.
De ez így még mindig kevés nekem.
-
#6166
PumpkinSeed
addikt
tothjozsi96
#6165
PumpkinSeed
addikt
válasz
tothjozsi96
#6165
üzenetére
Google szempontjából jobb.
-
#6165
tothjozsi96
addikt
Most átírtam a <div id="menu">-t <nav id="menu">-re.
A css-ben a formázást is, de nem értem még mindig.Mitől lesz ez jobb attól hogy ez most nav?
Mi értelme ezeknek az új tag-eknek? -
#6164
Sk8erPeter
nagyúr
DNReNTi
#6159
Sk8erPeter
nagyúr
válasz
DNReNTi
#6159
üzenetére
"Ha viszont igen, akkor jöhet a html5shiv, vagy valami hozzá hasonló script. Ettől viszont szerintem jobb megoldás a jó öreg div"
Miért lenne jobb megoldás, mint include-olni egy feltételtől függően behúzott scriptet? Itt van példa rá. Lesz egy
<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
rész a kódban, a nem érintett böngészők egyszerűen ignorálják, ott nem is lesz behúzva ez a script, de cross-browser és modern a kód, mindenki happy... -
-
DNReNTi
őstag
Tény, hogy modernebb megoldás a <nav> és társai, és talán egy picit olvasmányosabb is a kód. Ha nem szempont támogatni IE9 alatt akkor teljesen egyetértek. Ha viszont igen, akkor jöhet a html5shiv, vagy valami hozzá hasonló script. Ettől viszont szerintem jobb megoldás a jó öreg div.
-
#6158
tothjozsi96
addikt
Zedz
#6157
-
#6157
Zedz
addikt
tothjozsi96
#6156
Zedz
addikt
válasz
tothjozsi96
#6156
üzenetére
De amúgy menükhöz szerintem már nyugodtan használhatod a nav taget is.
-
#6156
tothjozsi96
addikt
DNReNTi
#6155
-
#6155
DNReNTi
őstag
tothjozsi96
#6154
DNReNTi
őstag
válasz
tothjozsi96
#6154
üzenetére
Nem e lehet hogy azért csúszik be, mert valami konténer már kapott padding attribútumot és abban van, az amit eredetileg akartál változtatni? A linkelt kód, mint írtam is, általános, tehát minden elemre vonatkozik. Másra nem tudok gondolni.
-
#6154
tothjozsi96
addikt
DNReNTi
#6153
-
#6153
DNReNTi
őstag
tothjozsi96
#6152
DNReNTi
őstag
válasz
tothjozsi96
#6152
üzenetére
Persze, hogy "kicsúszik", mert a fix szélességhez a padding értéke alap esetben hozzáadódik. Epic megoldás a box-sizing: border-box; trükk. Van rá a neten millió megvalósítás, a linkelt egy teljesen általános. Tökéletes ha mindenre alkalmazni akarod. Így nem kell vacakolni a fix méretek matekolásával. Ha valami 200px széles, annyi lesz akkor is ha adsz hozzá padding-ot.
-
#6152
tothjozsi96
addikt
-
#6151
tothjozsi96
addikt
PumpkinSeed
#6150
válasz
PumpkinSeed
#6150
üzenetére
ÁÁÁ, köszi!
Még megadtam a height értéket is így a border is leér teljesen már.
thx! -
#6150
PumpkinSeed
addikt
tothjozsi96
#6149
PumpkinSeed
addikt
válasz
tothjozsi96
#6149
üzenetére
Paddinggal tudod szabályozni.
-
#6149
tothjozsi96
addikt
Olyan kérdésem lenne hogy van egy <div>-ekből álló menüm.
És úgy szeretném hogy legyen rajta border-left is, tehát elválasztó vonalak.
De az a baj hogy a szöveget nem tudom középre helyezni.
Próbáltam már text-align:center-rel is, de nem megy.Mutatom.
HTML:
<div id="menu">
<ul>
<li><a href="login.php">Bejelentkezés</a></li>
<li><a href="signup.php">Regisztráció</a></li>
<li><a href="recover.php">Jelszó emlékeztető</a></li>
</ul>
</div>CSS:
div#menu {
width: 100%;
background: #DADAD3;
border: 1px solid #AEAEA9;
}
div#menu ul {
height: 20px;
margin: 0;
padding: 0;
list-style: none;
}
div#menu li {
float: left;
display: inline;
} -
martonx
veterán
Már volt itt vita a fórumon arról, hogy szvsz nem hatékony (kód futási szempontból) adatbázisban tárolni a fordításokat. PHP esetében ott vannak a .po file-ok, ASP.NET vonalon .resx fileok (amik dll-be fordíthatók, így még a fordítás file IO erőforrása is minimalizálható, mert elinduláskor egyszer beolvasódnak és utána már csak használni kell memóriából).
-
cidalain
veterán
"Ui.: fontos kritérium, hogy nem hozhatok létre annyi példányt az adatbázisban ahány nyelv van, hisz az adathalmaz csupán 10%-át teszik ki a dinamikusan változó nevek, és nagyon nagy pazarlás lenne."
Akkor vedd két részre a táblát:
-dinamikusan változó nevek
-90%-nyi egyéb adathalmazA dinamikusanból csinálj annyit ahány nyelv van. Ebben az esetben nincs pazarlás, mert minden adat csak 1× van meg, viszont nem kell szótártáblákkal szarakodni.
Termék univerzális adatai tábla
Termék id | további attribútumok amik nyelvfüggetlenek
1 | 13 kg | 12×33×44 mm | 1234 FtTermék nyelvfüggő szöveges adatai tábla
Termék id | nyelv id | termék név | termék leírás | termék egyéb fordítandó szöveges cuccai
1 | HU | Kalapács | kéziszerszám
1 | EN | Hammer | hand toolVagy ez nem járható?
-
qfm
őstag
Igazából mindkettő, de a problémát az adatbázis jelenti. Az egyszerűség kedvéért egy példa, és a koncepció:
Van egy termékeket forgalmazó program/honlap, amire feltöltenek adott paraméterekkel rendelkező termékeket. A feltöltő magyar nyelvű, így létrehoz egy adott objektumot, aminek a nevét magyar nyelven adja meg. Van ugyanebben a cégben egy másik feltöltő, aki használni akarja ugyanezt az objektumot, de angol nyelven. Ilyen jellegű problémára hasonló elképzelés született:
Van egy objektumot tartalmazó tábla, mely a nevet nem string formátumban, hanem azonosítóként tárolja.
Van egy szótár tábla amiben az elsődleges kulcs mellett van egy név azonosító mező, valamint egy nyelv. Erre a név azonosító mezőre hivatkozik az objektum, és mindig a megfelelő nyelven kéri le.
Pl.:
Termék (azonosító, név_azonosító, további_attribútumok)
1, 3, "bármilyen további mező"
Szótár (azonosító, név_azonosító, nyelv, fordítás)
1, 3, "magyar", "kalapács"
2, 3, "angol", "hammer"Ekkor a nevek közül az kérdeződik le, amelyik a programban kiválasztott nyelven van. A helyzet ott bonyolódik, hogy ebben a programban mind a neveket, mind a nyelveket dinamikusan a felhasználók töltik fel. Ezért érdekelne valamilyen optimálisabb megoldás, ha létezik. (a példa egy leegyszerűsített kivonat csak)
Elnézést a hosszú házzászlósáért, és köszönöm a válaszokat a másik kérdésemre, megfogom őket nézni.
Ui.: fontos kritérium, hogy nem hozhatok létre annyi példányt az adatbázisban ahány nyelv van, hisz az adathalmaz csupán 10%-át teszik ki a dinamikusan változó nevek, és nagyon nagy pazarlás lenne.
-
qfm
őstag
Sziasztok!
Tudtok valamilyen grafikus programot, amibe kialakítható a divek struktúrája/elhelyezkedése? Régen láttam már valamilyen felosztás kialakító programot, de mivel nem használtam végül, el is felejtettem mi volt az.
Nem teljesen ide tartozó téma:
Ha valakinek van valami jól bevált módszere több nyelvű program készítésére, az egy linket küldhetne privátban, vagy akár itt is. Az általunk kialakított koncepció kicsit talán túlbonyolított, érdekelne egy bevált megoldás is.
-
#6142
Kommy
veterán
Sk8erPeter
#6141
Kommy
veterán
válasz
Sk8erPeter
#6141
üzenetére
Mivel e szerint csináltam a saját oldalt: [link], de ha php fájlt adok meg neki akkor nem fut le semmi.
-
#6141
Sk8erPeter
nagyúr
tothjozsi96
#6138
Sk8erPeter
nagyúr
válasz
tothjozsi96
#6138
üzenetére
"De szerintem a <table> használata lehet ajánlottabb lenne, mert nagyon kevés helyre kellene ez a layout.
És table-n belül a div működik úgy is ha csak bizonyos helyre kell."
Mi van?! Sokszor egyszerűen nem értem a mondataidat. Mi az, hogy "kevés helyre kellene ez a layout"? Én a page layoutról beszéltem, abból egy van, ez határozza meg a látható elemek elhelyezkedését. Na, erre mondtam, hogy NAGYON NEM ajánlott a <table>, nem véletlenül nem divat, hanem azért, mert rettentően rugalmatlan tud lenni, nem tudod szabadon pozicionálni az elemeidet, táblázatba ágyazott táblázatokkal kell helyenként szenvedni, ha ilyen megoldáshoz folyamodsz, köze nincs a reszponzivitáshoz, és még számtalan potenciális problémát vet fel.
Az eredeti kérdésed is elég értelmetlenül hangzik, nem pontosítottad, az ezelőtti válaszomban arról beszéltem, hogy ha valóban táblázatról van szó (pl. adatok sor-oszlopszerű megjelenítése a cél), akkor nyilván <table>-t használj, ha a lap alapvető megjelenéséről van szó, akkor <div>-eket, sőt, a HTML5-ös elemeket is (<header>, <nav>, <main>, <section>, <aside>, <footer>, stb.).(#6139) Kommy :
És akkor miért a HTML topicba írsz, és miért nem oldod meg PHP-val?
Jól érzed, ez így elég durván gány. -
#6140
tothjozsi96
addikt
Kommy
#6139
-
Kommy
veterán
Sziaszatok,
phpbb fórumba akarok egy oldalt csinálni, amiben html oldalt kell kreálnom, viszont az adatokat csak php-val tudnám megoldani. Jelenleg iframe-el van berakva a megjelenitendő adat (jelenlegi oldal).
A kockák egyetlen php fájl, ami paraméterben kap egy számot és e szerint írja ki az adatokat, a legnagyobb bajom ezzel a megoldással, hogy a méretet állandóan át kell írogatni az egyes iframekre, hogy látszódjon minden adat, jó lenne ha ez automatikus lenne.
-
#6138
tothjozsi96
addikt
Sk8erPeter
#6137
válasz
Sk8erPeter
#6137
üzenetére
Igazából én egy P2P oldalt akarok megírni, azért kérdeztem a PHP topicban hogy cookie vagy session ...
De szerintem a <table> használata lehet ajánlottabb lenne, mert nagyon kevés helyre kellene ez a layout.
És table-n belül a div működik úgy is ha csak bizonyos helyre kell. -
#6137
Sk8erPeter
nagyúr
Jim-Y
#6136
Sk8erPeter
nagyúr
Ezek szerint eléggé félreértetted, nem állította senki, hogy minden esetben ilyen egyszerű, de amúgy igen, a jelen helyzetben ilyen egyszerű, hogy az attribútum-érték párosokkal ellátott verzió jobb, és kész.
Eléggé kifejtettem az okát az előző hsz.-emben. Mert szerinted a példában mégis mi szól a másik mellett? (Nem láttam tőled indoklást. )"Ellenben ha mar ez az XML pl egy build.xml lenne, akkor az elso verzio -szertintem- sokkal atlathatobba tenne a fajlt."
Ez így nem túl értelmes állítás, mivel ha megnézel egy Ant-es build.xml-t, akkor az tele van ilyen vagy olyan megoldásokkal (van, ahol az egyik formátumot, van, ahol a másikat használja), épp attól függően, hogy hol melyik praktikusabb/logikusabb (kb. azon szempontok szerint is, amiket írtam).(#6135) tothjozsi96 :
"HTML-ben mit érdemes használni mint táblakezelőt?
Vagyis több értelme van a DIV-nek?"
Ennek a kérdésnek ebben a formában semmi értelme. Ha táblázatot akarsz megjeleníteni (tehát indokolt a <table> használata), akkor használj táblázatot, ha pedig a layoutról van szó, akkor azt ne táblázatos formában készítsd, mert az rendkívül rugalmatlan. De ha átfogalmazod a kérdést valami értelmes változatra, akkor még talán tudunk is válaszolni arra, amire kíváncsi vagy. -
#6136
Jim-Y
veterán
Sk8erPeter
#6134
Jim-Y
veterán
válasz
Sk8erPeter
#6134
üzenetére
Egyebkent szerintem nem ilyen egyszeru a dolog, hogy az inline property-s verzio az jobb, es kesz.
cidalain:
Szerintem van amikor az elso verzio a jobb, es van amikor a masodik. Ha peldaul sok repetitiv elem lenne az XML fajlomban, peldaul
<product>
<id>ágy123</id>
<name>ágymelegítő</name>
</product>
<product>
<id>ágy123</id>
<name>ágymelegítő</name>
</product>
<product>
<id>ágy123</id>
<name>ágymelegítő</name>
</product>Akkor en is a rovidebb, tomorebb verziot hasznalnam. Ellenben ha mar ez az XML pl egy build.xml lenne, akkor az elso verzio -szertintem- sokkal atlathatobba tenne a fajlt. Egzebkent pedig pfuj XML, tessek mar JSON-t hasznalni!
-
#6135
tothjozsi96
addikt
HTML-ben mit érdemes használni mint táblakezelőt?
Vagyis több értelme van a DIV-nek? -
#6134
Sk8erPeter
nagyúr
cidalain
#6133
Sk8erPeter
nagyúr
válasz
cidalain
#6133
üzenetére
"Az XML szintaxis leírásánál mindenhol kivétel nélkül a terjengősebb forma van, majd a végén 1 sorban megemlítik a másikat is."
Ez a "kivétel nélkül" talán egy kicsit erős, nem?
Melyik leírás volt ez?A másikra: nézd meg martonx példáját, ebből jól látható, hogy attól még, mert valamit sokan igényelnek vagy használnak, az attól még nem biztos, hogy a megfelelő technológia a feladat kivitelezésére. De lehet, hogy nagyon sokan vannak olyanok is, akik meg a célra megfelelőbb technológiát ajánlanák.
Van, ahol őskövületek dolgoznak, és ők döntenek bizonyos dolgokról, vagy épp az a helyzet van, hogy rettentő komplikált vagy pénzigényes lenne a teljes átállás, és ilyen módon csomó mindent sikerül jópár évig bebetonozni. -
#6133
cidalain
veterán
Sk8erPeter
#6132
cidalain
veterán
válasz
Sk8erPeter
#6132
üzenetére
Az XML szintaxis leírásánál mindenhol kivétel nélkül a terjengősebb forma van, majd a végén 1 sorban megemlítik a másikat is. Ezért kérdeztem itt hogy mi a véleményetek, mert gyanúsan a jobbnak tűnő megoldás volt elintézve egy sorban.
Nekem nem kellett még ilyesmit csinálni így nagyon nem mentem bele, hogy mi az elterjedtebb. Viszont ügyfelek már kerestek meg akiknek kellett XML feldolgozót készíteni: pl a használtautós oldal is XML-be exportálja ki egy adott kereskedés cuccait, illetve volt már dolgom ilyen kuponos oldalak ajánlatainak átvételéről, azok is kivétel nélkül XML-ben adják ki az adatokat. JSON-t eddig sehol sem láttam ilyenre, de mondom, nem is kerestem
-
#6132
Sk8erPeter
nagyúr
cidalain
#6121
Sk8erPeter
nagyúr
válasz
cidalain
#6121
üzenetére
Bár ahogy megbeszéltük, úgyis JSON-t kéne választanod, de akkor már beszéljük meg az XML-t is az érdekesség kedvéért.
Ennél a példánál, amit mutattál, teljesen egyértelmű, hogy az utóbbi, attribútumokkal ellátott formát kell választani. De szerintem a példa is rossz, mert ez annyira magától értetődő, ebben az esetben nem kérdés, melyiket kéne választani: egyrészt az utóbbi láthatóan jóval tömörebb (nemcsak olvashatóbb, de kisebb hálózati forgalmat is jelent, ami nagy mennyiségnél már nem mindegy), másrészt az előbbi forma esetén az azt feldolgozó kód felesleges terjengőssége is problémát jelenthet, mivel be kell járni az adott csomóponthoz tartozó gyerekelemeket, ez plusz metódushívásokat és overheadet jelent, míg az utóbbi forma esetén csak az adott tag attribútumainak értékeit kérdezgeted le, és megvagy. Szóval több szempont is az utóbbi mellett szól.
Abban az esetben lenne max. indokolt az előbbi forma, ha valami komplexebb adatstruktúrát kellene tárolnod gyerekelemekként, ahol mondjuk pont az attribútum-érték páros szerinti leírás lenne már undorítóan olvashatatlan és/vagy erőltetett (mert mondjuk kényszerből iszonyú hosszú neveket kell adnod már az attribútumoknak, hogy megkülönböztethető legyen, az most micsoda is). -
#6131
Sk8erPeter
nagyúr
cidalain
#6129
Sk8erPeter
nagyúr
válasz
cidalain
#6129
üzenetére
Ahogy a többiek már elég meggyőzően elmondták, mindenképpen a JSON-t válaszd az XML-lel szemben. Azt meg nem értem, hogy nem találkoztál még vele, hogy mennyire nyomatják (nem véletlenül) a JSON-t, minden tisztességes és említésre méltó dokumentáció/tutorial/e-book/könyv/fórumhozzászólás a JSON-t javasolja manapság (például nagyon kényelmes is kezelni mondjuk AJAX-os kliens-szerver kommunikációnál). Főleg, ha azt írod, hogy elsősorban JavaScript-kódban használnád a szerverről fogadott adatokat... szerintem már az is elég beszédes, hogy a JSON a JavaScript Object Notationből készített mozaikszó.
A JSON-nek nagyon széleskörű a támogatottsága, ma már csak kb. a nem "karbantartott" programozási nyelvekhez nincs JSON-támogatás. -
martonx
veterán
válasz
cidalain
#6129
üzenetére
"Nem tudom miért nem promózzák ezt jobban"
A csapból is JSON folyik. Én azt nem értem, hogy juthat még bárkinek is eszébe az XML manapság (mondom én, aki nem győzök XML-t visszaadó service-ekhez fejleszteni online felületeket, de egyszer csak kikopnak a köztudatból a régi szarok).
Anno 2012-ben a kedvencem a KHR (Központi Hitelnyilvántartó Rendszer) volt, ahol anno hihetetlen nagy dérrel-dúrral jelentették be a rendszer totális megújulását. A régi rendszer sajátosan formázott txt file-ok ftp-n küldözgetésével működött (na jó, nem pont ftp, de fejlesztői szemmel nézve pont úgy működött, a GIRO-sok meg napokig tudnának beszélni a különbségről).
Gondoltam, na milyen király lesz, végre lesz egy normális REST API a KHR-hez is, és JSON-ban jönnek-mennek majd az adatok.
Ezzel szemben az újítás abban merült ki, hogy már xml file-ok ftp-n küldözgetésével működik a KHR
Ráadásul komolyan brutál nagy XML-eket képzeljetek el, a legapróbb adat változás is több száz kbyte-os körítésekben utazik.
Anno, amikor az OTP elkezdte az ősfeltöltést, napokig elérhetetlen volt a KHR szolgáltatás
Egyszer véletlenül mi is kifektettük fél napra, pedig csak valami korrekciókat akartunk feltolni.Ah, de jó hogy nem dolgozok már az őskövület pénzügyi szektorban.
-
cidalain
veterán
válasz
martonx
#6128
üzenetére
Értem, köszönöm.
Igazából most tökmindegy nekem hogy mit rakok össze PHP-val, kb ugyanannyira egyszerű egy XML meg egy JSON outputot is elkészíteni.
Hallottam már a JSON-ról korábban is, de valahogy eszembe sem jutott ez az opció most, automatikusan az XML ugrott be. Közben persze most én is elkezdem utánanézni, és több az előnye ha ilyet használnék. Nem tudom miért nem promózzák ezt jobban... (vagy csak én nem forgatom elég mélyen a szakirodalmat?) -
martonx
veterán
válasz
cidalain
#6126
üzenetére
"És ha ezt az adathalmazt később egy külső forrásnak is ki kell szolgáltatnom, akkor a JSON oda is ajánlott?"
Mi az hogy, nagyon is. Az XML így 2014-ben már sehova nem ajánlott."Mi az előnye a JSON-nak az XML-lel szemben?"
Tömörebb, s minden nyelv kb. natívan át tudja fordítani a saját objektumaivá. Én C#-ról tudok nyilatkozni, ott pl. XML-t parse-olni pár nagyságrenddel nagyobb szopás, mint Json-ből kapni egy megfelelő erősen típusos osztályt (Java vonalon tudtommal dettó ugyanez a helyzet). -
#6127
fordfairlane
veterán
cidalain
#6126
-
#6126
cidalain
veterán
fordfairlane
#6125
cidalain
veterán
válasz
fordfairlane
#6125
üzenetére
És ha ezt az adathalmazt később egy külső forrásnak is ki kell szolgáltatnom, akkor a JSON oda is ajánlott?
Mi az előnye a JSON-nak az XML-lel szemben? Javascripttel tökmindegy, max kicsit gyorsabb a feldolgozási idő, nem?
Külső programokkal le lehet kezelni rendesen a JSON fájlokat (mittudomén mondjuk Androidos szoftver ha lehívja az adatot a weboldalról) -
cidalain
veterán
Nem annyira HTML, de talán belefér.
Mi a különbség, és melyik XML struktúra javasolt
<product>
<id>ágy123</id>
<name>ágymelegítő</name>
</product>vagy
<product id="ágy123" name="ágymelegítő" />
Olvastam hogy ez a kettő megoldás elvileg teljesen ekvivalens egymással.
Van e olyan szituáció amikor ajánlott valamelyik felállást alkalmazni.
Mostanában volt dolgom több adatátpasszolós XML oldallal, és az egyik így használja, a másik amúgy, de van olyan is aki egy XML fájlon belül mindkét módszert alkalmazza.Nekem most viszonylag nagy mennyiségű adatot kellene átadnom adatbázisból egy javascriptnek, így a második megoldást választanám, mert ott kevesebb lenne az egyéb sallang, kisebb lenne az XML mérete.
-
#6120
martonx
veterán
tothjozsi96
#6115
martonx
veterán
válasz
tothjozsi96
#6115
üzenetére
Igen websocket-ről beszélünk. Én ugyan csak ASP.NET vonalról, és MS Serverről tudok nyilatkozni, ott semmit nem kell telepíteni.
-
cidalain
veterán
válasz
pumatom
#6118
üzenetére
szerencsére ritkán csinálom én a designt, így ilyen jellegű problémám még nem volt.
ha meg én csinálok designt, akkor ott nincs kép a design részeként ami fix lenne, tartalomkezelővel tölthető a fejléckép is pl. a tartalomkezelőt meg a tulaj tölti...ilyen hogy ikon, vagy mini ábra ami esetleg kellene valamihez (mittudomén pl nyilak, email ikon, vagy nemtudom), azt általában lenyúlom valahonnan, bár itt is inkább free ikonok között keresek elsősorban, és max alakítok rajta kicsit.
ilyen istockphoto szerű oldalaknál képenként is lehet fizetni, 10-20 dollár körül van egy kép.
a getty elég húzósnak tűnik árban így elsőre -
pumatom
aktív tag
válasz
cidalain
#6111
üzenetére
Értem.
A termékek még egy dolog, mert ha árulhatja, akkor jó eséllyel valami joga már van a megjelenítéshez.
A másik esetnél tudsz arra hivatkozni, hogy Ő küldte.
Viszont, ha teljesen rád van bízva, hogy milyen legyen a weboldal, akkor hogy csinálnád?
fordfairlane:
Egy képért akarnak kérni 1665€ -t, a weblapért nem adnak annyit. -
#6117
tothjozsi96
addikt
Zedz
#6116
Igen, csak kíváncsi lennék a használatára.
Mert doksit és hasonlókat nem nagyon találtam róla, tehát a pontos működéséről.
Azért érdekelne, mert egy real-time üzenőfalat akarok írni, gyakorlatilag most is az üzenetek memóriában vannak tárolva, szóval ezért még jó lenne egy realtime is mellé. -
#6116
Zedz
addikt
tothjozsi96
#6115
Zedz
addikt
válasz
tothjozsi96
#6115
üzenetére
Websockethez kell szerver oldal is igen, viszont ezzel real-time lehet csodákat művelni.
-
#6115
tothjozsi96
addikt
martonx
#6113
-
#6113
martonx
veterán
tothjozsi96
#6109
martonx
veterán
válasz
tothjozsi96
#6109
üzenetére
"Nekem viszont realtime kéne, de ha jquery-vel vagy ajax-al frissítem akkor az bizony terheli a memória használatát egy usernek." - tényleg terheli, és vajon mennyivel?
Viccet félretéve valóban nem elegáns megoldás pollozni a szervert, mégha ez egy bevált módszer is.Egyébként igen, én használok real time ózenetküldést per pillanat is, bár én ASP.NET vonalon mozgok, ott pl. a SignalR erre tökéletes. Biztos PHP vonalon is megvannak a HTML5-ös push notification API kihasználásra épülő komponensek.
-
-
pumatom
aktív tag
Sziasztok!
Elsősorban azokhoz szólna a kérdésem, akik pénzért csinálnak weboldalakat.
A képeket, amiket felhasználtok, azokat Ti honnan szeditek le, veszitek meg(
)?A kérdés a különböző szerzői jogok miatt fogalmazódott meg, nem tudom, hogy jelenleg mi erre a hivatalos törvény, stb... ?
Szerk.: Nem a free vector images, és satöbbi oldalakra gondolok, hanem a rendes felismerhető arcokat, tájakat, stb.-t ábrázoló képekre.
Ti hogy csináljátok?
-
#6109
tothjozsi96
addikt
Van egy üzenőfalam ami jelenleg iframe-es megoldás.
Nekem viszont realtime kéne, de ha jquery-vel vagy ajax-al frissítem akkor az bizony terheli a memória használatát egy usernek.Valaki használt már real time-ot vagy felhasználó barát üzenőfal frissítést/módszert?
-
Carasc0
őstag
Sziasztok!
Abszolút kezdőként érdeklődök egy adott egyszerű probléma megoldása ügyében. A feladat roppant egyszerű. Adott egy szimpla JPEG kép amit szeretnék a weboldal hátterébe berakni. Ez még megy is, de hogyan tudom úgy beállítani, hogy ha az oldalt tetszőleges felbontásban lévő monitoron nézik meg, illetve tetszőlegesen nagyítják az oldalt, akkor a kép igazodjon ezekhez az átméretezési paraméterekhez.
Előre is köszönöm!
-
#6106
honda 1993
senior tag
Sk8erPeter
#6105
honda 1993
senior tag
válasz
Sk8erPeter
#6105
üzenetére
Hat en sem ertem hogy miert, es hogy hogyan, de ez volt a problema.
PumpkinSeed Nem is volt olyan sok.
-
#6105
Sk8erPeter
nagyúr
honda 1993
#6103
Sk8erPeter
nagyúr
válasz
honda 1993
#6103
üzenetére
Örülök, hogy sikerült, bár ha megfelelően meg vannak adva a képdimenziók (szélesség x magasság), akkor nem kellene ilyen problémának előfordulnia, hogy kitolja valamelyik elemet egy eltérő méretekkel rendelkező kép.
(#6104) PumpkinSeed : Hadd örüljön.
-
#6104
PumpkinSeed
addikt
honda 1993
#6103
PumpkinSeed
addikt
válasz
honda 1993
#6103
üzenetére
Bocs, hogy beleszólok, de lehetne legközelebb kevesebb ugráló, tapsoló, guruló fejjel elküldeni valamit?
-
#6103
honda 1993
senior tag
honda 1993
senior tag
HAHHHAHAAHAHAAAAAAAAA
Es vegig az volt a baj hogy annak a kepnek mas volt a felbontasa.
Csak most jottem ra, hogy rapillantottam az images mappaban levo kepre. Koszi a segitseget.
Mostmar mukodik ( ahogy Fekete Pako mondana ). -
#6102
honda 1993
senior tag
Sk8erPeter
#6101
honda 1993
senior tag
válasz
Sk8erPeter
#6101
üzenetére
Haaat, ez felig-meddig bevalt. Koszonom
Bar a kozepso kep megint szivat engem, mert most majdnem ugy nez ki mint az altalad linkelt kodban, de most meg alacsonyabb lett a kozepso kep,mint a ket szelso.
Annak ellenere hogy ugye meg van adva a magassag es a szelesseg is.
Raadasul direkt ossze is hasonlitottam a te kododdal a sajatomat, es nincs is kulombseg a ketto kozott.Lehet hogy az lesz a baj hogy annak a kepnek mas a felbontasa mint a masik kettonek ?
Mert mar tenyleg nincs mas otletem.Tehat megegyszer, igen jol gondolod. Es a jsfiddle peldaban talalhato kod pont olyan ami nekem kell, tehat eltalaltad. XD
A masik kerdesedre valaszolva, a keret termeszetesen nem a vegleges formaban jelent meg a linkelt kodban.
-
#6101
Sk8erPeter
nagyúr
honda 1993
#6100
Sk8erPeter
nagyúr
válasz
honda 1993
#6100
üzenetére
Ha egyszerűen a korábbi példát módosítod, amit mutattam, csak úgy, hogy nem az img_containerre rakod a bordert, hanem magára az img-re, az nem jó?
Mármint így: http://jsfiddle.net/e4per0nL/2/
Mondjuk fogalmam sincs, konkrétan mit szeretnél, mert nem fejtetted ki, de nekem úgy tűnt az eddigiekből, hogy jó az első példa is, csak a képek köré szeretnél valami keretet rakni (amúgy ebben a formában a keret elég ronda, gondolom nem ilyen lesz élesben, de szemléltetésnek pont jó).
Csak az meg gusztustalan. Elavult fos módszereket meg itt nem fog senki javasolni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Amúgy szerveroldalról is simán visszaküldhetnéd az aktuális logót, az src-attribútumban olyan URL-t megadva, ahol először némi pársoros query-feldolgozás után visszaküldöd a képet (PHP-vel is megteheted, hogy kiolvasol képfájlból, majd megfelelő fejlécekkel kiküldöd).
Attól még, mert helyenként mást illik használni HTML5-ös doctype-pal, mint egy sima divet, egyszerűen azért, mert kifejezőbb lesz tőle a kód (így olvashatóbb is, és keresőmotorok vagy egyéb automatizált eszközök által is könnyebben érthető), attól még a divet továbbra is HASZNÁLJÁK, igen, HTML5-nél is!!! Capisce?
Új hozzászólás Aktív témák
- LG 27UL500-W - 27" IPS - 3840x2160 4K - 60Hz 5ms - HDR10 - AMD FreeSync - 300 Nits - sRGB 99%
- Bomba ár! Dell Latitude 7320 - i5-11GEN I 8-16GB I 256-512SSD I HDMI I 13,3" FHD I Cam I W11 I Gari!
- iMac Pro 1.1 2017 Intel Xeon W2150B 64GB 1TB VEGA 64 16GB!!! 1 év garancia!
- Emlékezetes gamer élmény, amit megvásárolhatsz VAGY akár ki is bérelhetsz! Akár rèszletre is!
- iKing.Hu - Motorola Razr 40 Ultra Glacier Blue 8 GB RAM / 256 GB tárhely Használt, karcmentes
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest