[Yes, this is two different reports with the same example form] OK, I think my use of tr/xforms:group/td which is turned into tr/div/td is probably not the best practice, but nevertheless the scoping of class=xforms-disabled should probably be considered a bug. So ...
(1) At: http://oracc.museum.upenn.edu/oas-bad-safari-div.xml Is a form which behaves differently on Firefox versus Safari/Chrome. Just open the form with each browser. In FF, two select1 controls inside the 'Search index' fieldset are displayed as expected: you see 'Any position' and 'Any role' when the form is first opened. In Safari/Chrome the two select1 controls are not displayed. The inspector shows that #xsltforms-mainform-select1-4 is being assigned class=xforms-disabled in Safari/Chrome but not in FF. (2) I think I am going to experiment with using ref and/or bind to control the select1 display, and then use CSS to set display: none for td .xforms-disabled. Thanks, Steve ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Xsltforms-support mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xsltforms-support
