mboost-dp1
Hente position (css) med js
Hejsa
Jeg har lavet et lille script til at hente x/y koordinater, for et element:
Jeg har et halvavanceret stylesheet, der tit gør brug af position: relative, til at positionere elementer absolut på elementet med relative, istedet for at skulle angive koordinater for hjørnet af browseren
Så for at undgå, at jeg får koordinater fra element til body, istedet for kun at få koordinater til et element med position: relative, ville jeg gerne tjekke om elementet har den style på sig, men jeg kan kun hente det ud med objObject.style, der kun giver mig inline style..
Så er der ikke en måde i js, at hente style ud, der kommer fra et stylesheet?
Jeg har lavet et lille script til at hente x/y koordinater, for et element:
function fnGetOffset(objObject) {
iLeft = 0
iTop = 0
while(objObject.tagName != "BODY") {
alert(objObject.tagName + " (" + objObject.id + "/" + objObject.className + "): " + objObject.style.position)
iLeft = iLeft + objObject.offsetLeft
iTop = iTop + objObject.offsetTop
objObject = objObject.parentNode
}
return [iLeft,iTop]
}Jeg har et halvavanceret stylesheet, der tit gør brug af position: relative, til at positionere elementer absolut på elementet med relative, istedet for at skulle angive koordinater for hjørnet af browseren
Så for at undgå, at jeg får koordinater fra element til body, istedet for kun at få koordinater til et element med position: relative, ville jeg gerne tjekke om elementet har den style på sig, men jeg kan kun hente det ud med objObject.style, der kun giver mig inline style..
Så er der ikke en måde i js, at hente style ud, der kommer fra et stylesheet?
Forklar mig hvad der er galt i at bruge div-layouts, hvor en eller flere elementer (måske?) er relativt positionerede..
Det er da 10 gange lettere, når man gerne vil placere noget absolut (så det ikke påvirker flow og kan køre henover andre elementer, som en slags popup) - og ikke engang "forkert" eller et hack
(Du kan slappe alt det du vil, hvis du bruger fancy udtryk, du ikke forklarer)
Det er da 10 gange lettere, når man gerne vil placere noget absolut (så det ikke påvirker flow og kan køre henover andre elementer, som en slags popup) - og ikke engang "forkert" eller et hack
(Du kan slappe alt det du vil, hvis du bruger fancy udtryk, du ikke forklarer)
#2
Må indrømme at jeg ikke kan se noget galt i at bruge Hungarian Notation.
(som er: http://en.wikipedia.org/wiki/Hungarian_notation)
Må indrømme at jeg ikke kan se noget galt i at bruge Hungarian Notation.
(som er: http://en.wikipedia.org/wiki/Hungarian_notation)
Alting!
Det er grimt, unødvendig, ubrugeligt, plus hvis du ændre en type skal du ændre samtlige variable navne.
objObject er dårlig navngivning. Det samme er fnGetOffset , da GetOffset tydeligvis altid vil reffere til en funktion da navnet i sig selv beskriver en handling.
iLeft giver heller ikke mening, Karga mener sikkert at der er en "integer", selvom det burde være "indention".
Så variable navnet burde være "leftIndention" eller "leftMargin", "marginLeft" etc.
Og så er jeg dybt skuffet over at du kalder dig selv professionel uden at vide hvad du laver :p
Lidt info til de tungnemme:
Funktion/Metode navne: Beskriver en handling/funktion
Variablenavne: Beskriver indholdet af den givne variabel
Parametre: Beskriver indholdet af det givne parameter.
Og brug DOKUMENTATION (ie. kode-kommentarer) istedet for hungarian notation, det giver så uendelig meget mere mening, og folk skal ikke GÆTTE til hvad dine personlige notations betyder.
Det er grimt, unødvendig, ubrugeligt, plus hvis du ændre en type skal du ændre samtlige variable navne.
objObject er dårlig navngivning. Det samme er fnGetOffset , da GetOffset tydeligvis altid vil reffere til en funktion da navnet i sig selv beskriver en handling.
iLeft giver heller ikke mening, Karga mener sikkert at der er en "integer", selvom det burde være "indention".
Så variable navnet burde være "leftIndention" eller "leftMargin", "marginLeft" etc.
Og så er jeg dybt skuffet over at du kalder dig selv professionel uden at vide hvad du laver :p
Lidt info til de tungnemme:
Funktion/Metode navne: Beskriver en handling/funktion
Variablenavne: Beskriver indholdet af den givne variabel
Parametre: Beskriver indholdet af det givne parameter.
Og brug DOKUMENTATION (ie. kode-kommentarer) istedet for hungarian notation, det giver så uendelig meget mere mening, og folk skal ikke GÆTTE til hvad dine personlige notations betyder.
#2
Hvorfor?
Hvad er der galt i at bruge position: relative; ?
#Karga
For lige at forstaa dig ret, hvilket output giver "objObject.style" dig saa?
JEg tror det eneste umiddelbart er offsetParent, men den giver dig bare top/left til en "parent" boks..
Lidt besynderligt at JS ikke kan tjekke alle styles egentligt, der burde vaere en object.styles som bare indeholdt alt om den paagaeldende boks :P
Og du skulle måske overveje at lave en design uden en masse relative elementer.
Hvorfor?
Hvad er der nu galt i god gammeldaws boks-opbygning.
Hvad er der galt i at bruge position: relative; ?
#Karga
For lige at forstaa dig ret, hvilket output giver "objObject.style" dig saa?
JEg tror det eneste umiddelbart er offsetParent, men den giver dig bare top/left til en "parent" boks..
Lidt besynderligt at JS ikke kan tjekke alle styles egentligt, der burde vaere en object.styles som bare indeholdt alt om den paagaeldende boks :P
Absolut ikke besynderligt, det er et grundlæggende princip i hvordan CSS fungere.
Javascript kan kun tilgå inline styles, så simplet er det.
Det kan godt aflæse det nuværende positionering af et element på skærmen, men ikke hvad en CSS fil har lagt overpå.
Husk at CSS er et style layer som tilføjes oven på DOM, hvor javascript kun kan aflæse selve DOM.
Fordi det kan lade sig gøre! Mindre komplex kode, skaber mindre antal problemer.
Brug af position konstrukten i CSS er 9/10 tilfælde et hack som basere sig i
a) Manglende skills/erfaring
b) Fanatisme mod at bruge tables til kolonne layouts
Javascript kan kun tilgå inline styles, så simplet er det.
Det kan godt aflæse det nuværende positionering af et element på skærmen, men ikke hvad en CSS fil har lagt overpå.
Husk at CSS er et style layer som tilføjes oven på DOM, hvor javascript kun kan aflæse selve DOM.
Hvorfor?
Fordi det kan lade sig gøre! Mindre komplex kode, skaber mindre antal problemer.
Brug af position konstrukten i CSS er 9/10 tilfælde et hack som basere sig i
a) Manglende skills/erfaring
b) Fanatisme mod at bruge tables til kolonne layouts
#6 og #8 du aner jo ikke hvad du taler om :S
1. Jeg har (desværre) set kolleger, der koder usandsynligt ringe, så ens "skills" har intet at gøre med det at tjene penge på programmering - hvad der måske er mere skræmmende, er at en pæn portion af dem jeg kender, der faktisk koder rigtigt godt, de er ikke professionelle, andet end et projekt i ny og næ
2. Det er muligt det er grimt, unødvendigt og ubrugeligt, når du bruger det der ungarske gullash, men kunne det tænkes i din ideelle verden, at andre mennesker tænker anderledes end du gør? Når jeg sætter et i foran en variabel siger jeg blot til mig selv at det er et tal, ikke om det er float, double eller integer, bare et tal
Og NEJ, det er ikke unødvendigt.. det gør, for mig, at variabelnavne kan være utroligt korte og præcise, da jeg ikke skal tænke på om funktionsnavnet evt. er det samme som en variabel - eksempel: Funktionen Offset kan ikke bare smides ind i en variabel, der hedder Offset, men hvis funktionen hedder fnOffset og variablen hedder arrOffset, så kan man læse en sammenhæng mellem de to, men de er totalt adskilte
Navne som objObject kommer, hvis jeg ikke ved nøjagtigt hvad objectet peger på at tagName (kalder divs for objDiv, hvis de ikke har andet "pænere" og mere beskrivende navn
3. Kommentarer er fine, men i en overflod af kommentarer, bruger man dobbelt så lang tid på det.. og hvis man har bare lidt evner og engelsk egenskaber, så kan man læse koden direkte - jeg kommenterer, når jeg ser en funktion i det og ikke bare for at gøre det, fordi det siger manden
4. CSS-layouts er bare "the way to go" - ved ikke om det er css-layouts du ikke kan lide, eller kun det at bruge positionering?
Og hvis man har en god portion erfaring med css, så behøver der ikke være et eneste hack.. personligt vil jeg hellere finde en anden måde, end at bruge et hack og i mit cms er der ikke en eneste af slagsen, selvom det efterhånden er et rimeligt avanceret system, så jeg må åbenbart være en del af de 10% du snakker om..?
Tror ikke på du har lavet vitterligt avancerede layouts før, hvis du mener positonering er dumt/unødvendigt..
5. Når nu du er så glad for dokumentation, hvorfor kommer du så ikke med nogle links til alle dine påstande? Det kan jo ikke bruges til noget, når du bare sviner til og så går videre..
Men hvorfor jeg gider skrive det her ved jeg ikke, du plejer jo altid bare at tage det bid for bid og svare på en endnu mere tom måde.. :S
1. Jeg har (desværre) set kolleger, der koder usandsynligt ringe, så ens "skills" har intet at gøre med det at tjene penge på programmering - hvad der måske er mere skræmmende, er at en pæn portion af dem jeg kender, der faktisk koder rigtigt godt, de er ikke professionelle, andet end et projekt i ny og næ
2. Det er muligt det er grimt, unødvendigt og ubrugeligt, når du bruger det der ungarske gullash, men kunne det tænkes i din ideelle verden, at andre mennesker tænker anderledes end du gør? Når jeg sætter et i foran en variabel siger jeg blot til mig selv at det er et tal, ikke om det er float, double eller integer, bare et tal
Og NEJ, det er ikke unødvendigt.. det gør, for mig, at variabelnavne kan være utroligt korte og præcise, da jeg ikke skal tænke på om funktionsnavnet evt. er det samme som en variabel - eksempel: Funktionen Offset kan ikke bare smides ind i en variabel, der hedder Offset, men hvis funktionen hedder fnOffset og variablen hedder arrOffset, så kan man læse en sammenhæng mellem de to, men de er totalt adskilte
Navne som objObject kommer, hvis jeg ikke ved nøjagtigt hvad objectet peger på at tagName (kalder divs for objDiv, hvis de ikke har andet "pænere" og mere beskrivende navn
3. Kommentarer er fine, men i en overflod af kommentarer, bruger man dobbelt så lang tid på det.. og hvis man har bare lidt evner og engelsk egenskaber, så kan man læse koden direkte - jeg kommenterer, når jeg ser en funktion i det og ikke bare for at gøre det, fordi det siger manden
4. CSS-layouts er bare "the way to go" - ved ikke om det er css-layouts du ikke kan lide, eller kun det at bruge positionering?
Og hvis man har en god portion erfaring med css, så behøver der ikke være et eneste hack.. personligt vil jeg hellere finde en anden måde, end at bruge et hack og i mit cms er der ikke en eneste af slagsen, selvom det efterhånden er et rimeligt avanceret system, så jeg må åbenbart være en del af de 10% du snakker om..?
Tror ikke på du har lavet vitterligt avancerede layouts før, hvis du mener positonering er dumt/unødvendigt..
5. Når nu du er så glad for dokumentation, hvorfor kommer du så ikke med nogle links til alle dine påstande? Det kan jo ikke bruges til noget, når du bare sviner til og så går videre..
Men hvorfor jeg gider skrive det her ved jeg ikke, du plejer jo altid bare at tage det bid for bid og svare på en endnu mere tom måde.. :S
#7 objObject.style giver et objekt.. desværre.. den har jeg også tænkt på et par gange.. men det objekt giver kun adgang til inline style
offsetParent giver en referance til det øvre element, der er positioneret til.. ehm, svært at forklare hehe.. og jeg kan faktisk ikke forklare hvorfor nogle elementer skal springes over, hvor parentNode ikke gør det
Nå men nu vil jeg squ i seng, har lige brugt et par timer på at finde ud af hvor meget jeg har glemt fra min gymnasietid :S kunne ikke engang finde en simpel formel for et parabelt tidsforløb :S
offsetParent giver en referance til det øvre element, der er positioneret til.. ehm, svært at forklare hehe.. og jeg kan faktisk ikke forklare hvorfor nogle elementer skal springes over, hvor parentNode ikke gør det
Nå men nu vil jeg squ i seng, har lige brugt et par timer på at finde ud af hvor meget jeg har glemt fra min gymnasietid :S kunne ikke engang finde en simpel formel for et parabelt tidsforløb :S
Når jeg sætter et i foran en variabel siger jeg blot til mig selv at det er et tal, ikke om det er float, double eller integer, bare et tal
Det ved programmør nummer 2 ikke! (Desuden, så er det standard at lille i er integer, og stort I er interface -- for dem som nu engang elsker hungarians)
3. Kommentarer er fine, men i en overflod af kommentarer, bruger man dobbelt så lang tid på det..
Du skal dokumentere mindst ligeså lang tid som du koder. (Note: kode != hele udviklingsprocessen).
Links? Læs nogle bøger, tag en uddanelse, arbejde hos firmaer med dokumentationsstandarder og processor.
Navne som objObject kommer, hvis jeg ikke ved nøjagtigt hvad objectet peger på at tagName (kalder divs for objDiv, hvis de ikke har andet "pænere" og mere beskrivende navn
Prøv også at beskrive ting mere humant (på engelsk)
<div> er et block element, som typisk indeholder indhold. dvs. det er en kontainer (container).
thus: <div id="maincontent"> =
var mainContentContainer = document.getElementById("mainContent");
#1
I vores produkt bruger vi jquery plus plugins, et af dem hedder dimension som kan det jeg tror du prøver at opnå.
Du kunne kigge på, hvordan han gør det i funktionen "offset".
http://brandonaaron.net/docs/dimensions/#api-offse...
#8
Det er så ikke helt sandt.
Der er en DOM level 2 function der hedder getComputedStyle som levere et elements samlede stil. Desværre er den ikke universelt understøttet.
Sektionen med overskriften "Reading applied element styles" http://www.howtocreate.co.uk/tutorials/javascript/...
Jeg har lavet et lille script til at hente x/y koordinater, for et element:
I vores produkt bruger vi jquery plus plugins, et af dem hedder dimension som kan det jeg tror du prøver at opnå.
Du kunne kigge på, hvordan han gør det i funktionen "offset".
http://brandonaaron.net/docs/dimensions/#api-offse...
#8
Javascript kan kun tilgå inline styles, så simplet er det.
Det kan godt aflæse det nuværende positionering af et element på skærmen, men ikke hvad en CSS fil har lagt overpå.
Det er så ikke helt sandt.
Der er en DOM level 2 function der hedder getComputedStyle som levere et elements samlede stil. Desværre er den ikke universelt understøttet.
Sektionen med overskriften "Reading applied element styles" http://www.howtocreate.co.uk/tutorials/javascript/...
#6
God dammit, man går i seng, og vågner til en Marathon-debat.
Ikke det store problem når man benytter sig af en nogenlunde kompetent IDE.
Enig, dårlig navngivning, men nu er Hungarian notation per definition med til at beskrive mere end intention (så som type).
Smååååååå sko :-P
Enig... hvis man altså ikke benytter sig af Hungarian notation.
Nej, ikke istedet for, men som et supplement. Dokumentation af kode er alpha omega, men der er også sådan ting som Unit Test, man kan supplere med. En kombination af de 2 burde nok være hvad man sigter efter. Jeg giver dig dog ret i at det er dårlig stil at lade andre udviklere gætte funktionalitet ud fra notationsform.
Men igen... dette er skrevet før jeg har fået noget koffein i kroppen, så der taget forbehold for alt.
God dammit, man går i seng, og vågner til en Marathon-debat.
Det er grimt, unødvendig, ubrugeligt, plus hvis du ændre en type skal du ændre samtlige variable navne.
Ikke det store problem når man benytter sig af en nogenlunde kompetent IDE.
objObject er dårlig navngivning. Det samme er fnGetOffset , da GetOffset tydeligvis altid vil reffere til en funktion da navnet i sig selv beskriver en handling.
Enig, dårlig navngivning, men nu er Hungarian notation per definition med til at beskrive mere end intention (så som type).
iLeft giver heller ikke mening, Karga mener sikkert at der er en "integer", selvom det burde være "indention".
Smååååååå sko :-P
Funktion/Metode navne: Beskriver en handling/funktion
Variablenavne: Beskriver indholdet af den givne variabel
Parametre: Beskriver indholdet af det givne parameter.
Enig... hvis man altså ikke benytter sig af Hungarian notation.
Og brug DOKUMENTATION (ie. kode-kommentarer) istedet for hungarian notation, det giver så uendelig meget mere mening, og folk skal ikke GÆTTE til hvad dine personlige notations betyder.
Nej, ikke istedet for, men som et supplement. Dokumentation af kode er alpha omega, men der er også sådan ting som Unit Test, man kan supplere med. En kombination af de 2 burde nok være hvad man sigter efter. Jeg giver dig dog ret i at det er dårlig stil at lade andre udviklere gætte funktionalitet ud fra notationsform.
Men igen... dette er skrevet før jeg har fået noget koffein i kroppen, så der taget forbehold for alt.
#11 objObject bliver brugt her netop fordi jeg ikke ved noget om det element der kommer ud, da det jo bare kører op igennem hierakiet
Hvis jeg skal behandle en række elementer, inden i en div jeg bruger til at rette fokus på de elementer i den div, så kalder jeg skam også objektet objContainer, men hvis jeg kan give div'en et bedre navn, så gør jeg det, f.eks. er jeg igang med en billedbrowser, der indeholder en div-container med en masse divs inden i, der så igen har et billede inde i sig. Der kalder jeg containeren for objImages - objektet, der indeholder billeder - samtidig med jeg kalder div-elementerne inde i containeren for objImage (bare et hurtigt eksempel)
Lige netop dette projekt er det udelukkende mig der skal håndtere koden.. og hvis du kunne se mit skrivebord, ville du vide jeg bruger vældigt meget tid på at planlægge forløbet med flowcharts og 10.000 krusseduller
#14 så må du jo lære at være vågen i døgnets 24 timer ;)
Hvis jeg skal behandle en række elementer, inden i en div jeg bruger til at rette fokus på de elementer i den div, så kalder jeg skam også objektet objContainer, men hvis jeg kan give div'en et bedre navn, så gør jeg det, f.eks. er jeg igang med en billedbrowser, der indeholder en div-container med en masse divs inden i, der så igen har et billede inde i sig. Der kalder jeg containeren for objImages - objektet, der indeholder billeder - samtidig med jeg kalder div-elementerne inde i containeren for objImage (bare et hurtigt eksempel)
Lige netop dette projekt er det udelukkende mig der skal håndtere koden.. og hvis du kunne se mit skrivebord, ville du vide jeg bruger vældigt meget tid på at planlægge forløbet med flowcharts og 10.000 krusseduller
#14 så må du jo lære at være vågen i døgnets 24 timer ;)
#8
....? Det er et grundlaeggende princip i CSS at man kun kan aflaese *NOGEN* styles?
For mig at se er de blot en fejl i CSS at "tagget" ikke er med ...
( Tagget bliver jo, sjovt nok, sendt til renderen, saa JavaScript burde kunne lege med her. )
Jow, men saa vil jeg stadig sige at det er en design-fejl i CSS eller DOM, at alle tags ikke er repraesenteret.
Relative elementer kan fint lade sig goere.
Jeg ville have en generel grund, ikke lige noget der specifikt relaterer til JS DOM aflaesning.
Og mindre funktionalitet, mindre alt muligt andet.
Kompleksitet er en uundgaaelighed, uanset om man arbejder for at undgaa det.
Din kode bliver kompleks naar du kommer op i en vis stoerrelse og vil have specielle funktioner - at forsoege at undgaa at bruge relative elementer kan jeg slet ikke se nogen pointe i.
Slet ikke naar alle tuder vildt og voldsomt over at man skal bruge EM stoerrelser og alting skal skalere med browseren.
Okay?
Jeg kender ellers mange der bruger "position: relative;" som er ganske gode programmoerer.
Men hvorfor mener du dette?
Er jo tydeligvis ikke problemet for Karga, dog kunne det vaere et problem for dig - naar du siger det er umuligt, men en anden linker til en maade at goere det paa? :-p
Det er dumt at kaste med sten naar man selv er programmoer. ... Eller noget i den stil ;)
Personligt bruger jeg en blanding af tables og divs, men jeg har stadig divs der er position: relative; ..
Jeg kan ikke umiddelbart se hvordan jeg faar divs til at overlappe uden at bruge relativ positionering - hvis du har et bud siger du bare til, saa skal jeg nok se om det virker :)
Absolut ikke besynderligt, det er et grundlæggende princip i hvordan CSS fungere.
....? Det er et grundlaeggende princip i CSS at man kun kan aflaese *NOGEN* styles?
For mig at se er de blot en fejl i CSS at "tagget" ikke er med ...
( Tagget bliver jo, sjovt nok, sendt til renderen, saa JavaScript burde kunne lege med her. )
Det kan godt aflæse det nuværende positionering af et element på skærmen, men ikke hvad en CSS fil har lagt overpå.
Husk at CSS er et style layer som tilføjes oven på DOM, hvor javascript kun kan aflæse selve DOM.
Jow, men saa vil jeg stadig sige at det er en design-fejl i CSS eller DOM, at alle tags ikke er repraesenteret.
Fordi det kan lade sig gøre!
Relative elementer kan fint lade sig goere.
Jeg ville have en generel grund, ikke lige noget der specifikt relaterer til JS DOM aflaesning.
Mindre komplex kode, skaber mindre antal problemer.
Og mindre funktionalitet, mindre alt muligt andet.
Kompleksitet er en uundgaaelighed, uanset om man arbejder for at undgaa det.
Din kode bliver kompleks naar du kommer op i en vis stoerrelse og vil have specielle funktioner - at forsoege at undgaa at bruge relative elementer kan jeg slet ikke se nogen pointe i.
Slet ikke naar alle tuder vildt og voldsomt over at man skal bruge EM stoerrelser og alting skal skalere med browseren.
Brug af position konstrukten i CSS er 9/10 tilfælde et hack som basere sig i
Okay?
Jeg kender ellers mange der bruger "position: relative;" som er ganske gode programmoerer.
Men hvorfor mener du dette?
a) Manglende skills/erfaring
Er jo tydeligvis ikke problemet for Karga, dog kunne det vaere et problem for dig - naar du siger det er umuligt, men en anden linker til en maade at goere det paa? :-p
Det er dumt at kaste med sten naar man selv er programmoer. ... Eller noget i den stil ;)
b) Fanatisme mod at bruge tables til kolonne layouts
Personligt bruger jeg en blanding af tables og divs, men jeg har stadig divs der er position: relative; ..
Jeg kan ikke umiddelbart se hvordan jeg faar divs til at overlappe uden at bruge relativ positionering - hvis du har et bud siger du bare til, saa skal jeg nok se om det virker :)
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund