Runde tablekanter i HTML

[dedLy_sCoRpIoN]

Nå holder eg på å lage ei heimeside, i forbindelse med It på skulen, så eg lurte på: Korleis klarer eg å få runde kanter på tables i steden for firkanta?

 

(Er ikkje heilt 100% i HTML )

[halvardm]

Det går dessverre ikke ann.

Det eneste er slike metoder du kan bruke, med CSS og/eller JS.

Men jeg kan anbefale deg å tegne de runde kantene.

[N*]

de går ikke an å lage de runde i prinsippet..

men du kan få de til å se runde ut ved hjelp av bakgrunnsbilder (du kan sikkert tenke deg fram til hvordan?).

 

visste du at tabeller til layout er feil btw?

[dedLy_sCoRpIoN]

Nei... men det er no heilt ok å bruke talbes meiner no eg

 

Eit problem med tables, som eg heller ikkje får fiksa er at det blir eit lite mellomrom mellom dei som har samme farge som bakgrunnsfargen på sida, slik at dei ikkje ligg heilt inntil kvarandre, sjølv om <table border="0">...

[N*]

Nei... men det er no heilt ok å bruke talbes meiner no eg

huff da. kjenner jeg forumbrukerene her rett, kommer du til å angre på at du skrev de ordene :!:

 

mitt tips: les igjennom artikkelen jeg postet over en gang til (leste du den i det hele tatt?), tenk litt igjennom den og prøv den andre metoden (VELDIG VIKTIG).

hvis du gidder alt det kommer du ikke til å angre.

[dedLy_sCoRpIoN]

Er det ikkje vanskelig å skifte frå table til div på ei side?

[N*]

Er det ikkje vanskelig å skifte frå table til div på ei side?

det kommer an på størrelsen på siden og om du har brukt include-muligheten i php. og viktigst av alt, om du kan html og css godt fra før. hvis du kan html og css tar det deg kansje bare en time.

 

<div> skal forresten ikke brukes til alt

 

et lite tips:

html-språket har et eget element til nesten en hver sitvasjon. hvis du kommer over noe som er tungvint å få til med det elementet du bruker, er det sansynligvis ikke det rette elementet.

[Medrakil]

Nei... men det er no heilt ok å bruke talbes meiner no eg

 

Eit problem med tables, som eg heller ikkje får fiksa er at det blir eit lite mellomrom mellom dei som har samme farge som bakgrunnsfargen på sida, slik at dei ikkje ligg heilt inntil kvarandre, sjølv om <table border="0">...

<table border="0" cellspacing="0" cellpadding="0"> ?

 

Tables kan jo være greit da, hvis de validerer og hvis CSS brukes til all formatering etc. så man ikke bruker <font> og liknende mannskit...(hybridlayout) - er en del ting som er betydelig enklere med tabeller enn med CSS/divs.

 

Men CSS er som regel det beste.

[dedLy_sCoRpIoN]

Takker for hjelpa, det funka...

Er det nokken sider der du enkelt kan lære CSS?

[Ṱormod]

http://forum.programmer.no/index.php?showtopic=176376

http://www.htmldog.com

http://www.w3schools.com

http://www.glish.com/css

 

Anbefaler på det varmeste HTMLDOGs guide til css!

[superlaban]

de går ikke an å lage de runde i prinsippet..

men du kan få de til å se runde ut ved hjelp av bakgrunnsbilder (du kan sikkert tenke deg fram til hvordan?).

 

visste du at tabeller til layout er feil btw?

 

Jeg er i teorien enig i at table bør erstattes med div+css til layout-formål. Bl.a. fordi det finnes muligheter i div+css som ikke er mulig i table (f.eks. float eller utskrift-media).

 

I praksis derimot er det ting som taler mot div+css

 

- Css behandles ulikt i ulike browsere og versjoner. Her har msie et par

svære svin på skogen. De lar seg gå rundt ved å utnytte en annen

css-mangel/bug i msie, men vakkert blir det ikke. (Ulik browserhåndtering

var kanskje mer sant for to-tre år siden enn nå? Men det er mange som

sitter på utgamle browsere ennå...dessverre. Kanskje ikke i dette forumet)

 

- div-blokker kan ha en tendens til å overlappe hverandre. Dette er ofte

kun et resultat av mangler i css-kunnskapen, eller at man ikke forstår eller

har testet i flere browsere og versjoner i flere vindustørrelser.

 

- Jeg tror div+css har en brattere lærekurve enn table. Dermed blir ikke div+css

like lett å vedlikeholde likevel for folk som kun kan html halveis bra (de er

det svært mange av, men skal man ta hensyn til det når man webutvikler?

....kanskje ikke).

 

Med table vet man mer hva man får. Og argumentet med at det er vanskeligere å vedlikeholde table-layout-html kjøper jeg ikke helt. Fordi det er ihvertfall på større sites er vanlig å ha mulighet for en eller flere inkluderingsmekanismer som (følger med i) SSI/CMS/Templates/CGI/PHP/OSV/OSV.

[Arve Systad]

- Css behandles ulikt i ulike browsere og versjoner. Her har msie et par

svære svin på skogen. De lar seg gå rundt ved å utnytte en annen

css-mangel/bug i msie, men vakkert blir det ikke. (Ulik browserhåndtering

var kanskje mer sant for to-tre år siden enn nå? Men det er mange som

sitter på utgamle browsere ennå...dessverre. Kanskje ikke i dette forumet)

CSS behandlast litt ulikt i forskjellige nettlesarar - ja - men alle layoutar du vil kunne vere i stand til med tabellar er du også i stand til å få finfint til med ein strukturbasert og semantisk layout. Det einaste som kan vere ein eventuell brems her er kunnskapane dine om emnet, men når dei strekk til er det ikkje eit problem. Selfølgelig håpar vi på at nettlesarane i framtida er fullstendig "standards-compliant"

 

- div-blokker kan ha en tendens til å overlappe hverandre. Dette er ofte

  kun et resultat av mangler i css-kunnskapen, eller at man ikke forstår eller

  har testet i flere browsere og versjoner i flere vindustørrelser.

 

Div-blokker overlappar kvarandre kun når absolutt posisjonering og feil bruk av float er brukt. Som du sjølv skriv; mangel på kunnskap.

 

- Jeg tror div+css har en brattere lærekurve enn table. Dermed blir ikke div+css

  like lett å vedlikeholde likevel for folk som kun kan html halveis bra (de er

  det svært mange av, men skal man ta hensyn til det når man webutvikler?

  ....kanskje ikke).

 

Strukturbaserte layoutar er enkle å forstå for nybegynnarar, værre for folk som har fått tabellkode inn i hovudet over lang tid. Konseptet er enklare, men folk som lærer seg tabellmetoden først har vanskeligheiter med å forstå den. Folk som startar fra bunnen av derimot, vil med stor sansynligheit forstå strukturbaserte layoutar bedre, rett og slett fordi dei er basert på rein og skjær logikk.

 

Med table vet man mer hva man får. Og argumentet med at det er vanskeligere å vedlikeholde table-layout-html kjøper jeg ikke helt. Fordi det er ihvertfall på større sites er vanlig å ha mulighet for en eller flere inkluderingsmekanismer som (følger med i) SSI/CMS/Templates/CGI/PHP/OSV/OSV.

 

Du tenker på innholdsoppdateringar; det er snakk om å kunne vedlikeholde layouten - noko ein gjer vesentlig lettare i eit design som styrast av CSS. Dette rett og slett på grunn av mindre rotete kode og effektiv bruk av nettopp CSS.

 

Angåande forståelse av tabellmetoden kontra "strukturbasert-metoden" vil eg sitere meg sjølv:

Tabellar

Du svingar inn på ein parkeringsplass, og vil finne deg ein ledig plass så fort som mulig. Du kan kun parkere på plass 8 fordi plassane 1-7 allerede er fulle. Nestemann blir då nødt til å parkere på plass 9.

 

Strukturbasert HTML

Du svingar inn på den same parkeringsplassen, og parkerer nøyaktig der du vil. Avhengig av hvilken bil du har kan du enten parkere ved sida av andre, parkere langt vekke fra alle andre eller du kan parkere oppå dei, eller gjerne parkere over heile parkeringsplassen på en gang. Du gjør nøyaktig som du sjøl vil.

 

No står dine argument om forståelse og nettlesarstøtte på tynn is, og med ein strukturbasert layout har du fortsatt fordelane med å separere innhold og presentasjon, sparing av bandbredde osv.

[superlaban]

Det einaste som kan vere ein eventuell brems her er kunnskapane dine om emnet, men når dei strekk til er det ikkje eit problem.

 

Jeg utelot vel dette, men jeg tenkte først og frem på kunnskapene til de som skal vedlikeholde websidene i etterkant. I mange prosjekter lager IT-utdannede folk, som forhåpentligvis kan både html og css godt nok, den første versjonen og forslag til tekster der. Så vil de neste versjonene vedlikeholdes og oppdateres av folk med annen bakgrunn. Da gjelder det å ikke ha laget et alt for vanskelig opplegg som de skal ta over. Her mener jeg å ha erfaring for at CSS-layout har en brattere lærekurve.

 

Strukturbaserte layoutar er enkle å forstå for nybegynnarar, værre for folk som har fått tabellkode inn i hovudet over lang tid. Konseptet er enklare, men folk som lærer seg tabellmetoden først har vanskeligheiter med å forstå den. Folk som startar fra bunnen av derimot, vil med stor sansynligheit forstå strukturbaserte layoutar bedre, rett og slett fordi dei er basert på rein og skjær logikk.

 

Du har kanskje rett i det med rekkefølgen på læringen, men jeg tror du skal lete lenge etter folk som lærer css-layout før de lærer html og table-layout. Mange bøker osv.

 

Du tenker på innholdsoppdateringar; det er snakk om å kunne vedlikeholde layouten - noko ein gjer vesentlig lettare i eit design som styrast av CSS. Dette rett og slett på grunn av mindre rotete kode og effektiv bruk av nettopp CSS.

 

Ofte flytende overganger mellom innhold (brødtekst) og layout...

 

Tabellar

Du svingar inn på ein parkeringsplass, og vil finne deg ein ledig plass så fort som mulig. Du kan kun parkere på plass 8 fordi plassane 1-7 allerede er fulle. Nestemann blir då nødt til å parkere på plass 9.

 

Strukturbasert HTML

Du svingar inn på den same parkeringsplassen, og parkerer nøyaktig der du vil. Avhengig av hvilken bil du har kan du enten parkere ved sida av andre, parkere langt vekke fra alle andre eller du kan parkere oppå dei, eller gjerne parkere over heile parkeringsplassen på en gang. Du gjør nøyaktig som du sjøl vil.

 

Morsom sammenligning :-) Men i det siste tilfellet tror jeg faren for kostbare "overlappinger" er stor.

 

No står dine argument om forståelse og nettlesarstøtte på tynn is, og med ein strukturbasert layout har du fortsatt fordelane med å separere innhold og presentasjon, sparing av bandbredde osv.

 

Sparing av bandbredde...hmm, oftest er mer enn 90% av dataene er uansett bilder, da hjelper det ikke særlig å knipe inn en byte eller tre i html/css'en. Og på sider som ikke inneholder mye bilder burde etter min mening alle gode webservere / -applikasjoner returnere gzip'et html til de browsere som sier de godtar det. Tror mange ikke er klar over hvor mye bedre responstid brukere flest kan oppleve når man gjør dette, spesielt de mange som ennå har tregbånd/modem/isdn. (Men det var vel off-topic).

[Arve Systad]

Det einaste som kan vere ein eventuell brems her er kunnskapane dine om emnet, men når dei strekk til er det ikkje eit problem.

 

Jeg utelot vel dette, men jeg tenkte først og frem på kunnskapene til de som skal vedlikeholde websidene i etterkant. I mange prosjekter lager IT-utdannede folk, som forhåpentligvis kan både html og css godt nok, den første versjonen og forslag til tekster der. Så vil de neste versjonene vedlikeholdes og oppdateres av folk med annen bakgrunn. Da gjelder det å ikke ha laget et alt for vanskelig opplegg som de skal ta over. Her mener jeg å ha erfaring for at CSS-layout har en brattere lærekurve.

Uansett dyktighetsnivå på nyansatte vil det vere enklare å gjøre innholdsoppdateringer i et miljø med så lite kode som overhodet mulig, altså ikkje tabeller.

 

Strukturbaserte layoutar er enkle å forstå for nybegynnarar, værre for folk som har fått tabellkode inn i hovudet over lang tid. Konseptet er enklare, men folk som lærer seg tabellmetoden først har vanskeligheiter med å forstå den. Folk som startar fra bunnen av derimot, vil med stor sansynligheit forstå strukturbaserte layoutar bedre, rett og slett fordi dei er basert på rein og skjær logikk.

 

Du har kanskje rett i det med rekkefølgen på læringen, men jeg tror du skal lete lenge etter folk som lærer css-layout før de lærer html og table-layout. Mange bøker osv.

 

Folk som lærer seg webutvikling per i dag lærer seg den ordentlige metoden først, og eg har sjøl opplevd at folk som lærer ting i riktig rekkefølge seier at dei ikkje kan fatte og begripe korleis folk klarte å tenke seg til det å lage layouter med tabellar. Folk som lærte seg ting for et par år sida er ein heilt anna sak. Desverre er det endå både lærebøker og nettsider som underviser feil metode.

 

Du tenker på innholdsoppdateringar; det er snakk om å kunne vedlikeholde layouten - noko ein gjer vesentlig lettare i eit design som styrast av CSS. Dette rett og slett på grunn av mindre rotete kode og effektiv bruk av nettopp CSS.

 

Ofte flytende overganger mellom innhold (brødtekst) og layout...

 

Var det relevant? Kor flytande overgangen (grafisk?) har da ingenting med emnet å gjøre engang.

 

Tabellar

Du svingar inn på ein parkeringsplass, og vil finne deg ein ledig plass så fort som mulig. Du kan kun parkere på plass 8 fordi plassane 1-7 allerede er fulle. Nestemann blir då nødt til å parkere på plass 9.

 

Strukturbasert HTML

Du svingar inn på den same parkeringsplassen, og parkerer nøyaktig der du vil. Avhengig av hvilken bil du har kan du enten parkere ved sida av andre, parkere langt vekke fra alle andre eller du kan parkere oppå dei, eller gjerne parkere over heile parkeringsplassen på en gang. Du gjør nøyaktig som du sjøl vil.

 

Morsom sammenligning :-) Men i det siste tilfellet tror jeg faren for kostbare "overlappinger" er stor.

 

Kostbare "overlappinger"? Forklarer du litt bedre?

 

No står dine argument om forståelse og nettlesarstøtte på tynn is, og med ein strukturbasert layout har du fortsatt fordelane med å separere innhold og presentasjon, sparing av bandbredde osv.

 

Sparing av bandbredde...hmm, oftest er mer enn 90% av dataene er uansett bilder, da hjelper det ikke særlig å knipe inn en byte eller tre i html/css'en. Og på sider som ikke inneholder mye bilder burde etter min mening alle gode webservere / -applikasjoner returnere gzip'et html til de browsere som sier de godtar det. Tror mange ikke er klar over hvor mye bedre responstid brukere flest kan oppleve når man gjør dette, spesielt de mange som ennå har tregbånd/modem/isdn. (Men det var vel off-topic).

 

Håhå, tru det eller ei, men du tar omtrent så feil som du kan ta overhodet. Gjelder riktignok kun på relativt store sider, men her skal eg gi deg en liten ting å tygge på:

http://www.stopdesign.com/articles/throwing_tables/ <= Rull litt nedover og sjå på tabellen som er der, samt les teksten under. Tygg på den du, og kom tilbake å sei at du kun sparer et par-tre bytes