Angular custom elements with a `type="text"` prop get styled as inputs

[brandonpittman]

Since this plugin targets [type] instead of input [type], anything in the DOM with a type attribute gets styled as an input. That's certainly not what we want.

[alexbu92]

I have the opposite problem with a Angular 10 project, inputs with type="text" aren't being styled by tailwindcss-forms. I have imported the plugin. Did you have this problem?

[ximus]

This also impacts any standard web custom element that declares a type content attribute. From my understanding of the spec, usage of type outside of inputs is not restricted.

[adamwathan]

We can't use input[type=...] because the specificity is higher than a utility, so you wouldn't be able to customize things with Tailwind classes. The only solution I can think of is to provide an alternate "strategy" via config that uses a class instead of targeting the raw elements. Happy to look at a proposal from someone who is actually affected by this issue, it's not a problem on our projects so it's not as pressing on my todo list as some things that actually are problems for me.

[brandonpittman]

@adamwathan Since it's been a minute since this problem surfaced, I just renamed the component props. I forgot all about opening this issue. If I didn't have to use Angular for work, I wouldn't think twice about Angular-related issues either.

[ximus]

@adamwathan thanks for the feedback, good catch about specificity. I was in process of writing a PR to start qualifying these rules via tag names. I'd be happy to switch gears to implement the strategy you bring up. However i'm not enough of a project and css expert to clearly imagine that ideal solution, you'd have to provide me with a rough outline of it.

Side note: Though this isn't an issue for the original reporter anymore, it remains one for the project. Maybe keep it open? This is likely going to only become more of an issue as custom elements usage grows. I expect friction over this as more users at large run into this issue. Makes me wonder if the default strategy should maybe one day change, which would suck if all need to start using classes by default ... (a little premature to start thinking about that)

[adamwathan]

Probably something like:

// tailwind.config.js 
module.exports = {
  // ...
  plugins: [
    require('@tailwindcss/forms')({ mode: 'class' })
  ]
}

I don't know what all the class names should be or anything though and don't have time to spec it out myself at the moment. Likely not something I can prioritize for at least a few months, which is why I'm looking to members of the community who are actually impacted by this to propose a solution.

Going to keep closed for now as a "no plans to fix" issue, I try to only use open issues for things we actually plan to address as maintainers. If the approach we've taken here is a deal-breaker for someone they are free to fork the library, implement the changes they need, and take on the burden of maintaining those changes themselves, much like we maintain this version of the library ourselves that meets our needs 👍🏻