HTML، CSS و JavaScript هرکدام چه کاری انجام می‌دهند؟

سه اسم را به سه شعار تبدیل نکنید

هم‌تیمی شما یک feature کوچک را این‌طور توضیح می‌دهد: «HTML محتواست، CSS خوشگلش می‌کند و JavaScript منطق است.» این جمله برای شروع به‌یادماندنی است، اما به‌محض اینکه با semantic structure، responsive layout، interactionهای declarative، Web API یا server endpoint روبه‌رو شوید، مرزهایش فرو می‌ریزد.

سؤال دقیق‌تر این درس چنین است: هر concern باید در HTML، CSS، JavaScript، ترکیبی از آن‌ها، یا خارج از این سه قرار بگیرد؟ تصمیم را در Web Technology Responsibility Map v1 ثبت می‌کنید. این artifact توصیهٔ stack نیست؛ مدرکی است که نشان می‌دهد می‌توانید responsibilityها را جدا کنید، mixed case را توضیح دهید، uncertainty را حفظ کنید و server/runtime concern را داخل یک شعار front-end پنهان نکنید.

در پایان باید بتوانید یک concern محدودشده را classify کنید و هم placement و هم مرز آن را توضیح دهید.

فقط boundary لازم از WEBF-001 را همراه بیاورید

WEBF-001 prerequisite سخت این درس است. فقط boundary موردنیاز آن را نگه دارید: صفحه‌ای که Browser با آن کار می‌کند در یک سامانهٔ بزرگ‌تر navigation و Request/response قرار دارد. این درس از همان نقطه جلو می‌رود و می‌پرسد سه فناوری آشنای وب در بخش page-facing چه مسئولیتی دارند.

این صفحه implementation tutorial نیست. Framework API، accessibility implementation، performance tuning و server architecture متعلق به مراحل بعدی‌اند. همچنین این درس مالک کل WEB-000 نیست؛ WEBF-002 فقط تفکیک مسئولیت HTML/CSS/JavaScript را پوشش می‌دهد.

مدل مسئولیت

به‌جای سه شعار، چهار مقصد برای classification در نظر بگیرید:

1. HTML — ساختار و semantics سند. HTML لایهٔ markup برای نمایش ساختار محتوا و معنای سند است. بعضی رفتارهای استاندارد/declarative نیز از طریق elementهای HTML ممکن‌اند؛ هر interaction مفیدی الزاماً با custom JavaScript شروع نمی‌شود. [S-MDN-WEB] [S-WHATWG-SCRIPT]
2. CSS — presentation و layout. CSS نحوهٔ ارائهٔ سند را روی mediaهای مختلف توصیف می‌کند. این مسئولیت فقط رنگ و فونت نیست؛ layout، responsive condition، transition، animation و قواعد presentation نیز می‌توانند در این لایه باشند. [S-MDN-CSS]
3. JavaScript — رفتار برنامه‌نویسی در میزبان صفحه/Browser در این نقشه. در این نقشهٔ مسئولیتِ صفحه‌محور، مقصد JavaScript یعنی رفتاری که در میزبان صفحه یا Browser اجرا می‌شود و در صورت نیاز از DOM/Web API استفاده می‌کند. خود زبان JavaScript در محیط‌های خارج از Browser هم اجرا می‌شود؛ اما مسئولیت‌های runtime غیرBrowser یا سرور در این artifact خارج از این سه‌گانه هستند، حتی اگر با JavaScript پیاده‌سازی شده باشند. [S-MDN-JS]
4. ترکیبی یا خارج از این سه. یک قابلیت واقعی اغلب چند لایه دارد. یک فرم می‌تواند معناشناسی HTML، چیدمان CSS، enhancement سمت Browser با JavaScript و یک endpoint سرور خارج از این سه‌گانه داشته باشد. بنابراین دسته‌بندی درست همیشه «یک قابلیت = یک فناوری» نیست.

مهارت پایدار این است که بپرسید: concern چیست؟ مسئولیت پایه کجاست؟ چه لایه‌های دیگری مشارکت دارند؟ چه چیزی بیرون این مدل می‌ماند؟

effect ظاهری را classify نکنید؛ concern را classify کنید

برای هر concern یک ردیف در HTML/CSS/JavaScript Responsibility Matrix بنویسید. این Matrix جدول داخلی Web Technology Responsibility Map v1 است و artifact دوم محسوب نمی‌شود.

ستون‌ها:

• Observed concern: requirement یا رفتاری که سناریو واقعاً داده است.
• Primary responsibility: HTML، CSS، JavaScript، combination یا outside trio.
• Rationale: چرا این placement از خود concern می‌آید نه از stack موردعلاقه.
• Boundary / uncertainty: این placement چه چیزی را ثابت نمی‌کند.
• Next evidence: قبل از یک ادعای قوی‌تر چه چیزی باید بررسی یا پرسیده شود.

یک تست مفید: نام technology را از جمله حذف کنید. «layout باید با عرض صفحه تغییر کند» ابتدا یک presentation concern است؛ «داده باید روی server ثبت شود» به بیرون این trio اشاره می‌کند، حتی اگر JavaScript از سمت Browser Request را آغاز کند.

چرا boundaryها مفیدند اما مطلق نیستند؟

HTML فقط «متن روی صفحه» نیست

HTML سند را با elementهایی دارای structure و meaning نمایش می‌دهد. heading، navigation region، label، button، list یا disclosure می‌توانند semantics داشته باشند که مستقل از ظاهرند. اگر semantic structure را فقط با container عمومی و script بازسازی کنید، responsibility سند را داخل behavior code حل کرده‌اید.

CSS فقط «تزئین» نیست

CSS presentation را کنترل می‌کند. presentation شامل typography و color است، اما layout، media-dependent rule، state styling، transition و animation را هم دربرمی‌گیرد. یک layout دو ستونه که در فضای کم یک‌ستونه می‌شود می‌تواند مسئولیت CSS باشد، هرچند ظاهر صفحه در response به viewport تغییر می‌کند. [S-MDN-CSS]

JavaScript همان Browser نیست

JavaScript یک زبان برنامه‌نویسی است. در Browser با APIهای محیط میزبان، از جمله DOM و Web APIها، کار می‌کند و در محیط‌های غیرBrowser نیز می‌تواند اجرا شود. اما این واقعیت دربارهٔ زبان، مرز مکانی artifact را عوض نمی‌کند: برای مثال، کنترل مجوزی که با JavaScript روی سرور اجرا می‌شود در این نقشه OUTSIDE_TRIO است، چون مسئولیت آن بیرون از بخش صفحه/Browser قرار دارد. پس باید هویت زبان، محیط میزبان و محل مسئولیت را از هم جدا کرد. [S-MDN-JS]

هر interaction الزاماً custom JavaScript نیست

HTML mechanismهای استاندارد interactive هم دارد و HTML Standard در جای مناسب استفاده از declarative alternative را به‌جای scripting تشویق می‌کند. نتیجه «JavaScript استفاده نکنید» نیست؛ نتیجه این است که قبل از افزودن code، responsibility را درست classify کنید. [S-WHATWG-SCRIPT]

mixed responsibility طبیعی است

یک feature می‌تواند هم‌زمان چند لایه داشته باشد. requirement «profile card واکنش‌گرا که با button داده را از API به‌روزرسانی کند» می‌تواند semantic HTML، CSS layout، JavaScript behavior و یک remote service خارج از trio داشته باشد. Map باید این split را نشان دهد، نه اینکه یک owner مصنوعی بسازد.

مثال‌های متضاد

مثال ۱ — عنوان یک product card

requirement: نام محصول در structure صفحه یک heading است. مسئولیت پایه: HTML semantics/structure. CSS می‌تواند ظاهرش را عوض کند، اما styling رابطهٔ سند را ایجاد نمی‌کند.

مثال ۲ — grid با عرض موجود تغییر می‌کند

requirement: cardها در فضای زیاد چند ستون و در فضای کم یک ستون شوند. مسئولیت پایه: CSS presentation/layout. JavaScript ممکن است به دلایل دیگری layout را observe کند، اما صرف responsive بودن یک presentation rule آن را به JavaScript منتقل نمی‌کند. [S-MDN-CSS]

مثال ۳ — button یک مقدار محلی را در سند تغییر می‌دهد

requirement: input کاربر برنامه‌ای را اجرا می‌کند که state سند را می‌خواند یا تغییر می‌دهد. مسئولیت پایه: JavaScript behavior در Browser با استفاده از host API در صورت نیاز. DOM API بخشی از environment است، نه خود زبان JavaScript. [S-MDN-JS]

مثال ۴ — داده باید روی server ذخیره شود

requirement: یک عمل در Browser در نهایت server-side processing پایدار ایجاد کند. event سمت Browser می‌تواند HTML و JavaScript داشته باشد، اما پردازش سرور خارج از مدل این سه‌گانه است، حتی اگر همان پردازش با JavaScript پیاده‌سازی شده باشد. صرف اینکه JavaScript یک Request را آغاز کرده یا سرور نیز از JavaScript استفاده می‌کند، کل قابلیت انتهابه‌انتها را «JavaScript» نمی‌کند.

این مثال‌ها برای classification هستند و پاسخ آمادهٔ transfer نهایی form نیستند.

دو misconception مسدودکننده

خطا ۱ — «HTML محتواست، CSS زیبایی است، JavaScript منطق است»

مشکل این نیست که این جمله هیچ ارزش آموزشی ندارد؛ مشکل این است که nounها بیش از حد کلی‌اند. HTML structure/semantics دارد، CSS presentation rule از جمله layout و responsive behavior را بیان می‌کند و JavaScript یک programming language است که در Browser از host APIها برای رفتار استفاده می‌کند. repair بهتر، نام بردن از responsibility است نه تکرار slogan.

خطا ۲ — «اگر interactive است، پس حتماً JavaScript است»

بعضی interactionها mechanism استاندارد declarative در HTML دارند. بخش scripting استاندارد HTML نیز می‌گوید در جای مناسب alternative declarative می‌تواند ترجیح داده شود. repair این نیست که «JavaScript هرگز نزن»؛ بلکه custom JavaScript را زمانی انتخاب کن که requirement واقعاً behavior برنامه‌نویسی فراتر از mechanism مناسب declarative می‌خواهد. [S-WHATWG-SCRIPT]

اگر پاسخ شما نتواند مشخص کند چه چیزی خارج از trio است، boundary هنوز collapse شده است.

ترجمه مدل به زبان architecture review

برای learner باتجربه، labelهای ساده را به responsibility + host + evidence تبدیل کنید:

• document semantics/structure → مسئولیت HTML؛
• presentation/layout rule → مسئولیت CSS؛
• رفتار برنامه در میزبان صفحه/Browser → مسئولیت JavaScript در این نقشه؛
• DOM، Fetch، timer، storage و مشابه آن → host/Web APIهایی که JavaScript می‌تواند استفاده کند، نه خود core language؛
• ماندگاری داده، مرجع احراز هویت، کار پایگاه‌داده یا منطق کسب‌وکار سرور → بر اساس محل مسئولیت خارج از این نقشهٔ صفحه‌محور است؛ حتی اگر کد server/runtime خودش با JavaScript نوشته شده باشد.

سؤال review این می‌شود: کوچک‌ترین responsibility boundary که requirement را برآورده می‌کند چیست، بدون اینکه یک technology مالک مصنوعی کل feature شود؟

placementهای معتبر و trade-off آن‌ها

بعضی concernها بیش از یک implementation معقول دارند، اما این موضوع model پایهٔ responsibility را حذف نمی‌کند.

یک disclosure می‌تواند اگر requirement مناسب باشد از mechanism native HTML استفاده کند؛ این انتخاب می‌تواند custom scripting را کم و پایهٔ declarative را حفظ کند. اگر interaction contract فراتر از mechanism native باشد، custom JavaScript می‌تواند موجه باشد. تصمیم از requirement می‌آید، نه از یک قانون جهانی درباره برتری یک technique. [S-WHATWG-SCRIPT]

responsive layout می‌تواند در CSS بیان شود. JavaScript زمانی می‌تواند مشارکت کند که application لازم باشد به state به شکل programmatic واکنش نشان دهد؛ اما بازسازی یک presentation rule در JavaScript یک design choice است که باید justification داشته باشد، نه default پنهان.

server-rendered page هنوز می‌تواند در نتیجهٔ Browser-facing خود HTML/CSS/JavaScript داشته باشد. «HTML کجا تولید شد؟» با «HTML در document چه مسئولیتی دارد؟» دو سؤال متفاوت‌اند.

تمرین با حذف تدریجی scaffold

تمرین A — classification

این concernها را classify کنید: semantics یک heading، layout دو ستونه responsive، button که document state محلی را تغییر می‌دهد، database write و elementی که روی hover رنگش تغییر می‌کند. یک primary responsibility بدهید و participation لایه‌های دیگر را نیز یادداشت کنید.

تمرین B — repair یک overclaim

این جمله را بازنویسی کنید: «CSS فقط decoration است؛ responsive behavior واقعی باید با JavaScript باشد.» در repair خود responsibility CSS را نام ببرید و یک حالت بنویسید که JavaScript همچنان به‌صورت موجه مشارکت کند.

تمرین C — decision مستقل

یک help panel باید قبل از اجرای custom JavaScript قابل‌فهم باشد، با responsive layout صفحه هماهنگ شود و بعد از available شدن script یک enhancement اختیاری keyboard-driven بگیرد. decision rowها را خودتان بسازید؛ پاسخ مثال‌های بالا را کپی نکنید. مشخص کنید چه چیزی declarative باقی می‌ماند و چه چیزی واقعاً programmed enhancement می‌خواهد.

ترتیب حذف scaffold: filled row → responsibility label → source hint. transfer نهایی باید مستقل باشد.

evidence: Web Technology Responsibility Map v1

artifact نهایی شما HTML/CSS/JavaScript Responsibility Matrix را به‌عنوان جدول داخلی خود دارد و حداقل این فیلدها را ثبت می‌کند:

بعد از rowها حداقل دو non-claim صریح ثبت کنید. artifact نباید القا کند HTML فقط visual markup است، CSS فقط decoration است، JavaScript فقط در Browser اجرا می‌شود یا این درس کل WEB-000 را کامل می‌کند.

این درس executable coding Lab ندارد. construct مورد سنجش classification و bounded architecture reasoning است؛ اجبار به coding Lab در اینجا skill درس‌های implementation بعدی را زودتر از موعد وارد می‌کند.

assessment و transfer

پنج نوع evidence سنجیده می‌شود:

1. Retrieval: boundaryهای اصلی HTML، CSS، JavaScript و outside-the-trio را نام ببرید.
2. Application: یک concern محدودشده را classify و primary owner به‌همراه combination لازم را justify کنید.
3. Diagnosis: category collapse یک توضیح ظاهراً معقول را پیدا و repair کنید.
4. Decision: تحت constraint یک placement انتخاب کنید و بنویسید چه چیزی تصمیم را تغییر می‌دهد.
5. Transfer: form دارای semantic label، responsive styling، client validation و server submission endpoint را classify کنید و مشخص کنید کدام responsibility خارج از trio است.

Diagnosis، decision و transfer blocking هستند. stack name به‌تنهایی evidence کافی نیست. پاسخ باید reasoning، limitation و handoff boundary را در Web Technology Responsibility Map v1 نشان دهد.

sourceهای اعلام‌شده و مرز freshness

این درس فقط چهار source منجمدشده در Bible را استفاده می‌کند:

• S-MDN-WEB — MDN, How the web works: برای context سطح‌بالای fileهای وب و تفسیر آن‌ها در Browser.
• S-MDN-CSS — MDN, CSS: برای CSS به‌عنوان زبان presentation سند، از جمله layout و mechanismهای مرتبط با presentation.
• S-MDN-JS — MDN, JavaScript technologies overview: برای جداسازی core JavaScript language از DOM/Web API و hostهای غیرBrowser.
• S-WHATWG-SCRIPT — WHATWG HTML Standard, Scripting: برای scripting mechanism و caution درباره declarative alternative مناسب.

این چهار منبع رسمی/استاندارد در 2026-09-10 دوباره بررسی شدند؛ claim boundaryهای Bible همچنان قابل استفاده‌اند و source set تغییر نکرده است. review بعدی حداکثر تا 2026-12-31 لازم است یا زودتر اگر source مبنای یک claim تغییر کند.

مرز نهایی: این درس پشتهٔ فناوری جهانی پیشنهاد نمی‌کند، JavaScript را محدود به Browser نمی‌داند و مسئولیت server-side را فقط به دلیل استفاده از همان زبان داخل سه‌گانهٔ صفحه‌محور HTML/CSS/JavaScript جذب نمی‌کند.