Before EasyChair and CMT took over, conference websites were hand-coded HTML. The committee page—usually committee.html or organizing.html—was the public face of peer review. It listed program committee members, area chairs, and organizing committees, and it was the primary way researchers could verify who was handling their submissions. Understanding how these pages were built, maintained, and eventually replaced reveals a fascinating chapter in the history of scientific community management.
The committee page was not a trivial listing of names. It was a carefully structured document that had to balance completeness, accuracy, and timeliness. A typical mid-2000s committee page for a conference like the International Conference on Pattern Recognition (ICPR) or the IEEE International Conference on Acoustics, Speech, and Signal Processing (ICASSP) would include several sections: General Chair, Program Chairs, Area Chairs (or Track Chairs), Technical Program Committee members, and often a separate list for reviewers. Each section was usually rendered as an HTML table with columns for name, affiliation, and sometimes a link to a personal homepage. The markup was often hand-coded, with minimal CSS, relying on browser defaults for readability.
Why Committee Pages Mattered for the Research Community
For authors submitting papers, the committee page was a tool of transparency. It allowed them to see if their potential reviewers had any obvious conflicts of interest. It also served as a directory for networking: knowing who served on the committee helped junior researchers identify influential figures in their field. For the organizers, the page was a contractual obligation—conference sponsors often required a publicly accessible list of committee members. And for historians of science, these pages now offer a snapshot of the evolving social networks in pattern recognition and computer vision.
Between 2005 and 2007, CVPR submissions jumped from 1,200 to over 1,500. Managing the review process required ever-larger program committees. A typical committee page from 2006 might list 150–200 names, spread across multiple tables. The HTML source code for such pages often became unwieldy—nested tables, inline font tags, and repetitive row structures were the norm. Yet the information was considered authoritative; many researchers printed the committee list and pinned it to their office walls.
The Anatomy of a Mid-2000s Committee HTML Page
Let’s break down the typical structure. The page began with a title and a brief description of the committee’s role. Then came a series of <table> elements, each with a header row and data rows. A common pattern was:
<table border="1" cellpadding="3" cellspacing="0" width="100%">
<caption>Program Committee</caption>
<tr><th>Name</th><th>Affiliation</th></tr>
<tr><td>John Smith</td><td>MIT</td></tr>
...
</table>Some conferences added a third column for email addresses, though this was often omitted to avoid spam harvesting. A few progressive sites used CSS to style the tables, but many relied on HTML attributes like bgcolor and width. The page footer typically included a link back to the main conference site, and sometimes a last-updated timestamp.
One notable variation was the inclusion of a “Reviewers” section separate from the committee. In the mid-2000s, many conferences began to acknowledge external reviewers by name on the committee page. This was a gesture of gratitude and also a way to encourage participation. The HTML for this section was identical in structure, but the data was often gathered via email—review coordinators would compile names from emailed review assignments and manually insert rows into the HTML file.
Maintenance Challenges and Workarounds
Keeping a committee page up-to-date was a constant struggle. Names were misspelled, affiliations changed, and people dropped out. The typical workflow involved a program chair sending a spreadsheet to a webmaster, who would then edit the HTML by hand. Mistakes were common.
Some conferences adopted a simple server-side include (SSI) to pull committee data from a text file, but this required the web server to support SSI, which was not always available. A few early adopters used PHP to generate the table from a CSV file, but PHP was still considered a “scripting language” and many academic webmasters distrusted it for static content.
The lack of a standardized format meant that archiving committee pages for future reference was difficult. The Internet Archive’s Wayback Machine captured many of these pages, but the HTML was often broken due to missing images or relative links. Researchers today who want to study the composition of mid-2000s program committees must often rely on cached versions or PDF snapshots.
The Transition to Dynamic Systems
By the late 2000s, the limitations of static committee HTML became apparent. The rise of online submission systems like Microsoft’s CMT (Conference Management Toolkit) and the open-source OpenConf changed the game. These platforms automatically generated committee pages from a database, ensuring consistency and real-time updates. The HTML output was still similar—tables with names and affiliations—but the underlying data was now centralized. Program chairs could assign reviewers, track conflicts, and generate the committee page with a single click.
Nevertheless, the static committee page did not disappear overnight. Many smaller workshops and niche conferences continued to use hand-coded HTML well into the 2010s. For these communities, the simplicity of editing a single .html file outweighed the convenience of a database-driven system. The committee page also survived as a static snapshot: after the conference, the page was often frozen to preserve the official record.
Lessons for the Modern Researcher
For those exploring the history of pattern recognition and speech research, committee HTML pages offer a unique window into the social structure of the field. They reveal who was active, which institutions dominated, and how the review process evolved. The pages also highlight the importance of good data management: the shift from static HTML to dynamic databases was driven not by a desire for fancy design, but by the need for accuracy and maintainability. Today’s conference websites are sleek and responsive, but they owe a debt to those clunky committee tables of the mid-2000s.
If you are digitizing old conference materials, pay special attention to the committee HTML files. They are often the most information-rich pages, containing names, affiliations, and sometimes even email addresses that are no longer valid. Extracting this structured data can help reconstruct the historical network of the field. And if you ever find yourself editing a committee page by hand in 2025, you are keeping a tradition alive—one that started with a simple <table> and a lot of manual effort.