| |||||||||||||
Opera moves to WebKit and V8Opera moves to WebKit and V8Posted Feb 18, 2013 12:15 UTC (Mon) by epa (subscriber, #39769)In reply to: Opera moves to WebKit and V8 by alankila Parent article: Opera moves to WebKit and V8
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.
(Log in to post comments)
Opera moves to WebKit and V8 Posted Feb 18, 2013 12:53 UTC (Mon) by alankila (subscriber, #47141) [Link]
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;
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 (subscriber, #47141) [Link]
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]
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 (subscriber, #47141) [Link]
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
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
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]
> 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 (subscriber, #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.
|
|||||||||||||