| 00:51 | <SamB> | and they tell me that HTML email is totally unstandardized |
| 01:19 | <SamB> | so, I can have an <xmlns:foo> element, but only if I use the right namespace URL? |
| 01:20 | <SamB> | http://dom.spec.whatwg.org/#dom-document-createelementns |
| 04:27 | <roc> | I think this insistence that WebIDL be no more expressive than JS has gone much too far |
| 04:29 | <MikeSmith> | roc: people are really advocating for that? |
| 04:29 | <MikeSmith> | on script-coord? or somewhere else? |
| 04:29 | MikeSmith | is way behind on e-mail |
| 04:30 | <roc> | that is my impression from public-script-coord, though to be fair it's mostly Domenic Denicola |
| 04:34 | <MikeSmith> | roc: yeah I'm reading up on that thread now. Wonder what slightlyoff's take on this is |
| 04:36 | <caitp> | *reads thread* |
| 04:37 | <caitp> | would those interfaces need to be exposed to JS at all? I thought that's what NoInterfaceObject was mostly used for |
| 04:46 | <roc> | Domenic seems to insist that there be one WebIDL interface per implementation class. |
| 04:49 | <caitp> | I can see his point, it would be potentially be helpful for users, and would also probably be helpful for the whole "implement the platform in JS" push |
| 04:49 | <caitp> | but I dunno :> |
| 06:39 | <annevk_> | roc: a large part of ES6 was to make ES as expressible as DOM |
| 08:32 | <annevk> | I realized over the weekend the asFormData thread was slightly silly, as for FormData parsing you need to extract the MIME type in order to get the boundary |
| 08:32 | <annevk> | Nobody on the list noticed that however |
| 10:09 | annevk | filed http://www.rfc-editor.org/errata_search.php?rfc=2388&eid=4030 |
| 10:47 | annevk | revives http://wiki.whatwg.org/wiki/FormData |
| 11:00 | annevk | filed http://www.rfc-editor.org/errata_search.php?rfc=7231&eid=4031 |
| 11:10 | <annevk> | Domenic: fetching itself requires teeing as well |
| 11:10 | <annevk> | Domenic: e.g. POST a stream to X, now X replies with a redirect to Y. The platform expects both X and Y to get the stream |
| 11:12 | <annevk> | I should probably spell that out in http://fetch.spec.whatwg.org/#http-network-or-cache-fetch rather than say "Let HTTPRequest be a copy of request." which does not really work for streams (well, copy is not immediately clear) |
| 11:12 | <MikeSmith> | annevk: I think Larry would be happy if you filed issues at https://github.com/masinter/multipart-form-data/issues too |
| 11:13 | <MikeSmith> | annevk: oh, the first one at least |
| 11:13 | <MikeSmith> | not the http one |
| 11:15 | <annevk> | Is that actually moving? |
| 11:16 | <annevk> | Seems the boundary comment is already captured there by a comment from Alexey |
| 11:36 | <MikeSmith> | annevk: dunno if it's moving or not but I know Larry would for people to at least read what he's got there and comment |
| 11:44 | <annevk> | I'm sort of surprised it is not done yet, this should not be hard |
| 11:44 | annevk | points himself to topic |
| 11:45 | <annevk> | Hixie: your echo tool is great btw |
| 11:45 | <annevk> | Hixie: that hex viewer :-) |
| 13:14 | <annevk> | Domenic: either way "When an Advisory Board or TAG participant changes affiliations, as long as Advisory Board and TAG participation constraints are respected, the individual MAY continue to participate until the next regularly scheduled election for that group." applies |
| 13:40 | <annevk> | Refactoring XMLHttpRequest in terms of Fetch <3 |
| 14:14 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23646#c24 lol |
| 14:20 | <annevk> | Hixie: how much positive reactions have you gotten to the "domintro" boxes? So far all they have caused is confusion in bug reports I got |
| 14:20 | <annevk> | Hixie: in particular implementers citing them causes concern |
| 14:25 | <Domenic> | What's a domintro box |
| 14:36 | <annevk> | http://xhr.spec.whatwg.org/#the-open%28%29-method the green box that says "Note" |
| 14:45 | <Domenic> | Oh. So before those were green but didn't have the little box, right? |
| 14:45 | <Domenic> | I much prefer the explicit call-outs myself. |
| 14:51 | <jgraham> | Maybe it should say "non normative note" |
| 14:52 | <annevk> | Domenic: well yes, that it says "Note" is great, I'm just wondering if there's value versus having people just read the algorithms |
| 14:52 | <annevk> | Domenic: and leaving "domintro" material to MDN |
| 14:52 | <Domenic> | annevk: ah, for them existing at all, you mean. |
| 14:53 | <annevk> | Yes, given that people get confused and most developers don't seem to read specifications |
| 14:53 | <Domenic> | Oh, and not just notes generally, but the "intro" notes describing each method. |
| 14:53 | <jgraham> | annevk: Being able to get a rough idea of what a method is supposed to do seems valuable. Not least to people writing MDN |
| 14:54 | <annevk> | Domenic: notes generally still have value I think |
| 14:54 | <Domenic> | I agree that they can be a bit problematic. I think I would prefer making them more vague, i.e. one- or two-sentence prose descriptions instead of things that link to defined terms, and specify all the error conditions |
| 14:55 | <annevk> | That might work |
| 14:55 | <annevk> | Trying to be accurate is indeed not paying off |
| 14:55 | <annevk> | Oh shit, back later |
| 14:55 | <Domenic> | So e.g. "mutates the state of the XMLHttpRequest object according to the passed values, setting it up for a future call to send()" (just off the top of my head) |
| 15:14 | <MikeSmith> | we should have an implementor view of the spec that omits all of the non-normative parts |
| 15:15 | <MikeSmith> | basically, just the class=impl parts |
| 15:15 | <jgraham> | MikeSmith: The other notes are really helpful when implementing |
| 15:15 | <jgraham> | Because they often state non-obvious things that should be invariants |
| 15:15 | <jgraham> | Or similar |
| 15:16 | <MikeSmith> | jgraham: So we need class="impl note" |
| 16:03 | <Domenic> | In ES specs/streams spec we do "Assert: <invariant must hold>" as part of the spec steps |
| 16:12 | <jgraham> | Domenic: Not just asserts though. e.g. the parser spec has things like (paraphrasing) "although this attribute is removed and never used in the tree, it is still the /currentAttribute/" |
| 16:13 | <jgraham> | Which is already normatively specified, but makes it clear that the behaviour in the normative parts is intentional |
| 16:17 | <Domenic> | Yeah, fair. |
| 16:32 | <gsnedders> | Also last I knew Hixie wasn't confident of the "fragment case" notes being correct, and thought there might also be other cases not so denoted. |
| 16:36 | <Hixie> | yeah the fragment case stuff is out of date, i'm pretty sure. i really should just strip those annotations. |
| 16:36 | <Hixie> | annevk: before i added domintro boxes i got a regular stream of people saying the spec was inpenetrable for authors, because nothing said how to use APIs |
| 16:36 | <Hixie> | annevk: since adding them, i've gotten no such feedback, but i do occasionally get confused implementors |
| 16:37 | <Hixie> | annevk: mostly new implementors who can't tell that they're non-normative and have no requirements, though |
| 16:40 | <SamB> | I think you should get some cute "caution" signs |
| 16:40 | <Hixie> | the "Note" labels aren't cute enough? |
| 16:40 | <Hixie> | we used to explicitly label them "These are not normative, the requirements are below", but I think the "Note" conveys the same meaning |
| 16:41 | <SamB> | I meant for particular (classes) that you suspect of being stale |
| 16:41 | <Hixie> | ? |
| 16:42 | <Hixie> | MikeSmith: we actually do have class="impl note" in some places, fwiw |
| 16:42 | <Hixie> | e.g. any note in the parser section |
| 16:44 | <SamB> | Hixie: oh, btw, how in the world am I supposed to fix crossrefs in the multipage edition without a copy of the buildsystem ;-P |
| 16:45 | <Hixie> | i'm going to fix those shortly |
| 16:45 | <Hixie> | i'm redoing my build system |
| 16:45 | <Hixie> | the multipage splitter is in github, though, fwiw |
| 16:45 | <Hixie> | the current one, i mean |
| 16:45 | <SamB> | hmm |
| 16:45 | <Hixie> | it's not part of the spec generator per se |
| 16:45 | <SamB> | see, this is why you should have a README in the repo |
| 16:45 | <Hixie> | *shrug* |
| 16:46 | <Hixie> | i wouldn't have thought to put that in there :-) |
| 16:46 | <SamB> | well, yes, that's why I'm telling you now |
| 16:46 | <Hixie> | the only thing i'd think to put in such a README is "stop forking the spec" |
| 16:46 | <Hixie> | and the w3c would ignore it anyway |
| 16:48 | <SamB> | it'd go like this "My current spec generator is awful, so I'm writing a new one at <...>. Code to split this into multiple pages is at <...>, and some of the images, scripts, and stylesheets are in the repo at <...>. |
| 16:48 | <SamB> | oops forgot the closing quote |
| 16:49 | <Hixie> | that would just make it even easier for the w3c to fork it |
| 16:49 | <Hixie> | which is an antigoal |
| 16:49 | <SamB> | they don't use your style though |
| 16:49 | <SamB> | or logos |
| 16:50 | <Hixie> | they use the rest |
| 16:50 | <Hixie> | they even use some of the styles |
| 16:50 | <SamB> | hmm |
| 16:50 | <SamB> | I don't see that making it easier for the W3C to fork it is actually going to make anything worse; they *already* forked it. |
| 16:51 | <Hixie> | it's an ongoing thing |
| 16:51 | <Hixie> | they copy all our patches too |
| 16:51 | <Hixie> | well, most of them |
| 16:51 | <SamB> | What license are you using for the text again? |
| 16:51 | <Hixie> | (if it was just all of them and tehy didn't make any additional changes, it would be fine) |
| 16:51 | <Hixie> | SamB: "You are granted a license to use, reproduce and create derivative works of this document" |
| 16:51 | <Domenic> | did you see this reply: https://twitter.com/stevefaulkner/status/483600468011393025 |
| 16:52 | <SamB> | Hixie: yeah, if it was all of them that'd not really be what you call a fork |
| 16:52 | <SamB> | Hixie: maybe switch to one requiring retention of copyright statements ;-P |
| 16:53 | <SamB> | like the Expat license |
| 16:53 | <Hixie> | SamB: i'm very close to just changing the license to disallow forking entirely |
| 16:53 | <Hixie> | SamB: i'm right on the knife edge of not being sure which is more important, the freedom for specs to be reusable, or the damage the w3c is causing with their fork |
| 16:53 | <SamB> | Hixie: what, you gonna go all LPPL on them? |
| 16:53 | <SamB> | or Knuth? |
| 16:53 | <SamB> | like "you must not call this HTML if you fork it" |
| 16:53 | <SamB> | "no, you can't just add a 5" |
| 16:54 | <Hixie> | i was thinking more the w3c documentation license with "w3c" replaced with "whatwg", for extra irony |
| 16:55 | <SamB> | hmm, I'd really prefer if you'd try some other Free Software licenses before you do something like that |
| 16:55 | <Domenic> | Hixie: this feels like a very movie-esque situation... I think I have to chime in and say "don't do it! That's what separates *us* from *them*!" |
| 16:57 | <SamB> | I'd just start with "Copyright 200x--20xx whatwg.org" |
| 16:58 | <Hixie> | Domenic: yeah, that's why i haven't done it |
| 16:58 | <SamB> | then go on to give the text of the Expat license, which would forbid the W3C from removing the first bit |
| 16:58 | <Hixie> | SamB: there's plenty of licenses like that. I'd just use the MIT license if that was my goal. |
| 16:58 | <Hixie> | SamB: however, having them put our copyright on their spec isn't the goal |
| 16:58 | <SamB> | expat license IS an MIT license |
| 16:58 | <SamB> | http://www.jclark.com/xml/copying.txt |
| 16:58 | <Domenic> | SamB: the relevant portion is not whether they include some kind of credit (they already do), but whether they modify it. Thus the W3C document license's "No right to create modifications or derivatives of W3C documents is granted pursuant to this license." |
| 16:59 | <SamB> | hmm, so, maybe use something like the LGPL then |
| 16:59 | <Domenic> | LGPL software can't be forked? Weird. |
| 16:59 | <SamB> | it can |
| 16:59 | <Domenic> | Well then it's not suitable. |
| 16:59 | <SamB> | but I think you're technically supposed to document the changes |
| 17:00 | <Hixie> | SamB: they do "document" the changes |
| 17:00 | <Hixie> | i mean, they do a pathetic job of it, but they at least try |
| 17:00 | <Hixie> | the problem isn't that |
| 17:00 | <Hixie> | the problem is that there are changes at all |
| 17:00 | <SamB> | also they'd be required to pass on the permission to all recipients |
| 17:01 | <jgraham> | The level of problem here is not worth the cost of adopting a restrictive license |
| 17:01 | <jgraham> | Not least because you would automatically lose any argument in favour of permissive licenses in the future |
| 17:02 | <Hixie> | yup |
| 17:02 | <Hixie> | jgraham: is there some way to force pms to sort attributes? or if they're always sorted, what order are they sorted in? |
| 17:03 | Hixie | crosses his fingers and repeats "please don't say python hash order please don't say python hash order" |
| 17:03 | <SamB> | well, the LGPL isn't viral to the extent that the GPL is |
| 17:03 | <Hixie> | realistically, the license isn't changing |
| 17:03 | <jgraham> | Hixie: It is possible to make html5lib do it. I don't remember if that's exposed anywehre though |
| 17:04 | <Hixie> | jgraham: any chance i could get you to make pms do it briefly? i'm trying to ensure my output matches pms', so that i know i haven't broken anything |
| 17:06 | <SamB> | Hixie: wouldn't *any* sort of copyleft make things tricky for the W3C fork, though? |
| 17:06 | <Hixie> | this is probably their most important spec, "tricky" won't stop them |
| 17:06 | <Hixie> | and it has much bigger disadvantages |
| 17:06 | <Hixie> | e.g. can't reuse in mozilla comments |
| 17:06 | <SamB> | hmm |
| 17:07 | <SamB> | so would any sort of licensing scheme with an |MPL be a pointless exercise here? |
| 17:08 | <SamB> | what does the MPL let you get away with? |
| 17:09 | <Hixie> | MPL is more or less the sme as what we have now |
| 17:09 | <jgraham> | Hixie: Try now, but I'm not sure I did anything useful |
| 17:09 | <MikeSmith> | Hixie: about class="impl note", I'm reminde that you're always way ahead of me |
| 17:11 | <Hixie> | jgraham: thanks, trying now |
| 17:22 | <SamB> | hmm, well, #debian-devel thinks you should use one of those anyway just to make sure you're actually granting all the rights you think you're granting ;-) |
| 17:22 | <SamB> | er, sorry, was scrolled up |
| 17:22 | <SamB> | s/one of those/MIT licenses/ |
| 17:23 | <SamB> | er. |
| 17:23 | <SamB> | grammatified better |
| 17:23 | <Hixie> | yeah, we should. but changing the license is harder than it appears, so unless someone has an actual problem, we won't. |
| 17:23 | <Hixie> | clearly the w3c is sure we're granting them. |
| 17:26 | <Hixie> | jgraham: that changed nothing :-( |
| 17:31 | <jgraham> | Hixie: Oh, sorry. Got to run now but I will try again later / tomorrow |
| 17:33 | <Hixie> | jgraham: k |
| 17:33 | <Hixie> | jgraham: thanks for trying! |
| 18:47 | <SamB> | Hixie: oh, btw, those links that point at, like, the previous sentence are kind of annoying |
| 18:49 | <SamB> | Hixie: and will your new tool link to the actual *definitions* imported from other specs? |
| 19:23 | <mounir> | Domenic, abarth: ping |
| 19:28 | <abarth> | mounir: hi |
| 19:28 | <mounir> | abarth: I thought it could be great to have a quick discussion about the screen.orientation issue |
| 19:28 | <abarth> | mounir: I commented on the github bug thread |
| 19:28 | <abarth> | yeah |
| 19:28 | <mounir> | abarth: I saw that |
| 19:28 | <abarth> | there's some sort of crazy going on |
| 19:29 | <mounir> | abarth: what would you prefer? |
| 19:29 | <abarth> | i'd just leave it as an normal interface |
| 19:30 | <abarth> | instead of hacking around to try to making it into a dictionary |
| 19:30 | <mounir> | abarth: and you would pass that interface when resolving the promise? |
| 19:31 | <abarth> | i'm not sure I understand the connection to promises |
| 19:31 | <abarth> | but sure, you can pass an interface to a promise |
| 19:31 | <mounir> | screen.lockOrientation().then(function(o) {}) |
| 19:31 | <abarth> | that's how everything else in the platform works |
| 19:31 | <abarth> | sure |
| 19:31 | <mounir> | o is the orientation at the time of the lock being applied |
| 19:31 | <mounir> | it has to be "frozen" |
| 19:32 | <abarth> | you don't mean frozen in the ECMAScript sense |
| 19:32 | <abarth> | you just mean 'not live' |
| 19:32 | <abarth> | sure |
| 19:32 | <mounir> | abarth: yes, thus the quotes |
| 19:32 | <mounir> | having a live and not live version sounded dirty |
| 19:32 | <mounir> | and I didn't really know what to do |
| 19:32 | <abarth> | why? |
| 19:33 | <abarth> | that's how everything works |
| 19:33 | <mounir> | Domenic's proposal sounded a cleaner way to solve the problem |
| 19:33 | <abarth> | except that it doesn't work |
| 19:33 | <mounir> | abarth: there isn't that many frozen/live objects |
| 19:33 | <abarth> | you can't even express it in IDL |
| 19:33 | <mounir> | abarth: except crazy things like NodeList, maybe |
| 19:33 | <abarth> | window.location |
| 19:33 | <abarth> | window.document |
| 19:33 | <abarth> | |document| is live |
| 19:34 | <abarth> | but if you make your own element |
| 19:34 | <abarth> | and hold onto it |
| 19:34 | <abarth> | it's "not live" |
| 19:35 | <abarth> | the reason screen.orientation is "live" is because the platform keep mutating it |
| 19:35 | <abarth> | the version it gives you via lockOrientation is "no live" because the platform just doesn't mutate it |
| 19:35 | <mounir> | abarth: I understand that |
| 19:36 | <mounir> | abarth: I'm not really convinced that it is nicer that Domenic's opinion |
| 19:36 | <mounir> | s/opinion/proposal/ |
| 19:36 | <abarth> | dominic's proposal doesn't work |
| 19:36 | <abarth> | and is different from every other thing in the platform |
| 19:36 | <abarth> | is there any problem with the proposal above that needs to be solved? |
| 19:37 | <mounir> | why it doesn't work? |
| 19:37 | <mounir> | because it's not expressable in WebIDL? |
| 19:38 | <mounir> | fwiw, doing s/dictionary/object/ and it becomes fine wrt WebIDL |
| 19:39 | <abarth> | maybe the "not working" part is specific to the CL you wrote |
| 19:39 | <abarth> | but the CL you wrote is a security vulnerability |
| 19:39 | <mounir> | how so? |
| 19:40 | <mounir> | because it's using custom bindings? |
| 19:42 | <mounir> | abarth: my understanding is that I can't return an arbitrary object using the bindings in Blink, if that's not right, I can change the CL |
| 19:43 | <abarth> | Chasing down the details, I see that I'm mistaken about it being a security vulnerability |
| 19:43 | <abarth> | here's a strange behavior that you've got through: |
| 19:43 | <abarth> | var x = screen.orientation; |
| 19:43 | <abarth> | x.foo = "bar"; |
| 19:43 | <mounir> | abarth: anyhow, I want to make sure we have an agreement on the API - if the implementation needs fixing, that's orthogonal |
| 19:43 | <abarth> | ... time passes .. |
| 19:43 | <abarth> | alert(screen.orientation.foo == "bar") |
| 19:43 | <abarth> | does that alert |true| or |false| ? |
| 19:44 | <mounir> | abarth: might be true but screen.orientation should be read-only |
| 19:45 | <mounir> | abarth: I should probably fix that |
| 19:45 | <mounir> | (i was actually thinking about that during diner...) |
| 19:45 | <abarth> | making screen.orientation readonly doesn't solve this problem |
| 19:45 | <abarth> | the problem is that you're creating new objects from time to time |
| 19:45 | <abarth> | which means you lose all the expandos |
| 19:46 | <abarth> | In any case, I still haven't heard a problem with implementing this feature the normal way |
| 19:47 | <abarth> | if there's no problem to solve, I'd strongly prefer for this feature to behave in the same way as every other API in the plaform |
| 19:48 | <mounir> | abarth: I was going to go the "normal way", as you can see, the spec was going that way and only needed to add the frozen definition |
| 19:48 | <mounir> | abarth: Domenic pointed that other solution that looked reasonable |
| 19:49 | <abarth> | when you get into the details, they look less reasonable |
| 19:50 | <mounir> | abarth: sure |
| 19:50 | <mounir> | abarth: I don't have any strong opinion but I would like to hear from Domenic before going the other way |
| 19:51 | <mounir> | (ahah, that previous sentence is terrible...) |
| 19:53 | <annevk> | Hixie: is there any advantage of class=domintro over class=note then? Maybe we should have class=intro and just label them "Introduction"? |
| 20:07 | <annevk> | mounir: what abarth is saying is that you need to define the lifetime of the object you return |
| 20:07 | <annevk> | mounir: or its GC policy |
| 20:07 | <annevk> | mounir: but you need to do that either way |
| 20:07 | <mounir> | annevk: I understood that |
| 20:07 | <annevk> | mounir: so I don't really see the problem, seems like it could just be the lifetime of the screen object |
| 20:08 | <abarth> | annevk: my point is that we're creating all these problems and complex spec and implementation to solve a non-problem |
| 20:08 | <mounir> | annevk: and we will get many objects lying around for no reason? |
| 20:08 | <abarth> | annevk: instead, we could just use the normal spec for readonly attributes in WebIDL and return a normal interface object |
| 20:09 | <annevk> | abarth: that Chrome is wonky when it comes to dealing with JavaScript shouldn't really influence API design I think |
| 20:09 | <SamB> | annevk: any idea why this says what it does about "xmlns" <http://dom.spec.whatwg.org/#dom-document-createelementns>;? I'm not familiar with any xmlns elements |
| 20:09 | <abarth> | annevk: I didn't say that |
| 20:09 | <abarth> | annevk: I said this API should work the same way as every other API in the platform |
| 20:10 | <abarth> | annevk: no one has advanced any reason why doing things the normal way is a problem |
| 20:10 | <annevk> | Our "the normal way" is alien to many web developers |
| 20:10 | <annevk> | And JavaScript as a language |
| 20:11 | <annevk> | SamB: legacy XML cruft |
| 20:11 | <SamB> | annevk: because it SOUNDS like stuff that has more to do with attributes |
| 20:12 | <abarth> | annevk: can you show me some code that would be written by a web developer that would be materially better using this alternative approach? |
| 20:14 | <annevk> | abarth: if you're not convinced by the premise that the platform is a library written on top of JavaScript I recommend talking to slightlyoff et al |
| 20:14 | <abarth> | annevk: The normal way of implementing this works fine in JavaScript |
| 20:14 | <annevk> | abarth: or e.g. dglazkov if that's closer |
| 20:15 | <abarth> | annevk: there's nothing "non javascripty" about the normal way here |
| 20:15 | <abarth> | annevk: so, you don't have a concrete problem with the normal approach either |
| 20:15 | <annevk> | abarth: yes there is, the normal way has a non-constructable class |
| 20:15 | <Hixie> | SamB: i hope so, eventually |
| 20:15 | <abarth> | so, make the class constructable |
| 20:15 | <Hixie> | annevk: domintro vs note is mostly a historical thing now |
| 20:15 | <annevk> | abarth: if you write some JavaScript, the normal way to return some properties is just returning an object |
| 20:16 | <abarth> | the only difference here is (1) the prototype and (2) the toString value |
| 20:16 | <Hixie> | "if you're not convinced by the premise that the platform is a library written on top of JavaScript I recommend talking to slightlyoff et al" <- i have, still not convinced |
| 20:16 | <annevk> | abarth: people care about us not using data properties too, these things matter to some people |
| 20:16 | <abarth> | annevk: so, do you have any code that would be made better? |
| 20:16 | <abarth> | it sounds like the answer is "no" |
| 20:17 | <SamB> | if it's written in JavaScript, remind me what all that C++ code is for |
| 20:18 | <annevk> | abarth: I don't think this is helping |
| 20:18 | <abarth> | ok :) |
| 20:19 | <Hixie> | "Our "the normal way" is alien to many web developers" <- the JS way is alien to at least as many developers |
| 20:19 | <abarth> | Hixie: it's all about who you pick as "JS" developers |
| 20:20 | <Hixie> | exactly |
| 20:20 | <abarth> | the true scottsmen who will arbitrate |
| 20:20 | <Hixie> | yeah |
| 20:21 | <annevk> | abarth: it does seem to me that just like we think XML is cruft, returning an object that has a prototype and various bits IDL adds over a normal object can also be seen as such |
| 20:21 | <annevk> | abarth: but I'm not the one you need to convince here |
| 20:22 | <Hixie> | (for the record i've no idea what y'all are actually talking about, concretely) |
| 20:22 | <abarth> | Hixie: it's has to do with what screen.orientation returns |
| 20:22 | <abarth> | should its prototype be Object.prototype |
| 20:23 | <abarth> | should it change identity when the orientation changes |
| 20:23 | <Hixie> | shouldn't it just be a string... |
| 20:23 | <abarth> | it has two fields |
| 20:24 | <abarth> | angle and type |
| 20:24 | <MikeSmith> | Hixie: from where is the quote "if you're not convinced by the premise that the platform is a library written on top of JavaScript I recommend talking to slightlyoff"? |
| 20:24 | <Hixie> | MikeSmith: slightly earlier in the annevk/abarth conversation |
| 20:25 | <MikeSmith> | Hixie: ah ok |
| 20:25 | MikeSmith | is just reading scrollback now |
| 20:25 | <abarth> | Hixie: but yes, you could explode them onto Screen if you wanted |
| 20:26 | <Hixie> | abarth: imho should probably return an interface ScreenOrientation { readonly attribute SomeEnum firstField; readonly attribute SomeOtherEnum secondField; } |
| 20:26 | <Hixie> | abarth: what else would it return? |
| 20:26 | <abarth> | that's my perspective |
| 20:26 | <Hixie> | lgtm, ship it |
| 20:27 | <abarth> | that's alien to "JS" developers |
| 20:27 | <abarth> | instead, they want exactly the same thing, except the prototype is set to Object.prototype and the toString returns "[Object object]" |
| 20:28 | <Hixie> | that's alien to Web developers |
| 20:28 | <SamB> | abarth: why do they have to care about that |
| 20:28 | <Hixie> | what Web devs want is that rare that the Web has done consistently for decades |
| 20:28 | <SamB> | isn't Object.prototype in the chain anyway |
| 20:28 | <Hixie> | that sentence got garbled |
| 20:28 | <abarth> | SamB: that's my argument. no code is made better by returning that sort of object instead |
| 20:28 | <Hixie> | what Web devs want is that rare thing, a think the Web has done consistently for decades. namely, the interface thing. |
| 20:29 | <Hixie> | thing. not think. |
| 20:29 | <Hixie> | i'm gonna go elsewhere now. |
| 20:29 | <SamB> | Hixie: hehehe |
| 20:29 | <SamB> | it sounded senseful to me, if slightly garbled |
| 20:30 | <SamB> | (can't you do that in JavaScript too though?) |
| 20:32 | <Hixie> | do what in JS? |
| 20:32 | <Hixie> | return a host object? |
| 20:33 | <SamB> | you can only do that whole interface thing for host objects? |
| 20:35 | <Hixie> | "interface" basically means "host object" |
| 20:35 | <Hixie> | i mean it's more complicated than that |
| 20:35 | <Hixie> | but what abarth and i are saying is that the api should return a host object |
| 20:35 | <Hixie> | not an Object |
| 20:36 | <SamB> | yeah, I know; I guess I'm just underestimating the extent to which host objects are magical ... |
| 20:36 | <Hixie> | they're not really magical at all |
| 20:36 | <Hixie> | well, Window is |
| 20:36 | <SamB> | s/magical/special/ ? |
| 20:37 | <Hixie> | they're not really special either, there's more types of host objects than there are types of Object |
| 20:37 | <Hixie> | they're just objects implemented by the browser |
| 20:37 | <SamB> | where by special I mean different from things one can do in JavaScript code |
| 20:38 | <Hixie> | well obviously author code can't create objects implemented by not-author code |
| 20:38 | <SamB> | well, yes, that part is clear |
| 20:56 | <odinho> | I think they want to implement as many browser features as possible in javascript these days. And that might be part of the reason host objects seem to breaking their stride. Not having to go out from JIT or somesuch. |
| 20:57 | <odinho> | In case someone is following along at home and didn't already know. |
| 21:03 | <SamB> | odinho: which "they"? |
| 21:04 | <SamB> | Chrome's chrome doesn't seem to be in JS ... |
| 21:12 | <mounir> | Domenic: yt? |
| 21:14 | <Domenic> | mounir: ya back |
| 21:15 | <mounir> | Domenic: i replied in the GH issue |
| 21:15 | <mounir> | Domenic: this thing is a bit frustrating :) |
| 21:17 | <Domenic> | mounir: yeah, sorry... |
| 21:17 | <mounir> | Domenic: not your fault, mostly a tz problem |
| 21:17 | <mounir> | Domenic: I sud |
| 21:17 | <mounir> | I used to do non-office hours, it's hard to handle tz while doing office hours |
| 23:19 | <JonathanNeal> | If an article displays comments for individual paragraphs, what does that markup look like? Is there a definitive element to use for the comments, like <blockquote> or <aside>? <p>Content</p><x>Comment</x>. |
| 23:20 | <Hixie> | <article> is the definitive element for comments |
| 23:20 | <Hixie> | assuming you mean reader comments |
| 23:20 | <SamB> | that's kind of dumb, since it's not really the same thing as a comment ... |
| 23:20 | <Hixie> | it really is |
| 23:20 | <Hixie> | see the spec |
| 23:20 | <SamB> | I've seen the spec! |
| 23:21 | <Hixie> | there's no difference between a person's comment, and a person's article, other than the writer of the article thinking they're special |
| 23:21 | <Hixie> | (this is demonstrated really effectively by reddit) |
| 23:21 | <SamB> | reddit has articles? |
| 23:21 | <Hixie> | exactly. |
| 23:21 | <SamB> | I thought that thing was just the first comment |
| 23:21 | <Hixie> | there is no difference. |
| 23:22 | <zewt> | depends entirely on the site |
| 23:22 | <Hixie> | only superficially |
| 23:22 | <SamB> | maybe what I really mean is there ought to mark up what is being replied to ... |
| 23:22 | <zewt> | comments are very different on stackoverflow (but stackoverflow's comment system is completely worthless and not really a good example) |
| 23:22 | <SamB> | if anything |
| 23:22 | <SamB> | indeed, SO comments are totally not deserving of <article> |
| 23:22 | <Hixie> | zewt: stackoverflow's structure maps to <article> very well also |
| 23:23 | <zewt> | i have no idea what the point of "<article>" is in the first place (but I'm usually in the "mostly divs" camp) |
| 23:23 | <Hixie> | SamB: it is marked up. it's whatever the parent <article> is. |
| 23:23 | <SamB> | Hixie: that doesn't distinguish replies from quotations! |
| 23:23 | <Hixie> | the point of <article> (and all the other "block-level" elements) is to kill divs :-) |
| 23:23 | <Hixie> | SamB: quotations are marked up with <blockquote> |
| 23:24 | <Hixie> | not <article> |
| 23:24 | <SamB> | what if you repost a whole article in your article? |
| 23:24 | <Hixie> | then you put it in <blockquote> |
| 23:25 | <JonathanNeal> | I follow. If one paragraph has a few, ordered comments, are those comments then grouped by a <section>? |
| 23:26 | <Hixie> | yeah, or aside, probably |
| 23:26 | <Hixie> | (section is probably better than aside) |
| 23:26 | <JonathanNeal> | As opposed to, say, <ol><li><article/><li><article/></ol> |
| 23:27 | <JonathanNeal> | That feels all kinds of wrong to me, but I don’t know the spec well enough to justify the feeling. |
| 23:27 | <Hixie> | i personally wouldn't consider it a list in the <ol> sense, but some people would advocate for that and i wouldn't say they're wrong |
| 23:30 | <JonathanNeal> | My feeling is: Not everything that is ordered is a list. Any article can be made of paragraphs dispalyed in a certain order. To be a list, that requires intent to absorb the list items as connected to each other. |
| 23:31 | <JonathanNeal> | So, <section><article/><article/></section> is okay because an article “could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment”. Thanks! |
| 23:31 | Hixie | nods |
| 23:31 | <Hixie> | yeah that's why i wouldn't put it in a list either |
| 23:32 | <SamB> | Hixie: the other problem I have with the "nest them" idea is that I normally think of the comments as coming *after* the article they comment on ... |
| 23:33 | <Hixie> | you can put them anywhere you want, before, middle (like JonathanNeal is saying), after, on a different page, whatever you want |
| 23:34 | <SamB> | hmm, screw it, lets just use an mbox ;-P |