3 ms·

Compatibility in new engines is ... hard. Servo is basically going to need to spoof the WebKit UA and duplicate a bunch of WebKit bugs (the Edge approach) or s

Compatibility in new engines is ... hard. Servo is basically going to need to spoof the WebKit UA and duplicate a bunch of WebKit bugs (the Edge approach) or spoof the Gecko UA and duplicate a bunch of Gecko bugs. Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" switch with behavior specified for both branches. :(

leeoniya 10y ago
> Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" woah! that's truly tragic. at the risk of ruining the rest of my week, may i ask where?
- bzbarsky 10y ago
  Sure. https://html.spec.whatwg.org/multipage/webappapis.html#concept-navigator-compatibility-mode https://html.spec.whatwg.org/multipage/webappapis.html#conce... and the pieces of that spec that use it is the main place so far. There is also discussion about maybe using the same switch in https://github.com/whatwg/dom/issues/278 https://github.com/whatwg/dom/issues/278 if it turns out that too many pages assume "not webkit" means XMLDocument.load exists. It could be worse. When the ECMAScript committee discovered that parsing for function-in-a-block differs between browsers and that sites sniff and do different things in different browsers such that none of the browsers can change to each other's behavior, they went ahead and specified a "compatible subset" of behavior such that if you follow those rules you will get the same behavior in all browsers. That's fine, but if you _don't_, as web pages do not, then you're back to square 1: pages sniff and do different things. And the details are not written down anywhere, so a new implementation has no choice but to try to reverse-engineer the sniffing somehow and then also reverse-engineer the actual runtime behavior of function declarations of whatever browser's sniffing response they decided to fake. The good news is that this function-in-a-block thing is literally the worst situation I have encountered in web standards, so all the other ones suck less. ;)
Aldo_MX 10y ago
Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine? Replicating other engine's bugs sounds like too much effort towards the wrong direction :/ Although, after the -webkit-disaster I don't really expect anyone to like the idea of a standards-compliant engine :(
- Manishearth 10y ago
  > Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine? So far, we are (as far as I know)! We try very hard to avoid nonstandard behavior, and if we can't avoid it, try to push for its inclusion in the standard. Given that there are no users that rely on Servo, we can even wait for the standard to be changed before implementing it. We often try to implement the standard to the word, with code that closely matches up to the standard. This has helped find tons of bugs in the standard (or in the tests). Nonstandard behavior in components shared with Gecko are off in Servo mode. But if Servo is to be a product we probably will have to change our stance here eventually.
- pcwalton 10y ago
  > Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine? That's what we've done so far. We haven't exposed any Gecko- or WebKit-specific stuff that I'm aware of. We have our hands full with the standard :) (That said, we have implemented things that are unspecified but are de facto standards implemented by both Gecko and WebKit. That includes basic things like <button> and tables…)
  - kibwen 10y ago
    Any efforts underway to turn those de facto standards into actual standards as Servo encounters them?
    - pcwalton 10y ago
      Yes, when we have time. For example, notriddle has been going great work trying to spec hypothetical boxes: https://github.com/notriddle/ServoHypothetical https://github.com/notriddle/ServoHypothetical

leeoniya 10y ago

> Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" woah! that's truly tragic. at the risk of ruining the rest of my week, may i ask where?

bzbarsky 10y ago
Sure. https://html.spec.whatwg.org/multipage/webappapis.html#concept-navigator-compatibility-mode https://html.spec.whatwg.org/multipage/webappapis.html#conce... and the pieces of that spec that use it is the main place so far. There is also discussion about maybe using the same switch in https://github.com/whatwg/dom/issues/278 https://github.com/whatwg/dom/issues/278 if it turns out that too many pages assume "not webkit" means XMLDocument.load exists. It could be worse. When the ECMAScript committee discovered that parsing for function-in-a-block differs between browsers and that sites sniff and do different things in different browsers such that none of the browsers can change to each other's behavior, they went ahead and specified a "compatible subset" of behavior such that if you follow those rules you will get the same behavior in all browsers. That's fine, but if you _don't_, as web pages do not, then you're back to square 1: pages sniff and do different things. And the details are not written down anywhere, so a new implementation has no choice but to try to reverse-engineer the sniffing somehow and then also reverse-engineer the actual runtime behavior of function declarations of whatever browser's sniffing response they decided to fake. The good news is that this function-in-a-block thing is literally the worst situation I have encountered in web standards, so all the other ones suck less. ;)

Aldo_MX 10y ago

Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine? Replicating other engine's bugs sounds like too much effort towards the wrong direction :/ Although, after the -webkit-disaster I don't really expect anyone to like the idea of a standards-compliant engine :(

Manishearth 10y ago
> Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine? So far, we are (as far as I know)! We try very hard to avoid nonstandard behavior, and if we can't avoid it, try to push for its inclusion in the standard. Given that there are no users that rely on Servo, we can even wait for the standard to be changed before implementing it. We often try to implement the standard to the word, with code that closely matches up to the standard. This has helped find tons of bugs in the standard (or in the tests). Nonstandard behavior in components shared with Gecko are off in Servo mode. But if Servo is to be a product we probably will have to change our stance here eventually.
pcwalton 10y ago
> Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine? That's what we've done so far. We haven't exposed any Gecko- or WebKit-specific stuff that I'm aware of. We have our hands full with the standard :) (That said, we have implemented things that are unspecified but are de facto standards implemented by both Gecko and WebKit. That includes basic things like <button> and tables…)
- kibwen 10y ago
  Any efforts underway to turn those de facto standards into actual standards as Servo encounters them?
  - pcwalton 10y ago
    Yes, when we have time. For example, notriddle has been going great work trying to spec hypothetical boxes: https://github.com/notriddle/ServoHypothetical https://github.com/notriddle/ServoHypothetical