Yleistä keskustelua webdevauksesta

[Zvona]

Millä kielellä kannattaisi lähteä harjoittelemaan nettisivujen tekemistä? Pythonista kokemusta aika paljonkin, muiden kielien lukeminen ja opettelu onnistuu kohtalaisesti. Itse olen kuullut vain Djangosta, onko se hyvä? Ei ole siis käytännössä mitään hajua miten nettisivujen käyttäjälle näkyvä puoli toteutetaan.

Jatkan hyvin alkanutta keskustelua tässä kontekstissa:

1. yleinen virhe, minkä henkilökohtaisesti koen (etenkin aloittelevien) kehittäjien tekevän on frameworkin / kirjaston valitseminen web-sivustojen tekemiseen. Eli tehdään sovelluskehitykseen sopivalla kikkaleella fancyt kotskasivut. Tämä, kun ei ole esim. Reactin / Angularin / Vuen tarkoitus, että "käyntikorttimaiset" kotisivut tehtäisiin niillä.

2. lisäksi HTML:n ja CSS:n perusteellinen osaaminen on monesti aliarvostettua. Sitä näkee vaikkapa triviaalien animointien olevan toteutettu JS:llä (ja apuna n+1 riippuvuutta aina PopMotioniin saakka), vaikka saman saa tehtyä CSS:llä.

3. semanttinen osuus "Markup Language":sta on jäänyt monilta pois ja 90% sisällöstä survotaan kylmästi divien sisään. Tällähän ei loppukäyttäjän näkökulmasta ole varsinaista merkitystä, mutta pitää muistaa myös, että sivuston rakenteen tulkinta on monesti selainten ja niille tehtyjen lisäosien vastuulla.

4. mobiililaitteet edustavat yleensä vähintään 50% vierailukerroista. Tämä kannattaa ottaa huomioon - ei niinkään opettelemalla "responsive web design" -huttua vaan aidosti tutustumalla CSS:n täysin käyttökelpoisiin ominaisuuksiin (esim. flexbox, gridit, media queryt).

"Mobile first" on myös fraasi jota hoetaan ja se toki pitää paikkansa. Mutta itse en jättäisi hyvin alkanutta kehitystä kesken vain siksi, että serkun tyttöystävän kolme vuotta vanha android ei rendaa sivustoa täydellisesti. Eli kannattaa valita taistelunsa responsiivisuuden suhteen. Ja "RWD" on aika 2013 juttua - itse kutsun tätä aluetta "Adaptive User Interface Designiksi" - eli koko käyttöliittymän tulee mukautua niin päätelaitteen kuin myös muiden käyttäjän ominaisuuksien mukaan. Tämä tarkoittaa siis paljon muutakin kuin ärsyttäviä hampurilais-menuja.

5. palvelinpuoli (johon alkuperäisessä kysymyksessä viitataan) on kokonaan toinen osio. Mielestäni käytetyt kielet, kirjastot ja konventiot riippuvat monesti kokonaistoteutuksesta. Nyt, kun kyseessä on web-sivusto, niin itse teen aina node+express endpointit, johon "mockaan" oikeat, sivuilla näytettävät tiedot esim. JSON-tiedostoina, jotka populoidaan pug:illa (ex-Jade). Vasta tämän jälkeen alan harkita - ihan jo ylläpidettävyyden näkökulmasta - josko tarvittaisiin (dokumentti)tietokanta. Ehkä voisit harkita tämän toisentamista Pythonilla ja lähteä siitä liikkeelle?

Suosittelen miettimään, miten hakee tietoa netistä. Viitaten vaikka kohtaan #2: kun halutaan kaunis transitio etusivun kuville, niin kannattaa esim. hakea "image transitions with css" eikä "bleeding edge javascript library for animations".

Ja kun tulee ensimmäisen JS:ää vaativan toimenpiteen aika, niin silloin pitää hahmottaa asia (joka jo mainittiinkin) että kirjoitetaanko JavaScriptiä sellaisenaan vai käyttääkö sitä DOMin sörkkimiseen. Tässä karrikoitu esimerkki:

// JS:ää:
const numbers = "0123456789".split("");

// JS:ää:
const classNames = numbers.map((number) => `className-${number}`);

// DOM-manipulointia (tai sen valmistelua):
const elements = document.querySelectorAll('div');

// DOM-manipulointia:
Array.from(elements).forEach((element) => element.classList.add(classNames.shift()));

Harras mielipiteeni on, että mitä enemmän joudut manipuloimaan DOMia, niin sitä todennäköisemmin teet jotain väärin.

Myös se kannattaa muistaa, että paperilla moni asia voi näyttää hyvältä. Mutta kun pääsee aidosti kokeilemaan sitä ruudulla / päätelaitteella, niin tilanne saattaa kääntyä päälaelleen. Siksi "fail fast, fail often" on hyvä ideologia jota seurata. Siinä vaiheessa, kun koko leiska on jo taitettu kasaan ja tajutaan, että sekä leipäteksti että kaikki call to action -elementit ovat liian pieniä, niin homma lähtee valitettavasti käytännön nollasta. Eli konsepti- ja UI-suunnittelu on hyvä startti, mutta varsinainen UX asettuu uomiinsa vasta sitten, kun tekelettä pääsee ensimmäisen kerran kokeilemaan.

 

[Vispersson]

Tuli nyt sitten mentyä vähän ojasta allikkoon tässä kun lähdin googlettelemaan, että mitäs käytännön eroja noilla frameworkeillä ja itse js:llä, css:llä yms. on Jätin nyt kuitenkin Djangon väliin ja lähdin opettelemaan JavaScriptiä javascript.info:n avulla. Eli jos nyt jotain oikein ymmärsin niin tämänkö ohella olisi hyvä lähteä opettelemaan css:n käyttöä?

Minulla ei tällä hetkellä ole suurempaa visiota kotisivun käyttötarkoituksesta tai päämäärästä, mutta jotain suhteellisen simppeliä olisi tarkoitus vuoden aikana kehitellä omalle domainille. Käyttäjäystävällisyys on kuitenkin ollut omissa projekteissa aina ensisijalla, hyvä kun otitte sen esille. Omalla kohdalla ideaalinen toteutus olisi tuo, että tekisin datan pyörittelyn nettisivun ulkopuolella pythonilla ja json-tiedostoina.

Vähän on vielä hakusessa termit ja mitä tällä kaikella nyt tehdään ja mitä ne tarkoittaa palvelimen toiminnan kannalta, mutta eiköhän tämä tästä.

 

[nnaku]

Tuli nyt sitten mentyä vähän ojasta allikkoon tässä kun lähdin googlettelemaan, että mitäs käytännön eroja noilla frameworkeillä ja itse js:llä, css:llä yms. on Jätin nyt kuitenkin Djangon väliin ja lähdin opettelemaan JavaScriptiä javascript.info:n avulla. Eli jos nyt jotain oikein ymmärsin niin tämänkö ohella olisi hyvä lähteä opettelemaan css:n käyttöä?

Minulla ei tällä hetkellä ole suurempaa visiota kotisivun käyttötarkoituksesta tai päämäärästä, mutta jotain suhteellisen simppeliä olisi tarkoitus vuoden aikana kehitellä omalle domainille. Käyttäjäystävällisyys on kuitenkin ollut omissa projekteissa aina ensisijalla, hyvä kun otitte sen esille. Omalla kohdalla ideaalinen toteutus olisi tuo, että tekisin datan pyörittelyn nettisivun ulkopuolella pythonilla ja json-tiedostoina.

Vähän on vielä hakusessa termit ja mitä tällä kaikella nyt tehdään ja mitä ne tarkoittaa palvelimen toiminnan kannalta, mutta eiköhän tämä tästä.

HTML on siis markup jolla määritellän DOM (Document Object Model) puu, eli sivun runko!
CSS (Cascading Style Sheets) on stylesheet eli pitää sitällään tyyli viittauksia DOM puun elementteihin.

Selain muodostaa ensin HTML tiedostosta DOM ja CSSOM puut
Joista se sitten muodostaa Renderöinti puun, jonka se piirtää näytölle.

CSS siis pitää sisällää vain staattisia viittauksia DOM elementteihin!

JavaScriptillä taas tuotetaan kaikki interaktiivinen sisältö! Kuten vaikkapa listojen järjestys a-ö ja ö-a, tai datan hakeminen palvelimelta. TAI elementin tyylin muokkaaminen mikäli CSS ei siihen pysty ja silloinkin yleensä muutetaan elementin selectoreita, kuten id tai luokkaa.

huomaa että #id tulisi olla uniikki kun taas .luokkaa voidaan käyttää usealle eri elementille joille halutaan sama tyylit.

<!DOCTYPE html>
<html>
  <head>
    <title>Document</title>
    <style>
      /* # id */
      #container {
        min-height: 100vh;
        position: relative;
      }
      header {
        background: tomato;
        padding: 10px;
      }
      main {
        padding: 10px;
        padding-bottom: 60px; /* footerin korkeus */
      }
      footer {
        position: absolute;
        bottom: 0;
        width: 100%;
        height: 60px; /* footerin korkeus */
        background: seagreen;
      }
      /* . luokka */
      .code {
        font-weight: 600;
        text-decoration-line: underline;
      }
    </style>
  </head>
  <body id="container">
    <header>
      Ylätunniste, usein headerissa on jonkinlainen sivuston navigointi.
    </header>
    <main>
      <h1>Otsikko</h1>
      <p>
        Sivun näkyvä sisältö määritellään <span class="code">body</span> tägien
        sisään. <span class="code">p</span> on paragraafi joka on tarkoitettu
        leipätekstille.
      </p>
    </main>
    <footer>Tämä on sivun alatunniste</footer>
  </body>
</html>

Eli seuraavan lainen html documentti piirtyy selaimessa näin.

Suosittelen aloittamaan iha siitä staattisen sivun räpellyksestä! Ja sitten kun, nälkä kasvaa syödessä on hyvä lähteä laajentamaan osaamista valmiisiin työkaluihin, kirjastoihin ja kokonaisiin frameworkkeihin.

Kirjastoilla ( esim. ReactJS ) ja frameworkeillä ( esim Vue ja Angular ) yleensä rakennettaan hieman monimutkaisempia ja laajempia ratkaisuja, kuin jokin perus staattinen sivu.

Nuo kolme edellämainutta pytkivät pilkkomaan koodin muduleiksi joita voidaan helposti uudelleen käyttää. Nämä modulit myös sitten toimitetaan javascriptin avulla selaimen renderöitäväksi riippuen käyttäjän käyttäytymisestä sivustolla/sovelluksessa. Näiden DOM pitää sisällää tasan pakolliset meta tiedot ja ns. bundle.js tiedoston jonka kautta kaikki sisältö toimitetaan.

 

[Uhanalainen]

Lähde nyt yhdestä liikkeelle, turha niitä kaikkia on sekaisin yrittää opetella, menee vaan aivot umpisolmuun turhaan. HTML:ssä nyt ei kauaa mene kun sen sisäistää, CSS:ään voikin käyttää enemmän aikaa.

Sitten kun ne on hallussa, alat tutustumaan JS:ään kunnes alkaa tuntua siltä että hallitset jotenkuten (tai osaat googlata). Sitten yhdistelet palaset jossain isommassa projektissa.

 

[Karhukainen]

Omalla kohdalla ideaalinen toteutus olisi tuo, että tekisin datan pyörittelyn nettisivun ulkopuolella pythonilla ja json-tiedostoina.

Vähän on vielä hakusessa termit ja mitä tällä kaikella nyt tehdään ja mitä ne tarkoittaa palvelimen toiminnan kannalta, mutta eiköhän tämä tästä.

Katso Flask-tutorialeja, sillä on hyvä lähteä liikkeelle mitä palvelinpuoleen tulee.

 

[Kautium]

En ole koskaan kovinkaan syvällisesti tutustunut HTML/CSS:n logiikkaan ja nyt kun näitä on pitänyt vähän enemmän tavailla, niin eipä tule äkkiseltään mieleen mitään yhtä kömpelöä kokonaisuutta.

Pakko sanoa tämä perinteinen, eli että kuussa on käyty 50v sitten ja edelleen webbisivuja askarrellaan jollakin Notepad++:lla ja arvotaan erillisessä tyylitiedostossa, että mikähän asetus/attribuutti voisi vaikuttaa minnekin ja milläkin tavalla. Tuossa oli mm. sellainen tilanne, että piti rakennella sivu, jossa on ensin header, alla pari palstaa ja niiden alla footer, mutta eihän tällaista perusleiskaakaan ole mahdollista luoda kuin kikkailemalla sinne väliin jotain kelluvia elementtejä, jotta palstat saadaan edes jotenkin siististi rinnakkain. Ja siinä vasta hiukset harvenevatkin, jos haluaa mitään edistyneempää.

On kyllä totaalisen perverssi systeemi ja muistui aika nopeasti mieleen, miksi ei ole aihe koskaan liiemmin kiinnostanut.

Millä työkaluilla porukka näitä hommia oikein tekee, jotta pää kestää? Ainakaan mitään kunnollisia wysiwyg-työkaluja ei taida olla olemassa, että saisi nopeasti edes jonkinlaista pohjaa aikaiseksi ja voisi sitten viilata sitä koodia säätämällä tarkemmaksi?

 

[hsalonen]

En ole koskaan kovinkaan syvällisesti tutustunut HTML/CSS:n logiikkaan ja nyt kun näitä on pitänyt vähän enemmän tavailla, niin eipä tule äkkiseltään mieleen mitään yhtä kömpelöä kokonaisuutta.

Pakko sanoa tämä perinteinen, eli että kuussa on käyty 50v sitten ja edelleen webbisivuja askarrellaan jollakin Notepad++:lla ja arvotaan erillisessä tyylitiedostossa, että mikähän asetus/attribuutti voisi vaikuttaa minnekin ja milläkin tavalla. Tuossa oli mm. sellainen tilanne, että piti rakennella sivu, jossa on ensin header, alla pari palstaa ja niiden alla footer, mutta eihän tällaista perusleiskaakaan ole mahdollista luoda kuin kikkailemalla sinne väliin jotain kelluvia elementtejä, jotta palstat saadaan edes jotenkin siististi rinnakkain. Ja siinä vasta hiukset harvenevatkin, jos haluaa mitään edistyneempää.

On kyllä totaalisen perverssi systeemi ja muistui aika nopeasti mieleen, miksi ei ole aihe koskaan liiemmin kiinnostanut.

Millä työkaluilla porukka näitä hommia oikein tekee, jotta pää kestää? Ainakaan mitään kunnollisia wysiwyg-työkaluja ei taida olla olemassa, että saisi nopeasti edes jonkinlaista pohjaa aikaiseksi ja voisi sitten viilata sitä koodia säätämällä tarkemmaksi?

Kannattaa opetella joku yleisesti käytössä oleva kirjasto, esim. Bootstrap:
Bootstrap

 

[Paapaa]

En ole koskaan kovinkaan syvällisesti tutustunut HTML/CSS:n logiikkaan ja nyt kun näitä on pitänyt vähän enemmän tavailla, niin eipä tule äkkiseltään mieleen mitään yhtä kömpelöä kokonaisuutta.

Pakko sanoa tämä perinteinen, eli että kuussa on käyty 50v sitten ja edelleen webbisivuja askarrellaan jollakin Notepad++:lla ja arvotaan erillisessä tyylitiedostossa, että mikähän asetus/attribuutti voisi vaikuttaa minnekin ja milläkin tavalla. Tuossa oli mm. sellainen tilanne, että piti rakennella sivu, jossa on ensin header, alla pari palstaa ja niiden alla footer, mutta eihän tällaista perusleiskaakaan ole mahdollista luoda kuin kikkailemalla sinne väliin jotain kelluvia elementtejä, jotta palstat saadaan edes jotenkin siististi rinnakkain. Ja siinä vasta hiukset harvenevatkin, jos haluaa mitään edistyneempää.

On kyllä totaalisen perverssi systeemi ja muistui aika nopeasti mieleen, miksi ei ole aihe koskaan liiemmin kiinnostanut.

Millä työkaluilla porukka näitä hommia oikein tekee, jotta pää kestää? Ainakaan mitään kunnollisia wysiwyg-työkaluja ei taida olla olemassa, että saisi nopeasti edes jonkinlaista pohjaa aikaiseksi ja voisi sitten viilata sitä koodia säätämällä tarkemmaksi?

Jos "kelluvilla elementeillä" tarkoitat floateaja, niin ei onneksi tarvitse. Nykyään leiskat/palstat tehdään flexboxeilla tai vielä paremmin uudemmilla grideillä. Ei mene enää niin pahasti hermo asemoinnin kanssa. IE:tä lukuunottamatta grid on hyvin tuettu.

Usein kun tekee sivuja, on käytössä joku dev-server/hot-loader, joka uudelleenlataa ja näyttää muutokset, kun tallentaa jonkun projektin tiedoston. Voi siis pitää selainta auki ja muutokset näkyvät ns. reaaliajassa. Helpoiten tällaisen saa käyttöön esim. suunnitelemalla leiskaa täällä:

CodeSandbox: Online Code Editor Tailored for Web Application Development

Muitakin vastaavia on. Wysiwygejä en ole koskaan käyttänyt.

 

[Kautium]

Jos "kelluvilla elementeillä" tarkoitat floateaja, niin ei onneksi tarvitse. Nykyään leiskat/palstat tehdään flexboxeilla tai vielä paremmin uudemmilla grideillä. Ei mene enää niin pahasti hermo asemoinnin kanssa. IE:tä lukuunottamatta grid on hyvin tuettu.

Usein kun tekee sivuja, on käytössä joku dev-server/hot-loader, joka uudelleenlataa ja näyttää muutokset, kun tallentaa jonkun projektin tiedoston. Voi siis pitää selainta auki ja muutokset näkyvät ns. reaaliajassa. Helpoiten tällaisen saa käyttöön esim. suunnitelemalla leiskaa täällä:

CodeSandbox: Online Code Editor Tailored for Web Application Development

Muitakin vastaavia on. Wysiwygejä en ole koskaan käyttänyt.

Höh, kaikki ohjeet mitä löysin aiheesta, ohjeistivat käyttämään juuri floatteja. Ei vissiin ole tieto mahdollisesti paremmista menetelmistä tavoittanut kaikkia.

Tuo Codesandbox vaikutti ihan mielenkiintoiselta, pitääpä tutkia. Ei sillä että sekään auttaisi siihen vaivaan, että tietää mitä haluaa, mutta ei tiedä millä menetelmillä se kannattaisi toteuttaa. Joku wysiwyg-työkalu olisi tällaiseen tarpeeseen kätevä, kun sillä voisi tehdä näppärästi leiskan pohjan ja lisäillä kuvat ja niiden ominaisuudet jne ja loppu hienosäätö ja koodin siistiminen sitten suoraan css-tiedostoon manuaalisesti.

 

[Paapaa]

Höh, kaikki ohjeet mitä löysin aiheesta, ohjeistivat käyttämään juuri floatteja. Ei vissiin ole tieto mahdollisesti paremmista menetelmistä tavoittanut kaikkia.

No, netti säilyttää ne 10v vanhat ohjeet myös ja Google saattaa niitä tarjota. Lähtökohtaisesti et tarvitse tai halua floateja mihinkään moderneilla selaimilla. Niitä saattaa olla esimerkeissä selaintuen takia, mutta moderneilla selaimilla toimivat pelkillä grideillä/flexboxeilla, joiden avulla asemointi on paljon helpompaa ja monipuolisempaa.

Codepen on toinen näppärä työkalu pikkukokeiluun. Pointti on se, että ei tarvitse asentaa ja käynnistää mitään, voi suoraan kirjoittaa koodin/markupin ja nähdä tulos.

 

[Kautium]

No, netti säilyttää ne 10v vanhat ohjeet myös ja Google saattaa niitä tarjota. Lähtökohtaisesti et tarvitse tai halua floateja mihinkään moderneilla selaimilla. Niitä saattaa olla esimerkeissä selaintuen takia, mutta moderneilla selaimilla toimivat pelkillä grideillä/flexboxeilla, joiden avulla asemointi on paljon helpompaa ja monipuolisempaa.

Toki vanhaakin kamaa löytyy, mutta nämä olivat alle vuoden vanhoja ohjeita. Ja jotenkin naiivisti kuvittelin että edes w3schools.comissa olisi uusinta tietoa, mutta ei (kliks).

Codepen on toinen näppärä työkalu pikkukokeiluun. Pointti on se, että ei tarvitse asentaa ja käynnistää mitään, voi suoraan kirjoittaa koodin/markupin ja nähdä tulos.

Mikähän olisi järkevä näitä vastaava paikallisesti asennettava sovellus?

 

[Zigh]

Ja jotenkin naiivisti kuvittelin että edes w3schools.comissa olisi uusinta tietoa, mutta ei (kliks).

No onhan tuossakin esitelty: "A modern way of creating two columns, is to use CSS Flexbox."

Tosin se voisi nykyisin olla tuon float esimerkin tilalla ja floatit sitten "tee näin jos haluat tukea vanhaa IE:tä".

 

[Paapaa]

Kieltämättä hassua, että floateja mainitaan, mutta ehkä noita ei päivitellä kovin usein. Gridit on se modernein tapa, flex semi-tuoretta.

 

[Fanboys Suck]

Flexbox sopii jos tarvitse sarakkeita/rivejä yhteen suuntaan, eli joko vaakaan tai pystyyn, gridboxit sopii jos haluat vaakaan ja pystyyn tai vaakaan tai pystyyn. Eli gridit on se mitä kannattaa ehkä käyttää layoutteihin, ja flexboxit sitten grideihin sijoittuviin laatikoihin jne.

Floateille on paikkansa, mutta sen takia CSS kehittyy että tulee parempia tapoja tehdä asioita.

Se ettei osaa tehdä jotain tai ei ymmärrä ei tee siitä teknologiasta huonoa.

 

[Kautium]

Se ettei osaa tehdä jotain tai ei ymmärrä ei tee siitä teknologiasta huonoa.

No jaa, huono ja huono. Kyllähän tuo webbisivujen leiskan rakentaminen aika toivottoman kömpelöä säätämistä on CSS:n kanssa. Ongelma on siinä, ettei parempaakaan ole ja syy tähän on varmaankin siinä, että kaikki on rakennettu tuon himmelin varaan, eikä yhteensopivuutta voi yhtäkkiä mennä muuttamaan. Jotenkin sitä voisi kuvitella, että tarjolla olisi edes tehokkaampia/kätevämpiä työkaluja, mutta aika vaatimatonta on meno silläkin puolella.

 

[Joonikko]

CSS Gridillä saa tehtyä pohjan helposti ja samalla pystyy erottamaan HTML tiedoston rakenteen sivun visuaalisesta rakenteesta. grid-template-areas ja @media kyselyillä sivusta saa myös responsiivisen. Bootstrap CSS-kirjastolle löytyy myös visuaalinen työkalu ja CSS grid-pohjalle myös.

Esimerkiksi tälläisen perus asetelman saa tehtyä helposti:

┌─────────────────────────────┐
│Header                       │
├────────┬────────────────────┤
│Sidebar │Content             │
│        │                    │
├────────┴────────────────────┤
│Footer                       │
└─────────────────────────────┘

CSS:

.grid-container {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr 1fr;
  grid-template-rows: 1fr 1fr 1fr 1fr;
  grid-template-areas: "Header Header Header Header"
                       "Sidebar Content Content Content"
                       "Sidebar Content Content Content"
                       "Footer Footer Footer Footer";
}

.Header { grid-area: Header; }
.Content { grid-area: Content; }
.Sidebar { grid-area: Sidebar; }
.Footer { grid-area: Footer; }

HTML:

<div class="grid-container">
  <div class="Header"></div>
  <div class="Content"></div>
  <div class="Sidebar"></div>
  <div class="Footer"></div>
</div>

Noissa WYSIWYG-editoreissa tulee niin nopeasti rajat vastaan ja niitä on suhteellisen vaikea hyödyntää mihinkään suurempaan web-sovelluksen kokonaisuuteen.

 

[Fanboys Suck]

No jaa, huono ja huono. Kyllähän tuo webbisivujen leiskan rakentaminen aika toivottoman kömpelöä säätämistä on CSS:n kanssa. Ongelma on siinä, ettei parempaakaan ole ja syy tähän on varmaankin siinä, että kaikki on rakennettu tuon himmelin varaan, eikä yhteensopivuutta voi yhtäkkiä mennä muuttamaan. Jotenkin sitä voisi kuvitella, että tarjolla olisi edes tehokkaampia/kätevämpiä työkaluja, mutta aika vaatimatonta on meno silläkin puolella.

No mikä olisi vaihtoehto mielestäsi? html ei ole tarkoitettu pikselintarkkaan julkaisuun. HTML ei edes sisällä mitään ulkonäköön liittyviä määrittelyjä, vain rakenteeseen liittyviä. Se mitä ilmeisesti kaipaat on flash ja silverlight. Deklaratiiviset sivunkuvauskielet ei myöskään takaa samaa ulkonäköä kaikissa laitteissa. CSS:n ongelma on ollut se ettei kaikki ohjelmat ole tulkinneet sitä samalla tavalla, ja business ym. syistä johtuen ovat tehneet siitä "oman" tulkintansa.

 

[nnaku]

Mikähän olisi järkevä näitä vastaava paikallisesti asennettava sovellus?

Taitaa olla joku tekstieditori ja siihen sopiva plugari. Esim vscode ja liveserver. Ja tämä on siis todellinen WYSIWYG, koska voit avata lopputuoteet millä tahansa selaimella tai laitteella haluat.

 

[ojisama]

CSS Gridillä saa tehtyä pohjan helposti ja samalla pystyy erottamaan HTML tiedoston rakenteen sivun visuaalisesta rakenteesta. grid-template-areas ja @media kyselyillä sivusta saa myös responsiivisen. Bootstrap CSS-kirjastolle löytyy myös visuaalinen työkalu ja CSS grid-pohjalle myös.

Vanha quote, mutta mainittakoon, että Firefox Developer editionissa on tuohon myös työkaluja: https://mozilladevelopers.github.io/playground/css-grid/03-firefox-devtools

 

[Tapio X]

Käyttämäni teema asemoi pääsisältöelementit ihan float-elementteinä. Tällä hetkellä leveälle näytölle kaksi rinnakkain (alun perin kolme) ja kapealle kaksi. Toimii ihan ok.

Mutta tähän sisältyy yksi ongelma. En tiedä, olisiko grideistä tai flex-boxeista siihen ratkaisua kun niitä ei ole tullut käytettyä.

Ongelma on se, että on mahdoton laittaa yhtenäistä reunaviivaa leveällä näytöllä oikean ja vasemman reunan väliin.

Jos sen laittaa pääsisällölle, se katkeaa jos oikean reunan palkki on korkeampi ja päinvastoin.

Minulla on siksi erään hlön nimittämä "puhekupla" oikean reunan palkkina. Se toimii aina.

Tuskin tämän takia muutan rakennetta, mutta ratkaisisiko grid tämän ongelman?

Tyypillinen leveys minulla on 75% pääsisältö ja 25 sivupalkki. Jos grid muuttaisi floatit ikään kuin taulukoksi, kai sitten periaatteessa yhtenäinen reunaviiva/reuna-alue olisi mahdollinen. Gridiä voisi käyttää yli 783+ leveyksillä.

Kannattaako muutos vai onko "puhekupla" ihan ok ratkaisu?

 

[Xiyng]

^Jos haluat tukea IE:tä, grid ei lähtökohtaisesti ratkaise ongelmaa, sillä IE ei tue gridiä.

 

[Tapio X]

Haluan tukea IE:täkin, joten unohdetaan gridit. Sivustoni toimi IE 11:ssa lähes suunnitellusti. IE:n ongelma on vain siinä, että se laittaa pystysuunnan vierityspalkin sisällön puolelle kun Chrome laittaa sen sisällön ulkopuolelle. Sisällön puolelle laitto hieman pilaa ulkoasua.

Tätä voisi periaatteessa kiertää kyllä vanhanaikaisilla taulukoillakin.
Kun leveys on enintään 782px, laitetaan vain
table.maincontent, table.maincontent tbody, table.maincontent tr,table.maincontent td{display:block}
table.maincontent td{float:left}

Vaatisi leiskan uudelleen määrittelyä erittäin paljon. Ei olisi järkeä.

Ongelman voisi kaiketi ratkaista sillä, että elementit menevät reunaviivan verran päällekkäin. Jos toisen reunaviiva katkeaa, toisen jatkuu. Näin reunaviivat yhdessä olisivat aina täyskorkeita.

Tosin juuri nyt myös pääsisältö on tavallaan ikään kuin puhekupla, sillä ydinsisältö on kehystetty. Reunaviiva ei nykyisellään edes toimisi. Tämä oli vain teoreettinen kysymys.

 

[Xiyng]

Piti vielä vilkaista uudemman kerran, ja nähtävästi IE:n omilla grid-versioilla (-ms-grid jne.) saa tehtyä enemmän tai vähemmän grid-juttujakin. Riippuen tarpeista voi siis sittenkin olla ihan käyttökelpoista.

 

[Tapio X]

Hyvä tietää, mutta ei sillä nykyiseen projektiin ole vaikutusta. Tuskin alan muuttamaan systeemiä.

 

[jhalmu]

Hyvät hyssykät kun takkuaa tuo weppi-devaus. On nyt Svelte+tailwind valittu käyttöön ja ainakin tailwindin opiskeluun mennyt aikaa. Jossain juutuubi -videossa sen tekijä sanoi, että ei kannata ruveta hienosäätämään alussa vaan ihan kaikki perustoiminnot ja sitten... no tietenkään tässä on viilattu pikseliä ja pitäisi oikeasti pistellä vaan muutamat chartit pystyyn ja niille jotain kivaa että olisi helppo päivittää. Mutta ei. Toki tiedän että katselen ihan liikaa juutuubi-tekemistä enkä itse tee. Toisaalta. Saanut hyviä ideoita. Toisaalta. Rima nousee kun tietää liikaa, mutta ei osaa tehdä...

 

[Fanboys Suck]

Käyttämäni teema asemoi pääsisältöelementit ihan float-elementteinä. Tällä hetkellä leveälle näytölle kaksi rinnakkain (alun perin kolme) ja kapealle kaksi. Toimii ihan ok.

Mutta tähän sisältyy yksi ongelma. En tiedä, olisiko grideistä tai flex-boxeista siihen ratkaisua kun niitä ei ole tullut käytettyä.

Ongelma on se, että on mahdoton laittaa yhtenäistä reunaviivaa leveällä näytöllä oikean ja vasemman reunan väliin.

Jos sen laittaa pääsisällölle, se katkeaa jos oikean reunan palkki on korkeampi ja päinvastoin.

Floattien aiheuttamia ongelmia ja päänvaivaa miljoonille devaajille ei voi väheksyä piiruakaan. Mitä nopeammin lopetat niiden käytön layouttien tekemiseen sitä nopeammin pääset taas kiinni tuottavaan työskenteleen eikä aika mene turhien ongelmien ratkaisuun.

Can I use... Support tables for HTML5, CSS3, etc

IE tukee gridiä jotenkuten kohtuullisesti, sehän on MS:n kehittämä ominaisuus aluperin. Ja oikea tapahan on muutenkin käyttää @supports toimintoa minkä avulla tarjoillaa fallback ominaisuus esim. vanhemmille selaimille.

How @supports Works | CSS-Tricks

Siis: älä käytä floatteja ne rikkkoo layoutin ennemmin tai myöhemmin, riippuen selaimesta, ruudun koosta, käyttäjän valitsemasta fontista tai ihan mistä tahansa muusta syystä. IE:n mahdolliset gridiongelmat on pientä siihen verrattuna.

 

[Tapio X]

No en tee enää toisille sivuja (olen eläkkeellä). Silloin kun tein, ei aluksi voinut edes käyttää floatteja, koska Netscape ei osannut niitä käsitellä. Käytettiin yleensä taulukoita. Tavallaan grid on paluuta niihin, mutta toimivat joustavammin.

Nykyinen sivusto skaalatuu 320px ylöspäin ja on vain yksi pää katkaisukohta (782px). Se ei kaipaa gridejä, koska yhtenäistä reunaviivaa ei ole.

Ei gridejä näyttäisi olevan tälläkään sivustolla. Jos laittaa leveälle näytölle oikealle tulee "puhekuplia". Pääsisältöalue on sekin tavallaan oma "puhekuplansta", jonka yläpuolelle on jätetty tilaa otsikolle ja otsikon ympärille laitetuille elementeille.

Puhekupla-alueita reunustavat täysleveinä ylhäällä header- ja alhaalla footer-osa. Koska elementit ovat täysleveitä, ne toimivat käytännössä grid-elementteinä.

Pääsisältöalueen reunustus loppuu ennen footer-osaa.

Rakenne on omaan sivustooni verraten samankaltainen. Pääkatkoskohta vain on eri. (Tosin oman sivuston rakenne on nyt aika lailla kopio tästä sivustosta).

Tässä oikean reunan puhekuplat ovat irtonaisia. Itselläni ne ovat kiinni pääsisältöalueessa.

Rakenteeltaan suht. yksinkertainen sivusto toimii ilman gridejäkin.

Toki vaikutelmani tästä sivustosta on vain pintapuolinen. Pintapuolisesti tarkastettuna tämä sivusto ei käytä gridejä, mutta voi se käyttääkin, mutta elementit on ainakin laitettu niin, että vaikutelma on floattien käyttö ja floatit riittävät tämän sivuston rakenteen hallintaan.

Ja riittävät ihan samasta syystä kuin itsellänikin - ei ole yhtänäistä reunaviivaa pääsisällön ja oikean reunan välillä leveällä näytöllä.

________________________

Mikä nyt puuttuu omasta ratkaisustani, on tämän sivuston kaltainen hälytystoiminto, joka ilmoittaa uusista viesteistä osoiterivillä.

Lisäksi ominaisuuksiin kuuluu hälytysten avaus sivun alusta.

Saan selville funktioilla vastauksen id:n ja yksittäisen vastauksen päivämäärän ja kirjoittajan. Näistä olisi varmaan apuja kehittämisessä.

Listausksessa on ns. koukkuja, mutta ne liittyvät vain yksittäiseen kohtaan listauksesta tai siihen, että listan alkuun tai loppuun saa jotain. Jos saisi listan alkuun, se olisi aika kaukana sivun alusta, sillä otsikko ja leivänmurut on välissä. Toki kohtuullisen toimiva ratkaisu olisi hältytysten informaation otsikon alapuolella. Saisi olla kyllä ylempänä.

Absoluuttinen tai kiinnitetty asemointi on ongelmallinen.

Osoiterivillä näkyvä ikoni ymmärtäkseni on LINK-tägillä. Missä se on WordPressissä määritelty, ei tietoa eikä mitään ideaa, miten sen saisi liittymään uuteen viestiin.

 

[Fanboys Suck]

No en tee enää toisille sivuja (olen eläkkeellä). Silloin kun tein, ei aluksi voinut edes käyttää floatteja, koska Netscape ei osannut niitä käsitellä. Käytettiin yleensä taulukoita. Tavallaan grid on paluuta niihin, mutta toimivat joustavammin.

Samaa on ainoastaan rivien ja sarakkeiden käsitteet.

Itsekin aloitin sivujen ja layouttien tekemisen mm. tauluilla, sitten floateilla jne. Sain myös jotain perverssiä tyydytystä jos sain sivuston tehtyä pelkällä css:llä. Myöhemmin siirryin bootstrapin ja muiden css frameworkkien käyttöön, mediaqueryt auttoivat floateissa jne. Mutta se tyyppi sisälläni joka optimoi layoutteja, css:ää ja html:ää vuosituhannen alussa tunsi itsensä likaiseksi. Gridin (ja myös flexboksin) myötä se HTML:ää ja css:ää optimoinut tyyppi on taas kokenut herätyksen. Html voi taas olla pelkkä runko ja css:llä se tieto voidaan helposti esitttää lähes miten vain ilman satojen kilojen frameworkkeja.

Mutta joo holy grail floateilla vuonna 1999 samaan aikaan IE:lle ja Netscapelle, hirveetä paskaa. Ei siinä mitään jos homma toimii, mutta itseltäni ainakin lähtenyt niin paljon turhautumista weppidevauksesta standardien kehittyessä ja kun valtaosa selaimistakin toimii niinkuin pitää niin tästä hommasta voi joskus jopa nauttia.

link tagilla voidaan viitata mihin tahansa ulkoiseen resurssiin, yleensä css-tiedostoon. Tarkoitatko faviconia mahdollisesti? Sitähän ei tarvitse erikseen linkittää vaan kopioimalla sopivasti nimetty kuvatiedosto sivuston juureen ilmaantuu se osoiteriville. Hälytyksiin suosittelen käyttämään jotain valmista pluginia. javascript alert library - Google-haku

 

[Tapio X]

Tarkoitatko faviconia mahdollisesti?

Tarkoitan. Jos saa hälytyksen, se pitää pystyä vaihtamaan toiseksi kuten tällä sivustolla toimitaan.

Mitenkä valmiit Js-pluginit voi liittää WordPressiin. Siinä tieto haetaan WordPressin omilla funktioilla.

Osan JavaSriptistä joutuisi kaiketi luomaan PHP:llä, jotta voi käyttää WordPressin funktioita.

___________________

Gridit voisi ymmärtääkseni periaatteesa hoitaa kyllä ikään kuin taulukkoina, mutta ongelmana on se, että yhtä sivupalkkia kohden samalla elementtitasolla on useita elementtejä

@media screen and (min-width:1031px){
.site-content{display:table;width:1280px;margin:auto}
.main-content {display:table-row}
.entry-header,article,#content-sidebar{display:table-cell}
.entry-header,article{width:75%}
#content-sidebar{width:25%;border-left:1px solid lightgray;background-color:#eee;box-sizing:border-box}

Normaali taulukoilla on rowspan ja colspan, mutta display:table-cell ei niitä ymmärtääkseni hyödytä. Eikä rowspan-emuloinnista olisi mitään hyötyä tilanteessa, jossa ei tiedä, kuinka paljon niputtaa elementtejä yhteen.

Eroaako grid käytännössä siitä, että elementeille annettaisiin taulukoihin liittyvät display-arvot? Eikö lopputulos pitäisi olla periaatteessa ihan sama?

Voiko grideillä selvittää rowspan ja colspan tarve? Jos ne voivat jotenkin emuloida taulukoiden rowspan ja colspan -attribuutteja, kokisin gridit hyödyllisinä. Rowspan emulointikaan ei toimisi, sillä artikkelisivuilla ei voi tietää, kuinka paljon pitäisi niputtaa elementtejä yhteen.

Maksimissaan sivupalkin rinnalla voi olla kolmekymmentä samalla elementtitasolla olevaa elementtiä.

En usko, että grid olisi käyttämässäni leiskassa lainkaan käyttökelpoinen. Leiskan täytyisi lähtökohtaisesti olla suunniteltu hieman toisin ts. article + .entry-header-elementeillä + joillakin muillakin elementeillä pitäisi olla yhteinen ns. container-elementti, esim. .main-content-container, joka on samalla elementtitasolla kuin #content-sidebar. Sitten grid olisi kyllä käyttökelpoinen.

Nyt sivupalkki (#content-sidebar) on sijoitettu leiskaan niin, että grid-suunnittelu on mahdotonta.

Tietenkin kun itse suunnittelee leiskaa, asiat voi ottaa huomioon. Toisen tekemää leiskaa hyödynnettäessä asia on eri.

Jos lähtökohtaisesti voisi valita, käyttääkö gridejä vai display:table jne., mikä etu grideillä olisi?

 

[Tapio X]

Katsoin väärin. On tässä kokoava elementti sittenkin eli kaikki sivupalkin oikealla puolella olevat elementit on yhden elementin alaisuudessa yläosan palkkia lukuun ottamatta. Periaatteessa siis grid-suunnittelu on mahdollista. Pääsisällön yläosaan sijoittamani palkki vain pitäisi siirtää ennen kokoavaa elementtiä eikä sen sisälle. Sitten pitäisi tehdä erinäisiä muutoksia.

Sen verran testasin, että taulukoiksi ei käytännössä gridiksi muuttaminen sai aikaan vasemman reunan sivupalkille yhtenäisen reunaviivan. Kovin suuria muutoksia ei tarvisisi tehdä muuhun CSS:ään. Erääseen teemaan ihan harkinnan arvoinen display-ominaisuutta käyttäen.

 

[jhalmu]

Tee kuva ulkoasusta ja tarvittavista sarakkeista, niin katotaan miten ne vois luoda eri keinoin?

 

[Tapio X]

Nyt melko simppeli tietokoneella yli 783px leveyksillä:
OTSAKE eli HEADER (täysleveä)
LEIVÄNMURUT(täysleveä)
VASEN SISÄLTÖ ja OIKEA SISÄLTÖ (yhteensä 1280px)
ALAOSA eli FOOTER (täysleveä)

Kokeilin tuota display:table jne leveällä näytöllä vasemman ja oikean reunan elementit asemoiviin elementteihin jaolla 75%, 25%.

Loi normaalia taulukkoa muistuttavan rakenteen. Piti vain laittaa float:none ennen float-elementteinä olleille elementeille. Kun se laittoi, taustaväri ja reunukset käyttäytyivät kuin taulukoissa eli "solut" olivat tasakorkeita.

Mutta ulkoasu toimi paremmin kun oikean reunan elementti oli float, koska pääsisällön alareuna näytti huonommalta, jos oikean reunan elementti oli täyskorkea. Alareunaa olisi ainakin pitänyt muuttaa, ettei alareuna näyttäisi hassulta. Lopputulos oli ainakin ilman muutoksia float-elementtiä huonompi.

Eikös gridin ideana ole luoda taulukkoa muistuttava rakenne, joka on float-elementtejä hallitumpi? Vai olenko ymmärtänyt asian väärin?

Eikös display:table, display:table-row; display:table-cell ole MS IE:ssäkin tuettu?

Tietenkin taulukkomaisella rakenteella saa varmemmin oikein käyttäyvän lopputuloksen kuin float-elementeillä.

 

[Tapio X]

Mutta onko tasakorkeudella suurta merkitys muulloin kuin CMS:ssä? Jos joku laittaa ylisuuren objektin float-elementille, jolla ei ole overflow:hidden, jokin elementti siirtyy alle. Taulukkosoluksi määritelty lohko pitäisi vain venyä aiheuttaen vaakaskrollin. Hajoamisvaaraa ei pitäisi olla.

Foorumi: 2.1 WordPress & bbPress | Sanaristikkofoorumi – sanaristikot & muuta pohdittavaa

Ydinkoodi:

#page #main{display:table}
/* #page #main #main-content {display:table-row} */
#page #primary,#page #content-sidebar{display:table-cell}
#page #primary{width:25%}
#page #content-sidebar {width:75%}

Katsoin CSS Grid Layout

Periaatteessa grid on käytännössä sama kuin display:table jne. Molemmissa ideana on luoda taulukkomainen rakenne ilman, että käyttää HTML table jne elementtejä eli selvitään pienemmällä elementtimäärällä.

Koska ei ole pakko laittaa display:table-row, on kaiketi useimmiten ihan sama käyttääkö display:grid vai display:table + display:table-cell.

Molempiin saa periaatteesa soluvälit.

Homman voisi myös laittaa toisin päin. Vanhanaikaisen taulukon voi muuttaa kännykässä lohkoiksi:

@media screen and (max-width:782px){
table.xxx, table.xxx tr, table.xxx td {display:block;width:100%;}
table.xxx td {float:left;}
}

Valinta on kaiketi siinä, mikä toimii luotettavimmin ja on yleisimmin tuettu ja mikä on helpointa toteuttaa ja hallita.

 

[Tapio X]

Ihan tuli mieleen, että jos on vanhat vain tietokonenäytölle tehdyt www-sivut saisi CSS:llä usein varsin helposti kännykälle soveltuvaksi fonttien uudelleen määrittelyillä ja elementtien display-ominaisuudet uudelleen määrittäen. Toimisi ainakin hätäratkaisuna, jos sivuja ei ehditä täysin uudistamaan.

 

[Fanboys Suck]

Nyt melko simppeli tietokoneella yli 783px leveyksillä:
OTSAKE eli HEADER (täysleveä)
LEIVÄNMURUT(täysleveä)
VASEN SISÄLTÖ ja OIKEA SISÄLTÖ (yhteensä 1280px)
ALAOSA eli FOOTER (täysleveä)

Kokeilin tuota display:table jne leveällä näytöllä vasemman ja oikean reunan elementit asemoiviin elementteihin jaolla 75%, 25%.

Loi normaalia taulukkoa muistuttavan rakenteen. Piti vain laittaa float:none ennen float-elementteinä olleille elementeille. Kun se laittoi, taustaväri ja reunukset käyttäytyivät kuin taulukoissa eli "solut" olivat tasakorkeita.

Älä turhaan sekoita floatteja ja esim. gridiä layouttia tehdessä.

Voit aloittaa mahdollisuuksien tutkimisen vaikkapa Grid by Example - Usage examples of CSS Grid Layout sivulta.

Niin siis vielä, gridillä on mahdollista muokata niiden solujen leveyksiä jne. huomattavasti joustavammin kuin tauluilla. Voi määritellä mihin suuntaan, kuinka päin jne. tiedot esitetään, miten lohkot käyttäytyvät kun niiltä loppuu tila ym.

Gridin ja felxboxin myötä weppileiskojen teko alkaa olla ihan lastenleikkiä ja jengi voi alkaa toteuttamaan ihan mitä mieleen tulee sen sijhaa että miettii miten joku asia olisi mahdollista toteuttaa.

Mainitsemasi layout on helppo tehdä vaikkapa grid-arealla: CSS Grid Layout: Grid Areas

 

[Tapio X]

En tarvinnut taulukkomaista vasemman ja oikean reunan asettelua kuin yhteen väriteemaan. Toimivaa ratkaisua ei kannata muuttaa. Mutta jatkossa voi tietenkin ottaa huomioon, jos jotain ihan uutta tekee.

 

[Tapio X]

Minulla tietokoneen kapealla näytöllä (alle 783px) vierityspalkkeihin liittyvä virhe, jota en ole saanut korjattua. Lievensin visuaalista merkitystä määrittämällä vierityspalkeille värit ja kavensin vierityspalkkeja. Virheeseen ei enää juuri kiinnitä huomiota.

Mutta se toimii vain -webkit-verdorprefiksillä. Toimii ainakin Chromium-selaimissa (Chrome, Vivaldi) ja Safarilla siis. Firefox ei taida tukea mitenkään. Onko MS:n selaimille jokin JS?

Chrome on kuitenkin yleisin selain Android ja Windows -ympäristöissä ja Safari iOS-ympäristössä, joten useimmille toimii. Tällä hetkellä Chrome + Safari = 77% (lähde). MS IE + Edge = 9,5%. Tosin tuo ei anna oikeaa kuvaa tietokoneesta, koska tuo koskee kaikkia laitteita. Tietokoneessa Safarin osuus on pienempi ja oletettavasti MS:n selainten osuus on suurempi. En nyt löytänyt statistiikkaa pelkästään läppäreitä ja pöytätietokoneita koskien.

Kun katsoo tilastoja, omilla sivuillani kattavuus on n. 90%. Ei kuukauteen vierailuja MS:n selaimilla ja FF osuus Windows-laitteissa n. 10%. IE:tä ei juuri käytetä. On se joskus näkynyt tilastoissa.

Kovin suurta intoa ei MS:n selaimia ole tukea, mutta jos on suht. yksinkertainen mahdollisuus määrittää sillekin vierityspalkit, sitä voisi käyttää.

 

[nnaku]

Kun kosket IE natiivin scrollbariin, saat luultavast repullisen ikäviä edgecase hoidettavaksi. Mä en kyllä oikeen ymmärrä miksi, hukkaat harraste projun kanssa aikaa johonkin EI ongelmiin... Microsoft itsekkiin kustsuu IE yhteensopivuus ratkaisuksi, ei selaimeksi! Uutta koodia kirjoitettaessa IE tuen rakentamisen ymmrräin oikeastaa vain Julkishallinnon ja isojen korporaatioden prokkiksissa.

 

[Fanboys Suck]

Minä taas en ymmärrä miksi et korjaa sitä alkuperäistä scroll bar bugia vaan kierrät sen jollain epästandardilla tai uudella valmistajakohtaisella fiksillä? Todennäköisesti tälläkin palstalla jos olisit käyttänyt virheen kuvailemiseen yhtä paljon tekstiä kuin mitä käytit yo. viestiin olisi homma jo ratkennut.

 

[Tapio X]

Kun en keksi millään, mistä virhe johtuu, yritin vain vähentää sen vaikutuksen miminiin. Kyse on kahdesta toisiinsa liittyvästä ongelmasta.

1. Selain tekee joillakin sivuilla valikkoon vierityspalkin.
2. Valikko jää joillakin sivuilla vierityspalkin verran alileveäksi, jolloin ikävintä on ylös/alasnuolien näkyminen reunalla osittaisina.

Hankalinta on se, että ongelma ei koske kaikkia sivuja.

Kun kavensin vierityspalkit 7px leveyteen ja vaihdoin värejä, asiaa ei juuri huomaa eikä se ainakaan pistä pahasti silmään.

MS:n selainten tukeen ei nimimerkin "nnaku" kannata panostaa, mikä on varmaankin totta. MS:n selaimet ovat nykyisin marginaalissa - niin ajat muuttuvat.

 

[nnaku]

Kun en keksi millään, mistä virhe johtuu, yritin vain vähentää sen vaikutuksen miminiin.

Sulla on sama ongelma kuin monella suurella IT hankkeilla. Eli kuvittelet että sun tähän asti kehitetty työ olis jotenki arvokata hukattavaksi. Ei ole, sillä ei ole mitään arvoa! Pelkästää noi css on kasa spagettia! Mistä et enään itsekkään osaa sanoa mikä vaikuttaa mihinkin. Pikkupikku bugien korjaaminen vaatii turhanpaljon aikaa, koska ikinä ei tiedä mikä vaikuttaa minnekin ja aina ilmantuu muutama ongema lisää.

Sanoin jo puolivuotta sitten että, vedä vessa ja aloita alusta tän projun kanssa. Säästä siinä aikaa ja pääset aloittamaan puhtaalta pöydältä! Olet sä kumminkin tässä harjoitellessa kartuttanut lisää osaamista, joten osaat ehkä välttää ne pahimmat suden kuopat uudella yrittämällä.

Spoileri: salaisuus

vältä !important enemmän kuin ruttoa!
<p style="color:red;">foobar</p> inline css ei pitäisi käyttää ikinä!
javascriptillä elementille lisätään vain luokkia/selektoreita jotka viittaa css tyyleihin.

 

[Tapio X]

Tiedän kyllä sen, että CSS saisi olla selvempää, jolloin ei kävisi niin, että jossakin kohtaan ei ole selvillä, mikä vaikuttaa mihinkin. Nyt kävi yhden asian suhteen niin, että siihen liittyvää bugia nyt vaan en saa korjattua.

Ihan alusta en aloita, sillä jäljelle jääneet ongelmat ovat pieniä. Jotkut marginaalit voisivat olla parempia, mutta mitään suoranaista bugia muulla en tiedä.

Ihan tiedoksi, että poistin alkuperäiset teeman ja foorumin CSS:t kokonaan ja rakensin ne uudestaan. Jokin seikka vain jäi huomaamatta. Nyt suurin ongelma se, että foorumin uuden version mallinteet eivät toimi halutusti. Piti palauttaa entinen versio. Kun jotain uusitaan, joku voi mennä ihan totaalisesti pieleen.

Sain lopulta muutettua mallinteitani toimimaan uuden version kanssa (melkein samalla lailla). Mutta kun muutoksista on aina todella paljon ylimääräistä työtä, suurempia muutoksia ei mielellään tee.

bbPressin saaminen toimimaan toisen leiskan kanssa on iso työ. WordPress-teemalla on oma värimaailmansa, joka on vain osittain yhteinen bbPress kanssa. Itse foorumilla on paljon omaa CSS:ää, mukaan luettuna omia värimäärityksiä. Värit, fontit, reunukset, mahdolliset varjot ja elementtien leveydet pitää sovittaa yhteen. Kunnon lopputulos edellyttää muutoksia sekä WordPress teemaan että bbPressin CSS-määrityksiin.

XenForo on helpompi tapaus, koska ei ole yhteensovittamista ollenkaan, koska XenForoa ei kytketä toiseen ohjelmistoon.

Parasta bbPressin kannalta olisi se, että olisi olemassa teema, joka on lähtökohtaisesti suunniteltu toimimaan yhteen sen kanssa, jolloin yhteensovittamiselta vältyttäisiin. Riittäisi vain omien muutoksien tuomat CSS-muutostarpeet.

WooCommerce-sovellukselle on olemassa valmis integraatio, joten käytettäessä tiettyä teemaa, ei tarvitse itse luoda integraatiota.

Jos integraatio pitää rakentaa itse, halutunlaisen lopputuloksen luominen on aina työlästä. Jos on korjattavaa, pitää vaan tutkia CSS-tiedostot paremmin. Itsellä CSS on jaettu muutamaan palikkaan.

Oletuksena oleva foorumilistaus on mielestäni perin ruma, ks. :
Forum: Requests & Feedback · bbPress.org

Olen pyrkinyt itse laittamaan sen melko lähelle tämän sivuston tyyliä. Laitoin siitä jopa ehdotuksen (Better looking forum list).

Sen sovittaminen uudestaan toiseen teemaan - ei kiitos.

 

[Miksuu]

jos on tehnyt lähinnä visual studiolla (vs2011) ja asp.net alustalla esim työtilaus kirjaus sivuston, ja nyt kyseinen sivusto kaipais päivitystä nykyiselle vuosikymmenykselle, niin mikä olisi helpoin? tarvis tuota päivittää, ja toki voisin sen tehä vanhalla systeemillä, mutta alkaa risomaan vanha grid/form juttu, jossa lähes aina koko sivu välkyy (no on siellä javascriptiäkin ja muuta mutta karrikoisin hieman)

 

[Stephen Elop]

jos on tehnyt lähinnä visual studiolla (vs2011) ja asp.net alustalla esim työtilaus kirjaus sivuston, ja nyt kyseinen sivusto kaipais päivitystä nykyiselle vuosikymmenykselle, niin mikä olisi helpoin? tarvis tuota päivittää, ja toki voisin sen tehä vanhalla systeemillä, mutta alkaa risomaan vanha grid/form juttu, jossa lähes aina koko sivu välkyy (no on siellä javascriptiäkin ja muuta mutta karrikoisin hieman)

Jatka sillä asp.net:llä koska on tuttu. Toiset IDE:t, kielet ja API:t ei ole mikään suuri oikotie onneen. Välkyntä on varmaan joku bugi koodissa. Helpoiten selvität tekemällä toisen samanlaisen projektin ja lisäämällä siihen sitten pala kerrallaan vanhasta ja katsot milloin alkaa välkkymään. Sitten selvitys miksi ja lopuksi korjaus.

 

[Miksuu]

Jatka sillä asp.net:llä koska on tuttu. Toiset IDE:t, kielet ja API:t ei ole mikään suuri oikotie onneen. Välkyntä on varmaan joku bugi koodissa. Helpoiten selvität tekemällä toisen samanlaisen projektin ja lisäämällä siihen sitten pala kerrallaan vanhasta ja katsot milloin alkaa välkkymään. Sitten selvitys miksi ja lopuksi korjaus.

välkkyminen enimmäkseen postback yms juttujen takia, kun tuo web koodaus on vieraampi, niin voi olla et on kaikki tekniikka sivustossa pyllystä enemmän kun olen koodannut sovelluksia, arduinoita, plc yms.. ja kun en ole seurannut hirveästi tuon kehitystä/tekniikoita ni oikeen tie ees mitä katselis "ajankuluks". Nähnyt kyllä sivuja joissa toiminta juuri mitä itseki haen, mutta ei hajuakaan miten/millä ne on toteutettu, eikä haisua mistä hakisin sen infon, juurikin kun web mailma on "vieraampi".
projekti on siis sellainen, että kaikki on sql kannassa, ja sitä pääosin käytetään sovelluksen yli, johon aikoinaan oon osittain tehnyt web sovelluksen, nyt sitä pitäisi laajentaa, ja mieluusti saada puhelinystävälliseksikin, sivusto olisi siis lähinnä kannasta hakua, vientiä ja päivitystä. myös raportteja kannasta, mutta ne on crystalreportsilla, ja niitä tarkoitus ajaa jatkossakin.

 

[Starg]

Ensimmäinen viesti tälle palstalle ja olisi heti kysymys Wordpress ja WooCommerce tietäjille. Saattaa olla tyhmä kysymys, mutta kysyn joka tapauksessa ettei tule tehtyä turhaa työtä.

Olen nyt siis tehnyt verkkokaupan ulkoasua käyttämällä HTML, CSS, JS ja Bootstrap. Tarkoitus olisi tehdä tästä oma WooCommerce teema, mutta en ole varma mitä kaikkea tohon pitää itse tehdä? Esimerkiksi pitääkö checkout sivu tehdä itse, vai hoitaako WooCommerce tuon automaattisesti? Kokemusta ei hirveästi noista ole, joten kysytään viisaammilta.

YouTuben tutoriaaleja olen kahlannut läpi, mutta ei ole tämä ihan selväksi tullut. WooCommercen docseja olen myös lukenut, mutta ei ihan ole tohon mun kysymykseen vastannut.

 

[debuggeri]

välkkyminen enimmäkseen postback yms juttujen takia, kun tuo web koodaus on vieraampi, niin voi olla et on kaikki tekniikka sivustossa pyllystä enemmän kun olen koodannut sovelluksia, arduinoita, plc yms.. ja kun en ole seurannut hirveästi tuon kehitystä/tekniikoita ni oikeen tie ees mitä katselis "ajankuluks". Nähnyt kyllä sivuja joissa toiminta juuri mitä itseki haen, mutta ei hajuakaan miten/millä ne on toteutettu, eikä haisua mistä hakisin sen infon, juurikin kun web mailma on "vieraampi".
projekti on siis sellainen, että kaikki on sql kannassa, ja sitä pääosin käytetään sovelluksen yli, johon aikoinaan oon osittain tehnyt web sovelluksen, nyt sitä pitäisi laajentaa, ja mieluusti saada puhelinystävälliseksikin, sivusto olisi siis lähinnä kannasta hakua, vientiä ja päivitystä. myös raportteja kannasta, mutta ne on crystalreportsilla, ja niitä tarkoitus ajaa jatkossakin.

Teet tietojen haun ja tallennuksen edelleen siellä asp.net:ssä, mutta käyttöliittymän teet uusiksi esim. vue.js:llä Vue.js

Käyttöliittymästä teet sitten kutsuja sinne asp.net:iin.

 

[Miksuu]

Teet tietojen haun ja tallennuksen edelleen siellä asp.net:ssä, mutta käyttöliittymän teet uusiksi esim. vue.js:llä Vue.js

Käyttöliittymästä teet sitten kutsuja sinne asp.net:iin.

no tuo ainakin nopsaan vaikutti suht hyvältä, kun suurin ongelmai on juurikin tuo käyttöliittymä..
mites suhtautuminen noihin valmiisiin vue ui paketteihin on? äkkiseltään tuntuisi et niillä pääsisi helpommalla tuon käyttöliittymän kanssa, jossa se suurin haaste on omalla kohalla View ui nyt ainakin tuli vastaan, ja nopsaan ois aika tarvittavia komponenteja het suoraan, vai onko jotain parempaa?

 

[jhalmu]

Svelte kannattaa myös tsekata. Erinomaisen helppo lähestyttävä, vaikkei vuekaan niitä vaikeimpia.

 

[©©©]

no tuo ainakin nopsaan vaikutti suht hyvältä, kun suurin ongelmai on juurikin tuo käyttöliittymä..
mites suhtautuminen noihin valmiisiin vue ui paketteihin on? äkkiseltään tuntuisi et niillä pääsisi helpommalla tuon käyttöliittymän kanssa, jossa se suurin haaste on omalla kohalla View ui nyt ainakin tuli vastaan, ja nopsaan ois aika tarvittavia komponenteja het suoraan, vai onko jotain parempaa?

Vue Material Design Component Framework — Vuetify.js