| 02:29 | <erlehmann> | there is no redirect? http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html#atom |
| 02:31 | <erlehmann> | i see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/068847.html |
| 02:36 | <erlehmann> | http://edward.oconnor.cx/2013/03/herodotus-on-standards-work |
| 02:56 | <Hixie_> | erlehmann: i think that section is long gone |
| 02:57 | <erlehmann> | Hixie_ yeah, i see. can't you add a note about that? |
| 02:57 | <erlehmann> | it really took me some time to find out that it has not moved around or something |
| 02:57 | <erlehmann> | because of software changes |
| 02:57 | <erlehmann> | and was just scrapped |
| 02:57 | <Hixie_> | sure. file a bug. not sure where i'd put it exactly, or what it should say, but i can try |
| 02:59 | <erlehmann> | Hixie_ where can i file bug? |
| 02:59 | <erlehmann> | i'll try to figure it out |
| 02:59 | <Hixie_> | whatwg.org/newbug |
| 03:00 | <erlehmann> | thx! |
| 03:00 | <erlehmann> | www.w3.org |
| 03:00 | <erlehmann> | hahaha |
| 03:00 | <erlehmann> | in the spirit of slashdot.org |
| 05:17 | <zcorpan> | hsivonen: MikeSmith: https://github.com/svenkreiss/html5validator |
| 05:32 | <karlcow> | wondering who is in charge at Apple for Mixed Content Blocking issues https://bugzilla.mozilla.org/show_bug.cgi?id=881485 |
| 06:41 | <Ms2ger> | "This is not enough quorum to discuss anything meaningful so we ended the call after 15 minutes." |
| 06:42 | <Ms2ger> | One wonders how it takes 15 minutes to figure that out |
| 07:33 | <ato> | Ms2ger: Maybe only non-meaningful things were discussed. |
| 07:56 | <jgraham> | othermaciej: http://w3c-test.org/url/ |
| 08:22 | <annevk> | ah, was just about to answer that :-) |
| 09:28 | <annevk> | hsivonen: are you going to a do a blogpost on DNSSEC one day? |
| 09:31 | <foolip> | annevk: do you know which spec defines how Web browsers detect the encoding of text/plain input, i.e. the heuristic that looks for a UTF-8 BOM, valid UTF-8 sequences and that kind of thing? |
| 09:32 | <jgraham> | HTML, I imagine |
| 09:33 | <annevk> | foolip: currently we don't have sniffing for text/plain |
| 09:33 | <foolip> | http://www.whatwg.org/specs/web-apps/current-work/#encoding-sniffing-algorithm seems relevant |
| 09:33 | <annevk> | foolip: if user agents employ sniffing for text/plain, that should probably be defined in HTML |
| 09:34 | <foolip> | I said text/plain because I'm interested in a good heuristic that isn't HTML-specific |
| 09:34 | <foolip> | for a non-Web, non-work thing |
| 09:34 | <annevk> | the current rules are only checking BOM for text/plain |
| 09:34 | <foolip> | jgraham: detecting the encoding of files loaded in Critic, in fact |
| 09:34 | <jgraham> | From a web-browser point of view text/plain is very like HTML |
| 09:34 | <annevk> | no hueristics |
| 09:35 | <jgraham> | foolip: Ah. Isn't the canonical solution there to use chardet, or something? |
| 09:36 | <foolip> | jgraham: dunno, molsson asked me and all I know is Web stuff :) |
| 09:36 | <jgraham> | Heh |
| 09:36 | <Ms2ger> | def detect_charset(content): |
| 09:36 | <Ms2ger> | return "utf-8" |
| 09:37 | <foolip> | Ms2ger: that is a serious option, yes :) |
| 09:39 | <jgraham> | try: input.decode("utf-8"); except UnicodeDecodeError: review.add_issue("Your source is in the wrong encoding. Please use UTF8.") |
| 09:39 | <foolip> | jgraham: yes, or input.decode("utf-8", errors="replace") :) |
| 09:41 | <Ms2ger> | Nah, what jgraham said |
| 09:41 | <hsivonen> | annevk: maybe. more likely if my domain experiences "DNSSEC suicide" for the third time... |
| 09:41 | <hsivonen> | annevk: DNSSEC is probably the fourth post in my queue of blog post ideas |
| 09:42 | <annevk> | hsivonen: ah shit, I just changed the Preface |
| 09:43 | <hsivonen> | (the three ahead of it are: "You should work on Firefox OS and self-hostable services if you want Software Freedom for phones", "You only need 3 or 4 ciphersuites" and "Character Encoding Menu in 2014") |
| 09:45 | <annevk> | those are all great, please take a week to write them :) |
| 09:46 | <hsivonen> | annevk: very productive to try to use a religious snowclone to end a bikeshed about wordsmithing non-normative text not to be offensive |
| 09:47 | Ms2ger | appears to be missing context on that one |
| 09:47 | <hsivonen> | Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26693#c4 |
| 09:49 | <Ms2ger> | Ta |
| 09:51 | <hsivonen> | annevk: the new text is good. gives less rationale than my suggestion, but the less you say, the less text there is for people to complain about |
| 09:53 | <annevk> | I'll see about integrating some of it, the extra rationale is actually nice |
| 09:55 | <hsivonen> | now that I'm disillusioned about DNSSEC, maybe I should ask my ISP to support IPv6 |
| 09:56 | <annevk> | Did you see http://tack.io/ btw? |
| 09:56 | <annevk> | Although https://lists.riseup.net/www/arc/tack/2014-01/msg00001.html suggests it might be dead |
| 09:57 | <hsivonen> | annevk: I'm aware of TACK |
| 10:00 | <jgraham> | Wow, GitHub finally got side-by-side diffs |
| 10:01 | <annevk> | hsivonen: you think it might work for replacing CAs? |
| 10:33 | <othermaciej> | jgraham: thanks! |
| 10:36 | <hsivonen> | annevk: it seems to me that TACK still needs CAs for the first connection |
| 10:52 | <hsivonen> | annevk: if you are looking for encoding permathreads to debate, Thunderbird just improved its encoding UI but shows both windows-1252 and iso-8859-1 as distinct items: https://hg.mozilla.org/comm-central/rev/f2a455fd8e80 |
| 11:08 | <JakeA> | Any indexeddb experts awake? If I have an index with two keys, say ['name', 'birthdate'], how do I open a cursor for a specific name but any birthday (but in birthdate order) |
| 11:08 | <JakeA> | ? |
| 11:13 | <hsivonen> | it's been too long since I've paid attention to html5lib tests |
| 11:15 | <hsivonen> | please remind my what happened to the SVG filterRes attribute |
| 11:15 | <hsivonen> | html5lib explicitly tests for it *not* getting camelCased |
| 11:20 | <hsivonen> | oh. awesome. the html5lib test format has changed |
| 11:20 | <hsivonen> | that's why things are failing |
| 11:21 | <jgraham> | hsivonen: Blame Hixie |
| 11:21 | <hsivonen> | jgraham: for test format or filterRes? |
| 11:22 | <jgraham> | Test format |
| 11:22 | <jgraham> | But maybe both! Who knows :) |
| 11:22 | hsivonen | blames Hixie |
| 11:29 | hsivonen | is quite unamused by the #script-on / #script-off stuff |
| 11:42 | hsivonen | finds https://www.w3.org/Bugs/Public/show_bug.cgi?id=24900 |
| 11:51 | <hsivonen> | oh. great. there are three other attributes that got un-camelCased |
| 12:06 | <caitp-> | how about element names? |
| 12:47 | <Domenic> | I forget ... did anyone propose measuring DOMRectList.prototype.item usage to see if we can remove it in favor of Array? |
| 12:50 | <Ms2ger> | You did just now |
| 12:51 | <Domenic> | I don't want to re-propose it if someone already found a bunch of popular GItHub libraries using it... |
| 12:54 | <foolip> | Domenic: do you mean measuring ClientRectList.item in Blink? |
| 13:04 | <Domenic> | foolip: yeah |
| 13:06 | <foolip> | Domenic: I can make it so if the relevant spec editors want it. zcorpan? |
| 13:07 | <Ms2ger> | Make it sp |
| 13:07 | <Ms2ger> | so |
| 13:08 | <foolip> | Domenic: or are you already a Chromium/Blink committer? |
| 13:08 | <zcorpan> | foolip: want what? nuke ClientRectList? |
| 13:08 | <Domenic> | foolip: I am definitely not a committer, although I really should start committing some stuff sometimes soon :) |
| 13:09 | <jgraham> | It's a little known fact that in his high school yearbook foolip was voted "Person most likely to go on to measure web platform feature usage" |
| 13:09 | <foolip> | zcorpan: whatever it is one does to make it Array-like I guess. |
| 13:10 | <Ms2ger> | zcorpan, yeah, nuke |
| 13:10 | <Ms2ger> | If possible |
| 13:10 | <Domenic> | zcorpan: the proposal on the table is to use-counter ClientRectList.prototype.item and if it's not used then DOMRectList can die in favor of plain old Array. |
| 13:10 | <zcorpan> | foolip: http://dev.w3.org/fxtf/geometry/#DOMRectList already has [NoInterfaceObject, ArrayClass] |
| 13:11 | <foolip> | interesting |
| 13:11 | <zcorpan> | it should make it array-like as i understand it but item() is still there |
| 13:11 | <foolip> | so is ClientRect and ClientRectList a WebKit-only thing? |
| 13:11 | <Ms2ger> | foolip, they got renamed |
| 13:11 | <zcorpan> | no it was Client* in the spec earlier |
| 13:11 | <Ms2ger> | It would be nice to go arraylike -> array |
| 13:12 | <foolip> | best outcome is adding DOMRect and then failing to remove ClientRect :) |
| 13:12 | <zcorpan> | Ms2ger: sure |
| 13:12 | <Domenic> | foolip: oh god now i am afraid that will happen :( |
| 13:13 | <foolip> | :) |
| 13:13 | <jgraham> | s/best/most likely/ |
| 13:14 | <Ms2ger> | Gecko's already killed ClientRect |
| 13:15 | <foolip> | if you want to talk to someone with an actual clue about where Blink is going with these interfaces, jinho.bang⊙sc and Rik Cabanier seem to be the relevant people |
| 13:15 | <zcorpan> | i think i tried to research usage of ClientRect/ClientRectList and, iirc, there was some item() usage but people didn't rely on the name of the interface object |
| 13:15 | foolip | wishes "Gecko doesn't have X" would automatically count as justification for removing X |
| 13:16 | <Ms2ger> | Make it so |
| 13:18 | <foolip> | Here are a few silly things in that category: Event.srcElement, Event.cancelBubble, Window.offscreenBuffering, Document.charset, Document.defaultCharset |
| 13:18 | <foolip> | offscreenBuffering is my favorite, it's always true and enjoys ~0.2% usage |
| 13:19 | <Ms2ger> | Nice |
| 13:19 | <Ms2ger> | Sadly, browser sniffing makes that argument invalid :/ |
| 13:19 | <foolip> | Indeed |
| 13:20 | <Domenic> | we should all copy IE11 Mobile's user agent string |
| 13:20 | <Domenic> | Or, perhaps more realistically, all desktop browsers should have the same UA string. |
| 13:21 | <zcorpan> | Domenic: it is indeed a race to the bottom, except there is no bottom |
| 13:21 | <Ms2ger> | Except that the first browser to copy another UA string disappears from statistics |
| 13:21 | <Domenic> | Ms2ger: oh, I didn't think of that :( |
| 13:22 | <Ms2ger> | And there's an argument to be made that statistics are a legitimate use case |
| 13:22 | <Domenic> | yeah |
| 13:23 | <jgraham> | Presumably statistics are the intended use case |
| 13:23 | <jgraham> | Otherwise wtf were they thinking? |
| 13:23 | <foolip> | when the UA string can't be trusted you get something equally horrible: https://github.com/zynga/core/blob/cd2a5e639a603d4d327fea57fa3bb6c3b554d5d0/src/core/detect/Engine.js |
| 13:24 | <foolip> | sorry Gecko, you don't get to remove XULControllers, whatever that is |
| 13:24 | <foolip> | although this one did have a fallback that may work, I don't know |
| 13:25 | <jgraham> | That sounds like a thing we tried to remove and couldn't because of UA detection |
| 13:25 | <foolip> | I found it because of WebKitPoint, a recent removal I'm hoping won't get reverted because of nonsense like this |
| 13:25 | <Domenic> | IE mobile' strategy is a nice try though, I must say. I love how on my phone simultaneously a bunch of sites looked a lot better, and a bunch of sites started offering "install app from the Google Play Store" buttons. |
| 13:30 | <Ms2ger> | foolip, yeah, we tried to remove it, there's a shim in its place |
| 14:29 | <annevk> | hsivonen: baby steps, seems like |
| 14:47 | <zcorpan> | wait... standard markdown has processing instructions and CDATA blocks? |
| 14:50 | <jgraham> | ?! |
| 14:53 | <jgraham> | Oh I guess "PIs" are for PHP |
| 14:54 | <zcorpan> | yeah. and CDATA for "XHTML" probably |
| 14:54 | <jgraham> | Because obviously using markdown to generate PHP to generate HTML is sensible |
| 14:55 | <jgraham> | Pretty sure that it should be a requirement that if you use either of those features the markdown processor will uninstall itself from your system, or refuse to grant you further access (if remotely hosted) |
| 14:56 | <caitp> | hah |
| 15:20 | <zcorpan> | Hixie_: looking at web-apps-tracker, maybe we should drop google-gears and add blink? or is "opera" code for blink now? :-) |
| 15:25 | <Ms2ger> | Heh, google gears |
| 15:25 | <ondras> | q |
| 15:25 | <ondras> | oops typo. |
| 15:26 | <zcorpan> | annevk: i don't follow how web-apps-tracker works :-( |
| 16:08 | <Hixie_> | hsivonen: i believe i tried to get your feedback on all those issues, fwiw :-) |
| 16:11 | <annevk> | zcorpan: what do you need guidance on? |
| 17:18 | Sample | thinks if anyone is trying to grab a filename from a file inputs value attribute their code -should- break/be inherently considered broken |
| 17:33 | <jgraham> | Sample: That's a fine thing to think, but if your bank is doing it, browsers change their behaviour, and you lose access to your account in a way that costs money, it feels like you aren't going to go "oh my bank had inherently broken code, so this is quite a reasonable outcome" |
| 17:44 | <Sample> | jgraham: yeah, unfortunately as well they had followed a specification at some point when they wrote that =/ sad |
| 17:44 | <Sample> | this must be the story of your guys' life |
| 18:15 | <caitp> | annevk, what if we had a way to do a better job of url resolution? like, a base content attribute for any elent, which if specified, would use a base tag with an appropriate id |
| 18:16 | <caitp> | (and by default, would use the first <base> tag in the document, or the usual url resolution procedure) |
| 18:17 | <caitp> | or maybe even automatically figuring out which base to use based on the element type or namespace or something |
| 18:20 | <caitp> | i'm just throwing ideas around, but it really sucks that you can only have one base that applies to all types of content :( |
| 18:28 | <annevk> | there was xml:base, but it was pretty terrible perf-wise and not really implemented well |
| 18:28 | <annevk> | in any event, you should start with use cases |
| 18:31 | <caitp> | well, the use cases are many, but there are some big ones --- SPA frameworks tend to give a second meaning to <base> tags, and unfortunately angular now requires it (the alternative was just too problematic for browsers that didn't support history), so people now have issues because they need to use one <base> for angular, and then have to specify all of their other content using fully qualified URIs |
| 18:32 | <caitp> | but I mean, I've had other use cases for it myself, like just generally needing to look for assets on a different domain while generally using the current domain and default base for everything else |
| 18:32 | <caitp> | fully qualified URIs kind of suck in case domain registration or other deployment details change |
| 21:02 | <mathiasbynens> | why is `<body id=b onload=b.innerHTML=1>` not equivalent to `<body onload=innerHTML=1>`? i’d expect both to set `document.body.innerHTML` to `1` |
| 21:02 | <mathiasbynens> | does the latter assign to `document.innerHTML` instead? |
| 21:07 | <Hixie_> | mathiasbynens: "this" in both cases is the global object (window) |
| 21:07 | <Hixie_> | mathiasbynens: so in the latter case you're doing window.innerHTML = 1 |
| 21:09 | <mathiasbynens> | but for inline event attributes like that there are three ‘scopes’, right? the element itself, the parent form (if any), and the global object |
| 21:11 | <mathiasbynens> | for example, <p onmouseover=innerHTML=1>. does set the innerHTML of the `<p>` to `1` on hover |
| 21:11 | <Hixie_> | mathiasbynens: <body onload> (along with several other <body> event handlers) are special cases |
| 21:11 | <Hixie_> | mathiasbynens: in that they're not body's event handlers, they're window's event handlers |
| 21:11 | <Hixie_> | mathiasbynens: but since there's no <window> element, <body> acts as a convenience proxy for them |
| 21:12 | <Hixie_> | setting body.onload or <body onload> is equivalent to setting window.onload |
| 21:12 | <mathiasbynens> | ah, that explains it – thanks Hixie_! |
| 21:12 | <Hixie_> | note that this means you can't catch an event 'load' that bubbles through a <body> element with an onload handler |
| 21:13 | <Hixie_> | which leads to funny results when your markup is <html onload="t(event)"> <body onload="t(event)"> <div onload="t(event)"> and you fire a bubbling 'load' event at the div |
| 21:13 | <mathiasbynens> | hah |
| 21:44 | <Hixie_> | TabAtkins: is there a specific spec i should reference for display: newline? I'm update the <br> default stylings per our last conversation on the matter back in july |
| 21:45 | <Hixie_> | i guess i don't actually ref specs in the rendering section's style sheets actually |
| 21:46 | <Hixie_> | TabAtkins: hm, looks like 'display-box' has gone away |
| 21:46 | <Hixie_> | TabAtkins: what property should i use for br's newline behaviour? |
| 21:49 | <TabAtkins> | Hixie_: display-box changed name to box-suppress (but it's not what you want for newline) |
| 21:49 | <TabAtkins> | Hixie_: If you're going to assume it exists, it's a display-outside value. |
| 21:50 | <Hixie_> | k |
| 21:50 | <Hixie_> | do you want me to reassign the bug to you once i've done my side? |
| 21:50 | <TabAtkins> | Sure. |
| 21:51 | <Hixie_> | k, will do. Thanks. If things change, feel free to reassign to me again. |
| 22:24 | <Hixie_> | does nobody yet implement hit regions on canvas? |
| 22:25 | <Hixie_> | i see bugs suggesting people have implemented it... |
| 22:26 | Hixie_ | wonders what he's doing wrong |
| 22:26 | <Hixie_> | cabanier: didn't you implement hit regions in mozilla at least? i can't get it to work |
| 22:26 | <Hixie_> | i found a bug where you checked code in, and that was months ago |
| 22:27 | <Hixie_> | more than a release cycle, at least |
| 22:27 | <cabanier> | Hixie_: you need to turn it on in about:config |
| 22:27 | <Hixie_> | aah |
| 22:28 | <Hixie_> | is it still buggy? |
| 22:28 | <cabanier> | canvas.hitregions |
| 22:28 | <cabanier> | Hixie_: yes. |
| 22:28 | <Hixie_> | ah, ok |
| 22:28 | <Hixie_> | cabanier: do you know anything about clearHitRegions() ? |
| 22:28 | <cabanier> | Hixie_: I need to finish it but keep getting pulled away. |
| 22:29 | <cabanier> | Hixie_: I didn't implement that one yet |
| 22:29 | <Hixie_> | cabanier: like, why it was proposed? i'm trying to work out if it's something i should spec. i can't work out what it's for and nobody seems to implement it. |
| 22:29 | <cabanier> | ah |
| 22:30 | <cabanier> | Hixie_: the hit regions are not removed by drawing over them so there needs to be a way to remove them from the canvas |
| 22:30 | <Hixie_> | oh this is for people who just draw opaque stuff and never clearRect() ? |
| 22:31 | <cabanier> | yes |
| 22:31 | <Hixie_> | and it just clears the entire list? |
| 22:31 | <cabanier> | Hixie_: a clearRect on the entire canvas should have the same effect |
| 22:31 | <cabanier> | yes |
| 22:31 | <Hixie_> | fair enough |
| 22:32 | <Hixie_> | seems a bit blunt but i guess why not if people don't need to call clearRect() |
| 22:32 | <cabanier> | yeah |