Summarized problems with accordion, and working on this one jira (will clos=
e all the others, but fixes will be done on this one as they are all relate=
d).
1) complete domdiff update as before so removed the 'open' and 'closed' cla=
sses from the renderer and put in javascript and re-arranged divs (uses cor=
e renderer, so should not be too difficult to get jsp going once jsf is goo=
d).
2) javascript attempts to update the rule for open and closes with height, =
but new css is much larger and for some reason, it's not able to update the=
rule (could be the @media annotations in css), but since it's not very per=
formant, I went the way to just modifying the divs themselves with the auto=
Height
3) autoHeight cannot be calculated once at initialization since some of the=
divs are empty until that div is selected. (when ui:include is used or fac=
elet=3D"true"), so when it's updated, must re-calculate autoHeight.
4) attributes have changed so tests now must be changed and modifications l=
ike renaming "autoheight" passed in to js as config object to "autoHeight" =
was not propagated through to javascript. Also, changing component attribu=
te to selectId means modification of tests in mobitest as well.
5) tests now first for autoHeight=3D"true'. If so, then calculates autoHei=
ght based on the div height - the calculated height of the handle. (rather=
than 33 which is in the current styling). if autoHeight is false and fixe=
dHeight is set, then that height is set on the divs. This is where the scr=
olling attribute will be set to overflow such that if the fixedHeight does =
not accommodate the content of the div, it will scroll. Still have to test=
the autoHeight =3D false and no fixedHeight set so divs default to whateve=
r their content is. I am not changing the css which has fixed values as th=
at will override anything for the autoHeight=3Dfalse and no fixedHeight...n=
ot sure exactly how this should be dealt with. If they have css which spec=
ifies the height of the div's, should that be the fallback??? _> need clari=
fication on this last point. Should user styling over-ride? Why bother ha=
ving user-defined styling which affect height (transitioning on this attrib=
ute) when we have attributes set to handle them?
=20
Task
Major
Summarized problems with accordion, and working on this one jira (will clos=
e all the others, but fixes will be done on this one as they are all relate=
d).
1) complete domdiff update as before so removed the 'open' and 'closed' cla=
sses from the renderer and put in javascript and re-arranged divs (uses cor=
e renderer, so should not be too difficult to get jsp going once jsf is goo=
d).
2) javascript attempts to update the rule for open and closes with height, =
but new css is much larger and for some reason, it's not able to update the=
rule (could be the @media annotations in css), but since it's not very per=
formant, I went the way to just modifying the divs themselves with the auto=
Height
3) autoHeight cannot be calculated once at initialization since some of the=
divs are empty until that div is selected. (when ui:include is used or fac=
elet=3D"true"), so when it's updated, must re-calculate autoHeight.
4) attributes have changed so tests now must be changed and modifications l=
ike renaming "autoheight" passed in to js as config object to "autoHeight" =
was not propagated through to javascript. Also, changing component attribu=
te to selectId means modification of tests in mobitest as well.
5) tests now first for autoHeight=3D"true'. If so, then calculates autoHei=
ght based on the div height - the calculated height of the handle. (rather=
than 33 which is in the current styling). if autoHeight is false and fixe=
dHeight is set, then that height is set on the divs. This is where the scr=
olling attribute will be set to overflow such that if the fixedHeight does =
not accommodate the content of the div, it will scroll. Still have to test=
the autoHeight =3D false and no fixedHeight set so divs default to whateve=
r their content is. I am not changing the css which has fixed values as th=
at will override anything for the autoHeight=3Dfalse and no fixedHeight...n=
ot sure exactly how this should be dealt with. If they have css which spec=
ifies the height of the div's, should that be the fallback??? _> need clari=
fication on this last point. Should user styling over-ride? Why bother ha=
ving user-defined styling which affect height (transitioning on this attrib=
ute) when we have attributes set to handle them?
=20