From 3ec7cf8fc09a59a0bee66329783dd1ca7df93bc4 Mon Sep 17 00:00:00 2001 From: Alon Zakai Date: Mon, 4 May 2015 11:10:20 -0700 Subject: mention polyfill limitations --- HighLevelGoals.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'HighLevelGoals.md') diff --git a/HighLevelGoals.md b/HighLevelGoals.md index c560891..eb9bbff 100644 --- a/HighLevelGoals.md +++ b/HighLevelGoals.md @@ -11,8 +11,12 @@ evolution story of the web; engines should not need multiple, versioned decoders. 5. Design and implement incrementally: - * [v.1](V1.md) of the standard will be a Minimum Viable Product with a full, effective [polyfill][] via client-side compilation to [asm.js][] and thus run on existing browsers; - * subsequent versions will add more [features](EssentialPostV1Features.md) prioritized by feedback. + * [v.1](V1.md) of the standard will be a Minimum Viable Product with a [polyfill][] via client-side compilation to [asm.js][] and thus run on existing browsers. + In semantic corner cases (such as out-of-bounds and alignment, which evoke Undefined Behavior in C and C++), where asm.js does not have ideal semantics, + the default polyfill would diverge for performance reasons (it would also be possible to run a more precise but slower polyfill, but almost all + real-world applications are not expected to need to do so). + * subsequent versions will add more [features](EssentialPostV1Features.md) prioritized by feedback. Some of those features might not be polyfillable + to asm.js in a practical way. 6. Design to execute within and integrate well with the existing web platform: * execute in the same semantic universe as JavaScript; * allow synchronous calls to and from JavaScript; -- cgit v1.2.3