क्या मुझे नीचे से पाद को मारना चाहिए?

हाल ही में, काम पर एक विवाद छिड़ गया। बहुत गंभीर है। हम वर्तमान में एक बहुत बड़ी सामाजिक परियोजना में लगे हुए हैं, जिस पर दो डिजाइनर काम कर रहे हैं, जिनमें से एक मैं हूं। लेकिन सवाल पूरी तरह से डिजाइन में नहीं था, बल्कि HTML लेआउट के बारे में था। उन्होंने इस बारे में तर्क दिया कि क्या जानकारी की मात्रा की परवाह किए बिना, पृष्ठ के निचले भाग के पाद को नाखून देना आवश्यक है या संभव है या इसे तैरने दें? पाद लेख अधिकांश पृष्ठों पर तैरता है, और यदि पृष्ठ पर बहुत कम जानकारी है, तो यह बढ़ जाता है।



निजी तौर पर, मैं इस तरह के फैसले के खिलाफ हूं। ज्यादातर मामलों में, पाद लेख में माध्यमिक जानकारी होती है, जो, सिद्धांत रूप में, बहुत ध्यान आकर्षित नहीं करना चाहिए। और बड़े मॉनीटर पर, पृष्ठ पर थोड़ी सी जानकारी के साथ, फूटर बंद हो जाता है, लगभग स्क्रीन के केंद्र में स्थित है। इस प्रकार, महत्वहीन जानकारी एक अतिरिक्त जोर प्राप्त करती है और इस खंड में मूल जानकारी के साथ मिश्रण करते हुए थोड़ा गड़बड़ करती है। और यह विशेष रूप से घृणित लगता है अगर पाद की कुछ पृष्ठभूमि है, जो पृष्ठ की सामान्य पृष्ठभूमि से अलग है। वास्तव में, पाद लेख पृष्ठ पर लगभग मुख्य ब्लॉक बन जाता है, क्योंकि यह आधी स्क्रीन पर कब्जा कर लेता है, और पृष्ठभूमि से स्पष्ट रूप से बाकी हिस्सों से अलग हो जाता है।



मेरा मानना ​​है कि ज्यादातर मामलों में, पाद को ऊंचाई में एक निश्चित आकार दिया जाना चाहिए और इसे ब्राउज़र विंडो के बहुत नीचे तक कील करना चाहिए। हालांकि यह कड़ाई से डिजाइन पर निर्भर है।



मेरे सहयोगी का पुरजोर विरोध किया जाता है। उनका मानना ​​है कि परिस्थितियों की परवाह किए बिना पाद को तैरना चाहिए। उसी समय, वह इस तथ्य को संदर्भित करता है कि: हर कोई ऐसा करता है; तो लेबेडेव करता है; यह W3C मानकों द्वारा है।



तो सवाल यह है कि क्या इस मामले में मानक तत्व के तर्क के विपरीत हैं? आखिरकार, मानकों को डिजाइनर को लाभ पहुंचाना चाहिए, न कि उसके खिलाफ। यही है, मानकों का पालन करते हुए, मुझे केवल ऐसे पाद बनाने चाहिए जो पर्याप्त दिखेंगे, बशर्ते कि वे तैरना शुरू करें और आकार में वृद्धि करें। और अगर मैं एक विपरीत पाद की कल्पना करता हूं, तो इसके विपरीत (इन मामलों में: www.free-lance.ru/users/raga/viewproj.php?prjid=161441 , www.free-lance.ru- users / raga / viewproj.php) उदाहरण के लिए, संरचना को हल करने के लिए prjid = 67262 )?



वास्तव में, यह पता चला है कि इस मामले में, लेआउट मानक डिजाइनर के लिए पूरी तरह से अनावश्यक प्रतिबंध बन जाते हैं। डिजाइनर को उस रूप में तत्व को मूर्त रूप देने में सक्षम होना चाहिए जिसमें उसने इसकी कल्पना की थी। और इस मामले में, मुझे इसके लिए कोई तकनीकी सीमाएँ नहीं दिखतीं।



हम टीम में एक आम राय के लिए नहीं आए, और मालिकों ने "हम और सभी दोनों" का रास्ता अपनाया।



और मैं इस मुद्दे पर हब्रोसैक्विटी की राय में दिलचस्पी रखता था। तर्कों के साथ बहुत ही उचित।