148364 - bordercolor=""

Status: VERIFIED WONTFIX

(Core :: Layout: Tables, defect)

Description

[Kai Lahmann (is there, where MNG is)]

Mozilla supports this idiotic M$-HTML - remove it asap!

Comment 1

[Waheed Islam]

err no.
so just because microsoft supports bordercolor, mozilla shouldn't?

you need to expand and justify your point.

Comment 2

[Carl Busjahn]

It's not because M$ supports it, bordercolor is not a valid Html tag.  See
w3c.org for more on that.  Part of Mozilla's goal of supporting standards
perhaps should include not supporting non-standard bad tags.  I belive the bug
poster is irritated with Microsoft's continued standards crushing, and this
doesn't help any.

Comment 3

[Kai Lahmann (is there, where MNG is)]

it's quite difficult to explain people that Mozilla/Netscape7 is the most
standard compliant Browsder, if it supports a proprietary color value from
Microsoft, which no other Browser supports (so there's no problem with broken
layout while not supporting it)

Comment 4

[Waheed Islam]

indeed. bordercolor is not part of the html 4.01 w3c standards. however,
removing such tag properties results in a loss of function. thus sites don't
display properly.

Perhaps you are right that as a part of promoting the standards effort, we
shouldn't support the non-standards. but this would just make it harder for
normal users to convert to gecko based browsers since so many sites arn't w3c
compliant, and so they won't display properly if we didn't support the
non-standards.

maybe if 90% of all users are using gecko, then maybe we can take action over
not supporting the non-standards. but for the time being...

sorry about getting too political on this. But for the sake of functionality
over politics, i'm marking this as WontFix.

Maybe someone can later reopen it with more light on the fact.

Comment 5

[Kai Lahmann (is there, where MNG is)]

Netscape 4 doesn't support it.
Opera doesn't supprt it.
konqueror doesn't support it.

..so we are going more away from spec then Netscape 4? Sorry, but THIS sounds
for me like Mozilla fucks on the spec.

Comment 6

[karnaze (gone)]

If this is supported in standards mode, then please reopen the bug and it will 
be fixed. If not, then what is all of the fuss about?

Comment 7

[Kai Lahmann (is there, where MNG is)]

Attachment: testcase (strict!)

I don't understand why we even should support this in quirks mode, but it's
worse: the testcase is in strict mode.

Comment 8

[Kai Lahmann (is there, where MNG is)]

comment #6 + attachment = reopen

Comment 9

[Hixie (not reading bugmail)]

That testcase is invalid, thus per HTML we are allowed to do anything we want
with it.

Comment 10

[karnaze (gone)]

If it is invalid because it contains bordercolor, shouldn't we ignore 
bordercolor in strict mode?

Comment 11

[Hixie (not reading bugmail)]

The spec doesn't say.

If we use <blink> as a precendent, then no, we should just support it in the
same way as we do in quirks mode. David Baron and I think that quirks mode
should be limited to quirks that break standards compliant pages, i.e. only for
quirks that are a violation of the spec, rather than an extension to the spec.
We have enough quirks as it is -- adding more merely adds bloat, potential for
bugs, increases the cost of migrating to strict mode, and increases support costs.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The point of strict mode is to have different behavior when, and only when,
being compatible with real pages requires us to do something that is not
compliant with standards.  HTML does not define error-handling behavior, so we
can do whatever we want, including "support" things that are invalid.  This
should be WONTFIX.  We don't need even more divergence between quirks and strict
mode than we really need, since that leads to huge lack of testing of strict
mode (remember the two modes of form controls).

Comment 13

[karnaze (gone)]

dbaron, that is a convincing argument, and I'm marking this wontfix. However, it 
becomes increasing difficult to get drivers to approve non standard extensions 
which IE supports (e.g. IE has an html tag for a text marque) and which Netscape 
wants to support.

Comment 14

[Hixie (not reading bugmail)]

VERIFIED WONTFIX

karnaze: could you mail me the relevant bug numbers for the extensions you are
referring to? Cheers.

Comment 15

[SineSwiper]

I disargee with the WONTFIX argument.  Support for non-compliant functions
creates this imaginary choker chain on Mozilla that lets its owner (in this, and
all other cases, MS IE) drag it around like a little bitch as it forces it to
feed on its own deformed and rotting masses of proprietary junk.  What's next? 
VB support for the SCRIPT tag?  Support for the BLINK tag?  (Oops...too late.)

AOL will be supporting Mozilla in its next release.  As much as I detest AOL,
they do have 30% of the market share of users of the Internet, and this will
change the browser world forever.  For once, people will have to stop using IE
as their testbed and use the *#%^ing W3C standards.  The webmasters can cry all
they want about having to change their pages, but it's their own damn fault.  (I
still can't go to Capital One's login page because they are too lazy to fix it.
 Maybe with 30+% of the customer base on Mozilla, they'll get in gear.)  I've
been supporting W3C for years, and it's not that hard to do.  Maybe it'll force
IE to fix its buggy HTML4/CSS code (fat chance).

Let's do ourselves a favor and remove all non-standard tags/properties/behaviors
in Mozilla.  That way, when the big pro-AOL/Mozilla web page rewrite happens,
people will finally follow the standard that the Internet community has been
working on so hard for, but has been half-hazardly implemented: W3C.

Comment 16

[Hixie (not reading bugmail)]

If we did that, we wouldn't render the web, and nobody would use us. So that's
not really a viable solution.