Custom CSS Bug Report - no urgency

[Duke3D]

The instructions contained in custom-example.css.php are in error.
The ID of the rendered form is no longer simply #Form_7 The ID now includes the displayed record number and so styling using the form's ID itself to target on a specific form is no longer practical.

What does work is styling using the Group as that does not change. #group7 works to style elements in that group, but reaches across all instances (multiple forms reusing the same group) which is usually good news for code efficiency.

Since there was likely a reason to change the structure of the form ID to include the record number, how about adding the form number back in as a class on the form tag? .form7

 

[cheesegrits]

You can just add $rowid to your selector, although you need to include both, with and without rowid (new forms won't have rowid) like ...

echo "
#form_123, #form_123_{$rowid} {
   foo: bar;
}
";

... or whatever.

I'll fix the instructions in the file.

-- hugh

 

[cheesegrits]

PS ... the reason we had to add the rowid to the form's ID is that it is possible to have the same form displayed more than once on the same page, for instance a form component view with the same form in a module, or a J! article with the same form (with different rows) rendered multiple times with the content plugin.

While not a common occurrence, people do sometimes have a valid requirement for doing that ... so we have to individuate the form ID with the rowid, otherwise Bad Things Happen <tm> when you have multiple forms with the same ID on the same page.

-- hugh

 

[Duke3D]

Totally understand the reason - seems that rowID would not be sufficient for styling how do you know that #Form_7_2834 is positioned at the big center of the page instance and #Form_7_2821 is the smaller one in a module where the row number changes with each use. Perhaps use a more generic instance number of the form the same way you add instance in a join AS? #Form_7_0 v. #Form_7_1 for two instances on a page.

Anyway, a class with .form_7 is a better separation of concerns solution as a styling hook leaving the ID for JS requirements. I would think styling .form_7 .myspecificelement is the most frequently sought use case.

I'm also a charter member of the Bad Things Happen club! Glad to know there is an active Huntsville chapter. <warm smile>

 

[Duke3D]

My concern with rstyling with #Form_7_2821 as the hook to use for form styling is that you cannot cache generic form styling - this approach is great for cache busting when that is needed and each record needs custom styling. I am having a hard time coming up with that real world use case, but I'm sure there is one.
Most designers will appreciate having the .form_7 class without figuring out the syntax for generic regex selectors that are not fully cross-browser yet.

 

[Duke3D]

Hugh - How do you prefer to receive minor bugs/usability issues like the one in the attached screenprint?

Sometimes we have to inherit another component's too long table names. Need hover tip or width as percentage.

 

[cheesegrits]

Best is a code fix as a github PR.

Sent from my HTC One using Tapatalk

 

[Duke3D]

Fair enough! Though some fixes are not yet in my skillset so not a 100% solution. I'll do what I can.

 

[cheesegrits]

Sorry, I was wondering the aisles of Home Depot when I responded to that last one, misread your post, thought you meant you had a fix for that.

Just post 'em, one issue per thread. However, things like that are very unlikely to get dealt with in Community support. We (staff) typically only respond in Community if it's a serious bug, or something (like the Save and Edit thing) which is on our personal radar / to do list

Hugh


Sent from my HTC One using Tapatalk