| 00:24 | <tantek> | Hixie, obligatory reference to xkcd.com/927 |
| 00:32 | <MikeSmith> | embind looks fairly cool http://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/embind.html |
| 00:34 | <MikeSmith> | now you can do manual memory management in JavaScript! http://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/embind.html#memory-management |
| 00:37 | <tantek> | yo dawg we heard you like memory management |
| 00:38 | <caitp> | are we still talking about llvm IC converted to js, or is emscripten doing something else now? |
| 00:40 | <caitp> | (it's pretty cool either way, i'm just not understanding how emscripten is providing bindings between js and C++ now if it runs entirely in a JS sandbox) |
| 01:06 | <Hixie> | tantek: these aren't competing standards, these are the same standard, forked multiple times by one organisation |
| 01:10 | <tantek> | Hixie s/competing/confusing |
| 04:45 | <zcorpan> | Hixie: what are the html5 spec URLs? i can send a PR to fix them |
| 05:21 | <Hixie> | zcorpan: if you mean in the caniuse.com data, there's a number of things we could ask to have changed, e.g. most of the things that use TR/ drafts could point to more recent actively maintained versions, the whatwg.org statuses could be changed to "other", and we could suggest that the whatwg specs be used as canonical rather than the forks |
| 05:54 | <MikeSmith> | caitp: it's emscripten doing something else now (though I don't know the actual mechanics of how it's doing it) |
| 06:00 | <MikeSmith> | Hixie: https://twitter.com/jschauma/status/513013363375628288 |
| 06:16 | <MikeSmith> | caitp: http://chadaustin.me/2014/09/connecting-c-and-javascript-on-the-web-with-embind/ has more details if you're interested |
| 07:51 | <jgraham> | Hixie: does being around now help? |
| 08:16 | <MikeSmith> | I'm wondering if it's time we just gave up on meta@http-equiv=X-UA-Compatible as a conformance error |
| 08:17 | <MikeSmith> | everybody's using it in spite of that, so having the validator report an error for it is just an annoying time-waster from the perspective of most authors, I think |
| 08:41 | <annevk> | heycam|away: I try to avoid [Attributes] as they look ugly |
| 08:41 | <annevk> | heycam|away: also, legacyiterable has the right incentive attached to it |
| 08:42 | <annevk> | heycam|away: (my initial thought was [NoMethods] too though) |
| 08:43 | <Ms2ger> | What's legacyiterable? |
| 08:49 | <annevk> | Ms2ger: something we can use for HTMLCollection and friends |
| 08:49 | <annevk> | Ms2ger: stuff that gets Symbol.iterator, but not forEach and such |
| 08:50 | <Ms2ger> | Ah |
| 09:14 | <MikeSmith> | hsivonen: FYI https://github.com/validator/validator/issues/1 about 'error: An “body” start tag seen but an element of the same type was already open. |
| 09:24 | <zcorpan> | MikeSmith: actual testimonials: https://twitter.com/newtron/status/405370084904173568 https://twitter.com/paulgreg/status/390546545071771648 https://twitter.com/m_strehl/status/383279928709357569 https://twitter.com/mattur/status/377500793575718912 |
| 09:25 | <MikeSmith> | zcorpan: you missed one: https://twitter.com/jalbertbowdenii/status/377502617191976960 |
| 09:25 | <zcorpan> | there were positive tweets also though |
| 09:25 | <MikeSmith> | oh yeah? |
| 09:29 | <zcorpan> | https://twitter.com/obiwankimberly/status/397701282560872449 https://twitter.com/therealdeiu/status/389486808914219008 https://twitter.com/ia11y/status/379957284660469760 https://twitter.com/gwfrink3/status/378149023921614848 |
| 09:32 | <MikeSmith> | zcorpan: wonders never cease |
| 09:35 | <MikeSmith> | zcorpan: I wonder if "I'm hoping this bad idea will just die a natural death soon" would be considered a positive testimonial or a negative one |
| 09:35 | <MikeSmith> | it's positive in that it's expressing hope at least -- it's a hope-filled testimonial |
| 09:35 | <zcorpan> | heh |
| 09:37 | <MikeSmith> | zcorpan: as far something genuinely hopeful and nice to see, https://github.com/twbs/bootstrap/issues/11984#issuecomment-31206072 |
| 09:37 | <MikeSmith> | 'A bot that scans for newly posted comments with JS Fiddle or JS Bin links, extracts the HTML portion of the Fiddle/Bin, runs it thru the HTML5 validator, and posts a follow-up comment listing any validation errors. We get a decent number of "bug" reports where the problem is actually due to invalid HTML.' |
| 09:37 | <MikeSmith> | = comments posted to github issue tracker for a particular project |
| 09:38 | <MikeSmith> | and the best part is that the code for just such a bot does now actually exist https://github.com/cvrebert/lmvtfy |
| 09:40 | <zcorpan> | nice |
| 09:40 | <zcorpan> | but does it check for accessibility? |
| 09:45 | <jgraham> | "If you're not using [it] yet you don't know what you're missing" is just a statement of fact. An endorsement would be something like "Web Developers SHOULD use the new W3C validator suite" |
| 09:46 | jgraham | assumes all web authors have read Hixie's guide to how to read specifications |
| 10:01 | <smaug____> | can service worker open new windows? |
| 10:02 | smaug____ | is just wondering annevk's question to webapps wg |
| 10:12 | <smaug____> | ServiceWorkerClient perhaps? |
| 10:21 | <smaug____> | I don't understand how that setup prevents unwanted popups |
| 10:43 | <annevk> | smaug____: well it might have to be opt-in |
| 10:43 | <annevk> | smaug____: there's no API today for opening things |
| 10:45 | <smaug____> | we need window opening too for the skype use case |
| 10:46 | <smaug____> | did you mean "[accept call] [cancel]" kind of case for the notifications? |
| 10:47 | <smaug____> | Wouldn't we possibly need also some kind app-activator-icon |
| 10:53 | <annevk> | smaug____: well window and popup are the same, no? |
| 10:54 | <annevk> | smaug____: I meant notifications that would basically allow HTML, which is why I just went with the word popup |
| 10:54 | <annevk> | smaug____: so you can show who is calling, etc. |
| 10:58 | <smaug____> | window and popup aren't quite the same |
| 10:58 | <smaug____> | well |
| 10:58 | <smaug____> | window and notification |
| 10:59 | <smaug____> | window and popup are the same |
| 11:14 | <zcorpan> | can someone explain https://www.w3.org/Bugs/Public/show_bug.cgi?id=26952 ? |
| 11:24 | <jgraham> | zcorpan: I imagine Silvia could? I don't understand the percieved conflict at least, so it seems rather needsinfo |
| 11:49 | <annevk> | smaug____: depends on whether the notification requires a browsing context, imo |
| 11:49 | <annevk> | smaug____: and in this case it would |
| 11:50 | <annevk> | smaug____: but agreed on "not quite", but at this point such details seem a bit premature :-) |
| 11:50 | <jgraham> | I always forget that the foreign content handling in the parser spec is by "magic" |
| 11:51 | <jgraham> | (i.e. a branch when getting tokens from the tokenizer rather than through the normal state machinery) |
| 11:55 | <annevk> | Seems I forgot that too, if I never knew it |
| 11:55 | <annevk> | zcorpan: tried |
| 11:56 | <zcorpan> | annevk: thx |
| 12:24 | <annevk> | Per https://html.spec.whatwg.org/multipage/semantics.html#the-head-element only Firefox implements the <head> element |
| 12:32 | <MikeSmith> | zcorpan: I need to submit a patch to change the 'error: An “body” start tag seen but an element of the same type was already open.' emitted from http://hg.mozilla.org/projects/htmlparser/file/ddc1fa48fcc9/src/nu/validator/htmlparser/impl/TreeBuilder.java#l6232 |
| 12:32 | <MikeSmith> | zcorpan: any opinion on what it should be changed to? |
| 12:33 | <MikeSmith> | zcorpan: one choice is, just drop the "An" and make it "“body” start tag seen but an element of the same type was already open." |
| 12:33 | <zcorpan> | MikeSmith: oh it's a vs an that is the problem? |
| 12:33 | <MikeSmith> | another is "Start tag “body” seen but an element of the same type was already open." |
| 12:34 | <MikeSmith> | zcorpan: yeah |
| 12:34 | <MikeSmith> | reported at https://github.com/validator/validator/issues/1 |
| 12:34 | <MikeSmith> | from one of the boostrap devs |
| 12:35 | <annevk> | Hixie: I can't really come up with a decent way to improve the current set of styles to address the issue I'm seeing in other specs :/ |
| 12:35 | <zcorpan> | Start tag “body” seems ok. maybe make the messages a bit more consistent in the wording while at it? |
| 12:35 | <MikeSmith> | zcorpan: Henri currentlly just has "An" harcoded in there |
| 12:35 | <zcorpan> | there's "End tag \u201Cbr\u201D." |
| 12:35 | <MikeSmith> | zcorpan: yeah ok I'll look at the others in there too |
| 12:36 | <MikeSmith> | oh so changeing it would actually make it more consistent then |
| 12:37 | <zcorpan> | yeah... but i also see "\u201C" + name + "\u201D end tag..." |
| 12:46 | <MikeSmith> | I guess I should fix that one too then |
| 12:47 | <jgraham> | annevk: Yeah, all that implementation metadata is crap |
| 12:47 | <jgraham> | I don't know why we still have it |
| 12:48 | <annevk> | The new idea is to get some stuff from caniuse |
| 12:48 | <jgraham> | There is no evidence that anyone is interested in conuming it or keeping it updated |
| 12:48 | <jgraham> | The new old idea (pretty sure that's been floating around for years) |
| 12:49 | <annevk> | I'm experimenting with some rules that make it easier to edit by enlarging it when you hover (and I should probably add focus) it |
| 12:50 | <jgraham> | Is ease of editing the actual problem? |
| 12:53 | <annevk> | Well, it's not entirely obvious you can edit these |
| 12:54 | <jgraham> | (I guess your answer is "we don't know until we try changing it", which is fair. I guess I wouldn't invest too much effort in it though.) |
| 12:54 | <jgraham> | Yeah, but you and I know that and I certainly never update them |
| 12:59 | <annevk> | True |
| 13:01 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26951#c7 is a bit depressing |
| 13:06 | <jgraham> | zcorpan: That seems like it follows from the first law of metadata ("if getting your metadata wrong doesn't actually break anything, it will be wrong often enough to be useless") |
| 13:06 | <jgraham> | zcorpan: Although 98% is still pretty impressive :) |
| 13:07 | <zcorpan> | yeah |
| 13:09 | <zcorpan> | also interesting that it seems there are more cases that are neither "en" nor "es" than there are "es" |
| 13:10 | <annevk> | We used to have the reverse problem. DOCTYPEs stating //EN and people changing it to //NL |
| 13:13 | <Ms2ger> | "I would have expected that their polyfill would be smart enough to notice a ES7 compliant A.p.contains() and defer to it." |
| 13:13 | Ms2ger | cackles |
| 13:15 | <zcorpan> | annevk: maybe that was the same 2% that specified lang=es here :-) |
| 13:17 | <jgraham> | Ms2ger: I was thinking of coining the phrase "the myth of the suffciently smart web author" in response to that, but maybe I shouldn't ;) |
| 13:18 | <jgraham> | *sufficiently |
| 13:18 | <Ms2ger> | If you're going to typo it, you shouldn't ;) |
| 13:18 | <jgraham> | If that was the criterion I would never be allowed to write anything ever again |
| 13:19 | <jgraham> | I suppose some people might consider that to be a good thing |
| 13:20 | <jgraham> | hsivonen: I pushed your change to html5lib-tests. Do you need to update the patch in bug 886390 ? |
| 13:30 | <zcorpan> | SteveF_: now i wonder if it's you or me who is out of touch with reality |
| 13:30 | <SteveF_> | zcorpan: both |
| 13:31 | <zcorpan> | SteveF_: github isn't just for personal projects for own consumption |
| 13:32 | <jgraham> | Github is actually a rather popular site hosting platform these days |
| 13:32 | <jgraham> | e.g. it hosts the webdevdata site… |
| 13:33 | <SteveF_> | zcorpan: i realise that but the vast majority of the results you provided are for repos with i contributor and no stars/forks |
| 13:34 | <zcorpan> | SteveF_: how does that say anything about whether they are published on the web and viewed by other users? |
| 13:35 | <SteveF_> | zcorpan: it does not translate to the webdev data set at all |
| 13:35 | <zcorpan> | SteveF_: it's possible that the amount of mislabeling is different for top sites and long tail |
| 13:36 | <SteveF_> | zcorpan: sure |
| 13:36 | <SteveF_> | i would say it almost definetely is |
| 13:37 | <zcorpan> | so then i still don't see how you conclude that the github pages aren't on the web |
| 13:40 | <SteveF_> | zcorpan: i would not be overly concerned i only added some lang attributes to some examples (there were already some there) in an editors draft of a bastard fork. think it would be worthwhile adding some advice in there though about lang, will do that |
| 13:41 | <SteveF_> | zcorpan: will take a view, may even remove all and provide advice instead |
| 13:42 | <SteveF_> | zcorpan: there are certain precanned script thingys that are culprits https://github.com/search?q=lang%3D%22en%22+class%3D%22no-js+ie6+lt8%22&ref=searchresults&type=Code&utf8=%E2%9C%93 |
| 13:43 | <zcorpan> | SteveF_: yeah |
| 14:21 | <annevk> | Domenic: apparently some guy from Google is putting some serious effort into WebRTC promises stop energy: http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0003.html |
| 14:21 | <annevk> | slightlyoff: ^ |
| 14:21 | <annevk> | JakeA: ^ |
| 14:26 | <JakeA> | Ugh. What's the reason other than waaaa minor effort |
| 14:28 | <annevk> | As far as I can tell that group is broken. We told them they should switch over a year ago. |
| 14:30 | <mathiasbynens> | Q.E.D. |
| 14:32 | <astearns_> | I guess the PDF is so the line break in the middle of 'e.g.' could be preserved? |
| 14:40 | <mathiasbynens> | annevk: why can’t we just make all relative URLs in HTML-imported documents be relative to that document’s base URL? |
| 14:41 | <annevk> | mathiasbynens: you haven't taken any red pills yet it seems |
| 14:41 | <annevk> | mathiasbynens: how do you determine what a URL is within a <template>, for instance? |
| 14:43 | <mathiasbynens> | annevk: i still don’t understand why `document.importNode` can’t just take care of this |
| 14:43 | jgraham | wonders which document "that document" is here |
| 14:44 | <mathiasbynens> | jgraham: the one that gets <link rel=import>ed |
| 14:44 | <annevk> | mathiasbynens: why would that be in charge of what is a URL? |
| 14:45 | <annevk> | mathiasbynens: you'll have to get a bit more concrete so I can either learn something or point out an error in your reasoning I'm afraid |
| 14:46 | <mathiasbynens> | annevk: so I’m thinking, why can’t this line https://github.com/mathiasbynens/relative-urls-in-web-components/blob/1b3d159721102d366d575769ab4fa0f3c6341687/packaged-web-component/import-me.html#L17 not somehow make the relative URL in the template an absolute one? |
| 14:46 | <mathiasbynens> | perhaps when `someTemplateElement.content` is accessed |
| 14:47 | <annevk> | mathiasbynens: how does it know what is a relative URL within the template? |
| 14:47 | <annevk> | (you can tell I'm still asking the same questions) |
| 14:47 | <mathiasbynens> | oh right, cause everything is normalized already at that point |
| 14:48 | <jgraham> | It seems pretty weird if the urls are resolved relative to the document that does the import? You end up with different resources depending on where you are importing |
| 14:49 | <mathiasbynens> | jgraham: I agree, but that’s the current behavior |
| 14:50 | <annevk> | So the one thing mentioned in that bug is associating a URL with <template> somehow. However, that complicates base URL processing. But perhaps it is sufficient. |
| 14:50 | <jgraham> | That just doesn't seem sane. What's the use case? Isn't this supposed to provide some sort of encapsulation? |
| 14:50 | <annevk> | However, doing it now might be too late. |
| 14:51 | <annevk> | jgraham: it's not about use cases, it's about it being problematic |
| 14:52 | <mathiasbynens> | annevk: it might still be possible: everyone using web components seems to be using absolute or root-relative URLs for this reason |
| 14:52 | <jgraham> | So I don't understand why it's problematic to resolve the URLs against anything you want, but I'm worried if decisions aren't being made based on what's best for people using the tech |
| 14:53 | <annevk> | mathiasbynens: it's still not clear if that would work though and it would break e.g. with the innerHTML example |
| 14:53 | <annevk> | jgraham: the problem is that all scripts execute in the same global |
| 14:54 | <annevk> | jgraham: and that web components are not really providing any of the promised encapsulation, they're a hack |
| 14:55 | <annevk> | I'm sure everyone involved would love a solution |
| 14:56 | <jgraham> | Oh yeah, the sharing a global thing |
| 14:56 | <jgraham> | Well that's pretyt much insane to start with |
| 14:58 | <jgraham> | I'm pretty sure in 5 years there will be a new generation of people working on the web-platform coming through and giving everyone hell for the design decisions of web components |
| 14:58 | <annevk> | That it breaks scripts is still a really convincing reason to not solve it for the static case |
| 14:58 | <annevk> | I thought we already did that and nobody really listened? |
| 15:05 | <tobie> | jgraham: I'm pretty sure you won't need to wait 5 years for that. |
| 15:06 | <jgraham> | Well the new generation thing seems to happen about every 5 years |
| 15:08 | <darobin> | you'll have to wait five years for it to have any momentum |
| 15:09 | <tobie> | Seriously, the message I've heard from devs about Web components right now is pretty much aligned with your fears, jgraham |
| 15:10 | <tobie> | I'm struggling with properly writing out algorithms. When do you nest steps, etc.? Is there a primer on this somehwere? |
| 15:11 | <mathiasbynens> | because of the global sharing, i guess there’s no way to figure out the absolute URL of an HTML-imported document within that document? |
| 15:19 | <jgraham> | Yep, and so some people will come up with a — well we've had "principles" and "manifesto" — "Large Scale Web Applications Objectives" document, say, and make a big fuss about how all the people who worked on this before made terrible choices and introduce some new things that will paper over the cracks in a new and differently broken way |
| 15:21 | <ManishCloud> | Hixie: around? |
| 15:22 | <ManishCloud> | Any reason why the spec here seems to recommend storing a form owner and updating whenever the DOM changes as opposed to calculating it on demand? |
| 15:22 | <ManishCloud> | https://html.spec.whatwg.org/multipage/forms.html#form-owner |
| 15:22 | <ManishCloud> | (Is there any reason for the two to not mean the same thing?) |
| 15:23 | <ManishCloud> | AFAICT storing the form owner would be much less performant than calculating on demand |
| 15:23 | <ManishCloud> | https://github.com/servo/servo/issues/3553#issuecomment-57643743 |
| 15:23 | <tobie> | jgraham: we seem to be in agreement over something. |
| 15:23 | <Hixie> | ManishCloud: because you can't calculate it |
| 15:24 | <Hixie> | ManishCloud: it can be set e.g. by the parser to values that can't be found from looking at the static state of the dom |
| 15:24 | tobie | ponders whether that makes him less likable. |
| 15:25 | <ManishCloud> | Hixie: the parser can set it? Hm |
| 15:25 | <Hixie> | jgraham: i'm taking over your bug database maintenance task thing |
| 15:25 | <Hixie> | jgraham: since i'm making the data get baked into the spec itself |
| 15:25 | <Hixie> | jgraham: rather than having it shimmed in at load time |
| 15:25 | <Hixie> | bbiab |
| 15:25 | <jgraham> | Hixie: OK, since I'd forgotten that existed I can't really complain :) |
| 15:25 | <Hixie> | :-) |
| 15:25 | <mathiasbynens> | aha, `document.currentScript.ownerDocument.baseURI` from within a <script> in the imported document, of course |
| 15:26 | <tobie> | Seriously though, my algorithm looks like an ode to goto statements. |
| 15:33 | <ManishCloud> | Hixie: any example of where the parser spec recommends setting it? |
| 15:35 | <jgraham> | ManishCloud: click on the definition |
| 15:35 | <jgraham> | Well on the term |
| 15:35 | <jgraham> | i.e. the bold bit at https://html.spec.whatwg.org/#form-element-pointer |
| 15:58 | <ManishCloud> | jgraham: but that's set only once, right? |
| 16:01 | ManishCloud | -> Manishearth |
| 16:06 | <jgraham> | Manishearth: Well each element is only parsed once, sure |
| 16:07 | <jgraham> | You still need to keep the state from parsing somewhere |
| 16:46 | <Manishearth> | jgraham: keep the state from parsing somewhere? |
| 16:47 | <Manishearth> | I was thinking of a lazy load mechanism that sets the owner in case of broken html, and then can be fetxhed on demand where it looks for changes |
| 16:51 | <annevk> | So for now WebRTC does not use promises since someone in the call came with the ultimatum that I couldn't propose deprecating the callback-style that exists today for the next three years. (Keep in mind that implementations are still prefixed.) |
| 16:51 | <annevk> | I have no words |
| 17:00 | <tantek> | three years? wow. who's ship schedule is that? |
| 17:00 | <tantek> | s/who's/whose |
| 17:02 | <terinjokes> | also… this is deprecating them, not removing them |
| 17:37 | <Hixie> | Manishearth: how would that differ from what the spec says? |
| 17:37 | <Hixie> | annevk: uh, push back? that's absurd, if there's no implementations. |
| 17:56 | <annevk> | Hixie: we ran out of time and everyone dropped and it's unclear what happens next |
| 17:56 | <annevk> | Hixie: teleconferences are so weird |
| 17:59 | <SimonSapin> | annevk: Is there a general principle for when and how many UTF-8 decoding emits replacement characters? |
| 17:59 | <Hixie> | annevk: send an e-mail? |
| 18:00 | <Hixie> | teleconf-gated standards development is so last century |
| 18:06 | <tantek> | email-gated standards development is so last decade. ;) |
| 18:08 | <annevk> | SimonSapin: yeah, the spec |
| 18:09 | <annevk> | Hixie: I might |
| 18:12 | <SimonSapin> | annevk: I mean a principle guiding spec-writing |
| 18:13 | <gsnedders> | SimonSapin: IIRC one for a bogus sequence (i.e., you start a sequence, it goes bogus -> one); bogus start of sequence -> one |
| 18:13 | <SimonSapin> | thanks gsnedders |
| 18:18 | <annevk> | SimonSapin: I think Unicode makes a recommendation and I think it so happens that was the correct recommendation |
| 18:18 | <annevk> | SimonSapin: spec makes a note of it |
| 18:19 | <SimonSapin> | got it, thanks |
| 19:33 | <Hixie> | tantek: who does e-mail-gated standards development? |
| 19:34 | <tantek> | IETF, WHATWG, parts of W3C |
| 19:35 | <Hixie> | WHATWG doesn't |
| 19:35 | <tantek> | though at least (plain text) email is better than emailing Word / PPT / PDF docs back and forth. |
| 19:35 | <Hixie> | we do accept feedback by e-mail, but it's not gated on e-mail |
| 19:35 | <tantek> | Hixie, I seem to remember a lot of docs, wiki, etc. on whatwg all saying to eventually send feedback by email, as that being the one mechanism that's preferred or something. |
| 19:35 | <Hixie> | (it's gated on the spec editor, primarily) |
| 19:36 | <Hixie> | e-mail or bugs, yeah |
| 19:36 | <tantek> | ok that's an important clarification |
| 19:36 | <tantek> | thank you - that helps. |
| 19:37 | <Hixie> | annevk: ok i think the markup is gonna be this: |
| 19:37 | <Hixie> | <div class="status"> |
| 19:37 | <Hixie> | <p><strong>Bugs:</strong> <a href="..." title="...">...</a>, <a href="..." title="...">...</a></p> |
| 19:37 | <Hixie> | <p><strong>Support:</strong> |
| 19:37 | <Hixie> | <span class="ff"><span>Firefox</span> <span>44+</span></span> |
| 19:37 | <Hixie> | <span class="ie"><span>IE</span> <span>9+</span></span> |
| 19:37 | <Hixie> | </p> |
| 19:37 | <Hixie> | </div> |
| 19:37 | <Hixie> | let me know if you want something different |
| 20:05 | <TabAtkins> | annevk: Who sent that ultimatum? |
| 20:11 | <boogyman> | Hixie Two questions: 1 - why not use a definition list. <dl class=support><dt>Support</dt><dd class=ff>Firefox <span>44+</span></dd><dd class=VendorAbbr>VendorName <span>SupportSince</span></dt>…</dl> <style>dl.support dd {…} dl.support dd > span {…}</style> 2- if you are going to keep the proposed markup above, I what's the need for the <span> around the Vendor Name? It seems superfluous to me. |
| 20:13 | <Hixie> | i expect the vendor name to be display:none'ed |
| 20:14 | <Hixie> | a <dl> would make sense, but CSS makes styling <dl>s hard |
| 20:14 | <SimonSapin> | I think I finished the WTF-8 spec! Feedback welcome. (Technical, editorial, …) http://simonsapin.github.io/wtf-8/ |
| 20:14 | <boogyman> | Hixie: image replacement? |
| 20:15 | <TabAtkins> | Hixie: Just use <di>! |
| 20:16 | <Hixie> | boogyman: maybe |
| 20:16 | <Hixie> | TabAtkins: heh |
| 20:16 | TabAtkins | has used <di> without shame when he needed it. |
| 20:17 | <Hixie> | css should just be fixed to handle this case |
| 20:17 | <Hixie> | but anyway |
| 20:17 | <Hixie> | it's not really a dl |
| 20:17 | <Hixie> | it's more a ul |
| 20:17 | <boogyman> | Can you provide a reference? I am unfamiliar with the deficiency |
| 20:18 | <Hixie> | the deficiency is just that there's no way in CSS to insert an anonymous block around a set of siblings |
| 20:18 | <Hixie> | like <a/><::x><b/><c/></::x><d/> |
| 20:21 | <rubys> | annevk: ping? |
| 20:50 | <rubys> | http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI |
| 20:53 | <tantek> | annevk ^^^ |
| 21:12 | <Sample> | Two separate questions I'm considering right now |
| 21:15 | <Sample> | 1) Regarding deprecation of readAsBinaryString (http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1497.html) it proposes the removal due to "inefficiency". Wouldn't the real reason have been because it wasn't feasible? bits cannot be decoded to UTF-8 and back to bits without data corruption |
| 21:16 | <Sample> | Just wondering if anyone was around at the time or knows any details beyond that post |
| 21:18 | <Sample> | my other question is 2) Is "query encoding" as defined by the HTML or URL spec identical to x-www-form-urlencoded? |
| 21:23 | <Sample> | question 2 arises from statements like: Align RFC 3986 and RFC 3987 with contemporary implementations and obsolete them in the process. (E.g. spaces, other "illegal" code points, query encoding, equality, canonicalization, are all concepts not entirely shared, or defined.) |
| 21:26 | <Hixie> | not sure what you mean by #2 |
| 21:27 | <Sample> | sorry for being unclear =) My question is if there's character restrictions present in the "query" portion of a URL that are not present in x-www-form-urlencoded |
| 21:28 | <Hixie> | are there character restrictions in x-www-form-urlencoded? |
| 21:28 | <Hixie> | i don't know that we really define conformance criteria for that format |
| 21:28 | <Hixie> | we define serialisation and parsing rules, but... |
| 21:29 | <Sample> | I'm admittedly not clear what the MIME type means when it suggests "urlencoded". I didn't think x-www-form-urlencoded percent-encoded characters |
| 21:29 | <Sample> | I guess I need to take a look at some test requests |
| 21:30 | <Domenic> | If I am understanding you correctly, the answer is: the spec for x-www-form-urlencoded is either nonexistant or underspecified, so the URL standard obsoletes it, at least in the cases we care about (usage of that format in URLs) |
| 21:31 | <Hixie> | url.spec.whatwg.org and html.spec.whatwg.org both define x-www-form-urlencoded, but neither define a conformance criteria |
| 21:31 | <Hixie> | just parse and serialise algorithms |
| 21:31 | <Hixie> | (aka encode/decode) |
| 21:31 | <Sample> | Yeah sorry for being unclear, I'm half confused myself. I'm presuming that a URL query and x-www-form-urlencoded are the same format |
| 21:32 | <Domenic> | i think part of the disconnect is that talking about a "format" is not generally that interesting compared to talking about encode/decode algorithms |
| 21:33 | <Hixie> | Sample: i think neither "a URL query" nor "the x-www-form-urlencoded format" are well-defined terms |
| 21:33 | <Hixie> | Sample: which makes the discussion hard to follow :-) |
| 21:33 | <Sample> | Hixie: haha okay |
| 21:34 | <Sample> | I just became curious if the payload constructed via a GET ampersand-delimited percent-encoded (urlencoded) name=value pair is exactly identical to the payload of a forms x-www-form-urlencoded |
| 21:35 | <Sample> | looks as if they are |
| 21:36 | <Hixie> | not sure what you mean by "payload constructed via a GET ampersand-delimited percent-encoded (urlencoded) name=value pair" |
| 21:36 | <Hixie> | form submission uses https://html.spec.whatwg.org/#application/x-www-form-urlencoded-encoding-algorithm |
| 21:37 | <Hixie> | and then passes it to https://url.spec.whatwg.org/#serializing as the query component |
| 21:38 | <Sample> | is the same encoding defined there required for constructing a URL "query" as defined by something like: http://tools.ietf.org/html/rfc3986#section-3.4 |
| 21:38 | <Hixie> | that RFC is dead. |
| 21:38 | <Sample> | maybe that question uses better nomenclature |
| 21:38 | <Sample> | ah |
| 21:38 | <Hixie> | (at least as far as #whatwg is concerned) |
| 21:38 | <Hixie> | url.spec.whatwg.org obsoletes it |
| 21:39 | <Sample> | and you define that same section as "A URL's query is either null or a string holding data. It is initially null." |
| 21:39 | <Sample> | which is rather vague =) |
| 21:40 | <Hixie> | what's the actual question you're trying to answer? |
| 21:41 | <Sample> | Yes, is a URL query request and an x-www-form-urlencoded payload the same data format |
| 21:42 | <Sample> | they appear to be. ampersand delimited, equals delimited, urlencoded name value pairs |
| 21:44 | <Hixie> | The part after the ? and before the # in a URL is an opaque string, whose meaning is only defined by the server. |
| 21:44 | <Sample> | not standardized? |
| 21:44 | <Hixie> | it's standardised in the same way that the "path" part is standardised |
| 21:44 | <Hixie> | it's an opaque string with meaning defined by the server |
| 21:45 | <Sample> | huh... weird |
| 21:45 | <Sample> | thanks |
| 21:45 | <Hixie> | form submission assumes that the server expects the x-www-form-urlencoded part to be in the format generated by https://html.spec.whatwg.org/#application/x-www-form-urlencoded-encoding-algorithm |
| 21:45 | <Hixie> | er, the query part |
| 21:45 | <Hixie> | the part between ? and # |
| 21:45 | <Hixie> | so when you do form submission from a browser, you end up seeing the output of the https://html.spec.whatwg.org/#application/x-www-form-urlencoded-encoding-algorithm in the query component |
| 21:46 | <Sample> | so you could put a CSV encoding between the ? and the # and that's totally fine? |
| 21:46 | <SimonSapin> | Hixie, annevk: https://url.spec.whatwg.org/#application/x-www-form-urlencoded looks identical to https://html.spec.whatwg.org/#url-encoded-form-data . Should one of them use the other? |
| 21:46 | <Hixie> | Sample: if the server expects it, sure |
| 21:46 | <Sample> | ?first,last,score\njohn,doe,98# |
| 21:46 | <Sample> | strange |
| 21:46 | <Sample> | interesting |
| 21:47 | <Sample> | most servers would be rather confused I imagine |
| 21:47 | <Hixie> | Sample: consider, e.g.: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.fillStyle%20%3D%20%27green%27%3B%0Ac.fillRect(10%2C10%2C200%2C200)%3B%0A |
| 21:47 | <Hixie> | that file takes JavaScript snippets in the query and evaluates them |
| 21:48 | <Sample> | looks like quite the XSS vector =D |
| 21:48 | <Hixie> | it's just up to the server to decide how to interpret it |
| 21:48 | <Hixie> | yes, if that server had anything interesting it would be |
| 21:48 | <Sample> | well that's all very interesting, thanks |
| 21:48 | <Hixie> | the path component is the same. it's up to the server to know how to parse it |
| 21:49 | <sicking> | annevk: awake? |
| 21:49 | <Sample> | so we can say "most servers expect x-www-url-encoded payload via the URL query" |
| 21:49 | <Hixie> | e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1 |
| 21:49 | <Sample> | in the same way we can say "most servers expect form-data to come via application/x-www-form-urlencoded" |
| 21:49 | <Hixie> | Sample: most servers expect nothing in the query and ignore it. |
| 21:50 | <Hixie> | (in the url i gave above, the /saved/1 part is parsed by the script at http://software.hixie.ch/utilities/js/live-dom-viewer -- there's no /saved/ directory or anything) |
| 21:50 | <Hixie> | (in fact you can go to http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1 and it does the same thing) |
| 21:52 | <Sample> | Hixie: apache which is probably the most common webserver I think could be said to "expect" a data format within the URL Query to parse a GET parameter |
| 21:52 | <Sample> | that format I guess being x-www-form-urlencoded |
| 21:53 | <Sample> | perhaps I'm wrong and the server is indifferent. maybe this "GET" notion is handled on backend code exclusively |
| 21:53 | <Sample> | I just figured apache had some notion or expectation of it |
| 21:55 | <Sample> | maybe the basis of the confusion I'm procuding here is that I had the expectation that a URL query is in a certain format and that webservers parse that expected format somehow |
| 21:56 | <Hixie> | Sample: apache doesn't parse the query component at all as far as i know. maybe for directory listings. |
| 21:56 | <Sample> | since you generally ever only see key=value ampersand delimited URL queries (except in your example obviously) |
| 21:56 | <Sample> | this was enlightening though, thanks |
| 21:56 | <Hixie> | you generally see key=value&key=value because that's what forms submit |
| 22:05 | <Sample> | Regarding my first question I was incorrect assuming JS strings use UTF-8. They use USC-2 which is a fixed 16-bit with no bit metadata, so readAsBinaryString was probably totally safe operation |
| 22:06 | <Hixie> | JS uses UTF-16 exposed as 16-bit code units |
| 22:20 | <Sample> | hm, utf-16 does have invalid bit sequences (unpaired surrogates) but I don't believe it throws the "replacement character" which results in data corruption. though it's possible it may still corrupt a bit sequence |
| 22:21 | <Sample> | like I wonder what D800FFFF displays |
| 22:22 | <Sample> | "Unpaired surrogates are invalid in UTFs. These include any value in the range D80016 to DBFF16 not followed by a value in the range DC0016 to DFFF16, or any value in the range DC0016 to DFFF16 not preceded by a value in the range D80016 to DBFF16." |
| 22:22 | <Hixie> | two U+FFEFs iirc |
| 22:22 | <Hixie> | FFFDs i mean |
| 22:23 | <Sample> | yeah. anything which throws FFFDs would currupt binary data in code point representation. UCS-2 does not |
| 22:33 | <Hixie> | well UCS-2 corrupts anything that isn't in the BMP, but sure :-) |
| 22:37 | <Sample> | in terms of raw bit sequences everything falls within every 16 bits falls within 0000 and FFFF =) |
| 22:37 | <Sample> | glitch-in-the-matrix style sentence there |
| 22:38 | <gsnedders> | Sample: Unicode doesn't define how ill-formed code unit sequences decode |
| 22:38 | <gsnedders> | Sample: though the Web Encoding spec does, which matters more in browser land |
| 22:39 | <cwilso> | annevk: TBF, they heavily push "navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia; |
| 22:39 | <cwilso> | " as cargo-cult boilerplate (HT: Hixie for term), so not too surprising they ignore prefixing as a way of separating. |
| 22:40 | <cwilso> | annevk: that said, I think that's totally wack, and they should make v1 the api we should have for the next 20 years, not the last 20 months. |
| 22:42 | <cwilso> | annevk: what do you think about other ancient-design APIs, like geoloc? I recast geoloc with Promises, just because I wanted to see what it would look like (https://gist.github.com/cwilso/3922d0a85a684f8ab298) - not sure if it's worth trying to push through, or should just leave it as a shipped API. |
| 22:42 | <caitp> | people have a hard time engineering a toilet that will work for 20 years, let alone an application/media platform |
| 22:43 | <cwilso> | Aw, come on, I think the toilets in my house are at least 40 years old at this point. :) |
| 22:43 | <gsnedders> | And cwilso suddenly appears, says a lot, and presumably will vanish again :) |
| 22:44 | <cwilso> | Lurker extraordinaire, that's me. |
| 22:44 | <cwilso> | (the pattern of talking to someone who's likely asleep.) |
| 22:46 | <gsnedders> | SimonSapin: I hope we're not planning on exposing WTF-16 to the web platform (AIUI it's only there because WinNT filenames). |
| 22:46 | <SimonSapin> | gsnedders: no |
| 22:47 | <gsnedders> | cwilso: Hey, I scarcely contribute to web standards now and still talk more than you! :P |
| 22:47 | <gsnedders> | SimonSapin: good, because otherwise I would cry |
| 22:48 | <SimonSapin> | gsnedders: I have "must not be used for interchange" in the spec, but I still need to define interchange. Any suggestion? |
| 22:48 | <cwilso> | gsnedders: you talk more than me in the WHATWG IRC, maybe. :) I'm not known for keeping my mouth shut. |
| 22:48 | <gsnedders> | cwilso: well, that's what I meant :P |
| 22:48 | <gsnedders> | I don't doubt in more /serious/ channels you don't do more |
| 22:49 | gsnedders | hopes he didn't confuse himself with all the negatives in that |
| 22:50 | <cwilso> | gsnedders: "serious" is also not something I'm known for. |
| 22:50 | <gsnedders> | cwilso: you mean threatening to pick people up and dump them in the sea isn't serious?! |
| 22:51 | <cwilso> | gsnedders: THAT WAS ONE TIME. |
| 22:51 | <gsnedders> | SimonSapin: does Unicode ever define it? |
| 22:51 | <cwilso> | :) |
| 22:51 | <gsnedders> | cwilso: hey, it wasn't me, so it's all cool here |
| 22:52 | <gsnedders> | SimonSapin: I think it doesn't really need defined, tbh |
| 22:52 | <gsnedders> | SimonSapin: Unicode doesn't appear to |
| 22:52 | <SimonSapin> | Unicode defines Restricted Interchange, but apparently not interchange |
| 22:53 | <gsnedders> | well restricted interchange is really just "don't do this in interhcange" |
| 22:53 | <gsnedders> | rather than defining anything about interchange |
| 22:54 | <SimonSapin> | "cannot be conformantly interchanged" |
| 22:54 | <SimonSapin> | yes |
| 22:55 | <gsnedders> | SimonSapin: and stop thinking I have any real opinions, I just lurk on IRC and bitch at you guys without really knowing any context :) |
| 22:55 | <Hixie> | btw, good luck inventing an encoding and then telling people not to use it |
| 22:55 | <Hixie> | c.f. the CESU-8, UTF-7, BOCU-1 and SCSU encodings |
| 22:56 | <gsnedders> | well CESU-8 more just /arose/ |
| 22:56 | <Hixie> | WTF-16 too, no? |
| 22:56 | <gsnedders> | I'm not sure anyone deliverately invented |
| 22:56 | <gsnedders> | yeah |
| 22:56 | <SimonSapin> | Hixie: sure, but I can at least try to convince browsers not to implement it for stuff from the network |
| 22:57 | <gsnedders> | WTF-8 is arguably the scary one |
| 22:57 | <gsnedders> | because it doesn't yet exist |
| 23:12 | <Domenic> | https://streams.spec.whatwg.org/branch-snapshots/move-readable-stream/ almost ready to merge into master and thus https://streams.spec.whatwg.org/... \o/ |
| 23:29 | <Yuhong> | On W3C's fork of WHATWG's URL standard, how often does URLs change really? |