Indrykninger i en HTML-kode

hvor er det du vil ændre i koden? i en editor eller det der sendes til klienten?

I en editor.
Jeg havde engang adgang til et program der formaterede Pascal-kode på den måde.
"Spruce" hed det.
Det er nyttigt når man læser andres kode.

Hilsen Per

Nej, jeg ved ikke om det skal være en editor - hvis man derved forstår et program som også kan bruges til manuel redigering.
Der var forresten osse et "Anti-Spruce" program - det hed måske "Trim".
Det fjernede alt "overflødigt" whitespace.

Hilsen Per

<ole>

Selvom indrykninger er en rigtig god ting, så er det dog en ligegyldig detalje i forhold til dit eksempel med indrykket kode. Dels er koden i eksemplet ikke valid - og dels vil den resultere i utilsigtet rendering.

Du kan under ingen omstændigheder have et h1-element liggende i et span. Spannet er et inline element - og sådan et kan ikke indeholde et block element.

Dernæst vil koden:
  <td>
    Dette er en tabel
  </td>

- resultere i ekstra luft i bunden af cellen, når siden vises i IE. Hvis det sidste indhold i et block eller 'block-agtigt' element er inline-indhold, skal block elementets sluttag trækkes helt op i slutningen af indholdet:
  <td>
    Dette er en tabel</td>

Ellers vil der som sagt introduceres noget ekstra luft under indholdet.

Hvad indrykninger angår, så er det ikke noget, man laver efter koden er skrevet. Der bør rykkes ind, _mens_ koden skrives.
Indrykning er noget, man selv foretager - forstået på den måde, at når man tabber en linje, tabber programmet selv til samme position, når der skiftes linje næste gang ... og det gør enhver seriøs editor. De fleste editors kan også tabbe blokke af tekst både ind og ud.

Hvormeget og hvor der skal tabbes/indrykkes er et privat anliggende, som afviger fra koder til koder, så det ville være noget rod, hvis editoren selv står for det. Dog er det sådan, at hvis du i f.eks. DreamWeaver indsætter en tabel i design-view, vil koden automatisk være indrykket i kode-view.
Skriver man derimod selv koden, må man altså delvist selv tabbe, hvilket de fleste kodere nok foretrækker  ;o)

/mvh
</bole>

Du kunne prøve at kikke på HTML Tidy:
    http://tidy.sourceforge.net/

Jeg lavede selv engang en 'kodevaskemaskine' til brug sammen med online editors:
    http://www.dengodekode.dk/laundry/

Den er ikke perfekt, men den virker ret okay. Dog vil du nok ikke kunne bruge den direkte i din situation uden lidt ændringer  =)

En kender vil nok påskønne din kode mere end jeg. Jeg har kun lært Javascript vha. klippe-klistre, og de rigtige eksperter kender mange flere hjørner af sproget end jeg.

Du påpeger nogle fejl i mit eksempel. Fint nok, jeg var ikke opmærksom på dem. Men i virkeligheden forestiller jeg mig en programstump, som kun bekymrer sig om en overfladisk del af syntaksen. Den skal ikke finde fejl.

Indrykningsprogrammet skal kunne skelne mellem start-tag og slut-tag (f.eks. <h1> og </h1>).

Men programmet må for min skyld gerne lave indrykninger i en fejlbehæftet kode som denne:

<table><h1></table></h2><dummy></dymmu>

Der skal jo nok laves en lille ordbog ligesom i dit program: Hvilke start-tags kræver et slut-tag? (Tilfældet <p> må behandles specielt, fordi </p> kan bruges men ikke er obligatorisk.)

Hilsen Per

-- hrm, nu begynder vi altså også at nærme os hvilken flavour din mark-up-kode kan indeholde, for undgå p-lukketags kan du zq kun i de rigtig gamle html-udgaver (omend det accepteres i html4.01 transitional, men absolut ikke kan anbefales !-)

Hej roenving,

Du glemte at fortælle hvorfor det ikke kan anbefales.

Hilsen Per

-- fordi det er deprecated (hvilket gælder _alle_ tags med indhold, fordi de ikke lever op til den generelle definition af taggede koder !-)

-- begrebet deprecated skal nærmest oversættes til 'bør ikke bruges, da det principielt ikke lever op til forudsætningerne i denne standard, men først vil blive taget endeligt ud i forbindelse med en kommende/nyere/mere udviklet standard' ...

-- og allerede html4.01 strict, der er defineret samtidigt, tillader ikke åbne tags med indhold ...

Okay, roenving - tak for info.

Det er nyttig viden, at mine hjemmesider på et tidspunkt måske ikke længere kan læses, hvis jeg fortsætter med 4.01 loose frem for 4.01 strict.

Jeg har nu siddet og puslet med én af mine sider, for at få det samme layout frem i strict. Men det er godt nok et hulens bøvl, og jeg ved ikke rigtig hvor meget energi jeg vil bruge på det - for de ser jo rigtige ud i browseren i forvejen. Nå, jeg fortsætter nok alligevel - en anden nørd har tidligere kritiseret mig for at bruge loose, men først nu har jeg fået en begrundelse. Jeg synes det virker lidt arrogant blot at sige: "Lad være med dét" - uden at fortælle hvorfor. Som om jeg burde vide alting på forhånd.

Et HTML "Spruce-program" kunne sagtens koncentrere sig om ikke-loose HTML-definitioner. Det ville gøre programmeringen en hel del nemmere.

Men derefter kommer Javascript-formateringen. Og her ville jeg egentlig gerne give brugeren valgmulighed imellem eksperternes og min egen foretrukne "indryknings-metode". Som nævnt har jeg lært en del Pascal, og her er det sædvane at lade et "begin" have samme indrykning som det tilhørende "end". Men den mest udbredte Javascript-typografi lader IKKE et "{" have samme indrykning som det tilhørende "}". F.eks. skriver eksperterne således:

function xxx() {
[...]
}

- hvilket jeg synes er mindre informativt.

Hilsen Per

Tjah, et godt spørgsmål, men egentlig synes jeg, at det giver den bedste information at lave indrykning på den måde, for det viser, at den pågældende funktion er afsluttet på det niveau, hvor den er påbegyndt, selve deklarationen bør vel ikke skabe en indrykning ...

-- f.eks. kan man have en deklaration af en funktion, hvor der er rigtig mange parametre, og lige efter det en funktion uden parametre, de bør vel ikke syntaktisk adskilles med en tilfældig indrykning ?-)

-- skriver du f.eks. i Visual Studio, rykkes funktions-start-Tuborgen ned på næste linje, hvilket i den sammenhæng er ganske rimeligt, men bare et tegn (eller flere !-) i overskud i webkode, der skal sendes til en browser !o]

Jeg svarer lige selv for at få dette gamle indlæg ud af verden.