Adding the location of the parsed file in the start-event · Issue #1317 · htmlhint/HTMLHint · GitHub
Skip to content

Adding the location of the parsed file in the start-event #1317

Open

Description

@commodis

Is your feature request related to a problem? Please describe.

Introducing HTMLHint to legacy code is quite tricky. You can either disable all failing rules or ignore the file for all HTMLHint rules.
It is impossible to implement a ratcheting system where I can prevent new commits from having faults while systematically ignoring the existing faults.

This is especially the case for custom rules, where very specific problems can be detected at a very late stage and require huge amounts of labor to fix.

Describe the solution you'd like

There must be some way to retrieve the currently parsed source code location.
With that one can add an ignored source code location list to each of the rules and ignore the specific pages.

Currently the start-event looks like this:

{
  pos: 0,
  line: 1,
  col: 1,
  type: 'start'
}

Adding the source code location would allow that implementation:

{
  pos: 0,
  line: 1,
  col: 1,
  type: 'start',
  url: '/home/text.html'
}

Describe alternatives you've considered

I tried checking every event if they contain such information but nothing was found.
I am unaware of any Node.js specific function or object to retrieve that information,
which file HTMLHint is currently working on.

Activity

  1. added
    bot:staleIssue marked as stale because there was no activity
    on Aug 12, 2023
  2. deleted a comment from stale on Aug 14, 2023
  3. added
    keep-unstaleThe issue will not be marked as stale by the stale-bot
    and removed
    bot:staleIssue marked as stale because there was no activity
    on Aug 14, 2023
  4. commodis commented on Jan 16, 2025

    @commodis
    Author

    I just read through the source code and noticed a potential path:

    1. is where the filepath is parsed and passed to verification system.
    2. adding this to the event

    Is that a feasible solution? I do not see any problems with that. I could submit a PR if it is wished.

  5. commodis commented on Apr 20, 2026

    @commodis
    Author

    @coliff is the above mentioned solution feasible? I do not see any problems with that. I could submit a PR if it is wished.

  6. coliff commented on May 14, 2026

    @coliff
    Member

    sorry for not replying sooner! I'm not too much in favour of adding this feature (as in, I don't think I'd use it myself), but if this introduces only small changes and doesn't affect how it works for anyone not using the feature then I might be okay with adding it. You are welcome to submit a PR. Thanks for your time!

  7. added 4 commits that reference this issue on May 15, 2026
    fce04e8
    8c6504a
    2395343
    a44eddd
  8. added a commit that references this issue on Sep 23, 2026
    19aeed7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    keep-unstaleThe issue will not be marked as stale by the stale-bot

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions