02:18 <rick42> hello (back :)

06:50 <m_mans> Hi all!

07:51 <Regenaxer> m_mans: Do you have any new info about the style issue in @lib/form.js?

07:53 <m_mans> Regenaxer: no, I've postponed that issue a little

07:57 <Regenaxer> ok

08:10 <cess11> happy holidays

08:14 <Regenaxer> Hi cess11, same!

09:03 <clacke[m]> Merry Gravmass!

10:29 <Unscrmbl-aw> hi all! happy holidays!

10:31 <aw-> not sure if my last message appeared correctly

10:31 <aw-> happy holidays!

11:46 <m_mans> Regenaxer: here?

11:47 <m_mans> we could change form.l:262

11:48 <m_mans> - val = j >= 0? cls.substr(j+2) : "";

11:48 <m_mans> + val = j >= 0? cls.substr(j+2) : cls;

11:49 <m_mans> but small issue remains in this case

11:51 <m_mans> e.g, if field value is -1, thus class attr value is "red field" (during initial GET)

11:53 <m_mans> then we change value to -2. After handling JS the class attr value become "red red field". Visually everything is still correct

11:54 <m_mans> /become/becomes/

11:58 <m_mans> then we change field value to positive number. JS handler strips "red " from class attr, thus we have class="red field" again. So finally we see positive value but in red color

12:08 <m_mans> I've made workaround with (form.l:1034):

12:08 <m_mans> (<style> (and (lt0 (val> This)) "red ") (extra "Var")) )

12:08 <m_mans> notice extra space after 'red'

12:24 <Regenaxer> Hi m_mans, sorry, was out

12:25 <Regenaxer> I'm very reluctant to change this, as it may have unexpected consequences

12:25 <Regenaxer> I'll first release picoLisp-17.12 next week

12:26 <Regenaxer> I believe the current logic has a reason

12:30 <Regenaxer> If we change to ... cls.substr(j+2) : cls;

12:31 <Regenaxer> then the class will never be cleared. I think this was the reason for ... cls.substr(j+2) : "";

12:32 <Regenaxer> I have many cases where the style is set upon a certain condition, and should be cleared again if that condition vanishes

12:35 <Regenaxer> Why is it that I never saw this effect? How exactly was it caused?