Share
Twee van de meest gevierde verbeteringen aan Safari op iOS 5 zijn ondersteuning voor vaste positionering en inhouds scrollen. In deze zelfstudie leert u hoe u van deze wijziging kunt profiteren en wat de implicaties zijn voor Java-bibliotheken met stop-gap, zoals iScroll.
In een eerdere tutorial had ik het over iScroll en hoe deze geweldige kleine plug-in een probleem met iOS Webkit (5.0 en lager) en Android Webkit (2.1 of lager) oplost, waarbij er geen native ondersteuning was voor vaste positionering of schuifbare contentgebieden.
Dus, na een weekend met verschillende tests, is het goed om te bevestigen dat de iOS 5 Safari-update nu beide problemen aanpakt en we hebben nu volledige native support voor hen. Het staat al een tijdje in de pijplijn wat betreft de beta-releases voor iOS 5, maar je kunt nooit garanderen dat deze dingen de uiteindelijke release halen.
In deze tutorial zal ik deze verandering uitvoerig bespreken en zal ik je ook leren hoe je het iScroll-project van onze vorige tutorial kunt converteren naar het gebruik van de nieuwe CSS-eigenschappen.
Om expliciet te zijn, hebben we nu de mogelijkheid om web-apps te bouwen met vaste headers en footers position: fixed evenals scrollable inhoud tussendoor gebruik -webkit-overflow-scrolling. Dit stelt ons in staat applicaties te bouwen met een meer native uitstraling zonder een beroep te hoeven doen op een plug-in van derden, zoals iScroll. Zoals je zult zien, zijn er echter nog enkele goede redenen om afhankelijk te zijn van externe bibliotheken zoals iScroll.
Hoewel deze verandering geweldig nieuws is voor webontwikkelaars, zijn er enkele kanttekeningen die het waard zijn om te bespreken.
Ten eerste is de meest voor de hand liggende dat deze functie momenteel alleen wordt ondersteund in Safari 5.1. Terwijl de nieuwe 4S record-pre-orders heeft gezien en veel eerdere gebruikers al een upgrade naar iOS 5 hebben uitgevoerd, zullen er waarschijnlijk nog steeds een aanzienlijk aantal gebruikers van iOS-apparaten zijn op 5.0 of lager.
Vervolgens is er momenteel geen manier om de schuifbalk aan de zijkant van het inhoudsgebied te verwijderen. Je zou iets kunnen proberen met de WebKit-scrollbar CSS-methode om kleuren enz. Te veranderen, maar ik zie dit niet als een groot probleem. De schuifbalk is een leuk gebruikersinterface-element dat de gebruiker bewust maakt van waar ze zich in het document bevinden. Waarom zou ik het verwijderen verwijderen??
Een ander probleem: er is geen manier om het gedeelte 'elastisch banding' van de browser te definiëren, omdat het alleen rubberen randen boven en onder aan het schermgebied bevat, inclusief de adresbalk. Ik was begonnen aan een beetje JavaScript om de scrollTop-waarde aan beide zijden handmatig met 1 te compenseren, maar toen vond ik dat Joe Lambert dit al had gedaan met scrollFix.js.
Ten slotte heeft het schuifmoment momenteel geen snelheidsregeling. Dit zou leuker zijn om te hebben.
Dat is genoeg met de problemen, laten we eens kijken hoe we de nieuw ondersteunde CSS kunnen gaan gebruiken!
Laten we eens kijken hoe we ons vorige project kunnen omzetten in de nieuwe CSS-regels. We gebruiken onze eerder gebouwde pagina met iScroll voor demonstratie.
Het eerste wat u moet doen, is de JavaScript-include en de iScroll-aanroep uit de onderkant van het document verwijderen, zodat u uiteindelijk een eenvoudig HTML- en CSS-bestand krijgt zoals hieronder:
Web App-sjabloon Web App-sjabloon
- Wat spullen
- Meer spullen
- Grote spullen
- Klein spul
- Geek Stuff
- Nerd Stuff
- Snelle dingen
- Slow Stuff
- Goed spul
- Slecht spul
- Jouw spullen
- Mijn spullen
- Hun spullen
- Onze spullen
- Super spul
- Uber-dingen
- Spul
- Frans spul
- Duits spul
- Engels spul
- Amerikaans spul
- spul
We hoeven onze HTML helemaal niet te veranderen. We hoeven alleen maar wat van onze CSS aan te passen en een nieuwe klasse toe te voegen.
-webkit-overflow-scrolling: auto;
Dit is de nieuwe klasse die werd geïntroduceerd rond bèta 2 van iOS 5, en het is degene die ons het mooie momentum-scrollen geeft. Standaard is deze ingesteld op automatisch, waardoor het schuiven een stijf uiterlijk krijgt. Als u uw scrolgebied een meer native gevoel wilt geven, stelt u deze eigenschap in op aanraken.
-webkit-overflow-scrolling: touch;
Pas deze stijl nu toe op de scroll-inhoud div en we gaan een aantal van de stijlen uit de verpakking verwijderen, voornamelijk de positionering en overloop. We hebben de verpakking eigenlijk helemaal niet nodig div helemaal, dus je kunt het verwijderen als je dat wilt, maar ik wil graag een div rond om alles in te pakken als dat nodig mocht zijn. De twee CSS-regels moeten er als volgt uitzien:
#wrapper z-index: 1; Breedte: 100%; achtergrond: #aaa; # scroll-inhoud positie: absoluut; top: 0; z-index: 1; Breedte: 100%; padding: 0; --Webkit-overflow scrollen: aanraking; overflow: auto;
Vroeger hadden we de header en footer ingesteld op absoluut (omdat fixed niet werd ondersteund). We kunnen nu doorgaan en deze in de CSS plaatsen met behulp van de vaste regel om te voorkomen dat ze wegschuiven op het scherm.
header background-colour: # deb500; position: fixed; z-index: 2; top: 0; left: 0; Breedte: 100%; hoogte: 45 pixels; padding: 0; footer background-colour: # c27b00; position: fixed; z-index: 2; bottom: 0; left: 0; Breedte: 100%; hoogte: 48px; padding: 0; border-top: 1px solid # 444;
Als u het verschil tussen vaste positionering en absolute positionering niet kent, is de korte versie dat absolute positionering een gedefinieerde positie is ten opzichte van het bovenliggende element. Vaste positionering is een positie die is vastgesteld in de viewport.
Je hebt nu een schuifgebied met een vaste kop- en voettekst, zonder gebruik te maken van Javascript!
Het zal leuk zijn wanneer andere browsers inhalen (Window-telefoon, ik kijk naar je!) En de meerderheid van de gebruikers op een Android-besturingssysteem van meer dan 2,1, maar de nabije toekomst zou een aantal aardige verbeteringen in de webkit-gebaseerde browsers moeten zien. Omdat de snelheid per iteratie toeneemt, kunnen apps die met webtechnologieën zijn gemaakt, de native applicaties snel inhalen. Alles wat we nu nodig hebben, zijn meer native API's!
iScroll heeft op dit moment nog steeds een plaats. Er zijn veel parameters die we kunnen doorgeven aan de scroll-methode om wat extra opties te geven voor de manier waarop ons scrollen werkt en eruit ziet dat momenteel niet mogelijk is zonder het schrijven van aangepast JavaScript? dus waarom niet gebruiken wat al beschikbaar is?
Er is ook de kwestie van browserondersteuning. Misschien hebt u de vaste toolbars voor uw project echt nodig in oudere implementaties van de webkit-browser. Nou geen probleem. Als dit het beste is voor het project, dan is er geen schande om een van de bestaande JavaScript-bibliotheken te gebruiken om dit te bereiken. Ik zou echter willen voorstellen de native implementatie zoveel mogelijk te gebruiken.
De iScroll-bibliotheek gaat verder dan de eenvoudige scrollfunctionaliteit en biedt ook enkele geweldige aanvullende functies zoals "Pull To Refresh", "Pinch / Zoom" en "SNAP / Snap to Element". We kunnen deze in een latere iScroll-tutorial behandelen, omdat het nog steeds nuttige en relevante functies zijn.
Accentsconagua