---

Kære læsere

Er der nogen der kender et program til Linux der kan ryde op i stylesheet
filer, så classes og divs der ikke bliver brugt slettet?

Knus,
Louise

---

Louise Johnson skrev:

> Kære læsere
>
> Er der nogen der kender et program til Linux der kan ryde op i
> stylesheet filer, så classes og divs der ikke bliver brugt slettet?
>
> Knus,
> Louise

jeg har ikke engang hørt om et til windows! Dine stylesheets ligger jo
på 3 forskellige måder, internt, eksternt, inline. Er de eksterne, så
ville programmet skulle gå samtlige sider igennem, som stylesheetet er
inkluderet i, for at se om der skulle være nogen overskydende
definitioner, ud over det, kan et program jo ikke vide om de skal være
der til fremtidig brug eller ej, så jeg er bange for at du nok selv må
bruge tiden og hovedbruddene på det.
Læs eventuelt: http://web-graphics.com/mtarchive/001649.php for
inspiration til at lave dem, og se i css-koden til www.stopdesign.com
hvordan man rent faktisk kan organisere det, så det også bliver
nogenlunde let at finde rundt i. (douglas har lavet kommentarer med
nogle "unikke" headers så han hurtigt kan søge og finde de steder han
skal arbejde!)


Claus

--

---

> jeg har ikke engang hørt om et til windows! Dine stylesheets ligger jo
> på 3 forskellige måder, internt, eksternt, inline. Er de eksterne, så
> ville programmet skulle gå samtlige sider igennem, som stylesheetet er
> inkluderet i, for at se om der skulle være nogen overskydende
> definitioner, ud over det, kan et program jo ikke vide om de skal være
> der til fremtidig brug eller ej, så jeg er bange for at du nok selv må
> bruge tiden og hovedbruddene på det.
> Læs eventuelt: http://web-graphics.com/mtarchive/001649.php for
> inspiration til at lave dem, og se i css-koden til www.stopdesign.com
> hvordan man rent faktisk kan organisere det, så det også bliver
> nogenlunde let at finde rundt i. (douglas har lavet kommentarer med
> nogle "unikke" headers så han hurtigt kan søge og finde de steder han
> skal arbejde!)

Det findes til Windows, men det koster penge.

http://www.bradsoft.com/topstyle/index.asp

Så jeg havde håbet, at der var en eller anden Perl eller Python programmør
der havde lavet et =)

Knus,
Louise

---

> Det findes til Windows, men det koster penge.
>
> http://www.bradsoft.com/topstyle/index.asp
>
[KLIP]
>
> Knus,
> Louise
>
Hej Louise
Jeg er selv bruger af TopStyle Pro og ekstrem begejstret for dette stykke
software! MEN.... Det kan IKKE rydde op i css-elementer der ikke bliver
brugt. Derimod kan det formatere og sortere css-elementer ved hjælp af en
"Style Sweeper". Dette er den derimod rigtig god til, således at css'en
bliver overskuelig og 'let-læselig'.
Du kan evt. læse lidt mere her:
http://www.html.dk/software/00024/
eller
http://www.html.dk/software/00104/
/Claus

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Claus Rasmussen wrote:
> Jeg er selv bruger af TopStyle Pro og ekstrem begejstret for dette stykke
> software!

Jeg spurgte på et tidspunkt om der var nogen, der kendte til
software/metoder til at "crunche" (altså fjerne al white space, unødig
linieskift, kommentarer osv.) CSS-filer, og fik det svar (af Martin
Hintzmann, mener jeg) at netop TopStyle kan klare det. Har du prøvet dette?

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Jeppe Høiby wrote:
> Jeg spurgte på et tidspunkt om der var nogen, der kendte til
> software/metoder til at "crunche" (altså fjerne al white space, unødig
> linieskift, kommentarer osv.) CSS-filer, og fik det svar (af Martin
> Hintzmann, mener jeg) at netop TopStyle kan klare det. Har du prøvet dette?

Nu er det ikke ligefrem nødvendigt med et program til at gøre den ene
lille ting.
CSS har så simpel en syntax at man let kan skrive en makro til at fjerne
whitespaces, og en til at tilføje dem igen.

Jeg har lavet to sådanne makroer som benytte regexp find/replace. Jeg
benytter Ultra Edit, men jeg er sikker på at princippet ligeledes kan
implementeres i enhver anden editor:
---
CSS-fold:
Find RegExp "(\t.*):\s*"
Replace All "\1:"
Find RegExp "^\s*"
Replace All ""
Find RegExp ";\p"
Replace All ";"
Find RegExp "\s*\{\s*\p*"
Replace All "{"
Find RegExp "^\p([^/])"
Replace All "\1"
---
CSS-unfold:
Find RegExp "\}\p"
Replace All "\p}\p"
Find RegExp "\}\p([^/])"
Replace All "}\p\p\1"
Find RegExp "\{"
Replace All " {\p\t"
Find RegExp ";(.)"
Replace All ";\p\t\1"
Find RegExp "(\t.*):"
Replace All "\1: "
---

Det er muligt at disse ikke kan tages direkte i fald man benytter en
anden måde at stille CSS op på end jeg selv. Jeg stiller typisk mine
ting op sådan:

/* Block1 */
selector {
   property: value;
   property: value;
}

selector {
   property: value;
   property: value;
}
/* /Block1 */

Og så fremdeles.

Brug det eller lad være. Men værsågod.

--
Mvh.
Peter Müller

---

Peter Müller [2000] wrote:
> Brug det eller lad være. Men værsågod.

Super! Mange tak for det, jeg vil prøve at lege med det.

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Peter Müller [2000] skrev:

>> Jeg spurgte på et tidspunkt om der var nogen, der kendte til
>> software/metoder til at "crunche" (altså fjerne al white
>> space, unødig linieskift, kommentarer osv.) CSS-filer, og fik
>> det svar (af Martin Hintzmann, mener jeg) at netop TopStyle
>> kan klare det. Har du prøvet dette?

> Nu er det ikke ligefrem nødvendigt med et program til at gøre
> den ene lille ting.

Style Sweeper i Topstyle kan en del mere end blot at fjerne
whitespace og kommentarer.

Her er nogle af mulighederne:

- Kombiner ens regler (opret gruppe)
- Vælg mellem 1-linje/regel og 1-linje/egenskab
- Skift versalitet på selektorer (fx BODY => body)
- Skift rækkefølge på selektorer
- Skift versalitet på egenskaber
- Skift rækkefølge på egenskaber
- Brug kortformer (fx font i stedet for font-family og font-size)
- Skift format for farvedefinitioner

I forhold til en "cruncher" er det primært mulighederne for at
kombinere regler og bruge kortformer der giver en mærkbar
reduktion. Det vil fx kunne reducere følgende 10 linjers css:

a:link{
   font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
   font-size: 12px;
   font-weight: bold;
}
a:hover{
   font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
   font-size: 12px;
   font-weight: bold;
}

- til denne ene linje:

a:link,a:hover{font:bold 12px Verdana,Geneva,Arial,Helvetica,sans-
serif}


NB: Der er ikke nogen måde at fjerne css-kommentarer med style
sweeper (bedømt ud fra version 3.11 - jeg har ikke testet
betaudgaven af 3.12). Man bør dog også være opmærksom på at ting
der på overfladen bare ligner en kommentar eller en overflødig
erklæring, kan være en del af et css-hack på siden.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Louise Johnson wrote:
> Kære læsere
>
> Er der nogen der kender et program til Linux der kan ryde op i stylesheet
> filer, så classes og divs der ikke bliver brugt slettet?
>
> Knus,
> Louise
>
Der findes et par online tjenester, der gør det for dig. Jeg skriver om
sagen i artiklen:
http://www.webdesign101.dk/www/artikler/bandwidthreduction.html

Med venlig hilsen
Jørgen Farum Jensen
www.webdesign101.dk

---

> http://www.webdesign101.dk/www/artikler/bandwidthreduction.html

De sammentrækker indholdet af css filerne. Det er ikke lige det jeg søger =)

Jeg søger noget i stil med:

programnavn *html *css --output newcss.css

Så den laver en liste over de classes og divs som findes i html filerne,
og findes de ikke i css filerne, så bliver de fjernet.

Egenlig underligt, hvis det ikke findes som Perl eller Python. Det er jo
ganske brugbart =)

Knus,
Louise

---

Louise Johnson skrev:

> > http://www.webdesign101.dk/www/artikler/bandwidthreduction.html
>
> De sammentrækker indholdet af css filerne. Det er ikke lige det jeg
> søger =)
>
> Jeg søger noget i stil med:
>
> programnavn *html *css --output newcss.css
>
> Så den laver en liste over de classes og divs som findes i html
> filerne, og findes de ikke i css filerne, så bliver de fjernet.
>

som jeg også skrev i mit tidligere indlæg, så kan den jo altså ikke
vide præcis hvordan! (der er ALTID begrænsninger, og selv om Brad ved
hvad han gør er der ikke noget program der er fuldkommen!) Jeg kender
godt topstyle, som en decideret css-editor, men må også indrømme at jeg
under ingen omstændigheder vil lade et program ændre min css og fjerne
ting fra den. Den slags skal jeg da nok selv klare, du mister
overblikket over det hvis du overlader den slags til en maskine eller
et program. Ikke mindst hvis man har en ordentlig struktur og
disciplin, så er det ikke noget problem.

Claus

--

---

Louise Johnson skrev:

> Egenlig underligt, hvis det ikke findes som Perl eller Python.

Opgaven er ganske kompleks. At der findes kommercielle programmer
beregnet til det, beviser jo ikke at de gør det
tilfredsstillende.

>Det er jo ganske brugbart =)

Jo, jeg havde såmænd selv brug for det for nylig. Min løsning var
at sætte et XXX ind i de klasser som jeg havde mistanke om var
overflødige og så se om designet faldt til jorden. Så fjernede
jeg X'erne igen ét sted ad gangen indtil det så normalt ud, og så
slettede jeg alle klasserne med X'er i.

Derefter kom jeg til at kikke på en underside og opdagede at én
af dem forresten skulle bruges alligevel ...

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
[snip]

> Derefter kom jeg til at kikke på en underside og opdagede at én
> af dem forresten skulle bruges alligevel ...

Eller et script gør brug af en klasse, som ikke umiddelbart ses i
html-koden.


--
Benny Nissen

---

Benny Nissen skrev:

> Eller et script gør brug af en klasse, som ikke umiddelbart ses i
> html-koden.

Hvordan kan en CSS-klasse hvis påvirkning ikke ses, være
nødvendig?

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Benny Nissen skrev:
>
>> Eller et script gør brug af en klasse, som ikke umiddelbart ses i
>> html-koden.
>
> Hvordan kan en CSS-klasse hvis påvirkning ikke ses, være
> nødvendig?

Simpelt i et javascript skrives en linie ind i dokumentet.

document.write("<td class='AnderledesCelle'>Noget sludder</td>");

AnderledesCelle findes ikke i html, men er indlejret i javascriptet. Den
bruges, men kan ikke findes, ved en søgning i dokumentet..

Med venlig hilsen
Johnny Winther Ronnenberg
--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

Jørgen Farum Jensen wrote:

> http://www.webdesign101.dk/www/artikler/bandwidthreduction.html

Det kan da godt være, at man kan spare nogle procenter i filstørrelse på css
ved at skrive alle definitioner i en lang køre uden linjeskift.

Men det er da hamrende upraktisk og totalt uoverskueligt. Jeg kan ikke
anbefale det.

En css-fil blivers også kun hentet hjem sammen med den første html-side på
sitet, som bruger css'en. Resten af siderne læser den fra cachen, så den
ekstra filstørrelse har minimal betydning.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk
http://html-faq.dk/

---

Erik Ginnerskov wrote:
> Det kan da godt være, at man kan spare nogle procenter i filstørrelse på css
> ved at skrive alle definitioner i en lang køre uden linjeskift.
>
> Men det er da hamrende upraktisk og totalt uoverskueligt. Jeg kan ikke
> anbefale det.
>
> En css-fil blivers også kun hentet hjem sammen med den første html-side på
> sitet, som bruger css'en. Resten af siderne læser den fra cachen, så den
> ekstra filstørrelse har minimal betydning.

Her er jeg fuldstændig enig med de synspunkter Jørgen Farum Jensen
fremlægger i sin artikel.

Hvis man allerede har et site, der validerer og fungerer, bør man bruge
noget energi på optimere. Eet af de steder man kan gøre dette er CSS-filer.

Det er ikke unaturligt at have CSS-filer på 10KB eller mere, og hvis man
bruger "almindelig (overskuelig) notation" er der altså en del at spare
ved at "crunche" CSS-filen.

Det er muligt at det i det samlede billede ikke betyder det store, men
hvis man optimerer alle de steder det er muligt, vil man kunne spare en del.

I mange tilfælde er det jo et spørgsmål om at reducere med nogle få KB,
så alt hvad der kan skrælles væk, bør fjernes/optimeres.

Selv om CSS-filen kun skal hentes een gang, så er det stort set altid,
når de besøgende kommer til forsiden, at dette sker. Det er jo netop på
forsiden at tingene gerne skulle loade hurtigst, så de besøgende ikke
allerede her skræmmes væk.

Om det er upraktisk eller ej, er jo blot et spørgsmål om
planlægning/workflow. Der er ingen der siger at man skal sidde og
arbejde i den samme CSS-fil som bliver publiceret med ens website. Man
kan sagtens forestille sig at have en fil, som er pænt formateret og let
læselige, og at denne fil så køres igennem en "optimizer" eller
"cruncher", som spytter en kompaktudgave af CSS-filen ud. Det er så
denne optimerede fil, som lægges online.

Den gyldne regel (i hvert fald min!) i webdesign er, at man laver det
for brugernes skyld - *IKKE* for ens egen. Derfor er det heller ikke
noget særlig godt argument at sige at filen skal være pænt formateret.
Det samme gælder for (X)HTML-koden. Alt hvad der kan hjælpe brugeren,
hjælper i sidste ende dig selv, for du får gladere brugere/kunder hvis
dit website er toptunet. Det kan CSS-optimering være en (lille) del af.

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Jeppe Høiby skrev:

> Hvis man allerede har et site, der validerer og fungerer, bør
> man bruge noget energi på optimere. Eet af de steder man kan
> gøre dette er CSS-filer.

Vi er enige om at optimering er en god ting, men så hører
enigheden også op. Jeg gjorde 64'er-perioden med, og der kunne
man se 'optimerede' Basic-programmer hvor alle mellemrum og mange
linjeskift var fjernet. Det var frygteligt.

> Det er ikke unaturligt at have CSS-filer på 10KB eller mere, og
> hvis man bruger "almindelig (overskuelig) notation" er der
> altså en del at spare ved at "crunche" CSS-filen.

En del? Jeg tror at du undervurderer moderne computere. Det er
ikke CSS-filer der sinker processen.

> Det er muligt at det i det samlede billede ikke betyder det
> store, men hvis man optimerer alle de steder det er muligt,
> vil man kunne spare en del.

Det er en modstrid. Hvis det ikke betyder det store, kan man ikke
spare noget af betydning.

> Selv om CSS-filen kun skal hentes een gang, så er det stort set
> altid, når de besøgende kommer til forsiden, at dette sker.
> Det er jo netop på forsiden at tingene gerne skulle loade
> hurtigst, så de besøgende ikke allerede her skræmmes væk.

En grundregel ved optimering er at man skal identificere de
steder hvor der bruges tid, før man går i gang. At 'optimere'
hovedløst ved at skære ned hvor man (tror man) kan, spilder ofte
mange gange den tid man prøver at spare.

> Om det er upraktisk eller ej, er jo blot et spørgsmål om
> planlægning/workflow. Der er ingen der siger at man skal sidde og
> arbejde i den samme CSS-fil som bliver publiceret med ens website.

Mangen programmør har lagt noget superspecialtunet kode væk i den
sikre forvisning at det aldrig ville blive nødvendigt at pille
ved det igen, blot for et par måneder senere at sidde og svede
tran over koden fordi den er ugennemskuelig. Endnu værre var det
da hvis 'specialisten' havde forladt projektet og en anden skulle
gætte hvad han havde lavet.

> Man kan sagtens forestille sig at have en fil, som er pænt
> formateret og let læselige, og at denne fil så køres igennem
> en "optimizer" eller "cruncher", som spytter en kompaktudgave
> af CSS-filen ud. Det er så denne optimerede fil, som lægges
> online.

Ja. Så har man to filer der skal opdateres i stedet for én.

> Den gyldne regel (i hvert fald min!) i webdesign er, at man laver det
> for brugernes skyld -

Stakkels bruger der vil lære noget af dine CSS-filer - eller
hjælpe dig med at spore fejl som han ser på sit system, og som du
ikke selv har fundet.

> Det samme gælder for (X)HTML-koden.

Hov! Så er vi pludselig enige igen.

Når jeg laver PHP-styret HTML, står resultatet overskueligt og
letlæseligt.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Vi er enige om at optimering er en god ting, men så hører
> enigheden også op. Jeg gjorde 64'er-perioden med, og der kunne
> man se 'optimerede' Basic-programmer hvor alle mellemrum og mange
> linjeskift var fjernet. Det var frygteligt.

Jeg tror du misforstod mig. Jeg skrev netop at man kunne have to
versioner, så man *ikke* skulle sidde og tåge rundt i en optimeret
(ulæselig) version.

> En del? Jeg tror at du undervurderer moderne computere. Det er
> ikke CSS-filer der sinker processen.

20-30% af en 10-12KB stor fil, synes jeg da bestemt er "en del" i
webdesign-sammenhæng. Desuden har moderne computeres regnekraft
ingenting at gøre med båndbreddeforbrug, hvilket er præcis dét øvelsen
går ud på at spare på.

> Det er en modstrid. Hvis det ikke betyder det store, kan man ikke
> spare noget af betydning.

Så lad mig omformulere. Hvis man KUN optimerer sin CSS-fil(er) og kan
spare fx 2-4KB, så betyder det selvfølgelig ikke det store, hvis man har
et samlet 'load' på 50-80KB.

> En grundregel ved optimering er at man skal identificere de
> steder hvor der bruges tid, før man går i gang. At 'optimere'
> hovedløst ved at skære ned hvor man (tror man) kan, spilder ofte
> mange gange den tid man prøver at spare.

Det er ikke et spørgsmål om at "tro". Og det er heller ikke "hovedløst",
hvis man kan konstatere at ens CSS-fil er kandidat til at blive
optimeret. Men som jeg sagde allerførst i mit tidligere indlæg:

"Hvis man allerede har et site, der validerer og fungerer, bør man bruge
noget energi på optimere. Eet af de steder man kan gøre dette er CSS-filer."

Underforstået CSS-filen er ikke det første sted man bør sætte ind.

> Mangen programmør har lagt noget superspecialtunet kode væk i den
> sikre forvisning at det aldrig ville blive nødvendigt at pille
> ved det igen, blot for et par måneder senere at sidde og svede
> tran over koden fordi den er ugennemskuelig. Endnu værre var det
> da hvis 'specialisten' havde forladt projektet og en anden skulle
> gætte hvad han havde lavet.

Det er heller ikke det jeg siger! Jeg siger jo netop at man skal sørge
for at have en "kilde" og en "destination". ALtså 2 CSS-filer. Een man
arbejder i, og een der publiceres.

> Ja. Så har man to filer der skal opdateres i stedet for én.

Der er ikke tale om at du skal opdatere "destinationen", den skal du
bare se som et slags output af "kilden". Det svarer lidt til at
kompilere et program.

> Stakkels bruger der vil lære noget af dine CSS-filer - eller
> hjælpe dig med at spore fejl som han ser på sit system, og som du
> ikke selv har fundet.

Det rager mig da en høstblomst, om der sidder et par stakkels brugere og
vil lære noget af min CSS-fil. Det er da det sidste jeg vil bekymre mig
om på mit website. Jeg laver altså websites til mine besøgende/kunder,
hvis jeg vil lære nogen CSS, så skriver jeg en artikel om det el.lign.

Hvis jeg skal have hjælp til at spore en fejl, vil jeg enten lægge
"kilden" på, eller jeg vil fejlsøge i et andet miljø. Hensynet til
brugerne står højere end at jeg skal have det nemt i en
fejlsøgningssituation.

>>Det samme gælder for (X)HTML-koden.
>
> Hov! Så er vi pludselig enige igen.

I hvad?

> Når jeg laver PHP-styret HTML, står resultatet overskueligt og
> letlæseligt.

Hmm, så er der jo også her plads til optimering, altså fjerne, white
space osv., måske en form for "filter", der kan optimere HTML-output'et
on-the-fly, hvad ved jeg.

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Jeppe Høiby skrev:

> Jeg tror du misforstod mig. Jeg skrev netop at man kunne have to
> versioner, så man *ikke* skulle sidde og tåge rundt i en optimeret
> (ulæselig) version.

Det forstod jeg godt, men jeg forklarede også at det er upraktisk
at fordoble antallet af filer der skal opdateres. Du havde jo
tænkt dig at køre alle filer gennem persillehakkeren.

Dine øvrige kommentarer er stort set gentagelser eller
uddybninger der ikke ændrer min mening.

> "Hvis man allerede har et site, der validerer og fungerer, bør
> man bruge noget energi på optimere. Eet af de steder man kan
> gøre dette er CSS-filer."

Og min pointe er at man overhovedet ikke skal gå i gang med
optimering før man har vurderet hvor det bedst kan betale sig at
sætte ind. Måske viser analysen at man slet ikke skal pille ved
CSS-filen *selv om* man som dig mener at det er noget der kan
optimeres.

Men mine filer skal altså ikke nedtimeres efter din opskrift.

> Der er ikke tale om at du skal opdatere "destinationen", den skal du
> bare se som et slags output af "kilden". Det svarer lidt til at
> kompilere et program.

Ja, der er der også to filer der skal opdateres. Det er dobbelt
så mange som én.

> Hensynet til brugerne står højere end at jeg skal have det nemt
> i en fejlsøgningssituation.

Du får det her opstillet som om jeg er hensynsløs over for
brugerne. Fidusos forside hentes i Opera 8.5 på 1 sekund når jeg
har tømt hukommelsen og cachen. De to andre browsere (IE FF)
tager noget lignende. Jeg kunne ikke drømme om at fedte med at
kvadre mine filer for at spare brugeren for et millisekund. Den
største side vil jeg tro er "Diverse". Den tager 3 sekunder, men
på det tidspunkt er CSS-filen allerede til rådighed i browseren.

>> Hov! Så er vi pludselig enige igen.

> I hvad?

I at CSS- og HTML-fil skal behandles ens.

>> Når jeg laver PHP-styret HTML, står resultatet overskueligt og
>> letlæseligt.

> Hmm, så er der jo også her plads til optimering

Nej, ikke din slags 'optimering'.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Det forstod jeg godt, men jeg forklarede også at det er upraktisk
> at fordoble antallet af filer der skal opdateres. Du havde jo
> tænkt dig at køre alle filer gennem persillehakkeren.

Jeg gentager gerne: Der er *ikke* tale om at man skal opdatere to filer,
men der er tale om at man skal bruge tid på optimeringen og output'et
bliver en komprimeret fil der skal kopieres sammen med de øvrige ting
til destinationsserveren. "Alle filer" - ja, dem det kan betale sig at
optimere på.


> Dine øvrige kommentarer er stort set gentagelser eller
> uddybninger der ikke ændrer min mening.

OK.

> Og min pointe er at man overhovedet ikke skal gå i gang med
> optimering før man har vurderet hvor det bedst kan betale sig at
> sætte ind. Måske viser analysen at man slet ikke skal pille ved
> CSS-filen *selv om* man som dig mener at det er noget der kan
> optimeres.

Som sagt er CSS-filen ikke det første man bør kaste sig over.

> Men mine filer skal altså ikke nedtimeres efter din opskrift.

Det kan nok heller ikke betale sig for *dig*, men det *kunne* være at
der fandtes andre for hvem det var relevant.

> Ja, der er der også to filer der skal opdateres. Det er dobbelt
> så mange som én.

Hvis optimeringen kan give noget (som jo er en vurdering i den enkelte
situation) så er det arbejdet værd. Det er fuldstændig det samme som at
arbejde med billeder eller kompileret kode.

> Du får det her opstillet som om jeg er hensynsløs over for
> brugerne. Fidusos forside hentes i Opera 8.5 på 1 sekund når jeg
> har tømt hukommelsen og cachen. De to andre browsere (IE FF)
> tager noget lignende. Jeg kunne ikke drømme om at fedte med at
> kvadre mine filer for at spare brugeren for et millisekund. Den
> største side vil jeg tro er "Diverse". Den tager 3 sekunder, men
> på det tidspunkt er CSS-filen allerede til rådighed i browseren.

Sludder. Du gav udtryk for at man skulle tage hensyn til andre
nysgerrige webdesignere i den måde man strukturerer sin kode/design på,
og det er jeg helt uenig.

Jeg har ikke sagt at CSS-optimeringen vil gavne *dig*, men der findes
altså andre sites end dit, som er større og tungere og for hvem
optimeringen vil gavne.

> Nej, ikke din slags 'optimering'.

Siden du har sat optimering i citationstegn, går jeg ud fra at du mener
at båndbreddebesparelse ikke er optimering?

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Jeppe Høiby skrev:

> Jeg gentager gerne: Der er *ikke* tale om at man skal opdatere to filer

Det er latterligt det her. Der er to filer der skal ændres. En
ændring er en opdatering. Hvis jeg ændrer i en C-fil
(programkode), skal jeg kompilere igen så exefilen bliver
opdateret.

> Siden du har sat optimering i citationstegn, går jeg ud fra at
> du mener at båndbreddebesparelse ikke er optimering?

Der er ingen grund til at skyde mig vrøvl i skoene. Jeg siger at
fjernelse af mellemrum og linjeskift og lignende ikke er en reel
optimering. Det har ingen indflydelse af betydning på
båndbredden.

Hvis du vil overbevise mig om noget andet, må du lave nogle
tidsmålinger.

Som Harry Motor svarede da folk blev ved med at indsende
forskellige påstande om hvad der var værst: To ens biler frontalt
mod hinanden med samme fart, eller én af dem frontalt ind i en
solid mur. Han svarede: Stop nu med al den teori. Lad os høre om
nogle praktiske forsøg.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Det er latterligt det her. Der er to filer der skal ændres. En
> ændring er en opdatering. Hvis jeg ændrer i en C-fil
> (programkode), skal jeg kompilere igen så exefilen bliver
> opdateret.

Du fik det til at lyde som man først skulle ind i een fil og lave
opdateringer og bagefter ind i en anden fil og lave de samme
opdateringer. Det er ikke tilfældet.

> Der er ingen grund til at skyde mig vrøvl i skoene. Jeg siger at
> fjernelse af mellemrum og linjeskift og lignende ikke er en reel
> optimering. Det har ingen indflydelse af betydning på
> båndbredden.

Jeg kan ikke se hvordan besparelse af X-antal bytes *ikke* kan være en
optimering.

> Hvis du vil overbevise mig om noget andet, må du lave nogle
> tidsmålinger.

Jamen du har lov at have den holdning du vil, jeg prøver skam ikke at
pådutte dig noget som helst. Jeg giver blot udtryk for min holdning, og
det er helt i orden hvis du ikke er enig.

Det virker som om du er meget fokuseret på at man kun sparer nogle få
100 bytes ved at optimere sin CSS. Det kan også sagtens være tilfældet
hvis man har en lille CSS-fil, men der kan være tilfælde hvor det vil
have en betydning.

Hvis du kigger i mine indlæg har ikke noget sted skrevet at det er en
naturlov at man skal optimere sin CSS. Jeg har tværtimod givet udtryk
for at det nok står som een af de sidste ting på listen. Der er andre
(og sikkert mere relevante) steder man bør kigge først. Det kan fx være
optimering af serverside-kode, caching (som Jens er inde på), billeder
(som Martin er inde på) og måske især HTML, hvis man bruger det gode
gamle tabel i tabel i tabel design-mantra. Man kan også kigge på
overforbrug af div-elementer og class-attributter.

Optimering af CSS-fil bør indgå som *en del* af den øvrige optimering,
og det drejer sig altså ikke om kun at fjerne mellemrum osv., det
handler også om at fjerne unødvendige regler og bruge kortform, fx ændre:
..myClass{
margin-top: 0px;
margin-right: 0px;
margin-bottom: 0px;
margin-left: 0px;
}
til:

..myClass{margin:0}

> Som Harry Motor svarede da folk blev ved med at indsende
> forskellige påstande om hvad der var værst: To ens biler frontalt
> mod hinanden med samme fart, eller én af dem frontalt ind i en
> solid mur. Han svarede: Stop nu med al den teori. Lad os høre om
> nogle praktiske forsøg.

Nu har jeg bare taget mit eget stylesheet fra awake.dk og kørt gennem
TopStyle's "Style sweeper". Det gav dette resultat:

Original størrelse: 6.425 bytes
Efter optimering: 4.320 bytes
En besparelse på ca. 2KB (2.105 bytes = ~33%)

Jeg prøvede også med fidusos:
Original størrelse: 4.685 bytes
Efter optimering: 3.378 bytes
En besparelse på lidt over 1KB (1.307 bytes = ~28%).

Det er en lille besparelse, men det er også kun havldelen af
optimeringsarbejdet. Den anden halvdel består i at kigge på overflødige
klasser, samt regler, der kan skrives på kortform (fx margin:0).

Nu skal man nok lige have med i billedet at ovenstående to CSS-filer er
meget pænt optimerede ift. overflødige regler. Der er nok ikke mange
steder i selve CSS'en man kan optimere, så der er det udelukkende
linieskift og mellemrum osv., der giver noget. Og så er det klart at med
vores små fedtede filer er der ikke nær så meget at hente som et site
med flere eller store CSS-filer.

Så så skal det lige siges at optimeringen har taget nogle få sekunder.
Jeg har stort set bare klikket på en knap i TopStyle.

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Jeppe Høiby skrev:

> Du fik det til at lyde som man først skulle ind i een fil og lave
> opdateringer og bagefter ind i en anden fil og lave de samme
> opdateringer. Det er ikke tilfældet.

Nej og jo. Man skal først ind i den ene fil og skrive nogle
rettelser, og derefter skal man udføre en opdatering af den anden
fil. Der er altså to processer - to opdateringer - som designeren
skal udføre, og der er to filer - råfilen og den kompakte fil -
der skal holdes (versions)styr på.

> Jeg kan ikke se hvordan besparelse af X-antal bytes *ikke* kan
> være en optimering.

Det prøvede jeg at forklare med daleren og skillingen.

> Nu har jeg bare taget mit eget stylesheet fra awake.dk og kørt gennem
> TopStyle's "Style sweeper". Det gav dette resultat:

> Original størrelse: 6.425 bytes
> Efter optimering: 4.320 bytes
> En besparelse på ca. 2KB (2.105 bytes = ~33%)

Det der rummer ingen ny oplysning. Jeg har et udmærket billede af
hvor meget blanktegn fylder i forskellige filtyper. Det var
*tids*studier jeg efterlyste - og jeg mener ikke isolerede tider
på selve CSS-filen, men en test af en samlet side før og efter
kompaktning.

> linieskift og mellemrum osv., der giver noget. Og så er det klart at med
> vores små fedtede filer er der ikke nær så meget at hente som et site
> med flere eller store CSS-filer.

Et site med flere og store CSS-filer har nok også flere og store
HTML-filer med flere og store billeder. Det er stadig
tidsbesparelsen der er interessant, og hvis den relativt er
forsvindende lille, er det ikke optimering, men tidsfordriv at
kompakte filerne.

> Så så skal det lige siges at optimeringen har taget nogle få sekunder.

Ja, jeg er godt klar over at det ikke er et praktisk problem med
selv kompaktningen.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Jeppe Høiby skrev:

> Det er fuldstændig det samme som at arbejde med
> billeder eller kompileret kode.

Med hensyn til billeder er vi helt enige, men kompileret
kode kan ikke køre før det er kompileret, så du har slet
ikke noget at sammenligne det med.

Jeg har prøvet at rydde op i gammel frontpage- og golive-
kode, og her kan man virkelig spare plads og tid ved at
rydde ud i det der ikke bliver brugt, eller er brugt på en
uheldig måde med en masse tabeller i tabeller - det tager
tid at gnaske sig igennem.

Jeg kan dog ikke se fordelen ved at skrive sine koder på
én lang linie, og som andre har været inde på, så giver
det ikke den stor forskel, andet end at man enten skal
have 2 versioner af alle sine sider, eller at det er komplet
umuligt at fejlsøge i.

Et godt design er ikke kun hvordan det ser ud på skærmen.
Jeg kan (det kan mange andre sikkert også) finde på at
kigge i kildekoden, og er den rodet, så mister jeg pludselig
al respekt.

Mange i disse grupper spørger: "Hvordan er det lavet?" Se
i kildekoden, er svaret ofte, men er kildekoden uoverskuelig
eller skrevet i én lang linie i et forkvaklet forsøg på at sige at
man har optimeret sin kode, så spørger jeg ofte mig selv
hvor mange millisekunder det mon har givet?

Vis med stolthed det du har lavet - gerne så selv din mor kan
forstå det

--
Allan Vebel
http://html-faq.dk

---

> Hvis man allerede har et site, der validerer og fungerer, bør man bruge
> noget energi på optimere. Eet af de steder man kan gøre dette er CSS-filer.

De tjenester som der blev henvist til tror jeg ikke går udpå at spare
båndbredde. Om man spare 300 bytes for hvert besøg har indet at sige. Ved
1000 besøg er det 300k. Såting!

Bare brugeren åbner ét ekstra billed på dit site, på lade os sige 40k, så
falder hele css optimerings ideen til jorden.

Hvis man skal spare båndbredde, så skal man væksle mellem gif og png. Der
kan være et par kb at hente.

Men til de små sites, som vi laver, så har det stadig ingen betydning.

At sidde og fjerne linie skift og sammen trække flere linier til en, tror
ingen betydning har. Browseren køre jo ikke css scriptet. Det bliver læst
og med det samme oversat til noget andet.

Folk der bruger css optimizere ønsker nok mere at gøre deres kode ulæselig
for andre, så folk ikke har lige så lidt ved at hugge ideer.

Personligt synes jeg det er dårlig stil. Hvem kan sige sig fri fra, ikke
at have lært af, at kigge i andres css og html filer?

---

Martin wrote:
> De tjenester som der blev henvist til tror jeg ikke går udpå at spare
> båndbredde. Om man spare 300 bytes for hvert besøg har indet at sige. Ved
> 1000 besøg er det 300k. Såting!

De to tjenester der henvises til, optimerer heller ikke CSS-filen så
meget den kan. Langt fra. "Rigtig" optimering vil typisk kunne spare ca.
20-30%. Der må holdes op imod størrelsen af ens CSS-fil(er). Det er klar
at jo større filer man har, jo større gevinst er der ved optimeringen.

> Bare brugeren åbner ét ekstra billed på dit site, på lade os sige 40k, så
> falder hele css optimerings ideen til jorden.

Ja 40KB er da en del ift. hvad man kan optimere på en CSS-fil, men et
40KB billede er forhåbentligt ikke dét du præsenterer dine besøgende for
på din forside.

> Hvis man skal spare båndbredde, så skal man væksle mellem gif og png. Der
> kan være et par kb at hente.

Det er nu ikke kun billeder, eller CSS for den sags skyld, man kan hente
nogle bytes. Det er sådan set i alle de filer, der skal sendes til
klienten, fx javascript, HTML, flash, applets osv. Iøvrigt er PNG vel et
ret dårlig vel pga. den dårlige understøttelse i IE.

> Men til de små sites, som vi laver, så har det stadig ingen betydning.

Det er klart jo større sitet er, og jo flere besøgende det har, jo
større fordel er der i optimeringen.

> At sidde og fjerne linie skift og sammen trække flere linier til en, tror
> ingen betydning har. Browseren køre jo ikke css scriptet. Det bliver læst
> og med det samme oversat til noget andet.

Det er ikke et spørgsmål om hvad der sker i browseren. Det er
udelukkende et spørgsmål om at spare båndbredde og give de besøgende et
hurtigere site.

> Folk der bruger css optimizere ønsker nok mere at gøre deres kode ulæselig
> for andre, så folk ikke har lige så lidt ved at hugge ideer.

Det har du nok ret i, men det hjælper jo ikke noget som helst.

> Personligt synes jeg det er dårlig stil. Hvem kan sige sig fri fra, ikke
> at have lært af, at kigge i andres css og html filer?

Som jeg også skrev til Bertel, så laver jeg altså ikke websites for at
tilfredsstille nogle få webdesigner-nørder, der vil lære noget af min
CSS. Folk må kigge alt det de vil og lære alt det de vil ved at kigge i
kilden, men det går altså ud på at lave hurtige og brugervenlige
websites for ens besøgende.

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

> Som jeg også skrev til Bertel, så laver jeg altså ikke websites for at
> tilfredsstille nogle få webdesigner-nørder, der vil lære noget af min
> CSS. Folk må kigge alt det de vil og lære alt det de vil ved at kigge i
> kilden, men det går altså ud på at lave hurtige og brugervenlige
> websites for ens besøgende.

Det kommer det heller ikke til =)

Hvor hurtig er gennemsnitsforbindelsen og hvormeget variere den?

Hvis variationen er mindre en det du kan spare på en css fil, så kan det
betale sig, ellers ikke.

Eks. Mon ikke gennemsnitsforbindelsen er person har er en slags ADSL på
1Mbit? (Min forbindelse er 8Mbit)

En gennemsnits css fil fylder nok 5k.

Ved optimering siger vi man vinder 30%

Variationen på forbindelsen er min. 512kbit.


Den nye css størrelse er 3,5k og man har vundet 1.5k

På en 1Mbit forbindelse tager det ca. 0,0122 sek. at hente 1.5k.

Det vil sige, at har brugeren en 1,5Mbit forbindelsen er besparelsen
endnu mindre, og har brugeren en 512kb forbindelse, så er besparelsen
0,02 sek.

Det kan ikke mærkes! Selv ikke hvis besparelsen var 10 gange så stor,
altså så tiden blev 0,1 sek i forhold det 1Mbit.

Hvis besparelsen var 100 gange så stor end de 30%, så har du vundet
1 sek i forhold til 1Mbit.

Eller se det på en anden måde. Hvis du hårdt og brutalt slettede din css
fil, det som vil svarer til en besparelse på 100%, så har du sparet
0,04 sek.



Mit råd er, at hvis man virkelig har et båndbredde problem, så fjern
bare ét billed på dit website. Selv hvis du
fjernede det mindste af alle dine billeder, så er besparelsen størrere.

Hvis folk optimere deres css fordi de synes det er sjovt, så er det noget
helt andet. Men det spare ikke båndbredde eller tid.

---

Martin wrote:
> Det kommer det heller ikke til =)

Hvad kommer til hvad?

[klip beregning]

Jamen jeg er skam ikke uenig i at der er andre steder man kan optimere
*mere*! Jeg siger blot at hver eneste kilobyte man kan "spare" betyder
noget. Dette er CSS-optimering blot en (lille) del af.

Desuden tager du nærmest for givet at de fleste sidder på fede
ADSL-forbindelse - det gør de *ikke*! Der findes stadig en del
mennesker på almindelige modem, og specielt for disse mennesker vil det
betyde noget.

> Mit råd er, at hvis man virkelig har et båndbredde problem, så fjern
> bare ét billed på dit website. Selv hvis du
> fjernede det mindste af alle dine billeder, så er besparelsen størrere.

Det handler ikke om at sammenligne, det handler om at jo mere du kan
spare jo bedre. Hvis du kan fjerne billeder, fint! Hvis du kan fjerne
unødvendig CSS, fint!

> Hvis folk optimere deres css fordi de synes det er sjovt, så er det noget
> helt andet. Men det spare ikke båndbredde eller tid.

Det er jeg ikke enig i. Og jeg synes stadig man sparer båndbredde ved at
skære 1, 2, 3, 4, 5... KB af sin CSS-fil.

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

> Desuden tager du nærmest for givet at de fleste sidder på fede
> ADSL-forbindelse - det gør de *ikke*! Der findes stadig en del
> mennesker på almindelige modem, og specielt for disse mennesker vil det
> betyde noget.

Selv ikke for dem vil det betyde noget. I bedste fald snakker vi om 0.5
sek. her.

Husk at css filen bliver cache't.

> Det handler ikke om at sammenligne, det handler om at jo mere du kan
> spare jo bedre. Hvis du kan fjerne billeder, fint! Hvis du kan fjerne
> unødvendig CSS, fint!

Det handler altid om at sammenligne. Der er forskel på at spare 300 bytes
på et website, og 300 bytes i en IC.

Du har en fornemmelse om, at du kan spare noget ved at gøre din css
mindre. Vi snakker altså om 2k - 3k i bedste fald. Er det tiden og ulempen
at andre ikke nemt kan læse dine filer?

Og det gør det bestemt ikke nemmere for dig selv, at vedligeholdt dit site.

Som jeg skrev. Hvis du går det for morskaben så er det en ting, men gør du
det for at spare båndbredde, så spilder du din tid.


> Det er jeg ikke enig i. Og jeg synes stadig man sparer båndbredde ved at
> skære 1, 2, 3, 4, 5... KB af sin CSS-fil.

Tag det her eks.

Forestil dig, at jeg laver en while-løkke med wget i, hvor jeg
henter dit website 10.000 gange.

Mens den står og henter dit website ned, hvor ville du optimere, så
båndbredden bliver så lille som mulig?

At lukke websitet eller blokke min IP eller noget i den stil går
spørgsmålet ikke ud på. Vi snakker om optimering af båndbredde.

---

Martin wrote:
> Selv ikke for dem vil det betyde noget. I bedste fald snakker vi om 0.5
> sek. her.

Det kan du jo ikke vide, når du ikke kender størrelsen på CSS-filen, og
hvor mange KB der er skrællet af.

> Husk at css filen bliver cache't.

Ja.

> Det handler altid om at sammenligne. Der er forskel på at spare 300 bytes
> på et website, og 300 bytes i en IC.

Ja.

> Du har en fornemmelse om, at du kan spare noget ved at gøre din css
> mindre. Vi snakker altså om 2k - 3k i bedste fald. Er det tiden og ulempen
> at andre ikke nemt kan læse dine filer?

Ja.

> Og det gør det bestemt ikke nemmere for dig selv, at vedligeholdt dit site.

Nej, men heller ikke sværere.

> Som jeg skrev. Hvis du går det for morskaben så er det en ting, men gør du
> det for at spare båndbredde, så spilder du din tid.

Det er ikke spild af min tid at bruge 10 sekunder på at optimere min CSS.

> Tag det her eks.
>
> Forestil dig, at jeg laver en while-løkke med wget i, hvor jeg
> henter dit website 10.000 gange.
>
> Mens den står og henter dit website ned, hvor ville du optimere, så
> båndbredden bliver så lille som mulig?

Hvis du *vil* misforstå, så er det åbenbart ikke svært. Det er *IKKE* et
spørgsmål om *KUN* at optimere CSS-filen. Der er mange andre steder der
er relevant at optimere først!

> At lukke websitet eller blokke min IP eller noget i den stil går
> spørgsmålet ikke ud på. Vi snakker om optimering af båndbredde.

Ja, det gør vi, og her kan optimering af CSS-filer hjælpe (lidt).

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

> Det er ikke spild af min tid at bruge 10 sekunder på at optimere min CSS.

Hvad med ulemperne? Så som at du skal vedligeholde to filer isetdet for en?

Ideen med CVS forsvinder totalt.

> Hvis du *vil* misforstå, så er det åbenbart ikke svært. Det er *IKKE* et
> spørgsmål om *KUN* at optimere CSS-filen. Der er mange andre steder der
> er relevant at optimere først!

Bare at vi er enige om, at det overhovedet ingen betydning har for
brugeren eller for din båndbredde.

> Ja, det gør vi, og her kan optimering af CSS-filer hjælpe (lidt).

Hvis du havde svaret det i en multiple choice quiz, så havde du fået
minus. (man få plus for at svare rigtigt, 0 for ikke at svare og minus
for at svare forkert.)

Du burde overveje HTML4, hvor man ikke behøves at afslutte alle tags, som
f.eks. <tr>


Samtalen er slut fra min side af uanset, hvad du svare. Vi kommer ikke
vidre.

---

Martin wrote:
> Samtalen er slut fra min side af uanset, hvad du svare. Vi kommer ikke
> vidre.

Det er skam også helt i orden at have sin egen holdning til tingene.

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Jeppe Høiby wrote:
> Erik Ginnerskov wrote:
>
>> Det kan da godt være, at man kan spare nogle procenter i filstørrelse
>> på css
>> ved at skrive alle definitioner i en lang køre uden linjeskift.
>>
>> Men det er da hamrende upraktisk og totalt uoverskueligt. Jeg kan ikke
>> anbefale det.
>>
>> En css-fil blivers også kun hentet hjem sammen med den første
>> html-side på
>> sitet, som bruger css'en. Resten af siderne læser den fra cachen, så den
>> ekstra filstørrelse har minimal betydning.
>
Jeg ser, at min henvisning til en artikel jeg har skrevet har vakt en lille
debat, så jeg vil lige sige, at jeg jo ikke har skrevet, at det er noget
man *skal* gøre. Jeg henleder blot opmærksomheden på et forhold, jeg ikke
selv før har tænkt over, og giver anvisning på, hvordan man kan reducere
datamængden i stylesheets.

Artiklen overskrift henviser til sparet båndbredde, og det er det, det
handler om.

Så derfor er jeg helt på Jeppe Høibys side, det handler om, hvor hurtigt en
side indlæses, jo hurtigere jo bedre. Hver kilobyte sparet betyder noget.
Derfor kan man ikke anstille sammenligninger, som en posting gør, med et
billedes tyngde eller lignende.

Dermed være ikke sagt, at det er det første man skal tage sig til for at
spare båndbredde. Med fare for at starte en ny debat vil jeg fortælle, at
jeg har for nylig foretaget nogle analyser af forskellige webprojekter,
hvor det viser sig, at html-kode/tekst ratioen lån mellem 5:1 og 10:1,
fordi siderne var layoutet med en mængde tabeller i tabeller og med en
mængde inline attributter, inklusive styleattributter.

Se, der er virkelig noget at hente.

Med venlig hilsen
Jørgen Farum Jensen
www.webdesign101.dk

---

Claus Jacobsen skrev:

>> Så den laver en liste over de classes og divs som findes i
>> html filerne, og findes de ikke i css filerne, så bliver de
>> fjernet.

> som jeg også skrev i mit tidligere indlæg, så kan den jo altså
> ikke vide præcis hvordan!

Jo - hvis der kun er tale om at fjerne ubrugte klasser og id-
værdier, kan det godt gøres automatisk (forudsat at scriptet kan se
al den html-kode der bruges - det kan give problemer hvis man
bruger serversidesprog til at generere kode).


> (der er ALTID begrænsninger, og selv om Brad ved hvad han gør

Manden bag Topstyle hedder nu Nick (Bradbury).


> omstændigheder vil lade et program ændre min css og fjerne
> ting fra den. Den slags skal jeg da nok selv klare, du mister
> overblikket over det hvis du overlader den slags til en
> maskine eller et program. Ikke mindst hvis man har en
> ordentlig struktur og disciplin, så er det ikke noget problem.

Jeg kan sagtens følge Louises problem. På et stort site med masser
af klasser og id-værdier, kan det være svært at holde styr på hvor
mange der er i brug. Og problemet bliver kun værre af at der
udvikles løbende på sitet - så nogle css- og html-filer er gamle,
mens andre er helt nye.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen skrev:


> Manden bag Topstyle hedder nu Nick (Bradbury).
>
>

Duh! selvf. , nå jeg må vist hellere finde en grund til misseren! (jeg
har haft rimeligt travlt de sidste par dage!)


Claus

--

---

Jeppe Høiby skrev:

> Det er nu ikke kun billeder, eller CSS for den sags skyld, man
> kan hente
> nogle bytes. Det er sådan set i alle de filer, der skal
> sendes til
> klienten, fx javascript, HTML, flash, applets osv.

Det er klart - når det gælder båndbredde er alt hvad der overføres
mellem server og klient af betydning. Har du nogle eksempler på
hvor meget en komprimering giver i praksis?

<personlig kæphest>
Når man bruger serversidekode, er der i øvrigt en helt anden ting
der har stor indflydelse på den oplevede hastighed på et site -
nemlig cache-styring. Der er jævnligt folk i asp-gruppen der
spørger om hvordan man undgår caching af en side. Det kan sagtens
gøres - og i nogle tilfælde er det også ønskeligt - men brugt
forkert, vil cacheblokering have langt større konsekvenser end
manglende kodeoptimering. En kodeoptimering kan måske spare 20-30 %
pr objekt, mens fornuftig brug af cache sparer næsten 100 % pr
objekt.

I langt de fleste tilfælde har browseren ganske godt styr på hvad
der kan caches og hvad der ikke skal caches - men det bliver sat ud
af kraft på mange serverside-sider, fordi forfatteren er hunderæd
for at en bruger skal se en side der ikke er 200 % opdateret.
</personlig kæphest>


> Iøvrigt er PNG vel et ret dårlig vel pga. den dårlige
> understøttelse i IE.

Så vidt jeg ved er det kun PNG-transparens der giver problemer i
IE.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen wrote:
> Det er klart - når det gælder båndbredde er alt hvad der overføres
> mellem server og klient af betydning. Har du nogle eksempler på
> hvor meget en komprimering giver i praksis?

Ikke andre end dem jeg har refereret til i svaret til Bertel.

Det er dog typisk 20-30% man kan spare, så man må vurdere om man har en
stor nok CSS-fil til det kan betale sig.

[klip personlig kæphest]

Ja, det er jeg meget enig i. Der er en hel del at hente ift. optimering.
Har du leget med Caching i .NET? Jeg har ikke selv, men læst en del om
det, og det ser ud til at være ret godt.

> Så vidt jeg ved er det kun PNG-transparens der giver problemer i
> IE.

Jeg kender ikke problemets karakter, men jeg faldt over denne side:
<http://homepage.ntlworld.com/bobosola/index.htm>
som beskriver problemet med transparens (skal ses både i IE og fx FF).

Jeg ved ikke om der er andre problemer med PNG i IE.

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

On Thu, 13 Oct 2005 13:12:31 +0200, Jens Gyldenkærne Clausen
<jens@gyros.invalid> wrote in dk.edb.internet.webdesign.html:

>Det er klart - når det gælder båndbredde er alt hvad der overføres
>mellem server og klient af betydning. Har du nogle eksempler på
>hvor meget en komprimering giver i praksis?
>
><personlig kæphest>
>Når man bruger serversidekode, er der i øvrigt en helt anden ting
>der har stor indflydelse på den oplevede hastighed på et site -
>nemlig cache-styring. Der er jævnligt folk i asp-gruppen der
>spørger om hvordan man undgår caching af en side. Det kan sagtens
>gøres - og i nogle tilfælde er det også ønskeligt - men brugt
>forkert, vil cacheblokering have langt større konsekvenser end
>manglende kodeoptimering. En kodeoptimering kan måske spare 20-30 %
>pr objekt, mens fornuftig brug af cache sparer næsten 100 % pr
>objekt.
>
>I langt de fleste tilfælde har browseren ganske godt styr på hvad
>der kan caches og hvad der ikke skal caches - men det bliver sat ud
>af kraft på mange serverside-sider, fordi forfatteren er hunderæd
>for at en bruger skal se en side der ikke er 200 % opdateret.
></personlig kæphest>

Er det noget, du vil uddybe - for ASP's vedkommende?
Eller måske give et par forståelige links?

XFUT: dk.edb.internet.webdesign.serverside.asp

Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

Jørn Andersen skrev:

[om brug - og misbrug - af cache]

> Er det noget, du vil uddybe - for ASP's vedkommende?


Det bliver meget kort i første omgang - jeg er snart på vej til
kapsang i Köln.

Jeg tænker på utallige indlæg i denne gruppe hvor folk spørger om
hjælp til at sikre at besøgende altid ser seneste udgave af siden.
Typisk er problemet at en udvikler har siddet og ændret i koden, og
når han/hun så går ind på sitet igen er det den gamle side der
vises. Det nogle bare glemmer, er at de har besøgt tidligere i
samme browsersession - og det er derfor den cachede udgave vises.

"Rigtige" besøgende kan godt komme ud for det samme - men
sandsynligheden er meget lille.

Et praktisk eksempel kan være en get-baseret søgeside. Prøv at lave
en vilkårlig google-søgning, besøg en af de sider der linkes til,
og vend så tilbage med tilbage-knappen. Det fungerer fint, fordi
Google klogeligt.

Hvis Google nu havde tænkt "brugerne må ikke få en forældet
søgning" eller "brugerne skal have friske reklamer hver gang de ser
en side", kunne de fortælle browseren at søgeresultatet ikke måtte
caches i browseren - men det ville betyde markant længere svartid
når man bladrer frem og tilbage, samt belaste Google-serverne langt
mere end nødvendigt.

Der er bestemt også tilfælde hvor der er god grund til at forhindre
caching - men hvis den eneste grund man kan komme i tanke om er
"brugerne må ikke se gamle data", er det sandsynligvis en dårlig
ide.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

On Fri, 14 Oct 2005 11:05:50 +0200, Jens Gyldenkærne Clausen
<jens@gyros.invalid> wrote:

>Det bliver meget kort i første omgang - jeg er snart på vej til
>kapsang i Köln.

Jamen god tur!

>Jeg tænker på utallige indlæg i denne gruppe hvor folk spørger om
>hjælp til at sikre at besøgende altid ser seneste udgave af siden.

<snip glimrende forklaring, som jeg godt forstår>

Jeg er helt klart en af synderne, så hvis du får tid, lyst og
lejlighed kunne jeg godt tænke mig nogle bud på, hvordan det omsættes
til praksis

Pft.,
Jørn

--
Jørn Andersen,
Brønshøj

---

Det lyder som et spændende projekt, som jeg godt kunne finde på at kaste
mig over i Perl.

En skrev om, at man kunne have classes og divs i scripts. Bliver de
angivet på samme måde som i html?

Ellers kan css vil kun forekomme i(?):

* html indrammet af <style></style>
* <link rel="stylesheet" type="text/css" href="FILENAME" />
* en css fil ved @import "FILENAME";

Kan der være andre måder, at angive css på?

---

Martin wrote:
> Det lyder som et spændende projekt, som jeg godt kunne finde på at kaste
> mig over i Perl.

Det er nok et ret stort projekt at gå i gang med. I hvert fald skal det
script ikke arbejde på lokale filer, men kun ting der har været igennem
den server der sørger for templating.
Derudover skal du tage højde for 4 forskellige måder at style på,
herunder specielt specificitet, og kunne strukturere css'en så den giver
mening for et menneske at læse. Du skal tage højder for at der eventuelt
bliver tilføjet styles eller klasser til DOM'en fra javascripts, som
ikke optræder i DOM'en i forvejen, dvs du kan ikke med sikkerhed slette
en css selector blot fordi den ser overflødig ud i den hentede html kode.


> * html indrammet af <style></style>
> * <link rel="stylesheet" type="text/css" href="FILENAME" />
> * en css fil ved @import "FILENAME";
>
> Kan der være andre måder, at angive css på?

<element style="property: value;"></element>
<script type="text/javascript">
   var temp = document.getElementById('test');
   temp.className = 'nyklasse';
   temp.id = 'nytid'
   temp.style.foo = 'bar;
</script>

--
Mvh.
Peter Müller
http://fumle.dk

---

> Det er nok et ret stort projekt at gå i gang med. I hvert fald skal det
> script ikke arbejde på lokale filer, men kun ting der har været igennem
> den server der sørger for templating.

Det tror jeg du har ret i.

> Derudover skal du tage højde for 4 forskellige måder at style på,
> herunder specielt specificitet, og kunne strukturere css'en så den giver
> mening for et menneske at læse.

Jeg har angivet 3 måder i min forige post. Hvad er den 4.?

> Du skal tage højder for at der eventuelt
> bliver tilføjet styles eller klasser til DOM'en fra javascripts, som
> ikke optræder i DOM'en i forvejen, dvs du kan ikke med sikkerhed slette
> en css selector blot fordi den ser overflødig ud i den hentede html kode.

Nu ved jeg ikke hvad DOM er.

Hvis det er JS der laver et stylesheet, så er der vel ingen problemer?

Min plan er kun at ryde op i css og ikke i HTML filerne.

> <element style="property: value;"></element>
> <script type="text/javascript">
>    var temp = document.getElementById('test');
>    temp.className = 'nyklasse';
>    temp.id = 'nytid'
>    temp.style.foo = 'bar;
> </script>

Ja okay, det er en "grim" en. Jeg har aldrig hørt om det før. Hvad er/kan
være fordelen med at generere CSS i JS?

---

Martin wrote:
> Jeg har angivet 3 måder i min forige post. Hvad er den 4.?

Den 4. mulighed er inline styles som <element style="property:
value;"></element>


> Nu ved jeg ikke hvad DOM er.

Document Object Model. Det er den model man benytter til at tilgå og
modificere dokumentstrukturen via javascript.


> Hvis det er JS der laver et stylesheet, så er der vel ingen problemer?

JS laver typisk ikke et stylesheet, men benyttes til at sætte en/flere
klasser på ting, som ikke findes i html'en i forvejen. Det betyder også
at hvis du kun kigger på html'en som den er hentet fra serveren, og den
tilhørende css, så kan enkelte klasser virke overflødige. Men hvis de
fjernes virker scriptet pludselig ikke mere efter henseende. Derfor skal
du også tage højde for eventuelle klasser som benyttes af scripts.


> Min plan er kun at ryde op i css og ikke i HTML filerne.

Derved er hele idéen om et oprydningsværktøj jo mere eller mindre
forsvundet. En af de helt grimme ting er netop inline styles fordi disse
ikke kan caches på samme måde som et eksternt stylesheet. Hvis du kun
kigger på css filen, så er din målgrupe folk som gør det rigtigt i
forvejen, og de vil typisk ikke rigtig have gavn af sådan et værktøj.


>><script type="text/javascript">
>>   var temp = document.getElementById('test');
>>   temp.className = 'nyklasse';
>>   temp.id = 'nytid'
>>   temp.style.foo = 'bar;
>></script>
> Ja okay, det er en "grim" en. Jeg har aldrig hørt om det før. Hvad er/kan
> være fordelen med at generere CSS i JS?

Fordelen ved at generere styles i JS er at du kan lave ekstra
funktionalitet for folk me dJS understøttelse, mens du kan undgå at
genere folk som ikke har JS understøtelse med det som scriptet ellers
ville tilføje.

Jeg ser ingen fordel ved at tilføje styles direkte i JS fremfor blot at
ændre classer eller id. Men det betyder ikke at folk undlader at
hardcode styles i JS.

--
Mvh.
Peter Müller
http://fumle.dk

---

> Den 4. mulighed er inline styles som <element style="property:
> value;"></element>

Kan der være andet end JS derinde?

> Document Object Model. Det er den model man benytter til at tilgå og
> modificere dokumentstrukturen via javascript.
>

Ok.

> JS laver typisk ikke et stylesheet, men benyttes til at sætte en/flere
> klasser på ting, som ikke findes i html'en i forvejen. Det betyder også
> at hvis du kun kigger på html'en som den er hentet fra serveren, og den
> tilhørende css, så kan enkelte klasser virke overflødige. Men hvis de
> fjernes virker scriptet pludselig ikke mere efter henseende. Derfor skal
> du også tage højde for eventuelle klasser som benyttes af scripts.

Det har jeg godt nok aldrig mødt, men så må jeg gøre det klart, at man
skal bruge programmet med forbehold, hvis der indgår JS.

> Derved er hele idéen om et oprydningsværktøj jo mere eller mindre
> forsvundet. En af de helt grimme ting er netop inline styles fordi disse
> ikke kan caches på samme måde som et eksternt stylesheet. Hvis du kun
> kigger på css filen, så er din målgrupe folk som gør det rigtigt i
> forvejen, og de vil typisk ikke rigtig have gavn af sådan et værktøj.

Personligt vil jeg selv have gavn af sådan et program, når jeg henter
websites ned med f.eks. Scrapbook, og har rettet i dem. Nogen gange
rettet/fjernet meget.


> Fordelen ved at generere styles i JS er at du kan lave ekstra
> funktionalitet for folk me dJS understøttelse, mens du kan undgå at
> genere folk som ikke har JS understøtelse med det som scriptet ellers
> ville tilføje.

Smart.

> Jeg ser ingen fordel ved at tilføje styles direkte i JS fremfor blot at
> ændre classer eller id. Men det betyder ikke at folk undlader at
> hardcode styles i JS.

Der kan vel forekomme hvad somhelt i JS =)

---

Peter Müller [2000] skrev:

> Det er nok et ret stort projekt at gå i gang med.

Man kan jo starte med en light-udgave. En udgave der ikke tager
hensyn til javascript-filer og servergenereret kode kunne fx være
første mål.

Sådan en udgave kan sagtens være anvendelig i praksis - der er jo
ingen der siger at scriptet bare skal slette de klasser det ikke
kan finde i html-koden. Hvis det fx bare markerer dem, eller
flytter dem til en særskilt fil, kan man selv afprøve om de nu også
er sikre at slette.


> I hvert fald skal det script ikke arbejde på lokale filer, men
> kun ting der har været igennem den server der sørger for
> templating.

Det vil være en god ide - men det er ikke nødvendigt hvis man
arbejder med rene html-filer eller med shtml.

Det er heller ikke sikkert det er nødvendigt hvis man arbejder med
asp eller php - det afhænger af om der genereres klassekode direkte
i asp-filen (en <style>-blok placeret i en asp-fil er ikke i sig
selv et problem).

> Derudover skal du tage højde for 4 forskellige måder at style
> på,

Nej. Direkte styling (<p style="...">) er ikke relevant for et
script der leder efter ubrugte klasser og id-værdier - den slags
kan kun angives på 3 måder.

> herunder specielt specificitet,

Heller ikke rigtigt. Hvis en klasse ikke anvendes på nogen html-
side, er dens specificitet underordnet.


> og kunne strukturere css'en så den giver mening for et menneske
> at læse.

Jeg tror du forventer at scriptet skal kunne en del mere end det
der efterspørges. En oprydning i form af at slette ubrugte
klasser/id-værdier betyder ikke at der skal omstruktureres i resten
af css-koden. Princippet er ret enkelt - hvis scriptet kan finde en
reference til css-klassen i de tilknyttede html-sider, skal regler
baseret på denne klasse beholdes, i modsat fald skal de markeres
til sletning.


> Du skal tage højder for at der eventuelt bliver tilføjet
> styles eller klasser til DOM'en fra javascripts, som ikke
> optræder i DOM'en i forvejen, '

Det har du ret i. Hvis man ikke kender til de javascripts der
bliver anvendt på siden, kan metoden være dårlig. Men omvendt er
det ikke et problem i praksis hvis man ved at der ikke bliver brugt
javascript til at manipulere med css på sitet (eller hvis man ved
præcis hvad javascript foretager sig i forhold til css).
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

> Man kan jo starte med en light-udgave. En udgave der ikke tager
> hensyn til javascript-filer og servergenereret kode kunne fx være
> første mål.

Til mit formål, der vil det er nok =) Og der skal nok være en perl hej et
sted der kan finde på noget, når JS er i stil =)

> Sådan en udgave kan sagtens være anvendelig i praksis - der er jo
> ingen der siger at scriptet bare skal slette de klasser det ikke
> kan finde i html-koden. Hvis det fx bare markerer dem, eller
> flytter dem til en særskilt fil, kan man selv afprøve om de nu også
> er sikre at slette.

En udkommentaring er nok bedre som du siger. Det vil jeg gøre.

> Det vil være en god ide - men det er ikke nødvendigt hvis man
> arbejder med rene html-filer eller med shtml.
>
> Det er heller ikke sikkert det er nødvendigt hvis man arbejder med
> asp eller php - det afhænger af om der genereres klassekode direkte
> i asp-filen (en <style>-blok placeret i en asp-fil er ikke i sig
> selv et problem).

Næ, det burde vel bare virke, hvis jeg søger efter class= og id=



> Nej. Direkte styling (<p style="...">) er ikke relevant for et
> script der leder efter ubrugte klasser og id-værdier - den slags
> kan kun angives på 3 måder.

Kender du et/par website(s) der bruger direkte styling? Jeg kunne godt
tænke mig, at kigge lidt på det.

Eller endnu bedre, kan du finde det på w3c?

På
http://www.w3.org/Style/CSS/

kan jeg ikke finde det=(



> Jeg tror du forventer at scriptet skal kunne en del mere end det
> der efterspørges. En oprydning i form af at slette ubrugte
> klasser/id-værdier betyder ikke at der skal omstruktureres i resten
> af css-koden. Princippet er ret enkelt - hvis scriptet kan finde en
> reference til css-klassen i de tilknyttede html-sider, skal regler
> baseret på denne klasse beholdes, i modsat fald skal de markeres
> til sletning.

Simpelhen =)

> Det har du ret i. Hvis man ikke kender til de javascripts der
> bliver anvendt på siden, kan metoden være dårlig. Men omvendt er
> det ikke et problem i praksis hvis man ved at der ikke bliver brugt
> javascript til at manipulere med css på sitet (eller hvis man ved
> præcis hvad javascript foretager sig i forhold til css).

Nej, så beder man næsten selv om det =)

---

Martin skrev:

>> Nej. Direkte styling (<p style="...">) er ikke relevant

> Kender du et/par website(s) der bruger direkte styling?

Det bruges mange steder - her er det fx sakset fra html.dk
(forsiden):

<div style="text-
align:center;position:absolute;top:90px;left:0px;width:100%;"
class="noprint">

> Eller endnu bedre, kan du finde det på w3c?

Bestemt:
<http://www.w3.org/TR/html401/present/styles.html#adef-style>

Det var muligvis forvirrende at jeg kaldte det "direkte styling" -
det er vist mere almindeligt at bruge termen "inline styling".
Problemet er bare at inline også kan dække over css-kode anbragt i
en <style>-blok.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

> Det bruges mange steder - her er det fx sakset fra html.dk
> (forsiden):
>
> <div style="text-
> align:center;position:absolute;top:90px;left:0px;width:100%;"
> class="noprint">

Jeg kan se, at du har en .noprint i
http://html.dk/site/stylesheets/print.default.css

Hvis den class nu ikke var der; Kunne man så forestille sig, at din inline
style stadig giver mening uden .noprint ?

> Bestemt:
> <http://www.w3.org/TR/html401/present/styles.html#adef-style>
>
> Det var muligvis forvirrende at jeg kaldte det "direkte styling" -
> det er vist mere almindeligt at bruge termen "inline styling".

Tak for det =)

> Problemet er bare at inline også kan dække over css-kode anbragt i
> en <style>-blok.

Så har jeg misforstået noget. Hvad kan det ellers være?

---

Martin wrote:
>> Det var muligvis forvirrende at jeg kaldte det "direkte styling" -
>> det er vist mere almindeligt at bruge termen "inline styling".
>
> Tak for det =)
>
>> Problemet er bare at inline også kan dække over css-kode anbragt i
>> en <style>-blok.
>
> Så har jeg misforstået noget. Hvad kan det ellers være?

Inline er egentlig udtrykket for en <style>blok anbragt i head men det
bruges også om en blok anbragt midt i dokumentet, hvilket Gyldenkærne
kalder direkte styling hvilket er en udmærket måde at skelne mellem dem
på.

Men I får det til at lyde som et meget uoverskueligt problem. Med
JavaScripts FileSystemObject er det muligt at konstruere en funktion der
gennemløber et helt websted finder alle CSS filer udtrækker alle
definitioner og efterfølgende gennemløber alle andre filer HTML, ASP,
PHP, INC, JS osv. for at se om definitionerne er blevet brugt. hvis de
er, markeres de som brugt og ellers slettes de.

Hvis alle brugte definitioner skrives til en samlet fil så kan alle CSS
filer slettes i samme arbejdsgang.

Samme princip kan bruges på inline styles og her kunne scriptet passende
udtrække brugte elementer og tilføje dem sidst i ovennævnte maskinelt
generede CSS fil, og fjerne inline blokken.

En ting der ikke har været nævnt er gentagne definitioner og som kan
være meget drilsk.

Hvis de samme stylesheets bruges på alle sider, kan man tage dem i den
brugte orden og sammenligne dem og smide ændrede definitioner væk
således at man har en samlet definition ved dokumentstart.

I et dokument vinder den sidste definition altid,
derfor skal definitioner der findes inde i et dokument sammenlignes med
den sidste i de inkluderede. og ren ny dokument specifik definition
dannes. Således at man på bestemte sider feks. formular sider eller
sitemaps, hvor man inline har overstyret de overordenede ark, ikke
mister funktionaliteten.

Det er er en større opgave ja, men det vil snildt kunne laves i
JavaScript uden brug af en server, Det vil faktisk kunne gøres via en
adminside direkte i browseren.

Med venlig hilsen
Johnny Winther Ronnenberg

--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

Johnny Winther Ronnenberg wrote:
> Inline er egentlig udtrykket for en <style>blok anbragt i head men det
> bruges også om en blok anbragt midt i dokumentet, hvilket Gyldenkærne
> kalder direkte styling hvilket er en udmærket måde at skelne mellem dem
> på.

Det er nu ikke rigtigt. Inline CSS er regler anbragt i style-attribut'en
på et element. Her er de tre muligheder:

Inline CSS er fx:
....
<body>
<p style="background-color:#666;margin:1em">Hest!</p>
</body>
....


Ekstern CSS er fx:
....
<head>
<link rel="stylesheet" type="text/css" href="screen.css" />
</head>
....
<p class="myClass"></p>
....



Intern CSS er fx:
....
<head>
<style type="text/css">
p{background-color:#666;margin:1em}
</style>
</head>
....
<p>Hest!</p>
....

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Jeppe Høiby wrote:
> Johnny Winther Ronnenberg wrote:
>> Inline er egentlig udtrykket for en <style>blok anbragt i head men
>> det bruges også om en blok anbragt midt i dokumentet, hvilket
>> Gyldenkærne kalder direkte styling hvilket er en udmærket måde at
>> skelne mellem dem på.
>
> Det er nu ikke rigtigt. Inline CSS er regler anbragt i
> style-attribut'en på et element. Her er de tre muligheder:
>
> Inline CSS er fx:
> ...
> <body>
> <p style="background-color:#666;margin:1em">Hest!</p>
> </body>
> ...
>
>
> Ekstern CSS er fx:
> ...
> <head>
> <link rel="stylesheet" type="text/css" href="screen.css" />
> </head>
> ...
> <p class="myClass"></p>
> ...
>
>
>
> Intern CSS er fx:
> ...
> <head>
> <style type="text/css">
> p{background-color:#666;margin:1em}
> </style>
> </head>
> ...
> <p>Hest!</p>
> ...

Jeg vil ikke påstå at vi er gevaldigt uenige, men Gyldenkærnes version
illustrererer faktisk tingene på en nemmerere forståelig måde. Vi skal
til stadighed huske på, at vi ikke befinder os i et unuvers for
programmører

Jeg må hellere dukke mig, for Gyldenkærne er på vej med et regexp

Med venlig hilsen
Johnny Winther Ronnenberg
--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

Johnny Winther Ronnenberg wrote:
> Jeg vil ikke påstå at vi er gevaldigt uenige, men Gyldenkærnes version
> illustrererer faktisk tingene på en nemmerere forståelig måde. Vi skal
> til stadighed huske på, at vi ikke befinder os i et unuvers for
> programmører

Hehe, det er rigtigt Men du skrev nu at inline CSS = <style
....>...</style> og det er det ikke, det er intern CSS, hvis jeg nu skal
fluekneppe (igen...)

> Jeg må hellere dukke mig, for Gyldenkærne er på vej med et regexp

Ja, for det gør så allerhelvedes ondt at få i nakken

---

On Thu, 13 Oct 2005 12:33:49 +0200, Jens Gyldenkærne Clausen
<jens@gyros.invalid> wrote:

>Det var muligvis forvirrende at jeg kaldte det "direkte styling" -
>det er vist mere almindeligt at bruge termen "inline styling".
>Problemet er bare at inline også kan dække over css-kode anbragt i
>en <style>-blok.

Plejer man ikke at kalde den sidste for "embedded"?
Det gør WDG i hvert fald i deres hjælpefil - eller her:
<url: http://www.htmlhelp.com/reference/html40/head/style.html>

Mvh. Jørn

--
Jørn Andersen,
Brønshøj

---

Martin skrev:

> Jeg kan se, at du har en .noprint i
> http://html.dk/site/stylesheets/print.default.css
>
> Hvis den class nu ikke var der; Kunne man så forestille sig,
> at din inline style stadig giver mening uden .noprint ?

De to ting har ikke noget at gøre med hinanden.

Her en en forsimplet udgave af koden fra før:

<div style="position:absolute;top:90px;width:100%;"
   class="noprint">

Inline-style er det der står i style-parameteren - altså
"position:absolute;top:90px;width:100%;".

Klassen "noprint" der også er tilknyttet, kan findes i en css-blok
eller i en ekstern css-fil - men den har ikke nogen tilknytning til
det der står i style-parameteren.


>> Problemet er bare at inline også kan dække over css-kode
>> anbragt i en <style>-blok.

> Så har jeg misforstået noget. Hvad kan det ellers være?

Der er grundlæggende tre måder at bruge css-kode på. De er
gennemgået udmærket på <http://html.dk/tutorials/css/lektion2.asp>
(brugen af @import er en variant af metode to).

Inline style svarer til metode 1 i html-tutorialen (altså med
style="..." i html-koden).

Uformelt skelnes der imidlertid ofte mellem css-kode placeret
direkte i et webdokument (sammen med html-koden) og css-kode
placeret i eksterne filer. Det er i denne sammenhæng at "inline"
nogle gange betyder metode 1 eller 2.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

> De to ting har ikke noget at gøre med hinanden.
>
> Her en en forsimplet udgave af koden fra før:
>
> <div style="position:absolute;top:90px;width:100%;"
>    class="noprint">
>
> Inline-style er det der står i style-parameteren - altså
> "position:absolute;top:90px;width:100%;".
>
> Klassen "noprint" der også er tilknyttet, kan findes i en css-blok
> eller i en ekstern css-fil - men den har ikke nogen tilknytning til
> det der står i style-parameteren.

Okay, så glemmer jeg alt om den.

Så burde jeg være klar.

Det jeg dog tror kommer til at genre mig, er at tage højde for

class="noget"
class = "noget"
class='noget'
class = 'noget'

> Der er grundlæggende tre måder at bruge css-kode på. De er
> gennemgået udmærket på <http://html.dk/tutorials/css/lektion2.asp>
> (brugen af @import er en variant af metode to).

Alletiders.

> Inline style svarer til metode 1 i html-tutorialen (altså med
> style="..." i html-koden).

Ok.

> Uformelt skelnes der imidlertid ofte mellem css-kode placeret
> direkte i et webdokument (sammen med html-koden) og css-kode
> placeret i eksterne filer. Det er i denne sammenhæng at "inline"
> nogle gange betyder metode 1 eller 2.

Det skal jo ikke være nemt =)

---

Jeppe Høiby skrev:

> Det er nu ikke rigtigt. Inline CSS er regler anbragt i
> style-attribut'en på et element.

Jeg er enig, men Johnnys indlæg demonstrerer også min tidligere
pointe - at inline nogen gange læses som det du kalder intern css.


> Ekstern CSS er fx:

> <link rel="stylesheet" type="text/css" href="screen.css" />

Er det eksternt fordi css-filen er ekstern, eller fordi der bruges
link?

Jeg spørger fordi jeg selv er i tvivl om hvad man så skal kalde
css-inkludering med @import. Syntaksangivelsen er det du kalder
intern, men css-koden ligger stadig i en ekstern fil.

> Intern CSS er fx:

> <style type="text/css">

Det er egentlig nogle meget gode betegnelser du bruger. Jeg tror
dog at jeg ville aflæse "intern" sådan at det både omfatter
<style>-blokke og inline-css - begge dele er placeret "internt" i
html-dokumentet.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen wrote:
> Jeg er enig, men Johnnys indlæg demonstrerer også min tidligere
> pointe - at inline nogen gange læses som det du kalder intern css.

Ja, du har helt ret.

> Er det eksternt fordi css-filen er ekstern, eller fordi der bruges
> link?

Heh... Det havde jeg egentlig ikke tænkt over. Jeg vil dog mene at det
er fordi CSS-definitionerne ligger i en ekstern fil.

> Jeg spørger fordi jeg selv er i tvivl om hvad man så skal kalde
> css-inkludering med @import. Syntaksangivelsen er det du kalder
> intern, men css-koden ligger stadig i en ekstern fil.

Ja, det har jeg faktisk slet ikke spekuleret over! Jeg ved faktisk ikke
hvad "import" kaldes, men jeg gætter på det også falder under kategorien
"ekstern".

> Det er egentlig nogle meget gode betegnelser du bruger. Jeg tror
> dog at jeg ville aflæse "intern" sådan at det både omfatter
> <style>-blokke og inline-css - begge dele er placeret "internt" i
> html-dokumentet.

Jeg vil lige skynde mig at sige at det ikke er betegnelser jeg selv har
fundet på. Jeg har set dem masser af steder i bøger og på forskellige sites.

Een grund til at man skelner mellem inline og intern er måske at der er
forskel på hvilken prioritet de har. Altså at inline 'overrider' intern
CSS? En anden grund sikkert blot at det er rart at vide at når nogen
taler om "inline CSS, så er det CSS sovset ind i HTML-elementer, og
intern ligger i head.

Forresten er det lovligt at placere <style...>...</style> i body, eller
*skal* den altid være i head?

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Den 13-10-05 22.40 skrev Jens Gyldenkærne Clausen følgende:

> Er det eksternt fordi css-filen er ekstern, eller fordi der bruges
> link?

Jeg vil sige, fordi det er eksternt.

> Jeg spørger fordi jeg selv er i tvivl om hvad man så skal kalde
> css-inkludering med @import. Syntaksangivelsen er det du kalder
> intern, men css-koden ligger stadig i en ekstern fil.

Eksternt. Hvis man endelig vil give det et eget navn, kunne man kalde
det et importeret stilark.

>>Intern CSS er fx:
>><style type="text/css">
>
> Det er egentlig nogle meget gode betegnelser du bruger. Jeg tror
> dog at jeg ville aflæse "intern" sådan at det både omfatter
> <style>-blokke og inline-css - begge dele er placeret "internt" i
> html-dokumentet.

Jeg skelner på samme måde som Jeppe - det gør Nvu for øvrigt også. Det
er vel også logisk, for et internt stilark svarer stort set til et
eksternt stilark, det er blot indsat samlet øverst i selve siden i
stedet for i en selvstændig fil. Inline stile er derimod spredt rundt
omkring på siden.

--
Mvh. Kim Ludvigsen
Få hjælp til at bruge de gratis anti-spywareprogrammer Ad-Aware, Spybot
og SpywareGuard.
http://kimludvigsen.dk

---

Martin skrev:

> Det jeg dog tror kommer til at genre mig, er at tage højde for
>
> class="noget"
> class = "noget"

Noget a la: class\s*=\s*["']?noget["']?

Det vil godt nok også matche skæverter som:
   class="noget
   class="noget'
   class = noget"
   class= noget'
   
- men det er ikke noget problem hvis brugen af anførselstegn ikke
er helt i skoven. Man kan også lave en reference til det først
matchede anførselstegn, men det kan jeg ikke lave i hovedet.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jeppe Høiby skrev:

> Een grund til at man skelner mellem inline og intern er måske
> at der er forskel på hvilken prioritet de har.

Ja - inline vil altid vægtes højere end al anden css-kode (med en
mulig undtagelse i bruger-css-ark).

En anden væsentlig forskel er at inline-kode altid kun påvirker ét
bestemt element - nemlig det de er sat ind i. I intern/ekstern css
er udgangspunktet at en selektor kan ramme flere elementer - om end
det ikke altid er tilfældet (fx body, #menu)

> rart at vide at når nogen taler om "inline CSS, så er det CSS
> sovset ind i HTML-elementer, og intern ligger i head.

Inline er css sovset ind *i* html-elementer, mens intern er css
stoppet ind *mellem* html-elementer


> Forresten er det lovligt at placere <style...>...</style> i
> body, eller *skal* den altid være i head?

Den må kun være i head.
(jf. <http://www.w3.org/TR/html401/present/styles.html#edef-STYLE>)
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen wrote:
> Inline er css sovset ind *i* html-elementer, mens intern er css
> stoppet ind *mellem* html-elementer

Ja, det er noget være rod...

> Den må kun være i head.
> (jf. <http://www.w3.org/TR/html401/present/styles.html#edef-STYLE>)

OK!

--
Med venlig hilsen
Jeppe Høiby
Web-udvikler
<http://awake.dk/>

---

Kim Ludvigsen skrev:

> Jeg skelner på samme måde som Jeppe - det gør Nvu for øvrigt
> også.

- er det ikke også dig der har oversat det?

> Det er vel også logisk, for et internt stilark svarer
> stort set til et eksternt stilark,

Ja - den fælles endelse "-ark" markerer fint at der er tale om en
samlet mængde css i modsætning til inline der er spredt rundt i
html-koden.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Den 14-10-05 11.12 skrev Jens Gyldenkærne Clausen følgende:
> Kim Ludvigsen skrev:
>
>>Jeg skelner på samme måde som Jeppe - det gør Nvu for øvrigt
>>også.
>
> - er det ikke også dig der har oversat det?

Er der nogen bedre at henvise til end en selv? Den engelske udgave
skelner dog på samme måde.

--
Mvh. Kim Ludvigsen
Gratis bridgeprogram, så du kan øve dig uden at blive udsat for
makkerens hvasse blikke og spark under bordet.
http://kimludvigsen.dk