
Linting HTML using CSS - basename
https://bitsofco.de/linting-html-using-css/
======
nates
So... this:
[https://github.com/imbrianj/debugCSS](https://github.com/imbrianj/debugCSS) ?

------
oneeyedpigeon
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.

~~~
mercer
Does it affect layout if you use box-sizing: border-box;?

------
tannhaeuser
Soundly checking HTML, including all kinds of customization and more is
possible using SGML.

[1]:
[http://sgmljs.net/blog/blog1701.html](http://sgmljs.net/blog/blog1701.html)

~~~
oneeyedpigeon
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.

~~~
tannhaeuser
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.

Disclaimer: my project

~~~
oneeyedpigeon
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.

------
SpaceManiac
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.

~~~
foo123456
display:block will show them. Those elelemnts are not impossibly visible, they
are just display:none by default

------
bennettfeely
Is there a reason the * selector is needed on the first example or am I
missing something? I believe [style] { } would get the same result.

~~~
tomatsu
The '*' there has no effect whatsoever. It doesn't even change the
specificity.

------
yokohummer7

      a:not([href])  
      a[href="#"],  
      a[href=""],  
      a[href*="javascript:void(0)"] { … }
    

Wait, what should I use instead then?

~~~
jacobr
The button element should be used for interaction that is not navigation to a
different url.

~~~
jontro
What about anchors using name?

~~~
lexicality
They've been deemed obsolete with HTML5 - you should use the id attribute on
the element the <a> would be naming.

------
remy_luisant
Reminds me how some video games would use really garish default textures, so
that the errors in texturing stand out.

I believe Thief 1 and 2 have done this, but I may be wrong.

~~~
deoxxa
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.

[0]:
[https://en.wikipedia.org/wiki/Pseudolocalization#Pseudolocal...](https://en.wikipedia.org/wiki/Pseudolocalization#Pseudolocalization_in_Microsoft_Windows)

------
jwdunne
Interesting idea though I think the best choice is a VLI linting tool
configured to check these and editor integration.

You could also use JS and log the info to console. Last thing you want to do
is this making its way into production and it probably will: sods law.

I just think the most efficient approach is to log violations to a console
with exact line numbers.

------
lendk
Hi guys i already made a github repo as a follow up from this article you can
check it here: [https://github.com/lendk/Lint-HTML-with-SCSS-
CSS](https://github.com/lendk/Lint-HTML-with-SCSS-CSS)

------
nodesocket
Very cool trick. If interested, there is a node cli module which tests against
W3.

    
    
         npm install html-validator-cli -g
         cd "$HOME"/Sites/mysite
         html-validator --verbose --file=index.html

------
grav
Inline styles are what keeps my React code maintainable :-)

------
jzig
Why isn't there an HTML linter in the same way there is ESLint for JavaScript?

~~~
dredmorbius
There is _tidy_. I was going to say "but it's not kept up with standards", but
find whilst researching this comment that it _has_ been extended to HTML5.

[https://www.w3.org/People/Raggett/tidy/](https://www.w3.org/People/Raggett/tidy/)

Search shows a few other options as well:
[https://duckduckgo.com/?q=html+linter&t=ftas&ia=web](https://duckduckgo.com/?q=html+linter&t=ftas&ia=web)

Unless I'm misreading your question.

------
5_minutes
It would be nice if this was all bundled in some easy to include package

------
adzicg
broken XML leading to browsers applying inconsistent closing tags is a much
bigger issue than missing attributes or inline CSS

this kind of linting can't spot broken document structure

~~~
Xorlev
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.

------
combatentropy
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.

~~~
alanh
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.

An image without the alt attribute is not even valid HTML. Try it yourself:
[https://validator.w3.org/nu/#textarea](https://validator.w3.org/nu/#textarea)

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”

~~~
combatentropy

       > 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...](https://html.spec.whatwg.org/multipage/embedded-
content.html#alt)). 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.

~~~
matt4077
Just say you were wrong. This is embarrassing.

~~~
combatentropy
Why do you think I was wrong?

