mozilla :: #mdn

13 Jul 2017
10:02fscholzmike5w3c: Isn't it too early to mark CSP report-uri as deprecated when no one supports the new CSP report-to yet?
10:16mike5w3cfscholz: I dunno, is there any MDN policy to look to for guidance on this?
10:16mike5w3cI mean, the latest spec is the CSP3 spec, which does deprecate report-uri
10:18mike5w3cbut anyway, a rule of thumb is to dont mark things as deprecated if browsers dont yet support the thing that replaces it, that makes sense
10:18mike5w3cso I guess its best if I revert that change?
10:19mike5w3chmm
10:19fscholzI think if the spec deprecates something, we should deprecate it, too. But I guess reality is that no one can use report-to yet and it also isn't fully stable yet in the spec? report-uri seems like a thing that is more real for now
10:19mike5w3cyeah
10:19mike5w3cso, not sure what to do
10:20mike5w3cbut re-reading the deprecation boilerplate, I can see its carefully worded already to deal with this
10:20fscholzMe neither. I would maybe relax the red banners on report-uri and just add a note that the standard is planning to deprecate this in favor of report-to
10:20mike5w3c> This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Avoid using it and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
10:21fscholzWill it really be removed? I mean a lot of people use report-uri, right? It would break the web?
10:21mike5w3cThough some browsers may still support it... Avoid using it.. *if possible* ...
10:22mike5w3cyeah I dunno but I suspect that browser will have to continue to support it until use counters show they don'
10:22mike5w3c*dont need to any longer
10:22fscholzyeah
10:22mike5w3cI can at least re-word the second note:
10:22mike5w3c> The report-to directive should be used in place of the deprecated report-uri directive. But for backward compatibility with older browsers, you can specify both:
10:23mike5w3c...is what it says now
10:23mike5w3cbut refine it to sya, But for compatibility with *current* browsers...
10:24mike5w3canyway, will make some tweaks to it in 30-40 minutes
10:24mike5w3cgotta step away for a bit now
10:24fscholzyeah that makes sense. Also, there is no page for report-to yet, so no one actually knows it isnt supported yet
10:24fscholzSure
17:35mike5w3cstandups: Clarified deprecation status of the CSP report-uri directive https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/report-uri$compare?to=1271429&from=1268541
17:35standupsOk, submitted #48175 for https://www.standu.ps/user/mike5w3c/
17:36mike5w3cfscholz: see the new wording there
17:36mike5w3c> Though the report-to directive is intended to replace the deprecated report-uri directive, report-to isnt supported in most browsers yet. So for compatibility with current browsers while also adding forward compatibility when browsers add report-to support, you can specify both report-uri and report-to: Content
17:36mike5w3c...
17:36mike5w3c> In browsers that support report-to, the report-uri directive will be ignored.
17:37fscholzmike5w3c: excellent, thank you!
17:37mike5w3ccheers
17:38mike5w3calso note that part of the context for this is that for the W3C HTML Checker, I just recently updated the third-party library that we use for CSP checking, and it that update causes the HTML checker to now emit warnings about report-ui and also child-src
17:39mike5w3cbut I subsequently added some filtering to suppress the child-src warning
17:39mike5w3cand it may be that I need to also suppress the report-ui warning for now
17:40fscholzInteresting, I noticed this only because https://bugzilla.mozilla.org/show_bug.cgi?id=1380422 was filed.
17:40firebotBug 1380422 NEW, nobody@mozilla.org Document "report-to" CSP directive
17:40* mike5w3c looks
17:40fscholzI wonder if we have an implementation bug filed for Firefox at all
17:40mike5w3caha
17:41mike5w3coh I would hope so but I guess I should not assume
17:45fscholzhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/referrer is also deprecated fwiw
17:46fscholzI can't find the report-to bug right now and I have to call it a day.
17:48mike5w3cfscholz: cheers & thanks
17:52rwaldronfscholz good day!
17:52rwaldronI was just looking through mdn notifications and I happened upon this page: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/length
17:52rwaldronand I realized there is something "funny" about this. "Array.length" is a thing, but not in the way this page presents it. I wonder how we can address that?
19:36sheppyrwaldron: Hi... how is the Array.length page wrong?
19:48rwaldron@sheppy "wrong" feels harsh
19:48sheppyrwaldron: Okay... still curious what's up. :)
19:48rwaldronThe Array constructor itself has a property called `length` (like all functions)
19:49rwaldronBut that page is actually referring to the length property of an Array object
19:49rwaldronSee what I mean?
19:50rwaldronI'm just wondering if there is a better way to deliver the intended information
19:54sheppyI guess I'm not sure what the difference is.
19:58* sheppy looks at spec
19:59sheppyBecause the Array constructor's length property's value is always 1, so that's hardly useful...
20:03sheppyFrom the strict sense, Array.length is always 1, but this is of course referring to the length of an array instance in the documentation, as are pretty much all pages in the reference; the object type name is used as a stand-in for the name of an instance of that type.
20:06sheppystandups: Updated the doc for Array.length to clarify that it's referring to the length property on an Array instance, rather than the length property of the Array constructor.
20:06standupsOk, submitted #48182 for https://www.standu.ps/user/sheppy/
20:07rwaldron:D
20:07rwaldron@sheppy high-five
20:28sheppyrwaldron: :)
14 Jul 2017
No messages
   
Last message: 69 days and 16 hours ago