Placeholder for editable regions

[okaybmd]

Hi!

I've seen that you patched this issue but I think we need a placeholder text too. On a regular HTML input field, you have the placeholder attribute. For instance, you can have this code:

<input type='text' name='username' value='' placeholder='Please enter a username'>

The code above will display a faded text on the field. When the user clicks the field, the placeholder text will still be shown and only disappear if the user types something. When the user deletes everything again, the placeholder text will be shown again. This would be very beneficial to have in Content Tools too :)

To be more specific, here's the kind of usage that I'm looking for:

<div class="article-title" data-editable data-name="article-title" data-placeholder-type="h1" data-placeholder="Enter a title here">

So data-placeholder-type AND a data-placeholder on a data-editable div would be awesome :D

---

Also, i noticed a small bug for the issue mentioned above (#180): if you have an element like this:

<div class="article-title" data-editable data-name="article-title" data-placeholder-type="h1">

and you delete all the text, there will be a new empty <h1> added (which was the whole purpose of that enhancement), but if you click on another editable element in the page, such as:

<div id="article-content" class="article-content" data-editable data-name="article-content">

then it will reset back to a <p> element.

Thanks for your time and keep up the great job :)

[anthonyjb]

Hi @okaybmd - this should actually already be possible. The new functionality added allows you to control the element inserted and ContentEdit supports a data-ce-placeholder attribute that lets you set the placeholder content of the element as you describe it, so for example to implement what you're asking for you might use:

var editorCls = ContentTools.EditorApp.getCls();

editorCls.prototype.createPlaceholderElement = function(region) {
    var type = region.domElement().getAttribute('data-placeholder-type');
    var placeholderText = region.domElement().getAttribute('data-placeholder');
    return new ContentEdit.Text(
        type || 'p', 
        {'data-ce-placeholder': placeholderText || ''}, 
        '');
};

However this isn't ideal as the placeholder attribute will remain against the child element and ideally it would be better if it was taken from the parent not the child.

I'll take a look at the bug you mentioned and confirm it, and I agree this feature should be improved upon a long the lines you have mentioned moving forward so will flag this as an enhancement.

[okaybmd]

Ok, thanks a lot for your reply :)

So, in order to reproduce the bug, you have to edit the first field, delete all its contents (leave it empty, so a new <h1> will be created), and then click on a different editable region right after you deleted all the text in the first one. That <h1> will be replaced with a <p> element instead of staying a <h1>.

[okaybmd]

I noticed your error in your comment before you fixed it :) (it should have been || not "or")

The thing is, the code above still doesn't work as expected. It still shows "..." (3 dots) while you're still focused on the field if it's empty (instead of the new placeholder). The placeholder is shown after you unfocus the field though.

I also noticed that starting the 2nd time you're focusing on that field, it does behave properly (well, except the things connected to the bug mentioned above: it will turn into a <p> instead of an <h1>, and it's very noticeable in my environment because of the line height difference)

[okaybmd]

And thanks again for all your help! I hope I wasn't bothering you too much. It's great that you marked this as an enhancement, but take your time. I don't need this right away, but it will be useful for other in the long run too. Take care :)

[anthonyjb]

OK will take a look at this tomorrow and see if I can provide a more concrete example, I admit I haven't tried the code I posted I was coding out loud (I'm too used to writing coffeescript so ors tend to slip in), as I mentioned I don't think this is the ideal approach either.

The 3 dots you see as placeholders are added using the same CSS as we're attempting to use to set the custom placeholder (https://github.com/GetmeUK/ContentEdit/blob/master/src/styles/content-edit.scss#L155). I'm wondering if the created empty tag isn't getting the placeholder, I'm sure more will be revealed once I look into the bug you reported re. h1s becoming p tags, but at the point the 3 dots show does the element in question have the data-ce-placholder attribute applied to it?

[anthonyjb]

Not a bother I'm glad of the feedback :)

[okaybmd]

We replied at the same time :)

No, is that even an attribute? Wasn't it supposed to be data-placeholder? Because I tried with data-ce-placeholder and it didn't work.

This is what I'm using:

<div class="article-title" data-editable data-name="article-title" data-placeholder="Enter a title"><h1>Title 01</h1></div>

So this works fine on the second time you write in that region ;)

[anthonyjb]

OK this makes more sense now, so data-ce-placholder is the attribute that needs to be used to set the placeholder currently (baring changes we will make). The code I specified adds the value of data-placeholder against the region tag to the value of data-ce-placeholder against the first child tag for the region created by createPlaceholderElement.

However you're adding your own initial tag currently, e.g <h1>Title 01</h1>, so this either needs to be removed initially so that the region creates the first empty tag or you need to set a placeholder attribute directly against it such as <div class="article-title" data-editable data-name="article-title" data-placeholder="Enter a title"><h1 data-ce-placeholder="Enter a title">Title 01</h1></div>.

As I say this isn't idea but at least it explains the first time second time behaviour you're seeing (I think).

[anthonyjb]

BTW any official data- attributes for CT or CE are namespaced -ct- and -ce- to prevent clashes with other libraries (we've seen these in the past, data-tooltip the most recent one I can remember). However the createPlaceholderElement allows you to use whatever you want interms od data- tags as you define what attributes to look for.

[okaybmd]

Ok, thanks for all of this :)

I tried adding <h1 data-ce-placeholder="Enter a title"> and looks fine now.

I also realized that I forgot to add data-placeholder-type="h1" in the example above (I was testing with 2 different files, so it's my bad). However, even with the fixed div:

<div class="article-title" data-editable data-name="article-title" data-placeholder="Enter a title" data-placeholder-type="h1"><h1>Title 01</h1></div>

The problem of "..." persists on the first focus. EDIT: with your latest code is fine: <div class="article-title" data-editable data-name="article-title" data-placeholder="Enter a title" data-placeholder-type="h1"><h1 data-ce-placeholder="Enter a title">Title</h1></div>

---

Regarding the bug: I've further investigated, and it seems that it does NOT convert to a <p> while you're still focused on the field and is empty, but the cursor will MOVE a few pixels below, looking like a <p> on my environment, this is why I ASSUMED it was a <p>. Here's a screenshot for what I mean by this: image

So not an issue as big as I thought.

CONCLUSION: it's still a <h1>, not a <p>, but for whatever reason, the cursor is moved a few pixels below.

[okaybmd]

Last edit (new screenshot): http://imgur.com/a/iMjvW - even in the updated and fixed version, the cursor position issue is still present. I'll stop bothering you now, I promise :)

[anthonyjb]

The cursor position discrepancy you are seeing is down to how browsers treat an empty contenteditable element. Funnily enough the reason I added :after elements initially was to solve a problem where some browsers (such as Firefox) completely collapsed some elements if empty (such as list items) - which looks very odd.

So to help try and look at this can you tell me what browser you're using and also provide me with the CSS styles associated with your header so I can reproduce the issue. I ask because I don't see this cursor/carat position discrepancy using Chrome to edit the content of the sandbox.html file in the repo.

[okaybmd]

Hi Anthony :)

Ok, so I have removed everything, left with the barebone of the CSS files too, and found the issue. It was the stupid font (named "Poppins")! It works absolutely fine with Arial... So it's totally my fault... I have attached an edited sandbox folder so you can play with it to see how it looked like.

[okaybmd]

Edit: I can't upload a zip file, it says Unfortunately, we don’t support that file type. Choose Files Try again with a PNG, GIF, JPG, DOCX, PPTX, XLSX, TXT, PDF, or ZIP. But it is a zip! AAAAH!

So I've uploaded the file here: http://www.filedropper.com/contenttools-edit

Thanks again for all you've done :)

2nd edit: I'm using Chrome too (Version 51.0.2704.103 m) on Windows 7.

[anthonyjb]

@okaybmd thanks very much for all your detailed feedback - really useful :+1: