On 1/15/20, 10:47 AM, "Harbs" <[email protected]> wrote:
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?
Yes, that makes sense to put them on some other base. What else from UIBase do
they really need? I'll bet most of the APIs are not used or should be
pass-through like "width" unless you think they should be some sort of hybrid.
They don't need typenames, explicitWidth/Height, or probably even
addedToParent().
Would be a good way to find out where we assume UIBase and not IUIBase.
-Alex
> 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
>
