Closed Bug 103429 Opened 23 years ago Closed 14 years ago

Links Bar should use same colors as the page

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: mpt, Unassigned)

References

Details

(Keywords: polish) 

The bar showing LINK links should have the same border style, and the same font,
as toolbars in the window. However, it should use the same foreground,
background, link, visited, and highlight colors as the page itself.

Um, why on earth ...?
    1.  Like A HREF links, LINK links are part of the document, and they should
        look like part of the document.
    2.  As with A HREF links, whether LINK links are visible should depend on
        whether they exist in the document. There are three problems to showing 
        the bar only as needed: making it fast enough (103097), making it
        display incrementally as the page loads (bug 102922), and making its
        disappearance and appearance no more visually distracting than the
        disappearance and appearance of the rest of the page (bug 102990, and
        this bug).

But ... but ... but what if a page author specifies the same foreground color as
their background color? The links will be invisible!
    Then they're going to have the same problem with the rest of their page,
    aren't they?

Not necessarily -- they could have a table with colored cells ...
    If they're smart enough to use LINK in the first place, they're smart
    enough to not do that.
Blocks: 103053
With some background colors, the toolbar-style bevelled edge is going to look
very ugly. I'm not totally opposed to this in principle, but I'm not totally
convinced it's a good idea either. I like having link as a toolbar, precisely
because it stays in one place and looks consistent. For me, changing the color
would be at best pointless, and at worst a distraction.
From discussion between me and mpt tonight: what we'll essentially do is treat
<link> as if it had a default style of display:
-moz-not-really-block-but-a-special-XBL-implementation.  If someone over-rides
this style, the link will be removed from the toolbar and displayed as they see
fit.  (mpt: should this include display: hidden, in which case we don't see the
link at all?  this would also provide a nice workaround for authors using
rel="newmachinereadable" so that it wouldn't show up here).  This way, people
can style the toolbar legitimately per CSS, and have it work (as it should).

Regardless of whether or not they set explicit display, we should respect their
text and background colors for link, whether explicitly set or inherited.  One
problem may be that sites set color on <body>, rather than <html>; applying
<body> styles to <link> seems rather treif to me.  Of course, since link
implementations are few and far between right now, perhaps we can encourage
implementors to DTRT anyway and set style on <html>.

cc'ing Hixie to see if we're allowed to do this.
Status: NEW → ASSIGNED
Keywords: polish
Priority: -- → P2
Target Milestone: --- → mozilla0.9.6
I think the Links Toolbar is part of the chrome even though it displays data
from the document. Surely no one is suggesting that the "Page Info" and the
"Element Properties" windows should be author-stylable.

I'd like to have consistent-looking toolbars, so I think letting the author
style the toolbar is a bad idea.

Also, relying on <link> having a special display value is problematic. For
page-layout purposes, <head> and its subelements behave as if they had display:
none;. The links Toolbar implementation shouldn't break is the author makes
display: none; explicit in a style sheet instead of relying on the UA style sheet.
I don't like this RFE. I honestly think it would look horrible. I personally adore
the toolbar as it is now -- it looks like chrome because, well, it _is_ chrome.
Web authors can do what they want to <link> elements, that shouldn't affect the
link toolbar IMHO. e.g. one of my Link pages styles the <link> elements itself.
This should be independent of the link toolbar. If mpt is not convinced, I
suggest someone hack up the toolbar on his build so that it has style attributes
set to that of various web pages, see if it looks good or not. :-)
> mpt: should this include display: hidden, in which case we don't see the link
> at all?

Yes, but I think that's outside the scope of this bug.

> Surely no one is suggesting that the "Page Info" and the "Element Properties"
> windows should be author-stylable.

No, but (with the exception of IMG LONGDESC) they're not for navigation
intrinsic to the page, whereas LINK links are.

> it looks like chrome because, well, it _is_ chrome.

That bug is bug 102990.

> If mpt is not convinced

No, I'm not. In fact, I think if this bug was not fixed, the Links Bar would be
too distracting to be included in commercial Mozilla distributions.
->claudius, who tests toolbars.
QA Contact: sairuh → claudius
Gotta agree with hixie.  <Link> bar should remain part of the chrome, and
unstylable.  It's in the <head> and is meta-data about the page, not part of the
content of the page.  Nobody is suggesting that authors can apply CSS to <title>
and modify the window's titlebar, right?

Based on everything I've read, the whole point of <link> is to have _consistent_
navigation for the web built into the UI.  If not, this is not much different
than the author putting an absolutely positioned block at the top of the
page/screen.  
Futuring. We can debate this after the Great XBLification.
Target Milestone: mozilla0.9.6 → Future
agreeing with comment #7

links toolbar is chrome, not web page.

I do *not* want someone applying style to my links toolbar. If a page author
really wants control over the links toolbar so badly, they have this option:
    do not use link elements
    do use HTML/CSS to keep a div floated at page top

The point of the link element is to avoid everyone doing their own navigation
links in a zillion different styles. If page authors don't want to support
constent UI for navigation, then they should not use the link elements.

can't this be marked a won't fix?

If it's a valid bug, shouldn't we also let page authors dictate what back and
forward buttons look like when the buttons take me to their site? Shouldn't we
use their colors for bookmarks? I just know we'd all love for our bookmarks menu
to come in millions of colors.

-matt
> I do *not* want someone applying style to my links toolbar.
That's fine, this isn't applying style to a toolbar. It's applying colors (and
nothing else) to a bar which appears at the top of the viewport and which is not
a toolbar. If you want a toolbar as well, make yourself an XPI.

> can't this be marked a won't fix?
Well, you might be ok with the LINK UI never appearing in mass-market Mozilla
distributions, but AFAIK you weren't one of the ones putting any work into it.

> If it's a valid bug, shouldn't we also let page authors dictate what back and
> forward buttons look like when the buttons take me to their site?
No, because they're not for navigation intrinsic to the page, whereas LINK links
are.

> Shouldn't we use their colors for bookmarks?
No, because they're not for navigation intrinsic to the page, whereas LINK links
are.
Product: Core → Mozilla Application Suite
Assignee: choess → nobody
Status: ASSIGNED → NEW
Priority: P2 → --
QA Contact: claudius → guifeatures
Target Milestone: Future → ---
Component: XP Apps: GUI Features → UI Design
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.