Yritin tehdä sivuilleni IE:lle omia muotoiluja, mutta ne eivät jostain syystä toimi.
<!--[if lt IE 9]> <link rel="stylesheet" href="/(polku)/css/master.ie8.css" type="text/css" /> <![endif]-->
Olen tarkistanut, että kyseinen tiedosto sijaitsee tuossa osoitteessa, mutta siinä määritellyt muotoilut eivät vain toimi. Olen yliopiston koneella, jossa on IE8, joten tuon pitäisi tässä toimia. Kävin tutkailemassa IE:n Developer toolsia ja tuota kyseistä css-tiedostoa ei löydy css-osiosta ollenkaan. Eli tuota master.ie8.css tiedostoa ei siis löydy? Vaikuttaako tuo nimessä oleva piste jotenkin asiaan?
Pisteestä ei ole haittaa nimessä. Jos olet katsonut, että polku on oikea mutta tiedostoa ei löydy, niin silloinhan sitä ei ole. Kokeile tallentaa (tai siirtää FTP-ohjelmalla) tiedosto uudelleen paikalleen ja päivittää sivu CTRL + R näppäinyhdistelmällä.
Polku on oikea ja tiedosto on olemassa, mutta ei toimi. Kai se täytyy silti jommassakummassa olla vika, jota en vain kaikesta huolimatta ole huomannut.. Ongelma löytyy sivulta 4store.fi, jos sen paljastaminen auttaisi ongelman löytämisessä. Minulla ei nyt millään välähdä missä tuo vika on.
Kyllä tuo viittaus näyttäisi olevan ihan oikein. Ei nyt ole vanhaa IE:tä käsillä, mutta epäilisin lähinnä että tuo CSS-tiedoston sisältö on väärin.
En ruvennut sen enempää miettimään, mutta #content .readmore. #sidebar .readmore näyttää hämmentävältä.
Oho.. Tuon piti tietysti olla #content .readmore, #sidebar .readmore
Korjasin tuon, mutta ei toimi tästä huolimatta. IE:n Developer Tools ei tunnu löytävän tuota kyseistä master.ie8.css tiedostoa.
Kyllä se ainakin itsellä näkyy IE9:n kehittäjäkonsolissa CSS-lehdellä, jos valitsen browser modeksi IE8. IE9 browser modessa se ei luonnollisesti näy.
Kokeilepa muuttaa polkua:
<link rel="stylesheet" href="polku/css/master.ie8.css" type="text/css" />
Eli eka kauttaviiva pois....tyypillinen vanhempien IE-versioiden polkurakenne (vaikka IE8 ei vanha olekaan). Tuo polku toimii ainakin Firefoxissa.
En kyllä suoraansanottuna ymmärrä mitä tässä välissä tapahtui, mutta nyt tuo IE:n kehittäjäkontoli löytää master.ie8.css tiedoston molemmilla poluilla sekä ensimmäisen kauttaviivan kanssa että ilman. Vähän oli tiedostossa css:t pielessä, joten pientä muutosta piti tehdä jotta sain halutun tuloksen. Nyt tuo siis toimii juuri niin kuin halusinkin, vaikken tiedä mitä siinä tapahtui. Kiitoksia auttaneille. :)
pistemies kirjoitti:
tyypillinen vanhempien IE-versioiden polkurakenne
... mikä? Ihan samoja polkuja se IE käyttää kuin muutkin.
CSS-tiedostossasi on UTF8 Byte order mark. Ota se pois.
merri kirjoitti:
CSS-tiedostossasi on UTF8 Byte order mark. Ota se pois.
Mitäs se siellä haittaa? Kopsasin sen muistaakseni jostain toisesta css-tiedostosta, että ei ollut oma ideani sitä sinne laittaa. Otanpa sen poies.
Oletan vastauksesi perusteella, että ymmärsit väärin.
@charset "utf8"; saa olla, tosin siitä on hyötyä vain jos lisäät esimerkiksi contentin avulla sisältöä sivulle, jolla on käytössä UTF-8.
Byte order mark tarkoittaa, että tiedoston alussa on kolme tavua, jotka kertovat joillekin tekstinkäsittelyohjelmille, että tekstidata on UTF-8:aa. Sisällöllistä merkitystä noilla tavuilla ei ole (UTF-16 kanssa olisi), mutta ensinnäkin BoM on turha CSS:n kanssa (koska @charset) ja toisekseen se aiheuttaa ongelmia CSS-parsereissa, mm. IE ei tykkää siitä.
Sama juttu HTML-sivujen kanssa, BoM tiedoston alussa aiheuttaa ongelmia ja on suositeltavaa jättää se pois.
Merri, voitko mainita jonkin selaimen, joka jotenkin toimii väärin (miten? mille dokumentille), jos UTF-8-koodatun HTML- tai CSS-tiedoston alussa on BOM?
Tuntuu siltä, että tieto Netscape 4:n yms. ongelmista on jäänyt elämään omaa elämäänsä. Ja...
öA BOM – – can also serve as a hint indicating that the file is in Unicode, as opposed to in a legacy encoding and furthermore, it act as a signature for the specific encoding form used.ö
http://www.unicode.org/faq/utf_bom.html#bom2
Mahdollisesti HTTP-otsakkeissa on tieto koodauksesta (mutta ne eivät tallennu, kun tieto tallennetaan paikallisesti). Mahdollisesti CSS-tiedostossa on @charset-ilmoitus. Mutta BOM lienee silti useammin hyödyksi kuin haitaksi tällä vuosituhannella
AkeMake kirjoitti:
Ongelma löytyy sivulta 4store.fi, jos sen paljastaminen auttaisi ongelman löytämisessä.
Tosiasioiden paljastaminen on toki yleensä vain haitaksi, paitsi jos halutaan oikeasti ratkaista ongelmia. :-)
Tuolla sivulla on sen verran raskaasti merkkaus- ja muita virheitä, että on aika iso ihme, että se toimii mitenkään. Aloita laittamalla merkkaus edes muodollisesti kuntoon validaattorilla (sanoo nyt ö95 Errors, 111 warning(s)ö). Sitten voi alkaa toivoa, että CSS:n käyttö toimii, jos CSS-koodi itse on kunnossa, jne.
Suuri osa virheistä on toki trivialiteetteja (sivu väittää olevansa Strict vaikka ei ole, ö&ö on kirjoitettu sellaisenaan kun pitää olla ö&ö jne.), mutta oikeasti outoa on ainakin se, että style-elementin sisällä on ö<!--ö (joka XHTML:ssä tarkoittaa, että selain saa oikeasti käsitellä sisällön kommenttina) ja sen sisällä sitten on jotain ilmeisesti kommentiksi tarkoitettua...
"Enemmän hyödyksi kuin haitaksi tällä vuosituhannella" on aavistuksen huono sanavalinta. "Tällä vuosikymmenellä" olisi tarkempi. Vielä vuonna 2009 esimerkiksi Firefox suolsi BoMin merkkeinä HTML-sivun alkuun. Vastaavasti CSS-tiedoston alussa oleva BoM taas esti ensimmäistä tyylisääntöä toimimasta. En tiedä missä kohtaa tämä ongelma on korjattu, mutta nyt homma pelittää.
Nimenomaisesti siis tällä vuosikymmenellä tilanne on sitten kaikkien selainten osalta paljon parempi. Ainakaan Firefox, Chrome ja IE9 eivät kärsi CSS-tiedostossa olevasta BoMista, vaan ohittavat ne mukisematta. Sen sijaan HTML-tiedoston alussa oleva BoM on mielenkiintoinen tapaus! Roskaa sivun alussa ei näytetä, mutta myöskään BoMia ei noudateta. Jos palvelin ei kerro sivun merkistöä, niin sitten oletusmerkistö on iso-8859-1 ja sillä selvä. Oli BoM sivun alussa tai ei.
Suomeksi: BoM on yhtä tyhjän kanssa HTML-tiedostoissa.
Ja kun viimeks katoin, PHP:n include hajos BOMiin.
Tein tässä testejä myös CSS:n BoMin noudattamisesta, mutta törmäsin sellaiseen ongelmaan, että selaimet näyttävät olettavan CSS-tiedoston merkistöksi automaattisesti saman kuin mitä HTML-sivu käyttää. Keksin nyt vihdoin kuitenkin jotain: jos laitan sivun merkistöksi iso-8859-1, niin myös CSS:stä luotu sisältö näytetään iso-8859-1 mukaisesti, ei UTF-8:n mukaisesti (vaikka CSS-tiedostossa olisi BoM!). Vasta kun käytän @charsetiä, niin sitten sivun sisältö voi olla iso-8859-1, mutta CSS:stä generoitu sisältö näkyy UTF-8:n mukaisesti.
Eli BoM on yhtä tyhjän kanssa CSS-tiedostossa. Se vain ohitetaan, aivan kuten se ohitetaan HTML-tiedostossakin.
Ja PHP-tiedostoissa BoM tosiaan vaan sotkee asiat. Joko sivun sisältö tulee ennenaikaisesti tai sitten käy kuten Blaze sanoi. Eli parempi vaan antaa sen BoMin olla jossain muualla kuin interveppisivuilla, kun ei se oikeasti vaikuta mihinkään.
Sinänsä jos PHP:n tekijät haluaisivat, niin BOM voitaisiin huomioida skriptin alusta ja jättää lähettämättä kunnes sivua muuten aletaan lähettää selaimelle. Toki suoritusnopeuteen tulisi muutaman nanosekunnin ero.
Merri kirjoitti:
Vielä vuonna 2009 esimerkiksi Firefox suolsi BoMin merkkeinä HTML-sivun alkuun.
Olen löytänyt netistä vuodelta 2009 peräisin olevia väitteitä siitä, että Firefox toimisi niin. Ei niissäkään yksilöity versionumeroa vaan viitattiin joihinkin monen vuoden takaisiin sivuihin – joilla on samanlaisia ylimalkaisia väitteitä.
Pikainen Bugzillan silmäily vahvistaa käsitystä siitä, että kyseessä on jonkinlainen myytti, verrattavissa varoituksiin siitä, ettei pidä kirjoittaa ääkkösiä suoraan vaan ä-tyyliin. Tällä vuosituhannella esitetyissä bugiraporteissa, joissa BOM mainitaan, näyttää kyseessä olevan joko havaintojen väärintulkinta tai sentapainen virhe, että koodaukseksi on HTTP-tasolla ilmoitettu iso-8859-1.
lainaus:
Nimenomaisesti siis tällä vuosikymmenellä tilanne on sitten kaikkien selainten osalta paljon parempi.
Kysymys on kai siitä, onko yhdessäkään nykyisin käytössä olevassa selainversiossa sellaista BOM-ongelmaa, josta traditio pelottelee.
lainaus:
Sen sijaan HTML-tiedoston alussa oleva BoM on mielenkiintoinen tapaus! Roskaa sivun alussa ei näytetä, mutta myöskään BoMia ei noudateta. Jos palvelin ei kerro sivun merkistöä, niin sitten oletusmerkistö on iso-8859-1 ja sillä selvä. Oli BoM sivun alussa tai ei.
Jos palvelin ei kerro sivun merkistöä, selain käyttää meta-tägissä olevaa tietoa. Senkin puuttuessa selain soveltaa omaa heuristiikkaansa, joka tietysti voi johtaa eri selaimissa eri tulokseen.
Mutta katsotaanpa:
http://www.cs.tut.fi/~jkorpela/chars/bom.htm
http://www.cs.tut.fi/~jkorpela/chars/nobom.htm
Erona on, kuten nimistä voi arvata, että edellisessä on BOM alussa, toisessa ei. En ole hirveän yllättynyt siitä, että selaimet tulkitsevat BOM-version utf-8-koodatuksi.
lainaus:
Suomeksi: BoM on yhtä tyhjän kanssa HTML-tiedostoissa.
Olet siis muuttanut mieltäsi etkä enää väitä, että öBoM tiedoston alussa aiheuttaa ongelmiaö.
Merri kirjoitti:
Vielä vuonna 2009 esimerkiksi Firefox suolsi BoMin merkkeinä HTML-sivun alkuun.
Hirveästi haittaahan tuosta ei olisi, koska se BOM-merkki on Unicode 0xFEFF eli "zero width no-break space". Eli siis, vaikka siinä alussa on se merkki, niin sitä ei voi nähdä ellei tarkastele merkkejä kooditasolla.
Ongelmia tulee ehkä tilanteissa, joissa tehdään Unicode-tiedostoja vaikka palvelin ei osaa lähettää niitä unicode-tiedostoina. Silloinhan oikea tapa olisi tallentaa tiedostot siinä muodossa, jossa palvelin niitä lähettää. Esim. iso-8859-1, jolloin mikään editori ei myöskään tallenna BOMia alkuun.
Eli summa summarum, mitään ongelmaa ei ole, paitsi se, että ihmiset jotka ei osaa käyttää tietokoneita tekee sivuja.
Yucca: sattuneesta syystä en voi enää testata helposti IE6, IE7 ja IE8, joissa muistelen noita ongelmia olleen (sen lisäksi että on tuo yllä mainittu vanhentunut Firefox-ongelma). IE9 ei kelpaa testikoneistoksi, koska sen toiminta voi poiketa tämänkaltaisissa pienissä yksityiskohdissa.
Nyt kuitenkin tein huomion, että nykyään tiedostojen lähettämiseen käyttämäni ohjelma (WinSCP) tekee itsenäisiä ajatelmia ja pudottaa kaikista lähetetyistä tiedostoista BOMin automaattisesti pois. Kyseistä ominaisuutta ei ole missään asetuksissa näkyvillä, joten selvisipähän tämmöinenkin asia nyt, ja muuttaa tietysti asioita kun tekemissäni testeissä on tietämättäni BOM pudotettu pois.
Jäljelle jää toki viralliset suositukset, ja HTML5:ssä edelleen suositellaan UTF-8 signaturen (eli BOMin) pudottamista pois käytöstä UTF-8 -sivuilla. Valitettavasti sivu ei täsmennä, millä selaimilla ongelmia on. Tuo sivu on kirjoitettu syyskuussa 2010, joten jos haluaa vaikuttaa nykytilanteeseen niin asian voi nostaa pöydälle ja kyseenalaistaa W3C:n puolella.
CSS-tiedostoissa BOM näyttää aiheuttavan nykyään eniten ongelmia optimointikoneistoissa, jotka yhdistävät kaikki CSS-tiedostot yhteen. Näitä ominaisuuksia löytyy mm. sekä Apachen moduuleista (mod_pagespeed) että CMS-järjestelmistä (Drupal).
Ja mitä tulee mielipiteisiini, niin mielipiteeni sentään kehittyy sitä mukaa, mitä enemmän tietoa saan, enkä jankkaa yhtä ja samaa kuin mikäkin kiviaivo.
Merri kirjoitti:
Yucca: sattuneesta syystä en voi enää testata helposti IE6, IE7 ja IE8
Mikäköhän se sattunut syy on? Anyways, kokeilin nyt IE versiolla 6.0.2900.5512.xpsp_sp3_gdr.101209-1647 ja BOM html-tiedoston alussa ei aiheuttanut mitään ongelmaa.
W3C:n sivuilla sanottiin "This used to be a problem for static HTML files, but is no longer in recent versions of major browsers".
Eli yhteenvetona, jos sivua tekee IE6:sta vanhemmille selaimille, niin ongelma on hyvä pitää mielessä.
No jos se olennaista on: hankin kesällä SSD:n, joten asensin pöytäkoneen uusiksi sitä ajatellen. En ole asentanut Virtual PC:tä uusiksi, enkä taida viitsiäkään. "Retroläppärini" taas on tällä hetkellä osina, koska pöytäkoneeni kovalevy hajosi ja tuli kiire löytää levyjä, jonne varmuuskopioida kaikki toimivat tiedostot talteen ennen kuin bad sectorit tuhosivat levyn täysin käyttökelvottomaksi.
Merri kirjoitti:
Jäljelle jää toki viralliset suositukset,
Siltä osin kuin on selvinnyt, että ne perustuvat vanhentuneeseen tietoon, niitä ei kannata ottaa kovin vakavasti.
Merri kirjoitti:
ja HTML5:ssä edelleen suositellaan UTF-8 signaturen (eli BOMin) pudottamista pois käytöstä UTF-8 -sivuilla.
Eihän tuo linkittämäsi sivu ole HTML5-aineistoa lainkaan, ei myöskään suositus (kuten ei HTML5:kään). Se on vain Richard Ishidan tekemä sivu. Ishida on kyllä W3C:n eksperttejä, mutta hänen sivunsa eivät ole W3C:n kannanottoja. Ja sivu muuten viittaa toiseen sivuun, jossa olennaisesti sanotaan, että BOM ei ole ongelma
Merri kirjoitti:
Valitettavasti sivu ei täsmennä, millä selaimilla ongelmia on.
Ei, koska sekin toistaa vuosia vanhoja käsityksiä. Ei mitenkään ainutlaatuista.
Merri kirjoitti:
Tuo sivu on kirjoitettu syyskuussa 2010, joten jos haluaa vaikuttaa nykytilanteeseen niin asian voi nostaa pöydälle ja kyseenalaistaa W3C:n puolella.
Ishidan pöytä taitaa olla aina täynnä muutenkin. Saattaa jopa olla, että siellä on myös minun lähettämäni huomautus jostain tällaisesta (en aina muista kaikkea palautetta, mitä lähetän).
Merri kirjoitti:
CSS-tiedostoissa BOM näyttää aiheuttavan nykyään eniten ongelmia optimointikoneistoissa, jotka yhdistävät kaikki CSS-tiedostot yhteen.
Ohjelmistot, jotka eivät selviä sellaisesta, eivät taida ylipäänsä olla kovin valmiita käsittelemään muuta kuin Ascii-dataa. Tätä ei kuitenkaan pidä sekoittaa kysymykseen siitä, saako webissä olevassa HTML- tai CSS-tiedostossa syytä käyttää BOMia.
Merri kirjoitti:
Oletan vastauksesi perusteella, että ymmärsit väärin.
Niin näköjään ymmärsinkin. Enpä ole ennen kuullut tuosta BoM:sta enkä kyllä vieläkään täysin ymmärtänyt mikä se on. Merri kyllä selitti sitä, mutta se ei oikein auennut minulle. En tajua miten näen tiedostoista onko niiden alussa tuota BoMia ja miten sen voi poistaa? Enpä oikein saanut kiinni tämän BoM-keskustelun punaisesta langasta. Päädyttiinkö tässä minun tapauksessani nyt siis siihen, että BoM on tärkeä pitää mukana, turha, mutta harmiton vai haitallinen ja pitäisi poistaa?
Grez kirjoitti:
Eli yhteenvetona, jos sivua tekee IE6:sta vanhemmille selaimille, niin ongelma on hyvä pitää mielessä.
:D Niin yllättävää kuin se onkin, en aio koodailla sivujani IE6 vanhemmille selaimille.
Yucca kirjoitti:
Tuolla sivulla on sen verran raskaasti merkkaus- ja muita virheitä, että on aika iso ihme, että se toimii mitenkään. Aloita laittamalla merkkaus edes muodollisesti kuntoon validaattorilla (sanoo nyt ö95 Errors, 111 warning(s)ö). Sitten voi alkaa toivoa, että CSS:n käyttö toimii, jos CSS-koodi itse on kunnossa, jne.
En kyllä suostu ottamaan syitä niskoilleni noista virheistä, koska ne eivät periaatteessa ole minun virheitäni.
68 virhettä ja 105 varoitusta tulee sivustolla olevista facebookin suosittele-napeista. Kyseinen koodinpätkä on facebookin antama ja virheet ovat lähinnä "there is no attribute src/scrolling/frameborder...", joita en oikein voi poistaakaan. Moni noista herjoista on kyllä sitä, että "&" pitäisi olla "&", mutta tällekin löytyy selitys. Sivusto toimii MyCashflow:n alla ja jostain syystä tuo verkkokauppaohjelma muuttaa jo heti tiedostoon "&" yms. vastaaviksi merkeiksi, jolloin ne näkyvät sivuilla sitten valmiina merkkeinä. En voi siis asialle mitään.
10 virhettä ja 5 varoitusta tulee etusivulle upotetusta youtube-videosta. Siinä virheet ja varoitukset ovat samaa tyyppiä kuin facebookin suosittele-napeissakin: "there is no attribute..." ja "&" pitäisi olla "&".
11 virhettä tulee tuotteille laittamistani juuri Yuccan ohjeistamista Product-metatietomäärittelyistä. Helpottaisikohan yhtään, jos muuttaisi pelkän itemscope muotoon itemscope="itemscope"?
Loput 6 virhettä ja 1 varoitus tulee toiselta sivustolta palveluntarjoajan sekaan tyrkkäämän koodinpätkän vuoksi. Haen osan tuon sivuston koodeista verkkokauppaohjelman tarjoamien tagien avulla eräältä omalta ilmaissivustoltani. Valitettavasti sivu on juuri ilmainen ja sen vuoksi palveluntarjoaja heittää jokaisen sivun loppuun oman scriptinsä (ja näin tulee jokaisen haun mukana 4store.fi sivulle), joka aiheuttaa kaikki nuo loput ongelmat. Valitettavasti en voi hakuni yhteydessä myöskään karsia tuota scriptiä pois, sillä verkkokauppaohjelma ei hyväksy mitään muuta kuin html, css ja js tiedostoja, joten haku ottaa sokeasti koko sivun sisällön mukaansa palveluntarjoajan ylimääräisine scripteineen.
Yucca kirjoitti:
mutta oikeasti outoa on ainakin se, että style-elementin sisällä on ö<!--ö (joka XHTML:ssä tarkoittaa, että selain saa oikeasti käsitellä sisällön kommenttina) ja sen sisällä sitten on jotain ilmeisesti kommentiksi tarkoitettua...
Tuo tulee juuri siitä, että haen css-koodia toiselta sivulta ja sen sivun palveluntarjoaja heittää mukaan omia scriptejään, joita en saa karsittua pois. Ongelma korjaantuu, kun joskus tulevaisuudessa voin siirtää sen toisen sivun eri palveluntarjoajalle, joka ei heittele joka sivulle omia scriptejään.
Noista virheistä -> Bugirapsaa paskan tekijöille. Facebookin kötöstykset voit varmaakin vaikka itse korjata ilman että se haittaa toiminnallisuutta.
Miksi ihmeessä haet CSS-koodia toiselta sivulta niin, että tulos on moskaa? Voithan kirjoittaa haluamasi CSS-koodin vaikka oman sivusi sisälle.
Jos käytät itemscope-määritettä, ei kannata väittää sivun olevan HTML 4.01:tä, kun se ei sitä ole
Grez kirjoitti:
Bugirapsaa paskan tekijöille.
Tuskinpa Facebook ja Youtube paljon hetkahtavat, jos jotain heille kirjoitan. Entäs Product-metatieto.. Eikös tuo ollut Googlen määrittelemä vielä epävirallinen juttu? Ja tuossa ilmaispalvelimen tapauksessa en usko, että ottavat scriptinsä pois sivuilta, vaikka kuinka kauniisti sitä pyytäisin. Pitää vain odottaa, että voin siirtää tuon sivun paremmalle palveluntarjoajalle. Näistä verkkokauppaohjelman automaattisisti merkkien muunnoksista voin kyllä lähettää jotain kysymystä.
Yucca kirjoitti:
Miksi ihmeessä haet CSS-koodia toiselta sivulta niin, että tulos on moskaa? Voithan kirjoittaa haluamasi CSS-koodin vaikka oman sivusi sisälle.
Melkein osasin arvata, että joku kysyy tätä. Jos kirjoittaisin tuon tietyn css-koodin sivun sisään, se olisi kaikilla sivuilla vakio. Tässä tapauksessa sen pitää kuitenkin olla muuttuva. Koska tavalliset tuotelaatikot on kellutettu vasemmalle ja ne ovat eri korkuisia riippuen kunkin laatikon sisällöstä, pitää sopivin väliajoin asettaa clear: left;, jotta tuotteet asettuvat nätisti kolmen tuotteen riveihin. Tietyissä kategorioissa tietyt tuotteet haetaan ensimmäiseksi leveämpinä tuotelaatikoina (päätuotteet). Tämän vuoksi clear: left; pitää asettaa eri kategoriassa eri kohtaan, jotta tuotteiden sulava rivitys toimii joka sivulla. Vrt. kategorioita "Voimatoimi kahvakuulapuoti", "Gymstick sisäliikunta" ja "Gymstick ulko- ja vesiliikunta".
Yucca kirjoitti:
Jos käytät itemscope-määritettä, ei kannata väittää sivun olevan HTML 4.01:tä, kun se ei sitä ole
En mielestäni ole näin väittänytkään. Eikös sivu ole XHTML 1.0 Strict? Mikä sen sitten pitäisi olla itemscopea käytettäessä?
AkeMake kirjoitti:
Yucca kirjoitti:
Miksi ihmeessä haet CSS-koodia toiselta sivulta niin, että tulos on moskaa? Voithan kirjoittaa haluamasi CSS-koodin vaikka oman sivusi sisälle.
Melkein osasin arvata, että joku kysyy tätä. Jos kirjoittaisin tuon tietyn css-koodin sivun sisään, se olisi kaikilla sivuilla vakio.
Tuo ei vastaa siihen, miksi haet koodia niin että tulos on moskaa; kirjoitit: ösen sivun palveluntarjoaja heittää mukaan omia scriptejään, joita en saa karsittua poisö. Miksi siis et tee omaa CSS-tiedostoasi ja käytä sitä?
lainaus:
Yucca kirjoitti:
Jos käytät itemscope-määritettä, ei kannata väittää sivun olevan HTML 4.01:tä, kun se ei sitä ole
En mielestäni ole näin väittänytkään. Eikös sivu ole XHTML 1.0 Strict? Mikä sen sitten pitäisi olla itemscopea käytettäessä?
XHTML 1.0 on elementtien ja määritteiden nimien osalta sama kuin HTML 4.01, eli yhtä lailla itemscope yms. on määrittelemätön siinä. Ja ei, sivu ei ole lähelläkään XHTM 1.0 Strictiä, kuten mainittu; miksi sivu väittää olevansa Strict vaikka kuvauksesi mukaisesti tiedät, että siellä on Strictiin kuulumattomia asioita.
Koska itemscope on vasta HTML5:ssä määriteltävä asia, olisi aika luonnollista käyttää HTML5-doctypeä.
Aihe on jo aika vanha, joten et voi enää vastata siihen.