Sivujen optimointi näytön resoluution mukaan

Ihan vaan tiedoksi, että nykyisin käyttämäni teema on suunniteltu johdannossa mainittu laite huomioiden.

Sivujen leveyssuuntainen huomiointi on lopetettu 1280 kohdalla.


Pystyisin tietokoneellani ottamaan huomioon<em> iPad 9,7</em>:n pystysuuntaan laitettuna (tällöin pikselimäärä on 1536). Samoin pystyisin suunnittelemaan sivut 2K-näytölle laite pystysuuntaan laitettuna. Jälkimmäinen toimisi myös suht. hyvin <em>iPad Pro 10,5</em> kanssa, jossa pikselimäärä on laite pystysuuntaan laitettuna 1668px.

Ongelmana on se, että tablet-laitteella/älykännykkä voi sivuja katsoa myös laite vaakasuunnassa. Minulla ei ole mitään mahdollisuuksia huomioida em. laitteita laitteen vaakasuuntaan asetettuna.
Pitäisikö laittaa muistutus, että pidä laite pystysuunnassa?

Jos fonttikoot ja kaikki muut olisi optimoitu pystysuuntaan laittamista ajatellen, vaakasuuntaan laitteen laittaminen muuttaisi tilannetta radikaalisti.

Minä en voi muuta kuin arvata, mikä olisi järkevää. Joillakin Android-laitteilla näyttö on 1900px. Voisin vain arvata, mikä olisi hyvä 1900px tai sitä suuremmille näyttöresoluutioille.

Kannattaako siis yrittää luoda iPad 9,7, 2K-laitteiden ja iPad Pro 10,5:n pystynäytöt huomioivaa leiskaa?

Jos haluaa häätää ihmisiä www-sivuiltaan niin siitä vaan optimoimaan sivujaan jollekin tetylle resoluutiolle.

Vinkki
Kumpi on fiksumman näköinen ?

Tämä: https://i.postimg.cc/pXy5NcDt/800x500-007.png
vai tämä: https://i.postimg.cc/7PKJWrJV/800x500-008.png

En nyt oikein ymmärrä, miten noi kuvakaappaukset on tehty, joten en osaa kommentoida. En ymmärrä, miten toisessa vain otsikon fonttikoko on eri.

Kokeilin äsken iPad 9,7, 2K ja iPad Pro laite pystyyn laitettuna - suunnittelua tällä säännöllä:

@media screen and (min-width:1520px) and (max-width:1668px)

ja testasin tällä sivulla:
https://www.sanaristikkofoorumi.net/wordpress/forums/forum/sanaristikot/suomen-kuvalehti/

Sain mittasuhteet oikein, mikä on varsin hankalaa. Kaikki aiemmat @media screen and (min-width:XXX) määrittelyt sotkevat suunnittelua. Ne vaikuttavat taustalla ja kaikki edeltävät muutokset pitää ottaa huomioon.

Tällä CSS:llä ei ole mitään vaikutusta:

body.bbpress form#new-post fieldset.bbp-form p label,
body.bbpress form#new-post fieldset.bbp-form legend,
body.bbpress form#new-post fieldset.bbp-form textarea.bbp-the-content {
font-size: 11px !important;
}

jos haluaa hallita fonttikoot resoluution mukaan, noita(kin) pitäisi pystyä hallitsemaan.

Otsikkoa ei voi tuolla lailla jakaa koskematta PHP-koodiin.
Alaotsikko tulisi normaalisti vasemmanpuoleiseen palkkiin, mutta se ei ole yleensä esillä.
Alaotsikkoa ei siten voi käyttää.

Otsikon muotoilua ei voi muuttaa kuin fonttikoon osalta.

Suurin ongelma tässä on mainitsemani tiettyjen fonttien koko.

Nostin fonttikokon iPad 9,7:lle 15px, MUTTA kun se ei vaikuta aiemmin mainittuihin kaikista pienimpiin fonttikokoihin. Niistä tulee iPad 9,7:ssa ja sitä paremmissa laitteissa aivan mahdottomia lukea ilman sivun suurentamista.

Leiska on tehty niin, että maks. ajateltu koko on mainitsemani 800x1280 näyttö. Sitä isommissa tietyt fonttikoot ovat ihan mahdottoman pieniä.

Ei kellään olisi iPadia tai jotain korkearesoista muuta tablet-laitetta.

Fonttikoot on muuten melko OK, paitsi

Avainsanat:


Ilmoita vastauksista sähköpostilla

jäävät naurettavan pieniksi. Ja orientaatiota vaihdettaessa ero on suuri!

Olikohan tuossa järkeä?

*piip*

Syy fonttiongelmiin on siinä, että laitettu lomakkeiden yhteyteen

link rel='stylesheet' id='dashicons-css' href='https://www.sanaristikkofoorumi.net/wordpress/wp-includes/css/dashicons.min.css?ver=5.0' type='text/css' media='all'
link rel='stylesheet' id='editor-buttons-css' href='https://www.sanaristikkofoorumi.net/wordpress/wp-includes/css/editor.min.css?ver=5.0' type='text/css' media='all'

Selain siis lukee nuo aina viimekseksi.

sori, sain muutettua - lisäsin vielä yhden elementtitason.

body.bbpress div.bbp-topic-form form#new-post fieldset.bbp-form p label,
body.bbpress div.bbp-topic-form form#new-post fieldset.bbp-form legend,
body.bbpress div.bbp-topic-form form#new-post fieldset.bbp-form textarea.bbp-the-content {
font-size: 15px !important;
}

nostin perusfonttikoon 17px.

Millä periaatteella selain pistää valikon kasaan? Se vaihtelee teemoittain, mutten tiedä, mikä määrittää vaihtumisen.

Kun olin työelämässä ja tein www-sivuja, ilmiötä ei silloin ollut olemassa.

Yritin vähän tutkia asiaa. W3C:n mukaan niissä on mukana CSS:n ohella hieman JavaScriptiä. Lienevät toimivan samaan tapaan kuin sivustoni oikean yläkulman hakulomakkeet, mutta mukana on leveystarkistus.

https://www.w3schools.com/howto/howto_js_collapsible.asp

Optimointi niin että toimii Chrome, Edge, Firefox, Firefox ESR ja Safari selaimilla, kaikilla alle 4v ikäisillä laitteilla ja kaikilla näyttökokoluokilla taskukoosta 4K ruutuihin.

Ei missään nimessä mitään pikselimittoja missä ei tarvitse.

Sivut voi tehdä skaalautumaan, sitä varten on erilaisia UI-frameworkkeja kuten vaikka Bootstrap.

En yritäkään kaikilla selaimilla. Selamet tulee päivittää säännöllisesti. Uusien Android-laitteiden mukana tulee kunnon selain. Safarilla en voi luottaa muuhun kuin W3C:n taulukoihin, mikä missäkin laitteissa on tuettu. Firefoxin tiedän entuudestaan tukevan hyvin CSS:ää ja luotan siihen, että näyttää suurin piirtein samoin kuin Chrome.

Käytän leiskaa, joka lähtökohtaisesti on suunniteltu skaalautumaan portaittain CSS:n avulla. Esillä on yksi, kaksi tai kolme rinnakkaista aluetta. Jos ei mahdu rinnalle, laitetaan peräkkäin.

En perusideaa lähtenyt muuttamaan vaan sopeutin omat muutokseni leiskan perusideaan. Uudet WordPress-leiskat on tehty tällä periaatteella.

Itse asiassa lisäsin siihen jatkoa, jotta fonttikoot olisivat miellyttäviä korkearesoluutioisessa näytössä.

Esim. Matkapuhelinfoorumi toimii yksinkertaisemmin. Ongelmana on, että fonttikoko ei ole järkevässä suhteessa näytön kokoon nähden.

Tein HD-näytölle ja 2K näytölle määrityksen, jossa fonttikoko on järkevä suhteessa käytettyyn leveyteen. Näin siis silloin, kun laitteita pidetään pystyasennossa.

Vaakasuuntaan siirryttäessä fonttikoko pienenee rajun puoleisesti, koska 2500px näyttö käyttää fontteja, jotka on suunniteltu 1280 px. laitteille. Myös toinen puoli näyttöä jää tyhjäksi.

Jos näin ei ole, käyttäjä joutuu jatkuvasti skaalaamaan sivua, että teksti on kunnolla luettavaa.

Katsoin tämän sivun käännepistettä. Näemmä vain yksi alle 800px valikot menevät kasaan (kuten minullakin).

Täysleveällä näytöllä sama fonttikoko. Jos on 800x1280 laite, sivuilla on kaikki olennainen ja aika sopivan kokoiseksi.

Jos. näyttö on 1600px, fonttikoko on sama, minkä täytyy näyttää varsin pieneltä 2K tablet-laitteessa.

Tälläkin sivustolla fonttikoon pitäisi elää näytön pikselimäärän mukaan.

Kokeilin 70% pienennyksellä ja laittamalla ikkunan iPad 9,7 leveydelle. Olisi tämä sivusto kuten omanikin luettavissa iPadilla ilman fontin suurentamista. Kännykkäkoossa olisi kyllä aika tihrua.

Ehkä se fonttikoon kasvatus ei ole tarpeen kuin kännyköille.

Turpo-Urpo-1:lle

iPad ..............................768x1024

eikös iPad ole n. 1500x2000

iPad Pro .....................1024x1366

eikö iPad Pro ole n. 1700x2700

Outo juttu tuo iPad Pro - mielestäni näytit pystysuuntaan.

Yritin laittaa tällä määrittelyllä ison fontin iPad 9,7:lle ja iPad Prolle:


/* iPad 9,7; 2K ja iPad Pro pystyoptimointi 1520-1668 */
@media screen and (min-width:1520px) and (max-width:1668px)

tuossa on 17px fonttikokomääritys. 1600px tietokonenäytöllä näytti tosi isolta ja arvioin, että näyttäisi sopivalta iPadeilla & 2K-laitteilla kun laitteita käytetään pystysuunnassa.

En ymmärrä, mikä mättää.

iPad ..............................768x1024


iPad Pro .....................1024x1366

Jos olet laittanut pienennettyyikkunaan, noilla leveysarvoilla iPadeissa teksti on pientä, koska se on oletuskokoista. Oletuskoko ei toimi korkearesoluutioisella näytöllä.

Android-tabletilla selain käyttää koko näytön pinta-alaa. Oletin, että iPadin käyttäjät myös käyttävät koko ikkunaa. Koska CSS reagoi vain ja ainoastaan selainikkunan kokokoon, on mahdotonta huomioida muu kuin täysi selainikkuna.

Jos säädät selainikkunan iPadilla 1060-1080 välille

@media screen and (min-width:1060px) and (max-width:1080px) {

saat 16px tekstin. Tiedän, että tulla arvolla HD-kännykällä sivustoni on varsin luettava.

Toimii annetuilla pieniresoluutioisilla näytöilläkin, joskin 320 px suhteen foorumilista menee vähän sumppuun, mutta on silti luettavissa.

iPhone X ......................375x 812

tuo on ongelma, jos laitteen laittaa vaakasuuntaan. 812 px kun on suunniteltu pystynäytölle. Kaikille valikoille ei ole tilaa avautua.

Oli hyvä tiettä, että varsin pienetkin pikseliarvot on syytä ottaa huomioon.

Tämä on harrastus, joten ei niin väliä, jos mene vähän aikaa.

Laitoin foorumille viisi eri fonttikokoa
310 - 481
482 - 593
594-
1060-1080 eli HD-näyttö
1520-1668 eli iPad 2K -laitteet

Marginaaleit saisivat olla parempia.

w3schools.com
CSS osio. Google kääntää suomeksi jos tarvetta. Lue läpi sivusto.
Googlaa: w3 englantia css
Niin löydät nopeasti tiedon.

Laita
font size 2em;
font family arial sans... Löytyy w3school sivulta turvalliset fontit.
@media säännöt
meta tag puhelin 1.0

Selaimen f12 menu ja laite näkökulma päälle. Muokkaa suoraan selaimella css. Sit koodiin hyvät muutokset. Voit myös selaimella suoraan tiedostoja kirjoittaa.

Turbo-Urpolle.

Laitoin vasta eilen etusivulle tuon. Hyvä huomio.

"@media screen and (min-width: 673px)
.slider .featured-content .entry-header {"


En ole jaksanut lukea läpi mitä kaikkea erikoista teeman CSS sisältää. Olen yrittänyt omalla CSS:llä vain korjata epäkohtia. Ärsyttää jonkin verran se, että joissakin tilanteissa sisältö tuli otsikkokuvan päälle n. 70px verran. Kun sitten estin tulemasta, otsikon etäisyys otsikkokuvasta heittelee. Kaikki liittynee tuohon CSS:ään. Etusivulla täytyy korjata tuo kauneusvirhe.

Hiivatin ärsyttävä asia teeman CSS:ssä on se, että otsikko tulee joillakin leveyksillä kuvan päälle ja toisilla ei. Minkää *piip* takia joku on moista pelleilyä harrastanut. Korjaaminen on *piip* hankalaa ja ärsyttävää. No ei tässä leiskassa muuta todella pannuun ottavaa CSS:ää ole. Sohaisit kohtaa, joka minua potuttaa!

Foorumille piti määrittelyjä uusia, että kommentit olisivat aina järkevän kokoisia.

googleta.... nimimerkille

font size 2em;

Mutta ei kai se poista sitä ongelmaa, että 2em. 300-400px levyisessä laitteissa ylisuurta ja 1600px laitteissa taas aika pientä. Fontin tulee olla järkevässä suhteessa sekä laitteen resoluutioon ja sekä laitteen kokoon.

Pieni resoluutio kasvattaa fonttikokoa ja suuri pienentää. Pieni koko pieni reso vaatii pienen fontin. Pieni/pienehkö laite & suuri resoluutio vaatii suhteellisen suuren fonttikoon.


@media säännöt
meta tag puhelin 1.0

puhelinkohtaiset säädöt - ei sentään, ei niissä pysy kärryillä ja millä tasolla niitä on tuettu.

Etusivulla otsikko on kiva olla kuvan päällä. Määritin z-index:0. Muualla en siitä pidä.

On näiden nykyleiskojen kanssa pirummoinen työ. Body-luokkia tosi paljon. Yksi luokka on jäänyt huomioimatta kun lisäsin uuden tyyppisiä sivuja.

Toimii tällä hetkellä nätimmin HD-laitteilla (ainakin tietokonenäytön perusteella).

Sain otsikkokuvan määriteltyä joka leveysarvolle suht. mielekkään kokoiseksi. Otsinkon marginaalit sain siedettäviksi. Muutkin marginaalit pitäisi toimia näytönleveyksittäin suht. ok. Ei kannata enempää hioa.

Jos keskusteltavaa vielä, kannattaa keskustella foorumisivustollani.

Tarkoitin tuolla siis kohdista, jotka liittyvät sivustoni yksityiskohtiin.

Mitä tälle sivustolle kaipaisin on linkkeä sivun ylä- ja alalaitaan. Olisi aika helppo toteuttaa.

Jonkin tason editori olisi kiva. Sain sivustolleni graafisenkin editorin, mutta piti lisätä funktio lähdekoodiin. Jostakin ihme syystä graafisen editorin mahdollistavaa funktiota ei teemassa ollut valmiina.

Opetelkaa käyttämään CSS:ssä.
Ihan vain vinkiksi fontti koot voi muuttaa EM ei px, jolloin ne skaalautuvat oikein riippumatta käytetystä laitteesta!
@media screen and (min-width:) (Itse vältän näiden käyttöä niin kauan kuin mahdollista. Yleisin käyttötarkoitus taitaa olla poistaa näkyvistä esim. kuva liian pienessä näytössä.

Lisäksi headerit,footerit, height, weight... mielummin % kuin px, jolloin responsiivisempi.

Ja vielä mielummin osioita position:resolute; float:left; tyyliin ei position:absolute. Tämä riippuu tietenkin tilanteesta ja tottumuksesta.

Voit hyvinkin olla oikeassa tuossa fonttikoossa.

@media screen and (min-width:) ja max-width kuuluvat WordPress leiskojen olemukseen. Niillä hallitaan sitä, onko esillä kerrallan yksi, kaksi vai kolme palstaa. Toimii ihan hyvin, mutta onhan niitten kanssa näpertelemistä. Kyse on siis PERUSTAVALAATUISESTA toimintatavasta, ei mistään pikkunäpertelystä.

Position absolute ja fixed sopii navigaatioon. Minusta on kiva, kun navigaatio on aina käytettävissä.

En muuttanut alkuperäistä CSS:ää paitsi lisäsin loppuun väripaletin. Näin leiska hallinnassa.
Omasta CSS:stä tuli iso, koska pohjana vaikutti koko ajan teeman laatijan CSS, jota tuli yrittää hallitusti muuttaa.

Monet arvot on prosentuaalisia ja float:left käytössä
Osassa max-width ja min-width myös, että saa käytettyä tarkasti näytön pinta-alan.

@media screen and (min-widht...)
@media screen and ( (max-widht...)
@media screen and ( (max-widht...)

idea on siinä, että näytön pinta-ala hyödynnetään järkevästi.
Jos ajatellaan tätä sivustoa ja omaa foorumisivustoani isoresuluutioisessa näytössä on hirvittävästi tyhjää tilaa.

2K näytöllä pystysuunnassa tyhjää tilaa ei jää hirveästi. Ihan siedettävä lopputulos.

2K näytöllä vaakasuunnassa niin tällä sivustolla kuin omalla foorumilla noin puolet näytön pinta-alasta jää käyttämättä. Olisi ihan kiva suunnittella sivut näinkin päin järkevää tilankäyttöä ajatellen.

En tunne iPad laitteita, mutta ainakin Android-selain toimii koko ikkunassa. Hukkatilaa ei voi hyödyntää laittamalla rinnalle toisen ohjelman kuten voi ainakin Windows-laitteissa ja ymmärtääkseni myös Chrome OS -laitteissa sille suunnitelluilla ohjelmilla (Android-ohjelmat käyttävät kokoikkunaa).

Jotenkin tulee epävarma olo noiden em-arvojen kanssa, joten en taida niihin mennä. Ehkä tuntemattomille laitteille voisi ne määritellä.

Alla määrittely HD-laitteille:

textarea.wp-editor-area,
.site-info a.privacy-policy-link:link,
.site-info a.privacy-policy-link:visited,
.site-info a.imprint:link,
.site-info a.imprint:visited,
ul#primary-menu a:link,
ul#primary-menu a:visited,
.bbp-reply-content p,
.bbp-reply-content blockquote,
.bbp-reply-content li,
#colophon .widget,
#colophon .widget *,
body.single-post .entry-content,
body.page .entry-content,
body.search .entry-content,
.content-sidebar *,
.content-sidebar a:link,
.content-sidebar a:visited,
body.bbpress ul.bbp-topics *,
body.bbpress div.bbp-topic-form form#new-post fieldset.bbp-form textarea.bbp-the-content {
font-size:16px !important;
}
body.bbpress #bbpress-forums *,
body.bbpress div.bbp-reply-form form#new-post fieldset.bbp-form p label,
body.bbpress div.bbp-reply-form form#new-post fieldset.bbp-form legend,
body.bbpress div.bbp-topic-form form#new-post fieldset.bbp-form p label,
body.bbpress div.bbp-topic-form form#new-post fieldset.bbp-form legend {
font-size:15px !important;
}
#colophon .widget #bottom-forum-list span.sub a,
body.bbpress li.bbp-header *,
body.bbpress li.bbp-body * {
font-size:14px !important;
}
Ehdotuksia iPadille ja 2K laitteille vaakasuuntaan.

Em-fonttikoot on mielestäni kaikkein huonoin mahdollinen tapa. Fonttikoot karkaavat täysin lapasesta. Kokeilin - ei toimi ollenkaan. 1.1em aiheutti järkyttävän suurta fonttia, Syy siihen, että fonttikoko karkasi täysin lapasesta löytyy tästä:

"em units are relative to their parent container so nested lists have decreasing font sizes. It can be difficult to determine font sizes on complex pages — most of us use the force (lots of trial and error).

rem is similar to em except that it’s relative to the root element rather than the parent. Changing the li selector to 0.75rem will ensure all nested lists remain at 12px.

rem is available in Chrome, Firefox, Safari, Opera and IE9 . "

Ongelma ei koske vain listoja vaan ylipäätänsä monikerroksellisuutta.

rem-arvot on ainut tapa, jolla leiskakoko on sekä suunnittelija että käyttäjän kannalta hallinnassa.
Em-arvojen sijaan kannattaa suositella rem-arvoja. Riittää että BODY-elementille antaa arvon.

Epäien, että toisille näyttökoolle fontti on turhan pientä tai turhan isoa. Tavoitteeni on saada järkevän kokoista fonttia suhteessa laitteen fyysiseen kokoon.

Eihän se tietenkään täysin onnistu, sillä Full HD kännykkä ja Full HD läppäri/tablet-laite näyttävät fontin eri kokoisina. Full HD:n kuitenkin haluan määrittää kännykän mukaan.

On pakko pienentää fontteja listoissa, koska listoissa on paljon tietoa.
Tieto on listaelementteinä.

Ainoa mahdollisuus kunnolla hallita lstaelementtien WordPress fontteja on joko käytää px- tai rem-arvoja.

Em on kaikkialla huono, sillä se aiheutta aina ongelma listaelementeille, jos listoisssa käytetään muuta kuin arvoa 1.0em.

Em-arvot ovat yleiselläkin tasolla WordPress leiskoissa käyttökelvottomia, koska elementtikerroksia on todella paljon. On ihan mahdotonta pitää kirjaa siitä, mikä on minkäkin elementin emoelementti. Lähtökohtaisestikin leiskoissa on em-fonttimääritysten takia jonkin verran holtitonta fonttikoon heittelyä sivun footer-osiossa.

Minun täytyy elää niiden mallinteiden mukaan, mitä on käytettävissä. Kävin läpi kaikki css-tiedostot ja koostin niistä fonttikokomäärityslistat. Kokeilen lähiaikoina em-arvoisia fonttikokoja täydennettynä BODY-elementille annetulla peruskoolla.

Mitähän sille BODY-elementille laittaisi.

Bodylle laitoin
body {
font-size:medium;
}
Tämä tarpeen, jotta BODY:lle annettu pikseliarvoinen fonttikoko voidaan ohittaa.
Kännykkää ajatellen HD-laitteille perusfontteja on isonnettu.
Myös iPad & 2K pystysuunnassa omat fonttikoot.
Muuten perusfonttikoko on 1.0rem. Otsikot tuota suurempia ja listauksiin ja painikkeisiin liittyvät fonttikoot pienempiä.
Sivujen pitäisi skaalautua nätisti 320-1668px alueella kun laitetta pidetään pystysuuntaisesti.
Vaakasuunnassa ei kaikilla laitteilla toimi.

Osa fonttikoista on rem-arvoilla ylikokoisia. En ymmärrä miksi.

En nyt oikein pysty ymmärtämään, miten selain voisi tunnistaa laitteen fyysisen selainikkunan koon.

Jos tuo vw suhteutuu pikselimäärään, se voisi olla toimiva. Se saattaisi paremmin suhteutua näyttöporttiin kuin rem. Rem pitäisi suhteutua näyttöportiin, koska juurielementille (BODY) on fonttikoko.

Mutta on todella outoa, että rem ei toiminut 800x1280px tablet-laitteessani. Se toimi vaakasuuntaisella näytöllä ok lukuun ottamatta footer-osioita. Pystysuunnassa ei perustekstin suhteen ollenkaan. Miksi toimi toiseen suuntaan, en voi käsittää. 800 ja 1280 suuntiin on sama fonttikokomääritys.

https://www.sanaristikkofoorumi.net/wordpress/forums/topic/foorumin-fonttikoon-toimivuus/
ehkä parempi paikka keskustella juuri minun ongelmastani
HEAD-osasta näkee uudelleenmäärittelyt

No vw-arvoilla sain fonttikoon oikeaksi:

/* rem-arvo ei toimi, yritin korvata pikseliarvoilla , mutta ei toimi
*/
@media screen and (min-width:783px) and (max-width:800px) {
body.single-post #main-content div.entry-content p,
body.single-post #main-content div.entry-content li,
body.page #main-content div.entry-content p,
body.page #main-content div.entry-content li,
body.bbpress #main-content .bbp-reply-content p,
body.bbpress #main-content .bbp-reply-content li {
font-size:1.35vw !important;
}
}
Rem-arvot eivät pitäneet lupaustaan ts. että rem-arvoilla fonttikoot saisi luotettavasti määriteltyä suhteessa BODY-elementtiin.

Täytyy muuttaa vw-arvoiksi ne arvot, jotka eivät toimi rem-arvoina.

Sain 800×1280 Google Chrome -selaimelle sopivat arvot, mutta mitenkähän muut selaimet niihin suhtautuvat?

Sivun alaosan kohdalla meni kokeilemiseksi. 1280-suuntaan on pienemmät arvot kuin 800-suuntaan.

Tietokoneen näytöllä tablet-laitteelle sopivan kokoinen fontti on tietokoneella hirveän pientä.

Niin em, rem kuin vw-arvoilla työskentely aiheuttaa ennalta arvaamatonta fonttikokojen vaihteluita.

Pikseliarvoilla määrittely on monin verroin helpompaa. Silloin tietää, mikä on lopputulos eikä sitä joudu arvailemaan ja kokeilemaan järjettömän paljon.

Minusta minulla ei mopo karannut käsistä - selaimella kyllä!

Ennen vw-muutosta tablet-laitteeni Chromessa 1.0rem näkyi päätekstissä ainakin puolitoistakertaa suurempana kuin sivupaneelin 0.95rem. Eihän sen näin pitänyt mennä?

Olen totaalisen pettynyt Androidin Chromen fontinkäsittelyyn. Sen kanssa mopo karkaa keneltä tahansa käsistä suhteellisilla fonttikoilla komplekseilla leiskoilla.

Antaa olla, en jaksa tapella enempää asian kanssa.

Sivustoni voisi toimia nopeammin - mutta keskustelufoorumissa on ainakin tyylikkyyttä!
https://www.sanaristikkofoorumi.net/wordpress/forums/topic/ongelmia-visuaalisen-editorin-kanssa/

Pientä takeltelua, mutta sille ei voi mitään.

Testasiin 320x480px kännykällä. Osoitti ainakin sen, että sivujen on syytä toimia 320px ikkunassakin. Toimi suunnitellusti. Tietokoneen näyttö antoi asiasta oikean kuvan.

Testasin relatiivisten fonttikokojen käyttäytymistä Firefoxissa, jossa ne näyttäisivät toimivat täysin oikein tai ainakin lähes oikein.

Chromessa relatiiviset fonttikoot toimivat täysin epäluotettavasti. Jos haluaa, että fonttikoot näyttävät kaikissa selaimissa oikein, ei relatiivisia fonttikokoja voi käyttää monimutkaisilla leiskoilla.

Tähän sain tänään ihan uutta tietoa. Mobiililaitteissa on kertoimet, millä tavoin todellinen näytön pikselikoko suhteutuu CSS:llä määriteltyihin leveysarvoihin.

720x1280 -tason kännyköillä arvot yleensä puolitetaan.

iPad Pro käyttää n. 2,5 jakosuhdetta, sillä se näyttää www-sivuni saman näköisenä kuin 800x1280 -tablet-laitteeni.

Oletan, että HD ja ns. 2K tablet-laitteet näyttävät samaan tapaan kuten myös MS Surface Pro.

Mutta miten toimii iPad 9,7. Sen kuvasuhde on 1.33 kuten myös esim. Samsung Galaxy Tab S 3:n.

Arvaan, että se näyttäisi sivut ikään kuin 800x1064 -resoluutioinen laite. Tämä on kuitenkin vain arvaus. Mikähän on totuus?

Väärä arvaus. Löysin vastauksen. Tälle säikeelle ei enää ole käyttöä.