Closed Bug 151620 Opened 22 years ago Closed 22 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: 22 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: 22 years ago → 22 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: