PX থেকে REM কনভার্টার

px থেকে rem এবং আবার rem থেকে px, তাৎক্ষণিক

এই px থেকে rem কনভার্টার আপনার বেছে নেওয়া যেকোনো রুট ফন্ট সাইজের সাপেক্ষে px, rem, em ও pt-কে একসাথে সিঙ্কে রাখে। যেকোনো একটি ঘরে লিখুন, বাকিগুলো লাইভ আপডেট হয়ে যায়, তাই পিক্সেল ডিজাইন মকআপ থেকে স্কেলযোগ্য CSS rem ইউনিটে যাওয়া — বা উল্টো rem থেকে px-এ ফিরে আসা — কোনো মানসিক অঙ্ক ছাড়াই হয়। এটি একটি দ্রুত, ফ্রি CSS ইউনিট কনভার্টার যা সম্পূর্ণভাবে আপনার ব্রাউজারে চলে, কিছুই আপলোড হয় না।

কনভার্টারের নিচের রেফারেন্স টেবিলে প্রতিদিনের কাজে দরকারি সব সাধারণ px মান তালিকাভুক্ত থাকে — যেকোনো ফলাফল এক ক্লিকে কপি করুন। রুট ফন্ট সাইজ পাল্টালে পুরো টেবিলটি সঙ্গে সঙ্গে পুনরায় হিসাব করে, ফলে ১৬px প্রজেক্ট আর ১০px (৬২.৫% ট্রিক) প্রজেক্টের মধ্যে সহজেই যাওয়া-আসা করা যায়।

px থেকে rem সূত্রের ব্যাখ্যা

রূপান্তরটি সহজ: rem = px ÷ রুট ফন্ট সাইজ। ব্রাউজারের ডিফল্ট রুট ১৬px, তাই ১৬px = 1rem, ২৪px = 1.5rem, এবং ৪০px = 2.5rem। উল্টো দিকে: px = rem × রুট, তাই 0.875rem × ১৬ = ১৪px। কনভার্টারটি দ্বিমুখী হওয়ায় আপনাকে কখনও মনে রাখতে হয় না কোন দিকে কাজ করছেন — শুধু যে ঘরের মান জানেন সেটিতে লিখুন, বাকিগুলো আপডেট হয়ে যাবে।

৬২.৫% ট্রিক এটিকে আরও সরল করে: html { font-size: 62.5%; } সেট করলে রুট হয়ে যায় ১০px, তখন rem মানগুলো পরিষ্কারভাবে ১০-এর গুণিতকে মিলে যায়। 1.6rem = ১৬px, 2.4rem = ২৪px, 3.2rem = ৩২px। এখানে ১০px প্রিসেটে সুইচ করে সব সাধারণ মানের জন্য পরিষ্কার এই ম্যাপিং দেখে নিন।

px, rem ও em — পার্থক্য কোথায়?

px একটি পরম (absolute) ইউনিট: ১৬px সবসময়ই ১৬px। rem রুট (html) এলিমেন্টের ফন্ট সাইজের সাপেক্ষ, যা পুরো পেজের জন্য একটি ধারাবাহিক অ্যাঙ্কর দেয়। em তার নিজের প্যারেন্টের ফন্ট সাইজের সাপেক্ষ, তাই এলিমেন্ট নেস্ট করলে এটি চক্রবৃদ্ধির মতো জমে ওঠে — 1.2em-এর একটি article-এর ভেতরে 1.2em-এর একটি section-এর ভেতরের একটি প্যারাগ্রাফ হয় 1.2 × 1.2 = 1.44em, অথচ 1.44rem নেস্টিং যত গভীরই হোক রুটের সমান 1.44 গুণই থাকত।

টুলটি প্রিন্ট-ধাঁচের মানের জন্য pt (১px = 0.75pt)-ও দেখায়। কোনো নেস্টিং ছাড়া ১৬px রুটে ১৬px, 1rem ও 1em সবই সমান — পার্থক্যটি তখনই দৃশ্যমান হয় যখন প্যারেন্টের ফন্ট সাইজ বদলায় বা ব্যবহারকারী তাঁর ব্রাউজারের ডিফল্ট টেক্সট সাইজ বদলে দেন।

ফন্ট সাইজে কেন rem ব্যবহার করবেন — অ্যাক্সেসিবিলিটি গুরুত্বপূর্ণ

টাইপকে px-এর বদলে rem-এ মাপা একটি অর্থপূর্ণ অ্যাক্সেসিবিলিটি উন্নতি। কোনো দর্শনার্থী যখন তাঁর ব্রাউজারের ডিফল্ট টেক্সট সাইজ বাড়ান (দৃষ্টি সমস্যাযুক্ত ব্যবহারকারী বা হাই-DPI স্ক্রিনে পড়া মানুষদের জন্য একটি সাধারণ প্রয়োজন), তখন প্রতিটি rem-ভিত্তিক ফন্ট সাইজ ও স্পেসিং মান তার সাথে সমানুপাতিকভাবে বাড়ে। px মান স্থির থেকে যায় এবং এমন লেআউট তৈরি করতে পারে যেখানে টেক্সট তার কন্টেইনারের তুলনায় খুব ছোট হয়ে যায়।

WCAG 2.1 গাইডলাইন 1.4.4 অনুযায়ী টেক্সট কনটেন্ট বা কার্যকারিতা না হারিয়ে ২০০% পর্যন্ত রিসাইজযোগ্য হতে হবে। ডিফল্টভাবে rem ইউনিটে বিল্ড করলে এই গাইডলাইন মেনে চলা অনেক সহজ হয় — রুট বদলালে আপনার পুরো টাইপোগ্রাফিক স্কেল এবং বেশিরভাগ স্পেসিং সরে যায়, অনুপাত অক্ষুণ্ন থাকে। এই কারণেই Tailwind CSS-এর মতো টুল সর্বত্র ডিফল্টভাবে rem ইউনিট ব্যবহার করে।

সাধারণ px থেকে rem মান — দ্রুত রেফারেন্স

স্ট্যান্ডার্ড ১৬px রুটে: 8px = 0.5rem, 10px = 0.625rem, 12px = 0.75rem, 13px = 0.8125rem, 14px = 0.875rem, 16px = 1rem, 18px = 1.125rem, 20px = 1.25rem, 24px = 1.5rem, 28px = 1.75rem, 32px = 2rem, 36px = 2.25rem, 40px = 2.5rem, 48px = 3rem, 64px = 4rem। এগুলোই CSS কোডবেসে আপনি সবচেয়ে বেশি লিখবেন।

টুলের রেফারেন্স টেবিলে এই সবগুলো তালিকাভুক্ত থাকে এবং যেকোনো মান এক ক্লিকে কপি করা যায় — প্রতিবার হাতে হিসাব করার চেয়ে দ্রুত এবং টেবিল মুখস্থ করার চেয়ে কম ভুলপ্রবণ। এই rem ক্যালকুলেটর বুকমার্ক করে রাখুন, আর যখনই পিক্সেলে দেওয়া ডিজাইন স্পেক ও rem ইউনিটে লেখা CSS-এর মধ্যে অনুবাদ করতে হবে তখন খুলুন। Tailwind CSS-এও এই একই rem মান ব্যবহৃত হয়: text-sm = 0.875rem (14px), text-base = 1rem (16px), text-lg = 1.125rem (18px), text-xl = 1.25rem (20px), text-2xl = 1.5rem (24px)।

rem কেন ফন্ট সাইজে em-কে হারায়

em নেস্টেড এলিমেন্টের মধ্য দিয়ে চক্রবৃদ্ধির মতো জমে, যা দ্রুতই বোঝা কঠিন হয়ে ওঠে। একটি Modal-এ font-size 1.25em, তার ভেতরের একটি Card-এ 1.25em, আর সেই Card-এর ভেতরের একটি label-এ 1.25em হলে, label রেন্ডার হয় বেস সাইজের 1.25 × 1.25 × 1.25 = 1.953 গুণে — প্রায় দ্বিগুণ — অথচ কোডে কোনো স্পষ্ট ইঙ্গিত থাকে না। আরেকটি স্তর যোগ করলে তা ২.৪৪ গুণে পৌঁছায়। এই চক্রবৃদ্ধি প্রভাব CSS-এর সবচেয়ে পুরোনো ফাঁদগুলোর একটি, অসংখ্য “আমার নেস্টেড টেক্সট এত বড় কেন?” ডিবাগিং সেশনের জন্য দায়ী।

rem চক্রবৃদ্ধি সম্পূর্ণ দূর করে, কারণ এটি সবসময় রুট html এলিমেন্টে অ্যাঙ্কর করে। একটি Dialog-এর ভেতরের Modal-এর ভেতরের Card-এর ভেতরে 1.25rem-এ সেট করা একটি label সবসময়ই রুট ফন্ট সাইজের ঠিক 1.25 গুণে রেন্ডার হয়, পূর্বপুরুষ যতগুলোই নিজেদের font-size সেট করুক না কেন। এই পূর্বানুমেয়তার কারণেই প্রতিটি বড় কম্পোনেন্ট লাইব্রেরি — Material UI, Chakra, Radix ও Mantine সহ — টাইপোগ্রাফি ও স্পেসিং টোকেনের জন্য ডিফল্টভাবে rem ব্যবহার করে।

ডিজাইন সিস্টেমের জন্য এর বাস্তব ফল তাৎপর্যপূর্ণ: কম্পোনেন্ট গঠন করার সময় rem-ভিত্তিক সাইজ ধারাবাহিক থাকে, অথচ em-ভিত্তিক সাইজে লেখককে রেন্ডার হওয়া সাইজ জানতে গোটা পূর্বপুরুষ শৃঙ্খল মাথায় রাখতে হয়। em শুধু ইচ্ছাকৃত আপেক্ষিক স্কেলিংয়ের জন্য রেখে দিন — যেমন একটি আইকন যা 1.2em হওয়া উচিত যাতে পাশের টেক্সটের ফন্ট সাইজের সাথে স্কেল করে — সাধারণ ফন্ট-সাইজ ইউনিট হিসেবে নয়।

৬২.৫% রুট ফন্ট-সাইজ ট্রিক — জনপ্রিয় কিন্তু বিতর্কিত

৬২.৫% ট্রিক html { font-size: 62.5%; } সেট করে, যা ব্রাউজারের ডিফল্ট ১৬px-এ ১০px হয়ে দাঁড়ায়। এতে rem-এর অঙ্ক তুচ্ছভাবে সহজ হয়ে যায়: 1.6rem = ১৬px, 2.4rem = ২৪px, 3.2rem = ৩২px। প্রতিটি rem মান শুধু পিক্সেল মানকে ১০ দিয়ে ভাগ করা, যা অনেক ডেভেলপার ১৬ দিয়ে ভাগ করার চেয়ে সহজ মনে করেন (১৬ দিয়ে ভাগ করলে খুব কমই গোল সংখ্যা হয় — ১৪px হয়ে যায় দুর্বোধ্য 0.875rem)।

সমস্যা হলো এটি ব্যবহারকারীর ব্রাউজার ফন্ট-সাইজ পছন্দকে ওভাররাইড করে। কোনো ব্যবহারকারী পড়ার সুবিধার জন্য তাঁর ব্রাউজার ডিফল্ট ২০px-এ সেট করলে — যা কম দৃষ্টিশক্তির ব্যবহারকারী বা দূর থেকে বড় স্ক্রিনে পড়া যে কারও জন্য সাধারণ প্রয়োজন — html { font-size: 62.5%; } নতুন রুট বানিয়ে ফেলে ২০px-এর ৬২.৫% = ১২.৫px। সাইটের প্রতিটি rem মান এখন ব্যবহারকারীর চাওয়া ২০px-এর বদলে ১২.৫px-এ অ্যাঙ্কর করে। এই কৌশল প্রথমেই rem ব্যবহারের গোটা অ্যাক্সেসিবিলিটি সুবিধা নষ্ট করে দেয়।

WCAG 2.1 সাফল্য মানদণ্ড 1.4.4 (Resize Text, Level AA) অনুযায়ী টেক্সট কনটেন্ট বা কার্যকারিতা না হারিয়ে ২০০% পর্যন্ত রিসাইজযোগ্য হতে হবে। ৬২.৫% ট্রিক শুধু অঙ্কের শর্টকাটের জন্য ব্যবহার করলে সরাসরি এটি লঙ্ঘন করে না, তবে rem যে ব্যবহারকারীর ফন্ট-সাইজ সম্মান দেওয়ার কথা তা এটি অনেকখানি ক্ষয় করে ফেলে। একটি পরিচ্ছন্ন পদ্ধতি হলো রুটকে তার ডিফল্টে রাখা (বা ১০০%-এর মতো একটি শতাংশে রাখা যা স্পষ্টভাবে ব্যবহারকারীর সেটিংকে মেনে চলে) এবং মেনে নেওয়া যে 0.875rem হলো ১৪px লেখার উপায়। এখানকার কনভার্টার আপনাকে ১৬-বেস মানগুলোর সাথে সহজবোধ্যতা গড়ে তুলতে সাহায্য করতে পারে, যাতে মানসিক ভাগটি স্বাভাবিক হয়ে ওঠে।

কখন px-ই সঠিক পছন্দ

rem-এর পক্ষে জোরালো যুক্তি থাকা সত্ত্বেও, কিছু CSS প্রপার্টি px-এই থাকা উচিত। বর্ডার প্রস্থ সবচেয়ে স্পষ্ট উদাহরণ: border: 1px solid ঠিক এক ডিভাইস পিক্সেল হিসেবে রেন্ডার হওয়া উচিত — একটি পরিষ্কার, সূক্ষ্ম রেখা। border: 0.0625rem solid (যা ১৬px রুটে ১px) লিখলে ব্যবহারকারী রুট ফন্ট সাইজ বাড়ালে তা সমানুপাতিকভাবে বাড়ত, আপনার ১px আলংকারিক বর্ডারকে ১.২৫px বা ১.৫px রেখায় পরিণত করে যা ভারী বা ঝাপসা দেখাতে পারে। বক্স শ্যাডো ও আউটলাইনের বৈশিষ্ট্যও একই রকম — এদের ব্লার ও স্প্রেড প্রায়ই নান্দনিক পছন্দ যা স্থির থাকা উচিত।

মিডিয়া কোয়েরি ব্রেকপয়েন্ট px-এ রাখা বেশিরভাগ ফ্রেমওয়ার্কে একটি ইচ্ছাকৃত সিদ্ধান্ত, যদিও বিতর্ক চলমান। মিডিয়া কোয়েরিতে rem ব্যবহার করলে যে ব্যবহারকারী তাঁর ব্রাউজার ডিফল্ট ২০px-এ সেট করেছেন তিনি আপনার “768px ব্রেকপয়েন্ট”-এ পৌঁছাবেন ৭৬৮ × (২০/১৬) = ৯৬০px প্রকৃত ভিউপোর্ট প্রস্থে — তাঁর সংকীর্ণ লেআউট চাওয়ার চেয়ে দেরিতে চালু হয়। কিছু দল একে সুবিধা মনে করে, অন্যরা বিপদ। Tailwind CSS px ব্রেকপয়েন্ট ব্যবহার করে; সর্বোচ্চ অ্যাক্সেসিবিলিটির লক্ষ্যযুক্ত ফ্রেমওয়ার্ক কখনও কখনও rem ব্রেকপয়েন্ট ব্যবহার করে।

জানা পিক্সেল মাত্রার ছবি, পিক্সেল-নিখুঁত হতে হবে এমন SVG আইকন, এবং একটি নির্দিষ্ট-রেজোলিউশন অ্যাসেটের সাথে যুক্ত এলিমেন্ট (পেজে বসানো ৩২×৩২ favicon, একটি স্প্রাইট শিট) — সবই px-এর ভালো প্রার্থী। মূল নিয়ম: যখন আপনি ডিভাইস পিক্সেলে থাকা কিছু বর্ণনা করছেন (একটি বর্ডার, পিক্সেল-আর্ট গ্রাফিক, জানা-মাত্রার ছবি) তখন px ব্যবহার করুন, আর যখন পড়ার প্রেক্ষাপটের সাথে স্কেল হওয়া উচিত এমন কিছু বর্ণনা করছেন (টেক্সট, ফাঁকা জায়গা, লেআউট গ্যাপ) তখন rem।

ভিউপোর্ট ইউনিট গভীরে: vh, vw, dvh ও মোবাইল বাগ

ভিউপোর্ট ইউনিট vh ও vw যথাক্রমে ব্রাউজার ভিউপোর্টের উচ্চতা ও প্রস্থের শতাংশ — 100vh মানে “ব্রাউজার উইন্ডোর পুরো উচ্চতা”। ডেস্কটপে এটি প্রত্যাশামতো কাজ করে, কিন্তু মোবাইল ব্রাউজারে এটি CSS ইতিহাসের অন্যতম বহুল লেআউট বাগ তৈরি করেছিল: মোবাইল ব্রাউজার তাদের 100vh হিসাবে অ্যাড্রেস বার ও নিচের নেভিগেশন ক্রোম অন্তর্ভুক্ত করে। 100vh-এ সেট করা একটি hero সেকশন ব্রাউজার UI-এর পেছনে চলে যেত, ক্লিপ হয়ে যেত বা প্রথম লোডে স্ক্রল অফসেট তৈরি করত। ব্যবহারকারী স্ক্রল করলে অ্যাড্রেস বার লুকিয়ে যায়, যা মাঝপথেই প্রাপ্ত উচ্চতা বদলে দেয়।

২০২২ সালের সমাধান ছিল তিনটি নতুন ইউনিট: svh (small viewport height — ব্রাউজার ক্রোম পুরো দৃশ্যমান থাকা অবস্থার উচ্চতা, সবচেয়ে ছোট জায়গা), lvh (large viewport height — ক্রোম পুরো গুটানো অবস্থার উচ্চতা, সর্বাধিক জায়গা), এবং dvh (dynamic viewport height — ক্রোম দেখানো বা লুকানোর সাথে রিয়েল-টাইমে আপডেট হয়)। পূর্ণ-উচ্চতার সেকশনের জন্য min-height: 100dvh এখন সঠিক আধুনিক উত্তর। তিনটি ইউনিটই Chrome 108+, Safari 15.4+, Firefox 101+ ও Edge 108+-এ সমর্থিত, প্রোডাকশনে ব্যবহারের জন্য নিরাপদ।

vw-এর Windows-এ নিজস্ব খামখেয়ালিপনা আছে: এটি হিসাবে উল্লম্ব স্ক্রলবারের প্রস্থ অন্তর্ভুক্ত করে। দৃশ্যমান স্ক্রলবারযুক্ত পেজে width: 100vw কনটেন্ট এলাকার সামান্য বাইরে চলে গিয়ে অনুভূমিক ওভারফ্লো তৈরি করে। সমাধান হলো ব্লক এলিমেন্টে width: 100% ব্যবহার করা (যা স্বাভাবিকভাবেই স্ক্রলবার বাদ দেয়) এবং vw শুধু সেই ক্ষেত্রে রাখা যেখানে সত্যিই ডকুমেন্ট থেকে স্বাধীন ভিউপোর্ট-প্রস্থ রেফারেন্স দরকার — যেমন বড় টাইপোগ্রাফিক হেডিং যা স্ক্রিন প্রস্থ অনুসরণ করবে, font-size: clamp(1.5rem, 5vw, 4rem)-এর মতো একটি সূত্র দিয়ে যা rem ফ্লোর/সিলিংয়ের সাথে একটি তরল vw মধ্যভাগ মেলায়।