Opera moves to WebKit and V8

Posted Feb 18, 2013 4:43 UTC (Mon) by dlang (guest, #313)
In reply to: Opera moves to WebKit and V8 by marcH
Parent article: Opera moves to WebKit and V8

far too many webdev people try to make things pixel perfect.

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.

Opera moves to WebKit and V8

Posted Feb 18, 2013 9:02 UTC (Mon) by alankila (guest, #47141) [Link] (10 responses)

I guess my attitude would be best described as apathy. Apathy is result of the complexity of the system, and the fact the specs and implementations are always in flux, there is no "right answer" how something should be done. Only the fact it works matters. Therefore I try to use techniques and APIs that seem to work the same on all browsers as much as possible.

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.

Opera moves to WebKit and V8

Posted Feb 18, 2013 9:19 UTC (Mon) by epa (subscriber, #39769) [Link] (9 responses)

I would have said that having more different engines like Opera would make your job easier, not harder. After all the more different engines you test with, the greater the chance of finding problems - which may not show up immediately under popular browsers, but might cause the site to break a couple of years from now when newer browsers become popular, because you inadvertently relied on some non-standard behaviour or implementation quirk. (If your site breaks with browser X, some of the time it will be because of bugs in X, but at least half the time it will be because of bugs in the site's code, assuming X is not hopelessly ancient or non-standard.)

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.

Opera moves to WebKit and V8

Posted Feb 18, 2013 10:13 UTC (Mon) by alankila (guest, #47141) [Link] (8 responses)

You do not understand. There is no specification that I program for that would deserve such a name. Therefore it is not possible to determine what are bugs and what are not, or how something should be improved if it doesn't work other than "do not use this feature, because you can't rely on it working correctly". So basically the way I read your "multiple implementations are good" is "because they force you to program to some pathological subset of features that happen to work in all". I fail to understand why that is such a good thing. When something is absolutely essential in that it just has to work or you can't do the task at all, like say JavaScript events from clicks and drags, you have to write compatibility glue to get IE on board with the rest of the browsers.

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.

Opera moves to WebKit and V8

Posted Feb 18, 2013 12:15 UTC (Mon) by epa (subscriber, #39769) [Link] (7 responses)

I can see that if there were a single browser, with a promise to maintain backwards compatibility, then life would be easier. But even then you have the thorny question of what counts as backwards compatibility; taken strictly, even bug fixes would be impossible. Even new features ('I was relying on the fact that <FOO>hello</FOO> renders as text!'). At some point you have to admit that there is a specification, formal or informal, and you have to consider the spec as well as the current implementation.

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.

Opera moves to WebKit and V8

Posted Feb 18, 2013 12:53 UTC (Mon) by alankila (guest, #47141) [Link] (4 responses)

You still think there is a standard. I do not believe that to be case. We can point fingers at various web standardization bodies and the documents they write, but the only thing we have deployed are actual browsers, which may choose or not to follow these standard documents, or implement them incorrectly despite of best intentions.

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.

Opera moves to WebKit and V8

Posted Feb 18, 2013 13:28 UTC (Mon) by alankila (guest, #47141) [Link] (3 responses)

Before you have time to reply: of course you are right. I'm largely just parodying an extreme version of the "software must work here and now with what we got, and can you have it delivered yesterday"-mindset that a lot of us run into in a commercial setting.

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.

Opera moves to WebKit and V8

Posted Feb 18, 2013 14:26 UTC (Mon) by epa (subscriber, #39769) [Link] (2 responses)

Analogizing web design to C programming, there are two ways I can think of it. If you asked: would you prefer to build a program to run on a dozen different Unix variants, then I'd unhesitatingly reply that a world of just Linux would be ideal. But on the other hand, testing with different C compilers (including extra-strict ones like http://code.google.com/p/c-semantics/) is useful to find cases where you have made unwarranted assumptions or relied on implementation-specific behaviour.

It seems to me that Javascript is like the Unix-variants question: much better to have a single implementation. But pure HTML and CSS is more like the choice of compilers. CSS is declarative anyway and you don't expect to get pixel-identical results (not if you are wise), and there is such a large diversity of different screens (not to mention print and screen readers) that you are not building a fixed artefact so much as giving some general instructions which you hope that somebody will interpret in the way you intended. Given that you want to make sure that there are no hidden ambiguities or assumptions in the instructions you have written.

Opera moves to WebKit and V8

Posted Feb 18, 2013 16:16 UTC (Mon) by alankila (guest, #47141) [Link] (1 responses)

I do think CSS is meant to be pixel exact positioning tool, at least if you use pixel metrics. (Of course, anything that has images is pretty much forced to use pixel metrics because browsers suck at image scaling.)

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".

Opera moves to WebKit and V8

Posted Mar 12, 2013 6:12 UTC (Tue) by Duncan (guest, #6647) [Link]

> I do think CSS is meant to be pixel exact positioning tool, at least if you use pixel metrics.

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

s+((\{\s*font-family:[^;]*)|(<font[^>]*))clean+$1unclean+isg

# Kill dynamic-loaded font-faces as they're
# crashing konqueror (2011.0426)

s+@font-face+@font-face-jed-font-killed+isg

# Replace Lucida Console

s+lucida\sconsole+luxi mono+isg

# Replace pixels with points (style)

s+({[^}]*font-size:\s*[0-9][0-9]*)px+$1pt+isUg

# Kill sub-100% font sizes

s+({[^}]*font-size)(:\s*[0-9][0-9]%)+$1-JED-Font-pct$2+isUg

)

Opera moves to WebKit and V8

Posted Feb 18, 2013 13:10 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> I can see that if there were a single browser, with a promise to maintain backwards compatibility, then life would be easier. But even then you have the thorny question of what counts as backwards compatibility; taken strictly, even bug fixes would be impossible.

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.

Opera moves to WebKit and V8

Posted Feb 19, 2013 19:52 UTC (Tue) by sorpigal (guest, #36106) [Link]

Didn't you hear? There are no versions any more! All anyone cares about is that things are up-to-date. That's why Chrome and Firefox silently update and why the Firefox devs wanted to remove the version number from the About dialog. Even the HTML5 spec doesn't have a version, it's a "Living document"--live in the now, man! Versions are so last decade.

Opera moves to WebKit and V8

Posted Feb 18, 2013 9:29 UTC (Mon) by pboddie (guest, #50784) [Link] (3 responses)

My experience with CSS suggests that the more rules you add to try and get things "just right", the less likely it is that you will succeed in what you are trying to achieve. Unfortunately, instead of applying a light but effective touch, people instead resort to specifying everything in fixed pixel dimensions, resulting in the ubiquitous narrow strip of content surrounded by huge tracts of empty space, as seen on many sites.

Perhaps the only thing that is more annoying than pixel-precise layout is the apparent fad for needing JavaScript to set up the layout in the first place, meaning that if you use NoScript to stop the tens of superfluous "analytics" parasites from loading their scripts, you get a blank page or maybe content overwriting itself.

Opera moves to WebKit and V8

Posted Feb 18, 2013 15:54 UTC (Mon) by drag (guest, #31333) [Link] (2 responses)

Text is unpleasant to read when it's in wide rows on a screen. Much better to have narrow columns. At least in my experience.

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.

Opera moves to WebKit and V8

Posted Feb 18, 2013 19:08 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

> Text is unpleasant to read when it's in wide rows on a screen. Much better to have narrow columns. At least in my experience.

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.

Opera moves to WebKit and V8

Posted Feb 18, 2013 21:40 UTC (Mon) by pboddie (guest, #50784) [Link]

Once again someone makes my point for me better than I did! And, in any case, I can quite happily read your comment below this editing window even though it occupies around 80% of the screen width of my admittedly small monitor.

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.