Closed Bug 550186 Opened 10 years ago Closed 10 years ago

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

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.1a1

People

(Reporter: kairo, Assigned: stefanh)

References

Details

Attachments

(1 file)

+++ 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.
This isn't going to affect performance, since emptyText now uses placeholder internally.
Keywords: perf
(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
(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.
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.
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.
I didn't touched abCardOverlay.xul and emailWizard.xul since they're shared.
Assignee: nobody → stefanh
Status: NEW → ASSIGNED
Attachment #431680 - Flags: superreview?(neil)
Attachment #431680 - Flags: review?(neil)
Attachment #431680 - Flags: superreview?(neil)
Attachment #431680 - Flags: superreview+
Attachment #431680 - Flags: review?(neil)
Attachment #431680 - Flags: review+
http://hg.mozilla.org/comm-central/rev/386d5b686699
Target Milestone: --- → seamonkey2.1a1
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
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.
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.
You need to log in before you can comment on or make changes to this bug.