W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] Should editable elements have placeholder attribute?

From: Ojan Vafai <ojan@chromium.org>
Date: Thu, 13 Sep 2012 14:04:13 -0700
Message-ID: <CANMdWTvGVuguqLJ+u=_oO92oWnFntbGCud1ADaqo00bTJaRcow@mail.gmail.com>
To: Aryeh Gregor <ayg@aryeh.name>
Cc: whatwg <whatwg@lists.whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, James Graham <jgraham@opera.com>
On Fri, Sep 7, 2012 at 6:03 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Thu, Sep 6, 2012 at 6:30 PM, Tab Atkins Jr. <jackalmage@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
> [contenteditable=true].  But I don't think that works right if there's
> leading or trailing whitespace or similar.  In theory, this might do
> the trick:
>
>   :read-only > :read-write { min-height: 1em; }
>
> except that WebKit doesn't let editability affect
> :read-only/:read-write, because it uses a CSS property to track
> editability.  (Gecko uses a per-node boolean flag and just iterates
> through ancestors when necessary.)
>
> Also, :empty won't help if there's a child that's only whitespace, like
>
>   <div contenteditable>
>   </div>
>
> or
>
>   <div contenteditable> </div>
>
> which would be a case we'd want to handle.  But if you omit the
> :empty, it would break if there were smaller-than-usual text.
>
> Also, 1em isn't the same as if you put some text in it.  Generally,
> typing some text is supposed to create a <p>, which might make it
> substantially taller than 1em depending on margin collapsing, right?
> You'd know this better than me.
>
> So I don't think this would be so trivial to spec.  If you can come up
> with something that works, I'm all ears!
>
> On Thu, Sep 6, 2012 at 6:53 PM, Ojan Vafai <ojan@chromium.org> wrote:
> > While WebKit does put the magic <br> in, that's not what avoids the
> > collapsing in this case. If you set the innerHTML to "", it still doesn't
> > collapse. We actually hard-code that editing hosts don't collapse.
>
> I know -- this is the non-standard special case I referred to.  :)
> This is technically not per spec at present, but I wouldn't object to
> standardizing it if it can be done reasonably.  The only thing is, I'm
> not sure it can be.  I'm not convinced that hardcoding editing logic
> into CSS is a good idea unless it's needed for web compat, which I
> imagine it's not, because Gecko doesn't do it.
>
> But on the other hand, it looks like everyone but Gecko does do it,
> although I'm sure the details are totally different.  And it's
> certainly nice for usability.  So it would be nice if we had some good
> way to spec it.  I wonder if Opera does it in a saner-to-spec way.
>

The way I'd want to see this happen is to expose a CSS property that
prevents collapsing empty elements, then we'd add something like the
following to the UA stylesheet:
*[contentEditable=true] { empty-collapse-behavior: no-collapse }
Received on Thursday, 13 September 2012 21:05:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC