4 ms·

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 bu

by 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
bzbarsky 10y ago
> why not keep the scope of Servo focused in building a standards-compliant engine It depends on how you define standards-compliant. > Replicating other engine's bugs sounds like too much effort towards the wrong direction Well, web pages depend on those. So your options are either to standardize them or to have a standard that, when implemented, gives you a non-working product. In practice, they're being standardized (just like XMLHttpRequest was a non-standard thing that ended up getting standardized). See https://compat.spec.whatwg.org/ https://compat.spec.whatwg.org/ and https://html.spec.whatwg.org/multipage/webappapis.html#concept-navigator-compatibility-mode https://html.spec.whatwg.org/multipage/webappapis.html#conce... and the bits of the HTML spec that reference it, the bits of https://drafts.csswg.org/cssom/ https://drafts.csswg.org/cssom/ that mention "webkit", and so forth. So in the end, a "standards-compliant" engine will implement those standards, which are themselves to some extent a codification of old implementation bugs; pretty normal for standards...

by Aldo_MX 10y ago

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

bzbarsky 10y ago

> why not keep the scope of Servo focused in building a standards-compliant engine It depends on how you define standards-compliant. > Replicating other engine's bugs sounds like too much effort towards the wrong direction Well, web pages depend on those. So your options are either to standardize them or to have a standard that, when implemented, gives you a non-working product. In practice, they're being standardized (just like XMLHttpRequest was a non-standard thing that ended up getting standardized). See https://compat.spec.whatwg.org/ https://compat.spec.whatwg.org/ and https://html.spec.whatwg.org/multipage/webappapis.html#concept-navigator-compatibility-mode https://html.spec.whatwg.org/multipage/webappapis.html#conce... and the bits of the HTML spec that reference it, the bits of https://drafts.csswg.org/cssom/ https://drafts.csswg.org/cssom/ that mention "webkit", and so forth. So in the end, a "standards-compliant" engine will implement those standards, which are themselves to some extent a codification of old implementation bugs; pretty normal for standards...