Jump to content
  • 0

(Archived) Mac client occasionally leaves open bold html tags



I have noticed a problem with several of my longer notes; wherein, they display fine on my Mac but the whole last half of the note will be in unrelieved bold type on the iPad client or the web client using Chrome, Firefox, or Safari. I decided to investigate this a little further and it seems that there is in fact an abnormal and seemingly unclosed bold tag in my notes that can reproducibly give this error.

At a certain segment or segments, there will be a "" tag, Firefox, Chrome, and Safari all read this as being an open bold tag. Since there is no corresponding closing tag, this produces unrelieved bold type for the rest of the note (unless you go in and play around with bolding and unbolding things, in which case you can occasionally get some relief for a small section).

Just to be clear, I am doing almost no copying and pasting from other sources. Most of this is hand typed, with an occasional picture/screen capture thrown in. I am willing to let the EN Devs look at my account if you want to see what is going on. I am not sure the behavior that is creating this bug, but I get it every time I have one of these long notes and the "" tag is always present where the unrelieved bold type begins. Also, if you do a quick and dirty html page with this abnormal tag, it does exactly what I describe until it reaches a corresponding closing tag. As such, it is definitely is being treated as an opening tag and EN (for Mac at least) is not recognizing the need to remove/close it.

I am not sure what is causing this error but it almost looks like an issue that would be caused by a regexp function to find and deal with bold tags. I am not sure if this is happening on other platforms, but it sure is a pain for me as it makes my notes extremely hard to read on anything but my macbook pro, defeating the purpose of Evernote in many ways.

Link to comment

1 reply to this idea

Recommended Posts

  • Level 5*

That's kind of interesting. Evidently, is not the sort of tag that use the empty-element form, unlike, say

, ,

, etc. Seems a little inconsistent, I guess, not that would actually do anything, having no content to modify.

Side note: I hope that nobody's using regexp to try to parse HTML. Almost certainly a bad idea, except in very constrained cases. I doubt that that's really what's happening. My own guess would be that the HTML generating code has a behavior that makes an empty element tag from out of an opening tag for an element that doesn't have any content, even for tags that oughtn't. But that's just a guess.


Link to comment


This topic is now archived and is closed to further replies.

  • Create New...