או- למה <video> ו-<audio>  משעממים

או- פלטפורמטת הווב החדשה

או- הקדמה לHTML5

תרגמתי לאחרונה מאמר מאוד מעניין של גו'ל מרטין שנותן סקירה מעניינת (וקצת פחות בנאלית) של תקן הHTML5. המאמר תורגם למגזין של איגוד האינטרנט הישראלי ותוכלו לגשת למאגזין דרך הלינק הזה. ובכן, בלי יותר הקדמות, לפניכם המאמר.

תרגום מאמר מאת Joel Martin (kanaka)

קצת פרספקטיבה

הלידה של הווב

לפני 20 שנה (6 אוג', 1991), טים ברנס-לי שחרר את ה-World Wide Web לעולם, בזמן שעבד בCERN-. למעשה, מה שהוא שיחרר הייתה תוכנה שנקראה "WorldWideWeb" שלאחר מכן שונתה לשם "Nexus" על-מנת ליצור הבדלה בין הקונספט של World Wide Web והדפדפן.

הדפדפן ההתחלתי היה יכול לרנדר מסמכים אשר היו כתובים ב-HyperText Markup Language (HTML)‎. הHTML- הראשון תמך במספר מצומצם של פורמטי עיצוב ובהיפר-לינקים (כיום אנחנו פשוט קוראים להם לינקים) למסמכים אחרים. מוצג כאן צילום מסך, שנתיים לאחר מכן – כאשר התמיכה בצבעים ותמונות נוספה:

דפדפן WorldWideWeb מורץ על מערכת NeXT

התקומה של הווב

במשך 10 השנים הבאות "הווב" הופצץ במונחים של חדשנות, תקינות¹, מספר משתמשים, דפדפנים (התקנות וגרסאות), שרתי ווב (התקנות וגרסאות), והשפעה כלכלית. יחד עם השחרור של Mosaic(ב-NCSA) ב-1993, עם שילוב החלק בין גרפיקה לטקסט, ה- World Wide Web החל במהרה להיות השימוש הדומיננטי ביותר של האינטרנט והכוח המניע לאימוץ האינטרנט. למעשה, לרוב משתמשי המחשב "הווב" ו"האינטרנט" הפכו להיות מילים נפרדות.

הנפילה של הווב

במפנה המאה, החדשנות בווב האטה בגלל הדפדפן Internet Explorer של מיקרוסופט, שיצר כמעט מונופול בשוק הדפדפנים. ברגע שמיקרוסופט השיגו שליטה רחבה בשוק הדפדפנים הם איבדו עניין בהנעת או בשיתוף פעולה לתקני אינטרנט חדשים וטכנולוגיות, מהסיבה שזה אולי יפגע ברווחיות של פלטפורמתWindows.

התקומה של הווב (בפעם השנייה)

במהלך שלוש השנים הבאות החלה הפצצה חדשה של חדשנות וובית. הווב יצא מתוך המערה שלו בגלל שלושה טרנדים מרכזיים: העלייה של Mozilla Firefox (צאצא רוחני של הדפדפן Mosaic), העלייה שלGoogle Chrome והעלייה בשימוש במכשירים סלולאריים.

חלוקת השימוש בשוק הדפדפנים (Wikimedia)

אחת התכונות של בני-אדם היא לתת לכל דבר שם, כולל מושגים מופשטים. האנרגיה החדשה והחדשנות שאפפו את פלטפורמת הווב לא יצרה מצב שונה – היה צריך לתת לזה שם. מה שמחזיר אותנו ל-"HTML5" …

"HTML5"

טכנית, HTML5 הוא מפרט של ה-²World Wide Web Consortium (W3C)‎. אנשים קפדנים רבים יטענו שזה השימוש היחידי שצריך להיות. לכל שאר האנשים, HTML5 הוא מושג שימושי לתיאור של השינויים המהירים שקורים בזמן הנוכחי לפלטפורמת הווב. לזה אני מתכוון כשאני משתמש במושג "HTML5". התייחסות למפרט של הW3C- תעשה באמצעות המושג "W3C HTML5".

W3C HTML5

למרות שמפרט הW3C HTML5- לא יהיה משוחרר רשמית עד 2014, כבר בתחילת חודש אוג' המפרט סיים את סיקור הקריאה האחרונה כך שככל הנראה לא יהיו שינויים מהותיים בשלוש השנים הבאות עד לשחרור התקן.

W3C HTML5 זה שעמום המחץ

ה-W3C HTML5 הוא מאוד חשוב מצד אחד, אבל מצד שני הוא גם דיי משעמם. זה למעשה תיאור רשמי של כל הדברים העדכניים בפלטפורמת הווב בשלוש השנים האחרונות. התוכן של המפרט כתוב בצורה דיי יומיומית (בשונה מהאופי הטכני של מפרטים בדר"כ). הAPI- המעניין ביותר בW3C HTML5- הוא Canvas 2D והוא מוגדר במסמך נפרד.

W3C HTML5 הוא חשוב

למרות זאת, הW3C HTML5- הוא חשוב בגלל שהוא גורם לכל הרעיונות הטובים שנלמדו במרוץ השנים להפוך לרשמיים, והוא מנסה לבטל את רוב הדברים שנחשבים כיום כטעויות. בנוסף הוא גם מעניק שכבה נוספת של עקביות ושלמות לDOM APIs- ולאלמנטי הHTML-. וכנראה הכי חשוב, הוא גרם ליצרניות הדפדפנים השונות להסכים ביניהן. הכוונה היא שמפתח ווב שמפתח כפי שמפורט במפרט הW3C HTML5-יוכל ליצור אפליקציה אחת שתעבוד בצורה הולמת בכל גרסאות הדפדפנים המודרניים בלי הצורך להתאים את קוד האפליקציה לכל שטיק של כל דפדפן.

W3C HTML5 נגד HTML5

אם נסכם את ההבדלים בין המפרט W3C HTML5 והקונספט הכללי של HTML5:

• הW3C HTML5- מקדם רבים מן האלמנטים דרג ב' כמו וידאו, אודיו, אנימציות, טפסים חכמים וכו' לאלמנטי דרג א'.
• HTML5 (בשימוש הנפוץ) לוקח את האלמנטים החדשים הללו ומוסיף להם כח ופונקציונאליות שלא היה אפשרי בעבר. HTML5 מייצר בנוסף סט שלם של אלמנטים מדרג א' מטכנולוגיות שלא היו חלק מהווב בהתחלה כמו גישה לחומרת מכשיר, מידע בינארי, גישה למערכת הקבצים, multiprocessing וכו'.

או בדרך אחרת נסכם את מערכת היחסים בין השניים:

מפרט הW3C HTML5- משמש כקרקע ומסגרת עליה כל פיתוחי ה-HTML5 המעניינים שקורים.

החלקים המעניינים ביותר בHTML5-

כעת הגענו לעיקר במאמר זה- לתת רשימה ולפרט את הAPIs- של HTML5, תקנים והטכנולוגיות החשובות ביותר (והמעניינות ביותר). ניסיתי לדמיין כיצד יראה הווב בעוד 5 שנים, ומנקודת המבט המקדימה הזאת להחליט איזה חלקים בHTML5- הם החיוניים ביותר על-מנת לקדם אותנו לעתיד הזה.

הרשימה הבאה מסודרת לפי סדר החשיבות מהחשוב ביותר לפחות חשוב. כמובן שזה רק הדעה הסובייקטיבית שלי. אני מפתח אפליקציות ווב (noVNC, websockify) ומשתתף בקבוצות העבודה והדיונים של HTML5, אבל כמובן שהעתיד הוא תמיד יותר מעניין (ופחות) ממה שכל מומחה יכול לחזות.

אז ללא הקדמה נוספת…

1. מנועי Javascript מהירים יותר

   הווב כפלטפורמת אפליקציות נבנה על זה יותר מכל דבר אחר. מנועי הJS החדשים הם טכנולוגיית ה"על-חלל" (Wrap Drive) של הווב. ללא טכנולוגיית ה"על-חלל", מסע בין כוכבים היה סיפור שמתרחש על כדור הארץ (או במקרה יותר טוב במערכת סולרית בודדה). ללא גידול המשמעותי בביצועי הJS- היינו היום עדיין מדברים על דפי ווב ולא אפליקציות ווב.

2. WebSockets

   וובסוקטס יקדמו את הדפדפן לעולם של אפליקציות רשת מתקדמות. אחרי שנוספו לנו מנועיJavascript מהירים, רשתות עם latency נמוך הם בעלי הפוטנציאל הגדול ביותר לאפשר לווב לשלוט בתחומי אפליקציות חדשים.

3. סוגי נתונים בינאריים (Typed Arrays ו-Blobs)

   Javascript התחילה את דרכה כדרך לביצוע אימות של נתונים טקסטואליים בטפסים. עם זאת, אלמנטים רבים מדרג א' שהוצגו לראשונה ב-HTML5 מכילים, מקבלים ו/או שולחים מידע בינארי ולכן נוצר הכרח ביצירת סוגי מידע בינאריים אשר מוגדרים ב-Javascript. מפתחים השתמשו במשך שנים רבות בכל מיני סוגי "האקים" על מנת לקודד מידע בינארי בסוגי הנתונים הישנים ב-Javascript. אבל השימושים ב"האקים" הללו הם מחסום רציני ולא נוכל לממש את הכוח המלא של HTML5 ללא תמיכה בנתונים בינאריים.

4. Web Audio API

   לא מדובר בתגית ה-<audio>, אלא בAPI-ים / הצעות לאפשר מניפולציות בסאונד ב-latency נמוך, באופן ישיר באמצעות Javascript. תגית <audio> (שהיא חלק מה-W3C HTML5) מאפשרת להטביע קובץ אודיו ישירות בדף האינטרנט ומציעה API להשמעה וסנכרון.

   ההצעות ל-Web Audio API מאפשרות יצירה ומניפולציה של סאונד באופן ישיר וגם מטפלות בבעיות של פסקול ב-latency גבוה שקיימות היום במימוש של תגית ה-<audio>.

   ההצעות הללו עדיין בשלבים ראשוניים ויתכן והפתרונות הסופיים יתאחדו לבסוף עם תגית ה-<audio>, אבל הבעיות שנפתרות ע"י ההצעות ל-Web Audio API יהיו חלק מעתיד הדפדפנים בצורה כזו או אחרת.

5. Canvas 2D Context

   מניפולציית פיקסלים בצורה ישירה. כולם מסכימים שזה חשוב אז אני לא אוסיף עוד הרבה. שמתי את זה מתחת ל-8iy-Web Audio API מכיוון ורוב הדברים שניתן לעשות עם Canvas 2D ניתן לעשות עם מתודות אחרות (SVG, WebGL, CSS3).

6. CSS3 ו-WOFF

   גיליונות עיצוב מדורגים 3 (3 Cascading Style Sheets) ופורמט הפונט הווב הפתוח (Web Open Font Format) מביאים יחד את העוצמה המלאה של עיצוב, טיפוגרפיה, layout ותזוזה ויזואלית לווב. כמו כן, עם CSS3 (במיוחד מודל ה-Flexible Box), אפליקציות ווב יוכלו ליצור עיצוב לממשק משתמש בצורה פשוטה וחזקה ללא הבלאגן הנדרש בCSS2- במיקום אלמנטים.

7. Local Storage, אפליקציות Offline ו-APIs לקבצים

   יש הרבה תחומים של אפליקציות שלא יכולות להתקיים ללא אחסון מידע מהיר, מקומי וקבוע (לפחות עד שיהיה לכולם חיבור אינטרנט ג'יגהבייטי בזול). כמו-כן לכמה מהאפליקציות דרוש שיטת אחסון מידע מקומית למקרה בו אין חיבור אינטרנט זמין. ישנם מספר סטנדרטים/APIs שמפותחים בתחום הזה אבל כל אחד מהם מטפל באספקטים שונים של אותה מגבלה בסיסית של דפדפני הפרה-HTML5.

8. Web Workers

   חוק מור מת, יחי חוק מור! הגידול, שנה אחרי שנה, בCPU- בזכות חוק מור נגמר לפני מספר שנים. אבל חוק מור היה למעשה הצהרה של מחיר / צפיפות של טרנזיסטורים וזה לא השתנה, רק הנושא השתנה: ליבות מעבד לכל אינץ' של שבב. בעוד מספר שנים, אפילו למכשיר הסלולרי שלך יהיו יותר ליבות מעבד מאשר כמות האצבעות שלך.

   מודלים של תוכנה חדשים נדרשים כדי לנצל את מלוא היתרונות במציאות של חוק מור של ריבוי ליבות. למרבה המזל, למרות ש-Javascript הייתה תמיד שפת single-thread היא עוצבה מלכתחילה גם כשפה מונעת אירועים. זה אומר שלמרות שאי-אפשר להריץ כמה שורות שלJavascript באפליקציית ווב בודדת בו-זמנית, הדפדפן יכול לעשות כמה דברים בו-זמנית בחסות קוד ה-Javascript שרץ.

   היכולת להיות מונע מאירועים מגיע לגבול מסוים. המפרט של Web Workers נוצר על-מנת לאפשר לאפליקציית ווב בודדת לקיים הרצות של מספר אשכולות של Javascript סימולטנית. על-מנת למנוע סיבוכיות שבדרך כלל מגיעה בתכנות בmulti-threaded (מנעולים, מבני נתונים מיוחדים וכ"ו), Web Workers הן יחידות Javascript עצמאיות והן יכולות לתקשר אחת עם השנייה ועם אשכול ה-Javascript הראשי באמצעות הודעות מבוססות אירועים.

9. SVG 1.1/2.0

   פורמט ה-SVG (Scalable Vector Graphics) היה כאן בסביבה כבר הרבה זמן וכמה דפדפנים אפשרו הטמעה של תמונות SVG בתוך דפי אינטרנט. SVG מתחיל סוף סוף להיות מאומץ ע"י כל יצרני הדפדפנים בצורה של APIs חזקים אשר מאפשרים גישה מלאה ואפשרות למניפולציה לאלמנטים המוכלים בו (כלומר אלמנט מדרג א').

   היה קשה למקם את SVG ברשימה הזו. הרבה (עם לא רוב) השימושים ב-Canvas 2D Contextהם למעשה מתאימים יותר ל-SVG ובמובנים רבים SVG הוא הרבה יותר חזק. עם זאת, ל-SVGיש היסטוריה לא יציבה ואני חושש שהוא צבר סוג של מטען נפשי לא מוצדק שיפריע לו להיות אבן יסוד וחשוב כמו שהוא צריך להיות. אני אשמח לגלות שטעיתי ושהוא יהפוך לטכנולוגיה חשובה יותר ממה שחזיתי לו.

10. WebGL

    WebGL הוא ה-Canvas 3D Context וזה למעשה – האצת חומרה באמצעות OpenGL APIבשביל הווב. בדומה לSVG, יש לו פוטנציאל להיות חלק חשוב מאוד מתוך ה-HTML5. אבל אמרתי פוטנציאלי מכיוון ומיקרוסופט מזלזלת בצורה מוסיימת ב-WebGL (יתכן מכיוון שהוא מוגדר במונחים של OpenGL ולא בAPI- שלהם - DirectX) ולכן קיימת אי-ודאות האם הטכנולוגיה תכנס לתוךInternet Explorer. אם לא היו האי-ודאויות הללו הייתי בוודאי ממקם את WebGL גבוה ברשימה מכיוון והטכנולוגיה הזו פותחת שער להרבה תחומי אפליקציות מעולמות חדשים (כמו משחקי 3Dלדוגמא).

11. כל השאר

    החזון האולטימטיבי של אלה שדוחפים קדימה את פלטפורמת הווב היא להפוך את פלטפורמת הווב לחזקה, מסוגלת ומקיפה כמו אפליקציות נייטיב. כל אחד מ-10 הנושאים שהוצגו כאן פותח את פלטפורמת הווב להרבה תחומי אפליקציות חדשים שהיו קיימים עד היום רק באפליקציות נייטיב. אבל הם משאירים עוד פערים רבים שעוד נצטרך למלא לפני שיגיע היום העתידי בו מפתחים לא יצטרכו לשאול "האם אני יכול לפתח את זה כאפליקציית ווב?" אלא כ: "האם אני רוצה לפתח את זה כאפליקציית ווב?".

    ישנן אינספור טכנולוגיות אשר מנסות לענות על הפערים הללו בפונקציונאליות של אפליקציות ווב. חלקן היו מופיעות גבוה יותר ברשימה אם היו יותר בשלות או שהיה פחות חוסר ודאות לגבי מידת האימוץ שלהן ע"י יצרניות הדפדפנים. הנה רשימה חלקית של טכנולוגיות/APIs אשר מנסות להשלים את הפערים:

    • WebRTC/Stream API: שיחות וידאו Peer-to-peer.
    • Geolocation: איפה אני בעולם?
    • Orientation: איזה כיוון זה למעלה?
    • Crypto: הצפנה/פענוח יעילים ב-Javascript.
    • WebCL: גרסת האינטרנט של OpenCL. מי לא היה רוצה להשתמש בGPU ישירות דרך תכנות ב-Javascript?
    • WebNotifications: תגיד לי מה קורה, אבל בעדינות.
    • Web Intents: סוגי נתונים אסוציאטיביים עם פעולות ברירת מחדל והעברת נתונים הלוך חזור בין אפליקציות ווב. אפליקציית ווב המעודפת עליך לעריכת תמונות תוכל לשתף את המידע לאפליקציית הווב שלך ליצירת מצגת. ונאמר אמן.
    • נראות דף: נסו לדמיין כמה אנרגיה העולם יחסוך עם כל האנימציות והסרטים יפסיקו להתרנדר בזמן שאתם לא מסתכלים עליהם.
    • requestAnimationFrame: עם פקודת setTimeout אתה מקבל 100 FPS או 2FPS(לרוב באותה שנייה). עכשיו תוכל לקבל באופן קבוע 30FPS. ויש הרבה יותר שמחה בעולם.
    • Microdata: ניתוח חד-משמעי של מידע מוטבע באמצעות מידע מובן למכונה.
    • וכו'
    • וכו' ³

    

    Mac נגד PC נגד דפדפן (מתוך xkcd.com)

מה לגביי <video> ו- <audio>?

תגיות <video> ו-<audio> הן ככל הנראה התגיות של HTML5 שגרמו להכי הרבה התרגשות (וחרדה) בווב בהקשר של HTML5. למעשה, חלק מכם כבר סרקו מראש וחיפשו אותם ברשימה והיו מופתעים לגלות שהם לא היו #1 ו-#2. שני האלמנטים הללו הן חלק מ-W3C HTML5 ולמרות שהן הפכו את השימוש המסורתי באלמנטים מדרג ב' (לדוגמא מה שנעשה באמצעות פלאש) לשימוש באלמנטים מדרג א', הן עדיין רק דרך טובה יותר לעשות משהו שכבר נעשה בעבר. תגיות <video> ו-<audio> לא מרחיבות בצורה משמעותית היקף היכולות של אפליקציות ווב וזו סיבה ראשונה לחוסר הנוכחות שלהן ברשימה. בעיה נוספת שיש בתגיות הללו שהרשימה של פורמטי המדיה הנתמכים שונה מדפדפן לדפדפן. עד שהבעיה הזאת תיפטר האימוץ של התגיות הללו יהיה קלוש⁴.

הערות שוליים

מוצגת כאן רשימה של כמה סטנדרטים משמעותיים שפותחו סביב פלטפורמת הווב בשנים הראשונות לאחר שהדפדפן הראשון שוחרר ע"י טים ברנס-לי:

1. • 1995 - HTML 2.0 הופץ כסטנדרט הראשון של HTML.
   • 1995 - HTML עושה את צעדיו הראשונים לעבר הפיכתו לדינאמי ואינטראקטיבי כאשרJavascript נוצר ע"י ברנדן איך (Brendan Eich) ונוסף לדפדפן נטסקייפ (Netscape Navigator 2).
   • 1996 – ספציפקציית CSS1 (Cascading Style Sheets) מוכנה וחלקים ממנה מופיעים ב-Internet Explorer 3. חלק מהסיבה ל-CSS הוא ליצור הפרדה בין תצוגה של דף אינטרנט ומהתוכן והפונקציונאליות. בעקבות זה נוצר עיקרון במדעי המחשב של הפרדה בין חלקים.
   • 1998 – ספסיפיקציית DOM שלב 1 (DOM Level 1 - Document Object Model), ה-API של אלמנטי HTML בעמוד, שוחרר ע"י W3C.
2. אני צריך לציין עוד קבוצה חשובה (עם שם ארוך ונוטה לשיכחה) שמעורב בסטנדרט של HTML, הקבוצה Web Hypertext Application Technology Working Group (WHATWG). רבים (אולי כל) האנשים שנמצאים ב-WHATWG ומשתתפים בעבודה ב-W3C. ה-WHATWG יכול להיחשב כיותר דינאמי ופחות נוקשה מאשר ה-W3C.ה-WHATWG שומרת על מסמכי סטנדרטי-על. הראשון הוא HTML. רבים מהרעיונות שנמצאים ב-W3C HTML5 נכתבו לראשונה שם. המסמך הזה יכול להיחשב גם כ-HTML5+. הסטנדרט השני נקרא Web Apps 1.0. הוא מכיל את התוכן של מסמך ה-HTML ומוסיף רבים מה-APIsשנחשבים לאלה שגורמים לווב להיות פלטפורמה אפליקטיבית לכל דבר.מסמך WHATWG Web Apps 1.0 כבר הרבה יותר קרוב למה שאנשים מתכוונים כאשר הם משתמשים במושג "HTML5", עם זאת, אפילו זה לא מתמצת את כל המשמעות הטמונה בו. יש עוד APIs רבים והצעות שהם חלק מהאנרגיה החדשה של הווב שהם כבר עכשיו בדרך או עתידים להיות בדרך להיטמע ברוב הדפדפנים (באמצעות תהליך הסטנדרטיזציה או בלעדיה).
3. וכו'. אני עדיין לא מכיר הצעה/API עם שלושת האותיות האלה. השאלה היא האם המאמר הזה יגרום לכך שיהיה יותר סיכוי או פחות סיכוי שיהיה כן כזה בקרוב?
4. ע"י שילוב של Javascript מהיר, WebSockets, Canvas, Web Audio וסוגי מידע בינארי נוכל לקבל וידאו ואודיו ללא תגיות ה-<video>/<audio> וללא תוספים (Plugins). ה-frame rateוהרזולוציה יכול להיות נמוכות מהרצוי אבל זה אפשרי.

מקורות

• Dive Into HTML5
• HTML5Rocks
• Excellent Presentation on HTML5 from HTML5Rocks
• When can I use… Compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers.
• HTML5 Readiness - Flower chart of HTML5 & CSS3 features in major browser versions
• The HTML5 Test - How well does your browser support HTML5?
• The Web Platform: Browser technologies ()
• HTML5 Tweets
• W3C Blog
• WHATWG Blog
• Google Chrome Blog
• Mozilla Firefox Blog
• Opera Developer Blog
• Microsoft Internet Explorer Blog
• "An Open Web" book
• "20 Things I Learned About Browsers and The Web" Google comic
• "What is HTML5"

לינקים

• Early History of the Web (W3C)
• Where the web was born (CERN)
• W3C
• W3C HTML5
• WHATWG
• WHATWG HTML
• WHATWG Web Apps 1.0
• 1. EcmaScript/Javascript: ECMA-262
• 2. WebSockets
  • API: W3C, WHATWG
  • Protocol: IETF/HyBi
• 3. Binary Data Types
  • Typed Arrays
  • Blob Type
• 4. Web Audio: Google, Mozilla, W3C
• 5. Canvas 2D Context: W3C, WHATWG
  • CSS3: W3C
  • WOFF: W3C
  • Web Storage: W3C
  • IndexedDB: W3C
  • Offline Applications: W3C, WHATWG
  • File/Reader: W3C
  • File Writer: W3C
  • File Dir/System: W3C
• 6. CSS and WOFF
  • W3C 1.1
  • SVG 2.0 W3C Roadmap
• 7. Local Storage, Offline Application and the File APIs
  • WebRTC/Stream API
  • Geolocation
  • Orientation
  • Crypto
  • WebCL
  • WebNotifications
  • Web Intents
  • Page Visibility
  • requestAnimationFrame
  • Microdata
• 8. Web Workers: W3C, WHATWG
• 9. SVG 1.1/2.0:
• 10. WebGL
• 11. All the Rest
• websockify – WebSocket to TCP socket proxy/bridge -https://github.com/kanaka/websockify
• noVNC – HTML5 VNC Client - https://github.com/kanaka/noVNC

מאמרים נוספים:

• QuickText תוסף שימושי ל-notepad++
• מנוע חיפוש שמתאים בין תו, לקוד HTML

כחלק מתקן HTML 5 שקורם עור וגידים בימים אלו, הולכת להיכנס לחיינו אופציה חדשה, חשובה ומעניינת – Offline. המימוש של אופציה זאת תאפשר לנו בתור בוני אתרים, לבנות אפליקציות אינטרנט שיודעות לגלות מתי היוזר עובד במצב לא-מקוון, ליצור פתרונות משלימים לגולש להמשך עבודה במצב לא מקוון וכך למעשה להרחיב את האפלקציה האינטרנטית שלנו למצב בו היוזר מחובר לאינטרנט ולמצב בו הוא לא מחובר. בפוסט זה אני אנסה לסקור את הטכנולוגיה החדשה, לתת לכם אסבר כיצד תוכלו אתם לבנות אפלקציות לא מקוונות וכמובן, כהרגלי בקודש, לתת לכם דוגמא פועלת לאפליקציה כזו. יאללה בואו נרוץ על זה.

חשוב לדעת שעל-מנת לראות את הדוגמא שהכנתי, אתם צריכים לגלוש בדפדפן Firefox, החל מגרסה 3 ומעלה. בעתיד שתקן HTML 5 ישוחרר, כל הדפדפנים יתמכו, בצורה זו או אחרת בשירותים לא-מקוונים, בינתיים, אני לא ממליץ להשתמש בטכנולוגיות לא-מקוונות באתרים שתכינו (כמובן מחוסר תמיכה בשאר הדפדפנים).

לפני שאני אתן דוגמא חשוב להסביר את הצורך של הגולש במתן שירותים במצב לא-מקוון.

למה אנחנו צריכים את זה?

עד היום אפלקציות אינטרנט עבדו במצב אחד – אונליין. כל העבודה שלנו מול אתרי האינטרנט החלה לאחר שהתחברנו לרשת והפסיקה בשנייה שהתנתקנו (או לחלופין שאיבדנו את החיבור לאינטרנט). כיום אנו מחוברים לאינטרנט דרך אמצעים שונים (מחשב נייד, סלולרי, מחשב נייח…) ובמקומות שונים (במשרד, בבית, בנסיעה ברכבת, בטיסה…). בגלל אופן צריכת האינטרנט שלנו לא ניתן להבטיח שתמיד נוכל להיות מחוברים. כאשר אין לנו חיבור לאינטרנט אין סיבה שנפסיק לעבוד על האפלקציות האינטרנט השלנו במצב לא-מקוון.

קחו לדוגמא שירות של אימיילים, אין סיבה שלא נוכל להמשיך לקרוא מיילים ולכתוב מיילים במצב לא-מקוון וכאשר יחזור חיבור אינטרנט, האפלקציה תסתנכרן לשרת האימיילים, קרי, תשלח את המיילים שכתבנו אופליין ותטען את המיילים החדשים.

כיצד זה עובד?

לאחר שהבנו את הצורך בשימוש בטכנלוגיות לא-מקוונות. בואו נעבור לתאוריה. טכנולוגיה העובדת במצב לא-מקוון צריכה למעשה לשמור שני סוגים של נתונים על מחשב הגולש. הסוג הראשון, הם קבצי האתר ההכרחיים לעבודה במצב מקוון (לדוגמא: תמונות, קבצי JS, קבצי HTML). הסוג השני של הנתונים שצריכים להישמר על מחשב הגולש הם המידע שהגולש מזין, בדוגמא של האימיילים, הנתונים שהגולש מזין הן הודעות חדשות. בנוסף לשמירת הנתונים על האפלקציה להיות מודעת מתי הגולש עבר ממצב מקוון למצב לא-מקוון ולהפך על-מנת לדעת היכן לשמור נתונים ומתי לסכרן את הנתונים מול השרת.

אם נסכם את הפסקה הקודמת לבניית האפלקציה עצמה, נגלה שכדי לגרום לאפליקציה לעבוד במצב לא מקוון צריך לדאוג לשלושה דברים:

1. הגדרת קבצי האתר שישמרו ב-catch באמצעות קובץ manifest.
2. שמירת נתוני הגולש באמצעות אובייקט localStorage.
3. טיפול בהתחברות והתנתקות הגולש באמצעות אירועי התחברות-התנתקות.

קובץ manifest

נתחיל בנקודה הראשונה, כפי שהסברתי, נתונים שאתר צריך על-מנת לעבוד במצב לא מקוון צריכים להישמר אצל הגולש. כיצד עושים זאת? פשוט מייצרים קובץ עם סיומת manifest. הקובץ יכיל רשימה של קבצים אותם הדפדפן ישמור לעבודה לא-מקוונת. אתם מוזמנים לראות דוגמא לקובץ מאניפסט שיצרתי לאפלקציה הקטנה שלי:

כפי שאתם רואים, הקובץ מכילה רשימה של קבצים שאותם אני מעוניין לשמור במחשב הגולש לאפשרות בו הוא יעבוד במצב לא-מקוון. שמרתי קובץ תמונה, קובץ CSS, קבצי JS וקובץ htm. השורה השלישית היא כמובן הערה, חשוב לשים לב שהדפדפן פיירפוקס ישמור את רשימת הקבצים שמופיעים במאניפסט רק בפעם הראשונה שהוא מגיע לאתר ובכל פעם שנוצר שינוי בקובץ המאניפסט, כך שאם עדכנתם קובץ ואתם מעוניינים שהדפדפן ישמור מחדש את הקבצים ב-catch שנו פרט כלשהו בקובץ המאניפסט, לדוגמא: שנו את הערת הגרסה ל"v3".

לאחר שהבנו את הנקודה הזו נעבור לנקודה השנייה.

שמירת נתונים במחשב הגולש

ישנן שתי דרכים לשמור נתונים במחשב הגולש:

• window.sessionStorage – שמירת נתונים כל עוד הדפדפן פתוח. ברגע שייסגר ימחקו כל הנתונים.
• window.localStorage – שמירת נתונים לאורך זמן. הנתונים ישמרו גם לאחר יציאה מהדפדפן ואף כיבוי המחשב.

לשני האובייקטים הללו ישנם אותן פעולות ומאפיינים:

• setItem(שם מפתח, ערך) – הוסף או עדכן ערך באובייקט האחסון.
• getItem(שם מפתח) – אחזור ערך מתוך אובייקט האחסון.
• removeItem(שם מפתח) – מחיקת ערך מתוך אובייקט האחסון.
• length - מספר הערכים ששמורים.
• key(אינדקס) – שם המפתח באינדקס.
• clear() – אתחול אובייקט האחסון (מחיקת כל הערכים).

לדוגמא:

חשוב לציין שבדומה לעוגיות, אחסון מקומי נשמר יחסית לאתר. כלומר, מאתר htm לא נוכל לגשת לנתוני אחסון מקומי שנשמרו מאתר gmail.

אירועי אונליין/אופליין

שמרנו את כל הנתונים הרצויים על מחשב הגולש, כעת אנו צריכים להאזין לאירועים בהם הגולש עובר למצב לא-מקוון והפוך. זאת ניתן לעשות באמצעות קריאה לאירועי online ו-offline.

מה שאנו רואים בקוד הוא שבצורה מאוד פשוטה ניתן להאזין לאירועים בהם הגולש עבר למצב של אופליין והפוך. במימוש הבסיסי של אפלקציות אופליין, נכניס לתוך הפונקציה של המעבר לאופליין את שמירת הנתונים החשובים לאחסון המקומי, ובפונקציה השנייה (מעבר לאונליין), נכניס את הקוד שמסכרן את השינויים שביצענו אופליין עם השרת.

בנוסף המאפיין navigator.onLine, מחזיר true או false כאשר הדפדפן במצב אונליין, אופליין בהתאמה. המאפיין הזה נתמך ברוב הדפדפנים.

חשוב לציין כי בשני המקרים הדפדפן לא מחזיר ערך לפי חיבור האינטרנט אלא לפי המצב אותו הגדיר הגולש. כלומר, לא נוכל לגלות שהיוזר התנתק מהאינטרנט אלא נוכל לגלות מתי היוזר עבר למצב בו הוא מעוניין לעבוד במצב לא-מקוון.

סיכום ודוגמא

לאחר שסקרנו את כל ההיבטים להם אנו זקוקים לבניית אפלקציית אופליין, אתם מוזמנים להציץ בדוגמא שבניתי:

בדוגמא, עברו למצב אופליין (file-> Work Offline) שנו את שורת הטקסט ולחצו save. כאשר תעברו חזרה למצב אונליין הדפדפן יעלה את התוכן שהזנתם אוטומטית לשרת ויעדכן את מסד הנתונים. שימו לב שבמצב אופליין תוכלו לגשת לעמוד האינטרנט של הדוגמא למרות שהוא נמצא בשרת מרוחק (כי למעשה קבצי האתר שמורים אצלכם במחשב בזכות קובץ המאניפסט).

כעת גם אתם מוזמנים לשחק עם הטכנולוגיה החדשה הזו ולבנות בעצמכם אפלקציות שעובדות במצב לא מקוון.

עוד באותו נושא:

• הוספת כתוביות לתגית וידאוAdding subtitles to a video tag
• HTML 5 – מה נכנס ומה יוצא? – חלק ב'

בזמן שלא הייתי כאן הייתי עסוק בבניית מערכת ניהול תוכן לחברת בניית האתרים שלי. את מערכת ניהול התוכן שלי בניתי ב-Zend Framwork שזהו Framework של PHP. מאוד נהנתי להשתמש בכלים שZF מעניקה, ורציתי לספר לכם קצת מה זה פריימוורק לPHP, מה זה ZF ולמה ומתי כדאי לכם להשתמש בהם בתכנות PHP.

Framework

פרייוורק היא למעשה ספריית קוד אשר בנויה על בסיס שפה מסויימת (כולם בוודאי מכירים את הספרייה JQuery שמרחיבה את Javascript). הספריה מרחיבה את אפשרויות השפה הקיימת ומאפשרת ליצור קוד בצורה מהירה יותר ואפקטיבית יותר. לרוב לפריימוורק יהיה API משלו אבל הוא יתמוך כמובן בAPI של השפה אותו הוא מרחיב.

באמצעות ה-API של הפרייוורק נוכל להשתמש בכלים מתקדמים שהפריימוורק מספק ובכך לייעל את עבודתנו בתור מתכנתים.

Zend Framework

טוב עכשיו אחרי שסיברתי את אוזנכם קצת בנוגע לספריות הרחבה לשפות תכנות (framework), אני אספר לכם על Zend Framework.

הספרייה Zend Framework או בקיצור ZF היא ספריית PHP שפותחה ע"י זאב סורסקי ואנדי גוטמנס, מכאן שמה (זאב+אנדי = זאנד). יוצרי הסביבה הם ישראלים יוצאי טכניון שפיתחו בין השאר גם את שפת PHP (נחמד לא?). בדומה לPHP, מטרת הספרייה היא בניית אפליקציות אינטרנטיות. הספרייה רשומה בקוד פתוח ובנויה על סביבה מונחת עצמים עם הפרדת Model-View-Controller (בקיצור MVC).

MVC – אחד הדברים היפים ביותר בZF. כל הרעיון מאחורי ההפרדה הזו (שתוכלו לקרוא עליה עוד בויקיפדיה), היא שהיא מכריחה אותנו (המתכנתים) להפריד בין עיצוב לבין קוד, וגם הקוד מחולק לשניים. שיטת MVC עושה זאת ע"י הפרדה ל-3 שכבות – המודל, שאחראי על האובייקטים המרכזיים במערכת, הבקר, שאחראי על יצירת התוכן המעובד, והתצוגה, שאחראית לסדר את האופן בו יראה כל דף. כעת נרחיב:

• Model – זוהי השכבה שמכילה את אובייקטי המערכת המרכזיים (אלה שלא קשורים לתצוגה או לפעולה כלשהי), בשכבה הזו נבנה ונייצג כל אובייקט במערכת שלנו. השכבה הזו אינה מתממשקת באופן ישיר עם מסד הנתונים אך דרכה מתבצע הקישור. אני משתמש בשיטה ה-data mapper להתממשקות עם מסד הנתונים.
• View – שכבת התצוגה. בשכבה זו צריך כמה שיותר להמנע מכתיבת סקריפטים ותפקידה העיקרי הוא להציג את פלט הקוד שנוצר בשכבת ה-Controller.
• Controller – השכבה שבעצם מכילה את הפעולות של כל חלק באפלקציית האינטרנט. היא למעשה מחברת בין שכבות הModel והView בכך שהיא משתמשת במודולי המערכת ומעבירה מידע לשכבת התצוגה.

קשה מאוד להבין את השימוש ב-ZF לפני שפשוט מנסים אותה. אבל המלצה כנה ממני, תנסו ותרוויחו. ישנם ספריות רבות המרחיבות את PHP בינהם CodeIgniter ו-CakePHP, הספרייה ZF נחשבת למתקדמת ביותר ובל נשכח שהיוצרים שלה הם אלה שיצרו את ה-PHP, אני חושב שזה נותן להם קצת קרדיט. בכל מקרה למי שסקפטי ולא בטוח לגביי הספרייה אותה הוא רוצה ללמוד, האתר הבא מאפשר להשוות בין הפריימוורקים השונים לPHP והמאמר הבא מתוך nettuts מסביר כיצד כדאי לבחור פריימוורק באופן כללי (לא רק לPHP).

לסיום אני רוצה לצרף לכם לינק לאתר נפלא שנותן מספר סרטוני הדרכה בוידאו ללימוד ZF. אני התחלתי ללמוד משם, ובאמת שזו דיי דרך טובה להתחיל להשתמש בZF (הסרטונים באנגלית).
כמו כן בטח תוכלו להעזר בדוקומניזציה של ZF, היא מלאה בהרבה מאוד תוכן ועם שילוב של חיפוש בגוגל היא תענה לכם על הרבה שאלות.

בתחילת הדרך ללימוד ZF בטח תיתקלו בכל מיני באגים מעצבנים שלא תבינו למה הם קורים, אני עברתי רבים מהם ואתם מוזמנים לשאול שאלות כאן למטה בתגובות.

עוד באותו נושא:

• קוד קצר להצגת תוכן תיקייה
• ב-2010 אנחנו עוברים ל-Offline

בחודשים האחרונים כמעט ולא היה לי זמן לכתוב שום פוסט וזאת מכוון ועבדתי על האתר של חברת בניית האתרים שלי – דקור. עכשיו לאחר שהאתר על הרגליים התפניתי לעשות מה שהרבה זמן רציתי כבר לעשות – לפרסם כאן פוסט. אז כמובן גם הפעם אני מצ'פר אתכם במתנה, והפעם גלריית פלאש מקורית (לא, לא כמו כל הגלריות שאפשר לבנות עם jQuery), שטוענת תמונות מתוך XML ומייצרת מסך מלא תמונות וכאשר לוחצים על תמונה היא נפתחת באמצעות lightbox. קרדיט גדול לאיתי גורן שאיתו בניתי את הגלריה. תהנו.

picWin - גלריית פלאש עם טעינה מתוך XML

אפשרויות:

1. הוספת תמונות מתוך XML –
ניתן להוסיף תמונות לתוך קובץ pics.xml. כל תמונה תקבל את המאפיינים הבאים:

dir - התיקייה בה תמצא התמונה לפלאש (התמונה הקטנה)
big_dir - התיקייה בה התמונה ל-lightbox (התמונה הגדולה)
name - שם קובץ התמונה (בשני התיקיות!)
desc - יופיע כתיאור התמונה בתוך ה-lightbox.

2. תוכלו לשנות את מספר הריבועים בפלאש באמצעות שינוי שורה מספר 6 בקובץ project.fla:

החליפו את הספרה 5 במס' השורות הרצוי ואת הספרה 8 במס' העמודות הרצוי.

עוד באותו נושא:

• גלריית פלאש מתנה
• טעינת תמונות באמצעות jQuery

הוספת כתוביות לסרטון וידאו זה בהחלט לא דבר חדש. בטכניקת הארדסאב (hard-sub) ניתן לצרוב את הכתוביות על גבי הסרטון ולעלות אותו לאינטרנט ובטכניקת סופטפאב (soft-sub) ניתן להציג סרטון עם כתוביות באמצעות שילוב של טכנולוגיית פלאש. מה שאני אלמד אתכם היום היא טכניקת סופטסאב להוספת כתוביות לסרטון המתנגן בתגית וידאו.

במדריך היום אנו נשתמש בסרטון וידאו בפורמט OGG או OGV (פורמט OGV הוא למעשה מקרה פרטי של OGG מכיוון ו-OGG יכול להתייחס גם לסאונד) ובכתוביות בפורמט SRT.

היתרונות של הטכניקה שנלמד היום היא שהיא משתמשת בפורמטים פתוחים (OGG ו-SRT), היישום שלה מאוד פשוט ודינאמי ובתוך קובץ הכתוביות אנחנו יכולים לשלב תגיות HTML שיופיעו מאוחר יותר כחלק מן הכתוביות.

קוד ה-HTML

בואו תחילה נביט בקוד ה-HTML:

וכעת ההסבר. בשורה 4 אנחנו למעשה מוסיפים כהרגלנו בקודש את ספריית ה-jQuery מתוך google. בשורה הבא אנחנו נוסיף את הסקריפט שיגרום לכל הכתוביות להופיע (מקורהסקריפט הוא מהבלוג mozbox).

לאחר מכן בין שורות 7-26 אנחנו מגדירים עיצוב CSS לוידאו ולשורת הכתוביות, אני לא ארחיב על נושא העיצוב.

ועכשיו הגענו לעיקר, שורות 32-33 בואו נביט בהם שוב:

הוספנו למעשה שני דברים:

תגית וידאו - התגית מכילה id בשם video, קישור לקובץ הוידאו (בפורמט OGV), לחצני פעולה (המאפיין controls לא צריך לקבל שום ערך) וקישור לקובץ הכתוביות שלנו (בפורמט SRT).

אלמנט div ריק - האלמנט מכיל id בשם subtitles והוא מוסתר.

אם פעלתם לפי כל ההוראות עד עכשיו צריך להיות גם לכם סרטון עם כתוביות. אתם מוזמנים להוריד את קבצי המקור ולהביט בקוד הJS שמפעיל את הכתוביות.

עוד באותו נושא:

• ב-2010 אנחנו עוברים ל-Offline
• מפת אתר צבעונית בעזרת jQuery

פוסט אורח של ברק דנין מ-Uniq UI, בעל הבלוג "פשוט. שימושי" – על אנשים, מחשבים והמסכים שביניהם.

בואו נודה על האמת: טפסים הם לא בדיוק הדבר הכי מסעיר בעולם. זה לא מעניין במיוחד לקודד אותם, וגם לא למלא אותם. אבל זה ברור מאוד לכל שניסה אי-פעם לשבור את הראש למה לא נרשמים אצלו מספיק לרשימת התפוצה, שטפסים הם חלק בלתי נפרד מהאתר. אבל זה גם הרבה יותר מזה: טפסים הם לא פעם הבסיס לקיום האתר, כי הם מאפשרים איסוף מידע ואינטראקציה עם המשתמש. בלעדיהם זה סתם אתר שמספק מידע. בפוסט האורח הזה אנסה לחלוק איתכם כמה מהדברים שהופכים טפסים למוצלחים מבחינת חוויית המשתמש.

טפסים, יבשים ככל שיהיו, עשויים להפוך ל-make or break של אתר, מה שיגרום לאתר להצליח או להכשל. בין אם זה טופס הרשמה לאתר שמרתיע חלק מהמשתמשים, טופס לתשלום בכרטיס אשראי שמבקש נתונים לא מוכרים (תארוז לי פעמיים CVV) או כל טופס אחר, הטופס הוא נקודת כשל פוטנציאלית בכל אתר, וחשוב לתת לטפסים שפע של תשומת לב כשבונים אותם.

מספר השדות בטופס

ככל שיש יותר שדות בטופס, הסיכוי שהמשתמש יגיע לסופו קטן יותר. טוב, זה די ברור כשחושבים על זה, אם רואים טופס עם שני שדות, או טופס עם 20 שדות, קל לנחש את איזה מהטפסים ימלאו יותר אנשים. כשמדובר בטופס לאיסוף לידים (פניות של לקוחות פוטנציאליים) באתר שיווקי, זה כבר הופך לעניין רציני. הבעיה היא שהרבה פעמים מי שבוחר שיזה שדות להציג בטופס לא מודע לבעייתיות שבשדות רבים. אם הוא היה יודע שצמצום השדות היה מביא לו 40% יותר פניות, מתוכן אחוז לא מבוטל הן פניות רלוונטיות, הוא בוודאי היה חושב על זה פעמיים.

קחו למשל את הטופס המקורי מאתר "יורם" (מצד ימין), שמטרתו לאסוף פרטים של מעוניינים בלימודים, ואת הגירסה המקוצרת שלו (מצד שמאל). מה הסיכוי שהייתם ממלאים את הטופס הארוך? ומה עם הטופס הקצר? התשובה, לדעתי, ברורה.

יישור תוויות

לכל שדה יש, בדרך-כלל, תווית. יש את אלה שכותבים את התווית בתוך הטופס וחוסכים מקום מצד אחד, אבל אז כשמנסים לקרוא מה כתוב בטופס בלי שמות השדות, זה עשוי להיות מבלבל ברגע שהשדות הם לא הרגילים, כמו שם או כתובת.

יש שלושה יישורים לתוויות: ימני, שמאלי ועליון.

יישור תוויות ימינה

יתרונות: קל לסרוק את עמודת השדות. בגלל שהשדות נמצאים אחד מתחת לשני, העין שלנו מסוגלת לאתר שדות ספציפיים בקלות. אם זה טופס לעדכון פרטים, היישור הזה אידיאלי.

חסרונות: מילוי טופס עם שדות ביישור ימני לוקח הרבה זמן. למעשה, לשים את השדות ביישור ימני גורם למילוי טופס האיטי ביותר. היישורים אחרים הם ב-50% יותר מהירים בממוצע! זה קורה בגלל שהעין צריכה לקפוץ בין התווית לשדה בזמן מילוי הטופס, וזה לוקח זמן. לפרטים על מקור הסטטיסטיקה הזאת אתם מוזמנים לסדרת הפוסטים שלי על תכנון ועיצוב טפסים.

מה זה משנה שאלתם? יש כמה סיבות. אחת היא שאנשים לא פעם מתייאשים באמצע מילוי טופס אם הוא לוקח להם הרבה זמן, או אם הוא לא ברור. השניה היא שבזמן מילוי הטופס יש למשתמש כל מיני הסחות: תינוק בוכה ברקע, מיילים נכנסים. ככל שייקח יותר זמן למלא את הטופס, יש יותר סיכוי שיפריעו למשתמש למלא אותו.

המלצה: להשתמש ביישור ימני רק בטפסים שמשמשים לעדכון פרטים, או במקומות שבהם אתם רוצים להאט את המשתמש בכוונה, למשל כדי שהוא ישים טוב לב לפרטים שהוא מכניס.

יישור תוויות שמאלה

יתרונות: מילוי הטופס מהיר ב-50% מטופס עם יישור תוויות לימין, כי הזנת השדות מתרחשת בצמוד לתווית שלהם.

חסרונות: תוויות השדות לא מסודרות בקו ישר בצד ימין, מה שמקשה על סריקה שלהן כדי לאתר תווית ספציפית.

המלצה: להשתמש ביישור שמאלי בטפסים להזנת פרטים, או בטפסים לעדכון עם מעט שדות.

יישור תוויות למעלה

יתרונות: מילוי הטופס מהיר ב-20% מטופס עם יישור תוויות לשמאל, כי מיקום התווית מעל התוכן מאפשר לעין לקלוט את התווית ואת תוכן השדה במבט אחד. בטפסים שמחולל Google Docs משתמשים ביישור הזה, ולא סתם. הוא הכי מהיר והכי קל למילוי.

חסרונות: הטופס הופך להיות ארוך מאוד ודורש גלילה לאחר מספר שדות לא רב.

המלצה: להשתמש בכל מקום שאתם רוצים את מילוי הטופס המהיר ביותר, אבל רק במידה והאירגון הזה של הטופס לא גורם לגלילה, או אם גלילה לא מפריעה לטופס שלכם.

המלצות נוספות

יש עוד הרבה דברים שאפשר ללמוד על טפסים, כמו למשל המסלול להשלמת הטופס, עזרה והודעות שגיאה, פעולות ראשיות ומשניות ועוד. אתם מוזמנים לקרוא על כל אלה ואחרת בסידרה איך מעצבים טפסים בבלוג שלי, "פשוט. שימושי".

עוד באותו נושא:

• שימוש בפקודת OnBeforeUnload לוידוא יציאה של המשתמשUsing OnBeforeUnload to confirm user's relocationing
• סיכום של יום השימושיות

יצירת ממשק נוח שמתחשב במשתמש, צריך לכוון את המשתמש לבצע את הפעולות הנכונות, אך בד בבד לנסות למנוע ממנו לעשות טעויות. משתמש יכול להיות מאוד מתוסכל כאשר התוכנה עשתה פעולה שהוא לא התכוון לה וכעת אין באפשרותו לעשות דבר.
היום אני אתן לכם קוד של אחת הטכניקות המוכרות לנו, היא השאלה שצצה כאשר משתמש מנסה לצאת מדף האינטרנט והדפדפן שואל "האם אתה בטוח?".

בימים אלה אני עובד על בניית מערכת ניהול תוכן בעזרת ה-framework של Zend. כחלק ממערכת ניהול תוכן, בניתי כמובן גם חלק באתר בו עורכים עמודי תוכן. הדף בנוי מתיבות טקסט שונות ועיקרו הוא תיבת הטקסט עם עורך הטקסט, שם נכתב התוכן העיקרי.
אתם בוודאי מכירים את הסיטואציה, הזנתם תכנים רבים בעמוד עריכה כלשהו באינטרנט, לחצתם על כפתור כלשהו שהעביר אתכם לעמוד אחר, וכל המידע שהקלדתם נעלם ולא יחזור.

אני החלטתי שבמערכת שלי אני רוצה לעזור למשתמש ולשאול אותו, האם הוא בטוח שהוא רוצה לצאת מהדף, חיפשתי קצת באינטרנט ומצאתי את פקודת ה-Javascript החביבה: OnBeforeUnload.

השם הארוך הזה, הוא למעשה Event, שמבצע קריאה לפונקציה כאשר המשתמש מנסה לצאת מהדף (לא משנה אם לחץ על כפתור Back, על לינק בדף או אפילו לחץ על סגירת הדפדפן), הפונקציה שמתלווה ל-Event יכולה להחזיר מחרוזות או ערך בוליאני (true או false).

הוסיפו את הקוד הבא לדף HTML, וכך הדפדפן יציג שאלה למשתמש לפני סגירת הדף:

שימו לב שהטקסט בעברית ("כל המידע שלא נשמר יאבד!"), הוא טקסט שיתווסף להודעה הקבועה של הדפדפן במבנה הבא:

עזרו למשתמש שלכם למנוע טעות

בבדיקתי אם הדפדפנים השונים, chrome ו-Safari לא תמכו בהודעות בעברית.
שימו לב שאופרה מאז ומתמיד לא תמכה ב-OnBeforeUnload, כך שהקוד הנ"ל לא יעבוד בדפדפן אופרה כלל.

אני הוספתי את הקוד הזה לדפים שבהם עורכים טקסט רב ובמידה והעבודה לא נשמרה.

אשמח לשמוע, איפה אתם מצאתם שימוש לקוד הזה?

עוד באותו נושא:

• טפסים? למי זה חשוב? —פיהוק—
• סיכום של יום השימושיות

בתור בוני אתרים אנחנו נתקלנו לא פעם אחת בצורך ליצירת מפת אתר, אם זו מפת אתר XML או מפת אתר מעוצבת. הסיבות לבניית מפות אתר הם מגוונות, סיפוק מנועי החיפוש ועזרה לגולש בניווט באתר. למרות שהצורך המקורי ליצירת מפות אתר היה דווקא השני (עזרה למנווט באתר), היום כמעט ולא נראה גולשים מנווטים דרך מפת האתר. אם את שואלים מה הסיבה לכך, לדעתי, מפות אתר פשוט לא ידיותיות למשתמש. בסרטון ההדכה שאני אתן לכם היום אני מסביר איך להוסיף קוד jQuery דינמאי ופשוט, על-מנת ליצור מפת אתר ידודתית יותר ומסודרת יותר. את המדריך הזה לקחתי מכריס קויר מאתר css-tricks, שפרסם מאמר על הטכניקה הזו באתר Smashing Magazine.

ברשותכם חילקתי את הסרטון לשני חלקים, כל חלק כ-5 דקות:

להלן התכנים שהוסברו בסרטון:

HTML

JavaScipt – sitemap.js

עוד באותו נושא:

• הוספת כתוביות לתגית וידאוAdding subtitles to a video tag
• הפיכת טופס לתהליך הרשמה

לאחר המאמר הקודם, בו סקרתי את תגיות ה-HTML 5 החדשות, במאמר זה אני אפרט על התגיות שהכרנו אבל יוצאות משימוש בתקן HTML 5. בסיום הסקירה אני נשארתי עם תהייה, האם באמת נוצרה הפרדה בין העיצוב לתוכן ב-HTML 5, או שרק התקדמנו פסיעה קטנה לכיוון הזה.

התגיות שיעזבו אותנו

כחלק מהראיה הכללית של הפרדת תוכן מעיצוב בה דוגלת HTML 5, רוב התגיות שהולכות לצאת משימוש ב-HTML 5, הן תגיות שאחראיות על עיצוב. במקומן יבוא ה-CSS ויצור את אותו אפקט אליו היינו רגילים בעבר, רק עם הגיון נכון יותר של הפרדה בין עיצוב לתוכן. כמובן שאנחנו נפרדים גם מתגיות נוספות בשאיפה ליצור אתרים טובים יותר ונגישים יותר בתקן החדש.

התגיות מהן אנו נפרדים בתקן החדש

ואלו התגיות שעתידות לצאת משימוש ב-HTML 5:

<acronym>

תגית זו אחראית להגדיר את משמעות רשי תיבות. תגית זו תוחלף בתגית המוכרת לנו, <abbr>, שמתפקדת בצורה דומה ותפקידה לתת הגדרה לכל דבר.

<applet>

התגית שימשה להצגת אפלקציות חיצוניות (כגון Java). ב-HTML 5 אנו נשתמש בתגית ה-object במקומה.

<isindex>

תגית שלא נתקלתי בה בחיי אבל משום מה קיימת ב-HTML 4. תגית זו תיפקדה בדרך מיושנת להצגת טופס של שורה אחת, בכל מקרה כל מה שהיא יכלה לעשות תגית form עושה, תשמשו בה.

<xmp>

תגית זו שיצאה משימוש כולל, גרמה לכל התוכן שבתוכה להיות מוצג כאילו היה טקסט (גם אם הכיל תגיות HTML בתוכו). הצגה של סימן >, כטקסט נוגדת את כללי ה-SGML ולכן במקום להשתמש בתגית xmp, השתמשו בתגית PRE עם התווים המיוחדים ;gt& ו- ;lt& לסימון תחילת תגיות HTML.

<frame> <frameset> <noframes>

תגיות ה-frame יוצאות משימוש ב-HTML 5. הסיבה להוצאתן מהתקן היא מכיוון ופריימים מקלקלים את הנגישות של דפי האינטרנט. התגית שנתמכת ב-HTML 5 היא iframe והפרמטר היחידי שמותר להזין אליה היא src (קישור לדף חיצוני), כל שאר העיצוב יעשה ב-CSS.

<big> <center> <dir> <font> <basefont> <s> <strike> <tt> <u>

כל התגיות הללו הן תגיות המשמשות לעיצוב ואין להן שום משמעות סמנטית. התגיות הללו לא יתמכו בתקן של HTML 5, ובמקומן נצטרך להשתמש ב-CSS.

אני תוהה מדוע לא הוציאו את כל תגיות שאחראיות אך ורק על עיצוב מ-HTML 5? התגיות: b, i, sub, sup, small, hr – כולן מיותרות ב- HTML 5 שמתיימר להפריד בין עיצוב לתוכן. בתקן החדש (לפי W3C) כל התגיות הללו הוגדרו מחדש, אך עדיין לא ברור מה הצורך בהן בתור תגיות HTML.

מה אתם חושבים על כך? האם גם אתם חושבים שהתגיות שתפקידן הוא רק תצוגתי צריכות לצאת מ-HTML 5?

עוד באותו נושא:

• HTML 5 – מה נכנס ומה יוצא? – חלק א'
• ב-2010 אנחנו עוברים ל-Offline

תקן HTML 5 עדיין לא אושר על-ידי משרד W3C העולמי, אך כבר עכשיו אפשר לקבל טעימות קטנות מתקן האינטרנט העתידי. במאמר זה אני אספר לכם על התגיות שיכנסו לחיינו בתקן הבא, בהחלט יש למה לחכות.

התגיות שנוספות ב-HTML 5

נוספו כ-26 תגיות חדשות ל-HTML 5. חלקן מאוד אינטאוטיביות ושמענו על בואן (video, audio) וחלקן הזויות מאוד, אני אסביר כאן את שימושן של כולן. חילקתי את נושא התיגיות החדשות לכמה חלקים: האחד – תגיות המחלקות את הדף למקטעים, השני - תגיות המשמשות לאפיון של טקסט, השלישי- תגיות להצגת מולטימדיה והאחרון - תגיות נוספות.

1. חלוקת הדף למקטעים:

כל התגיות בקבוצה זו, אינן מבצעות אף לא דבר אחד בתחום העיצוב, אלא נותנות אך ורק משמעות סמנטית לחלקי המסמך (האתר).

<header>

תחילת העמוד – תגית זו תוחמת בתוכה את החלק העליון במסמך האתר, החלק שתואם לכל שאר הדפים. תגית זו יוצרת למעשה הפרדה של החלק העליון שברוב הפעמים הוא לא החלק המרכזי של הדף.

<footer>

כמו התגית הקודמת, אך הפעם התיחום הוא של החלק התחתון.

<aside>

תגית התוחמת בתוכה את החלק באתר שנמצא בצד (אם יש כזה).

<nav>

תגית זו תוחמת בתוכה את החלק במסמך אשר דרכו ניתן לנווט באתר. לרוב, התפריט של האתר.

<section>

תגית זו מחלקת את המסמך לחלקים, תגית זו היא כללית ונשתמש בה כאשר לא נמצא תגית מתאימה יותר. אני חושב שהיא תתן לנו חלופה לא רעה לשימוש המוגזם בתגית div.

<article>

תגית התוחמת בתוכה קטעי מאמר. באתרי מאמרים ובלוגים החלק המרכזי יתחם בתגית זו.

HTML 5 - חלוקה הגיונית

2. תגיות טקסט:

תגיות אלו יתנו משמעות סמנטית לטקסט הנתחם בתוכם. התגיות יעזרו למנועי החיפוש להבין טוב יותר את תוכן האתר וכן יחזקו את פן השימושיות של האתר.

<time>

כשמה כן היא, תגית התוחמת בתוכה זמן או תאריך.

<details>

תגית המכילה פרטים נוספים על אלמנט כלשהו. לתגית יש מאפיין open, שמקבל true או false, ולפיו מוצגים או לא מוצגים הפרטים שתחומים בתגית זו. ניתן לצרף לתגית זו כותרת באמצעות התגית legend. כותרת זו תשמש גם כפתור להצגה והסתרה של טקסט.

<mark>

בדומה לתגיות em ו-strong שתפקידן להדגיש, תגית זו תוחמת בתוכה טקסט מסומן.

<progress>

תפקיד תגית זו הוא להציג התקדמות של תהליך. לרוב תתחום בתוכה אחוזים להתקדמות של הורדה או טעינה.

<meter>

התגית הזאת מייצגת כמות. הכמות תיהיה יחסית למינימום מוגדר ומקסימום מוגדר. לדוגמא:

1	<meter max="10" min="0">2 from 10</meter>

<output>

בדומה לתגיות, code ו-samp, תגית output תפקידה לייצג סוג של פלט, כמו כזה של קוד תכנות.

<dialog>

תגית שתוחמת בתוכה שיחה. אם יש טקסט שמייצג שיחה בין אנשים רצוי לתחום אותו בתגית הזאת.

תגיות טקסט ב-HTML 5

3. תגיות מולטימדיה וטכנולוגיות חדשות:

כעת אעבור להציג את התגיות המעניינות ביותר (לטעמי), הן בהחלט מחוללות שינוי גדול מהמצב הקיים כיום.
* הדוגמאות שאתן כאן מחייבות אתכם לגלוש בדפדפנים שתומכים ב-HTML 5, כגון firefox 3.5.

<video>

כשמה כן היא תגית המציגה וידאו. בHTML 5 לא נהיה חייבים להיות תלויים בטכנולוגיות קוד סגור כמו פלאש להצגת וידאו, ונוכל פשוט להציג וידאו דרך הדפדפן בעזרת קוד html פשוט. לדוגמא:

1 2 3

<video src="שם קובץ.ogg" controls width="320" height="240">         <a href="שם קובץ.ogg">אין לכם תמיכה ב-HTML 5 הורידו את הסרט</a> </video>

והדוגמא בפועל:

<audio>

תגית שמע, פועלת כמו תגית וידאו למשמשת לניגון קבצי סאונד. נעבור לדוגמא:

<figure>

תגית זו משמשת על מנת לקבץ בתוכה תגיות מולטימדיה, כמו video ו- audio. ניתן להוסיף את תגית legend על מנת להציג כותרת לקבוצה זו.

<source>

תגית שמכילה URL לקובץ סאונד או וידאו. לרוב תופיע בתוך תגיות וידאו ואודיו.

<embed>

אנחנו מכירים כבר את התגית הזאת, מהקוד של הצגת פלאש, אבל רק ב-HTML 5 היא תיכנס באופן רשמי. תפקידה להציג תוכן מוטבע (חיצוני). לדוגמא:

<canvas>

אם עדיין לא שמעתם על canvas הגיע הזמן לשמוע. קאנבס זוהי טכנולוגיה ליצירת גרפיקה בעזרת קוד html. אני לא ארחיב על כך יותר במאמר זה אבל אני בוודאי אכתוב בעתיד כאן ב-htm מאמר על טכנולוגיה זו. צפו בדוגמא:

דפדפן זה לא תומך בקאנבס!


בדוגמא זו ציירתי ריבוע אדום בקאנבס, אבל אפשר לעשות הרבה יותר מזה, צפו בלינק הבא – ציור תמונות בקאנבס.

4. תגיות נוספות:

לאחר חלוקה יפה לשלוש קטגוריות של תגיות, אסביר עכשיו על שאר התגיות שיתוספו לנו ב-HTML 5:

<datalist>

בדומה למדריך שנתתי לכם לפני כמה ימים, שמסביר איך להוסיף תיבת הצעות לתיבת טקסט, תגית זאת למעשה מאפשרת להוסיף, דרך קוד ה-HTML, אפשרויות לבחירה לתיבת טקסט. קוד לדוגמא:

1 2 3 4 5 6 7

<input id="myCar" list="cars" />             <datalist id="cars">             <option value="BMW">             <option value="Ford">             <option value="Volvo">             <option value="Porche">             </datalist>

וכעת לדוגמא בפועל (לי זה עבד רק באופרה, בגרסה החדשה ביותר):

<command>

עד שהומצאה התגית הזאת היינו משתמשים בתגית input על מנת ליצור כפתורים שמבצעים פעולות. בעזרת התגית החדשה נוכל ליצור כפתורים שיבצעו פעולות. ניתן לבחור את סוג כפתור הפעולה (מאפיין type) מתוך שלוש אפשרויות: command (ברירת המחדל, מתנהג כמו input type="button"), checkbox, radio.

<event-source>

בתגית זו פונים ל-URL (דרך מאפיין ה-src) של מסמך מסוג, text/event-stream. תגית זו יוצרת חיבור למסמך זה ומאפשרת לטעון אירועים מהמסמך. עוד לא נתקלתי בדוגמא לשימוש בתגית זו ברשת אך אני בטוח שנגלה דוגמאות רבות בעתיד.

<input>

אתם אולי חושבים שהתבלבלתי, נכון, תגית ה-input אומנם לא חדשה והיא קיימת כבר הרבה זמן, אך ב-HTML 5 נוצרו סוגי Input חדשים ומאוד שימושיים. בעוד שעד היום, כשרצינו לתת ממשק נוח למילוי טפסים השתמשנו בשפות צד לקוח (כמו JS), ב-HTML 5 הטיפול בצד הלקוח עובר לדפדפן. לשם הדוגמא, כאשר ארצה ליצור תיבת טקסט שמקבלת לתוכה תאריך, הפתרון הנוח ב-HTML 5 עושה לי את החיים קלים.
הקוד:

1	<input type="datetime" />

והתוצאה (על מנת לראות את התוצאה גלשו בגרסא האחרונה של אופרה):

חוץ מ-datetime ישנם אפשרויות רבות חדשות. והן:

datetime-local,date,time,month,week,number,range,email,url,search,tel,color.
אתם מוזמנים לבדוק את התוצאה שלהן באופרה.

זה הכל! במאמר זה נתתי לכם סקירה מלאה של התגיות החדשות שנזכה להכיר ב-HTML 5. אנחנו עדיין לא שם, והדפדפנים עדיין לא תומכים בתקן (שימו לב שהתקן עדיין לא נכתב במלואו ואושר ע"י W3C), אך בהחלט מעניין לגלות מה תומן לנו העתיד.

במאמר הבא אני אספר לכם בקצרה על התגיות שניפרד מהן בתקן HTML 5, עד אז אשמח אם תספרו לי כאן בתגובות, מה אתם חושבים על התגיות החדשות וכן אשמח מאוד אם תוכלו לחדש לכולנו לגביי דברים שלא הזכרתי.

עוד באותו נושא:

• פורסמו ההקלטות והמצגות ממפגש ההעשרה של ISOC
• HTML 5 – מה נכנס ומה יוצא? – חלק ב'