QuirksBlog - Coding techniques
| Contest | Memory leaks | XMLHTTP |
I feel it’s time to revisit the web vs. native debate, and concede defeat — or, at least, concede that the web cannot, and should not, compete with native when it comes to complex, app-like structures.
I feel we’ve gone too far in emulating native apps. Conceding defeat will force us to rethink the web’s purpose and unique strengths — and that’s long overdue.
I feel that our desire to take on native heads-on has given rise to unnecessarily complex toolchains that slow down what could be simple websites. I’m especially thinking of struggling news sites here, and will argue below that they should go native all the way and forget about the web.
Seems Facebook (which I don’t use) has put out a new product that allows iPhone users (and only them) to read news articles without leaving Facebook. John Gruber wrote an as-always thought-provoking article about why this could be bad for the web as a whole.
Although I don’t agree that the web is in danger (we hear this story every week, it seems), John makes an important and valid point:
Daring Fireball pages load fast, but the pages I link to often don’t. I worry that the inherent slowness of the web and ill-considered trend toward over-produced web design is going to start hurting traffic to DF.
Today I rant about undocumented Chrome features and unreadable W3C specs. There’s too much of both nowadays, and I’m getting VERY tired of both. Google and W3C should clean up their act.
During my research of modern input types such as
number I stumbled upon the
type === 'text' detection, mostly in order to cater to Android WebKit, although it also solves a few other problems.
The difference between back-enders and front-enders is that the first work in only one environment, while the second have to work with myriad of environments that may hold unpleasant surprises.
Even worse, where back-enders hold that they’re better in creating complex applications than front-enders — and they may even be right — some show an unwillingness to learn about the front end.
The combination of an insistence on being right about application structuring with a casual dismissal of front-end techniques aimed at catering to myriads of challenging environments makes the archetypical back-ender come across as arrogant. If you want to teach, be prepared to learn.
Well, that was quite a ride. 50K hits on my Angular article (which is a LOT for me), and still people trickling in.
Predictably, trolls came out in the comment threads on Hacker News and Reddit, but also some thoughtful reactions, and even a few who defended my article. It almost seems as if the comment quality is going slightly up. That’s unexpected, and nice. (For the record, I’m not a fan of comments.)
There’s way too much feedback to treat it all — I encourage you to read the comments for yourself — but there’s one particular argument I’d like to point out. It’s about my belief that templating belongs on the server, and it was made in both comment threads:
In the last six months or so I talked to several prospective clients that had a problem finding front-end consultants in order to help their dev teams get a grip on their Angular projects.
Although there are front-enders that are enthusiastic about Angular, I have the feeling that their number is surprisingly low for a major framework. I expected Angular to gain more traction than it has.
Angular is aimed at corporate IT departments rather than front-enders, many of whom are turned off by its peculiar coding style, its emulation of an HTML templating system that belongs on the server instead of in the browser, and its serious and fundamental performance issues.
I’d say Angular is mostly being used by people from a Java background because its coding style is aimed at them. Unfortunately they aren’t trained to recognise Angular’s performance problems.
I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.
The proposed radical Angular 2.0 rewrite aims to make it more palatable to front-enders, but I doubt they’re interested in yet another MVC framework. In addition, the rewrite will likely alienate Angular’s current target audience.
Yesterday I found that proper hyphenation of text is now supported by Firefox, IE10, and Safari. So I added it to my main style sheet and it should work in these browsers across my site. I also advise you to add it to your sites straight away.
During my media query test I found out that
min-resolution: 0[unit] does not work in any browser for any unit. I find this weird.
For my DIBI presentation
I need a dropdown menu (in order to compare it on desktop and mobile), so I wrote one.
and three of which deal with the fact that bloody Firefox still doesn’t support
Net amount of lines: 18. Can somebody please remind me why we all used to think dropdowns
are so extremely complicated? I can’t for the life of me figure it out.
Yesterday I walked into the local phone store because the “Temporarily Unavailable” sign had been removed from their “Get your iPhone here” poster. To my utter surprise they had six (6!) entire iPhones for sale, and no, there was no waiting list. I walked back home with a shiny new gadget, impatient to start testing it.
Meanwhile I’ve done some tests; now it’s time for a report.
Before we continue, let’s get the bad CSS news out of the way: Safari on the iPhone does not support
position: fixed. Certain Other Browsers were ridiculed for this lack; Safari won’t be.
Event delegation is especially useful in effects like dropdown menus, where lots of events on links may take place that can easily be handled at the root level (an
<ul> in this case).
There used to be one problem, though: although event delegation works fine for the mouse events, it does not work for the focus and blur events we need to make dropdown menus keyboard-accessible.
In the course of my ongoing event research, however, I found a way to delegate the focus and blur events, too. Maybe one of those
will use this technique to shave off a few milliseconds of computing time
For all I know they're already aware of this technique; but it was new to me so I publish it anyway.
The previous version of the Find Position script didn't work quite correctly,
since it often ignored the last step in position calculations: the one from the
<html> element. Part of the reason was that its code was too complicated.
The problems with this script used to generate a lot of comments. Eight months ago I changed the
script somewhat, and comments dropped off to zero, meaning I'd done it right. Meanwhile I've taken another
look at it and changed it a bit more.
In any case, the changed script now uses a new approach (that is, it was new to me eight months ago).
It now uses the assignment operator
= instead of the equality operator
that you'd expect:
while (obj = obj.offsetParent)
I always planned to write a blog entry about this approach, because I feel this little trick should
become general knowledge. So here it is (eight months too late, but anyway):
While attending Brian Fling's presentation on desiging for a mobile phone, I suddenly had an idea that might solve one of the problems he mentioned. I thought I'd document it immediately, before tonight's beer will cloud my mind and make me forget all about it.
I added a new page about importing the site navigation on all QuirksMode.org pages. The page is mostly about why I do what I do, and less about the how (besides, technically it's quite easy). The site navigation is a perfect example of what Jeremy calls Hijax.
I also put my trusty XMLHttpRequest functions online for future reference. No explanations on this page; I already treated them in section 10A of the book.
Just now I delivered a project during the making of which I noted a feature of event bubbling that, though totally logical, came as a surprise to me. No doubt someone else will be surprised, too, and may even be able to use it in a project.
I'm already regretting the publication of my Browser Detect 2.0. From one of the comments I learned that there's a new script making the rounds of blogs, a script that neatly highlights the dangers of using browser detects, but that's been received with glad cries by otherwise sensible sites.
Combine the release of this script with my release, and it might seem to the unaware web developer that browser detects are back in fashion. It's necessary to repeat why browser detects are dangerous, unprofessional and usually badly written, even though those facts have been general knowledge since at least 1998.
Well, I'm back from @media, and it was as wonderful as last year. I met lots of interesting people, talked about lots of geeky stuff, drank the amount of beer required by British law, and went on stage at a web conference for the first time—but I hope not for the last.
Well, my previous entry Is asynchronous communication really being used? has certainly elicited some interesting comments. The answer was a resounding "Yes"; and the replies allow me to take a first stab at defining a few Ajax use patterns.
Yesterday I attended the 10th Sigchi.nl conference in Amsterdam, during which I had the pleasure of seeing
Jesse James Garrett,
Martijn van Welie,
and Steven Pemberton in real live action. (Note to self: Jared and Steven are stiff competitors of Joe when it comes to being The Funniest Man at Web Conferences).
I'm not going to describe the conference in detail. Instead, I'd like to discuss an asynchronous communication question that popped into my head during Jesse James' presentation.
In a project I'm currently working on I encountered an Explorer bug that depends on the window you open a page with.
I post it here because I know that MSIE team members occasionally read my blog, and I have the faint hope that can they solve this bug, especially since it's messing up one of my projects (and, after all, what in the world is more important than my projects going smoothly <grin>, particularly when I have another important and exciting project that should be finished quickly but is held up by this bug).
One of my minor irritations with Mozilla is that it doesn't support a few DOM methods and properties that, though not officially a part of the spec, are nonetheless extremely useful and supported by all other browsers. I'm especially thinking of the
contains() method and the
children nodeList. While going through the more abstruse parts of the Level 3 Core spec today I found a way to add
contains() to Mozilla.
Sounds fascinating? You bet. There's just one slight problem: the actual data is totally inaccessible.
My last entry The AJAX response generated a few interesting comments, as well as a thoroughly non-scientific and non-representative poll on the use of the various output formats.
In the rest of this article I'd like to reply to some points that were made: the name "AJAX", rendering speed, error handling, the "evilness" of
innerHTML and some other remarks.
(This article has been translated into Spanish.)
In the past two weeks I've again created an Ajax-driven interface, and as usual I discovered quite a few interesting XMLHTTP bugs and problems. This entry contains three Explorer and one Safari bug, and it talks about cloning nodes from HTML to XML, from XML to XML, appending HTML that contains a form, and extremely agressive caching.
In my ongoing quest for memory leaks I've come upon a mystery. A script that should leak memory according to the definitions and the experts, doesn't. Why not? I have no idea.
Since the comments to my previous posts contain a few useful links to memory leaks and closure resources, I thought I'd create a linkdump for future reference. Note that I only included those articles that explain what they're doing and why and give code examples. I ignored the pages that just throw scripts over the fence and leave it to the reader to figure out what they're all about.
I made an obvious error in my previous round of experiments. We're going to start afresh.
The plot thickens. I now have succesfully created a simple function that causes memory leaks. The problem is, I don't understand why.
Update: Incorrect experiments. This entry is closed.
It becomes more and more apparent that creating the new
addEvent() function is not for the fainthearted. I underestimated the many problems, and in the comments to my previous entry compelling arguments were raised against the winning code.
I've decided to take a few steps back and study the problem before messing about with the solution. I want to write a script that leaks memory. I'd like to judge how bad it is in practice and I'd like to see some practical code examples. Unfortunately I just can't get any function to leak memory. I'm afraid I just don't get it.
Well, that wasn't what anyone would call fast. Scott, Dean and I all had trouble making time to judge the contest. Besides, the quality of most of the entries was less and their length far greater than we'd expected. We had to wade through dozens of lines of script that didn't really make much sense to us, and that weren't really necessary to perform the job at hand.
Despite this disappointment we have determined a winner.
I know, I know. I'm terribly late, not to say distinctly overdue, in judging the addEvent() recoding contest. The main reasons are that my clients now actively gang up on me to prevent me working on anything but their projects, and that the bit of spare time I've managed to squeeze from them is almost entirely taken by a very exciting new project that I hope to unveil within the next few weeks.
That said, today I finally found the time for the first round. I took a quick look at all the entries and judged them on formal grounds.
On Thursday my Windows XP computer died. This was not entirely unforeseen, since it had taken to crashing at random instances, and also when I wanted to restart it after a night of inactivity. But now it didn't want to start up at all, and reinstalling Windows XP brought on yet another crash. Time for a new computer.
This thrilling episode of "My glorious life as a web developer" has played havoc on my schedule, which was rather tight to begin with. The main victim turns out to be the addEvent() recoding contest.
As we all know an xmlhttp script requires the use of the
readystatechange event. In theory, using the
load event is also possible, but Explorer doesn't support it on xmlhttp requests.
Both these events, and the
readyState property, have a few odd quirks when used in an xmlhttp environment, though. These quirks don't impact standard xmlhttp scripts too much, but as soon as you want to use the event objects or
readyStates other than 4 you need to know about them.
Remember that the addEvent() recoding contest closes in three days. Thursday is your last chance to submit your script, since I'm going to close comments on my Friday morning and start working on the judging.
In my continuing quest to understand XMLHTTP I gathered some very intriguing material that I'm quite sure will save somebody else's ass. Today I offer a closer look at the
abort() method, as well as an as yet unexplained bug in Mozilla which causes the
responseXML to go missing.
My recent entry addEvent() considered harmful generated many interesting comments and technical pointers. It's clear that the original
addEvent() function doesn't quite cut the cake any more, and it's equally clear that we badly need a function such as this to keep our scripts simple.
Hence I'd like to take the opportunity to launch an
addEvent() recoding contest. Write your own version of
In a recent article on the IE Blog, Justin Rodgers talks about further CSS improvements in the ever more impatiently awaited IE 7 beta 2. His message is that CSS hacks will start to break in IE 7, and I fully agree.
Nearly two years ago I warned against the excessive use of CSS hacks, because I envisioned a situation like this. Web developers who rely on CSS hacks are going to have serious problems.
Currently I'm working on debugging a very complicated script that's supposed to xmlhttprequest a few pages to be shown in a "Dashboard". I already wrote about another aspect of the project in my previous entry, but now that I'm concentrating on the XMLHTTP aspects of this project I found out a few very interesting things about
responseXML, as well as a complicated Explorer bug.
This entry treats these two points, since they should be documented.
Back in 2001 Scott Andrew LePera published the cross browser event handler script
addEvent(), which was subsequently copied, revised, and used in many, many websites. I never used it, because I felt — and feel — it is wrong to assume that the W3C
addEventListener and the Microsoft
attachEvent methods are the same. They aren't, and the slight but important difference can trip up the unwary web developer.
Today I found excellent evidence that
addEvent() can be harmful if it's used without intimate knowledge of the differences between the W3C and Microsoft event registration models.
When I first read Jesse James Garrett's article Ajax: A New Approach to Web Applications my reactions were "What a silly name", and "Not really new, is it?" Although both points of critique have been repeatedly and heatedly mentioned in the ensuing discussion, the concept seems to be taking the Web development community by storm. This can mean one of two things: either it's a promise or it's a hype. To decide the case, I offer an annotated link dump.
Since XMLHTTP is becoming more and more important I thought I'd create a linkdump, both for my own future reference and for other developers. Additions and comments will be gratefully accepted.