Theory
The seat counter must live
Garba Night's card shows Seats left: 350. A registration comes in; the page must now say 349 without a reload.
That means your script needs to read what an element currently holds, compute, and write it back. Same for the register link's destination, and the search box's typed value.
jQuery covers all of it with 4 methods sharing one elegant trick: each is both the reader AND the writer, depending on how you call it.
Formula
The overload rule
No argument = GET. Argument = SET.
$("#seats").text() reads the text.
$("#seats").text("349") writes it.
One name, 2 jobs, decided by the brackets' contents. All 4 methods of this lesson follow it, and when a SET runs on a multi-element selection, it writes to every matched element at once.
At a glance
The 4 get/set methods
| Method | Works on | Get returns | Set does |
|---|---|---|---|
| text() | Element content, plain | COMBINED text of all matches | Replaces content; tags show literally |
| html() | Element content, markup | First match's inner HTML | Replaces content; tags RENDER |
| val() | Form fields (input, select) | First field's current value | Fills the field |
| attr("name") | Attributes (href, src, id...) | First match's attribute | attr("name", v) sets it on all |
Practical
The counter ticks down (complete page)
<!DOCTYPE html>
<html>
<head>
<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>
<script>
$(document).ready(function() {
$("#bookBtn").click(function() {
var seats = parseInt($("#seats").text()); // GET, then convert
if (seats > 0) {
$("#seats").text(seats - 1); // SET plain text
}
if (seats - 1 === 0) {
$("#status").html("<b>House Full!</b>"); // SET rendered markup
$("#regLink").attr("href", "waitlist.html"); // SET attribute
}
alert("Booked for: " + $("#name").val()); // GET form value
});
});
</script>
</head>
<body>
<p>Seats left: <span id="seats">350</span></p>
<p id="status">Open</p>
<input id="name" placeholder="Your name">
<button id="bookBtn">Book</button>
<a id="regLink" href="register.html">Register</a>
</body>
</html>
This example runs in Gri-Learn on the web, where you can edit it and see the output.
Theory
text vs html: the distinction with teeth
Both write content; the difference is what happens to tags in the string:
$("#status").html("<b>Full!</b>") renders Full! in bold: the browser parses the markup.
$("#status").text("<b>Full!</b>") displays the 7 characters <b>Full!</b> literally: tags become visible text.
Which to use? For YOUR OWN markup, html(). For anything a USER typed (names, comments), always text(): it cannot be tricked into injecting markup or scripts into your page. That safety habit has a security name you will meet later; build it now.
One more read: $("#seats").text() returns a String; arithmetic needs parseInt first, as the listing does.
Quiz
$("#status").text("<b>House Full!</b>") What does the visitor see inside #status?
- House Full! in bold letters
- The literal characters <b>House Full!</b>, tags visible on screen
- House Full! in normal weight: the tags are silently removed
- Nothing: text() rejects strings containing tags
Show the answer
The literal characters <b>House Full!</b>, tags visible on screen
text() treats its argument as PLAIN TEXT: every character lands as-is, so the angle brackets and b letters are displayed, not interpreted. Rendering bold (option A) is html()'s job: this pair is the exam's favourite one-word-apart comparison. Option C invents a sanitising filter neither method has: text shows tags, html obeys them, nobody deletes them. Option D imagines validation that does not exist. Choosing rule: your own markup via html(), anything user-typed via text(), always.
Think first
The get that behaves differently
Three event cards match $(".eventName"). Compare what $(".eventName").html() and $(".eventName").text() return. One of the 4 methods is the odd one out on multi-element GETS: which, and how?
Show the answer
text() is the odd one: it returns the COMBINED text of ALL matched elements, concatenated ("Garba NightCoding ContestRobo Race"). html(), val() and attr() return from the first match only. Sets are uniform (all 4 write to every match); gets are where text() breaks ranks. Practical consequence: to read ONE card's name from a set, narrow the selection first ($(".eventName:first").text()) rather than trusting the get to pick for you.
Watch out
Three manipulation bugs
Arithmetic on a get: text() and val() return Strings; "350" - 1 works by luck but "350" + 1 is "3501". parseInt first, every time (the InputBox lesson of BCA404 rhymes here).
html() with user input: a visitor typing markup into your page via an html() set is a real attack surface; text() for user content is non-negotiable.
val() vs text() on fields: an input's typed content is its VALUE; $("#name").text() reads its (empty) element content and returns nothing useful.
Theory
Read-modify-write is the whole pattern
The seat counter is the template for half of dynamic UI work: GET the current state, compute in plain JavaScript, SET the new state: 3 lines, any widget. You will reuse it verbatim when AJAX responses arrive in Unit 4 (server data lands via these same setters: responseText poured into html()). Next lesson grows the page itself: append, prepend, before and after: adding brand-new elements instead of editing existing ones.
Summary
Key takeaways
- One overload rule: no argument gets, an argument sets (sets apply to ALL matches).
- text() = plain text (sets show tags literally; multi-get returns COMBINED text of all matches).
- html() = markup (sets render tags; get reads the first match).
- val() = form-field values; attr("name") / attr("name", v) = attributes.
- Gets return Strings: parseInt before arithmetic.
- User-typed content is set with text(), never html(): no markup injection.
- Memory hook: empty brackets ask, full brackets tell.