Opera moves to WebKit and V8
Posted Feb 17, 2013 23:10 UTC (Sun) by marcH (subscriber, #57642)
I've always wondered what kind and how much portability work web developers typically perform. Is this really useful work like trying to work around horrible bugs in some browsers? Or do some web developers just waste their time trying to get the same, "pixel perfect" layout across all browser versions instead of reading and applying Nielsen Norman's free advice?
Posted Feb 18, 2013 4:43 UTC (Mon) by dlang (subscriber, #313)
This doesn't work for even a single browser because people do not all have their browser maximized to take their entire screen, and even if they do, you don't know how many 'helpful' toolbars they've got loaded that eat up screen space.
But they keep trying.
Posted Feb 18, 2013 9:02 UTC (Mon) by alankila (guest, #47141)
I use chrome to develop websites because of its built-in development tools, then once ready check it on the major browsers like Firefox $LATEST_VERSION and IE8 (if I know customer still uses XP) or just IE9. The fact Opera has no JS and HTML rendering implementation of its own means I can leave Opera out of my routine altogether, which is what I am pleased about.
I do not care one bit if things are not exactly laid out as I intended. This is not the sort of thing that matters. The site just has to be usable and controls laid out approximately where I intended them to be placed originally. If something isn't quite where I intended but the site is usable, I'll just state that it's a browser issue that likely fixes itself in some future update.
The layout issues that are too severe to be ignorable, I circumvent with IE8/IE9 targeted conditional comments and Firefox-specific CSS workarounds. Most of the time I only need some simple hacks for IE8, as all the other browsers (including Opera) tend to render everything pretty much the same way.
Posted Feb 18, 2013 9:19 UTC (Mon) by epa (subscriber, #39769)
After all, the purpose of testing is to find bugs, and anything that helps you find more of them is a good thing. But you seem to be approaching it from the other way: you see the testing process as a way to prove that something works (rather than finding ways in which it doesn't work), and thus by testing less exhaustively you can find fewer problems and go home earlier.
Posted Feb 18, 2013 10:13 UTC (Mon) by alankila (guest, #47141)
My ideal world would have exactly one browser engine, with everyone running the same version. That would allow skipping the entirely of the testing-after-development phase, and to use everything that engine provides -- a huge improvement to current status quo. And if it was nailed down in such a way that I could specify "I designed this to look and work right with version 12.34" (similar to what Microsoft is doing, incidentally, with their IE version compatibility tagging, and what Android is doing, with the manifest version specification), I would then simply trust that future versions of browsers retain compatibility to past versions, and solve this thorny problem for me.
The difference in our mindsets could hardly be greater. I think browsers grew up a huge deal when the acid tests arrived, because they provided a nice score that anybody could check and solved a lot of incompatibility problems back in the day when browser vendors rushed to compete against each other to beat their rivals' scores. So I would credit those tests, and the long-awaited death of IE6 and now IE7 for making our lives quite easy these days.
Posted Feb 18, 2013 12:15 UTC (Mon) by epa (subscriber, #39769)
An alternative nirvana would be to have a single reference browser and for all current and future browsers to promise compatibility with that. Then you could test with the reference engine only. But that is no more realistic than the single-browser scenario.
In the real world, of course you have to program to some pathological subset of the language which is supported on all browsers. You said as much yourself; you end up writing compatibility code for older IE versions. I would not advocate testing on additional browsers just to narrow that subset even further, but to flag up possible problems with the dialect you are using. You may inadvertently rely on a behaviour which happens to work one way at the moment, but was never specified anywhere (formally or informally), and might even be considered buggy and changed in future browser versions. You may make assumptions which look fine when rendered on a standard screen today, but will cause the site to break with very small or very large screens tomorrow - this was certainly the case a few years back with sites that had only been 'tested' on typical PC monitors. If you consciously decide to rely on these implementation details, that's fine. You may judge it is a better use of your time to write something that happens to work for 99% of users today, rather than agonize over whether it strictly complies with all possible standard-conforming browsers in the future. But it is surely better to make an informed choice.
Posted Feb 18, 2013 12:53 UTC (Mon) by alankila (guest, #47141)
From my point of view, all the multiple browsers accomplish is:
1) make it harder to write single acceptable codebase that works for them;
2) make it more time consuming to test things;
3) reduce the set of functions I can use, or
4) force extra code to be written that deals with the unacceptable reductions from 3.
The compat crud and ridiculous kludges you end up with are not resulting in any improved code quality of catching of bugs; that is the standard-mindset speaking. But there is no standard: they're just ridiculous kludges that mar otherwise simple and nice designs.
Posted Feb 18, 2013 13:28 UTC (Mon) by alankila (guest, #47141)
My message is this: implementations dominate. And I have fully resigned to updating the code whenever some new popular browser or new screen dimension comes that causes stuff to not work optimally. It's just fact of life and the alternatives of trying to spend a lot of effort trying to guess where you are 5 years from now are probably going to go wrong anyway.
Posted Feb 18, 2013 14:26 UTC (Mon) by epa (subscriber, #39769)
Posted Feb 18, 2013 16:16 UTC (Mon) by alankila (guest, #47141)
CSS was also meant to solve the multidevice presentation problem by allowing overriding of the instructions based on screen type (somehow), so the pixel reign can probably be extended even to devices shaped like a david's star in due course. But as with all abstractions, you can spend a lot of effort doing something that probably ends up being a very small benefit. The only really good use case I've come across for @media is the ability to remove elements from page when printing, so far. Not very glorious.
All this CSS stuff is very complicated, and historically most of it didn't work reliably. Today it might work, but I don't care. As I admitted from early on, my attitude is best summarized in the word "apathy".
Posted Mar 12, 2013 6:12 UTC (Tue) by Duncan (guest, #6647)
Perhaps it was meant to be at one point...
As someone in another recent discussion pointed out, even pixels are relative, these days. Even if on first visit there's a 1:1 mapping of physical to logical pixels (and for all I know a browser accounts for the window size and possible average zoom on previous sites and does an initial zoom even on first render), the first thing many people do the first time they hit a site is zoom it to a comfortable size. I know firefox (and I presume all modern browsers) remember the zoom-state, so from there on out, every time a user comes back, the browser automatically zooms to whatever the user preferred, and any page-specified pixel sizes are relative to that.
So even pixel metrics are relative, these days...
(Of course, that's not even considering user controlled rewriting proxies such as privoxy, or technologies such as greasemonkey. I long ago taught my instance of privoxy to replace font px with pt, along with a number of related replacements like ms sans serif with just sans serif. From my filter file (JED are my initials, nice convenient way to avoid namespace pollution; many of these were from when I was using konqueror as my default browser; I could probably revisit some of them now, but if they're not causing issues...):
FILTER: JED-Font Kill various font attributes
# Kill MSSansSerif, as the default replacement for it
# here is virtually unreadable
s+ms sans serif(,?)+m\$ sans serif($1)+isg
# Kill clean, as it's single-sized tiny
# Kill dynamic-loaded font-faces as they're
# crashing konqueror (2011.0426)
# Replace Lucida Console
# Replace pixels with points (style)
# Kill sub-100% font sizes
Posted Feb 18, 2013 13:10 UTC (Mon) by marcH (subscriber, #57642)
Lack of backward compatibility: where the "single browser" dream/nightmare breaks indeed. It's surprising how browsers versions are very seldom mentioned in discussions like this one.
Posted Feb 19, 2013 19:52 UTC (Tue) by sorpigal (subscriber, #36106)
Posted Feb 18, 2013 9:29 UTC (Mon) by pboddie (guest, #50784)
Posted Feb 18, 2013 15:54 UTC (Mon) by drag (subscriber, #31333)
Of course it's irritating when 3 column design were everything is just jammed together and you end up with the real content that is only about 15 character wide text. That's almost as bad.
Posted Feb 18, 2013 19:08 UTC (Mon) by dlang (subscriber, #313)
The problem is that lots of websites will have a 2-3" wide column of text in a 19" wide window, the rest of the browser window is blank.
This is even worse than super wide text.
if you let your text go the width of the browser window the user can narrow the window if they want. If you lock it to a really narrow column, the user can't widen it.
Posted Feb 18, 2013 21:40 UTC (Mon) by pboddie (guest, #50784)
People seem to forget that observations about the readability of wide columns of text are accompanied by recommendations that do not simply end with "restrict the width to ten words". Such recommendations came about through centuries of experience with the printed word and included other measures such as increasing the line spacing or "leading", or using shorter paragraphs (a general trend in mainstream writing, particularly in electronic media).
I do agree that CSS is a fairly poor tool for dealing with flexible layout and thus delivering multiple columns without a lot of extra work, however.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds