If that’s the case, the HTML element components need a new base class. Pretty much the entire HTML component set does not use beads and doesn’t require classes. Are you saying they shouldn’t be based on UIBase?
> On Jan 15, 2020, at 7:17 PM, Alex Harui <[email protected]> wrote: > > I would argue it is a bug for any subclass of UIBase to not have a class. > > "All" UIBase subclasses should be comprised of beads, and the beads should > have defaults overridable in the CSS. So, IMO, if you want to add a > debug-time check for no specified typenames, that's fine, but we shouldn't be > checking in release mode. > > Of course, I could be wrong... > -Alex > > On 1/15/20, 2:20 AM, "Harbs" <[email protected]> wrote: > > Currently when an element is added to a parent, the following is called: > > setClassName(computeFinalClassNames()); > > Because there’s no check there to determine if a class name was actually > set, you can end up with elements with empty class names like so: <div > class="">, <br class=“”>. > > While this has no visual effect, it does clutter up the dom markup in the > browser (and might have a non-zero effect on performance — although this is > likely minuscule). > > I’d like to get rid of the empty assignments. I can either do that in > UIBase, or in the HTML package for those classes. > > My preference is to add it to UIBase — both because I think it belongs > there and because it’s going to be very messy adding it to subclasses. The > code is in the middle of addedToParent. > > Thoughts? > Harbs >
