Custom Elements

[eddiemonge]

Is there a way to be able to use custom HTML5 elements while still allowing "valid": true?

md-input-container.has-link
  position: relative

[PhiLhoSoft]

+1 as we use AngularJS templating, where directives can be kept as is in the HTML code. So if we have a multi-selection directive, we might want to style multi-selection.vertical for example.

We should be able to give a list of custom elements in the configuration.

Personally, I prefer to use a class for that, but I have a legacy project using this...

[renehamburger]

Defining it as a mixin in .stylintrc seems to be a possible workaround for now:

"mixins": [
  "md-input-container"
],

[eddiemonge]

Thats what I'm doing now but it gets painful having to add that for every component.

[PhiLhoSoft]

Well, you have to provide a list of valid components to have valid to work, no?

[SimenB]

Concating a user-provided list of strings with our own internal list of valid elements shouldn't be a problem. Care to provide a PR?

[SimenB]

We already do this. mixin is currently used for this purpose, but customProperties (which is an alias) might be more semantically suited.

Is there some API which would make more sense? If you ask us to validate custom elements, you have to tell us which actually are valid.

Please ping me if I'm missing something

[eddiemonge]

It'd be nice if it accepted a prefix like ng- or md-

[SimenB]

customPropertyPrefixes? And just startsWith means valid?

I don't really want built-in, non-standard stuff. User-provided prefixes should be fine though

[wojciechczerniak]

More like a wildcard described in #239. Probably a duplicate.

[SimenB]

Wildcard as part of customProperties, or its own option?

[wojciechczerniak]

A part of. Can be an option for customProperties if easier to implement or has negative performance impact if applied for every item in array but for me it looks like a config for this rule.

There is a one side effect:

⚠️ We won't be able to tell if ng-width or ng-widht is valid or typo.

We should encourage taking the time and carefully listing them all.

[SimenB]

Ok, I'm fine with that.

How do we check what's considered regexes and what's string literals, though? Just chucking it in new RegExp won't work if you want my-thing to be valid, but my-thingyling not to be.

/my-thing/.test('my-thingyling') => true. Requiring everything to be regexes (meaning if you want exact match you provide /^my-thing$/) is a non-starter IMO

[SimenB]

But custom-properties: ['error', { exactMatches: ['my-thing'], regexMatches: ['^ng-*'] }] might work though. Thoughts?

[eddiemonge]

We won't be able to tell if ng-width or ng-widht is valid or typo.

Thats fine since you could do the same thing with classes and this wouldn't catch it. It shouldn't care about property names anyway.

edit I don't think it should care if selectors are valid html or not since increasingly they are not, especially with things like web components and shadow dom. I think valid should only look at the css properties themselves, like margin, padding, etc.

[renehamburger]

Here's another quicker workaround: Just add the suffix & to custom selectors. It's a superfluous self-reference to the element that will not be reflected in the css. But it does (probably wrongly so and not for all times) suppress Stylint's error:

md-input-container&.has-link
  position: relative

[renehamburger]

Or add & before the custom selector, which will also work when the custom selector is not on the top level, e.g.:

.sidebar
  & md-input-container.has-link
    position: relative