y.st./source/pages/en/coursework/CS2205/Markup_validation.xhtml

<?php
/**
 * <https://y.st./>
 * Copyright © 2017 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'title' => 'Markup validation',
	'subtitle' => 'Written in <span title="Web Programming 1">CS 2205</span> of <a href="http://www.uopeople.edu/">University of the People</a>, finalised on 2017-09-13',
	'copyright year' => '2017',
	'body' => <<<END
<p>
	The main tool I used to use for markup validation was the $a[W3C]&apos;s <a href="https://validator.w3.org/">main validation tool</a>.
	However, that tool has some issues.
	First, it cannot load pages from servers that make use of $a[SNI].
	I&apos;m not sure why not, as servers that support $a[SNI] tend to also accept requests without it, so it baffles me that this validation tool somehow chokes when it comes to those servers.
	Second, this tool doesn&apos;t handle $a[HTML]5 or $a[HTML] 5.1, and can only validate pages written in an older version of $a[HTML] or $a[XHTML].
	Now, I instead use their experimental <a href="https://validator.w3.org/nu/">Nu validator</a>.
</p>
<h2><a href="https://validator.w3.org/nu/?useragent=Validator.nu%2FLV+http%3A%2F%2Fvalidator.w3.org%2Fservices&amp;acceptlanguage=&amp;doc=https%3A%2F%2Fwww.uopeople.edu%2F">University of the People&apos;s website</a></h2>
<p>
	Our university is teaching us the importance of Web standards, so you&apos;d think their own website would pass inspection, right?
	Nope.
	Most websites aren&apos;t properly written, and University of the People&apos;s is no exception.
</p>
<p>
	The main error present is the lack of an <code>alt</code> attribute on several <code>&lt;img/&gt;</code> tags.
	This attribute is <strong>*mandatory*</strong> for most <code>&lt;img/&gt;</code> tags.
	I thought <strong>*all*</strong> <code>&lt;img/&gt;</code> tags required it, but according to the validator, there are some cases in which they&apos;re not needed.
	However, the missing attribute in these <code>&lt;img/&gt;</code> tags isn&apos;t one of those cases; otherwise the validator wouldn&apos;t be throwing errors.
	This is a pretty common mistake made on the Web.
	Another common theme in the error list is the presence of <code>&lt;div/&gt;</code> tags nested within <code>&lt;h1/&gt;</code> and <code>&lt;h2/&gt;</code> tags.
	<code>&lt;h1/&gt;</code> and <code>&lt;h2/&gt;</code> tags are supposed to contain inline elements, not block elements, so <code>&lt;div/&gt;</code> tags don&apos;t belong there.
	Some <code>&lt;h2/&gt;</code> tags are nested within <code>&lt;span/&gt;</code> tags as well, causing more errors.
	Like <code>&lt;h1/&gt;</code> and <code>&lt;h2/&gt;</code> tags, <code>&lt;span/&gt;</code> tags contain only inline elements.
	While <code>&lt;h1/&gt;</code> and <code>&lt;h2/&gt;</code> tags <strong>*contain*</strong> inline elements, they <strong>*are*</strong> block elements, so they don&apos;t belong within a <code>&lt;span/&gt;</code> tag.
	In general, the home page of the university shows a frequent misuse of heading tags.
	A <code>&lt;style/&gt;</code> tag is also out of place, being in the <code>&lt;body/&gt;</code> instead of the <code>&lt;head/&gt;</code>.
	The <code>&lt;meta/&gt;</code> tag has an invalid <code>content</code> attribute value, and the deprecated <code>border</code> attribute is used in a couple places.
	The validator presents a few non-error warnings worth taking into consideration as well.
	The language of the document isn&apos;t specified in the <code>&lt;html/&gt;</code> tag&apos;s <code>lang</code> attribute, the page disables user zooming, and one of the headings is empty.
	In general, this is a pretty messy page.
	I will say this though: at least the page appears to be well-formed, which I wasn&apos;t expecting.
	Tags and attributes are misused and misplaced, but there are no syntax errors.
</p>
<p>
	Aside from the validator errors and warnings, I&apos;d say the main thing that doesn&apos;t work well on the page is the use of JavaScript to run the videos.
	Videos are plenty capable of running on a webpage without JavaScript, and requiring JavaScript makes the page less accessible to people with different browser set-ups.
	Other than that, the page seems to be in good working order to me.
</p>
<h2><a href="https://validator.w3.org/nu/?useragent=Validator.nu%2FLV+http%3A%2F%2Fvalidator.w3.org%2Fservices&amp;acceptlanguage=&amp;doc=http%3A%2F%2Ffloraverse.com%2F">Floraverse</a></h2>
<p>
	Floraverse is one of two comics I read, the other being one that updates so infrequently that I never know when to expect a new page.
	I wasn&apos;t expecting it, but their markup is incredibly clean.
	They do have one reoccurring error though: missing <code>alt</code> attributes on their <code>&lt;img/&gt;</code> tags.
	Again, this is an incredibly common error and most people don&apos;t seem to realise that the <code>alt</code> attribute isn&apos;t optional, but <strong>*mandatory*</strong>.
	The validator also throws out some warnings requesting heading tags be used within the <code>&lt;section/&gt;</code> elements, but these are just very good suggestions and not requirements.
</p>
<p>
	The comments section doesn&apos;t function without JavaScript, though.
	This is a big accessibility problem.
	Additionally, the heavy use of images makes non-graphical browsing of the site pointless.
	That said, it&apos;s a Web comic.
	What can you expect?
	The comments section should be cleaned up, but as for the heavy image use, it&apos;s sort of the whole point of the site.
	There&apos;s no need to fix that, aside from adding <code>alt</code> attributes where they belong.
</p>
<h2><a href="https://validator.w3.org./nu/?useragent=Validator.nu%2FLV+http%3A%2F%2Fvalidator.w3.org%2Fservices&amp;acceptlanguage=&amp;doc=https%3A%2F%2Fy.st.%2F">My own website</a></h2>
<p>
	We can&apos;t discuss website validation without considering the validation of our own websites.
	Personally, I&apos;m a stickler for standards, and as a result, my website&apos;s markup is flawless.
	In fact, every page of my website has a link in the footer to the $a[W3C] validator with the appropriate query string to tell the validator to display the validation results for that particular page.
	The validator has neither any errors nor any warnings to present.
</p>
<p>
	I also do my best to make my site incredibly accessible.
	I use a very simple layout.
	There&apos;s a little JavaScript, but the site works perfectly well without it; the JavaScript&apos;s just a navigation aid, allowing the user to use the left and right arrow keys on certain pages to load the previous and next pages, respectively.
	Even if JavaScript&apos;s disabled though, it works because actual <code>&lt;a/&gt;</code> tags are provided in the navigation menu to get to both adjacent pages (in fact, the JavaScript is set up to read the $a[URI]s from those tags to know where to send the user, so the content of those tags is identical to what the user gets from the JavaScript).
	That doesn&apos;t mean my site&apos;s without issue though.
	There are at least two problems.
	Most noticeably, the site makes use of a $a[TLS] certificate issued by a certificate &quot;authority&quot; blacklisted by Mozilla.
	Mozilla-based browsers therefore refuse to load my website at all.
	However, I can&apos;t afford a commercial $a[TLS] certificate, so I don&apos;t have any option to replace it until I find another certificate &quot;authority&quot; that gives out decent and gratis certificates.
	Most browsers offer you a way to bypass the certificate issue if you choose to, but Mozilla-based browser refuse to provide this option for websites using certificates issued by my provider.
	This is a problem in Mozilla-based browsers, not my website, and there&apos;s nothing I can do about it.
	The second issue is triggered by a bug in some browsers.
	Some browsers ignore the <code>Content-Type</code> header, and in doing so, assume my pages are written in $a[HTML] of some sort.
	They&apos;re not.
	They&apos;re written in $a[XHTML] 5.1.
	When rendered as $a[HTML], my pages appear blank; they <strong>*must*</strong> be rendered in $a[XHTML] to display their content properly.
	This is an uncommon bug though, and I&apos;ve only heard of it happening in old versions of the Links browser.
	Other browsers and newer versions of that browser don&apos;t have that problem.
</p>
END
);