Hi Alex,

to recete the classList you can do className = "" and reenter typeNames and
classNames
I think is the only way, then you can continue doing add/remove/toggle
though classList.

In your example you're still thinking in className mode, you can do easily
with classList.remove('Piotr'')





2018-03-14 0:07 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:

>
>
> On 3/13/18, 3:16 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>
> >Hi Alex,
> >
> >2018-03-13 19:20 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
> >
> >> Hi Carlos,
> >>
> >> I took a quick look.
> >>
> >> 1) I don't see how if the user did:
> >>
> >> myComp.className = "Carlos";
> >> myComp.className = "";
> >>
> >>
> >Right this case is missing, we need to add it, but seems simple since is
> >deal with value == ""
>
> Carlos, that was a simple example.  What about:
>
> myComp.className = "Carlos Piotr Alex";
> myComp.className = "Carlos Alex";
>
> The "Piotr" class would need to be removed.
>
> >
> >
> >> That 'Carlos' would be removed from the classList.
> >>
> >> 2) I still don't like that we are calling split and apply on classList
> >> even for simple assignment of a single className
> >>
> >> 3) I don't like that as we aggregate typeNames that we will reset
> >> className to "" and call split more than once.  Not to mention the
> >> overhead of the extra function calls now that typeNames is not a var and
> >> now a getter/setter.
> >>
> >
> >ok
> >
> >>
> >>
> >> That said, I also took another look at the Basic UIBase code and don't
> >> like it either.  Seems like it could be optimized as well and have
> >> setClassName call computeFinalClassNames.
> >>
> >> Regarding performance.  I think the key issue is that every change to
> >> element.className or element.classList can cause a DOM update, so you
> >> don't want to change element.className or element.classList more than
> >>once
> >> during the initialization of the component.  I didn't watch the videos
> >>you
> >> linked to, but in the first link to a blog post, that person was just
> >> replacing a one-time setting of className to a string with a call to
> >> classList.add.  But his code is probably pre-parsed into the parameter
> >> list to classList.add.  We have to compute it from a String.split.  And
> >> the current code you have proposed is going to change classList several
> >> times as we aggregate typeNames.  That doesn't seem right.
> >>
> >
> >I think the video is short and explained very well. I think is good to
> >review it
> >
> >But I think is ok to change my code to get a better performant one. Mine
> >was created only to see
> >it works, now we need to tune depending on the different entry points as
> >you say
> >
> >
> >> If you want to use classList everywhere, I think we'd have to shadow it
> >> with an array so we only set the array of strings on classList as
> >>needed,
> >> but classList isn't set up to do a full replacement, AFAICT.
> >>
> >> IMO, if you want to continue to pursue use of classList, you would focus
> >> on just replacing computeFinalClassNames and/or setClassName with
> >> classList handling and see how it looks.  Leave typeNames as a var and
> >>let
> >> it aggregate without touching classList.  UIBase will eventually call
> >> setClassName in addedToParent.  That is the point in the lifecycle where
> >> the user might have set some classNames and the typeNames have been
> >> aggregated and maybe "fab" or "primary" has been set as well.  Either
> >>you
> >> track everything in a shadow array or you do one big split then.
> >>
> >> Do we know if you set className then read classList, doesn't classList
> >> represent the things set in className?  If that's the case, then in
> >> MDL/Jewel, "fab" and "primary" should just check to see if addedToParent
> >> has been called and the classNames/classList has been stuffed and if it
> >> has, just call classList.toggle.
> >>
> >> However, IMO, the simplest solution should be to leave UIBase as is.
> >>MDL
> >> and Jewel should just have to override computeFinalClassNames to include
> >> adding "fab"/"primary" to the final set of strings.  I don't understand
> >> why other work would be needed.  But the "fab"/"primary" getter setters
> >> should be able to call classList.toggle instead of
> >>computeFinalClassNames
> >> and/or setClassName.
> >>
> >> If you want to separately prove that it is faster to call String.split()
> >> and set classList instead of passing the space-delimited strings to
> >> className, that's fine too.  The difference for us vs the link you
> >>posted
> >> is that we MUST start with space-delimited strings coming from the MXML,
> >> so at least one split() call is required.
> >>
> >
> >I spend some hours trying and
> >* change typeNames to only one var again, then in addToParent I reset the
> >className, I think this solves the problem of using typeNames lots of
> >times
> >and call split and apply lots of times
> >* I tried to create again a computedFinalClassNames to handle classList.
> >* The only problem I see is that if don't see any way to avoid call split
> >and apply each time you call setClassName since a compute final is needed.
> >Or I'm missing something?
>
> Not sure. I was wondering if you could track which elements in the array
> belong to typeNames so that portion doesn't need to be re-split.  I really
> don't know.  Like maybe when typeNames is first split, remember the number
> of elements in the split.
>
> HTH,
> -Alex
> >
> >Maybe could be good that you write some code (pseudo code) here better to
> >explain what you propose
> >since I don't know if I'm understanding your phrases accurately
> >
> >It's time for me to go to sleep, tomorrow I'll check if you posted
> >something to try it
> >
> >thanks!
> >
> >
> >>
> >> Of course, I could be missing something...
> >> -Alex
> >>
> >> On 3/13/18, 10:30 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
> >>
> >> >Hi Alex,
> >> >
> >> >right, I tested it in JewelExample. If you find something that does not
> >> >conform to what you thinked please let me know to address it.
> >> >I think it should not be very difficult to handle some isolated case
> >>with
> >> >what we have
> >> >
> >> >thanks
> >> >
> >> >
> >> >
> >> >2018-03-13 18:24 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
> >> >
> >> >> Hi Carlos,
> >> >>
> >> >> Just so I'm clear, you believe that UIBase.as in the jewel-ui-set
> >>branch
> >> >> addresses all of these issues?  I've just been watching commits, so
> >>if
> >> >>you
> >> >> think that's the case then I will look at the current state of your
> >> >>UIBase.
> >> >>
> >> >> Thanks,
> >> >> -Alex
> >> >>
> >> >> On 3/13/18, 10:14 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >> >>Rovira"
> >> >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org>
> wrote:
> >> >>
> >> >> >Hi Alex,
> >> >> >
> >> >> >2018-03-13 17:50 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
> >> >> >
> >> >> >> Hi Carlos,
> >> >> >>
> >> >> >> I do not think you are considering all of the scenarios in your
> >> >>proposed
> >> >> >> code.  I'm sad that I have to delineate them again, but I will
> >>try.
> >> >> >>
> >> >> >> 1) In Basic there are two sets of strings:  The fixed set from
> >> >>typeNames
> >> >> >> that should "never" change.  And the className set from the user
> >>that
> >> >> >>can
> >> >> >> not only add, but also remove a set of HTML classes.
> >> >> >>
> >> >> >>
> >> >> >I see the next email so I respond to this in the following, I solved
> >> >>that
> >> >> >and explain later
> >> >> >
> >> >> >
> >> >> >> 2) In MDL and I guess Jewel, there is a third set.  They are tied
> >>to
> >> >> >> properties like you said.  "fab" and "primary", and things like
> >>that.
> >> >> >>
> >> >> >
> >> >> >Yes this will be the normal case in users. People using Jewel or
> >>other
> >> >>UI
> >> >> >set with look and feel will
> >> >> >use properties as their normal basis in the same way they do now in
> >>MDL
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> 3) For PAYG reasons, it would be great if Basic did not have to
> >> >> >> contemplate the third set.
> >> >> >>
> >> >> >> 4) For PAYG reasons, it would be nice if Basic did not have to
> >>assume
> >> >> >> conversion to array and call split().  The current code in the
> >> >>develop
> >> >> >> branch lets the browser do the split() in native code.
> >> >> >>
> >> >> >
> >> >> >for 3 and 4 what's the best way to left UIBase untouched so I can
> >>use
> >> >>my
> >> >> >code in Jewel?
> >> >> >Is the actual way of duplicating the code for UIBase in my own
> >>library
> >> >>the
> >> >> >best way?
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> Then, as a performance consideration, Harbs claims that changing
> >> >> >>classList
> >> >> >> is expensive.
> >> >> >>
> >> >> >
> >> >> >I don't will say that there's a low performance, but my guess is
> >>that
> >> >>is
> >> >> >nothing that we should have in consideration, but we can discuss it
> >> >>later.
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> So, your proposed solution MUST allow the user to delete/remove
> >>any
> >> >> >> strings they added without removing strings added from typeNames
> >>or
> >> >>from
> >> >> >> the "fab"/"primary" properties.
> >> >> >
> >> >> >
> >> >> >That's now working
> >> >> >
> >> >> >
> >> >> >> And allow add/remove of the user's
> >> >> >> strings before or after changing properties like "fab" and
> >>"primary".
> >> >> >>
> >> >> >
> >> >> >as we are dealing with a collection this is working and only one
> >>copy
> >> >>of
> >> >> >the string is maintained and outputted, I think in this way
> >> >> >less errors of this kind should happen
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> Show us how that will work.  I'm pretty sure it is possible.
> >>Then we
> >> >> >>will
> >> >> >> debate the performance aspects.
> >> >> >>
> >> >> >
> >> >> >I have it right now completely working in my branch, so it's a
> >>matter
> >> >>to
> >> >> >try it in JewelExample
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> Thanks,
> >> >> >> -Alex
> >> >> >>
> >> >> >> On 3/13/18, 6:49 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >> >> >>Rovira"
> >> >> >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org>
> >> wrote:
> >> >> >>
> >> >> >> >So, you if is == you expect that setting className in royale you
> >> >>remove
> >> >> >> >all
> >> >> >> >inclusive typeNames?
> >> >> >> >Harbs, className is not equal to class in HTML
> >> >> >> >
> >> >> >> >2018-03-13 14:08 GMT+01:00 Harbs <harbs.li...@gmail.com>:
> >> >> >> >
> >> >> >> >> className in Royale == class in HTML.
> >> >> >> >>
> >> >> >> >> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira
> >> >> >><carlosrov...@apache.org>
> >> >> >> >> wrote:
> >> >> >> >> >
> >> >> >> >> > I think we're getting to the point in this discussion.
> >> >> >> >> >
> >> >> >> >> > For me as a user, I expect to use className property to
> >>"add",
> >> >>and
> >> >> >>not
> >> >> >> >> > override all I have
> >> >> >> >> > for that reason in MDL and now in Royale we decided to create
> >> >> >> >>properties
> >> >> >> >> > (that use to be boolean) like "primary" or in MDL "fab" to
> >>add
> >> >>or
> >> >> >> >>remove
> >> >> >> >> > those properties (since are library properties that are
> >>managed
> >> >> >> >> > specifically).
> >> >> >> >> > I don't want to set primary and then className removes that!
> >>I
> >> >> >>think
> >> >> >> >>that
> >> >> >> >> > function is not right and will be the cause of many problems.
> >> >> >> >> >
> >> >> >> >> > If the user wants to remove all class names, he can do with a
> >> >> >>method
> >> >> >> >>that
> >> >> >> >> > callls element.classList.remove, but the behavior by default
> >> >> >> >>shouldn't be
> >> >> >> >> > to use className to get rid of all what we have.
> >> >> >> >> >
> >> >> >> >> > If you work with html directly , is normal to write
> >> >>class="class1
> >> >> >> >>class2
> >> >> >> >> > ..." and create from scratch
> >> >> >> >> >
> >> >> >> >> > in Royale you write mxml and as3 and use className to add
> >> >> >>additional
> >> >> >> >> > classes that are not in the api but not to remove the ones
> >>the
> >> >> >> >>component
> >> >> >> >> > set plus the ones the user "switched" on/off due to
> >>properties
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > 2018-03-13 13:42 GMT+01:00 Harbs <harbs.li...@gmail.com>:
> >> >> >> >> >
> >> >> >> >> >> No. className is supposed to *replace* the entire classList
> >> >>minus
> >> >> >>the
> >> >> >> >> >> internally managed ones (i.e. typeNames). Your code
> >>drastically
> >> >> >> >>changes
> >> >> >> >> the
> >> >> >> >> >> current behavior.
> >> >> >> >> >>
> >> >> >> >> >> You cannot use add for that and replacing the classList will
> >> >> >>destroy
> >> >> >> >> your
> >> >> >> >> >> custom class names.
> >> >> >> >> >>
> >> >> >> >> >>> On Mar 13, 2018, at 2:34 PM, Carlos Rovira
> >> >> >><carlosrov...@apache.org
> >> >> >> >
> >> >> >> >> >> wrote:
> >> >> >> >> >>>
> >> >> >> >> >>> Solving the multiple string value problem:
> >> >> >> >> >>>
> >> >> >> >> >>> This: <j:TextButton text="PRIMARY" className="myCustomStyle
> >> >>some
> >> >> >> >>other"
> >> >> >> >> >>> primary="true"/>
> >> >> >> >> >>>
> >> >> >> >> >>> *<button type="button" class="jewel button textbutton
> >> >> >>myCustomStyle
> >> >> >> >> some
> >> >> >> >> >>> other primary" style="margin: 10px 0px 0px; display:
> >> >> >> >> >>> block;">PRIMARY</button>*
> >> >> >> >> >>>
> >> >> >> >> >>> with this change
> >> >> >> >> >>>
> >> >> >> >> >>> COMPILE::JS
> >> >> >> >> >>> protected function setClassName(value:String):void
> >> >> >> >> >>> {
> >> >> >> >> >>> var classes:Array = value.split(" ");
> >> >> >> >> >>> element.classList.add.apply(element.classList, classes);
> >> >> >> >> >>> }
> >> >> >> >> >>>
> >> >> >> >> >>> I think this was all the problems we have right?
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >> >>> 2018-03-13 13:20 GMT+01:00 Carlos Rovira
> >> >> >><carlosrov...@apache.org>:
> >> >> >> >> >>>
> >> >> >> >> >>>> Hi Piotr,
> >> >> >> >> >>>>
> >> >> >> >> >>>> that's one of the advantages of a collection, order
> >>doesn't
> >> >> >> >>matter! :)
> >> >> >> >> >>>>
> >> >> >> >> >>>> <j:TextButton text="PRIMARY" className="myCustomStyle"
> >> >> >> >> primary="true"/>
> >> >> >> >> >>>>
> >> >> >> >> >>>> output:
> >> >> >> >> >>>>
> >> >> >> >> >>>> *<button type="button" class="jewel button textbutton
> >> >> >>myCustomStyle
> >> >> >> >> >>>> primary" style="margin: 10px 0px 0px; display:
> >> >> >> >> block;">PRIMARY</button>*
> >> >> >> >> >>>>
> >> >> >> >> >>>> this is one of the reason to change, since you'll end
> >>trying
> >> >>to
> >> >> >> >>figure
> >> >> >> >> >>>> what comes in first or not.
> >> >> >> >> >>>>
> >> >> >> >> >>>> Do you need more evidence?
> >> >> >> >> >>>>
> >> >> >> >> >>>> Thanks
> >> >> >> >> >>>>
> >> >> >> >> >>>>
> >> >> >> >> >>>> 2018-03-13 12:48 GMT+01:00 Piotr Zarzycki
> >> >> >> >><piotrzarzyck...@gmail.com
> >> >> >> >> >:
> >> >> >> >> >>>>
> >> >> >> >> >>>>> In my example orders matters. Setup first className than
> >> >>your
> >> >> >> >> property.
> >> >> >> >> >>>>>
> >> >> >> >> >>>>>
> >> >> >> >> >>>>> On Tue, Mar 13, 2018, 12:39 Harbs <harbs.li...@gmail.com
> >
> >> >> >>wrote:
> >> >> >> >> >>>>>
> >> >> >> >> >>>>>> Hi Carlos,
> >> >> >> >> >>>>>>
> >> >> >> >> >>>>>> I definitely appreciate the work you are doing. I’m
> >>swamped
> >> >> >>with
> >> >> >> >> work
> >> >> >> >> >>>>>> right now, so I don’t have the time to spend helping
> >>you.
> >> >> >>(Sorry
> >> >> >> >> about
> >> >> >> >> >>>>>> that.) :-(
> >> >> >> >> >>>>>>
> >> >> >> >> >>>>>> I think the discussions here are about pretty minor
> >>points.
> >> >> >>You
> >> >> >> >>can
> >> >> >> >> >>>>>> certainly implement jewel how you think makes sense,
> >>but if
> >> >> >>you
> >> >> >> >>want
> >> >> >> >> >> to
> >> >> >> >> >>>>>> make changes to basic in areas which are not broken,
> >>there
> >> >> >>needs
> >> >> >> >>to
> >> >> >> >> >> be a
> >> >> >> >> >>>>>> really good reason to do so.
> >> >> >> >> >>>>>>
> >> >> >> >> >>>>>> My $0.02,
> >> >> >> >> >>>>>> Harbs
> >> >> >> >> >>>>>>> On Mar 13, 2018, at 1:31 PM, Carlos Rovira <
> >> >> >> >> carlosrov...@apache.org>
> >> >> >> >> >>>>>> wrote:
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>> Hi Piotr,
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>> thanks for your words, but is difficult to work on
> >> >>something
> >> >> >> >>when
> >> >> >> >> you
> >> >> >> >> >>>>>>> believe in your vision and others no, and more over
> >>when
> >> >>all
> >> >> >>the
> >> >> >> >> >> facts
> >> >> >> >> >>>>>> you
> >> >> >> >> >>>>>>> see corroborates that vision. It's difficult to
> >>maintain
> >> >>live
> >> >> >> >>the
> >> >> >> >> >>>>> moto in
> >> >> >> >> >>>>>>> that scenario.
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>> but anyway for you Kindly words
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>> Carlos
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>> 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki <
> >> >> >> >> piotrzarzyck...@gmail.com
> >> >> >> >> >>>>>> :
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>>> Carlos,
> >> >> >> >> >>>>>>>>
> >> >> >> >> >>>>>>>> In my opinion you are not facing the wall from US. You
> >> >>are
> >> >> >> >>facing
> >> >> >> >> >> the
> >> >> >> >> >>>>>> wall
> >> >> >> >> >>>>>>>> from lack of volounteers who can help, do the job.
> >> >> >> >> >>>>>>>> Believe me your Jewel effort in my list of tasks is
> >> >>almost
> >> >> >>on
> >> >> >> >>the
> >> >> >> >> >>>>> Top. I
> >> >> >> >> >>>>>>>> have to fiinish planned work in TranspiledActionScript
> >> >>first
> >> >> >> >>and I
> >> >> >> >> >>>>> hope
> >> >> >> >> >>>>>> to
> >> >> >> >> >>>>>>>> join.
> >> >> >> >> >>>>>>>>
> >> >> >> >> >>>>>>>> When it will be - maybe in couple of weeks. In the end
> >> >> >> >>something
> >> >> >> >> >>>>> have to
> >> >> >> >> >>>>>>>> pay the bills and Royale is only fraction of that.
> >> >> >> >> >>>>>>>>
> >> >> >> >> >>>>>>>> I contribute in other related areas. I Wish I could
> >> >> >>contribute
> >> >> >> >>in
> >> >> >> >> >>>>> your
> >> >> >> >> >>>>>> way
> >> >> >> >> >>>>>>>> or Alex and Peter.
> >> >> >> >> >>>>>>>>
> >> >> >> >> >>>>>>>> Thanks for your work!
> >> >> >> >> >>>>>>>> Piotr
> >> >> >> >> >>>>>>>>
> >> >> >> >> >>>>>>>> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki <
> >> >> >> >> >>>>> piotrzarzyck...@gmail.com>
> >> >> >> >> >>>>>>>> wrote:
> >> >> >> >> >>>>>>>>
> >> >> >> >> >>>>>>>>> I personally said - Go and try, report back. I have
> >>gave
> >> >> >>you
> >> >> >> >>an
> >> >> >> >> >> real
> >> >> >> >> >>>>>>>> world
> >> >> >> >> >>>>>>>>> examples where classList failed. Try and post the
> >> >>results.
> >> >> >> >> >>>>>>>>>
> >> >> >> >> >>>>>>>>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira <
> >> >> >> >> carlosrov...@apache.org
> >> >> >> >> >>> :
> >> >> >> >> >>>>>>>>>
> >> >> >> >> >>>>>>>>>> Hi,
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>> it's very hard to me to invest lot of time both in
> >> >>tryin
> >> >> >>to
> >> >> >> >> >> develop
> >> >> >> >> >>>>>>>>>> something useful in the look and feel field for us
> >> >>where
> >> >> >>no
> >> >> >> >> other
> >> >> >> >> >>>>> is
> >> >> >> >> >>>>>>>> doing
> >> >> >> >> >>>>>>>>>> work, trying to explain and discuss all issues I
> >>find
> >> >> >>without
> >> >> >> >> get
> >> >> >> >> >>>>> any
> >> >> >> >> >>>>>>>>>> traction. It's like to face a wall all the time.
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>> Maybe I'm wrong with my proposals but other times my
> >> >> >> >>perception
> >> >> >> >> is
> >> >> >> >> >>>>>> that
> >> >> >> >> >>>>>>>>>> things are settled in a particular way
> >> >> >> >> >>>>>>>>>> and we don't want to change it since is working in
> >>the
> >> >> >> >>current
> >> >> >> >> >>>>> state.
> >> >> >> >> >>>>>>>> But
> >> >> >> >> >>>>>>>>>> I
> >> >> >> >> >>>>>>>>>> think we always where thinking of change things as
> >>we
> >> >> >>evolve
> >> >> >> >> >>>>> Royale.
> >> >> >> >> >>>>>>>> We're
> >> >> >> >> >>>>>>>>>> in a 0.9.2 release, we're not in 1.0, but the way
> >>we're
> >> >> >> >>managing
> >> >> >> >> >>>>> all
> >> >> >> >> >>>>>>>>>> issues
> >> >> >> >> >>>>>>>>>> seems to
> >> >> >> >> >>>>>>>>>> me that we're fine with what we have now and we are
> >> >> >>freezing
> >> >> >> >>the
> >> >> >> >> >>>>> API.
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>> In all the issues raised last days only CSS compiler
> >> >> >>errors
> >> >> >> >>are
> >> >> >> >> >>>>> real
> >> >> >> >> >>>>>>>> bugs,
> >> >> >> >> >>>>>>>>>> since without that fixes royale can't output
> >>concrete
> >> >>CSS
> >> >> >> >>rules
> >> >> >> >> (I
> >> >> >> >> >>>>>> think
> >> >> >> >> >>>>>>>>>> those not require any discussion)
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>> The font injection is maybe another bug (don't know
> >> >>why a
> >> >> >> >>class
> >> >> >> >> in
> >> >> >> >> >>>>> a
> >> >> >> >> >>>>>>>> theme
> >> >> >> >> >>>>>>>>>> is not "visible" by the final app), but can be
> >> >> >>workarounded
> >> >> >> >>with
> >> >> >> >> >> an
> >> >> >> >> >>>>>> html
> >> >> >> >> >>>>>>>>>> that setup the font for now.
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>> Things like classNames discussion are not critical
> >>(I
> >> >> >>know),
> >> >> >> >> it's
> >> >> >> >> >>>>>> just a
> >> >> >> >> >>>>>>>>>> matter to refine the API since I had problems each
> >> >>time I
> >> >> >>go
> >> >> >> >> that
> >> >> >> >> >>>>>> path,
> >> >> >> >> >>>>>>>>>> first with MDL and now with Jewel. Maybe I'm the
> >>only
> >> >>one
> >> >> >> >>since
> >> >> >> >> no
> >> >> >> >> >>>>>> other
> >> >> >> >> >>>>>>>>>> has tried what I'm trying to do: Creating Themes.
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>> In my opinion, give the users only a way to manage
> >> >> >>classNames
> >> >> >> >> vía
> >> >> >> >> >>>>>>>> string,
> >> >> >> >> >>>>>>>>>> is insufficient and cumbersome and deserves at a
> >> >>minimun
> >> >> >>some
> >> >> >> >> API
> >> >> >> >> >>>>>>>> methods
> >> >> >> >> >>>>>>>>>> since is an important point in how UI is stylized,
> >>and
> >> >>how
> >> >> >> >> >> controls
> >> >> >> >> >>>>>> and
> >> >> >> >> >>>>>>>>>> objects in html can be "extended" or diferenciated
> >> >>(Alex
> >> >> >> >> explained
> >> >> >> >> >>>>>> very
> >> >> >> >> >>>>>>>>>> well the importance of this in the typenames
> >>thread).
> >> >>So
> >> >> >>some
> >> >> >> >> API
> >> >> >> >> >>>>> to
> >> >> >> >> >>>>>>>> ease
> >> >> >> >> >>>>>>>>>> that is for me very Wellcome since I'm doing that
> >>work,
> >> >> >>and
> >> >> >> >>will
> >> >> >> >> >> be
> >> >> >> >> >>>>>> more
> >> >> >> >> >>>>>>>>>> users doing that work. In this point, I don't think
> >>we
> >> >> >>should
> >> >> >> >> >>>>> shield
> >> >> >> >> >>>>>> us
> >> >> >> >> >>>>>>>> in
> >> >> >> >> >>>>>>>>>> things like PAYG or if that is a bit less
> >>performant.
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>> To close and avoid having much discussion to not
> >>reach
> >> >>to
> >> >> >> >>some
> >> >> >> >> >>>>>> valuable
> >> >> >> >> >>>>>>>>>> point:  I can try to go with what we have, but
> >>makes me
> >> >> >>feel
> >> >> >> >>not
> >> >> >> >> >> so
> >> >> >> >> >>>>>> good
> >> >> >> >> >>>>>>>>>> about the continuous rejection of my proposals. As
> >> >>well,
> >> >> >>you
> >> >> >> >>are
> >> >> >> >> >>>>>> saying
> >> >> >> >> >>>>>>>>>> that we should wait to what users demand...but I'm
> >>an
> >> >> >>user of
> >> >> >> >> the
> >> >> >> >> >>>>> API,
> >> >> >> >> >>>>>>>> and
> >> >> >> >> >>>>>>>>>> my perception as a "zero user" seems to be not
> >> >>valuable.
> >> >> >> >>Since I
> >> >> >> >> >>>>> don't
> >> >> >> >> >>>>>>>> get
> >> >> >> >> >>>>>>>>>> traction on this, I'll try to continue with what we
> >> >>have
> >> >> >>and
> >> >> >> >> >> report
> >> >> >> >> >>>>>> back
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>> 2018-03-13 9:24 GMT+01:00 Harbs
> >> >><harbs.li...@gmail.com>:
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>>> +1.
> >> >> >> >> >>>>>>>>>>>
> >> >> >> >> >>>>>>>>>>>> On Mar 13, 2018, at 10:08 AM, Alex Harui
> >> >> >> >> >>>>> <aha...@adobe.com.INVALID>
> >> >> >> >> >>>>>>>>>>> wrote:
> >> >> >> >> >>>>>>>>>>>>
> >> >> >> >> >>>>>>>>>>>> I am so sad and frustrated that we have spent so
> >>much
> >> >> >>time
> >> >> >> >>on
> >> >> >> >> >>>>>>>>>> managing a
> >> >> >> >> >>>>>>>>>>>> set of strings.  I just don't think we have the
> >> >>people
> >> >> >> >>power
> >> >> >> >> to
> >> >> >> >> >>>>>>>>>> continue
> >> >> >> >> >>>>>>>>>>>> to seek perfection until it is truly needed by a
> >> >>user.
> >> >> >> >> >>>>>>>>>>>
> >> >> >> >> >>>>>>>>>>>
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>> --
> >> >> >> >> >>>>>>>>>> Carlos Rovira
> >> >> >> >> >>>>>>>>>>
> >> >> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> >> >> http%3A%2F%2Fabout.me%
> >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> >> >> 7Ce137bd7a9095473c2bcc08
> >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> >> >> 7C63656545817565873
> >> >> >>
> >>
> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=
> 0
> >> >> >> >> >>>>>>>>>>
> >> >> >> >> >>>>>>>>>
> >> >> >> >> >>>>>>>>>
> >> >> >> >> >>>>>>>>>
> >> >> >> >> >>>>>>>>> --
> >> >> >> >> >>>>>>>>>
> >> >> >> >> >>>>>>>>> Piotr Zarzycki
> >> >> >> >> >>>>>>>>>
> >> >> >> >> >>>>>>>>> Patreon:
> >> >> >> >>*https://na01.safelinks.protection.outlook.com/?url=
> >> >> >> https%3A%2F%2Fwww.pat
> >> >> >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> >> >> >> %7Ce137bd7a9095
> >> >> >> >>473c2bcc08d588e95a01%7Cfa7b1b5a7b34438794aed2c178de
> >> >> >> cee1%7C0%7C0%7C6365654
> >> >> >> >>58175658737&sdata=DNkm0Dce279Klqlmt%2BF7YV7%
> >> >> >> 2BiDRjzQWyG9GPG1rs2Bw%3D&rese
> >> >> >> >>rved=0
> >> >> >> >> >>>>>>>>>
> >> >> >> >><https://na01.safelinks.protection.outlook.com/?url=
> >> >> >> https%3A%2F%2Fwww.pat
> >> >> >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> >> >> >> %7Ce137bd7a9095
> >> >> >> >>473c2bcc08d588e95a01%7Cfa7b1b5a7b34438794aed2c178de
> >> >> >> cee1%7C0%7C0%7C6365654
> >> >> >> >>58175658737&sdata=DNkm0Dce279Klqlmt%2BF7YV7%
> >> >> >> 2BiDRjzQWyG9GPG1rs2Bw%3D&rese
> >> >> >> >>rved=0>*
> >> >> >> >> >>>>>>>>>
> >> >> >> >> >>>>>>>>
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>>
> >> >> >> >> >>>>>>> --
> >> >> >> >> >>>>>>> Carlos Rovira
> >> >> >> >> >>>>>>>
> >> >> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> >> >> http%3A%2F%2Fabout.me%
> >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> >> >> 7Ce137bd7a9095473c2bcc08
> >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> >> >> 7C63656545817565873
> >> >> >>
> >>
> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=
> 0
> >> >> >> >> >>>>>>
> >> >> >> >> >>>>>>
> >> >> >> >> >>>>>
> >> >> >> >> >>>>
> >> >> >> >> >>>>
> >> >> >> >> >>>>
> >> >> >> >> >>>> --
> >> >> >> >> >>>> Carlos Rovira
> >> >> >> >> >>>>
> >> >> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> >> >> http%3A%2F%2Fabout.me%
> >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> >> >> 7Ce137bd7a9095473c2bcc08
> >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> >> >> 7C63656545817565873
> >> >> >>
> >>
> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=
> 0
> >> >> >> >> >>>>
> >> >> >> >> >>>>
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >> >>> --
> >> >> >> >> >>> Carlos Rovira
> >> >> >> >> >>>
> >> >> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> >> >> http%3A%2F%2Fabout.me%
> >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> >> >> 7Ce137bd7a9095473c2bcc08
> >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> >> >> 7C63656545817565873
> >> >> >>
> >>
> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=
> 0
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > --
> >> >> >> >> > Carlos Rovira
> >> >> >> >> >
> >> >> >> >>https://na01.safelinks.protection.outlook.com/?url=
> >> >> >> http%3A%2F%2Fabout.me%
> >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> >> >> 7Ce137bd7a9095473c2bcc08
> >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> >> >> 7C63656545817565873
> >> >> >>
> >>
> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=
> 0
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> >--
> >> >> >> >Carlos Rovira
> >> >> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> >> >> http%3A%2F%2Fabout.me%2
> >> >> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> >> >> 7Ce137bd7a9095473c2bcc08d5
> >> >> >> >88e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> >> >> 7C636565458175658737&s
> >> >> >>
> >>>data=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >--
> >> >> >Carlos Rovira
> >> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> >> http%3A%2F%2Fabout.me%2
> >> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> >> 7Cce849efb1cf84ab780ae08d5
> >> >> >8905f78a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> >> 7C636565581091621628&s
> >> >> >data=5bptuicHsczeSJ84dMNT8%2FFZG42Ai732OmY8QCEbgXo%3D&reserved=0
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> 7C6de99e3bf5d844c2d09508d5
> >> >890825d0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636565590443837727&s
> >> >data=S%2F5fMzHFvlp8PHkdA28CcWSeMvcly1YJXTmDz6l0fUM%3D&reserved=0
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C1ca96ed710784d65283408d5
> >893021e1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636565762176651455&s
> >data=BMnY%2BfW6dLZq0xVS3f1jTATtbUEXWOiaWFGRIwwPu7U%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Reply via email to