| 02:54 | <GPHemsley> | oh, here's a question... are validation errors ever used by anybody? |
| 02:54 | <GPHemsley> | by which I mean, do they have an effect on web compatibility or anything of that nature? |
| 03:29 | <GPHemsley> | I have a question about WebIDL and constructors... does an interface not have a constructor unless you explicitly say it does? how do you initialize an interface without a constructor? |
| 03:40 | <GPHemsley> | is it a matter of `Foo()` vs. `new Foo()`? |
| 03:41 | <GPHemsley> | I see the dependence on ECMAScript gets stronger the deeper you go |
| 10:28 | <profsimm> | Sorry for the silly question but what's the official opinion about why WHATWG calls it "URL" and not URI? |
| 10:43 | <tobie> | GPHemsley: interfaces don't have a constructor unless you specify one using the constructor extended attribute |
| 10:43 | <tobie> | GPHemsley: so calling both Foo() and new Foo() will throw a TypeError in that case |
| 10:46 | <tobie> | GPHemsley: see step 1.1 of the algorithm described in https://heycam.github.io/webidl/#interface-object |
| 10:46 | <Philip`> | profsimm: The distinction between URL/URI/IRI is not useful in practice and is confusing, and URL is the term that almost everyone in the world uses so it seemed best to standardise on that one |
| 10:47 | <profsimm> | Philip`: thanks |
| 10:47 | <Philip`> | profsimm: See e.g. https://url.spec.whatwg.org/#goals |
| 10:47 | <Philip`> | profsimm: (Also it's what I remember from discussions on the mailing lists like a decade ago) |
| 10:48 | <tobie> | GPHemsley: Note that as per step 1.2 of the same algorithm, Foo() (without the new constructor) throws in all cases. |
| 10:49 | <tobie> | GPHemsley: that is, even when a Constructor extended attribute is present. |
| 11:14 | <profsimm> | Philip`: is WHATWG the HTML spec which browsers follow most closely? |
| 11:14 | <profsimm> | Philip`: compared to W3C |
| 11:26 | <gsnedders> | profsimm: yes |
| 11:26 | <profsimm> | gsnedders: aren't browser makers involved in W3C as well? |
| 11:28 | <gsnedders> | profsimm: not with the HTML specification; it was merged into a larger WG to try and get them involved they haven't |
| 15:07 | <GPHemsley> | tobie: Thanks for clarifying. :) |
| 15:17 | <tobie> | GPHemsley: np. |
| 15:22 | <GPHemsley> | tobie: Do you know where the semantics of getters and setters are defined? Is that in WebIDL or ECMAScript or somewhere else? |
| 15:22 | <GPHemsley> | DOM, maybe? |
| 15:22 | <GPHemsley> | oh wait, I think I found them |
| 16:51 | <gsnedders> | GPHemsley: WebIDL and ES |
| 16:51 | <gsnedders> | GPHemsley: depending on what getters and setters you're talking about |
| 20:31 | <GPHemsley> | gsnedders: Ultimately, I just wanted to know if setters return the new value of the attribute, and it seems the answer is yes. |
| 20:37 | <gsnedders> | GPHemsley: that would be the normal ES behaviour, and I don't think it can be avoided |
| 20:44 | <GPHemsley> | gsnedders: I wasn't trying to avoid it, I was trying to replicate it. |
| 20:46 | <gsnedders> | GPHemsley: I just mean I think it falls from the definition of the = operator in ES |
| 20:46 | <GPHemsley> | well I'm not implementing ES, and some things take ES behavior for granted |
| 20:46 | <GPHemsley> | so I was just trying to approximate |