The dot for the last stage is bright red, indicating to users that the import has failed. While some of importer's HTML is written clearly to use green for success and red for failure, angular-wizard's default styling confuses this;
angular-wizard applies the class "editing" to the dot for a stage that was already completed, but has been clicked back to in order to edit. The dot for the last stage is also getting this class. angular-wizard's default style for li.editing is bright red, so the last stage is being marked in bright red.
angular-wizard default styling applies the color green to dots for each completed stage.
Glynnis came up with some good color fixes, working within the constraints set by angular-wizard's markup: 'editing' can be a dark gray just like 'current', and the done color can be blue, so that the meaning of green is reserved.
In our ensuing CSS patch, the override of the bright red with gray was swallowed up because it was
preceded by a // line; that works in some preprocessors, but in CSS it's an error which silently causes the next CSS construct to be ignored, so the bright red was persisting. By correcting the comment to match CSS, the override of the bright red becomes effective, and the confusing color symbolism is addressed
The dot for the last stage is bright red, indicating to users that the import has failed. While some of importer's HTML is written clearly to use green for success and red for failure, angular-wizard's default styling confuses this;
angular-wizard applies the class "editing" to the dot for a stage that was already completed, but has been clicked back to in order to edit. The dot for the last stage is also getting this class. angular-wizard's default style for li.editing is bright red, so the last stage is being marked in bright red.
angular-wizard default styling applies the color green to dots for each completed stage.
Glynnis came up with some good color fixes, working within the constraints set by angular-wizard's markup: 'editing' can be a dark gray just like 'current', and the done color can be blue, so that the meaning of green is reserved.
In our ensuing CSS patch, the override of the bright red with gray was swallowed up because it was preceded by a // line; that works in some preprocessors, but in CSS it's an error which silently causes the next CSS construct to be ignored, so the bright red was persisting. By correcting the comment to match CSS, the override of the bright red becomes effective, and the confusing color symbolism is addressed