Closed Bug 151620 Opened 23 years ago Closed 23 years ago

use non-standard line-height for table cells, even in standards mode [INLINE]

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
mozilla1.0.1

People

(Reporter: emeyer, Assigned: karnaze)

References

(
URL
)

Details

(Keywords: topembed+, Whiteboard: [adt2 RTM] [ETA 06/24])

Attachments

(1 file, 4 obsolete files)

revised patch with additional suggestions
5.32 KB, patch
karnaze
: review+
karnaze
: superreview+
Details | Diff | Splinter Review
The URL: field above points to an article that explains what Gecko does with images and line layout, and how that lead to layout problems in table-based designs... and others, actually; images in DIVs can trigger the same problem. This issue was originally reported in bug 22274 and has been duplicated almost 100 times as of this entry. What Gecko does in "quirks" mode is consistent with other browsers, which shrink-wrap table cells around images. In "standards" mode, spaces open up underneath such images (the article referenced above explains why). In some designs, this can literally rip a page into little pieces and fling them all over the place. Whether or not such design paradigms are sufficiently pure or not is beside the point-- there are still questions, complaints, and so forth regarding this behavior. This behavior has caused layout problems on Web sites that are using DOCTYPEs that trigger "standards" mode, and it will continue to do so with any site that adds an HTML 4 Strict DOCTYPE, or any XHTML DOCTYPE, even a transitional one. The behavior has already bitten sites like Orbitz, Match.com, and IBM, and will continue to be an problem in the future. Any site that converts to XHTML is highly likely to be hit with this problem the instant the conversion happens. To be fair, the CSS Working Group has confirmed that the CSS2 specification does call for the behavior Gecko has implemented, and the Mozilla team is to be commended for doing such a thorough job of implementing the CSS2 standard. Nonetheless, I can guarantee that this is NOT what authors want, and no other browser engine does what Gecko does for precisely that reason. Again, consider the number of duplications of bug 22274. Perusal of 22274 also shows that there are some very strong opinions on what should be done. In order to sidestep this issue, I am requesting the implementation of an internal preference that can be used to set which line-layout behavior is used in the rendering modes. This would let Mozilla retain its current behavior while allowing non-Mozilla Gecko embedding clients (Chimera, Netscape, Galeon, Compuserve, any others) decide whether they want the strict-CSS2 line layout behavior or not when in "standards" mode. This would almost certainly be the simplest, safest, and least controversial way to address this problem. I want to be clear that this is not a proposal to change the quirks/standards switching mechanism. It is simply an internal preference-- one that should never be exposed in the UI-- that says, "when in standards mode, do line layout this way or that way." Nothing more. I am given to understand that this could be done with a very small patch. The sooner this can be done, the better. I have set the severity to Major because I don't think I can justify calling it critical or blocker-- this isn't a crash situation, or a security problem, or anything like that. But I do believe that this is an important change to make, especially if Gecko wants to be taken seriously as a desirable embedding candidate into the future.
Taking the bug.
Assignee: attinasi → karnaze
Priority: -- → P2
Target Milestone: --- → mozilla1.0.1
Status: NEW → ASSIGNED
Attached patch patch to fix the bug (obsolete) — — Splinter Review
The patch only fixes the cases involving table cells and doesn't use a pref. I think some of us agreed that a pref wasn't necessary in this case, but if I'm wrong, I can add one.
Comment on attachment 87598 [details] [diff] [review] patch to fix the bug >+PRBool >+nsBlockFrame::IsTableCellBlock(nsIFrame& aFrame) >+{ >+ nsIFrame* parent; >+ aFrame.GetParent(&parent); >+ if (parent) { >+ nsCOMPtr<nsIAtom> frameType; >+ parent->GetFrameType(getter_AddRefs(frameType)); >+ if (nsLayoutAtoms::tableCellFrame == frameType) { Any chance you could check here whether the content node is a td here? That would mean that this change wouldn't apply to non-XHTML XML. >+ return PR_TRUE; >+ } >+ } >+ return PR_FALSE; >+}
Making this topembed, seeing this a lot these days. As for an actual pref, drivers might want one, not sure what mozilla.org's stance is on this.
Keywords: topembed
dbaron, if a check is made for a <td>, it won't handle the html cases where elements have their display types changed to table-cell and the cases involving anonymous table cells (e.g. putting an image inside a row). If you think it is necessary to exclude xml, maybe it would be better to check the default namespace and exclude xml.
CSS3 provides a property to control this. Let's implement that instead of adding yet more complications to our inline box model (it gets limited enough testing as it is). I don't understand why any Mozilla embedder would want to break the standards in standards mode. Doing so is irresponsible. It would be even more irresponsible for us to consider letting embedders do that.
> dbaron, if a check is made for a <td>, it won't handle the html cases where > elements have their display types changed to table-cell and the cases involving > anonymous table cells I would definitely want to exclude such cases.
ian, dbaron indicated that it is not trival to implement the property you are suggesting (by the way what is the property called?), hence the current approach, which only affects table cells. See also the related bug 22274. I don't think the patch adds much additional complexity to the block/inline code base.
QA Contact: petersen → ian
The patch makes our standards mode non-compliant. As such, it shouldn't be used. Pages that follow the specs should be rendered per the specs. If we don't keep our standards compliant behaviour, there is zero chance that any other browser will ever fix their behaviour. As we have already seen with many of our standards mode vs quirks mode differences, it is only after we insist on following the specs that other browser fix themselves (e.g. CSS parsing; the box model).
Incidentally, I'm not overly concerned about Mozilla here. It's the behaviour of Netscape's releases, and the releases of Netscape's embeding partners, which concerns me the most, as they are the ones that will get the most users. This is why a pref is pointless; just because three of Mozilla's users happen to be doing the right thing doesn't help the Web at large.
ian, the patch doesn't have a pref. Maybe the summary should be changed, but I'm not going to do it.
Attachment #87598 - Attachment is obsolete: true
Attachment #87691 - Attachment is obsolete: true
Contrary to the way emeyer filed the bug, we're not going to implement a preference here: we're just gonna do it across the board (if we do it at all). dbaron had asked that emeyer and the other evangelists clarify whether this was an issue that was confusing content authors who are creating _new pages_, or if it was an issue that was affecting a large number of _extant pages_. If the latter, then this change is more palatable to me. Hixie: If CSS3 is going to propose a property to explain IE and Opera behavior post hoc, then I'm having trouble understanding your objection here. At the point in time when the CSS3 property becomes well-defined, we'll remove this code, and implement that code. I suppose at that moment we'll change from "CSS2 non-compiliance" to "CSS3 compliance", but who really cares?
Summary: RFE: Create internal preference to fix layout-shattering behavior → use non-standard line-height for table cells, even in standards mode
Comment on attachment 87692 [details] [diff] [review] revised patch with dbaron's suggestion sr=waterson, contingent on dbaron as r=.
Attachment #87692 - Flags: superreview+
Comment on attachment 87692 [details] [diff] [review] revised patch with dbaron's suggestion r=dbaron, although I'd rather see the |aMustHaveTdContent| argument removed (and, if you want, the function renamed to |IsTDTableCellBlock|). There's only one set of callers, so why bother with two ways of calling it (and the extra cost associated with passing and checking the argument).
Attachment #87692 - Flags: review+
Well, my proposal was (and is) to make this an internal preference, so that embedding clients can choose what they want to do-- follow the standards, or do what authors want and every other rendering engine I've ever seen does. I have no interest in making all Gecko-based clients do the non-standards thing, but I also have no interest in Gecko continuing to shatter page layouts. If the Mozilla team can implement the CSS3 property 'line-box-contain' (http://www.w3.org/TR/css3-box/#the-line-box-contain) to fix this behavior as fast as the client could be patched to let embedding clients to what they want, then I'm all for it. Then embedding clients could set up the UA styles to either do things the way Gecko does now, or the way every other browser does now. It would be almost like having an internal preference to set. The reason I proposed taking the latter approach at this time is that I've been repeatedly told that 'line-box-contain' won't be coming any time soon, and I think this problem needs to be addressed soon.
Chris (comment 14): I still think an internal prefernce makes the most sense, because it will very closely mimic the situation when 'line-box-contain' is implemented. At that time, clients can set up their UA styles to do what they please. This was the whole idea behind creating the preference. However, to address your other point about new pages versus old pages: it's both. Every week or two, I see someone asking the question "Why does (Mozilla|NS6.x) break my page?" on an authoring mailing list or newsgroup. In some cases, it's someone creating a new design. In other cases, it's an author who finally downloaded a Gecko-based client, loaded up their Web site, and saw everything fall apart. We have also seen cases with major and minor corporate sites where they have taken an old design, rewritten it in XHTML, and put an XHTML Transitional DOCTYPE on the page. Even thought it's transitional markup, the XHTML bit puts them in standards mode, and their design falls apart. As I mentioned in my lead comment, IBM, Match.com, and Orbitz got hit by this, and I have no doubt at all that there are other sites out there that we just haven't found yet. This could become an especially difficult problem in Asia, where table-based graphic-heavy sites are apparently rather common. As more and more sites convert to XHTML (because it's the Right Thing To Do, after all), more and more designs will shatter. Whether or not a "large number" of sites are affected by this depends on what you consider to be "large." The problem as I see it is that a noticeable number of sites have been bitten by this problem, and that number will only grow over time.
For an example of a site which exhibits this problem see http://ibm.com/. They use custom DOCTYPEs for internal validation purposes which will always force them into Standards mode. Currently there is a minor layout foo in the masthead which appears in Mozilla and Gecko embedded browsers that does not appear in IE or NN4. As an exercise please tell me how you would evangelize IBM on this. In particular I would be very interested in CSS rule(s) that I could give them that will fix the layout in their masthead and not break the layout of other images outside of the masthead on *any* of their pages without requiring that they QA/redesign their entire site.
> dbaron had asked that emeyer and the other evangelists clarify > whether this was an issue that was confusing content authors who are > creating _new pages_, or if it was an issue that was affecting a > large number of _extant pages_. Extant pages should be using quirks mode. We've already made *massive* sacrifices for backwards compatability reasons in quirks mode. If there exist pages that are triggering standards mode but aren't following the specs, then it is _trivial_ for them to remove the DOCTYPE. Doing that really is easy. Standards mode is supposed to be the holy ground in which we do the right thing for authors who are themselves doing the right thing. Just because a bunch of incompetent web designers can't fix their sites doesn't mean we should have to go out of our way to break all the standards compliant ones. > Hixie: If CSS3 is going to propose a property to explain IE and > Opera behavior post hoc, The IE and Opera behaviour couldn't be explained using the property, since you can't change their behaviour, which is the whole point of the property. (It would be like saying that some of the table quirks can be explained by CSS. Microsoft tried using that argument, and Eric, David and I correctly pointed out that it was flawed.) > then I'm having trouble understanding your objection here. At the > point in time when the CSS3 property becomes well-defined, we'll > remove this code, and implement that code. We already know enough about what the property would be to implement it _now_ as a -moz-* property. So by your logic, that is what we should do, rather than implement a non-compliant hack. Since Eric has been told that 'line-box-contain' won't be coming any time soon, I have to question the likelyhood that "when the CSS3 property becomes well-defined, we'll remove this code, and implement that code". > I suppose at that moment we'll change from "CSS2 non-compliance" to > "CSS3 compliance", but who really cares? Me? And hopefully, all of you? > do what authors want and every other rendering engine I've ever seen > does. That is the mandate of quirks mode, not standards mode. Why should we even bother trying to follow the specs at all? Compliance isn't a buffet meal where you pick what you want to support. It's an agreement between browser implements and content providers to follow a set of rules. I am frankly ashamed that any of you are considering changing this in standards mode. You all know why standards compliance is so important. You all know what leverage our pedancy has against Microsoft. Considering that CSS2 was specifically and repeatedly clarified to describe the behaviour we implement, changing our behaviour would be a huge step backwards. We currently have an almost perfect inline box model. Changing it would not only be bad for authors who are following the spec (or trying to learn the specs using Gecko-based browsers as a guide), but it would be embarassing for us all. Now, I'm open to some compromises. How about these: * We could trigger quirks mode for XHTML Transitional documents sent as text/html. * We could trigger quirks mode for IBM's custom DOCTYPE.
I basically agree with Ian, except for his proposed solutions (though perhaps that's just because I'm tired of fighting about this issue, and about standards in general). However, with the Netscape evangelism team saying that this bug is costing them too much time, I don't see much chance that Netscape will want to ship releases with this implemented correctly in the future, and I really don't want to fork the layout engine between Mozilla and Netscape (and the previously proposed change in Bugscape was a much broader change, since it wasn't limited to table cells) -- that would be incredibly confusing for web developers as well as even more damaging to our standards compliance than a smaller compromise. I'd really rather not push back further on our DOCTYPE boundary between standards mode and quirks mode (IBMs custom DOCTYPE is OK, but I'd rather not push back on XHTML transitional), since it is good to have real pages using standards mode (both for testing that we're really correct (recall the standards mode form controls) and because of the influence it has on pages). Bug 22274 is the main issue that keeps us from moving the standards/quirks boundary in the other direction. I think making this change only for table cells that are TD elements is a somewhat reasonable compromise -- after all, the working group really doesn't want this to be the observed behavior, and is trying to find solutions that allow it not to be. In theory, such a change shouldn't matter for pages that are *really* following the standards since they won't be using tables-as-layout.
eric, based on dbaron's comment #21 regarding tables-as-layout, do you still feel strongly about having a pref? Because I think most of the developers feel strongly about not having a pref.
>We already know enough about what the property would be to implement >it _now_ as a -moz-* property. So by your logic, that is what we >should do, rather than implement a non-compliant hack. Great! How long will it take to have a patch show up in this bug? Because if it can be properly implemented (as a -moz-*, that's fine with me) in short order, I'd be all for that-- it would have the effect of a preference switch, as I pointed out before. >Why should we even bother trying to follow the specs at all? >Compliance isn't a buffet meal where you pick what you want to >support. It's an agreement between browser implements and content >providers to follow a set of rules. Yeah, that argument was used in the style-attribute specificity case (bug 62150), and Mozilla never did follow the standards on that one. It does now by errata'ed fiat, but there was a long period where we willfully ignored CSS2 because it suited us to do so, and because "no other user agent follows the specification." I fail to see how this would be greatly different, at least as I originally proposed tackling this problem. Doing it via CSS or a CSS-like -moz-* construct would suit me as well-- if it can be done quickly. > We could trigger quirks mode for XHTML Transitional documents sent as > text/html. I know that many authors would consider that the right thing to do, because some of them have already been confused by our triggering "standards" mode on a "transitional" DOCTYPE. But I don't know that it's necessarily a good idea. > We could trigger quirks mode for IBM's custom DOCTYPE. I don't see how that would help in the general case, unless you'd like to have ANY custom DOCTYPE trigger "quirks" mode. Because odds are we'll see more custom DTDs cropping up over time, and many of them are likely to run into this problem.
Re: comment 22: I still think that a pref would be the best compromise at this time, unless we can come up with an implementation of 'line-box-policy' or something like it. That would, as an example, let Mozilla do what it does now, and Netscape do what other commercial products do. Thus authors can have a client that does strict standards layout to test with, but not have to create workarounds for inconsistent layout behaviors between commercial clients. It also lets every embedding client make the choice: are we more interested in standards compliance or layout consistency? And as I say, either approach (pref or CSS extension) would serve that as well as the other for setting up UA defaults. 'line-box-policy' would offer more flexibililty than a simple pref, but I'm greatly concerned about implementation time. I'd also like to take a moment to note that this behavior does not only bite developers when working with tables. I recently answered a question on this behvaior, where a design was split between two DIVs and the DOCTYPE triggered standards mode. They couldn't figure out why a space opened up between the image in the first DIV and the border of the second. I was able to help them fix it easily enough, but it's an understandable reaction. I'm pointing this out because while tables are the vast majority of problem cases, they aren't the only ones. And also to highlight that if we implemented 'line-box-contain' or an equivalent, authors could choose what to do for themselves instead of depending on an internal pref. As long as it can be done quickly, it seems a better solution. But it may be better, from my perspective, to create an internal pref for the short term, and then rip it out when 'line-box-policy' is implemented a little later down the road. I would be more accepting of the "if we give on this point nobody will ever follow suit" argument if I thought anybody ever would. But in all honesty I believe that every other browser will just wait until CSS3 is published, and then claim to follow certain internal 'line-box-policy' values. That's what they did with style-attriubte specificity-- just waited until the specification was finally evolved enough to match their behavior. I see no reason why they would behave any differently in this case, especially given the more dramatic nature of the difference between the two layout behaviors.
I did some research. Of _all_ the dupes of bug 22274, the following still exist (all are sent as text/html): URI DOCTYPE NOTES http://www.alterion.com/ 4.0 strict shows problem http://perl9.tripod.com/doctype-error.html 4.01 tran w/uri shows problem http://pbskids.org/sagwa/characters/ 4.01 tran w/uri shows problem http://www.rit.edu/~wjl3191/daemons/ 4.01 tran w/uri shows problem https://www4.bc.edu/login/menu 4.01 tran w/uri shows problem http://home.arcor.de/yajirobi/ 4.01 tran w/uri shows problem[1] http://puchol.com/cpg/software/cthumb/ex01... lowercase 4.01 shows problem[2] http://www.gigabee.com/ xhtml transition shows problem http://www.offenburg.de/ xhtml transition shows problem http://siteware.ch/digichat/ xhtml transition shows problem http://sites.canaan.co.il/ xhtml transition shows problem http://sjostedt.no/mozilla/doctype.php xhtml transition shows problem http://www.earthtone9.fire-bug.co.uk/debug/ xhtml transition shows problem http://www.kamborio.com/ xhtml transition shows problem http://www.jazzinberlin.de/ xhtml transition shows problem http://macaddict4life.dhs.org/ none site has adapted http://www.dewender.com/english.shtml 4 tran w/uri site has adapted http://www.sinz.com/Palm/ 4 tran w/uri site has adapted http://www.lillmicke.nu/ 4.01 strict site has adapted http://www.penguinhosting.net/ xhtml strict site has adapted http://store.giftmarket.org/index.asp xhtml strict site has adapted http://www.wirelessinfotech.com/web/ xhtml transition site has adapted http://www.dynetics.com/ xhtml transition site has adapted http://pysmatic.net/ xhtml transition site has adapted http://www.html-programme.de/ xhtml transition site has adapted http://avonet.cz/maca/ xhtml transition site has adapted http://greymalkin.progeny.com/ xhtml transition site has adapted http://www.lokigames.com/ none worksforme http://www.adistek.com/ none worksforme http://blog.gazolinemm.com/ none worksforme attachment 60916 [details] none worksforme http://www.dts.cz/cgi-bin/dts/dts.fcgi none worksforme http://ah121.tripod.com/News.html none worksforme http://64.224.182.101/index2.html none worksforme http://www.tnsofres.cz/test2.html 4.0 tran no uri worksforme http://nortiq.com/ 4.01 tran no uri worksforme http://www.dwarf.dk/kode/hovedet.php4 4.01 tran no uri worksforme http://www.larsmichael.com/cgi-bin/gallery... 4.01 tran no uri worksforme http://whitehat.dyndns.dk/ 4.01 tran w/uri worksforme http://netsplit.com/ 4.01 tran w/uri worksforme [3] http://www.algorithm.at/mozillatest.html xhtml strict worksforme attachment 50102 [details] none testcase http://www.kirsanov.com/web.design/test.html 4 strict no uri testcase attachment 3171 [details] 4 strict no uri testcase http://alladyn.art.pl/gandalf/ImageInCell/ 4 strict no uri testcase attachment 21919 [details] 4 tran w/uri testcase http://sap.augusta.de/testpage.html 4 tran no uri testcase http://www.epita.fr/~le-mig_g/mozlayout.html 4 tran w/uri testcase http://www.macykids.net/~bmacy/test_lines.... 4 tran w/uri testcase http://test.invisiband.net/ver2/table.html 4.01 strict testcase attachment 46663 [details] 4.01 tran w/uri testcase http://www.ai.univie.ac.at/~johann/moztes... 4.01 tran w/uri testcase http://www.tammer.net/mozilla/test.html 4.01 tran w/uri testcase attachment 75360 [details] 4.01 tran w/uri testcase http://www.progoth.com/test.html xhtml 1.1 strict testcase attachment 14083 [details] xhtml transition testcase attachment 32492 [details] xhtml transition testcase http://startsiden.telia.dk/~lap/witherror.php xhtml transition testcase [1] Site has partly adapted but still shows problems [2] <!doctype html public "-//w3c//dtd html 4.01 transitional//en"> [3] I'm not entirely sure why this site works. What we learn from this is that: of the 70 sites, a good dozen (those marked worksforme) have presumably switched to a quirks-mode DOCTYPE, another dozen have fixed their site, and of the dozen or so of the remainder real sites that still show the problem, more than half are using an XHTML Transitional DOCTYPE sent as text/html. OUR BEHAVIOUR IS HAVING A DIRECTLY MEASURABLE EFFECT. I cannot emphasise that enough. That alone should be a reason to not layout change our behaviour here. If we do want to do something, though, I think we should definitely consider changing our quirks mode DOCTYPE detection code rather than adding a weird quirk in standard mode.
> Yeah, that argument was used in the style-attribute specificity case > (bug 62150), and Mozilla never did follow the standards on that one. Throughout the entire time that bug was being discussed in a Mozilla context, we were actively campaigning to have the spec changed. In the case of _this_ bug, the spec has been clarified several times, and it is clear that what we are doing is correct. >> We could trigger quirks mode for XHTML Transitional documents sent >> as text/html. > > I know that many authors would consider that the right thing to do, > because some of them have already been confused by our triggering > "standards" mode on a "transitional" DOCTYPE. I had no idea the proliferation of XHTML Transitional sent as text/html was as widespread as my recent examination of bug 22274 shows it is. Given this new information, I would now be quite happy to trigger quirks mode from that transitional DOCTYPE. (When it is sent as text/html.) >> We could trigger quirks mode for IBM's custom DOCTYPE. > > I don't see how that would help in the general case It doesn't, it's just a cheap way of fixing a high profile site. Given the low cost, low risk and high potential gain (it's a whole site off our list) I think we should go for it. > That would, as an example, let Mozilla do what it does now, and > Netscape do what other commercial products do. As I mentioned earlier, I am not worried about Mozilla's behaviour. Mozilla has about three users. Mozilla's behaviour will have no lasting effect on the Web at large. It's Netscape's behaviour that I care about. (Along with IE's, and AOL's, and other browsers with measurable market share.) > Thus authors can have a client that does strict standards layout to > test with, but not have to create workarounds for inconsistent > layout behaviors between commercial clients. Authors already have a good way of doing that; remove the DOCTYPE. > It also lets every embedding client make the choice: are we more > interested in standards compliance or layout consistency? As you know, I don't _want_ them making that decision. :-) > I would be more accepting of the "if we give on this point nobody > will ever follow suit" argument if I thought anybody ever would. So the way that WinIE is following us on CSS parsing, text-decoration, the box model, etc, is not enough? > But in all honesty I believe that every other browser will just wait > until CSS3 is published, and then claim to follow certain internal > 'line-box-policy' values. The CSS WG firmly established that this would not be satisfactory for exiting CR, and since exiting CR is something all browser makers now care about, I have a lot more faith that we'll eventually see interoperable implementations of this.
Summary: use non-standard line-height for table cells, even in standards mode → use non-standard line-height for table cells, even in standards mode [INLINE]
Comment on attachment 88159 [details] [diff] [review] alternate patch to (always) turn off strict mode line height via a pref I'm against this, as I said in comment 21.
Attachment #88159 - Flags: needs-work+
I thought we agreed "no pref"? Do, or don't do. My thoughts: Hixie, you are in the comfortable position of being "right" (i.e., you "stand on the standards high ground"), yet you don't have to do (or pay for) any of the evangelism work, nor do you have to support any of the customers who complain about the perceived "incompatibly rendered" pages. OTOH, emeyer makes the claim that this quaint feature of CSS2 is too expensive (in terms of time, effort, or money, I'm not sure which) to evangelize. He ought to be able to back that up. So, why doesn't someone @netscape.com organize a conference call between emeyer and Hixie, and anyone else that would like to be involved in this debate, or needs to be able to deal with the technical fallout of any decision that is reached.
The layout developers agreed to not have a pref. The patch is in response to comment #24. There are now 2 patches. I'm not going to decide which patch to use, although it sounds like it will be very difficult to get sr and r for the 2nd patch. I'm not going to check the 1st patch in until emeyer agrees to it.
> Hixie, you are in the comfortable position of being "right" (i.e., you "stand > on the standards high ground"), yet you don't have to do (or pay for) any of > the evangelism work, nor do you have to support any of the customers who > complain about the perceived "incompatibly rendered" pages. I volunteer to help anyone remove their DOCTYPEs, all they need do is give me access to their site and I'll do it for them. I also volunteer to help with the evangelisation work that this feature is requiring. Furthermore, I'd like to point out that I have proposed several alternative solutions that do not violate the standards. To wit: 1. Implement -moz-line-stacking-strategy per http://www.w3.org/TR/css3-linebox/#line-stacking-strategy 2. Add the following DOCTYPEs to our list of DOCTYPEs that trigger quirks mode: HTML 4.01 Transitional with URI XHTML 1.0 Transitional sent as text/html <!doctype html public "-//w3c//dtd html 4.01 transitional//en"> <!DOCTYPE html SYSTEM "http://www.ibm.com/data/dtd/v11/ibmxhtml1-transitional.dtd"> Of these two solutions I prefer the second. It has the least risk and is by far the easiest.
See also bug 146125.
Your offer to help sites is very generous yet not realistic. This is a chicken and egg situation where making changes driven by Gecko are not a priority for many sites. The browser will not be embedded if too many sites are messed up. As you can see Match.com is still broken, for months now, despite their being a major partner and site which has been aware of this problem.
From http://www.w3.org/MarkUp/ : XHTML 1.0 Transitional [...] The idea is to take advantage of XHTML features including style sheets but nonetheless to make small adjustments to your mark-up for the benefit of those viewing your pages with older browsers [...] So I'm all for Hixie's suggestion to make all transitional doctypes trigger the quirks mode. That seems to be in agreement with the specs. Please, stick to the standards, it's *the* thing mozilla is extremely good at.
About comment #33: Hixies suggestion solves the majority of the cases. Especially the xhtml cases, there people want a doctype and they often are to lazy to correct their markup. Transitional would be a godsend for them. Please, at least _try_ it with the transitional doctypes triggering quirks before you try to apply this patch/bug to mozilla. You'll see, it'll almost all of the sites work.
While no request has been made for 1.0 branch approval yet, the 1.0 drivers (myself and Jud Valeski in particular) feel that Karnaze's patch is an appropriate compromise on a tough issue with no obvious "right" answer. There's a "right" answer from a standards point-of-view, and from a compatibility (and vendor/embeddor) point-of-view, but they conflict. We should move forward with this on trunk as well.
I can't see what problem the 2nd solution in comment #31 would cause. It's a win-win situation. We would still be standards compliant and vendors would be saved from 95% of the current evangelism bug reports.
Re comment 37 (and the second solution in comment 31): The problem with adding to our list of quirks doctypes is that we actually want standards mode to be used, for a number of reasons. First, standards mode doesn't get that much testing, and we don't want it to have lots of nasty bugs that will show up in a few years once more real pages start triggering it. (Consider our standards mode form controls, where, for a long time, we emulated Nav 4.x's form control behavior in quirks mode and IE's in standards mode, and the standards mode controls were severely broken until we switched to them by default and discovered all the bugs.) Second, the point of standards mode is that we want our standards support to influence new pages that are being written today, but we want the compatible behavior for older pages. Thus the current best-practice DOCTYPEs should all be triggering standards mode, not quirks mode. The reality of the web is that authors don't understand the standards (and often don't even use validators, which only test a small subset of the requirements of the standards), they just test against browsers. If they're testing against Mozilla running in standards mode, they're much more likely to write good pages than if they're testing against Mozilla running in quirks mode.
Most web authors see "transitional" as beeing the logical equivalent for using "old" standards. A lot of comments say "I'm using transitional, but mozilla still renders it in standards mode". That's what's confusing web authors. That's what's confusing match.com. There are now more and more sites using "stricts", but it'll take it's time. We simply can't say we make standards mode non standards compliant to have more people testing the standards mode, that's inherently wrong.
> ------- Additional Comment #33 From Susie Wyshak 2002-06-19 11:23 ------- > Your offer to help sites is very generous yet not realistic. I was merely pointing out that Waterson's statement (that I was able to claim that we should follow the spec because I did not have to worry about the consequences) is incorrect. I *am* willing to do the work required. Just point the way. > ------- Additional Comment #38 From David Baron 2002-06-19 13:36 ------- > The problem with adding to our list of quirks doctypes is that we > actually want standards mode to be used, for a number of reasons. There is no point _having_ a standards mode if it doesn't follow the standards. > Second, the point of standards mode is that we want our standards > support to influence new pages that are being written today And it's working -- just look at how many sites we've affected *with this issue alone*. (See comment 25 -- over 20% of sites listed have actually gone and fixed themselves because of us.) > The reality of the web is that authors don't understand the > standards, they just test against browsers. Which is why our standards mode should be as close to the standards as humanly possible. > If they're testing against Mozilla running in standards mode, > they're much more likely to write good pages than if they're testing > against Mozilla running in quirks mode. Of course. But the reality of the situation is that we *now* have a whole bunch of *existing* pages that trigger our standards mode but expect to get rendered in a backwards-compatible way. Furthermore, all the DOCTYPEs I listed are *transitional* DOCTYPEs. The whole point of the *transitional* HTML modes is that they be renderered in a backwards-compatible way.
And what Arthur said.
Re comment 39: There's a big difference between the continued ability to use old markup and the ability to have correct standards support. There's been strong support (see bug 42525) for a way to trigger standards mode while still using some old markup in valid documents. Also note that IE's standards mode is triggered by *any* doctype that contains a system identifier in addition to the public identifier -- our conditions are much stricter than IE's.
Jud and I were referring to (suggesting) the "no-pref" patch that's r/sr'd http://bugzilla.mozilla.org/attachment.cgi?id=87692&action=view
If we allow agents to behave different from a stock Mozilla, Mozilla-Users will get more bad looking pages and maybe some embed agents with the pref set will get a deny - so the pref is no option imho. About Quirkt for XHTML 1.0 Transitional: I know many pages which only use Transitional because they need some special attributes, so you won't have a way to get cellpadding="" legal _and_ be in Standards mode. The others (non-official) DOCTYPEs (lovercased 4.01 and the internal IBM one have no W3C Standard behind them, so there's no standard we would break. so there are 2 real options: 1. get a stricter handling which DOCTYPE should go into Standards, which into Sloppy mode and send _all_ non 100% valid W3C DOCTYPEs (in addition to the current list) to Sloppy mode. 2. always use the non-standard line-height, which no webmaster really understands (I see at least 3 "Netscape sucks" with this problem in German SelfHTML forum - don't know, how many just kick Netscape 6/7/Mozilla without asking why it does this).
dbaron: Our compliance is also a lot stronger than IE's.
If there really are authors who want to trigger standards mode while using the transitional DTD, then they can trigger our standards mode by using an empty internal subset. Authors who are not concerned with legacy rendering behaviour really should just be using strict DTDs and stylesheets.
Attachment #87692 - Attachment is obsolete: true
Attachment #88159 - Attachment is obsolete: true
Attachment #88365 - Flags: superreview+
Attachment #88365 - Flags: review+
The patch (always use quirk line-height inside a TD) is in the trunk.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: [FIXED_ON_TRUNK]
Re comment 46: We want our standards compliance to affect more than just those who know and care about it.
So we want this to apply to <td> elements in the XHTML namespace in arbitrary XML content? (I think we do, but...) As a secondary point, the + nsCOMPtr<nsIDOMHTMLTableCellElement> cellContent(do_QueryInterface(content)); + if (cellContent) { is pretty slow when |content| does not implement nsIDOMHTMLTableCellElement (for example, any time "display:table-cell" is applied to random XML). If this happens often, it would be much better to do: if (content->IsContentOfType(nsIContent::eHTML)) { nsCOMPtr<nsIAtom> tag; content->GetTag(*getter_AddRefs(tag)); if (tag == nsHTMLAtoms::td) { return PR_TRUE; } }
Re Comment #49: What standards compliance? This bug is specifically about removing one of the corner stones of our efforst to implement the specs. VERIFIED FIXED on the trunk CVS tip. This caused regression bug 152959.
Status: RESOLVED → VERIFIED
Continuing the discussion from bug 22274 comment 76... Well I know its been a year, but the thing that I was thinking about proposing back then seems to be half implemented with this patch. In order to also cover comment 24, would it break anything (and how hard would it be to implement) to only use "strict" line-heights on inline items if there were #text nodes present in the containing block? Otherwise it would use the quirks-type calculation. This way if you had text, you'd presumably want the line-height to match that and use strict rendering, but if you did not have text, then you would not gain the seemingly magical (to anybody not familiar with the issues) line-height and it would work like it has in the past. You'd get the best of both worlds unless there are other things that would break. The benefits over bug 22274's resolution would be that most (if not all) pages should work (and it would cover <div>s too), and the benefit over this bug's resolution would be that we could still get the strict rendering in <td> elements. If this approach is feasible, I'll open another bug for it. Personally I'd like to see the Transitional DTD's moved to Quirks mode too.
I should note about my proposal that if line-height was explicitly applied, it would be honored instead of following the above formula. (So we don't get another bug like 152959). It would only be the inherited line-height's that would go through this filter.
Before this degenerates into irrelevant commentary, I'd like to slightly rephrase my comment. Unless we have a really good reason to use the slow QI method for that test, we should switch to the one I propose. For cases when the node is not an HTML table cell it's at least 20 times faster, last I checked....
Er, shouldn't this have the keyword for the release notes ? When will http://developer.netscape.com/evangelism/docs/articles/img-table/ be fixed ?
Boris, since your comments came after the patch was checked in, would you mind developing the patch and going through the approval and testing?
I'm at a loss as to why this risky and controversial patch was checked in, reducing our standards compliance instead of the equally effective and much safer fix of making transitional DOCTYPE trigger our transitional mode.
(The only reason that has been put forward is that it reduces the number of pages that are exposed to our standard mode handling, which seems a little silly considering the patch which has gone in.)
No, it's not silly. The differences between our standards mode and quirks mode are quite large, and this fix does something that the CSS working group is busy adding a CSS property just so that it can be made the default.
Wait, no, I have a better idea. We can just use quirks mode for all pages, and our strict mode will still be correct, and we can claim standards compliance, but it won't matter at all.
Filed bug 152979, attached patch. Reviews are quite welcome (though I suspect no one really cares and it'll just be a waste of my time to have bothered).
Actually, this patch is quite far from the behaviour the WG is discussing. I agree that it is unfortunate that authors are apparently assuming that "transitional" means "legacy rendering". But surely rendering pages that are written with this assumption in quirks mode is better than rendering _all_ documents incorrectly. Transitional documents are largely written with presentational HTML in mind, and CSS doesn't fit well with that kind of document. Quirks mode does. Strict documents, on the other hand, work very well with CSS. We should be encouraging authors to drop transitional altogether and write web pages that are structurally sound. Maybe we need three layout modes, as we had parsing modes at one point: Quirks, for HTML 3.2 and other legacy content, Transitional, which only has the few quirks that are needed for most validating but naively authored documents (i.e. doesn't have things like parsing unitless numbers as pixels, but does have the patch from this bug), and Standard, where we do what the spec says. Of course then we'd have even more to test and even fewer people testing each one, so that's not a perfect solution either. While I know your "better idea" was rhetorical, it is not analogous to what I am suggesting in comment 31, because there is no evidence that a large number of Strict DTD documents are failing because of this issue. There is ample evidence that the four DOCTYPEs I listed are used by sites affected by this "bug".
> encouraging authors to drop transitional altogether This is unfortunately impossible while NS4 has any sort of marketshare (and at the moment it still holds far more than we do). The current setup allows a content author to use presentational attributes (which are not in strict HTML) so that legacy browsers will have about the right color, alignment, background while at the same time using stylesheets in the modern browsers and not having to worry about rendering quirks due to "backwards compatibility" in said modern browsers....
For the record, since I was saying it somewhere else: The determination as to whether to go into standards mode would ideally be something like that we should go into standards mode for all pages written more than a few months after Mozilla became a well-known user-agent on the web (say, beginning of 2001). Our doctype detection is merely the best approximation for that we could come up with. Re comment 62: Perhaps a three-modes solution would be a good idea. The middle mode would only be noncompliant for this bug, for loading stylesheets that aren't 'text/css', and a few other things. Then we could drop the bar a bit and use the middle mode for more pages. I'd be willing to consider that, and perhaps even implement it. You could file a bug on me if you want.
Opened bug 153032 for implementing an additional rendering mode. I'd prefer that compared to the situation now where we have a quirks and a non-standards mode.
bug 153035 added for my proposal bug 153039 added for DOCTYPE change proposal Resolve as you will. I feel that either or both of these should be done instead of what this bug did.
Depends on: 153032
I propose we back out the patch checked in for this bug and instead work on the proposal in bug 153032.
Keywords: adt1.0.1, mozilla1.0.1, nsbeta1+
Whiteboard: [FIXED_ON_TRUNK] → [adt2 RTM] [FIXED_ON_TRUNK] [ETA 06/24]
Marking it topembed+
Keywords: topembed → topembed+
Adding adt1.0.1+ on behalf of the adt for checkin to the 1.0 branch. Please get drivers approval before checking in. When you check this into the branch, please change the mozilla1.0.1+ keyword to fixed1.0.1
Keywords: adt1.0.1 → adt1.0.1+
Keywords: approval
Sadly, I have to reopen this bug. I have verified with some simple tests that the patch is indeed operating in cases where images are all alone in a TD. However, it would seem that if an image is wrapped in a hyperlink (as is the case on match.com) then the patch doesn't kick in-- I presume due to the presence of the anchor's node. Since most images in tables are links, the patch as it stands is nowhere near sufficient to address the problem. I apologize for not catching this before the patch went in; I should have thought the implications through more clearly ahead of time. In addition, consider: <td> <img src=blah.gif> </td> I presume the spaces to either side of the IMG prevent the patch from working, which would drastically limit its usefulness as well. We need something that can detect cases where a TD contains images and optionally whitespace (but no visible characters) and does the quirks-mode layout. The current patch isn't that inclusive. If that's somehow too risky, we could consider adopting the approach outlined in bug 153032, or something like it. Of course, it might carry its own risks...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
removing adt1.0.1+, as this has been reopned. we'd really like this one on 1.0.1, so pls, pls come with a new fix soon.
Blocks: 143047
Keywords: adt1.0.1+
What you are asking for is basically the fully blown quirks inline box model, it would be very hard to implement it only for images (think :before, broken images showing alternate text, etc). I strongly recommend we back out the patch that was checked in and instead implement the suggestion gives in bug 153032.
No longer blocks: 143047
Keywords: adt1.0.1+
Blocks: 143047
Keywords: adt1.0.1+
I (personally) would be happy with a solution as spelled out in bug 153032.
Bug 153032 now has a new fix. I'm going to try and get reviews tomorrow.
The fix for bug 153032 has landed on the trunk. Should some of the keywords from this bug go there?
I'm not sure what the status of this bug should be, but it shouldn't be left open.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
This bug has a WONTFIX resolution but the status whiteboard says FIXED_ON_TRUNK. What does that mean?
The fix was backed out of the trunk as part of the landing of bug 153032.
Whiteboard: [adt2 RTM] [FIXED_ON_TRUNK] [ETA 06/24] → [adt2 RTM] [ETA 06/24]
VERIFIED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: