[whatwg] borders on images inside links

[ddailey]

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.

grumble
David
(I'll be cheerier in the morning)


----- Original Message ----- 
From: "L. David Baron" <dbaron at dbaron.org>
To: <whatwg at lists.whatwg.org>
Sent: Tuesday, March 02, 2010 12:20 AM
Subject: [whatwg] borders on images inside links


>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 .
>
> -David
>
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/
>
>