Mozilla: The Browser with Everything and the Kitchen SinkWednesday February 19th, 2003For years, many of Mozilla's detractors have complained that Mozilla is too bloated with useless features. "Mozilla has everything but the kitchen sink," they retort. Well they're wrong because the kitchen sink will soon be coming to a Mozilla browser near you! Makali writes: "A patch for Bug 122411 got a super-review today meaning that Mozilla (and presumably the next release of Netscape) will now have a kitchen sink. While in good humour and a rather cute touch, this does make me wonder how much time developers spend adding features of dubious value to our favourite browser when it still doesn't correctly support HTML 4.01." Makali offers up bug 915 as an example of a long-standing standards-compliance bug. Please remember that this bug, like all bugs, doesn't need to be spammed with useless comments. As someone who used to programmer all the time I can tell you that silly things like these really brighten up your day. As long as the mozilla developers don't go crazy with implementing easter eggs then I saw more power to them. aside from the point Tekhir made, it's also worth pointing out that nearly all the work on this feature was done by a couple of people that don't do a lot of development on mozilla, and are purely volunteers. so it's not taking away significant developer time of someone that would, for example, have been working on bug 915. another point about the kitchen sink is that the actual code for the page will be at the location that this article links to, so it won't "bloat" the browser by more than the space necessary to add an extra about: URL and redirect it to the web site. It maybe fun for developers to play but it does not add to good code. I thought that it was really lame when I heard that there was a flight simulator in excel. Easter eggs is one of those things Microsoft does that indicates that thier software was only designed to be used in a non-corporate enviroment. So this is minor but if this actually gets aproved, it will indicate that the core developers do not have a philosophy of "lean and clean". "So this is minor but if this actually gets aproved, it will indicate that the core developers do not have a philosophy of "lean and clean"." Err, no, it will indicate that the people to contribute to Mozilla are human, not rouge instances of MozBot gone wild. This easter egg is nothing like Excel's built-in game. The code bloat is negligible (< 10 lines), as is the performance impact, as is the loss of development time. If you don't like it, download the source, remove the sink, and be done with it, but don't try spoil the fun of developers and users everywhere else. I guess you don't like the splash-screen either? /mike Actually, the splash screen takes up a lot more code to put up than about:kitchensink needs to make it work... I agree that if this change required anything but the most trivial code it would not be going in. But all it does is to add one entry to a lookup table (4 lines of code) and add one entry to a list (1 line). "So this is minor but if this actually gets aproved, it will indicate that the core developers do not have a philosophy of "lean and clean"." Err, no, it will indicate that the people to contribute to Mozilla are human, not rouge instances of MozBot gone wild. This easter egg is nothing like Excel's built-in game. The code bloat is negligible (< 10 lines), as is the performance impact, as is the loss of development time. If you don't like it, download the source, remove the sink, and be done with it, but don't try spoil the fun of developers and users everywhere else. I guess you don't like the splash-screen either? /mike 'It maybe fun for developers to play but it does not add to good code.' So you're a developer then? I am. And I'll tell you yes it does. Happy developers are better developers - this is a principle that's been true throughout all forms of industry since the Industrial Revolution. As for Microsoft software, if you think Office was 'only designed to be used in a non-corporate environment', you're on crack. Office is probably used in more corporate environments than any other application suite. This probably makes it the most successful piece of corporate software ever written. And oh look - it achieved this result despite including a (crappy but mildly amusing) 'flight simulator'. Get a grip. --sam Does this include a pref to turn it on and off? ;) I do hope that this is a joke. About the only thing worse than having an easter egg (in terms of bloat) is having one with a preference. I think it's cool, power to them (for those bloat fanatics, check the code eyeballing it, I'd say that it's way under 5k). If you click the top of the faucet handle, the water shuts off. I wonder why they didn't do this in color. Maybe I'll file a bug on that.... How great, haha =) Easter eggs are fun to play with and fun to put in yourself, they really outdid themselves on that one though (It would take me days to do it, them maybe 10 minutes?) Sorry, is there any one can explain what is "kitchen sink" for ? English is not my native language, I just see some codes running in this URL http://www.mozilla.org/catalog/web-developer/examples/kitchensink.xml Does kitchen sink apply in web design ??? Thanks a lot. You should see a text-rendered kitchen sink, complete with a tap and a running-water effect. "It's got everything but the kitchen sink" is an old expression - used, for example - if you've just bought a car with every conceivable accessory. Since Mozilla has a lot of features, one might have also said "Mozilla has everything but the kitchen sink", except now it really does have a kitchen sink. This is also why the Windows icon for emacs is a kitchen sink. > This is also why the Windows icon for emacs is a kitchen sink Is it?? I've never actually been able to figure out what the heck that it actually is. It sort of looks like a stylised "T" with a yellow bit on top (that's Emacs 20.7) :o). Raj. There is an expression to include "everything but the kitchen sink", which means someone/something has thought of every possible thing they could need and taken/added it, normally far more than they need. This is a complaint that people sometimes have about mozilla, so someone thought it would be funny to actually include the kitchen sink. The other responses have explained the XML file. In case you are unsure of what a real "kitchen sink" is, in English, a "kitchen" is a room for preparing food, and a "sink" is a basin with (usually) running water. There is a picture of a typical one at http://www.southyorks.police.uk/band/images/kitchen%20sink.jpg . If you already understood this, please don't be insulted by my response. You know, that kitchen picture you have there seem identical to the text rendered one. Check out the lighting in both pics (the text one has blanks to represent light.). The shape and all is identical as well. WJTW That's the pic I used to make the text sink. I claned up the water spots in the basin, removed the counter, and converted it to ASCII. If you read the bug, Asa has asked that this not be checked in, since other projects (notably Phoenix) might not appreciate the kitchen sink. Personally I think it's a nice demo, but I can see that some people might object. ...of the lack of committment that is growing in this project. C'mon. The fact that they seriously took the time to VOTE this code in/out takes time away from REAL bugfixes. HTML4.01 standards compliant bugs that have lain dormant for years should be priority #1 in my opinion. How the heck does this effort expect to survive if these things are allowed to bubble up through the system? This is inexcusable in my opinion. I AM a software engineer, have been for years, and have been doing web development since mosaic 0.9! So don't tell me this is a responsible reaction when soooooo many other things are more important. > HTML4.01 standards compliant bugs that have lain dormant for years should be priority #1 in my opinion. They're a priority for people working on the layout engine. Not one person who has worked on the kitchen sink works on layout. In fact, precious few people do (5 actively, at last count, 2 more sort of). A better question would be why so few people are working on layout. The answer is that layout is "hard" (you actually have to think or something) while writing things like kitchen sinks and the UI is "easy" (you still have to think to do it well, but the app doesn't usually crash and burn if you fail to think). What burns me more is that this thing went through the approval process. It took time from THAT process, which is the same process used for REAL bugfixes. That is what is disconcerting here. I could care less about the thing being developed, since it does not directly detract from the layout development. However, it does affect the overall project since it has stolen Program/Project Manager time away from evaluating more important things. That is the sad part of this story. That program management has allowed this to happen, seems to reveal that they have nothing better to do than to discuss the approval of including silly additions like this to the codebase. I've been in these type of meetings more times than I care to remember, and they are never 5 minute meetings. The review process for that patch took less than 5 minutes all told. > That program management has allowed this to happen There is no program management. Each module (necko in this case) is an autocracy (sometimes of 2-3 people, but darin is sole autocrat in necko). What he decides goes. What he does not decide, does not go. That's it. So you're laboring under a misconception of how decisions get made in the Mozilla project. Well we might newer know how much time this has taken away from something more important. Maybe drivers looked at this bug during coffee break? We are not machines, I can't work (normally) 8 hours straight I have to do something different in between coding sessions. This time away from more important thing is the same as adding private software piracy to some sw companys losses. Not that SW piracy is acceptable... you really need to relax. this probably took 10 minutes to approve this patch, who are you to tell these guys that are working like mad when they can take a little break? there is *zero* impact codewise, this is 4 lines of code, the is *zero* impact time wise, this was probably done in a break between real work. chill out, man. This "chill out" and "do it yourself" attitude is the reason I have to try to continually attempt to convince customers that Mozilla is worth the wait. In the corporate world, people are not using Mozilla because of it's lack of some key, base, HTML bugs. Their attitude is, if they can't get that right, what else is under the covers? This is a daily reality that I fight against. I have been championing the Mozilla effort out here in the field for going on 4 years now, and have numerous bugs reported that remain unfinished because of this attitude. <flame off> I apologize for the rant, but I simply cannot hold it in any longer. <flame off> is not closed. :P People have got to stop thinking that because HTML 4.1 was named XHTML 1.0 instead it isn't HTML. And HTML can now be considered to be a particular XML with a DTD and a default CSS style sheet, and the HTML DOM. This isn't to say that there aren't a few exceptions, and I agree that the supporting the current HTML recommendation (XHTML 1.1) is important. Hmm I just read bug #69032 where you got that comment about XML+CSS+DOM, and I have to say that in response to that statement I 100% agree with you, Mozilla is an HTML user-agent. I'm not sure about 1st priority, but it shouldn't be ignored! My initial comment was due to your final statement which seemed to group XHTML with XML instead of as the current version of HTML. > People have got to stop thinking that because HTML 4.1 was named XHTML 1.0 instead it isn't HTML Lesee.... it has different parsing rules than HTML. It has different error-handling rules than HTML. It has different case-sensitivity conventions than HTML. They respond differently to the same DOM calls. It's nearly impossible to produce an XHTML document and an HTML document that have the same source and lead to the same rendering. Sounds to me like they're not the same thing at all. The only thing in common is some tag names; everything else is different. do you *honestly* believe that your pet bugs arn't getting fixed because 10 mintues were taken to check in some changes made by someone *outside* the project? i have a really hard time buying that. further, as i'm not a mozilla developer, dont let my (or anyone else who hangs out on these boards) "chill out" and "do it yourself" attitude color your opinion of the real moz dev's ... they are too busy *coding* to hang out here ;) FYI: The "do it yourself" and "chill out" attitudes come from both here AND the developers comments within Bugzilla. And they are busy coding...I agree, and I support that effort wholeheartedly (if I didn't care, would I be so frustrated?). However, what they are coding is not as much an issue as what gets added to the codebase. The 10 minutes spent making this decision could have been used to decide on the fix for a real, documented, and fixed bug. There ARE bugs that sit, languishing in the fixed state too y'know. In my professional opinion, devoting 10 minutes to those bugs is more important. Perhaps I'm just more conservative with my time, and like to squeeze every productive minute I can get out of it (if I had more free minutes, maybe I wouldn't care). But if I'm working on a project as important as I believe the Mozilla effort is, then yes, I get upset when this tpye of thing comes to the surface. "The 10 minutes spent making this decision could have been used to decide on the fix for a real, documented, and fixed bug. There ARE bugs that sit, languishing in the fixed state too y'know. In my professional opinion, devoting 10 minutes to those bugs is more important." Point me to a networking bug with a patch ready to go that Darin (the Networking module owner) could spend the same ammount of time reviewing (probably about 3 minutes, maybe less) which would be of more have made Mozilla a better product. (and make sure that bug you point me to has an actual completed patch, ready for review and with a review request pending). --Asa "In the corporate world, people are not using Mozilla because of it's lack of some key, base, HTML bugs." Oh, so they're using IE instead, with maybe hundreds of more HTML bugs? Give me a break, bcortez. Yes, I agree MSIE has it's own set of bugs (believe me, I know). However, the fact that Microsoft essentailly has a lock on approx. 90% of the browser market overshadows its own bugs. This is the reason Mozilla code must be "better, stronger, faster" than MSIE. This market dominnce by MSIE is a major hurdle that I know Mozilla could overcome (I try to preach this to anyone who will listen on a daily basis). However, when I see this type of thing being added to the codebase, I have to respond to corporate customer questions about it. They view this type of thing as frivoluos and only gives Microsoft more clout to say something to the effect, "see, this Mozilla/Netscape browser is just a toy, a plaything for the geeks of the world. We build MSIE for you (corporate industry), we're serious, they are not." I say, why give them even a smidgen of FUD to bash Mozilla with? This is the way corporate management (who, lets face it, pay the IT bills) view browsers now. They want, and are continually demanding, new applications be browser-based. And they DONT want to support a browser they "think" is branded a toy. I have to correct these folks EVERY DAY on this misconception. Please, give me a break, I'm on Mozilla's side (and would hate to stop). I feel similarly. There are several uses (namely, elegantly managed printing) for which Mozilla /could/ rock, but it seems as though standards-compliancy is taking a back-seat to other issues. I saw a mention on Bugzilla about how Mozilla isn't an HTML or XHTML user-agent, but rather an XML +CSS +DOM user-agent (See bugs #7954, #69032). Frankly, I find this bizarre for people coding a browser. HTML compliance should be /first/ priority for an application whose purpose is /browsing/, with the XML/XHTML stuff coming in second. > seems as though standards-compliancy is taking a back-seat to other issues Compliancy with which standards? There are dozens of standards out there.... and we're doing better at some of them than others (typically the clearer and better designed the standard, the better we do; this is why HTML4 support is not done yet -- the standard is inane and self-contradictory in too many places). It's lack of internal coherence within the standards that's preventing Mozilla from becoming more standards-compliant? In that case, shouldn't the team be e-mailing to W3C to clarify these areas? That way, there'd be progress, and the old standards would be clarified. > It's lack of internal coherence within the standards that's preventing Mozilla from becoming more > standards-compliant? In some cases, yes (in addition to the other problems, like insufficient time, standards requiring a large performance or memory hit to implement, etc) > In that case, shouldn't the team be e-mailing to W3C to clarify these areas? There have been numerous request to the HTML WG for errata to HTML4 to clarify issues. They've been ignored (for years now). The CSS WG is in the process of working on CSS2.1, which should address a lot of the issues with CSS2. So this is happening, slowly, but writing a standard is a slow laborious process, especially when many competing interests are involved, as in the W3C. I did this as a lark. A few other non-coders took up the banner and actually added some nifty stuff to it, and a couple devs thought it funny enough to r= and sr= it. Unfortunately, the patches that got it weren't mozilla-conditional, so it's nto going anywhere for a while And for the whole 15 minutes various people spent on it, I guarantee you it brightened someone's day. If you think time not spent on coding is a waste, then why the hell are you posting here, rather than fixing bugs? Why the personal attack in the title of your message? Was there a need for this? I welcome constructive criticism, however, when your response begins with "GET A LIFE" (all caps), then anything you say after that is falling on deaf ears. Part of my job desciption as the technology liason requires me to follow-up and comment on the state of Mozilla/Netscape from a corporate perspective since I am the key design architech of our web-based development effort. Perhaps if you lent your Mozilla devt time more wisely to something that actually IMPROVED the codebase, we wouldn't be having this discussion in the first place? |