- This topic is empty.
August 26, 2014 at 1:17 pm #180747
So I have this JQ plugin that makes an element sticky when you scroll down. I’ve taken the approach that upon initialization, the element (that you want to be sticky) will be cloned. Long reasoning behind it but let’s not get into that right now.
Now, the cloned element will have the exact same classes, AND same ID as the original element — in order to make sure all styling is the same.
Result: two elements on one page with the same ID. Does not validate!
But if I take out the ID and ensure every ID is unique, then any styling that may have been done on the element through the ID, will get lost.
So question: is it OK to have a double ID on one page? I don’t think it’s that bad, it’s just a validation issue and won’t actually break anything.
Or should I make sure it’s always unique IDs and find other ways to copy the styles that may have been set in the CSS by targeting IDs (which is a point of hot debate — but it happens)?
What’s your take on this?August 26, 2014 at 1:20 pm #180749
Dude, I would say that all IDs need to be unique. What you could do is rename BOTH IDs to a common class. Or… you could create a new unique ID that inherits styling from the old ID via SASS/SCSS.
Both of those are pretty trivial and will let you have the best of both worlds :)August 26, 2014 at 1:41 pm #180751
I’m only offering a plugin, so if the original page has “bad practice” of styling something through IDs, then I have no control over that. So renaming the ID of either the original or the cloned element is not desired cause that way, we may lose some styles.
Unless ALL the styles (placed on the ID) are being read by the jQuery plugin and then applied to the common class.
But how can jQuery find ALL the styles of an element, when these styles are declared in one or more stylesheets…?August 26, 2014 at 1:44 pm #180752
So you have no control over whether or not the end user has an ID associated with the sticky element?August 26, 2014 at 1:54 pm #180754
Indeed. It’s a plugin — I have no control over what the user did to the page where he/she wants to include the plugin.
This is how it works. Let’s say someone uses my plugin on their own page. Obviously, I don’t have any control over the code of this page. Good or bad.
My plugin creates a clone of an element. This cloned element HAS to have the exact same styles as the original element. All of them. Because it has to look exactly the same.
If the original element was styled by the author only with classes as selectors, fine. The clone will have the same classes then, and so will look the same.
But if the original element was styled by the author with the ID as selector, the only way to make the cloned element look the same is if it would have the same ID as well.
It’s fine if the sticky element HAS an ID. It’s not if the sticky element has been STYLED with the ID as a selector.
August 26, 2014 at 2:19 pm #180755
- Option 1: give the cloned element the same ID, or…
- Option 2: cloned element will not get an ID and say “this plugin does not support elements that have been styled using an ID as selector“, or…
- Option 3: “read” all styles from the original element (how??) and apply them all to the cloned element (with a new class)
Ok, now I fully understand. That’s tough man.
Option 2 seems like the best… but it doesn’t answer your question. I see no problem with requesting that people make a few changes to use your plugin. All plugins have some criteria for use. If the end user want to have a non-valid site… well, at least they’ve been warned.
As for option 3… I don’t know. I would assume you could get the styles if they were inline but that’s the worst option ever. Requiring users to have inline styles is much worse than requiring them to use classes.August 26, 2014 at 2:23 pm #180756__Participant
getElementByIdusually (in most browsers, AFAIK) only returns the first match. So, there’s potential for conflicting code and general funkyness if the user tries to attach some other functionality to the
Sorry; I don’t really have a suggestion. Your best bet, I think, is #1, combined with a big warning against giving the menu an
idin your README.
Maybe you could mix a little bit of #2 in there by logging a warning in the console when you find an
id.August 26, 2014 at 2:26 pm #180757
getElementById usually (in most browsers, AFAIK) only returns the first match.
I believe you are correct sir. Easy enough to test though.
#1 with #2 as a fallback sounds reasonable.
I’ve taken the approach that upon initialization, the element (that you want to be sticky) will be cloned.
On a sidenote… I created a complete shit-storm for myself earlier this week by cloning stuff. It sucked.August 26, 2014 at 2:41 pm #180758__Participant
On a sidenote… I created a complete shit-storm for myself earlier this week by cloning stuff. It sucked.
Yeah. My original response was going to be “are you sure you need to clone it”, but I read your explanation in the pen.August 26, 2014 at 3:01 pm #180768
let’s not get into that right now.
Sorry. I got into it. Shouldn’t have gotten into it.August 26, 2014 at 3:33 pm #180773August 26, 2014 at 3:45 pm #180775August 26, 2014 at 3:51 pm #180776
I don’t think there’s an elegant solution. You could clone the bar, make the original hide() and append a spacer. Super dirty solution though.August 26, 2014 at 3:52 pm #180777
And… Spacer wouldn’t work. The whole problem is that we can’t get the styles. How big should the spacer be? We can’t know if it’s styled via ID.August 26, 2014 at 3:54 pm #180778AlenParticipant
So just compensate with padding on the body.
See edited pen.