Re: Is polyfilling future web APIs a good idea?

[Brian Kardell]

On Mon, Aug 3, 2015 at 9:07 PM, Glen Huang  wrote:
> Brian,
>
> prollyfills seems pragmatic. But what about when the logic of an API changes, 
> but not the name? The node.replaceWith() API for example is about to be 
> revamped to cover some edge cases. If the prollyfills exposed 
> node._replaceWith(), what should it do when the new node.replaceWith() comes? 
> Expose node._replaceWith2()? This doesn't seem to scale.
>

Why would it need to?  Just like any library, you import a version and
deal with incompatibilities when you upgrade?


> But I do see the benefit of prefixing in prollyfills. node.replaceWith() used 
> to be node.replace(). If we exposed _replace() earlier, we can swap the 
> underlying function with node.replaceWith() when we release a new version, 
> and old code immediately benefit from the new API. But over time, prollyfills 
> are going to accumulate a lot obsolete APIs. Do you think we should use 
> semver to introduce breaking changes? Or these obsolete APIs should always be 
> there?
>

Yes, I think authors will opt in to an API and that API may contain
breaking changes or backcompat changes, I think that's up to people
implementing and maintaining to experiment with.  Too early to say
what will be more successful, but I don't forsee things growing
forever - at some point people remove polyfills too in practice... In
theory you could use something like FT-labs polyfill as a service to
make any browser 'normalized' but that gets really heavy if it isn't
targeted and goes back too far in practice.  No one is even writing
polyfills for IE6 anymore - most don't even go back to IE8.


> And if we are going this route, I think we need blessing from the WG. They 
> have to promise they will never design an API that starts with the prefix we 
> used.

We have that in web components already (no native element will be a
dasherized name - in most practical terms, attributes too), for all
things CSS (-vendor-foo just has no vendor and becomes --foo) and when
you're talking about DOM - yeah, we dont have one, but no DOM will
contain an leading underscore, I can just about promise that without
any agreements - but I agree it'd be great if we just had one.



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Fwd: [webappsec] CfC: Proposed non-normative updates to CORS

[Brad Hill]

(Dang, just realized I forgot to include WebApps on this joint deliverable.)

Members of WebApps, please note the below Call for Consensus on proposed
non-normative updates to the CORS recommendation and comment on
public-webapp...@w3.org by Monday, August 10, 2015.

Thank you,

Brad Hill
co-chair, WebAppSec WG

-- Forwarded message -
From: Brad Hill 
Date: Tue, Jun 30, 2015 at 2:05 PM
Subject: [webappsec] CfC: Proposed non-normative updates to CORS
To: public-webapp...@w3.org 


In response to https://www.w3.org/Bugs/Public/show_bug.cgi?id=28861 and
other requests, I would like to propose the following non-normative edits
to the CORS Recommendation. (http://www.w3.org/TR/cors/)

See attached file for the proposed publication-ready document including
these edits.

A detailed description of the proposed edits follows:

1) Remove text referring to expected changes in HTML5 and the HTTP Status
Code 308, as both have advanced to REC and RFC status, respectively.

2) Update the HTTP Status Code 308 reference to point to RFC7538

3) Remove text and links for implementation reports that are 404.

4) Add the following to the end of SOTD:

 Development of the CORS algorithm after 2013 has continued in the https://fetch.spec.whatwg.org/";>Fetch Living Standard. 

5) Correct Section 6.2 Preflight Request, step 10, second Note, to
correctly refer to Access-Control-Request-Headers.

These changes do not impact the conformance characteristics of any user
agent implementation.  This is a call for consensus to publish these
changes, which will end in 10 days, on July 10th.

Sincerely,

Brad Hill
WebAppSec co-chair
Title: Cross-Origin Resource Sharing

 
  





   Cross-Origin Resource Sharing

   W3C Recommendation 16 January 2014

   
This Version:
http://www.w3.org/TR/2014/REC-cors-20140116/

 Latest Version:
 http://www.w3.org/TR/cors/

Previous Versions:
http://www.w3.org/TR/2013/PR-cors-20131205/
http://www.w3.org/TR/2013/CR-cors-20130129/
http://www.w3.org/TR/2012/WD-cors-20120403/
http://www.w3.org/TR/2010/WD-cors-20100727/
http://www.w3.org/TR/2009/WD-cors-20090317/
http://www.w3.org/TR/2008/WD-access-control-20080912/
http://www.w3.org/TR/2008/WD-access-control-20080214/
http://www.w3.org/TR/2007/WD-access-control-20071126/
http://www.w3.org/TR/2007/WD-access-control-20071001/
http://www.w3.org/TR/2007/WD-access-control-20070618/
http://www.w3.org/TR/2007/WD-access-control-20070215/
http://www.w3.org/TR/2006/WD-access-control-20060517/
http://www.w3.org/TR/2005/NOTE-access-control-20050613/

Editor:
Anne van Kesteren
(formerly of Opera Software ASA)

   
Please note there may be errata for this document.
  
  The English version of this specification is the only normative version. Non-normative
  translations may also be available.
  



Copyright © 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.

  


  



  Abstract

  This document defines a mechanism to enable client-side cross-origin
  requests. Specifications that enable an API to make cross-origin requests
  to resources can use the algorithms defined by this specification. If
  such an API is used on http://example.org resources, a
  resource on http://hello-world.example can opt in using the
  mechanism described by this specification (e.g., specifying
  Access-Control-Allow-Origin: http://example.org as response
  header), which would allow that resource to be fetched cross-origin from
  http://example.org.




  Status of this Document

This section describes the status of this document at the time of
  its publication. Other documents may supersede this document. A list of
  current W3C publications and the latest revision of this technical report
  can be found in the
  W3C technical reports index at
  http://www.w3.org/TR/.

  This document has been reviewed by W3C Members, by software developers,
and by other W3C groups and interested parties, and is endorsed by the
Director as a W3C Recommendation. It is a stable document and may be
used as reference material or cited from another document. W3C's role in
making the Recommendation is to draw attention to the specification and
to promote its widespread deployment. This enhances the functionality
and interoperability of the Web.

  This W3C Recommendation of CORS was produced jointly by the
  Web Applications (WebApps)
  and
  Web Application
  Security (WebAppSec) Working Groups, and published by the
  WebAppSec Working Group. No changes were made since the previous
  publication as Proposed Recommendation.
  If you wish to make comments regarding this document, please send them to 
  public-webapp...@w3.org 
  (subscribe,
  archives).


 This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains a pu

Re: Is polyfilling future web APIs a good idea?

[Glen Huang]

Brian,

prollyfills seems pragmatic. But what about when the logic of an API changes, 
but not the name? The node.replaceWith() API for example is about to be 
revamped to cover some edge cases. If the prollyfills exposed 
node._replaceWith(), what should it do when the new node.replaceWith() comes? 
Expose node._replaceWith2()? This doesn't seem to scale.

But I do see the benefit of prefixing in prollyfills. node.replaceWith() used 
to be node.replace(). If we exposed _replace() earlier, we can swap the 
underlying function with node.replaceWith() when we release a new version, and 
old code immediately benefit from the new API. But over time, prollyfills are 
going to accumulate a lot obsolete APIs. Do you think we should use semver to 
introduce breaking changes? Or these obsolete APIs should always be there?

And if we are going this route, I think we need blessing from the WG. They have 
to promise they will never design an API that starts with the prefix we used.

Let's say we write a prollyfills for the node.replace API. So our lib exposes 
node._replace
> On Aug 3, 2015, at 10:16 AM, Brian Kardell  wrote:
> 
> On Sun, Aug 2, 2015 at 9:39 PM, Glen Huang  wrote:
>> I'm pretty obsessed with all kinds of web specs, and invest heavily in tools 
>> based on future specs. I was discussing with Tab the other day about whether 
>> he thinks using a css preprocessor that desugars future css is a good idea. 
>> His answer was surprisingly (at least to me) negative, and recommended sass. 
>> His arguments were that
>> 
>> 1. the gramma is in flux and can change
>> 2. css might never offer some constructs used in sass, at least with very 
>> low priority.
>> 
>> I think these are good points, and it reduced my enthusiasm for future spec 
>> based css preprocessors. But this got me thinking about polyfills for future 
>> web APIs. Are they equally not recommended? Likewise, the APIs might change, 
>> and for DOM operations we should rely on React because the native DOM might 
>> never offer such declarative APIs, at least with very low priority. Do 
>> polyfills like WebReflection's DOM4 look promising? For new projects, should 
>> I stick with polyfills that only offers compatibilities for older browser, 
>> and for future spec features, only use libraries that offer similar features 
>> but invent their own APIs, or should I track future specs and use these 
>> "unstable" polyfills?
>> 
>> I'm torn on this subject. Would like to be enlightened.
> [snip]
> 
> TL;DR: Yes, I think they are good - really good actually, with some
> best practices.
> 
> CSS is a slightly different beast at the moment because it is not
> (yet) extensible, but let's pretend for a moment that it is so that a
> uniform answer works ok...
> 
> This was why I and others advocated defining the idea of/using the
> term "prollyfill" as opposed to a polyfill.  With a polyfill you are
> filling in gaps and cracks in browser support for an established
> standard, with a prollyfill you might be charting some new waters.  In
> a sense, you're taking a guess.  If history is any indicator then the
> chances that it will ultimately ship that way without change is very
> small until it really ships in two interoperable browsers that way.
> There's more to it than slight semantics too I think:  Polyfill was
> originally defined as above and now for many developers the
> expectation is that this is what it's doing.  In other words, it's
> just providing a fill for something which will ultimately be native,
> therefore won't change.  Except, as we are discussing, this might not
> be so.  Personally, I think this matters in a big way because so much
> depends on people understanding things:  If users had understood and
> respected vendor-prefixed CSS for use as intended, for example, they
> wouldn't have been much of a problem -- but they were.  Users didn't
> understand that and things shipped natively, so vendors had to adjust
> - things got messy.
> 
> Debates about this took up a lot of email space in early extensible
> web cg lists - my own take remains unchanged, mileage may vary:
> 
> It is my opinion that when possible, we should 'prefix' prollyfilled
> APIs - this could be something as simple as an underscore in DOM APIs
> or a "--property" in CSS, etc.  Hopefully this makes it obvious that
> it is not native and is subject to change, but that isn't the reason
> to do it.  The reason to do it is the one above:  it *may* actually
> change so you shouldn't mislead people to think otherwise - it
> potentially affects a lot.  For example, if something gets very
> popular masquerading as native but no one will actually implement
> natively it without changes - they are stuck having to deal with
> shitty compromises in standards to keep the web from breaking.  Also,
> what happens when devs "sell" a standard with the promise that it's
> going to be native and then we rip that rug out from underneath them.
> 
> For me then, following a nice pattern wh