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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: hsivonen, Assigned: hsivonen)
References
()
Details
(Keywords: html5)
Attachments
(1 file, 3 obsolete files)
3.65 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
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.)
Assignee | ||
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
David, Boris, what do you think?
Comment 2•16 years ago
|
||
I could live with giving it a shot.
So what happens to the pages where authors do want it? (I've written such pages.)
Assignee | ||
Comment 4•16 years ago
|
||
(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.
Assignee | ||
Comment 6•15 years ago
|
||
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
Assignee | ||
Comment 7•15 years ago
|
||
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
Comment 8•15 years ago
|
||
IE7 seems to do the same as Mozilla, afaict, so it seems to me that Mozilla is doing it correctly.
Comment 9•15 years ago
|
||
Since when is the goal emulating IE7?
Comment 10•15 years ago
|
||
I always suppress the border when I write pages, but I have to agree with the logic presented in comment 5.
Comment 11•15 years ago
|
||
(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.
Assignee | ||
Comment 12•15 years ago
|
||
Assignee | ||
Comment 13•15 years ago
|
||
Assignee: nobody → hsivonen
Attachment #401175 -
Attachment is obsolete: true
Assignee | ||
Comment 14•15 years ago
|
||
Attachment #401188 -
Attachment is obsolete: true
Assignee | ||
Updated•15 years ago
|
Attachment #401189 -
Flags: review?(dbaron)
Assignee | ||
Comment 15•14 years ago
|
||
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.
Assignee | ||
Comment 17•14 years ago
|
||
(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.
Comment 19•14 years ago
|
||
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.
Comment 20•14 years ago
|
||
(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.
Comment 21•14 years ago
|
||
> 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-
Comment 25•14 years ago
|
||
(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.)
Assignee | ||
Comment 26•14 years ago
|
||
(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.
Comment 27•14 years ago
|
||
> 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+
Assignee | ||
Comment 29•14 years ago
|
||
Thank you. Pushed: http://hg.mozilla.org/mozilla-central/rev/95ec012e2e22
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 30•14 years ago
|
||
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.
Comment 32•13 years ago
|
||
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".
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•