| 07:51 | <annevk> | MikeSmith: zcorpan: I mentioned the XSLT argument too, but I think the problem with that argument is that XSLT hasn't evolved at all and still does poorly at HTML serialization |
| 07:51 | <annevk> | MikeSmith: zcorpan: I believe there are several void elements it doesn't get right and such |
| 08:41 | <annevk> | zcorpan: belated happy b-day! |
| 08:41 | <zcorpan> | annevk: thank you |
| 09:21 | <zcorpan> | annevk: yeah, using this doctype is indicative that the tool used is bad at producing HTML. but people use them anyway, and there are non-XML tools that are also bad at producing HTML that are also used. |
| 09:45 | <MikeSmith> | annevk: zcorpan I could add a warning to the checker for documents with “about:legacy-compat” saying “Tools that aren’t capable of generating a docytpe without a system ID are likely to have other problems generating HTML output. Check your output carefully.” |
| 09:45 | <MikeSmith> | but in practice for users of that checker they are going to see that as an error message |
| 09:46 | <MikeSmith> | a message they want to make go away |
| 09:46 | <zcorpan> | they are using a checker so they are checking their output already |
| 09:46 | <MikeSmith> | true |
| 09:47 | <zcorpan> | if anything the message should be "consider switching to a different toolchain that doesn't suck" :-) |
| 09:47 | <zcorpan> | but i don't think that's helpful |
| 09:48 | <MikeSmith> | yeah |
| 09:48 | <MikeSmith> | but I guess that is not helpful to authors |
| 09:49 | <MikeSmith> | it hurts to keep paying the XML tax forever |
| 09:49 | <zcorpan> | we can make tools suck less by contributing with issues etc, and advocating using tools we think are good |
| 09:49 | <nox> | Do any of you have an opinion about XML5? |
| 09:50 | <zcorpan> | nox: what context? |
| 09:50 | <botie> | i heard context was https://github.com/validator/validator/issues/284 |
| 09:50 | <nox> | zcorpan: ALL OF THEM |
| 09:50 | <MikeSmith> | haha |
| 09:51 | <MikeSmith> | I like XML5 |
| 09:51 | <MikeSmith> | but maybe the window of opportunity has passed |
| 09:51 | <MikeSmith> | or the window of need |
| 09:51 | <nox> | Yeah I don't see anyone using it anytime soon but Servo. |
| 09:52 | <zcorpan> | i would much prefer browsers using XML5 over parsing XML with the HTML parser |
| 09:54 | <nox> | zcorpan: Do they do that? |
| 10:04 | <zcorpan> | nox: some do, but more back in the day. presto-Opera did also at the end in some cases (only to reparse if it wasn't well-formed XML) |
| 10:04 | <zcorpan> | nox: https://simon.html5.org/articles/mobile-results |
| 10:07 | <zcorpan> | good times |
| 10:12 | <zcorpan> | MikeSmith: is there an upstream/downstream process between validator/validator and w3c/web-platform-tests ? |
| 10:39 | <zcorpan> | oh validator/tests is a mirror. ok |
| 18:27 | <annevk> | http://lists.xml.org/archives/xml-dev/201611/msg00067.html |
| 18:46 | <annevk> | I'm somewhat surprised the major difference in boolean attributes isn't discussed |
| 18:47 | <annevk> | Also somewhat surprised we're discussing DTDs in 2016, but maybe given recent election results I shouldn't be |
| 18:48 | <eusid> | annevk: thinking about the election as a boolean hurts my brain |
| 18:53 | <Domenic> | Why can dictionary attributes not be nullable, I wonder? |
| 18:54 | <annevk> | Domenic: dictionary members can be nullable |
| 18:54 | <annevk> | Domenic: but the preference is that they're not, unless they can be fed by some object that has a property of the same name that is nullable for some reason |
| 18:54 | <Domenic> | annevk: yes, but you can't do interface Foo { attribute SomeDictionary? bar; } |
| 18:55 | <Domenic> | So people are inventing interfaces just to get around that restriction |
| 18:55 | <annevk> | Domenic: if we start returning plain objects from getters, why do we have FrozenArray? |
| 18:55 | <annevk> | Domenic: should just be Array then |
| 18:55 | <Domenic> | I agree, but some people like immutability |
| 18:55 | <annevk> | sigh |
| 18:56 | <Domenic> | So your argument is against dictionary attributes in general |
| 18:56 | <Domenic> | Also doesn't notifications do this |
| 18:56 | <annevk> | Now sicking has disappeared, maybe we can revisit the immutability argument? |
| 18:56 | <Domenic> | I guess just not nullable |
| 18:57 | <annevk> | Notification doesn't return dictionaries from a getter |
| 18:57 | <Domenic> | yeah just frozenarray<dictionary> |
| 18:57 | <Domenic> | which it freezes in prose |
| 18:57 | <annevk> | Oh right, that madness |
| 18:57 | <annevk> | I'm not a fan |
| 18:58 | <annevk> | If I had the power I'd remove FrozenArray and replace existing usage with sequence |
| 18:59 | <annevk> | As for nullable dictionary attributes, why would that be needed as opposed to returning {}? |
| 19:01 | <Domenic> | Is your payment address not set, or is it just a payment address with empty string country/region/city/etc.? The former seems better. |
| 19:02 | <annevk> | Fair |
| 19:03 | <Domenic> | But it seems like we want a PaymentAddress interface with lots of readonly fields, after all. |
| 19:39 | <TabAtkins> | annevk, tobie: The distinction y'all are looking for is the notion of "kinds" from type theory. Values are the lowest kind, types are the next highest (they can be instantiated to produce a value), and type constructors are the next highest after that (they can be instantiated to produce a type). The kind hierarchy is infinite, of course. |
| 19:39 | <TabAtkins> | If values are kind 1, types are kind 2, etc, then "dictionary" or "record" are kind-3 things. |
| 19:40 | <TabAtkins> | The IDL definitions types in Bikeshed are meant to capture kind-2 things. There's nothing official for kind-3, because there's no call for it, so they instead fall into the generic "dfn" bucket. |
| 19:42 | <TabAtkins> | Then you've also got the kind-2 things like "sequence<DOMString>". They're definitely kind-2, types, because when they're instantiated they produce values (an array of strings, in this case). |
| 19:44 | <TabAtkins> | They're just *anonymous* types, which aren't handled by the Bikeshed linking model. As far as I can tell, you don't really need it, either. You instead want to link to "sequence" (the kind-3 thing) and "DOMString" (the kind-2 thing). If you use typedef to give a name to it, tho, like "typedef sequence<DOMString> NameList;", then "NameList" is a kind-2 |
| 19:44 | <TabAtkins> | thing, a type, with a name that can be referred with Bikeshed's linking model. |
| 21:46 | <younder> | I am getting complaints frm devepers that webgl it has to transpile to javascript or avoid garbage colection. |
| 21:47 | <younder> | They don't like it |
| 21:47 | <younder> | What are you ogoing to do about it? |
| 22:23 | <TabAtkins> | I think we removed the "block inheritance" flag from shadow roots, right? |
| 22:26 | <gsnedders> | Philip`'s old canvas tests, regenerating them seems to produce different reference images depending on cairo version. Is this a problem? |
| 22:26 | gsnedders | wonders how they differ |
| 22:30 | <Philip`> | gsnedders: If it's just changes to antialiasing etc, then no |
| 22:31 | <Philip`> | The reference images weren't meant to precisely match the canvas output, just look close enough that a human could visually check if the browser was doing basically the right thing |
| 22:31 | <Philip`> | and to help debug test failures by seeing what was expected |
| 22:37 | <gsnedders> | Philip`: thx |
| 22:39 | <Philip`> | (But I could be wrong, I haven't worked on this stuff for like a decade) |
| 22:39 | <gsnedders> | Well, that's where you went wrong! :) |
| 22:52 | <Philip`> | I assumed the web was solved so there wasn't any need to continue working on it |
| 22:58 | <gsnedders> | turns out that assumption was wrong, unfortunately |