Notes

 
In reply to this conservation:
Glenn Jones
I hate the current experience of creating and managing SSL certs with all my soul. Enough to put people off using encryption for life
Jeremy Keith
@glennjones YES!! I wish that security advocates would realise that the problem isn’t lack of will; the problem is good ol’ fashioned pain.
@adactio It’s a classic definition of a UX issue, a process that helps me fail at every point and leaves you feeling stupid and disempowered
‐ Also on:


I hate the current experience of creating and managing SSL certs with all my soul. Enough to put people off using encryption for life
‐ Also on:
Mentions:
Steven Livingstone
Jeremy Keith
@glennjones YES!! I wish that security advocates would realise that the problem isn’t lack of will; the problem is good ol’ fashioned pain.
Glenn Jones
@adactio It’s a classic definition of a UX issue, a process that helps me fail at every point and leaves you feeling stupid and disempowered
Glenn Jones
@weblivz I so hope @letsencrypt and the next generation certificate authorities fix this problem


Performance testing microformats parser as it walks through the DOM. Never realised how fast Safari is, shame its #thenewIE : )
‐ Also on:

Taking a look at the profile and performance areas of the browsers, liking Firefox's performance tab, anyone known of a good post about it?
‐ Also on:




In reply to this conservation:
Tobie Langel
@glennjones that's a tough one indeed. What else could IE do not to cause that issue? /cc @adrianba
Glenn Jones
Find it a little sad some of the browser APIs are introduced in such an incomplete state the only way to use them is in try/catch blocks
Tobie Langel
@glennjones are these implementation issues or spec ones?
Tobie Langel
@adrianba I don't know. Would not shipping a partial implementation help? @glennjones
Ade Bateman
@tobie @glennjones We shipped a complete implementation of what was in the File API spec at the time (which only defined static members).
Ade Bateman
@tobie @glennjones IE10+ only supported the static methods on URL so there is no constructor. At the time what else could it do but throw?
Glenn Jones
@tobie @adrianba I don't known the history, but it does look like the URL object should not have been extended in this way, not a IE issue!
Ade Bateman
@glennjones @tobie It's complicated because I think things were proceeding in parallel. I actually don't think there is a problem here.
Tobie Langel
@adrianba I'm not blaming IE, btw. We just don't have a good story for these issues. @glennjones
Glenn Jones
@tobie just looking at URL and URLUtils the constructor of URL takes 2 arguments to resolve absolute URL, but the early IE version blows up
Tobie Langel
@adrianba agreed. Still, that makes it painful for devs. There must be a better way. @glennjones
Tobie Langel
@adrianba sounds like the @urlstandard should have taken that in account then. @glennjones
@tobie @adrianba @w3ctag its an issue with API design, developer expectations and documentation. Wrote post: http://bit.ly/1RkmWqP
‐ Also on:
Mentions:
Ade Bateman
@glennjones BTW, I expect IE11 to be around for a long time, but not IE10.
Robin Berjon
@glennjones Not wonderful, but you might be able to test window.URL.prototype.constructor.length or some such. @tobie @adrianba @w3ctag
Tobie Langel
@robinberjon I'm sure you meant window.URL.prototype.constructor.prototype.constructor.length. #bettersafethansorry @glennjones @adrianba

In reply to this conservation:
Glenn Jones
Find it a little sad some of the browser APIs are introduced in such an incomplete state the only way to use them is in try/catch blocks
Tobie Langel
@glennjones are these implementation issues or spec ones?
Glenn Jones
@tobie just looking at URL and URLUtils the constructor of URL takes 2 arguments to resolve absolute URL, but the early IE version blows up
Tobie Langel
@glennjones that's a tough one indeed. What else could IE do not to cause that issue? /cc @adrianba
Ade Bateman
@tobie @glennjones IE10+ only supported the static methods on URL so there is no constructor. At the time what else could it do but throw?
Tobie Langel
@adrianba agreed. Still, that makes it painful for devs. There must be a better way. @glennjones
Tobie Langel
@adrianba I don't know. Would not shipping a partial implementation help? @glennjones
Ade Bateman
@tobie @glennjones We shipped a complete implementation of what was in the File API spec at the time (which only defined static members).
Tobie Langel
@adrianba sounds like the @urlstandard should have taken that in account then. @glennjones
@tobie @adrianba I don't known the history, but it does look like the URL object should not have been extended in this way, not a IE issue!
‐ Also on:
Mentions:
Ade Bateman
@glennjones @tobie It's complicated because I think things were proceeding in parallel. I actually don't think there is a problem here.
Tobie Langel
@adrianba I'm not blaming IE, btw. We just don't have a good story for these issues. @glennjones
Glenn Jones
@tobie @adrianba @w3ctag its an issue with API design, developer expectations and documentation. Wrote post: http://bit.ly/1RkmWqP
Ade Bateman
@glennjones BTW, I expect IE11 to be around for a long time, but not IE10.
Tobie Langel
@adrianba well, according to @glennjones, there is: lots of try..catch wrapping in lieu of feature detection.
Robin Berjon
@glennjones Not wonderful, but you might be able to test window.URL.prototype.constructor.length or some such. @tobie @adrianba @w3ctag
Tobie Langel
@robinberjon I'm sure you meant window.URL.prototype.constructor.prototype.constructor.length. #bettersafethansorry @glennjones @adrianba

In reply to this conservation:
Glenn Jones
Find it a little sad some of the browser APIs are introduced in such an incomplete state the only way to use them is in try/catch blocks
Tobie Langel
@glennjones are these implementation issues or spec ones?
Glenn Jones
@tobie just looking at URL and URLUtils the constructor of URL takes 2 arguments to resolve absolute URL, but the early IE version blows up
Tobie Langel
@glennjones how to ship partial implementations that don't blow-up in devs' faces is something @w3ctag should help implementors with, imho.
@tobie @w3ctag its a hard problem, but when you start to see cross browser code examples like https://developer.mozilla.org/en-US/docs/Web/API/DOMParser… I do start to worry
‐ Also on:
Mentions:
Tobie Langel
@glennjones incidentally, that's why we need more tests. /cc @w3ctag

In reply to this conservation:
Glenn Jones
Find it a little sad some of the browser APIs are introduced in such an incomplete state the only way to use them is in try/catch blocks
Tobie Langel
@glennjones are these implementation issues or spec ones?
@tobie the examples for URL and URLUtils polyfills are having to use try/catch to get around this. Similar issues with DOMParser
‐ Also on:

In reply to this conservation:
Glenn Jones
Find it a little sad some of the browser APIs are introduced in such an incomplete state the only way to use them is in try/catch blocks
Tobie Langel
@glennjones are these implementation issues or spec ones?
@tobie just looking at URL and URLUtils the constructor of URL takes 2 arguments to resolve absolute URL, but the early IE version blows up
‐ Also on:
Mentions:
Tobie Langel
@glennjones that's a tough one indeed. What else could IE do not to cause that issue? /cc @adrianba
Tobie Langel
@adrianba agreed. Still, that makes it painful for devs. There must be a better way. @glennjones
Ade Bateman
Tobie Langel
@adrianba I don't know. Would not shipping a partial implementation help? @glennjones
Ade Bateman
@tobie @glennjones IE10+ only supported the static methods on URL so there is no constructor. At the time what else could it do but throw?
Tobie Langel
@adrianba sounds like the @urlstandard should have taken that in account then. @glennjones
Glenn Jones
@tobie @adrianba I don't known the history, but it does look like the URL object should not have been extended in this way, not a IE issue!
Ade Bateman
@glennjones @tobie It's complicated because I think things were proceeding in parallel. I actually don't think there is a problem here.
Tobie Langel
@adrianba well, according to @glennjones, there is: lots of try..catch wrapping in lieu of feature detection.
Tobie Langel
@adrianba I'm not blaming IE, btw. We just don't have a good story for these issues. @glennjones
Tobie Langel
@glennjones incidentally, that's why we need more tests. /cc @w3ctag
Glenn Jones
@tobie @adrianba @w3ctag its an issue with API design, developer expectations and documentation. Wrote post: http://bit.ly/1RkmWqP
Glenn Jones
@tobie @w3ctag its a hard problem, but when you start to see cross browser code examples like https://developer.mozilla.org/en-US/docs/Web/API/DOMParser… I do start to worry
Ade Bateman
@glennjones BTW, I expect IE11 to be around for a long time, but not IE10.
Tobie Langel
@glennjones how to ship partial implementations that don't blow-up in devs' faces is something @w3ctag should help implementors with, imho.
Robin Berjon
@glennjones Not wonderful, but you might be able to test window.URL.prototype.constructor.length or some such. @tobie @adrianba @w3ctag
Ade Bateman
@tobie @glennjones We shipped a complete implementation of what was in the File API spec at the time (which only defined static members).

Find it a little sad some of the browser APIs are introduced in such an incomplete state the only way to use them is in try/catch blocks
‐ Also on:
Mentions:
Tobie Langel
@glennjones are these implementation issues or spec ones?
Tobie Langel
@glennjones incidentally, that's why we need more tests. /cc @w3ctag
Ade Bateman
@tobie @glennjones IE10+ only supported the static methods on URL so there is no constructor. At the time what else could it do but throw?
Tobie Langel
@adrianba agreed. Still, that makes it painful for devs. There must be a better way. @glennjones
Glenn Jones
@tobie @w3ctag its a hard problem, but when you start to see cross browser code examples like https://developer.mozilla.org/en-US/docs/Web/API/DOMParser… I do start to worry
Tobie Langel
@adrianba I don't know. Would not shipping a partial implementation help? @glennjones
Ade Bateman
@tobie @glennjones We shipped a complete implementation of what was in the File API spec at the time (which only defined static members).
Tobie Langel
@adrianba sounds like the @urlstandard should have taken that in account then. @glennjones
Glenn Jones
@tobie @adrianba I don't known the history, but it does look like the URL object should not have been extended in this way, not a IE issue!
Ade Bateman
@glennjones @tobie It's complicated because I think things were proceeding in parallel. I actually don't think there is a problem here.
Tobie Langel
@glennjones how to ship partial implementations that don't blow-up in devs' faces is something @w3ctag should help implementors with, imho.
Tobie Langel
@adrianba well, according to @glennjones, there is: lots of try..catch wrapping in lieu of feature detection.
Tobie Langel
@glennjones that's a tough one indeed. What else could IE do not to cause that issue? /cc @adrianba
Tobie Langel
@adrianba I'm not blaming IE, btw. We just don't have a good story for these issues. @glennjones
Glenn Jones
@tobie the examples for URL and URLUtils polyfills are having to use try/catch to get around this. Similar issues with DOMParser
Glenn Jones
@tobie @adrianba @w3ctag its an issue with API design, developer expectations and documentation. Wrote post: http://bit.ly/1RkmWqP
Glenn Jones
@tobie just looking at URL and URLUtils the constructor of URL takes 2 arguments to resolve absolute URL, but the early IE version blows up
Ade Bateman
@glennjones BTW, I expect IE11 to be around for a long time, but not IE10.
Ade Bateman
















Data formats:

API