Closed Bug 1024642 Opened 11 years ago Closed 11 years ago

Map "rebeccapurple" to #663399 in named color list.

Categories

(Core :: CSS Parsing and Computation, enhancement)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla33

People

(Reporter: jjdsampson, Assigned: automatedtester)

References

(
URL
)

Details

(Keywords: dev-doc-complete)

Attachments

(5 files, 3 obsolete files)

Update devtools source editor and test to add rebeccapurple
5.30 KB, patch
jwalker
: review+
Details | Diff | Splinter Review
Update layout tests to incorporate rebeccapurple a color in element properties
11.10 KB, patch
dbaron
: review+
Details | Diff | Splinter Review
Add rebeccapurple to mochitest colors
951 bytes, patch
jmaher
: review+
Details | Diff | Splinter Review
Add in rebeccapurple to color lists in gfx
1.21 KB, patch
automatedtester
: review+
Details | Diff | Splinter Review
Remove extra white space from files, no functional changes
7.18 KB, patch
automatedtester
: review+
Details | Diff | Splinter Review
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 Steps to reproduce: I set color of element to "beccapurple". A movement is presently happening in the developer community that wishes to remember the daughter of Eric Meyer by immortalizing her under her favorite color purple. A hashtag was created on twitter (#663399Becca) to remember her, and the other children whose lives have been taken by cancer and other illnesses. A similar issue has been opened for WebKit (https://bugs.webkit.org/show_bug.cgi?id=133804), and the request is being taken to IE presently as well. Actual results: The color was #000000. Expected results: The color should be #663399.
This has also been requested at http://lists.w3.org/Archives/Public/www-style/2014Jun/0129.html, and is finding extensive support from the community here: http://discourse.specifiction.org/t/name-663399-becca-purple-in-css4-color/225.
Severity: normal → enhancement
OS: Mac OS X → All
Hardware: x86 → All
Webkit bug, including patch: https://bugs.webkit.org/show_bug.cgi?id=133804
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
Version: unspecified → Trunk
Assignee: nobody → dburns
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee: dburns → nobody
(In reply to David Burns :automatedtester from comment #4) > Took a stab at this, I have updated what I think are the right things and > have pushed to try https://tbpl.mozilla.org/?tree=Try&rev=440ea0751d6c. Any > and all feedback is appreciated. (nit: looks like a good fraction (maybe the majority?) of the changes in your Try push are whitespace-fixes, probably from something in your .hgrc or editor that's auto-fixing-up all the end-of-line whitespace in any file that you touch. Ideally, those fixes should be split out into their own patch, so that they don't obscure what the actual changes are here.)
First: amazing work, guys. Web standards is a new enough field where we get to decide exactly what it’s going to be, and it’s hard to imagine better than this. I’m proud to be able to play a part, no matter how tiny. We’d like to hold off on shipping this anywhere until we hear back from Eric, for obvious reasons. A few of us will be working to coordinate with the other browsers; we’ll give the word here. Thank you all.
oops. sorry about that. Will redo patch when I see what breaks on try.
(Sorry, wrote this before Mat's comment above and then collided, but I figure it's worth adding.) I'd like to wait on this until we know that Eric and Kat support doing this. I believe someone else in the CSS WG is planning to ask Eric tomorrow, so please don't all go asking.
There's a lot of support for this because everyone is too nice. Turning the CSS named color list into a permanent memorial, and thus setting the precedent that people can ask to be memorialized in it, will forever turn this feature into something it's not supposed to be. If this color was added with a name that was not a direct memorial; i.e. some purple-y name without "Becca" in it, then this would be less of a risk. Sticking names of loved ones throughout specs could eventually become an ever increasing problem. That being said, nobody is likely to oppose this too heavily.
I have to agree with Bob. I don't see why a project like Mozilla would allow an emotional response to work its way into actual code, and I think it's dangerous precedent. We don't need in-jokes, easter eggs, or memorials in established web standards, and I think it's irresponsible to suggest that this is the right course of action. This change does not make rational sense, and it's likely going to be a head scratcher years from now, and there's way more appropriate ways of grieving and memorializing people than in CSS color names. I think people need to put their emotions aside to figure out that this is a Really Bad Idea(tm).
This is not the appropriate venue for +1/-1 comments, in particular those based on vague “slippery slope” predictions. Perhaps, as you want, we should keep this a strictly technical and by-the-books web standards discussion: In the priority of constituencies, an overarching guide to the adoption of new web standards, the “theoretical purity” that you’ve cited here is the bottom-most priority. There is no practical cost to users with the addition of this single feature—and we are, since we cannot tell the future from a single data point, discussing one (1) color keyword here. There is significant demand from authors, and immediate willingness from implementers—the second and third priorities. Web standards is fundamentally and primarily concerned with _people_—users and authors—and that theoretical purity is the absolute lowest priority by comparison. I might, if you’re certain action is called for to stave off the inevitable decline of something so critical as CSS color keywords, suggest you start taking proactive steps toward the removal of “papayawhip” in order to maintain equilibrium. I’m happy to help you get started with the necessary paperwork. Since you feel so strongly about this that it’s worth down-voting this _tiny_ tribute for the sake of someone who has has done so much for CSS itself and for the establishment of the careers we’re able to enjoy, I assume we’ll see you putting in some real effort and hours in making web standards a more theoretically-pure place. Please, let me know how you’d like to get involved. There’s plenty to do.
(In reply to Mat Marquis from comment #11) > This is not the appropriate venue for +1/-1 comments, in particular those > based on vague “slippery slope” predictions. Perhaps, as you want, we should > keep this a strictly technical and by-the-books web standards discussion: > > In the priority of constituencies, an overarching guide to the adoption of > new web standards, the “theoretical purity” that you’ve cited here is the > bottom-most priority. There is no practical cost to users with the addition > of this single feature—and we are, since we cannot tell the future from a > single data point, discussing one (1) color keyword here. There is > significant demand from authors, and immediate willingness from > implementers—the second and third priorities. > > Web standards is fundamentally and primarily concerned with _people_—users > and authors—and that theoretical purity is the absolute lowest priority by > comparison. I might, if you’re certain action is called for to stave off the > inevitable decline of something so critical as CSS color keywords, suggest > you start taking proactive steps toward the removal of “papayawhip” in order > to maintain equilibrium. I’m happy to help you get started with the > necessary paperwork. > > Since you feel so strongly about this that it’s worth down-voting this > _tiny_ tribute for the sake of someone who has has done so much for CSS > itself and for the establishment of the careers we’re able to enjoy, I > assume we’ll see you putting in some real effort and hours in making web > standards a more theoretically-pure place. > > Please, let me know how you’d like (In reply to Mat Marquis from comment #11) > This is not the appropriate venue for +1/-1 comments, in particular those > based on vague “slippery slope” predictions. Perhaps, as you want, we should > keep this a strictly technical and by-the-books web standards discussion: > > In the priority of constituencies, an overarching guide to the adoption of > new web standards, the “theoretical purity” that you’ve cited here is the > bottom-most priority. There is no practical cost to users with the addition > of this single feature—and we are, since we cannot tell the future from a > single data point, discussing one (1) color keyword here. There is > significant demand from authors, and immediate willingness from > implementers—the second and third priorities. > > Web standards is fundamentally and primarily concerned with _people_—users > and authors—and that theoretical purity is the absolute lowest priority by > comparison. I might, if you’re certain action is called for to stave off the > inevitable decline of something so critical as CSS color keywords, suggest > you start taking proactive steps toward the removal of “papayawhip” in order > to maintain equilibrium. I’m happy to help you get started with the > necessary paperwork. > > Since you feel so strongly about this that it’s worth down-voting this > _tiny_ tribute for the sake of someone who has has done so much for CSS > itself and for the establishment of the careers we’re able to enjoy, I > assume we’ll see you putting in some real effort and hours in making web > standards a more theoretically-pure place. > > Please, let me know how you’d like to get involved. There’s plenty to do. I understand that Matt, but this is not a technical issue to begin with, yet it's presented as one here in a bug tracker. I also think your arguments are rather fallacious. You cannot argue that it's OK to add a CSS color name that makes no sense, because some other colors already exist and they don't make a lot of sense. I can guess that 'papayawhip' is a similar color to whipped papaya, it's not hard to imagine. beccapurple has NO objective meaning whatsoever, other than it's a shade of purple. That alone should be significant reason to be against it. Also when "standards" are implemented by claiming "bugs" when no actual bugs exist, that's how we get into web compatibility standards issue. So much time is wasted making web technologies work in many different browsers, and all it takes is one to not implement this to cause it to be a headache to a developer later on. This is not a "slipperyu slope" argument, we have been battling web standard issues for the entire history of the web, and there is a practical cost to this. I do feel strongly about this because this decision is fueled ONLY by emotion, not by logic. I'd love to get involved in standards creation, just not when decisions are based off of what makes you feel good rather than what's actually right.
Tell me Jay P, what specific color does "DodgerBlue" bring to mind? How about "Gainsboro"? The color names are not sharpened discovery tools, and many of them are so culturally skewed as to be irrelevant to a global audience. Your own argument is rather fallacious.
Quick, somebody tell me what the HEX for AliceBlue or BlanchedAlmond is. You likely cannot. You know it's some shade of blue, and some almond-color shade, but you're not likely to instinctively hammer out the HEX for any one of these. The fact that "BeccaPurple" isn't as explicit as RGB or HEX is irrelevant - it is no way a deviation from the semantic-criteria that has gone before us to determine an appropriate name. Is this request emotion-driven? Absolutely. Eric has had a profound and undeniable influence on this community. His efforts have emotionally-aroused many young developers, myself included, and driven them to find careers and satisfaction in a budding industry. His thankless sacrifices and innumerable contributions have brought web-development to heights that others found difficult to imagine possible. Mankind has, all throughout history, immortalized and acknowledged trailblazers and influencers. I see no reason why our industry is any different. When I update Opera, I am reminded that the software is build "In memory of Geir Ivarsøy." I find these artifacts as humanizing the experience. There are [real people] making [real sacrifices] to bring us to where we are today. You are certainly free to keep emotion out of this industry; I am not compelled to do so.
new try https://tbpl.mozilla.org/?tree=Try&rev=18a7164c7237 cleaning up test failures. Any/All feedback welcome. Rev 18a7164c7237 in try is the change and 0d9615d12a16 in try is white space cleanup in those files.
Tim, Gainsboro is a color scheme that came from X11, DodgerBlue is the color of the Dodgers, none of these colors originated in CSS. To say that I do not support the use of technical specifications for emotional memorializations does not mean I suddenly support every CSS color addition into the spec. Just because there were **** choices of colors in the beginning, doesn't mean you have to continue adding to the list. You should think about this logically rather than emotionally. Web developers outside of your bubble are forced to deal with the repurcussions of decisions made in bug trackers when they should not be. Ever wonder why 'darkgray' is lighter than 'gray'? Let's not pollute the standard with memorials that cannot be fairly applied. Jon, AliceBlue is memorializing somebody, however, it predates CSS, it was named after Theodore Roosevelt's daughter and referenced in plays in 1919. BlanchedAlmond looks like... Blanched Almonds. I don't know why you guys insist on trying to use colors that already exist in the CSS set to add another out of a bad decision. Nobody is attacking Eric Meyer's work in the community. You guys should be able to take professional criticism in a non-personal manner, including claiming I lack empathy on Twitter Mat https://twitter.com/wilto/status/477536616274493442 This is childish, and Eric Meyer never even requested these changes. I think if given a significant enough cool-off process people will logically see this to be a bad decision, much like how it's being viewed other places where it has been proposed such as: https://news.layervault.com/stories/25847-name-663399-beccapurple-in-css4-color I think you guys need to step outside of your bubble and consider things from a logical and technical perspective and not trash people just because they have a technical argument against it.
"Gainsboro is a color scheme that came from X11, DodgerBlue is the color of the Dodgers" Jay, you've both made and missed part of my point — those color names are only helpful to those who happen to know X11, or who happen to know who the Dodgers are. To anyone else, the names are irrelevant. This means the current color list already doesn't match your abstract ideal of what it should be, so why not allow this one part of the spec to contain some subjective elements? (And, if you feel so strongly about it, have you filed bugs to re-name these culturally skewed and ambiguous names?) You have also missed Jonathan Sampson's point, which he made very well: the specification is more than the totality of its words. And Mat is right — you are behaving as if you have no empathy. We are not voting for this strictly because we want to support Eric, but also because we want to *be part of a community that supports its members*. Food is better when the ingredients in a recipe combine to create a whole that is more than the sum of its parts. The same is true of communities and the things those communities create. Techincal purity is an admirable goal, but not when it gets in the way of the community it serves. Sometimes you have to set that purity aside and say, what the hell, this is important too. If we were replacing an existing word, I might agree with you. If the new word used "green" to define a reddish color, I might agree with you. But I hope you appreciate, even if you don't think it's the right thing to do, that one can act both emotionally *and* with regard for the spec. No harm is being done.
Alternate implementation route: use CSS variables instead of changing the spec Instead of "BeccaPurple", define "--BeccaPurple". Various CSS developers could get together and publish a public CSS file containing every named color under the sun, from DodgerBlue to CocaColaRed, all using single lines of CSS for each. Those who wish to support these named colors could simply import the CSS file directly. As these new named colors would not be written into stone via specification amendments, they could be added, removed, & changed as needed in the future. If a custom named color list gets too large, it could be forked and people would be free to pick the sets of named colors they wish. Even if browser vendors wish to build these named colors into their releases, this is a much simpler way to implement the change. (it'd be a little cleaner to use if the requirement of the "var()" syntax was dropped from the CSS variables spec, though, this doesn't really affect the ability to do this)
I like how everyone in here are so nice. But... The death of the girl is really sad. My Condolences to Eric. Does adding the color improve the situation? If my daughter's color would be added to colortable I'd be very depressed every time I use color name.
Has anyone actually asked Mr. Meyer what he thinks of all this?
As stated earlier in the thread: Eric has been asked about this change, and can respond whenever and if ever he should feel a need.
Apparently, the name was changed from `beccapurple` to `rebeccapurple`. (I don’t know where this was discussed.) This is now landed in WebKit: http://trac.webkit.org/changeset/170136
cleaned up the patch with the name change and have pushed to try https://tbpl.mozilla.org/?tree=Try&rev=fb0cd4f3f594
Assignee: nobody → dburns
Summary: Map "beccapurple" to #663399 in named color list. → Map "rebeccapurple" to #663399 in named color list.
Servo patch merged
(In reply to Mathias Bynens from comment #22) > Apparently, the name was changed from `beccapurple` to `rebeccapurple`. (I > don’t know where this was discussed.) This is now landed in WebKit: > http://trac.webkit.org/changeset/170136 Eric asked for the name change: http://meyerweb.com/eric/thoughts/2014/06/19/rebeccapurple/
Last try is https://tbpl.mozilla.org/?tree=Try&rev=beb1512cb6ef I am not sure who the best people are to flag for review so suggestions welcome. Patches split roughly on modules
Attachment #8439510 - Attachment is obsolete: true
Attachment #8443673 - Flags: review?(dbaron)
Attachment #8443672 - Flags: review?(jwalker)
Attachment #8443674 - Flags: review?(dholbert)
Attachment #8443675 - Flags: review?(jmaher)
Attachment #8443671 - Flags: review?(dbaron)
Comment on attachment 8443673 [details] [diff] [review] Add in rebeccapurple to color lists in gfx I don't think there's any need to modify skia since it's not involved in what named colors we support, and it might complicate it being imported, so r=dbaron on the nsColorNameList.h change, and please drop the changes to the other two files changed here. (You could ask mattwoodrow if you wanted, but I don't think there's any reason to bother.)
Attachment #8443673 - Flags: review?(dbaron) → review+
Comment on attachment 8443671 [details] [diff] [review] Remove extra white space from files, no functional changes r=dbaron on the nsColorNameList.h change; the other two files are imported code, so I think we're better off modifying them as little as possible.
Attachment #8443671 - Flags: review?(dbaron) → review+
Comment on attachment 8443675 [details] [diff] [review] Add rebeccapurple to mochitest colors Review of attachment 8443675 [details] [diff] [review]: ----------------------------------------------------------------- lgtm
Attachment #8443675 - Flags: review?(jmaher) → review+
Attachment #8443672 - Flags: review?(jwalker) → review+
Attachment #8443673 - Attachment is obsolete: true
Comment on attachment 8444007 [details] [diff] [review] Add in rebeccapurple to color lists in gfx Review of attachment 8444007 [details] [diff] [review]: ----------------------------------------------------------------- Carrying r+ forward, updated after comments
Attachment #8444007 - Flags: review+
Attachment #8443671 - Attachment is obsolete: true
Comment on attachment 8444009 [details] [diff] [review] Remove extra white space from files, no functional changes Review of attachment 8444009 [details] [diff] [review]: ----------------------------------------------------------------- updated as per comments, carrying r+ forward
Attachment #8444009 - Flags: review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: