You could just add some extra logic to make sure you're affecting the row for the exact label you are looking for:
$('nobr:contains("B")').each(function() {
// the BB column will not meet this condition
if ($(this).text() === "B") {
$(this).closest('tr').hide();
}
});
So, just to be clear on the two approaches, when you are looking for the nobr:contains
with the display name of the column, that is looking at the column labels that are on the left hand side of the form. SharePoint wraps the display names of the columns in a nobr
tag, so that's why that works. On the other hand, when you are using the [id^="FieldInternalName"]
way of finding the row you want, you are looking for the control for that column that is on the right hand side of the form (i.e., the textbox, the people picker, the drop-down, etc.). The reason Ganesh's suggestion won't work, and the other answer you found uses the "starts with" (^=
) comparison is because when building the control for that field, SharePoint creates the ID this way:
id="FieldInternalName_some-guid-here_TypeOfControl"
so the ID of the control is more than just exactly the internal name, and you have to use "starts with" to find it.
In your case, [id^="B"]
will also find your BB
column, because of course BB
starts with B
. However, if you take into account the fact that after the internal column name comes an underscore and then a GUID, this might work for you: [id^="B_"]
.
Keep in mind, though (and this is to somewhat address your comment that the internal field names are "automatically assigned by SharePoint") - when you create a column, SharePoint assigns the internal name of the column based on what you name the column, and people quite often name a column using more than one word, so there are spaces in there. This causes SharePoint to encode the spaces as _x0020_
in the internal name.
You can control this.
If you create a column and do not use spaces or any other special characters (like apostrophes or parentheses, they get encoded too, just with a different code than spaces) when you initially create the column, the internal name will be nice and neat. You can then go back and edit the column and make the display name whatever you want, the internal name will already be set. So for instance, if you wanted to create a site column "Phone Number", if you name it like that initially, the internal name will be Phone_x0020_Number
, which is not great. Instead, you should name the column "PhoneNumber" initially, which will give it an internal name of PhoneNumber
, and then you go back and add the space and make the display name "Phone Number", but the internal name will stay PhoneNumber
.
Where am I going with all this?
Well, not controlling the internal names of the columns is one of my biggest peeves with how people use SharePoint, so I tend to get a bit ranty about it. BUT, I will bring it back around to tie it in to this question and answer.
Let's say that someone had created a column on your site or list or wherever that was called "B and B", and they hadn't used the best practice method of controlling the internal name by not using spaces. If they used spaces, the internal name for that column would be B_x0020_and_x0020_B
. So if that were the case, using [id^="B_"]
would not work for distinguishing between your B
column and the B and B
column.
So that's just something you have to keep in mind and watch out for.