Community
Participate
Working Groups
Since we currently have no linting / parsing errors being reported for HTML files, we should investigate using htmllint, which looks like a port of CSSLint and is backed by the htmlparser2 parser. https://github.com/htmllint We are already requesting to use htmlparser2 in bug 472412
Please use the following options for accessibility: img-req-alt label-req-for (thanks! these are exactly the 2 options I was going to code by hand! both of these are accessibility errors, and deserve a red x <g>) Also, this one looks useful for accessibility (probably should be an error, too): fig-req-figcaption Consider using: id-no-dup (this just seems like a good idea - I've seen some id dups on our rendered pages) Do we want to enforce these? html-req-lang doctype-html5
(In reply to Carolyn MacLeod from comment #1) > Please use the following options for accessibility: > img-req-alt > label-req-for > > (thanks! these are exactly the 2 options I was going to code by hand! both > of these are accessibility errors, and deserve a red x <g>) > > Also, this one looks useful for accessibility (probably should be an error, > too): > fig-req-figcaption > > Consider using: > id-no-dup (this just seems like a good idea - I've seen some id dups on our > rendered pages) > > Do we want to enforce these? > html-req-lang > doctype-html5 FYI, we would have to go through the IP process for approval to use htmllint. If the experience is similar to CSSLint/ESLint and we may not be able to use the existing rule implementations. I will open the CQ today.
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10138 I opened a CQ to start the IP Process
(In reply to Curtis Windatt from comment #3) > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10138 > I opened a CQ to start the IP Process The CQ has been approved.
Great! Can we use the options listed in comment 1?
(In reply to Carolyn MacLeod from comment #5) > Great! Can we use the options listed in comment 1? There is a big chunk of work to hook this into the Orion validation framework. However, the CQ included the rules so we can use their implementations. We will have to look at how to package the rules as we found having each rule in its own file significantly slows down load times. I don't see a built script file that includes everything (like csslint had).
*** Bug 489463 has been marked as a duplicate of this bug. ***
Just in case it doesn't work out with htmllint, the html validator mentioned in bug 489463 works pretty well from what I can see, and it's from the W3C: https://validator.w3.org/nu/about.html (just FYI).
There are number of obstacles preventing use of HTMLLint. Here are the two major ones: 1) It is all built on node require, including the rules. Browserifying the whole library results in a 886k file. 2) The following dependencies are used in HTMLLint, which the CQ likely did not consider: lodash bulk-require htmlparser2 promise Based on this I'm working on just using the rules files. We already are using htmlparser2 to create a DOM for content assist and the editor context provides access to the text and line/col data. It doesn't look like the rules have dependencies on the additional libraries, though some of the framework around them does.
Does the w3c html validator (https://validator.w3.org/nu/about.html) have a bunch of similar dependencies/obstacles? I'm not sure what to look for.
(In reply to Carolyn MacLeod from comment #10) > Does the w3c html validator (https://validator.w3.org/nu/about.html) have a > bunch of similar dependencies/obstacles? I'm not sure what to look for. The Nu validator is a relatively large (4 MB src) Java program. No way it is going to run as part of Orion client. Depending on what happens with this language server API being discussed perhaps the validation could be done on some separate server (similar to how the Flux project provides Java tooling to a browser).
(In reply to Curtis Windatt from comment #9) > It doesn't look like the > rules have dependencies on the additional libraries, though some of the > framework around them does. Some of the rules use knife.js to do some text filtering. Knife has requires on lodash and bulk-require. So to use the rules as is we would need to get legal approval. Using browserify to get the rules into a single AMD file resulted in a 680KB file (the unmodified rule source is 29K).
Created attachment 263028 [details] Simple template for html validator
Curtis, if we are going to implement this, let's set the target.
(In reply to Steve Northover from comment #14) > Curtis, if we are going to implement this, let's set the target. Investigation is definitely happening for 13. However, the investigation is leading towards NOT using htmllint.
How hard would it be to collect up a bunch of rules and write our own? (at a minimum, the ones in comment 1) Then we could: - keep it small - not need any dependencies
(In reply to Carolyn MacLeod from comment #16) > How hard would it be to collect up a bunch of rules and write our own? > (at a minimum, the ones in comment 1) > > Then we could: > - keep it small > - not need any dependencies I think this would be the best option (in light of htmllint not being that great). We already have a visitor for HTML ASTs, so we just need to hook up some rules and configuration options.
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=aa8351108fd131509e021f3a609dd41f0cd2c6fe Fixes some bugs around casing, severities and ranges Adds img-alt-req and fig-req-figcaption rules
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=d2a877a1b59a2bc6a17da030c7671e3167b5cf56 Initial validator implementation with banned-attr rule
This should have been closed after the previous commits. It is FIXED. We will add more rules incrementally.
