Een inleiding in het gebruik YUI 3 in offline toepassingen

27 mei 2010 om 13:53 door Alexander Kessinger | In ontwikkeling | 9 Commentaren

Over de auteur: Alex Kessinger werkt als een front-end engineer bij Yahoo! in het verleden werkzaam als front-end, hij geniet van het werken op de gehele stack. Hij besteedt ook veel tijd aan het lezen, curatorschap en schrijven over het internet, sociale media, en het bouwen van websites. U vindt alles op zijn website alexkessinger.net . U vindt hem op twitter @ voidfiles .

Ik zou kunnen zeggen dat HTML5 wordt stoom bouwen, maar die tijd is voorbij: HTML5 is hier. Mobile is al enorm, wordt WebKit groeit snel, en het aantal mensen die een HTML5-browser op hun telefoon en / of laptop in de komende jaren zal een "nieuwe normaal", waarin HTML5-mogelijkheden zijn de standaard te creëren.

Een van de geweldige functies in HTML5 is de Application Cache , waardoor websites de mogelijkheid om de browser welke bestanden in de cache te vertellen en om de bestanden in de cache te gebruiken wanneer de browser niet over een netwerkverbinding. U kunt gebruik maken van de Application Cache om ervoor te zorgen dat een gebruiker in staat zal zijn om ten minste een deel van uw applicatie toegang te krijgen terwijl hij offline is. In het geval van apparaten zoals telefoons of tabletten (of zelfs ouderwetse apparaten zoals laptops), kan dit betekenen dat uw gebruikers in staat zijn om je app te gebruiken, terwijl op een vliegtuig. Ondertussen krijg je te blijven het bouwen van uw app met web technologieën in plaats van het leren van Objective-C.

Naast de Application Cache , zijn er ook andere API's beschikbaar in HTML5, dat geeft webontwikkelaars de middelen om nuttige online ervaringen te creëren. Er zijn twee permanente opslag API's beschikbaar in de meeste nieuwere browsers. Een daarvan is een eenvoudige sleutel / waarde data store, genaamd localStorage . De tweede is een SQL-database . Beide kunnen worden ingezet terwijl de gebruiker offline is.

Met deze concepten in het achterhoofd, ga ik naar de evergreen "takenlijst" applicatie te verkennen, te gebruiken als een springplank om te kijken hoe we kunnen gebruik maken van de Application Cache en permanente opslag in een app die voortbouwt op alles wat we leuk vindt aan YUI 3, met inbegrip van de YUI 3 Gallery.

Markup

Markup is altijd een geweldige plek om te beginnen bij het bouwen van alles wat met het web. De basis schil van onze HTML5 pagina: 

  <! DOCTYPE HTML>
 <Html
 <head>
     <title> YUI ToDo </ title>
     <link rel="stylesheet" href="base.css" type="text/css" media="screen" title="no title" charset="utf-8">
 </ Head>
 <body class="yui-skin-sam">
     <script src="yui-min.js"> </ script>
     <script src="base.js"> </ script>
 </ Body>
 </ Html>

Hoewel we het opbouwen van een offline-applicatie klaar is, volgens de beste praktijk, maar zetten CSS in het hoofd, en Javascript vlak voor de afsluitende body-tag. Zelfs als uw pagina gaat offline beschikbaar zijn, moet de eerste pagina te laden kunnen reageren. (Merk op dat we het vreselijk simpele HTML5 doctype hier gebruikt.)

De app heeft een aantal tijdelijke aanduiding opmaak: 

 <! DOCTYPE HTML> <html> <head> <title> YUI ToDo </ title> <link rel = "stylesheet" href = "base.css" type = "text / css" media = "screen" title = "no titel "charset =" UTF-8 "> </ head> <body class="yui-skin-sam"> <div id="doc3"> <div class="hd"> <h1> ToDo App </ h1 > <a class="callout" href="http://alexkessinger.net" target="_blank"> door Alex Kessinger </ a> <div class="item_entry"> <form class="entry_form"> <input type = "text" name = "todo_item_input" class = "todo_item_input"> <p class="toRight"> <a class="addItem" href="#add"> Toevoegen </ a> </ p> </ form > </ div> </ div> <div class="bd"> <div class="yui-main"> <div class="yui-b"> <div class="todo_items"> <h2> Todo Items </ h2> <ul> <li class="no_items"> ophalen ToDo items ... </ li> </ ul> </ div> </ div> </ div> </ div> <div id = " debug "> </ div> <-! Initialisatie proces / / -> <script src="yui-min.js"> </ script> <script src="base.js"> </ script> </ div> </ body> </ html>

Dit laat de gebruiker weten dat we van plan om een ​​aantal gegevens voor hen wanneer ze voor het eerst laden van de app. Hierbij worden ook ons ​​podium, een DOM-structuur voor onze Javascript aan de slag met.

Een opmerking over Progressive Enhancement

Er is geen reden dat een aanvraag niet kan worden gebouwd met de beginselen van progressieve verbetering en nog steeds beschikbaar voor offline gebruik. In deze verkenning, ik ben het weglaten van de extra complexiteit die betrokken zou zijn bij PE, om zoveel mogelijk te focussen op de technieken die nodig zijn voor offline-ondersteuning. Sommigen zullen misschien kritiek op die aanpak, en ik ben sympathie voor dit argument.

Extra Eigenschappen voor het omgaan met mobiele apparaten

iPhoneOS en Android browsers kunnen de meeste webpagina's zonder speciale aandacht, maar bij de behandeling van mobiele apparaten is het waard om te onderzoeken hoe de inhoud wordt geperst zodat ze op het kleine scherm. Quirksmode heeft niet een , maar twee diepgaande artikels op viewport die goed de moeite waard uw tijd.

Kort is er een metatag genoemd kijkvenster. Het ziet er ongeveer zo uit: 

  <meta name="viewport" value="">

Het doel van de viewport tag is om mobiele browsers erachter te komen hoe je een echt grote webpagina weer te geven op een klein scherm. Mobiele apparaten hebben hulp nodig, omdat de meeste apparaten proberen 700-1100px van de inhoud te persen op een 300-500px scherm. Ook wanneer we onze breedte vastgesteld op 100%, de browser neemt zijn beste gok op hoe groot de webpagina zou moeten zijn, en dan schalen ervan uit dat groot om te passen binnen de afmetingen van het apparaat.

Om u te helpen we de viewport bij deze. 

  <meta name="viewport" value="width=device-width">

Dit vertelt het apparaat aan de breedte van onze pagina ingesteld op de breedte van het scherm van het apparaat. Als we ervoor dat onze pagina vloeistof is, dan is onze pagina vult het scherm op de meeste mobiele apparaten. Dit betekent ook dat als de telefoon heeft een landscape mode de pagina uit te breiden naar de extra ruimte op te vullen.

Er zijn andere dingen die we kunnen doen om de viewport ook. Als je hebt gewerkt met mobiele browsers, je weet ze je in staat om in te zoomen. Als u nemen om tijd om een ​​website te bouwen om het hele scherm te vullen kunt u niet wilt dat een gebruiker in staat om in te zoomen. Als we onze viewport naar iets als de volgende zijn, zal de gebruiker niet in staat zijn om in te zoomen, of uit. Op een toestel als de iPhone dit kan het voelen zich meer native. Maar als je dit doet, zorg ervoor dat de inhoud van uw app geeft de gebruiker geen enkele reden om ooit willen om in te zoomen (bijvoorbeeld kleine tekst), anders zal dit een frustrerende bruikbaarheid beperking te vormen. 

  <meta name="viewport" value="width=device-width,user-scalable=no">

De viewport is niet een W3C-standaard, maar is een algemene conventie. Het is op dit moment ondersteund door de WebKit-browsers op de iPhone en Android-besturingssystemen. Fennec , de mobiele browser van Mozilla, zal waarschijnlijk ook deze conventie te ondersteunen.

CSS

Meer dan ooit, met behulp van CSS in staat is om vloeiend en dynamisch is belangrijk. Wanneer we kijken naar het brede scala aan telefoons, tabletten, en andere kleine schermen, ontwikkelaars van toepassingen moeten zich ervan bewust dat onze apps zullen worden gebruikt op een overvloed aan apparaten. Ook al is er geen toverstokje kunnen we zwaaien om alles gewoon werken, voor de meeste toepassingen kunnen wij niet nodig om pixel perfect op elk apparaat te zijn. Gewoon volgende best practices 'kan ons het grootste deel van de weg naar de meeste apparaten ondersteunen.

Te beginnen met het instellen van de breedte van onze app aan de basis in% is een goede start. Met behulp van em is om font-grootte is ook nuttig omdat ems zijn berekend op basis van de gerenderde webpagina. Een ander ding dat helpt is om ervoor te zorgen dat u de kolombreedte te baseren op percentages ook. Zelfs kolom goten kan worden ingesteld in Em's.

Een geweldige plek om, te beginnen zonder een hoop werk te doen is een CSS-kader. YUI 2 roosters CSS is natuurlijk een van onze favorieten, en het helpt ons denken aan onze pagina in termen van verhoudingen in plaats statische breedte blokken.

Dus het bouwen van off YUI 2 CSS Grids hier is het uitgangspunt CSS voor mijn app. 

  . Todo_items {
     padding-top: 1em;
 }

 . Todo_items ul {
     padding: 0;
     margin: 0;
 }
 . Todo_items ul li {
     margin: 0.125 Em 0 0,5 em 0;
     padding: 0,125 em 0 0 0;
     border-top: 1px solid # ccc;
     list-style: none;
     display: block;
     word-wrap: break-woord;
     text-wrap: onderdrukken;
 }

 . ToRight {
      text-align: right;
 }

 . Yui3-console {
      text-align: left;
      margin-left: 10px;
 }

 body h1 {font-size: 200%;}
 lichaam h2 {font-size: 150%;}

Javascript

Next up voor onze offline to-do-applicatie is de JavaScript. Download eerst yui_min.js naar uw document root, en voeg deze toe aan de markup, zoals we hierboven. Dan zet dit in je base.js bestand: 

  YUI (). Te gebruiken ('node', functie (Y) {
     Y.one ("todo_items h2.") SetContent ("Ik vlieg").;
 });

Naast Node, ben ik ook naar het onder meer YUI 3 CSS Reset en YUI 2 CSS-grids. Ik ga een module uit de include YUI 3 Galerij , uitstekende Ryan Grove's Storage Lite , zal dat wikkel alle mogelijke lokale data-opslag methoden in een makkelijk te gebruiken API. 

  YUI (). Gebruik ('cssreset', 'yui2-grids', 'galerie-storage-lite', 'node', functie (Y) {

   / / To-do lijst Toepassingscode

 });

Opmerking: Ik ben niet van plan te duiken in de to-do lijst code, noch in een aantal van de technieken die ik zou gebruiken om het gemakkelijker maken om dit soort projecten op mobiele apparaten te debuggen. U kunt dat allemaal vinden op GitHub: yui3-todo . Binnen base.js vindt u het geheel van de app. U kunt ook de app op en draait op http://html5.alexkessinger.net/yui/ytodo/ . Hier, ik ga richten op de stappen die nodig zijn om deze eenvoudige app met offline-mogelijkheden te verbeteren.

Cache Manifest

De eerste stap om het nemen van een web-app offline is de Application Cache . De Application Cache kunt uw browser welke bestanden u wilt downloaden en offline te houden. In dit voorbeeld, ik weet dat ik wil mijn JavaScript en mijn CSS niet beschikbaar, evenals de belangrijkste HTML-pagina te houden voor de app. Met dat in gedachten, zal mijn cache manifesteren als volgt uitzien: 

  CACHE MANIFEST

 index.html
 base.css
 yui_min.js
 base.js

Sommige dingen op te merken over de cache manifesteren.

  • Het moet beginnen met de lijn CACHE MANIFEST .
  • U moet serveer het met een Content-Type header van tekst / cache-manifest

Als je op Apache, kunt u de volgende code toe te voegen aan .htaccess om de juiste content type te krijgen. 

  AddType text / cache-manifest. Manifesteren

Met dat in de plaats, een bestand met een .manifest zal achtervoegsel worden geserveerd met de text/cache-manifest Content-Type header.

Vervolgens moeten we de browser van de cache duidelijk te informeren, om te doen dat we een attribuut toe te voegen aan onze HTML-tag: 

  <html manifest="todo.manifest">

Nu als je naar uw pagina in een browser die offline apps ondersteunt zul je waarschijnlijk een melding dat deze webpagina wordt offline toegang vraagt.

Offline / Online

Met het manifest op zijn plaats te vertellen onze browser welke middelen in de cache, we zijn klaar om na te denken over wat er gebeurt in de online modus ten opzichte van offline-modus. Er zijn nu twee "boot sequenties," de eerste is de volledige online sequentie die we al hebben (en gedurende welke middelen zijn in de cache voor offline gebruik). Deze online volgorde maakt gebruik van de Yahoo CDN het laden van de bestanden en de bestanden zijn combo-behandeld dus we hebben maar een paar HTTP-verzoeken.

Maar we bouwen ook een offline boot procedure. We moeten in staat zijn om het feit dat de browser is nu online en dan initialiseren YUI goed om uit te putten in de cache middelen op te sporen. 

  var online = (navigator.onLine)?  waar: false;

Nu, we hoeven alleen maar een configuratie object op basis van zijn offline of online te kiezen. 

  var YUI_ONLINE_CONF = {},
     YUI_OFFLINE_CONF = {
         basis: "yui3/build /",
         combineren: 0,
         groepen: {
             Gallery: {
                 basis: 'yui3-gallery/build /',
                 patronen: {'gallery-': {}}
             }
             yui2 {
                 basis: '2 in3/dist/2.8.0/build / ',
                 patronen: {
                     'Yui2-': {
                         configFn: function (me) {
                             if (/-skin | reset | lettertypen | roosters | base / .test (me.name)) {
                                 me.type = 'css';
                                 me.path = me.path.replace (/ \ js /,. 'css.');
                                 me.path = me.path.replace (/ \ / yui2-skin /, '/ assets/skins/sam/yui2-skin');
                             }
                         }
                     }
                 }
             }
         }
      }
      ONLINE = (navigator.online)?  waar: false;
      CURRENT_CONF = (online)?  YUI_ONLINE_CONF: YUI_OFFLINE_CONF;

 YUI (CURRENT_CONF). Gebruik ('cssreset', 'yui2-grids', 'galerie-storage-lite', 'node', functie (Y) {
     ...
 });

De YUI_OFFLINE_CONF configuratie nodig zou kunnen hebben enige uitleg. Ten eerste ben ik het veranderen van de basis om mijn document root + yui3/build/ . Ik heb gepost de volledige distributie van YUI 3 tot en met mijn server, omdat de W3C specificaties staat dat de offline cache een strikt single origin beleid. Alle cache middelen moet afkomstig zijn van hetzelfde domein als doet het manifest. Als gevolg hiervan, ik kan niet vertrouwen op Yahoo! of Google of een andere CDN om mijn bestanden te dienen - allemaal beschikbaar moet zijn voor caching van mijn server.

Het volgende deel, combine:0 , vertelt de YUI lader niet automatisch combo van de bestanden, want ik heb geen combo-handler geinstalleerd op mijn eigen server.

Tot slot wil ik noemen de groups config. groepen is een nieuwe functie in YUI 3.1.1 waarmee u definieert hele groepen van bestanden die afkomstig zijn uit dezelfde plaats. U kunt ook instellen dat ze worden combo'd van de bron. Ik de YUI 3 Galerij hier om te laden van een lokale kopie heb ik van de yui3-gallery repository op GitHub.

Als we online zijn, kunnen we bootstrap van de Yahoo CDN, maar offline moeten we lokale kopieën van de bestanden. Dit is makkelijk te doen. U kunt de bestanden downloaden moet in een grote zip-bestand naar je map: 

  cd docroot;
 wget http://yuilibrary.com/downloads/yui3/yui_3.1.0.zip;
 pak yui_3.1.0.zip;
 mv yui yui3;
 wget http://download.github.com/yui-yui3-gallery-gallery-2010.05.19-19-08-0-g2a49f06.zip;
 unzip Yui-yui3-gallery-gallery-2010.05.19-19-08-0-g2a49f06.zip;
 mv Yui-yui3-gallery-2a49f06 yui3-gallery;
 wget http://download.github.com/yui-2in3-yui-2in3.3-0-gdf09025.zip;
 mv Yui-2in3-yui-2in3.3-0-gdf09025 2in3;

Of u kunt klonen de git repositories van github direct als git wordt geïnstalleerd op uw machine: 

  cd docroot;
 git clone git :/ / github.com/yui/yui3.git yui3;
 git clone git :/ / github.com/yui/yui3-gallery.git yui3-gallery;
 git clone git :/ / github.com/yui/2in3.git 2in3;

Voor testdoeleinden. Ik zal wel te stellen ONLINE = false en kijk hoe mijn site laadt. Als je dat doet, en dan je app te bezoeken in een normale browser, zie je elk bestand dat moet individueel worden opgenomen. Om goed te vullen onze cache manifesteren, moet je kennis te nemen van elk bestand dat wordt getrokken, met behulp van iets als Firebug. Dan in je cache manifesteren zul je elk bestand een lijst een voor een. Het zal er ongeveer als volgt. 

  CACHE MANIFEST
 # Een opmerking
 index.html
 base.css
 base.js
 Yui-min.js
 yui3/build/loader/loader-min.js
 yui3/build/widget/assets/skins/sam/widget.css
 yui3/build/console/assets/skins/sam/console.css
 yui3/build/oop/oop-min.js
 yui3/build/event-custom/event-custom-min.js
 yui3/build/intl/intl-min.js
 yui3/build/console/lang/console.js
 yui3/build/attribute/attribute-min.js
 yui3/build/event/event-base-min.js
 yui3/build/pluginhost/pluginhost-min.js
 yui3/build/dom/dom-min.js
 yui3/build/node/node-min.js
 yui3/build/event/event-delegate-min.js
 yui3/build/event/event-focus-min.js
 yui3/build/base/base-min.js
 yui3/build/classnamemanager/classnamemanager-min.js
 yui3/build/widget/widget-min.js
 yui3/build/substitute/substitute-min.js
 yui3/build/console/console-min.js
 yui3/build/cssreset/reset-min.css
 2in3/dist/2.8.0/build/yui2-grids/yui2-grids-min.css
 yui3-gallery/build/gallery-storage-lite/gallery-storage-lite-min.js
 yui3/build/json/json-min.js
 startup.png
 icon.png

Op dit punt kunnen we helemaal offline. Als u een iPhoneOS of Android-toestel (of een HTML5-browser) kunt u nu een bezoek aan uw website, laat het af te laden, en dan opnieuw de pagina met het apparaat internet toegang geblokkeerd.

iPhone-specifieke extra's

De iPhone biedt de WebApp ontwikkelaar de mogelijkheid om uw applicatie te geven wat ruimte op het startscherm net als alle andere apps. Je kunt zelfs een glossy icoon en opstartscherm als je zou hebben met een "native" applicatie. Eerst moet u de te volgen specificaties voor het pictogram en opstartscherm. En dan kun je de volgende meta tags: 

  <meta name="apple-mobile-web-app-capable" content="yes" />
 <meta name="apple-mobile-web-app-status-bar-style" content="white" />
 <link rel="apple-touch-icon" href="icon.png"/>
 <link rel="apple-touch-startup-image" href="startup.png" />

De eerste twee tags te vertellen mobiele Safari dat uw web-pagina is een HTML5 WebApp en dat je maar wilt de kleur van de statusbalk aan de bovenkant wit te zijn. Dit verwijdert ook alle navigatie-chroom rond browservenster. De tweede twee tags verwijzen naar de bestanden die u wilt gebruiken voor uw icoon en opstartscherm.

Wat is de volgende

De HTML5 spec is nog steeds een bewegend doel. Houd een oog voor nieuwe ontwikkelingen. Dat gezegd hebbende, zelfs vandaag de dag zijn er fantastische nieuwe mogelijkheden in moderne browsers. Zoals je kunt zien in deze tutorial, het is niet moeilijk om een ​​web-applicatie offline te nemen, een dramatische toename van het potentieel van nut. En als je offline gaat, aarzel dan niet om YUI 3 mee te nemen, samen met alle kracht die u bent gewend om uit de YUI 3 Gallery en de YUI 2 widget familie.

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

Werk met YUI als onderdeel van de Yahoo! Open Strategy (Yos) Engineering Team

20 mei 2010 om 2:06 pm door Rohit Dube | In Frontend Engineering Vacature bij Yahoo | Comments Off

De Yahoo! Open Strategy (Yos) Team bouwt de volgende generatie van open platforms. Een van onze nieuwe producten - Connect - is gericht op externe uitgevers en ontwikkelaars. Connect kunnen derden gemakkelijk met Yahoo! te integreren door het droppen van een paar regels javascript-code op hun site. Verder Connect stelt gebruikers in staat om in te loggen op websites van derden met behulp van hun Yahoo!-ID's en hun updates uit te zenden naar vrienden en volgelingen.

Connect maakt gebruik van verschillende technologieën, waaronder Yahoo YQL en YUI . In het bijzonder Connect maakt gebruik van de kern bibliotheken van YUI3 (knooppunt, io, aangepaste gebeurtenissen) en de widget infrastructuur om een ​​consistente api en cross-browser te bieden. Eenmaal volledig ontwikkeld, zal Connect worden ingezet voor duizenden web-sites en zichtbaar zijn voor miljoenen consumenten. Dit is een opwindende kans om betrokken te zijn bij een project die een uitstekende consument te bereiken en uitdagende schaalbaarheid eisen zal hebben.

De ideale kandidaat heeft 5 + jaar van grootschalige web development ervaring, inclusief bekendheid met browser-side-client technologieën zoals Javascript, HTML en CSS en met cross-browser compatibiliteit problemen, optimalisatie technieken, en internationalisering. Kennis van PHP en een JavaScript-bibliotheek - zoals YUI - nodig zijn.

Interesse? Zie de volledige functiebeschrijving op http://careers.yahoo.com/jdescription.php?oid=29752 en contact Rohit Dube (rdube op Yahoo-inc.com).

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

YUI Theater - Ryan Dahl: "Inleiding tot NodeJS" (58 min.).

20 mei 2010 om 13:26 door Allen Rabinovich | In Ontwikkeling , YUI Theater | 14 Commentaren

Ryan Dahl's Talk op de BayJax evenement op Yahoo! op 5 mei 2010.

Twee weken geleden, Yahoo! gastheer van een BayJax meetup gewijd aan NodeJS (sinds de meetup viel samen met Cinco de Mayo, we noemden het 'Cinco de Node'). Ryan Dahl , de bedenker van NodeJS, gaf een lezing over het project en was erg vriendelijk om ons te laten registreren zijn presentatie voor YUI Theater.

PS De video begint met een 30-seconden blik in de Cinco de Mayo vieringen op Yahoo!

Als de video insluiten hieronder niet te zien zijn in uw RSS-reader van keuze, moet u doorklikken naar de hoge resolutie versie van de video op YUI Theater te kijken .

Andere recente YUI Theater Video's:

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

YUI Theater - Elia Insua: "jsdom: een CommonJS Uitvoering van het DOM" (18 min.).

20 mei 2010 om 13:24 door Allen Rabinovich | In Ontwikkeling , YUI Theater | Comments Off

Elia Insua's Talk op de BayJax evenement op Yahoo! op 5 mei 2010.

Elia Insua , een ster ontwikkelaar uit Arc90 , presenteerde zijn werk op jsdom bij de Cinco de Node BayJax evenement bij Yahoo!. Elia was de presentatie van de Brooklyn via Skype (dus vergeef de minder-dan-ideale video en audio kwaliteit), en genadig liet ons toe om zijn toespraak voor YUI Theater vast te leggen.

Als de video insluiten hieronder niet te zien zijn in uw RSS-reader van keuze, moet u doorklikken naar de hoge resolutie versie van de video op YUI Theater te kijken .

Andere recente YUI Theater Video's:

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

Implementatie Focus: Phanfare Media Organizer

19 mei 2010 om 13:51 door Eric Miraglia | In In the Wild , YUI Implementaties | 1 Reactie

Cory Mintz van Phanfare schreef vorige week om ons te vertellen over hun recente product te lanceren, die sterk is gebaseerd op YUI 2.8.0.

We hebben net onze nieuwe web-organisator gisteren ... Het is een volledige foto-en video-organisator gebouwd als een web applicatie, met behulp van zowat elke YUI 2-componenten. We denken dat het echt de grens tussen desktop en web software vervaagt.

Enkele opvallende kenmerken zijn:

  • Met behulp van de uploader , we laten de mensen organiseren en bewerken van hun foto's als ze te uploaden.
  • Met behulp van slepen en neerzetten en Menu , de verkleinde raster heeft alle van de gedragingen van het bestand een OS van de browser. U kunt slepen selecteren, slepen en neerzetten opnieuw ordenen, multi-select met behulp van Ctrl en Shift, pijl tussen de miniaturen, enz.
  • De dynamische belasting van de TreeView , laat ons lui belasting gebruikersaccounts met 100s van albums omdat ze hiërarchisch (jaar -> Album -> sectie). Hierdoor kan de pagina voor een zeer groot rekening te laden even snel als een account.

Ik hou van de schone professionaliteit van de site en de buitengewone aandacht voor detail in de gebruikersinterface. Voel je vrij om de site een rondleiding - trial accounts zijn gratis en komen bevolkt met voorbeeld albums om u een gevoel voor wat de site te bieden heeft. Proficiat aan Cory en het team voor zo'n fantastische lancering.

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

CSS 101: Blok opmaken contexten

19 mei 2010 om 11:46 am door Thierry Koblentz | In ontwikkeling | 10 Commentaren

Over de auteur: Thierry Koblentz is een front-end engineer bij Yahoo!
Hij is eigenaar van TJK Ontwerp , ez-css.org en css-101.org . U kunt Thierry op Twitter via @ thierrykoblentz .

Een blok opmaak context is een doos die ten minste een van de volgende voldoet:

  • de waarde van "float" is niet "geen",
  • de gebruikte waarde "vrij" is "zichtbaar"
  • de waarde van de "display" is "table-cell", "table-caption", of "inline-block",
  • de waarde van "positie" is niet "statisch", noch "relatief".

Als het gaat om het visuele opmaakmodel (dit is hoe user agents de verwerking van documenten boom voor visuele media ), blok opmaak contexten zijn grote spelers. Het is dus van cruciaal belang voor CSS auteurs hebben een goed begrip van hun relatie met de stroom mee, drijvers, helder en marges.

Wat zegt de spec zeggen over ...

Hoe te blokkeren opmaak contexten stroom

De positionering regeling aan welk blok opmaak contexten behoren is normale stroom . Daarom wordt het "blok" van een blok opmaak context geplaatst in de stroom van de pagina zoals je zou verwachten met een blok dozen, inline opmaak van de inline boxen, relatieve positionering van het blok of inline boxen, en de positionering van de run-in dozen. Simpel gezegd, ze zijn deel van de pagina flow.

Wat veroorzaakt blok opmaak contexten

Sectie 9.4.1 zegt dat het volgende stelt nieuw blok opmaak contexten:

  • drijvers,
  • absoluut gepositioneerde elementen,
  • inline-blokken,
  • tabel-cellen,
  • table-bijschriften,
  • elementen ingericht met "overflow" (een andere waarde dan "zichtbaar")

Maar volgens de CSS niveau 3 specificatie , wordt een blok opmaak context (een "flow root" in CSS3 spreken) gecreëerd wanneer de volgende voorwaarde is voldaan:

  • De waarde van " positie "is niet" statisch ", noch" relatief "(zie [CSS3POS] ).

Deze definitie houdt in dat position:fixed wordt een nieuw blok opmaak context, ook. Dit is geen miss in paragraaf 9.4.1, hoewel, vaste positionering is een variant van absolute positionering (9.6.1) en verwijzingen in de specificatie van een absoluut gepositioneerd element (of de box) impliceren dat het element " positie "eigenschap heeft de waarde "absoluut" of "vast".

Merk op dat display:table bevat geen blok opmaak contexten per se. Maar omdat het kan genereren anonieme dozen , een van hen (met display:table-cell ) is een nieuw blok opmaak context. Met andere woorden, de trekker de anonieme vak niet display:table . Dit is iets wat de auteurs in gedachten moet houden, want zelfs als beide stijlen vast te stellen nieuwe blok opmaak contexten (impliciet of expliciet), clear niet dezelfde werken met display:table als met display:table-cell .

Een laatste trigger is het fieldset element. Vreemd genoeg was er geen informatie over www.w3.org over dit probleem tot aan de HTML5 -specificatie. Er waren browser bugs ( Webkit , Mozilla ) dat dit vermeld, maar niets "officiële". Eigenlijk, zelfs als veldverzamelingen invoering van nieuwe blok opmaak contexten in de meeste browsers, zoals bepaald in punt 3.2 (UA conformiteit), werden de auteurs niet de bedoeling dat dit voor lief nemen:

CSS 2.1 niet bepalen welke eigenschappen van toepassing zijn op controles en kaders te vormen, of hoe CSS kan gebruikt worden om stijl van hen. User Agents kunnen van toepassing zijn CSS-eigenschappen voor deze elementen. Auteurs wordt aanbevolen om een ​​dergelijke ondersteuning als experimenteel te behandelen. Een toekomstige niveau van CSS kan aangeven dit verder.

Wat blok opmaak contexten te doen

Blok opmaak contexten bevatten praalwagens door de manier waarop ze flow, en per sectie 9.4.1, ze voorkomen instortende marges en elkaar niet overlappen praalwagens:

In blok opmaak verband worden dozen aangelegd na elkaar verticaal, vanaf de top van een bevattende blok. De verticale afstand tussen twee verwant dozen wordt bepaald door de "marge" eigenschappen. Verticale marges tussen aangrenzende blok dozen in een blok opmaak context instorten .

In een blok opmaak context, elk vak de linker buitenkant raakt de linkerrand van het bevattende blok (voor rechts-naar-links opmaak, rechts randen touch). Dit geldt zelfs in aanwezigheid van drijvers (hoewel een box regelboxen kan krimpen de drijvers), tenzij de doos wordt een nieuw blok opmaak context (in welk geval de box zelf kan smaller worden door de drijvers).

Genoeg met de specs, wat betekent dit in de echte wereld?

Blok opmaak contexten gedragen zich min of meer als een blok box, afgezien van deze belangrijke uitzonderingen:

  • Blok opmaak contexten te voorkomen marge instorten

    Verticale marges tussen aangrenzende blok dozen instorting , maar alleen als ze in hetzelfde blok opmaak context. Met andere woorden, als de aangrenzende dozen niet tot hetzelfde blok opmaak verband hun rand niet bezwijken.

    Voorbeeld:

    Dit is een paragraaf in een DIV met een blauwe achtergrond, gestileerd met margin:20px .

    Dit is een paragraaf in een DIV met een blauwe achtergrond, gestileerd met margin:20px .

    Dit is een paragraaf in een DIV met een blauwe achtergrond, wordt ingericht met margin:20px , is de moedermaatschappij DIV ingericht met overflow:hidden;zoom:1 .

    Tussen de twee eerste blauwe vakjes boven, de onderste en bovenste rand van de leden ineenstorting (de kloof is gelijk aan 20 pixels, niet 40 pixels), maar omdat de laatste DIV creëert een nieuw blok opmaak context, hebben de marges van de derde paragraaf niet instorten , vandaar dat zij niet "uitsteken" van de verpakking de paragraaf, maar in plaats daarvan maken deel uit van dat blok doos.

    Let op: in IE6, zonder uitdrukkelijke marges van de DIV zou niet de marges te voegen.

    Als het aankomt op instorten marges, het creëren van een nieuw blok opmaak context werkt het zelfde als het toepassen van border of padding aan het element.

  • Blok opmaak contexten bevatten praalwagens

    Ik weet zeker dat je hebt gehoord van de zin "een float bevat altijd zweeft", of misschien wel gehoord van de FNE ( drijven bijna alles ) methode. De basis hiervan is dat drijvers zijn blok opmaak contexten, dus een betere manier om dit te formuleren wil zeggen dat "een blok opmaak context altijd drijft bevat".

    Voorbeeld:

    Deze paragraaf is een vlotter in een DIV met een blauwe achtergrond, is het ingericht met margin:20px

    Deze paragraaf is een vlotter in een DIV met een blauwe achtergrond, is het ingericht met margin:20px . De ouder DIV is ingericht met overflow:hidden;zoom:1 .

    De eerste paragraaf een drijver zodat het uit de stroom en de verpakking zakt dus de achtergrond van deze container niet weergegeven.

    De tweede paragraaf is een vlotter, maar is opgenomen in een DIV een nieuw blok opmaak context brengt, zodat de container van het kind "marge box" omsluit. U ook opgemerkt dat, in tegenstelling tot de eerste paragraaf, hoeft de voorgaande uitschakelt. Dit wordt vaak aangeduid als "self-clearing", waardoor veel zin gezien het feit dat blok opmaak contexten zijn een normaal onderdeel van de stroming.

    Let op: clear alleen wist drijft in hetzelfde blok opmaak context.

  • Blok opmaak contexten elkaar niet overlappen praalwagens

    Deze is mijn favoriet . According to the spec, the border-box of a block formatting context must not overlap the margin-box of floats in the same block formatting context as the element itself. What this means is that browsers create implicit margins on block formatting contexts to prevent them from overlapping the margin-box of floats. For this very reason, negative margins should have no effect when applied to a block formatting context next to floats (WebKit and IE6 have a problem with this though – see test case ).

    Voorbeeld: 

     .sideBar { background: skyBlue; float: left; width: 180px; } 
     .sideBar { background: yellow; float: right; width: 180px; } 
     #main { background: pink; overflow: hidden; zoom: 1; border: 5px solid teal; }

    Because this behavior is attached to the “border box” (not the “margin box”), to create space (eg, a 20px gap) between the pink box and its siblings, authors would need to either:

    • Set a 20px margin on the floats
    • Set margin values on the pink box greater than the width of the floats (ie, margin:0 220px )

    Yes, you'd use 220px , not 20px . Because it is the border-box that tries to fit between the floats, not the margin-box. And if I say it tries it is because that container would drop if there was not enough room for it between the two floats.

    In other words, if the pink box was given a 400 pixels width, that box should drop when the parent container is narrower than 770 pixels (180px + 180px + 400px + 10px). As a side note, in a few instances, this behavior appears to be broken in Firefox (at least in v.3.5.9) (ie, when the above construct is the first child of body – see test case ).

    Note : the space that shows in IE6 between the pink box and the two floats is due to the three pixel jog bug .

hasLayout versus block formatting context

As you may have noticed, all previous examples are styled using overflow:hidden;zoom:1 . The former declaration establishes a new block formatting context in modern browsers while the latter triggers hasLayout in Internet Explorer (IE 5.5/6/7). This is because these renderings are very close ( similarities with the CSS specs ). Like block formatting contexts, elements that are given a layout appear to prevent collapsing margins, to contain floats, and to not overlap floats.

Properties/declarations that give elements a layout

The lists below show that the properties that establish a new block formatting context also trigger hasLayout, at least the ones supported by the browser, with the exception of overflow in IE < 7.

In Internet Explorer 5 and 6
position:absolute
position:fixed
float (any value other than ” none “)
display:inline-block
width (any value other than ” auto “)
height (any value other than ” auto “)
zoom (any value other than ” normal “)
writing-mode:tb-rl
-ms-writing-mode:tb-rl
In Internet Explorer 7
min-width (any value)
min-height (any value)
max-width (any value other than none )
max-height (any value other than none )
elements styled with overflow (any value other than visible )
overflow-x and overflow-y (any value other than visible )
Things to consider
  • zoom and writing-mode are proprietary properties and do not validate.
  • IE 5.0 does not support zoom
  • width and height trigger hasLayout on inline elements only when these properties apply to these elements (ie, IE6 in quirks mode).
  • overflow-x and overflow-y are part of the CSS3 box model module
  • hasLayout is also triggered when the layout-flow is different from the parent layout flow (ie, rtl to ltr )

In Quirks Mode and IE7 Mode (All Versions)

  • When overflow is set to something other than visible, table-cell elements do not establish new block formatting contexts.
  • When overflow is set to visible, table-cell elements establish a new block formatting context.

HTML elements that always have a layout:

In Internet Explorer, these elements have - by default – a layout.

  • <body> (as well as <html> in Strict mode)
  • <table> , <tr> , <th> , <td>
  • <img>
  • <hr>
  • <input> , <button> , <select> , <textarea> , <fieldset> , <legend>
  • <iframe> , <embed> , <object> , <applet>
  • <marquee>

Verpakken

To reduce the risk of issues between modern browsers and Internet Explorer ( < 8), authors may choose to give a layout to boxes that establish new block formatting contexts. This way the flow is identical, elements escape floats the same way, clear clears the same floats, and margins collapse where expected. Also, authors must pay attention when styling boxes using hasLayout triggers (ie, width ) as such styling may require making that element a new block formatting context as well.

Further readings

Implications

Demos and testcases

hasLayout articles

Special thanks to Philippe Wittenbergh and Bruno Fassino for finding spec references when one needs them and to Ingo Chao for giving us the best resource on having layout .

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

YUI: Open Hours, Fri May 21st

May 19, 2010 at 10:30 am by Luke Smith | In Development | 2 Comments

It's a new week, and time for another YUI: Open Hours !

This week, we'll be joined by the inimitable Dav Glass , author of (among other things) YUI's Rich Text Editor and Drag and Drop utility , and the primary architect behind yuilibrary.com and the Gallery itself. He'll be discussing the YUI 3 Gallery project — where it's going, how to contribute — and answer any questions about it, about the site, or really about anything else while we have him on the line.

After that, we'll jump into our main event, which will be a “Gallery widget sampler”. We have a number of module authors joining us this week, including

They'll introduce their module, give an example or two, go over their API, and discuss their experience creating it. Besides just being a nice introduction to additional components available to YUI 3 users, it should provide a good platform to talk about widget API best practices and help give a sense of some of the decisions that are made during widget creation.

Thanks again to Caridy Patiño for joining us last week and reviewing his Accordion Node plugin and Dispatcher modules. We'll have more topics in the future about creating Node plugins and the reasons why the plugin approach or the widget approach might be a better fit for your needs. And thanks to Matt Sweeney (author of YUI's Node class and selector engine) for dropping in as a surprise guest as well.

The time will be the same as before, 10am – 12pm PDT and the connection details are also the same:

  1. Inbellen op 1-888-371-8922 (niet-Amerikaanse deelnemers, me te mailen voor een lokaal nummer)
  2. Enter the attendee code 4718 8953#
  3. Word lid van de delen van het scherm sessie (dit wordt u gevraagd de Adobe Connect-plugin te installeren als dit je eerste keer te gebruiken)

And as always, you can keep up to date with the upcoming schedule and topics by following @yuilibrary on Twitter or subscribing to the YUI Event Calendar .

Hoop je daar te zien!

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

Volgende pagina »
Hosted by Yahoo!

Copyright © 2006-2012 Yahoo! Inc Alle rechten voorbehouden. Privacy Policy - Gebruiksvoorwaarden

Powered by WordPress op Yahoo! Web Hosting .