Udtrykke det

Re-Cycling er Buzzword og i Webudvikling betyder det ikke anderledes. Det sparer energi, i form af indsats!

Over år med at skrive CSS og skabe HTML fra design, har jeg fulgt nogle af bedste praksis, i jagten på at spare tid og energi i det, vi normalt betegnelsen som "Re-opfinde den dybe tallerken". Igen og igen har jeg fortalte mig selv, at jeg skal skabe nogle skabeloner, nogle standard genbruges CSS, som jeg ville bruge UD AF BOKSEN i mit fremtidige arbejde. Selvom det ikke helt, men jeg lykkedes at opnå nogle mål.

I fremme, Re-brug af CSS havde jeg et kig på de få CSS rammer, der er almindeligt tilgængelige for os, og besluttede at sætte dem til at bruge, da disse er afprøvet og testet og skabt af meget erfarne udviklere, end mig selv. Endnu vigtigere "UNDGÅ genopfinder".

Selvom almindelig viden til veteraner, har jeg forsøgt at pen nogle af de vigtigste begreber / bedste-praksis / tanker, der er lagt i at skabe disse rammer, at RE-CYKLING af CSS muligt. Håber dette vil hjælpe nogle CSS udviklere, der er lige ved at, og for nylig gik ombord på CSS vognen!

Keys Re-cykel af CSS:

Brug Navngivningskonventioner

Dette må være den vigtigste faktor i at gøre CSS / HTML genbruges. Give konsistente navne til sideelementer muliggør genbrug af siden komponenter og deres stil med lidt eller modifikationer. I tråd med dette argument, HTML5 selv, i en væsentlig ændring ændring i forhold til sine forgængere, er at indføre nogle strukturelle tags dvs. <article>, <section>, <header>, <aside>, og <nav> [ Hvad vil HTML5 medbringe? ]. Selv med HTML 4 (eller lavere), er det bedst at nævne standard dele af din side consistanly som i den simple eksempel nedenfor ...

Husk, de fleste sider på dit projekt, ender med at have de samme centrale strukturelle elementer. Identificere disse fælles grundlæggende sideelementer ....

  <div id="container">
    <div id="header"> ... </ div>
    <div id="nav"> ... </ div>
    <div id="sidebar"> ... </ div>
    <div id="footer"> ... </ div>
   </ Div> 

Nulstil standardstiler (CSS nulstiller): Uanset om du bruger en ramme eller skriv din egen, skal du give CSS Nulstiller [ Hvad er CSS Nulstiller? ], da de reducerer eller sommetider fjerne visuelle uoverensstemmelser, der opstår mellem forskellige browsere. I simple ord CSS Reset Mechanism sætter stilarter HTML Element til nul eller null værdier, og dermed tilsidesætter enhver browser standardværdier kan de udgør. Dette giver en ren tavle at indstille egenskaberne af disse elementer uden for enhver User-Agent Defaults [ CSS2.1 User agent typografiark Defaults ]. Alle de CSS rammer har af reset-mekanisme. Hvis du skriver dit eget CSS Nulstiller, et advarende ord er, at hvis du tilfældigvis til at glemme at nulstille en vigtig egenskab, kan det føre til cross-browser problemer, som er meget svære at fejlrette. Husk, Behold en kopi af reset stilarter og slippe dem i hvert nyt projekt, du opretter.

  krop, div, dl, dt, dd, ul, ol, li,
  h1, h2, h3, h4, H5, H6,
  før, form, fieldset, input, skal du vælge, textarea,
  p, blockquote, tabel, th, td
  {
    kant: 0px;
    margin: 0;
    padding: 0;
  } 

Angive standarder (Baseline Styles) til Elements:

Når du har angivet (til nul eller nul) standardværdier for visse egenskaber af visse HTML-elementer, er det nødvendigt at anvende nogle stilarter på tværs af alle forekomster af disse elementer. Disse standardindstilling kan variere som pr design eller efter den bedste praksis, du følger.

De fleste CSS rammer, altid introducerer nogle nye standarder, ud over at nulstille standardbrowser stilarter.
Disse standarder er ugyldig af User-Agent Defaults (skrællet væk af CSS Reset), vil disse være konsistent på tværs af browsere.

Husk, at baseline-stilarter bruges til at indstille stilarter, som vil blive anvendt design-bred. f.eks.

  html {font-size: 77%; font-family: Arial, sans-serif;}
 stærk, h1, h2, h3, h4, h5, h6 {font-weight: fed;} 

Abstrakte Styles for almindelige HTML-Komponenter og almindelige klasser:

De fleste projekt bestående af flere sider vil have fælles HTML-elementer bruges på tværs af webstedet, for fx nogle slags former, advarsler og fejl, Custom popups, lightboxer osv. Da sådanne komponenter anvendes igen på tværs af projekter, vil det være nyttigt at give et sæt af klasser i forbindelse med foruddefinerede typografier for disse komponenter, og du kan spare dig selv en masse tid.

Bortset fra at definere genanvendelige stilarter definitioner for de fælles HTML komponenter, kunne vi abstrakte stilarter klasser vedrørende typografi, farve eller endda layout. Jeg har en tendens du bruger ... almindelige klasser som Clearfix, Font08, FontGrey, AlignL, DisplayB osv.

  form, input {border: 0px; baggrund: # ffffff; padding: 0px 10px; _padding: 0px 0px; Højde: 26px; color: # 000000; line-height: 30px; font-size: 1.1em;}
 form, textarea {border: 0px; baggrund: # ffffff; color: # 000000; font-size: .9 em; line-height: 1.5em; overløb: synligt;}
 . Fbold {font-weight: fed, farve: # CCCCCC;}
 . Fgrey {color: # 666666;}
 . Flightgrey {color: # bbbbbb;}
 . Clearfix {klart: begge;}
 . Divider {border-top: 1px solid # 647B06; border-bottom: 1px solid # 9CC00A, højde: 0px;}
 . Displayb {display: block;}. Displayn {display: none;}
 . Alignr {text-align: højre}. Alignc {text-align: center}
 . Floatr {float: højre;}. Floatl {float: left;} 

Rettelser til almindelige browser særheder

Forskellige browsere implementere CSS kode og med varierende grad af støtte til CSS specifikationerne. Resultatet af denne .... "Browser Quirks", at vi udviklere er tilbage til at tackle. Især IE6 hjemsøger de fleste CSS kodere med en frist til at opfylde. Den gode nyhed er erfaring har samlet mulige Genanvendelige rettelser til disse spørgsmål (ofte betegnes som CSS Hacks ).

Husk, Hold disse hacks / fixes handy

  / * Følgende zoom: 1 regel er specifikt for IE6 + IE7.  * /
    * Html. Clearfix,
    *:. Første barn + html clearfix {
           zoom: 1;
      } 

Hold Forbedring af din CSS

• Den vane med at re-cykling vil ikke komme til dig i dag. Det skal udvikles. Så planlægge din Re-Cycling. Husk dette i tankerne, at man kunne abstrakte standard stilarter, typografi definitioner, layout, HTML-element stilarter osv. Prøv at tænke fremad.
• Også ser tilbage på dine tidligere projekter, vil det hjælpe med at identificere typografier, som du har tendens til at bruge ofte på tværs af porjects. Abstract det.
• Fjern eventuelle ubrugte stilarter. Denne praksis vil holde din CSS rammerne af en fælles symptom kaldes "oppustethed" -
• Fjern gentagne stilarter.
• Byg et sæt af stilarter, der er fleksible nok til at overføre det på tværs af projekter.

Et kig på CSS Frameworks

Endelig. Hvis du bliver inspireret og har til hensigt at anvende en eller flere af de CSS rammer, Heres er hurtig liste over nogle populære dem ....

• 960 Grid System : Den 960 Grid System er et forsøg på at strømline webudvikling arbejdsgangen ved at give almindeligt anvendte dimensioner, baseret på en bredde på 960 pixels. Der er tre varianter: 12, 16 og 24 søjler, som kan anvendes separat eller i tandem. Thought noget, du ikke kan oprette en for din egen nemt nok, den rammer giver grid skabeloner til tryk i PDF-format, at man kan bruge til at tegne din side designs.Bet, ville det gøre et professionelt indtryk, hvis du medbringer nogle få ark, når du går til en klient til UI krav indsamling. Det giver også grundlæggende grid skabeloner til populære design software som Fireworks, Flash, InDesign, Illustrator, Photoshop, Visio, osv. giver en "starter for ti" for at starte dit design arbejde.
• Handleplanen : Blueprint giver tydeligt klassificeret CSS-filer til Nulstiller, gitre, formularer, Print, typografi, plugins til knapper, faneblade og sprites osv. Det giver også støtte til IE som en særskilt omfatter.
• SenCSs : I modsætning til ovenstående to, SenCSs (udtales Sense) ikke har CSS-definitioner for Layout. Det gør omfatter skrifttyper, polstring, marginer, tabeller, lister, overskrifter, blockquotes, formularer og meget mere.
• BlueTrip : Dens oprindelige krav til berømmelse var, at det var en kombination af de bedste funktioner fra andre andre rammer som blå print, Trip oli ... fra, hvor det får sit navn. Dens funktion sæt inkluderer 24-kolonne grid, typografi stilarter, Orm stilarter, print, knapper mv
• YUI Grids : Bragt til dig af den Yahooo Developer Network, understøtter væske-bredde (100%) layout samt forprogrammerede fast bredde layout på 750px, 950px, og 974px, samt mulighed for nemt at tilpasse til ethvert nummer. Som du kan se, den teknisk kun layout komponenter. YUI også HTML / CSS sæt til andre sideelementer
• YAML (Yet Another multikolonne Layout)
• Emastic

Husk, ved hjælp af CSS rammer betyder ikke, at du er doven til at skabe en af ​​dine egne ... Det betyder, at du er smart at lære af andres erfaringer og fejltagelser, spare tid og øge produktiviteten!!

Med min begrænsede færdigheder-sæt med værktøjer som Photoshop og Illustrator, kan jeg ærligt indrømme, at jeg er bedre udvikler end jeg er en designer. Men min baggrund med kerne (server side) udvikling med Java / PHP / COBOL, har været en meget positiv indflydelse på mine UI udviklingskompetencer. Hvad jeg mener er, og samtidig skabe mine designs, dvs når jeg laver design, tænker jeg, hvordan design kan bedst omdannes til HTML-CSS og samtidig gøre HTML-CSS, giver jeg en tanke om backend teknologi og gøre rimeligt sikker at HTML let kan implementeres i XSL loops eller PHP snippets osv.

Over årene har jeg været kastet hovedet på design af UI designere, som formentlig donot har en anelse om, hvad HTML eller CSS er. Alle disse år har jeg tænkt at jeg ville bede om for meget, hvis jeg bare forventer, at designeren, der forsøger at shov hans "umuligt at kode" design ned i min hals, for at forstå bare en lille smule, hvad hans design ville blive konverteret til. Det ville hjælpe ret?

Så faldt jeg over dette indlæg i dag ... webdesignere, der ikke kan kode ... Tak Herre! Jeg er bare en af ​​mange, der føler det samme ... Ovenstående artitle er en smule lang forpustet .. men værd at læse, hvert eneste ord af det.

Thanks Elliot Jay Aktier ... jeg føler mig lettet!

Her er nogle uddrag fra Elliots artiklen .

Wow, sikke en dag! Det startede med en lille tweet og sluttede med en diskussion, der syntes at feje hele web design-community. Det ser ud til der er nogle meget stærke holdninger om emnet, om web-designere bør være i stand til at kode.
...
Så før vi komme ind på dette, lad mig hurtigt opsummere, hvad jeg sagde i morges på Twitter:

Helt ærligt, jeg chokeret over, at i 2010 jeg stadig kommer på Tværs 'web-designere', der ikke kan kode deres egne designs. Ingen undskyldning.

... Jeg skulle have været lidt mere specifik i mit tweet. Jeg talte om designere, der ikke har selv de mest grundlæggende HTML og CSS færdigheder til at slå et fladt design til en egentlig hjemmeside. Ikke folk, der bevidst vælger ikke at koden; dem, der ikke kan. Og jeg også kun at henvise til front-end kode her, selvfølgelig er det latterligt at tro, at designere bør også være fantastiske back-end-programmører ...

Vi får 'web' design sendt i Illustrator, 300dpi, umulige at kode, ingen konsistens / usability.
~ Amy Mahon

Det bliver sent, og jeg har fået at pakke dette op en eller anden måde. Jeg ved, at der vil være mange der er uenige med mig, og min hensigt er ikke at fornærme eller forstyrre nogen, der ikke kan kode, men jeg håber, at noget af det jeg har sagt afspejler nogle af de punkter, der altid kommer op, når dykke ned i denne debat.

I slutningen af ​​dagen, kan jeg ikke miste noget søvn over, hvem der kan kode, og der ikke kan. Jeg er bare virkelig overrasket over at finde så mange designere, der mangler frontend-færdigheder, som jeg troede det var en saga blot.

Læs også kommentarerne, der var omkring 320 kommentarer, som jeg skriver ... de er værd at læse.
Læs Elliots hele indlægget her .. webdesignere, der ikke kan kode

I går, efter emne, jeg mødte med CSS Nulstiller i Google Chrome ... Jeg tænkte på at grave lidt dybere ind i det område af User Agent Style Sheets ...
Fundet denne tabel på standardværdier for CSS2.1 User agent Style Sheets ... (for dem, uvidende om, hvad "User agent Style Sheets", er at følge Hvad er User agent Style Sheets (specifikation) .

For en komplet liste over CSS 2.1 User agent Style Sheets standarder klik her

I går, ligesom alle andre "Ground Hog Day", arbejdede jeg på nogle CSS / tableless layouts. Alt gik godt i IE 7, FF 3 og Chrome, indtil pludselig, så jeg nogle un-ignorable margener kun ses i Google Chrome. Selvom meget mærkeligt og worring, det var nogle nye fejl / spørgsmål, som jeg var kommet accross, var der endelig lidt krydderi i mit verdslige arbejde. Trist (men dejlig) det fik fastsættes inden for få minutter af sonden ...

Dybest set, Det lignede Google Chrome ignorerede min CSS Nulstiller (margin: 0px). Det faktisk var forårsaget af brugeren agent stylesheet (-webkit-padding-start: 40px). Så løsningen var at nulstille denne stil ved at sætte padding: 0 de opfører sig elementer.
En god måde at undgå dette problem sker for ethvert element er at bruge en global CSS Rest som følger

* {Margin: 0; padding: 0;}

Hvad er User agent Style Sheets (specifikation)?
Følgende uddrag er taget fra http://meiert.com/en/blog/20070922/user-agent-style-sheets/ , fulgt linket for at læse mere om User agent Style Sheets

CSS 1 introducerer ideen med, at hver bruger Agent (UA, ofte en "web browser 'eller' web-klient") vil have en standard style sheet der præsenterer dokumenter inden for en rimelig - men nok banalt - måde. CSS 2 siger, at der opfylder brugerens agenter skal anvende en standard style sheet (eller opfører sig som om de gjorde), og at en brugers agent standard-stylesheet skal præsentere elementerne i dokumentet sproget på måder, der opfylder de generelle præsentation forventninger til det dokument, sprog; CSS 3 er sandsynligvis af samme mening.

Da CSS specifikationerne lade det være op til implementeringer, om at bruge en "rigtig" style sheet til standard display eller ej, er det ikke forbavsende, at du ikke kan finde en standard style sheet i alle browsers installationsmappe. I modsætning til Microsoft Internet Explorer såvel som Opera, (og så vidt jeg ved) for eksempel gøre Gecko browsere som Firefox og Netscape Navigator (se efter "html.css"), men også Konqueror det temmelig nemt at forstå deres standard styling.

Hverken jeg er meget ny til User Interface (UI) udvikling eller er jeg en veteran, og som jeg altid sige det, jeg passer ind i profilen af ​​UI udvikler mere end en designer, med ikke fortrudt. Nå ja! Hvad var jeg skrive om? ... For et stykke tid (skal være i år ikke mindre) nu i ny og næ, når jeg kommer ind i en lidt UI Design (når professionel designer er gået på ferie), jeg altid kan ikke stoppe med at tænke, om mit design skal være korrekt complient eller ej (oprigtigt, ikke at jeg kunne arkiv 100% overholdelse af standarder, hvis jeg ville også). Så jeg siger til mig selv, hvad lort! ... Designet skal være enkel, pæn og først og fremmest synes anvendeligt, det skal ikke gøre besøgende løbe væk ... eller bounce (for at være teknisk). Hvad godt ville en dejlig tableless CSS layout være at den besøgende, der er uvidende om alle de smarte hypertekst og Cascading Style Sheet under huden på din webside ... Zilch!
Det skal se godt og være let at bruge ... så kommer alle standarder ting.

Jeg stumbbled accross dette blogindlæg af Jason Fried af 37 Signals (For dem der ikke er klar 37-signaler er onces, der har skabt nogle fantastiske web-apps som Basecamp, Campfire osv.), der skrev noget lignende i 2004, og tro mig, næsten 5 år og ikke meget har ændret sig siden, at ... jeg var glad for at læse sin post, da jeg er helt enig i, hvad han har at sige og også det faktum, hendes er ikke sikker på, hvad der fortæller om sin netop sin mavefornemmelse, og så er mit

Jason Fried: "Der er alt for megen snak om CSS og XHTML og standarder og tilgængelighed og ikke nok tale om mennesker. CSS og standarder i overensstemmelse kode er blot værktøjer - du skal vide hvad man skal bygge med disse værktøjer. Fantastisk, jeg er glad for jeres UI ikke bruge tabeller. Så hvad? Hvem bekymrer sig om det stadig ikke lade folk nå deres mål. Web standarder er store, men folks egne standarder omfatter at få tingene gjort (og det er stadig for svært at gøre online).

UI designere gør det samme gamle grundlæggende "at glemme menneske på den anden side" fejl - undtagen denne gang deres kode ser bedre ud. Mennesker - ikke kode validatorer - brug grænseflader ".

Kassen Jason Fried fulde artiklen

DISCALIMER: Det betyder ikke, at vi ikke skal bekymre os om standarder på alle. Standarder er godt at have og holde sig til dem så meget som muligt. Vi behøver blot at forstå, at godt UI design betyder ikke altid 100% standarder skal leve eller omvendt ....

Fra min liste af min indhøstede erfaringer, følger jeg et par UI design og udvikling gyldne regler ... Heres TOP 10 ... ikke, at du har følger dem også ...

1. Pas på dine brugere. Brugerne kan gøre eller bryde dit websted. Donot gøre brugeren at ligne en total idoit, aldeles ude af stand til ved hjælp af din hjemmeside. Det er BAD!

2. Hold enkelhed og brugervenlighed Brug dine primære retningslinier. Alt for mange ting på skærmen, jo højere sandsynlighed for, at en bruger vil blive forvirret eller distraheret fra deres oprindelige opgave.

3. Være inden for de grænser ... donot forkæl dig selv for meget i brugervenlighed, tilgængelighed og standarder. Brug standarder effektivt og gøre dem forstået til holdet. Dette vil sikre rette konsistens i produktet

4. Prototype krav. Da disse dage brugervenlige grænseflader er rige, og prototypefremstilling, altid er bedre end bare at gøre simple wireframes, og sidstnævnte er ugyldig af anstændige interaktioner, ville det ikke give kunden et klart billede af det endelige produkt, der er under udvikling. Altid, Det er lettere at konvertere de prototyper til færdige leverancer. Også! med prototyping enhver interaktion spørgsmål kan glattes ud tidligere i udviklingen cyklus.

5. Sammenhæng i dit design og interaktion er meget vigtigt. Donot forveksle din bruger med uforudsigelige interaktioner og dimser.

6. Forstå din "Design Mission Statement". Aways fokusere på den primære virkning af den side udformet beign. Også lave en liste over dine seconday handlinger på siden, og prioritere dem.

7. Give ordentlig feedback til de webstedets brugere. Med de fleste af de hjemmesider designet omkring AJAX, giver visuelle signaler til brugeren om ændringer til side. Brugeren skal gives en anerkendelse af afslutningen af ​​enhver opgave han udfører. Donot gøre brugeren vente og gætte, for f.eks. sikre fremskridt indikatorer for fil uplaods.

8. Brug kontroller passende. For eksempel brug Vælg drop down listen for små lister kun donot lade brugeren vælge en af ​​200 byer ved hjælp af udvalgte felter. Forstå forskellen mellem en knap og et link. Et link og knap har forskellige formål, donot bruge en til den anden. Give den rigtige kontrol til at interagere med en side lettere. Undgå at bruge menuer, der er mere end to niveauer dybt. Må ikke genopfinde hjulet. Brug standard kontroller, tilpasse dem kun hvis meget nødvendigt. Definer brugerdefinerede kontrolelementer, der er nødvendige for dit websted første hånd, så de kunne skabes og testes uafhængigt, klar til brug accross site.

9. Donot gentage alt for meget på design. Husk! Hele Produktet består mere end design alene. Byg passende tidslinjer ind i dit projekt tidsplan for design iterationer, og holde sig til det. Iteration hjælper os med at finde ud af, hvad der virker og hvad der ikke, udvælge de brændpunkter. Som en god brugerflade tager tid, give tid til gentagelser i begyndelsen af ​​denne udvikling cyklus, så designgentagelser doesnot direkte svare til Rework. For meget omarbejde kunne jeopradize frister.

10. Læn dig tilbage og tænke som en bruger tider.

Har du set animoto.com? Nå! dette er ikke en annonce, jeg virkelig kunne lide det! og det Kiss ASS UI faktisk

Jeg stødte på denne hjemmeside et par uger siden. Sav den første side, fordybning genere meget. For mig var det bare et andet sted med nogle rigt Flash-indhold, der giver brugerne mulighed for at uploade billeder, vælge nogle spor og omdanne det til et flot diasshow. Hent FLV, og sætte det på ethvert websted efter eget valg (YouTube, Metacafe, Facebook og lignende) ... PERIODE.

I går da jeg så de interne flow sider, der fandt brugeren gennem oprettelse af dette diasshow .... Jeg gik OH WOW! Da jeg indså, at der ikke var lidt af flash anvendt. Det var faktisk en Rich User Interface. Alle UI-udviklere skal stræbe efter at skabe eller i det mindste være en del af det hold, der har gjort denne grænseflade .... Helt genial! Og inspirerende!

Se dig ... http://animoto.com/ ... og registrere og lege med det ... først derefter kan du sætte pris på geni.

Da jeg læste denne artikel på A List Apart " Faux Absolute Positioning
af Eric Sol ", jeg var intet mindre end imponeret. Jeg blev også deprimeret majorly, forårsage, ærligt jeg tænkte på, hvorfor cant jeg komme op med noget fantastisk som denne.

Normalt, når vi opretter CSS-layout, bruger vi "position" eller "flyder", eller en meget dårlig kombination af begge. Eric Sol og hans team definere en ved siden af perfekt teknik af en ny type af CSS layout teknik, som de har døbt som "Faux Absolut Placering" efter faux kolonner teknik, der simulerer tilstedeværelsen af en kolonne.

Du ved, at problemet for os alle CSS udviklere har med sønderdelingsmidler layouts (De uventede ændringer af indholdet, der forårsager hele kolonner til wrap, når vi bruger svævede layouts) ... Nå! Historien synes!!
Dette layout teknikken er stadig meget ung, og har til smadret ud af alle de CSS guruer derude, før det bliver en un skriftlig standard. Jeg er glad for at bruge det NU! ... Og er allerede i midten af konvertering af mine tidligere problematiske / flydende un-nødvendigvis layouts i FAP layout allerede ... og er glad for at sige "vi allerede bruger Faux Absolute Positioning til denne blog websted, så godt" ... GO prøve det, NU!

Kudos Eric!

Flere DOM elementer på siden, langsommere det gør, langsommere er DOM adgang i JavaScripts. Et stort antal af DOM elementer kan skyldes dårlig layout design. For eksempel kan indlejrede tabeller er blevet anvendt til layoutformål. Brug en HTML-tag, hvor der er giver mening semantisk. Til f.eks donot tabeller til layout, men donot tøve med at bruge dem hvor du er nødt til at vise tabeldata, og dermed vil bruge reducere DOM elementer i sammenligning med en lignende struktur, skabt ved hjælp af divs alene ..

For at teste antallet af DOM-elementer i din HTML-side, skal du blot skrive følgende i Firebug konsol: document.getElementsByTagName('*').length

Der findes ingen standard for, hvor mange DOM elementer er for mange. Se andre lignende sider, der har en god markup.Eg. Yahoo! Startside side er en temmelig travl side og stadig under 700 elementer (HTML-tags).

Brug GET for Ajax Anmodninger

Det har vist sig, at ved anvendelse XMLHttpRequest er POST implementeret i browsere som en totrinsproces: sende headerne først, derefter sende dataene. Så det er bedst at bruge GET, som kun tager en TCP pakke til at sende (medmindre du har en masse cookies). Den maksimale URL-længde i IE er 2K, så hvis du sender mere end 2K data, som du måske ikke være i stand til at bruge GET.
En interessant side påvirke er at POST uden egentlig at sende nogen data opfører sig som GET. GET er beregnet til at hente oplysninger, så det giver mening (semantisk) at anvende får, når du kun anmode om oplysninger, i modsætning til at sende data, der skal lagres server-side.

Undgå Synkrone AJAX opkald

Når du foretager "Ajax" ønsker, kan du vælge enten async eller synkronisering. ASYNC tilstand kører anmodningen i baggrunden, mens andre browser-aktiviteter kan fortsætte med at behandle. Sync funktionen vil vente for anmodningen tilbage, før du fortsætter.
Anmodninger med synkronisering bør undgås. Disse anmodninger vil få browseren til at låse op for brugeren, indtil anmodningen tilbage. I tilfælde, hvor serveren er optaget, og svaret tager et stykke tid, brugerens browser (og måske OS) vil ikke tillade noget som helst andet, der skal gøres. I tilfælde, hvor et svar er aldrig rigtigt har modtaget, kan browseren fortsætte med at blokere, indtil anmodningen fik timeout.
Hvis du tror, ​​at din situation kræver synkronisering, er det mest sandsynlige tidspunkt at re-tænke dit design. Meget få (hvis nogen) situationer rent faktisk kræver Ajax anmodninger i sync mode.

Optimer billeder

Optimering betyder simpelthen holde størrelsen af ​​billedet lille holde kvaliteten af ​​billedet til det ønskede niveau. Der er masser af procedurer, der engang kan udføre for at optimere billeder, før de indlæses på serveren til levering. De værktøjer, vi bruger til oprettelsen af ​​disse billeder (Photoshop, Fireworks osv.) normalt har værktøjer, der giver brugerne mulighed for at optimere billedet til web brug.
• Tjek GIF har at se, om de bruger en palet størrelse svarende til antallet af farver i billedet. Når et billede er at bruge 4 farver og en 256 farvepalette, så billedet kunne optimeres yderligere

• Konverter GIF er til PNG 's hvor det er muligt, og se om der er en besparelse. Oftere end ikke, der er. Tøv ikke med at brug af PNG s, da de er fuldt understøttet af de fleste af de almindeligt brugte browsere. Forvent af animationen kapaciteter en PNG kan gøre, hvad en GIF gør, herunder gennemsigtighed.

• For de billeder, der anvendes i CSS sprites, arrangere billederne i Sprite vandret i modsætning til lodret normalt resulterer i en mindre filstørrelse. Også kombinere billeder med lignende farver i en sprite. Dette hjælper dig med at holde farven tæller lave, helst under 256 farver, så at passe i en PNG8.

• Hvis du bruger en favicon.ico, holde det lille, helst under 1K.

Brug korrekt skaleret / ændrede billede.

Altid forsøge at bruge størrelsesændrede billeder, altså ikke bruge et større billede end du har brug for, bare fordi du kan indstille bredden og højden i HTML. Hvis du har brug for at vise en 100px X 100px billede på siden, så skal du ikke bruge en skaleret ned 200x200px billede.

Brug Progressive billeder

En webbrowser allerede gør billeder gradvist. For at gøre det endnu bedre, skal du blot gemme GIF eller PNG-billeder med "interlaced" valgmulighed, eller dine JPEG-billeder med "progressive" valgmulighed.

Der er løbende debat blandt webbrugere om, hvorvidt brugen af ​​progressive billede er en velsignelse eller en hindring. Også et progressivt billede vejer cirka 20% mere end ikke progressivt modstykke. Så hvis du tror, ​​du layout bruger billeder, vil ikke hæmme den bruger-oplevelse ved at det er progressiv, er du velkommen til at gøre det.