I would not call "Layout" fine-grained. In the core components (DOM, layout, style system) keeping up with the new bug flow is nearly impossible. Style system is the one I have the most experience with, and 50% of those are duplicates, while a further 40% are misunderstandings of the CSS spec... Leaving 90% of the time spent on those bugs (or about 4 hours a day each for a few people) basically wasted.
The file extension bug is unfortunately just not on people's radars... I want to fix it by I was kinda tied up with finishing up my thesis and graduating. Now that that's over, I should be able to fix it within the next week and a half or so.
The site actually goes out of its way to detect Mozilla and give it different JS... then it has that whole section of code not written and instead has some debug crap someone never bothered to take out. The debug crap is what people are seeing.
Of course the spec for HTML does not say how to handle spacing... The spec for HTML does not say how to actually _render_ anything. That's covered by CSS.
This will happen as soon as the OpenBSD folks (or anyone familiar with the OpenBSD kernel) write the assembly stubs needed by XPConnect. They have been approached about this repeatedly, and have repeatedly stated outright that they do not care to have Mozilla run on OpenBSD.
See http://www.mozilla.org/docs/web-developer/quirks/d octypes.html
Basically, a parser bug in NS6/0.9.4 and everything before made your page render in quirks mode. Removing the DTD URI from the doctype will make it render in quirks mode again.
Release notes are your friend. http://mozilla.org/releases/mozilla1.0/#devel second paragraph will tell you what's up.
Re:The coders are getting a bit punch though.
on
Mozilla RC3 Released
·
· Score: 2
So. You have two options. You can temporarily disable the feature. Or you can rewrite the whole thing from scratch, test it, test its interaction with other components, debug it, fix the issues, test it some more.
Guess which is more likely to happen in a freeze period right before a release?
The "experimental" stuff has landed on the trunk. That happened two weeks ago. That means it will be in Mozilla 1.1. It may or may not be in 1.0.1, depending.
A unstripped mozilla build would be well over 90MB in size.... fairly prohibitive as a download. Furthermore, the Linux kernel does not create core files for multithreaded programs. So even if it were unstripped there would be no core file.
The expected "correct" rendering is to put the divs side-by-side.
However, just adding up the widths gives us:
70% + 2% + 2% + 25% + 2% + 2% = 103% > 100%
Therefore the two divs cannot possibly fit side-by-side and
conforming UAs should show the "right" div below the "left" div (but
floated to the right).
Similar problems happen with the two divs with class="pointers" --
the widths of those two divs (including margins and padding) are
36% each, which, when added to the 33% of the DIV.right means those
three divs cannot all fit side-by-side either (as the image
indicating "correct" rendering would have them do).
The page uses no doctype, so is rendered in "quirks" mode by Mozilla instead of "standards" mode. Testing standards support in a mode that purposefully violates some standards to be compatible with existing content is silly...
That and the failure of any test of standards to validate in an HTML validator kinda casts doubt on the validity of the test...
Sorry, the CSS property index lists proprietary _properties_ but not properietary _values_ of properties. For example, reading that doesn't tell me that "cursor: hand" is a complete and utter IE-ism.
Slashdot Mirror
There aren't the resources to do it. There aren't even the resources to do the two branches we're doing, really.
That's a gecko. It looks nothing like the green Mozilla logo.
There is such a pref. See all.js in the Mozilla installation, search for "middle".
works too, y'know....
I would not call "Layout" fine-grained. In the core components (DOM, layout, style system) keeping up with the new bug flow is nearly impossible. Style system is the one I have the most experience with, and 50% of those are duplicates, while a further 40% are misunderstandings of the CSS spec... Leaving 90% of the time spent on those bugs (or about 4 hours a day each for a few people) basically wasted.
> Why not run Mozilla locally
Because I do not own a Solaris machine and need to test Mozilla/Solaris?
Two words:
Library Stripping.
The file extension bug is unfortunately just not on people's radars... I want to fix it by I was kinda tied up with finishing up my thesis and graduating. Now that that's over, I should be able to fix it within the next week and a half or so.
The site actually goes out of its way to detect Mozilla and give it different JS... then it has that whole section of code not written and instead has some debug crap someone never bothered to take out. The debug crap is what people are seeing.
Of course the spec for HTML does not say how to handle spacing... The spec for HTML does not say how to actually _render_ anything. That's covered by CSS.
This will happen as soon as the OpenBSD folks (or anyone familiar with the OpenBSD kernel) write the assembly stubs needed by XPConnect. They have been approached about this repeatedly, and have repeatedly stated outright that they do not care to have Mozilla run on OpenBSD.
See http://www.mozilla.org/docs/web-developer/quirks/d octypes.html
Basically, a parser bug in NS6/0.9.4 and everything before made your page render in quirks mode. Removing the DTD URI from the doctype will make it render in quirks mode again.
Release notes are your friend. http://mozilla.org/releases/mozilla1.0/#devel second paragraph will tell you what's up.
So. You have two options. You can temporarily disable the feature. Or you can rewrite the whole thing from scratch, test it, test its interaction with other components, debug it, fix the issues, test it some more.
Guess which is more likely to happen in a freeze period right before a release?
The "experimental" stuff has landed on the trunk. That happened two weeks ago. That means it will be in Mozilla 1.1. It may or may not be in 1.0.1, depending.
A unstripped mozilla build would be well over 90MB in size.... fairly prohibitive as a download. Furthermore, the Linux kernel does not create core files for multithreaded programs. So even if it were unstripped there would be no core file.
er, padding on the "ul"
As a note, putting borders on all the elements involved should make it clear what's going on.
is completely under the float. So the rendering is almost correct (the overlap of the float and the bullets is an error).
Here is the mail I just sent the testcase author about the second testcase:
The second testcase [2] has the following style rules:
DIV.left {
float: left;
width: 70%;
}
DIV.right {
padding: 2%;
margin: 2%;
float: right;
width: 25%;
}
The expected "correct" rendering is to put the divs side-by-side.
However, just adding up the widths gives us:
70% + 2% + 2% + 25% + 2% + 2% = 103% > 100%
Therefore the two divs cannot possibly fit side-by-side and
conforming UAs should show the "right" div below the "left" div (but
floated to the right).
Similar problems happen with the two divs with class="pointers" --
the widths of those two divs (including margins and padding) are
36% each, which, when added to the 33% of the DIV.right means those
three divs cannot all fit side-by-side either (as the image
indicating "correct" rendering would have them do).
to 0, but does not change the padding. In Mozilla the margin is already 0 by default but the _padding_ is not. As a result, the
ends 40px wider than the testcase thinks it should.
This is an authoring error, pure and simple.
Looking at the second testcase now.
The page uses no doctype, so is rendered in "quirks" mode by Mozilla instead of "standards" mode. Testing standards support in a mode that purposefully violates some standards to be compatible with existing content is silly...
That and the failure of any test of standards to validate in an HTML validator kinda casts doubt on the validity of the test...
Sorry, _I_ use some of those other things. And I _never_ use "back". But then I'm a keyboard-mostly user and I just use alt-left...
Except data: can't read things off your hard drive...
Sorry, the CSS property index lists proprietary _properties_ but not properietary _values_ of properties. For example, reading that doesn't tell me that "cursor: hand" is a complete and utter IE-ism.
Unfortunately the same is true of IE/Windows (up to and including version 6.0 -- try using static positioning sometime....)