HTML

ایک DOCTYPE کیا کرتا ہے؟

DOCTYPE 'Document Type' کا مخفف ہے۔ ایک DOCTYPE ہمیشہ ایک DTD - 'Document Type Definition' سے منسلک ہوتا ہے۔

ایک DTD تعریف کرتا ہے کہ ایک خاص قسم کی دستاویزات کو کیسے ترتیب دیا جانا چاہئے (یعنی ایک button میں ایک span ہو سکتا ہے لیکن ایک div نہیں)، جبکہ ایک DOCTYPE اعلان کرتا ہے کہ ایک دستاویز کس DTD کا احترام کرتی ہے (یعنی یہ دستاویز HTML DTD کا احترام کرتی ہے)۔

ویب صفحات کے لیے، DOCTYPE کا اعلان ضروری ہے۔ یہ صارف ایجنٹوں کو یہ بتانے کے لیے استعمال کیا جاتا ہے کہ آپ کی دستاویز HTML کی وضاحتوں کے کس ورژن کا احترام کرتی ہے۔ ایک بار جب صارف ایجنٹ ایک درست DOCTYPE کو پہچان لیتا ہے، تو وہ دستاویز کو پڑھنے کے لیے اس DOCTYPE سے مماثل no-quirks mode کو متحرک کرے گا۔ اگر کوئی صارف ایجنٹ درست DOCTYPE کو نہیں پہچانتا ہے، تو وہ quirks mode کو متحرک کرے گا۔

HTML5 معیارات کے لیے DOCTYPE کا اعلان <!DOCTYPE html> ہے۔

متعدد زبانوں میں مواد کے ساتھ ایک صفحہ کیسے پیش کیا جاتا ہے؟

میں فرض کروں گا کہ یہ سب سے عام معاملے کے بارے میں پوچھ رہا ہے، جو کہ متعدد زبانوں میں دستیاب مواد کے ساتھ ایک صفحہ کیسے پیش کیا جائے، لیکن صفحے کے اندر موجود مواد کو صرف ایک مستقل زبان میں دکھایا جانا چاہیے۔

جب ایک HTTP درخواست سرور پر کی جاتی ہے، تو درخواست کرنے والا صارف ایجنٹ عام طور پر زبان کی ترجیحات کے بارے میں معلومات بھیجتا ہے، جیسا کہ Accept-Language ہیڈر میں۔ اس کے بعد سرور اس معلومات کا استعمال کر کے دستاویز کا ایک ورژن مناسب زبان میں واپس کر سکتا ہے اگر ایسا کوئی متبادل دستیاب ہو۔ واپس کی گئی HTML دستاویز کو <html> ٹیگ میں lang وصف کا بھی اعلان کرنا چاہیے، جیسے <html lang="en">...</html>۔

یقیناً یہ ایک سرچ انجن کو یہ بتانے کے لیے بیکار ہے کہ وہی مواد مختلف زبانوں میں دستیاب ہے، اور اس لیے آپ کو <head> میں hreflang وصف کا بھی استعمال کرنا چاہیے۔ مثلاً <link rel="alternate" hreflang="de" href="http://de.example.com/page.html" />

بیک اینڈ میں، HTML مارک اپ میں i18n پلیس ہولڈرز اور YML یا JSON فارمیٹس میں ذخیرہ شدہ مخصوص زبان کے لیے مواد شامل ہوگا۔ سرور پھر اس خاص زبان میں مواد کے ساتھ HTML صفحہ کو متحرک طور پر تیار کرتا ہے، عام طور پر ایک بیک اینڈ فریم ورک کی مدد سے۔

کثیر لسانی سائٹس کے لیے ڈیزائن یا ڈیولپ کرتے وقت آپ کو کن چیزوں سے ہوشیار رہنا چاہیے؟

  • اپنے HTML میں lang وصف استعمال کریں۔
  • صارفین کو ان کی مادری زبان کی طرف ہدایت کرنا - صارف کو بغیر کسی پریشانی کے آسانی سے اپنا ملک/زبان تبدیل کرنے کی اجازت دیں۔
  • راسٹر پر مبنی تصاویر (مثلاً png, gif, jpg, وغیرہ) میں متن، ایک قابل توسیع طریقہ نہیں ہے - کسی بھی کمپیوٹر پر اچھی لگنے والے، غیر نظامی فونٹس کو ظاہر کرنے کے لیے تصویر میں متن رکھنا اب بھی ایک مقبول طریقہ ہے۔ تاہم، تصویری متن کا ترجمہ کرنے کے لیے، متن کی ہر سٹرنگ کو ہر زبان کے لیے ایک علیحدہ تصویر بنانے کی ضرورت ہوگی۔ اس طرح کی چند ایک سے زیادہ تبدیلیاں تیزی سے قابو سے باہر ہو سکتی ہیں۔
  • پابند الفاظ/جملوں کی لمبائی - کچھ مواد کسی دوسری زبان میں لکھے جانے پر لمبا ہو سکتا ہے۔ ڈیزائن میں لے آؤٹ یا اوور فلو کے مسائل سے ہوشیار رہیں۔ ایسے ڈیزائن سے بچنا بہتر ہے جہاں متن کی مقدار ڈیزائن کو بنائے یا بگاڑے گی۔ حرفوں کی تعداد شہ سرخیوں، لیبلز اور بٹنوں جیسی چیزوں کے ساتھ آتی ہے۔ یہ جسمانی متن یا تبصروں جیسے آزاد بہاؤ والے متن کے ساتھ کم مسئلہ ہے۔
  • رنگوں کو کیسے سمجھا جاتا ہے اس پر دھیان دیں - رنگوں کو زبانوں اور ثقافتوں میں مختلف طریقے سے سمجھا جاتا ہے۔ ڈیزائن کو مناسب طریقے سے رنگ کا استعمال کرنا چاہیے۔
  • تاریخوں اور کرنسیوں کی فارمیٹنگ - کیلنڈر کی تاریخوں کو بعض اوقات مختلف طریقوں سے پیش کیا جاتا ہے۔ مثلاً امریکہ میں "May 31, 2012" بمقابلہ یورپ کے کچھ حصوں میں "31 May 2012"۔
  • ترجمہ شدہ سٹرنگز کو جوڑیں نہیں - "The date today is " + date جیسی کوئی چیز نہ کریں۔ یہ مختلف الفاظ کے ترتیب والی زبانوں میں ٹوٹ جائے گا۔ اس کے بجائے ہر زبان کے لیے پیرامیٹرز کے متبادل کے ساتھ ایک ٹیمپلیٹ سٹرنگ استعمال کریں۔ مثال کے طور پر، انگریزی اور چینی میں درج ذیل دو جملوں کو دیکھیں: I will travel on {% date %} اور {% date %} میں سفر کروں گا۔ نوٹ کریں کہ زبان کے گرامر کے اصولوں کی وجہ سے متغیر کی پوزیشن مختلف ہے۔
  • زبان پڑھنے کی سمت - انگریزی میں، ہم بائیں سے دائیں، اوپر سے نیچے پڑھتے ہیں، روایتی جاپانی میں، متن اوپر سے نیچے، دائیں سے بائیں پڑھا جاتا ہے۔
  • مفید - راستے میں لوکیل شامل کریں (مثلاً en_US, zh_CN, وغیرہ)۔

`data-` اوصاف کس کے لیے اچھے ہیں؟

جاوا اسکرپٹ فریم ورکس کے مقبول ہونے سے پہلے، فرنٹ اینڈ ڈویلپرز data- اوصاف کا استعمال DOM کے اندر ہی اضافی ڈیٹا کو ذخیرہ کرنے کے لیے کرتے تھے، بغیر کسی دوسری ہیکس کے جیسے کہ غیر معیاری اوصاف، DOM پر اضافی خصوصیات۔ اس کا مقصد صفحہ یا ایپلیکیشن کے لیے نجی حسب ضرورت ڈیٹا کو ذخیرہ کرنا ہے، جس کے لیے مزید مناسب اوصاف یا عناصر نہیں ہیں۔

آج کل، data- اوصاف کا استعمال عام طور پر حوصلہ افزائی نہیں کی جاتی ہے۔ ایک وجہ یہ ہے کہ صارفین براؤزر میں انسپیکٹ ایلیمنٹ کا استعمال کرتے ہوئے ڈیٹا وصف کو آسانی سے تبدیل کر سکتے ہیں۔ ڈیٹا ماڈل کو خود جاوا اسکرپٹ کے اندر ذخیرہ کرنا بہتر ہے اور ممکنہ طور پر کسی لائبریری یا فریم ورک کے ذریعے ڈیٹا بائنڈنگ کے ذریعے DOM کے ساتھ اپ ڈیٹ رہنا چاہیے۔

تاہم، ڈیٹا اوصاف کا ایک بالکل درست استعمال، Selenium اور Capybara جیسے end to end ٹیسٹنگ فریم ورکس کے لیے ایک ہک شامل کرنا ہے تاکہ کوئی بے معنی کلاسز یا ID اوصاف بنانے کی ضرورت نہ پڑے۔ عنصر کو ایک خاص Selenium سپیک کے ذریعے تلاش کرنے کا ایک طریقہ درکار ہے اور data-selector='the-thing' جیسا کچھ ایسا کرنے کا ایک درست طریقہ ہے جو ورنہ سیمنٹک مارک اپ کو الجھائے بغیر ہے۔

HTML5 کو ایک اوپن ویب پلیٹ فارم کے طور پر دیکھیں۔ HTML5 کے بنیادی بلاکس کیا ہیں؟

  • سیمانٹکس - آپ کو اپنے مواد کو زیادہ درست طریقے سے بیان کرنے کی اجازت دیتا ہے۔
  • کنیکٹیویٹی - آپ کو سرور کے ساتھ نئے اور جدید طریقوں سے بات چیت کرنے کی اجازت دیتا ہے۔
  • آف لائن اور سٹوریج - ویب صفحات کو کلائنٹ سائیڈ پر مقامی طور پر ڈیٹا ذخیرہ کرنے اور آف لائن زیادہ موثر طریقے سے کام کرنے کی اجازت دیتا ہے۔
  • ملٹی میڈیا - ویڈیو اور آڈیو کو اوپن ویب میں فرسٹ کلاس شہری بناتا ہے۔
  • 2D/3D گرافکس اور اثرات - پیشکش کے اختیارات کی ایک بہت زیادہ متنوع رینج کی اجازت دیتا ہے۔
  • کارکردگی اور انضمام - زیادہ رفتار کی اصلاح اور کمپیوٹر ہارڈ ویئر کا بہتر استعمال فراہم کرتا ہے۔
  • ڈیوائس تک رسائی - مختلف ان پٹ اور آؤٹ پٹ آلات کے استعمال کی اجازت دیتا ہے۔
  • سٹائلنگ - مصنفین کو زیادہ نفیس تھیمز لکھنے کی اجازت دیتا ہے۔

ایک `cookie`، `sessionStorage` اور `localStorage` کے درمیان فرق بیان کریں۔

مندرجہ بالا تمام ٹیکنالوجیز کلائنٹ سائیڈ پر کلیدی قدر ذخیرہ کرنے کے میکانزم ہیں۔ وہ صرف قدروں کو سٹرنگ کے طور پر ذخیرہ کرنے کے قابل ہیں۔

| | cookie | localStorage | sessionStorage | | --- | --- | --- | --- | | ابتدا کار | کلائنٹ یا سرور۔ سرور Set-Cookie ہیڈر استعمال کر سکتا ہے | کلائنٹ | کلائنٹ | | میعاد ختم ہونا | دستی طور پر سیٹ کریں | ہمیشہ | ٹیب بند ہونے پر | | براؤزر سیشنز میں مستقل | میعاد ختم ہونے پر منحصر ہے کہ آیا میعاد مقرر کی گئی ہے | ہاں | نہیں | | ہر HTTP درخواست کے ساتھ سرور کو بھیجا جاتا ہے | کوکیز خود بخود Cookie ہیڈر کے ذریعے بھیجی جاتی ہیں | نہیں | نہیں | | صلاحیت (فی ڈومین) | 4kb | 5MB | 5MB | | رسائی | کوئی بھی ونڈو | کوئی بھی ونڈو | وہی ٹیب |

نوٹ: اگر صارف براؤزر کے ذریعہ فراہم کردہ کسی بھی میکانزم کے ذریعے براؤز ڈیٹا کو صاف کرنے کا فیصلہ کرتا ہے، تو یہ ذخیرہ شدہ کوئی بھی cookie، localStorage، یا sessionStorage کو صاف کر دے گا۔ مقامی مستقل مزاجی کے لیے ڈیزائن کرتے وقت، خاص طور پر سرور سائیڈ پر ڈیٹا بیس یا اسی طرح کی چیزوں میں ذخیرہ کرنے جیسے متبادلات سے موازنہ کرتے وقت اس بات کو ذہن میں رکھنا ضروری ہے (جو یقیناً صارف کے اقدامات کے باوجود برقرار رہے گا)۔

`<script>`، `<script async>` اور `<script defer>` کے درمیان فرق بیان کریں۔

  • <script> - HTML پارسنگ بلاک ہو جاتی ہے، اسکرپٹ کو فوری طور پر حاصل اور عمل میں لایا جاتا ہے، HTML پارسنگ اسکرپٹ کے عمل میں آنے کے بعد دوبارہ شروع ہوتی ہے۔
  • <script async> - اسکرپٹ کو HTML پارسنگ کے متوازی طور پر حاصل کیا جائے گا اور جیسے ہی دستیاب ہوگا اسے عمل میں لایا جائے گا (ممکنہ طور پر HTML پارسنگ مکمل ہونے سے پہلے)۔ async کا استعمال کریں جب اسکرپٹ صفحے پر کسی دوسرے اسکرپٹ سے آزاد ہو، مثال کے طور پر، تجزیات۔
  • <script defer> - اسکرپٹ کو HTML پارسنگ کے متوازی طور پر حاصل کیا جائے گا اور جب صفحہ پارسنگ مکمل کر لے گا تو اسے عمل میں لایا جائے گا۔ اگر ان میں سے متعدد ہیں، تو ہر ڈیفرڈ اسکرپٹ اسی ترتیب میں عمل میں لایا جاتا ہے جس میں وہ دستاویز میں پائے گئے تھے۔ اگر کوئی اسکرپٹ مکمل طور پر پارس شدہ DOM پر انحصار کرتا ہے، تو defer وصف یہ یقینی بنانے میں مفید ہوگا کہ HTML کو عمل میں لانے سے پہلے مکمل طور پر پارس کیا جائے۔ ایک ڈیفرڈ اسکرپٹ میں document.write نہیں ہونا چاہیے۔

نوٹ: async اور defer اوصاف ان اسکرپٹس کے لیے نظر انداز کیے جاتے ہیں جن میں src وصف نہیں ہوتا ہے۔

CSS `<link>` کو `<head></head>` کے درمیان اور JS `<script>`s کو `</body>` سے بالکل پہلے رکھنا عام طور پر ایک اچھا خیال کیوں ہے؟ کیا آپ کو کوئی استثنا معلوم ہے؟

<head> میں <link>s رکھنا

<head> میں <link>s رکھنا ایک بہتر ویب سائٹ کی تعمیر میں مناسب تفصیلات کا حصہ ہے۔ جب کوئی صفحہ پہلی بار لوڈ ہوتا ہے، تو HTML اور CSS کو بیک وقت پارس کیا جا رہا ہوتا ہے؛ HTML DOM (Document Object Model) بناتا ہے اور CSS CSSOM (CSS Object Model) بناتا ہے۔ دونوں ایک ویب سائٹ میں بصری بنانے کے لیے ضروری ہیں، جو ایک تیز "پہلی معنی خیز پینٹ" ٹائمنگ کی اجازت دیتا ہے۔ یہ ترقی پسند رینڈرنگ ایک زمرہ کی اصلاح ہے جس میں سائٹوں کی کارکردگی کے سکور میں پیمائش کی جاتی ہے۔ اسٹائل شیٹس کو دستاویز کے نچلے حصے کے قریب رکھنا وہ چیز ہے جو بہت سے براؤزرز میں ترقی پسند رینڈرنگ کو روکتی ہے۔ کچھ براؤزرز رینڈرنگ کو روک دیتے ہیں تاکہ صفحے کے عناصر کو دوبارہ پینٹ کرنے سے بچ سکیں اگر ان کے اسٹائل تبدیل ہوتے ہیں۔ صارف پھر ایک خالی سفید صفحہ دیکھتا رہ جاتا ہے۔ دوسرے اوقات میں اسٹائل نہ کیے گئے مواد (FOUC) کی جھلک ہو سکتی ہے، جو بغیر کسی اسٹائلنگ کے ایک ویب صفحہ دکھاتا ہے۔

<script>s کو </body> سے بالکل پہلے رکھنا

<script> ٹیگز HTML پارسنگ کو روکتے ہیں جب انہیں ڈاؤن لوڈ اور عمل میں لایا جاتا ہے جو آپ کے صفحے کو سست کر سکتا ہے۔ اسکرپٹس کو نیچے رکھنے سے HTML کو پہلے پارس اور صارف کو دکھانے کی اجازت ملے گی۔

<script>s کو نیچے رکھنے کا ایک استثنا یہ ہے جب آپ کے اسکرپٹ میں document.write() شامل ہو، لیکن آج کل document.write() کا استعمال ایک اچھا عمل نہیں ہے۔ نیز، <script>s کو نیچے رکھنے کا مطلب یہ ہے کہ براؤزر اسکرپٹس کو ڈاؤن لوڈ کرنا شروع نہیں کر سکتا جب تک کہ پوری دستاویز پارس نہ ہو جائے۔ یہ یقینی بناتا ہے کہ آپ کا کوڈ جسے DOM عناصر میں ترمیم کرنے کی ضرورت ہے وہ کوئی غلطی نہیں پھینکے گا اور پورے اسکرپٹ کو روک نہیں پائے گا۔ اگر آپ کو <script>s کو <head> میں ڈالنے کی ضرورت ہے، تو defer وصف کا استعمال کریں، جو HTML کے پارس ہونے کے بعد ہی اسکرپٹ کو چلانے کا وہی اثر حاصل کرے گا لیکن براؤزر اسکرپٹ کو پہلے ڈاؤن لوڈ کر سکتا ہے۔

یاد رکھیں کہ اسکرپٹس کو بند ہونے والے </body> ٹیگ سے بالکل پہلے رکھنا یہ تاثر پیدا کرے گا کہ صفحہ خالی کیشے پر تیزی سے لوڈ ہوتا ہے (کیونکہ اسکرپٹس دستاویز کے باقی حصوں کو ڈاؤن لوڈ کرنے میں رکاوٹ نہیں بنیں گے)۔ تاہم، اگر آپ کے پاس کچھ کوڈ ہے جسے آپ صفحہ لوڈ کے دوران چلانا چاہتے ہیں، تو یہ پوری صفحہ لوڈ ہونے کے بعد ہی چلنا شروع ہوگا۔ اگر آپ ان اسکرپٹس کو <head> ٹیگ میں ڈالتے ہیں، تو وہ پہلے چلنا شروع کر دیتے ہیں - تو ایک تیار کیشے پر صفحہ دراصل تیزی سے لوڈ ہوتا ہوا نظر آئے گا۔

<head> اور <body> ٹیگز اب اختیاری ہیں

HTML5 کی تفصیلات کے مطابق، کچھ HTML ٹیگز جیسے <head> اور <body> اختیاری ہیں۔ گوگل کی اسٹائل گائیڈ بھی بائٹس بچانے کے لیے انہیں ہٹانے کی سفارش کرتی ہے۔ تاہم، یہ عمل ابھی تک وسیع پیمانے پر اپنایا نہیں گیا ہے اور کارکردگی کا فائدہ بہت کم ہونے کا امکان ہے اور زیادہ تر سائٹوں کے لیے اس سے کوئی فرق نہیں پڑے گا۔

ترقی پسند رینڈرنگ کیا ہے؟

ترقی پسند رینڈرنگ ان تکنیکوں کو دیا گیا نام ہے جو ایک ویب صفحے کی کارکردگی کو بہتر بنانے کے لیے استعمال ہوتی ہیں (خاص طور پر، محسوس شدہ لوڈ وقت کو بہتر بنانا) تاکہ مواد کو جلد از جلد دکھانے کے لیے رینڈر کیا جا سکے۔

یہ براڈ بینڈ انٹرنیٹ سے پہلے کے دنوں میں بہت زیادہ عام تھی لیکن یہ اب بھی جدید ترقی میں استعمال ہوتی ہے کیونکہ موبائل ڈیٹا کنکشن تیزی سے مقبول (اور ناقابل اعتبار) ہوتے جا رہے ہیں!

ایسی تکنیکوں کی مثالیں:

  • تصاویر کی سست لوڈنگ - صفحے پر موجود تصاویر ایک ساتھ لوڈ نہیں ہوتی ہیں۔ جاوا اسکرپٹ کا استعمال اس وقت ایک تصویر لوڈ کرنے کے لیے کیا جائے گا جب صارف صفحے کے اس حصے میں اسکرول کرے گا جو تصویر کو دکھاتا ہے۔
  • مرئی مواد کو ترجیح دینا (یا اوپر سے فولڈ رینڈرنگ) - صرف کم از کم CSS/مواد/اسکرپٹس کو شامل کریں جو صارف کے براؤزر میں پہلے رینڈر ہونے والے صفحے کی مقدار کے لیے ضروری ہوں تاکہ جلد از جلد دکھایا جا سکے، آپ پھر ڈیفرڈ اسکرپٹس کا استعمال کر سکتے ہیں یا DOMContentLoaded/load ایونٹ کو سن سکتے ہیں تاکہ دیگر وسائل اور مواد کو لوڈ کیا جا سکے۔
  • Async HTML fragments - HTML کے حصوں کو براؤزر میں فلش کرنا جب صفحہ بیک اینڈ پر تیار کیا جا رہا ہو۔ تکنیک پر مزید تفصیلات مل سکتی ہیں۔

آپ ایک تصویری ٹیگ میں `srcset` وصف کیوں استعمال کریں گے؟ اس عمل کی وضاحت کریں جو براؤزر اس وصف کے مواد کا جائزہ لیتے وقت استعمال کرتا ہے۔

آپ srcset وصف کا استعمال اس وقت کریں گے جب آپ صارفین کو ان کے آلے کی ڈسپلے کی چوڑائی کے لحاظ سے مختلف تصاویر پیش کرنا چاہیں - ریٹینا ڈسپلے والے آلات کو اعلیٰ معیار کی تصاویر پیش کرنے سے صارف کے تجربے میں اضافہ ہوتا ہے جبکہ کم ریزولوشن والے آلات کو کم ریزولوشن کی تصاویر پیش کرنے سے کارکردگی میں اضافہ ہوتا ہے اور ڈیٹا کا ضیاع کم ہوتا ہے (کیونکہ ایک بڑی تصویر پیش کرنے سے کوئی مرئی فرق نہیں پڑے گا)۔ مثال کے طور پر: <img srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 2000w" src="..." alt=""> براؤزر کو کلائنٹ کی ریزولوشن کے لحاظ سے چھوٹی، درمیانی یا بڑی .jpg گرافک دکھانے کو کہتا ہے۔ پہلی قدر تصویر کا نام ہے اور دوسری پکسلز میں تصویر کی چوڑائی ہے۔ 320px کی ڈیوائس کی چوڑائی کے لیے، درج ذیل حساب کتاب کیے جاتے ہیں:

  • 500 / 320 = 1.5625
  • 1000 / 320 = 3.125
  • 2000 / 320 = 6.25

اگر کلائنٹ کی ریزولوشن 1x ہے، تو 1.5625 سب سے قریب ہے، اور small.jpg سے متعلق 500w کو براؤزر منتخب کرے گا۔

اگر ریزولوشن ریٹینا (2x) ہے، تو براؤزر کم از کم سے اوپر کی سب سے قریب ریزولوشن کا استعمال کرے گا۔ اس کا مطلب ہے کہ یہ 500w (1.5625) کا انتخاب نہیں کرے گا کیونکہ یہ 1 سے زیادہ ہے اور تصویر خراب نظر آ سکتی ہے۔ براؤزر پھر 2 کے قریب تناسب والی تصویر کا انتخاب کرے گا جو کہ 1000w (3.125) ہے۔

srcsets اس مسئلے کو حل کرتے ہیں جہاں آپ تنگ اسکرین والے آلات کو چھوٹی تصویری فائلیں پیش کرنا چاہتے ہیں، کیونکہ انہیں ڈیسک ٹاپ ڈسپلے جیسی بڑی تصاویر کی ضرورت نہیں ہوتی ہے — اور اختیاری طور پر یہ بھی کہ آپ اعلی کثافت/کم کثافت والی اسکرینوں کو مختلف ریزولوشن کی تصاویر پیش کرنا چاہتے ہیں۔

کیا آپ نے پہلے مختلف HTML ٹیمپلیٹنگ زبانیں استعمال کی ہیں؟

جی ہاں، Pug (پہلے Jade)، ERB، Slim، Handlebars، Jinja، Liquid، اور EJS چند ایک نام ہیں۔ میری رائے میں، وہ کم و بیش ایک جیسے ہیں اور مواد کو بچانے اور دکھائے جانے والے ڈیٹا کو ہیرا پھیری کرنے کے لیے مفید فلٹرز کی یکساں فعالیت فراہم کرتے ہیں۔ زیادہ تر ٹیمپلیٹنگ انجن آپ کو اپنی مرضی کے مطابق پروسیسنگ کی ضرورت پڑنے پر اپنے فلٹرز کو داخل کرنے کی بھی اجازت دیں گے۔

کینوس اور SVG کے درمیان کیا فرق ہے؟

کینوس راسٹر پر مبنی ہے، پکسلز کے ساتھ کام کرتا ہے، جبکہ SVG ویکٹر پر مبنی ہے، شکلوں کی ریاضیاتی وضاحتوں کا استعمال کرتا ہے۔ کینوس امپیریٹو ڈرائنگ کا استعمال کرتا ہے، جہاں ہر قدم کو جاوا اسکرپٹ سے بیان کیا جاتا ہے، جو متحرک اور انٹرایکٹو گرافکس جیسے اینیمیشنز اور گیمز کے لیے مثالی ہے۔

اس کے برعکس، SVG ڈیکلریٹو ڈرائنگ کا استعمال کرتا ہے، جس میں شکلیں اور راستے براہ راست HTML میں بیان کیے جاتے ہیں، جو اسے زیادہ قابل رسائی اور SEO کے لیے دوستانہ بناتا ہے۔ کینوس اپنی کم اوور ہیڈ کی وجہ سے پیچیدہ مناظر کے لیے بہترین ہے، لیکن پیمانے پر تصویر کے معیار میں کمی آ سکتی ہے۔ SVG، ریزولوشن سے آزاد ہونے کی وجہ سے، معیار کی قربانی کے بغیر مختلف اسکرین سائز کے مطابق ڈھل جاتا ہے۔

بالآخر، کینوس متحرک، کارکردگی پر مبنی گرافکس کے لیے موزوں ہے، جبکہ SVG قابل پیمائش، ریزولوشن سے آزاد گرافکس میں بہترین ہے، جس میں موروثی رسائی اور SEO کے فوائد ہیں۔

HTML میں خالی عناصر کیا ہیں؟

HTML میں خالی عناصر وہ عناصر ہیں جن میں ان کے اوپننگ اور کلوزنگ ٹیگز کے درمیان کوئی مواد نہیں ہوتا ہے۔ اس کے بجائے، وہ خود بند ہونے والے ٹیگز ہیں، یعنی ان کے پاس کلوزنگ اینگل بریکٹ (>) سے پہلے ایک فارورڈ سلیش (/) ہوتا ہے۔ خالی عناصر کی کچھ عام مثالیں یہ ہیں:

  • <img>: دستاویز میں تصاویر کو ایمبیڈ کرنے کے لیے استعمال ہوتا ہے۔
  • <input>: صارف کا ان پٹ قبول کرنے کے لیے استعمال ہوتا ہے۔
  • <br>: لائن بریک یا زبردستی لائن بریک داخل کرنے کے لیے استعمال ہوتا ہے۔
  • <hr>: افقی قواعد یا جداکاروں کو بنانے کے لیے استعمال ہوتا ہے۔