Assam ASSEB HS Multimedia and Web Technology common mistakes
Assam ASSEB HS Multimedia and Web Technology · Understand the traps and how to avoid them.
Writing HTML tags in uppercase or mixing cases inconsistently (e.g., <BODY>, <P>, <Div>) and forgetting to close tags, so the page renders unpredictably and marks are lost on presentation.
Candidates learn HTML from old printed notes and from hand-written class work where case and closing tags are treated casually; browsers tolerate sloppy markup, so students never see the error and assume it is correct.
What to do instead
Adopt a fixed habit: type every tag in lowercase, close each element immediately after opening it, and self-check with the W3C Markup Validation Service before submitting any practical file. Practise writing a full page skeleton (, , , , <body>) from memory until it is automatic.</p>
Confusing internal, external and inline CSS and placing rules in the wrong context, for example writing a full <style> block inside the <body>, or linking a stylesheet with <link rel="stylesheet"> placed after </head>, so the styling does not apply.
Students memorise the three CSS types as definitions but never practise moving rules between them, so they do not build a mental model of where each belongs and in what order the browser applies them.
What to do instead
Build one small page three ways (inline, internal, external) and compare the source files side by side. Memorise the placement rule: and
Selecting the wrong CSS selector or property syntax: using a class selector when the HTML has an id (writing .header for id="header"), omitting the # or ., or writing properties without units such as width: 200, so declarations are silently ignored.
The difference between class and id is taught as a definition rather than as a matching rule, and browsers fail silently on bad CSS, so no error message ever corrects the student.
What to do instead
Drill the matching rule until it is reflexive: . matches class, # matches id, a bare name matches a tag. Always write units on lengths (px, %, em). When a style does not appear, open the browser developer tools, inspect the element, and read which declarations were struck through - this turns silent failure into visible feedback.
Writing JavaScript that references page elements before they exist, or that never runs because of a single syntax error, and being unable to locate the fault without any debugging routine.
Scripts are written top-to-bottom in without defer or a DOMContentLoaded wrapper, and students have no habit of reading the browser console, so one missing bracket or misspelled getElementById stops the whole script.
What to do instead
Adopt two fixed practices: load scripts just before (or use defer), and open the browser console on every run. Learn to read the reported line number, and use console.log to print intermediate values. Write a short form-validation script from scratch repeatedly until you can do it without referring to notes.
Mixing up client-side and server-side concepts and the roles of related technologies - for example claiming JavaScript runs on the web server, that HTML stores data, or that CSS is a programming language - and giving vague definitions of HTTP, URL, DNS and IP address.
These terms are often memorised as isolated one-line definitions from a textbook chapter, without any practical experience of what happens between typing a URL and seeing a page.
What to do instead
Learn the request-response cycle as one narrative: DNS resolves the domain to an IP, the browser sends an HTTP request to the server, the server returns HTML, CSS and JS, and the browser renders them. Place each technology on that timeline (HTML = structure, CSS = presentation, JS = behaviour in the browser). Rehearse the story aloud in under two minutes.
Describing image file formats and resolution inaccurately: treating JPEG as suitable for line art and logos, claiming GIF supports millions of colours, or confusing ppi with pixel dimensions and DPI with file size.
The topic is studied from tables of properties rather than from actually saving the same image in several formats and comparing size and quality, so the trade-offs remain abstract.
What to do instead
Run a concrete experiment: save one photograph and one logo each as JPEG, PNG and GIF at several quality settings, then record file size, visible artefacts and transparency. Build a one-page comparison table from your own results. State the rule you will write in the exam: JPEG for photographs, PNG for transparency and sharp edges, GIF for simple animation and a limited palette.
Confusing frame rate, resolution and bit depth in audio-video questions, and being unable to compute file size or justify a compression choice - for example saying a higher frame rate improves audio quality or that 24-bit refers to frame rate.
These are numerical concepts, and candidates memorise the words without ever doing the arithmetic, so any question requiring a calculation or a comparison of trade-offs collapses.
What to do instead
Practise the standard calculations until they are routine: video size = width × height × bit depth × frame rate × duration; audio size = sample rate × bit depth × channels × duration. Then explain in writing why doubling the frame rate doubles the size, and when a lower bitrate is acceptable. Do at least five worked examples with units shown at every step.
Giving tool-specific or purely descriptive answers in the multimedia authoring section - listing menu names without explaining the concept, or failing to distinguish bitmap from vector graphics, lossy from lossless compression, and authoring from editing software.
Practical classes focus on operating one application, so knowledge is tied to that software's interface instead of to the underlying principles the examiner is testing.
What to do instead
For every tool you use, write a two-line principle statement that names no menus: what it does, and how it does it. Prepare a comparison table for bitmap vs vector (resolution dependence, scaling, file size, typical formats) and lossy vs lossless. Answer past-style questions in concept-first form, then mention the tool only as an example.
Treating hosting and security as trivia: recommending free shared hosting for a project with no reason, confusing a domain registrar with a web host, and describing HTTPS, passwords or file permissions in vague or incorrect terms (e.g., 'HTTPS makes the site load faster').
These topics are usually skimmed at the end of the syllabus and are rarely practised, so candidates have no concrete model of what a host provides or what a security measure actually protects against.
What to do instead
Write a short deployment plan for your own project: choose a host type, justify it in two sentences, list the steps to upload files, and state how you would enable HTTPS and set file permissions. Learn one-line correct purposes: HTTPS encrypts traffic between browser and server; a strong password resists guessing; permissions limit who can read or write files. Practise explaining each to a classmate.
In the practical and viva, submitting a project whose source the candidate cannot explain - copied templates, uncommented code, and no ability to answer 'why did you use this tag or this script?' - and failing to demonstrate basic file organisation (index.html, separate css/js folders, working links).
Projects are often assembled quickly from downloaded code or from a friend's file, and candidates rehearse the output rather than the reasoning, so the viva exposes gaps that the working page concealed.
What to do instead
Build the project yourself in small increments and keep comments explaining each non-obvious choice. Before the viva, walk a teacher or classmate through the file structure and every script, answering 'why' for each decision. Verify that all links and image paths work from a fresh folder, that index.html is the entry point, and that you can rebuild one page from memory.