916 bytes, image/png
5.26 KB, text/html
8.74 KB, patch
Mike Schroepfer: approval1.8b5+
|Details | Diff | Splinter Review|
5.39 KB, text/html
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux alpha; U;) Gecko/20021226 Debian/1.2.7-6 Build Identifier: Mozilla/5.0 Galeon/1.2.7 (X11; Linux alpha; U;) Gecko/20021226 Debian/1.2.7-6 According to the W3C HTML 2.0 and 4.01: http://www.w3.org/TR/1998/REC-html40-19980424/struct/objects.html#adef-align-IMG the align=middle attribute "means that the center of the object should be vertically aligned with the current baseline." Instead, Mozilla renders the image so that the center of the object is vertically aligned with the center of the text. This is correct for the CSS vertical-align:middle, but not for the HTML 4.0 align=middle. Reproducible: Always Steps to Reproduce: I need the original HTML 4.0 behavior (for rendering equations that are aligned with the text). Is it possible to do this using CSS?
Bob McElrath: are you aware of a current browser that renders as you are asking? The only I can find is Netscape 4.x. IE 5.0 and 6.0 render the same as Mozilla does, as do Opera 5 thru 7. (All these tests on Windows.) I concur with your reading of the spec, but... 'align' *is* deprecated, and Mozilla does agree with all those other browsers.
Netscape 4 and Konqueror render it correctly. Depreciated or not, the tag/attribute appears in old HTML documents, and should be rendered correctly. Rendering aligned with the baseline is the most desirable way to do it for in-line equations, but I'm open to suggestions. The CSS vertical-align:middle does not behave nicely as the font size is changed. Independent of my particular application, I think mozilla is doing it wrong and should be fixed...
OK, confirming. If Konqueror does this as you want, Safari probably does too.
Looking at the URL given in this bug with IE 6 SP1 it seems like it renders the middle and bottom case correctly. Only align="top" is rendered wrong. Mozilla only gets the align="bottom" case right (tested with 1.4-branch build 20030610 and Windows XP SP1). Should this bug be morphed to also cover align="top"?
*** Bug 209281 has been marked as a duplicate of this bug. ***
For the record, anyone wanting to do image equations in HTML should really be using the CSS vertical-align:middle (because HTML 4.0 is very old, and because equations with align="middle" require more blank space below the line to get it lined up). However I understand IE does not correctly render vertical-align:middle. (Confirmation, anyone?) I am using LatexWiki (an add on for Zope and ZWiki): http://mcelrath.org/Notes/LatexWiki The Sandbox: http://mcelrath.org/Notes/SandBox has some example equations and a place to type your own. I have converted everything to vertical-align:middle. However it requires that the browser obey font-size:16px, which is somewhat unreliable it seems. (experts want to comment on that?)
Re: comment 6 - No, we do align=top just fine.
-> me, since I have a fix.
Be aware that there will be a few minor Evangelism bugs caused by this. I'm looking through the top100 sites and so far I have found a couple of images at http://www.cnn.com that are a few pixels off.
I'd think there ought to be a -moz-middle-with-baseline CSS keyword or something like that. What happens now when you use GetComputedStyle on something with this as the computed value? Given that WinIE does the same thing we do, I'm not convinced we even want to fix this. Maybe the HTML spec should just be changed to align itself with CSS?
> there ought to be a -moz-middle-with-baseline Yes, good catch. > Given that WinIE does the same thing we do That's not what I'm seeing. I'm using IE6-sp1 on Win98 - looking at the testcases (both) I see what the HTML4.01 spec. says - the center of the image is aligned with the baseline. OTOH, IE6-sp1 does not seem to have the same problem at CNN.com as I saw - do they have a quirk perhaps?
I've just loaded the testcase up and I now see that IE6 is performing align=middle as desired by reporter. (This is IE6.0.2800.1106 SP1, with a passel of 'security patches' applied.)
Apparently, align="middle" is commonly used by TeX to HTML converters. Examples of important sites: http://planetmath.org/encyclopedia/ZermeloFraenkelAxioms.html http://mathworld.wolfram.com/FourierSeries.html Examples of LaTeX2HTML output (latest LaTeX2HTML version looks the same): http://www.wisdom.weizmann.ac.il/~tromer/papers/meshc/node2.html In all cases, Mozilla 1.6 mis-aligns the in-line equations. With Konquerer 3.1.4 and MSIE 6.0 SP1 the rendering is different, and complies with the site designer's intention as well as HTML 4.01. This is clearly a rendering bug in Mozilla, and it has a visible effect in practice. "Deprecated" or not, this should be a high priority issue.
Comment on attachment 125666 [details] [diff] [review] Patch rev. 1 you still need to fix the keyword issue
Created attachment 141430 [details] [diff] [review] Patch rev. 2 1. Added -moz-middle-with-baseline as suggested 2. Preferred "absmiddle" over "abscenter" as the canonical DOM value.
I have several complicated documents with math (up to 500 nodes and over 1500 images, among which a lot are inline). These were created in 1997 and were correctly rendered with Netscape 3.0. I would strongly support comment #17, and I would avoid recompiling or filtering theses documents. I even doubt that CSS solution might be satifactory for the future, as inline image alignment is a core feature that must be accetpable for any end-user configuration.
So is this change just to agree with what HTML4 says about presentation (which should really be out of the scope of HTML)? Does this make us agree with Nav4? With IE/Windows? Do you have testcases (testing CSS and HTML's middle, center, absmiddle, and abscenter)?
> So is this change just to agree with what HTML4 says about presentation (which > should really be out of the scope of HTML)? Yes. > Does this make us agree with Nav4? With IE/Windows? Yes. > Do you have testcases (testing CSS and HTML's middle, center, absmiddle, and > abscenter)? There is one attached to this bug. As noted by a previous poster, all HTML4 output of latex2html uses align=middle, so most of the math on the web using images is mis-aligned. One need look no farther than mathworld.wolfram.com to see it: http://mathworld.wolfram.com/FiberBundle.html Why is this fix controversial?
Comment on attachment 141430 [details] [diff] [review] Patch rev. 2 It's useful to have that information on the bug somewhere so I don't have to spend 15 minutes comparing the testcases -- but r+sr=dbaron if you also change "center" to be MIDDLE_WITH_BASELINE, since that's what IE/Windows does and the value isn't an official value in the spec.
In Mozilla, also still in Firefox 1.0 final, the diplaying of align="absmiddle" and align="middle" for images is vice versa as it's in the Internet-Explorer. So the images can only be placed correctly for one browser type, never for both. See e.g. the site http://www.diefilzwerkstatt.de/ in the galery sub-pages, e.g. http://www.internet-ideas.de/DieFilzwerkstatt/Bilder_Figuerliches.htm . Watch it with IE and it's displayed correctly.
(In reply to comment #25) > In Mozilla, also still in Firefox 1.0 final, the diplaying of > align="absmiddle" and align="middle" for images is vice versa as it's > in the Internet-Explorer. See e.g. > http://www.internet-ideas.de/DieFilzwerkstatt/Bilder_Figuerliches.htm . > > Watch it with IE and it's displayed correctly. If you load the test case (attachment 125662 [details]), you'll see that absmiddle is one of the cases where Mozilla and IE agree. The reason the images on your example page are not staggered in IE has to do with a subtler issue, which is seen in the test case with the blue borders which mark the "inline box" surrounding the text. IE extends the inline box containing the text to include the image. The first image (align=baseline, by default) extends the inline box upwards, so the box's "middle" is now the middle of that first image. The second image therefore aligns with the previous. Mozilla (and Opera) do not extend the inline box for the first image, so the "middle" remains the middle of the text; the second, absmiddle image aligns properly to that box. IE is at fault here. (That particular page could be done more nicely without relying on align.)
Can someone check attachment 141430 [details] [diff] [review] (r+,sr+) with the change in comment 24 ?
I have done some tests with the testcase in Firefox 1.0.6, Konqueror 3.4, Internet Explorer 6 SP2, Opera 8.02. The screenshots and some more data are here: http://www.danielclemente.com/html/align/
Created attachment 193224 [details] [diff] [review] Patch rev. 3 This one works with the current code. What does it do: 1. ALIGN=MIDDLE agrees with the HTML specification, and with IE and Konqueror. Not with Opera. 2. ALIGN=CENTER (not standard) does the same as MIDDLE. Agrees with IE. Not with Opera and Konqueror. 3. New CSS value for vertical-align: -moz-middle-with-baseline, which also does the same.
Created attachment 193281 [details] [diff] [review] Patch rev. 4 Thanks for updating the patch. We can actually remove |kVAlignTable| since it isn't used. I also cleaned it up by removing the "ebina" comments which I think are obsolete and just confusing.
Created attachment 193282 [details] Testcase #2 This is for testing the attribute value mappings. The latest patch makes all the HTML4 cases return what was specified. (currently we map IMG:bottom=>baseline and IMG:middle=>center) The non-HTML4 values (at the end) now reads: absmiddle:absmiddle abscenter:absmiddle baseline:bottom texttop:texttop center:middle
Comment on attachment 193281 [details] [diff] [review] Patch rev. 4 >+ pfd->mBounds.y = baselineY - pfd->mBounds.height/2; There are two spaces after the "-" where there should be one.
Comment on attachment 193281 [details] [diff] [review] Patch rev. 4 r+sr=dbaron
Checked in to trunk at 2005-08-30 15:46 PDT -> FIXED
Your checkin comment said "Correct the DOM attribute value mapping for some of the other values as well." What did you mean by that? Just align="center"? (I couldn't find any way the order in kAlignTable mattered, although it does in the tables in nsCSSProps.cpp when there's duplication, so I was slightly confused by your reordering at first.)
(In reply to comment #36) > Your checkin comment said "Correct the DOM attribute value mapping for some of > the other values as well." What did you mean by that? See comment 32. In Testcase #2, we now map for IMG bottom -> bottom and middle -> middle, that is we now use the HTML4 names. There is also a change in the non-standard ones at the end (new values noted in comment 32). The rest is the same.
Oh, I see. nsAttrValue::ParseEnumValue sticks aTable in tableStart before storing it, so I missed that when looking closely.
Comment on attachment 193281 [details] [diff] [review] Patch rev. 4 Perhaps we should take this on the branch? It also affects "Save as / Webpage complete" - we're saving align="center" where it should be "middle", making valid pages invalid (bug 308670).
I tihnk we're a bit late in the game to take this fix. Unless this is near-zero risk, we probably shouldn't take this.
DBaron - comments on level of risk for this bug at this stage of release?
Pretty low risk.
Checked in to MOZILLA_1_8_BRANCH at 2005-09-20 12:45 PDT