"Jimmi Storgaard" <jimmi@smart.as> wrote in message
news:afcvqd$fsu$1@sunsite.dk...
> Hvorfor i alverden skulle jeg dog _ikke_ det ? Det har mine kolleger og
jeg
> altid gjort i vores udviklingsprojekter, hvilket altid har virket
> upåklageligt. Vi er da fuldstændigt kolde overfor dets oprindelige
formål..
> Martin kommer her med et problem han vil have løst. Jeg løser det for ham.
> Hvis DU vil have problemet på en anden måde, jamen så giv dog dit bud på
en
> løsning istedet for at kaste mudder efter mig!
Rolig nu... Ingen grund til at fare i flint!
Hvis du læste mine indlæg ville du se at jeg både i det indlæg til dig og i
et seperat til Martin har givet ham en mulig forklaring på problemet.
Hvad angår det at kaste mudder så må det vist stå for egen regning. Det er
ikke noget jeg har interesse i hvorfor det må være din opfattelse af det jeg
skriver og dermed dit problem.
Hvad angår det med at dig og dine kollegaer er fuldstændig kolde over for
hvad de oprindelige formål er med en teknologi så kan jeg da kun konstatere
at jeg synes at det er en sørgelig udmelding at man som udvikler ikke
interessere sig for teknologiens formål. Netop med et sprog som HTML der er
et markup sprog, hvilket som du nok formodentlig ved er betyder at man
markere noget op og angiver en meta beskrivelse for hvilken type data det
er. Tabel elementerne i HTML er primært lavet til at fortælle at her kommer
noget tabulær data, således at det semantisk giver mening.
At browserne så tolker dette som at noget skal renderes på en visuel bestemt
måde gør det ikke specielt smart at benytte disse tags til at opnå denne
visualisering så længe at indholdet ikke svarer til tabulær data.
HTML er primært et beskrivelsessprog (markup) ikke et visualiserings sprog.
At det så tidligere har måtte være en nødvendighed at benytte det som dette
er en ting, men i min verden giver det ikke mening at fortsætte med det når
der i dag findes semantisk mere smarte alternativer.
> > Tabeller er primært beregnet til opdelingen af tabulær data, selvom de i
> > lang tid har været anvendt til layoutmæssige hacks. I dag er css layout
> > (tableless) metoden efterhånden så udbredt i de forskellige browsere at
> det
> > virke en smule dumt at begynde at anbefale teknikker (hacks) som ikke er
> > nødvendige og som er udviklet i en tid hvor alternativer ikke fandtes
godt
> > nok endnu.
>
> Du kalder det hacks, jeg kalder det at få løst et problem på en
gennemprøvet
> måde. Vi udviklere har forskellige måde at udvikle på. Du har muligvis
> fundet en smart måde lige at opstille layout i HTML, tillykke med det. Jeg
> har så andre måder at gøre ting på smart, og når jeg ser indlæg som ikke
er
> specielt smart, gider jeg ikke at belære folk med at deres råd virker:
> "...en smule dumt...".
Hvis jeg forstår dette her korrekt, så føler du dig stødt over at jeg
kommenterede dit indlæg ved at sige at jeg syndtes det var "en smule dumt"
at anbefale en teknik der både er gammeldags, så småt ved at blive sluset ud
og samtidig ville ødelægge det Martin tilsyneladende prøver på, nemlig at
lave et div baseret layout? Okay jeg tillader mig at omformulere det for at
undgå misforståelser om mudderkastning: "Jeg finder det knap så smart"
Hvis du føler det belærende kan det vel kun være fordi det stillede et eller
flere synspunkter til skue som du ikke havde tænkt over? Det kan der vel
ikke være noget negativt i, medmindre du betragter det at lære nye ting som
negativt?
Vi har alle vores fordomme over for forskellige
> teknikker, nogle over for frames, og nogle overfor tabeller, åbenbart. Men
> det får mig IKKE til at bruge eller anbefale andre teknikker, hvis det
ikke
> viser sig at holde 100% vand. Derfor bruger jeg tabeller til et alternativ
> har skreget mig i hovedet, at det er bedre. Kald det konservativt - jeg
> kalder det at stå inde for det jeg laver.
Hmmm.... okay nu gør du mig forvirret. Du fortæller mig at jeg er uhøflig
(belærende i negativ drejning) ved at kommentere dit indlæg om at bruge
tabeller og foreslår en anden teknik, samt en mulig løsning, samt levere
link til information om denne. Derefter fortæller du mig at du personligt
nægter at skifte udviklingsteknik medmindre nogen står og skriger det ind i
hovedet på dig og at denne teknik holder 100% vand. Ja undskyld min dumhed,
men betyder det så at jeg skal råbe det ind i hovedet på dig at tableless
layout er fremtiden (selvom det formodentlig fra din side vil blive opfattet
som mudderkastning), i stedet for bare at smide et par links hvor du selv
kan følge op og kigge på det?
Definer venligst "et alternativ har skreget mig i hovedet" i så fald du
ønsker at lade mig forstå hvad du mener fordi lige nu må jeg indrømmer at
jeg ikke formår at forstå dette.
Dernæst kan jeg kun undrer mig over hvordan du nogensinde kom til at arbejde
med tabel design hvis de teknikker du arbejder (eller skal erstatte en
tidligere) med skal være 100% vandtætte. Mig bekendt er det kun inden for
det seneste stykke tid at tabeller bliver understøttet nogenlunde ens i de
forskellige browsere, samt ikke skaber problemet med nesting osv?
Kald det at stå inde for hvad du laver, jeg kalder det at ignore udviklingen
og levere et produkt der står tilbage i forhold til de ting der er mulige og
som ikke drager fordel af de sidste par års enorme mængde viden der er
indsamlet på området.
> > Mere teknisk info om tableless design fås på:
> >
> >
www.alistapart.com/stories/practicalcss
> >
www.glish.com/css
>
> Det bliver en anden dag.
Det var så her det ville være klædeligt hvis du havde brugt et par min på at
se hvad det egentlig handlede om inden du begyndte at snakke om alternativer
og 100% vandtæt.
> > Man kan sagtens undgå at div tags hopper ned under hinanden hvis man
> > virkelig ønsker det, og dermed få det samme låste design som ved
tabeller.
> > Dette kan som regel klares ved at placere et div tag omkring hele siden
og
> > så endten sætte denne til en fast pixel størrelse (låst design), eller
en
> > procent sats og så sørge for at indeholdet af denne (siden) ikke er
> bredere
> > end sidens div box. 100% er desværre et begreb som er problematisk at
> > arbejde med i css, hvorfor 100% for det meste må betragtes som værende
for
> > meget da browseren bryder på det.
>
> Hvis tabeller er "hacks", hvad er så dette ?
Jeg har svært ved at gennemsklue om dette er noget du skriver for at forsøge
at finde noget negativt, eller om det reelt er et spørgsmål baseret på
interesse for et svar. Jeg vælger at antage det sidste da det første reelt
er uinteressant i så fald det er tilfældet.
Tabeller kan betegnes som hacks da de som allerede tidligere nævnt er
udviklet til at præsentere tabulær data, men grundet et manglende
alternativer til at lave "grid layouts" begyndte nogle kloge hoveder at
udnytte dem til dette formål da den visuelle struktur mindede om grid
layouts. Det tog fart og blev en populær måde at opnå denne type layout på
og den almindelige opfattelse af tabeller blandt udviklere er i dag i stor
grad at det er det man bruger til at designe med. Man må derfor betegne
tabel layouts som et hack der er gået hen og blevet så defacto standard at
de fleste i dag ikke kender oprindelsen af teknikken.
For at kompensere for manglende alternativer til grid layouts samt at give
mulighed for bedre adskillelse af præsentation og indhold (data) blev CSS
udviklet af w3c som en partner til HTML. Det virker umiddelbart logisk at et
strukturerings sprog også skal have et sprog der kan fortælle hvordan
struktureringen skal vises visuelt. Efter en årrække hvor brugen CSS har
været plaget af dårlige browser implementeringer er vi nu efterhånden kommet
til et tidspunkt hvor 95%+ af browserne på markedet understøtter CSS i en
sådan grad at det ikke bare er et alternativ til tabel designs, men derimod
en væsentlig forbedring af tilgængelighed på siderne, bedre adskillelses af
semantik og visualisering, større bagudkompabilitet, samt som regel giver
mindre kode der skal sendes frem og tilbage.
At jeg skriver at der kan være problemer med 100% opfattelsen i visse
browsere, kan vist ikke betegnes som et hack, hvis du går ud fra
beskrivelsen ovenover. Årsagen til 100% problemet er at width ifølge de
officielle specifikationer angiver bredden på indholdet. Dvs angiver du en
samlet bredde på 100% på indholdet så risikerer du at bruger- og
systemdefinerede marginer, padding og lignende bliver lagt oveni, hvorfor du
kan ende med f.eks width 110%, hvis man ikke tænker sig om.
> Det er muligt. Der var bare ikke sådan, jeg læste hans indlæg. Men først
> siger du, at "tableless design" er så udbredt, at alt andet er "dumt", men
> her siger du, at det er "så småt er ved at vinde indpas rundt omkring".
> Måske ER det vitterligt bedre en tabeller, men jeg venter stadigt til jeg
> får en "aha"-oplevelse. Vi kan jo ikke alle være lige så hurtige som dig.
Igen tror jeg du trigger forkert på ordet dumt, hvilket jeg beklager hvis
det er den måder du opfatter det på. Derudover tror jeg du har læst lidt
forkert. ;) - svjh så skrev jeg at tableless design metoden er udbredt (læs:
mulig) i de fleste browsere. Derudover skrev jeg at jeg fandt det lidt dumt
(læs: knap så smart) at anbefale teknikker der reelt gør hans design mere
bloated fordi han nu en gnag har lavet et css baseret layout, hvorfor så
anbefale ham at skifte tilbage til en gammel teknik?
> > I Martins tilfælde skyldes problemet formodentlig at hans 3 kolonner til
> > sammen giver 100% (25+25+50). En løsning på dette burde være at fjerne
en
> > eller et par %'er da man så kommer ned under de problematiske 100%.
>
> Har du prøvet det ? Ellers synes jeg det er endnu mere "dumt" at give råd,
> som måske slet ikke virker!
Læs venligst mit andet indlæg til Martin. Derudover finder jeg det som en
ganske interessant holdning at der et forbudt at give forslag uden at man
selv har udført eksperimentet og konstateret at det virker. Som jeg ser på
det så har jeg givet Martin et forslag til noget der muligvis virker. Han
kan så afprøve det og virker det ikke så kan han tænke: "Øv ham Oscar ved
ikke hvad han taler om, jeg prøver noget andet". Virker det derimod så har
han fået løst sit problem.
Jeg kunne selvfølgelig også som du mener jeg burde gøre bare holde min mund
og mit forslag for mig selv indtil jeg fandt tid til at lave en hjemmetest
og Martin ville så skulle vente eller muligvis undvære det da det ikke er
alle der lige har tid til at sidde og sætte test scenarioer op for hvert
eneste spørgsmål man modtager.
Jeg ved godt hvad jeg ville foretrække hvis jeg var Martin!
Jeg har intet problem med at fortælle at nej jeg har ikke prøvet det
nøjagtig på Martins kode, men jeg har så tilgængæld haft nogenlunde samme
problem et utal af gange igennem tiden i forbindelse med både mere og mindre
komplekse UI's. Jeg tillod mig derfor at dele noget erfaring med Martin i
håb om at han kunne bruge dette til noget.
Jeg er ked af at sige det men dit indlæg virker mest af alt som et udtryk
for at du er blevet sur da du læste mit indlæg og følte dig personligt
krænket, hvorefter du har sat dig for at finde på så meget som muligt som du
kunne vende og dreje således at det muligvis kunne få stillet mig i dårligt
lys (læs: flame bait). Er dette ikke tilfældet så beklager jeg meget denne
påstand, men umiddelbart virker det således.
Yderligere henvendelse angående dette kan ske til mig privat via email for
at holde en OT debat væk fra de relle emner i denne gruppe.
Med Venlig Hilsen
Oscar Eg Gensmann