Zamanewby's Blog

My colleague encountered such a problem this morning.

He had to display a set of images which were retrieved from a co-partner's search engine's results. But the engine didn't supply the images sizes together with the results. So he had to decide what sizes should he use for displaying these images.

Before these images onloaded in the user's browser, their sizes were unknown and might vary a lot, which it was not what we expected. 'Cause the layout of the page might be in a mess for these undecided images sizes. So my colleague decide to resize these images sizes by registering an onload event handler for each image. But it has defects. The page will flash once when these images have loaded and the onload event handlers have triggered.

So I think there's might be two solutions.

One, show a default image which the size is fixed at first and hide the onloading images, when imags loaded, replace these defaults images with the onloaded images(for these images now have sizes, and we can calculate new proper sizes for displaying on retaining the original scale of the width and height).

Two, set the images size to fixed values before they loaded. When these images have loaded completely, the images size won't change. But the scale of the width and height might be not correct. So calculate the sizes with both fixed width/height and the original width/height of the image for a new proper one to display.

They decide to take the second solution for some reason. But my colleage find it was hard to retrieve the original sizes of those images after we specified a fixed width/height. So how we deal with that? Actually, after some "exploring", I found the answer it's simple. Remove the fixed sizes (or say the width/height attributes) we've set, and then retrieve them one more time. And we got the actual size of these images.

For instance, we may use something like the codes below:

img.removeAttribute('width');
img.removeAttribute('height');

or

img.style.width = '';
img.style.height = '';

Then we can get the original sizes of image instead the ones we set it before.

Which one to use depends on what method you've chosen for setting the images sizes.

Forgive my poor English representing . I don't know clearly what I'm saying either. -___-#

Margins and padding on inline elements work a little differently from block elements - if you add a margin on all sides of an inline element, you'll only see space added to the left and right. You can add padding to the top and bottom of an inline element, but the padding doesn't affect the spacing of the other inline elements around it, so the padding will overlap the other inline elements.

from Head First HTML with CSS & XTHML page 466 chapter 11

被产品经理告知运营数据统计有问题。 原因是运营统计的js代码里面， 在ie下取不到由window.open函数打开页面的document.referrer。 试验了一下， firefox、 opera、 safari（均为最新稳定版本）都可以取到， ie sucks...

我的第一反应是应该用window.opener去取父窗口页面信息。 所以统计代码改为在取document.referrer为空时，尝试判断window.opener是否存在， 然后取window.opener.location.href。以为没有问题了， 于是发布了个测试版统计代码到自己的项目上。

然后发现问题。 在各浏览器下都经常会发生跨域访问问题。 在ie下会显示没有权限， firebug也会相应的报错。trace了一下， 发现两个页面的document.domain的确不同， 但还不是必现-__-#， 貌似是部门某个公用的服务在一定条件下会设置业务的子域。 所以有时候一个页面是xx.com， 另一个页面是aa.xx.com（举例）。但统计代码是在页面最下面的， 所以还不能在执行时再把domain改回到上一级域。 从修改时间成本等角度考虑， 于是产品经理说把页面里面通过注册onclik事件来window.open新页面的地方替换为<a>元素。 但这样会影响整个页面的展现， 而且有些地方也不可行。 于是想办法改一下onclick事件。

最开始想到的是在页面append一个<a>元素， 然后调用其click方法。 但是在手册和MDC中发现至少gecko内核的浏览器不支持<a>元素的click方法。 准确的说应该是除了<input>元素中某些类型， 如button、 radio等之外， 其他元素都不支持调用element.click方法。 所以想到用<form>和<input>来代替<a>， 用<form>中的action属性指定要打开页面的url， 用target属性指定是否打开新窗口， 然后通过method属性为GET方式提交表单。 当然<input>也就多余了， 直接调用<form>的submit方法就可以了， 这样就肯定可以取到document.referrer了。 但是又发现问题了。 用GET method提交之后， action属性中指定的url的cgi参数丢了。打开的新页面的url只到问号处， 后面的参数没有了。 而用POST方式， action属性中指定的url是完整的传递到新页面的， 但是POST肯定行不通的，一刷新页面就麻烦了。 觉得GET方式提交表单， 目标窗口的url参数应该是从<input>元素中提取的， 所以直接写入到action是不起作用的。

最后想了个简单的方法， 就是直接判断元素是否支持click方法， 如果支持， 就通过添加或修改元素的href属性， 然后调用click方法打开新页面；如果不支持，则直接调用window.open方法打开新页面。 因为ie通过window.open打开新页面取不到页面的domument.referrer， 但是恰好支持元素的click方法。 其他不支持元素click方法的浏览器用window.open也可以取到referrer。当然opera即支持元素的click方法， 又可以通过window.open方法取到打开页面的referrer。

当然如果打开新页面需要指定窗口大小等属性， 该方法就不适用了。 不知道还有什么好方法不。或者只能通过解决document.domain问题的方法了。

上个月一直挺忙的， 很多事情也没时间记录一下， 只好现在回忆一下了。

11号我们组去腐佳节又重阳败， 在北大西门那边吃的烤翅。 酒是不能少的， 不过由于之前的游戏大家都已经非常熟了， 被罚酒的次数明显下降， 都担心酒喝不完。 于是我想到大四时酒桌上不许说“你我他”的玩法，只要提到这三个字中的任何一个就得罚酒一杯， 一经提议即被采纳。 效果很不错， 一箱酒瞬间就不够了。 const每次都是听到别人说到某个字，然后用手比划半天， 最后来了句“我听到你刚才说...”， 然后自罚两杯。 XO的酒还没喝就又连续被罚3杯。 colin每次被罚之后还得补一句“我X”。 总之大家玩得很开心。直到我们组老大和我们说他要离职了。 瞬间鸦雀无声了。 估计是大家都觉得比较突然吧。 老大人非常好，技术也很强。 我觉得这对公司尤其是我们组， 是非常大的损失。 我们都非常舍不得老大离开。 还是祝福老大的创业之路一帆风顺：）之后去清华打保龄， 我是第一次玩保龄， 感觉挺有意思的。

24号是部门组织的篮球友谊赛。 技术对产品。 比赛开始了， 才发现自己的体力真是远不如前了。 对方的后卫vivien简直体力太好了， 满场飞奔， 防守也是非常积极。 对方的高大中锋， 我赛前夸下海口， 说防他简直太轻松了。 结果那天他突然发飙了， 弄得我很没面子-__-# 后来我突破上篮， 他过来封盖， 我把球打进之后， 他落地时踩到我， 然后脚崴了，还去了医院... 之后比分一度相当接近， 但我们没抓住机会，最后由于对方组织得很好， 而我们球很难传到前场， 被打垮了。 赛后作为对方主力的部门老大带我们一起去吃烤翅 （发现这东东的确很好吃啊）。我到家基本上快夜里一点了。

这个月工作一直很忙。 发现总和UI协调不好。 他们总是在做视觉体验， 而做出来的页面， 简直没有啥可用性。 让他们返工， 即使是比较小的部分， 也会由于他们比较忙而往后延很多天。 结果大大压缩了我的开发时间。 弄得我这个月很多不必要的辛苦。 以前周末从来没加过班， 结果这个月就两次。 我真的是怕产品不能按时提测、 上线。 而总感觉他们就没点儿责任感。 我要不是把产品当作自己的产品， 我也不会经常加班到晚上八东篱把酒黄昏后九点， 甚至周末也出来。 为什么不能把UI也按产品和其他人分到一组呢。

这个阶段的工作很前端， js和相关的代码写了一两千行了， php写的很少， 可能不比写的shell脚本多多少-__-# 下一阶段整个数据库要重新调整、 划分，php代码要大面积的重构。 正好是个补数据库知识和熟练php的机会。 数据库的设计我主要是参与讨论。 最后基本上还是peterwang定的。 发现有个人带着还是很好的， 虽然项目90%的工作还是我一个人做， 但在很多方面， 老员工的经验的确能让自己少走很多弯路。 当然也是因为peter、 colin等人都很好， 大家在一起都很爱讨论问题，技术氛围非常好。 peter很学术， 丝毫没有项目经理的架子。 peter和colin对于vim的使用也很在行，最近经常向他俩请教， 发现vim越来越顺手了。 有这样一个氛围也的确是一个很好学习的机会。

才想起来23号的时候， 晓雷和柴营来北京玩。 先去了中央电视塔下面的海洋馆，感觉和上次在烟台看的那个差得很远， 自己不是很想去， 主要是陪他俩玩了。 然后去看了看鸟莫道不消魂巢、 水有暗香盈袖立方。 虽然还没开放， 但还是挑了几个不错的位置照了几张像。 满达同学也赶来了， 大家在一起还是很亲切的：）

来公司已经8个月了， 有时觉得自己进步挺快， 但更多的时候觉得自己差得很远。 精力大部分是在前端。而发现公司（起码是所在部门）这方面真是没有强人， 更别提牛人了。  如果全靠自己去学， 而和工作脱离， 感觉对于学习和工作都是比较低效的。 这也一直使我的发展方向产生些许不确定性。 只好先把自己知识上漏洞比较大的地方补好， 再找一两个方面深入下去了。