Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

HI Alex, 2018-03-12 8:17 GMT+01:00 Alex Harui : > IMO some styles (padding, margin, font*) determine the "boxes", other > styles (position, display) place the boxes. I think almost the same > The layouts will likely set > position and display directly on the outer

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Hi Piotr, this issue is affecting all the code since is in basic. You can check my branch and see it yourself, If you see the html code you'll see all buttons with hardcoded style properties. What is not good at all. 2018-03-12 10:20 GMT+01:00 Piotr Zarzycki : >

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Hi Harbs, the frameworks I'm watching are MDL, Semantic and Bootstrap (all top frameworks) to see what they do in different cases and guide me to find the best way to implement the HTML Jewel should output in royale in Royale. All of this frameworks are only HTML/JS/CSS (not builds from other

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

IMO some styles (padding, margin, font*) determine the "boxes", other styles (position, display) place the boxes. The layouts will likely set position and display directly on the outer box of a component. The defaults.css in Basic should not have any styles that determine the boxes. Those

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Carlos, Does your code with mentioned issue is in jewel branch ? 2018-03-12 10:15 GMT+01:00 Carlos Rovira : > Hi Harbs, > > the frameworks I'm watching are MDL, Semantic and Bootstrap (all top > frameworks) to see what they do in different cases and guide me to find

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

2018-03-12 11:29 GMT+01:00 Harbs : > > Can you explain why you care about inline CSS? I’m not getting it. > > As I get the basis of jewel and jewel theme working right, I want to start creating blog examples with the code and I know, people out there that wants to see if we

Re: TypeNames vs ClassName

Hi, long thread and very useful read here. Since Jewel is very similar to MDL in adding/removing classes I want to comment here some things: 1.- I just changed jewel typenames to the constructor and things works ok, I could remove the createElement override 2.- I have into account the use of

Re: TypeNames vs ClassName

Hi Alex, since Piotr and Harbs seems not to be very comfortable with the change, I can subclass UIBase for Jewel and make that changes there. I don't want to conflict in such central point of the framework, Will it be ok for all of us? 2018-03-12 18:56 GMT+01:00 Alex Harui

Re: TypeNames vs ClassName

Hi Carlos, I think people are more uncomfortable with the proposal to use element.classList than any issue about order. It is hard for me to truly understand without seeing code so I think you should push it to your branch. I agree with Piotr that we can't make the users (app dev) use

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Hi Alex, no, I want the normal effect of a vertical layout, since finaly is get in both ways. The problem for me is : 1) people that wants to change it must subclass layout to modify, instead of override css rule 2) there's an excess of html code since in each component inside the layout the

Re: TypeNames vs ClassName

HI Alex, ok, I think I'll be subclassing in my branch and see where I get, in this way the Piotr and Harbs can continue with things as they expect to. In the other way, maybe it could seem that I'm worried to much about how html looks, and maybe things like the layouts can wait, but I think is

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Hi Piotr, subclass will be most to test the use of element.classList, a part from the reverse order. I think element.classList will remove the need of much code in jewel components about how to setup classes in those components 2018-03-12 19:27 GMT+01:00 Piotr Zarzycki

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Subclass, change it and remember to test as I pointed with some custom className setted in the example. See what happen. Looking forward to the results. Thanks, Piotr 2018-03-12 19:30 GMT+01:00 Carlos Rovira : > Hi Piotr, > subclass will be most to test the use of

Re: [royale-asjs] branch develop updated: Revert "Change order in computeClassNames to get typenames before classNames (just for organization purposes in html output)"

FYI: My comment was on the bit in CSSClassList. I don’t have a strong opinion on the order of the class names. > On Mar 12, 2018, at 9:06 PM, carlosrov...@apache.org wrote: > > This is an automated email from the ASF dual-hosted git repository. > > carlosrovira pushed a commit to branch

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Hi Carlos, These layout classes have worked fine for dozens of example. They are small, simple and stupid. I don't understand why, if you want vertical layout, you want to set a child's display to "inline-block". That would not layout vertically unless you are counting in line-wrapping. To

Re: TypeNames vs ClassName

If HTMLElement.classList is exposed to the user (the app developer) then they can remove any of the items that were added from the typenames. There is no way to enforce immutability of the typenames. We can choose to give up on that and require that app developers be careful, but I'd rather not.

Re: TypeNames vs ClassName

I’m pretty sure your solution will only work if the user doesn’t set a className of their own. Setting className overwrites the entire classList. > On Mar 12, 2018, at 5:45 PM, Carlos Rovira wrote: > > Hi > > I made some simplification that works ok in Jewel: > > 1.-

Re: TypeNames vs ClassName

Hi I made some simplification that works ok in Jewel: 1.- remove CSSClassList and use element.classList since is native and supported in all browsers we target, this simplifies code, and removes classes from core. 2.- I still need to use some additional code that can be simplified. I'm doing:

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Hi Carlos, As I said in my last post, you are welcome to write different layout classes. We don't all have to agree on "one right answer". There often isn't one right answer. Code up what you want to see and document why you like it. Our users will then be able to choose. We will probably

Re: TypeNames vs ClassName

Hi Piotr, I was reding from the begging and saw when the CSSClassList came. I think Harbs solution is ok, the only problem I see is that in MDL, and Jewel, we need to have functions per class that manages add/remove of classes and override of compute function. That's what I don't like of current

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

On 3/12/18, 10:11 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" wrote: >> >> I still don't get why, if your Button is a subcomponent, some framework >> code was setting display style on it unless you were using a layout

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Hi, I must say that I was wrong in some part of my argumentation. I though the problem was in UIBase setting up things like display:block, but after looking at layout code since Harbs pointed me try to duplicate it by my side I saw is the vertical layout what was setting the inline styles. For

Re: TypeNames vs ClassName

Well, it isn't fair if someone writes to element.className, but we control what happens when someone writes to UIBase.className. I just want it to be as simple as possible and PAYG. -Alex On 3/12/18, 9:21 AM, "Harbs" wrote: >I’m pretty sure your solution will only work

Re: TypeNames vs ClassName

2018-03-12 17:14 GMT+01:00 Alex Harui : > If HTMLElement.classList is exposed to the user (the app developer) then > they can remove any of the items that were added from the typenames. > There is no way to enforce immutability of the typenames. We can choose > to give

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

HI Alex 2018-03-12 17:02 GMT+01:00 Alex Harui : > Hi Carlos, > > As I said in my last post, you are welcome to write different layout > classes. We don't all have to agree on "one right answer". There often > isn't one right answer. Code up what you want to see and

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

If I would want an Vertical layout which do not affect as much your children - I would create set of layouts beads which applies FlexBox rules or Grid rules to the children. The things is that I would do this the same way - by inline styles instead of css classes. Why ? Look into my previous

Re: Experiment with UIBase change to classList

Hi Carlos, classList was not used earlier because Arrays are cumbersome in MXML. In MXML, folks can add more than one class using space delimited list of strings: In AS, folks can delete classnames via: myLabel.className="SmallFont"; I don't believe your proposal takes these scenarios into

Re: Experiment with UIBase change to classList

Carlos, I don't see in your examples things which I've asked you in the previous thread. Let me ask you once again. Please test with your code following example. 1) Create custom style. .myCustomStyle { fontSize: 12px; /// some style whatever } 2. Set in your example Compile and check

Re: Trying to remove "style" attribute set by Royale. First let's focus on style="display:block"

Hi Piotr, don't worry that was some of things I worried so much when working on MDL, and for that reason I made most of the changes I did at that moment. In Jewel I'll be doing the same ;) 2018-03-12 19:34 GMT+01:00 Piotr Zarzycki : > Subclass, change it and remember