On 1/15/20, 11:42 AM, "Harbs" <[email protected]> wrote:
> What else from UIBase do they really need?
- addElement and friends.
- width/height/percent
- x/y
- Layout needs to work when acting as siblings for UIBase components (not
sure what’s required for that)
- measurement (probably related to the above)
- id
- style
- className
- parent
- alpha
- getElement and friends
- event related stuff
- visible
In fact, there’s very little not needed.
So you are saying it is a hybrid. I didn't design the HTML components, nor do
I use them much.
For example, why would the HTML components support an "alpha" property vs folks
coding "style.opacity=0"? If they never support beads, then why base on
something that does? If the goal is to quickly render existing HTML pages,
seems like you don't want to live on top of the beads infrastructure and might
want more native JS APIs.
Here’s a list of what’s not needed:
- With the possible exception of measurement, the bead logic is probably
not needed.
- model
- view
I certainly would not be in favor of making all other UIBase subclasses pay for
something these components want. You can put your null check in a subclass of
UIBase and have all HTML components subclass that.
-Alex
> On Jan 15, 2020, at 9:20 PM, Alex Harui <[email protected]> wrote:
>
>
>
> 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
>>
>
>
>
