I've recently been involved in a bit of a flame war regarding Macs vs. PCs on twitter. Unfortunately, 140 characters isn't quite enough to explain my real feelings. I am definitely on the Windows side of the argument, but I'm not as staunchly opposed to the Mac platform as my tweets have made me sound.
So let me set the record straight. I don't hate Macs. On the contrary, they're quite beautiful. Also, the operating system is solid and straightforward to use.
The main reason I don't care to own a Mac is that I like to build my own machines. I spend weeks researching and plotting every single component in my machine. I wouldn't own a Dell or a Toshiba or an HP for that very same reason.
I think it all boils down to comfort. The C drive comforts me. Unless Microsoft really disenfranchises me somehow in the near future, I'm perfectly satisfied with the performance and UI of Windows. Especially now that Windows 7 is out in the wild. I've been running Windows 7 RC on my home PC and I love it. And I can't wait for IBM to upgrade my workstation to Win7 (although I'm not holding my breath).
The Eastern Townships School Board, the public school system in the region where I grew up, provides MacBooks to most of their student population (grades 3 thru 11). I had access to these MacBooks, and was involved in informally troubleshooting problems with them at Sunnyside Elementary School. I ran website design workshops with the students, and struggled with providing good instructions for the kids because of a lack of good WYSIWYG web design freeware. I ended up installing Nvu and Paint.NET on some old Windows desktops. Granted this can now be solved by VMWare Fusion or Parallels, but neither of these are freeware either.
So I've eaten the green grass on the other side of the fence, and it's not quite as green as advertised. I've never seen a pinwheel of death in Windows. There are pros and cons to both platforms, and I feel strongly that the none of the various pros of Mac OS are compelling enough to lure me away from my comfort zone.
Feel free to enjoy whatever OS you like best. If you need to be coddled by Apple to enjoy your computing experience, go for it! Essentially, I don't care to evangelize or be evangelized. I will make my own operating system and computer platform decisions.
Showing posts with label webdev. Show all posts
Showing posts with label webdev. Show all posts
Friday, August 14, 2009
Wednesday, August 12, 2009
Browser Upgrades
Dean Hachamovitch, I have a bone to pick with you.
You just wrote a (mostly hand waving) blog post on the IEBlog outlining how "the choice to upgrade belongs to the person responsible for the PC." This post was in response to a Digg.com survey regarding why people are still using IE6, a 9 year old browser that is essentially holding the entire web development community hostage.
I applaud you for approaching the topic openly and I understand that your POV is grounded in pragmatism, but I think you've missed the point.
Yes, I am an enthusiast, and enthusiasts love living on the bleeding edge. I remember dutifully installing IE 5.5 Beta 1 on my Windows 98 SE box back in 1999. In those days, I wasn't really a web developer (beyond my Geocities "personal homepage"). I don't remember noticing any differences between IE 5 and IE 5.5, aside from a few little UI tweaks and a fancy Print Preview feature. This is how non web developers perceive new web browser releases - It's just a chore; change for the sake of change. Why should I upgrade to the latest version when the version I'm on works just fine?
This is precisely why upgrading shouldn't be left up to the user or system administrator, because the status quo is perceived to be easier even if it's counter-productive to the global community. In order for the web to evolve, the lowest common denominator needs to evolve with it.
I can hear the retort now: "But we don't care about the global community. We care about the bottom line. And the bottom line means we want to keep using the same crusty Windows XP image that we created back in 2004 that we subsequently wrote tools for using non-standard IE6-specific code that we're stuck with because the tool developers have since moved on to other jobs and can't update them to work with new browsers."
Cry me a river.
I work on the IBM Rational Jazz Foundation. We upgrade our servers every 4-6 weeks to the latest code, forcing everyone to upgrade their clients on their systems. This chore has just become part of the job. I have no choice, I just have to do it. And I've become quite fond of this monthly dance. Small jumps are much less painful than big jumps.
IE6 people are going to start noticing that more and more pages are broken for them because developers can't justify supporting them any longer. If users were forced to update their browsers, the world would be a better place. It's as simple as that.
The solution to this problem doesn't need to be as draconian as I'm suggesting. Just prod the user more forcefully. Do a better job of providing incentives to upgrade. Release more incrementally. Back port new features into old browsers (instead of relying on the community to write hacky shims). Decouple IE8 from the core OS and allow two versions to coexist. Just do everything in your power to raise the bar.
You just wrote a (mostly hand waving) blog post on the IEBlog outlining how "the choice to upgrade belongs to the person responsible for the PC." This post was in response to a Digg.com survey regarding why people are still using IE6, a 9 year old browser that is essentially holding the entire web development community hostage.
I applaud you for approaching the topic openly and I understand that your POV is grounded in pragmatism, but I think you've missed the point.
Yes, I am an enthusiast, and enthusiasts love living on the bleeding edge. I remember dutifully installing IE 5.5 Beta 1 on my Windows 98 SE box back in 1999. In those days, I wasn't really a web developer (beyond my Geocities "personal homepage"). I don't remember noticing any differences between IE 5 and IE 5.5, aside from a few little UI tweaks and a fancy Print Preview feature. This is how non web developers perceive new web browser releases - It's just a chore; change for the sake of change. Why should I upgrade to the latest version when the version I'm on works just fine?
This is precisely why upgrading shouldn't be left up to the user or system administrator, because the status quo is perceived to be easier even if it's counter-productive to the global community. In order for the web to evolve, the lowest common denominator needs to evolve with it.
I can hear the retort now: "But we don't care about the global community. We care about the bottom line. And the bottom line means we want to keep using the same crusty Windows XP image that we created back in 2004 that we subsequently wrote tools for using non-standard IE6-specific code that we're stuck with because the tool developers have since moved on to other jobs and can't update them to work with new browsers."
Cry me a river.
I work on the IBM Rational Jazz Foundation. We upgrade our servers every 4-6 weeks to the latest code, forcing everyone to upgrade their clients on their systems. This chore has just become part of the job. I have no choice, I just have to do it. And I've become quite fond of this monthly dance. Small jumps are much less painful than big jumps.
IE6 people are going to start noticing that more and more pages are broken for them because developers can't justify supporting them any longer. If users were forced to update their browsers, the world would be a better place. It's as simple as that.
The solution to this problem doesn't need to be as draconian as I'm suggesting. Just prod the user more forcefully. Do a better job of providing incentives to upgrade. Release more incrementally. Back port new features into old browsers (instead of relying on the community to write hacky shims). Decouple IE8 from the core OS and allow two versions to coexist. Just do everything in your power to raise the bar.
Tuesday, January 27, 2009
Pragmatism
I've recently been working on implementing a two column layout for Jazz web UIs (reg req'd). I could easily update our current layout's images and styles and be done with it, but while I'm restructuring, I want to clean up some of our current layout's problem areas. Currently, we've got the following "features":
1) Two column layout with equal height columns (one fixed width, one fluid width)
2) Drop shadow and gutters on either side of the layout
3) Sticky footer; make the layout stretch the full height of the window with a footer at the bottom.
CSS hackers everywhere know that these three requirements are tricky to achieve together. The sticky footer was achieved by adding a page wrapper div with 100% height, followed by a footer div with a negative top margin equal to its height. The columns inside the page wrapper were then stretched down to the footer using the One True Layout hack (large negative bottom margin with large positive bottom padding).
Unfortunately, this hack required overflow: hidden on the wrapper, which killed off the possibility of enabling horizontal scrolling on the layout (i.e. what if a table has a zillion columns and is wider than the screen? Sorry, it gets chopped at the edge).
To make things worse, even if I used another mechanism for the equal height columns, DIVs don't expand to fit their contents, so the wide table would just overflow out of the layout, which is ugly.
Another problem area had to do with floats. To achieve the two column layout, I floated one of the columns left, and allowed the other to fill the remaining space (with overflow: hidden to give it its own block formatting context so that the columns drew beside each other instead of overlapping). Unfortunately, anytime the right-most column was forced wider than its auto width, it would wrap below the left column. There were various ways to mitigate this wrapping, but they all precluded horizontal scrolling.
As far as I know, there is no CSS only solution to achieve all of my requirements while mitigating the aforementioned problems (if there is, I'd love to hear it). So I set out to find a happy medium, which led me to tables.
I can hear the groans from the CSS elite (What's your CSS level?). Table layout!! NOOO!! But hear me out.
Tables are expand-to-fit! They're the only HTML element that does this. So I'm using this property to achieve my horizontal scrolling. The great news is that tables expand even if they are set to overflow: hidden, so my One True Layout hack will still work for the equal height columns. I lose my sticky footer, but I can easily achieve that with some simple onload javascript logic that sets the height of the table's one and only cell.
But that still leaves my column wrapping problem. Horizontal scrolling is moot if the column wraps before it scrolls. So how do I fix this? I could split my table into two columns, but my willingness to rely on tables only goes so far. What other ways are there to put divs side by side? For that, I turned to display: inline-block.
Display: inline-block causes the element to generate a block box (like display: block), but to flow relative to its siblings using an inline formatting context (i.e. side by side like display: inline). To make this work on IE, I had to use spans instead of divs, but that's easy enough. By adding white-space: nowrap to the parent of these divs, all wrapping is nixed, and the table cell expands as it should when content forces out the side.
Sounds too good to be true, and it is... Inline-block elements do not fill their available width as block elements do, so inner divs would only be as wide as their contents force them to be.
To fix this, I had to apply a fixed width to this column using JavaScript, and register a resize handler to update the width when the window changes. This is no problem in Jazz Web UI land since these pages require JavaScript to even work (async code loading and dojo-based UI widgets). Even with the fixed width, the table continues to encapsulate overflowing contents.
Take a look at the final result: http://twitpic.com/17wdi
So is it bad that I'm using a table? I don't think so. It's important to be pragmatic in web development. If an element has a property that you need, use it!
1) Two column layout with equal height columns (one fixed width, one fluid width)
2) Drop shadow and gutters on either side of the layout
3) Sticky footer; make the layout stretch the full height of the window with a footer at the bottom.
CSS hackers everywhere know that these three requirements are tricky to achieve together. The sticky footer was achieved by adding a page wrapper div with 100% height, followed by a footer div with a negative top margin equal to its height. The columns inside the page wrapper were then stretched down to the footer using the One True Layout hack (large negative bottom margin with large positive bottom padding).
Unfortunately, this hack required overflow: hidden on the wrapper, which killed off the possibility of enabling horizontal scrolling on the layout (i.e. what if a table has a zillion columns and is wider than the screen? Sorry, it gets chopped at the edge).
To make things worse, even if I used another mechanism for the equal height columns, DIVs don't expand to fit their contents, so the wide table would just overflow out of the layout, which is ugly.
Another problem area had to do with floats. To achieve the two column layout, I floated one of the columns left, and allowed the other to fill the remaining space (with overflow: hidden to give it its own block formatting context so that the columns drew beside each other instead of overlapping). Unfortunately, anytime the right-most column was forced wider than its auto width, it would wrap below the left column. There were various ways to mitigate this wrapping, but they all precluded horizontal scrolling.
As far as I know, there is no CSS only solution to achieve all of my requirements while mitigating the aforementioned problems (if there is, I'd love to hear it). So I set out to find a happy medium, which led me to tables.
I can hear the groans from the CSS elite (What's your CSS level?). Table layout!! NOOO!! But hear me out.
Tables are expand-to-fit! They're the only HTML element that does this. So I'm using this property to achieve my horizontal scrolling. The great news is that tables expand even if they are set to overflow: hidden, so my One True Layout hack will still work for the equal height columns. I lose my sticky footer, but I can easily achieve that with some simple onload javascript logic that sets the height of the table's one and only cell.
But that still leaves my column wrapping problem. Horizontal scrolling is moot if the column wraps before it scrolls. So how do I fix this? I could split my table into two columns, but my willingness to rely on tables only goes so far. What other ways are there to put divs side by side? For that, I turned to display: inline-block.
Display: inline-block causes the element to generate a block box (like display: block), but to flow relative to its siblings using an inline formatting context (i.e. side by side like display: inline). To make this work on IE, I had to use spans instead of divs, but that's easy enough. By adding white-space: nowrap to the parent of these divs, all wrapping is nixed, and the table cell expands as it should when content forces out the side.
Sounds too good to be true, and it is... Inline-block elements do not fill their available width as block elements do, so inner divs would only be as wide as their contents force them to be.
To fix this, I had to apply a fixed width to this column using JavaScript, and register a resize handler to update the width when the window changes. This is no problem in Jazz Web UI land since these pages require JavaScript to even work (async code loading and dojo-based UI widgets). Even with the fixed width, the table continues to encapsulate overflowing contents.
Take a look at the final result: http://twitpic.com/17wdi
So is it bad that I'm using a table? I don't think so. It's important to be pragmatic in web development. If an element has a property that you need, use it!
Thursday, December 4, 2008
User Interface Programming: Why does it takes 80% of the time to do 20% of the work?
I'm working on a decorated box widget, with a drop down menu, expand/collapse, header icon, and more. No matter how close I get to finishing it, another little feature or tweak pops up!!
In half a day, I was able to get from nothing to a polished widget that satisfied almost all of my requirements. Now I'm two more days into hacking CSS and squashing edge cases, and I'm still not quite finished!
This boggles my mind. Yesterday evening when I left work, I said to myself "What a great day of work! Just a few more little tweaks and I'll be able to deliver this code!" Hah, yeah right :)
Why does it take 80% of the time to do 20% of the work? Maybe I'm just horrible at estimating. Or maybe it's a law. So I googled and found this:
http://en.wikipedia.org/wiki/Pareto_principle
That's not quite right, although one could draw parallels. The 20% of my time that accomplished most of the work could be considered "the vital few". Sounds like nature is screwing with everyone.. even the economists.
In half a day, I was able to get from nothing to a polished widget that satisfied almost all of my requirements. Now I'm two more days into hacking CSS and squashing edge cases, and I'm still not quite finished!
This boggles my mind. Yesterday evening when I left work, I said to myself "What a great day of work! Just a few more little tweaks and I'll be able to deliver this code!" Hah, yeah right :)
Why does it take 80% of the time to do 20% of the work? Maybe I'm just horrible at estimating. Or maybe it's a law. So I googled and found this:
http://en.wikipedia.org/wiki/Pareto_principle
That's not quite right, although one could draw parallels. The 20% of my time that accomplished most of the work could be considered "the vital few". Sounds like nature is screwing with everyone.. even the economists.
Thursday, September 6, 2007
Web Technologies Learning Materials
As I browse the web and run across things I think are useful, I add them to my favorites. Here is a list of my favourite favorites.
First -> http://www.gotapi.com/
AJAX/JavaScript:
First -> http://www.gotapi.com/
AJAX/JavaScript:
JavaScript (re)introductionCSS:
https://developer.mozilla.org/en/a_re-introduction_to_javascript
Learning JavaScript Basics
http://www.allsyntax.com/tutorials/JavaScript/18/Learning-JavaScript-Basics/1.php
Ajax for Java Developers:
http://www-128.ibm.com/developerworks/library/j-ajax1/?ca=dgr-lnxw01Ajax
AJAX with the Java platform
http://java.sun.com/developer/technicalArticles/J2EE/AJAX/
Mastering AJAX
http://www-128.ibm.com/developerworks/web/library/wa-ajaxintro1.html
CSS Tutorial:
http://www.html.net/tutorials/css/
CSS Cheatsheet
http://home.tampabay.rr.com/bmerkey/cheatsheet.htm
CSS Tricks
http://www.webcredible.co.uk/user-friendly-resources/css/css-tricks.shtml
Avoiding CSS Pitfalls
http://webddj.sys-con.com/read/45288.htm
*note: this article suggest using a "* html" hack... IE7 now supports a lot
of the issues that the star html hack targets... so use conditional comments to
target IE6 and older (see next link)
Conditional Comments
http://www.quirksmode.org/css/condcom.html
IE HasLayout
http://haslayout.net/haslayout
*very important consideration to make CSS work properly in IE
Tuesday, August 21, 2007
Best Practice In-Page Jumps
Hyperlinks to locations on the same web page are handy for long, scrolling pages. A common way to achieve this is to place a named anchor at the jump locations, and link to them using the # symbol.
Solution:
The HTML 4.0 spec provides an alternative to using <a name="something"> for your jump references, by allowing links to reference ID attributes instead:
Link: http://www.w3.org/TR/html401/struct/links.html#h-12.2.3
EDIT: This method is only supported on "modern browsers". So anyone who cares about people still using Netscape Navigator 4.x or an ancient version of IE (IE 4 or older) should still use <a> jumps. That said, the name attribute has been deprecated in XHTML 1.0...
This surfaces a potential styling conflict when CSS is applied to <a> (anchor) tags. Let's say you apply a hover state to all anchor elements in your page... Your jump location will be styled with the hover state, even though it's just a reference and not an actual link.<a href="#jumpName">Link to subtitle</a>
... some content ...
<h2><a name="jumpName">Subtitle</a><h2>
Solution:
The HTML 4.0 spec provides an alternative to using <a name="something"> for your jump references, by allowing links to reference ID attributes instead:
Specify your link in the same manner as above, by linking to #jumpName, and Bob's your uncle... potential CSS styling conflict solved.<h2 id="jumpName">Subtitle<h2>
Link: http://www.w3.org/TR/html401/struct/links.html#h-12.2.3
EDIT: This method is only supported on "modern browsers". So anyone who cares about people still using Netscape Navigator 4.x or an ancient version of IE (IE 4 or older) should still use <a> jumps. That said, the name attribute has been deprecated in XHTML 1.0...
Thursday, August 16, 2007
IE hasLayout
The hasLayout property is a very important consideration when designing for IE. A surprising number of IE rendering bugs are triggered by an element not having layout.
For example, have you ever applied a CSS background-image to a <div> tag, only to find out that IE does not show the background image (floats usually have to be involved to trigger this bug)? Giving the <div> layout will fix this.
Another bug: Ever tried to apply "display: block" to an <a> tag, with the goal of creating a large clickable area? In IE 6, only the text is clickable unless hasLayout is triggered.
hasLayout is triggered by a few CSS styles:
- overflow: hidden (IE7+ only)
- position: absolute
- height
- width
- zoom: 1
Inspecting an element with the IE Developer Toolbar will show you if an element has layout or not.
The best reference for haslayout that I've come across:
Link: http://haslayout.net/haslayout
For example, have you ever applied a CSS background-image to a <div> tag, only to find out that IE does not show the background image (floats usually have to be involved to trigger this bug)? Giving the <div> layout will fix this.
Another bug: Ever tried to apply "display: block" to an <a> tag, with the goal of creating a large clickable area? In IE 6, only the text is clickable unless hasLayout is triggered.
hasLayout is triggered by a few CSS styles:
- overflow: hidden (IE7+ only)
- position: absolute
- height
- width
- zoom: 1
Inspecting an element with the IE Developer Toolbar will show you if an element has layout or not.
The best reference for haslayout that I've come across:
Link: http://haslayout.net/haslayout
Avoiding CSS Pitfalls
A great read for anyone who has ever pulled their hair out trying to make their CSS work on older versions of IE. This article provides workarounds for box model, three pixel gaps, peek-a-boo, doubled float margin, flash of unstyled content (FOUC), horizontal centering, and more.
Link: http://webddj.sys-con.com/read/45288.htm
Link: http://webddj.sys-con.com/read/45288.htm
Flash activation fix
Update: IE has fixed this issue, so this post is for historical purposes only. ;)
When Microsoft lost the Eolas patent case a few years back, they were forced to add a stupid concession to IE, requiring people to click to activate embedded objects. The plugin most notably affected was Flash.
This provides a little JavaScript workaround. It essentially scours the page for objects requiring activation, then replaces those objects. Objects created via script do not require activation.
Link: http://www.dgx.cz/trine/item/how-to-avoid-activation-of-active-x-in-ie
When Microsoft lost the Eolas patent case a few years back, they were forced to add a stupid concession to IE, requiring people to click to activate embedded objects. The plugin most notably affected was Flash.
This provides a little JavaScript workaround. It essentially scours the page for objects requiring activation, then replaces those objects. Objects created via script do not require activation.
Link: http://www.dgx.cz/trine/item/how-to-avoid-activation-of-active-x-in-ie
Subscribe to:
Posts (Atom)