saidit icon indicating copy to clipboard operation
saidit copied to clipboard

Add title text from links to client-side image expandos.

Open wizzwizz4 opened this issue 5 years ago • 7 comments

This is tricky with the current code. If the elements were being created using ordinary DOM commands, it would be simple:

var a = thingy can't remember this
var img = document.createElement("img");
img.src = a.href;
if (a.title) img.title = a.title;
thingy can't remember.appendChild(img);

As the jQuery directly inserts HTML, though, this is slightly more tricky. Which approach should be taken?

  • String manipulation; or
  • DOM manipulation?

wizzwizz4 avatar Apr 17 '19 21:04 wizzwizz4

Touching the DOM as few times as possible is always a good approach for js. I'd build your html as a string an use a single jQuery/js call to insert it.

Also I don't understand this feature idea at all. You want to ajax request urls and extract their titles?

libertysoft3 avatar Apr 18 '19 04:04 libertysoft3

No…

Let's say that somebody included a URL like this:

[boring image](https://example.com/veryboring.png "Some title text.")

My feature request is to add the title attribute from the user's <a> tag to the image (or to the <a> tag produced to wrap it).

wizzwizz4 avatar Apr 18 '19 12:04 wizzwizz4

Also, why is it best to perform string hacks on strings that represent HTML elements, then get the browser to parse those strings, instead of interacting with the DOM directly? Your codebase, your rules, but I'd like to know the reasoning.

wizzwizz4 avatar Apr 18 '19 12:04 wizzwizz4

Oh I didn't even know you could add a title to your links. I'll play with that, sounding like a good feature.

Interacting with the Dom directly is fine, but if you have to do 5 Dom interactions that could be done with 1, one is always better. Every element selection and update has a delay, so they can add up if you are not careful. Your code above seems fine tho.

Thus all of these js frameworks needed to invent shadow Dom and batched updates and weird caching to stay fast.

libertysoft3 avatar Apr 18 '19 19:04 libertysoft3

Well, that shouldn't be a problem considering that we're not writing to elements in the tree, but only inserting them into the tree after they've been properly modified.

wizzwizz4 avatar Apr 18 '19 20:04 wizzwizz4

Inserting is writing is touching. Don't worry about it, if I see an optimization I can make on your code I will do so.

libertysoft3 avatar Apr 18 '19 21:04 libertysoft3

No, I mean… the elements aren't being modified until after they're inserted, which would have to happen anyway, so it's just as fast as using a DocumentFragment (or, at least, should be).

wizzwizz4 avatar Apr 19 '19 10:04 wizzwizz4