Proiect de atestat în HTML, CSS și JavaScript: ce cere comisia și cum îl construiești

Site-ul e cea mai aleasă temă de atestat, din două motive care nu se recunosc mereu: se poate începe fără să instalezi nimic și se vede imediat că merge. Amândouă sunt reale. Niciunul nu e un motiv pentru care comisia să dea o notă mare.

Pagina asta e despre diferența dintre un site care trece și unul care se notează bine — și despre cât din muncă e, de fapt, în afara codului.

Dacă încă alegi între tehnologii, pornește de la cum îți alegi tema de proiect. Cadrul general al examenului e în ghidul atestatului.

Pentru cine e potrivit

Un proiect web merge dacă:

• ai o temă cu date structurate de arătat — un catalog, o colecție, un orar, un clasament — nu doar text de prezentare;
• ești dispus să scrii JavaScript, nu doar HTML și CSS;
• îți convine să lucrezi vizual, cu rezultat imediat.

Nu merge dacă tema ta cere calcule serioase, lucru cu fișiere mari sau algoritmi — acolo o aplicație desktop e mai potrivită și se apără mai ușor în fața comisiei.

Capcana numărul unu: „doar HTML și CSS” nu e o aplicație

Asta e cea mai importantă frază din pagină.

HTML descrie conținut. CSS descrie aspect. Niciuna dintre ele nu e un limbaj de programare — n-are decizii, n-are repetiție, n-are date care se schimbă. Un proiect făcut exclusiv din HTML și CSS e un document formatat, nu un produs software.

Metodologia cere un produs software însoțit de motivarea lui teoretică. La un profil de matematică-informatică, un set de pagini statice legate prin meniu e, aproape peste tot, sub nivelul așteptat — chiar dacă arată bine.

Ce transformă un site într-o aplicație:

Nivel	Ce conține	Cum e primit
Pagini statice legate prin meniu	HTML + CSS	Insuficient la mate-info
Interacțiune reală	JavaScript: căutare, filtrare, sortare, validare, calcul	Acceptabil
Date + persistență	JS + o sursă de date (JSON) sau stocare locală	Bun
Server și bază de date	PHP + MySQL sau echivalent	Peste așteptări

Ținta rezonabilă e rândul al treilea. Un site cu date ținute separat, pe care le cauți, le filtrezi și le sortezi din JavaScript, e un proiect pe care îl poți apăra fără ezitare.

Domeniul minim viabil

Un proiect care acoperă cerințele fără să te epuizeze:

• 5–7 pagini reale, nu douăzeci pe jumătate;
• un set de date de cel puțin 20–30 de intrări, ținut într-un fișier JSON separat, nu scris de mână în HTML;
• căutare și filtrare peste setul ăla, făcute în JavaScript;
• un formular cu validare scrisă de tine, nu doar required;
• layout responsive, verificat pe telefon;
• o funcție proprie care face ceva specific temei — un calcul, un scor, o recomandare.

Ultimul punct e cel care te scoate din categoria „a descărcat un șablon”. Ceva ce nu există în niciun tutorial, pentru că ține de tema ta.

Structura fișierelor

Ordinea din proiect e primul lucru pe care îl vede evaluatorul când deschide arhiva:

proiect/
├── index.html
├── pagini/
│   ├── catalog.html
│   ├── detaliu.html
│   └── contact.html
├── css/
│   └── stil.css
├── js/
│   ├── date.js
│   ├── catalog.js
│   └── formular.js
├── date/
│   └── produse.json
├── imagini/
└── README.txt

Trei reguli care se verifică singure:

• un singur fișier CSS, nu stiluri style="..." împrăștiate prin HTML;
• JavaScript în fișiere separate, nu în <script> la sfârșitul fiecărei pagini;
• datele separate de cod — dacă adaugi o intrare nouă și trebuie să modifici un fișier .js, nu le-ai separat.

Numele fișierelor: mici, fără diacritice, fără spații. Un Catalog Final (2).html se vede din prima și spune ceva despre cum ai lucrat.

Planul pe luni

Termenul de depunere e 1 mai, iar proiectul se predă la secretariat cu referatul profesorului îndrumător. Înapoi de la data aia:

Când	Ce faci
Decembrie	Alegi tema și o discuți cu profesorul îndrumător. Scrii ce date vei avea
Ianuarie	Structura paginilor și HTML-ul static. Setul de date în JSON
Februarie	JavaScript: căutarea, filtrarea, funcția proprie
Martie	CSS final, responsive, testare pe alt calculator și pe telefon
Aprilie	Documentația și repetiția prezentării
1 mai	Depunere

Capcana reală nu e codul, e documentația lăsată pe aprilie. În aprilie nu-ți mai amintești de ce ai luat deciziile din ianuarie — și exact alea se notează. Scrie motivația și justificarea tehnologiilor când le decizi.

Ce te întreabă comisia la un proiect web

Întrebările se repetă, pentru că decurg din natura proiectului. Merită să ai răspunsul scris în documentație înainte să-l ai vorbit:

„De ce ai ales HTML și JavaScript și nu altceva?” Răspunsul slab e „pentru că știu HTML”. Cel bun leagă alegerea de temă: aplicația trebuie să fie accesibilă de pe orice dispozitiv, fără instalare, iar datele sunt puține și se pot ține local.

„Unde ții datele și de ce acolo?” Dacă răspunsul e „în HTML, pe fiecare pagină”, urmează întrebarea neplăcută: ce faci când se schimbă o valoare care apare pe cinci pagini.

„Arată-mi o funcție pe care ai scris-o tu și explică-mi-o linie cu linie.” Asta separă proiectele proprii de cele descărcate, în aproximativ treizeci de secunde.

„Ce se întâmplă dacă utilizatorul introduce altceva decât te aștepți?” De aceea formularul are nevoie de validare scrisă de tine, nu doar de atributul required.

„Ce ai face altfel dacă ai lua-o de la capăt?” Întrebare de final, aproape mereu pusă. Un răspuns concret — o limitare reală a aplicației tale — valorează mai mult decât „nimic, sunt mulțumit”.

Cum decurge proba și ce înseamnă motivarea teoretică: prezentarea proiectului în fața comisiei.

Greșeli frecvente

• Șablon descărcat, conținut schimbat. Se vede la prima întrebare despre o regulă CSS pe care n-ai scris-o. Dacă pornești de la un șablon, spune asta în documentație și arată clar ce ai adăugat tu — onestitatea declarată se notează mai bine decât o descoperire.
• Bootstrap pentru tot. Un proiect în care singurul CSS propriu e culoarea unui buton nu demonstrează că înțelegi layout-ul.
• Fără responsive. Evaluatorul deschide site-ul pe telefon. E gratis de verificat și se observă imediat.
• Linkuri care merg doar la tine. Căile absolute de tipul C:/Users/.../proiect/index.html se rup pe orice alt calculator. Folosește căi relative și testează din alt folder.
• Imagini de 4 MB. Zece poze neoptimizate fac site-ul să se încarce în zece secunde pe telefon și arată că n-ai testat niciodată în condiții reale.
• Fără diacritice. Pune <meta charset="utf-8"> și scrie corect românește — e prima impresie.
• Cod comentat lăsat înăuntru. Cincizeci de linii comentate „pentru orice eventualitate” spun că n-ai terminat.
• Nu funcționează offline. Dacă proiectul tău depinde de un CDN și în sala de examen nu e internet, nu se încarcă nimic. Descarcă bibliotecile local.

Ce livrezi, de fapt

Trei lucruri, nu unul:

1. Aplicația — folderul cu tot ce trebuie ca să ruleze pe alt calculator;
2. Documentația — pe capitole, cu motivația și justificarea tehnologiilor;
3. Prezentarea — maximum 30 de minute, în care explici de ce, nu doar ce.

Tehnicile de Word de care ai nevoie la documentație — stiluri, cuprins automat, legende la figuri — sunt aceleași care se cer și la proba practică: formatarea documentelor în Word.

Întrebări frecvente

Pot face atestatul doar din HTML și CSS? Formal, depinde de ce acceptă catedra liceului tău. Practic, la profilul de matematică-informatică un proiect fără nicio componentă de programare e considerat aproape peste tot sub nivelul așteptat, pentru că HTML și CSS nu sunt limbaje de programare. Adaugă JavaScript.

Câte pagini trebuie să aibă site-ul? Nu există un număr impus de metodologie. Cinci-șapte pagini bine făcute se apără mai ușor decât douăzeci neterminate. Contează ce face aplicația, nu câte fișiere are.

Pot folosi Bootstrap sau alt framework CSS? Da, și nu e o problemă dacă declari asta în documentație. Devine o problemă când tot CSS-ul proiectului vine de acolo și nu poți explica nicio regulă de layout.

Am voie să pornesc de la un șablon găsit pe internet? Regula o stabilește profesorul îndrumător. În toate cazurile, sursa se citează în documentație și trebuie să poți arăta clar ce ai modificat și ce ai adăugat tu.

Trebuie să pun site-ul online? Nu. Proiectul se prezintă local, de pe calculatorul din sala de examen. Asigură-te că funcționează fără conexiune la internet, cu căi relative și bibliotecile descărcate local.

Ce fac dacă aplicația nu pornește pe calculatorul din sală? De aceea documentația are un capitol de instalare și rulare, iar tu ai o copie pe stick și una în cloud. Testează pe alt calculator cu cel puțin o săptămână înainte.

Se poate folosi JavaScript cu o bază de date? Nu direct din browser. Pentru bază de date reală ai nevoie de partea de server, deci de PHP și MySQL sau echivalent. Pentru un proiect de atestat, un fișier JSON cu datele e suficient și se justifică ușor.

De unde vin informațiile de aici

Cerința ca proiectul să fie un produs software însoțit de prezentarea și motivarea teoretică, termenul de depunere de 1 mai și referatul profesorului îndrumător finalizat cu admis sau respins sunt din Metodologia de organizare și desfășurare a examenului de atestare a competențelor profesionale ale absolvenților claselor de matematică-informatică și matematică-informatică, intensiv informatică, aprobată prin OMECI nr. 4.843/2009 și modificată prin OM nr. 3.009/2021.

Nivelul tehnic așteptat, numărul de pagini, tehnologiile permise și criteriile de notare nu sunt prevăzute în metodologie — se stabilesc de catedra de specialitate a liceului tău. Recomandările de aici sunt un punct de plecare pentru cazul în care nu ți s-a impus un format. Verifică întotdeauna cerința profesorului îndrumător.