Evernote 6.0: Block element spacing lost

[Kevin Mitchell 19]

I created a note with Markdown like this:

 

Evernote Spacing

 

## Heading 2

 

- List

- Of

- Things

 

1. numbered

2. List

 

## Heading 2

### Heading 3

 

Paragraph

 

Another paragraph

 

Copied it from Marked 2, and pasted it into Evernote 6.0 on Mac. Note how there is no spacing between block elements (headings, paragraphs, lists).

 

 

Even though I created it on the Mac, and it looks bad there, it looks fine on the web and on iPad (the iPad display looks like the web)

 

 

Additionally, all my existing notes of this nature have lost their spacing in the Mac client.

 

I've made a gist of the .enex file so you can see the style on the note's contents: https://gist.github.com/kamitchell/0aad321f7056109a630a

 

Edit: .enex no longer contains location data. 

[songcrates 7]

+1

 

Seems the new Evernote for Mac changed the way it parse the ENML. Despite all the CSS styles added by whatever Markdown Editor it is, Evernote will override the display according to the ENML tag.

[pdd 1]

+1

 

Modifying the spacing of content from within the Evernote 6 rich text editor also does not fix the problem.  After syncing with the Evernote web service to commit my changes, the display renderer overrides my block spacing changes.  This seems to also be true for certain content styles such as font sizes.  

 

The Mac Evernote 6.0 display renderer simply does not respect some of the changes I am making. The rendered spacing makes everything unreadable.  

 

Luckily, the spacing and styles on my notes and web clippings still look ok on the Evernote web application.

 

The only workaround I've found was to delete my local cached notebooks, downgrade my Mac client to Evernote 5.5.1, and resync in order to restore the readability of my content.  

 

I will not be upgrading Evernote until this formatting and display bug is fixed.

[Andrei Thorp 20]

Hello Kevin,

 

I'm from the team that created the Mac v6 editor. I'm very sorry to have disrupted your workflow, and we've been working internally for a few days to come up with a decent solution. I've inspected the sample note that you've given us, and it doesn't actually specify any extra space between pieces of text. The real cause of this issue was that we decided to experiment with getting rid of the default whitespace that web browsers add to HTML tags like <p> and <h1>. As a result, you haven't been seeing this added space. In general, we believe that this decision has created a more predictable editing experience, but it unfortunately did break some stuff for users that were relying on the old behaviour.

 

Don't worry, we haven't lost any of your data or actually changed any of your old notes. It's just a note presentation issue. I'm still trying to figure out what the best compromise is, but I just wanted to let you know that I'm actively looking at it.

[pdd 1]

Would it be possible to create a preference setting to switch to the pre-v6 editor behavior until the new v6 editor can create a more seamless transition between the two?  After all these years, there are just too many notes that have been created and edited adjusting to and expecting the old behavior to just make such a drastic change without transition options.

 

Thanks for actively looking into this problem.  Looking forward to a resolution and expected release date.

[Andrei Thorp 20]

Unfortunately, maintaining the old editor in parallel took away too many human hours from trying to polish the current one, so we had to drop it. Do you have any active backwards compatibility issues (aside from this one)? I'm under the impression that we've done a great job supporting old notes and webclips, but I'd love to hear your side of it.

[pdd 1]

The backwards compatibility issues that I have noticed include.

 

1. As discussed above, block spacing issues from markdown notes and web clips.

2. When editing notes, font style and size changes would display properly after the initial edit but after navigating away from the note and coming back to it, it reverts back to its original display presentation.  I even tried syncing the my style updates with the Evernote web service before navigating away but it doesn't seem to help.

 

After the above two problems, I reverted Evernote back to 5.5.1 and re-downloaded all my notes so I have nothing else to report.

 

Is there a tracking bug that I can monitor for these type of issues so that I can find out when to finally make the upgrade?

[E-NoteForum 107]

This also applies to bullet lists. It's incredibly frustrating to have literally years' worth of notes suddenly change formatting and look broken. Users have relied on that formatting for years, and now the entirety of our note collection looks different than how we authored them.

 

What's worse, it's not even consistent with other versions of the app. If you create a note on iOS, for example, it still has the extra spacing. But when you look at it on Mac, the spacing is gone and the formatting is compressed. If you then add in extra line breaks on the Mac, the spacing is doubled on the iOS app, which looks terrible.

 

Surely it's not an intentional design decision to make notes look different on different platforms. Please tell me no one thinks that's actually a desirable feature.

[Andrei Thorp 20]

2. When editing notes, font style and size changes would display properly after the initial edit but after navigating away from the note and coming back to it, it reverts back to its original display presentation.  I even tried syncing the my style updates with the Evernote web service before navigating away but it doesn't seem to help.

 

Can you elaborate more on this one? I'm not 100% sure I get it. Would also love to see an exported note that exhibits this behaviour.

 

And no, unfortunately, our bug tracking system is internal-only.

[Kevin Mitchell 19]

The real cause of this issue was that we decided to experiment with getting rid of the default whitespace that web browsers add to HTML tags like <p> and <h1>. As a result, you haven't been seeing this added space. In general, we believe that this decision has created a more predictable editing experience, but it unfortunately did break some stuff for users that were relying on the old behaviour.

 

Thanks for getting back to me. Sorry I hadn't responded yet; it was a busy week and I was traveling.

 

Now it makes sense to me. I see what you're driving at, but maybe there is a better way to do it that works better cross-platform and doesn't affect legacy notes.

 

Taking out the default whitespace means that the display of the HTML is now incompatible with just about every other program that bases their formatting on HTML. The default HTML style sheet is such a key part of things that W3C has included it as an informative reference in the CSS 2.1 spec.

 

Evernote is clearly based on HTML, because there are AppleScript verbs for inserting HTML. Changing the default style sheet is going to mess things up for the community that supports Evernote by building things around it.

 

I also have scripts that insert HTML into Evernote notes and get undesired results; these would become unnecessarily more complicated if I had to look up the elements in the default stylesheet. I should be able to just put in an <h2> and get some kind of reasonable space.

 

If the editing experience needs to deviate from the default style sheet, then maybe the default could be left alone, and the editor could zero out those spacings with local style attributes when it creates those elements. It's a bit more work for you guys, but that's work done once, rather than frustration for all users. It would give a consistent experience across different platforms.

 

And, if the editor is the part making the change, maybe there could be a switch for the editor for how the spacing should work.

 

In short, I'm suggesting that if the editor wants elements to work differently, then it should style those elements individually rather than changing the default stylesheet for everything.

 

Thoughts?

[Kevin Mitchell 19]

 

 

The only workaround I've found was to delete my local cached notebooks, downgrade my Mac client to Evernote 5.5.1, and resync in order to restore the readability of my content.  

 

 

I'm at this point too. I put 5.5.1 on my work machine manually to keep App Store from accidentally upgrading it. The only reason I haven't downgraded my home machine from 6.0.3 to 5.5.1 is so I can respond to Evernote about bugs I'm reporting.

[Kevin Mitchell 19]

As an example of things I do with scripts and expect block spacing to work:

 

tell application "Evernote"

set theNote to create note with text "" title "Test note"

append theNote html "<h2>Heading</h2><p>Text</p>"

end tell

 

 

The (null) thing is a new bug that I've reported and started a forum topic on.

[chirmer 567]

This also applies to bullet lists. It's incredibly frustrating to have literally years' worth of notes suddenly change formatting and look broken. Users have relied on that formatting for years, and now the entirety of our note collection looks different than how we authored them.

Users have been complaining about that layout for years, too. It's one of the assumed complaints about EN - the way lists have spacing before/after them yet standard paragraphs don't. I've read the complaints about this so many times on this forum it's crazy! I'm beyond excited this is being fixed, as I think it's better and more consistent to have everything single-spaced from each other and add spacer lines as desired versus having some things single-spaced and some having block styling. Now to just get text-wrap...

 

To make sure I'm understanding you guys correctly - you format your notes in a 3rd party program, then paste into EN and that's when the spacing doesn't behave as it used to? It seems to me like Evernote's changing the software so that everything is consistent. When you create notes in EN's note editor, there is no support for block spacing (outside of lists). Seems to me (a non-developer but avid user) they're trying to make the experience the same across the board, since it's INCREDIBLY frustrating to have to copy/paste everything in plain text and format it in Evernote so that one doesn't get stuck with HTML formatting from the source that can't be modified. This way copy/pasting data from a web browser will have the same editing functionality, paragraph-wise, that just typing it in the editor does. Me likey!

 

What's worse, it's not even consistent with other versions of the app. If you create a note on iOS, for example, it still has the extra spacing. But when you look at it on Mac, the spacing is gone and the formatting is compressed. If you then add in extra line breaks on the Mac, the spacing is doubled on the iOS app, which looks terrible.

 

Surely it's not an intentional design decision to make notes look different on different platforms. Please tell me no one thinks that's actually a desirable feature.

This is easy to answer, and can be found on these forums as well - Evernote is developed platform-specific. Love it or hate it, but each team works on things not 100% parallel with each other. Evernote has 0 track record (as far as I know) of having core capabilities only on one platform (they might have a gap between implementations, but they all get everything eventually), so I wouldn't worry. Dollars to donuts, it will all be consistent eventually (according to track record).

[Andrei Thorp 20]

...

 

In short, I'm suggesting that if the editor wants elements to work differently, then it should style those elements individually rather than changing the default stylesheet for everything.

 

Thoughts?

 

 

I've queried the devs of all the other platforms to see what kinds of default spacing they're adding to notes. It is kind of inconsistent from place to place, but I'll work on improving that. Mac is the only platform currently that doesn't add space to these elements, so I feel like a compromise there is probably a good idea.

 

One of the good things about the new editor is that it doesn't use paragraph or heading tags itself (it does most formatting using <div>s instead). This means that I can potentially add some default spacing around <p> and <hX> without affecting notes that users type directly in the new editor. However, lists are still created as real HTML lists, so I won't add default spacing around them. Hopefully this is a good enough compromise for you.

[Andrei Thorp 20]

 This also applies to bullet lists. It's incredibly frustrating to have literally years' worth of notes suddenly change formatting and look broken. Users have relied on that formatting for years, and now the entirety of our note collection looks different than how we authored them.

Users have been complaining about that layout for years, too. It's one of the assumed complaints about EN - the way lists have spacing before/after them yet standard paragraphs don't. I've read the complaints about this so many times on this forum it's crazy! I'm beyond excited this is being fixed, as I think it's better and more consistent to have everything single-spaced from each other and add spacer lines as desired versus having some things single-spaced and some having block styling. Now to just get text-wrap...

 

Yeah, this is for sure the motivation for this change. I've been an avid Evernote user on many platforms for many years also, and it was always super strange to me how you'd have to remember to add newlines between paragraphs, but definitely avoid adding newlines between paragraphs and lists -- since lists automatically add space.

 

By text-wrap, do you mean text wrapping around floating images?

 

 What's worse, it's not even consistent with other versions of the app. If you create a note on iOS, for example, it still has the extra spacing. But when you look at it on Mac, the spacing is gone and the formatting is compressed. If you then add in extra line breaks on the Mac, the spacing is doubled on the iOS app, which looks terrible.

 

Surely it's not an intentional design decision to make notes look different on different platforms. Please tell me no one thinks that's actually a desirable feature.

This is easy to answer, and can be found on these forums as well - Evernote is developed platform-specific. Love it or hate it, but each team works on things not 100% parallel with each other. Evernote has 0 track record (as far as I know) of having core capabilities only on one platform (they might have a gap between implementations, but they all get everything eventually), so I wouldn't worry. Dollars to donuts, it will all be consistent eventually (according to track record).

 

Yep, you nailed this one too. I'm definitely working quite hard to try and improve the consistency of note editing/viewing between platforms.

[Kevin Mitchell 19]

 

...

 

In short, I'm suggesting that if the editor wants elements to work differently, then it should style those elements individually rather than changing the default stylesheet for everything.

 

Thoughts?

 

 

I've queried the devs of all the other platforms to see what kinds of default spacing they're adding to notes. It is kind of inconsistent from place to place, but I'll work on improving that. Mac is the only platform currently that doesn't add space to these elements, so I feel like a compromise there is probably a good idea.

 

One of the good things about the new editor is that it doesn't use paragraph or heading tags itself (it does most formatting using <div>s instead). This means that I can potentially add some default spacing around <p> and <hX> without affecting notes that users type directly in the new editor. However, lists are still created as real HTML lists, so I won't add default spacing around them. Hopefully this is a good enough compromise for you.

 

 

I don't count using div instead of paragraphs or headings a "good thing" either. The big win to me in Evernote was that it was HTML-based. Regular, standard HTML. The same stuff used in the web, the same stuff that Markdown formatters produce. It's bad that it's changing.

 

It's bad because it's not the same as other programs that handle HTML content. That makes all kind of interchange not work (as we already see).

 

It's bad because you're telling me that if I ever need to get out of Evernote, my newly-typed content doesn't have structural markup (using the correct heading/paragraph tags).

 

It's bad because it's not even consistent across Evernote platforms. "Eventual" consistency doesn't help. It just means that Evernote is going to get in my way on one platform or another until it's consistent...and then what's to say it won't change again? (And you're telling me I can expect this problem with iOS next? I use my iPad to quickly read things much more than my desktop.)

 

I'm finding that as long as I have 6.0+ installed on my personal machine, I'm afraid to create content. I know it's going to look bad, and now I know it's not going to have real heading tags. I want to help you find the bugs, so I'm keeping 6 installed, but I'm feeling compelled to go back to Evernote 5.

 

A program that makes me hesitate to use it...that basically removes the whole value of it.

 

The base HTML should use a standard stylesheet and real structural tags like p and h2. What the editor styles...well, that's what it styles...that's why there's a style attribute on all HTML elements.

[Kevin Mitchell 19]

 

This also applies to bullet lists. It's incredibly frustrating to have literally years' worth of notes suddenly change formatting and look broken. Users have relied on that formatting for years, and now the entirety of our note collection looks different than how we authored them.

Users have been complaining about that layout for years, too. It's one of the assumed complaints about EN - the way lists have spacing before/after them yet standard paragraphs don't. I've read the complaints about this so many times on this forum it's crazy! I'm beyond excited this is being fixed, as I think it's better and more consistent to have everything single-spaced from each other and add spacer lines as desired versus having some things single-spaced and some having block styling. Now to just get text-wrap...

 

To make sure I'm understanding you guys correctly - you format your notes in a 3rd party program, then paste into EN and that's when the spacing doesn't behave as it used to? It seems to me like Evernote's changing the software so that everything is consistent. When you create notes in EN's note editor, there is no support for block spacing (outside of lists). Seems to me (a non-developer but avid user) they're trying to make the experience the same across the board, since it's INCREDIBLY frustrating to have to copy/paste everything in plain text and format it in Evernote so that one doesn't get stuck with HTML formatting from the source that can't be modified. This way copy/pasting data from a web browser will have the same editing functionality, paragraph-wise, that just typing it in the editor does. Me likey!

 

What's worse, it's not even consistent with other versions of the app. If you create a note on iOS, for example, it still has the extra spacing. But when you look at it on Mac, the spacing is gone and the formatting is compressed. If you then add in extra line breaks on the Mac, the spacing is doubled on the iOS app, which looks terrible.

 

Surely it's not an intentional design decision to make notes look different on different platforms. Please tell me no one thinks that's actually a desirable feature.

This is easy to answer, and can be found on these forums as well - Evernote is developed platform-specific. Love it or hate it, but each team works on things not 100% parallel with each other. Evernote has 0 track record (as far as I know) of having core capabilities only on one platform (they might have a gap between implementations, but they all get everything eventually), so I wouldn't worry. Dollars to donuts, it will all be consistent eventually (according to track record).

 

 

I don't think our two desires are inconsistent. I'm basically asking for the meaning of the internal HTML to go back to the way it was. That way, HTML injected by scripts or pasted rich text will still look the same. The change to the defaults has also broken notes of mine that are up to two years old. That's pretty bad.

 

The editor level can always override the default stylesheet. There's nothing preventing the editor from inserting a new <p style="margin:0"> or whatever instead of <p> when you hit return, if that's what the editor needs to do to make it friendly to people.

 

The editor should also be able to tell if it's pasting rich or plain text and can act accordingly.

 

So I'm not arguing that they did something bad to the editor. Maybe it's a good thing; I haven't edited enough in Evernote to tell yet. I'm just suggesting that there's a better place and way to make those changes, and then everybody is happy.

 

Because believe me, I'm the opposite of happy right now.

[Andrei Thorp 20]

For what it's worth, <div>s are extremely standard, perfectly supported in all browsers, and are extremely common to see in all sorts of webclips, articles, and pages. Overall, they're probably the most consistent and well-defined HTML elements. In effect, using <div>s instead of <p> tags is essentially the same as using <p> tags with manually set margins, as you suggested. Copy-paste compatibility is less of a concern, since copy-pastes tend to hop through an HTML->RTF conversion or an HTML->HTML conversion as they happen (i.e. it doesn't matter too much what our internal representation is, as long as the outside world sees things as it expects. Of course different programs expect different representations, but that's a different problem.)

 

That said, I'll consider our options some more, and I appreciate your thoughts. 

[E-NoteForum 107]

 

 This also applies to bullet lists. It's incredibly frustrating to have literally years' worth of notes suddenly change formatting and look broken. Users have relied on that formatting for years, and now the entirety of our note collection looks different than how we authored them.

Users have been complaining about that layout for years, too. It's one of the assumed complaints about EN - the way lists have spacing before/after them yet standard paragraphs don't. I've read the complaints about this so many times on this forum it's crazy! I'm beyond excited this is being fixed, as I think it's better and more consistent to have everything single-spaced from each other and add spacer lines as desired versus having some things single-spaced and some having block styling. Now to just get text-wrap...

 

Yeah, this is for sure the motivation for this change. I've been an avid Evernote user on many platforms for many years also, and it was always super strange to me how you'd have to remember to add newlines between paragraphs, but definitely avoid adding newlines between paragraphs and lists -- since lists automatically add space.

 

By text-wrap, do you mean text wrapping around floating images?

 

 What's worse, it's not even consistent with other versions of the app. If you create a note on iOS, for example, it still has the extra spacing. But when you look at it on Mac, the spacing is gone and the formatting is compressed. If you then add in extra line breaks on the Mac, the spacing is doubled on the iOS app, which looks terrible.

 

Surely it's not an intentional design decision to make notes look different on different platforms. Please tell me no one thinks that's actually a desirable feature.

This is easy to answer, and can be found on these forums as well - Evernote is developed platform-specific. Love it or hate it, but each team works on things not 100% parallel with each other. Evernote has 0 track record (as far as I know) of having core capabilities only on one platform (they might have a gap between implementations, but they all get everything eventually), so I wouldn't worry. Dollars to donuts, it will all be consistent eventually (according to track record).

 

Yep, you nailed this one too. I'm definitely working quite hard to try and improve the consistency of note editing/viewing between platforms.

 

 

It's not even that I'm passionate about having spacing around bullet lists or not; I don't really care either way, I just want it to be consistent. Visually, I like having space around bullet lists, but I'm perfectly fine doing that manually (how it must be done in the new editor).

 

Of course, that doesn't help when 4+ years of notes now suddenly have different formatting. That's inexcusable; pick something and stick with it so users can rely on a consistent set of rules.

 

I use the iOS and Mac apps equally, and it is now literally impossible to format something that looks how you want across platforms. The changes in the Mac client (which were only made in the Mac client?!) now mean my lists look stupid in either Mac or iOS. They either have double spacing or no spacing. Wasteful or cramped.

 

I fully support having different platform teams who develop the best version of the app for each platform's strengths and limitations. Lord knows I don't want my Mac app to look like a Windows client or have my iOS app look like Android. But that should not apply to the content of notes. The content itself should be treated as sacred data and be consistent across all platforms. It shouldn't matter where I'm viewing a note; if it's a note created in and viewed on Evernote, it should look the same in every Evernote client. That seems like a very obvious goal, and it seems that each client should be using the same markup for authoring notes.

[Andrei Thorp 20]

I fully support having different platform teams who develop the best version of the app for each platform's strengths and limitations. Lord knows I don't want my Mac app to look like a Windows client or have my iOS app look like Android. But that should not apply to the content of notes. The content itself should be treated as sacred data and be consistent across all platforms. It shouldn't matter where I'm viewing a note; if it's a note created in and viewed on Evernote, it should look the same in every Evernote client. That seems like a very obvious goal, and it seems that each client should be using the same markup for authoring notes.

 

Yeah, I agree. I will definitely keep working on making sure that editing and viewing is totally consistent going forward. You're right, users' formatting should be sacred.

[John Christopher Jones 29]

I totally respect that a lot of people expect a, more or less, RTF Wordpad/TextEdit-like experience with formatting.  I can appreciate that using non-semantic tags like div can give you that most easily.  However, I'm worried about third-party integration if my Evernote notes have less resemblance to standard semantic HTML.

 

There are some really neat third-party applications that will probably start to break down if the semantic markup falls away.  For example, I'm a huge fan of postach.io, which lets you blog directly from an Evernote notebook.  I use postach.io for my blog, vorpal.club.  Editors that convert markdown to Evernote notes might also have some trouble.

 

For example, writers tend to like to get as far away from fonts and font sizes as possible, focusing on structure—words, emphasis, paragraphs, headings, etc.  See, for example Byword (which publishes to Evernote), iA Writer, and nvAlt.  (I've also gotta plug bordaigorl's excellent Sublime plugin for Evernote.)  There's a huge market (at least among my followees) for these minimalist structural editors that I'd love to see Evernote embrace as a platform.

 

My ideal would be if paragraphs automatically put a full empty line of margin between themselves (markup: <p>first para</p><p>second para</p>), but I could hit ⌥⏎ to insert a line return within a paragraph (markup: <p>first para<br/>new line</p>).  This is very much how Microsoft Word works and close to what the resulting XML looks like, so it would boost compatibility with third party apps, including exporting/importing to Word, and give Evernote's editor some beautiful+fast editing oomph.

 

I haven't used Word on Windows in years, but I'm pretty sure there's an equivalent "force newline" keyboard shortcut (probably ⇧⏎ or ⌃⏎?), which you could use on the Web client to get perfect editing parity.

 

And, yeah, iOS and OS X are using very different stylesheets.  To demonstrate, here's a public notebook with a copy of a note that I publish on Postach.io:

https://www.evernote.com/pub/teluial/demo2

 

How I'd like the note to look is basically how appears on my blog.  On the beta web client the spacing is much less cramped than it appears in the OS X client.  This crampedness isn't really a change from 5.x to 6.x, but it's a rough platform difference.

[chirmer 567]

My ideal would be if paragraphs automatically put a full empty line of margin between themselves (markup: <p>first para</p><p>second para</p>), but I could hit ⌥⏎ to insert a line return within a paragraph (markup: <p>first para<br/>new line</p>).  This is very much how Microsoft Word works and close to what the resulting XML looks like, so it would boost compatibility with third party apps, including exporting/importing to Word, and give Evernote's editor some beautiful+fast editing oomph.

I totally see the point in this, but count me as a vote against. I like control in my note editor. I put a lot of CSS in my Evernote, and if I have to type ⌥ + Return every time I am editing code... count me out. And, how would this be implemented in mobile? To me, it makes the most sense—when considering implementation, consistency, and the end user—to have hitting Return render a single line down, and double-typing Return to insert a blank line when desired. This works on all platforms and gives the end user much more control over the appearance of their notes. Don't forget, Microsoft Word is a document formatting program—Evernote is an information repository. They shouldn't necessarily function the same way. Even Google Docs doesn't auto-margin paragraphs.

[Kevin Mitchell 19]

I tried an experiment with some html, forcing all the CSS style to be inline with a tool that applied a stylesheet. So the margins on my headings and paragraphs should be there, right? Wrong.

 

If I make an HTML file and drop it on Evernote, Evernote imports it, and it removes the margins from the inline styles. So they don't show.

 

If you want to see what I mean, look at this gist with the original HTML, and what it was after Evernote changed it: https://gist.github.com/kamitchell/e109d8ab9dd1a6005747

 

I think this can be considered a bug. It also means that we can't work around the changes to how Evernote displays notes by changing the way scripts create HTML.

 

Not that we should have to work around the HTML display problem anyway.

 

Submitted ticket #868549 for this one.

[Kevin Mitchell 19]

 

...

 

In short, I'm suggesting that if the editor wants elements to work differently, then it should style those elements individually rather than changing the default stylesheet for everything.

 

Thoughts?

 

 

I've queried the devs of all the other platforms to see what kinds of default spacing they're adding to notes. It is kind of inconsistent from place to place, but I'll work on improving that. Mac is the only platform currently that doesn't add space to these elements, so I feel like a compromise there is probably a good idea.

 

One of the good things about the new editor is that it doesn't use paragraph or heading tags itself (it does most formatting using <div>s instead). This means that I can potentially add some default spacing around <p> and <hX> without affecting notes that users type directly in the new editor. However, lists are still created as real HTML lists, so I won't add default spacing around them. Hopefully this is a good enough compromise for you.

 

 

Evernote 5 used <div> tags too. I checked. So I'm going to take back my comment about using structure in Evernote 6. It's not a change from 5. If I want structure, I'll use one of my other routes for getting things into Evernote.

 

I think basing off the usual HTML stylesheet defaults would help with imported material. Could the editor take the margins off the lists that users create, by adding inline styles to the <ol> or <ul> element?

[Andrei Thorp 20]

I tried an experiment with some html, forcing all the CSS style to be inline with a tool that applied a stylesheet. So the margins on my headings and paragraphs should be there, right? Wrong.

 

If I make an HTML file and drop it on Evernote, Evernote imports it, and it removes the margins from the inline styles. So they don't show.

 

If you want to see what I mean, look at this gist with the original HTML, and what it was after Evernote changed it: https://gist.github.com/kamitchell/e109d8ab9dd1a6005747

 

I think this can be considered a bug. It also means that we can't work around the changes to how Evernote displays notes by changing the way scripts create HTML.

 

Not that we should have to work around the HTML display problem anyway.

 

Submitted ticket #868549 for this one.

 

Thanks for that. I'll take a look. Still, this'll be largely handled if we do add automatic margins back.

[John Christopher Jones 29]

You guys are totally right: Evernote is already using <div>s. It's right there in the developer docs on plaintext. So, Evernote wouldn't be moving any further from semantic markup, which means third-party apps probably won't break.

So, I stand corrected.

[zexpe 5]

 

You're right, users' formatting should be sacred.

 

 

Thank you. I've had so many problems with Evernote upgrades messing with the formatting of my existing (1000s of) notes. It's very distracting from the content of the note if the formatting appears jarring because it was written in an older version of Evernote. When changing the default formatting of notes in Evernote, would it not be possible to ensure the older notes are still formatted in the same manner as they were before? i.e. if you remove blank spaces before and after lists, then you automatically re-insert them for the old notes, so that the old note formatting is preserved? If you don't do that then users' formatting is no longer sacred.

[E-NoteForum 107]

 

I fully support having different platform teams who develop the best version of the app for each platform's strengths and limitations. Lord knows I don't want my Mac app to look like a Windows client or have my iOS app look like Android. But that should not apply to the content of notes. The content itself should be treated as sacred data and be consistent across all platforms. It shouldn't matter where I'm viewing a note; if it's a note created in and viewed on Evernote, it should look the same in every Evernote client. That seems like a very obvious goal, and it seems that each client should be using the same markup for authoring notes.

 

Yeah, I agree. I will definitely keep working on making sure that editing and viewing is totally consistent going forward. You're right, users' formatting should be sacred.

 

 

Has there been any update on this? Just curious if the devs are working toward making formatting consistent between clients or not. Currently, iOS and Mac still have different spacing, which means your notes look incorrect on one platform at all times.

[Andrei Thorp 20]

 

 

I fully support having different platform teams who develop the best version of the app for each platform's strengths and limitations. Lord knows I don't want my Mac app to look like a Windows client or have my iOS app look like Android. But that should not apply to the content of notes. The content itself should be treated as sacred data and be consistent across all platforms. It shouldn't matter where I'm viewing a note; if it's a note created in and viewed on Evernote, it should look the same in every Evernote client. That seems like a very obvious goal, and it seems that each client should be using the same markup for authoring notes.

 

Yeah, I agree. I will definitely keep working on making sure that editing and viewing is totally consistent going forward. You're right, users' formatting should be sacred.

 

 

Has there been any update on this? Just curious if the devs are working toward making formatting consistent between clients or not. Currently, iOS and Mac still have different spacing, which means your notes look incorrect on one platform at all times.

 

 

It's going to take some time to make all these small details the same across the board, since we're working with so many different client teams. There has been a lot of progress on this (it's actually my main project right now), but I'll have to be quiet about the specifics for now.

[E-NoteForum 107]

Just checking in to see if we're any closer to consistent formatting across clients ...

[E-NoteForum 107]

P.S., FWIW I think at this point I prefer not having automatic margins around things. I like the cleanliness of the way that bullet points are handled in the Mac client, since you have more control over how the notes look. If you want the spacing, you can add it. If not, it can be collapsed and tight.

 

But consistency is the thing I'm most interested in.

[E-NoteForum 107]

It's going to take some time to make all these small details the same across the board, since we're working with so many different client teams. There has been a lot of progress on this (it's actually my main project right now), but I'll have to be quiet about the specifics for now.

 

It doesn't seem like there has been any public-facing progress on this issue in the 6 months since it was discussed here. Are there any updates?

[Andrei Thorp 20]

 

It's going to take some time to make all these small details the same across the board, since we're working with so many different client teams. There has been a lot of progress on this (it's actually my main project right now), but I'll have to be quiet about the specifics for now.

 

It doesn't seem like there has been any public-facing progress on this issue in the 6 months since it was discussed here. Are there any updates?

 

 

Yep, for sure. For example, the latest Windows betas have had an updated editing experience that's basically identical to the Mac editing experience now (with a few kinks still being ironed out). My team is continuing to work on it.

[E-NoteForum 107]

Gotcha, thanks for the update! And sorry for the vague question; I was inquiring about the topic of note content being preserved and displayed consistently across platforms (the example from this thread being spacing automatically being added around bullet lists but not on Mac, making for different-looking content based on platform).

[Andrei Thorp 20]

Gotcha, thanks for the update! And sorry for the vague question; I was inquiring about the topic of note content being preserved and displayed consistently across platforms (the example from this thread being spacing automatically being added around bullet lists but not on Mac, making for different-looking content based on platform).

 

Yeah, for sure. That's why it's a big deal that we're rolling out this new beta editor on Windows right now. It means that the same editor that's being used to edit and display notes on Mac will be used on Windows. We think this'll make formatting differences largely disappear, at least between these two clients. The one exception would be the default font, which varies by platform -- but that's a feature.

[JMichaelTX 4,117]

The one exception would be the default font, which varies by platform -- but that's a feature.

 

Which, IMO, is a good feature.

 

For some reason due to the differences in the way Windows and Mac display fonts, I have found that Verdana 14pt on the Mac is about the same as Verdana 12pt on Windows.  So I have set my EN default fonts accordingly.

 

For the most part, the EN iOS display (of Notes from EN Mac/Win) comes across OK.  But I wish we could set default font in EN iOS, and control/change fonts.

[Andrei Thorp 20]

 

The one exception would be the default font, which varies by platform -- but that's a feature.

 

Which, IMO, is a good feature.

 

For some reason due to the differences in the way Windows and Mac display fonts, I have found that Verdana 14pt on the Mac is about the same as Verdana 12pt on Windows.  So I have set my EN default fonts accordingly.

 

For the most part, the EN iOS display (of Notes from EN Mac/Win) comes across OK.  But I wish we could set default font in EN iOS, and control/change fonts.

 

 

Yeah. On Mac, we actually use pixel fonts, and 14px = 14pt. However, on Windows, 14px actually equals about 12pt, as you noticed.

 

Now, you might say, "what? why? what?"

 

Basically, Microsoft made some very questionable decisions a long time ago, and now they're stuck with them. You can read more about it here -- https://www.evernote.com/shard/s20/sh/9d99a8ee-3cb0-4e3d-9b6f-99d3984ff5f9/16a6c350d856f24a-- which I clipped directly from the Microsoft Developer Network.

 

With respect to iOS font settings -- noted.

[zexpe 5]

 

Gotcha, thanks for the update! And sorry for the vague question; I was inquiring about the topic of note content being preserved and displayed consistently across platforms (the example from this thread being spacing automatically being added around bullet lists but not on Mac, making for different-looking content based on platform).

 

Yeah, for sure. That's why it's a big deal that we're rolling out this new beta editor on Windows right now. It means that the same editor that's being used to edit and display notes on Mac will be used on Windows. We think this'll make formatting differences largely disappear, at least between these two clients.

 

 

I'm still waiting for the iOS and OS X versions to be consistent with treatment of bullet list spacing. Surely, these two platforms are the easiest to make consistent to each other in this respect?

[E-NoteForum 107]

Ditto.

[E-NoteForum 107]

Just pinging this thread to see if there's an update or ETA on Mac/iOS consistency with block spacing.

[E-NoteForum 107]

Is the effort to unify iOS and OS X display still in progress, or has it been abandoned?

Notes still aren't consistent between OS X 6.4 and iOS 7.9.2.

[Andrei Thorp 20]

23 hours ago, E-NoteForum said:

Is the effort to unify iOS and OS X display still in progress, or has it been abandoned?

Notes still aren't consistent between OS X 6.4 and iOS 7.9.2.

Hello sir,

Yes, we're still working on it. It's not as simple as it sounds -- a pre-requisite is a big overhaul of a lot of the editor code. I've been going through that with my team for the last year and a half.

Sorry, I know that's not super satisfying -- but yes, we're still actively working on it, as part of the larger editor project.