Ha mondjuk csinálsz egy olyat, hogy a content középre igazítva mindig fix 1000px széles legyen, akkor nyilván ki fogja tölteni az egész teret egy 1024-es monitoron, és nyilván jó sok helyet ad egy 1920-ason. Ha azt akarod, hogy mindenhol kitöltése, akkor px helyett használj %-ot.

A lényeg szerintem hogy a középre igazított tartalom és úgy az egész oldal használható legyen. Ha ez kisebb felbontáson is megvalósul, akkor ne variáld át.

[ Szerkesztve ]

Sziasztok! A flexboxos elrendezéseket gyakorlom. Mit gondoltok ez az elrendezés miért nem hasonlít erre:

Elvileg a kódolt flexboxnak is így kellene kinéznie, ennek ellenére a különböző div konténerek teljesen máshol találhatóak. Mely tulajdonság "elírása" okozta ezt? Többször is összevetettem a példatárban található kódot az enyémmel, de mégsem jó.

Előre is köszi a válaszokat!

[ Szerkesztve ]

Valamint még az előző témához kapcsolatban elfelejtettem kérdezni, hogy az itt található kódrészletben a flexbox konténer flew-flow:row wrap; tulajdonság beállítása után mégsem töri meg az oldal kinézetét a különböző div konténereknél, ha kisebbre húzom az ablak méretét. Ez miért nem következik be?

Viszont ha a flex-flow tulajdonságot nem shorthandban írom, hanem így:
flex-wrap:wrap;
flex-direction:row; akkor gond nélkül működik a honlap törése kisebb ablakméretekben.

[ Szerkesztve ]

Most látom, hogy flew-flow-t írtam shorthandban flex-flow helyett. Így már minden világos!

Jól elbeszélgettem magammal.

Hogy egy picit ON is maradjak. Az SVG2 jelölőnyelvet mennyire érdemes elsajátítani a HTML5 és a CSS3 mellé?

[ Szerkesztve ]

"Az SVG2 nyelvet mennyire érdemes elsajátítani a HTML5 és a CSS3 mellé?"
Annak ellenére, hogy összességében nyilván nem haszontalan, szerintem teljesen felesleges egyelőre foglalkoznod vele, inkább mélyítsd az eddigi tanulmányaidat, plusz kezdd el inkább tanulni pl. a (kliensoldali) JavaScriptet. Aztán jöhet valami szerveroldali nyelv.

Sk8erPeter

A CSS és HTML mellé ha piacképes Frontendes tudást szeretne szerezni az ember mennyire fontos még a keresőoptimalizálásban szerzett gyakorlat? Valamint a Javascripthez az AJAX?

Nagyon fontos. De az AJAX nem csak akkor fontos ha SPA (Single Page Application) -t csinálsz, pl azok az emberek is találkoznak vele akik Entriprise JEE-t használnak JSF-el. Sőt, a JavaScript kikerülhetetlen manapság. Azt mindenképp érdemes megtanulni.

Én januártól az alábbi 4 továbbképző - kurzuson fogok résztvenni folyamatosan 2 hónapon keresztül, ezt ajánlották számomra továbbképzésre speciell a frontendes területre. Feketével a kurzus címe, dőlttel pedig a kurzus tartalmi részei láthatóak. Szóval tanulni fogok elég sok mindenről, emellett magamtól még majd később PHP-zok és megismerkedem majd a CSS Preprocessorokkal is, de úgy gondolom a kurzus tartalmilag felöleli a frontendes programnyelveket és elvárásokat. Ti mit gondoltok erről? Vagy még majd mit lenne érdemes "hozzátanulni"? Apropó Photoshopos, Illustratoros okosságok mennyire játszanak fontos szerepet? Vagy ez egy külön műfaj "designer-meló", nem mindegyik frontendes állásnál kritérium? Vagy jó ha ezt is tudja az ember alapszinten?

Webseitengestaltung mit (X)HTML und CSS - Struktur,
Texte, Farben, Hyperlinks, Grafiken, Formulare, Tabellen

Einführung
Aufbau eines HTML5-Dokuments
Texte strukturieren
Farben
Hyperlinks
Grafiken
Listen
Formulare
Tabellen
Unterschiede zu XHTML und HTML4

Webseitengestaltung mit (X)HTML und CSS - moderne
Weblayouts, Barrierefreiheit, Planen und Erstellen einer
eigenen Website

Zusammenspiel von HTML5 und CSS
Grundlagen moderner Weblayouts
Standardkonformes Webdesign: Standards, Regeln
Meta-Tags
Suchmaschinenoptimierung (SEO)
Barrierefreiheit
Ausblick: JavaScript
Grafiken für Webseiten optimieren
Planung und Konzeption von Internetseiten
Publizieren der eigenen Webseite im Internet

JavaScript, Basics

Einführung / Grundlagen
Erste Schritte
JavaScript einbinden
Sprachelemente
Kontrollstrukturen
Funktionen
Fehlersuche / Debugging
Das JS-Objektmodell

JavaScript - Aufbaukurs

Zugriff auf HTML-Dokumente
Ereignisse / Events
Cookies
DOM-Scripting / DOM-Manipulation
DHTML
Audio und Videosteuerung in HTML5
Ausblick: AJAX
Ausblick: JQuery

[ Szerkesztve ]

Na jó, szerintem tisztázni kéne először is, hogy mi a célod? A célod, hogy Web Developer legyél, vagy a Front-end ninja, vagy Designer, vagy multifunkciós emberke?

Igazából minden érdekel, de ha szűkíteni kellene a dolgot, akkor inkább HTML, CSS, Javascript irányba mennék el, inkább Frontend. De mivel érdekel a design és hasonló dolgok is (annak ellenére, hogy még nem mélyültem el a témában), azt is csinálnám emellett. Szóval olyan multifunkciósnak nevezném a dolgot.
De mivel a kurzus is inkább frontendre megy rá, meg azt tanulnom jelenleg is, tisztán frontendes is szívesen lennék.

De ha már így felvetetted, tisztán a Webdeveloper mivel foglalkozik? Ő Backendes, vagy Back és - Frontendes is egyben? Mert persze a szó szoros értelmében ezt a pozíciót sem vetném el, de mivel úgy godolom, ő foglalkozik szerver oldali dolgokkal is, inkább első körben Frontendes technológiákra feküdnék rá, hozzám az áll közelebb.

Még egy kérdés akkor már. Mely speciális szaktudással van nagyobb esélye, hogy az ember munkát kapjon? Frontend, backend, designer avagy a multifunkciós pozíció?

[ Szerkesztve ]

Hát, én ezt így látom (és lehet, hogy rosszul látom, sőt ami jön az szubjektív vélemény):

Megjegyzés: az általam írt kategóriák között nyílván van átlapolás amire nem térek ki. Illetve, nyílván egy nagy vállalatnál egy csomó feladatra van külön ember. Pl Designer, Integrátor, QAEng -> testing, CI, stb.. ezek feladatkörét is besoroltam lentebb valamelyik kategóriába.

Frontend-ninja
===========

* van érzéke a design-hoz.
* perfekten tudja a HTML-t, CSS-t
* ért a Photoshophoz
* ért a typográfiához
* ért a képmanipulációhoz, tudja, hogy kell bánni az svg-vel
* ért alapszinten a videóvágáshoz (olyan szinten, hogy ha a weblap megkívánná, akkor létre tudna hozni valamit amit megjelenít a weblapon)
* elsősorban web-lapokat készít
* tudja, hogy hogyan működik a browser (repaint, rerender, stb...)
* jól tudja használni a jQuery-t DOM manipulációra
* vágja a templatinget (templating alatt html templating-et, és css templatinget értek)
* ért valamilyen CMS-hez (WordPress, Drupal)
* ért a SASS, LESS, Compass valamelyikéhez

Web-Developer
============

* nem érdekli a design, nem is ért hozzá
* kevéssé érdekli a HTML, CSS, de alap szinten értenie kell hozzá
* értenie kell, hogy hogy működik a browser, értenie kell a HTTP-t
* elsősorban web-appokat készít
* perfekten vágja a JavaScriptet
* perfekten vágja az AJAX-ot, Promisokat, tudja mi az a Web-Socket, Web-Worker stb..
* mivel ő elsősorban programozó, így érti a programozás fogalmait (OOP-re gondolok elsősorban)
* algoritmikus gondolkozású
* alapszinten ért valamilyen backend oldali technológiához
* létre tud hozni backend oldalon pl egy REST szervert
* alap szinten ért a webszerverekhez/alkalmazásszerverekhez, ezeket tudja használni
* ért a toolinghoz, tudja, hogy miből áll egy build folyamat
* tudja, hogy mi az a CI
* esetleg tudja, hogy hogyan készítsen egy mobil alkalmazást (natív, vagy hybrid)
* ért a debugginghoz (DevTools)
* képes tesztelni az alaklmazást (Unit tesztek, Integrációs tesztek)

Backend-ninja
===========

* Nem igazán ért a kliens oldalhoz, nem ért különösebben a browserhez, JavaScripthez, CSS-hez, HTML-hez
* perfekten vág valamilyen szerver oldali technológiát (Java, .Net pl..)
* képes bármilyen szerver oldali alkalmazást elkészíteni (nem architect szinten) REST, SOAP, desktop stb..
* jól ért az adatbázisokhoz, képes azokat finomhangolni, optimalizálni
* jól ért az OOP-hez (ugyanúgy mint a web-developer)
* érti a build process-t
* képes tesztelni a backend oldalt (unit tesztek, selenium, mocking -> pl soapUI)
* képes az alkalmazásból külső komponensek meghívására, és ezen külső komponensek rendszerbe integrálására
* nagyon jól ért az alkalmazásszerverek konfigurálására (ezek közül többet is ismer, Glassfish, JBoss, Websphere pl..)
* járatos a UNIX világában
* ha a szerveren valamit be kell állítani akkor ő ért hozzá
* DevOps

---------------------------

Biztos sok mindent kihagytam, de hirtelen ennyi jutott eszembe, és ÉN nagyjából így érzem a dolgot momentán.

Mely speciális szaktudással van nagyobb esélye, hogy az ember munkát kapjon?

Java/C# developerként biztos kapsz munkát.
Web-Developerként is biztos kapsz munkát
Designerként nem tudom hogy kapsz-e munkát -> szerintem igen, de abban nem vagyok járatos.

Valószínűleg tök mindegy, hogy melyik utat választod, ha szorgalmas vagy, folyamatosan bővíted a spektrumod, akkor lesz munkád. És lesz jó fizetésed. Csak elkötelezettnek kell lenni a munkádat illetően.

----------------------------

> Szerintem Backendesként lehet legjobban keresni, utána WebDev-ként, utána Frontendesként
> Szerintem WebDev-ként kell a legtöbb mindenhez érteni, utána Frontendesként utána Backendesként
> Szerintem Backendesként kell a legmélyebb tudás, utána passz

Üdv

[ Szerkesztve ]

"Apropó Photoshopos, Illustratoros okosságok mennyire játszanak fontos szerepet?"
Hát szerintem frontendesnek kötelező ismernie valamennyire (mindenképp) vagy nagyon (attól függ, egész pontosan a munkakörnél mit értünk most frontend alatt (lehet, hogy kb. mindent beleért a munkáltató, amit az ügyfél a honlapodból lát, lehet, hogy annak csak egy szeletével foglalkozik), kicsit sztem elmosódik ez a fogalom) a Photoshopot.

"Unterschiede zu XHTML und HTML4"
Hát nem tom, szerintem az XHTML és HTML4 különbségeivel most tök felesleges foglalkoznod, foglalkozz azzal, amivel a jövőben is fogsz, tehát HTML5-tel. Aztán majd ha később mégis érdekel, majd magadtól megtanulod, mi is az az XHTML.

Amúgy tényleg alaposan nézz körül, hogy egy adott tanfolyamról milyen visszajelzések vannak (ha lehet ilyen véleményeket olvasni valahol), mert túl sok helyen túl sok a kókler, aki elmegy tanárnak, mert azt hiszi, ért hozzá (még BME-n is találkoztam olyan webfejlesztő kurzussal (szabadon választható tárgy volt, kíváncsiságból felvettem), ahol nekem égett az arcom a tanár nevetségesen elmaradott (90-es évekbeli) tudásától és leadott tananyagától (még valaki komolyan veszi); de szerencsére ennek ellenkezőjét is tapasztaltam, egy Microsoftnál is dolgozó emberkétől, akitől rengeteget lehetett tanulni, és nagyon képben volt).

Németországban tartózkodsz egyébként?

(#1461) Jim-Y:
"ami jön az szubjektív vélemény"
És megint Egy vélemény még mindig csakis szubjektív lehet... Olyan nincs, hogy "objektív vélemény", mivel a kettő kizárja egymást. Muszáj volt megjegyeznem.

[ Szerkesztve ]

Sk8erPeter

Akkor megerositetted azt amit gondoltam, mert en is ugy hiszem hogy a meg megmaradt par regebbi tipusu monitor miatt nem fogom atvarialni ( hiszen azokon is rendesen mukodik) csak az egesz monitort kitolti maga a tartalom.
Es ezekbol a monitorokbol ugyan nem tudom hogy mennyi lehet meg hasznalatban, de az biztos hogy az ido mulasaval egyre kevesebb lesz beloluk.

Koszi

[ Szerkesztve ]

XD alias IKSZDé

Köszönöm a véleményeteket. Igen, Németországban élek már másfél éve.

Szvsz ez a 3 felé bontás értelmezhetetlen. Amit a backendeshez írtál, az valójában több külön szakmaként szokott megjelenni, pont az adott dolgok összetettsége miatt, mint pl. SQL fejlesztő, rendszergazda. Sőt még SQL-en belül is külön szokták venni, azaz van SQL fejlesztő, és SQL adminisztrátor.

Aztán persze cégenként, cég méretenként változik, hogy hol hány fő tölt be 1-1 szerepet, vagy kis cégeknél 1-1 fő hány szerepet tölt be.

Én kérek elnézést!

De, teljesen logikus, csak értelmezni kell a szavakat.

"A vélemény szó utalhat arra, hogy amit írok azt saját kútfőből teszem, és nem másolom valahonnan"
Nem, a vélemény nem csak sajátod lehet, hanem lehet másé is. A vélemény pont az, amit idéztél az előbb ("egy személynek a saját nézőpontjából kiinduló elgondolása a dolgokról"), úgyhogy ez most félremagyarázás, ha másolnád/idéznéd valahonnan, akkor az attól még, hogy nem a saját nézőpontod, ettől még lehetne akár más véleménye is, ebből következően a másolt szöveg az illetőnek a saját nézőpontjából kiinduló elgondolása, következésképp továbbra sem lehet objektív.
Ha viszont száraz tényeken alapuló szöveget írsz (pl. leírod, hogy van gravitáció), vagy épp ilyeneket másolsz valahonnan (tök mindegy, milyen forrásból származik), az már nem vélemény - ergo nem is szubjektív, hanem objektív.

A "szubjektív vélemény" szavak összetétele tehát redundáns, és tulajdonképpen értelmetlen (mivel vélemény sosem lehet objektív).
Én szívesen OFF-olok erről még pár hsz.-en át, bármilyen szőrszálhasogatás is, eldumálhatunk róla, de mások nem biztos, hogy díjazzák.

(#1468) martonx:
Egyetértek, ezek a határok amúgy is legtöbbször szerintem elmosódnak, nincs olyan, hogy mondjuk a "web-developer" "nem ért" a design-hoz semmilyen szinten, vagy hogy a "backend-ninja" ne értene a kliensoldalhoz, "nem ért különösebben a browserhez, JavaScripthez, CSS-hez, HTML-hez", szerintem ez bullshit, elég nagy probléma, ha ilyen szinten csőlátású egy webfejlesztő, akár a frontenden, akár a backenden dolgozik.
Azért nekem elég fura lenne, ha valaki PHP expert lenne, de fingja nem lenne, hogy működik a böngésző, hogy kell leírni egy működő kódot JavaScriptben, és ne tudná, hogy kell CSS-sel formázni, vagy HTML-ben pötyögni...

[ Szerkesztve ]

Sk8erPeter

Sziasztok.

Ha letoltok egy kepet a "szabadon felhasznalhato vagy megoszthato" kepek kozul, (google kepek kozul) akkor azt mar hasznalhatom az oldalamon is ugye?

Van meg olyan hogy:

Szabadon felhasznalhato vagy megoszthato, akar uzleti celbol is.

Szabadon felhasznalhato, megoszthato vagy modosithato.

Szabadon felhasznalhato, megoszthato vagy modosithato akar uzleti celbol is.

[ Szerkesztve ]

XD alias IKSZDé

Ja, de illik feltüntetni a kép forrását.

Sk8erPeter

Ertem, koszonom.

XD alias IKSZDé

Ha a honlap egységeik (header, wrapper, footer, article ... etc.) méretezéséről van szó, akkor a responsive design kialakítása érdekében a pl. a különböző div konténerek méreteit célszerűbb és érdemesebb %-ban megadni? Vagy érdemesebb külön erre is inkább @media tulajdonságot használni? Mi erre a "szabály"?

[ Szerkesztve ]

Media query egy bizonyos méret alatt már elengedhetetlen. %-ban olyanokat jó megadni, hogyha mondjuk van 3 oszlopra bontott oldalad, ahol az arányokat szeretnéd tartani például 720p-s monitoron és 1080p-s monitoron is.

Ha a layout engedi, talán a legjobb megoldás a grid. Ehhez is kell (na jó, csak célszerű) media query-t használni, de fő váz, így egyszerű és egységes lesz.

but without you, my life is incomplete, my days are absolutely gray

A konténerek különböző elhelyezésére inkább a display tulajdonságot, vagy flexboxot érdemesebb használni? Vagy is-is? Mert most párhuzamosan tanulgatom a kettőt, de nem tudok különbséget tenni, hogy most mikor melyik célszerűbb... .. és erősítsetek meg, hogy jól gondolom, hogy a float tulajdonsággal megoldható tájolást csakis a legvégső soron érdemes alkalmazni, vagy ez hülyeség? Valahol ezt olvastam, hallottam.., és hogy elsősorban a display, flexbox-ra kellene hagyatkozni.

DNReNTi, Zedz: Köszönöm a válaszokat!

[ Szerkesztve ]

DNReNTi, Most olvasom a grides linkelt cikkedben, hogy "grid is extremely new, not well supported", tehát egyenlőre a "régebbi" technológiák használata javasolt jelenleg a responsive design kialakításánál? Bár érdemes a griddel már részletesebben ismerkedni, mert a jövőben ez fogja átvenni a régebbi metódusokat? Mit gondolsz erről?

[ Szerkesztve ]

Ah igen, mert nem ezt akartam linkelni. Hanem ezt. Ez nem a display: grid; attribútumra épít, hagyományos elemekből építkezel "rácsot", így nincs támogatottsági probléma. 1000 példát találsz amúgy erre a neten, de miután megérted mi a lényeg, saját magad sem nagy cucc megírni egyet. Mivel most menő az egyszerű, letisztult "flatdesign", így a "rácsrendszer" kiváló megoldás. Érdemes megismerni, responsive oldalhoz, szvsz a legjobb megoldás, ha sikerül elég általánosan megírni, akkor pedig többször is felhasználhatod.

but without you, my life is incomplete, my days are absolutely gray

Jól látom, hogy ez csak IE 10 után jó vagy az alsó táblázat átverés?

"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán

Jól látod, nem hogy IE10 után jó, de csak az IE10 és 11 támogatja, az is -ms- prefix-el. Ezért is írtam, hogy nem ezt akartam linkelni a kettő közül, hanem amit itt. Mondjuk nem árt tudni róla, de el fog telni még pár év mire ez így általánosan használt megoldás lesz... ha az lesz.

Szerk: elírás

[ Szerkesztve ]

but without you, my life is incomplete, my days are absolutely gray

Köszi az új linket.

Erről mit gondoltok? Pontosabban arra lennék kíváncsi, hogy pl. a media query-ben alkalmazott méretezések responsive design esetén így ebben a példában általánosnak mondhatóak? Ezeket a méretezéseket %-ban és px-ben nagy vonalakban lehet alapul venni más oldalak kialakításánál is, ha a responsive design is szerepet játszik?

@media all and (max-width: 480px)

body {
width: 85%;
max-width: 1280px;
min-width: 960px;
}

@media all and (min-width: 481px) and (max-width: 780px)

body {
width: 90%;
max-width: 780px;
min-width: 485px;
font-size: 80%;
}

@media all and (min-width: 780px)

body {
width: 90%;
max-width: 480px;
}

Gondolom az article, aside ... egyéb "részek" hossz/szélessége, már ezek mintájára szépen kiszámolgatható margin, padding, border ... méretekkel együttvéve, de most a fő body tagre és a media queryben alkalmazott min, max értékekre térnék ki, hogy mennyire tekinthetőek "iránymutatónak"?

Remélem érthetően írtam le, amit szerettem volna.

[ Szerkesztve ]

Valaki elmondaná, hogy pl.: ebben a body tagben mit takar a 100% a font tulajdonságnál?

Valamint a Font tagben írt Georgia, "Times New Roman...", Times azért van így írva, mert pl.: ha a Georgia típust nem értelmezi a böngésző, akkor ugrik a Times New Roman-ra, és így sorban? Ezt a font-family - generic family, meg úgy ámblokk a font tulajdonság felépítettségét elmagyarázná nekem valaki?

body {
width: 960px;
background: #fff;
margin: 0 auto 2em;
font: 100% Georgia, "Times New Roman", Times, serif;
}

Előre is köszönöm a segítséget!

Kérlek az előző h.sz.-ra is nézzetek majd rá.

[ Szerkesztve ]

A font-family attribútummal felsorolhatod azokat a fontokat amiket használni szeretnél. A sorrend számít, a prioritást jelenti, tehát az első lesz az első és így tovább. Első, de miben?

"ha a Georgia típust nem értelmezi a böngésző, akkor ugrik a Times New Roman-ra, és így sorban?"
Majdnem. Ha az adott karakter nem található az adott font karakter map-jén, akkor a következőn keresi, amíg el nem fogy, vagy meg nem találja.

"ebben a body tagben mit takar a 100% a font tulajdonságnál?"
A font-size: 100%; azt jelenti hogy a betűméret egyenlő lesz a böngésző default értékével, vagy ha azt már felüldefiniáltad, akkor az öröklöttel. Magyarul ennek így kb semmi értelme nincs.

Szerk:
A korábbi hozzászólásodhoz ajánlom ezt a posztot.

Már a kód elejében ellentmondásba ütközöl:
Azt mondod az első breakpoint max 480px-ig tart. Erre beírod hogy a szélesség 85%, tehát max 408px, aztán jön a max-width: 1280px; de ami még rosszabb: min-width: 960px; Na ezen menjen el a böngésző. Gondoltam lehet azért írtad be, mert úgyis tovább öröklődik, de nem, mert a következő breakpoint-on felülvágod szintén ellentmondással, hiszen a minimum szélesség nagyobb mint a breakpont kezdő szélessége.

[ Szerkesztve ]

but without you, my life is incomplete, my days are absolutely gray

Köszönöm a válaszod! A kódot egy oktatóvideóból vettem. Ennek ellenére a tutorialban a megírt kód szépen hozza az átméretezéseket, ha kisebbre viszem a böngésző méretét.

Kicsit más:

- Az adott menüpontban hogyan lehetne beállítani, hogy link hover tulajdonság hatására ne csak a szöveg körül legyen fehér háttér, hanem az egész adott menüpont sávjában? Úgy mint ezen az oldalon: [link]

- A headerben található img-et, ami tulajdonképpen a logó, valamiért nem engedi beljebb helyezni a "Kezdőlap" menüponttal egyvonalban, holott a headerben található még egy p tag, ami jobbra van floatolva, és őt simán tudom mozgatni a jobb széléről. Mi lehet a probléma? Persze JSFiddleben simán megy: [link] De valamiért az éles oldalon nem.

- Valamint még érdeklődnék, hogy az eredeti oldalon amikor görgetem le az oldalt, a menüsáv fixen felül marad, én az általam készített oldanál hiába teszem a nav elemet fix pozícióra, ha görgetem lefelé, ugyan felül marad, de így.
Egyrészt nem is pontosan felül marad az oldal tetején, hanem valamivel alá helyezi, másrészt a szélessége is valamiért lerövidül. Mi lehet ennek az oka?

Bocsánat, hogy ha sokra sikeredett volna a megoldatlan problémám, de most épp ezek foglalkoztatnak. A célom, hogy egy Wordpress alapú oldalamat saját magam koppintsam html és css segítségével grides elrendezésbe gyakorlásképpen. A főoldal kreálásánál pedig ezeket nem sikerült még "lemásolnom".

Előre is köszönöm az eddigi és a mostani hozzászólásokat!

[ Szerkesztve ]

"Ennek ellenére a tutorialban a megírt kód szépen hozza az átméretezéseket, ha kisebbre viszem a böngésző méretét."
Erre Wagner György tanár úr hírhedt idézetét tudom ismét elővenni:
Működik, de nem jó.

1. kérdésre a válasz:
Benne is van az átlinkelt oldalban. Az a tag blokkelem, amikor rámégy egérrel, az egész ami kifehéredik az mind maga a link. Tehát az a tag. Gondolom nálad a teret a li elem tölti ki, és inline van benne a link.

2. kérdés:
Ilyen esetekben mint már írtam is korábban, teljesen felesleges float-tal szívatni magad, sokkal jobb megoldás az inline-block elemek használata. Egyébként, így, margin attribútummal beljebb tudod tolni.

3. kérdés:
Ehhez már JS is kell. Létrehozol egy osztályt ami a menüt fix pozicióba rakja az oldal tetejére. Amikor az oldal legördül egy adott pozícióba ezt az osztályt hozzácsapod az elemhez (a menühöz). Ez a linkelt oldalán nagyon rondán, inline van megoldva.

but without you, my life is incomplete, my days are absolutely gray

" Benne is van az átlinkelt oldalban. Az a tag blokkelem, amikor rámégy egérrel, az egész ami kifehéredik az mind maga a link. Tehát az a tag. Gondolom nálad a teret a li elem tölti ki, és inline van benne a link. "

Ha az li elem hover tulajdonságát teszem fehér hátterűvé [link], nem változik semmi. Nem erre gondoltál?

" Ilyen esetekben mint már írtam is korábban, teljesen felesleges float-tal szívatni magad, sokkal jobb megoldás az inline-block elemek használata. Egyébként, így, margin attribútummal beljebb tudod tolni. "

Próbáltam az általad ajánlott marginnal beljebb húzni, de valahogy arra sem reagált az éles oldalon. Így hát a javasolt display: inline-block metódussal próbálkozom. Itt viszont most nekem az a bajom, hogy a kép alá teszi ilyenkor a szöveget, és ha a szöveget oldalra tolom, a jobb oldali pozíciónak megfelelően, akkor a kép alatt üresen marad a hely. Hogyan lehetne ezt egy sorba hozni?

" Ehhez már JS is kell. Létrehozol egy osztályt ami a menüt fix pozicióba rakja az oldal tetejére. Amikor az oldal legördül egy adott pozícióba ezt az osztályt hozzácsapod az elemhez (a menühöz). Ez a linkelt oldalán nagyon rondán, inline van megoldva."

JS-el majd később szeretnék foglalkozni, de köszönöm, hogy írtad. Azt hittem simán CSS-el van megoldva. Azt hogy a linkelt Wordpress alapú oldalon mit is takar az inline megoldás, és miért "ronda", azt részleteznéd?

[ Szerkesztve ]

"Ha az li elem hover tulajdonságát teszem fehér hátterűvé [link], nem változik semmi. Nem erre gondoltál?"
Nem. Hanem így: jsfiddle.

"Hogyan lehetne ezt egy sorba hozni?"
Így. Figyelj arra, hogy én most itt beírtam fix 200px szélességet. Ha nem adsz a blokkelemnek szélesség értéket akkor automatikusa 100% lesz.

"mit is takar az inline megoldás, és miért "ronda", azt részleteznéd?"
Ezt takarja:

Ezt bele lehetett volna tenni egy osztályba és azt hozzáadni az elemhez. Szebb, általánosabb, és egyszerűbb megoldás is szemben ezzel, hogy CSS stílust ad hozzá.

but without you, my life is incomplete, my days are absolutely gray

Ezen az oldalon található "effekt", amikor rámegyek a képekre, és alatta kis sávban egy átlátszó részen feljön egy szöveg, az milyen css tulajdonsággal állítható elő? Vagy ehhez is már JS kellene?

Úgy általánosságban kérdezném, nem tudom, hogy erre van-e "bevált módszer", de ha nektek valamilyen effekt, megjelenés megtetszik egy adott oldalon, amit a saját oldalatokon is alkalmazni szeretnétek, arra hogyan kerestek rá, néztek utána, hogy "hogyan csinálhatta az oldal eredeti tulajdonosa azt?". Gondolok itt a hasonló "képanimációkra", vagy animált menükre, ésatöbbi

Ehhez nincs szükség JS-re. Tessék egy übergagyi példa. Ha megtetszik valami, arra úgy a legkönnyebb rákeresni, hogy megnézed, adott oldalon, hogy oldották meg. Erre való a böngészők saját developer tool-ja.

but without you, my life is incomplete, my days are absolutely gray

Sőt, a visibility, opacity és transition segítségével némi áttűnéssel is lehet játszani.
>> http://jsfiddle.net/pad5q1kx/1/

Sk8erPeter

Mint írtam: "egy übergagyi példa"
Annyira má' nem bonyolítottam. Részletkérdés. De tény, szebb megoldás így.

but without you, my life is incomplete, my days are absolutely gray

Jó volt a példád, pont jó, hogy letisztult, hogy értse a kérdező, mi a helyzet, csak kiegészítésnek szántam, nehogy magadra vedd.

Sk8erPeter

DNReNTi, Sk8erPeter Köszönöm szépen! Igen, a DevToolsokra nem is gondoltam hirtelen. Technikai kérdés: A korábban linkelt oldalon elég sokmindent <div class="xy" </div> helyett <span class="xy"></span>-t alkalmaznak. Ez miben más, mintha div konténereket hozna létre?

[ Szerkesztve ]

A <div> blokkszintű elem, a <span> pedig inline.

Köszi, elmagyaráznád nekem, hogy itt a fentebb linkelt oldalon pl. miért van számomra "furcsán" a span theo osztályában a WORK kijelentés? Az adott oldalon még több helyen találkozok hasonló megoldással. Ez miért is van így, miért van szótagolva a szó és így beillesztve az osztályba?

<div class="caplabels">
<div class=" singlecolumncap">
W
<span class="theo">O</span>
RK
</div>
<div class=" singlecolumndescription"> Branding, Identity, Packaging, Illustration </div>
</div>

Tessék, itt egy példa.

Mint láthatod, ha <div> közé zárom az O betűt, akkor az előtt és után lesz 1-1 "sortörés". Ez azért van, mert block szintű elem.

Ha <span>-t használsz, akkor a szöveg az eredeti formájában fog megjelenni, viszont ki tudod jelölni a kívánt részt. Ez az inline szintű elem.

De CSS segítségével rá tudod húzni az egyik elem tulajdonságát a másikra. Pl.: display: inline-block, vagy display: block;.

Hogy mi a probléma az oldalon lévő O betűvel azt nem tudom.

[ Szerkesztve ]

Szerintem nincs vele semmi probléma, gondolom valami arculati megfelelés az oka, ha megnézed az osztály negatív jobb és bal margót állít be az elemre (azaz az O betűre), így az közelebb kerül a szomszédaihoz. Más okot nem tudok elképzelni.

but without you, my life is incomplete, my days are absolutely gray

Igen, megnéztem én is mit csinál az osztály ami rajta van, de szerintem a marginok nélkül lenne jó, így csak annyit értek el, hogy közelebb van a W betűhöz... érdekes, de ők tudják.

Gondolom pont az a cél.

(#1495) adam_
Kiegészíteném picit amit Zedz írt.
A blokk (block) szintű elem tulajdonságai:
- Mint ő is írta, előtte után sortörés van, ha ezt nem definiálod felül. (float)
- Ha nincs definiálva szélesség, kitölti a rendelkezésére álló teret. (Azaz a szülő elem szélességét)
- Ha nincs definiálva magasság, akkor a benne lévő elemek magasságáig terjed ki. (Ezért van, hogy pl egy üres <div> nem látszik, mivel a magassága nulla.)
- Definiálhatóak margin és padding attribútumok minden irányban. (Érdemes használni a box-sizing: border-box; fixet, megkönnyíti a matekot.)

A sorszintű (inline) elemek tulajdonságai:
- Nem okoz sortörést, marad a "szöveg"környezetben. (Azért tettem "" jelbe, mert pl az img tag is inline)
- Csak jobb és bal margin definiálható.
- Nem akarok hülyeséget mondani, azt hiszem padding minden irányban alkalmazható.
- Nem definiálható magassága és szélessége.

Így hirtelen ennyi.

but without you, my life is incomplete, my days are absolutely gray

DNReNTi, Zedz

Ehhez a kódhoz lenne két kérdésem. Élesben valamiért a .title a:link {
text-decoration: none; } tulajdonság hatására sajnos ha ráviszem az egeret az "Adam" title-re, még aláhúzza, viszont most így beillesztve JSFiddleben meg nem az adott linket. Mi lehet a gond amiért JSben működik, de amúgy meg nem?!

Valamint hogyan tudnám pontosan egy sorba hozni a címet és a menüt? Hiába adok a .title-re padding avagy margin-top: 10-20px-elt nem viszi egy sorban a menüvel.

[ Szerkesztve ]