Bugzilla

(In reply to Tim Nguyen :ntim from comment #17)
> (In reply to Dão Gottwald [::dao] from comment #16)
> 
> > (In reply to Kazumasa Hasegawa (Kazz) from comment #15)
> > 
> > > Please reconsider NOT to deprecate "toolbar_text".
> > > 
> > > "bookmark_text" is not suitable wording for the text color of the toolbar.
> > > "toolbar_text" is much more semantic.
> > 
> > Agreed. The color is used outside of the bookmarks toolbar, so bookmark_text would be misleading. It's fine to support bookmark_text as an alias to be compatible with Chrome themes, but compatibility doesn't need to go both ways as we aim to make Firefox more extensible than Chrome.
> > 
> > The same goes for textcolor / tab_background_text. tab_background_text is fine as an alias for compatibility, but in reality that color is used more broadly than just for background tabs.
> 
> The argument makes sense to me, but on the other hand, aliases make it harder for theme validation, which is why this change was decided. I don’t have a strong opinion tbh, but maybe we can figure out a solution that let’s us have descriptive names and compatibility with chrome without making it a pain to validate.

It's not clear to me why aliases make theme validation much harder. Generally it doesn't seem unreasonable for a validator to handle such things. What in particular is the problem here?

(In reply to Luca Greco [:rpl] from comment #18)
> Are we ready to proceed to the "API schema LWT aliases rip off"? 

No, we have not. Speaking from the Firefox theme perspective, I can't promise how will implement these things if the Chrome aliases become the primary and only names. We could either limit where they apply to reflect their names, which would likely break themes, or we could misuse them beyond their intended context, which would confuse theme authors targeting Firefox going forward. Either way seems problematic.

(In reply to Tim Nguyen :ntim from comment #17)
> (In reply to Dão Gottwald [::dao] from comment #16)
> 
> > (In reply to Kazumasa Hasegawa (Kazz) from comment #15)
> > 
> > > Please reconsider NOT to deprecate "toolbar_text".
> > > 
> > > "bookmark_text" is not suitable wording for the text color of the toolbar.
> > > "toolbar_text" is much more semantic.
> > 
> > Agreed. The color is used outside of the bookmarks toolbar, so bookmark_text would be misleading. It's fine to support bookmark_text as an alias to be compatible with Chrome themes, but compatibility doesn't need to go both ways as we aim to make Firefox more extensible than Chrome.
> > 
> > The same goes for textcolor / tab_background_text. tab_background_text is fine as an alias for compatibility, but in reality that color is used more broadly than just for background tabs.
> 
> The argument makes sense to me, but on the other hand, aliases make it harder for theme validation, which is why this change was decided. I don’t have a strong opinion tbh, but maybe we can figure out a solution that let’s us have descriptive names and compatibility with chrome without making it a pain to validate.

It's not clear to me why aliases make theme validation much harder. Generally it doesn't seem unreasonable for a validator to handle such things. What in particular is the problem here?

(In reply to Luca Greco [:rpl] from comment #18)
>  e.g. have we reached an agreement about what to do about `toolbar_text`?

No, we have not. Speaking from the Firefox theme perspective, I can't promise how will implement these things if the Chrome aliases become the primary and only names. We could either limit where they apply to reflect their names, which would likely break themes, or we could misuse them beyond their intended context, which would confuse theme authors targeting Firefox going forward. Either way seems problematic.

(In reply to Tim Nguyen :ntim from comment #17)
> The argument makes sense to me, but on the other hand, aliases make it harder for theme validation, which is why this change was decided. I don’t have a strong opinion tbh, but maybe we can figure out a solution that let’s us have descriptive names and compatibility with chrome without making it a pain to validate.

It's not clear to me why aliases make theme validation much harder. Generally it doesn't seem unreasonable for a validator to handle such things. What in particular is the problem here?

(In reply to Luca Greco [:rpl] from comment #18)
> Are we ready to proceed to the "API schema LWT aliases rip off"?
>  e.g. have we reached an agreement about what to do about `toolbar_text`?

No, we have not. Speaking from the Firefox theme perspective, I can't promise how will implement these things if the Chrome aliases become the primary and only names. We could either limit where they apply to reflect their names, which would likely break themes, or we could misuse them beyond their intended context, which would confuse theme authors targeting Firefox going forward. Either way seems problematic.