Gå til innhold

PHPdude

Medlemmer
  • Innlegg

    988
  • Ble med

  • Besøkte siden sist

Innlegg skrevet av PHPdude

  1. For å bruke absolutt posisjonering i forhold til andre foreldre-elementer enn body/html, så kan du sette "position:relative;" på det elementet du ønsker å posisjonere i forhold til.

     

    Merk også at absolutt posisjonering veldig sjeldent er noen god fremgangsmåte. Mest sannsynlig så bør du lese deg bedre opp på CSS generelt, så finner du nok en bedre løsning.

  2. For å skjule/stoppe tilgang til de forskjellige objektene på siden. Eller fordi man tror at siden har tekniske kvaliteter man vil prøve å hindre at andre får innsikt i.

     

    Dette er en tåpelig blindgate, som uansett kun fungerer i veldig liten grad.

    Ønsker man ikke hvem som helst tilgang til det man publiserer, så får man heller la være å publisere det fritt tilgjengelig.

  3. For øyeblikket blir nettlesere nødt til å laste de samme bakgrunnbildene på nytt for hver nye side som vises. Grunnen er at av en eller annen veldig tvilsom grunn, så har akkurat det samme bildet fått forskjellig URL.

     

    http://www.thesenights.com/These_Nights/Th...es/bakgrunn.jpg

    http://www.thesenights.com/These_Nights/Th...es/bakgrunn.jpg

    http://www.thesenights.com/These_Nights/Th...es/bakgrunn.jpg

     

    Så selv om HTTP-cachingen fungerer brukbart, så blir nettleseren nødt til å laste inn det samme bildet for hver eneste nye side som skal vises.

     

    Du må altså sørge for at hvert bilde kun har en URL, og at denne ene riktige URLn brukes på alle sidene. Da skjønner nettleserne at det er det samme bildet og trenger ikke å laste det ned på nytt og på nytt.

     

    Det samme problemet gjelder altså også for dette bildet:

    http://www.thesenights.com/These_Nights/Th...hapeimage_1.png

  4. "div" er ikke mer riktig nei. Det som er riktig er å bruke de elementene i HTML som best matcher den aktuelle strukturen.

    I dette tilfellet ser det ut til å være en nøstet liste ala dette:

    <ul id="links-menu">
     <li>
    <h3>Nettaviser</h3>
    <ul>
      <li>VG</li>
      <li>Dagbladet</li>
      <li>VG</li>
      <li>Dagbladet</li>
      <li>VG</li>
    </ul>
     </li>
     <li>
    <h3>Diskusjonsforum</h3>
    <ul>
      <li>diskusjon.no</li>
      <li>kvinneguiden</li>
      <li>diskusjon.no</li>
      <li>kvinneguiden</li>
      <li>diskusjon.no</li>
      </ul>
     </li>
     <li>
    <h3>IT-nyheter</h3>
    <ul>
      <li>hardware.no</li>
      <li>itpro.no</li>
      <li>hardware.no</li>
      <li>itpro.no</li>
      <li>hardware.no</li>
    </ul>
     </li>
     <li>
    <h3>Emulation</h3>
    <ul>
      <li>emu hq</li>
      <li>dcmu.no</li>
      <li>emu hq</li>
      <li>dcmu.no</li>
      <li>emu hq</li>
    </ul>
     </li>
    </ul>

     

    Noen enkle CSS-linjer ser ut til å gi deg akkurat den layouten du ønsker:

    ul#links-menu > li {
     display:inline-block;
    }

    Alternativt ser ut til at det fungerer greit å bytte ut "display:inline-block;" med "float:left;" for bedre nettleserkompatibilitet.

  5. Interessant, men kor mykje lastingstid sparer ein egentleg på dette?

    Som det ble sagt ovenfor: "Ikke merkbart"! Selv om du bryr deg om et par tusendels-sekunder, tviler jeg på at det er noe som helst å hente.

    Sammenligner man en vanlig dårlig SGML-HTML-suppe, mot XML, som kan parses strict, er det nok en stor forskjell i ren parsing-tid på de iforhold til hverandre, men selv da blir det absolutt minimalt utslag på den totale lastetiden.

  6. For det første tråkker han i salaten når han klart viser manglende forståelse for hva HTML er, og dermed argumenter for at HTML bør løse noe HTML ikke er ment å skulle løse. Enhver kan skjønne at det er høyst tvilsomt.

     

    Videre viser han hvor dårlig han kjenner CSS, ved for eksempel å overse at uansett hvordan man vrir og vender på det så kan umulig CSS være noe dårligere for layout enn HTML-tabeller, fordi CSS har akkurat de samme layout-egenskapene som HTML-tabeller gjennom "display".

    http://www.w3.org/TR/CSS21/tables.html

     

    Også setter han spikeren i sin egen kiste ved å belaste CSS for de svakhetene som er Internet Explorer sitt problem.

     

    CSS har helt klart sine svakheter, og debatten rundt dette er absolutt interessant, men den fortjener å baseres på kunnskap om svakhetene - ikke uvitenhet om HTML/CSS!

    To ting er vertfall helt sikkert:

    1. CSS er ikke perfekt, og en bedre løsning er selvfølgelig mulig.

    2. Bruke HTML til styling/layout gjennom tabeller, er ikke en bedre løsning.

  7. Det er kjent at IE generelt sliter veldig med det aller meste, men div-tags er ikke blant de kjente problemene...

    Du må nok lete etter problemet et annet sted, høyst sannsynlig i CSS-støtten. Også er både IE6, IE7 og IE8 i aktiv bruk, så vil være lurt å nevne hvilke av versjonene som krangler :)

     

    PS: <div> er ment å markere opp områder/seksjoner i dokumentet, så <div> for bilde-wrapping høres tvilsomt ut.

  8. Obligatorisk lesing for alle seriøse webutviklere: http://www.w3.org/Provider/Style/URI

     

    Som ChristianW sier så må man heve seg over de tekniske preferansene/begrensingene i f.eks. klassiske PHP-løsninger for virkelig å skjønne dette.

    En URL som http://example.com/index.php?page=3 er fullstendig borti natta tåpelig, og kun aktuell fordi utviklere bruker verktøy, som ikke tilrettelegger for noen bedre løsning.

  9. Sukk... er det ikke på tide at du legger fra deg aluminiumshatten og heller venter med å uttale deg til du vet noe? Dette begynner å bli latterlig.

     

    Det vi vet er at Microsoft har to produkter med lønnsomhet som et middels seddeltrykkeri, og at disse to i stor grad hjelper hverandre til fortsatt suksess.

    Ja, det er kanskje vel drøyt med ren synsing om hva de har "sikret seg", men at det er latterlig å mene at et aksjeselskap vil ta i bruk så effektive produkt-sammenkoblinger for å opprettholde inntektene, uten å blunke? Nei.

     

    Videre får Simen1 presisere hva han faktisk mener. Min oppfatning er at dette foreløpig mest er et grep fra MS for å sikre seg kontroll, istedenfor at f.eks. Google stikker av med (hele) kaka. Hva slags koblinger til resten av "MS-pakka", som kan bli aktuelt er mindre viktig, det viktige er at muligheten og "motivet" er der så til de grader.

  10. Hmmm.. Nå vet vi hva microsoft bruker ressurser på :yes:

     

    Lurer du fortsatt på hvorfor Windows koster så mye?

     

    Ikke bare det, men også: Lurer du fortsatt på hvorfor det tar så lang tid mellom hver nye IE-versjon? Lurer du fortsatt på hvorfor IE sin støtte for web-standarder bare blir dårlige og dårlige iforhold til de andre nettleserne?

  11. Dere som misliker silverlight, har dere hatt noe problem med det?

    Nei, ingen tekniske problemer. Ikke at jeg er noen SL-bruker heller, men tviler ikke på at MS har laget et produkt som er veldig attraktivt for utviklere som allerede er på MS sine plattformer.

     

    Eller er det bare fordi microsoft lager det og/eller det ikke støtter deres favoritt operativsystem?

    Sikkert veldig behagelig å kunne avfeie motpartens synspunkter som irasjonelle følelser og/eller personlige behov.

    Håper ikke du prøver å lure debatten inn i den fella.

     

    Angående å lage det i html i stede, så tar det i beste fall ganske mye mer tid og vil gi tregere kjøretider og dårligere sikkerhet (javaskript er foreløbig både tregt og usikkert, men det jobbes det jo med). Html forkjempere må jo gjerne være med å betale denne ekstra kostnaden.

    Hadde det bare stått på HTML (og andre relevante web-standarder) så! Dessverre stanges det langt mer i den elendige standard-støtten i IE, som er håpløst langt bak alle de andre nettleserne og bare havner lenger og lenger i bakleksa.

    Det er sikkert tilfeller hvor Silverlight vil være det mest egnede kun utifra tekniske egenskaper, men det skulle jo bare mangle, og på den andre siden er typisk vanlig web-innhold i bøtter og spann hvor en simpel HTML/CSS-modell er det klart mest effektive selv innenfor IE sine rammer.

     

    Også: MS-forkjemperne må gjerne få "være med å betale" den ekstra kostnaden som IE påfører all webutvikling...

  12. Må og må fru Blom...

    I hvilken grad man støtter IE er en sånn ting som hver enkelt må bestemme selv, utifra sine behov.

    Men du har helt klart rett i at man kan ikke la være å bry seg om IE i det hele tatt, i de aller fleste tilfeller.

     

    Når det gjelder IE-støtte er det altså viktig å merke seg at det ikke trenger å være enten eller, men heller en mellomting hvor IE også fungerer helt greit - bare at mer kapable nettlesere fungerer enda bedre.

     

    I denne saken vil det ikke bety annet enn at IE ikke får fine avrundede hjørner.

  13. Huff, er IE virkelig så langt etter altså.

    "10 år" var ikke noe stort forsøk på å være presis akkurat, men ser man på CSS2 så tok det 10 år fra funksjonaliteten var standardisert til den var på plass nå med IE8. Alle de andre nettlesere støtter allerede flere av CSS3-modulene, så IE er allerede noen år i bakleksa med CSS3...

    Fungerer Border-radius helt likt? Altså, må jeg spesifisere hvert enkelt hjørne i fire linjer? Eller holder en linje for alle hjørnene?

    Syntaksen for de tre er hovedsaklig helt lik tror jeg.

     

    border-radius:6px; /* Alle hjørnene 6px */
    border-radius:3px 6px 9px 12px; /* Forskjellig avrunding av alle hjørnene */

     

    border-radius er jo da ikke ferdig, så syntaksen kan endre seg, men vertfall -moz-border-radius og -webkit-border-radius fungerer slik.

  14. Du kan absolutt sette inn alle ja. Det siste kode-utdraget mitt fra forrige post er fullt fungerende.

     

    Angående CSS3 så er ikke det en standard, men en rekke forskjellige moduler, som hver utvikles for seg, og som tilsammen går under "kallenavnet" CSS3.

    De forskjellige modulene er i varierende grad ferdig. Noen moduler er "Candidate Recommendation" (så godt som ferdig), mens andre moduler kun er "Working Draft" (skisse).

    Flere av CSS3-modulene er allerede fullt støttet av både Firefox, Safari og Opera.

     

    Full oversikt over hvilke moduler som utgjør "CSS3" og deres status finnes her: http://www.w3.org/Style/CSS/current-work

     

    Alt det som går inn under "CSS3" kommer til å ta lang tid før er ferdig, men plukker man ut enkeltdeler så er svaret på når en kan ta det i bruk ganske enkelt: Når du synes at nok nettlesere har støtten. For noen vil det bety å vente 10 år på at IE får støtten, mens for noen andre vil det bety å vente 1 år på at en av de moderne nettleserne får støtten.

  15. Du ser det på "-moz-"-prefixen. Det er den Mozilla bruker når de skal prøve støtte standarder som ikke er stabile/ferdig ennå. Mozilla har en rekke elementer de støtter med "-moz-"-prefix. Det samme gjelder for WebKit (Safari) med "-webkit-" og IE med "-ms-" og Opera med "-o-.

     

    Det kommer altså aldri til å bli noen andre nettlesere enn Firefox som støtter -moz-border-radius. Det "ekte" elementet som kommer til å bli støttet av de fleste nettleserne etterhvert er border-radius.

     

    WebKit har en tilsvarende eksperimentell støtte som Mozilla, så for Safari og andre WebKit-baserte nettlesere kan du bruke -webkit-border-radius.

     

    -moz-border-radius:6px; /* For Mozilla */
    -webkit-border-radius:6px; /* For WebKit */
    border-radius:6px; /* For nettlesere som kommer til å støtte den ferdige standarden */

  16. For meg føles Opera lynkjapt, så hvor mye dette kan ha å si lurer jeg på.

     

    Det gjør kun betydelig utslag på sider med krevende Javascript-operasjoner. Sånne sider finnes knapt overhodet i dag, og da stort sett som teknologi-demoer. Men bedre JS-ytelse åpner en del gode muligheter fremover, så det er i grunnen fint at nettleserne tas litt ekstra i skinnet på det området.

     

    Selv for de sidene vi i dag regner som "tungt scriptede" (f.eks GMail), så har selve Javascript-ytelsen ganske liten betydning. Langt viktigere er ytelsen til generelle renderings-operasjoner gjennom DOM.

    For ikke-programmerere kan Javascript beskrives som det språket som brukes til å fortelle arbeiderne hva de skal gjøre, men selv om man leser opp instruksjonene 10 ganger raskere betyr ikke det at arbeiderne får gjort jobben 10 ganger raskere...

×
×
  • Opprett ny...