Small jQuery plugin dilemma

[Senff]

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.

See: http://codepen.io/senff/pen/ayGvD

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?

[nixnerd]

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 :)

[Senff]

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…?

[nixnerd]

So you have no control over whether or not the end user has an ID associated with the sticky element?

[Senff]

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.

Soooo….

• 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)

[nixnerd]

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.

[__]

Duplicate ids are invalid, but that doesn’t always matter. Different browsers do different things, but I think the main problem you’d have would be with javascript: getElementById usually (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 id…

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 id in 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.

[nixnerd]

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.

[__]

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.

[nixnerd]

let’s not get into that right now.

Sorry. I got into it. Shouldn’t have gotten into it.

[Alen]

http://codepen.io/alenabdula/pen/xnvDk

[Senff]

@Alen — your solution is taking the nav bar out of the flow of the page once it’s sticky, making all content jump up — exactly the reason why I used the cloning method.

http://codepen.io/senff/pen/sADGJ

[nixnerd]

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.

[nixnerd]

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.

[Alen]

So just compensate with padding on the body.

See edited pen.

[Author]

Posts