| 00:36 | <edburns> | I notice that HTML5 allows <object> to be submittable. What does it mean for an <object> to be submittable? What is the browser supposed to send ? |
| 00:37 | <edburns> | Hixie: I remember you from the Netscape 6 days, but I doubt you remember me. |
| 02:01 | <Hixie> | edburns: name doesn't ring a bell, but that was a long time ago :-) |
| 02:01 | <Hixie> | edburns: <object> being submittable doesn't really mean anything unless you have a plugin |
| 04:01 | <edburns> | Hixie: Thanks for the response. |
| 04:02 | <edburns> | Hixie: What about the other output-like submittable things, such as <output> and <fieldset>. Those are also submittable, but I'm not sure what the browser should do if the form in which they reside is submitted. |
| 04:04 | <edburns> | Hixie: Some more NetScape 6 names for you: Dawn Endico and Daniel Nunes, remember either of those folks, or Patrick Beard? |
| 06:30 | <dirkpennings> | somebody knows if the new posiition: sticky is coming to iOS Safari, and when? |
| 06:53 | <zcorpan> | Hixie: do i read it right that default="" now means that mode will be set to 'hidden' if it's 'disabled'? never to 'showing'? |
| 07:02 | <annevk> | Hixie: here now... |
| 07:04 | <Hixie> | edburns: fieldset and output aren't submittable, as far as i can see... where do you see that they're submittable? |
| 07:05 | <Hixie> | edburns: and yeah, i remember dawn, and the other names sound familiar |
| 07:05 | <Hixie> | zcorpan: should be set to showing if there's no better choice, and hidden otherwise. might be a mistake in the spec though. |
| 07:05 | <Hixie> | annevk: see fullscreen bug |
| 07:10 | <zcorpan> | Hixie: in http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#perform-automatic-text-track-selection i only see user pref -> showing and default="" -> hidden |
| 07:13 | <Hixie> | oops, i forgot to add the relevant line to step 4 |
| 07:15 | <Hixie> | zcorpan: ok, fixed. Note that this assumes that the requested changes to default=""'s authoring conformance requirements get made. |
| 07:19 | <zcorpan> | Hixie: now the spec makes multiple tracks showing rather than one (the first with default="") showing and the rest hidden |
| 07:19 | <Hixie> | yeah, that's intentional |
| 07:20 | <Hixie> | with metadata, multiple will be allowed |
| 07:20 | <Hixie> | and with others, it's non-conforming anyway, but we enable them all for consistency |
| 07:20 | <Hixie> | that's what i meant by the "note that this assumes..." |
| 07:21 | <zcorpan> | ok. for metadata, showing and hidden are equivalent. for the others, i'm not happy with enabling several in the automatic selection |
| 07:21 | <zcorpan> | i think metadata should be special-cased such that default always sets hidden and user pref doesn't apply to metadata |
| 07:22 | <Hixie> | what's wrong with enabling several? |
| 07:22 | <Hixie> | the author screwed up anyway |
| 07:22 | <Hixie> | who cares what happens |
| 07:23 | <zcorpan> | and the others should be 1 track based on user pref, or if there isn't one, set the first default to showing and the rest defaults to hidden |
| 07:23 | <zcorpan> | we usually do something sane even when the author screws up |
| 07:24 | <Hixie> | enabling the ones the author said to enable seems sane :-) |
| 07:24 | <Hixie> | anyway if you disagree, file a bug, mark it blocker, and drop me and e-mail to remind me to look at it pronto |
| 07:25 | <Hixie> | i've got to go to bed |
| 07:25 | <zcorpan> | ok |
| 07:28 | <annevk> | Hixie: ah, had added a comment already, sounds good |
| 07:28 | <Hixie> | zcorpan: btw, does opera have an opinion on http://www.whatwg.org/issues/#New-features--dnd-directories--awaiting-interest-from-more-vendo ? |
| 07:30 | <zcorpan> | Hixie: i don't know. i can ask our DnD people |
| 07:31 | <Hixie> | zcorpan: would be good to get input. so far it seems to be only chrome that's interested in a big API, sicking had a suggestion for a much thiner API (just expose the path in the filename), and no other vendor commented. |
| 07:32 | <sicking> | Hixie: once the B2G stuff has calmed down a bit I intend to finish up the DeviceStorage API and propose it as a generic filesystem API |
| 07:32 | <sicking> | Hixie: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI |
| 07:32 | <zcorpan> | Hixie: *my* knee-jerk sides with sicking's suggestion, but i haven't thought about this much |
| 07:32 | <Hixie> | sicking: which would be used in dnd? |
| 07:33 | <Hixie> | zcorpan: yeah, mine too (it's even easy to support empty directories, just have a file called "." in each directory, with no data) |
| 07:33 | <sicking> | Hixie: the intent is that we can then use it for DnD as well yes |
| 07:33 | <sicking> | Hixie: it's really not a whole lot more than a .get() and a .enumerate() function once you remove the functions which involve editing |
| 07:33 | <Hixie> | sicking: what does it add over your earlier suggestion of "just put the relative path in the filename"? |
| 07:34 | <sicking> | Hixie: it'll probably be an additional enumerate() function once it's finished though (for shallow enumeration) |
| 07:35 | <sicking> | Hixie: mostly it handles the probably better when someone dropps a huge directory |
| 07:35 | <sicking> | drops even |
| 07:35 | <Hixie> | how so? |
| 07:35 | <sicking> | Hixie: we really want some sort of ability for the webpage to get notified about progress of finding the full list of files |
| 07:36 | <Hixie> | sicking: not sure i'm following |
| 07:36 | <sicking> | Hixie: iirc my proposal was that .files on the "drop" event has the full list of files |
| 07:36 | <Hixie> | right |
| 07:36 | <sicking> | Hixie: in order for the UA to get that full list of files we need to enumerate the directory tree before firing the "drop" event |
| 07:37 | <sicking> | Hixie: that means that if the user drops a large directory tree, the page wouldn't see a "drop" event for, say, 30 seconds |
| 07:37 | <Hixie> | sicking: so instead you want an API that fires an event periodically as things get collected? |
| 07:37 | <sicking> | Hixie: effectively, that would to the user look like nothing happened for that long period of time |
| 07:38 | <Hixie> | well, the user agent would presumably show a progress UI |
| 07:38 | <sicking> | Hixie: I would say that in theory the UA could yes. But it's hard to do that in a way that blends together with the other UI, which is mostly the website |
| 07:39 | <Hixie> | why not just make FileList have a boolean "stillAddingFiles", and while that's true, fire progress events at that object regularly? |
| 07:40 | <sicking> | Hixie: That could also work yes. But that would be a backwards incompatible change if we just modify how .files work |
| 07:40 | <Hixie> | what would you return on .files if we didn't do that then? |
| 07:40 | <sicking> | Hixie: I don't know. Probably null and have a separate property :( |
| 07:41 | <Hixie> | that seems even less backwards compatible |
| 07:41 | <Hixie> | i agree that adding files dynamically isn't cool though... |
| 07:41 | <sicking> | yeah |
| 07:42 | <Hixie> | ah well, i'll think on it |
| 07:42 | <sicking> | Hixie: please do |
| 07:42 | <Hixie> | i'm skeptical about adding a whole ton of API essentially just for this though. |
| 07:42 | <Hixie> | right, way late for bed. |
| 07:42 | <Hixie> | nn |
| 07:42 | <sicking> | the DeviceStorage API is basically just a .get() and a .enumerate() though |
| 07:43 | <sicking> | not "a whole ton of API" |
| 07:43 | <jamesr> | how's this relate to the filesystem api? totally separate? |
| 07:43 | <sicking> | jamesr: totally separate but with the same feature set. *much* simpler and smaller API |
| 09:07 | <annevk> | Hixie: nano fails |
| 09:07 | <annevk> | nano FILENAME |
| 09:07 | <annevk> | Error opening terminal: xterm-256color. |
| 09:08 | <annevk> | Hixie: vi does not make me happy |
| 09:16 | <annevk> | Hixie: hmm fixed |
| 09:16 | <annevk> | Hixie: apparently the problem was with Mac OS Lion! |
| 09:34 | <annevk> | also weird |
| 09:34 | <annevk> | on your DreamHost server backspace is borked, on mine it works fine |
| 09:34 | <annevk> | I assume that's a Mac OS Lion problem too, but I wonder why it's so different |
| 09:34 | <jgraham> | Seems that the spec's handling og javascript URLs isn't really right |
| 09:36 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1759 <- per browsers that should say "pass" |
| 09:37 | <jgraham> | Per the spec I think it says FAIL, because the javascript url navigation aborts the earlier navigation |
| 09:38 | <jgraham> | Hixie: ^ |
| 09:52 | <annevk> | http://encoding.spec.whatwg.org/ http://fetch.spec.whatwg.org/ http://dom.spec.whatwg.org/ http://xhr.spec.whatwg.org/ http://fullscreen.spec.whatwg.org/ |
| 09:54 | <jgraham> | "Note: Web platform bytes consist of exactly eight bits" 0 as opposed to 8.1 or 7.99? |
| 09:55 | <annevk> | I don't follow |
| 09:55 | <jgraham> | The word "exactly" there seems rather unnecessary |
| 09:55 | <annevk> | I see |
| 09:57 | <jgraham> | s/0/-/ |
| 09:58 | <annevk> | jgraham: https://github.com/whatwg/encoding/commit/fe540c95535e7a299e296202637954203bf1c4cd |
| 09:59 | <jgraham> | Thank you :) |
| 12:11 | <annevk> | so should we spam @whatwg even more |
| 12:11 | <annevk> | with updates to DOM etc. |
| 12:11 | <annevk> | ? |
| 12:22 | <deane> | annevk: I'm liking these living standard specs :) Nice |
| 12:22 | <deane> | Is there a page that lists them all? |
| 12:24 | <annevk> | http://krijnhoetmer.nl/irc-logs/whatwg/20120912#l-376 ;) |
| 12:24 | <annevk> | I assume we're going to do something on spec.whatwg.org in due course |
| 12:24 | <annevk> | there's also http://mimesniff.spec.whatwg.org/ come to think of it |
| 12:25 | <deane> | cool |
| 12:26 | <deane> | Yeah I saw all those five. |
| 12:27 | <deane> | Yeah, having a list on spec.whatwg.org would be good. |
| 12:27 | <annevk> | http://html.spec.whatwg.org/ also exists |
| 12:27 | <annevk> | at some point that's going to be the official URL I think |
| 12:27 | <annevk> | but currently it has broken icons and things |
| 12:28 | <deane> | Yeah, but the html one is a mistake, it links to the wrong spec, links to the single page one |
| 12:30 | <deane> | whatwg.org/html links to the multipage spec |
| 12:31 | <deane> | So the "html" links are kinda mixed up, but perhaps it doesn't matter. |
| 13:35 | <annevk> | deane: I think we should fix URL conformance for the bug in fetch.spec.whatwg.org :) |
| 13:35 | <annevk> | deane: and as I'm going to fix URLs... |
| 13:36 | <deane> | Oh, I didn't really look at it too closely. |
| 13:36 | <annevk> | making [ and ] non-conforming in URL paths is just silly |
| 13:40 | <edburns> | Hixie: Thanks for your response. I incorrectly asserted that <output> and <fieldset> were submittable. You are correct to say they are not. |
| 13:42 | <darobin> | today we lament the disparition of annevk, who decided to "fix URLs" and was never seen again |
| 13:44 | jgraham | read "disapparition" which suggests too much Harry Potter |
| 13:56 | <annevk> | http://xhr.spec.whatwg.org/#interface-progressevent |
| 13:56 | <annevk> | darobin: heh, hope not :) |
| 14:06 | <zcorpan_> | for the createHTMLDocument spec change, would it be messy if i just edited http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/DOMImplementation-createHTMLDocument.html to test that? |
| 14:07 | <annevk> | I have done such a thing before |
| 14:07 | <annevk> | nobody complained |
| 14:07 | <zcorpan_> | well then |
| 14:09 | <darobin> | it's not like anybody actually looks at those tests |
| 14:09 | <jgraham> | zcorpan_: I have done that already (locally) |
| 14:09 | <jgraham> | I can push if you want |
| 14:09 | <zcorpan_> | jgraham: ah. then i won't duplicate your work |
| 14:11 | zcorpan_ | goes back to track |
| 14:12 | <annevk> | (I actually created new tests too in the Ms2ger directory; I don't get the whole division by contributor thing, we don't do that for specs either) |
| 14:12 | <jgraham> | Hmm, well I just pushed the test I wrote |
| 14:13 | <darobin> | annevk: didn't webapps agree to stop using the submissions thing? |
| 14:13 | darobin | has lost track of who's agreed to that and who hasn't |
| 14:13 | <annevk> | same here |
| 14:13 | <jgraham> | Did anyone agree to anything? |
| 14:13 | <darobin> | I suspect everyone agrees and we're just doing this out of inertia |
| 14:13 | <jgraham> | Yes, that exactly I think |
| 14:14 | <jgraham> | Although I thought it more strongly for the submitted/approved thing |
| 14:14 | <darobin> | dump everything in one directory — structure is for losers |
| 14:14 | <darobin> | we also mentioned using branches for the approved/submitted difference |
| 14:15 | <jgraham> | That would get messy quickly |
| 14:15 | <jgraham> | (branches) |
| 14:15 | <jgraham> | I mean, I like the idea |
| 14:15 | <jgraham> | But each submission would have to be its own branch |
| 14:16 | <jgraham> | And then it would be impossible to get all the tests even if they hadn't been approved |
| 14:20 | <jgraham> | (so a more sensible option would be a linear history, but a review tool that could mark certain commits as reviewed) |
| 14:20 | <jgraham> | (or certain files in certain commits) |
| 14:21 | <jgraham> | (then a file would be reviewed if it was reviewed in all the commits in its history) |
| 14:24 | <darobin> | jgraham: I wasn't thinking of having each submission in its own branch |
| 14:24 | <darobin> | that seems messy |
| 14:24 | <darobin> | I was just thinking of having master where every one would dump the tests they bring in |
| 14:24 | <zcorpan_> | +1 to review tool |
| 14:24 | <darobin> | and an approved branch where individual tests would be cherry picked to |
| 14:25 | <darobin> | so you'd have one branch with everything |
| 14:25 | <jgraham> | darobin: But then it becomes difficult to tell waht you have / haven't cherry picked |
| 14:25 | <jgraham> | all the SHA1s change |
| 14:25 | <zcorpan_> | darobin: with several release channels? :-) |
| 14:25 | <darobin> | that said, I like the idea of a review tool — the difference is that the review tool needs to be written whereas git is there :) |
| 14:26 | <darobin> | jgraham: sure, but the names don't (or shouldn't) |
| 14:27 | <darobin> | zcorpan_: several release channels, forked between WHAT and W3C, the whole thing maintained in both hg and git, with Windows line endings in some of the tests |
| 14:29 | <jgraham> | darobin: Sadly most useful git tools are designed to work with the SHA1s, not the commit messages :) |
| 14:29 | <darobin> | jgraham: yeah, we're going to have to move to a proper tooling for test management |
| 14:30 | <darobin> | I hope that HTML5 moves to CR soon, that way I can be 100% on testing, which in turn means I might be able to write such a tool |
| 14:30 | <darobin> | (to replace the current TF, which is painful to evolve to say the least) |
| 14:33 | <michel_v> | hello |
| 14:35 | <michel_v> | I just ran into an interesting problem with HTML5 and <input type="email"> with an email address on an IDN |
| 14:35 | <michel_v> | Chrome and Gecko wouldn't let us type the accents at all |
| 14:36 | <michel_v> | is it supposed to be this way (does the spec limit chars to simple ASCII?), or is it a problem with the implementation? |
| 14:36 | <beverloo> | the expression browsers are advised to use is included in the spec: |
| 14:36 | <beverloo> | http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address |
| 14:36 | <beverloo> | which indeed has a willful violation of rfc 5322 |
| 14:39 | <michel_v> | ah, so the email address should use the xn-- notation |
| 14:40 | <michel_v> | thanks beverloo |
| 14:40 | <michel_v> | that's most unfortunate |
| 14:48 | <zcorpan_> | michel_v: if the user types an email with non-ascii, the browser should convert it to ascii. rationale is that many servers likely are unable to send non-ascii emails |
| 14:49 | <michel_v> | zcorpan_: but then it should only do so on submit |
| 14:49 | <zcorpan_> | why? |
| 14:50 | <michel_v> | zcorpan_: I have a domain named "chezmémé.fr". if as a user I'm typing the domain name, it's very weird how once I type the first "é" the text becomes xn--chezm-fsa |
| 14:50 | <michel_v> | instead of "chezmé" |
| 14:50 | <zcorpan_> | michel_v: the UI doesn't need to show the ascii form |
| 14:51 | <darobin> | zcorpan_: I think that's what michel_v was hinting at when he said "only do so on submit" |
| 14:51 | <michel_v> | ah yes. so you mean that browser implementations should behave like that, ok |
| 14:51 | <zcorpan_> | (there's also a DOM API which should use the ascii form) |
| 14:53 | <zcorpan_> | there was a proposal recently about adding a .rawValue IDL attribute to form controls to expose exactly what the user typed in various controls without doing normalization like .value |
| 14:53 | <darobin> | I know, just pointing out that I think that's what he meant — it's just that the user shouldn't ever have to worry about that |
| 14:54 | <michel_v> | exactly |
| 14:54 | <zcorpan_> | k |
| 15:02 | <michel_v> | hmm. rectification: it does work in Gecko (firefox 15 at least) |
| 15:08 | <zcorpan_> | firefox doesn't seem to do the asciification in the dom api or when submitting |
| 15:08 | <zcorpan_> | opera does it for the after-@ part when submitting (but not for .value) |
| 15:09 | <zcorpan_> | chrome doesn't convert at all and doesn't allow non-ascii emails to be submitted |
| 15:12 | <michel_v> | it's amazing that after all those efforts went into supporting IDN in the address bar, browser makers did not bother with html5 parts that can use domain names :p |
| 16:08 | <zcorpan_> | [tm]: dude, you had agreed to deliver! |
| 16:08 | <Hixie> | jgraham: did you file a bug on that? |
| 16:09 | <jgraham> | Hixie: YEs. No idea which bug though |
| 16:09 | <Hixie> | thanks |
| 16:09 | <Hixie> | just wanted to make sure it didn't get lost to irc |
| 16:15 | <JonathanNeal> | Is it true that, if you have multiple rel="alternate" links in a document and want to specify which one should be considered the default for that page, you can add a type (type="application/atom+xml" or type="application/rss+xml") to that link and remove it from the others? |
| 16:17 | <Hixie> | JonathanNeal: rel="alternate" has various purposes, which purpose are you talking about here specifically? different versions for print vs mobile vs desktop? different languages? html vs pdf vs rss feed? |
| 16:18 | <Hixie> | (afk) |
| 16:18 | <JonathanNeal> | http://blog.whatwg.org/feed-autodiscovery |
| 16:18 | <JonathanNeal> | So, like, could you have three rel="alternate" links on your page, but set the second one as the default feed by specifying its type and not setting a type for the first link? |
| 16:20 | <zcorpan_> | Hixie: how are auto and 100 equivalent? https://www.w3.org/Bugs/Public/show_bug.cgi?id=16917 |
| 16:24 | <dglazkov> | good morning, Whatwg! |
| 16:29 | <Hixie> | JonathanNeal: the ones that don't have the type="" aren't considered feeds |
| 16:29 | <Hixie> | JonathanNeal: see http://www.whatwg.org/specs/web-apps/current-work/#rel-alternate |
| 16:30 | <Hixie> | zcorpan_: when snaptolines is false, isn't it true? |
| 16:30 | <JonathanNeal> | Got it, thanks. Just trying to address some issues in diveintohtml5 git. |
| 16:31 | <JonathanNeal> | Is wrapping the type attribute value in single quotes still best practice? e.g: type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'? |
| 16:31 | <Hixie> | single quotes, or double quotes |
| 16:32 | <Hixie> | or no quotes if there's no spaces and stuff in the value |
| 16:32 | <Hixie> | :-) |
| 16:32 | <zcorpan_> | Hixie: i thought an invalid state would get rendered as if the line webvtt setting was absent, i.e. snapToLine = true; line = 'auto' |
| 16:32 | <Hixie> | zcorpan_: oh, hm, i think the way i wrote it i only ignore the line number maybe |
| 16:32 | <JonathanNeal> | Well, the value has double quotes inside. |
| 16:33 | <Hixie> | JonathanNeal: then yeah, single quotes is prettier. you can also you " for the double quotes. this is for <source type> ? |
| 16:33 | <JonathanNeal> | Unless we can use single quotes for codecs='avc1..." |
| 16:33 | <JonathanNeal> | Yes, it's for source. |
| 16:33 | <Hixie> | i think that has to be double quotes, but you'd have to check the rfc |
| 16:33 | <zcorpan_> | Hixie: i'll reopen :-) |
| 16:33 | <Hixie> | zcorpan_: thanks |
| 16:33 | <JonathanNeal> | the rfc? |
| 16:33 | <Hixie> | zcorpan_: this is why lots of detail in bugs is good btw :-P |
| 16:33 | <Hixie> | JonathanNeal: for the codecs="" parameter |
| 16:34 | <jgraham> | Hixie: (Bug 18854 FWIW) |
| 16:36 | <JonathanNeal> | I'm sorry, Hixie. I don't know what that is. I tried finding it with Google and failed. Could you help me? |
| 16:38 | <zcorpan_> | Hixie: yeah, it's just that finding the right solution is a process of balling different ideas (notice how we ended up with the opposite of what i first suggested). giving lots of detail in the first iteration would be wasted time :-) |
| 16:38 | <JonathanNeal> | I think this might be it? http://tools.ietf.org/html/rfc4281 |
| 16:38 | <Hixie> | JonathanNeal: that sounds like the right number; should be a link to it from the relevant part of the spec |
| 16:38 | <Hixie> | zcorpan_: yeah, i know :-) |
| 16:38 | <Hixie> | zcorpan_: no worries |
| 16:39 | <Hixie> | zcorpan_: i just don't like yanking you around through my various mistakes :-) |
| 16:39 | <Hixie> | brb |
| 16:39 | <zcorpan_> | it's OK :-) |
| 16:45 | <JonathanNeal> | "Note that, per [MIME-Format], some characters (including the comma used to separate multiple values) require that the entire parameter value be enclosed in quotes." So, in plain English, using a comma requires wrapping codecs in double quotes? |
| 16:47 | <JonathanNeal> | I guess it doesn't specify double quotes. In fact, it never specifies double quotes. |
| 17:01 | <jgraham> | Er, what the hell GEcko |
| 17:01 | <jgraham> | Write 3 tests, all pass |
| 17:01 | <jgraham> | Write a fourth test in the same page, first two tests now fail |
| 17:02 | <jgraham> | (this does not happen in other browsers) |
| 17:02 | <JonathanNeal> | But when I tested this in Opera, Firefox, Chrome, and Safari; single quotes failed, double quotes worked, and no quotes worked. |
| 17:02 | <JonathanNeal> | And I tested codecs which used a "." |
| 17:03 | <jgraham> | OK, so there seems to be a race condition |
| 17:04 | <jgraham> | But someone just started practising the drums, so I guess it is time to go home |
| 17:25 | <Hixie> | jgraham: that test is weird. the JS does run, but it's like the browser is ignoring the result. |
| 17:31 | <Hixie> | jgraham: maybe the .submit() is queued? |
| 17:31 | <Hixie> | hm, the script doesn't run in gecko or opera, actually |
| 17:32 | <Hixie> | that's easier to spec... |
| 17:32 | <Hixie> | what does IE do on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1760 ? |
| 17:39 | <say2joe> | IE doesn't support addEventListener… code breaks there in IE8 |
| 17:39 | <say2joe> | Line 6 |
| 17:39 | <Hixie> | IE still doesn't do addEventListener? |
| 17:39 | <Hixie> | jeez |
| 17:39 | <say2joe> | well, i'm testing in IE8 |
| 17:39 | <Hixie> | (thanks anyway) |
| 17:39 | <Hixie> | ah, right |
| 17:39 | <Hixie> | i guess maybe IE9 does it? |
| 17:40 | <say2joe> | sure…. i've got 4 VMs for different IEs… let me know if you want another test. |
| 17:40 | <gsnedders> | Hixie: IE9 does |
| 17:40 | <Hixie> | i'm guessing the test still won't work in IE due to the data: URLs anyway |
| 17:40 | <Hixie> | i'll just have to fire up my own VMs instead of being lazy :-) |
| 17:41 | <Hixie> | or i'll just comment on the bug and have jgraham test it :-P |
| 17:43 | <say2joe> | Hixie: sorry … trouble with my VM. like gsnedders said… IE9 added support but the earlier ones make you attach |
| 17:43 | <say2joe> | @Hixie good idea… i just hung my Mac for a sec :) |
| 17:51 | <jgraham> | Hixie: I can't check IE until tomorrow |
| 17:52 | <jgraham> | And the script running but the result being discarded is sort of what I would expect, since it is the result that is the navigate part |
| 17:54 | <jgraham> | (I wouldn't trust alert for debuging in this case since browsers can be weird about alert around navigations) |
| 17:55 | <Hixie> | (http://korystamper.wordpress.com/2012/09/07/were-all-mad-here/ makes me feel a lot better about our own nutballs) |
| 17:55 | <Hixie> | jgraham: true |
| 17:56 | <Hixie> | jgraham: though since it's usually webkit that doesn't fire the alerts... :-) |
| 18:01 | <jgraham> | Actually I guess I lie |
| 18:01 | <jgraham> | The script not running at all seems more logical |
| 18:12 | <gsnedders> | > logical |
| 18:12 | <gsnedders> | > IE |
| 18:17 | <Hixie> | i think jgraham's main mistake is trying to find logic anywhere near the navigation algorithm |
| 18:17 | <gsnedders> | Oh, I heard enough rambling madness from him while I was in Lkpg a few weeks back. :) |
| 18:18 | <Hixie> | can someone explain to pillar that i can't work if she's lying in front of the keyboard being all cute |
| 18:19 | <gsnedders> | No. She's a cat. This makes that difficult. |
| 18:19 | <Hixie> | lol she just fell off the table trying to be even cuter |
| 18:19 | <gsnedders> | Girls are nothing but silliness! |
| 18:24 | <Hixie> | i don't think this is a gender thing. my boy cat is just as silly, if not more so |
| 18:25 | <Hixie> | sicking: could enumerating be slow even without directories? e.g. i drag 1000 files into a web page, all from the same directory, does that need to be async too? |
| 18:25 | <Hixie> | sicking: or does the problem only occur if you have at least one directory at the top level? |
| 18:26 | <sicking> | Hixie: even dragging 1000 files can be slow since we have to stat them all to get their size |
| 18:26 | <Hixie> | ok, so this isn't really about directories per se |
| 18:26 | <Hixie> | interesting |
| 18:26 | <sicking> | Hixie: but it's less of a problem i think |
| 18:30 | <gsnedders> | Hixie: Sarcasm explains many things. |
| 18:34 | <annevk> | Hixie: have you filed that thread on Referer? |
| 18:34 | <Hixie> | filed? thread? what? |
| 18:34 | <annevk> | Hixie: because it requires changing the fetch algorithm; once that's done I can update XMLHttpRequest |
| 18:35 | <annevk> | Hixie: http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0750.html in particular |
| 18:37 | <odinho> | Hm. My Win8 vbox stopped working. Bug or intended? Guess I will never know. It's just a preview after all. Still, no more IE10 testing. |
| 18:38 | <Hixie> | annevk: i guess we can be more explicit, like with the origin |
| 18:39 | <sicking> | annevk: did i miss any APIs which are currently intended to fall into the "from API" branch? I assume that .removeChild or .offsetTop isn't intended to fall into the "from API" branch, even though that's currently not clear |
| 18:39 | <sicking> | err |
| 18:39 | <sicking> | Hixie: ^ |
| 18:39 | <Hixie> | sicking: it's easy to tell what triggered the load. It's the algorithm that called "fetch". |
| 18:40 | <Hixie> | sicking: so for background-image, it's CSS that calls it (ok right now those specs aren't actually calling fetch, but that's a CSS issue) |
| 18:40 | <sicking> | Hixie: hmm.. i guess that makes sense |
| 18:40 | <Hixie> | sicking: (the intent is clear, i think) |
| 18:40 | <Hixie> | sicking: for APIs that call fetch, it's the API, and thus you use entry script |
| 18:40 | <sicking> | Hixie: though for CSS the referer isn't one of any Document. At least in Gecko |
| 18:41 | <Hixie> | sicking: yeah, for CSS maybe it's underdefined. Right now CSS doesn't call "fetch" at all. |
| 18:41 | <Hixie> | sicking: so arguably, it's not relevant here, and how networking works in CSS is an issue for www-style. |
| 18:41 | <Hixie> | sicking: though of course if they want to use "fetch" i'm sure anne and i would be happy to help |
| 18:41 | <sicking> | Hixie: i really don't think we'll want to use "entry script" ever. The fact that we ever do in Gecko is historical accident more than anything |
| 18:41 | <Hixie> | (eventually we plan to move "fetch" to its own spec and merge it with cors) |
| 18:42 | <annevk> | CSS must use fetch eventually |
| 18:42 | <Hixie> | sicking: "entry script" is used all over the place. i don't think that's likely to change. |
| 18:42 | <annevk> | http://fetch.spec.whatwg.org now has a note to that effect btw |
| 18:42 | <annevk> | yay productivity :p |
| 18:43 | <Hixie> | sicking: though if you have any specific cases where you think that should change, i'm happy to look at them |
| 18:43 | <Hixie> | annevk: btw when i created the domains i updated whatwg.org/specs |
| 18:43 | <annevk> | oh sweet |
| 18:43 | <annevk> | guess I should put a placeholder in url.spec.whatwg.org then |
| 18:43 | <Hixie> | :-) |
| 18:44 | <Hixie> | sicking: anyway, i guess we can be more explicit about the referrer |
| 18:44 | <Hixie> | sicking: but that's a lot of boilerplate text in a lot of places in the spec |
| 18:45 | <Hixie> | sicking: which is why i'd rather not |
| 18:45 | <sicking> | Hixie: ok |
| 18:45 | <sicking> | Hixie: i think it's mostly the "from APIs" that's wrong/ambigious right now |
| 18:47 | <annevk> | Hixie: could have a Document override |
| 18:47 | <Hixie> | yeah |
| 18:47 | <annevk> | that would be easy for XHR, dunno about window.location / Workers / ... |
| 18:48 | <annevk> | I wish we had less variables dangling around actually, not more |
| 18:49 | <jgraham> | Hixie: I don't particularly desire sanity from the navigation algorithm, just web compat and implementability |
| 18:50 | <jgraham> | (this particular case seems to have web-compat implications) |
| 18:52 | <jgraham> | 'IETF RFC's, PROPOSED STANDARDs, and a useful definition of "standard" have roughly the same relationship as potato chips and a bucket of weasels' |
| 18:52 | <jgraham> | ( http://www.reddit.com/r/programming/comments/zq17h/its_opus_it_rocks_and_now_its_an_audio_codec/c675pgb ) |
| 18:55 | <annevk> | it's not even proposed |
| 18:55 | <annevk> | it's just an RFC |
| 18:55 | <annevk> | oh wait, I guess that does make it proposed |
| 18:57 | <othermaciej> | IETF's process is still better than W3C's |
| 18:57 | <Hixie> | that is entirely not clear |
| 18:58 | <Hixie> | websockets went from ok to a disaster when it went from w3c to ietf |
| 18:58 | <othermaciej> | W3C's REC means "we may have done some testing and maybe someone thinks they can implement it, but now it can never change" |
| 18:58 | <Hixie> | no it doesn't |
| 18:58 | <Hixie> | look at XML |
| 18:58 | <othermaciej> | heh |
| 18:59 | <othermaciej> | ok, maybe it's that "unless the Director says otherwise" |
| 18:59 | <Hixie> | (or HTML, or SVG, or CSS) |
| 18:59 | <Hixie> | (or DOM) |
| 18:59 | <arunranga> | *sigh |
| 19:00 | <Hixie> | othermaciej: i don't think the director had any ability to stop HTML4 from changing, that was market forces. |
| 19:01 | <othermaciej> | I guess my beef is that there's an expectation that every spec should go to REC and that REC should be scheduled, in contrast with IETF STD which is supererogatory and applied well after the WG's work is done |
| 19:01 | <othermaciej> | thus, while an RFC has little actual credibility, I think STD does, and REC claims to be like STD but is more like RFC |
| 19:02 | <Hixie> | STD has theoretical credibility, but look at what has actually gone to STD |
| 19:02 | <Hixie> | e.g. URL syntax, whose specs are still a disaster |
| 19:03 | <annevk> | yeah, URLs are a good example as to why STD also fails (or maybe the exception, but I doubt it) |
| 19:03 | <jgraham> | I think IETF and W3C both have enough process problems to be getting on with |
| 19:04 | <Hixie> | most of the other STDs are outside my area of expertise so i don't know enough about them to comment |
| 19:04 | <Hixie> | but the URL one is clearly bogus |
| 19:05 | <annevk> | apparently ABNF is an STD... http://tools.ietf.org/html/std68 |
| 19:05 | <annevk> | and utf-8 http://tools.ietf.org/html/std63 |
| 19:06 | <Hixie> | utf-8 is pretty solid, though i think it went to std before defining error handling iirc |
| 19:06 | <annevk> | yeah, they don't define exact error handling |
| 19:06 | <annevk> | http://encoding.spec.whatwg.org does... |
| 19:07 | <annevk> | btw, in the course of 10 years, there's only 10 or so STDs |
| 19:08 | <annevk> | well, the first 60 took a little over five years... |
| 19:08 | <annevk> | I guess people figured out they were not worth the effort |
| 19:13 | <Hixie> | annevk: ok i need "cross-origin request" to be callable "using a document" (see new definiton of /fetch/ in a few minutes) |
| 19:15 | <Hixie> | sicking: ok, see if the spec makes sense now |
| 19:16 | <Hixie> | (i think technically i changed the referrer you use for workers...) |
| 19:17 | <Hixie> | (in the case of one iframe's script invoking a script in another iframe that then creates a worker) |
| 19:17 | <Hixie> | (the referrer is now the same as the document that owns the worker, not the first iframe's) |
| 19:19 | <a-ja> | Hixie" is this typo or am I confuzzled? |
| 19:19 | <sicking> | Hixie: the spec still says "The entry script's document.". The "entry script" issue aside, I don't see how that statement can ever be correct for workers |
| 19:19 | <a-ja> | Vorbis audio alone in Ogg container<source src='audio.ogg' type='audio/ogg; codecs=vorbis'> |
| 19:19 | <sicking> | Hixie: when a worker does an XHR request, we should use the URL of the worker as the referer, not the URL of any Document |
| 19:20 | <Hixie> | sicking: oh you want the referer of a worker to be the .js file of the worker?? |
| 19:20 | <Hixie> | sicking: interesting! |
| 19:20 | <sicking> | Hixie: indeed |
| 19:20 | <a-ja> | Hixie: should file ext be .oga ? |
| 19:20 | <Hixie> | sicking: that's a normative change, i thought this was an editorial issue |
| 19:20 | <sicking> | Hixie: there's both |
| 19:20 | <Hixie> | a-ja: extensions are meaningless, it could be .mp3 without being any less accurate |
| 19:21 | <Hixie> | a-ja: but as it happens, for whatever reason, people generally use .ogg for vorbis audio files |
| 19:21 | <a-ja> | true enough....but think it's what's recommended |
| 19:21 | <a-ja> | .oga that is |
| 19:22 | <Hixie> | sicking: that's a much bigger change, ok. let me ponder it. |
| 19:22 | <sicking> | Hixie: i'm also not seeing anything that you actually changed. It's still not clear to me that "When fetching resources in response to a call to an API" means "when this fetch algorithm was invoked by a spec which defines a javascript API that isn't related to elements or navigation" |
| 19:22 | <Hixie> | sicking: the text "When fetching resources in response to a call to an API" is gone |
| 19:22 | <sicking> | for some definition of "javascript API" |
| 19:23 | <Hixie> | (not in multipage yet since it's not yet checked in) |
| 19:23 | <sicking> | ah |
| 19:23 | <Hixie> | sicking: i guess this means that we should introduce a "the script's referrer" concept, and pass that to fetch... |
| 19:24 | <Hixie> | ugh |
| 19:24 | <Hixie> | annevk: disregard earlier request, this is gonna have to change |
| 19:25 | <annevk> | Hixie: so yeah, the idea was e.g. for XMLHttpRequest to no longer use the entry script but instead use the address from the Document associated with the XMLHttpRequest object |
| 19:25 | <annevk> | (or in case of Workers something else) |
| 19:25 | <annevk> | which would indeed be a change |
| 19:25 | <Hixie> | this is a much more invasive change, yeah. the fetch algorithm is all based on having a document for the referrer. |
| 19:26 | <Hixie> | it seesm weird to me that a js file could be a referrer |
| 19:26 | <Hixie> | is the css file the referrer when you have an image in css? |
| 19:27 | <sicking> | Hixie: i assume the "worker's Documents" concept is somehow involved in defining the referer for workers right now (too complex for me to dive into)? |
| 19:28 | <annevk> | would make sense... (famous last words) |
| 19:28 | <Hixie> | sicking: scripts in workers have a "the script's document" just like all scripts, yes |
| 19:28 | <sicking> | Hixie: yes, the css file is the referrer when fetching @import css and backgrounds etc |
| 19:28 | <Hixie> | huh |
| 19:28 | <Hixie> | i had no idea |
| 19:28 | <Hixie> | ok |
| 19:28 | <Hixie> | can you file a bug on this? it's gonna need more work than the quick fix i thought this would be. |
| 19:29 | <sicking> | where? |
| 19:29 | <Hixie> | whatwg.org/newbug |
| 19:29 | <annevk> | Hixie: I think what we want is a referer override |
| 19:29 | <Hixie> | annevk: yeah |
| 19:29 | <annevk> | to either omit or set the referer to a value |
| 19:29 | <Hixie> | annevk: and then skip a bunch of the algorithm if there is one |
| 19:30 | <annevk> | and CSS could just define "CSS fetch" where they predefine the referer override and such |
| 19:30 | <Hixie> | yeah |
| 19:31 | <Hixie> | we're gonna need the cors algorithms to also pass this override through |
| 19:33 | <annevk> | sicking: please cc me on the bug |
| 19:35 | <a-ja> | scope style any concern here? |
| 19:35 | <a-ja> | scoped |
| 19:39 | <Hixie> | hober: does this issue-204 thing that so much e-mail has been written about actually affect the whatwg spec in any way? even tbl is getting involved now |
| 19:39 | <TabAtkins> | Hixie: Let me know what I'd have to do regarding 'fetch' to make things sane, and I can make edits where appropriate. |
| 19:41 | <Hixie> | TabAtkins: basically any time css says to turn a URL into a resource, it needs to say what the Referer should be, whether to set an Origin:, how to handle redirects, what to do with cookies, how to handle async data, etc. For most purposes, just invoking the HTML algorithm's "fetch" is sufficient. |
| 19:41 | <Hixie> | HTML spec's "fetch" algorithm, even |
| 19:42 | <Hixie> | oh, christ |
| 19:43 | <Hixie> | EventSource inside a srcdoc |
| 19:43 | <Hixie> | it needs to use the Document of the parent |
| 19:43 | <Hixie> | i don't want EventSource's fetch to know that |
| 19:43 | <Hixie> | annevk: we're gonna have to make this be either a URL or a Document |
| 19:44 | <annevk> | CSS needs URL |
| 19:45 | <Hixie> | yeah |
| 19:45 | <annevk> | and saying document's address rather than document is not too hard for the few times this matters |
| 19:45 | <annevk> | ooh, you're saying you want both |
| 19:45 | <Hixie> | yes |
| 19:45 | <annevk> | meh |
| 19:45 | <Hixie> | but i don't know which i even want when i'm in the EventSource constructor |
| 19:45 | <Hixie> | since EventSource can be in srcdoc, in iframe, or in worker |
| 19:46 | <annevk> | so can XMLHttpRequest |
| 19:46 | <Hixie> | er, s/in iframe/in top-level/ |
| 19:46 | <Hixie> | right |
| 19:46 | <Hixie> | we need an abstract "referer concpt" |
| 19:46 | <Hixie> | concept |
| 19:46 | <Hixie> | that scripts can have |
| 19:46 | <Hixie> | which either points to their document or to a url |
| 19:46 | <Hixie> | except even that doesn't work for xhr |
| 19:47 | <Hixie> | since you need a special doc for that one, not the entry script |
| 19:47 | <Hixie> | lordy |
| 19:48 | <Hixie> | annevk: describe what you want for xhr again? |
| 19:48 | <annevk> | Worker URL inside workers |
| 19:48 | <annevk> | Associated document object's url for the normal context |
| 19:49 | <annevk> | I have not thought about the srcdoc case, didn't know it was special |
| 19:49 | <Hixie> | what document is the associated document object when in a worker? |
| 19:49 | <annevk> | there's none |
| 19:49 | <Hixie> | hm |
| 19:49 | <annevk> | the document is mostly used to determine the base URL and origin |
| 19:49 | <Hixie> | (srcdoc is special because otherwise you'll get about:srcdoc as the url) |
| 19:49 | <annevk> | and for workers they're set specifically |
| 19:49 | <Hixie> | aah, you already hard-code workers? |
| 19:49 | <annevk> | workers hardcodes XHR |
| 19:50 | <Hixie> | good to know |
| 19:50 | <annevk> | but XHR could have an associated XHR referer URL |
| 19:50 | <annevk> | that workers could set |
| 19:50 | <annevk> | and is used for fetching |
| 19:50 | <annevk> | that would basically be the same thing as we have now |
| 19:50 | <annevk> | for origin and the base URL |
| 19:50 | <Hixie> | ok |
| 19:50 | <Hixie> | let me stew for a minute |
| 19:50 | <annevk> | i might stew until tomorrow :) |
| 19:51 | <annevk> | ttyl |
| 19:51 | <Hixie> | if i just define a "referrer source" concept that is either a doc or a url |
| 19:51 | <Hixie> | and xhr has a way for me to set the referrer source |
| 19:52 | <Hixie> | and scripts have a "the scripts' referrer source" |
| 20:01 | <Hixie> | sicking: workers whose urls are data: URLs. What Referer should we use? nothing? the data: URL? |
| 20:05 | <annevk> | already use no referer if there's tuple origin |
| 20:05 | <annevk> | if there's no tuple origin |
| 20:05 | <annevk> | so I think we should do that here too |
| 20:06 | <Hixie> | annevk: well, origin is different that url, for workers |
| 20:06 | <Hixie> | annevk: and for everyone else for that matter |
| 20:06 | <Hixie> | annevk: data: documents ofter have a real origin that's not data: |
| 20:06 | <Hixie> | often |
| 20:06 | <annevk> | fair enough |
| 20:07 | <annevk> | but leaking data URLs seems somewhat dangerous |
| 20:07 | <annevk> | although I guess workers cannot really make many interesting requests except with XMLHttpRequest |
| 20:08 | <annevk> | but it also seems like a huge bandwidth waste for little benefit |
| 20:08 | <Hixie> | yeah i am thinking we should just drop data: URL referrers |
| 20:17 | <sicking> | Hixie: good question |
| 20:17 | <sicking> | Hixie: the data: url is certainly the wrong answer |
| 20:17 | <sicking> | Hixie: gut instinct is the URL of the opening document. |
| 20:18 | <sicking> | Hixie: which unfortunately introduces a fair amount of complexity |
| 20:18 | <Hixie> | my gut instinct is the empty string |
| 20:18 | <Hixie> | but maybe i'm more intuitively scared of complexity :-P |
| 20:18 | <hober> | Hixie: re: your question earlier, i'll file a bug on your side once things settle down |
| 20:18 | <Hixie> | hober: ok, thanks. |
| 20:19 | <Hixie> | hober: (then we can have the fight all over again with a different result ;-) ) |
| 20:20 | <hober> | heh |
| 20:48 | <jsbell> | Who let Ms2ger log off? grrrr. |
| 20:57 | <jgraham> | jsbell: Supposedly he went on holiday |
| 20:57 | <jgraham> | But we think he might just be rebooting |
| 20:57 | <jgraham> | (fsck takes a long time) |
| 20:58 | <jsbell> | Ah well, nothing urgent, just an IndexedDB edge case he uploaded a test for but there's no spec language or bug about it. |
| 23:06 | <Hixie> | heh, i hadn't thought about the referer for the actual script of the worker |
| 23:25 | <deane> | Hixie: Have you been involved with the mime-type registration(s) or has the w3c taken care of that area? |
| 23:34 | <deane> | Hixie: It's just that a long time ago you were having a conversation with someone about the syntax for XHTML served as text/html not being XHTML but being HTML (and I agree with you on that btw). This particular person didn't agree with you and you said something like, "don't worry it will all become clear when we update the mime-type registrations." It just made me think that you were going... |
| 23:34 | <deane> | ...to do something at this update time and I just wondered if you had done it? Does that make sense? :) |