On Thu, 6 Sep 2012, Aryeh Gregor wrote:
It should never be possible to make a contenteditable element contain
nothing, once it has something in it, because then it would collapse to
zero height and you wouldn't be able to click on it. [...]
On Thu, 6 Sep 2012, Ojan Vafai wrote:
While
On Fri, Sep 7, 2012 at 6:03 AM, Aryeh Gregor a...@aryeh.name wrote:
On Thu, Sep 6, 2012 at 6:30 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Note that this shouldn't be hard to do without magic. Just something
like this in the UA style sheet:
[contenteditable]:empty { min-height:
On Thu, Sep 6, 2012 at 6:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that this shouldn't be hard to do without magic. Just something
like this in the UA style sheet:
[contenteditable]:empty { min-height: 1em; }
contenteditable is not a boolean attribute -- you'd need to do
On Sat, Sep 1, 2012 at 4:22 AM, David Young dyo...@pobox.com wrote:
This demonstrates some unexpected contenteditable results on
Chrome 21.0.1180.82 under Mac OS X. I cannot seem to return the
contenteditable to the empty state again---i.e., to the state where the
placeholder shows---using
On Thu, Sep 6, 2012 at 3:56 AM, Aryeh Gregor a...@aryeh.name wrote:
It should never be possible to make a contenteditable element contain
nothing, once it has something in it, because then it would collapse
to zero height and you wouldn't be able to click on it. (IIRC, some
browsers have
On Thu, Sep 6, 2012 at 3:56 AM, Aryeh Gregor a...@aryeh.name wrote:
On Sat, Sep 1, 2012 at 4:22 AM, David Young dyo...@pobox.com wrote:
This demonstrates some unexpected contenteditable results on
Chrome 21.0.1180.82 under Mac OS X. I cannot seem to return the
contenteditable to the empty
On Wed, Aug 29, 2012 at 4:27 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 17 Jun 2012, Aryeh Gregor wrote:
On Thu, Jun 14, 2012 at 1:11 AM, Ian Hickson i...@hixie.ch wrote:
I strongly disagree. input and textarea are high-level constructs,
so it's fine for them to be defined by the UA's
On Thu, Aug 30, 2012 at 11:44:46AM +0300, Jussi Kalliokoski wrote:
On Thu, Aug 30, 2012 at 11:43 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
It's pretty simple to make a naive placeholder for contenteditable
elements with CSS:
[contenteditable]:not(:focus):empty::after {
It's pretty simple to make a naive placeholder for contenteditable elements
with CSS:
[contenteditable]:not(:focus):empty::after {
content: attr(data-placeholder);
color: #ccc;
}
I call it a bit naive because it turns out that if you have insert a line
break in the box, there
On Thu, Aug 30, 2012 at 11:43 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
It's pretty simple to make a naive placeholder for contenteditable
elements with CSS:
[contenteditable]:not(:focus):empty::after {
content: attr(data-placeholder);
color: #ccc;
}
I
On Sun, 17 Jun 2012, Aryeh Gregor wrote:
On Thu, Jun 14, 2012 at 1:11 AM, Ian Hickson i...@hixie.ch wrote:
I strongly disagree. input and textarea are high-level constructs,
so it's fine for them to be defined by the UA's platform. But
contenteditable is a very low-level primitive. We
On Thu, Jun 14, 2012 at 1:11 AM, Ian Hickson i...@hixie.ch wrote:
I strongly disagree. input and textarea are high-level constructs, so
it's fine for them to be defined by the UA's platform. But contenteditable
is a very low-level primitive. We can't just punt on how it interacts with
CSS;
On Wed, Jun 13, 2012 at 10:11:26PM +, Ian Hickson wrote:
On Wed, 2 May 2012, Alfonso Mart?nez de Lizarrondo wrote:
Recently I wrote such a plugin for CKEditor, it can be tested here:
http://alfonsoml.blogspot.com.es/2012/04/placeholder-text-in-ckeditor.html
I don't think that too
On Tue, 1 May 2012, Ryosuke Niwa wrote:
Would it be useful to have placeholder content attribute on elements
that are editable? (i.e. contenteditable=true).
According to the original WebKit bug 21286, this may reduce the amount
of code authors have to write.
contenteditable= is a
On Wed, May 2, 2012 at 8:00 AM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
Would it be useful to have placeholder content attribute on elements that
are editable? (i.e. contenteditable=true).
According to the original WebKit bug
21286https://bugs.webkit.org/show_bug.cgi?id=21286,
this may
On Tue, May 1, 2012 at 11:09 PM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, May 2, 2012 at 8:00 AM, Ryosuke Niwa rn...@webkit.org wrote:
Would it be useful to have placeholder content attribute on elements that
are editable? (i.e. contenteditable=true).
According to the original WebKit
On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote:
Great. I think the tricky part will be defining exactly how and when the
placeholder is displayed.
e.g. Should it be treated as if there is a text node in the editable
element? Should we ignore things like br or collapsible
On Wed, May 2, 2012 at 3:02 AM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote:
Great. I think the tricky part will be defining exactly how and when the
placeholder is displayed.
e.g. Should it be treated as if there is a text node
On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai o...@chromium.org wrote:
I'm OK with having when the placeholder is displayed be up to the UA. I
can see that being platform specific.
But, we should spec when content is eligible for showing a placeholder
(i.e. we should define what looks empty
On 5/2/12 10:08 AM, Ryosuke Niwa wrote:
On Wed, May 2, 2012 at 10:06 AM, Ojan Vafaio...@chromium.org wrote:
I'm OK with having when the placeholder is displayed be up to the UA. I
can see that being platform specific.
But, we should spec when content is eligible for showing a placeholder
On Wed, May 2, 2012 at 10:15 AM, Charles Pritchard ch...@jumis.com wrote:
On 5/2/12 10:08 AM, Ryosuke Niwa wrote:
On Wed, May 2, 2012 at 10:06 AM, Ojan Vafaio...@chromium.org wrote:
I'm OK with having when the placeholder is displayed be up to the UA. I
can see that being platform
On Wed, May 2, 2012 at 10:08 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai o...@chromium.org wrote:
I'm OK with having when the placeholder is displayed be up to the UA. I
can see that being platform specific.
But, we should spec when content is
On Wed, May 2, 2012 at 10:49 AM, Ojan Vafai o...@chromium.org wrote:
textContent will strip a bunch of visible content (images, iframes,
embeds, etc.).
Another edge case to consider:
div contentEditable placeholder=foodiv
style=background-color:red;width:100px;height:100px/div/div
Should
On Wed, May 02, 2012 at 01:02:10PM +0300, Aryeh Gregor wrote:
On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote:
Great. I think the tricky part will be defining exactly how and when the
placeholder is displayed.
e.g. Should it be treated as if there is a text node in the
FWIW:
Recently I wrote such a plugin for CKEditor, it can be tested here:
http://alfonsoml.blogspot.com.es/2012/04/placeholder-text-in-ckeditor.html
I don't think that too many people request this feature, but that might be
simply because there are other bigger problems and they don't want to
Hi,
Would it be useful to have placeholder content attribute on elements that
are editable? (i.e. contenteditable=true).
According to the original WebKit bug
21286https://bugs.webkit.org/show_bug.cgi?id=21286,
this may reduce the amount of code authors have to write.
Best,
Ryosuke Niwa
Software
26 matches
Mail list logo
