ראשי > dhtml חוצה דפדפנים > dom לכל עת
DOM
לכל עת
הנאשם
בחלק זה הוא ה-DOM,
הלא הוא מודל מסמך העצמים. שפת DHTML
היא מנגנון מונחה עצמים, וככזו, ה-DOM
הוא האנטומיה שלה. כפי ששמו מרמז, ה-DOM מגדיר את
העצמים שהם אבני הבניין שמהם מורכב עמוד
אינטרנט, ותכונות אופי שונות של כל אחד מעצמים
אלה. פעולה אינטראקטיבית עם אבני בניין אלה,
כמו שינוי תכונות עצם או יצירת מאורע כתוצאה
מפעולה של העצם, מוגדרת אפוא
על ידי ה-DOM.
אם לא ידעת, נטסקייפ ומיקרוסופט אמצו DOM-ים
שונים לפעולה עם הדפדפנים שלהן.
בעצם,
שני ה-DOM-ים
חולקים ביניהם תכונות רבות דומות, ואפילו
הרבה עצמים תואמים. שניהם, אחרי הכל, מנסים
להשיג את אותה המטרה—תפעול רכיבי עמוד
האינטרנט. גם בין עצמים דומים, יש לפעמים
שינויים דקים שמתבטאים בהתנהגות שתלויה בסוג
הדפדפן עמו עובדים. מה שיותר בעייתי אלו
העצמים שקיימים רק ב-DOM
אחד ולא בשני; לפעמים יש עצם דומה מאוד ב-DOM
השני: לדוגמה נביט בעצם layer
של נטסקייפ, שרוב תכונותיו זהות לתכונות העצם style של
מיקרוסופט. במקרים אחרים, ל-DOM
אחד יש עצם שלא קיים לו עצם זהה אצל המתחרה:
העצם iframe
של מיקרוסופט מייצג מסגרת צפה בתוך השורה, מה
שלא נתמך ע"י נטסקייפ.
התוצאה
של כל כאב הלב הזה היא, שאתה, מפתח ה-web,
נתקל בשלושה מכשולים אפשריים, הרשומים לפי
סדר עולה של חרדה שהם גורמים:
1.
אפליקציות שיכולות להיות ממומשות בשני
הדפדפנים, אבל דורשות תחביר שונה עבור כל
דפדפן.
2.
אפליקציות שיכולות להיות ממומשות בשני
הדפדפנים, אבל דורשות גישה שונה עבור כל דפדפן.
3. אפליקציות שיכולות להיות ממומשות בדפדפן אחד
בלבד, וניתן ליצור אלטרנטיבה עבור הדפדפן
השני.
מלבד
רעיונות מתוחכמים מאוד, שמאמר זה לא יכול ללמד,
נראה שיטות להתמודדות עם כל אחד מהתסריטים הנ"ל.
למרות שמובטח DOM חדש וסטנדרטי מ-W3C, עם תרומה ממיקרוסופט ומנטסקייפ, לא סביר שכל 3 המכשולים שצוינו יפתרו לגמרי. מפתחי תוכנה מעונינים בשמירת ההפרדה, ולכן מגבילים את התאימות בין הדפדפנים. הדילמה של מפתחי תוכנה אינה משתנה עם הזמן, אלו רק הפרטים שמשתנים.