Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Webbutveckling

    51 blogg poster in this category

      CSS Grid - ett nytt sätt att tänka

      CSS Grids är ett ganska underbart tillägg till en front end utvecklares arsenal, speciellt nu som det finns stöd för det i alla moderna browsers. Morten Rand-Hendriksen gör här en fantastisk presentation av hur användbart CSS Grids faktiskt är.




      [embed width=960" height="540] [/embed]


      CSS Grids tillsammans med media queries är ett välkommet sätt att hantera förändringar mellan olika viewports. Hur många utvecklare har inte svurit över en design där element flyttar sig mellan olika viewports? Hur många har inte försökt lösa det med duplicerad html eller andra dåliga lösningar?

      Morten Rand-Hendriksen visar i den här presentationen hur kraftfullt CSS Grids är och hur det kan användas för att lösa även de galnaste skillnaderna i design mellan viewports. Han gör det dessutom med underbar humor och rakbladsvass retorik som gör det till ett nöje att titta på.

      CSS grids bör vara på alls läppar redan och en naturlig del av en frontend utvecklares arsenal och tankesätt. Nu vet jag att det inte är så än, men det kommer ju mer denna teknik används och ju mer vi tar ansvar för att skapa en semantiskt korrekt design, utan att lägga in onödiga containers för att styra innehållet, desto snabbare kommer det att bli verklighet.

      Vad tycker du om CSS Grids och använder du det idag?

      Adobe Edge Code ger kreativiteten en boost

      Adobe  Edge Code, baserad på open source projektet Brackets, är en fantastisk editor som verkligen får min kreativitet att gå i taket. Med en enkelhet som är uppfriskande över klumpiga system som Eclipse och funktioner som gör att jag kan se min kod i realtid på flera enheter samtidigt så kan jag ärligen säga att jag älskar den lilla editorn som ännu knappt tagit sina första steg.
       
      Det var ett tag sedan jag först såg den första glimten av Adobe Edge Code och Brackets och redan då så var jag imponerad. En editor som är så snabb, enkel och anpassningsbar var helt enkelt förbluffande. Jag har suttit i många editorer under åren och de senaste åren så är det Eclipse och Dreamweaver som varit mina huvudsakliga editorer. Eclipse för att det är vad vi använder i jobbet och Dreamweaver för att det kommer med Adobe Creative Suite. Båda editorerna är väldigt kapabla, men precis som andra editorer som Netbeans och Visual Studio så är de alldeles fulla av funktioner som jag antingen inte behöver eller har tid att lära mig. Adobe Edge Code däremot har precis det jag behöver och sedan finns det en uppsjö av extra extensions om jag vill utöka funktionaliteten.
       
      Funktionen att kunna expandera vilket element som helst och se CSS klasser inline som jag kan modifiera direkt i koden istället för att hoppa mellan filer är helt otroligt hjälpsamt. Autocomplete funktioner och codehints är förvisso ganska vanligt, men ändå ganska trevligt. Lägger vi till funktionen att kunna se ändringar live så att jag kan se layouten samtidigt som jag jobbar med koden så har vi en riktig vinnare, men det finns mer! Genom att inkludera Adobe Edge Inspect så kan jag se koden live inte bara på den skärm jag jobbar på, jag kan även utöka med ytterligare enheter så att jag kan se hur koden ser ut på ipad, galaxytab, iphone och valfritt antal android telefoner - samtidigt! Det blir inte bättre än så, speciellt om du sitter och jobbar med responsiv design eller måste se hur din design ser ut på olika enheter.
       
      Nu är Adobe Edge Code fortfarande väldigt ung som system och har mycket utveckling som är pågående. En av de saker jag ser mycket fram emot är integrationen av Adobe Edge Reflow som ger ett visuellt interface för att jobba med media queries och olika upplösningar. En annan sak är något som kallas för Adobe Lens. Det låter användaren helt enkelt ta in en .psd fil i Adobe Edge Code och har sedan alla mått, fonter mm tillgängliga som code hints. Det är något liknande som CSS Hat, fast integrerat i Adode Edge Code. Överlag kan man säga att Adobe Edge Code är ett fantastiskt verktyg för frontendutvecklare, och det är ett verktyg som kommer att utvecklas mycket de närmaste åren.
       

      Bygg ditt eget API från början med Code Academy

      Ta en djupdykning in i back-end-arkitekturen i webbapplikationer genom att bygga ditt eget API från början.Lär dig grunden för JavaScript och Express.js, en ny teknik som driver API: er på företag som Twitter och PayPal.
       
      Detta program lär dig de färdigheter du behöver för att bygga baksidan av en webbapplikation. När du kombinerar den här kursen med avancerade programmeringsfärdigheter, så kan du bygga rika och interaktiva full stack applikationer.
       
      På bara åtta veckor kommer du att lära dig om arkitekturen för en webbapplikation, hur backend av en webbapplikation interagerar med en databas, och hur man använder JavaScript och Express.js för att skapa moderna backend API: er. Du kommer att examinera med tre egna projekt.
       
      Code Academy's egna utvecklare kommer att utvärdera och guida dig genom programmet med personlig feedback. Du bör kunna avsätta minst 10 timmar i veckan för att kunna fullfölja i den takt kursen är uppsatt.
       
      Erfarenhet med kommandotolk och textredigerare rekommenderas men det är inget krav. Programmet är endast tillgängligt på engelska.
       
      Prislappen är $199 och sista anmälningsdag är den 15:e Januari, så boka på en gång om du är intresserad!
       
       

      Vintage Typewriter - förmodligen den häftigaste kontaktformen du sett!

      Vintage Typewriter är en fantastiskt kul variant på kontakt form som med hjälp av jQuery ser ut och fungerar som en gammal skrivmaskin!
       
      Det är tutorialshock som skapat den fantastiska lilla skrivmaskinen och inte nog med att den är kul att leka med, du kan faktiskt skapa din egen och lägga upp på din webbplats! Följa bara beskrivningen som Tuturialshock skapat och glöm inte att lägga en länk här så vi kan se vad du skapat!
       
       

      HTML 5 structure översikt - en hippie standard med potential? #html5

      HTML 5 är på frammarsch ordentligt och är du som jag van vid den strikta XHTML syntaxen så gissar jag att du också rullar med ögonen över HTML5's luddiga och ibland snudd på obegripliga standard, men visst finns det potential?!
       
      HTML5 känns väldigt influerad av Internet Explorer och Microsoft med sina lösa regler och den där hopplösa "man kan göra lite som man vill" mentaliteten, något som förmodligen var XHTML's stora fördel när det petade ner HTML4.1 från tronen och skapade lite ordning i kodträsket. Nu är vi på väg tillbaka till ett mer avslappnat och förlåtande HTML som jag är inte helt säker på att jag gillar.
       
      Det som jag däremot gillar är dom nya strukturtaggarna. Dom nya taggarna ger en ny dimension till div-itis sjukan där div taggar nästlas tills man får tunnelseende. Nu går det Vid första anblicken så ser dom ganska enkla ut, men sedan så kollar man specifikationen och då blir det plötsligt inte lika tydligt:


      the footer element can appear at the start of its section when appropriate, such as in this case. (Using header in this case wouldn't be wrong either; it's mostly a matter of authoring preference.)
      Trots den förvirringen som först uppstår så finns det några riktlinjer att gå efter och jag gissar att ju mer taggarna används desto tydligare blir det, men tills dess tänkte jag beskriva taggarna och hur dom är tänkta att användas, enligt mig.

      Header
      header beskrivs som "a group of introductory or navigational aids", vilket inte säger speciellt mycket direkt. Många tänker direkt på HTML dokumentets head tagg, även kallad MastHead, men i HTML5 så kan det finnas många headers och det är till och med rekommenderar att varje section ska ha en header och även article kan ha det om det känns lämpligt (luddigt det här). Namnet kanske får dig tt tro att det alltid ska ligga överst i ett dokument eller sektion, men det stämmer inte alltid utan det är beroende på innehållet, dvs var introduktionen eller navigationshjälpmedel finns.


      A header element is intended to usually contain the section's heading (an h1 element or an hgroup element), but this is not required. The header element can also be used to wrap a section's table of contents, a search form, or any relevant logos.

      Nav
      Nav taggen är tänkt för olika delar av webbplatsen som länkar till andra områden på webbplatsen, något som vanligtvis brukar ligga som huvudnavigation i MastHead eller som en sidosektion. Nav kan användas på huvudnavigering och undernavigering, men bör inte användas på annat. I footern på en webbplats ligger det ofta navigering, men där ska nav inte användas utan footer taggen är tillräcklig.



      Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.

      User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip and/or provide on request.


      Section
      Section används för att gruppera olika sektioner av relaterad information. Section är förmodligen den tagg som kommer att användas mest som ersättning för en vanlig div tagg, som inte har någon semantisk betydelse, men den ska inte användas som en slags generisk ersättare. Section ska bara användas när det är logiskt att dela upp innehållet i sektioner, ungefär som om du skulle dela upp sidan i en punktlista med dom olika delarna på webbsidan. Något som är lite intressant med section är att det är helt ok att använda H1 taggar för varje sektion utan att därför bryta mot sidans semantiska uppbyggnad.


      Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element.
       
      The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline.

      Article
      Article används för "self-contained related content" vilket kanske inte alltid är helt enkelt att avgöra. Generellt kan man säga att innehåll som du publicerar styckevis i ett system, som nyheter, bloggposter osv kan använda article. Om innehållet skulle kunna syndikeras med RSS så är det med största säkerhet lämpligt att använda article eftersom article taggen är skapat speciellt just för syndikerat innehåll.


      When used specifically with content to be redistributed in syndication, the article element is similar in purpose to the entry element in Atom. [ATOM]
      The time element's pubdate attribute can be used to provide the publication date for an article element.

      Aside
      Första tanken var att aside är en slags sidebar tagg, men som många andra taggar så har namnet en lite annorlunda betydelse. Aside är tänkt för innehåll som är skild från huvudinnehållet. Det kan till exempel vara en sidebar, ett annonsblock eller undernavigation för sidan. Pullquotes är också något som passar väl i en aside tagg.


      It's not appropriate to use the aside element just for parentheticals, since those are part of the main flow of the document.

      Footer
      footer associeras, precis som header taggen, med en viss position, men precis som med headern så är det innehållet som styr. Footer används för information om vem som skrivit en viss artikel, copyright information, länkar till relaterat innehåll osv. Kontakt information ska däremot inte ligga i en footer utan i adress, men adress i sin tur kan mycket väl ligga inne i en footer. Precis som med header taggen så kan det ligga flera footer taggar i ett dokument.


      Contact information for the author or editor of a section belongs in an address element, possibly itself inside a footer.
       
      The footer element is not sectioning content; it doesn't introduce a new section.
×
×
  • Create New...