inherit
Official Code Helper
65613
0
1
Oct 22, 2024 1:56:19 GMT -8
Chris
"'Oops' is the sound we make when we improve"
9,022
December 2005
horace
RedBassett's Mini-Profile
|
Post by Chris on Nov 28, 2015 22:47:02 GMT -8
Okay, I haven't really got to working with ancestors yet (and I've no idea where to find the lookup class), so to be at least somewhat defensive in my coding so it plays nicely with others, could I do something like this: Take these lines: <div class="field1 lookup micro-profile"> <div class="field2 lookup micro-profile float-right"> <div class="results lookup miniprofile" style="width:458px">
and have them like this: <div class="field1 msg-rptr-fields"> <div class="field2 msg-rptr-fields float-right"> <div class="results msg-rptr-results" style="width: 458px;">
and have in the CSS component:
.msg-rptr-fields { color: #000; background-color: #aaa; } .msg-rptr-results { color: #000; background-color: #fff; }
That way, I've got a much higher chance of not using a class used elsewhere (I hope) and also allows for Admins to use the CSS classes for manipulation to better match their theme. Would that way be considered an acceptable alternative? Basically the "lookup" class I was referring to is one of the classes you're removing above. It is a class that is shared by both field1 and field2 as well as results so instead of defining multiple rules to set color: #000 for each you could have used that shared class to define the property which is shared between them all but I do see you already know this as evidenced by the creation of a similar shared class ("msg-rptr-fields") that applies to the subset elements that are fields. I.m seeing nothing off with your logic there. I didn't mean to give the impression that using a class shared elsewhere was somehow wrong, it is after all the main point of using a class versus an ID. The original architecture of V5 was to define a set of classes that could then be used by plugins in an ala mode manner to create themed elements similar to bootstrap but the need for cost cutting measures sort of crippled that plan. The problem stems from the current practice of writing code that depends on elements in the layout when the original intent was for the underlying data to be used instead and best of all it is theme agnostic. The problem was exacerbated when Proboards decided to remove (cut corners or inadvertently?) the underlying data for users on the page forcing coders to parse mini-profiles in order to obtain information about a particular author and forcing reliance on the layout, this is what makes using the mini-profile class bad since so many codes are looking for mini-profiles in order to parse author data. The users data was not entirely removed however just relegated to a certain page so you can still access it when viewing the forum members list (i.e. pb.data("proboards.user") ) but it used to be on every page where users existed just like the other useful data, pb.data("proboards.thread") and pb.data("proboards.post"), which are still available whenever there are lists of threads and posts respectively on the page. Codes are going to target elements via classes since that is what gives jQuery its sizzle but if there is a low probability of your shared class being the target of some other code then go for it.
|
|
inherit
217348
0
Jul 27, 2022 7:26:44 GMT -8
Lynx
5,849
January 2015
msg
|
Post by Lynx on Nov 29, 2015 6:45:30 GMT -8
Thanks, Chris! So, if I'm understanding correctly, the way you have it is that I could just use the .lookup in the CSS component to set their colors if field1. field2 and results all had the same color: and background-color: for example? I'm just trying to avoid the micro-profile and miniprofile classes - because, as you had said, those seem to be targeted quite a bit, and I don't want anything to mess them up (since this plugin really doesn't use them for any kind of mod). I'm just trying to make this plugin as close to "conflict-free" as possible, which was why I went the route I showed. There is one thing that confuses me that I can't find an answer for. What's the difference with space versus no space when doing classes. For example: .msg.rptr-fields (no space between class names) .msg .rptr-fields (space between class names) I've seen this in Brian's Custom Mini-Profile Creator Plugin: .mini-profile.msg-mp .msg-staff {No space between the .mini-profile and .msg-mp, but there is a space between .msg-mp and .msg-staff - Is there any special meaning between the 2? Thanks again very much, Chris! I should be (hopefully) set for awhile after these questions. Peter - I would also like to thank you very much for your help as well! You guys are awesome!
|
|
inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Nov 29, 2015 7:31:11 GMT -8
.msg .rptr-fields - Will target all elements (children) with the class "rptr-fields" inside elements with the class "msg" (parent). .msg.rptr-fields - Will target all elements that has the class "msg" and "rptr-fields". See 5.8.3: www.w3.org/TR/CSS2/selector.html#attribute-selectorsEdit: An article explaining it with a visual if you are still unsure... css-tricks.com/multiple-class-id-selectors/Edit again: Just in case you are confused with the explanation of the second selector when I say "and", it means both classes in the same attribute (i.e <div class="msg rptr-fields">).
|
|
inherit
217348
0
Jul 27, 2022 7:26:44 GMT -8
Lynx
5,849
January 2015
msg
|
Post by Lynx on Nov 29, 2015 8:53:13 GMT -8
Thank you very much, Peter! That explanation was definitely clear enough for me. So, this line: .mini-profile.msg-mp .msg-staff {
would target the ".msg-staff" if it was a child of the classes of ".mini-profile" and ".msg-rptr". (i.e.: <div class="mini-profile msg-rptr"> <-- both classes would have to be present to target that "msg-staff" class)
|
|
inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Nov 29, 2015 10:20:27 GMT -8
Yes, that's correct. If it's a child or descendant, then it will apply the rules to them.
|
|
inherit
217348
0
Jul 27, 2022 7:26:44 GMT -8
Lynx
5,849
January 2015
msg
|
Post by Lynx on Nov 29, 2015 10:31:46 GMT -8
Child and descendants aren't the same thing? O.O
Would you be so kind as to enlighten me, please?
|
|
inherit
2671
0
May 14, 2013 14:40:03 GMT -8
Peter
🐺
10,615
February 2002
peter3
|
Post by Peter on Nov 29, 2015 10:47:00 GMT -8
Easiest way to explain this is in plain English, and is commonly done this way as it does confuse people a little. My daughter is my child and my descendant. My granddaughter is not my child, but is my descendant. Examples: - Effect all div child and descendants .myclass div - Effect only children divs .myclass > div - Effect only grandchildren .myclass * div Selectors can become complex, but are very powerful. www.w3.org/TR/CSS21/selector.html#descendant-selectorsEdit: I don't actually have a daughter, just in case people thought I did lol
|
|
inherit
217348
0
Jul 27, 2022 7:26:44 GMT -8
Lynx
5,849
January 2015
msg
|
Post by Lynx on Nov 29, 2015 11:24:32 GMT -8
Thank you, Peter! I can see this will take some studying. I've got the link bookmarked in my browser. I read through it, but I see there's a whole chapter there, so I'm going to read the whole thing.
|
|