You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Harbs <ha...@gmail.com> on 2020/01/15 10:19:48 UTC
empty class names
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
Re: empty class names
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 1/15/20, 11:42 AM, "Harbs" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 1/15/20, 10:47 AM, "Harbs" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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
>>
>
>
>
Re: empty class names
Posted by Harbs <ha...@gmail.com>.
> 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.
Here’s a list of what’s not needed:
- With the possible exception of measurement, the bead logic is probably not needed.
- model
- view
> On Jan 15, 2020, at 9:20 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 1/15/20, 10:47 AM, "Harbs" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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
>>
>
>
>
Re: empty class names
Posted by Carlos Rovira <ca...@apache.org>.
For me is ok to change to have just one way. I think it will be beneficial
too. Taking some code like the one I posted, what's the proposal to get the
same?
Some example code to showcase would be the best to understand
El jue., 16 ene. 2020 a las 5:38, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
>
>
> On 1/15/20, 2:20 PM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> We're already using UIBase APIs in HTML elements. Example is used in
> all
> screens in Tour De Jewel check this link [1], for an example with Pre
> tag.
>
> I understand that's how it is currently coded. I believe we are
> discussing whether that is right or not. I'm now unclear on the API goals
> for the HTML components. "usually" it is not advised to have two ways to
> do some task via the API.
>
> -Alex
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: empty class names
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 1/15/20, 2:20 PM, "Carlos Rovira" <ca...@apache.org> wrote:
We're already using UIBase APIs in HTML elements. Example is used in all
screens in Tour De Jewel check this link [1], for an example with Pre tag.
I understand that's how it is currently coded. I believe we are discussing whether that is right or not. I'm now unclear on the API goals for the HTML components. "usually" it is not advised to have two ways to do some task via the API.
-Alex
Re: empty class names
Posted by Carlos Rovira <ca...@apache.org>.
We're already using UIBase APIs in HTML elements. Example is used in all
screens in Tour De Jewel check this link [1], for an example with Pre tag.
[1]
https://github.com/apache/royale-asjs/blob/bcffaeea1d28347b554c2f5dc723dffc28bf6fce/examples/royale/TourDeJewel/src/main/royale/components/ExampleAndSourceCodeTabbedSectionContent.as#L102
El mié., 15 ene. 2020 a las 20:20, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
>
>
> On 1/15/20, 10:47 AM, "Harbs" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
> 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" <ha...@gmail.com> 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
> >
>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: empty class names
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 1/15/20, 10:47 AM, "Harbs" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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
>
Re: empty class names
Posted by Harbs <ha...@gmail.com>.
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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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
>
Re: empty class names
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@gmail.com> 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
Re: empty class names
Posted by Carlos Rovira <ca...@apache.org>.
I'm ok to do that, since I think having a clean DOM is very important and
helps at a later time when trying to debug or fix issues.
That came at a cost of a check, for sure others can argument about this is
not PAYG, but my perception is that we should apply PAYG intelligently and
not just 100% of cases without think where it can fit or not depending on
other necessities and points of view. IOW, this makes us be smarter in how
we apply principles to see all grey tones, in opposite to try to go just
Black or White.
Thanks
El mié., 15 ene. 2020 a las 11:20, Harbs (<ha...@gmail.com>) escribió:
> 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
--
Carlos Rovira
http://about.me/carlosrovira