---

Hej,

Hvordan plejer I at "styre" det med at lave media-specifikke
stylesheets?
Så vidt jeg kan se, er der mindst flg. måder at lave dem på. Spm. er
om nogen af dem er at foretrække frem for andre?

1.
<link ... base.css>
<link ... print.css ... media="print">
<link ... screen.css ... media="screen">
- altså et basis-stylesheet og så media-specifikke tilføjelser.

2.
<link ... mycss.css>
Det hele i samme stylesheet - og så @media til at skille de mere
specikke regler ud

3.a.
<link ... print.css ... media="print">
<link ... screen.css ... media="screen">
Det hele i hver sit stylesheet.

Har den ulempe, at man skal huske at opdatere i begeg, hvis det er
"basis"-regler, der skal ændres.

3.b.
<link ... print.css ... media="print">
<link ... screen.css ... media="screen">
- ditto, men hvor man så laver @import fra en base.css

Den ser ud til at give en uspecificeret valideringsfejl hos W3C (måske
validator-fejl?).

Foreløbig er jeg landet på løsning 1 - andre bud?

Mvh. Jørn

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

---

Jørn Andersen wrote:
> Hej,
>
> Hvordan plejer I at "styre" det med at lave media-specifikke
> stylesheets?

<link ... main.css>
<link ... print.css ... media="print">

Det skulle kunne gøre det i de fleste tilfælde.

Man kan så overveje at tilføj specielle css til handheld (eks.
mobiltelefoner) og aural (talesyntese).

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

---

Jørn Andersen skrev:


> Hvordan plejer I at "styre" det med at lave media-specifikke
> stylesheets?

Model 1:

> - altså et basis-stylesheet og så media-specifikke
> tilføjelser.


Jeg kan godt lide at have tingene adskilt i separate filer. Det
giver også browseren mulighed for at skippe et print-ark indtil det
skal bruges (jeg ved dog ikke om den mulighed bliver udnyttet).


> 3.b.
> <link ... print.css ... media="print">
> <link ... screen.css ... media="screen">
> - ditto, men hvor man så laver @import fra en base.css
>
> Den ser ud til at give en uspecificeret valideringsfejl hos
> W3C (måske validator-fejl?).

Må vi se et eksempel på en side der giver fejlen?


--
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 kan godt lide at have tingene adskilt i separate filer. Det
> giver også browseren mulighed for at skippe et print-ark indtil det
> skal bruges (jeg ved dog ikke om den mulighed bliver udnyttet).

Det er min erfaring, at print.css indlæses sammen med siden - uden at man
har bedt om udskrift. Dette er jeg kommet frem til ved at iagttage, at
ændringer i print.css ikke tager effekt, før siden er blevet reloaded.

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

---

Erik Ginnerskov skrev:

> Det er min erfaring, at print.css indlæses sammen med siden -
> uden at man har bedt om udskrift. Dette er jeg kommet frem til
> ved at iagttage, at ændringer i print.css ikke tager effekt,
> før siden er blevet reloaded.

Der er også en vis logik i den opførsel. Hvis browseren ventede med
at hente printarket, skulle den lave et nyt request når man vælger
print - og det ville kunne forsinke udprintningen.

Det eneste en browser med rimelighed kan gøre når den støder på et
link til en print-css-fil, er at sætte den "bagerst i køen" af
objekter der skal hentes. Men jeg tror at gevinsten ved en sådan
operation er så lille at det ikke kan betale sig at bruge tid på at
implementere den.
--
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:

>>Det er min erfaring, at print.css indlæses sammen med siden -
>>uden at man har bedt om udskrift. Dette er jeg kommet frem til
>>ved at iagttage, at ændringer i print.css ikke tager effekt,
>>før siden er blevet reloaded.
>
>
> Der er også en vis logik i den opførsel. Hvis browseren ventede med
> at hente printarket, skulle den lave et nyt request når man vælger
> print - og det ville kunne forsinke udprintningen.
>
> Det eneste en browser med rimelighed kan gøre når den støder på et
> link til en print-css-fil, er at sætte den "bagerst i køen" af
> objekter der skal hentes. Men jeg tror at gevinsten ved en sådan
> operation er så lille at det ikke kan betale sig at bruge tid på at
> implementere den.

Alle URL'er specificeret i sidens kode forsøges hentet.

Den letteste måde at få dette bekræftet på er at kigge i serverens weblog.

--

venlige hilsener...

Philaweb


MacOS X 10.4.2 server ~ Mini Mac - siden 15. september 2005.

---

On Thu, 15 Sep 2005 12:17:51 +0200, "Jens Gyldenkærne Clausen"
<jens@gyros.invalid> wrote:

>Jeg kan godt lide at have tingene adskilt i separate filer. Det
>giver også browseren mulighed for at skippe et print-ark indtil det
>skal bruges (jeg ved dog ikke om den mulighed bliver udnyttet).

Det er også det, der tiltaler mig mest - mest for at jeg selv nemmere
kan styre det.

>> 3.b.
>> <link ... print.css ... media="print">
>> <link ... screen.css ... media="screen">
>> - ditto, men hvor man så laver @import fra en base.css
>>
>> Den ser ud til at give en uspecificeret valideringsfejl hos
>> W3C (måske validator-fejl?).
>
>Må vi se et eksempel på en side der giver fejlen?

Tilsyneladende kan jeg ikke fremprovokere fejlen igen.
Men den *var* god nok: Hvis jeg byttede rundt på de to <link
....>-linier, viste fejlen sig altid på den nederste af de to - og på
den linie, hvor der stod '@import url(base.css)' (også når jeg indskød
en ekstra tom linie før for at være sikker ...).

Nå, never mind - selv om det altid er irriterende at have uløste
problemer

Mvh. Jørn

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

---

philaweb skrev:

> Alle URL'er specificeret i sidens kode forsøges hentet.

Ja, det er også hvad jeg har kunnet teste mig til.

> Den letteste måde at få dette bekræftet på er at kigge i
> serverens weblog.

Smag og behag. Jeg klarer mig fint med LiveHTTPheaders til Firefox
eller pakkesnifferprogrammet Ethereal.
--
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

---

Jørn Andersen skrev:

> Foreløbig er jeg landet på løsning 1 - andre bud?

Alle medier i samme fil ligesom beskrevet under punkt 7.2.1 her:
http://www.w3.org/TR/REC-CSS2/media.html


--

venlige hilsener...

Philaweb


MacOS X 10.4.2 server ~ Mini Mac - siden 15. september 2005.