14. maj 2010 - 19:02Der er
45 kommentarer og 2 løsninger
Første forsøg på w3-validering
Jeg er efterhånden nogle gange blevet opfordret til at forsyne min kode med doctype og w3-validere. Jeg har så gjort mit første forsøg på at se, hvad det vil kræve af arbejdstype og -tid, ved at prøve at sætte doctype på min index-side, som er med frames, hvor jeg som doctype har valgt <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
<meta NAME="description" CONTENT="Vin, anmeldelser, anbefalinger, især om italiensk og fransk vin. Forum med vindebat. Vinordbog, gode råd om servering af vin, vinrejser og vinguider.">
Line 41, Column 7: end tag for "FRAMESET" omitted, but its declaration does not permit this </html>
Jeg læser det som, at jeg skulle have udeladt end-tag for frameset, hvilket, som det kan ses i koden ovenfor, ikke er tilfældet. I samme forbindelse er det html-end-tag, som vises med røde prikker under > Men heller ikke den mangler. Så viser validatoren forkert? Eller er der noget jeg ikke forstår?
3 andre fejl er af typen "there is no attribute". Og det drejser sig om FRAMESPACING, FRAMEBORDER OG TARGET.
Jeg forstår det som, at jeg ikke kan bruge disse attributer under den doctype. Men hvad gør jeg så? For jeg kan jo ikke undvære det, som de aktuelt gør.
Endelig kan jeg ikke få øje på den påståede "warning". Hvad er det for en?
Jeg håber på lidt begynderundervisning, så jeg får et indtryk af hvad det her handler om og i bedste fald får mod til at gå videre med projektet.
Ja, minsandten. Der er nu tilføjet en </frameset> mere efter den ene der var. Og så er den fejl tilsyneladende klaret.
Der er dog kommet en ny fejl, hvor jeg også citerer begyndelsen af kommentaren: Line 35, Column 12: document type does not allow element "NOFRAMES" here <noframes> The element named above was found in a context where it is not allowed. This could mean that you have incorrectly nested elements -- such as a "style" element in the "body" section instead of inside "head" -- or two elements that overlap (which is not allowed).
Kan de to "overlaps" have at gøre med de to <frameset>, hvor den ene er inde i den anden? I givet fald: Hvordan skal det nedenstående så omformuleres?
Meget fint. Der er jo virkelig noget at hente der.
Mht. noframes så har jeg simpelthen slettet den, har aldrig mødt en noframes-browser. Men engang var det faktisk indholdet indenfor det tag, som Google citerede i stedet for meta NAME="description". Så derfor var den udfyldt som den var.
Jeg har også klaret det, der må stå mellem <frameset...> og </frameset> MEN det giver en layout unøjagtighed i Internet Explorer (7) (ikke i Firefox), idet menuen er rykket iflg. mit øjemål 2px ned, så der kommer et hvidt mellemrum over den. Det var det, som framespacing="0" har klaret indtil videre, men den må man ikke bruge. Hvad gør jeg for at klare det problem?
Selvfølgelig. Det er jo mig der ikke læser ordentligt. Tak. Og hermed blev siden godkendt. Stort :-) Men hvorfor taler de så stadig om en warning? Er det "Notes and Potential Issues"-delen?
Der resterer så blot spørgsmålet vedr. den nævnte hvide kant i IE7. For det duer selvfølgelig ikke.
Men det er muligvis mere et design- end et valideringsspørgsmål. Jeg troede dog at chancen for ens layout i de to browsere var større med valideret kode end uden...
Ang. warning: Der står blot øverst: Passed, 1 warning(s) Men jeg kan ikke se nogen warning, kun Notes and Potential Issues.
Lige aktuelt er frames eller ikke frames ikke spørgsmålet. Jeg ønsker at tage udgangspunkt i mit site som det er.
Så spørgsmålet er, hvordan jeg kan regulere det, som framespacing="0" tog sig af før. Framespacing må ikke bruges - men jeg har brug for den den gjorde. Det er iøvrigt ikke blot menuen der er rykket. Det er alt under topframen, der er rykket ned, ca. 2px i IE og ca. 5px i FF.
Og opsætning via frames er ikke noget jeg har forstand på.
Generelt er arbejdsgangen: få validator.w3.org til at holde mund, og derefter eventuelt overtræde reglerne i de få tilfælde, hvor det kan være nødvendigt. Der er jo ikke noget ulovligt i det ... ;)
Tja, det med windows-1252 er jo automatisk sat på af mit gamle frontpageprogram, som jeg stadig benytter som "skrivemaskine" og til filhåndtering. Hvad vil du anbefale af utf-8, eller fx iso-8859-1? Hvad er forskellen?
Det med at det kan være nødvendigt at overtræde reglerne, hvor det er nødvendigt kan jeg godt følge. Men det forekommer mig alligevel lettere absurd, hvis det er sådan at der ikke findes koder, der kan det som de ikke-valide koder kunne. Det kan da ikke passe. Iøvrigt hjælper det ikke at genindsætte framespacing="0". Det har ingen effekt, når siden nu læses i standardoverholdelsestilstand.
Mht. frames: Selvfølgelig kan sitet på en eller anden led laves uden frames. Jeg er muligvis den sidste tilhænger af dem, synes de gør det de skal på en helt optimal måde. Der er så også det aspekt, at jeg ikke lige pt er i stødet til at lave sitets design fuldstændig om, da det består af 1600-1700 sider.
>w13: Jeg kender godt CSS, har også prøvet med alt det jeg kunne komme i nærheden af, men det rykker intet. Jeg tror jeg opretter et seperat spørgsmål under den mere passende kategori Design vedr. det problem, som jeg ikke har fået klaret. Det må kunne lade sig gøre.
I forbindelse med er forsøg på validering af siden i hovedframen, er der udover en masse manglende alt tags - som giver sig selv - følgende som jeg ikke forstår en lyd af. Det er følgende linje, det drejer sig om: <img src="http://pr.prchecker.info/getpr.php?codex=aHR0cDovL3ZpbnNpZGVybmUuZGs=&tag=1" alt="Vinsidernes aktuelle Google PageRank" border="0" align="right"></a>
Koden stammer fra prchecker.info's hjemmeside, hvor det angives, at det er den man skal indsætte. Det knytter an til det lille PR6 billede nederst til højre på forsiden.
De 3 fejl (omhandlende nogenlunde det samme) er: 1) (her er det t'et i tag=1, der står med rødt): Line 232, Column 81: cannot generate system identifier for general entity "tag" …hp?codex=aHR0cDovL3ZpbnNpZGVybmUuZGs=&tag=1" alt="Vinsidernes aktuelle Google …✉ An entity reference was found in the document, but there is no reference by that name defined. Often this is caused by misspelling the reference name, unencoded ampersands, or by leaving off the trailing semicolon (;). The most common cause of this error is unencoded ampersands in URLs as described by the WDG in "Ampersands in URLs".
Entity references start with an ampersand (&) and end with a semicolon (;). If you want to use a literal ampersand in your document you must encode it as "&" (even inside URLs!). Be careful to end entity references with a semicolon or your entity reference may get interpreted in connection with the following text. Also keep in mind that named entity references are case-sensitive; &Aelig; and æ are different characters.
If this error appears in some markup generated by PHP's session handling code, this article has explanations and solutions to your problem.
Note that in most documents, errors related to entity references will trigger up to 5 separate messages from the Validator. Usually these will all disappear when the original problem is fixed.
2) (her er det også t'et i tag=1, der står med rødt): Line 232, Column 81: general entity "tag" not defined and no default entity …hp?codex=aHR0cDovL3ZpbnNpZGVybmUuZGs=&tag=1" alt="Vinsidernes aktuelle Google …✉ This is usually a cascading error caused by a an undefined entity reference or use of an unencoded ampersand (&) in an URL or body text. See the previous message for further details.
3) (her er det lighedstegnet i tag=1, der står med rødt): Line 232, Column 84: reference to entity "tag" for which no system identifier could be generated …codex=aHR0cDovL3ZpbnNpZGVybmUuZGs=&tag=1" alt="Vinsidernes aktuelle Google Pag…✉ This is usually a cascading error caused by a an undefined entity reference or use of an unencoded ampersand (&) in an URL or body text. See the previous message for further details.
Under alle dette er der en kommentar til ovenstående (& i &tag=1: Line 232, Column 80: entity was defined here …php?codex=aHR0cDovL3ZpbnNpZGVybmUuZGs=&tag=1" alt="Vinsidernes aktuelle Google…
Som sagt sort snak for mig. Nogen der kan fortælle, hvad der er galt, og hvad der bør stå (bortset fra at jeg ikke rigtig forstår, hvis jeg skal rette i den kode jeg har fået opgivet)?
Tak. Bortset fra de manglende alt så er siden nu uden fejl. Det er faktisk med vilje, at jeg har udeladt alt, der hvor jeg har. Synes du de bør være alle steder?
Så kørte jeg lige siden i topframen igennem. Her brokker validatoren sig over placeringen af <base target="hovedramme"> uanset hvor jeg placerer den. Den står aktuel i head-sektionen. Jeg prøvede så at slette den. Så virker skidtet ikke, og der kommer desuden en grå border under.
Jeg har prøvet at finde, hvad man så kan gøre, men kan hos w3 ikke finde noget brugbart.
Hvad gør jeg her?
Iøvrigt: Hvis jeg bruger utf-8, så forsvinder æ og ø (og sikkert også å), så jeg har valgt iso-8859-1 i stedet.
Korrekt! Det er ikke sådan med 9 år gammel kode, der ikke har fået et eftersyn. Og så ovenikøbet <base target der henviser til to forskellig frames. Nå, men i praksis har det jo virket :-/
Koden for toppen er godkendt. Men kønt er det jo ikke i FF. Det kalder formodentlig på et kig på de tilhørende css-koder. Men kors hvor det irriterer mig at IE og FF fortolker så forskelligt. Når der er én kode-standard, burde der sørme også være én fortolkningsstandard. Jeg går ind for én browser, eller i hvert fald én fortolkningsstandard. Alt andet er det rene tidsspilde, oplever jeg. I den hellige konkurrences navn. Latterligt.
padding-top har indvirkning placeret i frame tags i index-fil (selv om det sikkert ikke vil blive godkendt), dog kun for positive værdier, hvorved det hele rykker endnu længere ned. Ved værdien 0 er det neutralt, dvs. jeg kunne lige så godt ingenting skrive, og minus-værdier har (selvfølgelig) ingen effekt. Margin ser ikke til at kunne bruges til noget. Har prøvet alt med margin og padding jeg kunne komme i tanke om.
Jeg er ikke helt sikker på jeg kan følge dig - du skal have rykket indholdet op i din top-frame, så man kan se den grønne bjælke. Det vil jeg tro kan gøres med noget css. Hvad har du prøvet?
Hvis du sammenligner vinsiderne.dk/ med testsiden til denne lejlighed vinsiderne.dk/index_doctype.htm, så skulle du gerne mellem topframe og menuframe se et hvidt mellemrum på testsiden, hvor menuen (grøn), som den skal, slutter helt op til det lysegrønne felt, hvor der står indhold. Her er der altså ingen afstand mellem topframe og de to frames nedenunder. Du kan på samme måde (men det er knap så tydeligt) se et lille mellemrum mellem det grønne felt ude til højre, hvor der står "Vindebat" (som tilhører topframen) og så rullepanelet i hovedframen. Dette mellemrum er der heller ikke på det "rigtige" site. Som nævnt skønner jeg at det drejer sig om et mellemrum på 2px i IE, 5-6px i FF.
Jeg har prøvet med alt det css jeg kan finde på, forgæves. Hvis det med w3-standarden ikke er muligt at have det der før og udenfor standarden hed framespacing på 0, så er det jo en forringelse, og så forbliver jeg helt sikkert uden doctype, for det er under doctypen, at framespacing ikke er en mulighed. Nej tak til forringelser!
ude fra hva jeg kan læse osv syntes jeg det lyder som om det er tid til at nosse sig sammen og bygge et nemt og overskueligt system - lav en database med siddernes indhold i, lav nogle includes. også kan man til enhver tid opdatere design, menu og andet pjat - det er en ordenlig portion indhold. men hellere begynde opdatere før siden dør pga dårlig understøttelse af gammel sjusket frames osv.
lige meget hvor meget nemmere det er for dig nu - så er det her ik sidste gang du kommer til at skal opdatere hvis du fortsætter i dette mønster og hvis du tror du er irreteret nu så vent til næste generation af browsere.
du kender jo fra en tidligere tråd allerede til min holdning omkring frames og hvor CMS-løsningen også blev foreslået, men for at holde os til emnet her;
den hvide kant er så vidt jeg kan se borderen/spacingen og den kan kun fjernes hvis du bryder valideringen (eller laver en custom doctype, men det giver nok ikke den store mening). En mulighed er også at sætte attributterne med javascript, på den måde vil koden se valid ud igennem en validator men resultatet vil i sidste ende selvfølgelig være det samme.
Bedste løsning som jeg ser det og hvis vi skal holde os inden for dine rammer er at beholde din doctype og sørge for valid kode pånær altså disse attributter. Vil du bryde de designbetingelser, der ligger inden for frames må du bryde standarderne.
I følge CSS burde border-spacing:0 kunne bruges, men den understøttes ikke på frames af nogen browser. Derfor er der kun den invalide framespacing tilbage, hvis du vil undgå kanten
>olebole: border-spacing: 0 er prøvet, og som du ganske rigtigt skriver, så understøttes den ikke og får ikke noget synligt resultat i browserne. Den invalide framspacing ignoreres også i Firefox, hvis jeg kører med doctype, men ikke i IE. Så det kan selvfølgelig ikke bruges til noget.
De erfaringer jeg har gjort undervejs i dette spørgsmål har ført mig frem til den konklusion, at det ikke giver mening at køre med doctype og at validere med mine nuværende koder. Det var ikke det jeg havde håbet, men alligevel er det måske bedst sådan, idet - som jeg også er blevet gjort opmærksom på af flere af jer - kan komme til at bruge rigtig meget tid på at lappe på mine nuværende koder, og måske endda i flere omgange.
Nu skriver jeg ikke kode for kodernes skyld. Jeg laver hjemmeside, fordi jeg har noget jeg godt vil skrive om og ud med. Men samtidig vil jeg faktisk helst have, at koderne er i orden. Så jeg har tænkt, at tiden til at tænke i nyt design nok er kommet. Det bliver til gengæld uvægerligt en større omgang grundet det ganske omfattende materiale, som sitet består af, og jeg har brug for at tænke mig godt om og finde nogle rigtig gode - og gerne langtidsholdbare - løsninger, før jeg går i gang.
Som jeg har skrevet før (eller det var vist i en anden tråd), så er mit kodekendskab aktuelt følgende: html og css. Så når fx du, RexReptiles, skriver "includes", og når du, keysersoze, taler om CMS, så ved jeg ikke hvad I snakker om. Så kan I ikke lige uddybe en smule? Rexeptiles, du taler også om at lægge alle siderne i en database. Kan du ikke lige uddybe det lidt? Jeg har længe ønsket at lægge vinanmeldelserne i en database, så man kan søge i dem ud fra kriterier, men alle de andre sider i en database også?
Jeg er klar over, at alt dette falder uden for rammerne af nærværende spørgsmål, men jeg vil være glad for et par inputs til nyorientering, herunder gerne steder hvor jeg kan læse om de ting, I foreslår. Ellers skal der nok komme mere konkrete spørgsmål, når jeg engang forhåbentligt begynder at tage fat.
I en anden tråd skrev du, olebole, at XHTML er en død sild, og at HTML 5 er på vej. Men først i 2012. Hvad gør man så i dag?
Vigtigt i forhold til kommende omlægning vil være en absolut nul-risiko for forhold, der kan føre til at jeg taber den Google PageRank jeg efterhånden har opnået, så SEO er også meget vigtig.
Det var en ordentlig omgang - sådan opleves det også :-)
includes betyder at du kan lægge genbrugelig ting, fx top, bund og menu, ud i eksterne filer og så inkludere dem på alle dine andre sider. Når man ikke arbejder i frames er man ellers nødt til at have mange ting gentaget på alle ens sider og benytter man ikke includes vil fx en ændring i menuen betyde ændringer i lige så mange filer man har i stedet for kun et enkelt sted. Du kan se lidt mere om det tekniske her; http://activedeveloper.dk/articles/category/9/
det jeg nævner omkring CMS, Content Management System / indholdsstyring, og rexreptiles nævner om database går på det samme - i stedet for at du sidder i et hjemmesideprogram og opretter nye filer hver gang du skal have en ny artikel går du ind i et web-administrationsinterface og opretter data, som så bliver gemt i en database. Det betyder, at du ikke længere selv skal styre programmeringen af fx kategorier, underkategorier og artikler - det hele sker vha indtastning i formfelter. Uden at det skal have nogen som helst sammenhæng med det du har behov for (det var bare det første billede jeg fandt på google) så kunne administrationen omkring oprettelse af artikler fx se sådan ud; http://www.filebuzz.com/software_screenshot/full/22796-bluo_cms.jpg
Som nævnt i din tidligere tråd vil brugen af et CMS absolut ingenting ødelægge i forhold til hvad du har behov for at oprette og vise på siden - tværtimod vil det kunne give en masse fordele fx i form af at give de besøgende mulighed for interaktion ved dine artikler (kommentarer, vurderinger etc) og samtidig vil man let kunne skifte designet totalt uden at alle dine data forsvandt, for de ligger jo i databasen helt adskilt fra præsentationslaget. Det eneste du taber i denne sammenhæng, medmindre du kommer ind i noget mere programmering end HTML og CSS, er muligheden for selv at ændre på designet/koden.
Hvis du skifter din kode så radialt som det vil være at skifte til et CMS - eller bare til uden frames - vil jeg ikke lægge hovedet på blokken på at det er absolut nul-risiko mht SEO men risikoen vil jeg vurdere til at være meget minimal såfremt der tages ét meget vigtigt forbehold, nemlig at URLs bibeholdes som nu eller at de peges over på nye URLs med en 301. Den del skal du for så vidt ikke bekymre dig om - det skal du bare stille som et krav til der hvor du end evt får sat et nyt system op. Risikoen, hvis den er der, vil jeg til gengæld mene bliver stærkt opvejet af de fordele det kan give (fx ved at droppe frames, undgå javascript-menu, styr på meta etc).
Du skriver: "Det eneste du taber i denne sammenhæng, medmindre du kommer ind i noget mere programmering end HTML og CSS, er muligheden for selv at ændre på designet/koden."
Her er jeg jo faktisk ganske hysterisk. Jeg er vant til at styre layout ned til mindste pixel (bortset fra at det ikke længere lader sig gøre med det virvar af browsere osv. der er dukket op). Betyder CMS at man køber et eller andet system, som så ser ud på en bestemt måde, som jeg ikke har indflydelse på? Det er jeg i givet fald ikke interesseret i. Der er så meget der ser flot, ensartet, professionelt ud i dag. Gab. Mit design må godt bære præg af at det er en person - og ikke en skabelonskaber - der står bag projektet. Med de ufuldkommenheder der hører med.
Sådan et system koster vel også en masse? I og med at jeg ikke tjener en øre på mit site (og heller ikke fremover vil annoncere), så vil jeg gerne holde udgifterne nede. Hertil hører, at hvis der er noget (webdesign) jeg ikke kan finde ud af, så vil jeg lære om det i den udstrækning jeg har brug for det og ikke betale kassen for at andre klarer noget, som risikerer at blive upersonligt. Jeg vil fremdeles godt styre min hjemmeside selv. Har faktisk elsket at sidde og rode med det i et hjemmesideprogram (som så i givet fald nok også skal finde en afløser...)
Som du forhåbentlig kan se på mit link mister du ikke design-muligheder på opsætningen af artiklen - det du, som udgangspunkt, mister er kontrol af kodningen på alt uden omkring, altså det overordnede design (menu, top, bund...). At du mister det betyder selvfølgelig ikke at du ikke kan få siden til at se ud som du vil for det er noget en udvikler vil kunne sætte op og også ændre efter behov (og det vil du i teorien også godt kunne (uden om selve CMS-delen) men det kræver oftest lidt mere viden end bare simple HTML- og CSS kundskaber - det kan fx være viden omkring ASP.NET, PHP og/eller XSLT).
Der findes utallige gratis CMS-løsninger du kan gå i gang med selv (umbraco, joomla, wordpress...) og du kan også sagtens lave en skræddersyet løsning til dig selv i fx ASP.NET eller PHP så det behøver ikke at koste noget. Andet end en masse tid selvfølgelig.
keysersoze >> jeg synes lige, vi bør nuancere den om, at man ikke bør bruge JavaScript. Ved man ikke i forvejen, hvad du taler om, kan det næsten ikke andet end misforstås =)
Der er i princippet intet i vejen med at bruge JavaScript. Der, hvor det kan give SEO-mæssige problemer (problemer med søgemaskine indeksering), er der, hvor JS bruges til at skrive decideret indhold ind i siden - efter den er loaded i browseren. Ligeledes bør man undgå at linke udelukkende via JS ... det bør gøres via helt alm. links.
Årsagen er, at søgemaskinerobotter ikke kan læse/tolke JavaScript, hvorfor indhold, der er indsat med JS, ikke findes af søgemaskinen - og derfor ikke indekseres. Det samme gælder linkning. Linkes via JS, kan søgemaskinen ikke finde den side, der linkes til - og den indekseres ikke (med mindre siden findes på anden måde).
Det er lidt forskelligt, hvad folk gøre indtil 2012. Hvis vi ser på de store, trendsættende aktører, deler de sig i to. Nogle går tilbage til HTML 4.01 Strict, mens andre allerede er begyndt at bruge HTML 5's DTD (som også i dag er fuldt valid og sætter browseren i 'standard compliant mode'): <!doctype html>
I og med at jeg jo nåede frem til en konklusion (at det ser udsigtsløst ud at gå efter en validering med mit nuværende design), må det være tid til at uddele point og formelt afslutte spørgsmålet - om end kommentarer fortsat vil blive værdsat.
erikjacobsen, der ikke ønsker point, fortjener stor tak fordi han tålmodigt og vedholdende forsynede mig med meget af det, der gjorde det muligt for mig, at nå en konklusion. RexPeptiles fortjener især point for #33, hvor han giver et udmærket spark, keysersoze især for forklaring vedr. includes og CMS, olebole især for anbefalingen vedr. kodesprog.
I forlængelse af oleboles sidste uddybning, så sætter jeg pris på den mht. javascript, fordi den forekommer mig at gøre det klart, at både mit omstillingsjavascript (der sørger for at undersider altid indlæses i frameset), som jeg i anden tråd har diskuteret med keisersoze, og min javascriptmenu er neutrale i forhold til SEO, idet JS _ikke_ bruges til at skrive decideret indhold ind i siden, efter den er loaded i browseren, og der er taget højde for menuens uanvendelighed i SEO sammenhæng ved at have en almindelig linkside med links til alle overordnede sider, hvorfra der så er links videre til samtlige undersider.
Der vil givetvis gå nogen tid, før jeg er klar til at gå igang med nyt design. Der skal researches grundigt først. Herunder angående følgende mulighed: I forlængelse af den model jeg bruger nu, og som metode-mæssigt passer mig fint, vil jeg spørge, om I kender til gode html-editorer efter WYSIWYG princippet? Som afløser for min ældgamle Frontpage 2002, som jeg har været glad for som skrivemaskine og fil-organisator. Men jeg kan selvfølgelig i en ny situation med valide koder ikke have det med at den selv tilføjer kode, hvad den konstant gør. Jeg frabeder mig svaret "jeg bruger Notepad, så det foreslår jeg også at du gør". For det kommer jeg helt sikkert ikke til. En evt. ny html-editor skal have en lige så enkel og brugervenlig filorganisator og altså også en WYSIWYG-mulighed.
RexRetiles, keysersoze og olebole, læg venligst svar, hvis I vil have point. Og tak til alle for inputs.
Nej - grunden til at mange foreslår Notepad er, at mestrer man først det forstår man i højere grad hvad der sker i en editor. DreamWeaver og Visual Studio (evt bare den gratis Express-version - og at den er gratis begrænser dig på ingen måde inden for dit behov) er nok blandt de bedste inden for det du søger.
Jeg brugte i mange år Homesite, som er ret bedaget i dag. På et tidspunkt underviste jeg på Københavns Tekniske Skole, hvor brugte DreamWeaver var standard editor - hvorfor jeg nu bruger den. Dog bruger jeg aldrig WYSIWYG-delen, medmindre jeg skal hjælpe en person, der tilgår opgaven herfra.
I det store hele har jeg på fornemmelsen, den skriver ganske acceptabel kode, når man bruger den fra 'forsiden'. Dog skal man passe lidt på det, Adobe vist kalder 'floating layers' (= absolut positionerede elementer). Ellers kommer man let ud i rod med, at nogle elementer flytter sig forkert, når/hvis browseren resize'es.
Så er fristen for at lægge svar udløbet :-) Og jeg afslutter hermed.
Tak også for bud med editorer. Jeg har leget lidt med nogle stykker, og Dreamweaver ser fornuftig ud. Visual Studio 2010 Express var lidt svær at blive glad for, syntes jeg. Vi må se hvad det hele ender med...
Tak for points og god fornøjelse med dit nye værktøj ;o)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
