Everything for this course is on this page — the plan, the marking, and how to hand work in. You do not need to read all of it today.

Three channels, three purposes — using the right one gets you an answer faster:

The subject covers building the client side of a website: hypertext documents, cascading style sheets, and the JavaScript that makes a page do something. Attention is paid throughout to design, standards compliance and testing.

Rather than a series of unrelated exercises, we build one site across the semester — a browser for NASA's Astronomy Picture of the Day. Themes 1 to 8 build its structure and appearance in HTML and CSS: semantic markup, a responsive layout, forms, and a look you chose rather than inherited. Themes 9 to 16 make it work: fetching real pictures from an API, rendering them, handling events, validating input, and testing the result across browsers.

Each topic arrives when the site needs it. You will position things by hand until it becomes painful, and only then meet modern layout. You will update the page directly until it gets tangled, and only then separate the data from the display. The problem first, the tool second.

The platform carries the whole thing in two tracks that fit together: HTML ir CSS pagrindai builds the static page (weeks 1–7), and Interneto svetainių kliento dalies kūrimas makes it work (weeks 9–15). The stylesheet you write in the first carries straight into the second unchanged — the page itself gets rebuilt in JavaScript, and that is the interesting part rather than a repetition.

By the end you will be able to

• Design the structure of a website, choose appropriate interface elements, and build pages that meet web standards.
• Explain the solutions used in the client part of a site, and justify why you chose them.
• Use different elements to present different kinds of data, and keep the design of a site coherent.
• Read and change a live page from JavaScript, handle events, and work with data from an API.
• Use tools that check the correctness of page structure, and test rendering across browsers.
• Review literature on a topic in the field and present your findings to an audience.

One site, sixteen weeks. The small grey code under each week number is its theme in the approved subject description. Lesson links to the platform lesson for that week — weeks 1–7 use the HTML ir CSS pagrindai track, weeks 9–15 the Interneto svetainių kliento dalies kūrimas track; the second line is the file or folder that week adds.

The two shaded weeks are the assessed ones. On a phone, swipe the table sideways.

Assessment is cumulative. Because there is one project rather than weekly exercises, the site is assessed at two points during the semester — week 8 and week 15 — alongside your research presentation and the exam.

Practical work (P) — 50%

The largest part of your mark, and the one you build steadily. Practical tasks are set through the semester and defended — meaning you show the work running, and answer questions about how it is built and why you chose that approach. A task that works but cannot be explained is not finished.

Tasks are assessed against the requirements stated in each task. Marks are not awarded for the site looking impressive; they are awarded for meeting the requirements, using the right element for the job, and being able to justify the decision.

Your own feature

Everyone builds the same site from the same lessons. What makes yours yours is one feature nobody asked for, and it carries real weight within the practical mark.

It has to be big enough to need its own state. A restyled card or an extra colour is not enough. The test: does it need its own module, its own slice of state, its own render function and its own view? If yes, it counts — because building it means repeating everything from weeks 11 to 14 for something that does not already exist in the site.

Reasonable size, to give you the range: search by keyword across the pictures you have loaded · a saved collection that survives closing the browser · comparing two pictures side by side · a slideshow with keyboard control · filtering by media type, since the API returns video as well as images · sharing a link that opens one specific picture.

Agreed with me by week 6. Not at the end — by then your structure is settled and a new feature gets bolted on the side. Decided in week 6, it shapes how you build everything after it. If it lines up with your research topic, better still: research it, present it, then build it. Come to me with a suggestion; a proposal of your own is always better than one I hand you.

Research presentation (S) — 20%

You take one topic from the list below, read what has been written about it, and present what you found to the group in about ten minutes. In the subject description this is the literature review presentation; in practice it is closer to "go and find out how this is really done, then tell everyone."

Then you apply it to your own site. Every topic on the list is something the project needs, so the review is not a detour — you research it, present it, and the following weeks put it into your own work. That part is assessed as practical work.

Topics

Grouped by where they fit in the semester. Pick one — or propose your own in this area, which is usually a better presentation than a topic handed to you.

Layout and CSS

• Flexbox and grid — what each is actually for, and how to choose.
• Theming with custom properties — dark mode without duplicating a stylesheet.
• Container queries — layout that responds to its container rather than the screen.
• Typography on the web — scale, line length, and web fonts that cost you a second.
• CSS naming and organisation — BEM, utility classes, and why people argue about it.
• Animation and motion — transitions, and respecting prefers-reduced-motion.

Frameworks and tooling

• CSS frameworks — what Bootstrap gives you, and what it takes away.
• Tailwind and utility-first CSS — the argument for and against.
• What replaced jQuery, and what it was solving in the first place.
• State in Vue and React — how frameworks solve what we solve by hand.
• Build tools — what a bundler does, and whether you need one.
• Web components — the browser's own answer to reusable UI.

Data, storage and the network

• Client-side storage — localStorage, sessionStorage, IndexedDB, cookies.
• Handling network failure — retries, offline states, and what to show the user.
• CORS — why the browser blocks your request, and what the server has to say.
• Progressive web apps — installable sites, service workers, and the limits.
• Working with dates and time in the browser — timezones, formatting, and the traps.
• API keys in client-side code — why there is no safe way, and what people do instead.

Accessibility and quality

• What WCAG actually requires, and how much you get free from good HTML.
• Keyboard navigation and focus — using a site without a mouse.
• Screen readers — how a page is actually announced, and what ARIA is for.
• Colour and contrast — designing for the eight percent who see colour differently.
• Forms that people can actually complete — labels, errors, and autofill.
• The European Accessibility Act — what it requires of sites from 2025.

Performance, security and practice

• Responsive images — sizes, formats, and why a page is 8 MB.
• What makes a page feel fast — measuring it rather than guessing.
• Cross-site scripting in the browser — how it happens and what stops it.
• Progressive enhancement — building for the browser you did not test on.
• Browser differences in 2026 — what still varies, and how to find out.
• Testing a client-side application — what is worth automating.

Thirty topics, so in most groups everyone has their own. If two of you do want the same one, that is fine — tell each other, and present different angles rather than two summaries of the same three articles.

What is required

• At least four sources, one of which is a specification or official documentation (MDN, W3C, the framework's own docs). Blog posts count; a single blog post does not.
• Ten minutes, with something on screen, followed by questions.
• Where the sources disagree, say so. That is the most interesting part of any review and the easiest way to a high mark.
• End with one recommendation for your own site, and why.

Topic chosen by week 4. Presentations run across two lab sessions in weeks 9 and 10. What you recommended should be visible in your site by week 13.

How the 20% is made up

• 40% — presenting the work and answering questions about it.
• 30% — the review meeting the requirements above.
• 30% — your assessment of your classmates' presentations.

That last one is not a formality — it is nearly a third of this component. Attend both presentation sessions and come ready to give reasoned feedback, not a number.

Exam (E) — 30%

Open and closed questions covering every theme of the subject, ranging from recall through to analysis and evaluation. It covers the whole syllabus, not only the second half.

Late work

There is one project rather than weekly submissions, so "late" means three different things here.

Weekly tags. Push the week's tag before the next lab. A tag pushed late still counts and is still graded normally — but the tag times are how I see steady work, and a repository where every tag appears in the last fortnight will not survive the defence, because the work is not there to explain.

Milestones. Weeks 8 and 15, in the lab, with the site in front of me. If you cannot be there, email me before the lab and we arrange another time within two weeks. A milestone missed without warning is assessed from whatever is in your repository at that week's tag — which is usually worse than turning up with something half-finished and explaining it.

The presentation is the one fixed date. It runs in weeks 9 and 10 and your classmates assess it, so it cannot be moved for one person without moving it for everyone. Miss your slot without arranging it beforehand and the presenting component of S is lost. Tell me in advance and we find another slot.

The one hard limit: everything must be pushed by the end of week 15. After that I close the grading and cannot count it.

If something serious happens (illness, family, visa or travel delays), email me before the deadline and we will agree on a new date. A date agreed in advance is not late work.

AI tools

You may use Claude, ChatGPT, Copilot and similar tools — but to understand, not to do the work for you. Good use: ask the AI to explain a console error, to compare two layout approaches, or to review markup you already wrote. Bad use: paste the task in and push what comes back.

1. You must be able to explain and change every line you push. At the milestones and at the exam I will ask you to change your code in front of me, without any tools. Code you cannot explain is graded as not your work, whatever produced it.
2. It must meet the requirements of the task. AI happily produces a wall of nested <div>s with click handlers on them. It looks right in a browser and fails both the validator and a keyboard — and this course marks semantic structure, standards compliance and accessibility, not appearance.
3. Be honest. If an AI contributed materially, say so in the commit message — for example w12: fetch layer, error handling discussed with Claude. This costs you nothing.
4. The exam is written without AI tools, and the presentation must be your own reading. Practice the same way you will be tested.

These rules sit on top of VIKO's guidelines on the ethical use of AI, which apply to every course — see the faculty policy. Where this page is stricter, this page applies.

Your marks

Everything assessed appears in the Moodle gradebook for this course, under Grades in the course menu. If a mark there does not match what you expected, tell me — it is easier to fix in October than in January.

One private repository for the whole semester, named cosmos-2026. Add me as a collaborator (Settings → Collaborators → Add people, @EIF-COURSES), then fill in the registration form once. Your repository is private, so if you skip the collaborator step I cannot see your work and it cannot be graded.

cosmos-2026/
├── index.html
├── style.css
└── js/

What must never be committed

node_modules/
.DS_Store
.env              # if you put your API key in one

A NASA key is free and low-risk, but treat it as a secret anyway — the habit is what is being assessed, and in other courses the same mistake is serious.

Marking each week's state with a tag

git add .
git commit -m "w07: state layer"
git tag w07
git push --tags

A tag is a permanent name for one commit, so w07 is still reachable in January after the file has changed thirty times. Tags are how the milestones are assessed and how you show steady work.

One catch worth knowing now: git push on its own does not push tags. That is why the last line says --tags. A tag that exists only on your laptop is invisible to me.

Find your message below. Reading the error is half of fixing it — that is a skill this course teaches on purpose.

Anything else — ask in the Teams channel so everyone gets the answer, or bring it to the lab. Bring the error text and a screenshot of the Console, not "it doesn't work".

Core: the two lesson tracks on programuoki.lt — HTML ir CSS pagrindai and kliento dalies kūrimas — and MDN, which is the reference for everything in this course and is written by people who know what they are talking about.

Required (from the subject description): Duckett, HTML and CSS: Design and Build Websites (2014); Duckett, JavaScript & jQuery (2014); Robbins, Learning Web Design (2012); Verou, CSS Secrets (2015); Flanagan, JavaScript: The Definitive Guide (2011). Several are available through the college's EBSCO subscription.

Also useful: the W3C CSS specifications, the W3C validator, and the NASA API docs.

Client-side web development · Vilniaus kolegija, EIF · Contact: m.gzegozevskis@eif.viko.lt
If a link on this page is dead, tell me and I will fix it the same day. The semester plan and assessment weights may be refined at the start of the semester.