Att använda table till annat än just att presentera data i tabellform ska inte göras, det vet jag.

Frames ska också undvikas säger många. Själv tycker jag om att bygga sidor med frames, att ha t.ex. en sidomeny i egen frame ger stora fördelar anser jag. Att kunna scrolla fristående i menyn resp informationsidan är bekvämt samt att menyn behöver inte laddas om vid varje sidhämtning.

Själva layouten på sidorna kontrollerar jag med divs och inte med tabeller.

Tänker jag galet eller är detta okej på moderna hemsidor?
Anses en byggkonstruktion med frames och divs ändå som "godkänd"?

Jag själv hatar att surfa på frames-sidor, framför allt pga. att uppdateringsknappen får ett ryck och förstör hemsidan. Dessutom kan jag inte lägga till de bokmärken jag vill ha...

Det är bättre att ha menyn i en egen sida som du laddar in på varje sida med hjölp av
#Include file
När du kommer till en andra sidan har menyn redan laddats in i cachen från första sidan så det blir inga problem.

>När du kommer till en andra sidan har menyn redan laddats in i cachen från första sidan så det blir inga problem.

Nope... Du måste skilja på det som servern kör resp. det som klienten kör... För klienten finns det ingen includefil. Det finns ett dokument som den laddat ner. Inget mera...

<b>Jag själv hatar att surfa på frames-sidor, framför allt pga. att uppdateringsknappen får ett ryck och förstör hemsidan. Dessutom kan jag inte lägga till de bokmärken jag vill ha...</b>

Personligen hatar jag när man scrollar ned på en sida och sedan alltid måste scrolla upp igen för att kunna se menyn. Men om vi nu inte blandar in personligt tycke och smak. ;)

Anses det okej enligt normer och riktlinjer att bygga en hemsida med frames + divs om man väljer en layout som kan dra nytta av det?

>>Jag själv hatar att surfa på frames-sidor, framför allt pga. att uppdateringsknappen får ett ryck och förstör hemsidan. Dessutom kan jag inte lägga till de bokmärken jag vill ha...

>Okej, men om vi inte blandar in personligt tycke och smak. ;)
>Anses det okej enligt normer och rktlinjer att bygga en hemsida med frames + divs om man väljer en layout som kan dra nytta av det?

Nej, det är inte bara jag som tycker så... Dessutom finns det fler argument

http://autark.se/webbteknik_diverse2.html#ramar
http://www.pellesoft.se/communicate/forum/view.aspx?msgid=147540
http://www.pellesoft.se/communicate/forum/view.aspx?msgid=148738
http://www.pellesoft.se/communicate/forum/view.aspx?msgid=144098
http://www.pellesoft.se/communicate/forum/view.aspx?msgid=141124

Okej, men några saker jag funderar på i så fall...

Vid formulär ska man väl helst lägga felkontroll hos klienten för att snabba upp för användaren och spara bandbredd. I motsägelse till detta uppmanas man bygga sidor frame-fria så att även alla statiska delar av hemsidan som meny och sidhuvud ska laddas om vid varje enskild sidhämtning. (Genereras då menyn dynamiskt får servern hämta om även den datan från databasen vid varje liten sidhämtning).

Många har ännu idag bara vanligt modem, en sådan hemsida blir självklart trögare för dem. Uttrycket "Bredband åt alla" är tyvärr ännu inte sant för alla idag. :(

Är man en flitig surfare (och ändå har bredband) innebär det också att hemsidor utan frames tar mer KB att ladda hem, samtidigt som vissa operatörer vill att man ska betala för mängden data man laddar hem.

Ja?

En meny blir inte stor om den är gjord korrekt med en a-tagg för varje alternativ + en css-fil som cachas hos användaren...

Ja?

En meny blir inte stor om den är gjord korrekt med en a-tagg för varje alternativ + en css-fil som cachas hos användaren...

Många bäckar små heter det ju... :)
Om vi generellt spekulerar i att en meny + ett sidhuvud är 4 KB tillsammans och man besöker 40 sidor om dagen 30 ggr i månaden, då har en enda användare (t.ex. med modem) laddat ca 4.7 MB data enbart i menyer och sidhuvuden...

<b>>När du kommer till en andra sidan har menyn redan laddats in i cachen från första sidan så det blir inga problem.

Nope... Du måste skilja på det som servern kör resp. det som klienten kör... För klienten finns det ingen includefil. Det finns ett dokument som den laddat ner. Inget mera...</b>

Har inte ASP-motorn någon cache för redan använda skript?

>>>När du kommer till en andra sidan har menyn redan laddats in i cachen från första sidan så det blir inga problem.

>>Nope... Du måste skilja på det som servern kör resp. det som klienten kör... För klienten finns det ingen includefil. Det finns ett dokument som den laddat ner. Inget mera...

>Har inte ASP-motorn någon cache för redan använda skript?

Spelar roll? ;) För webbläsaren är det ju fortfarande ett enda dokument...

<b>Spelar roll? ;) För webbläsaren är det ju fortfarande ett enda dokument...</b>

Visst, men det kan gå snabbare att generera sidan. Dessutom skrev Jenny inte att det gällde webbläsaren, så hennes uttalande kan lika gärna ha gällt servern.

(Kan inte låta bli att försvara en tjej... ;-)

Iofs. ;)

Alldeles riktigt jag menade servern och inte webbläsaren. Eftersom servern cashar får clienten snabbare ett helt dokument.

Tyckte inte att jag behövde förtydliga eftersom jag tyckte att det var en självklarhet att det inte är clienten som gör en include utan att allt detta sker på servern. Men det var ju bra att någon annan förtydligade mitt inlägg.

Jadu, jag läste följande snutt text i originalinlägget
>menyn behöver inte laddas om vid varje sidhämtning.
och trodde att det var det du syftade på ;) Dessutom verkar lite för mycket folk på det här forumet tro att man kan exekvera klientkod i serverkoden eller vicer versa så... ;)

Du får väl förlåta mig för mitt dumma beteende :-p

<b>Dessutom kan jag inte lägga till de bokmärken jag vill ha...</b>

Explorer 6 kan spara bokmärken korrekt även om frames används.

Är dock bara ett utav problemen ;)

http://autark.se/webbteknik_diverse2.html#ramar

"en sida med ramar visar flera dokument samtidigt, ett i varje ram. Om detta låter komplicerat så är det precis rätt uppfattat"

Komplicerat för vem? En vanlig besökare behöver inte bry sig om hur man upprättar ramar, det behöver bara den som skapar sidan göra.

"För en mänsklig besökare...", vem ska annars besöka den? ;)

"Många använder ramar för att ha ett fast sidhuvud och en kolumn med standardlänkar som alltid är synlig. Nackdelar med detta är att webbplatsen kan uppfattas som statisk och oflexibel"

Detta behöver inte vara nackdel. Intranätet där jag jobbar är ramfritt och många påpekar irritation på att alternativen i menyn och sidhuvud försvinner när man scrollat ned för att läsa en sida.

söktjänster.
Att en söktjänst leder en besökare till en enskild sida utan ramverk går att fixa med script så att ramverket hämtas.

Visst ser jag att några problem kvarstår ändå, men det är lite lustigt att motståndare svartmålar så mycket som möjligt med ramar, även de saker som ändå kan lösas...

En fördel med ramar är ändå att vissa funktioner kan ligga ständigt åtkomliga (som jämförelse hatar jag när man använder en dator där nån har valt 'dölj automatiskt' på startmenyn, den tycker jag ska ligga framme ständigt lätt åtkomlig).
Annan fördel är att man kan scrolla i meny resp sida oberoende av varandra.

>Detta behöver inte vara nackdel. Intranätet där jag jobbar är ramfritt och många påpekar irritation på att alternativen i menyn och sidhuvud försvinner när man scrollat ned för att läsa en sida.
&
>En fördel med ramar är ändå att vissa funktioner kan ligga ständigt åtkomliga (som jämförelse hatar jag när man använder en dator där nån har valt 'dölj automatiskt' på startmenyn, den tycker jag ska ligga framme ständigt lätt åtkomlig).
>Annan fördel är att man kan scrolla i meny resp sida oberoende av varandra.

*host*
CSS
*host*

>Att en söktjänst leder en besökare till en enskild sida utan ramverk går att fixa med script så att ramverket hämtas.

Dålig lösning, sidan = ingen funktion utan javascript + att problemet inte finns om man skippar ramar... Varför?

Det finns väldigt få tillfällen då man behöver frames, kombinationen html + css löser 99,9% av fallen...

Jag menar inte att ramar alltid är av ondo, men många använder dem på ett dåligt sätt, t.ex. för positionering av sidans huvudsakliga innehåll ("dockskåp" , http://autark.se/webbteknik_diverse3.html#dockskap), där huvudparten av ramarna visar en sida utan innehåll. Ett annat dåligt användningsområde är för att dölja långa långa adresser.


<b>"För en mänsklig besökare...", vem ska annars besöka den? ;)</b>

Indexeringstjänster för sökmotorer.


<b>Intranätet där jag jobbar är ramfritt och många påpekar irritation på att alternativen i menyn och sidhuvud försvinner när man scrollat ned för att läsa en sida.</b>

CSS: "position: fixed"; fungerar visserligen inte i IE, men kan lösas med hjälpa av IE7, http://dean.edwards.name/IE7/


<b>Annan fördel är att man kan scrolla i meny resp sida oberoende av varandra.</b>

CSS: "overflow: scroll" eller "overflow: auto" tillsammans med "height: ...".


Det är lite lustigt att förespråkare för ramar skönmålar så mycket som möjligt, även de saker som bättre kan lösas med CSS...

PP> CSS: "overflow: scroll" eller "overflow: auto" tillsammans med "height: ...".


Ja visst. Detta är det bästa. Jag håller med.
Men verkligheten är inte alltid optimal.
På Internet förekommer en del användare som sitter med äldre webbläsare.
Jag har för mig att man får problem med DIV/SPAN/LAYER
i generation 4 av IE och NS eftersom de stödjer lager och CSS på lite olika sätt,
i synnerhet Javascriptning mot de objekten strular.
Däremot FRAMES fungerar på säkert 99,99% av alla webbläsare som används..

Ola

<b>Jag har för mig att man får problem med DIV/SPAN/LAYER</b>

LAYER skall inte användas eftersom det inte tillhör någon standard.


<b>i synnerhet Javascriptning mot de objekten strular.</b>

Måste man använda JavaScript? Själv tycker jag att det bara skall användas för att lägga till extra funktionalitet till en sida <b>som fungerar utan</b>. Det skall inte vara något som krävs för sidan.

Måste sidor se ut exakt likadant för alla besökare? Är det inte viktigare att de är användbara för alla? En webbläsare som inte stödjer stilmallar kan väl få placera elementen som de kommer på sidan (som om ingen stilmall funnes)?


<b>Däremot FRAMES fungerar på säkert 99,99% av alla webbläsare som används..</b>

Men inte bokmärken och utskrift av sidorna.

PP> CSS: "overflow: scroll" eller "overflow: auto" tillsammans med "height: ...".

Men är det inte lite som att ha en lösning som "simulerar frames", istället för att använda frames... Varför uppfinna nåt som redan finns? ;)

Fast jag erkänner, denna diskussion har gjort mig nyfiken på att pröva göra en helt framefri lösning nästa gång... :)

Jo, visst simulerar man viss funktionalitet hos ramar, men man slipper en del problem också. För utskrift kan man skapa en stilmall som visar hela "det inre dokumentet" så slipper man utskriftsproblemen.

Men kom på en sak idag...
En av hemsidorna jag sköter har inlänkade sidor från andra fysiska webbservrar (som administreras av annan part). Då måste man ju köra med nån form av frame för att få in sådana sidor i sin egen struktur, eller hur?

Jo, det måste du. Men då kan du använda en iframe till den lilla biten. Bästa är dock att inte gör så men, men

Men i de lägena då man valt att konstruera en sida så att frame/iframe krävs på t.ex. 20% av innehållet, är det inte lika bra att köra med frame rakt över?

Bör det inte ur tillgänglighetssynvinkel vara bättre för användaren att säkert kunna konstatera "denna hemsida har frames" jämfört mot att vissa sidor har frame och vissa inte? Detta skapar kanske istället ännu mera förvirring och irritation hos besökaren.

Jo visst, enhetlighet är bra, men använd då en iframe eller en grund ramstruktur så att du inte får en massa ramar med endast bakgrund.

Varför ska du alltid bråka Per? ;)

"LAYER skall inte användas eftersom det inte tillhör någon standard. "

Jag skrev inte att LAYER skall användas Per.

Jag skrev att det var strul med gamla v4 läsare där NS envisades med LAYER i stället för DIV,
om jag nu minns rätt... Du förespråkade CSS och lager i stället för frames?
Det är dessa problem man då får om man skall stödja v4 läsare inkl NS.

Därför är det inte smärtfritt underbart med CSS.

Om du vill kan vi prata XFORMS. Allt borde göras i XFORMS. Det är snyggast.
Men det fungerar inte IRL..



"Måste man använda JavaScript?"

Måste man inte, men om man scriptar något (inte helt obskyrt i dag) då får man problem med att styra lager avseende v4 läsare.






"Måste sidor se ut exakt likadant för alla besökare? "
"Är det inte viktigare att de är användbara för alla? "


Det beror på. Om du är webbsideartist med konstnärliga ambitioner så vill du nog inte att tant Asta ska configga ditt konstverk att se ut som Text-TV.

/Ola

Ola:

Varför inte tvinga folk att uppgradera?

Dessutom: html är helt fel när man ska leka konstverk; det har du t.ex. flash, pdf etc. för

Tvinga att uppgradera kan man göra i vissa lägen. Jag tycker absolut att man ska uppmuntra till det.
Men om du säljer saker på din webbsajt vill du inte att kunderna ska lämna sidan bara för att de inte har lust att installera en nyare webbläsare. Det är samma problem med Flash och Acrobat Reader. Det är ingen slump att du sällan ser webbshoppar som är fullproppade med Flash, PDFs, OCX:er eller Java-applets..

Ola

<b>Om du är webbsideartist med konstnärliga ambitioner så vill du nog inte att tant Asta ska configga ditt konstverk att se ut som Text-TV.</b>

Vad har denne "webbsideartist" tänkt skapa för sidor i framtiden? Lika oanvändbara som snygga?

Per, varför måste snygg vara oanvändbart?

Och varför måste alla hemsidor i hela världen stödja alla handikapp som finns? ;)

Ola

<b>Per, varför måste snygg vara oanvändbart?</b>

Det har jag inte påstått. Men om man inte får ändra storlek eller färg på texten bara för att webbdesignerns ego tycker att sidan måste se exakt likadan ut för alla besökare så blir sidan oanvändbar för vissa.



<b>Och varför måste alla hemsidor i hela världen stödja alla handikapp som finns? ;)</b>

Det måste de inte göra. Personliga hemsidor bryr jag mig inte så mycket om, men när en myndighets eller en kommuns webbsidor inte är användbara för handikappade, tycker åtminstone jag att det är fel.