JavaScript pings often aren't obvious by looking at the status bar. If there's a normal href attribute but an onclick or onmouse(down|up) attribute that does something different, the href attribute will show up in the status bar, and the user may never know about the ping that happens via JavaScript combined with an HTTP redirect (although connection latency is usually high enough that it's briefly visible in the URL bar).
Part of the plan, as I understand it, is to put something very similar to what you suggest in the status bar before this ships in any release.
I'd also note that Ferris's bug report (bug 307259) originally claimed that the vulnerability was a format string vulnerability, not a buffer overrun, and that the testcase he showed us was a huge testcase probably generated by a tool for generating mangled HTML (like MangleMe). What he published in his advisory wasn't analysis he gave to us when he reported the bug, but looks like it was copied from:
the analysis that I did and posted in comment 2 on the bug (which was accessible to him, since he reported it), excluding the correction I made in comment 9 (when I realized the characters I was looking at were not dashes, but soft hyphens), and
the testcase that Jesse Ruderman wrote and attached to the bug.
You can control for performance pretty well if you simulate the throughput and latency characteristics of various types of internet connection on a closed network on which there are no machines other than the client and the test server. And there's random variation when loading from local files too.
There are a bunch of things I'd have done differently when doing a report like this.
The most important one is trying to measure something as close as possible to the Web browsing experience. That means loading pages over a network (at 56K, DSL, Cable, and/or T1 speeds, with some latency) rather than from local files, and loading pages that look more like a random sampling of Web pages rather than constructed examples (e.g., a page with tons of absolutely positioned elements). When the author of the test constructs examples like those used here for the "Rendering CSS", "Rendering Table", "Script speed", and "Multiple Images" benchmarks, the results will have a bias (relative to average performance browsing the Web) towards one browser or another. I'm not saying the author of the tests chose to bias it in a certain direction; merely that constructed tests like this will always have some bias. When such tests become widely used by the press (as iBench has), it even leads browser makers to optimize for the tests rather than for what matters for users.
Also, when testing startup times on Linux (especially cold startup), it makes a huge difference whether starting in a KDE (QT-based environment), GNOME (GTK+-based environment), or other environment, since it affects which shared libraries are already in memory. Testing Mozilla's startup times under GNOME (especially if using a GTK2 version of Mozilla under GNOME 2, or a GTK1 version of Mozilla under GNOME 1) would have improved its performance significantly.
Finally, Mozilla 1.8 hasn't been released yet, so I'm a little puzzled how it was tested. The released version will have changes from the current development version, so it will perform differently. It may be a slight difference, but the report should really say exactly what is tested.
These preferences (font.FreeType2.*, etc.) trigger different antialiased font code -- code that uses FreeType directly rather than going through Xft2 and fontconfig. This requires that the user configure TrueType fonts separately for Mozilla.
There's been a bit of debate about which approach is better. I'm strongly in the "don't reinvent the wheel" camp, and thus I prefer Xft to the direct use of FreeType.
could you explain how a pre-compiled binary executes any faster than an identical user-compiled binary? if you're compiling for the same arcitecture with the same library base as the disributed-binary at compile time, it will be identical.
You're assuming that the user is compiling with the same build options. That's likely not to be the case. By default, Mozilla builds are debug builds, unless you explicitly configure with --disable-debug and --enable-optimize. Those aren't the only options used in releases, either. Essentially, the build system is designed to be easy for developers (who often want debug builds) under the assumption (perhaps a questionable one) that normal users will download binaries.
Automatic image resizing is off by default in Mozilla (although on by default in Phoenix), and can be toggled by clicking on the image.
I have to say I don't like it much either. For Phoenix users, it can be turned off by adding user_pref("browser.enable_automatic_image_resizing ", false); to user.js in the profile directory, or by manipulating the browser.enable_automatic_image_resizing preference in about:config.
The RPMs for RedHat 8 have the Xft support enabled. (They're not released yet, but they probably will be soon.)
It's not enabled by default because it requires libraries (Xft2, fontconfig) that many users don't have. At some point someone might modify the code so that it tests for the presence of the library and loads all the required function pointers manually, but that's a bit of work. What's available now is good enough for distributors and good enough for people who know to get the RH8 RPMs.
I'm glad that XHTML 2.0 is no longer backwards compatible. Given that it's not, fixing known problems with the HTML vocabulary is a good idea.
Why do I dislike XHTML 1.0's backwards compatibility? XHTML 1.0 encouraged authors to serve XHTML as text/html, the same MIME type as legacy HTML. Furthermore, it didn't provide any guidelines for how browsers should decide whether something served as text/html should be handled using an XML parser. (Had XHTML 1.0, right from the start, decreed that any HTML document begining with "<?xml " be treated as XHTML, the problem might have been avoided.) Some authors (although not that many) started writing XHTML right after the spec came out, thinking it was the cool new thing to be doing. This meant that there was already a good bit of invalid XHTML as text/html on the web before any user agents could start parsing it as XML and enforcing the strict error handling that is one of the main advantages of XML.
It seems like you're suggesting that validation assures standards-compliance. Validation does not ensure standards-compliance.
HTML Validation only ensures that you've met certain constraints of syntax and containment, but it doesn't ensure that you're following the standard. If you're using one of the Transitional doctype declarations, it doesn't ensure that you're avoiding deprecated features. More importantly, it doesn't show if you're depending on a bug in the browsers you're testing in. For example, a browser that doesn't implement section 14.3 of the HTML 4.0 spec correctly (pretty much any browser other than Mozilla, right now) might load stylesheets that the HTML spec says shouldn't be loaded. Thus you'll have valid markup, and your browser will load your stylesheets, but any standards-compliant browser will treat some of your stylesheets as alternate stylesheets and not load them. (This happens if you specify different title attributes on the LINK element linking to the stylesheets, since it makes some of the stylesheets alternate stylesheets.) Similar traps can happen in other ways and allow you to write perfectly valid markup that means something other than what you think it does and what you intended it to do.
CSS validation has similar problems. (It also has the problem that the validators themselves have rather significant bugs, since there aren't any mature implementations of CSS parsers using which one can build validators like the SGML parsers on which HTML validators are based.) For example, MSIE for Windows treats the height property on block-level elements incorrectly: it treats it as min-height and allows the height of the block to be larger if the contents overflow. This is incorrect, so there are pages that are displayed nicely on MSIE for Windows but have lots of overlapping text on any CSS-compliant browser. Likewise, you could be writing pages that work fine at your default font size or window width but display very badly at others.
In other words, validation tools for HTML and CSS are nowhere near smart enough to be a substitute for really knowing what you're doing. (Does anyone rely on lint to verify that their C programs are bug-free?)
(I actually wrote this post before on slashdot, but way too late in the thread for anyone to notice it. I'm afraid I'm doing the same thing again, though...)
What matters to users isn't how many CPU cycles transformations take, but how fast they are. In many cases, using a bit of CPU on the client will lead to a much faster transition than retrieving a complete new page from the server (after having the server's CPU do the same work).
However, it's worth noting that it's probably a bad idea to send large amounts of data in XML formats without known semantics over the web. Semantically rich formats such as (X)HTML, MathML, etc., can be interpreted better by user agents other than those the author intended them for (e.g., cell phones with web browsers, speech web browsers, search engines), while formats such as XSL-FO or some custom XML vocabulary used within a single application for data storage can't be interpreted nearly as well on such devices. I have mixed feelings about relaxing this guideline for interactive applications, although I think if the interactive applications are generating their output on the client side in a format with known semantics then most of the problems go away, although the chances that the formats will continue to work for a long time in the future might be diminished.
No, it's not just an embedding widget. A port of Mozilla to a toolkit is code that maps the interface Mozilla uses for interacting with native widgets and event queues (the part in widget/src/qt/) and graphics devices (the part in gfx/src/qt/) to the particular toolkit's API.
The default Unix port of Mozilla uses GTK+. (It's the default in the build system for platforms other than Windows, Mac, OS/2, BeOS, and QNX, and it's the one distributed in mozilla.org release builds for all but those platforms.) This means that many of the interactions between Mozilla and Xlib have GTK code in the middle. (Not all of them do -- some parts of the code, such as the font code, uses Xlib APIs directly, although the Xft builds use Xft2 and fontconfig APIs instead.) It also means Mozilla gets a good bit of look-and-feel information from GTK themes (more recently than it used to).
In addition to the GTK+ port, there are also a raw Xlib port (no toolkit between Mozilla and Xlib) and a QT port, but the QT port is poorly maintained and will be removed if no maintainer steps up (as the Motif port was a while ago).
Some of the ports also come with embedding widgets that allow embedding of the layout engine into programs using those toolkits. However, the embedding widget is just a small and optional part of the port. I also don't see any reason that it wouldn't be possible to use a QT embedding widget for Mozilla even if Mozilla is using GTK+ internally.
The fix to bug 182500 was a single character. An 9 was changed to an 8. There was not a backout of way too much code.
The problem was that a checkin that added a value to an array was incorrectly backed out. The size of the array was written explicitly instead of using sizeof and preprocessor magic, and the change to the size wasn't backed out along with the value added to the end of the array. The incorrect size caused whatever random data was stored after the end of the array to be read. (The array was in the HTML parser, containing a list of the types of things that are valid children of the HEAD element. Thus, I think the bugs can be traced to things that should have been in the BODY ending up in the HEAD.) Depending on the compiler, this caused different behavior, so the bug was worse on Windows (with MSVC 6.0) or on gcc 3.2 (on x86 Linux) than it was with egcs 1.1.2 (on x86 Linux).
So, in other words, the size of the binaries shouldn't have changed. That's odd.
The article described three voting systems: instant runoff (also known as single transferrable vote, etc.), Borda count, and approval voting. The instant runoff and Borda count systems both have the disadvantage that they require voters to rank all the candidates. The instant runoff system also has the disadvantage that voters can't really express strong dislike of a certain candidate very well (or at least that such an expression doesn't matter until the last round or two).
Approval voting requires the smallest changes to the US's current voting procedure: after all, voting for a single candidate is a valid way of voting, although it may not be a good idea. Approval voting is also the only voting system that allows voters to express the differences between their preferences for various candidates, although only in a probabilistic sort of way (since the split between "approve" and "don't approve" should fall at one of the larger gaps). It also seems that it would be harder to find ways (such as "how to vote" cards) to trick the system.
Yes, none of the systems is perfect, but approval voting seems to be a good choice and something to which we could easily transition.
This book covers a huge amount of material. After all, DHTML is just a name used for the interaction of a bunch of different things, and this book seems to try to cover all of them. I wonder whether Goodman is really an expert on all of it (or whether anyone can be). I'd be a lot more comfortable trusting a book like this if it were written by a group of authors with different areas of expertise.
Looking at what I can find about the book's coverage of CSS (which I know a lot about), I'm not optimistic. He seems to make up his own terminology, which can cause significant confusion in any public discussions. He uses the word "attributes" instead of "properties" (e.g., the CSS 'position' property) in the sample chapter available at O'Reilly. This is a mistake that's become very common these days, perhaps due to earlier editions of this book, and causes lots of confusion when people really need to discuss attributes (in HTML). The table of contents also shows sections titled by terms that he seems to have made up: "Common Subgroup Selectors" and "Advanced Subgroup Selectors".
It could be that he's decided he doesn't like the terminology used by the CSS specification so he's making new terminology. Such a decision has significant costs for communication between and among web developers and standards organizations. However, I fear it may not even be a conscious decision, but rather than he just doesn't know enough about CSS to know the correct terminology. (Not that I would expect any one person to be able to learn enough about all the topics covered in this book to be an authority on all of them.)
(If you want a good book on CSS, look for Eric Meyer's books on CSS, one of which is also published by O'Reilly.)
This particular thing is new (to some extent, but see below) since it's tracking the reverse of what is tracked through the HTTP Referer header.
However, it's also worth noting that some sites get this information already (especially when money is at stake) by making external links go through a local URL that redirects to the off-site URL.
This workaround will only disable one of the ways the bug can be exploited (albeit the easier way to exploit it). Based on my reading of the bug, it can also be exploited through timeouts, although methods for doing so are probably less reliable.
It's easy. Write standards-compliant pages, validate, and you're done.
It seems like you're suggesting that validation assures standards-compliance. (If not, then I apologize, but I've heard the same in other places, so I may as well respond.) Validation does not ensure standards-compliance.
HTML Validation only ensures that you've met certain constraints of syntax and containment, but it doesn't ensure that you're following the standard. If you're using one of the Transitional doctype declarations, it doesn't ensure that you're avoiding deprecated features. More importantly, it doesn't show if you're depending on a bug in the browsers you're testing in. For example, a browser that doesn't implement section 14.3 of the HTML 4.0 spec correctly (pretty much any browser other than Mozilla, right now) might load stylesheets that the HTML spec says shouldn't be loaded. Thus you'll have valid markup, and your browser will load your stylesheets, but any standards-compliant browser will treat some of your stylesheets as alternate stylesheets and not load them. (This happens if you specify different title attributes on the LINK element linking to the stylesheets, since it makes some of the stylesheets alternate stylesheets.) Similar traps can happen in other ways and allow you to write perfectly valid markup that means something other than what you think it does and what you intended it to do.
CSS validation has similar problems. (It also has the problem that the validators themselves have rather significant bugs, since there aren't any mature implementations of CSS parsers using which one can build validators like the SGML parsers on which HTML validators are based.) For example, MSIE for Windows treats the height property on block-level elements incorrectly: it treats it as min-height and allows the height of the block to be larger if the contents overflow. This is incorrect, so there are pages that are displayed nicely on MSIE for Windows but have lots of overlapping text on any CSS-compliant browser. Likewise, you could be writing pages that work fine at your default font size or window width but display very badly at others.
In other words, validation tools for HTML and CSS are nowhere near smart enough to be a substitute for really knowing what you're doing. (Does anyone rely on lint to verify that their C programs are bug-free?)
Now if I could only figure out what the W3 means by "inline, non-replaced elements" as opposed to "inline, replaced elements"...
CSS2 defines a replaced element as an element whose content is ignored, but instead replaced by something else with intrinsic dimensions. In other words, things like IMG and OBJECT are replaced elements. Most HTML elements, such as P, BLOCKQUOTE, STRONG, and BODY are non-replaced elements. It defines an inline element to be an element that is formatted within a line. This is the default presentation of elements like A, EM, STRONG, DFN, etc., whereas elements like P, UL, LI, DIV, BODY, and BLOCKQUOTE are block-level elements by default. (This can be changed with the CSS display property.)
Thus elements such as A, SPAN, EM, etc., are non-replaced inline elements by default (unless a stylesheet changes the display property). The IMG element is a replaced inline element by default. (Specifying display: block makes it a replaced block-level element, which can be useful, although it doesn't work well on some older browsers.)
Re:Native OS widgets cannot be used if you want CS
on
Netscape 6.2
·
· Score: 1
I agree that the CSS spec certainly does not require that any form widgets be stylable. The CSS2 model is not sufficient to describe the rendering of even the simplest form widgets (mainly due to the weakness of its anonymous content generation and lack of some concepts in the box model). Therefore the CSS spec doesn't define how form widgets should respond to CSS styles. I think (although some others disagree) that this implies that a user-agent that applies any CSS styles to form controls is extending CSS.
Proposals such as XBL would add to CSS a model that is sufficient to describe the behavior of form controls. With that or a similar proposal one could have styling of form controls within the CSS spec.
Even then, I doubt the CSS spec would ever require that user-agents avoid native form controls in favor of stylable ones. (It is possible that user agents with native form controls would not be able to implement all modules of CSS since they would not be able to implement the module describing the styling of form controls.) After all, native form controls give the user a more consistent and usually better user interface.
Slashdot Mirror
I'd also note that Ferris's bug report (bug 307259) originally claimed that the vulnerability was a format string vulnerability, not a buffer overrun, and that the testcase he showed us was a huge testcase probably generated by a tool for generating mangled HTML (like MangleMe). What he published in his advisory wasn't analysis he gave to us when he reported the bug, but looks like it was copied from:
You can control for performance pretty well if you simulate the throughput and latency characteristics of various types of internet connection on a closed network on which there are no machines other than the client and the test server. And there's random variation when loading from local files too.
There are a bunch of things I'd have done differently when doing a report like this.
The most important one is trying to measure something as close as possible to the Web browsing experience. That means loading pages over a network (at 56K, DSL, Cable, and/or T1 speeds, with some latency) rather than from local files, and loading pages that look more like a random sampling of Web pages rather than constructed examples (e.g., a page with tons of absolutely positioned elements). When the author of the test constructs examples like those used here for the "Rendering CSS", "Rendering Table", "Script speed", and "Multiple Images" benchmarks, the results will have a bias (relative to average performance browsing the Web) towards one browser or another. I'm not saying the author of the tests chose to bias it in a certain direction; merely that constructed tests like this will always have some bias. When such tests become widely used by the press (as iBench has), it even leads browser makers to optimize for the tests rather than for what matters for users.
Also, when testing startup times on Linux (especially cold startup), it makes a huge difference whether starting in a KDE (QT-based environment), GNOME (GTK+-based environment), or other environment, since it affects which shared libraries are already in memory. Testing Mozilla's startup times under GNOME (especially if using a GTK2 version of Mozilla under GNOME 2, or a GTK1 version of Mozilla under GNOME 1) would have improved its performance significantly.
Finally, Mozilla 1.8 hasn't been released yet, so I'm a little puzzled how it was tested. The released version will have changes from the current development version, so it will perform differently. It may be a slight difference, but the report should really say exactly what is tested.
The following is a full list of the primary and secondary mirrors that have Firefox 0.8 builds. This list will also be maintained and updated.
Apologies for not listing one per line, but slashdot rejects posts with "too few characters per line".
North America: mozilla.isc.org (http) mozilla.isc.org (ftp) trillian.cc.gatech.edu (http) trillian.cc.gatech.edu (ftp) mozilla.ussg.indiana.edu (http) mozilla.ussg.indiana.edu (ftp) mozilla.oregonstate.edu (http) mozilla.oregonstate.edu (ftp) mozilla.gnusoft.net (http)
Europe: sunsite.rediris.es (http) sunsite.rediris.es (ftp) sunsite.cnlab-switch.ch (ftp) ftp.cvut.cz (ftp) www.artfiles.org (http) ftp.rediris.es (ftp) ftp.rediris.es (http) ftp.task.gda.pl (ftp) ftp.task.gda.pl (http) sunsite.icm.edu.pl (ftp) (Windows only) sunsite.icm.edu.pl (http) (Windows only) ftp.mirror.ac.uk (ftp)
Asia/Australia: ftp.lab.kdd.co.jp (ftp) ftp.kaist.ac.kr (http) ftp.kaist.ac.kr (ftp) ftp.nctu.edu.tw (ftp) mozilla.mirror.pacific.net.au (ftp) mozilla.mirror.pacific.net.au (http)
These preferences (font.FreeType2.*, etc.) trigger different antialiased font code -- code that uses FreeType directly rather than going through Xft2 and fontconfig. This requires that the user configure TrueType fonts separately for Mozilla.
There's been a bit of debate about which approach is better. I'm strongly in the "don't reinvent the wheel" camp, and thus I prefer Xft to the direct use of FreeType.
You're assuming that the user is compiling with the same build options. That's likely not to be the case. By default, Mozilla builds are debug builds, unless you explicitly configure with --disable-debug and --enable-optimize. Those aren't the only options used in releases, either. Essentially, the build system is designed to be easy for developers (who often want debug builds) under the assumption (perhaps a questionable one) that normal users will download binaries.
Automatic image resizing is off by default in Mozilla (although on by default in Phoenix), and can be toggled by clicking on the image.
I have to say I don't like it much either. For Phoenix users, it can be turned off by adding user_pref("browser.enable_automatic_image_resizing ", false); to user.js in the profile directory, or by manipulating the browser.enable_automatic_image_resizing preference in about:config .
The RPMs for RedHat 8 have the Xft support enabled. (They're not released yet, but they probably will be soon.)
It's not enabled by default because it requires libraries (Xft2, fontconfig) that many users don't have. At some point someone might modify the code so that it tests for the presence of the library and loads all the required function pointers manually, but that's a bit of work. What's available now is good enough for distributors and good enough for people who know to get the RH8 RPMs.
Autocomplete doesn't use machine learning in 1.3. It was an experimental, disabled-by-default, feature in 1.3beta for data-collection.
I'm glad that XHTML 2.0 is no longer backwards compatible. Given that it's not, fixing known problems with the HTML vocabulary is a good idea.
Why do I dislike XHTML 1.0's backwards compatibility? XHTML 1.0 encouraged authors to serve XHTML as text/html, the same MIME type as legacy HTML. Furthermore, it didn't provide any guidelines for how browsers should decide whether something served as text/html should be handled using an XML parser. (Had XHTML 1.0, right from the start, decreed that any HTML document begining with "<?xml " be treated as XHTML, the problem might have been avoided.) Some authors (although not that many) started writing XHTML right after the spec came out, thinking it was the cool new thing to be doing. This meant that there was already a good bit of invalid XHTML as text/html on the web before any user agents could start parsing it as XML and enforcing the strict error handling that is one of the main advantages of XML.
It seems like you're suggesting that validation assures standards-compliance. Validation does not ensure standards-compliance.
HTML Validation only ensures that you've met certain constraints of syntax and containment, but it doesn't ensure that you're following the standard. If you're using one of the Transitional doctype declarations, it doesn't ensure that you're avoiding deprecated features. More importantly, it doesn't show if you're depending on a bug in the browsers you're testing in. For example, a browser that doesn't implement section 14.3 of the HTML 4.0 spec correctly (pretty much any browser other than Mozilla, right now) might load stylesheets that the HTML spec says shouldn't be loaded. Thus you'll have valid markup, and your browser will load your stylesheets, but any standards-compliant browser will treat some of your stylesheets as alternate stylesheets and not load them. (This happens if you specify different title attributes on the LINK element linking to the stylesheets, since it makes some of the stylesheets alternate stylesheets.) Similar traps can happen in other ways and allow you to write perfectly valid markup that means something other than what you think it does and what you intended it to do.
CSS validation has similar problems. (It also has the problem that the validators themselves have rather significant bugs, since there aren't any mature implementations of CSS parsers using which one can build validators like the SGML parsers on which HTML validators are based.) For example, MSIE for Windows treats the height property on block-level elements incorrectly: it treats it as min-height and allows the height of the block to be larger if the contents overflow. This is incorrect, so there are pages that are displayed nicely on MSIE for Windows but have lots of overlapping text on any CSS-compliant browser. Likewise, you could be writing pages that work fine at your default font size or window width but display very badly at others.
In other words, validation tools for HTML and CSS are nowhere near smart enough to be a substitute for really knowing what you're doing. (Does anyone rely on lint to verify that their C programs are bug-free?)
(I actually wrote this post before on slashdot, but way too late in the thread for anyone to notice it. I'm afraid I'm doing the same thing again, though...)
What matters to users isn't how many CPU cycles transformations take, but how fast they are. In many cases, using a bit of CPU on the client will lead to a much faster transition than retrieving a complete new page from the server (after having the server's CPU do the same work).
However, it's worth noting that it's probably a bad idea to send large amounts of data in XML formats without known semantics over the web. Semantically rich formats such as (X)HTML, MathML, etc., can be interpreted better by user agents other than those the author intended them for (e.g., cell phones with web browsers, speech web browsers, search engines), while formats such as XSL-FO or some custom XML vocabulary used within a single application for data storage can't be interpreted nearly as well on such devices. I have mixed feelings about relaxing this guideline for interactive applications, although I think if the interactive applications are generating their output on the client side in a format with known semantics then most of the problems go away, although the chances that the formats will continue to work for a long time in the future might be diminished.
No, it's not just an embedding widget. A port of Mozilla to a toolkit is code that maps the interface Mozilla uses for interacting with native widgets and event queues (the part in widget/src/qt/) and graphics devices (the part in gfx/src/qt/) to the particular toolkit's API.
The default Unix port of Mozilla uses GTK+. (It's the default in the build system for platforms other than Windows, Mac, OS/2, BeOS, and QNX, and it's the one distributed in mozilla.org release builds for all but those platforms.) This means that many of the interactions between Mozilla and Xlib have GTK code in the middle. (Not all of them do -- some parts of the code, such as the font code, uses Xlib APIs directly, although the Xft builds use Xft2 and fontconfig APIs instead.) It also means Mozilla gets a good bit of look-and-feel information from GTK themes (more recently than it used to).
In addition to the GTK+ port, there are also a raw Xlib port (no toolkit between Mozilla and Xlib) and a QT port, but the QT port is poorly maintained and will be removed if no maintainer steps up (as the Motif port was a while ago).
Some of the ports also come with embedding widgets that allow embedding of the layout engine into programs using those toolkits. However, the embedding widget is just a small and optional part of the port. I also don't see any reason that it wouldn't be possible to use a QT embedding widget for Mozilla even if Mozilla is using GTK+ internally.
The fix to bug 182500 was a single character. An 9 was changed to an 8. There was not a backout of way too much code.
The problem was that a checkin that added a value to an array was incorrectly backed out. The size of the array was written explicitly instead of using sizeof and preprocessor magic, and the change to the size wasn't backed out along with the value added to the end of the array. The incorrect size caused whatever random data was stored after the end of the array to be read. (The array was in the HTML parser, containing a list of the types of things that are valid children of the HEAD element. Thus, I think the bugs can be traced to things that should have been in the BODY ending up in the HEAD.) Depending on the compiler, this caused different behavior, so the bug was worse on Windows (with MSVC 6.0) or on gcc 3.2 (on x86 Linux) than it was with egcs 1.1.2 (on x86 Linux).
So, in other words, the size of the binaries shouldn't have changed. That's odd.
The article described three voting systems: instant runoff (also known as single transferrable vote, etc.), Borda count, and approval voting. The instant runoff and Borda count systems both have the disadvantage that they require voters to rank all the candidates. The instant runoff system also has the disadvantage that voters can't really express strong dislike of a certain candidate very well (or at least that such an expression doesn't matter until the last round or two).
Approval voting requires the smallest changes to the US's current voting procedure: after all, voting for a single candidate is a valid way of voting, although it may not be a good idea. Approval voting is also the only voting system that allows voters to express the differences between their preferences for various candidates, although only in a probabilistic sort of way (since the split between "approve" and "don't approve" should fall at one of the larger gaps). It also seems that it would be harder to find ways (such as "how to vote" cards) to trick the system.
Yes, none of the systems is perfect, but approval voting seems to be a good choice and something to which we could easily transition.
This book covers a huge amount of material. After all, DHTML is just a name used for the interaction of a bunch of different things, and this book seems to try to cover all of them. I wonder whether Goodman is really an expert on all of it (or whether anyone can be). I'd be a lot more comfortable trusting a book like this if it were written by a group of authors with different areas of expertise.
Looking at what I can find about the book's coverage of CSS (which I know a lot about), I'm not optimistic. He seems to make up his own terminology, which can cause significant confusion in any public discussions. He uses the word "attributes" instead of "properties" (e.g., the CSS 'position' property) in the sample chapter available at O'Reilly. This is a mistake that's become very common these days, perhaps due to earlier editions of this book, and causes lots of confusion when people really need to discuss attributes (in HTML). The table of contents also shows sections titled by terms that he seems to have made up: "Common Subgroup Selectors" and "Advanced Subgroup Selectors".
It could be that he's decided he doesn't like the terminology used by the CSS specification so he's making new terminology. Such a decision has significant costs for communication between and among web developers and standards organizations. However, I fear it may not even be a conscious decision, but rather than he just doesn't know enough about CSS to know the correct terminology. (Not that I would expect any one person to be able to learn enough about all the topics covered in this book to be an authority on all of them.)
(If you want a good book on CSS, look for Eric Meyer's books on CSS, one of which is also published by O'Reilly.)
er, ~/.mozilla///prefs.js
(Why don't < and > work when I select "Plain old Text"?)
The user preferences file should be
~/.mozilla///prefs.js
This particular thing is new (to some extent, but see below) since it's tracking the reverse of what is tracked through the HTTP Referer header.
However, it's also worth noting that some sites get this information already (especially when money is at stake) by making external links go through a local URL that redirects to the off-site URL.
This workaround will only disable one of the ways the bug can be exploited (albeit the easier way to exploit it). Based on my reading of the bug, it can also be exploited through timeouts, although methods for doing so are probably less reliable.
It seems like you're suggesting that validation assures standards-compliance. (If not, then I apologize, but I've heard the same in other places, so I may as well respond.) Validation does not ensure standards-compliance.
HTML Validation only ensures that you've met certain constraints of syntax and containment, but it doesn't ensure that you're following the standard. If you're using one of the Transitional doctype declarations, it doesn't ensure that you're avoiding deprecated features. More importantly, it doesn't show if you're depending on a bug in the browsers you're testing in. For example, a browser that doesn't implement section 14.3 of the HTML 4.0 spec correctly (pretty much any browser other than Mozilla, right now) might load stylesheets that the HTML spec says shouldn't be loaded. Thus you'll have valid markup, and your browser will load your stylesheets, but any standards-compliant browser will treat some of your stylesheets as alternate stylesheets and not load them. (This happens if you specify different title attributes on the LINK element linking to the stylesheets, since it makes some of the stylesheets alternate stylesheets.) Similar traps can happen in other ways and allow you to write perfectly valid markup that means something other than what you think it does and what you intended it to do.
CSS validation has similar problems. (It also has the problem that the validators themselves have rather significant bugs, since there aren't any mature implementations of CSS parsers using which one can build validators like the SGML parsers on which HTML validators are based.) For example, MSIE for Windows treats the height property on block-level elements incorrectly: it treats it as min-height and allows the height of the block to be larger if the contents overflow. This is incorrect, so there are pages that are displayed nicely on MSIE for Windows but have lots of overlapping text on any CSS-compliant browser. Likewise, you could be writing pages that work fine at your default font size or window width but display very badly at others.
In other words, validation tools for HTML and CSS are nowhere near smart enough to be a substitute for really knowing what you're doing. (Does anyone rely on lint to verify that their C programs are bug-free?)
CSS2 defines a replaced element as an element whose content is ignored, but instead replaced by something else with intrinsic dimensions. In other words, things like IMG and OBJECT are replaced elements. Most HTML elements, such as P, BLOCKQUOTE, STRONG, and BODY are non-replaced elements. It defines an inline element to be an element that is formatted within a line. This is the default presentation of elements like A, EM, STRONG, DFN, etc., whereas elements like P, UL, LI, DIV, BODY, and BLOCKQUOTE are block-level elements by default. (This can be changed with the CSS display property.)
Thus elements such as A, SPAN, EM, etc., are non-replaced inline elements by default (unless a stylesheet changes the display property). The IMG element is a replaced inline element by default. (Specifying display: block makes it a replaced block-level element, which can be useful, although it doesn't work well on some older browsers.)
I agree that the CSS spec certainly does not require that any form widgets be stylable. The CSS2 model is not sufficient to describe the rendering of even the simplest form widgets (mainly due to the weakness of its anonymous content generation and lack of some concepts in the box model). Therefore the CSS spec doesn't define how form widgets should respond to CSS styles. I think (although some others disagree) that this implies that a user-agent that applies any CSS styles to form controls is extending CSS.
Proposals such as XBL would add to CSS a model that is sufficient to describe the behavior of form controls. With that or a similar proposal one could have styling of form controls within the CSS spec.
Even then, I doubt the CSS spec would ever require that user-agents avoid native form controls in favor of stylable ones. (It is possible that user agents with native form controls would not be able to implement all modules of CSS since they would not be able to implement the module describing the styling of form controls.) After all, native form controls give the user a more consistent and usually better user interface.
-David