[whatwg] borders on images inside links

[Ian Hickson]

On Mon, 1 Mar 2010, L. David Baron wrote:
>
> I believe the rendering section should describe a default style rule, 
> present in Gecko and in Internet Explorer (and also in Netscape 4.x and 
> earlier, Mosaic, etc.), that gives borders to images inside links.  In 
> Gecko, this is represented as:
> 
>   :link img, :visited img, img[usemap], object[usemap] { border: 2px solid; }
> 
> People have expressed concern that this rule is a bad default because 
> it's a rule that authors frequently override.  I agree that it's a bad 
> default for HTML that is used as an application, but I think it's a good 
> default for HTML as a document.  And I think there is content written on 
> the assumption that borders would visually indicate links -- I know I've 
> written some.
> 
> I think we're better off not breaking compatibility here, as it's a 
> very-long-standing (for the Web) precedent.  I'd rather see 15-year-old 
> Web pages continue to work as intended rather than gradually turn them 
> into something that requires 15-year-old software to read.
> 
> For more information (and the reason that prompted me to post here), see 
> https://bugzilla.mozilla.org/show_bug.cgi?id=452915 .

On Tue, 2 Mar 2010, Maciej Stachowiak wrote:
> 
> WebKit has never had this rule. We have not had any significant problem 
> reports based on it. Therefore I doubt there is truly a compatibility 
> issue.
> 
> I do not believe the proposed rule is a good default for either 
> documents or applications. It looks ugly. I randomly checked 10 of the 
> sites I browse most often and I could not find a single one that 
> explicitly added this rule for the browsers that don't have it. What's 
> more, I could not find a single one that retained it for images. This 
> rule is just a vestigial artifact that Web developers have to work 
> around.

On Tue, 2 Mar 2010, Maciej Stachowiak wrote:
> 
> I partially take it back, news.google.com and images.google.com 
> deliberately add blue borders to image links. However they do not use a 
> default border (it's 1px instead of 2px for one thing).

On Tue, 2 Mar 2010, Maciej Stachowiak wrote:
> 
> I expect the WebKit community would be against adding such a style rule, 
> even if a spec said we should.
> 
> Even the 13-year-old HTML 3.2 spec has border="0" on images used as 
> links: <http://www.w3.org/TR/REC-html32>. That's before CSS!
> 
> I'd like to see some examples of actual 15-year-old Web pages that 
> render better with this style rule than without, to the point that a 
> modern reader would consider them broken.

On Tue, 2 Mar 2010, Ashley Sheridan wrote:
> 
> The majority of browsers render images within links as having a border 
> (which is the image highlight equivalent of a text underline when you 
> think about it in context). Having some default expected behavior would 
> be nice to see in a spec, even if the majority of websites actually 
> override it. Having it in a spec will remain consistent with the older 
> browser implementations, and may serve as a guideline as to exactly what 
> should be expected.
> 
> Besides, [...] most website devs override this rule anyway, so it won't 
> actually break anything, it would just clarify what is already 
> happening.

On Tue, 2 Mar 2010, Henri Sivonen wrote:
>
> My primary concern isn't that authors who control the entire page have 
> to include an additional incantation (img { border: 0; }). My concern is 
> that the default border makes copy-pasteable HTML fragments 
> unnecessarily crufty, because the providers of these fragments feel 
> compelled to zap the border regardless of the toggles in the target 
> document.

On Tue, 2 Mar 2010, ddailey wrote:
>
> I tend to concur not just with the specific (borders around images in 
> <a>) but with the broader principle of working hard to preserve simple 
> HTML. It is good to keep in mind that there are novices in the world for 
> whom the concepts of HTML, CSS, script, DOM, semantics, microformats. 
> libraries, etc. are becoming a steeper and steeper learning curve than 
> was the case when all the implementers learned the stuff. I worry that 
> things are becoming increasingly esoteric and elevated and sometimes 
> question if all the noble efforts expended here will ultimately help 
> with cross-browser compatability or not. It is not a foregone conclusion 
> to me that they will. A good many things that I used to do routinely 
> (albeit naively) as an instructor using IE and Netscape are now 
> hour-long quests to figure out how to do it "right." A shortest path now 
> often involves the strangest admixtures of CSS, multiple versions of 
> DOM, innerHTML, and script. Doctrine sometimes seems to override 
> comprehensibility.

(There was a subthread investigating making this a quirks-mode feature, 
but there's no evidence that it's needed for compatibility, so I haven't 
quoted that above.)

Personally, my opinion is that images in links should have borders because 
otherwise how do you know it's a link?

This seems to be a minority view, though. People have been explicitly 
turning off this cue for literally over a decade.

Generally for things like this the spec just does whatever is needed for 
optimal compatibility with existing content. In this case, whoever, pages 
don't by and large depend on one behaviour or the other, since there have 
been browsers with significant market share on both sides of this issue 
for a long time.

If compatibility isn't a factor here, and it doesn't appear to be, then 
we have to consider what provides the least work for authors. This appears 
to be having no border, since that is what most authors seem to gravitate 
towards.

We also have to consider what is best for users. In theory, that would be 
to have the border -- but since so many authors disable the border, in 
practice, our decision here doesn't affect users.

This leads to the conclusion that resulted in the current spec text: the 
only major factor here is author convenience, and that argues for no 
border by default.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'