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" <[email protected]>
To: <[email protected]>
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/



Reply via email to