550186 - HTML 5 'placeholder' attribute should be used instead of 'emptyText'

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, enhancement)

Description

[Robert Kaiser]

+++ This bug was initially created as a clone of Bug #547224 +++

The XUL emptyText attribute looks to behave the same as HTML 5 placeholder attribute. Maybe the placeholder attribute should be used instead of emptyText.

Comment 1

[Dão Gottwald [:dao]]

This isn't going to affect performance, since emptyText now uses placeholder internally.

Comment 2

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #1)
> This isn't going to affect performance, since emptyText now uses placeholder
> internally.

Are we missing something from the changes made in bug 547224? Do we need to change emptytext -> placeholder everywhere? Is this bug about that (note: summary says "should", not "needs to" and Importance is Enhancement)? We use emptytext in various windows (e.g. History, Bookmark Manager, MailNews search box, ...); the Help window looks OK, probably since it's from Toolkit.

Additionally this is what I get in recent SM trunk nightlies:

Warning: Unknown pseudo-class or pseudo-element '-moz-placeholder'.  Ruleset ignored due to bad selector.
Source File: chrome://global/content/textbox.css
Line: 17

Warning: Unknown pseudo-class or pseudo-element '-moz-placeholder'.  Ruleset ignored due to bad selector.
Source File: chrome://global/content/textbox.css
Line: 23

Comment 3

[Robert Kaiser]

(In reply to comment #2)
> Are we missing something from the changes made in bug 547224? Do we need to
> change emptytext -> placeholder everywhere? Is this bug about that (note:
> summary says "should", not "needs to" and Importance is Enhancement)? We use
> emptytext in various windows (e.g. History, Bookmark Manager, MailNews search
> box, ...); the Help window looks OK, probably since it's from Toolkit.

We're not really "missing" something from bug 547224, but we should follow and do the same on our side (note the *should*, I've been told over there that emptytext should continue to work for now, but placeholder is the more standard way to do it now). From all I know, this applies to all our usages of emptytext.

> Additionally this is what I get in recent SM trunk nightlies:

See recent comment(s) in bug 547224, it's a general problem.

Comment 4

[Stefan [:stefanh]]

Since this is 1.9.3, I suppose we could either do this now (and leave out the stuff we share with thunderbird) or do both apps at the same time later on.

Comment 5

[Robert Kaiser]

Stefan, I intentionally filed this against SeaMonkey, as we should do this on all our own code (which is 1.9.3-bound anyhow) as soon as we get around to it.

Thunderbird should care about it in their own bug.

Comment 6

[Stefan [:stefanh]]

Attachment: Switch to placeholder

I didn't touched abCardOverlay.xul and emailWizard.xul since they're shared.

Comment 7

[Stefan [:stefanh]]

http://hg.mozilla.org/comm-central/rev/386d5b686699

Comment 8

[Cédric Corazza]

Hum: I'm not a dev, just a localizer, and I didn't see the rationale about changing the strings name here, as there is no semantic changes.

Comment 9

[Stefan [:stefanh]]

I actually considered not changing the entity names since it would affect localizers. But since they actually describe the attribute itself (xx.emptytext), and I switch to another attribute (xx.placeholder), I think it made sense changing them.