هبوب نسيم الربيع "لإعادة الإعمار" في جميع أنحاء البلاد، وأصبح الإنترنت في حالة من الاضطراب لفترة من الوقت، وقد أصبح "div+CSS" "موضة" وبدأ عدد لا يحصى من مواقع الويب "إعادة الإعمار" الخاصة بهم دائمًا. ومع ذلك، فإن فتح الكود المصدري لهذه المواقع المختلفة غالبًا ما يجعل الناس يضحكون——
نرى تخطيطات div تحتوي على 6 أو 7 طبقات من التداخل، وجداول بدون جداول، وصفحات مكونة من div+a خالص، ومئات من فئات طبقات العرض... هناك المزيد والمزيد من الكتب حول المعايير في الوقت الحاضر باستثناء عدد قليل من الكتب التي يتم الإعلان عنها "التقنيات المتقدمة"، قليل من الناس لن يؤكدوا على مثل هذه الجملة في الفصول القليلة الأولى من كتبهم - "فصل البنية والتعبير". ومع ذلك، كم عدد قراء هذه الكتب الذين قرأوا الفصول القليلة الأولى بجدية؟ أو هل تفضل تخطي تفسيرات البنية المملة والتعمق في تقنيات التخطيط والاختراقات التي تبدو متقدمة؟
في الواقع، لقد ضلل مصطلح div+CSS الكثير من الناس منذ البداية، والعقلية المتعطشة للنجاح السريع هي السبب وراء هذه الظاهرة. لا ينبغي أن تكون الخطوة الأولى لأي شخص معتاد على إنتاج صفحات الويب لتخطيط الجدول للتواصل مع المعايير هي البحث بشكل أعمى عن تقنيات CSS لتنفيذ تخطيطات مختلفة، ولكن يجب أن يسعى جاهداً لتغيير طريقة تفكيره.
سأتحدث أدناه عن طريقة التفكير في الامتثال للمعايير بناءً على تجربتي الشخصية، والعديد منها عبارة عن طرق التفافية قمت بها، وآمل أن يكون ذلك مفيدًا لـ XDJMs الذين تعاملوا للتو مع المعايير.
1. "حفظ الكود" هو أداة تسويقية، وليس غرضًا
"استخدام تخطيط div يمكن أن يوفر تعليمات برمجية أكثر من تخطيط الجدول"، لقد رأيت هذه الجملة في العديد من الكتب ومواقع الويب. هذه الجملة نفسها صحيحة. يعد "حفظ الكود" أحد فوائد توحيد صفحات الويب. ومع ذلك، تذكر أنها "واحدة من الفوائد" فقط، وليست "الفائدة الوحيدة"، وليست هي الهدف. غالبًا ما يكون "حفظ الكود" بمثابة حيلة تسويقية نستخدمها لإقناع الرؤساء العنيدين. الغرض الوحيد من توحيد صفحات الويب هو "فصل البنية والأداء"، ولا يتعلق الأمر أبدًا بحفظ الكود من أجل حفظ الكود. لقد استخدمت فصلًا موحدًا ذات مرة لأن الشريط الجانبي وحتى المحتوى الرئيسي للموقع لهما نفس نموذج العرض التقديمي (لا تزال هناك بعض الكتب التي تعلم هذا الأمر)، وهذا في الواقع يوفر الكود أكثر من تسمية المعرفات بشكل منفصل هذا هو أن الكود يفقد بنيته الجيدة. عواقب فقدان البنية الجيدة هي: 1. لم يعد كود المصدر قابلاً للقراءة. 2. يزيد موقع الويب من تكاليف الصيانة غير المعروفة. فقط تخيل أنه عندما يغير جزء معين من المحتوى عرضه التقديمي بسبب الاحتياجات، مثل لون الرابط وما إلى ذلك، يتعين علينا تعديل الملف المصدر للصفحة وإضافة فئات إضافية، ويكون عبء العمل أكبر بكثير من مجرد تعديل المعرف التجمع. وإذا استمرت الأمور على هذا النحو، فإن البنية ستزداد سوءا، لتشكل حلقة مفرغة يصعب عكسها.
هناك موقف آخر يحدث في تسمية المعرفات، وهو خطأ ارتكبته أيضًا. في ذلك الوقت، من أجل "حفظ الكود"، تم تسمية القائمة الرئيسية بـ "mm"، وتم تسمية القائمة الثانوية بـ "m2"، وتم تسمية قائمة المستوى الثالث بـ "m3". تم تقليص حجم صفحة الويب بشكل كبير، مما جعل من الصعب على الزملاء الآخرين تولي المسؤولية، محاولًا توفير المتاعب ولكن أتعب نفسي. وبنفس الطريقة، لا يُنصح بالمبالغة في تبسيط تسمية الملفات والمجلدات. على سبيل المثال، يوصي موقع "Website Reconstruction" بتخزين جميع الصور في الدليل "i". شخصيًا، أعتقد أنه ليس من المستحسن إلا إذا كنت تستطيع الكتابة عن ذلك هيكل دليل مختصر للغاية. اشرحه بالتفصيل وتأكد من أن جميع المشاركين، بما في ذلك موظفو الإنتاج الآخرون والمطورون وحتى الرؤساء ذوو المعرفة... يمكنهم فهمه وتنفيذه، وإلا فلن يؤدي إلا إلى إضافة مشاكل غير ضرورية لنفسك.
2. المعرف هو بندقية قنص، والفئة سيف ذو حدين
إذا كنت ترغب في الحصول على بنية جيدة لصفحة الويب، فيجب إتقان كل من المعرف والفئة بكفاءة. المعرف يشبه بندقية القنص، والتي يمكن أن تساعدنا في تحديد العناصر التي نريد تحميل الأنماط بدقة؛ والفئة هي سيف الفارس، وهو أخف وأكثر مرونة في متناول يدك والأداء الغني. ومع ذلك، هناك وجهة نظر خاطئة الآن مفادها أنه يمكن استبدال المعرف بالكامل بالفئة. في الواقع، هذا صحيح بالنسبة للعديد من أكواد مصدر صفحات الويب، عندما تفتح الفصل بأكمله، لا يمكنك العثور على معرف. هناك العديد من الأسباب لهذه الظاهرة، ولكن المفهوم العميق الجذور لـ "class=CSS" الذي انتقل من عصر الجدول هو السبب الجذري. صحيح أن الفصل أكثر تنوعًا ومرونة من المعرف، ولكن يجب أيضًا إدراك أن الفصل أقل فعالية بكثير من المعرف في بناء بنية جيدة لصفحة الويب. إن التفرد الإلزامي للمعرف يجعل من السهل علينا استرداد أي وحدة نحتاجها من خلال المعرف، في حين أن الفصل لا يتمتع بهذه الميزة. على الرغم من أنه يمكننا تحديد اسم فئة فريد للوحدة، إلا أن الفرضية هي أن المنتج نفسه هو الوحيد الذي يمكنه تغيير نمط صفحة الويب. بخلاف ذلك، دعنا نجد شخصًا كسولًا بعض الشيء، نظرًا لأن الأنماط متماثلة، فسوف يطبق الفصل السابق مباشرةً، والنتيجة هي أننا نجد أن هناك أكثر من اثنتي عشرة وحدة في صفحة الويب تسمى "gonggao" أو "xinwen". "، بحيث يصعب التمييز بينها. وبدون إضافة الكثير من تعليقات html، فمن الواضح أن هذه النتيجة ليست ما نريده. علاوة على ذلك، كما ذكرنا سابقًا، يجب تبديد التعليمات البرمجية المحفوظة من خلال الفئات العامة في كل فئة محددة على حدة.
الهوية هي بندقية قنص، والطبقة سيف ذو حدين. معًا، كلانا يستفيد، وبصرف النظر عن ذلك، كلانا يخسر.
3. لا يتطلب كل المحتوى div باعتباره "حاوية"
هل يجب أن أستخدم <div id="mainnav"><ul> أو <ul id="mainnav"> للقائمة الرئيسية؟ هذه مشكلة في اللعبة. حتى الآن، لا أحد يستطيع أن يعطي إجابة واضحة على هذا السؤال، ولا حتى أنا. صحيح أنه عندما يحتوي <div id="mainnav"> على عنصر <ul> واحد فقط، يبدو هذا div زائدًا بعض الشيء، ولكن في بعض الأحيان من أجل مطابقة التصميم الرائع، تعني طبقة إضافية من العلامات طبقة أخرى (تغييرات). يستخدم بعض الأشخاص أيضًا النطاق في العلامة). الميزة المتأصلة في div بدون أي سمات أصلية لا مثيل لها من قبل العلامات الأخرى. أريد فقط أن أوضح شيئًا واحدًا بهذا الاقتراح، وهو أننا يجب أن ندرك أنه بالإضافة إلى <div id="mainnav"><ul>، هناك أيضًا <ul id="mainnav"> طريقة الكتابة هذه، والتي يتمتع أيضًا ببنية ودلالات جيدة ويزيل طبقة التداخل. عندما لا داعي للقلق بشأن الفن الرائع، هل يمكننا أيضًا أن نجعل الهيكل أكثر بساطة؟
يمكن في الواقع توسيع هذا الاقتراح إلى - "ليس كل المحتوى يحتاج إلى عناصر كتلة كحاويات" و"ليست كل الروابط تحتاج إلى عناصر أخرى كحاويات"، مثل "المزيد" الذي تحتويه العديد من الصفحات. يكتب بعض الأشخاص "<div class="more"><a>"، بينما يكتب آخرون <p><a> أو <strong><a>. هل لا تزال هناك حاجة إلى وجودها عندما تحتوي هذه "الحاويات" على علامة <a> فقط؟ هل الكتابة مباشرة<a class="more">تكسر البنية؟ هل ستفتقر إلى الدلالات؟ هل سيؤثر على التخطيط؟ إذا فكرت بشكل مختلف، فقد تكسب شيئًا مختلفًا.
4. تحقيق "الفصل بين الهيكل والأداء" في العمل
فيما يتعلق بهذه النقطة، يقترح العديد من الخبراء على الإنترنت ذلك، أي افتح المحرر أولاً، واكتب الهيكل بالكامل، ثم انتقل إلى CSS لكتابة الأداء، وحاول عدم لمس الهيكل المكتوب بالفعل.
ومع ذلك، فمن الصعب على الأشخاص الذين يستخدمون قراءة الكتب كوسيلة تعليمية رئيسية أن يفهموا ذلك، لأن معظم الكتب المتعلقة بالمعايير تدرس خطوة بخطوة، مما يعني أنه يجب عليهم الجمع بين البنية والتعبير بطريقة خطوة بخطوة. وعلى الرغم من أن بعض الكتب لديها اقتراحات في هذا الصدد، إلا أن بعض الجمل القصيرة تكون أقل بكثير من التأثيرات الدقيقة أثناء عملية القراءة. عندما يكون لدى موظفي الإنتاج فهم جيد للهيكل، فإن هيكل الكتابة والأداء في نفس الوقت لن يكون له تأثير كبير على النتائج. ولكن من خلال تجربتي، فإن طريقة العمل للفصل بين الهيكل والعرض هي أكثر كفاءة من كتابة الهيكل والعرض في نفس الوقت، وفي الوقت نفسه، ليس من السهل تفويت العناصر الموجودة على الصفحة.
بالطبع، ما يسمى بـ "الفصل بين البنية والأداء" لا يعني تجاهل الأداء تمامًا. إذا كنت تريد أن تأخذ الأداء في الاعتبار، فيجب عليك التأكد من أن محدد CSS يمكنه تحديد أكبر قدر ممكن من المحتوى دون تدمير البنية. . إن مكان إضافة الفئات أو التصنيفات التي يجب استخدامها لتمييزها هي مسألة رأي. من خلال الجمع بين مسودات التصميم المختلفة، يكون من الضروري أحيانًا إجراء تغييرات مقابلة، ومع ذلك، يجب أن يكون لهذه التغييرات نفس الفرضية - وليس تدمير بنية الكود وسهولة قراءته.
علاوة على ذلك، يجب أن ندرك أن أي أداة بصرية هي شيطان. غالبًا ما تكون التأثيرات المقدمة في واجهاتها المرئية بعيدة بآلاف الأميال عن تلك الموجودة في المتصفحات الحقيقية. ما نريده حقًا أن نكون متوافقين معه هو المتصفح، وليس الواجهة المرئية للمحرر.
5. CSS ليس علاجًا سحريًا، وليس من المستحيل العيش بدون CSS.
بالمقارنة مع عصر CSS1.0، يمكن لـ CSS إنجاز المزيد من الأشياء اليوم، ومع ذلك، فإن الطلب يتقدم دائمًا على التكنولوجيا. لا يمكن لـ CSS إكمال جميع أعمال طبقة العرض لصفحات الويب. في بعض الأحيان يتعين علينا الجمع بين JS أو لغات أخرى لتحقيق بعض التأثيرات . وفي أحيان أخرى، يكون استخدام JS أبسط بكثير من الاعتماد على CSS وحده، وتكون التعليمات البرمجية أكثر تنظيماً - والمثال الأكثر شيوعًا هو القائمة المنسدلة. في هذه الأوقات، علينا أن نقنع أنفسنا، أو رؤسائنا وعملائنا، باستخدام أساليب أبسط وأكثر منطقية. نظرًا لأن DOM يعد أيضًا مكونًا مهمًا لمعايير صفحات الويب، فهذا لا يعني أن استخدام JS سيجعل صفحات الويب الخاصة بنا أقل كفاءة أو لم تعد قياسية. على العكس من ذلك، يعد هذا أكبر سوء فهم لـ JS. بعد قولي هذا، يجب أن أذكر أنه في عصرنا هذا، يتعين على كل مهنة معرفة المزيد من المعرفة ذات الصلة أكثر من أي وقت مضى، ويجب على أولئك الذين يقومون بالتصميم أن يعرفوا القليل عن التفاعل والإنتاج، ويجب على أولئك الذين يقومون بالإنتاج أن يفهموا أيضًا التصميم والبرمجة ، خاصة مع التقنيات الأمامية مثل JS، بهذه الطريقة فقط يمكنك أنت وزملائك العمل معًا بشكل أفضل، وستكون آفاق التطوير الشخصي لديك أكثر إشراقًا.
يشير مصطلح "لا يوجد CSS" إلى فشل موقعنا في تحميل ملف CSS لأسباب مختلفة غير معروفة. لا داعي للذعر بسبب هذا، فهذا هو أفضل وقت لاختبار جودة الكود الخاص بنا. إذا كانت صفحة الويب لا تزال تحافظ على سهولة القراءة بدون CSS، فإن هذا الإنجاز يستحق فخرنا أكثر بكثير من اجتياز التحقق من W3C.