- Xiaomi 13 - felnőni nehéz
- Honor 200 Pro - mobilportré
- Szívós, szép és kitartó az új OnePlus óra
- Xiaomi 15 - kicsi telefon nagy energiával
- Fotók, videók mobillal
- Android alkalmazások - szoftver kibeszélő topik
- Apple iPhone 16 Pro - rutinvizsga
- Keretmentesít a Galaxy S25 FE
- iPhone topik
- Magyarországon is kapható a Moto G85 5G
Új hozzászólás Aktív témák
-
#6815
fordfairlane
veterán
sz.j
#6813
fordfairlane
veterán
És ez valahogy meglehet akadályozni? Azazhogy a tartalom ne tolja szét a cellát
A szöveget természetesen alapból sorokba tördeli a render, ha nincs beállítva az adott cellára a
white-space: nowrap;style property. Persze a tartalom így is lehet magasabb, mint kellene, illetve ha van hosszú szó, amiben nincs whitespace karakter, akkor a szöveg is széttolhatja a cellát vízszintesen, és ezáltal az egész oszlopot. Illetve még a képek is széttolhatják.Magára az egész táblára meg lehet adni a
table-layout: fixed;style-t, ebben az esetben a tartalom nem módosítja a cellák méretét. Ilyenkor ajánlatos beállítani minden cella magasságát és szélességét, célszerűen egy CSS-sel, ami az adott tábla összes cellájára érvényes lesz. -
#6812
fordfairlane
veterán
sz.j
#6811
fordfairlane
veterán
A táblázatoknál a legszélesebb cella határozza meg az oszlopszélességet, és a legmagasabb cella a sormagasságot. Elég egyhez beírni, de azzal sincs gond, ha mindegyikhez bekerül.
Alaphelyzetben a tartalom széttolhatja a cellákat, ha az adott méretben nem fér el. A cella tartalmának igazítása (text-align, vertical-align) cellánként változhat.
-
martonx
veterán
Az a baj, hogy valami miatt (talán mert ennek a legegyszerűbb átlátni magát a forráskódját is), a wp felhasználók, sőt a wp fejlesztők sem tudják hogyan is kellene normálisan szabályosan wp-zni. És van aki még könyvet is ír... Tragikus.
Egyébként kismillió fordító plugin van hozzá: link a legelső szerintem része az alap telepítő csomagnak.
-
#5298
Sk8erPeter
nagyúr
sz.j
#5297
Sk8erPeter
nagyúr
Inkább a hiba forrását kellene megkeresned, és azt, hogy milyen normális fordítási módszerek vannak, nem pedig beletákolni a forráskódba, amit ugye nem illik, hacsak nem saját készítésű sminkről/pluginről van szó. Jobban jársz, ha kicsit megismered a rendszert, amit használsz, mert később is lehet ilyesmiből problémád.
martonx azt állítja, valahogy meg van oldva az admin-felületen történő fordítás is (nem részletezte, hol, hogyan), úgyhogy körül kellene nézned.
-
#5294
Sk8erPeter
nagyúr
sz.j
#5293
Sk8erPeter
nagyúr
WordPress-nél nincs adatbázisszintű gyorsítótártörlés?
Ezenkívül a fordítások módosítására nincs valami lehetőség az admin-felületen? Nem tárolódnak adatbázisban?
Számomra eleve elég furcsa, hogy a fájlokban kell gányolni ahhoz, hogy elkészíts egy fordítást, szerintem kellene lennie valami normális módszernek is... Gondolj csak bele, mit csinálsz, ha egy oldalt 5 nyelven szeretnél megjeleníteni? A többnyelvűsítés miatt valami normális középutat csak elvárnék egy WordPress-szintű népszerűségnek örvendő CMS-től... Drupalnál ezt megoldották normálisan. -
sz.j
nagyúr
Előbb azt elfelejtettem megemlíteni, hogy miután az eredeti loop-blog.php-t visszatöltöttem a tárhelyre FTP-n keresztül újra leszedtem (lementettem) a tárhelyen lévő wp tartalmat és a loop-blog.php-ben az eredeti kód látszik, azaz
<?php $frontier_continue_reading_text = ( get_post_type() == 'page' ) ? __('Read Page', 'frontier') : __('Read Post', 'frontier'); ?>Mindezek ellenére a böngészőkben továbbra is a hibás "Folytatás" látszik ..
-
sz.j
nagyúr
Hát ezt végképp nem értem ....
Kísérletképpen azzal is próbálkoztam, hogy "Read Post" helyére beírt Folytatás helyett mást írtam be (Tovább, Próba, stb) majd visszatettem az eredeti lementésből az "érintetten" (azaz nem átírt) loop-blog.php-t (Read Post), de nem változott semmi, állandóan a hibás "Folytatás" látszik ....
Természetesen az előzményeket töröltem a böngészőkből, normál és inkognitó nézet is mindig ugyanaz látszik.
-
#5290
Sk8erPeter
nagyúr
sz.j
#5288
Sk8erPeter
nagyúr
Nem látunk az egészből semmit, így nehéz bármit is mondani.
Nem mindegy az sem, hogy Notepad++-ban csak simán átállítottad a karakterkódolást, vagy pedig a konvertálásra kattintottál. Megpróbálhatnád azt is, hogy kitörlöd a szöveget, aztán újra belerakod, ennél értelmesebb ötletem tényleg nincs így látatlanban.
-
cidalain
veterán
nem lehet hogy a WP motorja kódolja a szöveget php-ban mikor ráteszi a gombra?
mittudomén mondjuk htmlentities($gombszöveg); vagy akármi.Forráskódban hogy jelenik meg a gomb szövege amikor az oldalon hibásan látszik? (itt most úgy értem hogy böngészőből nézve a forráskódot)
-
#5256
Sk8erPeter
nagyúr
sz.j
#5255
-
The DJ
addikt
Ha Wordpress és az oldal sebessége a téma, akkor kötelező telepíteni a W3 Total Cache plugint.
Ebben aktiválod a page cache, minify, browser cache opciókat (a database cache és object cache nem mindig hibamentes, de adhatsz nekik is egy próbát). Ez már maga szépen le fogja redukálni a betöltési időt.
A tömörítést is tudja, de csak akkor, ha szerver oldalon be van töltve az Apache deflate modul. Ez szintén sokat jelent.
Egyébként nagyon komplex és sokoldalú plugin, tökéletes all-in-one megoldás, ami kezdőknek és haladóknak is nagy segítséget jelent. Megéri utánaolvasni és az oldaladhoz hangolni a beállításokat.
-
#5109
Sk8erPeter
nagyúr
sz.j
#5108
Sk8erPeter
nagyúr
Ráadásul a CSS-hibák többsége egyszerűen kompatibilitási okokból berakott különböző böngészőfüggő trükk, pont annak érdekében, hogy a látvány lehetőleg minden böngészőben a lehető legjobban hasonlítson. Például vannak olyan tulajdonságok, amik a W3C ajánlásában (a "szabványban") nem szerepelnek, mégis adott böngészőgyártók bevezették, így sok tulajdonság csak abban a konkrét böngészőben jut érvényre. Nem egy örvendetes dolog, amikor egy böngészőgyártó a saját útját járja, pont az egységesség, szabványkövetés ellen szól (ezért utálták annyi éven át az Internet Explorert a webfejlesztők, ma már kezd használható lenni fejlesztői szemszögből), de ez van, pont ezért tartalmaz a legtöbb smink általában olyan CSS-kódot, ami a W3C-validátor szerint hibának minősül, a böngésző szerint nem (mert mondjuk a böngésző csak a számára értelmezhető tulajdonságokat veszi figyelembe), viszont a felhasználói élményt jelentősen javítja, mert a cél az, hogy az adott weboldal minden böngészőben pontosan ugyanúgy nézzen ki, és ugyanúgy is működjön.
Szerk.: mindezt azért fejtettem ki bővebben, hogy rájöjj, bizonyos validálási hibákkal tényleg nem érdemes foglalkozni, még ha eleinte nagyon zavaró is, hogy a fenéért nem mutatja hibátlannak az oldaladat a validátor, pedig az jobban mutatna. A felhasználók aztán főleg nem foglalkoznak ezzel. A Google keresőrobotja pedig az ilyen jellegű CSS-hibákat az oldalad találati listában való elhelyezésekor nem hiszem, hogy túlzottan mérlegelné (értsd: SEO-szempontból a lehető legkevésbé fontos szempont, hogy teljesen valid-e a CSS-kód a W3C szerint).
Szerk. 2.: az oldalad betöltési sebességével nálam nincs semmi gond. A CMS komplex jószág, nem fog annyira durván gyorsan bevillanni, mint a régi statikus HTML-oldalaid.
-
#5106
Sk8erPeter
nagyúr
sz.j
#5105
Sk8erPeter
nagyúr
Először inkább a saját kódodban keresd a hibát
http://www.w3.org/TR/html-markup/table.html#table-constraints
"The value of the border attribute on the table element must be either “1” or the empty string. To regulate the thickness of table borders, Use CSS instead.
The cellpadding attribute on the table element is obsolete. Use CSS instead.
The cellspacing attribute on the table element is obsolete. Use CSS instead."Magyarul az összes attribútum, amit kifogásoltál, már régóta elavult. HTML5-ben ez nem is lesz valid.
Továbbra is az ilyen attribútumok helyett CSS-t kell használni.Amúgy csak nagyon gyors pillantást vetettem az oldaladra, és máris ezerszer kellemesebb a szemnek, mint a korábbi, szóval gratula, máris jóval modernebb lett az oldalad. Az előző tényleg rendkívül elavult hangulatú volt.
Ami viszont fontos, hogy ne vidd túlzásba ezt az állandó validálás-mániát, mert nem attól lesz jobb vagy rosszabb az oldalad. A SEO-ban sem ez a lehető legfontosabb szempont, ami létezik, még ha valamelyest számít is, de pont nem az olyan jellegű hibáknál, amiket eddig felsoroltál. Ettől függetlenül nyilván nem árt, hogy valid módon készíted el az oldaladat, sőt, de azért ne ess át a ló túlsó oldalára. Csak a nyugalmad érdekében javaslom, mert van, amin nem érdemes rágódni. Inkább másra ráfeküdni. -
#5063
Sk8erPeter
nagyúr
sz.j
#5062
Sk8erPeter
nagyúr
A gyorsítótárazás gondolom tudod, hogy gyorsítja az oldalbetöltéseket. Az inline CSS- és scriptkódok (előbbi <style> tagen belül vagy adott elem style attribútumának értékeként feltüntetve, utóbbi <script> tagen belül, vagy onclick és hasonló attribútumokon belülre rakva, nem külső fájlba bedobva) külön külső fájlba rakása segítheti a gyorsítótárazást, így a böngésző egy már korábban, a gépedre letöltött példányt vesz elő, így nem kell újból és újból letöltenie a szerverről az adott fájlt.
A gyorsítótárazáshoz hozzátartozik viszont a lejárati idő is (mennyi idő múlva akarja a böngésző újból letölteni az azóta esetleg módosult példányt), itt az alábbi cikkben HTTP-fejlécek módosításával történő lejáratiidő-kitolásról beszélnek:
http://gtmetrix.com/leverage-browser-caching.htmlUtóbbi, általad említett problémáról pedig itt van beszélgetés:
http://stackoverflow.com/questions/18013648/eliminate-external-render-blocking
meg itt:
https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery
https://developers.google.com/speed/docs/insights/BlockingJS
nagyon röviden a lényege az, hogy különböző trükközéseket javasol arra, hogy a lehető legminimálisabb mennyiségű, mindenképpen szükséges CSS- és JavaScript-kódot tölts be a <head> tagben vagy máshol, annak érdekében, hogy azok letöltése, feldolgozása ne vegyen el időt és erőforrást, a többi, esetlegesen vagy csak később szükséges tartalmat pedig lehetőleg az oldal teljes betöltése UTÁN töltsd csak be. Tehát az oldal első betöltésekor tényleg csak azt töltsd be, amit a felhasználó láthat, ne kelljen a többi, kevésbé lényeges elem betöltésére várnia, utána foglalkozz csak a többivel.Ez így nagyon szépen hangzik, de az esetek többségében rendkívül nehézkessé teheti a kódolást és a karbantartást, ahogy a belinkelt topicban írják is, széjjelszabdalhatja a logikusan egybetartozó kódokat, és egyáltalán megfontolandó, hogy bizonyos projektméret alatt megéri-e az egész, tart-e annyi ideig az oldalbetöltés, hogy érdemes legyen szenvedni vele.
Ha a betöltésed nem lépi át a mágikus ~2-3 másodperces türelmi határt, akkor én inkább a NEMre szavaznék, és ennek a figyelmeztetésnek a figyelmen kívül hagyására, és ehelyett inkább az erőforrásoknak az oldal igényességének csiszolására való fordítására (ami felhasználói szemszögből szintén nagyon sokat számít). -
#5022
Sk8erPeter
nagyúr
sz.j
#5018
Sk8erPeter
nagyúr
Lásd el a táblázatot egy id-vel (azonosító) vagy class-szal (osztály), majd az alapján "célozd meg" a táblázatot CSS-ben:
id:
#en_kis_tablazatom_id {
font-size:12px;
}osztály:
.en_kis_tablazatom_osztaly {
font-size:12px;
}A másik hsz.-szel ellentétben jelen esetben az :nth-of-type pseudo-class használatának nem sok értelme van, mivel egy konkrét táblázat betűméreteit szeretnéd megváltoztatni.
-
GG888
senior tag
Bonyolultabban:
http://www.w3schools.com/cssref/tryit.asp?filename=trycss3_nth-of-type
#szoveg p:nth-of-type(1){
font-size:12px;
}Egyszerűbben inline styling.
Az első keretes blokkodban ahol nyitod a p tagot, ott egy ilyet írsz:
<p style="font-size: 12px !important"> -
sz.j
nagyúr
Majdnem teljesen kész a weboldalunk dizájnjának (nagyobb konverziót, bizalomnövelést célzó) megváltoztatása ...
Pontosabban csak az első lépcsője, mert reménykedünk, hogy további jó ötleteket, javaslatokat tudtok adni az oldal további javításához, amit előre is köszönök.Viszont lenne egy konkrét kérdésem is, nevezetesen ennél az oldalnál, hogy tudom azt megoldani, hogy a szoveg-dívben lévő szöveg továbbra is 14px maradjon, de az első keretes táblázatban lévő szöveg mérete például 12 vagy 11px-re csökkenjen?
-
#5007
DeltaPower
addikt
sz.j
#5005
DeltaPower
addikt
Nem ugyanaz. A css-nek vagy egy öröklődési és érvényességi sorrendje.
#kapcsolat {}: a kapcsolat-ban szereplő elemekre általánosan vonatkozik.
p {}: az összes p-re vonatkozik
#kapcsolat * {}: a kapcsolat-ban levő összes elemre egyenként vonatkozikNálad a html így nézett ki
<div id="kapcsolat"><p>szöveg szöveg stb</p></div>Ilyenkor a p felülbírálja a #kapcsolat azonos formázásait, mert az van bentebb. A #kapcsolat *, ha a css-ben a p-re vonatkozó általános formázás után van, akkor felülbírálja a p azonos formázását. Helyette lehetett volna használni #kapcsolat p {} formát is, a hatás a te szempontodból megegyező.
A p általános formátum törlésével is megoldottad az eredeti problémát a #kapcsolat-ban, de a többi helyen újra kell formáznod a p-t, ha meg akarod tartani a 16px-es méretet.
GG888: talán fejlesztési szempontból érdemes az elem#id forma, így a css-t nézve tudod hogy az adott id-t milyen elemre tetted rá. Mivel egy lapon két azonos id-jű, eltérő típusú elem invalid, ezért max akkor van még értelme az elem kiírásának, ha ugyanazt az id-t más lapokon más típusú elemekre használod.
-
GG888
senior tag
Nekem tetszik, mivel a p stílusa minden bekezdésre érvényes, így prioritást élvez a #kapcsolat tulajdonságaival szemben.
háttérszínnél én is legtöbbször hexet használok, ugyanilyen formátumban, tehát hashtag +6 karakter.
viszont ha szempont a css mérete, akkor jelen esetben #3366FF helyett elég párosával a dublikált karaktereket megszüntetni. Értsd: #36F.
Vagy nevén is nevezhetjük a gyereket, a szín amit használsz nem más mint a Vivid Blue.
vagyis a böngészők a background:vividblue értéket is le tudják kezelni.Kinek melyik tetszik, használja nyugodtan.
Persze ellenérveket a kollegáktól szívesen fogadok.
Színeket pedig innen érdemes:
colorhexa.com/3366ff -
GG888
senior tag
<p style="font-size: 18px !important"></p>
Ha így se lesz akkora a p-ben mint szeretnéd, akkor van baj.
Ha a SEO fontos, akkor CSS-be ásd bele magad, mert képeknél má nem dívik a width, height attribútum, style-on belül kell megadni őket, minden képnek legyen alt és title attribútuma.
Mert ugye ma rengetegen használnak kép nélküli böngészőt...
Persze tudom a keresőrobotok miatt kell, de akkoris na...SEO-hoz meg a seotools.hu oldalt ajánlom, ingyen lehet regisztrálni és nagyon hasznos dolgok vannak fent.
-
#4999
DeltaPower
addikt
sz.j
#4998
DeltaPower
addikt
Van egy általánost formázásod, ami minden p-re érvényes. Ha a divre raksz egy betűméretet, de van benne egy p és azon belül a szöveg, akkor a p betűmérete érvényes a benne levő szövegre.
Divbe p-t nem kötelező tenni, ha közvetlen a divbe teszed a szöveget és a linkeket, akkor is valid a forráskód szerintem.
-
spammer
veterán
Ariel az a kis hableány
![;]](//cdn.rios.hu/dl/s/v1.gif)
Ha mindenhol Arialt akarsz használni, akkor felesleges mindenhova odaírni, hiszen a body-ban már definiáltad, így az az egész oldalra vonatkozik.
Továbbá olyat, hogy pl. font-weight:normal csak olyankor kell megadni, ha egyébként az adott részen (pl. divben) pl. bold (vastag betű) van definiálva, egyébként a normal az alapeset, tehát felesleges beleírni. A font-style:normal dettó.
Csak hogy a felesleges munkától megkíméled magad, na meg kisebb lesz a css fájl is.
Egyébként határozottan "letisztultabb" lett az oldal, kellemesebb a szemnek, mint a régi.
-
GG888
senior tag
Ha tudnád mellékelni a forráskód egy-két kérdéses részét akkor segítünk.
Egy adott div tulajdonságát inline-stylinggal a következőképp tudod alakítani:
<div style="font-size: 28px; font-family: Arial, 'Helvetica Neue', Helvetica, sans-serif;">
Ami itt van az Arial típusú, 28px méretű lesz
</div>Ha szeretnéd, hogy az egész Arial legyen, akkor a head részbe rakd be ezt:
<style type="text/css">
body {
font-family: Arial, "Helvetica Neue", Helvetica, sans-serif;
}
</style> -
cucka
addikt
-
#4986
DeltaPower
addikt
sz.j
#4984
DeltaPower
addikt
Amik így eszembe jutottak hirtelen:
Times new roman-t lecserélni elsőnek, pl arialra. Nagyon kevés profi weblap van, ami jól néz ki times-al.
Oszlopoknak meg lehet próbálni némi enyhe gradient hátteret.
Világoskék háttérre ne írj feketével, sötétkék, sötétszürke szebben mutat.
Menüpontok lekerekített sarka elüt a design többi, szögletesre hagyott sarkától.
Aláhúzott headingek szerintem gagyi hatásúak. Ha mindenáron aláhúzást szeretnél, akkor text-decoration:underline helyett border-bottom-ot használj, jobban formázható.
Fekvő MARTE logóban a helyesírási hibát javítani. -
#4965
Sk8erPeter
nagyúr
sz.j
#4960
Sk8erPeter
nagyúr
Pedig de, a W3C validátora szerint az oldalad valid.
Nem is írta egyébként sehol az általad használt extension/plugin, hogy bárhol hiba lenne.
(#4964) DS39 :
megelőztél.
Egyetértek, tipikusan olyan "probléma", amire egy fél percet sem érdemes szánni. Ez aztán semmilyen mértékben nem befolyásolja a Google találati listában való elhelyezkedést, ami nyilván a fő aggodalom tárgya. -
#4873
Sk8erPeter
nagyúr
sz.j
#4872
Sk8erPeter
nagyúr
Simán lehet.
Na meg mondjuk az sem elhanyagolható szempont, hogy ez ingyenes, míg mondjuk egy másik WYSIWYG-szerkesztő (mittudomén, Dreamweaver vagy ilyesmi) meg elég durván drága lehet.
Szóval akár kezdeti tanulás gyanánt, meg kódnézegetés helyett+mellett biztos jól jöhet sokaknak. -
-
cidalain
veterán
-
#4762
Sk8erPeter
nagyúr
sz.j
#4760
Sk8erPeter
nagyúr
Sajnos úgy tűnik, ez bizony bug a Kompozerben, amit azóta sem sikerült javítaniuk, legalábbis ezt igazolja ez:
http://sourceforge.net/p/kompozer/bugs/476/
másnál is előfordul:
[link]
[link]
ez csak gyors rákeresés alapján, szóval nem egyedi a probléma, sajnos ez a Kompozer hülyesége, tényleg elég gáz...
-
-
-
The DJ
addikt
Nem maga a sablon tartalmazza a nyelvi fájlt, hanem a Wordpress. Tehát ha egy magyar Wordpress-t töltesz le és telepítesz, akkor mindegy milyen sablont húzol rá, a nyelv magyar marad. (Esetleg 1-2 rosszabbul megírt sablonnál benne maradhat pár angol szó, de ezeket 1 perc kijavítani és lecserélni. A prémium theme-eknél viszont még ez sem jellemző.) Megéri átböngészni a sablonokat, mert ha találsz olyat, ami tetszik és passzol az üzleted arculatába, akkor a későbbiekben megtérülhet a váltás, hiszen ez most a jövő, robbanásszerűen jönnek felfelé a tabletek, az okostelefonok és már nem csak a felső réteg kiváltsága az ilyesmi. Én pedig magamról tudom, hogy ha egy oldal nem töltődik be vagy nem működik, esetleg nem jól néz ki a használt eszközön, akkor rögtön zárom is befelé.
Sk8erPeter: Így legalább mind a két népszerű CMS képviselteti magát ezekben a topikokban
Én ugye a Wordpress-hez (+Joomlához) értek jobban, ennek a rendszernek a működését, pluginjait ismerem alaposan, te pedig ugyanígy vagy a Drupallal. Az tény, hogy mind a kettő egy népszerű és kiforrott rendszer és amit a Drupalból láttam az is egyre pozitívabb, mert minden verzióváltással egyre letisztultabb és felhasználóbarátabb lett. -
#4715
Sk8erPeter
nagyúr
sz.j
#4713
Sk8erPeter
nagyúr
Első mondatodra: irónia volt, reméltem, hogy átjön...
Második felére: szerintem egy ilyen összehasonlítás elég félrevezető lehet ennyiből, mert nem ártana tudni, az illető mire alapozva mondja ezt, melyik verzióját próbálta a Drupalnak (például nyilvánvaló, hogy a 2-es Drupal nem összehasonlítható a mostani 7-essel...), és így tovább... Amúgy meg a jelenlegi, 7-es változat (a 8-as tudtommal szeptember körül lesz stable állapotban, ismét újabb nagyon jó fejlesztésekkel) pontosan ugyanúgy az arcodba tol minden egyes szükséges lépést, mint ahogy The DJ az előbb leírta a WordPress esetén a másik topicban - tényleg, egy az egyben ugyanez szinte minden lépés. Tehát szerintem nagyjából pont ugyanolyan egyszerű vagy bonyolult használni mind a kettőt, csak ízlés, ráérzés és megszokás kérdése, meg annak függvénye, hogy milyen igényes tutorialokat olvasgatsz, pl. Drupal esetén is nagyon bőséges szakirodalom van, lásd itt az összefoglalót: Drupal topic.
Félre ne értsd, én nem azt mondom, hogy a Drupal jobb, épp az az üzenet, hogy nem JOBB egyik vagy másik (attól még, mert az én preferenciám a Drupal), inkább másban erős a két CMS; plusz mivel a WordPress-t nem is nagyon ismerem, ezért arról nem is nyilatkozom se negatívan, se pozitívan. A Drupal erősségeit ismerem, nagyon sok van belőle, és ahogy egyik rendszer sem, úgy ez sem tökéletes. -
Soak
veterán
Én pár hete probáltam ki a drupalt, aki arra aztmondja, hogy bonyolult, még nem találkozott semmi bonyolultal az életében
... Nyilván ha komolyabban foglalkozik vele valaki akkor kell némi felkészültség, de 1 óra alatt összekattingat valaki egy siteot benne ha nem analfabéta. -
The DJ
addikt
Úgy, hogy vannak olyan sablonok, amik alapból reszponzívak, ergo csak annyi a dolgod, hogy keresel (vagy megvásárolsz) egyet és átülteted a tartalmat. Én Wordpress-el dolgozom, ahhoz értek a legjobban, ott ez nagyon jól megoldott már és egyre több a minőségi reszponzív sablon. Pont pár hete kellett készítenem egy weboldalt ezen kritériumok alapján és az volt a fő cél, hogy minden eszközön és felbontáson jól nézzen ki (tablet, mobil, iOS, Android, etc.). Az viszont tény, hogy ami igényes és valóban minőségi, az sajnos általában nem ingyenes (bár annyira nem is vészesek az árak. Vásárolgatni itt szoktam WP-hez: [link] )
-
-
#4705
Brown ügynök
senior tag
sz.j
#4698
Brown ügynök
senior tag
-
sz.j
nagyúr
-
#4683
Sk8erPeter
nagyúr
sz.j
#4679
Sk8erPeter
nagyúr
Ja, valszeg nem emiatt esett szét, de egyébként az igaz, amit DeltaPower is írt, bár a böngészők általában elég "toleránsak", próbálják megjeleníteni az oldalt legjobb tudásuk szerint:
http://www.w3.org/TR/CSS21/fonts.html#propdef-font-family
"Font family names must either be given quoted as strings, or unquoted as a sequence of one or more identifiers. This means most punctuation characters and digits at the start of each token must be escaped in unquoted font family names."vannak viszont "általános" betűtípus-családnevek, amelyeket utolsó tulajdonságként lehet megadni, ezeket NEM szabad idézőjelek közé tenni:
'serif' (e.g., Times)
'sans-serif' (e.g., Helvetica)
'cursive' (e.g., Zapf-Chancery)
'fantasy' (e.g., Western)
'monospace' (e.g., Courier) -
#4678
DeltaPower
addikt
sz.j
#4677
DeltaPower
addikt
Elsőre azt mondanám, hogy a googlebot nem érte el a css-t amikor cachelte, vagy valami hibát talált benne.
A css viszont validnak tűnik, az egyedüli hiba az lehet, hogy a szóközt tartalmazó font-family-t idézőjelbe kell tenni, tehát:
font-family: Times New Roman;
helyett:
font-family: "Times New Roman";
vagy egyszerűen csak:
font-family: Times; -
#4657
Sk8erPeter
nagyúr
sz.j
#4655
Sk8erPeter
nagyúr
Igen, jó, semmi baj nincs vele, sőt, az külön jó, ha kifejező az URL is, és tartalmaz releváns kulcsszavakat! URL aliasnál nem is feltétlenül kell törekedni arra, hogy rövid legyen, ha megnézed, egy csomó népszerű oldalnál is jó hosszú URL-eket kapsz egy-egy konkrét cikknél, mert ha mondjuk hosszú lett a cikk címe, akkor annak megfelelően hosszú lesz az URL alias is. Nincs gond ezzel, a böngészők a hosszú URL-eket is tudják kezelni (persze nem a regényméretűeket), a Google meg értékeli is, ha az URL kifejezi a hozzá tartozó tartalmat. Persze félreértés ne essék, nem cél a hosszú URL, de bajnak nem baj.
-
cidalain
veterán
szerintem semmivel sem jobb a
www.akarmi.hu/termekek/ajtok/bejarati/uvegbetetes/tipusnev123
link a
www.akarmi.hu/uvegbetetes_bejarati_ajto_tipusnev123.htmlszóval szerintem simán mehet. de azért várd meg a többiek véleményét is. hátha ők sokkal jobban otthon vannak a SEO-ban.
-
-
#4574
Sk8erPeter
nagyúr
sz.j
#4563
Sk8erPeter
nagyúr
http://docs.1h.com/How_to_switch_PHP_versions
http://kb.siteground.com/how_to_have_different_php__mysql_versions/Még ez is vonatkozik arra, azonkívül, amit Athlon64+ írt, tehát PHP-verzióváltás is lehetséges bizonyos tárhelyeknél.
Nálad ez van PHP 5.2-re vonatkozó beállítás:
AddHandler application/x-httpd-php52 .php
ahogy itt a példában írják, lehetne akár ez is, PHP 5.3-asra váltáshoz, ha több verzió lenne elérhető:
AddHandler application/x-httpd-php53 .php .php5 .php4 .php3 -
#4507
Sk8erPeter
nagyúr
sz.j
#4506
Sk8erPeter
nagyúr
Írhatnál róluk egy-két szót, hogy mi a véleményed róla.
(#4505) cidalain :
"Most pont azon gondolkodtam hogy így Iframe-esen simán jó arra is, hogy pl adattáblánál a felvitel űrlap ilyenben jelenjen meg (van bezárás után parent refresh opció is, tehát egyből frissítené a listát az újonnan felvitt anyaggal). Kicsit moderneb kinézetűvé lehet tenni vele egy sima adatfeltöltő részt is. Szerintetek?"
Ja, ha igényesen van megoldva, jó megoldás lehet. A Drupal 7-ben is úgy van megoldva, hogy alapértelmezetten az admin-dolgok egy overlay-ben jelennek meg, persze ez a viselkedés kikapcsolható, tehát opcionális. -
#4463
Sk8erPeter
nagyúr
sz.j
#4462
Sk8erPeter
nagyúr
Kiindulásnak jó. Most töröld azokat a tök felesleges <br>-eket a listából, és a "Redőny" szó maradjon konzekvensen <a> tagek közé zárva, hogy ugyanolyan stílust kapjon, mint a többi szülőelem.
Aztán a #menu li -nek adj valami magas z-indexet, ez pongyolán fogalmazva azt határozza meg, hogy melyik van "följebb" a rétegek közt.
pl.
#menu li {
z-index: 10;
}Aztán lehet tovább dizájnolni, de így már meg fog jelenni rendesen.
-
#4461
Sk8erPeter
nagyúr
sz.j
#4455
Sk8erPeter
nagyúr
De minek kellene itt lenyílni, mik az almenük, melyik a szülőelem?
Csak mert pont azt nem látom a kódodban, amit az általad belinkelt cikk tartalmaz, hogy legyen egy ilyen:<div id="menu">
<ul>
<li><a href="#">Első</a></li>
<li>Első
<ul>
<li><a href="#">Második</a></li>
<li><a href="#">Második</a></li>
</ul>
</li>
</ul>
</div>Itt látható, hogy az "Első" a szülőelem, az pedig tartalmaz egy újabb <ul> listát, magán a <li>-n belül (ez fontos). Ez így szintaktikailag helyes, nálad a <li>-k között egyszer csak szerepel egy <ul> (nem a <li> tartalmazza az újabb <ul><li>-t, hanem a <li>-k között van; kb. olyan, mintha egymás mellé állítanál almákat, aztán egyszer csak az almahalmaz közepén ott lenne egy T-Rex
), az pedig úgy szintaktikailag helytelen. -
#4449
Sk8erPeter
nagyúr
sz.j
#4448
Sk8erPeter
nagyúr
-
#4424
Sk8erPeter
nagyúr
sz.j
#4423
Sk8erPeter
nagyúr
#menu --> ez a menu AZONOSÍTÓVAL ellátott elem (<div id="menu">)
.menu --> ez a menu OSZTÁLLYAL ellátott elem (<div class="menu">)Nyilván én az előbbihez igazítottam a kódomat, mert nálad az azonosítós forma volt. (A saját kódomban class volt, de tök mindegy.)
Semmi baj nincs azzal, ha egyiket vagy másikat használod, annyi a nagy különbség, hogy azonosítóból csak egyetlen darab lehet egy oldalon, míg osztályból akármennyi (több elemnek is megadhatod a class="menu"-t, ha kell, és így mindnek ugyanaz a stílusa lesz, amit megkapott a .menu-nél; hacsak nincs még pluszban felülbírálva; id="menu"-t csak egyetlen elemnek lehet adni, ahogy benne van a nevében, az azonosító egyértelműen azonosít egy meghatározott elemet). De azzal sincs gond, ha azonosítóval és osztállyal is rendelkezik egy elem, még ha ugyanaz is a neve: <div id="menu" class="menu">; ez lehetővé teszi, hogy külön-külön stílusokat adj meg a #menu-nek és a .menu-nek, és ezáltal lényegében a kettőnek a kutyult változata fog kijönni. -
#4420
Sk8erPeter
nagyúr
sz.j
#4419
Sk8erPeter
nagyúr
Sokkal igényesebb a kódja, mint volt.
Bár én a <br>-t mindig inkább <br />-nek szeretem írni az XHTML-szintaxis szerint.
És bocsi, de muszáj szokás szerint belekötnöm.<div id="menu">
<h3><a style="font-weight: normal;" href="index.html">Kezdőoldal</a>
<a style="font-weight: normal;" href="redony.html">Redőny</a>
<a style="font-weight: normal;" href="nyilaszaro.html">Nyílászáró</a>
<a style="font-weight: normal;" href="reluxa.html">Reluxa</a>
<a style="font-weight: normal;" href="szunyoghalo.html">Szúnyogháló</a>
<a style="font-weight: normal;" href="szalagfuggony.html">Szalagfüggöny</a>
<a style="font-weight: normal;" href="arak.html">Árak</a>
<a style="font-weight: normal;" href="kapcsolat.html">Kapcsolat</a>
<a style="font-weight: normal;" href="oldalterkep.html">Oldaltérkép</a>
</h3>
</div>Ez így elég csúnya. Ha h3, akkor eleve nem kellene ide explicite megmondani, hogy félkövér legyen, mert alapból tudtommal minden népszerű böngészőben az. De ami nem tetszik benne, az inkább az, hogy egy nagy blokként kezeled a <h3>-at, pedig minden egyes címre külön-külön kellene megadni ezt a taget.
Példa:
<h3><a href="index.html">Kezdőoldal</a></h3>
<h3><a href="redony.html">Redőny</a></h3>
Továbbá a menüknél általában az <ul> listába szokás rendezni, aztán eltüntetni a default pöttyöt előle.
Pl.:<div class="menu">
<ul class="navigation">
<li><h3><a href="index.html">Kezdőoldal</a></h3></li>
<li><h3><a href="redony.html">Redőny</a></h3></li>
.....
</ul>
</div>Ez ad neki egy logikus struktúrát.
Szerintem SEO-szempontból is előnyösebb, de én aztán nem vagyok egy SEO-mágus, de mindenesetre az tény, hogy a keresőrobotok is jobban szeretik a tök logikus felépítésű, jól strukturált oldalakat.
Minden menüpont külön-külön fontos, ezért mindegyiket külön kéne szedni. Szerintem.
Csak hogy hihetőbb legyen a mondókám, nézd meg a w3.org főoldalán a menüt, ott is ugyanaz a struktúra van, amit én írtam.De továbbmegyek, szerintem itt a menüelemeknél nem biztos, hogy indokolt a <h3>, inkább egy külön CSS-fájlban kéne leírni a menüelemek formázását.
ul.navigation li {
list-style: none;
}
ul.navigation li a {
...
} -
#4411
Sk8erPeter
nagyúr
sz.j
#4410
Sk8erPeter
nagyúr
Végül is a lényeg annyi, hogy a <b> az konkrétan szövegformázásra való, a <strong> pedig szemantikailag is "erősnek", fontosnak jelöli a tagek közt lévő tartalmat. A <b> egy elavult formázási stílus, helyette CSS-t illik használni, úgy, ahogy Te is mutattad, míg a <strong> nem elavult, hanem ilyen XML-szerű megjelölés a tartalom fontosságának megjelölésére. Ettől függetlenül a <strong> tagek közt lévő szöveget az összes mai, jelentős részesedéssel rendelkező böngésző úgy jeleníti meg, ahogy a <b> tagek közt lévőt megjelenítené, DE ez böngészőfüggő implementáció kérdése, tehát egy böngészőgyártó nyugodtan dönthetne akár úgy is, hogy mostantól dőlten jeleníti meg a - CSS-sel nem felülbírált - <strong>-gal fontosnak megjelölt szöveget.
-
#4409
Sk8erPeter
nagyúr
sz.j
#4407
Sk8erPeter
nagyúr
http://www.w3schools.com/html/html_formatting.asp
"Often <strong> renders as <b>, and <em> renders as <i>.
However, there is a difference in the meaning of these tags:
<b> or <i> defines bold or italic text only.
<strong> or <em> means that you want the text to be rendered in a way that the user understands as "important". Today, all major browsers render strong as bold and em as italics. However, if a browser one day wants to make a text highlighted with the strong feature, it might be cursive for example and not bold!" -
#4360
Sk8erPeter
nagyúr
sz.j
#4358
Sk8erPeter
nagyúr
Félreérted, nem mindenáron és mindenhol kell lecserélni a táblázatokat, a táblázatok elkerülését inkább komplett layoutra szokták javasolni, mert adott esetben nagyon rugalmatlan, nehézkes átszabni, egy idő után elkerülhetetlenek az egymásba ágyazott táblázatok, és így tovább.
De attól még a táblázat táblázat marad! Ahogy már írták előttem, az általad mutatott helyeken nem kell lecserélni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
A kapcsolat sávnak lehetne némi oldalsó paddingja, mert így nem szép, hogy a széléig ér a szöveg.
Lehet nem jó linket nézek...
Se CSS-sel, se JavaScripttel nem állítottál be neki semmit, ami miatt úgy kéne viselkednie, mint egy legördülő menü.Új hozzászólás Aktív témák
Hirdetés
- Nvidia Quadro M2000/ M4000/ P2000/ P2200/ P4000/ P5000/ RTX 4000/ RTX A2000 / RTX A4000
- Azonnali készpénzes AMD CPU AMD VGA számítógép felvásárlás személyesen / postával korrekt áron
- Samsung Galaxy Tab A8 (2021) , 3/32 GB,
- Bomba ár! Lenovo ThinkPad Yoga 260 - i5-G6 I 8GB I 256SSD I 12,5" Touch I W10 I Cam I Gari!
- Jo Nesbo: LEOPÁRD (nem olvasott)
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest