Closed Bug 452915 Opened 16 years ago Closed 14 years ago

Linked images have a blue border in default style sheet

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

x86
All
defect
Not set
trivial

Tracking

()

RESOLVED FIXED

People

(Reporter: hsivonen, Assigned: hsivonen)

References

()

Details

(Keywords: html5)

Attachments

(1 file, 3 obsolete files)

Build ID: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080829020828 Minefield/3.1a2pre

Steps to reproduce:
 1) Load http://hsivonen.iki.fi/test/moz/alt.html

Actual results:
Images that are linked have a border as in Mosaic, Netscape 1.1 and Trident.

Expected results:
Expected none of the images to have a border by default as in Opera and WebKit (and Tasman).

Additional information:
Authors seem to hate the default border. Suppressing it with border=0 is very common. See
http://lists.w3.org/Archives/Public/public-html/2008Aug/0923.html
Strict authors suppress it via CSS. Virtually no author seems to want it. When it is systematically suppressed, it doesn't help users but it annoys authors. Since Opera and WebKit have managed to get rid of the default border (and Mac IE 5 did so before them), it should be safe for Gecko to get rid of the default border without Breaking the Web. (If Gecko gets rid of the border too, perhaps IE8 might, as well.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.1?
David, Boris, what do you think?
I could live with giving it a shot.
So what happens to the pages where authors do want it?  (I've written such pages.)
(In reply to comment #3)
> So what happens to the pages where authors do want it?

They'd render the way they render in WebKit and Opera now. Pages relying on the default (either way) are not cross-browser-safe today.

> (I've written such pages.)

When you did, were WebKit, Opera or Tasman doing the borderless default? How recent pages are you referring to?
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1-
Summary: Linked images have a border in default style sheet → Linked images have a blue border in default style sheet
I don't like these borders either, but they have their use. They show which images are links. It's like complaining that links by default are blue and underlined.
Google published a high-visibility demo (that doesn't work if Firefox due to codec) without bothering to hide the borders in Firefox:
http://www.youtube.com/html5
It seems that HTML5 sides with WebKit and Opera and doesn't prescribe the default border:
http://www.whatwg.org/specs/web-apps/current-work/#images-0
IE7 seems to do the same as Mozilla, afaict, so it seems to me that Mozilla is doing it correctly.
Keywords: html5
Since when is the goal emulating IE7?
I always suppress the border when I write pages, but I have to agree with the logic presented in comment 5.
(In reply to comment #5)
> I don't like these borders either, but they have their use. They show which
> images are links. It's like complaining that links by default are blue and
> underlined.

Authors don't systematically nuke the blue and underline of links.

As Henri said, when authors systematically nuke the border, it doesn't show users which images are links but instead are mere annoyance for authors.
Attached patch Zap the default image border (obsolete) — Splinter Review
Assignee: nobody → hsivonen
Attachment #401175 - Attachment is obsolete: true
Attachment #401188 - Attachment is obsolete: true
Attachment #401189 - Flags: review?(dbaron)
Adding a reftest to the patch.

Any chance of getting this into 1.9.3?
Attachment #401189 - Attachment is obsolete: true
Attachment #424961 - Flags: review?(dbaron)
Attachment #401189 - Flags: review?(dbaron)
Well, I still don't think we should do this.
(In reply to comment #16)
> Well, I still don't think we should do this.

Due to authors maybe actually wanting to have the border or for other reasons? Authors who want a border haven't been able to rely on a border to be rendered by default cross-browser for the past decade at least. 

It seems to me that keeping browser differences here makes every browser's default behavior useless, since authors have to override the defaults to get consistent results. (And it appears that the vast majority wants consistent results on this point.)

If we shouldn't do this, should HTML5 change to suggest a default border in order to try to get WebKit and Opera to change instead?
(In reply to comment #17)
> If we shouldn't do this, should HTML5 change to suggest a default border in
> order to try to get WebKit and Opera to change instead?

I think it should.
Yes, authors don't like borders on images, and don't nuke the blue underlines on links. So what? The borders are an important asset to accessibility regardless. When I disable a page's CSS, I better see which images are links thanks to the default stylesheet.

Really, how is having to have one simple CSS rule to disable borders an annoyance? Additionally, the same argument for not having to rely on the default stylesheet to have borders could be flipped around and used for not having borders on images. Finally, the CSS will remain mandatory for these authors thanks to various IE versions until a standard recommends that the default stylesheet shouldn't have a border.
(In reply to comment #19)
> Yes, authors don't like borders on images, and don't nuke the blue underlines
> on links. So what? The borders are an important asset to accessibility
> regardless. When I disable a page's CSS, I better see which images are links
> thanks to the default stylesheet.

The vast majority of users never disable CSS.  The default border on images affects the vast majority of authors who systematically nuke it, and so the vast majority of users never benefit from the default border anyway.  Browsers should not cater to minorities for edge cases.  End users who do want the default border when they turn of author stylesheets can use user stylesheets to provide the border, possibly provided by some browser extension.

> Really, how is having to have one simple CSS rule to disable borders an
> annoyance?

> Additionally, the same argument for not having to rely on the
> default stylesheet to have borders could be flipped around and used for not
> having borders on images.

No, the argument cannot be flipped around because most authors don't want borders, and those that do want borders for their designs, virtually never want to accept the default blue (unvisited) and purple (visited) colour, and need to customise it anyway.

> Finally, the CSS will remain mandatory for these authors thanks to various
> IE versions until a standard recommends that the default stylesheet
> shouldn't have a border.

Yes, there will be a transition period. No-one is claiming the problem can be solved overnight and authors will have to keep nuking the default border for a few more years.  But if Firefox aligns with Opera, Safari and Chrome, there will be far more incentive for IE to drop the border too.

(In reply to comment #18)
> (In reply to comment #17)
> > If we shouldn't do this, should HTML5 change to suggest a default border in
> > order to try to get WebKit and Opera to change instead?
> 
> I think it should.

In my own opinion, I seriously doubt that we at Opera would consider changing our default to add a border that most users and authors don't want or need, especially considering we already support user stylesheet features for users to enable this themselves if they want it.
> The vast majority of users never disable CSS.

That's irrelevant. Just because a lot of users don't doesn't mean that the default stylesheet has no value.

> End users who do want the default border when they turn of author stylesheets can use user stylesheets to provide the border, possibly provided by some browser extension.

End users should not have to resort to user stylesheets to enable basic accessibility. Furthermore, it would enable the border in both full CSS and default CSS modes, so it's not a satisfactory solution.

> No, the argument cannot be flipped around because most authors don't want borders

So? It'd still be relying on the default stylesheet in the first place, which was what the original argument was about. This bug is about removing the CSS for the border in the default stylesheet, so authors don't have to remove it. Hence, it's about wanting to rely on the default stylesheet, which was argued against for the opposing side.

> those that do want borders for their designs, virtually never want to accept the default blue (unvisited) and purple (visited) colour, and need to customise it anyway

Got statistics for those, as well?
(In reply to comment #20)
> No, the argument cannot be flipped around because most authors don't want
> borders, and those that do want borders for their designs, virtually never want
> to accept the default blue (unvisited) and purple (visited) colour, and need to
> customise it anyway.

But when they do customize link colors, that change automatically gets applied to the image borders, which pick up their color from the 'color' property change.
My basic objection here, though, is that the Web isn't just for the latest-and-greatest applications; it's also for documents, including ones that need to last.  Today's Web browsers do fine at presenting most 15-year-old HTML as it was intended, and changing this could make a substantial dent in that ability.  We shouldn't turn 15-year-old HTML documents into an unreadable format that you need to install a 15-year-old piece of software to read.
Comment on attachment 424961 [details] [diff] [review]
Zap the default image border, add reftest

I don't think that review requests are a great way to make policy decisions.  However, given that I have a review request to handle here, I'm going to mark it as minus.
Attachment #424961 - Flags: review?(dbaron) → review-
(In reply to comment #23)
> We shouldn't turn 15-year-old HTML documents into an unreadable format that
> you need to install a 15-year-old piece of software to read.

Not that I particularly agree or disagree with this bug (default-borderless is prettier, but I don't know whether that's really so important a concern as to make the change), but this assertion contains an excess of hyperbole.  Removing borders from linked images will not turn HTML into an unreadable format, nor will that change in and of itself require use of 15-year-old software to decipher.  Graceful degradation and constant semantic content and all that, you know.

As a substantive consideration, a less-breaking change that still meets the prettiness concern would be to change the border's *color* to *transparent* while otherwise preserving current default styling.  This would preserve existing layouts, and the only effect would be bleed-through from boxes beneath it.  (However, I'm uncertain whether the specificity of this particular selector would make this change more difficult than just adding a dozen characters to the rule.)
(In reply to comment #19)
> Yes, authors don't like borders on images, and don't nuke the blue underlines
> on links. So what? The borders are an important asset to accessibility
> regardless.

It's not an accessibility asset when authors consistently defeat it. A user opt-in feature "Show borders around linked images" could be an accessibility asset if it ignored author-set non-borders.

> When I disable a page's CSS, I better see which images are links
> thanks to the default stylesheet.

You need to take a user action to reveal the borders. That user action might as well be activating a user style sheet that forced borders.

> Finally, the CSS will remain mandatory for these
> authors thanks to various IE versions until a standard recommends that the
> default stylesheet shouldn't have a border.

IE could change in the future if none of Firefox, Safari, Chrome and Opera had the border and new pages started looking ugly in IE.

(In reply to comment #23)
> My basic objection here, though, is that the Web isn't just for the
> latest-and-greatest applications; it's also for documents, including ones that
> need to last.  Today's Web browsers do fine at presenting most 15-year-old HTML
> as it was intended, and changing this could make a substantial dent in that
> ability.  We shouldn't turn 15-year-old HTML documents into an unreadable
> format that you need to install a 15-year-old piece of software to read.

I agree on the level of principle, though since I filed the bug on this particular point I favored the future over the 1994-2000 past on balance considering that not having default borders doesn't render documents from 1994-2000 unreadable. (I maintain that in the past decade authors haven't had a reasonable cross-browser expectation of borders, so only documents authored in the late 1990s count when considering archival fidelity of documents.)

(In reply to comment #25)
> As a substantive consideration, a less-breaking change that still meets the
> prettiness concern would be to change the border's *color* to *transparent*
> while otherwise preserving current default styling.  This would preserve
> existing layouts, and the only effect would be bleed-through from boxes beneath
> it.  (However, I'm uncertain whether the specificity of this particular
> selector would make this change more difficult than just adding a dozen
> characters to the rule.)

I believe having transparent borders instead would be a worse solution for four reasons:
 1) When old sites set the border attribute to a non-zero value expliticly, they expect colored borders.
 2) Having transparent borders would still incentivize authors of copy-pasteable HTML snippets to include border=0 to get rid of the border.
 3) Having a transparent border would be different from both IE/Mosaic and WebKit/Opera.
 4) I believe there aren't layouts that depend on the thickness of the default borders. Designs that depend on the border thickness set it explicitly. Pages that were authored around 1995 and didn't touch the default borders didn't use pixel-perfect table layouts.
> a less-breaking change that still meets the prettiness concern would be to change the border's *color* to *transparent*

Less-breaking? The end result is (mostly) the same; the border is not visible. (mostly because now there's still a border taking space for no reason)

> It's not an accessibility asset when authors consistently defeat it.

Defaults exist for a reason, and what authors do/abuse doesn't matter.

Authors have consistently abused tables for lay-out. Does that mean that the table element loses all worth and should be respecified? Hell no.

> You need to take a user action to reveal the borders. That user action might as well be activating a user style sheet that forced borders.

But then it wouldn't be an accessibility feature that's part of the standard, but just yet another feature to fix something that current standards don't do anything about.

> IE could change in the future if none of Firefox, Safari, Chrome and Opera had the border and new pages started looking ugly in IE.

"could" is not good enough, especially when it comes to IE. Furthermore, old versions will stay around for a long time. Just look at IE6 and IE7, while IE8 has been out for over a year.
Comment on attachment 424961 [details] [diff] [review]
Zap the default image border, add reftest

Well, given that I seem to have lost this debate on whatwg@whatwg.org, and I suppose this change has slight performance benefits, r=dbaron.
Attachment #424961 - Flags: review- → review+
Thank you. Pushed:
http://hg.mozilla.org/mozilla-central/rev/95ec012e2e22
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Hmm. Sorry to chime in late, this just caught my attention.

There wasn't much of a discussion in the whatwg list. I still think this is a bad move - if you go this way, why not reset all padding, margins, font style and weight for em/strong, font sizes for headers, etc? All these, and blue borders, have a purpose as a default.
Request reversion of this change.  Terrible for usability if no indication what images are links.  Also inconsistent between images and links now.  If authors want to explicitly define their own convention for highlighting navigable links they can override the default.

Disagree strongly with slavish following of "whatever WebKit does".
Depends on: 641410
Product: Core → Core Graveyard
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: