These aren’t errors in the sense that they break your code, but they do break standards. I’m not sure about HTML, but @gareth mentions that you can now setup linter rules (at least for JavaScript): Can I setup the linter that’s used inside the editor?
I’m not familiar enough with setting up linters from scratch but maybe that thread might help.
that thread is exclusively about js linting, and besides, the fact that I CAN configure the linter myself doesn’t mean I should be required to to have a good experience.
@nightpool is correct, the .eslint.json feature in Glitch does not handle changing the html hinting features
The hinting in question here is an opinionated choice from the HTMLHint team, and HTMLHint provides this functionality in CodeMirror (which is the editor Glitch uses). My expectation is that if Glitch were to provide a “fix” for this it would be in the form of a .eslint.json-style override - I don’t imagine that we’d want to maintain many customizations in the CodeMirror codebase, especially ones that are opinion-based.
the HTMLHint wording should be changed to make it clear this is an opinionated style lint—“should” vs “must”. I’ll make a PR for this
while I agree in the specific this is a reasonable lint to have, in GENERAL I think glitch—as a friendly, newbie oriented editor—should not shy away from making opinionated linting decisions that may fit their userbase, which is very different from the overall CodeMirror userbase.
So, just to summarize: I think “We should recommend people consistently use double quotes when authoring HTML” is a completely reasonable position for Glitch to have, but I think “We don’t want to change opinionated linting defaults to better fit our user base” is a bad argument to get you there, especially given the goals of Glitch
Ha I think I communicated the reverse of what I meant.
Personally (and I’m not speaking for the Glitch team in this case, just expressing my own opinion) I don’t agree with that default hint, but I do agree that consistency is really important (and that particular guidance is one way to get there).
As far as the defaults are concerned I take your point. I wasn’t really making an argument and my perspective was less “We don’t want to” and more “we don’t have the resources for (right now)”. Sure it’s a small code change now, but it increases complexity long-term and is one more thing that we’d have to account for in the future; that’s not to say we won’t consider it.
If you do create a PR for it I’d love to know about it.
yup as cori mentioned it’s something we want to do/look into in the future. For additional context, we’re using the default codemirror hinting rules which are definitely too aggro
This error is really annoying, especially when you make an SVG and should set a viewBox attribute or a linearGradient element.
I used to write it in lowercase because of this error but when I tried to put the code in an .svg file it didn’t work. I hope this will get fixed soon.