I toyed with something similar a few years ago, although didn't pursue it to this depth. One issue, though: border is definitely not the right way to highlight elements in this manner since it affects layout. I'd go with outline instead.
You could probably also do something similar to the article, providing your document is XML-valid, using XSLT. This would keep the advantage that you just load your document in a browser (having added a temporary stylesheet link either manually or dynamically) but would support more powerful validation. It could be made into a browser extension so you're just a one-click away from validation with in-page feedback.
Of course, you can also validate XHTML using the provided DTDs if you take out the SGML-specific bits, using a (DTD-)validating XML parser (or indeed use XSLT as you say). But SGML has tag omission/inference, empty elements/HTML "void" elements, attribute short forms, unquoted attributes, Wiki syntaxes/markdown, and other features desired or even required for mere parsing mainstream HTML. As to using XHTML, I'm not sure it has a bright future. Last I've worked with it was like ten years ago (xsl-stylesheet processing instruction etc. on IE6; newer browsers don't seem to support it anymore).
FYI: SGML is way more powerful than XML, and its grammar formalism is identical to that of XML because XML was designed as a simplified subset of SGML. Though Relax NG, and also XML Schema, can theoretically express richer grammars than SGML, they can't be used for HTML due to lack of tag inference and other short syntax features, and the features that Relax NG has over SGML benefit data-oriented rather than document-oriented use cases (eg. the use cases that JSON and other serialization formats are arguably better suited for than markup in the first place IMO).
sgmljs.net can run (also) in the browser, so can also validate HTML5 in the browser.
I've had success with xhtml and xslt processing on the server-side. The fact that it's xhtml is incidental; that it's xml-valid means I can use a wealth of established tools to modify the content, and easily write my own. I don't mind too much about xml support in the browser, although I've found xslt to still be supported in chrome - e.g. for rendering RSS feeds as HTML.
Your comment sent me down a multi-hour rabbit hole.. thank you. I ended up reading a fair bit about Marcus Reichardt's initiative toward a SGML DTD for HTML5.1. However, i was unable to find a place where a tool or said DTD was available for download. Do you happen to have a link?
For now the full DTD grammar can be downloaded from the "Restrictive DTD" tab link of the full paper eg. [1] via copy/paste. I intend to be make it accessible on a permanent URL once I get more feedback/review comments. It can be processed using the venerable OpenSP/OpenJade package (install it with "sudo apt-get install opensp" on Debian/Ubuntu or "sudo port install opensp" on Mac/MacPorts; don't know the MacBrew equivalent, though). I'm using my own sgmljs SGML system (public release upcoming/pending).
This is a good choice of selectors, but I wonder what styles one should apply to <meta>, <script>, or <link> tags that will get them to actually display anything. Some fiddling in Firefox didn't reveal the solution.
It's also similar to what Microsoft does (did?) with Windows during development[0] - text that hasn't been translated yet is shown with a whole bunch of meaningless diacritical marks and replacement characters so it stands out.
The Source Engine (of Half Life and Counter Strike fame) uses a checkered black and bright pink texture for missing textures. It really is garish, as I discovered when playing Garry's Mod back in the day.
John Romero learned this in his early days at ID Software: it's crucial that you can still boot the game even when things are missing, but make them very apparent.
Sure, but lets say you have well-formed HTML tags. At that point you're looking for things semantically "weird" as opposed to structurally wrong. This helps there.
The rules for this are specified in the html5 spec. Also, some tags are not allowed to be closed, and others are only optionally closed. (like li and p)
If you have to apply CSS to find elements with inline styles, I think you have a more serious problem.
And telling everyone that every one of their images must have an alt tag is draconian. Sometimes an image is purely decorative. Sometimes an image doesn't convey any more than the paragraph beside it. Often an alt tag is written in a perfunctory way, or even when it isn't, it doesn't truly make things better for the blind person. I think they should be at the writer's discretion.
Your comment is actively harmful. You are spouting off a strong opinion that hasn't benefitted from any actual knowledge of the topic — or from actually reading the article — or from thinking about it for a more than a second.
As the article correctly states, an alt attribute should always be present; explicitly empty values signal that no alt content is needed for a screen reader.
I think it's smart that alt is required. Many of us would otherwise blithely continue on without considering accessibility. (Sadly, most of us still do, and we build tools and abstractions that "automatically" set the alt to something, be it an empty string or the file name… defeating the purpose of inviting the author to explicitly create an alt content.)
Back to your comment - if you are of the habit of shitting on ideas just to provoke a defense of them in order to ultimately learn something, I suggest you find a more constructive approach to learning… you could have googled it for 15 seconds and could have instead written, “I thought making a rule of always including alt was dumb, but I googled it and discovered that it's required by the HTML standard because x, y, and z”
> You are spouting off a strong opinion that hasn't benefitted
> from any actual knowledge of the topic
> or from thinking about it for a more than a second.
I made my first website in the late '90s and have been doing web apps for a living for over a decade. I have thought about it quite a bit over the years, and I have been on both sides of the issue.
> just to provoke a defense
I was not looking for a defense. I was trying to help others not feel guilty for not doing something that I think seldom makes a real difference. I'm thinking of most of the articles I have read, and I'm thinking of the difference to a screen reader in either case: (1) stopping to read some alt text or (2) simply silently skipping over it and just reading the article. In many cases I think it's best not to break the flow or waste the person's time.
> An image without the alt attribute is not even valid HTML.
The spec says it is for a few cases (https://html.spec.whatwg.org/multipage/embedded-content.html...). But yes, for the case I'm thinking of it insists we explicitly put alt="". I think this is tedious and overstepping its bounds. If a writer doesn't want to put alt text for one of his images, he shouldn't have to. He chose to write an article instead of doing nothing.
And I'm not really talking about being lazy. I'm talking about not wasting the reader's time. If you tell everyone it's better to put an alt tag than nothing at all, then you're going to get a lot of poorly written and annoyingly redundant alt text. If someone writes a text-based article, then it is handicap-accessible, with or without alt tags. What might be less accessible would be an article typeset with images (which is rare nowadays anyways) --- but even then, computers are so good now at deciphering images that even that might not be much of a problem either.
According to TFA, an image with no alt tag will cause some screenreaders to read the src, so a purely decorative image should instead have a null alt tag.
This makes some sense, but it occurs to me that a blind person has no way to distinguish between an image that has no alt tag because it would be meaningless, and an important image that the author simply didn't think to write an alt tag for.
alt="(Decoration)" would clear it right up and only takes a few seconds.
I like using these to diagnose what kind of lemon a client just brought for maintenance, but they can be pretty nice to ensure you got your final product right too.
