Skip navigation.

exploreopera

| Help

Sign up | Help

Posts tagged with "specs"

Suggestions for Chris Wilson

Wednesday, 23. January 2008, 07:07:17

, ,

How would Chris Wilson feel if people stopped writing him open letters?

I'm nowhere near Brendan's league but here's another "Dear Chris", this time on the proposed <meta http-equiv="X-UA-Compatible" content="IE=8" /> versioning for HTML5.

First: I know you're stuck between a rock and a hard place, between thousands of web developers shouting and swearing at you for not implementing the standards better and millions of web sites that might break if you do. Moreover, knowing first-hand the problems Opera ran into when implementing WebForms 2 I don't doubt for a moment that your compatibility concerns are real.

The proposed META tag sort of shifts maintenance and backwards compatibility concerns from website authors to browser developers, which can be a good thing. However, there are problems with such wholesale version targetting:

  • Browsers will have to support an unmanageable and confusing mess of different rendering modes (and the PocketIE team will hate you for the bloat).
  • Because the META tag affects every part of the page, progressively enhancing such pages with new CSS features will be harder.


The way the web currently works is partial versioning: using JavaScript object detection, conditional comments (IE-only), CSS hacks or special keywords to "opt in to" specific layout or scripting properties. Can we build on and extend that? Enhance feature detection rather than opt-in hard-coded rendering mode?

Some examples of what that might look like..

-moz-box-sizing equivalents for opting in to specific interpretations of given CSS properties 
if( 'borderRadius' in element.currentStyle )
@supports-multiple-backgrounds{ div.mosaic{ bacground: URL(bg1.png) top left no-repeat; bacground: URL(bg2.png) bottom right no-repeat } }

I'd like markup or CSS to express "if you support css3-column-layout, fetch that stylesheet, else use this XSL transformation to build a TABLE".. So, feature-based versioning built right into the standard itself instead of added as a META hack and an afterthought. Please consider making the opt-in mechanisms feature-based rather than rendering-engine-version-based!

How can you do it? Well, the IE team may have forgotten what it takes to play catch-up with a different UA implementation (you had some experience back in the NS4 days though) but Opera QA can remind you :wink:. You could apply the same skills to align the new standard and the new rendering engine with the web:

The web and the spec would benefit enourmously if your team sat down to do the detailed analysis work - hunting through the sites that break, figuring out the main problems, suggesting ways the still-in-progress HTML5 standard could change to make real compatibility possible. It's slow but you can make a public comittment and draw huge grassroot support from web developers. I bet you would get help doing evangelism and outreach for sites that serve you "error correcting" CSS you can't possibly work with in standars mode. You can release IE8 beta versions but delay the final until site compatibility problems are resolved..

We at Opera doing this right now, spending hours analysing IE quirks to figure out how to be compatible with the specs, the web, and the IEs. It's slow. It takes manhours and manyears. But it's what it takes to do it right..

Software is 100% detail. Quality is 100% attention to detail. And the detail called X-UA-Compatible should be replaced with something better. Thanks for your attention.

8 Comments

alignment of megaliths

Saturday, 2. June 2007, 20:48:28

, , , ...

The main point of the standards is of course to align the megaliths rendering and scripting engines of standards-compliant browsers. I've already discussed some of the problems arising when specs and implementations clash, and the dilemmas we face when we have the choice between being strictly standards-compliant and breaking some major website or breaking the spec, aligning with the other browsers, and making the site(s) work.

Never an easy decision to make!

I can now confirm a few points where Opera 9.5 is going to deviate somewhat from the specs or from our earlier implementations in order to be better aligned with other browsers. If you are a webmaster or JavaScript author please check that the changes will not cause problems for you!

We'll do the following:

  • Capturing event listeners will fire on target. This behaviour will be kept until Firefox fixes their bug. Opera's new implementation is not expected to cause problems since most sites using the addEventListener API will have been tested against Firefox. A possible exception is widget code which may expect Opera's old behaviour.
  • Implementation of capturing load event handlers changed: load events from within the document will now only be captured when the capturing event listener is attached to the document. In other words, earlier you could do 
    window.addEventListener('load', func, true)
    and expect func to be called for all "load" events inside the document. From 9.5 you will have to do 
    document.addEventListener('load', func, true)
    to get this capturing behaviour. (Please do not copy that code unless you know what the "true" part of it means!) This will probably become the official specification. Again, this will probably only break code specifically written for Opera such as widgets, and the change is known to fix large number of websites that use event capture by mistake.
  • We've changed the relationship between body.clientHeight and documentElement.clientHeight in standards mode. The value of body.clientHeight is now viewport height, documentElement.clientHeight is document height. This is AFAIK what Firefox does too. This change can break your website if you use browser detection before reading clientHeight from body or documentElement.


I believe Firefox will support adding capturing load events to document. There you go, alignment of megaliths!

(Like the post title? Found it on Wikipedia :smile:.)

10 Comments

re-invented wheels

Wednesday, 13. December 2006, 14:18:57

, ,


The HTML input element already defines a type attribute so it was a matter of adding new values, and my experiments looked at doing so for number and date. This worked fine on most browsers, but the Opera browsers handling of the type and required attributes made it necessary to support datatype and needed as alternatives.

(source)
Well, that's the sort of problem you get when re-inventing wheels: you have to figure out how to fit them in next to the wheels already in place. Meet the JavaScript car mechanic:
  // partial work around Opera's WF2 implementation for type
  // same technique doesn't work for required attribute :-(

Doesn't work for "required"? Seems like the JavaScript mechanic left his "removeAttribute" tool at home.

  if (nativewf2)
  {
    fields = document.getElementsByTagName("input");

    for (i = 0; i < fields.length; ++i)
    {
      field = fields[i];
      type = field.getAttribute("type");

      if (type == "number" || type == "date")
      {
        field.setAttribute("datatype", type);
        field.setAttribute("type", "text");


Look at those final setAttribute statements: since Opera's WF2 wheels apparently aren't good enough they are dismounted and the fancy JavaScript-required-XForms-Lite-wheels fitted instead. Why can't the mechanic simply say "OK, this car already has wheels so I don't need to do any work here"?

Are the differences between XForms Lite "date" and WF2 "date" so severe?

Why would one "required" be better than the other (besides from "required" being invented there while "required" isn't, that is..)?

2 Comments

When specs and implementations clash

Monday, 28. August 2006, 00:25:33

, , , ...

One of the points of having open, independently developed standards from the W3C is of course to achieve compatibility.

However, standards are not always clear and consistent, and browsers do not always get things right.

When facing a choice between being compatible with other browsers and websites OR the standard, we may have a third way: fixing the standard to align it with the common implementations and the content. That's the only way one can have the cake and eat it, be standards-compatible and compatible with the Web as it is. Is it feasible? Or even a good idea? Standards are supposed to be set-in-stone after all, to keep implementors happy so that we don't spend hours and money doing it this way only to find a rewritten standard tells us to follow that way instead..

Three real-life examples of cases where we do break or are about to break the standard:

1) getAttribute on non-existing attributes
Standard mandated returning an empty string. Other browsers returned null. Sites running into problems due to Opera's correct standards support included Yahoo mail.

We reached a general consensus that returning null is a better idea, so we have changed Opera and asked the relevant W3C group to consider changing the text in an errata or the next version.

2) Throwing WRONG_DOCUMENT_ERR on cross-document node usage
If a node created in one document is appended to another document, the standard clearly states that a WRONG_DOCUMENT_ERR should be thrown. Firefox doesn't, and sites taking the Firefox behaviour for granted and breaking in Opera included Blogger.com's rich text editor.

Opera will start to call adoptNode implicitly. I'm not sure what way the standard will go - nobody seems to intend to push for a change here. According to their bug report, Mozilla intends to fix it (which is great!) and as soon as they do and websites fix their coding errors, we can revert to spec-compatible mode. Meanwhile, we are not going to live with sites being broken in Opera due to Firefox's bugs.

3) addEventListener and firing capturing events on target
Setting a capturing "click" event listener on, say, an IMG tag has no effect, because the standard clearly says that event listeners should not fire on target. Again, Firefox gets the implementation wrong and sites where this has caused trouble include live.com (according to the Safari team, I have not seen this myself but their analysis is probably right).

Sure, we should fix the standard here and go for it - I don't see any specific benefit to not firing the event listener though I'm all ears if anyone knows why the spec is written like that. We haven't changed this yet but I guess we will follow Safari.

The lesson? To standards bodies: please care about existing implementations, experience and content when developing the standards. Specs that are seriously incompatible with prior implementations or web content cause implementation headaches, incompatibilities and suffering users.

13 Comments