2012-09-01
[17:27:35.0000] <TabAtkins>
Hixie: Is this better (for :read-only) http://dev.w3.org/csswg/selectors4/#rw-pseudos

[18:04:11.0000] <Hixie>
TabAtkins: so all elements match one or the other?

[18:04:31.0000] <Hixie>
TabAtkins: what should type=radio match? it's neither user-alterable, nor read-only...

[18:05:13.0000] <Hixie>
TabAtkins: (also if you could make user-alterable some sort of obvious hook, e.g. give it an ID and make it italics or bold or something (<dfn>), that'd be ideal)

[18:07:45.0000] <othermaciej>
Hixie: I'm thinking about implementing srcset and I have a question about the spec

[18:07:53.0000] <Hixie>
othermaciej: shoot

[18:07:59.0000] <othermaciej>
(since I actually have free time to code this weekend)

[18:08:16.0000] <othermaciej>
ok, if an image has both src and srcset set, and src appears first textually

[18:08:36.0000] <Hixie>
(the order doesn't matter)

[18:08:42.0000] <othermaciej>
if the parser treats this as the src attribute being added and then the srcset attribute being added

[18:08:44.0000] <Hixie>
(attribute order never matters)

[18:08:59.0000] <othermaciej>
then the obvious consequence is that the load for the src resource will be initiated first

[18:09:00.0000] <Hixie>
the HTML parser is defined as adding all the attributes simultaneously

[18:09:04.0000] <othermaciej>
is that wrong?

[18:09:05.0000] <othermaciej>
ok

[18:10:06.0000] <Hixie>
hence the "or both" in: "A user agent that obtains images immediately must synchronously update the image data of an img element whenever that element is created with a src attribute, a srcset attribute, or both."

[18:16:42.0000] <othermaciej>
thanks

[18:19:14.0000] <othermaciej>
Hixie: I think WebKit probably has quite a few bugs in cases where that matters

[18:19:35.0000] <othermaciej>
Hixie: hmm, on second thought, maybe not

[18:19:50.0000] <othermaciej>
sorry for the noise

[18:20:06.0000] <othermaciej>
it looks like we set them all, then process one at a time, but each attribute when processed checks if the relevant others have been set

[19:39:09.0000] <othermaciej>
man, if building wasn't so slow I'd be done implementing srcset by now (at least the subset handling resolution descriptors only)

[20:02:25.0000] <Hixie>
othermaciej: yeah, i've actually seen cases of browsers having bugs due to the attribute order mattering in practice

[20:02:36.0000] <Hixie>
othermaciej: surprisingly few, all things considered

[20:02:57.0000] <othermaciej>
I think I misinterpreted our code (though I certainly wouldn't promise we are bug-free in this area)

[20:10:42.0000] <TabAtkins>
Hixie: Yeah, it's either/or.  This was based off the HTML definition. ^_^

[20:11:04.0000] <TabAtkins>
type=radio I'd consider user-alterable.  You can alter the checkedness, which is *like* it's content.

[20:32:39.0000] <cabanier1>
hixie: ping

[20:33:40.0000] <cabanier1>
I saw that you replace 'any' with a union in the Canvas spec

[20:35:36.0000] <cabanier1>
I think that that will change the behavior

[20:38:43.0000] <Hixie>
TabAtkins: html's was based on css' old one, that's why i asked fantasai to change it :-)  there's some bug about it

[20:38:52.0000] <Hixie>
cabanier1: sounds plausible

[20:38:59.0000] <Hixie>
cabanier1: which change in particular?

[20:39:59.0000] <cabanier1>
[e] (0) Clean up some IDLs that use 'any' to specify the exact type instead, and clean up some surrounding markup

[20:40:00.0000] <cabanier1>
Fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=17952

[20:40:00.0000] <cabanier1>
Affected topics: Canvas, DOM APIs, Microdata

[20:40:00.0000] <cabanier1>
git-svn-id: http://svn.whatwg.org/webapps@7260 340c8d12-0b0e-0410-8428-c7bf67bfef74

[20:40:39.0000] <Hixie>
what behaviour would it change?

[20:41:20.0000] <cabanier1>
if you pass it something that can't be converted to a string, you will get a type error.

[20:41:29.0000] <cabanier1>
while it should ignore it instead

[20:41:52.0000] <Hixie>
what can't get converted to string?

[20:42:21.0000] <cabanier1>
the argument you pass to strokestyle/fillstyle

[20:42:37.0000] <Hixie>
do you have a concrete example of some code that would change behaviour?

[20:42:50.0000] <Hixie>
sorry i'm having trouble understanding

[20:44:15.0000] <cabanier1>
let's say you pass in an object that implements its own 'tostring' method that returns a csscolor

[20:44:38.0000] <cabanier1>
with your change, you can pass in that object and it will be accepted

[20:45:01.0000] <Hixie>
like   context.fillStyle = { toString: function () { return 'blue' } }; ?

[20:45:23.0000] <cabanier1>
yes

[20:45:58.0000] <Hixie>
yeah, that would have been ignored before but is now treated properly, right?

[20:45:59.0000] <cabanier1>
the wording doesn't allow that

[20:46:18.0000] <cabanier1>
that's true

[20:46:31.0000] <cabanier1>
I guess the prose should change

[20:46:44.0000] <cabanier1>
and we should try if it is allowed

[20:46:57.0000] <Hixie>
what prose? it all looks right to me...

[20:47:35.0000] <cabanier1>
"The style can be either a string containing a CSS color, or a http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasgradient or http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvaspattern object"

[20:48:08.0000] <Hixie>
oh the non-normative text

[20:48:14.0000] <Hixie>
yeah i guess the next sentence is wrong, huh

[20:48:52.0000] <Hixie>
oh, no

[20:48:54.0000] <Hixie>
it's still true

[20:49:01.0000] <Hixie>
because strings that don't parse as css colors are still ignored

[20:49:01.0000] <cabanier1>
I'm still trying to understand the WedIDL stuff...

[20:49:16.0000] <cabanier1>
yes. That's true

[20:49:39.0000] <cabanier1>
so, you can set an object. But when you look at the value, you would get a string back

[20:49:57.0000] <Hixie>
i'm assuming "you" in those two sentences refer to different people

[20:50:22.0000] <cabanier1>
correct

[20:50:36.0000] <Hixie>
if you mean that this:   context.fillStyle = { toString: function () { return 'blue' } };   ...would result in the function defined in the canvas prose being handed a string, that's my understanding.

[20:50:50.0000] <Hixie>
(well, setter, not function)

[20:52:01.0000] <cabanier1>
as long as people don't expect this to work: var mycolor="…"; context.fillStyle = { toString: function () { return mycolor; } }; ...

[20:52:14.0000] <cabanier1>
canvaspattern and canvasgradient allow that

[20:52:26.0000] <Hixie>
why would that not work?

[20:52:33.0000] <cabanier1>
"When set to a http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvaspattern or http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasgradient object, the assignment is http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#live, meaning that changes made to the object after the assignment do affect subsequent stroking or filling of sh

[20:52:41.0000] <Hixie>
oh you mean, dynamically

[20:52:42.0000] <Hixie>
yeah

[20:53:05.0000] <Hixie>
it'll work, it'll just set the fillStyle to whatever mycolor's value is at setting time

[20:53:32.0000] <cabanier1>
and it won't be live

[20:53:41.0000] <cabanier1>
yes

[20:54:35.0000] <cabanier1>
do you think that needs to be written down somehow?

[20:55:18.0000] <Hixie>
well it's unambiguously required by the webidl spec

[20:55:38.0000] <Hixie>
and it seems like a really esoteric detail to put in non-normative prose

[20:56:21.0000] <cabanier1>
I agree

[20:57:32.0000] <cabanier1>
I tried "ctx.fillStyle={ toString: function () { return 'blue' } };"

[20:57:41.0000] <cabanier1>
and the fillstyle is black

[21:02:30.0000] <cabanier1>
same on FireFox, Safari and Chrome...

[21:04:13.0000] <cabanier1>
If you have a moment, I think "If x0 = x1 and y0 = y1, then the linear gradient must paint nothing." and "If x0 = x1 and y0 = y1 and r0 = r1, then the radial gradient must paint nothing." in the spec should change.

[21:04:36.0000] <cabanier1>
The gradient should just become a line or a filled circle...

[21:05:11.0000] <cabanier1>
same with color stops at the same offsets

[21:08:11.0000] <Hixie>
file a bug :-)

[21:08:25.0000] <Hixie>
(or mail the list, either way it ends up on my radar)

[21:10:25.0000] <Hixie>
(whatwg.org/newbug and whatwg⊙wo respectively)

[22:52:08.0000] <cabanier1>
OK

[22:52:21.0000] <cabanier1>
I will file a bug on both issues :-P

[01:07:50.0000] <Calthropstu>
hi

[01:09:47.0000] <Calthropstu>
I have a question... if I use say html4 or xhtml doc type statements will I still be able to use html5 tags?

[01:11:16.0000] <deane>
Calthropstu: Hi. Yes you can AFAIK, but, it wont validate.

[01:13:07.0000] <deane>
Calthropstu: Just use <!DOCTYPE html> Why would you want to use old doctypes?

[01:13:42.0000] <Calthropstu>
Im dont

[01:13:49.0000] <Calthropstu>
*I dont

[01:14:29.0000] <matjas>
annevk (assuming you read the logs): could you perhaps chime in here? https://bugs.webkit.org/show_bug.cgi?id=17352

[01:15:11.0000] <Calthropstu>
I'm being considered for a position and when I looked at their work I noticed their website is using a mishmash of xhtml1.0 strict, xhtml 1.1 strict, and html4 transitional

[01:15:42.0000] <Calthropstu>
and the biggest requirment is html 5

[01:16:12.0000] <deane>
Calthropstu: OIC. Sorry to jump to the wrong conclusion.

[01:16:30.0000] <Ms2ger>
Calthropstu, so, doctypes basically don't do anything

[01:16:38.0000] <Calthropstu>
they do

[01:16:52.0000] <Ms2ger>
Calthropstu, except for standards/quirks mode

[01:16:59.0000] <Ms2ger>
And some more modes in IE

[01:17:28.0000] <Ms2ger>
To answer your question, yes, you can use new HTML features regardless of doctype

[01:17:35.0000] <Calthropstu>
well I do know if you dont have 1 at all the whole thing goes  nuts

[01:18:02.0000] <Ms2ger>
Right

[01:18:27.0000] <Ms2ger>
Only in IE, though; other browsers will still support those features

[01:18:55.0000] <Calthropstu>
not exactly... because it also starts treating css wrong

[01:19:05.0000] <deane>
A good resource -> http://hsivonen.iki.fi/doctype/

[01:19:44.0000] <Calthropstu>
Ive had that issue as recently as may

[01:19:47.0000] <Ms2ger>
Calthropstu, I'd advise to just search&replace their doctypes, it's not going to break anything

[01:20:00.0000] <Ms2ger>
Unless they rely on quirks-mode differences

[01:20:08.0000] <Calthropstu>
well I would if I already had the position :-)

[01:20:51.0000] <Ms2ger>
Any of the doctypes here: http://www.whatwg.org/html/#obsolete-permitted-doctype-string are fine too, fwiw

[01:21:38.0000] <Calthropstu>
ok

[01:48:03.0000] <deane>
Calthropstu: Good luck with the job.

[01:59:19.0000] <Calthropstu>
thx

[02:00:03.0000] <Calthropstu>
my first resume submittal did not specify html5 so I have to resubmit it on tuesday

[02:01:03.0000] <Calthropstu>
I just figured "html" would cover ALL forms of html and CSS would cover all forms of CSS but they specifically demand CSS3 and HTML5

[02:01:42.0000] <deane>
Yeah, I guess then it's best to be specific.

[04:12:28.0000] <jesusruiz>
hi, group

[11:11:15.0000] <gsnedders>
Anyone got tests for meta pre-parsing?

[11:12:08.0000] <Ms2ger>
Not me

[11:12:09.0000] <gsnedders>
Looks like html5lib has none. And it's totally broken in Py3.

[11:12:17.0000] <gsnedders>
hsivonen: I think I saw some from you?

[11:12:24.0000] <gsnedders>
hsivonen: (meta pre-parsing tests)

[12:44:52.0000] <zewt>
... the synchronous nature of javascript is part of the web platform's *use* of javascript, not javascript/ecmascript per se, right?

[12:45:12.0000] <zewt>
(nothing in the language seems to care one way or the other, but I'm not familiar with the spec itself)

[13:24:00.0000] <gsnedders>
zewt: asynchronous you mean?

[13:24:49.0000] <gsnedders>
Then no, it has nothing to do with JS. It's just how all the host object APIs for the DOM have developed with callbacks.

[13:25:19.0000] <gsnedders>
Probably in large part because most JS impls (i.e., all but Opera's) block everything, so synchronous APIs would be Rather Bad.

[13:30:03.0000] <zewt>
gsnedders: synchronous in the sense of not seeing asynchronous side-effects

[13:30:17.0000] <zewt>
(but yes, we're talking about the same thing)

[13:30:42.0000] <gsnedders>
Ah, right.

[13:30:56.0000] <gsnedders>
That's just a side-effect of impls, really.

[13:31:18.0000] <gsnedders>
The JS spec doesn't address multiple threads of impl at all.

[13:33:40.0000] <zewt>
yeah, that's what I've always assumed intuitively, was just looking for a sanity check before it came up in a debate :)

[13:34:44.0000] <zewt>
is anyone else driven mad by chrome's broken text searching, heh

[13:35:03.0000] <zewt>
i type "foo" and instead of finding the next "foo" from where I am now, it goes to the first "f" in the document before I can type the rest

[13:38:21.0000] <zewt>
particularly annoying in the html spec when it makes me lose my place

[14:08:21.0000] <smaug____>
is rick waldron ever here?

[14:25:43.0000] <zewt>
it's pretty (something) that anyone would seriously suggest this atrocity as a solution to anything: https://github.com/kriskowal/q/blob/master/examples/all.js


2012-09-02
[07:52:37.0000] <ubitux>
hi,

[07:52:57.0000] <ubitux>
how is webvtt supposed to be muxed within webm/mkv?

[07:53:09.0000] <ubitux>
i'm a bit concerned about the timing line mixed with the payload

[07:53:21.0000] <ubitux>
timing line mixed with the positionning* sorry

[07:54:10.0000] <ubitux>
(so what goes in the payload?)

[07:56:58.0000] <zewt>
not sure what you're asking

[07:57:30.0000] <zewt>
(not to say I can necessarily answer, but I'll try if I can :)

[07:59:15.0000] <ubitux>
well, if you take a common srt file muxed in mkv, an event such as "01:02:03.04 --> 05:06:07.08\nfoobar" will be stored in mkv such as [pts_start][duration][payload="foobar"]

[07:59:42.0000] <ubitux>
what happens now when the position information is stored on the timed line, and not as part of the payload

[08:00:11.0000] <ubitux>
if you put that information in the payload, how do you differenciate it from the classic text content

[08:01:55.0000] <zewt>
are you asking as a webm developer? i ask because this is a webm/mkv implementation detail--they can do it however they want, it's not something webvtt would define

[08:02:47.0000] <zewt>
for static (non-streaming) videos i'd be inclined to put the whole webvtt file (perhaps preprocessed in some way) at the start of the file, not to interleave it across the video--that's a strategy that doesn't make sense with files small enough to trivially load into memory

[08:03:18.0000] <zewt>
but that's entirely up to the file format; they can preparse and store the file however they like, of course

[08:04:43.0000] <ubitux>
putting the whole sub content is stupid since the format has capabilities to store subtitles events and an extra header

[08:05:01.0000] <ubitux>
the thing is, if we want to mux it properly

[08:05:05.0000] <zewt>
stupid? niiice

[08:05:06.0000] <ubitux>
it doesn't look like possible

[08:05:30.0000] <zewt>
"can do" and "should do" are not equivalent :)

[08:05:32.0000] <ubitux>
except doing the crappy way of dumping the file in it

[08:06:08.0000] <zewt>
you can dump the whole cue text in it, or preprocess it in some way if you like

[08:07:34.0000] <zewt>
let's back up a bit

[08:07:49.0000] <ubitux>
media containers are designed to have the split form (for audio, video or subtitles)

[08:07:54.0000] <ubitux>
but if we want to split it

[08:07:59.0000] <ubitux>
how are we supposed to do it?

[08:08:10.0000] <zewt>
is "start time/duration/payload" the basic format mkv has to work with for subtitles, or is that just how it handles srt?

[08:08:11.0000] <ubitux>
since if we split the timing line and positionning

[08:08:25.0000] <ubitux>
the demuxer can't guess if the positionning is part of the text or a positionning info

[08:08:31.0000] <zewt>
(it doesn't really matter, it just affects how we discuss it)

[08:08:51.0000] <ubitux>
basis for subtitles

[08:08:55.0000] <ubitux>
it's used for ASS/SSA too

[08:09:12.0000] <ubitux>
the start & end are extracted from the dialogue events

[08:09:17.0000] <zewt>
okay, so start time and duration are straightforward; you'd have to encode the remaining information into the payload

[08:09:28.0000] <ubitux>
put into the mkv structures, and rest of the dialog line put into the payload

[08:10:36.0000] <zewt>
for example--not suggesting this is optimal, just a simple quick way--the first byte of "payload" is the "align" setting (0: start, 1: middle, 2: end), the second byte encodes the size, etc., followed by the cue text

[08:11:23.0000] <zewt>
(not a very robust or extensible encoding, of course, just illustrating)

[08:11:49.0000] <ubitux>
having an obvious way of muxing it in most of the container would be way better

[08:11:55.0000] <zewt>
that is, the "payload" is all of the information in the cue block except the timestamps, not just the cue text

[08:12:38.0000] <zewt>
or put differently, the payload is the whole cue block, with the *exception* of the timestamps (since you encode those as separate fields)

[08:14:07.0000] <zewt>
my first more serious inclination if I was defining this would be to change the timestamps in the cue to "0.000 --> 0.000", and then just copy the entire cue block into the payload, so the parsing of the payload is defined by webvtt and no WebM format changes are needed to support new WebVTT features

[08:14:33.0000] <zewt>
(the reason for blanking the timestamp is to make it clearly not redundant with the timestamp/duration encoded in the separate fields, to ensure that nobody accidentally uses them)

[08:14:53.0000] <zewt>
(but leaving them in so it still parses in the same way)

[08:42:01.0000] <ubitux>
zewt: about your proposition, it's a pain if a new fields is added

[08:42:10.0000] <ubitux>
(having 1 byte per prop and stuff)

[08:42:30.0000] <ubitux>
also if formats implement that differently it will be a pain for demuxers

[08:42:37.0000] <zewt>
ubitux: like I said, that's not an extensible (or even serious) encoding

[08:42:41.0000] <ubitux>
since we can't factor code for such trivial thing

[08:42:51.0000] <zewt>
the latter is rather more probable

[08:43:34.0000] <zewt>
(muxers don't have to know anything at all about new cue features)

[08:43:41.0000] <ubitux>
well the good thing i see is cutting just after the timing info

[08:43:52.0000] <ubitux>
and includes the \n in the payload

[08:43:55.0000] <zewt>
that's more complex

[08:43:58.0000] <ubitux>
but it sucks a bit

[08:44:07.0000] <ubitux>
why?

[08:44:25.0000] <ubitux>
we can't have some heuristics on the payload to detect if it's align/size, etc

[08:44:47.0000] <zewt>
because 1: now you have a cue block without a timestamp, meaning you can't just use webvtt's parser, and 2: don't forget about cue identifiers (whether those are often useful or not, better off not dropping them unnecessarily)

[08:45:09.0000] <ubitux>
demuxers and decoders are different

[08:45:21.0000] <ubitux>
you use a decoder to parse the payload stuff

[08:45:26.0000] <ubitux>
basically the markup and stuff

[08:45:40.0000] <ubitux>
the timing stuff is extracted by the demuxer, splitting the input into chunk

[08:45:49.0000] <zewt>
yes, that's what i suggested :)

[08:46:22.0000] <ubitux>
so in case of a standalone webvtt, the demuxer will split the file into chunk, removing the timing stuff and send the payload to the decoder

[08:46:40.0000] <ubitux>
in case of a muxed file, it's the same, you construct a packet with the timing info from the format

[08:46:51.0000] <ubitux>
and send the payload to the webvtt decoder

[08:46:52.0000] <zewt>
yes, that's what i suggested :)

[08:46:56.0000] <ubitux>
alright

[08:47:02.0000] <ubitux>
well then that's not answering the question

[08:47:11.0000] <ubitux>
what happens to the align & size from the timing information?

[08:47:11.0000] <zewt>
i don't know what the question is

[08:47:21.0000] <zewt>
they're not part of the timing information, they just happen to be on the same line

[08:47:25.0000] <zewt>
let me give an example

[08:47:28.0000] <zewt>
(one sec)

[08:49:14.0000] <zewt>
http://pastebin.com/CWA5471e

[08:49:35.0000] <ubitux>
then you have the timing information two times

[08:49:37.0000] <ubitux>
that sucks.

[08:49:39.0000] <zewt>
no you don't

[08:49:55.0000] <ubitux>
well you have a kind of weird signature

[08:49:56.0000] <zewt>
there's no timestamp in the payload; just "0 --> 0", which is a dummy

[08:50:21.0000] <ubitux>
(0.000 --> 0.000 is a valid one no?)

[08:50:25.0000] <zewt>
it's there only to avoid having to change the parser (since then you'd run into other issues, like how to distinguish a cue id)

[08:50:26.0000] <ubitux>
and btw why this one?

[08:50:35.0000] <ubitux>
why a so long signature?

[08:50:42.0000] <zewt>
that's not the timestamp; the timestamp is 00:10.000 --> 00:15.000

[08:50:43.0000] <ubitux>
and couldn't that be standardized?

[08:51:00.0000] <zewt>
it's not a signature, it's just a dummy timestamp so the WebVTT parser can still be used

[08:52:05.0000] <zewt>
(eg. step 37 in the WebVTT parser)

[08:52:09.0000] <ubitux>
whatever is decided, it would be *really* important to standardize

[08:52:37.0000] <ubitux>
or at least a recommendation or something

[08:52:52.0000] <ubitux>
because this will likely be an issue for various containers

[08:54:09.0000] <zewt>
not sure it makes sense for webvtt to try to standardize how it's encoded in higher-level formats it knows nothing about, but if the webm/mkv folks want advice on this stuff, they can always come here or post on public-texttracks

[08:54:31.0000] <ubitux>
well the other way around would be to make obvious how to split that

[08:54:47.0000] <ubitux>
basically by separating the align/size stuff from the timing line

[08:54:47.0000] <zewt>
sorry--split what?

[08:55:16.0000] <zewt>
that's out of webvtt's scope--it doesn't know anything about that (and as I suggested above, I don't even know if that's a good idea)

[08:55:32.0000] <ubitux>
webvtt will be standardized and massively used

[08:55:38.0000] <zewt>
webvtt's parser depends heavily on seeing webvtt timestamps to know what it's looking at

[08:55:41.0000] <ubitux>
it will have the issue of being muxed

[08:55:47.0000] <ubitux>
so it's something you should consider

[08:56:18.0000] <ubitux>
zewt: i mean maybe move it do a dedicated line

[08:56:44.0000] <zewt>
but that would change the format and the parser significantly--the approach I suggested above (dummy timestamps) avoids that complexity

[08:57:44.0000] <zewt>
(not to say it's the only way of doing it, though nothing else comes to mind and it seems very simple, without all the ways trying to eliminate it might bite you)

[09:01:02.0000] <ubitux>
just found http://wiki.webmproject.org/webm-metadata/temporal-metadata/webvtt-in-webm

[09:01:15.0000] <ubitux>
seems like webm has another field that can be used for that information

[09:02:20.0000] <zewt>
i've seen that page before (it's a bit of a mess, hard to separate actual information from brainstorming)

[09:03:29.0000] <zewt>
yeah that makes up its own vtt-esque format for storing webvtt, which sort of seems like a bad idea

[09:04:50.0000] <ubitux>
well if the format isn't good you don't have a choice

[09:05:03.0000] <zewt>
nothing wrong with the format; i just gave a decent way to do it :)

[09:06:02.0000] <zewt>
(and if you raise it on texttracks others may well have better ideas--or find issues with mine, for that matter)

[09:06:27.0000] <zewt>
(though if webm's already made up its mind on how to do it, or if they're not paying attention, it won't help)

[09:08:02.0000] <ubitux>
meh the specs is missing a lot of examples

[09:09:23.0000] <zewt>
can file bugs if you have specific examples you want: https://www.w3.org/Bugs/Public/ (product: texttracks)

[09:09:49.0000] <ubitux>
i would like various timing examples :p

[09:10:28.0000] <ubitux>
i'll read deeply the text, but not me at first glance it doesn't look obvious if "12:23:45.123" is valid

[09:10:34.0000] <ubitux>
if "13245.12345" is also

[09:10:39.0000] <ubitux>
or if "12" is as well

[09:12:02.0000] <zewt>
see http://dev.w3.org/html5/webvtt/#webvtt-timestamp for the timestamp format (what's "valid") and the parser (http://dev.w3.org/html5/webvtt/#collect-a-webvtt-timestamp) for precisely what happens in a particular case

[10:48:13.0000] <ubitux>
zewt: thanks :)

[10:48:17.0000] <ubitux>
(sorry for the delay)

[10:48:26.0000] <ubitux>
and yes i was refering to that part of the spec

[10:48:49.0000] <ubitux>
still a list of valid examples would be nice

[10:54:06.0000] <ubitux>
the spec really isn't obvious IMO

[11:09:54.0000] <jack_tradez>
zewt: i do not use chrome for number of tasks because a number of quirks are not that developer friendly :P

[11:18:18.0000] <zewt>
heh, context loss is still an open problem for gpu-accelerated 2d canvas? i don't know why, but i thought that was only a problem with webgl

[12:23:42.0000] <jack_tradez>
I'm not sure. I like the vi style incremental search but it certainly doesn't work like vi ;)

[12:24:27.0000] <zewt>
vi starts searching where you are, chrome keeps going to the top of the page

[15:14:54.0000] <Smylers>
For <base href=http://example.com> without a trailing slash on the URL, getting the href property returns http://example.com/ with the trailing slash in some browsers.

[15:15:27.0000] <Smylers>
Reading through http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#dom-base-href I can't spot any step which says to add that trailing slash.

[15:15:47.0000] <Smylers>
Am I missing it?

[15:15:55.0000] <Hixie>
/me looks

[15:16:02.0000] <Smylers>
Hixie: Thanks.

[15:16:24.0000] <Smylers>
This page reports that Firefox, Opera, and Safari add the trailing slash, and IE doesn't: http://notes.minty.org/cgi-bin/wiki.pl?Fixing_Base_Href_Javascript_Document.Location_For_Internet_Explorer

[15:16:39.0000] <Smylers>
I've only personally checked Firefox, which does add it.

[15:16:42.0000] <Hixie>
the absolute URL returned by the "Resolve" algorithm always includes that leading slash

[15:16:51.0000] <Hixie>
("leading" because it's the first one in the path)

[15:17:22.0000] <Smylers>
Hixie: Thanks. I'll read it again more carefully.

[15:17:28.0000] <Hixie>
i'm not sure you'll find it

[15:17:40.0000] <Hixie>
the "resolve" algorithm is currently pointing at a vague RFC

[15:17:50.0000] <Hixie>
we hope to write a more detailed spec in due course

[15:17:57.0000] <Hixie>
(i think anne's the one working on that)

[15:20:25.0000] <Smylers>
Ah.

[15:20:32.0000] <Smylers>
I read that RFC before asking here.

[15:24:55.0000] <Smylers>
I read it as at the Parse step the RFC parses hier-part, picking the path-abempty option, which allows the empty string. So <path> is then set, but empty, and that gets copied across through the rest of the algorithm, still being empty at the end.


2012-09-03
[17:51:18.0000] <zewt>
sort of amusing to see people talking about one of the first things i raised on webapps a year and a half ago

[17:52:12.0000] <zewt>
The Web Platform: Software Development Patience

[19:51:52.0000] <cabanier>
zewt: the canvas conversation?

[19:53:58.0000] <zewt>
sync messages

[01:11:43.0000] <annevk>
whoa

[01:11:48.0000] <annevk>
2119 had errata?

[01:12:12.0000] <annevk>
maybe they should have another one to remove RECOMMEND, NOT RECOMMEND, and OPTIONAL

[01:12:17.0000] <annevk>
*ED

[01:12:45.0000] <annevk>
oh, and SHALL, SHALL NOT

[01:13:22.0000] <annevk>
being able to recommend rather than encourage without it meaning SHOULD is nice

[02:23:00.0000] <deano>
annevk: Welcome back.

[03:21:03.0000] <jgraham>
http://www.hackermusings.com/2012/08/using-git-to-push-to-mozillas-hg-repositories/ seems quite interesting

[03:21:07.0000] <jgraham>
MikeSmith: ^

[03:21:18.0000] <annevk>
thanks deane

[03:43:10.0000] <deane>
annevk: Hey there. Not sure if you read the logs or not, so not sure if you saw this => http://krijnhoetmer.nl/irc-logs/whatwg/20120901#l-384

[03:45:22.0000] <annevk>
deane: thanks, matjas, not sure what you want me to say

[03:45:44.0000] <annevk>
matjas: I suggest convincing abarth

[04:14:25.0000] <Smylers>
annevk: Re http://krijnhoetmer.nl/irc-logs/whatwg/20120903#l-8 onwards, is Hixie's thought that you are working on it right?

[04:14:50.0000] <Smylers>
Is there a bug tracking this specific point, or should I file one?

[04:15:26.0000] <annevk>
Smylers: I have done some work on parsing URLs; the idea is that you will end up with the / once you serialize such an object

[04:15:46.0000] <Smylers>
Thanks.

[04:15:50.0000] <annevk>
Smylers: but I'm not sure when I'll get around to doing the remainder of the research

[04:16:00.0000] <Smylers>
annevk: Sure.

[04:17:11.0000] <Smylers>
annevk: In terms of what to tell somebody who's encountered this, would “The non-IE behaviour will be specified, but that part hasn't been written yet.” be accurate?

[04:18:30.0000] <annevk>
yeah I suppose

[04:19:18.0000] <annevk>
any eventual URL specification will closely resemble Gecko/Safari/Chrome (all subtly different unfortunately)

[04:19:36.0000] <annevk>
IE's URL parsing has many weird quirks

[04:20:10.0000] <jgraham>
Smylers: I think you tell them "You expected the most fundamental parts of the web platform to be well specified? Are you new here?"

[04:22:27.0000] <jgraham>
Smylers: You should also tell them that it could be worse; the TAG still haven't decided if http://example.org/ refers to a website or a car

[04:23:21.0000] <jgraham>
Or maybe they have now. Who knows

[04:56:09.0000] <Smylers>
jgraham: The person in question isn't “here”, so whatever I tell him may well affect his view of the web standards process. I was trying not to alarm him too much.

[04:59:04.0000] <darobin>
jgraham: actually, the question of what a URL refers to has in fact been resolved: http://faketag.org/a-101-on-the-range-of-the-http-dereference-function/

[05:05:47.0000] <Smylers>
jgraham: They claim to've decided it here: http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html

[05:07:23.0000] <Smylers>
jgraham: Though I note that ‘solution’ describes itself as removing ambiguity. Of the three cases they list, (b) is “could be any resource” and (c) is “unknown” — which some people may still interpret as leaving a little ambiguity there.

[05:08:23.0000] <darobin>
Smylers: don't listen to www-tag — it's an usurpation of the real TAG! only read the faketag.org resolution, it's the only one that breaks the Web in all the right ways

[05:09:10.0000] <Ms2ger>
/me raises an eyebrow

[05:25:10.0000] <jgraham>
Smylers: http://www.w3.org/2001/tag/group/track/issues/14 suggests that the issue was discussed at a F2F a few months ago, and there was a TAG-Member only thread (I guess one should hide one's shame) questioning whether the issue is in fact still open

[05:25:45.0000] <jgraham>
Still it does give the impression that they aren't sure if they are dereferencing their arse or their elbow

[05:27:55.0000] <MikeSmith>
jgraham: thanks for the link about pushing to hg from git

[05:28:23.0000] <jgraham>
MikeSmith: Yeah, it seems like all the actual code might be somewhat hidden

[05:28:37.0000] <jgraham>
But maybe we could ask them to reuse it

[05:31:37.0000] <jgraham>
MikeSmith: BTW people on web-notifications are asking about publication status

[05:32:01.0000] <jgraham>
I imagine that is blocked by the lack of annevk

[05:32:10.0000] <jgraham>
Or, less specifically, the lack of a chir

[05:32:13.0000] <jgraham>
*chair

[05:32:25.0000] <jgraham>
But maybe you should say that since you are staff contact

[05:32:29.0000] <jgraham>
(I think)

[05:32:48.0000] <Ms2ger>
Did jgraham just volunteer to chair?

[05:32:54.0000] <jgraham>
Hahahaha

[05:35:07.0000] <odinho>
Ms2ger: Lots of voulenteering happening in this channel lately.

[05:35:42.0000] <Ms2ger>
odinho, oh yes, you were going to edit something, I just can't remember what...

[05:45:01.0000] <Ms2ger>
jsbell--

[05:48:27.0000] <jgraham>
?

[05:49:55.0000] <Ms2ger>
Writing tests with some obscure test harness

[05:53:51.0000] <jgraham>
Ugh. Link?

[05:54:19.0000] <Ms2ger>
https://code.google.com/p/stringencoding/

[05:54:33.0000] <Ms2ger>
On another note

[05:54:41.0000] <Ms2ger>
> we ran into site compatibility issues

[05:54:42.0000] <Ms2ger>
Is there a compat problem?

[05:59:16.0000] <jgraham>
Oh, qunit, yuck

[06:00:38.0000] <jgraham>
Doesn't look too hard to convert though

[06:34:21.0000] <crocket>
How can I make a web browser display consecutive whitespace characters?

[06:34:27.0000] <crocket>
They all collapse into one whitespace character.

[06:38:40.0000] <Lachy>
crocket, depends on what you need to do that for. There are multiple methods

[06:40:10.0000] <Lachy>
crocket, 1. <pre>   </pre>. 2. Use CSS 'white-space' property, or 3. Use non-breaking spaces &nbsp;

[06:40:43.0000] <crocket>
Lachy, How do I apply a monospace font-family?

[06:41:04.0000] <Lachy>
CSS 'font-family' property, or the 'font' shorthand.

[06:41:59.0000] <Lachy>
crocket, if you're trying to markup code and want it displayed in a monospace font with whitespace preserved, then just use <pre>

[06:42:07.0000] <Lachy>
that's the default rendering

[06:45:27.0000] <crocket>
Lachy, What if I want a monospace serif font?

[06:48:34.0000] <Lachy>
crocket, lots of monospace fonts have serifs on the glyphs.

[06:49:30.0000] <Lachy>
but you can't declare both monospace and serif generic font families together

[06:50:59.0000] <crocket>
Lachy, That's unfortunate.

[06:51:20.0000] <Lachy>
crocket, you can name a specific font if you have one in mind

[06:51:40.0000] <Lachy>
But even Courier New has serifs, so I don't see the problem.

[07:43:50.0000] <Ms2ger>
annevk, I guess you haven't set up the post-push hook for DOM yet?

[08:15:03.0000] <annevk>
Ms2ger: no, I should

[08:15:23.0000] <annevk>
Ms2ger: that is, my plan is to update dom.spec.whatwg.org on push

[08:15:30.0000] <Ms2ger>
Good :)

[08:16:14.0000] <annevk>
I wanted to wait a bit for the W3C to reply to my inquiry

[08:16:23.0000] <annevk>
and then move on

[08:17:10.0000] <annevk>
with a timeout of about one more week, as I'm somewhat eager to do some spec updates

[08:17:17.0000] <Ms2ger>
I did a few

[08:17:40.0000] <annevk>
I noticed you pushed to github already, nice :)

[08:18:08.0000] <Ms2ger>
hg-git works well enough

[08:22:09.0000] <jgraham>
Hixie: I assume you don't object to your document.open-in-unload tests being submitted to W3C under the normal license for the testsuite? I adapted them to testharness.js

[08:26:40.0000] <Ms2ger>
jgraham++

[08:37:28.0000] <Hixie>
jgraham: sure

[08:37:32.0000] <Hixie>
jgraham: (what's the license? mit?)

[08:39:20.0000] <jgraham>
Hixie: Dual W3C Testsuite / 3 clause BSD

[08:39:28.0000] <Hixie>
yeah, that's fine

[08:40:02.0000] <jgraham>
http://www.w3.org/Consortium/Legal/2008/04-testsuite-copyright.html

[08:44:18.0000] <jgraham>
http://w3c-test.org/html/tests/submission/Opera/loading_web_pages/browsing_the_web/unloading_documents/document_open/

[08:45:05.0000] <jgraham>
I may have broken the tests of course, please let me know if I did

[08:46:02.0000] <jgraham>
(also, WTF, I just tried one of the tests in WebKit and got a QUOTA_EXCEEDED_ERR)

[08:46:37.0000] <jgraham>
OK, that's just 005

[08:51:36.0000] <Hixie>
how can you get a storage exceeded error

[08:52:06.0000] <Hixie>
sweet lord, the tests now import tons of scripts

[08:52:13.0000] <Hixie>
i make no guarantees that they are valid

[08:52:26.0000] <Hixie>
(and i still don't understand why we have to do this rather than just exposing an API and using iframes)

[08:53:05.0000] <jgraham>
I'm not sure what you mean by "exposing an API and using iframes"

[08:53:14.0000] <Hixie>
oh i see, that's in fact what you do

[08:53:18.0000] <Hixie>
nevermind

[08:53:25.0000] <Hixie>
i didn't realise you renamed it too :-)

[08:53:57.0000] <jgraham>
Oh you mean 001.html -> 001-1.html

[08:54:34.0000] <Hixie>
yeah

[08:54:41.0000] <Hixie>
i also don't understand the quota error in 005

[08:54:46.0000] <jgraham>
Yeah, your tests are running in their own browsing context. New windows are slightly less evil than iframes for things that poke at the history

[08:54:56.0000] <jgraham>
Or document loading

[08:55:09.0000] <Hixie>
right

[09:02:31.0000] <zewt>
jgraham: more likely to trigger unrelated issues, though (popup blockers and not being allowed to open new windows--two issues I just hit trying to run that one)

[09:02:50.0000] <zewt>
(the first is easy enough to undo, the second i'd have to go play with obscure about:config stuff so I didn't bother)

[09:03:46.0000] <jgraham>
zewt: Right, alllowing popups from test sites does become necessary

[09:03:58.0000] <Hixie>
I really don't understand this quota problem

[09:04:01.0000] <jgraham>
But it can be a tab rather than a window

[09:04:04.0000] <Hixie>
is there some infinite loop going on or something?

[09:04:24.0000] <zewt>
jgraham: i have firefox set to never allow new windows or tabs; links always open in the same tab

[09:04:42.0000] <zewt>
(too many abusive sites trying to open new windows for every single link)

[09:04:54.0000] <jgraham>
zewt: Oh, well yeah I guess if you have weird non-standard configurations it is harder

[09:05:16.0000] <zewt>
one of those things i've never understood browsers allowing, since the abuse is so widespread and annoying

[09:06:09.0000] <jgraham>
Hixie: So I note that 001 seems to give 012389 rather consistently in existing browsers

[09:06:30.0000] <jgraham>
Ignoring Opera which is clearly broken and IE which I would have to change computers to test

[09:06:51.0000] <Hixie>
yeah, several of the test cases give reliable results that differ from what i ended up requiring, but it turns out that if you examine what they're doing it is crazy and doesn't really work in all cases

[09:07:18.0000] <Hixie>
(gecko and webkit in particular actually do quite different things)

[09:07:40.0000] <Hixie>
(yet end up with similar results on some of the tests out of basically coincidence)

[09:08:17.0000] <jgraham>
OK

[09:08:30.0000] <jgraham>
I am always nervous when the spec doesn't match implementations

[09:08:37.0000] <jgraham>
Especially if they match each other

[09:08:39.0000] <Hixie>
none of the implementations actually match here

[09:08:46.0000] <Hixie>
see my rants on irc (i linked to them from the checkin comment) for more details

[09:08:58.0000] <jgraham>
But obviously this is an insane thing to rely on

[09:09:00.0000] <Hixie>
(though note that i didn't do exactly what i suggested i should do in those notes, in the end)

[09:10:20.0000] <jgraham>
Which probably means that only facebook, google and twitter depend on it ;)

[09:58:45.0000] <annevk>
hmm

[09:58:51.0000] <annevk>
github is annoyingly inconsistent with URLs

[09:59:05.0000] <annevk>
 /whatwg and /WHATWG both work

[09:59:17.0000] <annevk>
as well as /whatWG and other crap

[10:01:10.0000] <zewt>
okay, that's annoying

[10:11:03.0000] <ubitux>
i don't understand what this http://dev.w3.org/html5/webvtt/#webvtt-cue-ruby-span is

[10:14:13.0000] <ubitux>
anyone has a simple explanation about what to do with this?

[10:15:38.0000] <zewt>
http://www.whatwg.org/specs/web-apps/current-work/#the-ruby-element

[10:15:42.0000] <webben>
ubitux: It's a way to put Ruby annotations in captions.

[10:16:13.0000] <webben>
ubitux: basically it's a type of oriental gloss: https://en.wikipedia.org/wiki/Ruby_character

[10:18:05.0000] <ubitux>
oh ok

[10:18:43.0000] <ubitux>
thanks

[10:32:06.0000] <ubitux>
that will be kind of painful to support such format :(

[10:33:56.0000] <zewt>
(how? who? where? context :)

[10:34:14.0000] <ubitux>
outside a browser

[10:34:19.0000] <ubitux>
C app

[10:34:28.0000] <ubitux>
subtitles transcoding

[10:34:34.0000] <ubitux>
rendering

[10:34:49.0000] <zewt>
transcoding is easy enough (if the format you're converting to doesn't support it, you remove the unsupported feature)

[10:35:04.0000] <ubitux>
transcoding is one of the most difficult

[10:35:16.0000] <ubitux>
the worst being the rendering, closely related

[10:35:35.0000] <ubitux>
the problem is, for subtitles rendering, the only library we can use is libass

[10:35:55.0000] <ubitux>
so we basically need to convert webvtt markup to ASS one

[10:36:03.0000] <zewt>
not due to this feature--you already have to parse the cue text, and you remove nodes for unsupported features

[10:36:29.0000] <zewt>
(converting to another format for rendering is probably not the best approach, though it may be the quickest short-term)

[10:36:41.0000] <ubitux>
that's the only solution

[10:36:54.0000] <ubitux>
or maybe you want to write a subtitles rendering library?

[10:36:59.0000] <ubitux>
at the moment libass is the most mature one

[10:37:03.0000] <zewt>
how could it possibly be the only solution? :)

[10:37:33.0000] <ubitux>
well i don't really want to dedicate 5 yr of my life to rewrite a rendering engine

[10:38:06.0000] <zewt>
rendering subtitles isn't a 5-year project unless a codebase is catastrophically broken

[10:38:30.0000] <Ms2ger>
Who's to say it isn't so?

[10:38:41.0000] <ubitux>
libass still has font glyph issues

[10:38:45.0000] <ubitux>
font stuff is a complex matter

[10:39:07.0000] <ubitux>
mixed with blur, rotation and misc. other transformations

[10:39:13.0000] <zewt>
that's why you don't write a font renderer, you use a font rendering engine (like freetype)

[10:39:16.0000] <ubitux>
and now ruby and stuff..

[10:39:41.0000] <ubitux>
that's what libass does

[10:40:25.0000] <ubitux>
libass is a "small" project of 10k lines

[10:40:58.0000] <ubitux>
the best move would be to fork it and make it supports the new vtt markup and stuff

[10:41:43.0000] <ubitux>
but that also means supporting CSS stuff

[10:41:53.0000] <ubitux>
and making available the access to the AST etc

[10:42:01.0000] <ubitux>
anyway, that's far from trivial

[10:42:18.0000] <ubitux>
i guess all of this is not really a problem for browsers

[10:42:22.0000] <ubitux>
but for anything else it is

[10:43:31.0000] <zewt>
(nothing is "trivial", and no matter what you do you need to support vtt's subset of CSS at some level)

[10:43:53.0000] <ubitux>
that's assuming browser will actually force the limit to these properties

[10:44:06.0000] <ubitux>
which won't happen and users will start abusing it quite quickl

[10:44:07.0000] <ubitux>
+y

[10:44:14.0000] <gsnedders>
ubitux: Do you have any evidence for that?

[10:44:37.0000] <ubitux>
well, that's what always happen

[10:45:01.0000] <zewt>
(i'm not assuming anything--no matter what you do, you need to be parsing CSS somewhere if you intend to support vtt's styling features at all)

[10:45:11.0000] <ubitux>
if even only one browser allows all the CSS stuff (because that's likely simpler), users WILL abuse it

[10:45:26.0000] <zewt>
whether that happens as part of a transcoding layer or closer to the renderer, it's got to be somewhere

[10:47:09.0000] <ubitux>
well anyway, requiring a CSS parser/matcher is kind of a problem

[10:47:16.0000] <ubitux>
of course, we can just ignore all that part

[10:50:36.0000] <ubitux>
now if we assume we actually write that CSS stuff (which is unlikely because of the complexity) the rendering will require something at least as big as libass

[10:51:13.0000] <ubitux>
so well, this is why i said it will be kind of painful to support such format

[10:51:28.0000] <ubitux>
(outside the browser)

[10:51:41.0000] <ubitux>
(so any players or subtitles editor/converter)

[10:53:52.0000] <zewt>
... that's something any serious captioning format is going to need (though comparing to ass isn't accurate--it supports lots of stuff other formats, including vtt, don't, like karaoke effects)

[10:54:34.0000] <ubitux>
ass supports karaoke

[10:54:39.0000] <ubitux>
jacosub as well

[10:54:56.0000] <zewt>
what? i just said ass does and vtt doesn't :)

[10:55:04.0000] <ubitux>
i thought vtt did

[10:55:13.0000] <zewt>
(vtt has very basic "change color at this time", but not all the goofy effects people do with ass)

[10:55:27.0000] <ubitux>
vtt has features not supported by ASS

[10:55:47.0000] <ubitux>
so you can't really fallback on the now-not-fully-featured-enough-ASS-system

[10:56:06.0000] <ubitux>
OTOH, if a full featured (parsing/styles-and-events-AST-publicly-accessible/rendering/portable) libsubtitles/libwebvtt was available, all of that wouldn't be a problem

[10:56:10.0000] <ubitux>
but that's a long term project.

[10:56:22.0000] <zewt>
anyway, if what you want is every subtitle format to be a subset of what you already have so you don't have to implement anything, that's not likely to happen :)

[10:56:57.0000] <ubitux>
yes, and that's a problem ;)

[10:57:40.0000] <ubitux>
at the moment most systems rely on the fact that almost all existing subtitles can be expressed as an ASS-subset

[10:57:54.0000] <zewt>
um, most systems don't support ass at all, heh

[10:58:02.0000] <ubitux>
and this is neat in the sense that there is a parsing/rendering lib to do all the stuff

[10:58:17.0000] <ubitux>
zewt: most players do

[10:58:37.0000] <ubitux>
they're using the libass rendering system for all the subtitles

[10:58:43.0000] <ubitux>
(except the simple formats)

[10:58:50.0000] <ubitux>
(sometimes)

[10:58:52.0000] <zewt>
you mean "desktop software"; set-top stuff rarely has usable support at all (wdtv claims support, and they lie--it's so incomplete it's unusable)

[10:59:21.0000] <ubitux>
i meant any app ≠ browsers

[11:00:01.0000] <zewt>
wdtv isn't a browser, heh

[11:00:05.0000] <ubitux>
so players like mplayer, vlc, possible the windows one (mpc?), as well as ffmpeg and such

[11:00:20.0000] <ubitux>
dunno what wdtv is

[11:05:27.0000] <ubitux>
anyway, i guess the best way would be to start a subtitles library being able to represent any kind of style structures and related crazyness, as well as the rendering part

[11:05:35.0000] <ubitux>
possibly a libass fork

[11:05:45.0000] <ubitux>
and then port all the subtitles decoders and encoders to it

[11:05:53.0000] <ubitux>
but this really is IMO a 5yr project

[11:05:57.0000] <zewt>
you're just not likely to get traction asking for all subtitle formats to be a subset of some particular library, which partially implements a particular weird ad hoc format

[11:06:00.0000] <ubitux>
just to support webvtt :)

[11:07:11.0000] <zewt>
i'd call it a project of a few months, if you can find a standalone css parsing/selector matching implementation

[11:07:22.0000] <ubitux>
zewt: i believe the main point of webvtt is to make a standard way of using subtitles accross the web, but i don't think it requires all that styling stuff

[11:08:06.0000] <zewt>
stylesheets are always technically optional

[11:08:28.0000] <ubitux>
yes but they are used as the basis of most styles, such as coloring and stuff

[11:08:38.0000] <zewt>
what? i just agreed with you, heh

[11:08:39.0000] <ubitux>
this means not supporting them is kind of a problem

[11:08:49.0000] <zewt>
i didn't say it wasn't, it seemed that you did :)

[11:09:47.0000] <ubitux>
(oh and i'm omitting the charset/encoding stuff)

[11:09:55.0000] <zewt>
stylesheets are important for presentation (especially if the current hideous black-rectangle-behind-captions default doesn't change), but no, it's not required as such

[11:10:27.0000] <zewt>
encoding is straightforward; webvtt is always utf-8

[11:11:54.0000] <zewt>
you really can't ask for anything simpler than *that* :)

[11:12:11.0000] <ubitux>
ASCII!

[11:12:23.0000] <zewt>
not so simple for japanese users :P

[11:12:49.0000] <ubitux>
romanji is more than enough

[11:12:58.0000] <ubitux>
:)

[11:13:53.0000] <zewt>
really, though, if you want implementation advice, feel free to open a discussion on public-texttracks

[11:14:47.0000] <zewt>
(for example, suggestions of a standalone CSS implementation, which I don't have off the top of my head)

[11:15:13.0000] <ubitux>
http://www.w3.org/Style/CSS/SAC/ ?

[11:15:57.0000] <zewt>
don't know (you'd need a parser and selector matching, at least)

[11:16:44.0000] <ubitux>
and then we will need a CSS rendering engine

[11:16:56.0000] <zewt>
and a robust enough API to allow iterating over :past/:future states and adding ::cue

[11:17:22.0000] <ubitux>
:/

[11:17:44.0000] <zewt>
no, you only need to be able to determine the state of properties at specific times (for example, font sizes aren't allowed to change once text is displayed, which simplifies a lot)

[11:19:05.0000] <zewt>
and the list of times at which properties change is finite, so i believe css rules + cues can be flattened to a simple list of states

[11:21:06.0000] <zewt>
anyway, i can't engineer this for you (and i need to eat), but again, mailing list :)

[11:23:15.0000] <ubitux>
i need to brainstorm by myself about what i really want indeed

[11:23:58.0000] <ubitux>
i think we will just make webvtt an equivalent of subrip with a lot of unsupported features

[11:24:11.0000] <ubitux>
and it will be more than enough :p

[11:25:00.0000] <zewt>
which implementation is this for, so I know what to avoid :P

[11:25:26.0000] <ubitux>
ffmpeg, and most likely will be used in the future by mplayer

[11:25:35.0000] <ubitux>
i believe vlc won't do anything more complicated as well

[11:25:57.0000] <ubitux>
and i don't think anything outside browsers will do as well

[11:26:01.0000] <ubitux>
at least not in the near future

[11:28:40.0000] <zewt>
(you're making me want to implement it for xbmc, so people have a good alternative)

[11:29:07.0000] <ubitux>
is xbmc linking with --enable-webkit?

[11:30:06.0000] <ubitux>
oh and btw, we can't actually rely on any library

[11:30:52.0000] <ubitux>
because what's the decoded packets for subtitles will contain the exploitable AST of the events & styles

[11:31:07.0000] <ubitux>
so it would require api user to link on that library as well, which is a problem

[11:31:14.0000] <ubitux>
so the full chain needs to be available

[11:31:21.0000] <ubitux>
as builtin

[11:53:58.0000] <zewt>
no, and you seem to have a misunderstanding of the complexity of webvtt if you think you need webkit to render it

[12:15:56.0000] <annevk>
so Instant Upload from Google+

[12:16:16.0000] <Ms2ger>
Google+ still exists?

[12:16:19.0000] <annevk>
is that known to fail when you attempt to upload 1500 at once?

[12:16:21.0000] <zewt>
is that the camera upload thing? because it's so un-instant i turned it off (useless)

[12:16:35.0000] <annevk>
it says "Starting upload..." but nothing happens

[12:17:07.0000] <annevk>
I'm not interested in paying Apple for iCloud so I figured I'd use this as backup instead, but it's rather crappy


2012-09-04
[17:38:21.0000] <GPHemsley>
Does anyone know if there's an ECMAScript IRC channel?

[17:43:57.0000] <benvie>
kind of

[17:44:07.0000] <benvie>
on mozilla's irc there's #jslang

[17:44:23.0000] <benvie>
irc.mozilla.org

[17:50:12.0000] <GPHemsley>
ah, OK, thanks

[19:07:53.0000] <ubitux>
it would be pretty nice if there was a webvtt sample file

[19:08:08.0000] <ubitux>
kind of a conformance ref file making use of all the features

[19:11:19.0000] <Hixie>
ubitux: there's a sample file in the spec intro

[19:11:26.0000] <Hixie>
ubitux: (doesn't use all the features)

[19:11:30.0000] <ubitux>
it is very limited

[19:11:39.0000] <Hixie>
(i don't speak japanese so it's hard for me to make a good one that uses the vertical text features)

[19:12:51.0000] <ubitux>
well even not that, i believe a file with a utf-8 bom, different timing formats, multilines events, and various nested tags would actually help

[19:14:44.0000] <zewt>
(sounds like what you're actually looking for is a test suite)

[19:19:39.0000] <ubitux>
no, just a sample

[19:19:58.0000] <ubitux>
and sure, to be included in our own test suite at some point

[19:20:09.0000] <ubitux>
but well, for testing it's kind of nice too

[19:20:25.0000] <ubitux>
as well as having a quick overview of everything that needs support

[19:21:55.0000] <ubitux>
see for example http://unicorn.us.com/jacosub/demo.txt

[19:22:12.0000] <ubitux>
it's kind of helpful with advanced subtitles...

[19:25:18.0000] <ubitux>
should i open a bug on the bugzilla?

[19:34:43.0000] <ubitux>
here we go, this is now #18770

[19:42:07.0000] <Hixie>
patches welcome :-)

[19:43:27.0000] <tantek>
Hixie, do you maintain a count of the # of times you end up saying that? ;)

[19:43:40.0000] <Hixie>
not that often :-)

[20:43:43.0000] <Von_Davidicus>
Why is it, when I put an <object> element in my document head, do I get errors in HTML5?  Never had that problem in XHTML 1.0 or HTML 4.01

[20:49:39.0000] <Von_Davidicus>
Well, I think I can call my first serious HTML5 project "finished".

[22:37:50.0000] <annevk>
ah

[22:37:52.0000] <annevk>
known issue

[22:37:53.0000] <annevk>
https://productforums.google.com/forum/?fromgroups=#!topic/google-plus-discuss/oMgOFgpRjzA

[22:38:03.0000] <annevk>
what a crap URLs btw

[22:38:17.0000] <Hixie>
Von_Davidicus: what do you mean by "get errors in HTML5"?

[22:38:27.0000] <Von_Davidicus>
Validation errors.

[22:38:35.0000] <Hixie>
ah. because it's not valid :-)

[22:39:02.0000] <Von_Davidicus>
Okay... why was <object> elements in the <head> element deemed bad?

[22:39:08.0000] <Hixie>
doesn't work

[22:39:21.0000] <Hixie>
(none of the browsers implemented it)

[22:39:45.0000] <Von_Davidicus>
Was it exclusively for the [declare] attribute, then?

[22:39:55.0000] <Hixie>
pretty much

[22:40:05.0000] <Von_Davidicus>
Oh, okay.

[22:40:16.0000] <Von_Davidicus>
/me uses it for SVG declarations and preloading images.

[22:40:26.0000] <Hixie>
does it work in browsers?

[22:40:37.0000] <Hixie>
i mean, do they put it in the <head> in the DOM?

[22:40:44.0000] <Von_Davidicus>
/me goes and checks.

[22:49:02.0000] <Von_Davidicus>
Hm.  FizzleFox, Slopera, Google Groan, and  are putting it in the <body>.

[22:50:38.0000] <Von_Davidicus>
/me is disappointed.

[22:52:24.0000] <Von_Davidicus>
Back.  Somehow I ended up leaving. :(

[22:52:24.0000] <Hixie>
that's what i call interoperability, it's a good thing :-)

[22:52:34.0000] <Hixie>
(and also why it's non-conforming now)

[22:53:21.0000] <Von_Davidicus>
/me grumps at browsers.  GRUMPS! *

[22:53:36.0000] <Hixie>
for following the spec? :-)

[22:54:28.0000] <Von_Davidicus>
For not following an outdated one!

[22:55:09.0000] <Von_Davidicus>
/me guesses he'll ave to put the <object> element somewhere in the body.

[23:01:48.0000] <Von_Davidicus>
/me sticks it just before the menu and changes the <object> element to <div>*

[23:01:56.0000] <Von_Davidicus>
Hm...  seems to work just as well.  http://www.mrinitialman.com/

[23:06:10.0000] <Von_Davidicus>
I "preloaded" the image so my CSS rollovers would work properly.

[23:21:44.0000] <Von_Davidicus>
/me has recently finished an XML project more or less to his satisfaction.

[03:48:25.0000] <Ms2ger>
annevk, yt?

[04:20:07.0000] <annevk>
Ms2ger: yup

[04:21:30.0000] <Ms2ger>
Is it just me, or is the isEqualNode spec wrong if the context object has more attributes than the argument?

[04:23:20.0000] <annevk>
see under -> Element

[04:24:04.0000] <Ms2ger>
Ah, right

[04:24:06.0000] <Ms2ger>
Well hidden

[04:24:14.0000] <Ms2ger>
(Or, I can't read)

[04:24:30.0000] <annevk>
feel free to move it around as you see fit

[04:24:43.0000] <annevk>
it's not the best wording

[05:02:26.0000] <MikeSmith>
w3c bugzilla is down

[05:02:34.0000] <MikeSmith>
systems team is working on it

[05:02:38.0000] <MikeSmith>
other stuff down too

[05:57:33.0000] <odinho>
Chrome guys, think you have a regression, don't have old versions in though so can't really check. :-(

[05:57:47.0000] <Ms2ger>
^ helpful guy

[05:57:50.0000] <odinho>
http://odin.s0.no/web/theora-video/video.htm << streaming video from icecast using ogg theora used to work.

[05:58:18.0000] <odinho>
Ms2ger: Hehe... I meant they're kinda hard to find. :-)

[06:00:16.0000] <odinho>
(that is, I found it for Windows, but no Linux)

[06:01:46.0000] <gsnedders>
odinho: BUT YOU NEED THE LATEST VERSION OR YOU'RE HOLDING THE WEB BACK!

[06:02:04.0000] <odinho>
gsnedders: But but... Regression. test. Help... Nice guy.

[06:02:39.0000] <gsnedders>
odinho: BE HORRIBLE.

[06:04:49.0000] <odinho>
gsnedders: Okay, I'll sniff it and say "get a better browser", then :-D

[06:39:57.0000] <jgraham>
"Umm, isn't the before method the wrong way round? I thought div2.before(div1) would put div2 before div1" - Opera developer on reading the new DOM4 mutation methods

[06:41:18.0000] <jgraham>
"there is a typo in the spec as well"

[06:42:11.0000] <jgraham>
"'the append nodes method must run these steps' should be nodes"

[06:42:20.0000] <jgraham>
*shoulfd be node

[06:42:32.0000] <jgraham>
(I am just quoting haven't checked)

[06:42:37.0000] <jgraham>
Ms2ger, annevk ^

[06:43:17.0000] <Ms2ger>
Those new things are annevk's thing

[06:43:51.0000] <annevk>
please file a bug on the typo

[06:43:55.0000] <annevk>
checking the other thing now

[06:44:08.0000] <jgraham>
The other thing isn't a "bug"

[06:44:45.0000] <annevk>
the before method matches http://api.jquery.com/before/

[06:44:48.0000] <annevk>
afaict

[06:44:51.0000] <jgraham>
It's a "oh this method does something different to what I expect"

[06:45:11.0000] <annevk>
jl/bratell prolly haven't used jQuery like the rest of the web? :)

[06:45:13.0000] <jgraham>
Right, this is bratell who afaik is not too familiar with jQuery

[06:45:43.0000] <jgraham>
But the number of future web developers who haven't used jQuery >> number of current web developers who have

[06:46:08.0000] <annevk>
maybe it helps if he thinks of it like insertBefore, but with the method directly on the object on which to insert things before

[06:46:58.0000] <annevk>
also, Maciej suggested renaming them to addBefore/addAfter

[06:47:00.0000] <jgraham>
But usually a mehod on an object mutates that object, not its argument

[06:47:02.0000] <annevk>
does that help?

[06:47:12.0000] <Workshiva>
annevk: But if it

[06:47:15.0000] <annevk>
neither the object nor the argument is mutated

[06:47:22.0000] <annevk>
the parent is

[06:47:23.0000] <Workshiva>
it's on the object on which to insert things before, it's not like insertBefore

[06:47:52.0000] <annevk>
Workshiva: well yeah, that's kind of the point

[06:48:18.0000] <jgraham>
If the node didn't have a parent and now does have a parent that seems like a more substantial change than being the N+1th child

[06:48:25.0000] <jgraham>
instead of the Nth

[06:48:47.0000] <annevk>
before() cannot give a node a parent

[06:49:04.0000] <Workshiva>
insertBefore can

[06:49:13.0000] <jgraham>
Really?

[06:49:47.0000] <annevk>
Workshiva: how?

[06:49:49.0000] <jgraham>
So if I p = createElement("p") and document.body.before(p), p doesn't end up with a parent node?

[06:50:16.0000] <annevk>
jgraham: I thought you meant body ending up with a parent node

[06:50:33.0000] <Workshiva>
annevk: p = createElement("p"); // no parent // document.body.firstChild.insertBefore(p) // now has a parent

[06:50:45.0000] <Workshiva>
Um, that was before I guess

[06:50:47.0000] <jgraham>
Right, it woudl if you write p.before(document.body)

[06:50:49.0000] <Workshiva>
See, it's already confusing me!

[06:51:15.0000] <jgraham>
(i.e. if the this object and the argument were swapped)

[06:51:42.0000] <jgraham>
Anyway, I don't know

[06:51:58.0000] <annevk>
again, comments on the suggested renaming welcome

[06:52:29.0000] <jgraham>
It seems to me that non-verb methods are pretty terrible and that this design is potentially confusing

[06:52:34.0000] <annevk>
updates next week ideally

[06:53:47.0000] <Workshiva>
assignSiblingRelationshipPreceding()

[06:57:04.0000] <jgraham>
element.assignRelationshipSiblingEarlier(), aliased as element.aRSE() to keep the names short and memorable

[07:04:55.0000] <odinho>
lol

[07:10:13.0000] <odinho>
I like addBefore, addAfter, -- they even have a better symmetry than   before/insertBefore.  But I think we are smart people and will be perfectly able to use whatever. But no more hard-to-write and long words like "stopPropagation". :-)

[07:11:07.0000] <Workshiva>
If we're going to be jquerish, why not "andThen" and "butFirst"?

[07:12:48.0000] <annevk>
Workshiva: because only in your mind is that jQueryish

[07:13:10.0000] <Workshiva>
My mind sees no problem with that

[07:13:18.0000] <zewt>
stopPropagation isn't overly long (close to borderline, maybe, but only that); now, findElementById ...

[07:13:28.0000] <annevk>
get*

[07:13:35.0000] <zewt>
y

[07:13:45.0000] <Workshiva>
Clearly you meant to say getElementsByClassName

[07:13:47.0000] <zewt>
<- just got out of shower, slack requested :P

[07:14:04.0000] <annevk>
only granted for out of bed or drunk

[07:14:12.0000] <odinho>
zewt: I have problems writing it... Always have to stop and think about it... It could be  cancelPropagation.  There's also the preventDefault, cancelDefault, stopDefault. What was it now again :]

[07:14:18.0000] <jgraham>
/me wonders if zewt put any clothes on

[07:14:59.0000] <annevk>
did jgraham just kill the conversation?

[07:15:05.0000] <zewt>
cool, adobe air just popped up a dialog saying "we have an update!!! [update now] [update later]" ... and "update now" was greyed out

[07:15:10.0000] <odinho>
Everyone picturing zewt naked

[07:15:28.0000] <annevk>
I have trouble picturing zewt

[07:15:51.0000] <Workshiva>
zewt sounds like a kind of newt

[07:16:04.0000] <jgraham>
It sounds a bit like a newt in a boyband

[07:16:05.0000] <Workshiva>
Maybe a very intense one, like zomg

[07:16:12.0000] <zewt>
annevk: if that makes it harder to picture me naked, then we can consider that a win for all of us

[07:16:12.0000] <jgraham>
Right, exactly

[07:16:31.0000] <Workshiva>
And newts tend to be naked, so I'm not really very affected

[07:17:11.0000] <jgraham>
At risk on underailing the conversation, I think I like zewt's proposed Sync API better than sicking's

[07:17:47.0000] <zewt>
(no! don't derail a conversation about a bunch of guys picturing me naked!)

[07:17:52.0000] <jgraham>
But I am not convinced I have enough experience with this kind of thing to offer a convincing argument

[07:18:21.0000] <Ms2ger>
Wait, what did I just walk into?

[07:18:23.0000] <jgraham>
(I also like the idea that javascript should grow some primitives to make async stuff more linear)

[07:18:32.0000] <jgraham>
Ms2ger: zewt in the nude

[07:18:42.0000] <odinho>
Ms2ger: What did you just walk out of? (shower?)

[07:19:04.0000] <Workshiva>
jgraham: "zewde"

[07:19:15.0000] <zewt>
jgraham: in principle--though it's probably too late in the game for this to fit--the "wait for message" api could have been the basis for all worker sync apis

[07:19:49.0000] <zewt>
eg. xhr.send(); getMessage(xhr.send()); // wait for what would have been the next message to the xhr client

[07:20:14.0000] <Ms2ger>
/me puts on http://www.leekspin.com/ for fun

[07:20:32.0000] <zewt>
not quite as nice as a real sync API that returns stuff and throws exceptions, but without the need to fork every single async API into two interfaces

[07:21:13.0000] <zewt>
reader = new FileReader(blob); arrayBuffer = getMessage(reader);

[07:21:29.0000] <zewt>
oh well

[08:40:13.0000] <matjas>
would other ECMAScript engine implementors be open to escaping ', < and > as well as " in the String.prototype HTML extensions, as per V8? http://code.google.com/p/v8/issues/detail?id=2217#c15

[08:42:06.0000] <matjas>
seems a bit over the top to me, but hey

[08:42:27.0000] <jgraham>
matjas: I'm pretty sure we would try anything once

[08:43:03.0000] <matjas>
jgraham: reason V8 does the extra escapes is: '_'.link('<script>...').substring(1);

[08:43:25.0000] <matjas>
but, like, *everything* is potentially dangerous

[08:45:08.0000] <dglazkov>
good morning, Whatwg!

[08:53:34.0000] <deane>
dglazkov: Good morning.

[09:00:09.0000] <annevk>
jgraham: going to update james.html5 at some point again?

[09:03:09.0000] <jgraham>
annevk: What happened to whatever used to be there?

[09:07:27.0000] <annevk>
jgraham: I don't know, I think you might have cleared it when there was some spam issue

[09:08:02.0000] <annevk>
with the idea of putting it back later

[09:16:44.0000] <niloy>
Please bring back WebSQL T____T, if not for the browser, then atleast for the native apps build with web techs T____T

[09:17:24.0000] <annevk>
what is T____T?

[09:17:24.0000] <zewt>
T____________________________________T

[09:17:38.0000] <annevk>
it's an abbreviation?

[09:17:43.0000] <zewt>
perhaps "thrift" or "talent"

[09:17:46.0000] <annevk>
I don't understand the longer form either

[09:18:45.0000] <annevk>
I take he might have meant the variant with three underscores, as http://www.urbandictionary.com/define.php?term=T____T seems sketchy in this context

[09:18:46.0000] <darobin>
annevk: I think it's one of them emoticons thingies that the young'uns use nowadays

[09:19:39.0000] <karlcow>
>One issue is that the W3C geolocation API, used by web browsers to determine your location, doesn’t tell you how your location was acquired. Was it from a wireless network? A cell-tower? A passing drone, overhead? There’s no way to know and by extension no way to adjust expectations. — http://nearfuturelaboratory.com/2012/09/04/the-atlas-of-desire/

[09:19:58.0000] <zewt>
( ﾟ∀ﾟ)

[09:20:15.0000] <jgraham>
darobin: All I am getting from it is "I'm a frog with crucifixes for eyes". Whichis interesting but doesn't seem that relevant to the point.

[09:21:16.0000] <annevk>
darobin: going to be one long blog post, huh? ;)

[09:21:31.0000] <darobin>
jgraham: I see no reason why frogs with crucifixes for eyes should be disenfranchised from the Web platform more than anyone else

[09:22:35.0000] <darobin>
annevk: beauty doesn't count the number of the years

[09:26:38.0000] <niloy>
T_T is emote of crying, the T's are eyes

[09:26:45.0000] <niloy>
I am just crying sooooooooo much T_______T

[09:28:49.0000] <niloy>
Well I hope Opera & Webkit keeps supporting them, we will all use it and someday and web & native apps, and someday everyone else will also have to support it!

[09:30:09.0000] <zewt>
javascript not scoping var to blocks repeatedly makes me :|

[09:30:34.0000] <darobin>
you just need to be more creative with your variable naming

[09:30:49.0000] <zewt>
i'd rather the scoping mechanism do its job, heh

[09:31:01.0000] <zewt>
(python has the same problem, unfortunately)

[09:31:05.0000] <smaug____>
use let :)

[09:31:20.0000] <niloy>
or iife

[09:31:22.0000] <Hixie>
odinho: there's a script they have that will do a binary search through old webkit builds to find when a regression happened

[09:32:11.0000] <odinho>
niloy: We (Opera) don't have any removal plans for websql. :-) But things can change, bla bla bla normal disclaimer talk.

[09:32:33.0000] <niloy>
odinho, yay we will win someday ^_^

[09:33:56.0000] <zewt>
smaug__________: if it actually worked in something other than FF, maybe :)

[09:33:59.0000] <jwalden>
/me resists the urge to get all stabby about websql

[09:34:00.0000] <odinho>
Hixie: I remembered I had a virtualbox with Windows, so I was able to find an old chrome (8) and it worked there. But I'm onto something else now, I have the patience of a fly :P

[09:35:02.0000] <niloy>
btw for those using urban dictionary: http://www.urbandictionary.com/define.php?term=t_t

[09:35:38.0000] <zewt>
heh, i had to do a git bisect recently ... holy boring

[09:36:05.0000] <Hixie>
odinho: it's a pretty sweet script, it does all the downloading and binary search and stuff for you. But I forget what it's called. :-)

[09:36:50.0000] <Ms2ger>
Hixie, mozregression? :)

[09:37:06.0000] <Hixie>
it's the same idea, yeah

[09:47:13.0000] <annevk>
Ms2ger: added a WebHook URL for DOM4 since you keep pushing

[09:47:49.0000] <annevk>
took me 10 minutes to learn shell/Apache interaction and that was that

[09:48:36.0000] <Ms2ger>
\o/

[09:48:49.0000] <annevk>
relearn actually

[09:48:55.0000] <annevk>
not the first post-commit hook

[09:49:50.0000] <annevk>
Hixie: it comes down to curl https://raw.github.com/WHATWG/dom/master/dom-core.html > dom-core.html (plus some stuff to make it not 500) so if you ever want to reclaim the subdomains that should be easy enough

[09:50:26.0000] <Hixie>
heh k

[09:50:38.0000] <Hixie>
seems unlikely to ever occur :-)

[09:51:41.0000] <jgraham>
Hixie: I'm noy sure it matters, but if you have document A with iframe B which itself has iframe C then it seems to me that, per the current spec, C can cause document.open to run in B during C's beforeunload

[09:52:14.0000] <Hixie>
jgraham: seems plausible

[09:52:18.0000] <Hixie>
jgraham: is that a problem?

[09:52:38.0000] <jgraham>
Hixie: I don't know

[09:52:43.0000] <Hixie>
jgraham: i guess it'll do a double unload?

[09:52:52.0000] <Hixie>
file a bug if you want me to look at it in more detail

[09:53:11.0000] <jgraham>
OK, I will see if I think of a case where it's a problem

[10:04:30.0000] <Hixie>
jgraham: as far as i can tell, the case simplifies to window A contains iframe B, B is navigated, B asynchronously invokes a task that synchronously does a beforeunload, during which A is document.open(), which synchronously does B's beforeunload reentrantly (but A and B can't document.open() at this point), followed by B's unload (d.o() is again neutered here), at which point B's original task does the original unload again.

[10:04:36.0000] <Hixie>
jgraham: which seems bad

[10:18:42.0000] <zewt>
it's not the future until i can stop worrying about starting a paragraph in an email with the word "From"

[10:46:01.0000] <GPHemsley>
/me wonders what past zewt is living in.

[11:21:20.0000] <jwalden>
GPHemsley: judging by every mailman web view in existence having >From in various bits of mail, the present past

[11:21:42.0000] <GPHemsley>
ah

[12:19:54.0000] <annevk>
Ms2ger: it's had that text since Hixie wrote it back in 2005/2006 or so

[12:20:15.0000] <annevk>
Ms2ger: need a little more in the bug than "is that intentional?" to make it actionable

[12:20:29.0000] <Ms2ger>
Make it "test this, please", then :):

[12:20:48.0000] <Hixie>
hm?

[12:21:04.0000] <Ms2ger>
XHR.getAllResponseHeaders

[12:21:15.0000] <Ms2ger>
And whether it should end with \r\n

[12:21:23.0000] <Hixie>
ah

[12:24:06.0000] <annevk>
Ms2ger: if you split it with JavaScript later not having it end in \r\n is nicer

[12:24:22.0000] <Ms2ger>
I guess

[12:24:48.0000] <Ms2ger>
What do browsers do?

[12:24:51.0000] <annevk>
Ms2ger: but yeah, someone should update the XHR test suite, I tried to have odinho do that, but he found someone else, who likely dropped the ball

[15:04:24.0000] <Hixie>
zewt: even if it's just a message to say "this has passed to something that is a descendant worker of X" or "...not an ancestor of X" or whatnot, it's still essentially impossible because if you send something from X to A to B, the message that it got from A to B might not reach X until long after X has started sending messages using this feature

[15:05:15.0000] <zewt>
Hixie: it doesn't matter if otehr messages are sent first

[15:05:27.0000] <zewt>
or other, for that matter

[15:06:08.0000] <Hixie>
ok i'm reading your message to sicking now and i'm even more confused :-)

[15:06:08.0000] <zewt>
all this is intended to do is guarantee that deadlocks can't happen in a "block until a message is received" API

[15:06:17.0000] <Hixie>
suppose i create a message port

[15:06:21.0000] <Hixie>
can i send a blocking message?

[15:06:30.0000] <zewt>
there's no such thing as "sending a blocking message"

[15:06:43.0000] <zewt>
there's only "block until a message is received"

[15:06:48.0000] <zewt>
(a message is a message is a message)

[15:06:54.0000] <Hixie>
so suppose i create a message port

[15:06:59.0000] <Hixie>
can i block until i receive a message?

[15:07:34.0000] <zewt>
so long as the "blocking allowed" flag remains set

[15:07:57.0000] <Hixie>
but the other side of the port is by definition in the same thread, so that seems bad?

[15:08:34.0000] <zewt>
you mean the "blocking on a port when you hold both ports" case? that's handled separately (the final "additionally")

[15:09:29.0000] <Hixie>
ah, i see

[15:09:52.0000] <Hixie>
i assume when you say "When a MessagePort is transferred to the current thread" you mean to imply that the internal flags and states are also cloned?

[15:10:02.0000] <Hixie>
it's unclear whether you mean MessagePort or "port"

[15:10:08.0000] <zewt>
yes, the "blocking allowed" flag being cleared persists across clones

[15:10:17.0000] <Hixie>
(MessagePort objects never actually change thread)

[15:10:17.0000] <zewt>
(once it's cleared it's cleared permanently)

[15:10:26.0000] <Hixie>
ok...

[15:11:32.0000] <Hixie>
and presumably this only happens in workers

[15:11:52.0000] <zewt>
yes (it doesn't matter if it happens in the UI thread, since the getMessage API just won't exist there)

[15:12:07.0000] <Hixie>
by "this" i mean the API

[15:12:24.0000] <zewt>
also, this is only really relevant for dedicated workers; any time you transfer to a shared worker the final "otherwise" kicks in and no blocking is ever allowed

[15:12:30.0000] <zewt>
(in either direction)

[15:13:01.0000] <Hixie>
seems kinda weird, but if browsers are willing to implement it, i guess it's ok

[15:17:14.0000] <zewt>
(correcting above--this does need to happen for ports going to the UI thread, since the other port is probably still inside a worker)

[16:11:31.0000] <cpearce>
annevk: ping

[16:12:06.0000] <cpearce>
/me suspects annevk is fast asleep...


2012-09-05
[17:04:50.0000] <nattokirai>
heycam: ping

[17:05:00.0000] <heycam>
nattokirai, pong

[18:02:14.0000] <crocket>
Does mozilla developer network provide proper learning materials for HTML, CSS, and javscript?

[18:02:25.0000] <crocket>
w3schools is said to suck.

[18:03:28.0000] <zewt>
w3schools was the first site i blocked on google as soon as google grew that feature

[18:03:48.0000] <zewt>
can't speak for learning materials but mdn is usually okay as a reference

[18:04:26.0000] <MikeSmith>
MDN has some how-to docs as well

[18:04:45.0000] <MikeSmith>
gimme a minute

[18:05:23.0000] <MikeSmith>
MDN JavaScript Guide: https://developer.mozilla.org/en-US/docs/JavaScript/Guide

[18:05:25.0000] <crocket>
MDN seems to contain firefox-specific extensions.

[18:05:46.0000] <zewt>
(browsing mdn tends to not be so good, feels like a bunch of isolated pages connected by huge indexes, but fine for individual things reached through goog)

[18:06:48.0000] <MikeSmith>
crocket: yeah it has some things like that but generally they're clearly marked

[18:07:35.0000] <MikeSmith>
and it now includes a lot of information about things like implementation status in all major browsers

[18:07:40.0000] <MikeSmith>
not just Firefox

[18:08:44.0000] <MikeSmith>
the other thing is, for pretty much every bug that gets created for implementing a new standards feature, a "needs docs" flag gets added to the bug

[18:08:46.0000] <crocket>
Does <body> have border property?

[18:09:24.0000] <zewt>
quickest way to answer questions like that is to try it :)

[18:10:21.0000] <zewt>
(randomly makes me think back on something I hit a few months ago, trying to have a width: 100%; height: 100%; border: 1px whatever; body and hitting the "100% + 2px" problem; guess I should revisit that using box-sizing)

[18:10:33.0000] <MikeSmith>
crocket: what zewt said

[18:11:15.0000] <zewt>
(technically I said one relevant thing and one rambling, obscure thing; go with the first)

[18:11:16.0000] <MikeSmith>
open up Firebug or Web Inspector on any page, go in and add a "body { border: 5px solid green}" CSS rule

[18:11:28.0000] <MikeSmith>
and see what happens

[18:12:50.0000] <crocket>
meh

[18:13:08.0000] <MikeSmith>
anyway, the Mozilla docs team goes in and adds docs to MDN for all new standards feature every time any new feature is implemented in Firefox

[18:13:11.0000] <zewt>
if you're not willing to try things out for yourself, you'll have difficulty in any platform :)

[18:13:22.0000] <crocket>
zewt, I'll try

[18:13:45.0000] <MikeSmith>
MDN CSS guide: https://developer.mozilla.org/en-US/docs/CSS/Getting_Started

[18:14:35.0000] <MikeSmith>
or https://developer.mozilla.org/en-US/docs/CSS is better

[18:14:43.0000] <MikeSmith>
bunch of tutorial docs linked to there

[18:22:47.0000] <MikeSmith>
crocket: you can also use http://jigsaw.w3.org/css-validator/#validate_by_input to test whether a particular CSS is valid or not

[18:23:00.0000] <crocket>
MikeSmith, ok

[19:00:06.0000] <crocket>
How do I use "inspect element" feature in firefox to modify CSS?

[19:00:10.0000] <crocket>
I tried, but it doesn't work.

[19:07:58.0000] <crocket>
What tag do I use to specify properties of a part of a sentence?

[19:07:59.0000] <crocket>
<span.?

[19:08:02.0000] <crocket>
<span>?

[19:25:31.0000] <Oliver_>
Hello everyone!

[19:39:25.0000] <divya>
care to explain what "properties" mean crocket ?

[19:39:56.0000] <crocket>
divya, font-size

[19:39:59.0000] <crocket>
font-weight

[19:40:01.0000] <crocket>
such things

[19:40:07.0000] <divya>
ya span would do

[19:40:15.0000] <crocket>
divya, But span looks dirty.

[19:40:18.0000] <divya>
o?

[19:40:19.0000] <crocket>
Do I have a neater way?

[19:40:34.0000] <divya>
use <u>, <i> or <b>? but they all ahve default properties set

[19:48:11.0000] <crocket>
divya, how about <div>?

[19:48:19.0000] <divya>
wat no

[19:48:24.0000] <crocket>
divya, why not?

[19:48:30.0000] <divya>
because it is for a division

[19:48:34.0000] <divya>
a block level alteration

[19:48:39.0000] <divya>
not for inline content

[19:48:39.0000] <crocket>
divya, I don't know what it means yet.

[19:48:44.0000] <divya>
then checkout MDN

[19:49:03.0000] <crocket>
divya, What do <h1>, <h2>, ... mean?

[19:49:14.0000] <crocket>
I don't understand the meaning of numbers.

[19:49:25.0000] <divya>
go to MDN that MikeSmith linked to

[19:49:29.0000] <divya>
and read up on html page.

[01:41:41.0000] <annevk>
cpearce: I was indeed

[01:43:48.0000] <cpearce>
annevk: yeah, I was going to ask whether object-fit:contain on the :fullscreen style is supposed to only apply to <img> elements which are fullscreen?

[01:45:58.0000] <cpearce>
object-fit is only mentioned here: http://dev.w3.org/csswg/css3-images/#object-fit which implies it's image only, I just wanted to check,

[01:46:28.0000] <cpearce>
since we've had a few bugs filed against gecko recently regarding scrolling fullscreen content, and that's relevant here.

[01:55:09.0000] <annevk>
also for <video> and such

[01:55:35.0000] <annevk>
especially video

[01:59:39.0000] <odinho>
annevk: XHR testsuite: He updated it a bit, but yeah, nothing great. He wrote a few extra tests. And found a few bugs that he wrote in a document.

[02:00:02.0000] <Ms2ger>
Hey, a few is better than none

[02:03:01.0000] <annevk>
odinho: spec bugs?

[02:03:23.0000] <odinho>
annevk: testsuite bugs :P And browser ofc bugs.

[02:03:31.0000] <annevk>
ah good

[02:47:11.0000] <Ms2ger>
c = new(window.ActiveXObject || XMLHttpRequest)("Microsoft.XMLHTTP")

[03:52:41.0000] <annevk>
Ms2ger: so that fails in everything but IE?

[03:53:12.0000] <Ms2ger>
Nah, extra arguments are ignored

[03:53:26.0000] <Ms2ger>
Only we have a dictionary argument in that spot

[03:53:30.0000] <annevk>
right

[03:53:49.0000] <annevk>
and we wanted to maybe change the whole AnonXMLHttpRequest design to use that dictionary instead

[03:54:15.0000] <Ms2ger>
Yeah

[03:54:28.0000] <annevk>
I guess someone will keep me posted

[03:54:54.0000] <annevk>
is anyone else going to maintain XHR or should we WHATWG that too?

[03:55:29.0000] <Ms2ger>
I guess

[03:56:43.0000] <annevk>
that could apply to either option :p

[03:57:29.0000] <Ms2ger>
No idea who would maintain it at the W3C

[03:57:32.0000] <Ms2ger>
darobin?

[03:58:07.0000] <darobin>
no idea either

[03:58:22.0000] <darobin>
annevk: I presume you haven't heard back on your post?

[03:58:36.0000] <annevk>
nope

[03:58:46.0000] <darobin>
let me figure this one out

[03:59:25.0000] <annevk>
in 2006 or so timbl told rigo to make it happen, instead of being a lawyer and doing as told, rigo objected and nothing happened

[03:59:58.0000] <annevk>
it prolly then escalated at some point within the Team

[04:00:11.0000] <annevk>
and the Team being lame instead of making a decision they put it forward to the AC

[04:00:16.0000] <annevk>
which is where all good ideas go to die

[04:00:30.0000] <annevk>
400 people are not going to embrace change

[04:01:50.0000] <darobin>
that's not exactly what happened, but I can't say I disagree with the sentiment

[04:31:08.0000] <MikeSmith>
there were actually only 24 AC reps who responded to the survey about the document license

[04:31:31.0000] <MikeSmith>
out of 350-400 or so AC reps

[04:31:57.0000] <MikeSmith>
so it's hardly like there was even a resounding mandate on it from the AC

[04:33:14.0000] <MikeSmith>
all that the survey really indicated is that we had 300+ other AC reps who didn't feel strongly enough about it either way to take the time to respond with their opinions

[04:34:58.0000] <odinho>
Oh, that doesn't sound very good.

[04:36:52.0000] <MikeSmith>
hmm

[04:37:32.0000] <darobin>
more importantly, the question was IMHO phrased completely wrong

[04:38:22.0000] <MikeSmith>
I guess I shouldn't say anything more

[04:38:32.0000] <darobin>
it was put forth as a possible exemption granted only to the HTML WG, which is silly because there's no reason any group should have an exemption, and it's a political hot button to boot

[04:39:03.0000] <MikeSmith>
yeah

[04:39:13.0000] <darobin>
IMHO, and like Mike I don't want to speak out too much on this just yet, it should be up to individual groups to select which licence to use

[04:39:24.0000] <darobin>
groups do the work, they have the stakeholders, they should make the call

[04:39:39.0000] <MikeSmith>
100% agreed about that personally

[04:40:03.0000] <MikeSmith>
and within groups, editors do the hands-on editing work

[04:40:50.0000] <MikeSmith>
anyway I'm realizing now I can't remember how much of the details are still secret

[04:41:27.0000] <darobin>
the number of respondents probably was :-p

[04:41:35.0000] <MikeSmith>
yeah

[04:41:53.0000] <darobin>
the rest I already knew, so it probably wasn't

[04:44:40.0000] <MikeSmith>
anyway I'm not sure about that number

[04:44:54.0000] <MikeSmith>
I could be plain wrong and thinking about something else

[04:45:34.0000] <MikeSmith>
and I can't document it so doesn't matter anyway

[04:45:45.0000] <MikeSmith>
people shouldn't listen to what I say

[04:46:19.0000] <Ms2ger>
Yay W3C: https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0264.html

[04:47:56.0000] <annevk>
I wanted to click on that, but then realized I no longer can :/

[04:50:56.0000] <Ms2ger>
You're not missing much

[04:54:12.0000] <jgraham>
Ms2ger: I think what you meant to say was "Oh well then you missed out on life-changing information"

[04:54:23.0000] <jgraham>
But with more commas

[04:58:32.0000] <Ms2ger>
Well, I can't tell him what you get when you dereference that eleph^WIRI, so we'll never know if it would have been life-changing

[05:47:04.0000] <annevk>
MikeSmith: you around still?

[05:47:09.0000] <MikeSmith>
yeah

[05:47:17.0000] <annevk>
MikeSmith: what are you going to cover next week?

[05:47:28.0000] <annevk>
MikeSmith: and are we going to prepare in one way or another together?

[05:48:34.0000] <MikeSmith>
in part I'm going to talk about recent HTML WG developments, so we're definitely not going to have overlap there

[05:49:07.0000] <MikeSmith>
but we should get together to compare notes

[05:49:46.0000] <MikeSmith>
I'm otherwise planning to talk about new features at a pretty high level

[05:49:58.0000] <darobin>
maybe it would be more entertaining if you let annevk cover the HTML WG instead

[05:49:59.0000] <MikeSmith>
and implementation status

[05:50:03.0000] <MikeSmith>
heh

[05:50:10.0000] <MikeSmith>
yeah that would definitely be entertaining

[05:50:38.0000] <MikeSmith>
I'm going to work from the list of specs at http://platform.html5.org/specs/a

[05:50:45.0000] <MikeSmith>
http://platform.html5.org/specs/

[05:50:57.0000] <MikeSmith>
and http://platform.html5.org/

[05:51:12.0000] <annevk>
okay

[05:51:24.0000] <MikeSmith>
and http://www.w3.org/Mobile/mobile-web-app-state/ too probably

[05:52:08.0000] <MikeSmith>
maybe also talk about http://ringmark.io/

[05:52:13.0000] <Ms2ger>
Hah

[05:52:38.0000] <annevk>
sounds good

[05:52:54.0000] <annevk>
maybe I'll do my code point / byte talk for something a little bit more low level

[05:52:55.0000] <darobin>
/me isn't sure he'd cover RingMark, it's not really finalised atm IMHO

[05:53:14.0000] <jgraham>
I wouldn't say anything nice about RingMark at least :)

[05:56:25.0000] <jgraham>
I guess I should qualify that with in-principle I have no problem with the idea of a graded set of targets for browsers to implement based on developer priorities

[05:56:44.0000] <jgraham>
But the reality of ringmark is highly non-ideal

[06:01:03.0000] <tantek>
indeed, last I checked the ringmark folks were including all kinds of "-webkit-" properties as part of their "platform/standard"

[06:06:03.0000] <darobin>
/me is now out of CoreMob, won't comment :)

[07:38:46.0000] <annevk>
MikeSmith: when are you in the Netherlands?

[07:39:05.0000] <annevk>
MikeSmith: middle of next week?

[07:49:37.0000] <MikeSmith>
annevk: arriving on the 13th at around 8pm

[07:49:49.0000] <annevk>
ah okay, so quite late :)

[07:49:56.0000] <MikeSmith>
yeah

[08:31:39.0000] <dglazkov>
good morning, Whatwg!

[08:44:40.0000] <Hixie>
lol, the only thing that has happened in the last 5 days on the w3c html wg specs is that they've removed the form for sending feedback and removed links to the whatwg

[08:44:58.0000] <Ms2ger>
They hadn't done that yet?

[08:45:17.0000] <Hixie>
seems not

[08:46:14.0000] <annevk>
I have the feeling that's about the same that happened to the CSSOM in the last, well, I stopped counting

[08:48:01.0000] <annevk>
the way the CSS WG uses version control these days makes it hard to view progress for a single spec

[08:48:16.0000] <annevk>
or maybe there is a way that I don't know

[08:48:59.0000] <Ms2ger>
I love how Bert always has four commits per change

[08:49:03.0000] <annevk>
maybe http://dvcs.w3.org/hg/csswg/log/tip/cssom/Overview.html

[08:50:54.0000] <Hixie>
TabAtkins: is http://lists.w3.org/Archives/Public/www-style/2012Jul/0014.html being tracked? it doesn't look like it got a formal reply

[08:51:47.0000] <annevk>
doesn't look like much happened

[08:51:56.0000] <annevk>
just some moving things around

[09:00:39.0000] <Ms2ger>
Adam Sobieski? I think I've seen that name before...

[09:02:17.0000] <Hixie>
does _anyone_ implement the dnd addElement() properly?

[09:03:19.0000] <Ms2ger>
I doubt it

[09:03:21.0000] <Ms2ger>
It's dnd

[09:04:12.0000] <TabAtkins>
Hixie: I don't remember seeing this!  It looks like his use-cases are all addressed by :user-error now (the official name for :moz-ui-invalid).

[09:09:25.0000] <jwalden>
given the dnd spec is so wrong, it's not a surprise implementations are wrong</troll>

[09:09:43.0000] <jwalden>
:-)

[09:10:03.0000] <jgraham>
Hixie: Got a test?

[09:21:23.0000] <Hixie>
TabAtkins: k, thanks

[09:21:37.0000] <Hixie>
jwalden: it's not wrong :-P

[09:21:44.0000] <Hixie>
jgraham: live dom viewer download

[09:21:50.0000] <jwalden>
success troll!

[09:22:31.0000] <Hixie>
looks like the browsers that support addElement() just treat it like setDragImage(), and they allow any element to be passed to setDragImage()

[09:23:06.0000] <Hixie>
i wonder if a should just remove addElement(), or leave it as an alias to setDragImage()

[09:24:44.0000] <Hixie>
webkit doesn't have addElement()

[09:25:04.0000] <Hixie>
(which is weird because i could have sworn it webkit documentation that i got it from)

[09:25:27.0000] <Hixie>
firefox treats it as setDragImage() without coordinates

[09:25:54.0000] <Hixie>
opera doesn't do anything with it but seems to not fire an error message

[09:28:13.0000] <Hixie>
i'm just gonna drop it

[10:24:47.0000] <miketaylr>
are we going to get something like srcList (DOMTokenList) for srcset? slicing up strings by hand doesn't sound fun

[10:30:46.0000] <Hixie>
miketaylr: i've been asking people on whatwg@ for use cases for script manipulation

[10:30:57.0000] <Hixie>
miketaylr: so far nobody has described anything concrete

[10:31:11.0000] <Hixie>
miketaylr: when they do, i'll try to design an api that makes sense for it

[10:31:20.0000] <miketaylr>
fair enough

[10:32:13.0000] <miketaylr>
Hixie: fwiw, i don't have one either.

[10:32:26.0000] <Hixie>
yeah, i couldn't come up with one either, even a theoretical oe

[10:32:35.0000] <Hixie>
constructing it, sure

[10:32:37.0000] <Hixie>
but reading it?

[10:32:50.0000] <Hixie>
someone suggested it would be good to have a way to force a specific one to be selected

[10:33:00.0000] <Hixie>
but again, that seems easier to do by just constructing a srcset with only the value you want

[10:33:07.0000] <Hixie>
that to use an api

[10:33:17.0000] <miketaylr>
my use case: if any of the filenames have the string "dog" in them, change them to a cat picture.

[10:33:20.0000] <miketaylr>
nailed it.

[10:33:43.0000] <Hixie>
you can do that today without any more of an api that .srcset :-)

[10:33:48.0000] <miketaylr>
heh

[10:33:52.0000] <Hixie>
.srcset.replace() or whatever the right regexp is

[10:36:08.0000] <miketaylr>
guess we can wait for srcsetQuery to pave some cowpaths

[10:41:59.0000] <Hixie>
annevk, Ms2ger: so for seamless="" we need to fire events (e.g. mouse and key events, focus events) across the iframe boundary so that the outer page doesn't miss events

[10:42:25.0000] <Hixie>
annevk, Ms2ger: e.g. if the user has focus in a seamless iframe but presses an accesskey="" key or onkeypress="" key set up in the outer frame

[10:42:53.0000] <Hixie>
annevk, Ms2ger: or if the user has a dialog and drags it across the inner iframe, so that the page doesn't lose track of where the mouse is during the drag

[10:43:22.0000] <Hixie>
annevk, Ms2ger: this seems like it'd require pretty invasive changes to the event model, is it something you want to do instead of having me try to patch it in the html spec?

[10:43:35.0000] <Hixie>
annevk, Ms2ger: (i can provide a link to feedback on the topic if you're interested)

[10:44:19.0000] <annevk>
you can't just dispatch the events again?

[10:45:29.0000] <Hixie>
no, because you want the capture phase on the outer frame to happen before the inner frame

[10:45:37.0000] <Hixie>
and stopPropagation has to work across both events

[10:45:42.0000] <Hixie>
and they have to be different Event objects

[10:45:48.0000] <Hixie>
and mouse event coordinates need to be adjusted

[10:45:55.0000] <Ms2ger>
Can you just mess with the propagation chain?

[10:45:56.0000] <Hixie>
and it has to work at multiple levels

[10:46:09.0000] <Hixie>
(consider multiple nested iframes)

[10:46:11.0000] <Ms2ger>
Oh, hmm, adjusting coordinates sounds like fun

[10:46:15.0000] <annevk>
hmm, sounds like something for HTML to define as DOM does not know about Window

[10:46:20.0000] <Hixie>
and also this might end up being a very similar system as for web components

[10:46:34.0000] <annevk>
alternatively, you could merge all of DOM into HTML and maintain both ;)

[10:46:54.0000] <Hixie>
you guys keep taking stuff out, it's too late to give it back :-P

[10:47:56.0000] <Hixie>
is there some way you guys could spec all that but just provide a hook for me to say what the objects are that should get the events fired on and stuff? so you don't have to know about Window/iframe/seamless?

[10:48:01.0000] <Hixie>
that seems like it'd be the best solution

[10:48:43.0000] <annevk>
1) DOM does not have mouse events

[10:48:53.0000] <Hixie>
well, nothing has mouse events currently

[10:49:11.0000] <Hixie>
not properly specced, anyway

[10:49:17.0000] <annevk>
yeah :/

[10:49:24.0000] <annevk>
definitely not signing up for that at this point though

[10:51:45.0000] <Ms2ger>
Hey, you'll get mouseevents.spec.whatwg.org if you do!

[10:52:06.0000] <annevk>
teehee, more domain names

[10:52:17.0000] <annevk>
Hixie: not exactly sure what you'd want DOM to define

[10:52:52.0000] <annevk>
Hixie: some kind of pausing in dispatch and a more global stop propagation flag?

[10:53:44.0000] <annevk>
Hixie: some kind of bug report with the details and the link to the use case is prolly best, can't really give an ETA

[10:54:11.0000] <Hixie>
basically a way to say "when an event is dispatched in this browsing context, the following tree of trees is to be used as the chain: ..." and then you deal with all the cloning events, checking dispatch cancelation and so on, and have a hook for when the event is retargetted so that event definitions can say what happens to their values and stuff

[10:54:16.0000] <Hixie>
k

[11:07:16.0000] <Hixie>
anne: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18780

[11:13:26.0000] <smaug____>
Hixie: I thought event re-targeting was discarded

[11:13:46.0000] <smaug____>
(for seamless)

[11:16:06.0000] <smaug____>
that is at least who I interpret the email thread about it

[11:16:42.0000] <smaug____>
/me comments on the bug

[11:27:04.0000] <dsheets>
wow… ms on public-fx… wow...

[11:28:01.0000] <jamesr>
they're in the CSS WG and that is a joint deliverable between CSS and SVG

[11:30:50.0000] <dsheets>
not their membership… their approach

[11:31:23.0000] <dsheets>
doesn't seem very savvy

[11:39:02.0000] <Hixie>
smaug____: what part of the thread suggested it was discarded?

[11:39:18.0000] <Hixie>
smaug____: i don't see anything to suggest that, but maybe i missed something

[11:39:45.0000] <smaug____>
Hixie: I sent email explaining the problems

[11:39:52.0000] <Hixie>
url?

[11:39:52.0000] <smaug____>
and dglazkov said "We should probably recreate an event object at each seamless frame boundary."

[11:40:21.0000] <Hixie>
right

[11:40:43.0000] <Hixie>
retargetting always involves new objects

[11:40:47.0000] <Hixie>
you can't reuse the objects

[11:40:49.0000] <smaug____>
no

[11:40:57.0000] <smaug____>
retargeting is retargeting

[11:41:09.0000] <Hixie>
ok well call it whatever you want :-)

[11:41:19.0000] <smaug____>
but ok, perhaps we do agree what should be done :)

[11:41:21.0000] <Hixie>
i'm talking about dispatching events at multiple scopes, with new objects at each level

[11:41:24.0000] <Hixie>
same as xbl

[11:41:27.0000] <smaug____>
right

[11:41:30.0000] <smaug____>
well, not same as xbl1

[11:42:18.0000] <smaug____>
/me doesn't remember what shadow DOM does

[11:42:56.0000] <smaug____>
Shadow DOM: "In the cases where events cross the shadow boundaries, the event's information about the target of the event is adjusted in order to maintain upper boundary encapsulation."

[11:43:15.0000] <smaug____>
so it is closer to XBL1

[12:46:10.0000] <Hixie>
heycam|away: yt?

[13:07:27.0000] <deane>
Hixie: He's probably not there as it was only 07:49 here. Not sure when he would start work.

[14:14:23.0000] <jkew>
Mildly dumb question; is there an xml namespace for microdata? Is it considered harmful?

[14:18:01.0000] <gavinc>
jkew: http://www.w3.org/TR/2012/WD-microdata-rdf-20120112/ may help you, or make you more confused

[14:18:42.0000] <gavinc>
see http://www.w3.org/ns/md# it's not an XML namespace, but it is a well known URI

[14:19:47.0000] <gavinc>
err, should have been http://www.w3.org/TR/microdata-rdf/

[14:19:49.0000] <gavinc>
sorry

[16:02:10.0000] <heycam>
hi Hixie

[16:07:00.0000] <Hixie>
heycam: we have a weird situation with HTMLCollection and its descendants, where they introduce operations that have the same name as in HTMLCollection, with different behaviour

[16:07:16.0000] <Hixie>
heycam: how this works in practice probably needs to be tested

[16:07:36.0000] <heycam>
hmm yes I remember there was a bug on this

[16:07:49.0000] <Hixie>
i looked but couldn't find it

[16:08:06.0000] <heycam>
I remember replying on it just recently… because you asked for some IDL way to say "override"

[16:08:24.0000] <heycam>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17201

[16:08:39.0000] <Hixie>
aha, wasn't in webidl :-)

[16:09:01.0000] <Hixie>
ah, i see your comment

[16:09:08.0000] <Hixie>
the answer to all those questions is "i've no idea"

[16:09:10.0000] <Hixie>
:-)

[16:09:17.0000] <heycam>
ha

[16:12:13.0000] <heycam>
ignoring what happens in practice, it would be good if calling HTMLCollection's namedItem on an HTMLPropertiesCollection object does something consistent with the definition from HTMLCollection

[16:13:22.0000] <Hixie>
i would suspect that the answer is entirely constrained by legacy

[16:13:46.0000] <heycam>
might be, but HTMLPropertiesCollection isn't that new. I guess maybe for the other descendents of HTMLCollection?

[16:13:50.0000] <heycam>
er, isn't that old

[16:14:00.0000] <Hixie>
HTMLPropertiesCollection should just be consistent with the others, yeah

[16:18:23.0000] <heycam>
Hixie, in the green author box for HTMLOptionsCollection it says "element = collection.item(name)". is that right?

[16:18:57.0000] <Hixie>
yeah, there's a legacycaller in the idl

[16:19:27.0000] <heycam>
but "item"?

[16:19:41.0000] <Hixie>
oh, right. yeah, i just filed a bug on DOM Core for that.

[16:19:46.0000] <Hixie>
turns out all browsers support it.

[16:20:02.0000] <heycam>
so item takes integers and names

[16:20:33.0000] <Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18784

[16:37:00.0000] <zewt>
drawing a blank here--is there a term for a node relationship on a rooted tree, where the path from node A to B starts by going to the parent

[16:37:41.0000] <zewt>
i guess "nodes that aren't descendants of the current node" is closer

[16:38:00.0000] <say2joe>
siblings?

[16:38:29.0000] <zewt>
that's just other children of your parent

[16:39:08.0000] <say2joe>
not sure i understand what you mean.

[16:39:43.0000] <zewt>
parents; grandparents; siblings; aunts, uncles; anything that you'd go up to your parent to reach, rather than down to a child

[16:39:51.0000] <say2joe>
i can only think of ancestors or siblings as fitting your question as an answer

[16:39:55.0000] <zewt>
i think simply "not a descendant" is good enough

[16:40:03.0000] <say2joe>
ancestor

[16:40:05.0000] <dsheets>
and not self

[16:40:05.0000] <zewt>
(not a descendant nor yourself)

[16:40:35.0000] <say2joe>
but ancestors does not cover lateral nodes (aunt, uncles, etc).

[16:40:42.0000] <zewt>
siblings aren't ancestors :)

[16:41:13.0000] <say2joe>
i think you're right… not a descendent.

[16:41:51.0000] <astearns>
parents, grandparents but not great-grandparents? or great-uncles?

[16:42:05.0000] <heycam>
and n-th cousins m-times removed

[16:58:12.0000] <zewt>
laughing at my desk at someone calling { image: 'img2.jpg', density: '2x', query: '300w' } "fractal complexity"

[16:59:17.0000] <say2joe>
hmmm. last i checked… that's just adaptive images in light of RWD

[16:59:24.0000] <say2joe>
i'd be laughing too.


2012-09-06
[17:04:03.0000] <zewt>
i dream of gmail undo that doesn't lag behind by ten seconds when I hold ^Z for a second

[17:11:52.0000] <ubitux>
anyone has an example of a webvtt file with one or more "cue identifier"?

[17:12:52.0000] <ubitux>
i've a hard time figuring out what it is useful for, and i'm wondering if i'm not misunderstanding the spec

[17:13:41.0000] <zewt>
hmm, "not a descendant" isn't right, since that would include nodes in different trees

[17:14:32.0000] <Hixie>
ubitux: the cue identifier is the line before the line with the -->

[17:14:39.0000] <Hixie>
ubitux: it's not very useful except for styling the cue from CSS

[17:15:01.0000] <ubitux>
Hixie: right, so it's to keep compat with the number in the old subrip and first versions of the webvtt?

[17:15:12.0000] <ubitux>
oh you can access it from the css? fear.

[17:15:24.0000] <zewt>
(and from scripts, but standalones don't care about that)

[17:34:33.0000] <zewt>
anyone recall off-hand where the MessagePort GC issue was explained? (not sure if it was on a list or the BTS)

[21:32:40.0000] <Hixie>
aha, another checkin from the w3c html editors! this one removing the links to the whatwg spec that say where you can find roughly the same text under a more liberal license

[21:33:58.0000] <deane>
Just tell them you want it all back now.

[21:34:39.0000] <zewt>
Hixie: replaced with more /TR/ links, just to avoid confusion

[21:35:04.0000] <Hixie>
zewt: ?

[21:35:49.0000] <zewt>
jooooke

[21:38:38.0000] <Hixie>
ah

[21:38:45.0000] <Hixie>
didn't seem implausible :-)

[21:38:57.0000] <Hixie>
i was just confused cos i didn't see it in the diff :-)

[21:39:38.0000] <zewt>
the best satire--things that are completely absurd and completely plausible at the same time :)

[00:28:10.0000] <jgraham>
/me wonders what a "Matrix Maker" is, fears it is nothing good

[00:41:53.0000] <MikeSmith>
jgraham: yeah I wondered about that when I saw it too

[00:42:03.0000] <MikeSmith>
but I can't remember where I saw it

[00:42:06.0000] <MikeSmith>
bugmail?

[00:42:10.0000] <MikeSmith>
e-mail?

[00:42:21.0000] <jgraham>
coremob

[00:42:31.0000] <MikeSmith>
ah yeah

[00:43:20.0000] <MikeSmith>
darobin: so what is Matrix Maker?

[00:46:35.0000] <Ms2ger>
Is it darobin's new job description?

[00:47:20.0000] <darobin>
Matrix Maker? where?

[00:47:43.0000] <darobin>
oh, in the TF

[00:48:23.0000] <darobin>
it's a tool that allows you to list specs vertically, and device types or UAs horizontally, and shows you a pretty report of the passing stuff

[00:49:46.0000] <MikeSmith>
darobin: ah ok

[00:49:53.0000] <darobin>
ah, I knew it would be fun to select Julian for my first bug

[00:49:55.0000] <jgraham>
I don't like it when people start doing that/

[00:50:12.0000] <jgraham>
It gives people all the wrong incentives for sontributing tests

[00:50:13.0000] <MikeSmith>
darobin: I thought you said "hug" there for a second

[00:50:16.0000] <jgraham>
*contributing

[00:50:21.0000] <darobin>
rofl

[00:50:29.0000] <MikeSmith>
Ms2ger: pretty sure his new title is "The Freshmaker"

[00:50:48.0000] <jgraham>
Maybe all he needs is a hug

[00:51:08.0000] <MikeSmith>
jgraham: what you mean about giving the wrong incentives?

[00:51:35.0000] <darobin>
mix me up with some coke!

[00:52:53.0000] <jgraham>
MikeSmith: I mean that people tend to start making tests in order to look good rather than in order to find bugs

[00:53:02.0000] <MikeSmith>
ah

[00:53:21.0000] <MikeSmith>
yeah

[00:53:28.0000] <darobin>
you only good if your tests catch problems with the other implementations

[00:53:58.0000] <jgraham>
Or with your own implementation :)

[00:54:39.0000] <MikeSmith>
I thought the goal was to construct your test suites such that your browser passes all the tests but other browsers tank on it

[00:54:52.0000] <darobin>
so long as everyone does that, we all win

[00:54:53.0000] <MikeSmith>
then you do a blog posting with a nice graphic showing that

[00:55:00.0000] <jgraham>
But there is a history of people cherry-picking tests to release based on "we get 100% and other people get 0% due to a single bug"

[00:55:55.0000] <jgraham>
That is, you intentionally find something that breaks in other browsers and make each test depend on it even if it isn't really relevant

[00:55:55.0000] <darobin>
speaking of tests and stuff, any suggestions on what would be most useful to cover at Test The Web Forward Paris are welcome

[00:56:47.0000] <jgraham>
Ms2ger, annevk Someone (TM) suggested writing DOM4 tests at TTWF. Does that sound sensible?

[00:57:13.0000] <annevk>
http://testsuite.org/

[00:57:19.0000] <jgraham>
(actually I have no idea who the someone was)

[00:57:28.0000] <darobin>
I thought it was you jgraham :)

[00:57:45.0000] <jgraham>
darobin: I thought I just agreed that it might be a good idea

[00:57:56.0000] <darobin>
heh

[00:58:02.0000] <darobin>
"It wasn't me"

[00:59:13.0000] <jgraham>
annevk: Well yeah, but do you have any feeling for whether it is well tested or not?

[00:59:37.0000] <annevk>
jgraham: parts are well tested by tests from Ms2ger and AryehGregor

[00:59:47.0000] <annevk>
jgraham: those tests are somewhere in W3C dcvs

[00:59:53.0000] <annevk>
dvcs?

[00:59:53.0000] <jgraham>
OK, I guess I will need to look in more detail

[01:00:18.0000] <jgraham>
dcvs -> like cvs but with more "d"

[01:00:53.0000] <jgraham>
darobin: DOM APIs for form elements might also be good

[01:01:05.0000] <jgraham>
HTMLOptionCollection and so on

[01:01:13.0000] <darobin>
ooh yeah, that's a good one

[01:01:22.0000] <darobin>
I might actually take that one for my group

[01:01:38.0000] <darobin>
/me bbiab

[01:03:58.0000] <annevk>
Hixie: with seamless there's guaranteed sync access between the two trees right?

[01:04:08.0000] <annevk>
Hixie: why does the object need to be duplicated?

[01:04:23.0000] <annevk>
Hixie: why can't you just expand the dispatch tree

[01:04:30.0000] <annevk>
Hixie: as you've done for Window already

[01:10:55.0000] <smaug____>
annevk: mouseevent coordinates wouldn't make sense

[01:11:45.0000] <smaug____>
event retargeting can't be used with seamless, but there needs to be separate events per document

[01:11:58.0000] <annevk>
unless they are against the outer document when dispatched on a seamless frame

[01:12:03.0000] <smaug____>
(event target chain can be created before dispatching either one)

[01:12:11.0000] <annevk>
but I guess now browsers have seamless without this event model it's too late for that

[01:12:43.0000] <smaug____>
I don't think seamless is in any way stable thing yet

[01:12:43.0000] <Ms2ger>
jgraham, events, maybe

[01:13:26.0000] <annevk>
jgraham: actually not, dvcs.w3.org

[01:13:36.0000] <annevk>
jgraham: oh, maybe you were joking :)

[01:14:42.0000] <Ms2ger>
I was thinking about boxes with links to the tests in the spec, btw

[01:20:09.0000] <jgraham>
Little boxes in the margin, little boxes filled with links-to-tests?

[01:20:28.0000] <annevk>
I need to download some new Weeds episodes

[01:20:33.0000] <jgraham>
Ms2ger: But seriously, please continue. I want something like that too

[01:20:49.0000] <Ms2ger>
Yeah, something like that

[01:20:58.0000] <annevk>
Ms2ger: we should Hixie to abstract his system

[01:21:13.0000] <annevk>
Ms2ger: get*; so we can use it for DOM / Encoding / Fullscreen / ...

[01:21:25.0000] <Ms2ger>
I wrote a script to pull out the rel=help links from tests, and put the data into a json file

[01:21:32.0000] <jgraham>
The main problem with links to tests is working out which test should be linked where

[01:21:37.0000] <Ms2ger>
Now I just need to coerce someone into doing the frontend :)

[01:23:57.0000] <jgraham>
I don't like rel=help

[01:24:04.0000] <jgraham>
For a start it doesn't work

[01:24:15.0000] <jgraham>
Because a test is not a file

[01:24:47.0000] <jgraham>
e.g. the html5lib tests run in 3 different modes depending on the query string

[01:25:22.0000] <Ms2ger>
Let's leave the html5lib tests out of this ;)

[01:25:33.0000] <jgraham>
Let's not

[01:25:46.0000] <jgraham>
Making tests that depend on the query string isn't exactly uncommon

[01:27:15.0000] <jgraham>
Opera seem to have ~4500 tests that require a query string (and ~20 that require a fragment id)

[01:28:26.0000] <Ms2ger>
OH: "Do you have a use case that does not involve the vanity of the library's authors?"

[01:29:52.0000] <Ms2ger>
jgraham, do those usually test different features when used with different query strings?

[01:31:40.0000] <Ms2ger>
/me goes off for a bit

[01:31:41.0000] <jgraham>
No idea

[01:32:24.0000] <jgraham>
In any case my point is that linking tests to files is the wrong data model

[01:32:29.0000] <jgraham>
Tests are URIs

[01:33:04.0000] <jgraham>
You could of course make each test that can be loaded with > 1 URI has to list that in the test file, or something

[01:33:19.0000] <smaug____>
I need chromium nightly. where can I find the .zip or .tar.gz file for linux

[01:33:39.0000] <smaug____>
(always difficult to find the nightly chromium build for linux)

[01:38:32.0000] <smaug____>
hmm, now I found it, but it doesn't run on this machine

[01:48:40.0000] <annevk>
Firefox does not allow dynamically setting the base URL?

[01:48:48.0000] <annevk>
That makes testing annoying

[01:55:29.0000] <annevk>
fwiw

[01:55:45.0000] <annevk>
there is no interop for <base href=about:blank><script src=local.js></script>

[01:56:06.0000] <annevk>
most browsers load local.js relative to the current file, Gecko does not

[01:57:00.0000] <annevk>
with a twist of course, Firefox view source resolves it relative too

[01:57:10.0000] <annevk>
that's some confusing mismatch

[02:02:22.0000] <darobin>
does Firefox's view source respect <base> in general?

[02:03:33.0000] <annevk>
not for http://example.org/ either

[02:03:48.0000] <annevk>
so yeah, might be a more generic bug

[02:07:02.0000] <smaug____>
annevk: file a bug, please. CC hsivonen

[02:07:23.0000] <smaug____>
(although this might be a UI problem)

[02:07:54.0000] <annevk>
I suspect this to be filed already

[02:10:24.0000] <smaug____>
annevk: ah, perhaps https://bugzilla.mozilla.org/show_bug.cgi?id=617789

[02:19:02.0000] <annevk>
looks like it

[02:19:08.0000] <annevk>
dynamic base is prolly filed too

[02:31:51.0000] <annevk>
heh, hsivonen is on air: http://futuradio.fi

[02:36:30.0000] <jgraham>
The volume control on the radio image doesn't actually control the volume :(

[02:39:52.0000] <darobin>
that's how the future of radio is!

[02:40:50.0000] <Ms2ger>
Clearly we need a volume content attribute

[02:42:04.0000] <jgraham>
darobin: Excessively loud?

[02:43:03.0000] <Ms2ger>
jgraham, no, that's the present

[02:43:28.0000] <darobin>
jgraham: yeah, you know, Finnish radio is special

[02:43:41.0000] <darobin>
I think they still have the one and only channel broadcasting in Latin

[02:44:15.0000] <darobin>
they are also known for having broadcasted computer programs over FM radio (you could tape it, and then just load the tape)

[02:44:46.0000] <darobin>
plus, they have hsivonen talking about browsers and mobile networks

[02:45:33.0000] <darobin>
he's making me all sad about the Android update situation

[02:50:48.0000] <smaug____>
darobin: it is not a channel, but just one program in Latin

[02:50:54.0000] <smaug____>
basically news in Latin

[02:51:09.0000] <darobin>
smaug____: my version of reality sounds better

[02:51:26.0000] <smaug____>
sure

[02:51:40.0000] <smaug____>
:)

[02:52:00.0000] <darobin>
next you're going to tell me it's just one program with hsivonen and not a whole 24/7 broadcast of his thoughts

[02:52:59.0000] <smaug____>
no no, hsivonen has his own channel and talking 24/7/365

[02:53:23.0000] <jgraham>
Oh, I assumed he had some sort of helmet to read his thoughts in realtime

[03:48:38.0000] <deane>
I wish I had heard all of that interview with hsivonen.

[04:25:50.0000] <annevk>
test

[04:26:13.0000] <Ms2ger>
failed

[04:26:35.0000] <annevk>
there's red all over the floor

[04:26:37.0000] <annevk>
aaaah

[04:26:44.0000] <annevk>
you're being eaten by a grue

[04:27:02.0000] <Ms2ger|waseatenb>
Dammit

[04:27:05.0000] <annevk>
haha

[04:29:59.0000] <jgraham>
I wish hsivonen had done the whole interview in LAtin

[04:49:20.0000] <annevk>
Chrome has something weird

[04:49:40.0000] <annevk>
about:blank as base with "unknown :test" as link creates "about:unknown%20:test"

[04:50:12.0000] <annevk>
no other browser tries to resolve URLs against about:blank

[04:52:30.0000] <jgraham>
Yeah, resolving against about:blank seems weird

[04:56:04.0000] <annevk>
kinda wish URLs were simpler

[04:56:11.0000] <annevk>
but then somebody might have defined them already I guess

[05:02:07.0000] <jgraham>
Ms2ger: (I just came up with another test that can run with a fragment ID on the URL)

[05:02:22.0000] <jgraham>
(or not, but to test slightly different things)

[05:02:30.0000] <annevk>
heh, in Gecko a data URL is only valid if it matches the whole data URL production

[05:02:37.0000] <jgraham>
(same part of the spec still)

[05:02:45.0000] <jgraham>
(except there is no spec yet)

[05:03:54.0000] <Ms2ger>
annevk, that sounds... sane?

[05:04:08.0000] <Ms2ger>
Though Julian did something with base64 and ;

[05:04:11.0000] <annevk>
Ms2ger: well it means data URL parsing becomes part of URL parsing

[05:04:40.0000] <annevk>
Ms2ger: if you want every URL library to behave the same way anyway

[05:04:58.0000] <Ms2ger>
Pff ;)

[05:05:12.0000] <annevk>
I mean if you stop caring about the details all of this is very simple

[05:05:57.0000] <annevk>
but if you do care about whether "DATA:test" becomes normalized and of which .protocol returns "data:" rather than the empty string (that's for invalid) you suddenly need to define this

[05:06:32.0000] <annevk>
well

[05:06:36.0000] <annevk>
invalid might also return ":"

[05:06:41.0000] <darobin>
piffle

[05:06:43.0000] <annevk>
browsers are in dispute of course

[05:06:49.0000] <darobin>
only quiche eaters process URLs with an API

[05:06:50.0000] <Ms2ger>
I only care about browsers :)

[05:07:01.0000] <annevk>
darobin: just had some quiche

[05:07:02.0000] <darobin>
real hackers do it with a twenty page long regex

[05:07:11.0000] <darobin>
my point exactly

[05:07:21.0000] <annevk>
and I'm using a 200 line incomplete tokenizer

[05:07:31.0000] <darobin>
bah, kids these days

[05:09:31.0000] <annevk>
so I take it URLs becomes a "this is implementation-dependent" in "HTML5"?

[05:11:20.0000] <Ms2ger>
No

[05:11:27.0000] <Ms2ger>
They become IRAs

[05:11:30.0000] <Ms2ger>
ARIs?

[05:11:33.0000] <Ms2ger>
ARAs?

[05:11:39.0000] <darobin>
URX I think

[05:12:36.0000] <annevk>
so ™ in the authority part becomes normalized to tm...

[05:13:00.0000] <annevk>
if somebody could explain authority parsing to me that would be awesome

[05:13:04.0000] <darobin>
heh, I wonder how well http://search.cpan.org/~gaas/URI-1.60/URI.pm#PARSING_URIs_WITH_REGEXP actually fares in the real world

[05:13:12.0000] <annevk>
unfortunately that also seems to differ wildly

[05:14:58.0000] <annevk>
e.g. "http:test test" yields invalid in Gecko/Safari, "http://test%20test/" in Chrome

[05:15:05.0000] <annevk>
maybe invalid is okay

[05:15:55.0000] <darobin>
you'd sort of hope so

[05:18:56.0000] <annevk>
well

[05:19:05.0000] <annevk>
http:annevankesteren.nl "works"

[05:19:09.0000] <annevk>
in most browsers

[05:19:15.0000] <annevk>
giving http://annevankesteren.nl/

[05:19:17.0000] <annevk>
unless

[05:19:19.0000] <annevk>
there's a base URL

[05:19:45.0000] <annevk>
in which case it's a relative path and you get something like http://example.org/annevankesteren.nl (scheme has to match)

[05:20:05.0000] <annevk>
but that part I got covered already

[05:20:17.0000] <annevk>
I'm wondering more about what characters to allow and to reject in host

[05:20:22.0000] <annevk>
well, authority

[05:29:34.0000] <annevk>
man

[05:30:10.0000] <annevk>
http:test -> http://test/ in Safari, but http:maraña.org is invalid, only works with //

[05:30:30.0000] <annevk>
Chrome's URL code is a little better there

[05:30:49.0000] <annevk>
Gecko too, but doesn't use punycode

[05:30:57.0000] <annevk>
because, why would anything here match each other...

[05:33:22.0000] <zcorpan>
annevk++ for speccing this

[05:34:03.0000] <Ms2ger>
annevk++ just because

[05:40:01.0000] <jgraham>
annevk++ to increase hit points agianst attacks from RFC-wonks

[05:40:03.0000] <karlcow>
annevk-- for destroying Poney and Rainbow tales ;)

[05:42:28.0000] <darobin>
annevk: re the HTML5 thing with MikeSmith, are you only doing it in .nl or are you travelling a bit too?

[05:42:34.0000] <darobin>
specifically, to the Paris one

[05:58:56.0000] <Ms2ger>
http://i.imgur.com/jxBZG.jpg

[06:11:35.0000] <zcorpan>
aaah, the browser spec. https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689

[06:12:22.0000] <zcorpan>
gotta monkey patch xslt in the browser spec

[06:18:58.0000] <Ms2ger>
There is no scope, dammit

[06:19:11.0000] <Ms2ger>
/me kicks zcorpan out of the secret tree house

[06:21:06.0000] <zcorpan>
i just find it amusing that the *xml core wg* who refused to have me specify this in the *xml-stylesheet PI spec* think that it is most appropriate to spec it in HTML

[06:21:59.0000] <Ms2ger>
"We don't have to deal with it"

[06:26:15.0000] <zcorpan>
(UI requirements for the xml-stylesheet PI is still absent, except i think CSSOM has rules for CSS)

[06:38:42.0000] <annevk>
darobin: I do not know about a Paris one, so presumably just here

[06:38:59.0000] <darobin>
annevk: ah, shame, it could have involved beer

[06:39:02.0000] <annevk>
darobin: I also only plan to put travel money into vacation for now

[06:39:17.0000] <darobin>
or wine, since they seem to be paying for wine and pizza

[06:39:17.0000] <annevk>
does kinda sound like vacation :p

[06:39:32.0000] <darobin>
you're going to take even more vacations??? ;-)

[06:40:04.0000] <Ms2ger>
Oh dear

[06:48:50.0000] <annevk>
haha, no, unfortunately not

[06:48:56.0000] <annevk>
apart from some weekends

[06:51:44.0000] <annevk>
so in Gecko http://\0example.org/ yields http://example.org/

[06:51:52.0000] <annevk>
is that safe?

[06:53:10.0000] <annevk>
Safari treats the zero byte as eof

[06:53:36.0000] <annevk>
same for Opera

[06:54:00.0000] <annevk>
Chrome converts to %00

[06:58:12.0000] <zcorpan>
%00 or treating the whole url as invalid seem like the sane options

[06:59:35.0000] <annevk>
during authority -> invalid otherwise %00 is what I'm going with I guess

[06:59:36.0000] <annevk>
in the end

[07:00:06.0000] <zcorpan>
sounds good

[07:01:30.0000] <annevk>
it seems in the host name you need to unescape %.. too

[07:01:38.0000] <annevk>
in the path only Chrome does it

[07:01:52.0000] <annevk>
which I think might result in some bugs

[07:02:03.0000] <annevk>
some sites expect paths to be pretty much literals

[07:13:26.0000] <annevk>
hsivonen: why does Gecko give the unbalanced tree message if all I write is <br>?

[07:13:32.0000] <darobin>
there's behaviour that I can't find to be specified anywhere, I'd appreciate a pointer if any

[07:13:51.0000] <annevk>
ask, don't ask to ask

[07:14:05.0000] <darobin>
I wasn't asking to ask, I was introducing my question :)

[07:14:11.0000] <darobin>
if you serve something as XML containing <foo><p>foo</p></foo>, it consistently gets rendered as a source tree

[07:14:34.0000] <darobin>
if however you add the namespace to an inner element no matter how deep, as in <foo><p xmlns='http://www.w3.org/1999/xhtml'>foo</p></foo>

[07:14:41.0000] <darobin>
it gets upgraded to an HTML document

[07:15:01.0000] <darobin>
(even if the namespace happens after megabytes of useless XML

[07:15:27.0000] <darobin>
everyone seems to do the same thing (at least given a cursory look) but I can't find it specified

[07:15:55.0000] <annevk>
if http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#read-xml does not have it, prolly a bug

[07:16:17.0000] <darobin>
yeah, that's what I was looking at

[07:16:36.0000] <annevk>
or maybe that's more about rendering XML

[07:16:41.0000] <annevk>
dunno if we have a section for that

[07:17:10.0000] <darobin>
I investigated because of https://www.w3.org/Bugs/Public/show_bug.cgi?id=15180

[07:18:30.0000] <darobin>
I don't believe there's anything about rendering XML

[07:18:37.0000] <darobin>
I'll figure something out, cheers

[07:19:34.0000] <jgraham>
Is there a shorter term for "documents without a browsing context"?

[07:21:16.0000] <annevk>
cookie-averse Document object, though that also means something else

[07:27:39.0000] <annevk>
man, IDNA is some vague shit

[07:27:54.0000] <jgraham>
I was hoping for "detached documents" or something.

[07:29:08.0000] <zewt>
"contextless document" seems accurate, but ... it's sort of a tonguetwister, heh

[07:30:30.0000] <darobin>
it's really funny, <foo><zorglub xmlns='http://www.w3.org/1999/xhtml'>foo</zorglub></foo> and even <foo><x:zorglub xmlns:x='http://www.w3.org/1999/xhtml'>foo</x:zorglub></foo>  work, but the namespace declaration on its own is not enough

[07:31:08.0000] <darobin>
jgraham: how about aloof documents

[07:32:08.0000] <annevk>
darobin: if you want to define this I would just say that the document needs to be rendered per CSS rules if there's at least one element in the HTML namespace

[07:32:27.0000] <annevk>
darobin: and maybe MathML namespace

[07:32:40.0000] <darobin>
yeah, that's what I was thinking of

[07:32:46.0000] <darobin>
lemme do a few more tests

[07:34:10.0000] <darobin>
works for MathML and SVG

[07:35:42.0000] <annevk>
I guess SVG gives you a CSS context as well

[07:36:27.0000] <annevk>
be careful not to make Rendering and XML Rendering sound exclusive

[07:41:10.0000] <darobin>
I'll put it on GitHub, nothing's exclusive there!

[07:44:05.0000] <annevk>
this channel did need more non sequitur

[07:44:15.0000] <annevk>
or does

[07:44:16.0000] <annevk>
hmm

[07:47:50.0000] <smaug____>
jgraham: just curious, and I think the answer is that you aren't allowed to say anything... how does Opera handle cycles in C++ objects

[07:47:58.0000] <smaug____>
well, C++ -> JS ->C++ cycles

[07:56:25.0000] <jgraham>
smaug____: The answer is honestly that I don't know

[07:56:52.0000] <jgraham>
I just asked if that kind of a cycle was a problem for us ans was told by the relevant developers that it wasn't

[07:57:16.0000] <annevk>
zero bytes on the other hand :p

[07:57:53.0000] <jgraham>
Yeah, excuse me while I list the zero websites that affects :p

[07:58:28.0000] <annevk>
well I have this file here on my local hard drive...

[07:58:44.0000] <jgraham>
Well, sometimes it is annoying

[07:59:00.0000] <jgraham>
I wrote a fuzzer once where it truncated the debug output

[07:59:22.0000] <jgraham>
But it's not like it makes sense to prioritise fixing it

[08:34:57.0000] <Hixie>
darobin: can you elaborate on your reasoning for https://www.w3.org/Bugs/Public/show_bug.cgi?id=18067 ? I was thinking about it myself but wasn't convinced it wouldn't be a security problem. Can you elaborate on why you think it's safe?

[08:35:55.0000] <darobin>
Hixie: I looked at the gopher protocol and the sort of content that it supports, and I could find no reason to believe that it would be more unsafe than any of the others

[08:36:08.0000] <darobin>
if there are rules for assessing this more systematically, I'd be happy to hear

[08:36:21.0000] <Hixie>
wouldn't it have the same risks as http:?

[08:36:49.0000] <jgraham>
/me checks his watch

[08:36:55.0000] <jgraham>
No, doesn't seem to be 1992

[08:37:20.0000] <darobin>
you mean highjacking all those gopher clients out there?

[08:37:26.0000] <Hixie>
jgraham: yeah, i'm not saying it would be useful in any way in the first place, but...

[08:37:38.0000] <zcorpan>
how is one supposed to discover which *.specs.whatwg.org exist?

[08:37:48.0000] <Hixie>
zcorpan: one is currently not, sadly

[08:38:38.0000] <Hixie>
darobin: well not just that, but in theory, e.g. in-place mitm in an iframe, or similar

[08:38:54.0000] <jgraham>
Hixie: "i'm not saying it would be useful in any way" no usecases -> not allowed, seems more reasonable

[08:38:55.0000] <Hixie>
darobin: to the extent that anyone supports it, it seems bad to support it inline

[08:39:06.0000] <Hixie>
jgraham: yeah, that's kinda my thinking

[08:40:44.0000] <darobin>
frankly I couldn't think of any reasonably mitm that would do anything useful — at the same time I can see this as useful for whoever wants to maintain historical gopher connectivity to implement it that way

[08:42:00.0000] <Hixie>
to the extent that it can be useful, it seems like it could be used in an attack.

[08:42:09.0000] <Hixie>
to the extent that it's not useful, it seems pointless to support.

[08:42:47.0000] <darobin>
the UC that I have in mind is exposing historical document retrieval systems

[08:44:04.0000] <darobin>
that said I can't say I am overwhelmed with desire for gopher, so I won't stand in the way of reversal

[08:44:47.0000] <Hixie>
i think the whatwg spec will be erring on teh side of abundant caution on this one, fwiw

[08:45:02.0000] <darobin>
/me has a fleeting image of an "I'll die for gopher" t-shirt

[08:46:08.0000] <annevk>
gopher is one of the schemes at least WebKit-based browsers use to trigger their relative URL handling

[08:46:21.0000] <jgraham>
If the usecase is "historical curiosity" it doesn't seem like integration with the web is important so you could require urls to be rewritten as web+gopher (and do so automatically where you have access to the URL)

[08:46:31.0000] <Hixie>
yeah

[08:46:36.0000] <annevk>
gopher implies a hierarchical URL, so to say

[08:47:49.0000] <darobin>
can one of the logbots here give a URL pointer to the logs?

[08:48:00.0000] <darobin>
that's a good point jgraham

[08:48:08.0000] <Ms2ger>
http://krijnhoetmer.nl/irc-logs/whatwg

[08:48:10.0000] <hober>
darobin: see the topic

[08:48:23.0000] <Ms2ger>
Also, now I need to review D3E again

[08:48:35.0000] <darobin>
no, that much I know, I meant a pointer to the current entry

[08:48:40.0000] <darobin>
(but I'll live without)

[08:48:49.0000] <jgraham>
At least krijn isn't really a logbot

[08:49:15.0000] <jgraham>
It's more like a radiator that also saves IRC conversations

[08:49:19.0000] <darobin>
unless you count mIRC as a logbot :)

[08:51:58.0000] <jgraham>
In a conversation about gopher mIRC is almost modern

[08:52:14.0000] <Hixie>
bbiab

[08:52:15.0000] <Ms2ger>
Zing

[08:53:23.0000] <karlcow>
Go for ever

[08:53:38.0000] <jgraham>
You want Hixie killed?

[08:53:46.0000] <Ms2ger>
No, just gone

[08:53:55.0000] <jgraham>
Oh, not "gone"

[09:11:45.0000] <darobin>
Hixie: re https://github.com/w3c/html/commit/c953c8da7b2363af2ec119f14c9383f0cee1b13b it confused someone, I could see how "this" may be slightly unclear, I figured that a two word non-normative change that had confused someone wouldn't hurt

[09:16:56.0000] <dglazkov>
good morning, Whatwg!

[09:31:58.0000] <say2joe>
good morning, Dimitri (and fellow west coaster)

[09:39:23.0000] <Ms2ger>
Hah: https://github.com/apache/httpd/commit/a381ff35fa4d50a5f7b9f64300dfd98859dee8d0

[09:39:28.0000] <darobin>
/me thinks you'd have to be mad to steal a cookie from a gopher

[09:39:28.0000] <Hixie>
darobin: you'll notice i made the change also :-)

[09:39:40.0000] <darobin>
Hixie: yes, I was just reacting to your comment :)

[09:40:13.0000] <Hixie>
darobin: there are definitely cases (not this particular one) where people are like "this is confusing" and despite my best efforts at working out why, i end up concluding it's just because they were tired or don't know how to read

[09:40:36.0000] <darobin>
yeah, I clearly saw a few of those in the bugs

[09:40:38.0000] <say2joe>
lol

[09:41:12.0000] <darobin>
in this case, I could see how it may be confusing (if I tilted my head right)

[09:41:48.0000] <darobin>
I sometimes wish the comment thing had a name field

[09:43:10.0000] <say2joe>
In Chrome Developer Tools, I'm using the Resources panel on the LATimes.com web site. I've got about 60 cookies from that site (and others) being utilized on LATimes.com — if I select all of them and try to delete them, nothing happens. However, I can remove 1-2 at a time it seems… is anyone here familiar with this being a bug or simply the way it works for some reason?

[09:49:52.0000] <Hixie>
darobin: if they're logged in on the spec, it includes their e-mail address on the line with the IP address

[09:50:43.0000] <karlcow>
Ms2ger this is all insane the apache thing

[09:50:50.0000] <darobin>
Hixie: yeah I saw, but the weirder ones aren't the logged in ones ;)

[09:50:57.0000] <Hixie>
yeah

[09:51:03.0000] <Ms2ger>
karlcow, how about we call it "the IE thing" ;)

[09:51:19.0000] <karlcow>
not going into that discussion again :)

[09:51:25.0000] <Ms2ger>
Me neither

[09:51:30.0000] <Hixie>
darobin: it's a natural trade-off between reducing the barrier to getting feedback, and getting more info

[09:52:00.0000] <Hixie>
darobin: the bugs filed on the w3c copy require that they get a login, so you get a name there (but less feedback overall)

[09:52:27.0000] <darobin>
I know, I wasn't suggesting requiring logins for all, au contraire

[09:52:54.0000] <darobin>
I was just wondering if adding a name field there might make sense — just mulling it over

[09:53:30.0000] <Ms2ger>
darobin, hey, shouldn't you be removing references to the WHATWG from HTML5 instead of hanging around here? :)

[09:55:54.0000] <darobin>
Ms2ger: nah, that was fun while outside W3C

[09:56:11.0000] <darobin>
now that I'm on the inside, I seem to mostly focus on pissing off XML Core WG and I18N

[09:56:21.0000] <Ms2ger>
Not a11y?

[09:56:58.0000] <darobin>
haven't gotten around to that yet :-)

[09:57:20.0000] <Ms2ger>
/me prepares some popcorn

[09:57:24.0000] <othermaciej>
I've never seen them in a non-pissed-off state so I'm not sure how you would know the difference

[09:58:20.0000] <Ms2ger>
Zing

[10:00:39.0000] <Hixie>
ouch

[10:03:23.0000] <Ms2ger>
Hixie, you got your HTMLCollection test wrong, btw

[10:03:29.0000] <Hixie>
no surprise there

[10:03:35.0000] <Hixie>
what specifically did i get wrong?

[10:03:51.0000] <Ms2ger>
ToUint32('test') == 0

[10:03:59.0000] <Ms2ger>
So it didn't prove anything

[10:04:12.0000] <Ms2ger>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18789

[10:04:19.0000] <Hixie>
d'oh

[10:05:13.0000] <Hixie>
i want strict typing damnit

[10:05:15.0000] <Hixie>
anyway

[10:05:17.0000] <Hixie>
bbl again

[10:06:52.0000] <darobin>
I find that a spellchecker can help lots with strict typing

[10:06:55.0000] <darobin>
/me gets his coat

[10:07:40.0000] <Ms2ger>
/me kicks darobin out

[10:11:30.0000] <annevk>
miketaylr: fullscreen is a single word

[10:11:37.0000] <annevk>
miketaylr: I blame Mozilla for realizing that too late

[10:12:19.0000] <miketaylr>
annevk: yeah my intuition says that too

[10:12:21.0000] <annevk>
miketaylr: in a couple of years from now people will be thankful not to have to write full-dash-screen

[10:12:24.0000] <miketaylr>
too lazy to look it up

[10:12:41.0000] <annevk>
well it used to be full screen

[10:12:47.0000] <annevk>
then full-screen, and nowish fullscreen

[10:12:59.0000] <annevk>
the English language sucks that way, so you better just remove that hyphen right away

[10:14:00.0000] <miketaylr>
can't wait to find all the broken sites where people create an analogous requestFullScreen from the prefixed guys

[10:14:10.0000] <miketaylr>
(html5test is the first i know of)

[10:14:37.0000] <paul_irish>
miketaylr: got spec link handy?

[10:14:44.0000] <paul_irish>
or list discussion?

[10:15:13.0000] <miketaylr>
paul_irish: here's a PR w/ a spec link inside https://github.com/NielsLeenheer/html5test/pull/196

[10:16:12.0000] <paul_irish>
thx

[10:18:51.0000] <annevk>
paul_irish: spec is hosted here for now: http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html

[10:19:01.0000] <annevk>
will prolly be fullscreen.spec.whatwg.org at some point

[10:19:07.0000] <annevk>
have to sort all that out still

[10:21:43.0000] <paul_irish>
oh man that's a hot URL. looking forward to it

[10:22:07.0000] <paul_irish>
annevk: im going to update the MDN and html5rocks tutorials with their casing and point this out more clearly.

[10:24:25.0000] <annevk>
thanks paul_irish!

[10:25:11.0000] <miketaylr>
paul_irish++

[11:25:22.0000] <annevk>
very slowly approaching more followers than commits on @WHATWG

[11:25:30.0000] <Hixie>
oh dear

[11:25:33.0000] <Hixie>
i'd better commit more

[11:25:43.0000] <annevk>
per character commits!

[11:26:54.0000] <Hixie>
actually since i don't have to deal with the htmlwg process any more i've been grouping typo commits again

[11:28:31.0000] <Hixie>
sicking: ping

[12:34:00.0000] <Hixie>
hober: looks like some bugs in the html5 spec component are getting assigned to me?

[12:34:28.0000] <Hixie>
not sure why

[13:21:09.0000] <sicking>
Hixie: pong

[14:03:32.0000] <hober>
Hixie: link(s)?

[14:04:40.0000] <hober>
Hixie: nvm, i see the mail on p-h-b

[14:33:29.0000] <zcorpan>
Hixie: maybe the live dom viewer bug thing should have its own bugzilla component? also, maybe prompt() for a description?

[14:36:33.0000] <TabAtkins>
Hixie: Why is the "DOM view" link a data:text/plain, when its contents are clearly HTML?

[14:37:21.0000] <TabAtkins>
Also: it would be nice to have the data url include the styles that it's normally rendered with.

[14:38:23.0000] <zcorpan>
hmmmmmmmmmmmmmmmmmmm. http://www.w3.org/community/texttracks/wiki/608_to_WebVTT

[15:07:19.0000] <zcorpan>
the style sheet there also has bogus selectors

[15:16:36.0000] <TabAtkins>
Indeed - <track> is never rendered, and ::cue-part() should hang off the <video> element instead.

[15:36:16.0000] <zcorpan>
and the /* default values */ should probably use ::cue, but it also includes properties that don't apply to cues

[16:12:02.0000] <Hixie>
TabAtkins: i use it to copy and paste the source into the spec

[16:12:20.0000] <Hixie>
zcorpan: yeah, prompting for a desc might make sense. is it still being abused?

[16:12:30.0000] <Hixie>
if not, then people can just put the desc in a comment...

[16:12:47.0000] <TabAtkins>
Hixie: Ah, kk.

[16:13:11.0000] <Hixie>
sicking: archives api -- is anyone taking care of speccing that? it was raised in the whatwg list and i want to make sure i'm not ignoring something that was intended to be work for me

[16:13:23.0000] <Hixie>
d'oh

[16:13:32.0000] <zcorpan>
Hixie: i don't know if it's abused, but apparently they don't have descs in a comment, so it's hard to tell if it's spam or worthwhile or what it's about at all

[16:13:33.0000] <zewt>
"run, coward, run"

[16:13:48.0000] <zewt>
Hixie: (you mean that ZIP API?)

[16:14:01.0000] <sicking>
Hixie: no one is writing drafts for it right now

[16:14:14.0000] <zcorpan>
Hixie: the other concern was that most seem to be about css browser bugs, not html browser bugs

[16:14:24.0000] <sicking>
Hixie: we've been trying to get input from authors, but so far not very successfully

[16:14:31.0000] <sicking>
/me looks at paul_irish ;-)

[16:14:33.0000] <zcorpan>
Hixie: i was just reading minutes, i haven't really looked at the bugs myself

[16:15:16.0000] <sicking>
Hixie: i wasn't counting on you writing it up though. But if you are so inclined that'd be lovely :)

[16:17:57.0000] <Hixie>
zcorpan: yeah, true

[16:18:18.0000] <Hixie>
sicking: i wish i had the bandwidth

[16:18:44.0000] <Hixie>
sicking: basically i'm trying to work out if i should ignore the thread as if there was another editor tracking that feedback, or reply with "that's nice, but i don't have the bandwidth to do it now"

[16:18:50.0000] <Hixie>
zcorpan: k

[16:19:12.0000] <Hixie>
zcorpan: i'm happy to change it

[16:19:27.0000] <Hixie>
zcorpan: ideally not right now though

[16:19:30.0000] <Hixie>
send mail?

[16:19:41.0000] <sicking>
Hixie: up to you. I wasn't expecting you to do it, so no comment needed

[16:20:49.0000] <Hixie>
k.

[16:20:55.0000] <Hixie>
i shall pretend it never happened :-)

[16:22:31.0000] <zcorpan>
sent


2012-09-07
[17:20:49.0000] <zewt>
cool, people talking about webvtt features in terms of "we should do this since some other format does it, and this feature doesn't need to be consistent with other parts of webvtt since some other format doesn't do it"

[21:42:12.0000] <Hixie>
annevk: you aware of http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/thread.html#msg210 ?

[23:25:31.0000] <annevk>
Hixie: seemed like a duplicate of the Mozilla stuff based on http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0218.html

[23:26:11.0000] <annevk>
Hixie: which is discussed on public-webapps already

[01:41:53.0000] <annevk>
The reason Chrome does the weird resolving btw is I think because parsing of URLs in Chrome never fails

[01:42:36.0000] <annevk>
so you never get a SYNTAX_ERR of any kind, but network errors down the road

[04:48:46.0000] <annevk>
Hixie: if you wake up soon enough: http://www.qwertee.com/product/there-s-no-place-like-home/

[04:49:08.0000] <annevk>
(via rune)

[05:03:04.0000] <annevk>
Is https://bugzilla.mozilla.org/show_bug.cgi?id=303478 also about handling changes to <base>?

[05:03:13.0000] <annevk>
(And note that behavior is now defined in HTML...)

[05:03:23.0000] <annevk>
(Somewhat different from how bz explains it afaict.)

[05:44:11.0000] <Ms2ger>
Lachy, thanks for http://dvcs.w3.org/hg/resources/rev/6a3a7087e2e2

[05:49:22.0000] <annevk>
can someone @opera.com tell sigbjorn Opera is the only browser to escape \ in the query string? He'll know what to do

[05:49:41.0000] <annevk>
sof that is

[05:51:26.0000] <MikeSmith>
yay XPath http://google-opensource.blogspot.co.uk/2012/09/wicked-good-xpath-faster-javascript.html

[05:58:11.0000] <jgraham>
Kind of hard not to read "pseudo-java" in place of "closure"

[05:58:18.0000] <jgraham>
annevk: Done

[05:59:25.0000] <AryehGregor>
jgraham, do you know (or can you find out) what makes <div contenteditable style="background:green"></div> not collapse to zero height in Opera?

[05:59:50.0000] <AryehGregor>
Apparently WebKit hardcodes contenteditable stuff in their layout logic somewhere, which seems kind of unpleasant.

[05:59:58.0000] <jgraham>
AryehGregor: I can ask at least

[06:00:06.0000] <AryehGregor>
Everyone but Gecko does it, though, so it should probably be specced.

[06:00:27.0000] <AryehGregor>
I'm hoping maybe Opera will have some good-enough 80% workaround that can be easily specced.

[06:00:47.0000] <AryehGregor>
Like maybe "editing hosts need to behave as though they're affected by the following CSS rule".

[06:04:52.0000] <jgraham>
AryehGregor: We seem to insert a <br>

[06:04:59.0000] <AryehGregor>
Hmm, interesting.

[06:05:03.0000] <AryehGregor>
So it's a parser special-case?

[06:05:19.0000] <AryehGregor>
That seems more appealing than a CSS special case, although still not ideal.

[06:05:35.0000] <jgraham>
I don't know that it's in the parser exactly

[06:07:02.0000] <AryehGregor>
jgraham, is https://dvcs.w3.org/hg/resources the authoritative copy that changes should be pushed to these days?

[06:07:18.0000] <jgraham>
Oh, it is in the parser

[06:07:23.0000] <jgraham>
AryehGregor: Yes

[06:07:41.0000] <jgraham>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1745

[06:43:35.0000] <annevk>
zcorpan: https://twitter.com/SilentImp/status/244061433627811840

[06:56:34.0000] <annevk>
argh

[06:56:49.0000] <jgraham>
< sof> jgraham: tell annevk to try 12.50, we fixed that one

[06:57:11.0000] <annevk>
 \0\n\t gives %00%0A%09 as you expect

[06:57:16.0000] <annevk>
but remove the \0 and they're all gone

[06:57:45.0000] <annevk>
in Gecko

[06:58:08.0000] <annevk>
jgraham: yeah sorry, thought of that later :/

[07:04:17.0000] <annevk>
jgraham: updated to 1497 for Opera Next, removed Opera.app to ensure I use the latest

[07:04:29.0000] <matt444>
http://www.w3.org/2012/05/sysapps-wg-charter.html

[07:04:38.0000] <matt444>
That page has a Join link which is dead

[07:05:06.0000] <annevk>
matt444: it's not an actual charter either

[07:05:09.0000] <annevk>
just a draft

[07:05:17.0000] <annevk>
matt444: anyway, you want to bug the W3C with that

[07:05:36.0000] <matt444>
ah, ok thanks

[07:07:14.0000] <annevk>
jgraham: still broken in the Opera Next 9.50...

[07:07:18.0000] <annevk>
euh, 12.50

[07:08:58.0000] <jgraham>
I have build 1577

[07:09:11.0000] <jgraham>
You might need to get it from the Desktop Team Blog

[07:16:56.0000] <annevk>
in other news, did anyone know browsers strip U+0009, U+000A, and U+000D liberally from anywhere in URL paths

[07:17:06.0000] <annevk>
also from the query string and fragment afaict

[07:17:13.0000] <annevk>
but only for hierarchical paths

[07:17:17.0000] <annevk>
of course...

[07:20:15.0000] <annevk>
installing 1583 now

[07:22:26.0000] <annevk>
jgraham: works, cool

[07:22:38.0000] <annevk>
jgraham: but not cool that the update command fails...

[07:23:31.0000] <jgraham>
Yeah, the Desktop people are quite reluctant to put builds onto the auto update for reasons that I don't entirely understand

[07:27:50.0000] <Ms2ger>
/me likes his auto-updates

[07:28:22.0000] <Ms2ger>
Also, since annevk apparently isn't going on vacation in the immediate future, I'll have to

[07:29:15.0000] <Ms2ger>
(until the 14th or so)

[07:29:15.0000] <annevk>
I was hoping you were going to type more

[07:29:39.0000] <annevk>
like "I'll have to demonstrate I'm a better editor" or some such

[07:29:48.0000] <annevk>
but have fun!

[07:29:52.0000] <Ms2ger>
Heh

[07:29:54.0000] <Ms2ger>
Thanks :)

[07:58:34.0000] <Ms2ger>
/me waves

[11:14:04.0000] <TabAtkins>
Anyone got a link to a document explaining the W3C policy of not allowing tech requirements in specs for things without sufficiently open licenses?

[13:34:49.0000] <Hixie>
seems crazy that we allow authors to add and remove text tracks from in-band text tracks while they're parsing

[14:17:52.0000] <jgraham>
MikeSmith: What the hell are you doing posting useful informative content to Google+?

[14:19:33.0000] <cabanier1>
tabatkins: you mean the w3c patent policy?

[14:23:25.0000] <Hixie>
jeez, zcorpan

[14:23:35.0000] <Hixie>
making <track> only work when there's a media element parent is a bitch

[14:23:39.0000] <Hixie>
i've no idea how to even do it

[14:35:49.0000] <TabAtkins>
cabanier1: Maybe, yeah.

[14:52:00.0000] <cabanier1>
http://www.w3.org/Consortium/Patent-Policy-20040205/

[16:00:36.0000] <Hixie>
i wonder if there are other platforms where the people designing the APIs have to basically treat authors as the enemy... :-/

[16:01:12.0000] <Hixie>
/me is trying to work out how to do the text track selection in a way that does what authors want, what users want, what vendors want, and yet is not going to just fall apart when authors start randomly removing track elements or poking at the DOM

[16:01:57.0000] <TabAtkins>
I, on the other hand, am figuring out the easiest way to automate this railroad-diagram creation. Existing libraries don't do what I want.

[16:02:08.0000] <TabAtkins>
At least, not in the exact visual style I want.

[16:02:38.0000] <Hixie>
railroad-diagram? that sounsd like way more fun

[16:03:08.0000] <TabAtkins>
Well, it's SVG.  And nothing to do with trains.  So, depends on your proclivities.

[16:03:16.0000] <Hixie>
oh. no trains. sad now.

[16:03:45.0000] <TabAtkins>
gonna add an informative section to the Syntax module illustrating the syntax of each token with railroad diagrams.

[16:03:50.0000] <TabAtkins>
Easier to read than regex.

[16:03:57.0000] <Hixie>
oh, those kinds of diagrams

[16:04:12.0000] <Hixie>
what i consider "pascal-style syntax diagrams", because i first saw them in pascal reference books

[16:04:27.0000] <Hixie>
i love those, so neat

[16:04:32.0000] <Hixie>
so hard to represent in text :-P

[16:04:42.0000] <zewt>
is that the diagrams that sqlite's docs changed to a few years ago, which overnight made the docs totally unreadable :|

[16:04:49.0000] <TabAtkins>
I consider them "JSON-style syntax diagrams", for the same reason.

[16:05:05.0000] <Hixie>
yeah, the json spec uses them too

[16:05:11.0000] <TabAtkins>
zewt: http://dev.w3.org/csswg/css3-syntax/railroad-diagrams.svg

[16:05:22.0000] <Hixie>
that's awesome

[16:05:45.0000] <Hixie>
TabAtkins++

[16:05:49.0000] <zewt>
TabAtkins: might make sense for that (no idea), but for SQL it's terrible: http://www.sqlite.org/lang_insert.html

[16:06:09.0000] <Hixie>
that looks awesome too, why is it terrible?

[16:06:32.0000] <Hixie>
surely better than the alternative bnf, let alone regex

[16:06:56.0000] <zewt>
i find it much harder to read than what it used to be (which I think was closer to postgres's, eg. http://www.postgresql.org/docs/current/static/sql-insert.html)

[16:07:00.0000] <zewt>
also it's unsearchable

[16:07:25.0000] <Hixie>
the postgre alternative syntax style there is not as precise by a long shot

[16:07:32.0000] <Hixie>
i agree that the searchability is zero

[16:07:41.0000] <Hixie>
that's what i meant (in part) by "hard to represent in text"

[16:07:45.0000] <zewt>
(perhaps svg-based ones could fix that particular problem--looks like I can search the text in that svg, but it won't actually highlight in FF or Chrome)

[16:08:11.0000] <TabAtkins>
zewt: I'm missing the diagram.  Is it somewhere on that page I don't see?

[16:08:28.0000] <TabAtkins>
Oh, I clicked on postgres, duh.

[16:09:00.0000] <Hixie>
TabAtkins: what does your source look like?

[16:09:12.0000] <TabAtkins>
Check it? I'm just writing straight SVG right now.

[16:09:13.0000] <zewt>
TabAtkins: i don't use SVG much--is it possible to make it so search-highlighting works, or is that just a multi-browser bug?

[16:09:24.0000] <TabAtkins>
Now that I've done two of them, I'm looking into generating them from a simpler source.

[16:09:24.0000] <Hixie>
TabAtkins: oh, you're doing it by hand?

[16:09:26.0000] <zewt>
(dunno if that's just coloring being overridden or something)

[16:09:28.0000] <Hixie>
TabAtkins: aaah

[16:09:38.0000] <TabAtkins>
zewt: Dunno!

[16:09:47.0000] <Hixie>
TabAtkins: i'm interested in subscribing to your newsletter, so that i may receive the issue that describes that syntax once you find a good one :-)

[16:09:49.0000] <zewt>
you're very excited about dunno!

[16:10:29.0000] <TabAtkins>
Hixie: It's simple.  All I want to do is omit some of the busywork around determining lengths of things.  Anyway, when I'm done I'll share.

[16:10:41.0000] <TabAtkins>
Won't finish today, but it might be my weekend project.

[16:10:55.0000] <Hixie>
cool

[16:11:41.0000] <Hixie>
maybe i can replace the html syntax section with some of these if your solution scales well, and give zewt a fit

[16:12:08.0000] <annevk>
Hixie: next Monday, I'm gonna need some *.spec.whatwg.org URLs

[16:12:23.0000] <Hixie>
annevk: good to know

[16:12:37.0000] <Hixie>
annevk: this is the ones that we have to dance into your account?

[16:12:58.0000] <zewt>
also, it's weird that <svg hidden> doesn't work

[16:12:59.0000] <annevk>
either that or make me some weird account

[16:13:00.0000] <Hixie>
annevk: or shall we just give you an account on my user

[16:13:06.0000] <Hixie>
that's probably easier

[16:13:18.0000] <annevk>
yeah, it's only going to be a simple script that pulls from github anyway

[16:13:21.0000] <Hixie>
if we don't have to involve dreamhost it's trivial, just say the word

[16:13:24.0000] <Hixie>
k

[16:13:42.0000] <Hixie>
guess at some point i should set up the specs/ page to point to these specs, too

[16:13:58.0000] <annevk>
xhr, encoding, fullscreen, cors maybe

[16:14:16.0000] <annevk>
and url at some point, but I've some research and writing to do for that one

[16:14:19.0000] <Hixie>
a mass exodus, no less

[16:14:32.0000] <Hixie>
i take it the w3c just shot itself in the foot? or did you time out waiting for them to

[16:14:38.0000] <annevk>
well, the W3C Invited Expert agreement I don't like

[16:14:58.0000] <annevk>
it basically prohibits forking these days

[16:15:02.0000] <Hixie>
yeah

[16:15:12.0000] <annevk>
and since I'm gonna pay for all development myself, that seems unfair

[16:15:16.0000] <Hixie>
(only the w3c can fork, don't you know)

[16:15:21.0000] <annevk>
I rather give it away as long as I still have money

[16:17:26.0000] <Hixie>
i wonder how many of your specs microsoft will end up forking into webapps :-)

[16:18:40.0000] <annevk>
if they turn them into respec like with the work of Ms2ger it's all for the worse :/

[16:19:00.0000] <TabAtkins>
Hixie: Check the source of http://dev.w3.org/csswg/css3-syntax/railroad-diagrams.svg now.  Does the comment at the top look good to you?

[16:19:46.0000] <Hixie>
hm, not sure xml would be my first choice, but i guess it works

[16:21:02.0000] <Hixie>
at least for these examples

[16:21:13.0000] <Hixie>
there are some more complex things i don't think you'd be able to represent as well

[16:21:23.0000] <Hixie>
do you plan to use this for property value syntax too?

[16:21:26.0000] <Hixie>
or just core syntax?

[16:24:20.0000] <Hixie>
TabAtkins: btw, for the hyphen case / <optional>, i think it's convention to put the "normal" case in the straight line, which in this case would mean the hyphen would be on the side branch

[16:25:36.0000] <Hixie>
TabAtkins: also, you need an element for "sequence of stuff" so that a <choice> can choose between sequences

[16:26:03.0000] <Hixie>
consider e.g. http://www.freepascal.org/docs-html/ref/ref79x.png

[16:27:59.0000] <Hixie>
TabAtkins: this diagram has an example i don't think you could do with xml easily: http://www.cosc.canterbury.ac.nz/greg.ewing/python/paramlist.png

[16:29:52.0000] <GPHemsley>
so... :active defaults to the whole page if an element isn't specified?

[16:30:18.0000] <Hixie>
no

[16:30:23.0000] <Hixie>
:active is equilavent to *:active

[16:30:30.0000] <Hixie>
*|*:active, if there's no default namespace

[16:30:54.0000] <Hixie>
like .active would be

[16:32:48.0000] <GPHemsley>
ah

[16:32:56.0000] <GPHemsley>
though isn't that effectively the same thing?

[16:34:10.0000] <Hixie>
depends on what exactly you mean by "defaults to the whole page"

[16:35:57.0000] <GPHemsley>
Hixie: Probably the fact that :active is *:active ;)

[16:44:14.0000] <Hixie>
the script that i report bugs with just told me off for not being descriptive enough for me to understand what i meant

[16:44:17.0000] <Hixie>
-_-


2012-09-08
[17:01:36.0000] <heycam>
zewt, I'm working on getting text selectable in Firefox, should land in a couple of weeks

[17:02:03.0000] <zewt>
looks like it's selectable in chrome, but still doesn't highlight on search

[17:02:29.0000] <zewt>
(which seems odd--seems like the hard part's done)

[17:03:16.0000] <heycam>
(https://bugzilla.mozilla.org/show_bug.cgi?id=655877 if you care)

[18:16:39.0000] <TabAtkins>
Hixie: Good point about the normal case being straight line.  In that case, <optional> should be a leaf node, and <choice> can put its first option in the straight line position.

[18:17:17.0000] <Hixie>
fair enough

[18:17:31.0000] <TabAtkins>
I *think* you can write the def_param_list without repeating yourself.  I'll see.

[18:17:52.0000] <TabAtkins>
And yes, I just haven't needed a <sequence> element yet in those two examples (assuming that there's implicit sequencing at the root).

[18:18:57.0000] <TabAtkins>
So far, I'm just planning on using this for the CSS token syntax.  If it's useful for other stuff in the future, that's cool.  ^_^

[18:19:26.0000] <Hixie>
cool

[18:36:02.0000] <TabAtkins>
Ugh, the def_param_list *is* doable in my syntax without repetition, but you have to rewrite it to be less clear (so all the skips are cleanly nested).

[18:36:12.0000] <TabAtkins>
Oh well, I can always manually generate things that run into that kind of problem.

[18:36:28.0000] <TabAtkins>
To be fair, this grammar is actually kinda hard to write as a regex or BNF.

[18:37:05.0000] <TabAtkins>
Or, no, a BNF for it is probably pretty easy.

[18:37:30.0000] <TabAtkins>
My syntax works well for regex-style things only.

[18:38:00.0000] <TabAtkins>
But being able to generate *most* of that diagram (everything but the skip line at the bottom) automatically and just hand-filling in the last bit is still pretty good.

[18:41:49.0000] <Hixie>
yeah, that's certainly a good start :-)

[18:42:01.0000] <Hixie>
dunno how often one would see that anyway

[11:56:13.0000] <GPHemsley>
Hixie: Does this (really old) bug relate to the unload stuff you were working on the other day? https://bugzilla.mozilla.org/show_bug.cgi?id=13701

[11:56:53.0000] <GPHemsley>
(Oh, you were the QA Contact on it until 2009!)

[11:59:57.0000] <GPHemsley>
Is there a document describing what "DOM0" actually refers to? Or is it just some arbitrary name for "whatever browsers supported as of XYZ date"?

[12:01:03.0000] <GPHemsley>
And are the features of DOM0 superseded by other documents? Or do the other DOM documents build orthogonal to each other?

[12:04:04.0000] <zewt>
DOM0-kun?

[12:04:29.0000] <GPHemsley>
?

[14:04:33.0000] <annevk>
GPHemsley: DOM0 are the APIs not in the DOM or JavaScript before HTML and related efforts standardized most of them

[14:04:41.0000] <annevk>
if that makes sense

[14:05:27.0000] <annevk>
e.g. window, window.history, window.location, XMLHttpRequest, keyboard events


2012-09-09
[22:54:57.0000] <adlwalrus1>
Are the *all* of the "special-"/"control-" characters in HTML represented by the class [<!>"'=/&]  ?

[10:41:14.0000] <GPHemsley>
annevk: So, does that mean there is no consensus on DOM0? Has there been any attempt to document existing behavior (rather than standardize to an ideal that hasn't been implemented)? Have there been any efforts to remove unused legacy items?

[10:50:30.0000] <GPHemsley>
Also, is (window.)navigator obsolete, or what?

[11:48:24.0000] <GPHemsley>
Hixie: Is the Navigator object (as documented in 7.5.1) intended to encourage modern continued usage? The non-legacy values (particular for appName and appVersion) seem to suggest so.

[11:48:46.0000] <GPHemsley>
7.5.1.1 in particular

[11:57:11.0000] <GPHemsley>
Hixie: Trying to determine the appropriate action for this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=61071

[12:02:21.0000] <jgraham>
GPHemsley: There are other uses for navigator as well as the app* stuff

[12:02:33.0000] <jgraham>
e.g. geoloaction lives under navigator

[12:02:40.0000] <jgraham>
*geolocation

[12:02:43.0000] <GPHemsley>
jgraham: Yeah, that original question is obsolete now :P

[12:03:40.0000] <jgraham>
I don't think the spec makes a relative value judgement between the various options for those properties

[12:04:06.0000] <jgraham>
But I would be very reluctant to change the values myself

[12:04:22.0000] <jgraham>
It seems likely to cause breakage for no good reason

[12:04:35.0000] <GPHemsley>
Well, it would help if it made clear whether the implementation is only for legacy value, or if there is intention afoot to bring it back into modernity

[12:05:14.0000] <GPHemsley>
because the description of "a string representing the version of the browser in detail" does not match Firefox's current value for appVersion, which is also not "4.0"

[12:06:05.0000] <GPHemsley>
so, the way I'm reading the spec right now, Firefox is not in compliance with this section

[12:06:10.0000] <GPHemsley>
(full)

[12:07:15.0000] <GPHemsley>
in an unrelated question: where are the tests that the spec's section tags refer to, and why aren't they linked directly?

[12:09:56.0000] <GPHemsley>
while we're looking at this section, is there some sort of guideline for determining whether "the platform on which the browser is executing" is formatted properly? What if different browsers specify the same platform differently?

[13:40:53.0000] <annevk>
GPHemsley: not sure why we need consensus on DOM0

[13:41:00.0000] <annevk>
GPHemsley: we just need to document the platform

[13:41:22.0000] <annevk>
GPHemsley: DOM0 is just some historical term to mean everything not in DOM and JavaScript at the time of writing (back in '98 or whatever)

[13:41:39.0000] <GPHemsley>
ok, wasn't clear on that

[13:41:46.0000] <GPHemsley>
(no docs ;))

[13:42:51.0000] <GPHemsley>
annevk: feel free to answer all my other questions, though :P

[13:43:18.0000] <annevk>
GPHemsley: not sure what you mean with document existing behavior versus standardize an ideal

[13:43:28.0000] <annevk>
GPHemsley: do you have an example of the former and one of the latter?

[13:43:50.0000] <annevk>
GPHemsley: and we have removed plenty of stuff

[13:44:07.0000] <annevk>
GPHemsley: see various "remove" bugs filed on browsers (some by me)

[13:44:18.0000] <annevk>
Ms2ger fixed some for Gecko

[13:45:52.0000] <smaug____>
GPHemsley: no one is standardizing the ideal

[13:46:04.0000] <smaug____>
expect perhaps with new APIs

[13:46:16.0000] <GPHemsley>
annevk: I was just trying to clarify where DOM0 stood in the spectrum of specifications (since older specs tended to ignore the current behavior and standardize the ideal).

[13:46:34.0000] <GPHemsley>
I wasn't accusing anyone of anything :)

[13:46:40.0000] <annevk>
GPHemsley: DOM0 is not a spec

[13:46:47.0000] <annevk>
GPHemsley: and DOM1-3 are obsolete

[13:46:50.0000] <GPHemsley>
well, that was part of what I was clarifying ;)

[13:47:57.0000] <GPHemsley>
annevk: So, does DOM4 (and the other specs before it) spec the entirety of the DOM, or just subsets?

[13:48:21.0000] <GPHemsley>
I'm not clear on the line of succession

[13:48:32.0000] <annevk>
GPHemsley: it's prolly best to start from http://platform.html5.org and find out if you have a feature in a browser that's not covered by the specs mentioned there

[13:49:09.0000] <annevk>
GPHemsley: http://dom.spec.whatwg.org/ is pretty clear on what it replaces

[13:49:29.0000] <GPHemsley>
alright, nevermind all that

[13:49:32.0000] <annevk>
GPHemsley: what is left in limbo at the moment are UI Events

[13:49:43.0000] <GPHemsley>
my current questions right now are about Navigator

[13:49:44.0000] <annevk>
but we'll get to those eventually

[13:50:04.0000] <GPHemsley>
which is in the HTML spec

[13:50:59.0000] <GPHemsley>
well, actually, I have more questions

[13:51:17.0000] <GPHemsley>
are DOM1 and DOM0 mutually exclusive?

[13:51:46.0000] <GPHemsley>
as in, DOM0 + DOM1 + JS = state of the browser in '98?

[13:51:51.0000] <annevk>
spec != term, so yes

[13:52:02.0000] <annevk>
well + HTTP + HTML + CSS

[13:52:06.0000] <GPHemsley>
right

[13:52:09.0000] <GPHemsley>
ok

[13:52:23.0000] <GPHemsley>
so, was DOM0 documented somewhere? or just bits and pieces everywhere?

[13:53:38.0000] <annevk>
what do you mean by documented?

[13:53:51.0000] <annevk>
I don't really understand what you're trying to find out

[13:53:52.0000] <GPHemsley>
like, the way the HTML spec is now

[13:54:00.0000] <annevk>
I just told you there was no spec

[13:54:16.0000] <GPHemsley>
ok, so then I should take that as a "no"?

[13:54:29.0000] <annevk>
documented, most likely, in spec form, no

[13:54:36.0000] <GPHemsley>
ok

[13:54:42.0000] <GPHemsley>
so moving on to the Navigator object

[13:56:24.0000] <annevk>
what's in the spec now is in draft and somewhat contradictory

[13:56:39.0000] <GPHemsley>
oh?

[13:56:55.0000] <GPHemsley>
how so?

[13:57:03.0000] <annevk>
well can't ask for the version of the browser in detail and warn at the same time that could be used for profiling

[13:57:34.0000] <annevk>
none of that seems entirely finished to me, mostly because nobody has implemented this from the spec

[13:57:52.0000] <annevk>
the spec was written with the implementations in mind, but it hasn't been fed back into the implementations

[13:58:01.0000] <annevk>
at least as far as I know

[13:58:19.0000] <annevk>
anyway, I'm gonna get some sleep

[13:58:23.0000] <GPHemsley>
ah, ok

[13:58:55.0000] <GPHemsley>
which tests are used for the WHATWG version of the spec?

[13:59:11.0000] <GPHemsley>
the W3C ones?


2012-09-10
[17:13:40.0000] <yuhong>
AFAIK "DOM0" as most commonly used refers most closely to what was implemented in Netscape 3.0.

[17:16:16.0000] <yuhong>
in late 1996

[17:16:37.0000] <yuhong>
document.images, document.anchors, etc...

[17:18:11.0000] <yuhong>
After that, Netscape and IE went off in different directions (document.all, document.layers) leading the W3C to create DOM level 1.

[02:20:10.0000] <annevk>
wow, encodeURI deals with surrogates, sweet

[02:38:17.0000] <zcorpan>
Hixie: yeah, i expect in-band tracks might need some tweaks when someone gets around to implement that

[02:39:44.0000] <annevk>
would it make sense to have <input type=number suffix="%"> or <input type=number prefix="$">

[02:39:46.0000] <annevk>
?

[02:40:34.0000] <zcorpan>
Hixie: about tracks without a media parent, there are already several checks in place that trigger loading; src URL changes, mode changes. why is it hard to also check the parent?

[02:40:51.0000] <zcorpan>
annevk: what's wrong with $<input> ?

[02:41:02.0000] <annevk>
zcorpan: ugly

[02:41:27.0000] <annevk>
e.g. if you have up and down buttons and %, you don't want % to render after those buttons

[02:41:46.0000] <annevk>
and it's kinda part of the content, without it the input does not make sense

[02:43:06.0000] <zcorpan>
i guess that makes sense

[02:44:32.0000] <zcorpan>
Hixie: it does not seem necessary to kill a <track> when it loses its media parent, though i haven't thought about that case much

[02:49:25.0000] <annevk>
bah, why is tokenizing authority so annoying

[02:55:26.0000] <annevk>
I guess authority is an appropriate name, it does not like to be broken down

[02:55:53.0000] <annevk>
at least not in a single pass

[07:35:53.0000] <mpt>
/me is surprised to discover that <input list> doesn't look like a combo box in either Gecko or WebKit

[07:36:46.0000] <mpt>
... Just a text field that shows a menu if you happen to know that you're supposed to double-click on it

[07:45:01.0000] <annevk>
mpt: yeah, that's kinda broken

[07:45:09.0000] <annevk>
same in Opera iirc :/

[08:36:42.0000] <dglazkov>
good morning, Whatwg!

[11:14:47.0000] <Hixie>
i like how the htmlwg changed the language code of the spec, without actually changing what language the spec uses :-)

[11:37:24.0000] <Stevef_>
hixie: the lang code hasn't been changed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18816

[11:38:02.0000] <Stevef_>
they rejected my suggestion <html lang="en-US-x-hober-ginger-erika-travis">

[11:43:09.0000] <Hixie>
Stevef_: as they should, there's no spec for that code

[12:00:40.0000] <Hixie>
Stevef_: (but for what it's worth, i was actually talking about https://github.com/w3c/html/commit/04cee206fd88d2d8f938b31e92b19fc91d356eb7)

[12:07:50.0000] <Stevef_>
hixie: righto

[12:25:06.0000] <annevk>
Hixie: as you long as you keep that x- in there no specification is required I think

[13:12:45.0000] <annevk>
http://lists.w3.org/Archives/Public/www-archive/2012Sep/0004.html backdoor lobbying appears to work in the HTML WG

[13:12:50.0000] <annevk>
what the hell

[13:13:03.0000] <annevk>
backroom*

[13:18:55.0000] <TabAtkins>
I was about to say, I didn't think Sam was quite that, um, liberated.

[13:23:47.0000] <annevk>
TabAtkins: haha

[14:03:03.0000] <Hixie>
annevk: oh i know, but i'm saying what does that language even mean? At least en-us-x-hixie has a spec.

[14:04:44.0000] <jgraham>
en-us doesn't have a spec

[14:05:14.0000] <Hixie>
yeah but it has lots of documentation

[14:05:27.0000] <jgraham>
and I strongly doubt the  x-hixie consistently conforms to its purported spec

[14:05:42.0000] <Hixie>
if you find any mistakes i can fix them :-)

[14:05:52.0000] <Hixie>
which is more than we could say for the other one

[14:05:57.0000] <Hixie>
which is my point :-)

[14:06:03.0000] <jgraham>
Hixie: en-us haslots of conflicting documentation :)

[14:07:32.0000] <jgraham>
(and because it is vaugely on-topic: http://stroppyeditor.wordpress.com/2012/09/04/the-very-model-of-an-amateur-grammarian/ )

[14:08:59.0000] <TabAtkins>
Hm.  Which WG should I be talking in about embedding HTML directly into SVG, without an intervening <foreignContent> and namespace crap?

[14:09:21.0000] <TabAtkins>
I mean, there's some CSS work, but I'm on top of that.

[14:09:50.0000] <Hixie>
TabAtkins: i wouldn't talk about it anywhere :-P

[14:09:59.0000] <TabAtkins>
Too bad, it's gonna happen.

[14:10:16.0000] <TabAtkins>
Apparently SVG directly in HTML is a non-starter still, but the other way around is fine.

[14:13:48.0000] <smaug____>
TabAtkins: why do you want to embed html directly into svg?

[14:14:07.0000] <TabAtkins>
So I can put <span> or <p> inside of SVG, without reinventing HTML in SVG elements?

[14:14:27.0000] <TabAtkins>
If you've never tried to write SVG by hand, dealing with text is THE WORST THING EVER.

[14:14:49.0000] <TabAtkins>
You want a box filled with text?  Congrats, you get to guess how large the text will be and make a completely independent rectangle positioned behind it.

[14:15:01.0000] <TabAtkins>
Linebreaking?  SURELY YOU JEST, SIR.

[14:16:52.0000] <smaug____>
TabAtkins: oh, you want to *fix* svg :)

[14:17:02.0000] <TabAtkins>
Also, shit like <video> and <audio> without going the Tiny1.2 route and having magical unique elements that are different-but-the-same as HTML.

[14:17:16.0000] <TabAtkins>
smaug____: Fixing from the inside, sure.

[14:17:42.0000] <TabAtkins>
The end goal is making SVG entirely a part of HTML, but *some* people have a bizarre attachment to namespaces that is making that difficult.

[14:32:21.0000] <TabAtkins>
The fun part is that SVG is totally cool with merging entirely into HTML, but there's pushback on the HTML side of the "they made their bed, now they have to lie in it" variety. :/

[14:32:49.0000] <gavinc>
bah, those people suck

[14:44:33.0000] <annevk>
TabAtkins: seems mostly a CSS/SVG problem

[14:44:58.0000] <annevk>
TabAtkins: unless you want to change HTML parsing too... in which case WHATWG

[14:46:16.0000] <Hixie>
TabAtkins: my reasoning is "svg is not a media-independent language and it makes no sense to merge them"

[14:47:35.0000] <WeirdAl>
I'd argue against it myself:  HTML and SVG are two honkin' huge specs

[14:47:47.0000] <WeirdAl>
</gallery>

[14:51:14.0000] <gavinc>
Hixie: canvas is media independent?

[15:16:58.0000] <Hixie>
gavinc: you can't put HTML in canvas either

[15:17:38.0000] <Hixie>
gavinc: i don't have a problem with embedding media-specific components in HTML, e.g. <img>, <canvas>, or <svg>. What I'm arguing is that they shouldn't be merged, as in, you're in the middle of SVG and you just randomly break out into HTML, then back into SVG, etc.

[15:17:56.0000] <Hixie>
gavinc: (plus, <canvas> and <img> require that the author provide non-graphical alternatives)

[15:18:11.0000] <zewt>
(for a fake, handwaving value of "require" :)

[15:25:29.0000] <jamesr>
Hixie, but having a <foreignContent> / <svg> boundary makes jumping in/out OK? what's the difference?

[15:28:27.0000] <Hixie>
jamesr: i don't think it makes it particularly ok, no

[15:28:43.0000] <Hixie>
jamesr: i think where svg would make sense is in something like web components

[15:29:40.0000] <Hixie>
(<foreignObject> makes sense in SVG proper because there you're not pretending to be using a media-neutral language, and so you can use HTML for its features while still being fully aware it's still media-specific)

[15:31:08.0000] <jamesr>
i see, so you just think <svg> doesn't make sense in HTML

[15:32:07.0000] <Hixie>
no, i think HTML doesn't make sense inside SVG inside HTML

[15:32:14.0000] <Hixie>
SVG in HTML makes sense just like PNG in HTML makes sense

[15:32:26.0000] <Hixie>
or <audio> in HTML makes sense

[15:32:38.0000] <Hixie>
sometimes you have some media-specific content to place in a media-neutral discussion

[15:33:16.0000] <Hixie>
this is similar to how it makes sense to have a PDF in an <iframe>, but not <font> in a <p>

[15:33:17.0000] <jamesr_>
so what's wrong with that media-specific content embedding media-neutral content?

[15:33:49.0000] <TabAtkins>
Hixie: In my railroad diagrams http://www.xanthir.com/etc/railroad-diagrams/example.html I need to do a *stupid* "guess at metrics and hope" or else "manually measure text" just to get a styled box.  Including a simple <span> in SVG would solve those problems.

[15:34:37.0000] <Hixie>
TabAtkins: the "right" solution is IMHO to have SVG have something like flexbox but for graphics

[15:34:39.0000] <TabAtkins>
SVG could add its own primitives that do the same thing, but that's just duplication of the same nasty variety that led to SVG's <script> and <style>, not to mention Tiny's <audio> and <video>.

[15:34:56.0000] <TabAtkins>
No, the right solution is to *use the technology we have in front of us instead of inventing something new for no reason*.

[15:35:21.0000] <Hixie>
maybe i'm misunderstanding why you are measuring text

[15:35:33.0000] <TabAtkins>
So I can make it look like it's inside of a box.

[15:35:45.0000] <Hixie>
if you just want a box to size to its contents and for all graphics that point to that box to adjust accordingly, HTML ain't gonna help you.

[15:35:47.0000] <TabAtkins>
That's a <text> and an *independent* <rect> element, positioned so that it looks like one is inside the other.

[15:35:51.0000] <gavinc>
TabAtkins: ... that page is supposed to not work right?

[15:36:01.0000] <TabAtkins>
Um, whoops.

[15:36:06.0000] <TabAtkins>
gavinc: I, um, messed it up.  One sec.

[15:36:07.0000] <Hixie>
TabAtkins: i don't see what that has to do with HTML

[15:36:13.0000] <gavinc>
TabAtkins: Ah! Thanks :D

[15:36:34.0000] <Hixie>
jamesr: my problem is with people who write pages intended for the web that only work on one medium, when they should be able to work on any medium.

[15:36:42.0000] <TabAtkins>
gavinc: Fixed.

[15:37:06.0000] <TabAtkins>
Hixie: I think you're not understanding me quite right, and assume I'm asking for soemthing weird.  I'll start small.

[15:37:42.0000] <TabAtkins>
So, see those boxes of text.  They are *not* boxes of text, because SVG doesn't handle text well.  Instead, they're a <rect> and a <text> element, independent siblings, which are positioned on top of each other such that they *look* like a box full of text.

[15:38:10.0000] <TabAtkins>
This is, obviously, stupid.  The shortest path to a solution is to pull in HTML, so I can just put in a <span> and style it like normal CSS, with border and background.

[15:38:10.0000] <Hixie>
TabAtkins: yes

[15:38:21.0000] <Hixie>
TabAtkins: o_O

[15:38:29.0000] <Hixie>
TabAtkins: that seems like a non-sequitur to me

[15:38:36.0000] <Hixie>
TabAtkins: HTML doesn't have any elements with boxes

[15:38:58.0000] <TabAtkins>
?_?

[15:39:04.0000] <Hixie>
TabAtkins: if you are saying you want the _CSS box model_ in SVG, then that's got nothing to do with HTML.

[15:39:10.0000] <Hixie>
TabAtkins: and that i would support

[15:39:50.0000] <TabAtkins>
Sure, theoretically.  But <text> *does not work like span* (or <p> for that matter).  Adding an <svg:span> or <svg:p> that *does* work correctly with the css 'inline' or 'block' model is just nasty, useless duplication.

[15:40:09.0000] <Hixie>
i have no idea what you mean by "work like span"

[15:40:22.0000] <TabAtkins>
I mean "work like an abspos display:inline element".

[15:40:36.0000] <TabAtkins>
<text> has its own crazy handling which can't be changed at this point.

[15:40:36.0000] <Hixie>
that's an entirely different, unrelated, and orthogonal statement.

[15:41:04.0000] <Hixie>
"span" is not "display:inline"

[15:41:17.0000] <Hixie>
they are literally orthogonal facets

[15:41:26.0000] <Hixie>
well not literally

[15:41:45.0000] <TabAtkins>
Dude, bro, I don't care.  The point is, I want normal text in my SVG without having to add <svg:span> to the language.

[15:41:47.0000] <Hixie>
"span" is no more "display:inline" than "h1" is "loud volume"

[15:41:54.0000] <TabAtkins>
I also want <video>, etc, in the same way.

[15:42:11.0000] <Hixie>
i am entirely in favour of making it possible to use the CSS box model in SVG

[15:42:17.0000] <Hixie>
(by the way, that's what <foreignObject> does)

[15:42:28.0000] <TabAtkins>
Yes, but <foreignObject> is stupid and cumbersome.

[15:42:32.0000] <Hixie>
?

[15:42:34.0000] <Hixie>
how so

[15:42:40.0000] <TabAtkins>
And fundamentally *does not work* for the kinds of things I want.

[15:42:59.0000] <Hixie>
/me files a preemptive ticket to get Tab a new asterisk key :-P

[15:43:07.0000] <TabAtkins>
For one, it's an extra long-named wrapper object.  For two, I need to declare a namespace.  For three, it needs a defined width and height.

[15:43:17.0000] <Hixie>
why do you need to declare a namespace

[15:43:33.0000] <Hixie>
<foreignObject> My Text </foreignObject>

[15:43:38.0000] <TabAtkins>
Because otherwise you're using elements in an arbitrary XML dialect, or maybe in just SVG, I dunno.

[15:44:08.0000] <Hixie>
oh wait, <foreignObject> it self isn't a positioned CSS box, is it

[15:44:12.0000] <TabAtkins>
That super doesn't work.  There's nothing to hang the CSS box model off of there, and it still need a 'width' and 'height' attribute specified.

[15:44:16.0000] <TabAtkins>
Nope, it's an SVG box.

[15:44:19.0000] <Hixie>
ok so just get a new element that is a positioned CSS box or whatever

[15:44:21.0000] <Hixie>
<box>

[15:44:29.0000] <TabAtkins>
(All elements in SVG are forced into the SVG display model.)

[15:44:36.0000] <Hixie>
anyway this has no more to do with HTML than it does with MAthML

[15:44:49.0000] <TabAtkins>
So, then what?  I have a <box>.  What do I put in it?  Just plain text?

[15:45:04.0000] <Hixie>
whatever you want, same as in CSS-styled raw XML

[15:45:20.0000] <TabAtkins>
That's a dumb solution.  CSS-styled raw XML is cumbersome.

[15:45:34.0000] <TabAtkins>
Plus much less featureful.

[15:45:37.0000] <Hixie>
it's not a dumb solution

[15:45:45.0000] <Hixie>
/me returns to <track>

[15:46:16.0000] <TabAtkins>
I'm not sure how you can say "just use raw XML from an arbitrary language" is better than "use HTML".

[15:47:45.0000] <TabAtkins>
Where "use HTML" has things like "yay, free styling/accessibility for <em>! yay, <video>! yay, <details>! yay, everything else that HTML gives me for free, and that I'd have to reinvent manually in raw XML!"

[15:53:12.0000] <TabAtkins>
Anyway, back to the original question.

[15:53:39.0000] <TabAtkins>
annevk: You said WHATWG if I wanted to change HTML parsing.  I shouldn't need to, I don't think...

[15:53:43.0000] <TabAtkins>
/me goes to check the parser.

[15:56:25.0000] <Hixie>
your use case was text with a box using the CSS inline box model, and didn't mention anything that would result in us even considering <video>, <details>, or <em>. If there are other use cases, then we should consider those as well.

[15:56:35.0000] <Hixie>
but so far I haven't seen any.

[15:56:52.0000] <Hixie>
(note that <video> in Tiny and <video> in HTML are quite different and have different use cases)

[15:56:56.0000] <TabAtkins>
Those other cases come along for the ride. :/  If I'm putting text in a diagram, *obviously* I sometimes want to emphasize parts of it.

[15:57:10.0000] <Hixie>
you want to emphasise it, or you want to italicise it?

[15:57:16.0000] <TabAtkins>
Both.

[15:57:23.0000] <Hixie>
can you elaborate on your use case for emphasis?

[15:57:26.0000] <TabAtkins>
The entire set of inline-type elements have useful semantics for text inside of diagrams.

[15:57:30.0000] <Hixie>
i don't understand how or why

[15:57:56.0000] <TabAtkins>
I don't understand how you dont' understand. :/  You have text.  In a diagram.  Some of that text may be emphatic.

[15:58:36.0000] <Hixie>
your use case seems circular :-)

[15:58:51.0000] <TabAtkins>
How so?

[15:58:57.0000] <TabAtkins>
/me doesn't understand.

[16:00:02.0000] <Hixie>
you want to be able to mark text as emphasised because you have text that is emphasised?

[16:00:11.0000] <TabAtkins>
...yes?

[16:00:12.0000] <Hixie>
do you also want to be able to mark verbs?

[16:00:58.0000] <TabAtkins>
I'd like to be able to mark up text with the same set of semantics that HTML grants, because that set has proven useful over time.  (Some of the set is just legacy, but including them doesn't harm anything.)

[16:01:26.0000] <TabAtkins>
This set of semantics is already mapped to presentation in other formats, like screen readers.

[16:01:36.0000] <TabAtkins>
It is the lingua franca of text semantics on the web.

[16:02:05.0000] <Hixie>
it has proven to be useful in particular because HTML can be rendered to multiple media, including in particular speech, braille, and visual media. This doesn't seem to apply when the use case is specifically for graphical diagrams.

[16:02:34.0000] <Hixie>
hence my asking you what the use case is

[16:02:38.0000] <zewt>
uh, no, "multiple media" has very very little to do with the wide use of html

[16:02:42.0000] <TabAtkins>
And that's incorrect.  For example, an SVG diagram can be combined with a pointing device that reads out text at the given point, to help low-vision users.

[16:02:45.0000] <TabAtkins>
This already exists, I believe.

[16:02:57.0000] <Hixie>
zewt: the set being useful has very little to do with the wide use of HTML too

[16:03:00.0000] <TabAtkins>
Expanding the set of textual semantics usable in this situation is a win.

[16:03:09.0000] <Hixie>
TabAtkins: aha, a new use case

[16:03:12.0000] <zewt>
it's fine for you to consider it important, but don't pretend it's a bigger factor for its success than it is

[16:03:32.0000] <Hixie>
zewt: i don't believe i pretended anything was a success?

[16:03:48.0000] <Hixie>
zewt: not sure what you're arguing against :-)

[16:04:24.0000] <zewt>
you said that multiple media is a significant ("particular") reason for HTML having been proven useful; really, it's a tiny, tiny piece

[16:04:58.0000] <TabAtkins>
zewt: We're not talking about HTML's suitability in general, so it's not necessary to defend its honor in this instance.

[16:05:08.0000] <Hixie>
TabAtkins: you should describe the use cases somewhere, rather than start with the solution you prefer, because it's not clear to me that the solution you prefer is a logical result of the use cases you've presented so far, but i can't tell if that's because it's a bad solution or if the use cases are incomplete (or both).

[16:05:43.0000] <TabAtkins>
Since, on inspection, this *will* require minor parser changes of some kind, I'll make a post on WHATWG.

[16:05:47.0000] <zewt>
TabAtkins: i may be doing the opposite of defending its honor, since i'm saying HTML would be just-about as successful if it didn't support multiple media :)

[16:05:48.0000] <Hixie>
zewt: i'm specifically talking about the semantics of certain inline elements, most of which are vastly underused and are definitely not what i would call a "success", at least not on the level of HTML overall

[16:06:08.0000] <Hixie>
TabAtkins: please be sure to start (and possibly stop, if you can :-) ) with use cases, at least in your first post :-)

[16:06:15.0000] <TabAtkins>
(To somehow avoid the "when you see an HTML element, POP EVERYTHING until you get out of the SVG context.)


2012-09-11
[19:00:32.0000] <Hixie>
hm. opera and webkit render this poorly due to an HTML parsing issue: http://www.thezorklibrary.com/history/00-encyclopedia.html

[19:00:35.0000] <Hixie>
gecko doesn't

[19:00:40.0000] <Hixie>
gecko bug? spec bug?

[19:00:43.0000] <Hixie>
opera and webkit bug?

[19:12:14.0000] <zewt>
fine in ie9

[00:06:10.0000] <zcorpan>
Hixie: did they talk to you before removing the license paragraph?

[00:07:30.0000] <Hixie>
no

[00:26:32.0000] <zcorpan>
booo

[00:28:11.0000] <MarkusDBX>
Should html/css validation be used in the year of 2012? In that case... what is the best validator to date? That follows the WHATWG version of html? Thank you.

[00:30:16.0000] <zcorpan>
why would the year make a difference? a validator is a quality assurance tool (like a spell checker)

[00:31:23.0000] <zcorpan>
http://validator.nu/ for html validation

[00:32:29.0000] <zcorpan>
i can't recommend a css validator but browsers usually flag things they think are invalid in css in their error consoles, so that's what i usually use to find errors in my css

[00:35:51.0000] <MarkusDBX>
zcorpan: sounds reasonable. I just mentioned the year, since the html-spec has changed somewhat i the last years. I used to use the w3c validator, but in the last years we have just used the browser-errors.

[00:36:15.0000] <MarkusDBX>
zcorpan: I now look for  even better QA to make our clients even more happy.

[00:36:39.0000] <zcorpan>
yeah the validator isn't perfectly up-to-date with the spec, but then again browsers also aren't

[00:37:31.0000] <zcorpan>
if you find bugs in the validator, file it here: http://bugzilla.validator.nu/ :-)

[00:37:32.0000] <MarkusDBX>
Is chrome or ff the better validator?

[00:37:52.0000] <zcorpan>
for css?

[00:38:10.0000] <MarkusDBX>
for css.

[00:38:33.0000] <zcorpan>
i'd recommend checking in multiple browsers since they might not all support the same set of features

[00:39:03.0000] <MarkusDBX>
ah. I see

[00:39:17.0000] <MarkusDBX>
zcorpan: any other good advice to improve QA?

[00:39:55.0000] <zcorpan>
MarkusDBX: http://blog.whatwg.org/quality-assurance-tools-for-html5

[00:40:12.0000] <MarkusDBX>
great

[00:40:26.0000] <MarkusDBX>
zcorpan: thanks alot

[00:42:11.0000] <zcorpan>
MarkusDBX: on a different level, i'd recommend user testing to get better user experience, and automated regression testing so you get to know when something stops working before your users find out and someone tells you instead of going to your competitor :-)

[00:45:39.0000] <a-ja>
Hixie: anyone bringing up issues with <track default> ?

[00:49:21.0000] <a-ja>
Hixie: asking cuz I was trying out a webvtt polyfill that would only use chapters if default'ed...so one would have to have two defaults specified....one for  subtitles/captions and another for chapters.

[00:51:37.0000] <a-ja>
Hixie: which suggests a use case......to select language for chapters as well as subtitles/captions

[00:51:51.0000] <a-ja>
Hixie: thoughts?

[00:52:47.0000] <zcorpan>
a-ja: there's a bug

[00:53:21.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17877

[00:53:26.0000] <a-ja>
zcorpan:ah....musta missed it.   #?

[00:53:33.0000] <a-ja>
k...tks

[00:54:10.0000] <zcorpan>
a-ja: for now, i'd recommend explicitly setting .mode instead of relying on default=""

[00:55:41.0000] <a-ja>
.mode ???   guess i have some more reading to do.

[00:57:05.0000] <zcorpan>
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#dom-texttrack-mode

[00:58:05.0000] <zcorpan>
(if you want to expose the chapters yourself and don't want the browser to render them somehow, use "hidden")

[01:06:13.0000] <a-ja>
zcorpan: mode's not an attribute of the track element, but changeable in DOM via js?

[01:06:36.0000] <zcorpan>
right

[01:06:48.0000] <zcorpan>
track_element.track.mode = 'hidden'

[01:06:54.0000] <a-ja>
hrm

[01:07:26.0000] <zcorpan>
setting mode triggers the track to load

[01:08:23.0000] <zcorpan>
see http://simon.html5.org/presentations/foms-2012/ for an example

[01:11:06.0000] <a-ja>
zcorpan: leanback player's the one that required default on chapter track for it to show up in its UI, iirc

[01:12:39.0000] <a-ja>
/me is really trying to not have to use js

[01:12:44.0000] <zcorpan>
a-ja: ok, well, until the spec has fixed its rules around default="", i'd recommend leanback player to hook in to a custom data- attribute and set mode explicitly :-)

[01:13:48.0000] <a-ja>
zcorpan:  that'd make sense.....esp since it's already using data- for fallback stuff

[01:16:49.0000] <zcorpan>
a-ja: is http://discussion.leanbackplayer.com/categories/development their bug tracker?

[01:16:54.0000] <a-ja>
no biggie for me...strictly for my intranet use...so i don't have to rely on polyfills or even flash fallback.  just thought perhaps i'd stumbled on a possibly unknown use case for default-per-type

[01:19:43.0000] <a-ja>
zcorpan: dunno...just tried a few different polyfills briefly (before abandoning them as superfluous for my needs)

[01:40:28.0000] <zcorpan>
a-ja: filed http://discussion.leanbackplayer.com/discussion/153/default-attribute-for-chapters

[01:43:02.0000] <a-ja>
zcorpan: fwiw, there's a new beta out this month....i likely have the prior beta

[01:43:56.0000] <zcorpan>
ok. i haven't tried it at all, i've just stolen their captions for my demo :-P

[03:09:23.0000] <annevk>
karlcow: watching them more or less in chronological order

[03:09:38.0000] <annevk>
karlcow: at least the purported trilogy (still need to see 2046)

[04:09:34.0000] <zcorpan>
Hixie: minimized to http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1757

[04:11:20.0000] <zcorpan>
seems it's related to the "don't reconstruct more than three identical elements" thing

[04:14:24.0000] <zcorpan>
i can't wrap my head around AAA so i can't tell if it's a spec bug or not

[04:14:37.0000] <zcorpan>
but i'll file a opera bug

[05:18:39.0000] <zcorpan>
sigh. why do web shops send me my password in plain text in email?

[05:20:09.0000] <zcorpan>
and also "security tips" like i should change my password every 6 months

[05:34:38.0000] <annevk>
sweet

[05:34:42.0000] <annevk>
the github setup works great

[06:16:17.0000] <annevk>
Hixie: when you're awake again, can you give me encoding.spec.whatwg.org / xhr.spec.whatwg.org / fullscreen.spec.whatwg.org

[06:53:26.0000] <zcorpan>
Hixie: apparently the spec is right (re AAA)

[07:04:39.0000] <zcorpan>
(filed https://bugs.webkit.org/show_bug.cgi?id=96385 )

[07:34:58.0000] <annevk>
Hixie: might as well create url.spec and fetch.spec (for CORS, later fetch) while you're at it

[07:35:16.0000] <annevk>
Hixie: thinking about merging Progress Events into XMLHttpRequest

[07:35:24.0000] <annevk>
dunno about Web Notifications

[07:35:34.0000] <annevk>
anyone with opinions?

[07:36:11.0000] <darobin>
annevk: would it change anything other than document organisation?

[07:36:32.0000] <annevk>
darobin: the merging?

[07:37:15.0000] <darobin>
yeah

[07:37:28.0000] <annevk>
not really, mostly easier for me

[07:37:34.0000] <darobin>
then *shrug*

[07:37:50.0000] <annevk>
well yeah, I actually meant about Web Notifications

[07:38:14.0000] <annevk>
I guess we can fork that too, but maybe wait a bit to see what happens first

[07:38:21.0000] <annevk>
there's no hurry

[07:38:23.0000] <darobin>
ah, gotcha

[07:39:19.0000] <annevk>
Hixie: interested in using https://github.com/whatwg too?

[07:39:37.0000] <annevk>
I suppose it should handle things as large as HTML

[07:40:55.0000] <darobin>
annevk: it handles them just fine :)

[07:41:16.0000] <darobin>
in fact, it's even fucking fast, considering

[07:41:55.0000] <annevk>
ah yeah, you guys are using github too

[07:41:58.0000] <annevk>
sweet

[07:42:01.0000] <jgraham>
Hmm, I tried importing the HTML spec into git once, with the full history

[07:42:05.0000] <darobin>
annevk: to make your life easier you could even just clone https://github.com/w3c/html/tree/feature/whatwg ;-)

[07:42:07.0000] <jgraham>
and it worked fine

[07:42:13.0000] <jgraham>
But it was *big*

[07:42:19.0000] <jgraham>
and github didn;t like it

[07:42:21.0000] <darobin>
the first import takes a while

[07:42:39.0000] <darobin>
jgraham: the W3C repo has all the SVN history from WHATWG

[07:43:18.0000] <darobin>
in fact, in theory we could all use the same repo just with different branches

[07:43:26.0000] <darobin>
/me puts flowers in his head

[07:43:26.0000] <annevk>
heh, fork the W3C copy of the WHATWG copy of HTML to WHATWG

[07:43:31.0000] <darobin>
:)

[07:47:18.0000] <jgraham>
darobin: Pretty sure you are only suppose to put the flowers in your hair, not try to penetrate the skull

[07:47:51.0000] <darobin>
jgraham: you're such a boring square

[08:43:44.0000] <scor>
where in the microdta spec does it say that a property cannot be used in its ful URI form if the vocabulary specifying it does not allow it?

[09:16:25.0000] <dglazkov>
good morning, Whatwg!

[09:19:02.0000] <david_carlisle>
TabAtkins:  Yes please we (mathematicians everywhere) want to be able to do commutative diagrams by just naturally nesting mathml in svg in html, it almost but not quite "just works"

[09:49:13.0000] <Hixie>
scor: properties don't have "full URI forms" unlsess a vocabulary specifies it

[09:49:33.0000] <Hixie>
annevk: what username should i use for you, assuming we're not going through the hoops we went through last time?

[09:50:09.0000] <Hixie>
annevk: re github, i have no reason to use github

[09:50:20.0000] <scor>
Hixie: ok, so the vocab author would have to specify both the short form and the full URI for both of them to be usable and valid?

[09:50:51.0000] <Hixie>
scor: yeah, though i wouldn't recommend it. You could end up with items that have two values for the property.

[09:51:08.0000] <Hixie>
scor: you'd really have to define them as separate properties and say which one takes preference, etc

[09:51:18.0000] <jgraham>
Hixie: (FWIW if you used github it would be better for me in a few small ways e.g. the revision list would be better than annevk's thing)

[09:51:19.0000] <scor>
for example one could define both 'http://example.com/fn' and 'fn'

[09:51:21.0000] <scor>
and have the same definition for both

[09:51:30.0000] <jgraham>
(so that is one small reason)

[09:51:48.0000] <Hixie>
jgraham: i think darobin's crew has that covered already

[09:52:07.0000] <Hixie>
scor: say you defined both of those to mean "biological mother"

[09:52:09.0000] <jgraham>
Hixie: Only to the extent that they pull in all the cvhanges you make

[09:52:12.0000] <scor>
Hixie: but I understand that even if both were defined, values using each would not be equivalent

[09:52:15.0000] <Hixie>
scor: and an item had both set, pointing at different other items...

[09:52:21.0000] <jgraham>
Which theya re sure not to

[09:52:38.0000] <Hixie>
scor: you'd just have to say which takes precedence (and say that it's not conforming to have both, so validators of that vocabulary could complain)

[09:52:48.0000] <scor>
ok

[09:52:51.0000] <Hixie>
jgraham: they have a branch on which they are doing so, i believe

[09:53:25.0000] <scor>
Hixie: now, where in the spec does it say that it is not valid to use a full URI for a property if the vocabulary does not define it?

[09:53:25.0000] <jgraham>
So they have one branch that is precisely the WHATWG spec?

[09:53:30.0000] <jgraham>
Interesting

[09:53:31.0000] <scor>
or is that implicit?

[09:53:46.0000] <Hixie>
scor: the spec says it's not valid to use a property that isn't defined, iirc

[09:53:56.0000] <Hixie>
scor: if you have a vocabulary type

[09:54:02.0000] <scor>
Hixie: I'm looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#selecting-names-when-defining-vocabularies

[09:54:07.0000] <scor>
(hope it's the right place)

[09:54:15.0000] <Hixie>
That section is non-normative

[09:54:29.0000] <Hixie>
you want http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#names:-the-itemprop-attribute for the nitty gritty

[09:55:01.0000] <Hixie>
hm, i guess it does allow URLs always

[09:55:05.0000] <Hixie>
interesting

[09:55:13.0000] <scor>
is it a bug?

[09:55:21.0000] <scor>
should it disallow them?

[09:55:32.0000] <scor>
(if not defined in the vocab)

[09:55:42.0000] <Hixie>
yeah, it's a bug. It should only allow URLs that are defined to be properties.

[09:56:47.0000] <Hixie>
same as itemtype=""

[09:57:16.0000] <Hixie>
filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18837

[09:57:26.0000] <Hixie>
/me pokes annevk 

[10:00:57.0000] <annevk>
Hixie: if annevk is taken, anne or annevankesteren

[10:01:11.0000] <annevk>
Hixie: or avankest for some irony

[10:01:13.0000] <Hixie>
i think annevk is taken by you

[10:02:06.0000] <Hixie>
anne is taken too, now trying annevankesteren

[10:02:29.0000] <Hixie>
ok, created user. now the domains

[10:02:39.0000] <Hixie>
annevk: which subdomains did you want again? can you list them all, comma separated?

[10:03:17.0000] <annevk>
url.spec.whatwg.org, xhr.spec.whatwg.org, encoding.spec.whatwg.org, fullscreen.spec.whatwg.org, fetch.spec.whatwg.org

[10:03:36.0000] <Hixie>
url, xhr, encoding, fullscreen, and fetch. ok

[10:04:04.0000] <Hixie>
after this i'll be up to 80 subdomains and domains on my plan, sheesh

[10:04:11.0000] <annevk>
heh

[10:04:22.0000] <annevk>
these could've been directories :p

[10:04:38.0000] <Hixie>
do you have a preference for directory structure in /home/annevankesteren/?

[10:04:48.0000] <Hixie>
just .../url.spec.whatwg.org/... ?

[10:05:11.0000] <annevk>
yeah that's fine

[10:05:19.0000] <annevk>
just defaults

[10:05:24.0000] <annevk>
only need to put a small script there

[10:05:29.0000] <Hixie>
roger

[10:07:07.0000] <Hixie>
freaking captchas

[10:08:50.0000] <annevk>
yeah, you'd think if you have a registered account there's no need for captchas

[10:09:53.0000] <Hixie>
nothing stops spammers from registering accounts and then generating 10,000 spammy domains

[10:10:31.0000] <Hixie>
ok any others while i'm at it?

[10:11:27.0000] <zewt>
well, assuming a captcha is required for creating accounts, that means the spammy domains can all be associated with the user and bulk deleted

[10:11:49.0000] <annevk>
Hixie: I used to edit Notifications, but I guess I'll wait to see if the W3C finishes that

[10:11:54.0000] <Hixie>
zewt: once you notice them

[10:12:20.0000] <Hixie>
ok. i'll mail you the e-mails once i get them.

[10:12:29.0000] <Hixie>
anne⊙an?

[10:13:18.0000] <annevk>
Hixie: annevk⊙an

[10:13:31.0000] <Hixie>
lol. http://www.whatwg.org/specs/README -- and people say i was unrealistic with my 2022 date.

[10:15:11.0000] <Hixie>
annevk: no dom.specs.whatwg.org?

[10:15:31.0000] <annevk>
Hixie: http://dom.spec.whatwg.org exists

[10:15:42.0000] <Hixie>
oh right that's the one we jumped through hoops for

[10:15:55.0000] <annevk>
Hixie: yeah, we could move it back, but might as well leave as is for now

[10:16:08.0000] <Hixie>
please yes let's not move that again!

[10:16:29.0000] <annevk>
maybe we should have redirects from specs to spec seeing how you already make that mistake

[10:17:47.0000] <Hixie>
not sure how to do that

[10:21:11.0000] <annevk>
Philip` did something like that once for his philip.html5.org domain

[10:21:20.0000] <Hixie>
on dreamhost?

[10:21:28.0000] <Hixie>
wonder how

[10:21:30.0000] <annevk>
can set up some kind of wildcard DNS match for *.specs.whatwg.org

[10:21:41.0000] <annevk>
but where you catch that I'm less sure about

[10:21:50.0000] <annevk>
Philip`?

[10:22:55.0000] <annevk>
gotta go

[10:24:28.0000] <scor>
Hixie: so just to be sure, is this statement correct? http://lists.w3.org/Archives/Public/public-vocabs/2012Sep/0055.html

[10:25:05.0000] <scor>
in particular, which vocab decides whether it's valid to use full URIs, the vocab used in @itemtype, or the vocab defining the full URI?

[10:25:47.0000] <Hixie>
scor: i don't believe that's right. you can add any random property you want if it's got a URL-based name.

[10:26:14.0000] <Hixie>
scor: the idea is you use your own proprietary URL property names to add random data to items using other people's vocabularies

[10:26:26.0000] <Hixie>
scor: (which is probably why the spec doesn't require a spec to define them, come to think of it)

[10:32:54.0000] <Hixie>
didn't anne also work on CORS?

[10:32:58.0000] <Hixie>
i wonder where that's gonna live

[11:21:49.0000] <annevk>
Hixie: that's "fetch"

[11:21:55.0000] <annevk>
Hixie: bit forward looking maybe...

[11:22:29.0000] <annevk>
Hixie: but since CORS is done (imo) I thought I put it there with some placeholder text to see if anyone is interested in merging CORS and HTML fetch

[11:23:33.0000] <annevk>
Hixie: and I also maintained Progress Events which I plan to fold into xhr

[11:35:03.0000] <heycam>
yes, flexbox (or generally applying CSS layout models) to SVG content!

[11:35:15.0000] <heycam>
I think that is the way to go

[11:40:59.0000] <Hixie>
annevk: k

[13:04:03.0000] <smaug____>
gavin: help. can't connect to moznet. too many connection

[13:04:23.0000] <smaug____>
or sicking

[13:05:32.0000] <sicking>
smaug____: how can i help?

[13:10:24.0000] <smaug____>
gavin: sicking: nm, I filed a bug

[15:51:56.0000] <Hixie>
annevk: yt?

[16:14:12.0000] <padenot>
l/b 51


2012-09-12
[17:36:57.0000] <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 ?

[17:37:25.0000] <edburns>
Hixie: I remember you from the Netscape 6 days, but I doubt you remember me.

[19:01:16.0000] <Hixie>
edburns: name doesn't ring a bell, but that was a long time ago :-)

[19:01:29.0000] <Hixie>
edburns: <object> being submittable doesn't really mean anything unless you have a plugin

[21:01:05.0000] <edburns>
Hixie: Thanks for the response.

[21:02:58.0000] <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.

[21:04:01.0000] <edburns>
Hixie: Some more NetScape 6 names for you: Dawn Endico and Daniel Nunes, remember either of those folks, or Patrick Beard?

[23:30:44.0000] <dirkpennings>
somebody knows if the new posiition: sticky is coming to iOS Safari, and when?

[23:53:28.0000] <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'?

[00:02:30.0000] <annevk>
Hixie: here now...

[00:04:41.0000] <Hixie>
edburns: fieldset and output aren't submittable, as far as i can see... where do you see that they're submittable?

[00:05:08.0000] <Hixie>
edburns: and yeah, i remember dawn, and the other names sound familiar

[00:05:44.0000] <Hixie>
zcorpan: should be set to showing if there's no better choice, and hidden otherwise. might be a mistake in the spec though.

[00:05:59.0000] <Hixie>
annevk: see fullscreen bug

[00:10:12.0000] <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

[00:13:02.0000] <Hixie>
oops, i forgot to add the relevant line to step 4

[00:15:30.0000] <Hixie>
zcorpan: ok, fixed. Note that this assumes that the requested changes to default=""'s authoring conformance requirements get made.

[00:19:29.0000] <zcorpan>
Hixie: now the spec makes multiple tracks showing rather than one (the first with default="") showing and the rest hidden

[00:19:55.0000] <Hixie>
yeah, that's intentional

[00:20:02.0000] <Hixie>
with metadata, multiple will be allowed

[00:20:16.0000] <Hixie>
and with others, it's non-conforming anyway, but we enable them all for consistency

[00:20:23.0000] <Hixie>
that's what i meant by the "note that this assumes..."

[00:21:10.0000] <zcorpan>
ok. for metadata, showing and hidden are equivalent. for the others, i'm not happy with enabling several in the automatic selection

[00:21:42.0000] <zcorpan>
i think metadata should be special-cased such that default always sets hidden and user pref doesn't apply to metadata

[00:22:01.0000] <Hixie>
what's wrong with enabling several?

[00:22:04.0000] <Hixie>
the author screwed up anyway

[00:22:07.0000] <Hixie>
who cares what happens

[00:23:00.0000] <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

[00:23:35.0000] <zcorpan>
we usually do something sane even when the author screws up

[00:24:39.0000] <Hixie>
enabling the ones the author said to enable seems sane :-)

[00:24:56.0000] <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

[00:25:03.0000] <Hixie>
i've got to go to bed

[00:25:29.0000] <zcorpan>
ok

[00:28:39.0000] <annevk>
Hixie: ah, had added a comment already, sounds good

[00:28:59.0000] <Hixie>
zcorpan: btw, does opera have an opinion on http://www.whatwg.org/issues/#New-features--dnd-directories--awaiting-interest-from-more-vendo ?

[00:30:37.0000] <zcorpan>
Hixie: i don't know. i can ask our DnD people

[00:31:24.0000] <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.

[00:32:16.0000] <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

[00:32:29.0000] <sicking>
Hixie: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI

[00:32:43.0000] <zcorpan>
Hixie: *my* knee-jerk sides with sicking's suggestion, but i haven't thought about this much

[00:32:47.0000] <Hixie>
sicking: which would be used in dnd?

[00:33:11.0000] <Hixie>
zcorpan: yeah, mine too (it's even easy to support empty directories, just have a file called "." in each directory, with no data)

[00:33:12.0000] <sicking>
Hixie: the intent is that we can then use it for DnD as well yes

[00:33:41.0000] <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

[00:33:58.0000] <Hixie>
sicking: what does it add over your earlier suggestion of "just put the relative path in the filename"?

[00:34:27.0000] <sicking>
Hixie: it'll probably be an additional enumerate() function once it's finished though (for shallow enumeration)

[00:35:07.0000] <sicking>
Hixie: mostly it handles the probably better when someone dropps a huge directory

[00:35:11.0000] <sicking>
drops even

[00:35:32.0000] <Hixie>
how so?

[00:35:41.0000] <sicking>
Hixie: we really want some sort of ability for the webpage to get notified about progress of finding the full list of files

[00:36:03.0000] <Hixie>
sicking: not sure i'm following

[00:36:24.0000] <sicking>
Hixie: iirc my proposal was that .files on the "drop" event has the full list of files

[00:36:30.0000] <Hixie>
right

[00:36:48.0000] <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

[00:37:22.0000] <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

[00:37:47.0000] <Hixie>
sicking: so instead you want an API that fires an event periodically as things get collected?

[00:37:48.0000] <sicking>
Hixie: effectively, that would to the user look like nothing happened for that long period of time

[00:38:07.0000] <Hixie>
well, the user agent would presumably show a progress UI

[00:38:49.0000] <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

[00:39:30.0000] <Hixie>
why not just make FileList have a boolean "stillAddingFiles", and while that's true, fire progress events at that object regularly?

[00:40:08.0000] <sicking>
Hixie: That could also work yes. But that would be a backwards incompatible change if we just modify how .files work

[00:40:25.0000] <Hixie>
what would you return on .files if we didn't do that then?

[00:40:58.0000] <sicking>
Hixie: I don't know. Probably null and have a separate property :(

[00:41:26.0000] <Hixie>
that seems even less backwards compatible

[00:41:53.0000] <Hixie>
i agree that adding files dynamically isn't cool though...

[00:41:59.0000] <sicking>
yeah

[00:42:09.0000] <Hixie>
ah well, i'll think on it

[00:42:25.0000] <sicking>
Hixie: please do

[00:42:27.0000] <Hixie>
i'm skeptical about adding a whole ton of API essentially just for this though.

[00:42:34.0000] <Hixie>
right, way late for bed.

[00:42:35.0000] <Hixie>
nn

[00:42:53.0000] <sicking>
the DeviceStorage API is basically just a .get() and a .enumerate() though

[00:43:00.0000] <sicking>
not "a whole ton of API"

[00:43:08.0000] <jamesr>
how's this relate to the filesystem api? totally separate?

[00:43:30.0000] <sicking>
jamesr: totally separate but with the same feature set. *much* simpler and smaller API

[02:07:34.0000] <annevk>
Hixie: nano fails

[02:07:55.0000] <annevk>
nano FILENAME

[02:07:55.0000] <annevk>
Error opening terminal: xterm-256color.

[02:08:04.0000] <annevk>
Hixie: vi does not make me happy

[02:16:34.0000] <annevk>
Hixie: hmm fixed

[02:16:41.0000] <annevk>
Hixie: apparently the problem was with Mac OS Lion!

[02:34:15.0000] <annevk>
also weird

[02:34:28.0000] <annevk>
on your DreamHost server backspace is borked, on mine it works fine

[02:34:39.0000] <annevk>
I assume that's a Mac OS Lion problem too, but I wonder why it's so different

[02:34:42.0000] <jgraham>
Seems that the spec's handling og javascript URLs isn't really right

[02:36:49.0000] <jgraham>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1759 <- per browsers that should say "pass"

[02:37:16.0000] <jgraham>
Per the spec I think it says FAIL, because the javascript url navigation aborts the earlier navigation

[02:38:36.0000] <jgraham>
Hixie: ^

[02:52:16.0000] <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/

[02:54:33.0000] <jgraham>
"Note: Web platform bytes consist of exactly eight bits" 0 as opposed to 8.1 or 7.99?

[02:55:11.0000] <annevk>
I don't follow

[02:55:43.0000] <jgraham>
The word "exactly" there seems rather unnecessary

[02:55:55.0000] <annevk>
I see

[02:57:45.0000] <jgraham>
s/0/-/

[02:58:39.0000] <annevk>
jgraham: https://github.com/whatwg/encoding/commit/fe540c95535e7a299e296202637954203bf1c4cd

[02:59:39.0000] <jgraham>
Thank you :)

[05:11:07.0000] <annevk>
so should we spam @whatwg even more

[05:11:13.0000] <annevk>
with updates to DOM etc.

[05:11:19.0000] <annevk>
?

[05:22:07.0000] <deane>
annevk: I'm liking these living standard specs :) Nice

[05:22:30.0000] <deane>
Is there a page that lists them all?

[05:24:14.0000] <annevk>
http://krijnhoetmer.nl/irc-logs/whatwg/20120912#l-376 ;)

[05:24:29.0000] <annevk>
I assume we're going to do something on spec.whatwg.org in due course

[05:24:55.0000] <annevk>
there's also http://mimesniff.spec.whatwg.org/ come to think of it

[05:25:50.0000] <deane>
cool

[05:26:16.0000] <deane>
Yeah I saw all those five.

[05:27:10.0000] <deane>
Yeah, having a list on spec.whatwg.org would be good.

[05:27:17.0000] <annevk>
http://html.spec.whatwg.org/ also exists

[05:27:27.0000] <annevk>
at some point that's going to be the official URL I think

[05:27:45.0000] <annevk>
but currently it has broken icons and things

[05:28:54.0000] <deane>
Yeah, but the html one is a mistake, it links to the wrong spec, links to the single page one

[05:30:29.0000] <deane>
whatwg.org/html links to the multipage spec

[05:31:53.0000] <deane>
So the "html" links are kinda mixed up, but perhaps it doesn't matter.

[06:35:02.0000] <annevk>
deane: I think we should fix URL conformance for the bug in fetch.spec.whatwg.org :)

[06:35:19.0000] <annevk>
deane: and as I'm going to fix URLs...

[06:36:27.0000] <deane>
Oh, I didn't really look at it too closely.

[06:36:59.0000] <annevk>
making [ and ] non-conforming in URL paths is just silly

[06:40:31.0000] <edburns>
Hixie: Thanks for your response.  I incorrectly asserted that <output> and <fieldset> were submittable.  You are correct to say they are not.

[06:42:47.0000] <darobin>
today we lament the disparition of annevk, who decided to "fix URLs" and was never seen again

[06:44:13.0000] <jgraham>
/me read "disapparition" which suggests too much Harry Potter

[06:56:32.0000] <annevk>
http://xhr.spec.whatwg.org/#interface-progressevent

[06:56:49.0000] <annevk>
darobin: heh, hope not :)

[07:06:38.0000] <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?

[07:07:05.0000] <annevk>
I have done such a thing before

[07:07:07.0000] <annevk>
nobody complained

[07:07:14.0000] <zcorpan_>
well then

[07:09:19.0000] <darobin>
it's not like anybody actually looks at those tests

[07:09:28.0000] <jgraham>
zcorpan_: I have done that already (locally)

[07:09:37.0000] <jgraham>
I can push if you want

[07:09:46.0000] <zcorpan_>
jgraham: ah. then i won't duplicate your work

[07:11:21.0000] <zcorpan_>
/me goes back to track

[07:12:05.0000] <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)

[07:12:55.0000] <jgraham>
Hmm, well I just pushed the test I wrote

[07:13:14.0000] <darobin>
annevk: didn't webapps agree to stop using the submissions thing?

[07:13:22.0000] <darobin>
/me has lost track of who's agreed to that and who hasn't

[07:13:31.0000] <annevk>
same here

[07:13:37.0000] <jgraham>
Did anyone agree to anything?

[07:13:38.0000] <darobin>
I suspect everyone agrees and we're just doing this out of inertia

[07:13:52.0000] <jgraham>
Yes, that exactly I think

[07:14:06.0000] <jgraham>
Although I thought it more strongly for the submitted/approved thing

[07:14:27.0000] <darobin>
dump everything in one directory — structure is for losers

[07:14:46.0000] <darobin>
we also mentioned using branches for the approved/submitted difference

[07:15:02.0000] <jgraham>
That would get messy quickly

[07:15:06.0000] <jgraham>
(branches)

[07:15:13.0000] <jgraham>
I mean, I like the idea

[07:15:25.0000] <jgraham>
But each submission would have to be its own branch

[07:16:02.0000] <jgraham>
And then it would be impossible to get all the tests even if they hadn't been approved

[07:20:19.0000] <jgraham>
(so a more sensible option would be a linear history, but a review tool that could mark certain commits as reviewed)

[07:20:28.0000] <jgraham>
(or certain files in certain commits)

[07:21:11.0000] <jgraham>
(then a file would be reviewed if it was reviewed in all the commits in its history)

[07:24:09.0000] <darobin>
jgraham: I wasn't thinking of having each submission in its own branch

[07:24:14.0000] <darobin>
that seems messy

[07:24:32.0000] <darobin>
I was just thinking of having master where every one would dump the tests they bring in

[07:24:39.0000] <zcorpan_>
+1 to review tool

[07:24:49.0000] <darobin>
and an approved branch where individual tests would be cherry picked to

[07:25:02.0000] <darobin>
so you'd have one branch with everything

[07:25:21.0000] <jgraham>
darobin: But then it becomes difficult to tell waht you have / haven't cherry picked

[07:25:27.0000] <jgraham>
all the SHA1s change

[07:25:43.0000] <zcorpan_>
darobin: with several release channels? :-)

[07:25:47.0000] <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 :)

[07:26:31.0000] <darobin>
jgraham: sure, but the names don't (or shouldn't)

[07:27:09.0000] <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

[07:29:16.0000] <jgraham>
darobin: Sadly most useful git tools are designed to work with the SHA1s, not the commit messages :)

[07:29:48.0000] <darobin>
jgraham: yeah, we're going to have to move to a proper tooling for test management

[07:30:18.0000] <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

[07:30:36.0000] <darobin>
(to replace the current TF, which is painful to evolve to say the least)

[07:33:47.0000] <michel_v>
hello

[07:35:00.0000] <michel_v>
I just ran into an interesting problem with HTML5 and <input type="email"> with an email address on an IDN

[07:35:25.0000] <michel_v>
Chrome and Gecko wouldn't let us type the accents at all

[07:36:06.0000] <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?

[07:36:44.0000] <beverloo>
the expression browsers are advised to use is included in the spec:

[07:36:45.0000] <beverloo>
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address

[07:36:56.0000] <beverloo>
which indeed has a willful violation of rfc 5322

[07:39:02.0000] <michel_v>
ah, so the email address should use the xn-- notation

[07:40:35.0000] <michel_v>
thanks beverloo

[07:40:40.0000] <michel_v>
that's most unfortunate

[07:48:36.0000] <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

[07:49:10.0000] <michel_v>
zcorpan_: but then it should only do so on submit

[07:49:27.0000] <zcorpan_>
why?

[07:50:16.0000] <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

[07:50:22.0000] <michel_v>
instead of "chezmé"

[07:50:42.0000] <zcorpan_>
michel_v: the UI doesn't need to show the ascii form

[07:51:07.0000] <darobin>
zcorpan_: I think that's what michel_v was hinting at when he said "only do so on submit"

[07:51:09.0000] <michel_v>
ah yes. so you mean that browser implementations should behave like that, ok

[07:51:54.0000] <zcorpan_>
(there's also a DOM API which should use the ascii form)

[07:53:14.0000] <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

[07:53:40.0000] <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

[07:54:05.0000] <michel_v>
exactly

[07:54:09.0000] <zcorpan_>
k

[08:02:06.0000] <michel_v>
hmm. rectification: it does work in Gecko (firefox 15 at least)

[08:08:01.0000] <zcorpan_>
firefox doesn't seem to do the asciification in the dom api or when submitting

[08:08:31.0000] <zcorpan_>
opera does it for the after-@ part when submitting (but not for .value)

[08:09:01.0000] <zcorpan_>
chrome doesn't convert at all and doesn't allow non-ascii emails to be submitted

[08:12:01.0000] <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

[09:08:00.0000] <zcorpan_>
[tm]: dude, you had agreed to deliver!

[09:08:42.0000] <Hixie>
jgraham: did you file a bug on that?

[09:09:23.0000] <jgraham>
Hixie: YEs. No idea which bug though

[09:09:27.0000] <Hixie>
thanks

[09:09:34.0000] <Hixie>
just wanted to make sure it didn't get lost to irc

[09:15:53.0000] <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?

[09:17:52.0000] <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?

[09:18:04.0000] <Hixie>
(afk)

[09:18:16.0000] <JonathanNeal>
http://blog.whatwg.org/feed-autodiscovery

[09:18:52.0000] <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?

[09:20:34.0000] <zcorpan_>
Hixie: how are auto and 100 equivalent? https://www.w3.org/Bugs/Public/show_bug.cgi?id=16917

[09:24:34.0000] <dglazkov>
good morning, Whatwg!

[09:29:37.0000] <Hixie>
JonathanNeal: the ones that don't have the type="" aren't considered feeds

[09:29:55.0000] <Hixie>
JonathanNeal: see http://www.whatwg.org/specs/web-apps/current-work/#rel-alternate

[09:30:07.0000] <Hixie>
zcorpan_: when snaptolines is false, isn't it true?

[09:30:30.0000] <JonathanNeal>
Got it, thanks. Just trying to address some issues in diveintohtml5 git.

[09:31:33.0000] <JonathanNeal>
Is wrapping the type attribute value in single quotes still best practice? e.g: type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'?

[09:31:55.0000] <Hixie>
single quotes, or double quotes

[09:32:04.0000] <Hixie>
or no quotes if there's no spaces and stuff in the value

[09:32:05.0000] <Hixie>
:-)

[09:32:06.0000] <zcorpan_>
Hixie: i thought an invalid state would get rendered as if the line webvtt setting was absent, i.e. snapToLine = true; line = 'auto'

[09:32:45.0000] <Hixie>
zcorpan_: oh, hm, i think the way i wrote it i only ignore the line number maybe

[09:32:46.0000] <JonathanNeal>
Well, the value has double quotes inside.

[09:33:06.0000] <Hixie>
JonathanNeal: then yeah, single quotes is prettier. you can also you &quot; for the double quotes. this is for <source type> ?

[09:33:09.0000] <JonathanNeal>
Unless we can use single quotes for codecs='avc1..."

[09:33:19.0000] <JonathanNeal>
Yes, it's for source.

[09:33:27.0000] <Hixie>
i think that has to be double quotes, but you'd have to check the rfc

[09:33:33.0000] <zcorpan_>
Hixie: i'll reopen :-)

[09:33:40.0000] <Hixie>
zcorpan_: thanks

[09:33:48.0000] <JonathanNeal>
the rfc?

[09:33:48.0000] <Hixie>
zcorpan_: this is why lots of detail in bugs is good btw :-P

[09:33:57.0000] <Hixie>
JonathanNeal: for the codecs="" parameter

[09:34:26.0000] <jgraham>
Hixie: (Bug 18854 FWIW)

[09:36:09.0000] <JonathanNeal>
I'm sorry, Hixie. I don't know what that is. I tried finding it with Google and failed. Could you help me?

[09:38:08.0000] <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 :-)

[09:38:09.0000] <JonathanNeal>
I think this might be it? http://tools.ietf.org/html/rfc4281

[09:38:44.0000] <Hixie>
JonathanNeal: that sounds like the right number; should be a link to it from the relevant part of the spec

[09:38:50.0000] <Hixie>
zcorpan_: yeah, i know :-)

[09:38:54.0000] <Hixie>
zcorpan_: no worries

[09:39:09.0000] <Hixie>
zcorpan_: i just don't like yanking you around through my various mistakes :-)

[09:39:17.0000] <Hixie>
brb

[09:39:34.0000] <zcorpan_>
it's OK :-)

[09:45:55.0000] <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?

[09:47:49.0000] <JonathanNeal>
I guess it doesn't specify double quotes. In fact, it never specifies double quotes.

[10:01:26.0000] <jgraham>
Er, what the hell GEcko

[10:01:33.0000] <jgraham>
Write 3 tests, all pass

[10:01:48.0000] <jgraham>
Write a fourth test in the same page, first two tests now fail

[10:02:06.0000] <jgraham>
(this does not happen in other browsers)

[10:02:09.0000] <JonathanNeal>
But when I tested this in Opera, Firefox, Chrome, and Safari; single quotes failed, double quotes worked, and no quotes worked.

[10:02:32.0000] <JonathanNeal>
And I tested codecs which used a "."

[10:03:53.0000] <jgraham>
OK, so there seems to be a race condition

[10:04:25.0000] <jgraham>
But someone just started practising the drums, so I guess it is time to go home

[10:25:56.0000] <Hixie>
jgraham: that test is weird. the JS does run, but it's like the browser is ignoring the result.

[10:31:15.0000] <Hixie>
jgraham: maybe the .submit() is queued?

[10:31:58.0000] <Hixie>
hm, the script doesn't run in gecko or opera, actually

[10:32:24.0000] <Hixie>
that's easier to spec...

[10:32:27.0000] <Hixie>
what does IE do on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1760 ?

[10:39:13.0000] <say2joe>
IE doesn't support addEventListener… code breaks there in IE8

[10:39:30.0000] <say2joe>
Line 6

[10:39:32.0000] <Hixie>
IE still doesn't do addEventListener?

[10:39:33.0000] <Hixie>
jeez

[10:39:41.0000] <say2joe>
well, i'm testing in IE8

[10:39:42.0000] <Hixie>
(thanks anyway)

[10:39:48.0000] <Hixie>
ah, right

[10:39:52.0000] <Hixie>
i guess maybe IE9 does it?

[10:40:01.0000] <say2joe>
sure…. i've got 4 VMs for different IEs… let me know if you want another test.

[10:40:36.0000] <gsnedders>
Hixie: IE9 does

[10:40:47.0000] <Hixie>
i'm guessing the test still won't work in IE due to the data: URLs anyway

[10:40:58.0000] <Hixie>
i'll just have to fire up my own VMs instead of being lazy :-)

[10:41:08.0000] <Hixie>
or i'll just comment on the bug and have jgraham test it :-P

[10:43:07.0000] <say2joe>
Hixie: sorry … trouble with my VM. like gsnedders said… IE9 added support but the earlier ones make you attach

[10:43:29.0000] <say2joe>
@Hixie good idea… i just hung my Mac for a sec :)

[10:51:30.0000] <jgraham>
Hixie: I can't check IE until tomorrow

[10:52:22.0000] <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

[10:54:40.0000] <jgraham>
(I wouldn't trust alert for debuging in this case since browsers can be weird about alert around navigations)

[10:55:50.0000] <Hixie>
(http://korystamper.wordpress.com/2012/09/07/were-all-mad-here/ makes me feel a lot better about our own nutballs)

[10:55:55.0000] <Hixie>
jgraham: true

[10:56:16.0000] <Hixie>
jgraham: though since it's usually webkit that doesn't fire the alerts... :-)

[11:01:24.0000] <jgraham>
Actually I guess I lie

[11:01:36.0000] <jgraham>
The script not running at all seems more logical

[11:12:56.0000] <gsnedders>
> logical

[11:12:57.0000] <gsnedders>
> IE

[11:17:31.0000] <Hixie>
i think jgraham's main mistake is trying to find logic anywhere near the navigation algorithm

[11:17:53.0000] <gsnedders>
Oh, I heard enough rambling madness from him while I was in Lkpg a few weeks back. :)

[11:18:29.0000] <Hixie>
can someone explain to pillar that i can't work if she's lying in front of the keyboard being all cute

[11:19:01.0000] <gsnedders>
No. She's a cat. This makes that difficult.

[11:19:20.0000] <Hixie>
lol she just fell off the table trying to be even cuter

[11:19:46.0000] <gsnedders>
Girls are nothing but silliness!

[11:24:08.0000] <Hixie>
i don't think this is a gender thing. my boy cat is just as silly, if not more so

[11:25:23.0000] <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?

[11:25:34.0000] <Hixie>
sicking: or does the problem only occur if you have at least one directory at the top level?

[11:26:08.0000] <sicking>
Hixie: even dragging 1000 files can be slow since we have to stat them all to get their size

[11:26:22.0000] <Hixie>
ok, so this isn't really about directories per se

[11:26:25.0000] <Hixie>
interesting

[11:26:26.0000] <sicking>
Hixie: but it's less of a problem i think

[11:30:08.0000] <gsnedders>
Hixie: Sarcasm explains many things.

[11:34:36.0000] <annevk>
Hixie: have you filed that thread on Referer?

[11:34:49.0000] <Hixie>
filed? thread? what?

[11:34:56.0000] <annevk>
Hixie: because it requires changing the fetch algorithm; once that's done I can update XMLHttpRequest

[11:35:24.0000] <annevk>
Hixie: http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0750.html in particular

[11:37:24.0000] <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.

[11:38:41.0000] <Hixie>
annevk: i guess we can be more explicit, like with the origin

[11:39:23.0000] <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

[11:39:34.0000] <sicking>
err

[11:39:36.0000] <sicking>
Hixie: ^

[11:39:36.0000] <Hixie>
sicking: it's easy to tell what triggered the load. It's the algorithm that called "fetch".

[11:40:18.0000] <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)

[11:40:23.0000] <sicking>
Hixie: hmm.. i guess that makes sense

[11:40:23.0000] <Hixie>
sicking: (the intent is clear, i think)

[11:40:46.0000] <Hixie>
sicking: for APIs that call fetch, it's the API, and thus you use entry script

[11:40:47.0000] <sicking>
Hixie: though for CSS the referer isn't one of any Document. At least in Gecko

[11:41:05.0000] <Hixie>
sicking: yeah, for CSS maybe it's underdefined. Right now CSS doesn't call "fetch" at all.

[11:41:19.0000] <Hixie>
sicking: so arguably, it's not relevant here, and how networking works in CSS is an issue for www-style.

[11:41:36.0000] <Hixie>
sicking: though of course if they want to use "fetch" i'm sure anne and i would be happy to help

[11:41:47.0000] <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

[11:41:47.0000] <Hixie>
(eventually we plan to move "fetch" to its own spec and merge it with cors)

[11:42:08.0000] <annevk>
CSS must use fetch eventually

[11:42:39.0000] <Hixie>
sicking: "entry script" is used all over the place. i don't think that's likely to change.

[11:42:44.0000] <annevk>
http://fetch.spec.whatwg.org now has a note to that effect btw

[11:42:59.0000] <annevk>
yay productivity :p

[11:43:12.0000] <Hixie>
sicking: though if you have any specific cases where you think that should change, i'm happy to look at them

[11:43:22.0000] <Hixie>
annevk: btw when i created the domains i updated whatwg.org/specs

[11:43:45.0000] <annevk>
oh sweet

[11:43:56.0000] <annevk>
guess I should put a placeholder in url.spec.whatwg.org then

[11:43:59.0000] <Hixie>
:-)

[11:44:46.0000] <Hixie>
sicking: anyway, i guess we can be more explicit about the referrer

[11:44:58.0000] <Hixie>
sicking: but that's a lot of boilerplate text in a lot of places in the spec

[11:45:02.0000] <Hixie>
sicking: which is why i'd rather not

[11:45:12.0000] <sicking>
Hixie: ok

[11:45:51.0000] <sicking>
Hixie: i think it's mostly the "from APIs" that's wrong/ambigious right now

[11:47:04.0000] <annevk>
Hixie: could have a Document override

[11:47:16.0000] <Hixie>
yeah

[11:47:33.0000] <annevk>
that would be easy for XHR, dunno about window.location / Workers / ...

[11:48:13.0000] <annevk>
I wish we had less variables dangling around actually, not more

[11:49:17.0000] <jgraham>
Hixie: I don't particularly desire sanity from the navigation algorithm, just web compat and implementability

[11:50:10.0000] <jgraham>
(this particular case seems to have web-compat implications)

[11:52:02.0000] <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'

[11:52:55.0000] <jgraham>
( http://www.reddit.com/r/programming/comments/zq17h/its_opus_it_rocks_and_now_its_an_audio_codec/c675pgb )

[11:55:28.0000] <annevk>
it's not even proposed

[11:55:30.0000] <annevk>
it's just an RFC

[11:55:45.0000] <annevk>
oh wait, I guess that does make it proposed

[11:57:43.0000] <othermaciej>
IETF's process is still better than W3C's

[11:57:50.0000] <Hixie>
that is entirely not clear

[11:58:16.0000] <Hixie>
websockets went from ok to a disaster when it went from w3c to ietf

[11:58:25.0000] <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"

[11:58:32.0000] <Hixie>
no it doesn't

[11:58:47.0000] <Hixie>
look at XML

[11:58:53.0000] <othermaciej>
heh

[11:59:04.0000] <othermaciej>
ok, maybe it's that "unless the Director says otherwise"

[11:59:05.0000] <Hixie>
(or HTML, or SVG, or CSS)

[11:59:18.0000] <Hixie>
(or DOM)

[11:59:43.0000] <arunranga>
*sigh

[12:00:17.0000] <Hixie>
othermaciej: i don't think the director had any ability to stop HTML4 from changing, that was market forces.

[12:01:20.0000] <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

[12:01:58.0000] <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

[12:02:21.0000] <Hixie>
STD has theoretical credibility, but look at what has actually gone to STD

[12:02:50.0000] <Hixie>
e.g. URL syntax, whose specs are still a disaster

[12:03:39.0000] <annevk>
yeah, URLs are a good example as to why STD also fails (or maybe the exception, but I doubt it)

[12:03:53.0000] <jgraham>
I think IETF and W3C both have enough process problems to be getting on with

[12:04:05.0000] <Hixie>
most of the other STDs are outside my area of expertise so i don't know enough about them to comment

[12:04:09.0000] <Hixie>
but the URL one is clearly bogus

[12:05:24.0000] <annevk>
apparently ABNF is an STD... http://tools.ietf.org/html/std68

[12:05:48.0000] <annevk>
and utf-8 http://tools.ietf.org/html/std63

[12:06:08.0000] <Hixie>
utf-8 is pretty solid, though i think it went to std before defining error handling iirc

[12:06:30.0000] <annevk>
yeah, they don't define exact error handling

[12:06:47.0000] <annevk>
http://encoding.spec.whatwg.org does...

[12:07:16.0000] <annevk>
btw, in the course of 10 years, there's only 10 or so STDs

[12:08:01.0000] <annevk>
well, the first 60 took a little over five years...

[12:08:16.0000] <annevk>
I guess people figured out they were not worth the effort

[12:13:38.0000] <Hixie>
annevk: ok i need "cross-origin request" to be callable "using a document" (see new definiton of /fetch/ in a few minutes)

[12:15:45.0000] <Hixie>
sicking: ok, see if the spec makes sense now

[12:16:48.0000] <Hixie>
(i think technically i changed the referrer you use for workers...)

[12:17:07.0000] <Hixie>
(in the case of one iframe's script invoking a script in another iframe that then creates a worker)

[12:17:19.0000] <Hixie>
(the referrer is now the same as the document that owns the worker, not the first iframe's)

[12:19:22.0000] <a-ja>
Hixie" is this typo or am I confuzzled?

[12:19:27.0000] <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

[12:19:35.0000] <a-ja>
Vorbis audio alone in Ogg container<source src='audio.ogg' type='audio/ogg; codecs=vorbis'>

[12:19:51.0000] <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

[12:20:13.0000] <Hixie>
sicking: oh you want the referer of a worker to be the .js file of the worker??

[12:20:20.0000] <Hixie>
sicking: interesting!

[12:20:25.0000] <sicking>
Hixie: indeed

[12:20:28.0000] <a-ja>
Hixie: should file ext be .oga ?

[12:20:34.0000] <Hixie>
sicking: that's a normative change, i thought this was an editorial issue

[12:20:42.0000] <sicking>
Hixie: there's both

[12:20:55.0000] <Hixie>
a-ja: extensions are meaningless, it could be .mp3 without being any less accurate

[12:21:30.0000] <Hixie>
a-ja: but as it happens, for whatever reason, people generally use .ogg for vorbis audio files

[12:21:37.0000] <a-ja>
true enough....but think it's what's recommended

[12:21:48.0000] <a-ja>
.oga that is

[12:22:10.0000] <Hixie>
sicking: that's a much bigger change, ok. let me ponder it.

[12:22:36.0000] <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"

[12:22:53.0000] <Hixie>
sicking:  the text "When fetching resources in response to a call to an API" is gone

[12:22:54.0000] <sicking>
for some definition of "javascript API"

[12:23:14.0000] <Hixie>
(not in multipage yet since it's not yet checked in)

[12:23:19.0000] <sicking>
ah

[12:23:47.0000] <Hixie>
sicking: i guess this means that we should introduce a "the script's referrer" concept, and pass that to fetch...

[12:24:11.0000] <Hixie>
ugh

[12:24:27.0000] <Hixie>
annevk: disregard earlier request, this is gonna have to change

[12:25:19.0000] <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

[12:25:28.0000] <annevk>
(or in case of Workers something else)

[12:25:40.0000] <annevk>
which would indeed be a change

[12:25:55.0000] <Hixie>
this is a much more invasive change, yeah. the fetch algorithm is all based on having a document for the referrer.

[12:26:02.0000] <Hixie>
it seesm weird to me that a js file could be a referrer

[12:26:15.0000] <Hixie>
is the css file the referrer when you have an image in css?

[12:27:50.0000] <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)?

[12:28:05.0000] <annevk>
would make sense... (famous last words)

[12:28:14.0000] <Hixie>
sicking: scripts in workers have a "the script's document" just like all scripts, yes

[12:28:23.0000] <sicking>
Hixie: yes, the css file is the referrer when fetching @import css and backgrounds etc

[12:28:29.0000] <Hixie>
huh

[12:28:34.0000] <Hixie>
i had no idea

[12:28:35.0000] <Hixie>
ok

[12:28:55.0000] <Hixie>
can you file a bug on this? it's gonna need more work than the quick fix i thought this would be.

[12:29:02.0000] <sicking>
where?

[12:29:07.0000] <Hixie>
whatwg.org/newbug

[12:29:10.0000] <annevk>
Hixie: I think what we want is a referer override

[12:29:14.0000] <Hixie>
annevk: yeah

[12:29:16.0000] <annevk>
to either omit or set the referer to a value

[12:29:31.0000] <Hixie>
annevk: and then skip a bunch of the algorithm if there is one

[12:30:26.0000] <annevk>
and CSS could just define "CSS fetch" where they predefine the referer override and such

[12:30:50.0000] <Hixie>
yeah

[12:31:06.0000] <Hixie>
we're gonna need the cors algorithms to also pass this override through

[12:33:55.0000] <annevk>
sicking: please cc me on the bug

[12:35:13.0000] <a-ja>
scope style any concern here?

[12:35:19.0000] <a-ja>
scoped

[12:39:15.0000] <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

[12:39:36.0000] <TabAtkins>
Hixie: Let me know what I'd have to do regarding 'fetch' to make things sane, and I can make edits where appropriate.

[12:41:00.0000] <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.

[12:41:10.0000] <Hixie>
HTML spec's "fetch" algorithm, even

[12:42:51.0000] <Hixie>
oh, christ

[12:43:01.0000] <Hixie>
EventSource inside a srcdoc

[12:43:06.0000] <Hixie>
it needs to use the Document of the parent

[12:43:14.0000] <Hixie>
i don't want EventSource's fetch to know that

[12:43:30.0000] <Hixie>
annevk: we're gonna have to make this be either a URL or a Document

[12:44:44.0000] <annevk>
CSS needs URL

[12:45:01.0000] <Hixie>
yeah

[12:45:16.0000] <annevk>
and saying document's address rather than document is not too hard for the few times this matters

[12:45:27.0000] <annevk>
ooh, you're saying you want both

[12:45:31.0000] <Hixie>
yes

[12:45:37.0000] <annevk>
meh

[12:45:40.0000] <Hixie>
but i don't know which i even want when i'm in the EventSource constructor

[12:45:53.0000] <Hixie>
since EventSource can be in srcdoc, in iframe, or in worker

[12:46:01.0000] <annevk>
so can XMLHttpRequest

[12:46:04.0000] <Hixie>
er, s/in iframe/in top-level/

[12:46:04.0000] <Hixie>
right

[12:46:25.0000] <Hixie>
we need an abstract "referer concpt"

[12:46:27.0000] <Hixie>
concept

[12:46:33.0000] <Hixie>
that scripts can have

[12:46:39.0000] <Hixie>
which either points to their document or to a url

[12:46:56.0000] <Hixie>
except even that doesn't work for xhr

[12:47:02.0000] <Hixie>
since you need a special doc for that one, not the entry script

[12:47:05.0000] <Hixie>
lordy

[12:48:14.0000] <Hixie>
annevk: describe what you want for xhr again?

[12:48:26.0000] <annevk>
Worker URL inside workers

[12:48:50.0000] <annevk>
Associated document object's url for the normal context

[12:49:00.0000] <annevk>
I have not thought about the srcdoc case, didn't know it was special

[12:49:12.0000] <Hixie>
what document is the associated document object when in a worker?

[12:49:22.0000] <annevk>
there's none

[12:49:26.0000] <Hixie>
hm

[12:49:31.0000] <annevk>
the document is mostly used to determine the base URL and origin

[12:49:36.0000] <Hixie>
(srcdoc is special because otherwise you'll get about:srcdoc as the url)

[12:49:39.0000] <annevk>
and for workers they're set specifically

[12:49:46.0000] <Hixie>
aah, you already hard-code workers?

[12:49:57.0000] <annevk>
workers hardcodes XHR

[12:50:04.0000] <Hixie>
good to know

[12:50:14.0000] <annevk>
but XHR could have an associated XHR referer URL

[12:50:18.0000] <annevk>
that workers could set

[12:50:23.0000] <annevk>
and is used for fetching

[12:50:30.0000] <annevk>
that would basically be the same thing as we have now

[12:50:34.0000] <annevk>
for origin and the  base URL

[12:50:37.0000] <Hixie>
ok

[12:50:41.0000] <Hixie>
let me stew for a minute

[12:50:57.0000] <annevk>
i might stew until tomorrow :)

[12:51:09.0000] <annevk>
ttyl

[12:51:40.0000] <Hixie>
if i just define a "referrer source" concept that is either a doc or a url

[12:51:49.0000] <Hixie>
and xhr has a way for me to set the referrer source

[12:52:00.0000] <Hixie>
and scripts have a "the scripts' referrer source"

[13:01:35.0000] <Hixie>
sicking: workers whose urls are data: URLs. What Referer should we use? nothing? the data: URL?

[13:05:29.0000] <annevk>
already use no referer if there's tuple origin

[13:05:36.0000] <annevk>
if there's no tuple origin

[13:05:40.0000] <annevk>
so I think we should do that here too

[13:06:28.0000] <Hixie>
annevk: well, origin is different that url, for workers

[13:06:35.0000] <Hixie>
annevk: and for everyone else for that matter

[13:06:46.0000] <Hixie>
annevk: data: documents ofter have a real origin that's not data:

[13:06:52.0000] <Hixie>
often

[13:06:53.0000] <annevk>
fair enough

[13:07:26.0000] <annevk>
but leaking data URLs seems somewhat dangerous

[13:07:45.0000] <annevk>
although I guess workers cannot really make many interesting requests except with XMLHttpRequest

[13:08:05.0000] <annevk>
but it also seems like a huge bandwidth waste for little benefit

[13:08:53.0000] <Hixie>
yeah i am thinking we should just drop data: URL referrers

[13:17:11.0000] <sicking>
Hixie: good question

[13:17:27.0000] <sicking>
Hixie: the data: url is certainly the wrong answer

[13:17:50.0000] <sicking>
Hixie: gut instinct is the URL of the opening document.

[13:18:09.0000] <sicking>
Hixie: which unfortunately introduces a fair amount of complexity

[13:18:12.0000] <Hixie>
my gut instinct is the empty string

[13:18:22.0000] <Hixie>
but maybe i'm more intuitively scared of complexity :-P

[13:18:43.0000] <hober>
Hixie: re: your question earlier, i'll file a bug on your side once things settle down

[13:18:57.0000] <Hixie>
hober: ok, thanks.

[13:19:25.0000] <Hixie>
hober: (then we can have the fight all over again with a different result ;-) )

[13:20:21.0000] <hober>
heh

[13:48:25.0000] <jsbell>
Who let Ms2ger log off? grrrr.

[13:57:23.0000] <jgraham>
jsbell: Supposedly he went on holiday

[13:57:32.0000] <jgraham>
But we think he might just be rebooting

[13:57:50.0000] <jgraham>
(fsck takes a long time)

[13:58:29.0000] <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.

[16:06:34.0000] <Hixie>
heh, i hadn't thought about the referer for the actual script of the worker

[16:25:42.0000] <deane>
Hixie: Have you been involved with the mime-type registration(s) or has the w3c taken care of that area?

[16:34:14.0000] <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...

[16:34:16.0000] <deane>
...to do something at this update time and I just wondered if you had done it? Does that make sense? :)


2012-09-13
[18:52:29.0000] <othermaciej>
Hixie: do you know offhand which Web Apps WG specs were factored out of WHATWG's HTML spec?

[19:02:15.0000] <Hixie>
othermaciej: should be a list of them in the whatwg faq, but i can never recall the exact list

[19:03:12.0000] <othermaciej>
Hixie: is your "should be" meant to say "is" or "ought to be but is not"

[19:03:23.0000] <othermaciej>
or that you are uncertain?

[19:03:44.0000] <othermaciej>
ah, I found the list

[19:09:40.0000] <Hixie>
othermaciej: ought to, not sure if it's up to date

[23:10:00.0000] <annevk>
some stuff migrated back recently

[23:11:11.0000] <othermaciej>
what stuff?

[23:44:58.0000] <annevk>
othermaciej: http://www.whatwg.org/specs/

[23:46:42.0000] <othermaciej>
neat to see those things, I was specifically wondering about factored out pieces of the WHATWG's "HTML Living Standard" spec, and it seems like the things on that page are separate items

[23:46:58.0000] <othermaciej>
or are they intended to be folded into HTML LS?

[23:47:52.0000] <annevk>
ah no

[23:48:05.0000] <annevk>
it's just that XHR once was split out and moved to the W3C and now it's back

[23:48:16.0000] <annevk>
but yeah, not in the same place

[23:48:55.0000] <othermaciej>
was XHR once one of the big monolithic thing formerly known as Web Apps 1.0?

[23:49:08.0000] <annevk>
yeah

[23:49:21.0000] <othermaciej>
I'd forgotten that

[23:49:36.0000] <othermaciej>
do you remember when it got split?

[23:49:43.0000] <annevk>
2006

[23:50:09.0000] <othermaciej>
thanks

[00:51:07.0000] <smaug____>
/me wonders which ancient bugzilla version w3 uses

[00:53:57.0000] <jgraham>
Bugzilla 3.6.2

[00:54:48.0000] <annevk>
why are Safari's password dialogs synchronous?

[00:54:51.0000] <annevk>
so annoying

[00:55:11.0000] <jgraham>
You mean modal?

[00:55:30.0000] <annevk>
I suppose

[00:59:10.0000] <zcorpan>
deane: http://www.whatwg.org/specs/web-apps/current-work/multipage/iana.html#text/html

[01:05:24.0000] <[tm]>
if John Daggett comes back around, please ask him to re-ping me

[01:05:32.0000] <[tm]>
aka nattokirai

[01:05:57.0000] <[tm]>
I'm in Budapest and don't have IRC access from my PC

[01:19:45.0000] <zcorpan>
Hixie: the quirks mode spec is part of WHATCG. should it be listed under specs/ as well?

[01:28:02.0000] <annevk>
DOM Parsing should maybe be listed too

[01:28:15.0000] <annevk>
zcorpan: you want to put it on github and get quirks.spec.whatwg.org ?

[01:28:36.0000] <zcorpan>
Hixie: so we don't want to support dropping directories at all because it's a can of worms of security problems and various complexities

[01:29:35.0000] <zcorpan>
annevk: maybe, yeah. what's the procedure assuming i want to keep the CLA in sync?

[01:31:01.0000] <annevk>
dunno, I guess then you'd have to push to both

[01:31:36.0000] <zcorpan>
do you only maintain the *.spec.whatwg.org specs now?

[01:31:40.0000] <annevk>
yup

[01:31:52.0000] <zcorpan>
ok

[01:32:15.0000] <annevk>
I can't join the W3C as I don't agree with the Agreement

[01:32:22.0000] <annevk>
but I still like editing

[01:32:23.0000] <zcorpan>
right

[01:33:11.0000] <zcorpan>
you should have a license for your specs such that forking is allowed but only for a fee going straight to your pocket :-)

[01:33:38.0000] <odinho>
If the forking entity is a big standards organization that starts with W and ends with 3C.

[01:33:45.0000] <annevk>
I was actually thinking of something like that, to get some money, but I didn't really like that model

[01:34:15.0000] <annevk>
I'll stick to Public Domain and find some other source of income in due course

[01:34:16.0000] <zcorpan>
so what's your business plan?

[01:34:28.0000] <zcorpan>
ok

[01:34:31.0000] <zcorpan>
flipping burgers?

[01:34:52.0000] <annevk>
vacation :)

[01:35:08.0000] <SimonSapin>
annevk: what part of the Agreement don’t you agree with?

[01:35:29.0000] <annevk>
the part that basically gives the W3C exclusive right to my creative work

[01:35:39.0000] <smaug____>
oh, hmm, need to get AryehGregor and Ms2ger (where is he btw) actively merge Anne's whatwg DOM to W3 DOM

[01:35:52.0000] <annevk>
smaug____: vacation

[01:38:01.0000] <smaug____>
oh, vacation

[01:38:02.0000] <smaug____>
odd

[01:38:22.0000] <smaug____>
that is at least 2nd time this year

[01:38:31.0000] <smaug____>
he is getting old

[01:40:33.0000] <smaug____>
annevk: so do you have a list of non-w3c specs you're editing now?

[01:40:52.0000] <annevk>
smaug____: whatwg.org/specs

[01:42:21.0000] <smaug____>
annevk: have you discussed with Art or perhaps AryehGregor/Ms2ger how to coordinate spec editing

[01:42:38.0000] <annevk>
just Ms2ger

[01:42:51.0000] <smaug____>
and what did he say?

[01:42:53.0000] <annevk>
talked with Art too

[01:43:07.0000] <annevk>
smaug____: nothing much

[01:43:15.0000] <smaug____>
/me would like to just know which spec to follow

[01:43:18.0000] <annevk>
smaug____: this setup works for him too

[02:04:36.0000] <jgraham>
So, does anyone know what the rules are for sharing resources in a document?

[02:05:01.0000] <jgraham>
e.g. if I have <img src=a><img src=a><img src=a> it seems like a should be loaded only once

[02:05:50.0000] <jgraham>
but <script src=a></script><script src=a></script><script src=a></script> might be 3 loads?

[02:08:37.0000] <annevk>
they can all be shared

[02:11:36.0000] <annevk>
jgraham: fetch describes those "rules" fwiw

[02:16:33.0000] <jgraham>
annevk: Apparently (and I quote) "we know that scripts aren't shared"

[02:17:19.0000] <jgraham>
I haven't done the experiment, but if I trust bratell it seems like the rules are more complicated than "share everything"

[02:17:29.0000] <annevk>
jgraham: you mean they always force a new HTTP request somehow?

[02:17:44.0000] <jgraham>
Well I don't know about "always"

[02:17:52.0000] <jgraham>
But at least in some circumstances, yes

[02:19:39.0000] <jgraham>
(speculative theories included "cache until the load event", "never cache scripts", "only cache images" and "only cache resources that are referenced by an element currently in the document")

[02:20:06.0000] <jgraham>
But since this is observable with e.g. cookies (not to mention race conditions), it is a compat issue

[02:21:53.0000] <annevk>
well of course

[02:22:23.0000] <annevk>
sounds like fetch needs another flag

[02:22:28.0000] <annevk>
unless scripts is already special cased

[02:54:50.0000] <annevk>
Hixie: I think I fixed the Referer stuff now, review would be appreciated

[02:55:05.0000] <annevk>
sicking: ^^

[03:55:53.0000] <smaug____>
hmm, when did workers lose close event

[04:00:18.0000] <zcorpan>
close event?

[04:05:35.0000] <zcorpan>
sometime between http://www.w3.org/TR/2009/WD-workers-20090423/ and http://www.w3.org/TR/2009/WD-workers-20091029/

[04:10:36.0000] <zcorpan>
smaug____: http://lists.w3.org/Archives/Public/public-whatwg-archive/2009May/0406.html

[04:10:45.0000] <smaug____>
I wonder how many implementations still have it

[04:10:46.0000] <smaug____>
at least one

[04:11:15.0000] <smaug____>
/me hasn't really followed all the worker discussions

[04:11:49.0000] <smaug____>
at least not at that time

[04:11:55.0000] <smaug____>
zcorpan: thanks!

[04:12:16.0000] <zcorpan>
http://html5.org/r/3143

[04:12:29.0000] <zcorpan>
opera doesn't have it

[04:12:43.0000] <zcorpan>
i think it was removed before we started implementing

[04:14:14.0000] <zcorpan>
what's the status for shared workers in gecko?

[04:24:47.0000] <smaug____>
zcorpan: I guess someone is starting to implement them

[04:26:12.0000] <zcorpan>
ok

[04:56:23.0000] <cheron>
Why is there no possibility to communicate between all open tabs of my domain in HTML5?

[04:56:49.0000] <annevk>
you can via localStorage I think

[04:58:19.0000] <cheron>
annevk: yes, badoo.com does it like this, but there are no efforts to provide a seperate API for that?

[04:58:47.0000] <annevk>
come to think of it, I guess SharedWorker allows for it too

[04:59:59.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c27 spam?

[05:01:59.0000] <cheron>
so there is no need for an explicit api?

[05:03:27.0000] <darobin>
I have a dim memory of using postMessage for that, but I'm not sure it ever became true

[05:03:56.0000] <annevk>
cheron: depends on whether there are a) use cases and b) nothing to address a

[05:04:48.0000] <darobin>
I recall one of the use cases being on YouTube having only the tab with page visibility play the music, and automatically tell the others to mute

[05:10:08.0000] <annevk>
zcorpan: http://xhr.spec.whatwg.org/#same-origin-request-steps and scroll up a notch; that makes data URLs work the way you want right?

[05:10:17.0000] <annevk>
zcorpan: do you remember if there was a thread or bug report for that?

[05:10:44.0000] <annevk>
darobin: you can do that via sharedWorkers and localStorage

[05:11:04.0000] <annevk>
(I think)

[05:11:32.0000] <darobin>
annevk: yeah, as far as I know that's how most people do it — it's not something I've had a reason to try so far

[05:35:36.0000] <annevk>
hsivonen: http://wiki.whatwg.org/wiki/Talk:Main_Page third box might be for you?

[05:36:02.0000] <zcorpan>
annevk: how does that deal with redirects to not-same-origin?

[05:36:27.0000] <annevk>
zcorpan: this is before redirects

[05:37:37.0000] <annevk>
zcorpan: I attempted to support it the same way as is done for workers

[05:38:00.0000] <annevk>
zcorpan: by checking the moment you supply the URL, rather than checking throughout the request

[05:38:15.0000] <annevk>
(well not actually when you supply the URL, but close to it)

[05:38:36.0000] <zcorpan>
workers don't support cross-origin at all, right?

[05:38:54.0000] <annevk>
right

[05:39:08.0000] <annevk>
but data URLs go together with the initial same origin check

[05:39:28.0000] <annevk>
so if it's same-origin and then a redirect to a data URL, it will fail

[05:39:57.0000] <zcorpan>
<img> and <track> support first requesting a same-origin url and then redirecting to a not-same-origin url and have it switch to the cross-origin branch

[05:40:36.0000] <zcorpan>
hmm, i haven't thought much about redirects to data:

[05:40:39.0000] <annevk>
well sure, XHR does too

[05:40:50.0000] <annevk>
but that has nothing to do with data URL support

[05:41:01.0000] <annevk>
are you not commenting on the data URL part?

[05:43:37.0000] <zcorpan>
right, sorry, i was commenting about non-data-URL same-origin redirecting to not-same-origin

[05:45:45.0000] <zcorpan>
does "and the rules listed at the end of this section." take care of that?

[05:46:01.0000] <annevk>
http://xhr.spec.whatwg.org/#same-origin-request-event-rules does

[05:46:21.0000] <annevk>
just updated to take 308 into account

[05:47:45.0000] <zcorpan>
ah, ok

[05:48:45.0000] <zcorpan>
then it's good, assuming it doesn't have the same bugs i reported on "potentially cors-enabled fetch" in html :-)

[05:50:05.0000] <annevk>
would have to read those bugs to be sure

[05:50:25.0000] <annevk>
but if this still has major holes, I'd worry about user security

[05:50:54.0000] <zcorpan>
what do browsers do when redirecting to data: ?

[05:51:16.0000] <annevk>
I don't think all browsers support data: to begin with

[05:51:51.0000] <annevk>
you know what's an interesting edge case

[05:51:55.0000] <annevk>
a redirect to a blob URL

[05:54:13.0000] <zcorpan>
yeah. i hope that shouldn't work :-)

[05:58:05.0000] <annevk>
I think it should given the current definitions

[05:58:24.0000] <annevk>
unless maybe its oneTimeOnly or whatever it's called flag is set

[06:00:56.0000] <darobin>
there's no reason a redirect to a blob uri shouldn't work

[06:01:09.0000] <darobin>
though how useful exactly that's another question :)

[06:30:22.0000] <annevk>
anyone familiar with the domain-related code of URLs?

[06:30:48.0000] <annevk>
in particular what I'm wondering about is how much happens during parsing

[06:31:09.0000] <annevk>
and when (and if) invalid characters turn the URL invalid

[06:49:32.0000] <annevk>
TIL domain names use NFKC

[06:51:46.0000] <jgraham>
I hope you found the heritic and pushed them off a bridge

[06:53:33.0000] <annevk>
good memory!

[06:53:34.0000] <annevk>
http://code.google.com/p/plainrss/source/browse/trunk/Atom.NET/tests/feeds/pilgrim.xml

[06:54:13.0000] <annevk>
I wonder if he was looking at domain names too at the time

[06:56:39.0000] <annevk>
but I guess I should just say "this is how you find the host name, now apply ToASCII to it"

[07:01:17.0000] <annevk>
implementing IDNA ToASCII in JavaScript might be a bridge too far

[07:46:04.0000] <annevk>
setting .protocol is highly illogical

[07:46:11.0000] <annevk>
e.g. you have http://test/

[07:46:20.0000] <annevk>
now you set protocol to https

[07:46:35.0000] <annevk>
my URL library makes that https://test:80/

[07:46:49.0000] <annevk>
most browsers have https://test/

[07:47:02.0000] <annevk>
completely ignoring that they now also changed the port

[07:47:56.0000] <jgraham>
But I would totally expect the browser behaviour to work and yours to break

[07:47:56.0000] <annevk>
or if you change away from https the // is kept

[07:48:09.0000] <annevk>
but if you change from data to https, the // is added

[07:48:39.0000] <jgraham>
I mean if you have a specified port then it should be constant, but if you are using the default it should be the default on the new scheme too, I guess

[07:52:08.0000] <annevk>
it seems Chrome just sets port to the empty string if you give it the default port

[07:52:16.0000] <annevk>
that certainly explains the serialization

[07:53:13.0000] <annevk>
Gecko does the same

[07:53:18.0000] <annevk>
HTML of course does not define this

[07:53:24.0000] <annevk>
well "of course"

[07:53:44.0000] <annevk>
sorry Hixie but the URL decomposition attributes are poorly done

[07:55:10.0000] <smaug____>
Hmm, webidl parser claims that void observe(Node target, MutationObserverInit options); isn't right

[07:55:16.0000] <smaug____>
that the latter parameter should be optional

[07:56:17.0000] <annevk>
you don't have to mark it optional for it to be optional I think

[07:56:26.0000] <annevk>
heycam|away: ?

[08:01:55.0000] <Hixie>
zcorpan: happy to add anything you want to the specs list

[08:03:34.0000] <Hixie>
jgraham: <img> is especially magical regarding duplicate resource loads; beyond that there's just HTTP caching and coalescing of multiple simultaneous requests. If there's a compat reason not to coalesce, file a bug.

[08:03:50.0000] <Hixie>
annevk: link to xhr/cors updates?

[08:04:55.0000] <jgraham>
Hixie: "especially magical" doesn't sound terribly well defined. Nor does "coalescing of multiple simultaneous requests", really

[08:05:23.0000] <Hixie>
annevk: url decomposition is a bit of a mess, but is it normatively ok?

[08:05:35.0000] <annevk>
Hixie: https://github.com/whatwg/xhr/commit/69f790f185aaf611a138742362dda55c1a3f7da7 and https://github.com/whatwg/fetch/commit/8d8fbd9e36b725e11afd679c9c0d8fe8ffced8bd

[08:05:37.0000] <Hixie>
jgraham: they're both quite well defined

[08:05:52.0000] <Hixie>
jgraham: insofar as they can be. <img> in particular.

[08:06:01.0000] <annevk>
Hixie: no, e.g. setting .port to 80 for "http://test/" should make it the empty string

[08:06:21.0000] <Hixie>
annevk: file bugs

[08:06:32.0000] <jgraham>
Hixie: In HTML?

[08:07:17.0000] <annevk>
Hixie: my plan is to obsolete you in the next few months

[08:07:27.0000] <Hixie>
jgraham: yes

[08:07:29.0000] <Hixie>
annevk: that wfm

[08:07:31.0000] <annevk>
Hixie: maybe that's optimistic, but in due course

[08:08:21.0000] <jgraham>
Hixie: Interesting

[08:08:55.0000] <Hixie>
annevk: xhr doesn't look like it has a <dfn> for XMLHttpRequest referrer source in that diff

[08:09:14.0000] <Hixie>
annevk: otherwise seems ok, i'll have to update my cors calls

[08:09:30.0000] <annevk>
Hixie: ah sorry, https://github.com/whatwg/xhr/commit/91670112d639e3f5f1899efd188d9e0425963036

[08:09:39.0000] <annevk>
made two changes to XHR

[08:10:45.0000] <Hixie>
lgtm

[08:13:19.0000] <Hixie>
ok updated html

[08:20:27.0000] <annevk>
Hixie: at some point you should prolly update the reference section to point to xhr.spec.whatwg.org etc.

[08:20:50.0000] <Hixie>
file a bug

[08:23:05.0000] <annevk>
fair enough

[08:31:27.0000] <Hixie>
darobin: while merging the last few checkins you've made, i've ended up using different prose (for different reasons each time; i tried to document them in detail in the checkin comments). Is this something silvia will end up tracking automatically or should I be bringing this up to someone's attention or is it something where we don't care?

[08:32:59.0000] <darobin>
Hixie: I think that ideally the prose should be the same unless there's an overwhelming reason not to do so

[08:33:53.0000] <darobin>
normally I think Silvia will track it (or whoever looks at deltas later), but pointers to the differences are appreciated (especially if they can avoid further difference in future)

[08:34:11.0000] <Hixie>
k

[08:35:14.0000] <Hixie>
darobin: r7344, r7337, r7336, and r7334 are the main ones that map to things you've changed recently, i think

[08:35:37.0000] <Hixie>
darobin: (i've been trying to make sure i fix the bugs you fix around the same time)

[08:39:45.0000] <darobin>
Hixie: heh, for r7344 you have the exact text I had before I decided I preferred reordering the list differently :)

[08:40:40.0000] <Hixie>
heh

[08:40:52.0000] <Hixie>
your current text reads like getting and setting always throws, and methods throw when they don't apply

[08:41:08.0000] <Hixie>
(and starts with "On" while the next paragraph uses "For", which reads weird)

[08:41:44.0000] <darobin>
we don't parse commas in the same way :)

[08:41:46.0000] <darobin>
but noted

[08:42:04.0000] <Hixie>
the problem isn't whether you or i parse commas in the same way, it's how will a hostile reader read it :-)

[08:42:15.0000] <Hixie>
that's why the paragraph was being rewritten in the first place, after all :-)

[08:42:42.0000] <darobin>
sure, it just looks like my hostile reader came from Oxford

[08:42:57.0000] <darobin>
that would explain the smell of tweed on my right shoulder

[08:43:37.0000] <darobin>
thanks for the heads up, I won't copy those change directly but will rather cherry pick them downstream

[08:44:55.0000] <Hixie>
(oh, also r7331)

[08:44:55.0000] <Hixie>
k

[08:48:13.0000] <darobin>
Hixie: oh yeah, I need to return to that oen

[08:48:46.0000] <darobin>
it raises a red flag for me that the new supposedly better constructor would require a helper function in simple spec example code

[08:49:18.0000] <darobin>
which is why I assumed the original example must have been wrong :)

[08:49:24.0000] <Hixie>
there's a reason i had originally designed it the way i had...

[08:49:38.0000] <Hixie>
:-P

[08:49:41.0000] <darobin>
heh

[08:50:14.0000] <Hixie>
depends what the most common use case is going to be: adding subtitles, or adding metadata

[08:50:15.0000] <darobin>
I can't disagree that having too many positional parameters is painful though

[08:50:25.0000] <darobin>
this strikes me as a case for a dictionary...

[08:51:24.0000] <darobin>
I'll scare up a proposal in the bug

[08:51:29.0000] <darobin>
(which was REOP)

[09:05:55.0000] <Hixie>
darobin: i dunno that a dictionary makes much sense here. all the values are mutable now, and if the common case is subtitles, you'll rarely need to change them anyway.

[09:07:22.0000] <Hixie>
darobin: (fwiw, i usually try to have the examples in the spec show both the easy ways to use the APIs and the more esoteric ways, so making the API support the examples in the spec specifically is probably not a winning strategy :-) )

[09:07:28.0000] <darobin>
yeah, I was just wondering whether the various uses would justify a dictionary, versus changing the example to use subtitles

[09:07:58.0000] <Hixie>
we can certainly add more examples

[09:08:03.0000] <Hixie>
but that's a different issue entirely

[09:08:12.0000] <darobin>
yeah, I'm definitely not trying to design against the example, but I think it makes sense to exemplify the common case

[09:08:28.0000] <darobin>
I know that's the first thing I look at when coding

[09:11:29.0000] <annevk>
heh fun

[09:11:40.0000] <annevk>
Gecko's URL thing is quite broken

[09:11:48.0000] <annevk>
if you set hostname to "x#"

[09:11:56.0000] <annevk>
well host

[09:12:04.0000] <annevk>
you get http://x/#/

[09:12:22.0000] <annevk>
or if you set it to "\n" it puts part of the path as the host

[09:12:54.0000] <odinho_>
Heh, good thing people don't do that then :]

[09:13:39.0000] <Hixie>
i love how the url parsing stuff is so complicated that each time someone tries to spec it, they learn more quirks than the previous person

[09:14:01.0000] <Hixie>
and then the next person comes along, sees all the quirks so far, tests all of those again, then tests a few more things, finds more quirks, and lather rinse repeat

[09:14:43.0000] <annevk>
for something fundamental to the platform, it's quite complicated

[09:15:18.0000] <annevk>
my library is now 350 lines (also handles the decomposition attributes)

[09:15:52.0000] <annevk>
once it's a bit more polished I'll put it online for review and then turn it into a proper spec

[09:17:23.0000] <odinho>
annevk: With a small eye towards some potential simplification I hope? :P

[09:22:53.0000] <annevk>
single-pass parsing was my goal

[09:23:08.0000] <annevk>
some stuff is simplified too I think

[09:23:25.0000] <annevk>
because they're no longer constrained by silly syntax constructs from the IETF

[09:23:36.0000] <annevk>
hmm

[09:24:04.0000] <annevk>
just realized that apart from the IDNA ToASCII thing, there's also figuring out whether it's a host or IP address

[09:24:25.0000] <annevk>
browsers do weird things with normalizing IP addresses too I noticed

[09:43:24.0000] <tantek>
good morning #whatwg. perhaps a bit of a reach, but any others here in Portland this weekend for XOXO festival?

[10:06:01.0000] <annevk>
oh heh

[10:06:14.0000] <annevk>
IP address syntax notation has a versioning strategy

[10:07:00.0000] <annevk>
hopefully that's never going to be used

[10:08:08.0000] <zcorpan>
annevk: what? for ipv7?

[10:08:31.0000] <annevk>
read and weep http://tools.ietf.org/html/rfc3986#section-3.2.2

[10:09:30.0000] <Hixie>
wow, that's hard core

[10:18:53.0000] <zcorpan>
annevk: do browsers support the versioning syntax?

[10:19:48.0000] <zcorpan>
oh i see they aren't expected to

[10:21:46.0000] <zcorpan>
well then it doesn't need to be specced, it can wait until ipv7 comes along and see if it needs a flag

[10:24:08.0000] <zcorpan>
Hixie: ok. can you add it? :-) url is http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.html

[10:25:44.0000] <Hixie>
i'm running out the door, drop me a mail?

[10:25:46.0000] <Hixie>
sorry

[10:26:04.0000] <zcorpan>
sure

[10:56:12.0000] <Famic>
hi

[11:14:58.0000] <zcorpan>
Famic: hi

[12:06:42.0000] <Hixie>
sicking: we think we fixed your referrer issue

[12:07:48.0000] <Hixie>
sicking: re dnd of directories, opera (zcorpan, i think) says they don't want to support directories at all. you said mozilla does want to do directories, right? in addition to handling thousands of files in one directory?

[12:08:50.0000] <zcorpan>
here's why opera doesn't want to support it (longish paste, sorry):

[12:08:57.0000] <zcorpan>
What happens when the directory structure has a loop? on unix you can have hard links that are undetectable, and can create infinite loops of various kinds.

[12:08:58.0000] <zcorpan>
 

[12:08:58.0000] <zcorpan>
What happens when the user drops / (root directory) or c:\ ?

[12:08:59.0000] <zcorpan>
 

[12:09:01.0000] <zcorpan>
What happens when the directories contain ".." links to the parent - what permission was granted (eg. read the parent folder contents)?

[12:09:03.0000] <zcorpan>
 

[12:09:05.0000] <zcorpan>
What should happen with path names if the user drops /home/ or c:\users\ - should the Web site be given a directory structure which then exposes the usernames and profile paths (which the user would *never* want to expose, but wouldn't realise they are exposing)?

[12:09:07.0000] <zcorpan>
 

[12:09:09.0000] <zcorpan>
What happens if two folders contain the same file name (assuming that you expose just the files instead of letting the script browse folder structure)?

[12:09:11.0000] <zcorpan>
 

[12:09:13.0000] <zcorpan>
This is hell, and I just don't want to go there.

[12:09:34.0000] <zcorpan>
(gotta go)

[14:05:19.0000] <sicking>
Hixie: yes, we want to do directories with thousands of files in them

[14:06:20.0000] <Hixie>
sicking: i mean, you want to expose a hierarchy, in addition to supporting the user dragging a ton of files flat

[14:07:25.0000] <sicking>
Hixie: yes, i want to expose the heirarcy, but it doesn't have to be throught the ability to traverse a directory tree. Though it's an advantage if that can be done as well, though much lower priority

[14:07:59.0000] <sicking>
Hixie: i.e. exposing a list of files with names like "foo/bar/baz.doc" is enough to expose hierarchy

[14:08:21.0000] <Hixie>
by "hierarchy", i mean specifically not giving everything in one flat synchronous list

[14:13:52.0000] <sicking>
well

[14:13:57.0000] <sicking>
a flat list could be ok

[14:14:32.0000] <sicking>
as long as we can provide some sort of useful progress events as we are "loading" that list (which is hard since we can't give a percentage since we don't know how many files total)

[14:15:12.0000] <sicking>
oh, but i guess that if you mean "synchronous" you mean synchronously from the "drop" event, then that's not good, yes

[14:17:05.0000] <jgraham>
What are your solutions for the security/privacy issues that zcorpan mentioned?

[14:17:29.0000] <Hixie>
i have no solution

[14:17:41.0000] <Hixie>
fwiw

[14:18:08.0000] <sicking>
neither do I

[14:18:18.0000] <jgraham>
That seems like a problem :(

[14:18:26.0000] <Hixie>
problems, that i have

[14:18:27.0000] <sicking>
but i don't know what the security/privacy issue that zcorpan mentioned is

[14:19:18.0000] <jgraham>
sicking: You just assume you don't have a solution to any security / privacy issues? :)

[14:19:39.0000] <Hixie>
jgraham: it's a pretty good starting assumption :-)

[14:19:46.0000] <jgraham>
sicking: http://krijnhoetmer.nl/irc-logs/whatwg/20120913#l-1154

[14:19:55.0000] <sicking>
"<sicking> *neither* do I" (emphasis added by me)

[14:20:09.0000] <sicking>
oh

[14:20:13.0000] <sicking>
you said "don't" :)

[14:21:23.0000] <sicking>
jgraham: good questions indeed

[14:21:46.0000] <Hixie>
the loop one is particularly bad and pretty much means we can't do a flattening solution

[14:21:53.0000] <Hixie>
but that's really just pushing the problem into the script

[14:21:58.0000] <jgraham>
Yeah, I should find out who came up with the list :)

[14:22:21.0000] <sicking>
jgraham: i'd be inclined to simply not follow links

[14:22:34.0000] <sicking>
jgraham: seems like that would still retain the majority of use cases

[14:22:56.0000] <jgraham>
sicking: Does that work for hard links?

[14:23:16.0000] <sicking>
jgraham: you keep having all these good questions :)

[14:25:07.0000] <Hixie>
you can't not follow links

[14:25:19.0000] <Hixie>
they're indistingushable from directories :-)

[14:26:02.0000] <jgraham>
I think I ought to sleep now

[14:39:30.0000] <Hixie>
sicking: can you elaborate on why you don't want to use the filesystem api for this? do you just not think we should have that api at all?

[15:09:25.0000] <Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c27 o-O

[15:10:11.0000] <Hixie>
darobin: you're fixing appcache?

[15:11:53.0000] <darobin>
Hixie: the discussion is open, no decision has been made yet

[15:12:44.0000] <darobin>
right now I'm mostly listening to the Fixing AppCache people

[15:13:00.0000] <Hixie>
there are Fixing AppCache people?

[15:13:43.0000] <darobin>
yeah there were two meetings, one in London, another in Mountain View with several implementers and die-hard users of appcache

[15:14:00.0000] <Hixie>
ah yes, i have heard of those

[15:14:14.0000] <Hixie>
none of the feedback from those meetings seems to ever make it to the bug database

[15:14:19.0000] <darobin>
by that I mean folks like Facebook, Pearson, Web Outlook, etc.

[15:14:22.0000] <Hixie>
at least not in actionable form (use cases)

[15:15:02.0000] <darobin>
no, the design is too much up in the air for that at this point

[15:15:14.0000] <Hixie>
what i have heard is mostly going to result in incremental changes, though, so i doubt it'll affect https://www.w3.org/Bugs/Public/show_bug.cgi?id=18272

[15:15:32.0000] <Hixie>
or https://www.w3.org/Bugs/Public/show_bug.cgi?id=18280

[15:15:53.0000] <darobin>
maybe, maybe not

[15:16:04.0000] <Hixie>
pretty sure not :-)

[15:16:35.0000] <darobin>
I've heard both

[15:16:52.0000] <darobin>
I'm essentially moving those bugs to the later bucket until I hear something more concrete

[15:17:22.0000] <Hixie>
http://goo.gl/VrQNF is the concrete list of what is going to change

[15:17:28.0000] <darobin>
if it turns out to be incremental, I can look at them then, if not, then I'll be glad I didn't dig any deeper

[15:19:54.0000] <darobin>
Hixie: last I heard there was still disagreement between implementers, so I just want to make sure all the Ts are crossed

[15:20:21.0000] <Hixie>
if they don't participate in the discussions, their disagreements aren't going to have much effect on the spec :-)

[15:21:16.0000] <darobin>
I think they plan to :)

[15:21:27.0000] <darobin>
anyway, it's bedtime in this TZ :) nn!

[15:22:41.0000] <othermaciej>
Hixie, darobin: is there any written down and publicly viewable form of all this feedback?

[15:23:06.0000] <othermaciej>
as an implementor of AppCache that I think has not been party to these discussions, I am interested

[15:23:29.0000] <othermaciej>
darobin: you should really move deferred bugs to another component instead of RESOLVED LATER btw

[15:58:31.0000] <smaug____>
huh, ringmark is a buggy test

[15:59:00.0000] <smaug____>
it is sad that people rely on such tests

[15:59:17.0000] <smaug____>
and also things like html5test

[15:59:40.0000] <othermaciej>
smaug____: what is buggy about ring mark?

[16:00:12.0000] <othermaciej>
smaug____: html5test is unfortunately becoming a big deal in mobile browser marketing, I wonder if it would be useful to give feedback to the test creators

[16:00:22.0000] <smaug____>
it is testing stuff which explicitly should not be there

[16:00:25.0000] <smaug____>
like touch events

[16:00:32.0000] <othermaciej>
smaug____: and for ring mark in particular, I have the ability to contact the people at Facebook who made it directly

[16:00:39.0000] <smaug____>
they should not be there on non-touch platforms

[16:01:01.0000] <othermaciej>
so you think its testing for touch events should be conditional?

[16:01:02.0000] <smaug____>
I've filed bugs on html5test to remove invalid tests

[16:01:07.0000] <othermaciej>
or it should not test that at all?

[16:01:08.0000] <smaug____>
and add some possibly useful tests

[16:01:23.0000] <othermaciej>
how does one file bugs on html5test?

[16:01:29.0000] <smaug____>
github

[16:01:33.0000] <othermaciej>
I'd like to suggest that they move FileSystem API to bonus points

[16:01:49.0000] <smaug____>
there is a link somewhere in html5test to github

[16:01:57.0000] <othermaciej>
since there exist popular platforms today with no user-visible filesystem

[16:02:06.0000] <smaug____>
othermaciej: there are already couple of bugs open about Filesystem api

[16:02:44.0000] <smaug____>
(btw, I think it should be discussed during TPAC what to do with filesystem api. I'd like to drop it)

[16:03:02.0000] <smaug____>
othermaciej: https://github.com/NielsLeenheer/html5test/issues/

[16:03:12.0000] <othermaciej>
perhaps it should be moved to the new WG proposed for system app APIs

[16:03:34.0000] <smaug____>
well, I think we shouldn't have the proposed filesystem api at all ;)

[16:03:40.0000] <smaug____>
but something better

[16:04:41.0000] <zewt>
how?

[16:04:48.0000] <smaug____>
what how?

[16:04:50.0000] <othermaciej>
I would be in favor of dropping it

[16:04:52.0000] <zewt>
better how?

[16:05:04.0000] <zewt>
the spec needs a lot of reworking, but the API is generally fine

[16:05:09.0000] <smaug____>
see comment in webapps wg mailing list

[16:05:13.0000] <smaug____>
comments

[16:05:30.0000] <zewt>
could you be more specific? heh

[16:05:35.0000] <smaug____>
othermaciej: I think everybody else but google is favor of dropping it

[16:05:39.0000] <zewt>
hasn't been anything about fsapi in quite a while

[16:05:54.0000] <smaug____>
zewt: because no one really cares about it :)

[16:05:57.0000] <zewt>
it's a pretty important API to bridge the current gulf between web apps and native anything

[16:06:05.0000] <othermaciej>
if only Google wants to implement it, then it probably should not be a standards-track document

[16:06:13.0000] <othermaciej>
WebSQL got dropped for less...

[16:06:21.0000] <smaug____>
/me tries to figure out where performance.memory is defined

[16:06:46.0000] <smaug____>
well, WebSQL was odd case, but rather obvious that it should be dropped

[16:06:56.0000] <zewt>
(debatable)

[16:07:06.0000] <zewt>
(but not really comparable)

[16:07:26.0000] <smaug____>
othermaciej: do you know if I can file bugs on ringmark somewhere?

[16:07:33.0000] <smaug____>
or just send emails to fb?

[16:07:58.0000] <othermaciej>
smaug____: I do not know, but I can personally send email to fb

[16:08:25.0000] <othermaciej>
smaug____: so if you mail me bugs I can pass them along, or I can ask about a way to file bugs

[16:08:25.0000] <othermaciej>
I'm on a plane right now so my mail and web are super slow

[16:08:51.0000] <smaug____>
/me could send emails to schrep but that is probably not the right level of management to send emails to

[16:09:27.0000] <smaug____>
is toby ever here

[16:09:35.0000] <smaug____>
from fb

[16:09:46.0000] <othermaciej>
http://rng.io/about/

[16:09:53.0000] <othermaciej>
gives info that might be relevant to sending feedback

[16:13:50.0000] <othermaciej>
chasing links, it looks like the only bug tracker is the Core Mobile Web Platform CG's issue tracker

[16:17:48.0000] <smaug____>
what is this performance.memory...

[16:20:56.0000] <sicking>
Hixie: i definitely think using *a* filesystem API for this might be a good solution

[16:21:26.0000] <sicking>
Hixie: i think the current google filesystem API is way more complex than what's needed for a filesystem API

[16:21:51.0000] <smaug____>
sicking: what that for Hixie or for zewt

[16:22:01.0000] <sicking>
smaug____: for hixie

[16:22:05.0000] <smaug____>
I agree *a* filesystem API is needed

[16:22:17.0000] <sicking>
<Hixie>	sicking: can you elaborate on why you don't want to use the filesystem api for this? do you just not think we should have that api at all?

[16:22:43.0000] <othermaciej>
I'm not sure I agree that *a* filesystem API is necessarily needed, at least for all platforms

[16:23:02.0000] <smaug____>
othermaciej: that is possible

[16:23:07.0000] <othermaciej>
for platforms that don't expose a hierarchical filesystem to the user, it doesn't really make sense to have an API that works like that

[16:23:10.0000] <sicking>
othermaciej: in general, or for dragndrop?

[16:23:12.0000] <smaug____>
yup

[16:23:41.0000] <smaug____>
/me still wonders what on earth is performance.memory

[16:24:01.0000] <zewt>
othermaciej: if they don't have any concept of that, then they wouldn't have any concept of "dragging in a directory" either

[16:24:02.0000] <othermaciej>
sicking: we had another conversation about filesystem API just now, I missed the original one with Hixie that I guess involved DnD

[16:24:16.0000] <othermaciej>
sicking: but I also don't think Drag & Drop makes sense on all platforms

[16:24:17.0000] <sicking>
othermaciej: i missed the later one :)

[16:24:22.0000] <othermaciej>
for instance, iOS has no drag * drop

[16:24:41.0000] <othermaciej>
and I do not think it even makes sense on a touch platform

[16:25:06.0000] <sicking>
othermaciej: agreed. I think that would simply result in not ever firing dragndrop events on iOS. Just like we'd never fire them in OSX if noone drops something

[16:25:57.0000] <zewt>
there are probably a bunch of things that I'd clean up in FS-API, and possibly some trimming, but it seems like the right direction

[16:25:58.0000] <othermaciej>
sicking: do you think it's appropriate to have all the interfaces relevant to DnD but just never invoke them on a platform with no DnD?

[16:26:00.0000] <othermaciej>
sicking: or would it be better to not expose the interfaces?

[16:26:21.0000] <othermaciej>
for FS API, I think it would be nutty to have all the interface objects but never let them be used in any way

[16:26:57.0000] <sicking>
othermaciej: oh. I suspect it makes sense that whatever interfaces exist for DND wouldn't exist on platforms that don't have DnD

[16:27:17.0000] <sicking>
othermaciej: we're mostly talking interface objects? Or is there more DnD API?

[16:27:19.0000] <zewt>
(eg. getMetadata seems unnecessary--it's redundant with simply creating a File)

[16:27:29.0000] <miketaylr>
smaug____: rwaldron (who isn't here right now) develops ringmark, you could email him rick⊙bc

[16:28:12.0000] <smaug____>
miketaylr: thanks

[16:28:28.0000] <othermaciej>
sicking: perhaps I should file a bug, because the spec is not very clear about what interfaces should be present or what the behavior should be on platforms with no DnD

[16:28:33.0000] <miketaylr>
np

[16:28:50.0000] <sicking>
othermaciej: On filesystems, I suspect what we need to do is to expose sandboxed filesystems to webapps. Similar to what chrome does. But it wouldn't be exposing a user-visible directory structure. It might not even be a real filesystem (chrome's FS API isn't actually backed by a filesystem)

[16:29:16.0000] <sicking>
othermaciej: but I don't like chromes FS API. I think we should propose a *much* simpler one

[16:29:21.0000] <othermaciej>
sicking: what's the benefit of making it look like a filesystem if it is not even backed by a filesystem?

[16:29:28.0000] <sicking>
othermaciej: the storage policy would be the same as what's used for WebSQL/IndexedDB

[16:30:30.0000] <sicking>
othermaciej: Mostly there are two advantages: 1. Many developers are very used to filesystems. Even for games that want to simply download and cache resources, saving them in a filesystem-like API is very natural for them

[16:30:38.0000] <othermaciej>
WebSQL and IndexedDB can store binary blobs just fine...

[16:31:10.0000] <othermaciej>
is it too complicated or confusing to use IndexedDB (let's say) for such a use case?

[16:31:54.0000] <zewt>
do IDB implementations store blobs out-of-line, eg. as their own file and not as a blob in the middle of a db file?

[16:31:57.0000] <sicking>
othermaciej: 2. URLs are hierarchical. Storing the files in a heirarchical storage area allows reading from that area directly using URLs

[16:32:40.0000] <sicking>
othermaciej: *anything* more complex than "just a filesystem" is "too complicated"

[16:32:44.0000] <othermaciej>
so blob urls don't cut it?

[16:33:03.0000] <sicking>
othermaciej: blob urls have to be generated on each run

[16:33:15.0000] <othermaciej>
filesystems are pretty complicated

[16:33:17.0000] <jsbell>
zewt: Chrome doesn't handle Blobs in IDB yet. :(

[16:33:19.0000] <sicking>
othermaciej: the nice thing about a filesystem url is that you can just read from the database directly

[16:33:23.0000] <sicking>
othermaciej: they don't need to be

[16:34:12.0000] <othermaciej>
hierarchical by-name read-write store for opaque binary objects seems like an ok concept

[16:34:12.0000] <othermaciej>
but I am sad at how many storage APIs the platform has already

[16:34:30.0000] <zewt>
i'm wary of database-backed systems for storing large data (eg. gigabytes of dynamically-patched game data); multiple layers of fragmentation, etc (but if IDB implementations mature and it's proven to "just work" then I'd probably get over that)

[16:34:31.0000] <sicking>
othermaciej: i haven't worried too much about filesystem because i feel the same way, "it's just syntax sugar on top of a database. use a library over IDB/websql"

[16:34:34.0000] <othermaciej>
does filesystem API give you URLs that persist from run to run?

[16:34:45.0000] <sicking>
othermaciej: i still think that's mostly true. But I think a filesystem is generally worth it

[16:34:49.0000] <sicking>
othermaciej: it does

[16:35:15.0000] <sicking>
othermaciej: filesystem://http://mysite.com/path/in/filesystem/to/file.jpg

[16:35:23.0000] <othermaciej>
is IndexedDB incapable of providing persistent URLs or a hierarchical namespace?

[16:35:31.0000] <zewt>
i don't think persistent URLs are very important, though, since it's easy to go path -> blob -> createObjectURL (for a nonpersistent blob)

[16:35:31.0000] <othermaciej>
I am not very familiar with it

[16:35:35.0000] <sicking>
othermaciej: incapable is a strong word

[16:35:51.0000] <othermaciej>
I guess it's a two-level question:

[16:35:52.0000] <sicking>
othermaciej: but keys can be anything, not just strings

[16:35:59.0000] <othermaciej>
(1) is it unable to do it in the current drafts?

[16:36:12.0000] <othermaciej>
(2) is it conceptually/technologically hard to add such features?

[16:36:13.0000] <jsbell>
The transaction overhead might scare off some developers. On the other hand, the transaction overhead is what you really need for multiple tabs from the same origin that are partying on the same data, so...

[16:36:51.0000] <othermaciej>
I don't really see how you can sanely offer read-write stream access w/o some form of transactional layer

[16:36:54.0000] <sicking>
othermaciej: (1) it's not possible currently (2) it's possible, but it won't be terribly clean

[16:37:32.0000] <sicking>
othermaciej: each "add this file to the filesystem" would be a transaction. Which makes it mostly invisible

[16:37:48.0000] <jsbell>
"Proof by example": http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api

[16:38:08.0000] <zewt>
jsbell: transactions and efficient, native files (ideal for large or growing files) are sort of mutually exclusive, though, since filesystem-level, cross-file transaction support is hit and miss (ntfs has transactional file access but I don't know much about that)

[16:38:21.0000] <othermaciej>
I might feel bad about "yet another storage api" if it did not have 22 new interfaces (adding on top of already existing reader and writer interfaces)

[16:38:39.0000] <jsbell>
zewt: +1, I share that concern.

[16:38:42.0000] <othermaciej>
sicking: filesystem API lets you write an existing file, no?

[16:38:47.0000] <othermaciej>
sicking: or read an existing file, by name

[16:38:51.0000] <sicking>
othermaciej: you mean, "not feel bad about ..."?

[16:38:53.0000] <othermaciej>
what if two tabs touch the same file at once?

[16:39:07.0000] <othermaciej>
sicking: "feel less bad about"

[16:39:13.0000] <sicking>
othermaciej: ah

[16:39:23.0000] <sicking>
othermaciej: you should look at my DeviceStorage proposal :)

[16:39:31.0000] <Hixie>
othermaciej: everything i know about the appcache stuff is http://goo.gl/VrQNF

[16:39:35.0000] <othermaciej>
pointer?

[16:39:47.0000] <sicking>
othermaciej: it's 3 interfaces currently. Probably will be 5 once it's fully capable

[16:39:55.0000] <sicking>
othermaciej: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI

[16:40:21.0000] <sicking>
othermaciej: currently it's a filesystemAPI + "API for getting access to a filesystem rooted in users pictures folder"

[16:40:30.0000] <sicking>
othermaciej: but the filesystem part can easily be broken out

[16:41:10.0000] <Hixie>
smaug____: websql got dropped because the editor of that spec wouldn't spec something without wide adoption, dunno if the editor of the other specs you mentioned fall into that category ;-)

[16:41:21.0000] <zewt>
othermaciej: 22? looking through the TOC I see 19 (still a lot), but 8 of those are Callback=FunctionOnly callback interfaces (which while I don't know where that's defined--it's not in webidl--it sounds like "you can only pass in a function and this doesn't actually expose an interface")

[16:41:29.0000] <zewt>
which would be 11

[16:41:50.0000] <zewt>
not to say that's not still a lot :)

[16:42:04.0000] <othermaciej>
see, combining filesystem-as-virtual-local-hierarchical-storage and filesystem-as-way-to-access-directories-in-the-user's-filesystem is what makes it something that I'm not keen on

[16:42:41.0000] <othermaciej>
zewt: I am imagining that for the "I need to store some blobs in a hierarchy and access by name" use case, 1-2 interfaces are sufficient (building on top of File, FileReader, FileWriter and friends)

[16:43:03.0000] <zewt>
(but there are also sync and async interfaces; I don't think it's fair to count an API as double-the-interfaces just because it has sync worker support; though the sync-getMessage proposal might in principle mean we don't need any more sync APIs at all)

[16:43:23.0000] <zewt>
ignore those and you're at 7

[16:43:26.0000] <othermaciej>
so even if we exclude the callback interfaces, we're still off by an order of magnitude

[16:43:54.0000] <zewt>
othermaciej: i do agree it can and should be simplified, though I'm not sure I'd go that far

[16:43:56.0000] <othermaciej>
yes, if you ignore 2/3 of the interfaces you get 1/3 as many

[16:43:57.0000] <sicking>
othermaciej: in what sense? You would prefer to have two separate APIs as to avoid author confusion about what they are working with? Or you want two separate APIs so that you can optimize for different usecases? Or something else?

[16:44:21.0000] <zewt>
yes, if I ignore interfaces that may not be needed and could be dropped, indeed I get less :)

[16:44:43.0000] <othermaciej>
the latter API is (a) not one that I'm sure we want to offer in Safari on any platform; and (b) more more complex than needed for the private-blob-store use case

[16:45:18.0000] <zewt>
(i suspect the FileSystem and Metadata interfaces could be dropped, too)

[16:45:20.0000] <smaug____>
Hixie: nope, they indeed don't fall into same category, which is why I said  "WebSQL was [an] odd case"

[16:45:42.0000] <sicking>
othermaciej: i absolutely agree that if we add a filesystem API to be used for a sandboxed storage area, then it needs to be possible to implement *just* that. And not worry about access to pictures folder etc

[16:45:44.0000] <Hixie>
smaug____: i would hope that having an editor who cares about multiple vendor interop wasn't odd :-)

[16:45:51.0000] <zewt>
(FileSystem just stores a name, which doesn't seem needed, and Metadata is redundant with File)

[16:46:13.0000] <smaug____>
Hixie: well, Filesystem API is such case atm ;)

[16:46:19.0000] <sicking>
othermaciej: i also agree that the API shouldn't need to be meaningfully more complex out of desire to handle both cases

[16:46:47.0000] <othermaciej>
sicking: I'm on a plane using the in-flight wifi so your proposal is tragically slow to load

[16:46:59.0000] <sicking>
othermaciej: ah :)

[16:47:02.0000] <othermaciej>
sicking: otherwise I would be commenting on it instead of just hypothetically

[16:47:24.0000] <zewt>
(url? missed that)

[16:47:50.0000] <sicking>
othermaciej: i think we can solve all designed constraints here. But I agree we need a specific proposal before we can know for sure. I think the DeviceStorage API is close, but not quite there

[16:47:54.0000] <sicking>
zewt: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI

[16:47:57.0000] <smaug____>
Hixie: er, I guess I mean, FSAPI is opposite of what you did

[16:48:05.0000] <othermaciej>
my theoretical minimum set of interfaces: Directory, some placeholder interface to get the root local storage Directory, callback interface for enumerating a Directory

[16:48:20.0000] <sicking>
othermaciej: i think you can do it without a Directory object

[16:48:25.0000] <Hixie>
smaug____: oh, i agree, i'm just hoping that the odd case is fsapi, not websql :-)

[16:48:27.0000] <othermaciej>
I would also question whether a hierarchical namespace is truly needed

[16:48:43.0000] <sicking>
"hierarchical namespace"?

[16:48:50.0000] <Hixie>
nested Directory objects

[16:49:01.0000] <sicking>
i say we don't need that

[16:49:18.0000] <sicking>
DeviceStorage doesn't have it

[16:49:26.0000] <Hixie>
if you don't have nested Directory objects, it's not clear that you need Directory objects at all -- just stick the Files in a database

[16:49:45.0000] <othermaciej>
then you only need a FileStore interface, a callback interface to enumerate the Files in FileStore, and a hook to get the FileStore

[16:49:51.0000] <othermaciej>
(maybe you just new FileStore())

[16:49:56.0000] <Hixie>
why isn't IndexDB that store?

[16:50:03.0000] <Hixie>
does it not handle Files?

[16:50:13.0000] <zewt>
well, you definitely need to be able to enumerate the files in a particular directory, but you don't necessarily need a Directory object to do that

[16:50:20.0000] <Hixie>
(Web Storage was that store for a while, but then we reverted to just text)

[16:50:24.0000] <othermaciej>
IndexedDB does not offer a persistent URL to refer to an entry

[16:50:29.0000] <othermaciej>
sicking says adding that would be awkward

[16:50:45.0000] <Hixie>
you just need to get a File out, no? then File can give you the url

[16:51:01.0000] <zewt>
(i don't understand the desire for persistent URLs either)

[16:51:13.0000] <othermaciej>
IndexedDB can in theory offer up blob: URLs but you have to make a new one each time

[16:51:35.0000] <othermaciej>
it would be nice to be able to store some markup referring to your stored resource items

[16:51:38.0000] <othermaciej>
without having to reconstitute the markup from a template each time

[16:52:50.0000] <Hixie>
aah

[16:52:51.0000] <Hixie>
i see

[16:52:53.0000] <Hixie>
i guess that makes sense

[16:53:03.0000] <Hixie>
that'd be useful for appcache too

[16:53:28.0000] <othermaciej>
It seems to me IndexedDB could offer than in principle, but I'm willing to believe it would be awkward to fit into the API

[16:53:49.0000] <othermaciej>
(indexeddb://http://mydomain.com/key/path

[16:54:47.0000] <jsbell>
Is the desire to mint URLs like that and be able to pass them around to other parts of the platform that consume URLs?

[16:55:01.0000] <zewt>
i think that's always the goal with URLs

[16:55:15.0000] <Hixie>
jsbell: images are a classic example

[16:55:22.0000] <sicking>
in particular it's hard to make relative URLs work

[16:55:27.0000] <othermaciej>
that's what I presume

[16:55:29.0000] <jsbell>
if so... yeah, figuring out how to reconcile that with the transaction model would require thought

[16:55:40.0000] <sicking>
i.e. you'd want "foo/bar/baz.html" to be able to link to a file

[16:56:05.0000] <sicking>
and "foo/bar/bizzle/hello.jpg" to link to another file

[16:56:29.0000] <othermaciej>
jsbell: not sure it's that complicated - http: has an asynchronous request/response model, indexeddb: or filesystem: could too

[16:56:30.0000] <zewt>
can't recall--is there a way for URLs to specify a protocol and a path, but no host?

[16:56:38.0000] <zewt>
which seems like what you'd want here

[16:56:42.0000] <othermaciej>
jsbell: it just has to give you one consistent state, asynchronously

[16:56:46.0000] <sicking>
while URLs into IDB probably would be something like "databasename/objectstore/key/objectproperty"

[16:57:32.0000] <sicking>
yeah, i think the transaction part is solvable. Though possibly higher overhead than the transactions that govern a filesystem

[16:57:42.0000] <sicking>
but that might not even be true


2012-09-14
[17:00:06.0000] <jsbell>
speaking of "databasename/objectstore/key/objectproperty" - the desire to read out just one property of an object has definitely come up as a pain point.

[17:03:38.0000] <othermaciej>
sicking: ok, loaded your proposal

[17:03:41.0000] <jsbell>
zewt: indexeddb:///databasename/etc with an optional domain that is usually blank (like file:///...)... and someday there may be a cross-domain permission model

[17:04:07.0000] <othermaciej>
sicking: I see ways to simplify further and some of the names are not my favorite but otherwise it's much closer to my design taste

[17:04:35.0000] <sicking>
othermaciej: i'm writing a new one which is more complete :) But you should be getting the basics of it.

[17:04:43.0000] <othermaciej>
sicking: not fully clear on what a DOMRequest is, is that a generic way to return an async result?

[17:04:45.0000] <sicking>
othermaciej: how would you simplify further?

[17:05:02.0000] <othermaciej>
sicking: I would say s/get/open/ s/getEditable/openForWrite/ or something

[17:05:05.0000] <sicking>
othermaciej: yeah. It's something we've used in a bunch of our new interfaces

[17:05:07.0000] <othermaciej>
as far as naming goes

[17:05:32.0000] <sicking>
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIDOMDOMRequest.idl

[17:05:48.0000] <othermaciej>
I would look for a way to get rid of DeviceStorageCursor

[17:05:57.0000] <sicking>
othermaciej: how?

[17:05:58.0000] <othermaciej>
it looks like you defined it twice though

[17:06:06.0000] <othermaciej>
so might be over counting the interfaces

[17:06:11.0000] <zewt>
sicking: fwiw, a way to convert blob -> file (attaching a name and mtime, with mtime being optional with a reasonable default) might be nicer than "addNamed"

[17:06:31.0000] <othermaciej>
I think a way to add an item without giving a name is unnecessary

[17:06:46.0000] <zewt>
fs.add(blob.getFile("foo.txt"))

[17:07:05.0000] <othermaciej>
I think addNamed() should be create()

[17:07:33.0000] <sicking>
othermaciej: indeed, unnamed files only makes sense for the "user's pictures folder" usecase

[17:07:40.0000] <sicking>
othermaciej: so we'd subclass for that i think

[17:07:43.0000] <othermaciej>
does DOMRequest have events?

[17:07:45.0000] <othermaciej>
is there a spec for it?

[17:07:54.0000] <othermaciej>
I can't tell how it works and thus do not understand what cursor is

[17:08:00.0000] <zewt>
why would pictures be unnamed?

[17:08:05.0000] <sicking>
othermaciej: it's basically the same as IDBRequest with some IDB specific stuff removed

[17:08:09.0000] <othermaciej>
sicking: for the "user's pictures folder" it's not clear to me you want to offer writing

[17:08:20.0000] <othermaciej>
sicking: but if you do, then surely it is named writing that you want

[17:08:26.0000] <sicking>
othermaciej: if you're building a web based OS you do :)

[17:09:01.0000] <othermaciej>
sicking: if NSDOMRequest could fire "success" multiple times and had a "done" event for that case, no extra interface would be needed

[17:09:24.0000] <sicking>
othermaciej: and make the .continue() call implicit?

[17:09:41.0000] <othermaciej>
sicking: for the "web based OS" use case (one which is not a use case I'm currently working on), I don't see why writing a named file to the pictures folder is insufficient

[17:09:50.0000] <othermaciej>
sicking: yeah, you just get events when stuff is ready

[17:09:53.0000] <sicking>
othermaciej: wouldn't that just mean that you'd want to add a .stop() function?

[17:10:00.0000] <othermaciej>
sicking: maybe you even get an array so stuff is batched as appropriate

[17:10:18.0000] <othermaciej>
sicking: I feel like you want cancel() for any DOMRequest

[17:10:46.0000] <othermaciej>
it seems like a fundamental feature of an asynchronous request that you can cancel it

[17:10:51.0000] <sicking>
othermaciej: mm... possibly.. though that can be really hard to implement usefully in the general case

[17:11:08.0000] <sicking>
othermaciej: for database operations it's basically impossible to do sanely

[17:11:16.0000] <othermaciej>
well, cancel() might just mean that you don't get the callback but it's too late to stop the side effect

[17:11:35.0000] <othermaciej>
it's clearly impossible for an async API to promise you the side effect will be prevented

[17:11:43.0000] <othermaciej>
but it can promise not to invoke the callback if it hasn't already

[17:12:04.0000] <sicking>
seems less racy then to promise to not remove the sideeffect

[17:12:09.0000] <othermaciej>
(or not to invoke it again)

[17:12:18.0000] <sicking>
which basically means that .cancel() == .removeEventListener()

[17:12:26.0000] <sicking>
except in the case of cursors, sure

[17:12:32.0000] <othermaciej>
fair enough

[17:12:40.0000] <sicking>
othermaciej: anyway, this is a detail i think

[17:12:47.0000] <othermaciej>
yeah

[17:12:48.0000] <zewt>
i wouldn't want that in all cases, eg. cancelling XHR should make a best effort to actually stop the request

[17:13:03.0000] <othermaciej>
I have many thoughts on details but I like this direction much better than FileSystem API

[17:13:19.0000] <sicking>
othermaciej: interesting to hear that you like the general approach though. I'd like to send it to the webapps list specifically for the use case of sandboxed filesystem

[17:13:26.0000] <othermaciej>
canceling a file read should also attempt to stop reading further bytes from disk

[17:13:29.0000] <sicking>
othermaciej: but i haven't had time (and won't for another little while)

[17:13:39.0000] <zewt>
othermaciej: well, that's not strictly a side-effect, since it has no visible effects

[17:13:49.0000] <zewt>
where XHR often does

[17:13:56.0000] <othermaciej>
can't promise what other Apple folks would think, but I suspect we'd be more warm to this than FileSystem

[17:14:09.0000] <sicking>
othermaciej: oh, you should probably look at the FileHandle API too

[17:14:28.0000] <othermaciej>
is that different from FileReader / FileWriter?

[17:14:29.0000] <sicking>
othermaciej: unless you have seen it already, i sent a early draft to the webapps mailinglist

[17:14:55.0000] <sicking>
yes

[17:15:01.0000] <sicking>
it's in place of FileWriter

[17:15:04.0000] <sicking>
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0886.html

[17:15:11.0000] <othermaciej>
ok

[17:15:23.0000] <othermaciej>
I'll have to look closer at both than and FileWriter

[17:15:54.0000] <sicking>
FileWriter has many bad problems IMHO. I enumerated most of them in that thread (not sure if it was in that email)

[17:16:42.0000] <sicking>
FileWriter suffers from being too close to FileReader, and I'm sad to admit to FileReader being poorly designed (my fault)

[17:17:26.0000] <sicking>
the problem is mostly syntactic in FileReader though. In FileWriter it doesn't provide enough primitives

[17:29:38.0000] <sicking>
Here's a more polished proposal which handles shallow directory enumeration: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI2

[17:29:42.0000] <sicking>
names are hard

[17:33:32.0000] <othermaciej>
sicking: I stand by my suggestion that nested directories are unnecessary given the use cases

[17:33:53.0000] <sicking>
othermaciej: not sure what you mean by that

[17:34:00.0000] <othermaciej>
sicking: (they might be necessary for the "web-based OS" use case, but I would prefer that to be kept separate from the "web" use case)

[17:34:17.0000] <othermaciej>
sicking: I don't see why you need to have any containers other than the top-level one

[17:34:31.0000] <othermaciej>
for the case of "I want to stage some resources and refer to them by URL"

[17:35:05.0000] <jamesr>
what if you have a lot of resources?

[17:35:11.0000] <othermaciej>
therefore I do not understand why there is any form of directory enumeration in addition to enumeration of the top level

[17:35:35.0000] <othermaciej>
what if you do?

[17:36:03.0000] <othermaciej>
apps on OS X and iOS have a flat "Resources" directory in their app bundle and it seems sufficient even for apps with lots of resources

[17:36:47.0000] <jamesr>
i see a lot of subdirs in the Resources directory of /Applications/Safari.app/Contents/Resources

[17:37:34.0000] <othermaciej>
the .lproj dirs are a localization scheme that's transparent to the app

[17:37:44.0000] <jamesr>
$ find /Applications/Safari.app/Contents/Resources/ -type d | wc -l     136

[17:37:50.0000] <jamesr>
no, there's more than .lproj dirs

[17:38:10.0000] <othermaciej>
others are likely files that are bundles

[17:38:25.0000] <othermaciej>
so their directory-nature is also mostly-opaque

[17:38:28.0000] <jamesr>
i see a manifest thing and a help thing just at a glance

[17:38:44.0000] <sicking>
othermaciej: so you are saying you don't want directories at all?

[17:38:53.0000] <sicking>
othermaciej: or just 1 level deep directories?

[17:39:07.0000] <othermaciej>
sicking: I think the root directory is the only one you need

[17:39:21.0000] <jamesr>
even though it's not sufficient for Safari.app ?

[17:39:33.0000] <jamesr>
i assume web apps have to deal with l10n

[17:39:35.0000] <othermaciej>
jamesr: those are both bundles and thus logically files

[17:39:56.0000] <othermaciej>
the API safari uses to access its resources offers a flat namespace

[17:40:14.0000] <sicking>
othermaciej: that's a pretty controversial position if you accept the need for filesystems

[17:40:15.0000] <othermaciej>
the relevant frameworks transparently overlay the localizations

[17:40:23.0000] <othermaciej>
I doubt web apps want that specific l10n scheme

[17:40:46.0000] <jamesr>
hm, so are you suggesting that the web API would support a specific l10n scheme?

[17:40:52.0000] <othermaciej>
sicking: I'm convinced that you need to store named data blobs that you can refer to by persistent URLs

[17:41:32.0000] <othermaciej>
jamesr: if you do your own l10n, it's not clear to me why you would need directories to do it - there's no real fundamental reason for OS X to do it that way, just quirk of history

[17:41:37.0000] <jamesr>
you're saying "it's good enough for OS X apps, except for these other cases that are handled by the framework" - so do you want to build that functionality into the framework itself to keep things looking flat?

[17:41:43.0000] <sicking>
othermaciej: one of the use cases that we had was people writing HTML editors and putting resource links in those documents that pointed to images and resources stored in the filesystem

[17:42:03.0000] <sicking>
othermaciej: it's pretty common on the web to store images in an images/ folder. So i would imagine people would want to do that here too

[17:42:48.0000] <othermaciej>
sicking: it's pretty common on the web to store images on a different server with a different hostname

[17:43:01.0000] <othermaciej>
sicking: but I'm not sure what relevance either of those approaches has to storing the files locally

[17:44:52.0000] <sicking>
othermaciej: the use case was basically to download a set of resources and have them use the same directory structure locally as you do on the website, edit locally, then upload to server

[17:45:09.0000] <othermaciej>
sicking: that would argue for N-deep directories

[17:45:15.0000] <sicking>
othermaciej: indeed

[17:45:19.0000] <othermaciej>
sicking: and ability to have multiple separate top levels

[17:45:40.0000] <sicking>
othermaciej: also indeed. The proposal has named toplevels

[17:45:47.0000] <sicking>
  DeviceStorage getSandboxedFilesystem(DOMString filesystemName);

[17:45:59.0000] <othermaciej>
which ends at an API that I think is more complex than I'm interested in implementing

[17:46:22.0000] <sicking>
othermaciej: the API doesn't actually get more complex because you have nested directories

[17:46:36.0000] <sicking>
see https://wiki.mozilla.org/WebAPI/DeviceStorageAPI2

[17:47:06.0000] <sicking>
the only thing that is added because of directories at all is 2 functions and an optional "directory" argument to two other functions

[17:47:13.0000] <sicking>
both are needed for 1-deep directories

[17:47:22.0000] <othermaciej>
you just showed me the simpler version that lacks that feature and the more complex version that has it

[17:47:24.0000] <sicking>
nothing extra is added for n-deep directories

[17:47:40.0000] <othermaciej>
(and which btw is bad OO design in the way it handles directories)

[17:48:10.0000] <sicking>
othermaciej: i'm really not sure that we need to build OO design around string concatenation

[17:48:26.0000] <sicking>
i actually think that's the main mistake in the google filesystem API

[17:48:35.0000] <othermaciej>
if string concatenation is sufficient, then why can't the client do it?

[17:48:36.0000] <othermaciej>
just allow a "/" character in filenames

[17:48:50.0000] <sicking>
othermaciej: most of the API does just that

[17:49:13.0000] <sicking>
othermaciej: the only additional thing was that people wanted to do shallow enumeration. That's the last two functions

[17:49:18.0000] <othermaciej>
I think having enumeration methods on DeviceStorage which take a token representing a directory is cheating

[17:49:31.0000] <othermaciej>
it would be like folding the FileHandle interface into DeviceStorage

[17:49:35.0000] <sicking>
is cheating bad?

[17:50:02.0000] <sicking>
if cheating == simple then cheating == good ;-)

[17:50:05.0000] <othermaciej>
to quote myself from a few weeks ago, "the web platform has enough 'war' in it, let's not add more"

[17:50:19.0000] <sicking>
how do you mean?

[17:51:03.0000] <othermaciej>
I mean using an opaque token with global methods to represent the named object is a more confusing design than an object with methods

[17:51:32.0000] <othermaciej>
to be fair, it is the Unix libc design, but at least it is done that way consistently

[17:52:15.0000] <othermaciej>
anyway, it would be better to have these discussions in a forum where more folks can participate

[17:52:23.0000] <sicking>
indeed

[17:52:50.0000] <othermaciej>
I like simple, I'm not yet convinced you need multiple top levels or that you need support for directories at anything more than a naming convention level (i.e. not clear why you need to enumerate)

[17:54:50.0000] <sicking>
othermaciej: if we don't need enumeration then i agree the API should be simplified. I think it'll be tough to sell a filesystem-like API without directories and enumeration though. Especially since IMO the main benefit of a filesystem API over indexedDB is that developers (not users) are used to dealing with directories

[17:55:06.0000] <sicking>
errr

[17:55:16.0000] <sicking>
are used to dealing with full filesystems as resource storage

[17:55:41.0000] <othermaciej>
sicking: that's kind of why I dislike thinking of it as a filesystem API - it leads people to expect complexity that does not seem fundamentally necessary for the relevant use cases

[17:55:48.0000] <sicking>
I'm definitely of the opinion that a filesystem is just a poor man's database

[17:56:25.0000] <othermaciej>
and I'm of the opinion that poor men don't need a rich api

[17:56:58.0000] <sicking>
othermaciej: heh

[17:57:41.0000] <othermaciej>
I said that to be funny, but I'm also kind of serious

[17:58:06.0000] <othermaciej>
is the goal is a simplified / dumbed down version of something you can already sort of do, then it shouldn't have a lot of features

[17:58:22.0000] <zewt>
i think by far the most important part of a filesystem API is to close the disconnect between websites and the user's filesystem and native apps; sandbox-only filesystem APIs aren't very interesting

[17:59:26.0000] <sicking>
othermaciej: indeed. But there's a range of complexity here. Finding the right points is the trick

[17:59:59.0000] <othermaciej>
zewt: that's a valid way of thinking, though such an API is a bad fit when there is no "the user's filesystem"

[18:00:26.0000] <othermaciej>
which is true on iOS and semi-true for sandboxed apps on OS X

[18:00:35.0000] <zewt>
othermaciej: when there's no user filesystem, apis connected to the concept just aren't activated

[18:01:08.0000] <zewt>
nothing really unusual there, i think

[18:01:25.0000] <othermaciej>
that API can be as complex as it likes, but it would likely be one we don't implement

[18:01:48.0000] <othermaciej>
so I wouldn't have much input other than to avoid mandating it in specs we may want to implement

[18:02:22.0000] <othermaciej>
thus the potential appeal of something like DeviceStorage, as the sandboxed file store use case is one I could be sold on, with a sufficiently simple interface

[18:32:24.0000] <sicking>
othermaciej: i agree with a lot of what you say. And I think the DeviceStorage API is very simple, even in the face of directories. We can argue whether directories are needed, but ultimately they are a pretty small part of the API, though of course non-trivial to implement

[18:33:22.0000] <sicking>
othermaciej: the only really hard part of the API is FileHandle. But I think you can make a pretty strong case for that filemanipulation is needed

[18:35:05.0000] <othermaciej>
sicking: haven't looked at FileHandle yet, but if it supports more than "write the file atomically from this blob/string/array/whatever" and "write to the file as a non-seekable stream", I would want to hear the use cases for that

[18:35:50.0000] <sicking>
othermaciej: it's mostly that. But it's also "read this data from the file, then write that data from the file, while keeping the file open inbetween to ensure that noone else modifies the file inbetween"

[18:36:31.0000] <othermaciej>
sicking: transactions, eh?

[18:36:40.0000] <sicking>
errr. "read this data from the file, write that data to the file (where the written data is based on the read data)..."

[18:36:44.0000] <othermaciej>
it's not totally clear to me that atomic read-write-modify is needed

[18:36:56.0000] <sicking>
othermaciej: no, no rollback, just the ability to keep the file open

[18:37:41.0000] <othermaciej>
I don't know if I understand the use case

[18:37:41.0000] <othermaciej>
you said "to ensure that noone else modifies the file inbetween"

[18:37:45.0000] <othermaciej>
on native operating systems, the way to ensure that is write to a whole new file, then count on rename being atomic

[18:38:21.0000] <sicking>
or you open with exclusive access, no?

[18:38:28.0000] <sicking>
crap, gotta run

[18:38:42.0000] <sicking>
there's usecases in the thread i pointed you to

[18:38:59.0000] <othermaciej>
exclusive access is applicable only when creating

[18:39:01.0000] <othermaciej>
at least on unix

[18:39:09.0000] <sicking>
but yes, my argument is that atomic read-modify-write is needed

[18:39:17.0000] <sicking>
as is fsync

[18:39:22.0000] <zewt>
othermaciej: atomic read/writes aren't done with rewriting and renaming, it's done with locks

[18:39:23.0000] <othermaciej>
there's no such thing as opening a file in a way that prevents other processes from opening it at the same time

[18:39:45.0000] <othermaciej>
well, native apps don't really have atomic read-modify-write

[18:39:49.0000] <zewt>
rather, ensuring other files don't write to it--you use rewrites and renames for transactional writes (when you want all-or-nothing writes)

[18:40:00.0000] <othermaciej>
zewt: rename is the only safe way to do it

[18:40:34.0000] <zewt>
it's far too expensive for general writes

[18:40:49.0000] <othermaciej>
the locking-based ways to do it either fail or require all sorts of trickery in what you put in the file

[18:41:16.0000] <othermaciej>
the only cases I know of that do "general writes" of that sort are databases

[18:41:18.0000] <othermaciej>
and attempting to implement a database on top of DeviceStorage would be insane

[18:41:33.0000] <zewt>
locking works when you control all of the readers and writers, when you don't you have to depend on the OS (and whether that works depends on the OS, and the network FS if any)

[18:41:40.0000] <othermaciej>
random-access writing a file is simply not safe

[18:42:12.0000] <othermaciej>
I'm just saying, native apps don't need this, so why do web apps?

[18:42:12.0000] <othermaciej>
use case!

[18:42:38.0000] <othermaciej>
(or rather, native apps generally only do this via a database-like api, which is offered elsewhere in the platform)

[18:42:49.0000] <zewt>
don't follow--native apps need safe writes all the time (which is one big reason lots of people use sqlite)

[18:42:51.0000] <othermaciej>
(or they are just broken)

[18:43:09.0000] <othermaciej>
sure, and indexeddb and websql do that

[18:43:17.0000] <othermaciej>
but where do you need it in the "game downloads its resources" use case?

[18:43:22.0000] <zewt>
but ultimately, for general-purpose, unstructured files, even if you ignore the multiple-users issue, there's no way to get safe writes when system crashes enter the picture

[18:43:37.0000] <othermaciej>
or the "stage mail uploads" use case?

[18:43:39.0000] <othermaciej>
or the "download a site, edit it, and upload" use case?

[18:43:41.0000] <zewt>
since nobody is transactional for that

[18:44:17.0000] <othermaciej>
right, unless you have a transaction model you built yourself, it's unsafe to do random-access file writes

[18:44:22.0000] <zewt>
adding a file to a ZIP, etc

[18:45:16.0000] <zewt>
updating big game data files with deltas/block hashes/whatever

[18:45:22.0000] <zewt>
afk, food

[19:31:43.0000] <MadPig>
So... who's in charge of HTML 5 Audio?

[19:32:36.0000] <Hixie>
what is HTML 5 Audio?

[19:33:01.0000] <MadPig>
The audio part of HTML 5.

[19:33:21.0000] <Hixie>
ok let me rephrase, what do you mean by "HTML 5" and what do you mean by "the audio part"?

[19:33:53.0000] <Hixie>
(not trying to be difficult, there are at least three things that you might mean by "HTML5" and several things that might be "audio")

[19:33:54.0000] <MadPig>
Sigh...

[19:34:11.0000] <MadPig>
I don't know what I mean. I assumed that there was only one standard of HTML 5.

[19:34:20.0000] <Hixie>
"HTML 5" isn't a standard

[19:34:24.0000] <MadPig>
And that it's pretty stable by now.

[19:34:35.0000] <MadPig>
"Draft" which isn't really a "draft", or whatever.

[19:34:44.0000] <Hixie>
there's the "HTML" standard which has an <audio> element, the guy "in charge" of that would be me

[19:35:21.0000] <MadPig>
Why did you not include panning in the specs? :-|

[19:35:32.0000] <Hixie>
there's the "HTML5" draft at the W3C which has their version of <audio>, not sure who would be "in charge" of that, probably the HTMLWG as a whole

[19:35:47.0000] <zewt>
(i suspect whatever it is he's talking about is not actually <audio>...)

[19:35:48.0000] <MadPig>
Hmm... that is very confusing.

[19:35:48.0000] <Hixie>
and there's the "Web Audio API" which people say is "part of HTML5", which does effects

[19:35:57.0000] <MadPig>
zewt: It is.

[19:35:59.0000] <Hixie>
and which has panning, i believe

[19:36:04.0000] <MadPig>
Hmm...

[19:36:15.0000] <Hixie>
not sure who is in charge of that exactly

[19:36:24.0000] <MadPig>
There is a lot of "Legend has it that..." kind of things related to "HTML 5".

[19:36:55.0000] <MadPig>
Nobody is sure. It's unclear what is official.

[19:36:56.0000] <MadPig>
Etc.

[19:36:59.0000] <Hixie>
anyway, as for <audio>, it doesn't have panning because it's just an audio file playback api

[19:37:12.0000] <MadPig>
Well, it should not be IMO.

[19:37:23.0000] <MadPig>
It should allow for panning since it's crucial for games.

[19:37:33.0000] <Hixie>
for games, you want the Web Audio API, not <audio>

[19:37:49.0000] <Hixie>
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html

[19:38:22.0000] <MadPig>
(Any action game will require many "voices" to be played at the same time (even of the same sample), and fully supported panning.)

[19:38:27.0000] <MadPig>
Well...

[19:38:32.0000] <Hixie>
yeah, that's what Web Audio is for

[19:38:49.0000] <MadPig>
So it's part of HTML 5?

[19:38:53.0000] <MadPig>
Why two different things?

[20:49:01.0000] <Hixie>
d'oh, he left

[20:57:30.0000] <othermaciej>
maybe he meant the <audio> element and related interfaces?

[20:58:01.0000] <Hixie>
he did, we had a whole conversation

[20:58:15.0000] <Hixie>
but i had a Computer Issue and he left while i was trying to deal with it

[00:54:13.0000] <jgraham>
darobin: Wait, what? Your Process involves deleting branches on github? That doesn't seem ideal

[00:54:49.0000] <darobin>
/me looks at jgraham, looks at coffee, wonders wah?

[00:55:06.0000] <jgraham>
Well, more nessy's process

[00:55:09.0000] <jgraham>
"The following branches have been merged (and are now gone from github

[00:55:10.0000] <jgraham>
to allow for the next round):"

[00:55:24.0000] <jgraham>
It is the parenthetical I am wondering about

[00:55:35.0000] <darobin>
deleting feature branches after they have been merged is not uncommon

[00:55:43.0000] <jgraham>
Really?

[00:55:46.0000] <darobin>
yeah

[00:55:53.0000] <jgraham>
It seems pretty silly to me

[00:56:20.0000] <darobin>
in fact git-flow does it by default

[00:56:36.0000] <darobin>
why? the full history is kept

[00:57:01.0000] <jgraham>
Because it seems confusing if someone else has a local branch that tracks that remote

[00:57:40.0000] <darobin>
you mean with local changes?

[00:57:41.0000] <jgraham>
(indeed, if you "merge" using rebase, the commits on that branch will eventually be lost)

[00:57:53.0000] <darobin>
ah, gotcha

[00:58:15.0000] <darobin>
yes, the problem isn't so much deleting branches — it's sharing feature branches in the first place

[00:58:47.0000] <jgraham>
That seems like a highly necessary part of any multi-person workflow

[00:59:15.0000] <darobin>
no, you don't collaborate on a feature branch

[00:59:37.0000] <jgraham>
…

[00:59:38.0000] <darobin>
the multi-person workflow is about the branches you merge to

[01:00:04.0000] <darobin>
there should be a health warning in there "These are feature branches being shared so that you can see where we're at. Be warned that they may be deleted without warning."

[01:00:11.0000] <jgraham>
There is clearly some part of the workflow that we do differently here :)

[01:00:17.0000] <darobin>
heh

[01:00:56.0000] <jgraham>
But if there is a team of 5 people all working on feature A, there has to be a branch where they can all push changes to feature A

[01:01:04.0000] <darobin>
when you use git-flow (which admittedly we don't) and in many uses of git in general, feature branches are branches you keep locally for a change you're working on but haven't finished

[01:01:20.0000] <darobin>
not every feature is a feature branch :)

[01:02:11.0000] <darobin>
but either way, you should take that up with silvia — at least she's had her coffee :)

[01:02:42.0000] <jgraham>
So in git-flow parlance "feature branch" is another name for a local branch that doesn't track a remote?

[01:02:51.0000] <jgraham>
Or does it track a remote?

[01:04:34.0000] <darobin>
I think that the second you have a branch that can be tracking a remote, you're sort of making the promise that you won't delete it

[01:04:51.0000] <darobin>
I don't believe I've ever pushed a feature branch on purpose

[01:05:05.0000] <darobin>
(the feature/whatwg branch would be a special case here of course)

[01:05:26.0000] <jgraham>
You mean tracked as a remote?

[01:05:31.0000] <darobin>
the branches that silvia is using are all about merging in stuff

[01:06:00.0000] <darobin>
I'm not sure which of my lines your "you mean" refers to :)

[01:06:21.0000] <darobin>
but then again, as I've mentioned: coffee

[01:06:26.0000] <jgraham>
Heh

[01:06:38.0000] <jgraham>
Don't let me get in your way :)

[01:08:41.0000] <zcorpan>
annevk: how is --pubdate="$(PUBDATE)" intended to be used in MakeFile?

[01:09:24.0000] <annevk>
try make PUBDATE="15 Sep 2012" or some such

[01:09:59.0000] <annevk>
I wonder if html5-diff is still necessary though

[01:10:24.0000] <annevk>
everyone should be up to speed by now

[01:10:46.0000] <zcorpan>
sonuds like you're out of touch with the real world :-P

[01:11:11.0000] <zcorpan>
browse sitepoint forums some day

[01:12:31.0000] <annevk>
I like my world

[01:37:15.0000] <Tuju>
I've a problem with xml schema, anyone able to help me? I'm trying to define a type with integer range limitation + an attribute

[01:37:37.0000] <Tuju>
% xmllint --noout --schema formats/config/apache/httpd/2.2/config.xsd tests/configs/domains/modweb.org.conf.xml

[01:37:39.0000] <Tuju>
formats/config/apache/httpd/2.2/config.xsd:226: element simpleType: Schemas parser error : Element '{http://www.w3.org/2001/XMLSchema}complexContent': The content is not valid. Expected is (annotation?, (restriction | extension)).

[01:39:17.0000] <jgraham>
Tuju: Pretty sure if you are trying to use XML schema you are beyond help :)

[01:39:35.0000] <jgraham>
But whatever help you can get is more likely to come from some XML-specific channel

[01:39:38.0000] <jgraham>
Not here

[01:39:59.0000] <Tuju>
jgraham: there is nothing wrong with xml imo.

[01:40:08.0000] <Tuju>
it only has a bad reputation.

[01:51:25.0000] <darobin>
Tuju: regardless of XML's merits or lack thereof, I think you're very unlikely to find the appropriate help for your issue here — it's not exactly the community for XML Schema

[01:52:02.0000] <Tuju>
i came here because earlier this was the only place anyone was able to comment my xml stuff

[01:52:43.0000] <Tuju>
but my intention is not to spam around, if it's out of scope, i'm happy to take my issue elsewhere. :)

[01:53:30.0000] <darobin>
Tuju: libxml2's support for XML Schema is incomplete at best, and unlikely to ever get fixed AFAIK

[01:53:47.0000] <darobin>
so if you really wish to use XML Schema, you should use another validator

[01:54:06.0000] <Tuju>
ah, that i didn't know.

[01:54:18.0000] <darobin>
the error you're getting is libxml2 complaining that the schema you're feeding to it is not a valid schema

[01:54:51.0000] <Tuju>
my skills are so limited that i would have bet that it's my mistake.

[01:55:27.0000] <Tuju>
that file where those exist is already quite long and has worked so far.

[01:55:29.0000] <darobin>
well, if you think it's a valid schema, given that it comes from Apache you should probably try it out with Xerces or whatever it is they use nowadays

[01:55:38.0000] <Tuju>
but with limited set of features used.

[01:56:00.0000] <darobin>
Tuju: frankly, XML is fine for a lot of stuff, but XML Schema is a rather dreadful piece of technology

[01:56:07.0000] <Tuju>
darobin: what comes from apache?

[01:56:21.0000] <darobin>
so I would recommend staying away from it as much as you can, *especially* if you're not an XML expert

[01:56:36.0000] <Tuju>
i wouldn't mind to become one :)

[01:56:42.0000] <Tuju>
it could be useful...

[01:56:58.0000] <darobin>
the config.xsd seems to come from Apache (based on the path)

[01:57:08.0000] <Tuju>
nope, i wrote that one.

[01:57:31.0000] <Tuju>
but yes, that content eventually came from there.

[01:57:42.0000] <darobin>
ah, ok, then it's possible you've made a mistake — writing XSD by hand is highly error-prone, and writing XSD with a tool is buggy at best

[01:58:23.0000] <Tuju>
i made plenty of bugs into that but gradually got them ironed out

[01:58:24.0000] <darobin>
if you do want to become an XML expert, learn all that you can do with XML without XML Schema, and only then look at XML Schema

[01:58:29.0000] <Tuju>
but it's still far from complete.

[01:58:34.0000] <darobin>
otherwise it'll warp any understanding you may have of the tech

[01:59:10.0000] <Tuju>
could be true. i just see that schemas are integral part of it.

[01:59:38.0000] <darobin>
if you think XML Schema is an integral part of XML, you will become a Java expert but never an XML expert :)

[02:01:22.0000] <Tuju>
uuuh, i would rather cut my wrists...

[02:01:57.0000] <Tuju>
looked at that xerces thingy, is there a cli tool for it? my fedora pkg search didn't find one.

[02:02:04.0000] <Tuju>
thou libs are included

[02:05:46.0000] <zcorpan>
can anyone tell me what materially changed in http://html5.org/r/7244 ?

[02:06:14.0000] <zcorpan>
the content model?

[02:07:10.0000] <zcorpan>
seems so

[02:30:53.0000] <Stevef_>
darobin: think i inadvertently overworte your change to https://www.w3.org/Bugs/Public/show_bug.cgi?id=18245

[02:32:04.0000] <Stevef_>
darobin: were you assigning or unassigning yourself to the bug?

[02:32:10.0000] <darobin>
and you will pay dearly for that Stevef_!

[02:32:21.0000] <darobin>
I was assigning it to me, but it's no biggie

[02:32:33.0000] <Tuju>
darobin: i got it working

[02:32:37.0000] <Tuju>
with xmllint

[02:32:41.0000] <darobin>
if you update it, since you agree that it's a .next thing, can you assign it to the html.next product please?

[02:32:43.0000] <Tuju>
ho, i'm good.

[02:32:50.0000] <Tuju>
/me hugs himself.

[02:32:57.0000] <Tuju>
/me taps his own back.

[02:33:03.0000] <darobin>
/me gives Tuju a RelaxNG cookie

[02:33:14.0000] <Tuju>
/me whees!

[02:33:18.0000] <Stevef_>
darobin: i have already paid so dearly for my past transgressions that i have nothing left to give, yes will reassign

[02:33:36.0000] <darobin>
Stevef_: I'm certainly interested in looking more deeply into this, I was under the impression that this could be done with existing tech without needing support from the browser

[02:33:47.0000] <darobin>
but if I'm wrong it's certainly something we can do something about

[02:34:08.0000] <jgraham>
Stevef_: Sounds like a speech you should save for your last words :)

[02:34:37.0000] <darobin>
"Yes Will Reassign" sounds like a great epitaph

[02:34:42.0000] <darobin>
(or not)

[02:35:02.0000] <Stevef_>
darobin: it can be done with ARIA, but at least some people would prefer it be done via a HTML feature

[02:35:30.0000] <darobin>
Stevef_: right, that's what I thought, and IIRC many of the "big" implementations of tabs do it with ARIA

[02:35:50.0000] <darobin>
I'm happy to chat about the tradeoffs — but just in the .next timeframe :)

[02:35:58.0000] <Stevef_>
jgraham: one never knows when one's last words may be uttered...

[02:36:30.0000] <darobin>
at which point annevk ominously drops off

[02:36:40.0000] <darobin>
I told him this URL thing wasn't any good for him

[02:37:34.0000] <Stevef_>
darobin: its not a priority at the moment, I commented as I wanted to respond to the pure CSS view as I said in bug, its an old issue that has been postponed for now

[02:37:49.0000] <darobin>
Stevef_: cool, ta

[02:39:16.0000] <darobin>
Stevef_: I'm on the bug right now — I'll reassign and move to .next

[02:39:28.0000] <Stevef_>
i have already moved

[02:39:44.0000] <darobin>
really? it was telling me not...

[02:40:11.0000] <darobin>
well — it seems to be in a consistent state now anyway :)

[03:17:24.0000] <zcorpan>
http://dev.w3.org/cvsweb/html5/html4-differences/Overview.src.html.diff?r1=1.192;r2=1.193

[05:06:10.0000] <AryehGregor>
Wait, is DOM4 still authoritative these days, or should I be editing something else if I want to make changes?

[05:06:17.0000] <AryehGregor>
/me looks for annevk or Ms2ger

[05:27:30.0000] <annevk42>
AryehGregor: use https://github.com/whatwg/dom

[05:27:41.0000] <annevk42>
AryehGregor: once you push the webpage will get updated automatically

[05:27:53.0000] <annevk42>
AryehGregor: webpage being http://dom.spec.whatwg.org

[05:27:57.0000] <AryehGregor>
annevk42, okay.  Is that what implementers are using, or is this an independent fork that will cause havoc and confusion?

[05:28:18.0000] <annevk42>
we'll see

[05:31:54.0000] <annevk42>
AryehGregor: they're implementing based on it, e.g. createHTMLDocument()'s now optional argument

[05:32:14.0000] <annevk42>
AryehGregor: afaict implementors implement whatever is maintained

[05:32:22.0000] <AryehGregor>
So in other words, it's an independent fork that will cause havoc and confusion, but hopefully it will win?

[05:32:50.0000] <annevk42>
I don't know, I know I can't join the W3C so I can't edit their specs

[05:33:14.0000] <AryehGregor>
You don't want to join as an Invited Expert because that means giving over your copyright or something?

[05:33:24.0000] <annevk42>
right

[05:38:57.0000] <AryehGregor>
Could you use a CG instead?

[05:39:44.0000] <annevk42>
might publish them through the WHATCG

[05:39:52.0000] <annevk42>
but that doesn't really seem needed for now

[05:39:56.0000] <annevk42>
only for FSA-style stuff

[05:40:15.0000] <annevk42>
which I'll let Hixie  pioneer

[05:51:20.0000] <Ms3ger>
/me summons jsbell

[05:53:00.0000] <Ms3ger>
(Only intermittently around until Monday or so, fwiw)

[05:56:39.0000] <odinho>
What's with all them numbers, annevk42 and now Ms3ger

[05:57:32.0000] <darobin>
yeah it's stupid, it's should clearly be annevkLS and MsLSget

[05:57:39.0000] <darobin>
*MsLSger

[06:17:19.0000] <zcorpan>
was there a bug filed about listing all events in the html spec?

[06:20:21.0000] <smaug____>
does anyone know what performance.memory is?

[07:19:23.0000] <zcorpan>
anyone feel like reviewing html5-diff before i say that i'm done (in a few minutes)? :-)

[07:19:50.0000] <zcorpan>
http://dev.w3.org/cvsweb/html5/html4-differences/Overview.src.html

[07:30:54.0000] <zcorpan>
(if you find issues, please file bugs, i'll fix it for the next publication)

[07:32:07.0000] <[tm]>
zcorpan: I will definitely take a look

[07:32:16.0000] <[tm]>
but I can't until tomorrow or so

[07:32:20.0000] <zcorpan>
[tm]: thanks!

[07:32:30.0000] <[tm]>
right now I am watching anne give a presentation

[07:32:49.0000] <zcorpan>
right now i'll call it a day

[07:33:00.0000] <zcorpan>
see you guys on monday :-)

[07:33:50.0000] <[tm]>
chheers

[08:29:07.0000] <jarek>
Hi

[08:29:13.0000] <jarek>
I have just found this spec: https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html

[08:29:26.0000] <jarek>
does it mean that SMIL is definitely dead now?

[08:56:03.0000] <cabanier>
hixie: I notice that not all images in the Canvas2D spec are checked in with SVN.

[08:56:23.0000] <cabanier>
hixie: could you add them so we can bring them into the W3 spec?

[08:56:38.0000] <cabanier>
hixie: also, do you have the original artwork?

[08:57:34.0000] <Hixie>
zcorpan: the ruby change was quite substantial; the spec went from basically having a trivial ruby feature to one that covers most of the use cases, by changing the content model and processing/rendering model. parsing didn't change.

[08:59:24.0000] <Hixie>
cabanier: they should be, but yeah, i can look into it. Can you send me an e-mail?

[08:59:31.0000] <Hixie>
cabanier: what do you mean by "original artwork"?

[09:00:46.0000] <Hixie>
actually don't worry about e-mail

[09:01:43.0000] <Hixie>
added them

[09:02:31.0000] <Hixie>
bbiab

[09:13:13.0000] <Ms3ger>
jsbell!

[09:13:24.0000] <jsbell>
eeeek!

[09:13:44.0000] <jsbell>
Wait... *3* ?

[09:13:45.0000] <Ms3ger>
You complained about an IDB test while I was offline?

[09:13:56.0000] <jsbell>
Yeah, sec...

[09:16:23.0000] <jsbell>
Ms3ger: http://w3c-test.org/webapps/IndexedDB/tests/submissions/Ms2ger/idbfactory_open9.htm has a test that IDBFactory.open() throws when version is >= 2^53. I agree with the sentiment, but it's neither in the spec nor did I see a spec bug.

[09:16:46.0000] <Ms3ger>
Did you look at WebIDL?

[09:17:17.0000] <jsbell>
*sigh*

[09:17:30.0000] <odinho>
Hmm... *testing*

[09:18:08.0000] <odinho>
yay green.

[09:18:13.0000] <jsbell>
Ah yes, there it is.

[09:18:18.0000] <jsbell>
*shakes fist at binding code*

[09:18:30.0000] <Ms3ger>
Good :)

[09:18:46.0000] <Ms3ger>
Not sure why you were looking anywhere else ;)

[09:18:53.0000] <Ms3ger>
Need to go now, though

[09:19:00.0000] <odinho>
okay, it's depressing staying longer at work now, so I'll go.

[09:19:05.0000] <odinho>
Hmm. at the same time even.

[12:55:38.0000] <jgraham>
smaug____: Isn't performance.memory the set of mostly-frightening requests that Zynga made

[12:55:41.0000] <jgraham>
?

[12:56:38.0000] <jgraham>
http://lists.w3.org/Archives/Public/public-web-perf/2012Sep/0016.html

[12:56:57.0000] <jgraham>
Or that doesn't actually mention performance.memory anywhere so maybe not

[12:57:07.0000] <jgraham>
What's the context for your question?

[12:57:43.0000] <smaug____>
jgraham: ringmark test

[13:15:54.0000] <jgraham>
smaug____: Oh who knows then

[13:16:33.0000] <jgraham>
That is a walking disaster area

[13:20:25.0000] <jgraham>
smaug____: But I don't see it there either

[14:38:44.0000] <sicking>
Hixie: why can't I find any callers of "jump to a code entry-point"? I'm trying to figure out how "entry script" is actually intended to work

[14:41:36.0000] <sicking>
oh, it's just called "jump" in the text

[14:41:36.0000] <Hixie>
sicking: one sec

[14:41:40.0000] <sicking>
Hixie: nm

[14:42:11.0000] <Hixie>
sicking: clicking on the bold <dfn> text will get you a backref list btw

[14:42:19.0000] <Hixie>
sicking: (only works usefully on the single-page copy of hte spec)

[14:42:29.0000] <sicking>
Hixie: only if i want to wait ages for the page to load

[14:42:42.0000] <sicking>
Hixie: i always read the spec with ?slow-browser

[14:42:55.0000] <Hixie>
firefox is pretty fast these days on the spec isn't it?

[14:43:11.0000] <sicking>
Hixie: no, it's just pretty fast these days ;-)

[14:43:31.0000] <Hixie>
well it's been fast for longer than it's been fast specifically on the spec, which is why i put it that way :-)

[14:44:29.0000] <sicking>
Hixie: still takes 20 some seconds for me to get it fully responsive

[14:44:43.0000] <sicking>
measured between my thumb and index finger

[14:45:10.0000] <Hixie>
it does seem to hang the browser more than it does in chrome, weird

[14:45:19.0000] <Hixie>
i recommend just leaving it open in the background

[14:45:21.0000] <Hixie>
that's what i do :-)

[14:45:44.0000] <Hixie>
(once the page is loaded, firefox seems to be way better on it than chrome)

[14:46:53.0000] <Hixie>
(though resizing the browser window isn't so hot)

[14:46:55.0000] <Hixie>
(yikes)

[14:47:58.0000] <sicking>
Hixie: i have too much ADD to leave too many tabs open :)

[14:48:24.0000] <Hixie>
heh

[14:48:50.0000] <sicking>
Hixie: not saying that we couldn't do better with the spec from the gecko side. But this is why i have the ?slow-browser version bookmarked

[14:49:04.0000] <Hixie>
fair enough :-)

[14:49:05.0000] <sicking>
but i did remove it in order to find the back-refs here

[15:16:43.0000] <jonathanj>
hello, with html5lib.parse(some_xhtml, treebuilder='lxml') i get attributes like this: xmlU0003Alang

[15:18:54.0000] <zewt>
a fun mistake is hitting inspect element on the spec in chrome

[15:19:30.0000] <jonathanj>
i would have expected html5lib to be able to parse xhtml, or is this an lxml issue?

[15:19:42.0000] <Hixie>
jonathanj: html5lib is for parsing html, not xml :-)

[15:21:26.0000] <cabanier>
hixie: not sure if you saw my earlier message but I noticed that not all images from the Canvas2D spec are checked in with SVN.

[15:21:44.0000] <Hixie>
cabanier: yeah i fixed it

[15:21:57.0000] <cabanier>
hixie: great!

[15:22:11.0000] <Hixie>
(i always forget to do "svn add")

[15:22:17.0000] <cabanier>
:-)

[15:55:01.0000] <jonathanj>
Hixie: thanks, that's actually good advice

[15:55:22.0000] <jonathanj>
even if i didn't think that 30 minutes ago

[15:56:41.0000] <Hixie>
heh


2012-09-15
[00:17:34.0000] <annevk>
GPHemsley: for https://bugzilla.mozilla.org/show_bug.cgi?id=791428 you prolly want to find someone to cc that has experience with that code

[00:17:45.0000] <annevk>
GPHemsley: standards people are not going to be of much help I think ;)

[00:34:42.0000] <annevk>
hmm, IPv6 parsing in JavaScript is kinda annoying with the 53bit int limit

[01:26:28.0000] <MikeSmith>
http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html

[01:26:36.0000] <MikeSmith>
from Tobie Langel

[01:26:48.0000] <MikeSmith>
"What's slowing down Mobile Facebook"

[01:53:36.0000] <smaug____>
ugh

[01:54:01.0000] <smaug____>
creating nodes in workers and moving them to main thread

[01:54:10.0000] <smaug____>
the API would become horrible

[01:54:21.0000] <smaug____>
what if you add event listener to the node in worker

[01:54:32.0000] <smaug____>
and transfer the node to mainthread

[02:07:11.0000] <annevk>
what's the context for DOM in workers?

[08:32:34.0000] <jgraham>
annevk: The facebook mail

[08:33:23.0000] <jgraham>
They seem to want to do infinite scrolling by preconstructing document fragments in a worker and then cloning them across to the main thread for rendering

[08:34:05.0000] <jgraham>
It is not obvious to me that this would be faster

[08:34:50.0000] <jgraham>
But presumably the response to smaug's concern is that such fragments would be dead until inserted into the main document

[08:35:04.0000] <jgraham>
So scripts would not run, event listeners would not fire, etc.

[09:05:17.0000] <zewt>
seems like an order of magnitude of complexity that should require an order of magnitude benefit

[10:07:09.0000] <annevk>
jgraham: oh, I searched that email for node and that yielded nothing

[10:24:45.0000] <jwalden>
dear lazywhatwg, does anyone know offhand what the document.all property looks like in Opera?  a plain old object, an object that pretends to be falsy, an object that compares == to undefined/null (but not ===), something else?

[10:30:33.0000] <annevk>
falsy iirc

[10:47:42.0000] <jwalden>
interestingly, in Opera it seems document.all === undefined

[10:47:55.0000] <jwalden>
even thought it's an object

[10:48:12.0000] <jwalden>
jsc at least has == undefined but !== undefined

[10:50:53.0000] <jgraham>
jwalden: Gecko also has === undefined, no?

[10:51:23.0000] <jwalden>
jgraham: Gecko is very funky in how it does things right now

[10:51:53.0000] <jwalden>
jgraham: if you can manage to get the document.all value as an object, it will not be === undefined

[10:52:44.0000] <jwalden>
roughly speaking there is a heuristic that looks at bytecode patterns and decides whether the pattern represents an attempt to "detect" whether a property exists

[10:53:48.0000] <jwalden>
well, the heuristic applies to all property accesses, including ones not directly implemented in script, but it's roughly informed by whatever the current script evaluation context is

[10:54:36.0000] <jwalden>
I'm hoping to remove it in favor of the undefined-looking mechanism right now, on the basis of it being so much less invasive and impossible to implement around

[10:55:07.0000] <jwalden>
arguments for compatibility probably help with that to some extent

[10:55:31.0000] <jwalden>
rather, arguments that doing so increases compatibility help

[10:56:35.0000] <Hixie>
http://www.whatwg.org/specs/web-apps/current-work/#dom-document-all

[10:56:46.0000] <jgraham>
Yes, I imagine that argument would go "ain't no way we will ever get interoperability around crazy bytecode hacks"

[10:59:10.0000] <jwalden>
that's how the argument *has* gone in the past :-)

[10:59:56.0000] <jwalden>
/me doesn't really think undefined-looking objects are right, but he's pretty sure they're at least less wrong

[10:59:57.0000] <Hixie>
what the spec says (cited above) is, iirc, the closest i could get to defining what browsers did without going off into the weeds of defining things like bytecode hacks

[11:01:26.0000] <jwalden>
in any case, it appears that engines (excepting Gecko) don't try to make "all" in document lie

[11:02:15.0000] <Hixie>
that's consistent with the spec, woot

[11:03:37.0000] <jwalden>
yep

[11:05:19.0000] <jwalden>
a little unfortunate maybe, but extending the property-access ECMAScript interface is just about the scariest possible thing a JS engine can do, in terms of making it easier to write bugs, harder to write correct code, harder to implement a spec-compliant engine, etc.

[11:06:18.0000] <jwalden>
/me isn't convinced anyone (including anyone working on SpiderMonkey) is smart enough to do it correctly

[11:06:23.0000] <jwalden>
well,

[11:06:38.0000] <jwalden>
"correctly" in the sense of not breaking incidental stuff along the way

[11:12:35.0000] <jwalden>
I think Gecko still makes document.all only appear in quirks mode, tho

[11:12:47.0000] <jwalden>
which does help satisfy the "all" in document test

[11:13:28.0000] <jwalden>
(that is, making it false to dissuade IE-detectors to some extent)

[11:24:13.0000] <Hixie>
annevk: if a sandboxed iframe has allow-popups and creates a sandboxed popup, should that popup be able to open fullscreen?

[11:24:53.0000] <Hixie>
annevk: or do i need to have a sandbox flag that stops that except if the attribute allowfullscreen is set?

[11:25:08.0000] <Hixie>
(this would be the first time the sandboxed flags get affected by things not in the sandbox attribute)

[12:19:08.0000] <Ms2ger>
/me dives into his inbox

[12:19:28.0000] <Ms2ger>
1161 unread...

[12:48:22.0000] <Ms2ger>
Down to a thousand, good time to head off...

[14:40:28.0000] <annevk>
Hixie: I guess it would need allowfullscreen

[14:40:39.0000] <annevk>
Hixie: roc might have a more informed opinion

[14:40:42.0000] <Hixie>
"it"?

[14:40:58.0000] <annevk>
Hixie: the allow-popups popup

[14:41:09.0000] <Hixie>
how can a popup have allowfullscreen?

[14:42:08.0000] <annevk>
the same way it can be sandboxed

[14:42:37.0000] <Hixie>
by adding a sandbox="" attribute on the iframe or in CSP?

[14:43:00.0000] <annevk>
I was thinking <iframe>

[14:43:15.0000] <Hixie>
ah ok

[14:43:19.0000] <Hixie>
so what i wrote in the bug, basically

[14:43:23.0000] <Hixie>
propagate a sandbox flag

[14:43:24.0000] <Hixie>
ok

[14:43:26.0000] <annevk>
uhuh

[15:01:27.0000] <brainproxy>
will this patch to the w3c's html5 spec re: link relations be incorporated into the whatwg's living standard?

[15:01:29.0000] <brainproxy>
https://github.com/w3c/html/commit/954203e085e601122a2df38207bfdd6d852a0963

[15:02:53.0000] <Hixie>
no

[15:03:09.0000] <Hixie>
(it's pointless)

[15:03:40.0000] <Hixie>
(it's so trivial to register a link type that there's really no reason to use a url, and urls wouldn't work right anyway since the rel="" field is case-insensitive and doesn't do url processing so really they'd just be opaque strings)

[15:04:03.0000] <Hixie>
(if we wanted to support a non-registered proprietary value space here, we'd likely use java-style reverse-dns names, not urls)

[15:05:04.0000] <brainproxy>
what if I'm developing an "semantic profile" based API, like Amundsen's ALPS, and I don't want to necessarily register links rels, but at the same time want to generate html that is valid

[15:05:29.0000] <Hixie>
can you elaborate on that?

[15:05:36.0000] <Hixie>
what problem are you trying to solve with this?

[15:05:58.0000] <brainproxy>
Hixie: see http://amundsen.com/hypermedia/profiles/

[15:06:17.0000] <brainproxy>
the idea is that you develop a semantic profile, where "rel" vals play an important role

[15:06:29.0000] <Hixie>
i have no idea what these words mean

[15:06:32.0000] <Hixie>
well that's not true

[15:06:35.0000] <Hixie>
i know what the words mean

[15:06:44.0000] <brainproxy>
the ALPS example is pretty short

[15:06:44.0000] <Hixie>
but put together in this order they don't add up to anything to me :-)

[15:07:00.0000] <Hixie>
i meant the words at http://amundsen.com/hypermedia/profiles/

[15:07:15.0000] <brainproxy>
the idea is that you document rel, class, name attrs

[15:07:22.0000] <Hixie>
the closest thing to a problem description there seems to be "The purpose of Application-Level Profile Semantics (ALPS) is to document the application-level semantics of a particular implementation." but i've no idea what that means

[15:07:27.0000] <brainproxy>
so that clients can be programmed to understand what they mean

[15:07:43.0000] <brainproxy>
but if you just use any old rel value, it's not valid html5

[15:07:48.0000] <Hixie>
can you give me a concrete example of what user-facing problem we're fixing with this?

[15:08:30.0000] <brainproxy>
it's another way to develop a hypermedia api using "semantic web" notions

[15:09:08.0000] <zewt>
("hypermedia"? heh)

[15:09:20.0000] <Hixie>
what is a "hypermedia api"

[15:09:40.0000] <brainproxy>
basically term to suggest that the API embraces HATEOAS

[15:09:48.0000] <Hixie>
"HATEOAS"?

[15:09:54.0000] <Hixie>
assume i know nothing here, and start from zero :-)

[15:10:03.0000] <brainproxy>
hyertext/media as the engine of application state

[15:10:07.0000] <Hixie>
i'm a user, sitting at a computer

[15:10:14.0000] <Hixie>
what is my computer not doing that you are going to make it do

[15:11:11.0000] <brainproxy>
well this has more value for developers programming clients and servers based on web tech, and not necessarily joe smith using his browser

[15:11:45.0000] <Hixie>
well      smith using his browser

[15:11:48.0000] <Hixie>
er

[15:12:04.0000] <Hixie>
well, developers programming clients and servers based on web tech are still solving joe smith problems, right?

[15:12:16.0000] <Hixie>
like, they write tools to help them send short messages to their friends

[15:12:20.0000] <brainproxy>
the idea is that I can give you an entry point to my api, and armed w/ the semantic profile, you can build a client that can use the api w/o having to know some uri generation scheme

[15:12:22.0000] <Hixie>
or to manage their calendar

[15:12:24.0000] <Hixie>
or watch porn

[15:12:25.0000] <Hixie>
or whatever

[15:12:56.0000] <Hixie>
"uri generation scheme"?

[15:13:27.0000] <Hixie>
i feel like i'm missing some key context here

[15:13:34.0000] <Hixie>
what kind of API are we talking about?

[15:13:44.0000] <brainproxy>
in other words, my documented api revolves around the semantics of the hypermedia and not around documenting how to build up uris to do what you want to do

[15:14:01.0000] <Hixie>
sounds like your API is very complicated :-)

[15:14:06.0000] <Hixie>
can't you just have a simple API?

[15:14:10.0000] <Hixie>
what does your API do?

[15:14:57.0000] <brainproxy>
well one in particular I'm building acts as a gateway between plain web (just html pages w/ links and forms) and industrial automation systems

[15:15:48.0000] <brainproxy>
so yes, there's a fair bit of complexity

[15:15:58.0000] <Hixie>
what is an "industrial automation system"? like, robots and stuff?

[15:17:26.0000] <brainproxy>
well, in general devices you'd find in a manufacturing environment communicate w/ each other, and w/ centralized systems to keep track of what's going on

[15:17:49.0000] <brainproxy>
alarms, events, data changes, an so on

[15:17:54.0000] <Hixie>
ok...

[15:17:58.0000] <Hixie>
what's that got to do with HTML?

[15:18:06.0000] <zewt>
things i don't want my factory communicating with: the web

[15:18:12.0000] <Hixie>
yeah really

[15:18:26.0000] <Hixie>
air gap that sucker :-P

[15:18:40.0000] <brainproxy>
using web tech doesn't mean you hang your ass out of the factory's firewally on port 80

[15:18:46.0000] <brainproxy>
gimme a break :p

[15:19:19.0000] <brainproxy>
anyway, what it has to do w/ html; there are standards which govern how these things communicate

[15:19:41.0000] <Hixie>
please tell me they document binary TCP protocols that have nothing to do with HTTP

[15:19:52.0000] <brainproxy>
it's more than just wire protocols

[15:19:59.0000] <brainproxy>
and they do both binary and xml/soap

[15:20:06.0000] <zewt>
:|

[15:20:13.0000] <Hixie>
i think i see your problem :-)

[15:20:17.0000] <brainproxy>
it's all very stateful and not very nice to work with

[15:20:41.0000] <Hixie>
still don't see how this relates to HTML though

[15:20:43.0000] <Hixie>
let alone rel=""

[15:21:13.0000] <brainproxy>
well, i'm working on a gateway that one one side uses http/html as the application layer

[15:21:26.0000] <brainproxy>
and on the other side uses these industrial protocols

[15:21:49.0000] <Hixie>
i'll admit i know nothing about this at all, as should be clear from this conversation so far

[15:21:54.0000] <Hixie>
but that sounds like a terrible idea :-P

[15:22:05.0000] <brainproxy>
that's okay, you asked, so I was trying to explain it

[15:22:12.0000] <brainproxy>
i can stop if it's not interesting

[15:22:21.0000] <Hixie>
it is definitely interesting

[15:22:26.0000] <brainproxy>
anyway, Amundsen's ALPS thing and a book he wrote inspired me

[15:22:43.0000] <brainproxy>
but you end up generating a lot of rel values

[15:22:47.0000] <brainproxy>
which aren't registered

[15:22:58.0000] <brainproxy>
hence ... the option to use valid but non-registered rels is appealing

[15:22:58.0000] <Hixie>
what do these rel values mean?

[15:23:14.0000] <brainproxy>
they allow a client to understand what <a> is pointing to

[15:23:35.0000] <Hixie>
how, if there's no definiton?

[15:23:50.0000] <Hixie>
or are these entirely intended for proprietary use and not public web use?

[15:24:09.0000] <brainproxy>
there is, you document it, but it's not necessarily apt for publication in microformats

[15:24:28.0000] <Hixie>
i'm trying to work out what the consumption software for this is

[15:24:40.0000] <Hixie>
is this something that you would ever try to read from an unrelated third party?

[15:24:55.0000] <Hixie>
or is this all for use within a closed circle of people?

[15:26:21.0000] <brainproxy>
unrelated third-parties could leverage the api to communicate w/ each other's systems

[15:26:43.0000] <Hixie>
on the web?

[15:27:16.0000] <brainproxy>
well across the global Internet yes, or intra-enterprise,

[15:27:46.0000] <brainproxy>
and/or you could have small devices sporting a lightweight http/html stack use it to tie into the heavier-duty stuff

[15:28:59.0000] <Hixie>
it sounds to me like the solution to this is to define a specification for "Industrial API HTML definitions" or something, which introduces a new attribute like "api-rel" or whatever, which you can use for this purpose

[15:29:06.0000] <Hixie>
it doesn't sound like rel="" is the right thing at all

[15:29:39.0000] <brainproxy>
well no i disagree because rel conveys the meaning perfectly

[15:30:20.0000] <Hixie>
honestly it doesn't sound like HTML is the right thing at all, but I could see wanting to reuse it so that the same page could open both in a web browser and in this magical api software

[15:30:34.0000] <brainproxy>
and if someone wants to know what the heck rel="http://mycompany.com/rels/rel-1" means then they can look it up

[15:30:41.0000] <brainproxy>
assuming I publishd documentation at the URI

[15:31:06.0000] <brainproxy>
it's not magical, you can write stuff like this easily with python or node.js or whatever

[15:31:16.0000] <zewt>
(why would you put a url in rel? that's totally wrong)

[15:31:30.0000] <brainproxy>
zewt: because that's what RFC 5988 recommendes

[15:31:40.0000] <brainproxy>
and the w3c editors saw the wisdom in it

[15:31:44.0000] <brainproxy>
and patched their spec

[15:31:51.0000] <Hixie>
doing things because an RFC recommends it is the worst possible reason to do something

[15:32:01.0000] <Hixie>
and the w3c editors didn't see the wisdom in it

[15:32:04.0000] <brainproxy>
Hixie: well if it's a bone-headed recommendation sure :)

[15:32:07.0000] <Hixie>
the w3c html chairs saw the wisdom

[15:32:18.0000] <Hixie>
and some w3c editors thought itwas so dumb they quit as editors :_)

[15:32:43.0000] <brainproxy>
so ... if want to know what rel="registered-rel" means

[15:32:56.0000] <brainproxy>
I can go look it up on microformats

[15:32:57.0000] <Hixie>
google [rel registered-rel]

[15:33:07.0000] <brainproxy>
or IANA i guess

[15:33:30.0000] <brainproxy>
but anyway, why is it bad to have the option to specify rel="http://mycompany.com/api/rels/rel-1"

[15:33:41.0000] <brainproxy>
and then joe blow client app developer can go look it up

[15:33:55.0000] <brainproxy>
on my wiki, or whatever that uri points him to

[15:34:15.0000] <Hixie>
what's bad is defining an API using rel="" :-)

[15:34:24.0000] <brainproxy>
nah, it's brililant

[15:34:27.0000] <brainproxy>
:D

[15:35:01.0000] <brainproxy>
and you don't use just rel of course

[15:35:09.0000] <brainproxy>
rel, class, name...

[15:35:16.0000] <Hixie>
o_O

[15:35:19.0000] <Hixie>
i really am at a loss

[15:35:30.0000] <Hixie>
why would anyone want to do this with HTML

[15:35:33.0000] <brainproxy>
read the ALPS thing, and here's an example

[15:35:41.0000] <Hixie>
i did read the ALPS thing

[15:35:45.0000] <Hixie>
it broke my buzzword detector

[15:35:55.0000] <Hixie>
and i didn't understand a word of it

[15:36:05.0000] <brainproxy>
https://github.com/mamund/Building-Hypermedia-APIs/tree/master/nodejs/microblog

[15:36:08.0000] <Hixie>
it was as bad as some of the Semantic Web stuff

[15:36:25.0000] <brainproxy>
that's an implemntation of Amundsen's ALPS, by the author, using nodejs

[15:37:03.0000] <Hixie>
what does it do?

[15:37:29.0000] <brainproxy>
it's a microblog which implements his semantic pofile

[15:37:34.0000] <brainproxy>
outlined in that document

[15:37:40.0000] <Hixie>
but what does it _do_?

[15:37:48.0000] <brainproxy>
it's a microblog

[15:37:53.0000] <zewt>
(what the heck is a microblog, aren't blogs micro by definition)

[15:37:54.0000] <brainproxy>
like Twitter, it's just an example

[15:38:08.0000] <brainproxy>
and this is a js bot which consumes the api

[15:38:10.0000] <brainproxy>
https://github.com/mamund/Building-Hypermedia-APIs/blob/master/nodejs/microblog/public/javascripts/mbclient.js

[15:38:15.0000] <Hixie>
zewt: microblog is basically like IRC but for hipsters :-)

[15:38:46.0000] <Hixie>
brainproxy: i don't understand why this is better than just having an API that you call directly

[15:38:54.0000] <Hixie>
brainproxy: it seems like a massive amount of extra work for no benefit

[15:39:16.0000] <brainproxy>
what do you mean by API you call directly?

[15:39:19.0000] <Hixie>
basically it's just an extra level of indirection

[15:39:35.0000] <Hixie>
instead of having to hardcode the API, you hardcode the values in rel="" etc, look up the API, and call the API

[15:39:36.0000] <brainproxy>
you mean by documenting URI construction rules?

[15:39:39.0000] <Hixie>
why not just call the API

[15:39:51.0000] <Hixie>
well I wouldn't use the term "URI construction rules", but sure

[15:40:02.0000] <brainproxy>
well in this manner two different implementations could use completely different URI schemes

[15:40:06.0000] <Hixie>
personally i would do all these APIs over WebSocket these days

[15:40:06.0000] <brainproxy>
and it would work the same

[15:40:27.0000] <Hixie>
they could use completely different URI schemes but would still have to use identical rel="" etc schemes, right?

[15:40:33.0000] <brainproxy>
yes

[15:40:37.0000] <Hixie>
so where's the benefit

[15:41:01.0000] <brainproxy>
:/

[15:41:05.0000] <Hixie>
why not just define a little JSON blob that defines the mapping to the "URI construction rules"

[15:41:12.0000] <Hixie>
if you want to abstract those out

[15:41:30.0000] <Hixie>
(and why not just screw URLs entirely, and just document and implement a microblogging WebSocket protocol)

[15:41:54.0000] <Hixie>
(then anyone who wants to microblog can just use that protocol, regardless of the implementation)

[15:41:58.0000] <brainproxy>
websockets are nice for some things, but....

[15:42:12.0000] <Hixie>
things like microblogging APIs? :-)

[15:42:34.0000] <brainproxy>
websockets are stateful

[15:42:37.0000] <brainproxy>
for one

[15:42:51.0000] <brainproxy>
different paradigm

[15:44:16.0000] <brainproxy>
anyway, i'd like to see the option to use absolute URIs as rels, per rfc 5988 and the direction the w3c is going ... guess maybe whatwg isn't going that direction

[15:44:39.0000] <brainproxy>
got to get back to work, but thanks for chatting w/ me about it :)


2012-09-16
[01:09:04.0000] <BgoosiBeo>
7cvb

[03:29:05.0000] <AryehGregor>
Is this the right XHR spec?  http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html

[04:25:22.0000] <AryehGregor>
annevk, do we have a place to put DOM tests if the W3C spec is supposed to be ignored?

[04:26:17.0000] <AryehGregor>
/me is not really enthusiastic the spec being forked, given that there was a public-domain version anyway -- who cares who owns the copyrights?

[11:26:33.0000] <JonathanNeal>
Is there a website that shows people good practice on how to markup different things, from documents to apps, like articles, contact lists, playlists, wikis, etc?

[13:11:20.0000] <annevk>
hmm, aryeh left


2012-09-17
[18:51:05.0000] <Benvie>
JonathanNeal: http://www.html5doctor.com

[02:09:17.0000] <jgraham>
Anyone on mozirc fancy asking jlebar to share his test cases?

[02:10:23.0000] <jgraham>
(also is it me or is he devaluing the brand of evil.com; using it in examples that are not really sites doing evil-evil things, just somewhat complex / unpleasant)

[02:12:17.0000] <jgraham>
(althopugh I guess there is actually a security bug in the second example)

[02:12:37.0000] <jgraham>
(but only because of firefox having a broken implementation)

[02:58:03.0000] <annevk>
Hixie: ping

[05:29:46.0000] <annevk>
so thus far I thought no browser other than Chrome unescaped

[05:29:52.0000] <annevk>
but apparently for certain sequences they do?

[05:29:55.0000] <annevk>
e.g. http://example.com/foo/%2e./%2e%2e/.%2e/%2e.bar

[05:30:15.0000] <annevk>
becomes http://example.com/%2e.bar in Gecko

[05:34:34.0000] <annevk>
hmm only Chrome and Gecko it seems

[06:37:30.0000] <annevk>
given e.g. /test/test

[06:37:47.0000] <annevk>
would you rather have .dirs = ["test"] and .filename = "test"

[06:37:57.0000] <annevk>
or .path = ["test", "test"]

[06:38:09.0000] <annevk>
 /test/test/ would be .path = ["test", "test", ""]

[06:38:23.0000] <annevk>
could still have filename as returning .path[-1]

[06:38:55.0000] <annevk>
the .path thing seems somewhat more elegant

[06:41:05.0000] <darobin>
all of the above

[06:52:12.0000] <smaug____>
jgraham: who @Opera might have something to say about Filesystem API ?

[06:53:46.0000] <zewt>
people who post "list etiquette" posts to mailing lists i suppose didn't learn the "don't be condescending" item of list etiquette

[06:54:30.0000] <zewt>
annevk: usually "/test/test" and "/test/test/" are equivalent--there are exceptions but having them parse differently would be strange

[06:55:01.0000] <annevk>
zewt: they're usually different

[06:55:11.0000] <annevk>
e.g. replace test with test.html

[06:55:24.0000] <zewt>
i guess if it's for urls and not filename paths (which is what it looked like you meant) you'd want them distinguishable

[06:57:14.0000] <zewt>
hard to do anything "nice" when you don't actually know if the last element is a filename or directory element

[06:58:09.0000] <zewt>
i'd lean towards just .path too

[07:03:35.0000] <zewt>
presumably you'd want to distinguish having a path, eg. [""] (http://foo.com/) with not having a path at all (http://foo.com, []); seems like that would also be awkward with .filename (need to allow it to be null or something)

[07:09:46.0000] <annevk>
actually there will always be a slash there

[07:09:51.0000] <annevk>
so you don't need that

[07:12:43.0000] <zcorpan>
annevk: are you adding more url decomposition idl attributes?

[07:13:00.0000] <annevk>
zcorpan: maybe

[07:13:06.0000] <annevk>
zcorpan: this is mostly the internal API for my parser for now

[07:13:14.0000] <annevk>
zcorpan: to easily implement "." and ".."  segments

[07:13:18.0000] <annevk>
for hierarchical URLs

[07:13:19.0000] <zcorpan>
ok

[07:13:30.0000] <annevk>
but some of it might be cool to expose

[07:14:27.0000] <zcorpan>
i don't see much point if we have ability to resolve a url to another

[07:15:15.0000] <zcorpan>
do popular javascript libraries have stuff in this area?

[07:47:07.0000] <annevk>
I was planning to look into that at some point

[07:47:31.0000] <annevk>
abarth did add .filename

[08:07:19.0000] <annevk>
https://github.com/annevk/url/blob/master/url.js is my code

[08:16:52.0000] <annevk>
note: does not do host/ip mess

[08:27:28.0000] <niloy>
why dont browsers provide api to list all listeners attached to a DOM node?

[08:28:17.0000] <annevk>
search public-webapps archives or www-dom

[08:28:57.0000] <niloy>
search on google?

[08:30:23.0000] <annevk>
I don't really care where you do it

[08:33:58.0000] <annevk>
ah

[08:34:05.0000] <annevk>
my URL parser also does not deal with encoding for query

[08:34:17.0000] <annevk>
that's kinda hard to support in JavaScript

[08:34:39.0000] <annevk>
without implementing all the encodings that is :)

[08:40:10.0000] <Ms2ger>
annevk, jsbell's encoder thing ;)

[08:40:36.0000] <annevk>
Ms2ger: yeah indeed, but since this parser is mostly for research purposes I don't really see the point

[08:40:50.0000] <annevk>
Ms2ger: but if you want to make it work, be my guest

[08:41:04.0000] <Ms2ger>
Heh

[08:41:13.0000] <annevk>
next step is rewriting this JavaScript into English

[08:41:27.0000] <annevk>
and then I guess I'll have another look at host/IP

[08:44:29.0000] <jgraham>
I see being on holiday didn't cheep Ms2ger up any :)

[08:44:34.0000] <jgraham>
*cheer

[08:45:22.0000] <Ms2ger>
Hmm? :)

[08:45:48.0000] <jgraham>
public-webapps

[08:47:00.0000] <Ms2ger>
Ah, always a cheery place

[09:07:56.0000] <annevk>
heh

[09:24:33.0000] <Ms2ger>
jgraham, though I don't know how you expected me to be cheery after wading through my email backlog ;)

[09:53:26.0000] <smaug____>
Ms2ger: that is why holiday isn't good for health

[09:54:09.0000] <smaug____>
reading the emails after holiday sucks all the energy

[09:57:20.0000] <Ms2ger>
Should've gone for a sauna instead

[09:58:06.0000] <smaug____>
/me is waiting for sauna to be ready :)

[10:28:23.0000] <annevk>
just mark email as read :)

[11:12:37.0000] <annevk>
rwaldron: thanks, seems I forgot a comma before IDNAToASCII

[11:13:18.0000] <annevk>
rwaldron: not too concerned about the global URL object; this is just a research thingie for now

[11:25:10.0000] <Hixie>
annevk: pong

[12:06:25.0000] <jgraham>
Dammit I forgot to reply to smaug

[13:05:33.0000] <annevk>
Hixie: dealt with it already; wiki account issue

[13:05:48.0000] <annevk>
or at least, I hope it is okay this time around

[14:38:37.0000] <Hixie>
can anyone think of ways to cause a document to fire more than one unload event?

[14:38:53.0000] <Hixie>
other than starting a navigation while running unload

[14:39:09.0000] <Hixie>
we've already killed running document.open() during unload

[14:42:35.0000] <Hixie>
back() eventually fires unload, but it does so on a task so i don't think you can have that one happen after another

[14:43:34.0000] <Hixie>
ok so to block the double unload from navigation i just need to detect if we're going back while navigating, and if so, not do the unload dance


2012-09-18
[17:17:13.0000] <Hixie>
jgraham: when you do tests for unload, one thing to see is what happens on pagehide and beforeunload, which fire around the same time

[20:39:35.0000] <Hixie>
good times, the w3c html wg editors have now changed the specs to contain the lies I had removed years ago :-)

[20:41:26.0000] <Hixie>
hahaha and they removed the guarantee that they'll reply to feedback

[20:42:38.0000] <Hixie>
and they added a note saying their document shouldn't be cited

[20:42:42.0000] <Hixie>
well, can't argue with that one :-P

[21:19:17.0000] <zewt>
sounds like typical "phew finally we're rid of that guy standing in our way let's do everything we've ever wanted"

[21:20:22.0000] <zewt>
similarly i wonder if somebody who used to work at google and kept the search page sane left a couple years ago, since all of a sudden all kinds of horrible nonsense started showing up on the search, the lack of which was what defined google search as non-crappy for so long

[00:34:07.0000] <annevk>
GPHemsley: thanks for the report; should be fixed now, but I should really find a better solution

[00:34:24.0000] <annevk>
GPHemsley: I don't really know what the problem is unfortunately, I think something goes wrong when writing the cache to disk

[01:50:53.0000] <Stevef>
hixie: which lies have been added back into w3c spec?

[02:03:44.0000] <annevk>
Stevef: presumably one can find out by looking at the HTML WG commit log, however I have no idea how their github setup works

[02:04:10.0000] <Stevef>
annevk: sure, just curious

[02:05:08.0000] <annevk>
me too

[02:05:09.0000] <Stevef>
annevk: i did have a look but couldn't see anything of note

[02:05:19.0000] <annevk>
pointer?

[02:17:37.0000] <Stevef>
annevk: i just looked at the status of this document section in the spec, presuming it was soemething there, can't make any sense out of github

[02:19:40.0000] <annevk>
is http://dev.w3.org/html5/spec/ still the latest?

[02:20:01.0000] <annevk>
it has today's date, but also mentions the WHATWG a fair bit and does not mention github...

[02:20:12.0000] <annevk>
oh well, whatever

[02:20:34.0000] <darobin>
annevk: I don't think the header material has been updated much

[02:20:57.0000] <darobin>
it won't be finalised before the issue attached to it is resolved anyway

[02:21:22.0000] <darobin>
http://dev.w3.org/html5/spec/ is updated every hour or so with what's in GH IIRC

[02:21:53.0000] <annevk>
darobin: where can I see what's been committed in github limited to the W3C copy?

[02:22:03.0000] <darobin>
I think that at some point later on I'll write up a history section so I can introduce plenty of new lies of my own

[02:22:33.0000] <darobin>
annevk: you mean without the commits imported from what?

[02:22:55.0000] <annevk>
darobin: yeah I guess

[02:23:15.0000] <darobin>
mmmm, I'm not sure the GH interface can filter that

[02:23:24.0000] <annevk>
darobin: or with, assuming they are easily distinguishable

[02:23:25.0000] <darobin>
/me multitasking atm, can't check

[02:23:39.0000] <annevk>
no rush, not even a real need, just curious :)

[02:23:41.0000] <darobin>
annevk: you can look at the commits tab on the repo's interface

[02:24:00.0000] <annevk>
oh so just https://github.com/w3c/html/commits

[02:24:01.0000] <darobin>
otherwise, I'm pretty sure you can do filters using git log, but it's "Work"

[02:24:02.0000] <annevk>
okay

[02:25:27.0000] <annevk>
ah, Hixie was presumably referring to the edits by Microsoft

[02:25:29.0000] <annevk>
e.g. https://github.com/w3c/html/commit/b5fde23fa2855418a281cddefaf672e05379a77f

[02:27:27.0000] <annevk>
https://github.com/w3c/html/commit/9652303ca313a5e2b5cd1cb80dbd1deac713ac55 also changed something not mentioned in the commit

[02:28:39.0000] <annevk>
I guess techtoons is from Microsoft too?

[02:29:26.0000] <annevk>
gotta go

[03:08:54.0000] <Stevef>
FYI created twitter account with feed of W3C HTML commits https://twitter.com/HTML_Commits

[03:22:40.0000] <beowulf>
hey, does anyone know of examples of AT/screen readers that have trouble with a page that only use H1s?

[03:24:27.0000] <beowulf>
and is there a better place to ask my question? :)

[03:31:00.0000] <smaug____>
moznet's #accessibility might be a better place to ask

[03:54:16.0000] <Stevef>
beowulf: what do you mean by trouble?

[03:56:29.0000] <Stevef>
beowulf: for AT that does not support the HTML5 concept of heading levels the structure will be flattened, 1 AT currently supports the HTML5 outline - JAWS 13+ , but its flaky

[03:59:50.0000] <beowulf>
Stevef: that's what I mean, ya. only one works, hmm. what kind of problems does a flat structure bring?

[04:00:50.0000] <beowulf>
Stevef: is this a good list for me to work off for trying stuff out? http://en.wikipedia.org/wiki/List_of_screen_readers

[04:03:20.0000] <Stevef>
beowulf: it means that AT users will not be able to understand the structure as well as when the levels are correctly exposed, when level is exposed users can navigate by level, it helps them understand the relationship between content blocks

[04:05:49.0000] <Stevef>
beowulf: I would suggest using NVDA on windows, VoiceOver on Mac OSx, iOS, Orca on linux

[04:06:40.0000] <beowulf>
Stevef: cheers!

[04:07:56.0000] <Stevef>
beowulf: this http://www.paciellogroup.com/blog/2012/02/rough-guide-browsers-operating-systems-and-screen-reader-support/ may also be helpful in regards to which browsers to use

[04:10:10.0000] <Ms2ger>
krijn, down again?

[04:10:20.0000] <krijn>
Yeh

[04:10:29.0000] <krijn>
Moving again :/

[04:10:41.0000] <krijn>
Hopefully up again tonight, faster

[04:11:27.0000] <Ms2ger>
\o/

[04:24:11.0000] <smaug____>
good that there is the backup logging

[04:32:39.0000] <sedovsek>
Hey! I've got a weird rendering issue on Safari6 when it comes to translate3d transforms

[04:32:47.0000] <sedovsek>
http://shrani.si/f/2L/xI/3AJuuVvj/screen-shot-2012-09-18-a.jpg

[04:32:59.0000] <sedovsek>
(It duplicates/translates the image and keeps the original intact)

[04:56:05.0000] <smaug____>
sedovsek: file a bug on Apple ?

[04:56:48.0000] <sedovsek>
smaug____: I might...

[04:56:56.0000] <sedovsek>
http://shrani.si/f/3v/Oy/4ufaLtAr/screen-shot-2012-09-18-a.jpg - more detailed example.

[04:57:15.0000] <sedovsek>
After I've changed the img source, it changes, but the origin stays at the same position.

[04:57:28.0000] <sedovsek>
The origin = 8.png, which was replaced with 2.png.

[04:57:53.0000] <smaug____>
"might". browser vendors need the bugs filed to be able to fix them ;)

[04:59:49.0000] <sedovsek>
True, true.

[05:12:19.0000] <cabanier>
scribenick: cabanier

[05:12:48.0000] <cabanier>
topic:  Dynamic document loading

[05:12:59.0000] <cabanier>
link: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/MappingTopics

[05:13:24.0000] <jgraham>
cabanier: Wrong channel?

[05:13:42.0000] <heycam>
yes :)

[05:21:10.0000] <annevk>
hmm

[05:21:30.0000] <annevk>
the .hash and .search part of the URL API suck

[05:23:14.0000] <annevk>
for a URL http://example.org/?# both will return the empty string

[05:23:29.0000] <annevk>
but they also return the empty string for http://example.org/

[05:23:44.0000] <annevk>
and setting them to the empty string for the first URL will not remove ? and # from the URL

[06:02:56.0000] <annevk>
matjas: thanks for the punycode link, going to take a look now

[06:04:25.0000] <annevk>
matjas: mapDomain does not seem to follow IDNA separator requirements

[06:11:59.0000] <annevk>
matjas: typo in https://github.com/bestiejs/punycode.js/blob/master/punycode.js#L201

[06:21:08.0000] <annevk>
matjas: also, what's BestieJS?

[06:27:31.0000] <darobin>
is there any spec that gives any ounce of clarity as to whether redirects should be honoured on DELETE?

[06:27:42.0000] <Ms2ger>
I'd default to "no"

[06:28:02.0000] <darobin>
well, given that this is HTTP that would be my default too

[06:28:14.0000] <darobin>
but hey it's not like we've got stuff built on top of this

[06:28:47.0000] <darobin>
/me writes a test to figure out if browsers are as random as CLI clients for this

[06:29:35.0000] <miketaylr>
annevk: it's more or less a collection of scripts that don't suck

[06:29:58.0000] <annevk>
miketaylr: heh

[06:31:31.0000] <annevk>
so the problem with this library is its toASCII method name

[06:31:40.0000] <annevk>
which seems to indicate it implements http://tools.ietf.org/html/rfc3490#section-4.1 but it really doesn't

[06:32:17.0000] <miketaylr>
annevk: ah, here we go https://github.com/bestiejs/bestiejs/blob/master/README.md

[06:32:23.0000] <annevk>
e.g. ™.com -> tm.com

[06:32:27.0000] <annevk>
I doubt it does that

[06:37:01.0000] <annevk>
right

[06:37:56.0000] <annevk>
see http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1775 and compare with browsers

[06:38:08.0000] <annevk>
of course it never claimed to implement that

[06:50:09.0000] <annevk>
hmm

[06:50:16.0000] <annevk>
this might be something IDNA2008 changed

[06:50:22.0000] <annevk>
ffs

[07:04:38.0000] <annevk>
not sure why I forgot about http://unicode.org/reports/tr46/

[07:12:32.0000] <annevk>
oh, Gecko does not even have IDNA2008 https://bugzilla.mozilla.org/show_bug.cgi?id=479520

[07:12:43.0000] <annevk>
Opera does since 11.60

[07:12:52.0000] <annevk>
yay for domain names I guess

[07:15:50.0000] <zcorpan>
having it breaks http://tinyarrows.com/

[07:16:13.0000] <annevk>
ooh

[07:16:18.0000] <annevk>
Opera does not do UTS 46

[07:16:54.0000] <annevk>
in Opera ™.com does indeed become xn--y2g.com

[07:17:28.0000] <annevk>
they should have taken this a bit more seriously, I mean this is not like XML 5th Edition

[07:17:33.0000] <annevk>
this is stuff that's actually used

[07:19:03.0000] <zcorpan>
i guess idna2008 needs to be changed since there are urls on the web expecting some characters to work (tinyarrows is what i know about)

[07:20:34.0000] <annevk>
do you know if it would work if you implemented UTS 46?

[07:21:23.0000] <annevk>
afaict IDNA2008 is pure Punycode without some kind of filtering step beforehand (NAMEPREP in IDNA2003)

[07:22:16.0000] <annevk>
Opera had the same problem with not recognizing certain label separators such as U+3002

[07:22:22.0000] <zcorpan>
i don't know, i haven't read much about this

[07:22:27.0000] <annevk>
required in IDNA2003 and also in UTS 36

[07:22:31.0000] <annevk>
euh 46

[07:24:48.0000] <zcorpan>
DSK-235264

[07:26:20.0000] <annevk>
oh Yngve

[07:37:48.0000] <annevk>
can anyone tell me where http://faß.de/ goes in IE?

[07:45:12.0000] <zcorpan>
ie8 on XP goes to www.bayern-fass.de

[07:46:06.0000] <annevk>
thanks, but I think IE8 is too old, IDNA2008 is from end of 2010

[07:46:31.0000] <darobin>
ah, I'm glad to see W3C isn't the only organisation with highly sensible year-based naming conventions

[07:47:22.0000] <zcorpan>
/me boots ubuntu again

[07:48:42.0000] <annevk>
darobin: or alone in pushing out updates to standards without ensuring all stakeholders follow them

[07:49:01.0000] <darobin>
wait, there are stakeholders in standards?

[07:49:10.0000] <darobin>
you're making that up...

[07:49:39.0000] <annevk>
maybe

[07:55:19.0000] <jgraham>
Good way to deal with vampires

[07:55:31.0000] <jgraham>
And I'mn pretty sure there are lots of them involved with standards

[08:05:18.0000] <darobin>
oh yes, the famed Buffy The Stakeholder

[08:09:28.0000] <annevk>
short summary: http://annevankesteren.nl/2012/09/idna

[08:18:39.0000] <tomasf>
annevk: what does "hierarchical URLs" mean? why do these things not apply to URLs with other schemes?

[08:19:04.0000] <annevk>
tomasf: data URLs don't have a domain name

[08:19:23.0000] <annevk>
neither do javascript URLs

[08:20:08.0000] <tantek>
hey annevk - I have a comment about a www-archive post of yours

[08:20:15.0000] <tomasf>
annevk: oh, right. I see

[08:20:20.0000] <annevk>
tantek: go ahead

[08:20:22.0000] <tantek>
this one: http://lists.w3.org/Archives/Public/www-archive/2012Aug/0028.html

[08:20:29.0000] <tantek>
I understand your perspective in that thread

[08:20:31.0000] <annevk>
tomasf: I guess mailto might be an edge case

[08:20:34.0000] <tantek>
though I come to a different conclusion

[08:21:18.0000] <annevk>
tantek: you mean you read the Agreement in a different way?

[08:21:20.0000] <tantek>
as quoted in your email from http://www.w3.org/Consortium/Legal/2007/06-invited-expert.html#L118

[08:21:25.0000] <tantek>
" «Branching» is one example of a non-permissible derivative work. "

[08:21:34.0000] <annevk>
tantek: because the W3C agrees with my reading afaict

[08:21:40.0000] <tantek>
in the context there, it implies branching *outside* W3C

[08:21:48.0000] <tantek>
in my opinion that leads to only one logical conclusion

[08:21:56.0000] <tantek>
 Since W3C doesn't want branches of specs *outside* of W3C, it's W3C's WDs (etc.) that themselves become branches.

[08:22:10.0000] <tantek>
while the main "trunk" lives elsewhere with a more liberal license

[08:22:24.0000] <tantek>
this has already happened with W3C HTML5 branching from WHATWG HTML.

[08:22:38.0000] <annevk>
yeah, but it gets hazy when you get contributions from others

[08:22:54.0000] <tantek>
so you only allow contributions to others to the main "trunk" that lives outside W3C

[08:23:13.0000] <tantek>
but yes, it may get hazy if other contributors contribute directly to a W3C branch of a spec

[08:23:26.0000] <tantek>
harder to incorporate those into trunk

[08:23:36.0000] <tantek>
due to the branch license

[08:24:06.0000] <annevk>
and since using it in that manner would not match their intent, they could still try to find ways to make it difficult

[08:24:10.0000] <annevk>
I rather have it solved

[08:24:12.0000] <tantek>
in the example of Fullscreen, since we're the only contributors I don't see a problem with continuing with trunk development being CC0+OWFa

[08:24:59.0000] <tantek>
it will take quite a lot of time to match whatever "intent" happens to be strong enough to motivate clarification, and also take such time to "make it difficult"

[08:25:10.0000] <darobin>
actually, I don't think that there's an intractable problem with people contributing to a W3C branch — you just need to make sure that they sign the RF commitment (which is separate from the copyright issue)

[08:25:44.0000] <darobin>
the problem is more in moving a spec that has already been published under W3C © to an open repo

[08:25:45.0000] <Ms2ger>
I don't think there's an intractable issue either

[08:25:45.0000] <tantek>
I'm fine to act within this particular reading of "branching not allowed" (thus W3C works themselves become branches)

[08:25:52.0000] <Ms2ger>
You just don't work at the W3C

[08:26:12.0000] <darobin>
tantek: that said I agree with annevk though, it would be better to get this fixed

[08:26:15.0000] <tantek>
and simultaneously pursue the issue of overturning such wording about branching at the AC/AB level

[08:26:22.0000] <tantek>
darobin - agreed long term better to get this fixed

[08:26:41.0000] <tantek>
however, I see nothing that prevents acting this way in the "short term" (in the mean while)

[08:26:42.0000] <darobin>
the way of getting movement on this is not the AB at this point

[08:27:03.0000] <darobin>
but it should be possible to mount an AC push — it just needs to be properly coordinated and politically well-organised

[08:27:17.0000] <tantek>
there's no urgency for a "fix"

[08:27:30.0000] <tantek>
because the "problem" just results in the consequence that W3C works themselves become branches.

[08:28:01.0000] <darobin>
I agree that we can largely make this work in the short term

[08:28:21.0000] <tantek>
therefore only those that care about *that* as a "problem" (that W3C works themselves become branches) need to bother with putting energy into an actual fix.

[08:28:31.0000] <tantek>
in the mean time, meh

[08:28:47.0000] <tantek>
all that wording does is encourage trunk spec development outside of W3C

[08:28:53.0000] <annevk>
tantek: my work is https://github.com/whatwg now

[08:29:20.0000] <darobin>
tantek: indeed — though that wasn't foreseen when the wording was crafted

[08:29:32.0000] <annevk>
tantek: when the W3C Agreement is changed I'm happy to reconsider

[08:30:24.0000] <annevk>
tantek: btw, if you want access, do you have a github account?

[08:30:30.0000] <tantek>
annevk, thanks annevk - I will treat https://github.com/whatwg/fullscreen as trunk for Fullscreen

[08:30:40.0000] <tantek>
that would be great

[08:31:00.0000] <annevk>
ah, tantek is you :)

[08:31:03.0000] <tantek>
:)

[08:31:21.0000] <annevk>
added you

[08:31:30.0000] <darobin>
annevk: given that setup, why bother with IE status in the first place? you can work on the lists, there are no calls, you just commit to some other repo and someone ships to TR now and then...

[08:31:58.0000] <annevk>
darobin: I wanted to bother because I was also a Chair

[08:32:01.0000] <darobin>
if you want to attend f2fs it's a chair's call anyway

[08:32:09.0000] <darobin>
oh right, the notifications stuff

[08:32:34.0000] <darobin>
does that group really need a chair? :)

[08:32:37.0000] <tantek>
annevk, I'm also happy to reconsider when the W3C IE Agreement is changed

[08:32:42.0000] <annevk>
darobin: and some companies are happier with W3C standards and I don't care strongly either way

[08:33:09.0000] <tantek>
but until then, that wording in the agreement makes a strong case for trunk spec development outside-of-W3C, and I will communicate that as such to anyone at W3C that asks.

[08:33:14.0000] <darobin>
annevk: sure — but my point is that those can still be W3C standards without you being an IE, the only thing that blocks is chairing WebNotifs

[08:33:30.0000] <annevk>
darobin: well and somebody doing the forking

[08:33:36.0000] <darobin>
tantek: you coming to TPAC?

[08:33:40.0000] <tantek>
/me notices that https://github.com/whatwg doesn't publicize members, is that deliberate?

[08:33:51.0000] <darobin>
annevk: there doesn't need to be any forking...

[08:33:51.0000] <annevk>
tantek: oh no, we can do that

[08:33:53.0000] <tantek>
darobin - trying to make travel plans :(

[08:34:01.0000] <tantek>
/me hates dealing with travel plans

[08:34:43.0000] <annevk>
darobin: need to change the boilerplate and such :)

[08:34:44.0000] <darobin>
wasn't the semantic web supposed to make travel plans automatic?

[08:34:47.0000] <tantek>
/me is considering notifying W3C that they ought to consider Halloween a religious holiday to be avoided for those that celebrate it as such.

[08:34:56.0000] <darobin>
annevk: that's, like, nothing :)

[08:35:13.0000] <darobin>
in fact if you're consistent across specs we could probably set it up once and for all

[08:35:28.0000] <darobin>
then for TR snapshots you just need a "document contact" — nothing says it has to be the editor

[08:35:48.0000] <darobin>
tantek: well, we celebrate it as such with a good game of Werewolk :)

[08:36:03.0000] <annevk>
darobin: works for me :)

[08:36:38.0000] <darobin>
annevk: well if it works for you, I reckon you can make that the plan :)

[08:36:41.0000] <darobin>
(and come to TPAC)

[08:37:31.0000] <darobin>
as for chairing WebNotifs, I guess plh can find someone else — it doesn't seem like a highly political group

[09:04:57.0000] <tantek>
annevk - how do I link to https://github.com/whatwg/fullscreen/blob/master/Overview.html so that it views as a web page, not as raw HTML?

[09:05:22.0000] <annevk>
tantek: http://fullscreen.spec.whatwg.org/

[09:05:35.0000] <annevk>
tantek: it updates automatically on push

[09:05:39.0000] <tantek>
thanks

[09:09:07.0000] <tantek>
is W3C bugzilla your preferred issue tracking mechanism for Fullscreen, or is that just one input?

[09:09:24.0000] <tantek>
this: https://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWG&component=Fullscreen&resolution=---

[09:10:24.0000] <annevk>
it's easier to track

[09:10:31.0000] <annevk>
but the last commit was based on an email thread

[09:10:57.0000] <tantek>
right - saw the thread

[09:33:26.0000] <JonathanNeal>
If a polyfill is code that fills in missing gaps of (existent) functionality, what would you code that fills in missing gaps of (non-existent) functionality? Still a polyfill?

[09:34:41.0000] <JonathanNeal>
An example of this non-existent polyfill would be https://github.com/scottjehl/picturefill (from before it was specced)

[09:35:50.0000] <JonathanNeal>
And I would further define it as "proposed functionality".

[09:35:51.0000] <jgraham>
"javascript library"

[09:36:15.0000] <JonathanNeal>
all right. seemed like it was a little more specific than that.

[09:37:15.0000] <jgraham>
"javascript library that makes dangerous assumptions about future markup design and will likely provide a back-compat problem when new features are added to browsers"

[09:37:50.0000] <jgraham>
(although using <div> and data- is fine)

[09:37:59.0000] <jgraham>
(so that example is probably OK)

[09:42:41.0000] <JonathanNeal>
Bah. Wikipedia has it written that "polyfills can also be used to add entirely new functionality to browsers" http://en.wikipedia.org/wiki/Polyfill

[09:43:40.0000] <JonathanNeal>
I'm geeking over semantics again, but that seems like too liberal an interpretation. That would make all javascript libraries a kind of polyfill, jgraham. :(

[09:45:35.0000] <JonathanNeal>
They are really more like "javascript spoilers".

[09:59:35.0000] <annevk>
it's just a script...

[10:03:56.0000] <JonathanNeal>
so is a polyfill, so is a library.

[11:18:01.0000] <Hixie>
talk about missing the point. search for backingStoreRatio on www.html5rocks.com/en/tutorials/canvas/hidpi/ and weep at how people miss the point of prefixes.

[11:21:17.0000] <Ms2ger>
There's a point to prefixes?

[11:21:53.0000] <Hixie>
there's a point

[11:21:59.0000] <Hixie>
it's a misguided point, but it's a point nonetheless :-)

[11:22:15.0000] <Ms2ger>
Zing

[11:23:08.0000] <jwalden>
they seemed to work better when web developers weren't following browser developments so closely, so you had fewer, and more conscientious, developers using them

[11:23:41.0000] <Hixie>
the ones using them are still not following development, as clearly shown by the blog post above

[11:24:21.0000] <Hixie>
in other news i have NO IDEA how to spec this nonsense with unload/pagehide/beforeunload/navigation/traversal

[11:25:27.0000] <Hixie>
http://www.whatwg.org/issues/#navigation

[11:35:01.0000] <rniwa>
Hixie: navigation within the navigation?

[11:39:24.0000] <Ms2ger>
Yo dawg

[11:44:08.0000] <Hixie>
rniwa: for instance

[11:46:08.0000] <jgraham>
Hixie: That makes two of us :(

[11:46:50.0000] <Hixie>
what happens if in a subframe pagehide the page navigates a sibling iframe, should that sibling get two unloads? one?

[11:46:57.0000] <Hixie>
what if you do it in the beforeunload?

[11:47:13.0000] <Hixie>
what if you are going back, and in that unload you navigate a subframe?

[11:47:25.0000] <Hixie>
plus i really don't understand the compatibility constraints

[11:47:57.0000] <Hixie>
i'm tempted to file a bug on the htmlwg, paste in all the feedback, and wait for darobin to fix it, but i know what would really happen is they'd reject it and say that if i disagree i should write a CP

[11:48:01.0000] <Hixie>
so that isn't helpful

[11:48:02.0000] <rniwa>
Hixie: i don't think chrome fires beforeunload even…

[11:48:12.0000] <Hixie>
rniwa: in general? or in that case?

[11:48:18.0000] <rniwa>
Hixie: in general.

[11:48:34.0000] <Hixie>
pretty sure it fires it in general

[11:48:40.0000] <jgraham>
Yeah, it really does

[11:49:13.0000] <othermaciej>
q+

[11:49:14.0000] <darobin>
hmmm, if it's a real bug I doubt it would be rejected

[11:49:27.0000] <rniwa>
oh oops, yeah we do fire.

[11:49:28.0000] <darobin>
I reserve the right to defer it to 2016 though ;-)

[11:49:34.0000] <othermaciej>
oops

[11:49:37.0000] <jgraham>
I'm sort of hopeful that the compat. constraints are "do what either Gecko or WebKit already does and you will be fine"

[11:49:41.0000] <darobin>
wrong channel :)

[11:49:43.0000] <rniwa>
Hixie, jgraham there is a bug…

[11:50:21.0000] <jgraham>
The problem is I don't know how to write down an algorithm that is sure to do what Gecko or WebKit already does

[11:50:26.0000] <Hixie>
darobin: imho this is a CR blocking bug since you couldn't exit CR with the spec incorrectly describing this (unless you violate w3c process like everyone else, of course)

[11:50:43.0000] <Hixie>
jgraham: yeah i don't even understand what they do

[11:51:00.0000] <darobin>
Hixie: your view of process is highly literalist :)

[11:51:01.0000] <Hixie>
jgraham: and what they do is different and bz says what webkit does is not compatible enough for gecko

[11:51:18.0000] <jgraham>
Indeed

[11:51:19.0000] <Hixie>
darobin: my view is that the process should either be followed or it's pointless

[11:51:32.0000] <jgraham>
My view is that it's pointless :)

[11:51:37.0000] <Hixie>
well, yes

[11:51:42.0000] <Hixie>
but then we should dump it

[11:51:51.0000] <Hixie>
not pretend to follow it and say that we're just being "not literalist"

[11:52:01.0000] <jgraham>
(I think blocking patent policy on the navigation algorithm being right is absurd)

[11:52:06.0000] <Hixie>
agreed

[11:52:18.0000] <jgraham>
(I think the navigation algorithm being right is high priority for the spec)

[11:52:23.0000] <Hixie>
agreed

[11:52:32.0000] <Hixie>
i just wish i understood what "right" was :-P

[11:53:01.0000] <darobin>
/me process *shrug*, just interested in getting shit done, and getting RF out o fit :) 

[11:53:27.0000] <Hixie>
getting shit done by delaying it til 2016? :-)

[11:53:40.0000] <rniwa>
as long as the navigation algorithm doesn't involve longdesc, we should be able to spec in the next few years :)

[11:53:41.0000] <darobin>
2016 is, like 5.7 or something :)

[11:54:08.0000] <Hixie>
"high priority" is hopefully faster than 4 years

[11:54:23.0000] <darobin>
rniwa: I think we should add longdesc actually — it's important to be able to get a longer description of the reason why you're navigating

[11:55:34.0000] <darobin>
/me dusts out his "This is a joke" emoticon set, seems useful

[11:55:35.0000] <Ms2ger>
iframe longdesc?

[11:55:45.0000] <darobin>
History.longdesc too!

[11:55:56.0000] <rniwa>
Hixie: not sure… this P1 bug in WebKit has been open since 2005: https://bugs.webkit.org/show_bug.cgi?id=3710

[11:56:02.0000] <Hixie>
hah

[11:57:14.0000] <Ms2ger>
Pah

[11:57:27.0000] <Ms2ger>
We've got bugs open that were marked P1 in 2002

[11:57:27.0000] <rniwa>
darobin: should it take an URL or string?

[11:57:36.0000] <Ms2ger>
rniwa, list of URLs

[11:57:41.0000] <Ms2ger>
Like profile

[11:57:47.0000] <darobin>
URLs? OMG, nevarh!

[11:57:53.0000] <darobin>
it should be an XRI

[11:57:55.0000] <jgraham>
Hixie: It wasn't clear to me that the WebKit behaviour wasn't compatible.

[11:58:10.0000] <Hixie>
jgraham: yeah the bugs are 404 now

[11:58:16.0000] <jgraham>
Indeed

[11:58:18.0000] <Hixie>
jgraham: so, hard to say

[11:58:24.0000] <darobin>
rniwa: lovely bug that — what kind of caret do you display when you have a ligature glyph that spans directional boundaries?

[11:58:46.0000] <rniwa>
dunno

[11:58:47.0000] <Hixie>
jgraham: what i'd LIKE to say is "while in beforeunload, unload, or pagehide, you cannot navigate anything"

[11:58:50.0000] <jgraham>
darobin: Is that even possible?

[11:59:00.0000] <Hixie>
jgraham: in the entire event loop group

[11:59:04.0000] <Hixie>
jgraham: just like we do with alert()

[11:59:07.0000] <darobin>
jgraham: you can try :)

[11:59:11.0000] <Hixie>
pretty sure that's a non-starter though

[11:59:15.0000] <jgraham>
Hixie: Yeah, that does have the appeal of simplicity

[11:59:17.0000] <rniwa>
Hixie: that might be incompatible with the Web...

[11:59:31.0000] <Hixie>
but a boy can dream

[11:59:40.0000] <rniwa>
Hixie: certainly.

[11:59:50.0000] <Ms2ger>
Better dream of trains, those can come true :)

[12:00:45.0000] <darobin>
not navigating in beforeunload/unload would break all those pr0n sites that try to keep people from hitting back I believe

[12:00:51.0000] <darobin>
(or so I'm told, uh)

[12:01:58.0000] <Hixie>
speaking of trains, wtf is with the 60215 being out of stock at the factory

[12:02:08.0000] <Hixie>
it's been months now

[12:02:15.0000] <Hixie>
grrr

[12:02:58.0000] <Hixie>
jgraham: what does webkit do, just stop navigation in the bc being unloaded and its descendants and ancestors?

[12:09:30.0000] <jgraham>
Hixie: I don't recall what happens in descendants/ancestors

[12:09:59.0000] <Hixie>
what about multiple navigations started from different unload handlers all fired as part of the same dispatch?

[12:11:18.0000] <jgraham>
In the same document?

[12:13:26.0000] <jgraham>
Something like http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1776 ?

[12:13:47.0000] <Hixie>
yeah

[12:14:09.0000] <Hixie>
i do like this webkit policy of not doing navigation from unload

[12:14:10.0000] <jgraham>
Chrome ends up at the document in the link, firefox at the image

[12:14:24.0000] <Hixie>
and how many unloads fire?

[12:14:50.0000] <Hixie>
one of the big complications is what "cancel previous navigation" means when you're in the middle of dispatching unloads and pagehides

[12:14:54.0000] <Hixie>
or beforeunloads

[12:15:14.0000] <Hixie>
do you finish running the unload algorithm before killing the navigation?

[12:15:51.0000] <Hixie>
i'm thinking of speccing that hte nav algorithm launches beforeunload/unload algorithms async, then blocks on those algorithms, so that canceling navigation never actually cancels the beforeunload/unload algorithms

[12:16:16.0000] <Hixie>
but the real problem is how to deal with hiearchies

[12:16:21.0000] <Hixie>
of iframes unloading

[12:16:37.0000] <jgraham>
In that example both unload events fire

[12:17:26.0000] <jgraham>
So I imagine it works by saying "if there is another navigation running the unload steps, abort this navigation"

[12:17:56.0000] <jgraham>
But I have no idea how the multiple frame thing should work

[13:59:34.0000] <Hixie>
jgraham: which is "this" navigation?

[14:17:00.0000] <Hixie>
hmmmm

[14:17:20.0000] <Hixie>
if unload is fired and anything notices, the document's salvageable flag gets set to false

[14:17:44.0000] <Hixie>
so what if we just say that we also only ever fire unload oncein that case

[14:17:51.0000] <Hixie>
or something like that

[14:52:01.0000] <Hixie>
http://www.hixie.ch/tests/evil/page-loading/unload/test.html

[14:52:02.0000] <Hixie>
browsers

[14:52:03.0000] <Hixie>
make

[14:52:03.0000] <Hixie>
no

[14:52:06.0000] <Hixie>
sense

[14:53:23.0000] <Hixie>
(opera and IE don't support pagehide so ignore them)

[14:53:43.0000] <Hixie>
(moving test to 001.html)

[14:55:19.0000] <Hixie>
it doesn't help my sanity that chrome thinks the page is written in afrikaans

[14:58:46.0000] <annevk>
I would point you at the channel topic, but I believe you coined that phrase

[15:00:12.0000] <Hixie>
i'm not even asking for logic

[15:00:23.0000] <Hixie>
just, like, consistency, would be a start

[15:00:30.0000] <Hixie>
something that i can spec

[15:04:19.0000] <annevk>
"Please take into account that the web is crazy, thanks!"

[15:04:59.0000] <Hixie>
i found the following comment in the spec, and now i want to bash my head against the table:

[15:05:05.0000] <Hixie>
      <!-- an interesting thing to test would be to traverse back

[15:05:07.0000] <Hixie>
      during onload, before the first pageshow has fired, and then to

[15:05:10.0000] <Hixie>
      traverse forward again, and see if we get _two_ pageshows. If

[15:05:12.0000] <Hixie>
      so, it indicates that the history traversal task source has a

[15:05:15.0000] <Hixie>
      higher priority than the DOM manipulation task source. -->

[15:05:57.0000] <annevk>
learned today (again, I forgot) that IDNA is not interoperable and that the IETF is apparently quite happy to break backwards compatibility

[15:06:03.0000] <annevk>
heh

[15:06:26.0000] <annevk>
man, whenever you get close to the UI, there's trouble

[15:06:42.0000] <Hixie>
also whenever you get close to the network

[15:07:04.0000] <Hixie>
and since the network and UI are separated by about 5mm these days, we're just screwed

[15:07:12.0000] <annevk>
heh

[15:07:22.0000] <annevk>
nn

[15:07:28.0000] <Hixie>
nn

[15:27:35.0000] <Hixie>
/me was jumping through the spec looking at mentions of 'unload' and came across a section that talks about loading and unloading body parts

[15:27:48.0000] <Hixie>
that was briefly confusing before i read the context


2012-09-19
[17:01:15.0000] <Hixie>
wtf was i doing in r3826

[17:02:16.0000] <Hixie>
fixing aryeh's bug apparently

[17:02:18.0000] <Hixie>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2009Sep/0356.html

[17:03:10.0000] <Hixie>
i wonder why i did it like that

[17:18:07.0000] <Hixie>
well, today's checkins ought to give those of you reading the checkins plenty to worry about

[17:18:41.0000] <nessy>
?

[17:18:47.0000] <nessy>
make me worried!

[17:19:41.0000] <Hixie>
basically i just made a bunch of invasive changes to the most sensitive algorithms in the spec.

[17:20:18.0000] <nessy>
hope I don't mingle that up when I apply it to the w3c spec - you do give me plenty of challenges!

[17:20:24.0000] <Hixie>
heh

[17:20:32.0000] <Hixie>
actually these should be relatively easy to apply, i think

[17:20:42.0000] <nessy>
ah goody

[17:20:43.0000] <Hixie>
it's more whether they're right or wrong that's the problem :-)

[17:20:48.0000] <Hixie>
testing them in particular

[17:20:58.0000] <nessy>
hmm...

[00:09:57.0000] <annevk>
How do you tell whether a browser parsed something as a hostname or IPv4 address?

[00:12:16.0000] <annevk>
And should we support IPv4 address formats that are outlawed but supported by some browsers? E.g. http://0x12.0x12/ yields 18.0.0.18

[00:12:28.0000] <annevk>
Where do I go for answers to these questions?

[00:15:22.0000] <jgraham>
annevk: You should probablt ask annevk. I hear he is working on this stuff.

[00:17:04.0000] <othermaciej>
annevk: you would need a hostname that loads as an IP address but fails to load as a hostname on your particular network configuration; or vice versa

[00:18:21.0000] <annevk>
othermaciej: so the URL stack just passes it to the network stack to let them figure it out?

[00:18:23.0000] <othermaciej>
annevk: I suspect browsers do not actually care if they parsed something "as a hostname" or "as an IPv4 address", since only the network layer cares, though perhaps in some cases different normalization rules apply

[00:18:57.0000] <othermaciej>
do you think you need an answer to this question for purposes of URL parsing?

[00:19:17.0000] <othermaciej>
either way, this piece gets returned in the "host" component when parsing

[00:19:38.0000] <annevk>
IPv6 has normalization rules. And IPv4 can have normalization rules if you support things such as 0x12 which is not allowed per the IETF RFC yet Chrome and Opera support it. IPv4 is also not allowed to be shortened (e.g. only one dot) per the RFC, but again Chrome and Opera support it and maybe IE too?

[00:19:39.0000] <othermaciej>
perhaps there is different normalization in some cases, I presume that would be observable

[00:20:17.0000] <othermaciej>
I think allowing weird IP address formats is a potential security risk

[00:20:28.0000] <othermaciej>
so probably should not be allowed unless it is required for web compat

[00:21:33.0000] <annevk>
yeah I read that too somewhere, but not what the risk was

[00:22:58.0000] <annevk>
http://tools.ietf.org/html/rfc3986#section-7.4

[00:23:25.0000] <annevk>
it seems Safari does not handle them, although I have some trouble getting the console to work there

[00:24:33.0000] <othermaciej>
what trouble are you having specifically?

[00:24:37.0000] <othermaciej>
I think the risk is:

[00:24:48.0000] <othermaciej>
- inconsistent parsing between different software components == risk

[00:24:57.0000] <othermaciej>
- weird formats are more likely to confuse users if displayed to them

[00:25:02.0000] <othermaciej>
at least those are the risks I can think of

[00:26:55.0000] <annevk>
I was mostly wondering whether a) to bother with formats such as 0x12.0x12.0x12.0x12 or 18.18 and b) whether I need to make a distinction between IPv4 addresses and domain names

[00:27:07.0000] <annevk>
I think you answered both, so thanks :)

[00:30:36.0000] <annevk>
othermaciej: while you're here, do you know anything about WebKit's plans with regards to IDNA2008 / UTS #46 or is that maybe outside the scope of the WebKit project?

[00:31:38.0000] <othermaciej>
annevk: I think WebKit contains some IDNA parsing code but I don't know the details with our plans on that

[00:31:49.0000] <othermaciej>
I think we were annoyed that IDNA changed incompatibly

[00:32:02.0000] <othermaciej>
but I can't remember what our conclusion was; not something I was closely involved in

[00:32:44.0000] <annevk>
heh, not alone in being annoyed :)

[01:02:58.0000] <annevk>
https://bugs.webkit.org/show_bug.cgi?id=55315 still unconfirmed

[01:03:31.0000] <annevk>
(IDNA2008 bug for WebKit)

[01:08:07.0000] <othermaciej>
UNCONFIRMED doesn't necessarily mean anything

[01:11:34.0000] <othermaciej>
we do have some internal bugs on IDNA2008 that are not scheduled for any release

[01:11:50.0000] <othermaciej>
so I expect Safari does not support it and does not necessarily plan to

[01:11:59.0000] <othermaciej>
the bugs mention some sites that work under IDNA2003 but would break under 2008

[05:53:21.0000] <annevk>
Is there any object besides WorkerGlobalScope that implements WorkerUtils?

[05:53:57.0000] <annevk>
And from WorkerUtils, why is navigator bound to it but importScripts is tied to WorkerGlobalScope (in prose and URL usage)

[05:55:33.0000] <zcorpan>
to the first question i think the answer is "no"

[05:57:25.0000] <annevk>
shouldn't it be flattened in then?

[06:02:42.0000] <zcorpan>
maybe? the interfaces around workers changed (was simplified) a while back, it might be possible to simplify it some more now

[06:30:46.0000] <alefteris>
Can http://validator.w3.org/nu/ validate HTML5 with the creative commons suggested code snippet (uses RDFa)?

[06:31:37.0000] <Ms2ger>
Why would you use rdfa?

[06:32:09.0000] <danbri>
alefteris, do you have a concrete example page to check?

[06:32:32.0000] <alefteris>
yes, just a minute, thanks

[06:33:50.0000] <danbri>
I thought http://validator.nu/ used to have an html5+rdfa option, but seems not

[06:40:32.0000] <alefteris>
danbri, here http://jsfiddle.net/7RZ59/

[06:41:14.0000] <alefteris>
danbri, validator Info: Using the schema for HTML5 + SVG 1.1 + MathML 3.0 + RDFa Lite 1.1 + Microdata

[06:44:34.0000] <danbri>
alefteris, great ... just useful to have a specific example for folk here

[06:44:42.0000] <danbri>
i'm curious what validator.nu gurus have to say too

[06:45:04.0000] <danbri>
I don't think you need  xmlns:dct="http://purl.org/dc/terms/"

[06:45:34.0000] <danbri>
use dc: or dc:terms from http://www.w3.org/2011/rdfa-context/rdfa-1.1 and they're pre-declared

[06:45:50.0000] <danbri>
cc: also

[06:46:00.0000] <danbri>
/me got to run

[06:46:53.0000] <alefteris>
I'll try and revice the example, thanks

[07:02:40.0000] <alefteris>
Revised example: http://jsfiddle.net/7RZ59/2/ Now I just get an error on the cc link. Any idea what I'm doing wrong?

[07:02:46.0000] <hsivonen>
Validator.nu support RDFa Lite in the sense of not treating it as invalid

[07:09:21.0000] <jgraham>
Oh look hsivonen is back :)

[07:09:25.0000] <alefteris>
hsivonen, don't understand RDFa but if that's the case as you say, the validator should ignore xmlns and property attributes?

[07:14:54.0000] <hsivonen>
alefteris: xmlns is typically an error in text/html.

[07:17:37.0000] <scor>
alefteris: you should probably use RDFa 1.1 which deprecates xmlns

[07:18:20.0000] <alefteris>
scor, like this? http://jsfiddle.net/7RZ59/2/

[07:19:22.0000] <scor>
alefteris: yes, that works

[07:21:25.0000] <alefteris>
is there any intro article into rdfa 1.1 from the authors perceptive?

[07:21:51.0000] <scor>
alefteris: you should probably start here: http://www.w3.org/TR/rdfa-lite/

[07:22:59.0000] <alefteris>
thanks

[07:43:34.0000] <annevk>
hey hsivonen, wb

[07:43:53.0000] <annevk>
hsivonen: fwiw http://wiki.whatwg.org/wiki/Talk:Main_Page

[07:43:57.0000] <annevk>
hsivonen: last entry

[07:44:12.0000] <annevk>
zcorpan: should I file a bug?

[07:46:11.0000] <zcorpan>
annevk: about workers?

[07:46:18.0000] <annevk>
zcorpan: y

[07:46:24.0000] <zcorpan>
annevk: sure

[07:47:27.0000] <annevk>
done

[07:48:33.0000] <annevk>
I wonder if we should align URL terminology with the JavaScript API...

[07:48:38.0000] <annevk>
maybe in due course

[08:11:52.0000] <annevk>
so

[08:11:53.0000] <annevk>
http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html#url

[08:11:58.0000] <annevk>
all that parameter stuff

[08:12:03.0000] <annevk>
1) is it implemented?

[08:12:12.0000] <annevk>
2) is there no way to do that more elegantly?

[08:15:41.0000] <annevk>
and do people really care that much about the query part?

[08:30:19.0000] <darobin>
annevk: yes, I have written code that would rely on stuff like that

[08:30:52.0000] <darobin>
as for more elegantly, *shrug*

[08:31:23.0000] <darobin>
you can build something more elegant on top of that, and it will be able to use your own conventions (e.g. for structured fields)

[08:35:57.0000] <annevk>
what do you mean rely?

[08:36:03.0000] <annevk>
you mean browsers support that?

[08:36:18.0000] <darobin>
that *would* rely

[08:36:32.0000] <annevk>
ah

[08:36:33.0000] <darobin>
right now I'm pretty sure I'd handroll it

[08:36:50.0000] <annevk>
wouldn't you just use cool looking paths though?

[08:36:51.0000] <darobin>
/me tries to recall which project he had to parse queries on recently

[08:37:14.0000] <darobin>
not for everything

[08:37:57.0000] <darobin>
if you have a *lot* of options, writing routers for cool looking paths becomes painful

[08:38:20.0000] <annevk>
I suppose

[08:38:24.0000] <darobin>
so I'd keep the paths to a few fundamentals, and add query params for all the options

[08:39:20.0000] <annevk>
just wonder if something like url.query["q"] = "test" would not be a whole lot nicer

[08:39:56.0000] <annevk>
though that's simplified... meh

[08:40:12.0000] <darobin>
yes, but you can have the same key multiple times

[08:40:33.0000] <annevk>
darobin: fwiw, we got some people that are pretty unhappy with the "nicer API can be on top approach"

[08:40:45.0000] <annevk>
darobin: e.g. Alex Russell would prefer the platform to be pretty

[08:40:46.0000] <darobin>
yeah, there always are :)

[08:40:58.0000] <darobin>
and with a pretty face like his I can't blame him

[08:41:04.0000] <annevk>
not sure how realistic that is, but it seems a worthwhile goal

[08:41:05.0000] <annevk>
heh

[08:41:15.0000] <darobin>
I have yet to see a pretty API to query strings though, tbh

[08:41:31.0000] <annevk>
well it's an ordered list of tuples

[08:41:39.0000] <darobin>
e.g. you could have url.query.param be either a string or an array depending on number

[08:41:50.0000] <annevk>
with some relationship between tuples that share the first value

[08:41:53.0000] <darobin>
but that just peppers your code with isArray checks

[08:42:09.0000] <darobin>
or it could always be an array even if of one element

[08:42:13.0000] <annevk>
I was thinking always return array but you can set either

[08:42:20.0000] <darobin>
but let's face it — that just sucks

[08:42:33.0000] <darobin>
well it's consistent — but it's not pretty :)

[08:42:57.0000] <annevk>
yeah, basically query sucks

[08:43:15.0000] <darobin>
well, yeah

[08:43:27.0000] <annevk>
PHP has some nice hack

[08:43:38.0000] <annevk>
only "name[]" is exposed as array

[08:43:42.0000] <darobin>
honestly, the Perl community wrote about 2000 different interfaces to queries — if it were possible to make a nice one it'd exist I think

[08:43:44.0000] <annevk>
if you use name you just get the first

[08:43:58.0000] <darobin>
yes, that's what I meant about structured keys, it's not just PHP but a rather common convention

[08:44:13.0000] <annevk>
that makes some amount of sense

[08:44:16.0000] <darobin>
but I don't think common enough that you could bake it into the standard

[08:44:36.0000] <annevk>
well we could actually for the API...

[08:44:46.0000] <darobin>
mmm, true that

[08:44:56.0000] <annevk>
if you don't like the API, make another one on top of .search

[08:45:07.0000] <darobin>
so essentially leave the ugly stuff ugly but provide nice stuff as well — that wfm

[08:45:16.0000] <darobin>
right

[08:46:23.0000] <darobin>
systems I've used recognise not just name[] but also name[42], name[something], name[7][9] (IIRC)

[08:49:11.0000] <GPHemsley>
Are IDs now any string of any characters?

[08:49:33.0000] <darobin>
not spaces

[08:49:56.0000] <GPHemsley>
right

[08:50:07.0000] <GPHemsley>
so, except spaces?

[08:50:59.0000] <darobin>
use the spec, GPHemsley :) http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-id-attribute

[08:51:08.0000] <GPHemsley>
I am.

[09:03:14.0000] <zcorpan>
does appcache not support using cross-origin resources yet?

[09:04:45.0000] <zcorpan>
or does it?

[09:06:18.0000] <zcorpan>
context: http://forums.whatwg.org/bb3/viewtopic.php?f=1&t=4357

[09:07:54.0000] <annevk>
jgraham: can you edit my comment in https://bugs.opera.com/browse/CORE-48687 to make it sane?

[09:08:09.0000] <annevk>
jgraham: for some reason BTS fucked up the domain

[09:08:24.0000] <annevk>
jgraham: and I lost edit rights :/

[09:11:11.0000] <odinho>
annevk: Hmm. It's ß in the edit view.

[09:11:30.0000] <annevk>
well sucks then :)

[09:11:36.0000] <annevk>
they'll figure it out

[09:11:55.0000] <odinho>
hehe, trying to html escape it makes it doubly worse.

[09:13:18.0000] <odinho>
annevk: allows ß in text but not in urls.

[09:14:16.0000] <annevk>
silly

[09:14:34.0000] <annevk>
you'd better not mangle user input much if you create bug tracking software

[09:32:55.0000] <Ms2ger>
"I think there are actually existing problems in Chapter 10"

[09:33:04.0000] <Ms2ger>
/me tries to avoid cynical comments

[09:49:05.0000] <jgraham>
Ms2ger: Where;s that from?

[09:49:31.0000] <Ms2ger>
#css

[09:55:45.0000] <GPHemsley>
annevk: Do all the single-byte encodings share US-ASCII in the first 0x7F code points?

[09:56:11.0000] <Ms2ger>
All the ones we don't hate do

[09:56:15.0000] <Ms2ger>
EBCDIC doesn't

[09:57:04.0000] <annevk>
GPHemsley: http://encoding.spec.whatwg.org says yes

[09:57:18.0000] <GPHemsley>
oh, a new URL!

[09:57:33.0000] <annevk>
GPHemsley: yeah, see http://www.whatwg.org/specs/

[09:57:37.0000] <annevk>
GPHemsley: I'll blog about it one day

[09:57:46.0000] <GPHemsley>
heh

[09:57:59.0000] <Ms2ger>
I guess I should parsing.s.w.o at some point

[09:59:32.0000] <annevk>
https://github.com/whatwg/url maybe I'll update url.spec.whatwg.org later today

[09:59:48.0000] <annevk>
but I should probably spec the parser before it's worthy of review

[10:00:39.0000] <GPHemsley>
Ms2ger: I notice EBCDIC isn't even in that spec

[10:00:40.0000] <annevk>
Ms2ger: or maybe merge it into DOM?

[10:00:52.0000] <annevk>
gotta go, back later maybe

[11:00:19.0000] <annevk>
Hixie: for some reason dfn.js does not work on http://url.spec.whatwg.org/

[11:25:35.0000] <annevk>
Hixie: http://www.whatwg.org/specs/ is not ordered in any way?

[11:49:49.0000] <jgraham>
annevk: Why doesn't specs.whatwg.org resolve? Or is that what you're fixing?

[12:10:14.0000] <annevk>
jgraham: it's spec.whatwg.org

[12:10:41.0000] <annevk>
jgraham: is there some easy way we can make specs.whatwg.org and *.specs.whatwg.org work?

[12:11:57.0000] <jgraham>
Well given sufficient access to the server config, yes

[12:12:08.0000] <jgraham>
I have no idea what dreamhost allows though

[12:12:19.0000] <annevk>
there's DNS access

[12:13:10.0000] <annevk>
if someone can tell Hixie how to make it work via DNS I'm sure it should be no problem

[12:14:51.0000] <Hixie>
annevk: it's roughly ordered by topic

[12:52:53.0000] <Hixie>
jgraham: why does this end up at "Document" and not "initial"? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1785

[12:53:29.0000] <Hixie>
opera gets to initial, but firefox and chrome don't

[12:55:58.0000] <Hixie>
wait, that's all kinds of wrong

[13:02:37.0000] <jgraham>
Hixie: Firefox gets to initial afaict, but it doesn't get a history position

[13:03:30.0000] <Hixie>
looks like when you hit the "empty" step in the "process iframe src attributes" or whatever it's called, we should do a replacement-enabled navigation to about:blank

[13:03:34.0000] <Hixie>
rather than nothing

[13:03:56.0000] <Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18664

[13:05:27.0000] <jgraham>
Is it "with replacement enabled" because it is happening in a load event?

[13:06:54.0000] <Hixie>
i hope not, but i guess that's possible...

[13:07:43.0000] <jgraham>
I think it probably is

[13:08:24.0000] <jgraham>
I think there is a rule like "navigations that are triggered before the document is completely loaded are performed with replacement enabled"

[13:08:27.0000] <Hixie>
looks like yes

[13:08:34.0000] <Hixie>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1791

[13:08:40.0000] <jgraham>
But I am not 100% sure on that ofc

[13:09:35.0000] <Hixie>
oh you think it's just anything before "completely loaded"?

[13:09:36.0000] <Hixie>
hmm

[13:10:04.0000] <Hixie>
step 16 of the form submission algorithm already does that for form submission

[13:10:05.0000] <Hixie>
interesting

[13:10:29.0000] <Hixie>
as does the location.href setter!

[13:10:53.0000] <Hixie>
interesting

[13:11:11.0000] <Hixie>
i wonder how widespread this should really be

[13:11:20.0000] <Hixie>
clicking a link while a page is loading clearly shouldn't do it

[13:11:25.0000] <Hixie>
so it's not a blanket statement

[13:11:43.0000] <jgraham>
No, user interaction is always magic

[13:12:35.0000] <jgraham>
Or always non-magic, depending on your point of view :)

[13:12:44.0000] <Hixie>
i guess heh

[13:13:00.0000] <Hixie>
ok i've noted what i think should happen in the bug

[13:13:03.0000] <Hixie>
lunch now

[13:14:09.0000] <Ms2ger>
krijn, still down?

[13:47:36.0000] <jgraham>
I am fascinated to see which bits of the spec the W3C think have "interoperability proven by the web". I somehow doubt it will be the same bits I would pick.

[13:53:40.0000] <othermaciej>
jgraham: if you consider that it's "judgment call" interop rather than interop proven by a thorough test suite, I would say:

[13:53:46.0000] <othermaciej>
- parsing algorithm

[13:54:15.0000] <othermaciej>
- most basic elements inherited from html4 that remain conforming (e.g. div, span, i, em)

[13:54:38.0000] <othermaciej>
- <video> excluding the more advanced features like MediaController and <track> (which are arguably separate features)

[13:54:51.0000] <othermaciej>
that being said, the plan doesn't include a list, just suggests making one

[13:54:58.0000] <othermaciej>
and you can and should have input on that list

[13:56:54.0000] <jgraham>
othermaciej: I would say that the parsing algorithm is one of the few things that does have a testsuite to suggest interoperability :)

[13:57:31.0000] <othermaciej>
jgraham: true, but I would also say that more tests are not needed, even though one could probably think of more edge cases to test

[13:57:50.0000] <jgraham>
Right, there are always more cases to test

[13:58:09.0000] <annevk>
wow, Apple Maps, kinda blows

[13:58:15.0000] <jgraham>
But it doesn't seem like a case where interoperability is proven by the web

[13:59:18.0000] <othermaciej>
html5 video (basic stuff at least) seems like a better case of that

[13:59:27.0000] <othermaciej>
given numerous prominent sites using it and working cross-browser

[13:59:34.0000] <othermaciej>
and setting aside the regrettable codec issues

[13:59:36.0000] <jgraham>
But pretty much everything that is "DOM0" and everything to do with navigation and so on is demonstrably non-interoperable

[13:59:51.0000] <jgraham>
And I doubt that will change in 24 months

[13:59:52.0000] <annevk>
same for DOM Level 2 HTML stuff

[14:01:28.0000] <othermaciej>
jgraham: anything that sites manage to use without needing browser-specific code paths would count to me as "judgment call" roughly interoperable, if not thoroughly interoperable in detail; but that is just my opinion

[14:01:46.0000] <othermaciej>
the point of departure here is how to get to REC in less than a decade

[14:01:57.0000] <jgraham>
I woukd prefer that we were honest and said "we know these bits of the spec aren't bug free but we are shipping anyway"

[14:01:59.0000] <othermaciej>
this requires abandoning the "comprehensive test suite for everything" assumption

[14:02:41.0000] <othermaciej>
to me, "Qualitatively interoperable at at a judgment level, not necessarily for every spec assertion. A test suite may be used as guidance for the qualitative decision." says "we know these bits of the spec aren't bug free but we are shipping anyway"

[14:02:45.0000] <jgraham>
Well more precisely it requires abandoning the idea that the spec will be correct except for minor bugs

[14:03:51.0000] <jgraham>
Truly abandoning that would of course mean moving to a process where that was a baked-in truth rather than something to be hushed up

[14:03:56.0000] <jgraham>
But baby steps...

[14:23:37.0000] <Hixie>
hahahaha

[14:23:42.0000] <Hixie>
i just saw the e-mail jgraham is talking about

[14:24:01.0000] <othermaciej>
jgraham: I see it as taking gradual steps towards a more living-standard-esque model

[14:24:22.0000] <othermaciej>
while being able to claim it is consistent with at least the letter of the w3c process

[14:24:34.0000] <othermaciej>
jgraham: comments on list (either on the whole plan thing or the cr exit criteria) would be welcome

[14:24:38.0000] <Ms2ger>
It won't be consistent with the letter

[14:24:46.0000] <Hixie>
i'm not aware of any areas that don't have tests that have any sort of serious interop

[14:24:48.0000] <Ms2ger>
But that doesn't mean  you can't claim that

[14:25:00.0000] <Ms2ger>
After all, that's a long W3C tradition

[14:25:05.0000] <othermaciej>
the point is not to go for "serious" interop

[14:25:24.0000] <Hixie>
it's not clear what the point is

[14:25:29.0000] <Ms2ger>
There is a point?

[14:25:34.0000] <Hixie>
it's clearly not "get to REC ASAP"

[14:25:39.0000] <Hixie>
since that could happen right now

[14:25:49.0000] <Hixie>
it's clearly not "remove bugs from the spec", since you can't do that without testing

[14:26:18.0000] <Hixie>
it's clearly not "write a spec that people can implement and be confident they are interoperable with other UAs and content", since that would need removing the bugs

[14:26:43.0000] <Hixie>
as far as i can tell, it's "pretend to follow the process so we can feel good without actually achieving anything truly useful"

[14:27:20.0000] <Ms2ger>
Sounds about right

[14:27:22.0000] <othermaciej>
it's "get to REC ASAP subject to the constraint that you could argue it is consistent with the W3C Process"

[14:27:41.0000] <Ms2ger>
s/feel good/feel good or get paid/, I guess

[14:27:46.0000] <othermaciej>
fyi the letter of the process on what is required for exit from CR is here: http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

[14:28:38.0000] <Ms2ger>
"If the Director believes that immediate Advisory Committee review is critical to the success of a technical report, the Director MAY accept to Call for Review of a Proposed Recommendation even without adequate implementation experience;"

[14:28:43.0000] <Ms2ger>
Just call that

[14:28:51.0000] <Hixie>
i can argue that it is consistent with the W3C process to get to REC right now

[14:29:03.0000] <Hixie>
and it would be no less valid an argument than if we do what that e-mail suggests

[14:29:03.0000] <Ms2ger>
The Director has been clear he doesn't care about interop

[14:29:54.0000] <othermaciej>
neither the WG nor the W3C Team seem convinced by "REC immediately", though I would personally not have a problem with it relative to the current pan

[14:29:57.0000] <Ms2ger>
Anyway, I've long given up on the HTMLWG producing anything useful, so do whatever

[14:30:39.0000] <Hixie>
othermaciej: if the goal is "do whatever it takes to convince the staff that we should go to REC", that's a pretty messed up goal

[14:31:23.0000] <othermaciej>
Hixie: given that the staff have veto power over transitions, it's hard to see how any other goal is possible

[14:31:41.0000] <Hixie>
there are tons of other goals possible

[14:32:15.0000] <Hixie>
e.g. "make a high quality spec that, if implemented, results in a UA that is interoperable with the legacy content on the web and provides new features for new applications"

[14:32:21.0000] <Hixie>
that's roughly my goal

[14:32:32.0000] <Hixie>
turns out you can do that without having to convince the w3c staff of anything :-)

[14:32:50.0000] <Ms2ger>
othermaciej, do you seriously think W3C staff would use their veto power?

[14:32:52.0000] <othermaciej>
REC has IPR disarmament value

[14:33:09.0000] <Hixie>
true

[14:33:19.0000] <othermaciej>
thus, it's useful to get to REC as quickly as possible given organizational constraints, even if also pursuing other goals

[14:34:44.0000] <othermaciej>
Ms2ger: I have evidence to believe they would

[14:34:58.0000] <Ms2ger>
Hah

[14:35:14.0000] <Hixie>
anyway, presumably this won't stop tests for the more critical legacy areas (that we somehow have "proof are interoperable") from being made

[14:35:32.0000] <Ms2ger>
It'll stop Microsoft from submitting tests

[14:35:37.0000] <Ms2ger>
Not sure if that's a net loss

[14:35:42.0000] <othermaciej>
no, this is intended to stop the test suite from gating REC, not stop tests from being created

[14:35:47.0000] <Hixie>
k

[14:35:59.0000] <Hixie>
well i don't think the test suite should gate REC, so that's fine. :-)

[14:35:59.0000] <othermaciej>
test suite work should continue beyond REC, obviously

[14:39:00.0000] <Hixie>
ok, let me get back to fixing these parts of the spec that we've proved interoperable...

[14:39:14.0000] <Hixie>
specifically, loading blank URLs into iframes

[14:57:03.0000] <Hixie>
anyone know what bug this is really for? https://github.com/w3c/html/commit/b55b3ce3bf7dd3deec9129766f5738b2d033ecca

[14:57:10.0000] <Hixie>
18224 (as in the bug comment) doesn't seem to have anything to do with it

[14:58:40.0000] <Hixie>
18226 maybe

[15:01:22.0000] <hober>
that commit message makes me go cross-eyed

[15:33:57.0000] <Hixie>
hober: dunno if you care, but https://www.w3.org/Bugs/Public/show_bug.cgi?id=18226 has an incorrect fix

[15:44:14.0000] <hober>
/me looks


2012-09-20
[20:26:11.0000] <alix88>
Are there any WebVTT people in here?

[20:30:10.0000] <alix88>
This room is sure lively.

[20:30:10.0000] <alix88>
I'm looking for anybody who might be familiar with cue settings in the WebVTT spec

[20:38:21.0000] <alix88_>
..

[20:44:02.0000] <alix88>
ERMEGERD

[20:46:02.0000] <celtboy>
WERB STERNDERDS

[20:46:32.0000] <celtboy>
Was someone wanting to discuss VTT?

[20:46:49.0000] <alix88>
That was me.  Know much about it?

[20:50:53.0000] <alix88>
Guess this isn't the place to discuss w3 specs :)  Goodnight, room full of silent people.

[01:14:45.0000] <zcorpan>
wow alix88 can't have heard of this thing called time zones

[01:14:52.0000] <zcorpan>
but maybe i should have popped in here when my daughter waked me up...

[01:16:20.0000] <zcorpan>
alix88: if you're reading logs, then, next time, just ask you question, and maybe somebody can answer it later

[01:21:55.0000] <krijnh>
Tee hee

[02:42:45.0000] <smaug____>
hsivonen: welcome back

[02:44:14.0000] <annevk>
so the new Maps.app is terrible, but the new Phone.app lets me call again

[02:44:38.0000] <annevk>
working Phone.app prolly beats Maps.app

[02:45:52.0000] <annevk>
krijn: teehee indeed

[02:51:50.0000] <jgraham>
annevk: My 200SEK Nokia thing lets me make calls, so it seems to me that if you are paying 6000+SEK then that's 5800SEK's for broken mapping

[02:52:04.0000] <jgraham>
s/SEK's/SEK/

[02:52:37.0000] <annevk>
jgraham: if it only were that simple :)

[02:53:01.0000] <zcorpan>
5800 for broken Maps.app

[02:53:30.0000] <zcorpan>
sounds like a fair deal :-)

[03:22:05.0000] <hsivonen>
smaug____: thanks

[04:30:40.0000] <annevk>
Does http://url.spec.whatwg.org/#concept-url-parse look comprehensible enough?

[04:31:03.0000] <annevk>
It's quite a bit of work to write it all out, so I rather not complete it only to hear it has to be redone

[04:40:54.0000] <annevk>
Ah, no feedbac?

[04:46:28.0000] <odinho>
annevk: Well, it takes time to read and understand, -- but that's just because that's how it is. I understand what's happening if that was the question.

[04:47:06.0000] <annevk>
sounds good enough to me :)

[04:47:14.0000] <annevk>
and yeah, URLs are annoying :)

[04:49:30.0000] <Ms2ger>
Maybe a list of the possible states would be useful?

[04:59:11.0000] <annevk>
yeah maybe, lets first write the whole thing down

[05:00:01.0000] <annevk>
then fix a few small things and then maybe start raising some questions as to how people want various interop issues resolved

[05:10:30.0000] <zcorpan>
annevk: do you generate the spec from the javascript impl?

[05:10:37.0000] <annevk>
nah

[05:11:46.0000] <annevk>
it's only a couple of hours to write it out, figuring out the conversion code would be more and it would not be good or readable anyway

[05:12:05.0000] <annevk>
but it's written based on the JavaScript impl

[05:13:26.0000] <zcorpan>
annevk: would be good if it said at the top what the algorithm can return (or what it does)

[05:14:31.0000] <zcorpan>
annevk: e.g. i expected it to return an error instead of just aborting in step 3 in scheme start

[05:15:16.0000] <annevk>
you can only get in step 3 if you set .protocol

[05:15:25.0000] <annevk>
override stuff is like innerHTML madness in the HTML parser

[05:16:03.0000] <annevk>
but yeah, some notes should be added in due course

[05:16:06.0000] <annevk>
forks encouraged :)

[05:19:10.0000] <zcorpan>
yay https://bugzilla.mozilla.org/show_bug.cgi?id=744907

[05:22:11.0000] <zcorpan>
annevk: should it be possible to pass in a URL object as baseUrl?

[05:23:39.0000] <annevk>
I'd rather not do that

[05:24:00.0000] <zcorpan>
why not?

[05:24:10.0000] <zcorpan>
what happens if the base url is invalid?

[05:24:14.0000] <annevk>
we can make it work, but URL objects can be manipulated in weird ways and the parser would then have to account for that

[05:24:27.0000] <Ms2ger>
/me wonders why this Zynga guy sends email in euc-kr

[05:24:27.0000] <annevk>
good question

[05:24:51.0000] <annevk>
zcorpan: should maybe throw for that case

[05:25:09.0000] <annevk>
zcorpan: also if the base URL hierarchical flag is not set, both are kinda useless

[05:25:28.0000] <annevk>
zcorpan: I'll add an XXX

[05:25:43.0000] <zcorpan>
if i have a URL and want to resolve something against it, it seems silly to have to serialize it for it to work

[05:26:06.0000] <marcosc_>
Anyone here interested in the responsive images stuff?

[05:26:32.0000] <Ms2ger>
No

[05:26:41.0000] <marcosc_>
:)

[05:26:51.0000] <annevk>
zcorpan: e.g. consider if you have a URL and then set its protocol to data

[05:27:09.0000] <annevk>
zcorpan: it's still a "hierarchical" URL because browsers do weird stuff

[05:27:15.0000] <annevk>
not sure what result you want out of that

[05:27:34.0000] <annevk>
I mean if you come with a proposal that solves all the weird shit, mkay

[05:32:55.0000] <zcorpan>
annevk: can you give a list of weird states i need to cover?

[05:33:15.0000] <annevk>
prolly once I have looked at it in more detail

[05:33:20.0000] <annevk>
what we could do btw

[05:33:24.0000] <annevk>
is that if you pass a URL object in

[05:33:31.0000] <annevk>
we just parse its URL.href again

[05:33:42.0000] <annevk>
and if that fails, you fucked up

[05:33:44.0000] <zcorpan>
annevk: tentatively i'd just check for the weird states and throw INVALID_STATE_ERR

[05:34:41.0000] <zcorpan>
or have a flag "weird state" that gets set when the url is mutated in weird ways, or whatever

[05:36:19.0000] <zcorpan>
i guess parsing URL.href could be black-box equivalent

[05:36:35.0000] <annevk>
it better be :)

[06:11:27.0000] <annevk>
Anyone know if it's normal for GitHub to lag behind?

[06:11:43.0000] <annevk>
Something I committed has not shown up on the site thus far...

[06:12:26.0000] <Ms2ger>
Hmm, https://github.com/whatwg suddenly looks rather different

[06:13:01.0000] <annevk>
today's redesign I guess

[06:13:07.0000] <annevk>
but I'm more worried about the syncing

[06:14:23.0000] <jgraham>
Doesn't sound that normal

[06:14:33.0000] <jgraham>
Did you check if it is actually in the repo?

[06:18:52.0000] <annevk>
it seems to be in now

[06:19:02.0000] <annevk>
but that was at least a delay of several minutes

[06:40:30.0000] <annevk>
and again

[06:40:36.0000] <annevk>
committed 3:40

[06:40:39.0000] <annevk>
lets see when it shows up

[06:56:25.0000] <annevk>
still not

[07:03:04.0000] <annevk>
now it is

[07:03:08.0000] <annevk>
so that's about 20 minutes

[07:03:29.0000] <annevk>
zcorpan: added the URL argument thingie: http://url.spec.whatwg.org/#api

[07:03:34.0000] <odinho>
maybe they're going freemium on the time.

[07:03:35.0000] <annevk>
zcorpan: haven't actually fixed the bugs it might cause

[07:04:01.0000] <annevk>
I wanted to expose invalid URLs

[07:04:10.0000] <annevk>
should I make that URLUtils.isInvalid?

[07:04:50.0000] <odinho>
Hmm. Just did a small private OTW. Opera is the only one having spaces in its Accept header...

[07:10:15.0000] <annevk>
they haven't fixed that yet?

[07:10:33.0000] <annevk>
ideally Accept is just nuked

[07:10:47.0000] <annevk>
but that's a compat issue

[07:13:37.0000] <odinho>
annevk: I might just do a troll patch for it. Saw the bug now. Really need those spaces out. I just had to fix a compat issue with a website because we have spaces.

[07:14:48.0000] <annevk>
ideally you also write that down somewhere

[07:15:22.0000] <annevk>
odinho: add it to http://wiki.whatwg.org/wiki/HTTP_Issues please

[07:15:40.0000] <annevk>
should maybe rename that page to HTTP to make it easier  to find

[07:16:33.0000] <odinho>
annevk: I haz no user.

[07:16:42.0000] <annevk>
email?

[07:16:51.0000] <odinho>
annevk: the obvious one I guess :]

[07:21:14.0000] <zcorpan>
ilovespicegirls⊙hc ?

[07:21:26.0000] <Ms2ger>
I thought that was you, zcorpan?

[07:21:43.0000] <zcorpan>
wait, maybe that was lachy

[07:21:48.0000] <annevk>
odinho: moved it to HTTP

[07:22:04.0000] <annevk>
wait, I've not been chatting with a girl all this time?

[07:22:34.0000] <Ms2ger>
That's what I thought when I heard "Anne"

[07:23:00.0000] <annevk>
Belgians

[07:23:12.0000] <zcorpan>
Ms2ger though is clearly a girl

[07:23:25.0000] <annevk>
or an unproductive robot

[07:23:28.0000] <Ms2ger>
You saw through the "Ms."?

[07:23:37.0000] <zcorpan>
yep

[07:23:46.0000] <jgraham>
Oooh, like Ms Pacman?

[07:24:06.0000] <jgraham>
Ms2ger is actually an 80s video game gone sentinent?

[07:24:17.0000] <Ms2ger>
Beep

[07:24:26.0000] <Ms2ger>
/me eats the ghost of longdesc

[07:24:27.0000] <jgraham>
*sentient

[07:27:08.0000] <jgraham>
Actually longdesc is quite like the pacman ghosts

[07:27:23.0000] <Ms2ger>
It always comes back?

[07:27:29.0000] <jgraham>
Yeah :(

[07:27:38.0000] <Ms2ger>
http://w3cmemes.tumblr.com/post/31865121758/the-joker-shares-his-approach-on-css2-1-issues also applies to HTML5, I guess

[07:27:58.0000] <Ms2ger>
"W3C Invites Implementations of The WebSocket API"

[07:28:08.0000] <Ms2ger>
Oh, why thank you, I'll start implementing right away

[07:28:20.0000] <jgraham>
The W3C would be rubbish as party planners

[07:28:29.0000] <zcorpan>
yeah we've been waiting for the w3c invitation!

[07:28:41.0000] <jgraham>
We'd be half way through trashing their house before they sent out the invites

[07:29:23.0000] <Ms2ger>
Of only that was all they were rubbish at

[07:29:28.0000] <Ms2ger>
If, even

[07:58:59.0000] <annevk>
TC39 has some complicated way to define percent escaping: http://es5.github.com/#Encode

[07:59:07.0000] <annevk>
I was hoping for a couple of lines :)

[08:44:21.0000] <annevk>
mine are a bit shorter

[08:44:21.0000] <annevk>
http://url.spec.whatwg.org/#percent-escaped

[09:05:46.0000] <marcosc>
/me notes that the hour glass emoji don't worky in Chrome

[09:39:07.0000] <SamB_MacG5>
/me wonders why he's supposed to leave his sense of logic at the door

[09:39:17.0000] <SamB_MacG5>
/me wonders "What door?"

[09:40:34.0000] <SamB_MacG5>
So, I was wondering why XBL 2.0 was scrapped.  Is this a good place to find out, or do you know a better place?

[09:40:48.0000] <annevk>
nobody implemented it

[09:41:27.0000] <SamB_MacG5>
I wish W3C docs would/could mention stuff like that ...

[09:42:39.0000] <annevk>
you mean like http://www.w3.org/TR/xbl/#status-of-this-document

[09:44:11.0000] <SamB_MacG5>
Pretty sure I read that, but it wasn't clear that the lack of plans to implement was the reason for abandonment, rather than the other way around

[09:44:47.0000] <annevk>
anyway

[09:44:52.0000] <annevk>
search for "web components"

[09:44:54.0000] <annevk>
or bug dglazkov

[09:45:02.0000] <annevk>
that's the new hot thing

[09:45:20.0000] <annevk>
though like XBL vendor interest is scarce

[09:45:28.0000] <annevk>
with /\

[09:45:46.0000] <SamB_MacG5>
 /\ ?

[09:46:06.0000] <Ms2ger>
An arrow

[09:46:25.0000] <SamB_MacG5>
ah

[09:46:46.0000] <SamB_MacG5>
/me is used to ^ for that, possibly with dashes on one side or the other

[09:46:53.0000] <Ms2ger>
~^~

[09:47:09.0000] <annevk>
mustache?

[09:48:04.0000] <SamB_MacG5>
anyway, who can I bug about clarifying http://www.w3.org/TR/xbl/#status-of-this-document ?

[09:53:29.0000] <marcosc>
SamB_MacG5: there should be a mailing list mentioned in the status of this document

[09:53:52.0000] <SamB_MacG5>
true

[09:54:17.0000] <SamB_MacG5>
there are actually *two* of them

[09:55:22.0000] <SamB_MacG5>
I guess public-webapps⊙wo is probably more appropriate for such administrative feedback?

[09:55:57.0000] <marcosc>
Yeah, hit those guys up... but I would recommend some text to be added... otherwise, I doubt anyone will do anything about it

[09:56:53.0000] <SamB_MacG5>
you mean, I should suggest a specific piece of text to insert?

[09:57:25.0000] <SamB_MacG5>
and possibly replacements for parts I think are unclear?

[11:26:11.0000] <annevk>
Ms2ger: so should we move DOM Parsing into DOM?

[11:26:24.0000] <Ms2ger>
Mm, I dunno

[11:26:34.0000] <Ms2ger>
It's icky markup ;)

[11:27:37.0000] <annevk>
you mean the source code or you mean you don't want markup features to spoil the DOM?

[11:27:47.0000] <Ms2ger>
The latter

[11:28:44.0000] <annevk>
okay

[11:32:19.0000] <annevk>
only a few days left and apart from IPv6 I will be 80% done

[11:32:25.0000] <annevk>
then of course comes the next 80%

[11:33:52.0000] <Ms2ger>
Heh

[11:35:25.0000] <annevk>
it's not too bad for a couple of weeks of research, although I guess it was closer to one or two months, don't quite remember when I started

[11:35:46.0000] <annevk>
I wonder what Hixie estimated back in the days for writing the URL part

[11:36:42.0000] <annevk>
I wonder if he included writing the Encoding Standard so http://url.spec.whatwg.org/#query-percent-escaped would be defined :)

[11:42:01.0000] <matjas>
Ms2ger: you magnificent bastard, you https://www.w3.org/Bugs/Public/show_bug.cgi?id=11204#c46

[11:50:44.0000] <annevk>
hey matjas

[11:50:52.0000] <annevk>
matjas: did you get my feedback the other day?

[11:51:59.0000] <matjas>
annevk: i didn’t get anything

[11:52:06.0000] <matjas>
annevk: was it here in #whatwg?

[11:53:04.0000] <annevk>
matjas: http://logbot.glob.com.au/?c=freenode%23whatwg&s=18%20Sep%202012&e=18%20Sep%202012#c722062

[11:53:29.0000] <annevk>
matjas: though in the end I guess all that was valid was the typo, as what should really be done is not entirely clear yet

[11:54:18.0000] <matjas>
thanks

[11:56:13.0000] <annevk>
matjas: are you using that Punycode in the wild btw?

[11:56:30.0000] <annevk>
matjas: I was wondering whether we should expose such a thing as native API

[11:57:59.0000] <matjas>
annevk: Punycode.js ships with Node.js, and some other open-source projects depend on it, so yes I think it’s being used

[11:58:18.0000] <annevk>
ah yeah, outside of browsers

[11:58:22.0000] <matjas>
annevk: (Node.js uses it internally for its URL stuff)

[11:58:36.0000] <annevk>
yeah, noticed that when looking at their URL impl

[11:58:54.0000] <matjas>
IMHO it would be a useful API to have built-in

[11:58:59.0000] <matjas>
in browsers

[11:59:38.0000] <matjas>
especially since stuff like <input type=email> disallows IDNA

[11:59:44.0000] <annevk>
maybe we could have static methods on URL

[11:59:57.0000] <annevk>
URL.toPunycode() / URL.fromPunycode() or some such

[12:02:47.0000] <matjas>
/me donates Punycode.js unit tests to browser vendors

[12:08:58.0000] <matjas>
annevk: just noticed your last three blog posts too, yay!

[12:16:09.0000] <matjas>
“There are other characters that are used as "full stops" that one could consider mapping as label separators, but their use as such has not been investigated thoroughly.” Thanks, RFC 5895

[12:34:40.0000] <humph_>
I had a question about the best way to write conformance tests for WebVTT, specifically how and where to capture metadata about the different good/bad .vtt files

[12:35:06.0000] <humph_>
should we put them in the .vtt file's comment block, in a separate file per test, in a wiki, in one file keyed by test file, etc.

[12:35:09.0000] <humph_>
what's the right approach?

[12:35:21.0000] <jgraham>
zcorpan: ^

[12:36:22.0000] <jgraham>
If it were me and I was writing a parser, I might develop a simple text format to embed the VTT and a desciption in

[12:36:24.0000] <zcorpan>
humph_: webvtt doesn't currently support comments, so your options are in the cue text or in a separate file

[12:36:37.0000] <jgraham>
Like we did for the HTML parser tests

[12:36:50.0000] <jgraham>
Then have a script to spit out the actual browser-readable tests

[12:36:55.0000] <humph_>
jgraham: so a file that you'd split the .vtt out of at test time?

[12:37:03.0000] <jgraham>
Yeah

[12:37:23.0000] <zcorpan>
humph_: for some of my parser tests i've put json in cue data with expected settings/timings; and a separate json file with expected number of cues or "error"

[12:37:26.0000] <humph_>
I was afraid of putting it in the cue text and making the tests unnecessarily large

[12:38:00.0000] <zcorpan>
for my other parser tests i used html5lib style like jgraham suggested

[12:38:13.0000] <zcorpan>
(i.e. for testing cue text parsing)

[12:38:29.0000] <zcorpan>
i haven't released these tests but i intend to

[12:38:56.0000] <humph_>
cool.  I'm implementing webvtt in firefox with my class this term, just wanted to figure out the best way to start

[12:39:01.0000] <humph_>
they are beginning with these tests

[12:39:31.0000] <zcorpan>
ok

[12:39:32.0000] <jgraham>
Nice project :)

[12:39:39.0000] <jgraham>
And testing++

[12:39:51.0000] <humph_>
http://vocamus.net/dave/?p=1525

[12:39:53.0000] <humph_>
yeah, should be fun

[12:40:00.0000] <jgraham>
I hope you will release the results to W3C for inclusion in the official testsuite

[12:40:11.0000] <humph_>
yeah, sylvia suggested the same

[12:40:15.0000] <humph_>
I think that's a good plan

[12:40:25.0000] <jgraham>
sylvia++

[12:40:29.0000] <humph_>
indeed

[12:40:59.0000] <humph_>
alright, thanks for the ideas

[12:41:09.0000] <jgraham>
If you need any help with test harness wrangling or getting the tests submitted feel free to ask me

[12:41:14.0000] <humph_>
k

[12:41:22.0000] <humph_>
I started by doing a node module to wrap the js parser

[12:41:24.0000] <jgraham>
Or there is #testing on the W3C server

[12:41:33.0000] <humph_>
https://github.com/humphd/node-webvtt

[12:41:40.0000] <humph_>
so they could at least validate in a test harness

[12:42:02.0000] <zcorpan>
i used testharness.js for testing the parser and the dom api, and reftests for rendering

[12:48:04.0000] <annevk>
matjas: nice find

[12:48:22.0000] <annevk>
matjas: so yeah, what we end up with here kinda depends on what browsers are going to implement :(

[12:48:49.0000] <annevk>
matjas: Opera has some kind of mixture, Gecko is aiming to adopt http://jprs.co.jp/idn/index-e.html

[12:48:55.0000] <annevk>
matjas: WebKit has no plans

[12:49:02.0000] <annevk>
dunno about Internet Explorer

[12:49:40.0000] <Hixie>
annevk: any chance i can get "nodes are inserted" to be defined so as to give me one hook per node that is inserted, in tree order?

[12:49:49.0000] <Hixie>
annevk: (if not no worries, i can do it on my end)

[12:50:22.0000] <jgraham>
Hixie: Doing the "which order should scripts run when several are inserted" bug?

[12:50:30.0000] <Hixie>
good guess

[12:50:31.0000] <Hixie>
ues

[12:50:32.0000] <Hixie>
yes, even

[12:50:41.0000] <jgraham>
:)

[12:51:59.0000] <annevk>
Hixie: yeah we could rephrase it like that

[12:52:09.0000] <annevk>
Hixie: file a bug, can fix it tomorrow prolly

[12:52:45.0000] <annevk>
I think HTML is the only one that makes use of this right now (SVG should prolly too) so whatever you want works

[12:53:20.0000] <Hixie>
annevk: k, thanks

[12:55:23.0000] <Hixie>
annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18941

[12:55:55.0000] <smaug____>
annevk: where should I file DOM4 bugs nowadays

[12:56:05.0000] <smaug____>
is w3c bugzilla still ok?

[12:56:10.0000] <annevk>
smaug____: yeah works for me

[12:56:38.0000] <annevk>
I should maybe get a component inside the WHATWG product but so far nobody in the WebApps WG has complained

[13:00:26.0000] <zcorpan>
[tm]: ^

[14:35:52.0000] <Hixie>
who's in charge of cssom these days, do they have a bugzilla account?

[14:38:20.0000] <jgraham>
Supposedly Glenn Adams

[14:40:27.0000] <Hixie>
k

[14:41:11.0000] <jgraham>
http://dvcs.w3.org/hg/csswg/log/911a391cb16c/cssom/cssom-source suggests that it might even be slightly true

[14:50:50.0000] <Hixie>
anne know if apple is on board with Opus as an audio codec?

[14:52:49.0000] <Hixie>
hober: ^

[15:00:51.0000] <jgraham>
/me has no idea how to get <input type=file multiple> to expose paths

[15:00:57.0000] <jgraham>
What am I missing?

[15:01:04.0000] <Hixie>
it doesn't expose paths

[15:01:05.0000] <jgraham>
*names* are rather easy

[15:01:22.0000] <Hixie>
(i suppose a UA could include the path in the name, if so inclined)

[15:01:40.0000] <Hixie>
oh you mean how _could_ we do it?

[15:01:42.0000] <Hixie>
it'd be easy

[15:01:49.0000] <Hixie>
just make the filenames foo/bar/baz.quux

[15:01:55.0000] <jgraham>
No, no

[15:01:57.0000] <Hixie>
or C:\foo\bar\baz.quux

[15:02:02.0000] <jgraham>
"File names may contain partial paths, e.g. in the case that a user has selected an entire directory hierarchy. Path components should be separated from each other using U+005C REVERSE SOLIDUS character (\)."

[15:02:15.0000] <Hixie>
ah, there you go, the spec even says it already

[15:02:16.0000] <Hixie>
cool

[15:02:30.0000] <jgraham>
I don't want it to expose paths

[15:02:33.0000] <jgraham>
:)

[15:02:42.0000] <jgraham>
Darin claimed that it already does

[15:02:52.0000] <Hixie>
whether it does or not is entirely an implementation issue

[15:03:02.0000] <jgraham>
AFAICT this isn't actually the case

[15:03:19.0000] <Hixie>
what isn't

[15:03:49.0000] <jgraham>
That paths are exposed by this API

[15:04:19.0000] <Hixie>
they can be

[15:04:21.0000] <Hixie>
in theory

[15:04:28.0000] <Hixie>
whether implementations do so or not is up to them

[15:06:11.0000] <jgraham>
How would they expose it if they did?

[15:06:24.0000] <Hixie>
you just quoted the answer to your question

[15:06:42.0000] <Hixie>
i don't understand

[15:06:44.0000] <Hixie>
is it not clear?

[15:08:53.0000] <jgraham>
Not at all :)

[15:09:17.0000] <Hixie>
what's not clear

[15:09:22.0000] <Hixie>
i really don't understand the problem

[15:09:29.0000] <jgraham>
I don't see how the statement "file names may..." is related to the properties of the input element

[15:09:41.0000] <Hixie>
oh

[15:10:00.0000] <Hixie>
the file names it refers to are those that form part of hte /selected files/ list

[15:10:16.0000] <Hixie>
input.files returns a FileList of the /selected files/ list

[15:10:32.0000] <Hixie>
FileList is a list of File objects, which each have a name

[15:10:41.0000] <jgraham>
Right, but that explictly doesn't include a path

[15:10:48.0000] <Hixie>
they explicitly do, here

[15:11:03.0000] <Hixie>
well

[15:11:07.0000] <Hixie>
they don't include a path

[15:11:11.0000] <Hixie>
they just include a filename with backslashes

[15:11:15.0000] <jgraham>
What? The File API says they don't

[15:11:18.0000] <Hixie>
but you can interpret that as a path

[15:11:23.0000] <Hixie>
the HTML spec says they do

[15:11:48.0000] <jgraham>
"The name of the file; on getting, this must return the name of the file as a string. There are numerous file name variations on different systems; this is merely the name of the file, without path information"

[15:11:52.0000] <Hixie>
right

[15:11:59.0000] <Hixie>
hence why the HTML spec changes the name to include the path information

[15:12:07.0000] <jgraham>
Woah

[15:12:13.0000] <jgraham>
That is totally unclear

[15:12:43.0000] <jgraham>
Why is there a "may" level wilful violation of another spec that no UA actually violates?

[15:12:50.0000] <jgraham>
(afaict)

[15:12:59.0000] <Hixie>
so that people can expose paths

[15:13:41.0000] <jgraham>
But since no UA actually does that, it seems highly unclear and quite probably undesirable

[15:13:47.0000] <Hixie>
*shrug*

[15:13:54.0000] <Hixie>
i don't see why it's unclear

[15:14:07.0000] <Hixie>
nor undesireable

[15:14:46.0000] <jgraham>
It's unclear because usually when you are willfully violating other specs a) it says so explicitly and b) there is a compat. reqiurement

[15:15:33.0000] <Hixie>
it's not a wilful violation

[15:16:08.0000] <Hixie>
a wilful workaround maybe :-)

[15:16:15.0000] <jgraham>
Erm? If spec A says "you must not do X" and you say "you may do X" that sounds like a wilfull violation

[15:17:00.0000] <Hixie>
spec A doesn't say "you must not do X". It says "you must return A, and not return B" and HTML says "put B inside A"

[15:17:30.0000] <Hixie>
actually even that's not quite accurate

[15:18:04.0000] <jgraham>
Since "B inside A and return A" is a special case of "return B", that is just the same

[15:18:55.0000] <Hixie>
i read it differently but whatever

[15:19:10.0000] <Hixie>
i'm happy to change one or the other to avoid the appearance of disagreement

[15:19:52.0000] <jgraham>
OK. Well I should have been asleep some time ago. Seems like a good juncture to fix that.

[16:13:59.0000] <Hixie>
can anyone explain the purpose of this change? https://github.com/w3c/html/commit/37b3183567666a226d304c54d6ac5123ba564dcc

[16:14:03.0000] <Hixie>
hober?


2012-09-21
[17:16:42.0000] <Hixie>
hah, call for implementations of websockets

[18:51:47.0000] <rniwa>
AryehGregor: yt?

[19:24:57.0000] <SamB_MacG5>
/me wonders why he's seeing hyphens inserted before/after single characters on http://hsivonen.iki.fi/cms/te/ ...

[19:28:14.0000] <SamB_MacG5>
/me supposes it might help to use the "lang" attribute?

[19:48:17.0000] <SamB_MacG5>
gah... if I use the multi-page version, I get lousy back-references; if I use the single-page version, I sit there waiting for my browser...

[19:49:03.0000] <SamB_MacG5>
/me remembers being able to open the multi-page version and have his browser not grind to a halt, wonders what changed

[19:49:59.0000] <Hixie>
SamB_MacG5: which browser? if you're on a G5 I think I see your problem. :-P

[19:50:40.0000] <SamB_MacG5>
it has more RAM than any of my other systems...

[19:57:43.0000] <SamB_MacG5>
/me thinks it's unwise for a web browser with no hyphenation dictionary to try to hyphenate stuff written in latin scripts ...

[23:33:46.0000] <Hixie>
why is https://www.w3.org/Bugs/Public/show_bug.cgi?id=18223 marked invalid?

[23:33:55.0000] <Hixie>
am i missing something?

[23:34:12.0000] <Hixie>
it doesn't have any boilerplate from the editors, suggesting it was misfiled or something?

[00:07:49.0000] <zcorpan>
Hixie: any advice on translating "flow content" and "phrasing content"? http://forums.whatwg.org/bb3/viewtopic.php?t=5074&p=8102#p8102

[00:09:39.0000] <zcorpan>
Hixie: maybe darobin interpreted it as a support forum question?

[01:59:27.0000] <hsivonen>
anyone want to guess how many requests for different doctype HTML.next will get?

[02:04:47.0000] <Ms2ger>
No, it makes me sad enough without thinking about that

[02:22:15.0000] <smaug____>
hsivonen: is HTML.next some W3C thing?

[02:22:33.0000] <smaug____>
and btw, are you planning to go to TPAC?

[02:39:02.0000] <zcorpan>
<!doctype html.next>

[02:42:19.0000] <jgraham>
<!doctype html.next.next>

[02:42:45.0000] <jgraham>
gets kind of silly

[02:43:29.0000] <Ms2ger>
<!doctype html.doublenext>

[02:44:09.0000] <jgraham>
I would take inspiration from functional programming

[02:44:44.0000] <Ms2ger>
next(<!doctype html>)?

[02:44:45.0000] <jgraham>
<!doctype applyN(html, next, 2)>

[03:10:23.0000] <annevk>
for DOMTokenList

[03:10:35.0000] <annevk>
do we want DOMTokenList.contains("a", "b") as well?

[03:10:46.0000] <Ms2ger>
What does it mean?

[03:10:47.0000] <annevk>
with AND semantics

[03:11:41.0000] <annevk>
I guess I'll leave that for now

[03:12:06.0000] <Ms2ger>
If someone wants to implement it, I guess

[03:12:26.0000] <Ms2ger>
Gecko might even be able to in the near future

[03:12:38.0000] <annevk>
I'm adding arity to add() and remove() now

[03:12:49.0000] <annevk>
fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=13999 as I think that part of ES6 is ready

[03:13:31.0000] <Ms2ger>
I believe SM supports the rest thing

[03:32:04.0000] <annevk>
http://dom.spec.whatwg.org/#domtokenlist

[03:33:41.0000] <hsivonen>
walmart.ca has a lovely content-type: text/html;UTF-8;charset=UTF-8

[03:36:01.0000] <annevk>
should work fine no?

[03:37:28.0000] <hsivonen>
annevk: yes

[03:40:42.0000] <annevk>
Is there a way to make https://github.com/whatwg list the repository links as well? (Each repository can have a short description and a link, but for some reason they are only displayed on the repository page.)

[03:42:31.0000] <miketayl_r>
i don't think github offers that

[04:04:13.0000] <annevk>
darobin: adding a post-push hook is just as easy

[04:04:30.0000] <annevk>
darobin: and you get to keep control over the URL, http://url.spec.whatwg.org

[04:28:17.0000] <hsivonen>
smaug____: it’s a W3C thing. I have TPAC travel booked.

[04:28:52.0000] <smaug____>
k

[04:29:02.0000] <smaug____>
I'll be in Lyon the whole week

[04:29:13.0000] <annevk>
hmm, now I'm somewhat tempted to visit too

[04:29:34.0000] <annevk>
but I don't really want to attend any meetings

[04:30:26.0000] <smaug____>
we can pretend to not see you if you're in the meeting room during webapps wg meeting

[04:31:39.0000] <hsivonen>
the validator is correct here, isn’t it? http://bugzilla.validator.nu/show_bug.cgi?id=943

[04:32:44.0000] <annevk>
for now

[04:32:47.0000] <annevk>
I'm going to make that valid

[04:41:00.0000] <odinho>
annevk: You can come to TTWF. Or just come down and hang around. Sit in a cafe all day and hang out in breaks and stuff ;P

[04:41:48.0000] <zcorpan>
annevk: but then we won't be able to use [ and ] to delimit urls!1

[04:47:20.0000] <zcorpan>
erratum 3297 for rfc3987 is interesting

[04:48:20.0000] <zcorpan>
"it's not cool to fix errors in errata if it wasn't an error by the time we published!"

[04:48:42.0000] <annevk>
odinho: is that in the same time period?

[04:48:48.0000] <annevk>
zcorpan: oh you

[04:51:35.0000] <odinho>
annevk: Nah, it's some days before. But anyway it's a reason to travel down :P

[04:59:01.0000] <darobin>
annevk: sorry, were you replying to something? I'm missing context

[04:59:41.0000] <darobin>
annevk: there are worse places to visit than Lyon

[04:59:45.0000] <darobin>
though there are better times of year

[04:59:55.0000] <darobin>
and TTWF is in Paris right befpre

[05:07:48.0000] <annevk>
darobin: I was replying to your tweet about spec hosting

[05:09:40.0000] <annevk>
zcorpan: yeah, the errata system is bullshit

[05:10:02.0000] <annevk>
I wonder why I keep getting disconnected, oh, maybe it's OS X ML

[05:11:21.0000] <Ms2ger>
Why not OS HT ML?

[05:11:42.0000] <annevk>
Why not Zoidberg?

[05:11:55.0000] <annevk>
not here to debate philosophy

[05:13:50.0000] <annevk>
it was the OS X update btw

[05:13:56.0000] <annevk>
on battery power computer sleep was 1h

[05:14:01.0000] <annevk>
but on adapter it was 15min

[05:14:03.0000] <annevk>
because Apple

[05:14:48.0000] <hsivonen>
zcorpan: wow. the IETF is sad.

[05:27:09.0000] <darobin>
annevk: ah, that document is from tobie actually

[05:28:07.0000] <tobie>
what did I do again?

[05:28:27.0000] <annevk>
oh hey, didn't notice tobie was here

[05:28:47.0000] <darobin>
tobie: annevk was providing some cryptic feedback about your specs@gh document

[05:29:04.0000] <annevk>
tobie: re your github speccing, all I mentioned was that using a post-push commit hook you can have the same thing, but with control over the URL, e.g. http://url.spec.whatwg.org

[05:29:16.0000] <jgraham>
/me was sort of expecting to get to the end and it to say "inception"

[05:29:21.0000] <darobin>
annevk: ah, you mean instead of using gh-pages?

[05:29:25.0000] <annevk>
yeah

[05:29:35.0000] <darobin>
yes, that's fine, but it does imply that you have somewhere else to host it at

[05:29:41.0000] <darobin>
imho both are useful

[05:29:53.0000] <jgraham>
Also, I don't recommend using RSpec (sorry darobin)

[05:29:57.0000] <annevk>
WHATWG hands out spec.whatwg.org addresses to anyone who wants to spec :)

[05:30:06.0000] <tobie>
agreed. Seems like we should have two parts to it then.

[05:30:09.0000] <annevk>
we also have html5.org available if someone fancies that

[05:30:42.0000] <darobin>
jgraham: I wouldn't recommend using RSpec either, unless you want to write Ruby tests that is

[05:30:53.0000] <darobin>
but for a spec, ReSpec is the rocking rock in town!

[05:30:53.0000] <jgraham>
er ReSpec

[05:31:09.0000] <tobie>
Not really interested in the ReSpec vs something else debate, tbh. Turns out ReSpec makes the gh-pages hosting thing trivial, which I think is kind of cool.

[05:31:12.0000] <jgraham>
Turns out that two technologies that are inexplicably popular have very similar names

[05:31:16.0000] <jgraham>
:)

[05:31:42.0000] <darobin>
I blame Ali G

[05:31:49.0000] <tobie>
Happy to take pull requests, btw.

[05:32:19.0000] <tobie>
:P

[05:32:24.0000] <annevk>
yeah, ReSpec has a bunch of issues

[05:32:26.0000] <annevk>
http://wiki.whatwg.org/wiki/Howto_spec#Legacy_DOM-style in particular

[05:32:30.0000] <annevk>
I know it's not enforced

[05:32:35.0000] <annevk>
but it's used all over

[05:33:00.0000] <annevk>
e.g. in http://www.w3.org/TR/DOM-Parsing/#extensions-to-the-text-interface

[05:33:06.0000] <jgraham>
Yeah, it's not ReSpec itself, exactly, but that it seems to encourage bad style

[05:33:12.0000] <annevk>
the crappy version of http://html5.org/specs/dom-parsing.html

[05:34:03.0000] <jgraham>
I am happy to believe that ReSpec is super-awesomeness with bad defaults

[05:34:15.0000] <jgraham>
Unlike RSpec which is just fundamentally wrongheaded

[05:35:55.0000] <darobin>
as always, I'm happy to take patches :)

[05:36:14.0000] <annevk>
happy to use Anolis :)

[05:36:20.0000] <tobie>
I always <3 a good BDD bashing.

[05:36:30.0000] <darobin>
fwiw the part of ReSpec that implements legacy DOM style is called "webidl-oldschool" — perhaps for a reason :)

[05:37:10.0000] <annevk>
heh

[05:37:29.0000] <darobin>
re Anolis it's fine, I just prefer web technology

[05:38:47.0000] <jgraham>
darobin: That *is* oldskool. The kids these days can't cope unless they have a dedicated app for everything

[05:39:25.0000] <darobin>
jgraham: I guess it shows my age :)

[05:40:14.0000] <jgraham>
If Google had a sense of humor they would release an iOS maps app that is just maps.google.com

[05:41:49.0000] <annevk>
that would actually be better than the situation right now

[05:41:59.0000] <tobie>
If anyone had a sense of business, they would just wrap maps.google.com with PhoneGap and charge for it.

[05:42:04.0000] <annevk>
because maps.google.com does not indicate with some flag it can operate independently from Safari

[05:43:42.0000] <annevk>
sense of business? hah, I'm unemployed and still work

[05:44:22.0000] <tobie>
yeah, certainly not one of us.

[05:44:48.0000] <tobie>
the person with a sense of business, that is, not you annevk

[05:47:08.0000] <annevk>
I see

[05:50:13.0000] <tobie>
annevk: I'm surprised you were able to make any sense out of my rambling.

[05:56:42.0000] <Ms2ger>
jgraham, sorry, Apple wouldn't allow it

[05:58:19.0000] <Ms2ger>
tobie, so about github making it simpler to contribute tests...

[05:58:37.0000] <Ms2ger>
Do you have actual examples of outside devs submitting tests?

[05:59:05.0000] <tobie>
Ms2ger: Isn't that what Test The Web Forward is all about?

[05:59:09.0000] <odinho>
If it hasn't been done before, all the more reason to try to get it.

[05:59:19.0000] <odinho>
And yeah TTWF FTW

[05:59:32.0000] <odinho>
WTF as well. Hmm. Funny.

[05:59:54.0000] <annevk>
WHAT TF, already been done

[05:59:55.0000] <Ms2ger>
tobie, ttwf? They've been contributing to HG

[06:00:30.0000] <annevk>
miketaylr: seems only you and @whatwg are excited about add/remove

[06:00:34.0000] <annevk>
miketaylr: too little too late? :)

[06:00:59.0000] <tobie>
Well, yes. Where else would they have contributed?

[06:01:20.0000] <miketaylr>
annevk: probably way too early for the US kids to get excited

[06:01:27.0000] <miketaylr>
let them have some coffee

[06:01:33.0000] <annevk>
miketaylr: still in line for that phone?

[06:01:37.0000] <miketaylr>
heh

[06:01:53.0000] <annevk>
or maybe that's just the folk that work at Starbucks

[06:02:07.0000] <Ms2ger>
tobie, did I misunderstand? I thought you had something set up on github

[06:02:13.0000] <miketaylr>
i'm sure paul_irish will alert his fanbase

[06:02:22.0000] <annevk>
Ms2ger: for writing specs

[06:02:39.0000] <annevk>
miketaylr: hard to compete with that

[06:02:56.0000] <Ms2ger>
Oh, I thought they had something for the ringmark thing too

[06:03:28.0000] <annevk>
whenever that name falls I think of goatse

[06:03:32.0000] <annevk>
can't help it

[06:06:41.0000] <odinho>
annevk: paul_irish or ringmark?

[06:06:54.0000] <annevk>
dude hahahahah

[06:07:07.0000] <tobie>
Ms2ger: Ringmark's a Facebook product with a high barrier to contribution (need a PHP server and a full node install, uses a custom test framework, etc). Really don't think it's relevant in this conversation.

[06:07:15.0000] <Ms2ger>
Oh

[06:07:22.0000] <Ms2ger>
Then I guess I misunderstood

[06:09:46.0000] <tobie>
annevk: thanks for the image.

[06:16:00.0000] <annevk>
lol

[06:16:01.0000] <annevk>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=11204#c52

[06:21:19.0000] <gsnedders>
Ms2ger: Equally, though I believe it is now better, you originally had to support the webkit prefix to do well at Ringmark.

[06:22:00.0000] <Ms2ger>
I saw a check for window.opera and gave up

[06:23:13.0000] <gsnedders>
Oh, test262 sniffs for Opera too. It used to make us fail tests. We tried to get it fixed to remove browser sniffing, but instead they just changed the Opera codepath.

[06:23:25.0000] <gsnedders>
Well, at least it now works regardless of whether you expose window.opera…

[06:23:47.0000] <zcorpan>
hsivonen: what's the status of regression tests for the validator?

[06:24:26.0000] <gsnedders>
hsivonen: Did I not see somewhere some meta charset sniffing tests you wrote? Able to release them under the MIT license for html5lib?

[07:31:37.0000] <miketaylr>
Chad Rampley is having a rough day, it would appear

[07:58:39.0000] <annevk>
hmm

[07:58:47.0000] <annevk>
thus far the only must statements in the URL Standard are in the API section

[07:58:54.0000] <annevk>
I guess that works

[07:59:35.0000] <annevk>
Would it be weird to name the Creating section Parsing and the "parse" bit "tokenize"?

[07:59:51.0000] <annevk>
it does a bit more than a typical tokenizer, but otherwise it's fairly close, and "Creating" is odd

[08:01:37.0000] <Hixie>
wow, we have no way to render the shadow in canvas but not the shape

[08:01:47.0000] <Hixie>
if you set the shape to transparent, the shadow doesn't render

[08:15:13.0000] <SamB_MacG5>
Hixie: Oh, I seem to have missed where you asked me "which browser?" last night.  I'm using TenFourFox 15 on this machine.

[08:16:02.0000] <annevk>
I emailed the list instead

[08:16:07.0000] <annevk>
lets see if that goes any better

[08:17:32.0000] <SamB_MacG5>
is rendering the shadow without the shape terribly important?

[08:31:43.0000] <dglazkov>
goodd morning, Whatwg!

[08:40:53.0000] <jgraham>
Can we video fantasai doing her "How to file a perfect bug report" talk?

[08:41:21.0000] <jgraham>
Or better yet, can we get a two minute video "How to file a bug report that won't be closed as invalid on sight"?

[10:45:24.0000] <MadPig>
I still don't get the whole "dropped version number" thing. How is a browser gonna know what to use? Why isn't it <html version="5.0"> or <html version="5.1">? Why can't it make sense?

[10:48:21.0000] <Ms2ger>
/me yawns

[10:48:33.0000] <Ms2ger>
Because a browser always uses the latest version it implements

[10:49:12.0000] <dglazkov>
the shuttle flyover!

[10:49:14.0000] <MadPig>
What?

[10:49:15.0000] <dglazkov>
yay

[10:49:20.0000] <MadPig>
Please try to make some sense.

[10:54:15.0000] <Ms2ger>
Do you know space shuttles?

[10:54:17.0000] <Ms2ger>
They fly

[10:54:18.0000] <Ms2ger>
over

[10:59:24.0000] <TabAtkins>
The flyover was very cool. ^_^

[11:00:36.0000] <dglazkov>
http://www.nasa.gov/centers/ames/events/2012/9.20.12_Shuttle_Endeavour.html for context

[11:40:21.0000] <smaug____>
is Rick Byers ever here ?

[11:59:47.0000] <Hixie>
Ms2ger: if you get questions about the version number thing, i recommend pointing them to the faq

[12:00:21.0000] <Hixie>
whatwg.org/faq

[12:07:23.0000] <Ms2ger>
Yay, a FAQ :)

[12:09:27.0000] <TabAtkins>
SamB_MacG5: I haven't finished reading through scrollback, so someone may have gotten back to you, but XBL2 was dropped due to lack of implementor interest.  It was too complex.

[12:09:55.0000] <TabAtkins>
SamB_MacG5: We're doing essentially the same thing, but in a saner way, with Web Components.  It has impl interest, too - WebKit is the original implementor, and Firefox is getting into it as well.

[12:11:01.0000] <SamB_MacG5>
yeah, annevk said something along those lines

[12:11:14.0000] <SamB_MacG5>
(rather more tersely, though)

[12:11:38.0000] <SamB_MacG5>
(and didn't mention the implementation status of web components)

[12:15:02.0000] <SamB_MacG5>
TabAtkins: is there a good wiki overview of web components?

[12:16:41.0000] <Hixie>
TabAtkins: web components has the same level of interest in it now as xbl2 did about 10 years ago... we'll see how long it holds!

[12:16:46.0000] <TabAtkins>
SamB_MacG5: Not wiki, but we have an explainer document: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html

[12:16:56.0000] <TabAtkins>
Hixie: Who actually implemented XBL2?

[12:16:59.0000] <Hixie>
TabAtkins: i have hope, though. dglazkov's approach of splitting it up into smaller problems is solid

[12:17:08.0000] <Hixie>
TabAtkins: mozilla implemented xbl1, xbl2 is just a recasting of it.

[12:17:20.0000] <Hixie>
TabAtkins: hyatt had parts of xbl2 implemented in webkit

[12:17:37.0000] <TabAtkins>
I'll have to trust you on that - from what I understood, XBL2 was significant different from 1.

[12:17:52.0000] <SamB_MacG5>
Hixie: yes, but was mozilla interested in either implementing both simultaneously, or trying to migrate AMO (and then some) to XBL2?

[12:18:40.0000] <SamB_MacG5>
I guess AMO *was* probably smaller then, but still...

[12:19:00.0000] <Hixie>
TabAtkins: well, 1 never had a real spec. xbl2 was an attempt at speccing it and cleaning it up.

[12:19:26.0000] <Hixie>
SamB_MacG5: everyone was "interested" at one point or another :-) nothing really went anywhere.

[12:19:42.0000] <Hixie>
SamB_MacG5: hopefully dglazkov's approach will be more successful

[12:20:05.0000] <Hixie>
(i expect that it will)

[12:20:24.0000] <dglazkov>
it's all about proper cheerleading

[12:20:30.0000] <SamB_MacG5>
well, I guess my point is that both of those approaches sound painful, though at least "implement both simultaneously" might have been possible...

[12:20:31.0000] <dglazkov>
\o/ web components \o/

[12:20:56.0000] <SamB_MacG5>
dglazkov: smaller pieces probably also helps?

[12:21:13.0000] <TabAtkins>
Smaller pieces has been working out extremely well in all our efforts.

[12:21:18.0000] <dglazkov>
SamB_MacG5: sure. but cheerleading. \o/

[12:21:24.0000] <dglazkov>
:)

[12:21:32.0000] <TabAtkins>
It's also much saner for the platform as a whole, because it means you're much more likely to get something that relies on a minimum of magic.

[12:22:08.0000] <TabAtkins>
Less magic = easier to implement slight variations in libraries, or to tweak details for yourself.

[12:22:51.0000] <TabAtkins>
Some of the worst additions to the platform are large dumps, because they tend to have too much interconnected stuff, so you can't tweak any details without reimplementing the whole stack yourself.

[12:23:05.0000] <dglazkov>
Mozilla is trying to ship parts of it pretty soon, afaik

[12:23:09.0000] <TabAtkins>
See: CSS layout, which desperately needs some lower-level primitives.

[12:25:10.0000] <Hixie>
i don't know that i'd agree entirely with that philosophy

[12:25:47.0000] <TabAtkins>
I know you don't.  You're wrong. ^_^

[12:26:14.0000] <Hixie>
i know you are, but what am i? :-P

[12:26:23.0000] <TabAtkins>
Rubber, apparently.

[12:29:26.0000] <Hixie>
in general, the reason i don't entirely buy into the philisophy you describe is that it relies on a host of very vague and relative concepts like "magic", "easier", "large", "too much", "lower".

[12:29:44.0000] <Hixie>
i do agree with many of hte conclusions you draw from this philosophy

[12:29:58.0000] <Hixie>
but i am not comfortable with it as stated

[12:30:08.0000] <SamB_MacG5>
Hixie: oh, you think he hand-waves too much?

[12:30:12.0000] <jgraham>
dglazkov: You need to work on your ascii dance shapes if you want adoption. At least throw in some \o\ and /o/

[12:30:41.0000] <TabAtkins>
The concepts are vague and arguable, but the philosophy seems to work well in practice, and be useful for arguing with people over what should be native vs libraries vs predefined in terms of native stuff.

[12:30:46.0000] <dglazkov>
¯\_(ツ)_/¯

[12:30:54.0000] <dglazkov>
---(ツ)_/¯

[12:31:01.0000] <dglazkov>
 _/¯(ツ)_/¯

[12:31:02.0000] <jgraham>
Now you're just being silly

[12:31:06.0000] <SamB_MacG5>
anyway, small pieces makes it easier to get somewhere

[12:31:08.0000] <dglazkov>
_/¯(ツ)---

[12:31:11.0000] <dglazkov>
:)

[12:31:14.0000] <jgraham>
:)

[12:31:29.0000] <Hixie>
TabAtkins: if it's just meant to be a way to convince people who aren't paying much attention, ok :-)

[12:31:35.0000] <dglazkov>
if you come to #chromium, you can always as trungl-bot to dance

[12:32:09.0000] <Hixie>
TabAtkins: but then it's not a philosophy, it's just a... something, there's a word for it, i forget what

[12:32:25.0000] <TabAtkins>
Hixie: I think it's a reasonable statement of my actual philosophy toward platform additions, but it's also useful as a conversational bludgeon.

[12:32:28.0000] <Hixie>
TabAtkins: i would be interested in working out what the real philosophy is

[12:32:46.0000] <Hixie>
"bludgeon" isn't the word i was looking for but it'll do :-P

[12:32:55.0000] <TabAtkins>
crowbar

[12:33:01.0000] <TabAtkins>
To pry apart their argument.

[12:35:09.0000] <dglazkov>
I think slightlyoff's Bedrock post describes the approach pretty well

[12:35:35.0000] <TabAtkins>
Yes, that's a rather more verbose statement of it.

[12:35:50.0000] <SamB_MacG5>
/me wonders how hard it would be to make the HTML spec display like the multi-page version, while still keeping a DOM like that of the single-page version

[12:35:59.0000] <SamB_MacG5>
/me also wonders if this would perform better

[12:36:09.0000] <TabAtkins>
What do you mean by "display like"?

[12:36:23.0000] <Hixie>
yeah i _definitely_ don't agree with the principles in /bedrock/

[12:36:37.0000] <SamB_MacG5>
TabAtkins: I mean, showing one chunk at a time

[12:36:45.0000] <SamB_MacG5>
however the multi-page version is chunked

[12:37:26.0000] <TabAtkins>
SamB_MacG5: Ah, kk.  That would help with some performance issues (less things in the rendering structure at once), but not all.

[12:39:22.0000] <SamB_MacG5>
TabAtkins: Yes, that was my thinking

[12:40:07.0000] <SamB_MacG5>
I mean, at the very least it the browser wouldn't have to look at the hidden parts of the tree during layout, right?

[12:40:29.0000] <jgraham>
The problem with philosphy is that it sounds good with highfalutin ideas, but when the real world comes along it tends to fall apart rather quickly

[12:40:50.0000] <TabAtkins>
Correct.  display:none things dont' show up in the render tree at all.

[12:41:03.0000] <TabAtkins>
jgraham: And yet, it seems to be working out well for us.

[12:41:04.0000] <Hixie>
i think the problem with /bedrock/ is that it has a faulty initial assumption. e.g. I wouldn't describe the JVM as particularly core to what Java is.

[12:41:19.0000] <Hixie>
there are "platform" concepts that apply above it -- the language apis, e.g.

[12:41:26.0000] <jgraham>
TabAtkins: What does?

[12:41:34.0000] <SamB_MacG5>
and, while there's no *guarantee* that source locality corresponds with address-space locality, it seems likely that it often would?

[12:41:41.0000] <Hixie>
there are "platform" concepts that apply below it -- the chip's number of processors, cache lines, etc, e.g.

[12:41:50.0000] <Hixie>
and you don't _need_ a jvm for java anyway

[12:42:04.0000] <SamB_MacG5>
as long as most of the DOM was left pristine?

[12:42:09.0000] <Hixie>
and you can write non-java to the jvm

[12:42:18.0000] <Hixie>
and there are things the jvm can do that java can't

[12:42:32.0000] <Hixie>
anyway

[12:42:41.0000] <SamB_MacG5>
you don't need a JVM to use JVM code, for that matter ;-)

[12:42:50.0000] <TabAtkins>
jgraham: The concept of "specify the minimum amount of magic at the bottom, and then define all the author-useful stuff in terms of that, rather than just defining author-useful things directly with larger amounts of magic".

[12:43:00.0000] <SamB_MacG5>
I can think of two ways to use JVM code without a JVM

[12:43:04.0000] <Hixie>
TabAtkins: what is "magic"?

[12:43:08.0000] <TabAtkins>
When people violate that, authors end up having to reimplement the entire thing from the ground up to make small tweaks.

[12:43:22.0000] <TabAtkins>
Hixie: Anything you can't do (or can't do performantly) from author-space code.

[12:43:25.0000] <jgraham>
TabAtkins: Where is that working out for you?

[12:43:42.0000] <jgraham>
CSS certainly doesn't seem like an example of taht

[12:43:53.0000] <jgraham>
And web compoents doesn't exist yet

[12:43:53.0000] <SamB_MacG5>
TabAtkins: that reminds me of Python

[12:43:59.0000] <TabAtkins>
jgraham: For example, all of our attempts to expand the web platform as part of the Parkour project.

[12:44:00.0000] <Hixie>
TabAtkins: so in java, everything is magic?

[12:44:03.0000] <TabAtkins>
Web Components, MDV, etc.

[12:44:14.0000] <Hixie>
TabAtkins: indeed, in C++, everything is magic?

[12:44:34.0000] <TabAtkins>
Hixie: Huh?

[12:44:39.0000] <Hixie>
TabAtkins: i don't understand your definition of "magic"

[12:44:40.0000] <Ms2ger>
Huh?

[12:44:43.0000] <jgraham>
SamB_MacG5: Python has *loads* of magic

[12:44:55.0000] <jgraham>
TabAtkins's definition sounds like C

[12:45:07.0000] <TabAtkins>
Hixie: Hm, not sure how to restate it.  Anything you can't polyfill with reasonable performance is probably magic.

[12:45:29.0000] <Hixie>
TabAtkins: x86 has instructions that perform stuff that you can't do "performantly" using other instructions, are they magic?

[12:45:36.0000] <TabAtkins>
The amount of magic is proportional to how much of the stack you need to reimplement to tweak details of it.

[12:45:39.0000] <SamB_MacG5>
jgraham: I was thinking about how much more of the magic is kept in the Lib/ tree than in the core

[12:45:47.0000] <TabAtkins>
Hixie: Yes, the lowest-level things are always magic.

[12:46:02.0000] <Hixie>
you can build non-magic on top of magic? o_O

[12:46:08.0000] <SamB_MacG5>
(and isn't really magic at all)

[12:46:10.0000] <TabAtkins>
By definition, yes.

[12:46:18.0000] <Hixie>
i think a different term would be more helpful here for me to understand what you're trying to argue

[12:46:24.0000] <SamB_MacG5>
Hixie: never heard of magitek?

[12:46:30.0000] <TabAtkins>
Perhaps a better term to help your understanding would be "atomic"?

[12:46:32.0000] <jgraham>
SamB_MacG5: But all the protocols and stuff in python are built-in magic

[12:46:38.0000] <TabAtkins>
An indivisible piece of functionality?

[12:47:07.0000] <Hixie>
TabAtkins: i think the problem is that you seem to be assuming that being able to divide functionality is a good thing

[12:47:08.0000] <TabAtkins>
Something which acts as if it's a bottom layer, rather than being composed of other things.

[12:47:26.0000] <SamB_MacG5>
the __methods__ are, yes

[12:47:32.0000] <TabAtkins>
Being able to divide functionality *is* good.  It's not an unrestricted good, of course - it often hurts performance.

[12:47:44.0000] <SamB_MacG5>
otherwise, the protocols are not part of Python

[12:47:49.0000] <jgraham>
Anyway to me the "bedrock" post sounds like second system syndrome

[12:47:53.0000] <TabAtkins>
Which is why precomposed versions of things are good - you can optimize them, even though they're not bottom-level.

[12:48:01.0000] <SamB_MacG5>
they are just applied late-binding

[12:48:26.0000] <jgraham>
On the other hand, I do think the Web Components project is interesting and potentially useful

[12:48:36.0000] <Hixie>
TabAtkins: nah, i disagree. it's way more subtle than that. you have to balance api usability, security, performance, efficiency -- all these things lead to finding a balance and does not at all lead to always suggesting that the best API is the one that can be ultimately decomposed.

[12:48:57.0000] <TabAtkins>
Hixie: The funny thing, we'd argue the opposite.  This is an attempt to take an elephantine, feature-laden monstrosity and bake it back down into a number of small, elegant systems.

[12:48:58.0000] <SamB_MacG5>
TabAtkins: you want small but powerful primitives ("system calls"), from which the rest can be built ("userspace code")

[12:49:16.0000] <TabAtkins>
Hixie: Of course.  I wouldn't argue that decomposability is an absolute good that must be preserved at all costs.

[12:49:24.0000] <TabAtkins>
But it is *a* good, and one which should not be understated.

[12:49:26.0000] <jgraham>
If it doesn't follow the trajectory of the last three attempts to do the same thing

[12:49:28.0000] <Hixie>
TabAtkins: sounds like you are arguing exactly that :-)

[12:49:48.0000] <TabAtkins>
Hixie: Only because you're attempting to distill an absolutist philosophy from what I'm saying. ^_^

[12:50:03.0000] <Hixie>
TabAtkins: i tend to do that when someone just says "you're wrong" :-P

[12:50:30.0000] <SamB_MacG5>
TabAtkins: with the goal being to have more user-servicable parts

[12:50:37.0000] <TabAtkins>
I was able to jump straight to that because I've butted heads with you on similar things in the past, where you've dismissed the value of decomposability in what I felt was far too cavalier a fashion.

[12:50:43.0000] <TabAtkins>
SamB_MacG5: Yes.

[12:50:44.0000] <Hixie>
TabAtkins: i think it's fine to argue from use cases, and the uses cases might lead to an API based on small components, or they might lead to an "elephantine" API that wraps lots of "magic" into a simple performant API that isn't particularly flexible

[12:50:58.0000] <Hixie>
TabAtkins: i think it's a mistake to just assume that small components are better though

[12:51:33.0000] <TabAtkins>
Hixie: My first impulse is always to develop what I want the final API to look like, then look for ways to break it down.  Occasionally you can't, and need to stay high-level with hidden functionality.  But you usually can, and it's usually a good idea.

[12:51:34.0000] <jgraham>
(It is also kind of funny that you are arguing this point and rniwa and abarth are insisting that WebKit will never allow APIs with JS<->C++ cycles i.e. will block any attempt to add native-backed js-like APIs to the platform)

[12:52:04.0000] <abarth>
hi

[12:52:08.0000] <TabAtkins>
jgraham: That's not contradictory.  It just means that we have multiple forces pulling on us.

[12:52:35.0000] <abarth>
i feel like i'm missing context

[12:52:40.0000] <jgraham>
TabAtkins: That sounds contradictory to me :)

[12:52:54.0000] <abarth>
jgraham: there might well be a difference between what TabAtkins wants to design and what we're actually able to build

[12:52:59.0000] <Hixie>
TabAtkins: i think where we disagree is that you're willing to assume that it's a good idea until proved otherwise, whereas i'm more likely to try to keep the API as simple as possible until decomposition is proved necessary.

[12:53:30.0000] <jgraham>
abarth: Sure

[12:53:36.0000] <Hixie>
TabAtkins: which is to say, i prioritise simplicity of the API for the use cases over flexibility of the API for unexpected use cases, and you vice versa.

[12:54:03.0000] <SamB_MacG5>
Hixie: both are important

[12:54:19.0000] <Hixie>
SamB_MacG5: yes, though they are often at odds

[12:54:40.0000] <SamB_MacG5>
which is why APIs tend to have layers

[12:56:00.0000] <dglazkov>
Hixie: I think you understood the difference wrong. The basic tenet of Bedrock post is that for each feature HTML, you should expect a developer to come by and say: "Hey, that's cool! How do I do the same thing, but slightly differently. How do I do that?"

[12:56:23.0000] <dglazkov>
remember our debates about whether it's useful to have a progress element auto-orients?

[12:56:27.0000] <jgraham>
(also making this a point about *DOM* specifically is a bit odd. For example if you were building the web from the ground up you might let developers write custom CSS properties in javascript. But I don't think anyone is proposing that)

[12:56:58.0000] <SamB_MacG5>
jgraham: hmm ... now you've got me imagining use cases ...

[12:57:10.0000] <Hixie>
dglazkov: sure, that's another aspect of that post. I think the answer to that question should often be "don't", though, which is another way in which i disagree with slightlyoff a lot :-)

[12:57:29.0000] <TabAtkins>
abarth: It would probably be good to have you review some of the shadow DOM stuff. ^_^

[12:57:30.0000] <SamB_MacG5>
but the implementation would involve a lot of new API

[12:57:34.0000] <astearns>
jgraham: aren't some polyfills "custom CSS properties in javascript"?

[12:57:56.0000] <jgraham>
astearns: In some limited sense I guess

[12:57:59.0000] <dglazkov>
Hixie: don't is the answer you can't give

[12:58:05.0000] <TabAtkins>
Hixie: Yup, when you say "don't", the usual response is "okay, I'll do it myself in JS and ignore your shitty native stuff".

[12:58:07.0000] <SamB_MacG5>
hmm, actually, sounds like a nightmare for the CSS WG

[12:58:16.0000] <abarth>
TabAtkins: happy to look at it

[12:58:34.0000] <TabAtkins>
abarth: dglazkov would know well what the prickly parts probably are.

[12:58:41.0000] <Hixie>
dglazkov, TabAtkins: people do bad stuff on the web all the time, but we _certainly_ shouldn't optimise the APIs to help them do so.

[12:58:45.0000] <jgraham>
But I don't think you can e.g. implement your own display: values in a sensible way that interacts with all the other values

[12:59:37.0000] <SamB_MacG5>
maybe some kind of user-use namespace for CSS properties, with no support for complicated grammars?

[12:59:58.0000] <jgraham>
and if you did want do do that I guess you would need to expose a crazy amount of internal state of the layout engine

[13:00:00.0000] <Hixie>
darobin: what's the context behind https://www.w3.org/Bugs/Public/show_bug.cgi?id=18223 ? i'm confused as to why you marked it invalid without even the boilerplate, is it something you know was filed by mistake or something?

[13:00:04.0000] <astearns>
jgraham: I agree for some value of "sensible" - you can throw a non-sensible amount of javascript towards creating a bespoke layout mode

[13:00:11.0000] <jgraham>
And you don't want to do that

[13:00:22.0000] <jgraham>
So we don't support display:function() {}

[13:00:36.0000] <dglazkov>
Hixie: re: meter/progress <-- I bet you couldn't foresee these scenarios: http://chemicaloliver.net/internet/styling-the-html5-meter-tag-using-the-shadow-dom/

[13:00:42.0000] <jgraham>
astearns: Yeah, but that's faking it

[13:00:51.0000] <TabAtkins>
Right.  I think we should expose better primitives for layout, but exactly how far down we go is an important question.

[13:01:04.0000] <jgraham>
I mean you run your script after all the native layout has happened

[13:01:05.0000] <SamB_MacG5>
jgraham: more to the point, layout engines change ...

[13:01:23.0000] <SamB_MacG5>
or, well, not more

[13:01:23.0000] <Hixie>
dglazkov: we absolutely considered that use case. That's exactly what XBL2 was intended to allow, and what Web Components will allow

[13:01:35.0000] <TabAtkins>
jgraham: For example, I have a sketch of adding constraints to abspos that lets you do a *lot* of layout with minimal script interaction.

[13:01:52.0000] <dglazkov>
Hixie: not if you had that crazy magic with auto-rotation depending on width/height ratio

[13:01:59.0000] <Hixie>
dglazkov: yes, even with that.

[13:02:06.0000] <TabAtkins>
Heh, relevant quote from a few minutes ago, on an unrelated G+ comment:

[13:02:14.0000] <TabAtkins>
That would certainly be useful -- as it is there's an enormous cliff between "I got something simple working in CSS" and "I had to ditch the whole bloody thing and rewrite it by hand because I couldn't get control over one little thing"...

[13:02:24.0000] <TabAtkins>
^^^ Quote from Joel Webber

[13:02:26.0000] <Hixie>
dglazkov: the rotation is implemented by the default binding, so providing a new binding lets you do whatever rotation you want.

[13:02:26.0000] <astearns>
heh

[13:02:32.0000] <jgraham>
TabAtkins: But that isn't really the "bedrock" philosphy. You're not allowing users to inject script into the layout lifecycle, or subclass display schemes

[13:03:11.0000] <SamB_MacG5>
jgraham: you can't provide hooks for *everything*

[13:03:12.0000] <jgraham>
You're proposing a much more limited set of powers that has the practical advantage of being implemntable

[13:03:14.0000] <TabAtkins>
jgraham: There's a gradient from "write it in assembly" to "just use this predefined element".

[13:03:15.0000] <Hixie>
dglazkov: (in fact i would say that's a great example of why the way webkit implemented meter is wrong)

[13:03:19.0000] <dglazkov>
Hixie: see quote above from Joel. To get rid of auto-rotation, you have _rewrite_the_whole_thing_

[13:03:45.0000] <jgraham>
TabAtkins: Hence my point about philosophy quickly crumbling against the rigours of reality

[13:03:47.0000] <Hixie>
dglazkov: no, you only have to rewrite the rendering.

[13:04:13.0000] <Hixie>
dglazkov: that's the whole point of web components (specifically, css-bound web components)

[13:04:17.0000] <TabAtkins>
jgraham: Obviously, the correct answer isn't always "expose the lowest-level thing all the time".  However, it *is* correct to seek out the lowest-level thing you can reasonably expose, rather than just stopping once you've created something which solves the use-cases presented.

[13:04:51.0000] <Hixie>
the lowest-level thing you can _reasonably_ expose _is_ what you're created that solves the use cases presented. :-)

[13:04:53.0000] <jgraham>
I don't think that's true

[13:05:04.0000] <jgraham>
Ah, Hixie beat me

[13:05:26.0000] <jgraham>
It's not like it's *hard* to think of use cases

[13:05:35.0000] <TabAtkins>
Hixie: That's wrong.  There are always use-cases that weren't presented to you.  Finding a spanning set of primitives often works better than exactly solving the use-cases you happened to see.

[13:05:38.0000] <astearns>
I'm with Tab - the use cases presented are almost always the tip of the iceberg

[13:05:50.0000] <SamB_MacG5>
Hixie: some specs don't expose the thing, though

[13:06:09.0000] <Hixie>
TabAtkins: as spec editor it is one's job to seek out such use cases

[13:06:11.0000] <TabAtkins>
*Then* you define things on top of those primitives that exactly solve those use-cases.

[13:06:14.0000] <SamB_MacG5>
they just use it internally

[13:06:29.0000] <TabAtkins>
Hixie: As a spec editor who thinks he does his job well, I always find more use-cases after the fact.

[13:06:31.0000] <jgraham>
But with e.g. Shadow DOM the problem has *never* been lack of use cases

[13:06:59.0000] <jgraham>
We have known for more than a decade that there were use cases that needed that sort of capability

[13:07:27.0000] <Hixie>
TabAtkins: in my experience, when i find use cases after the fact, they would rarely have been solved by my taking a more decomposed approach -- because you can't know how to decompose it if you don't know what the use cases are.

[13:07:30.0000] <SamB_MacG5>
jgraham: well, yeah; the Mozilla sources are full of them ;-)

[13:07:49.0000] <jgraham>
The problem has always been finding something that is simple enough to get cross-browser implemntations

[13:08:33.0000] <TabAtkins>
Hixie: Sometimes, sure.  However, small tweaks from the existing use-cases are often easy if you did a decomposed approach (because you can more easily slot in the small change you want), and extending the solution later is often easy as well, for the same reason.

[13:09:04.0000] <jgraham>
So if you want it to succeed, you should prioritise simplicity of implementation over flexibility, subject to the constraint that you still meet (the most significant) use cases

[13:09:07.0000] <TabAtkins>
I mean, don't decompose too early or too aggressively, because there are always multiple ways to do it, and it can be hard to tell which way is best.  But keep it in mind, and as patterns emerge, break ti down.

[13:09:32.0000] <TabAtkins>
jgraham: Often, breaking things down aids simplicity of implementation, because each piece is simpler.

[13:09:41.0000] <TabAtkins>
(Though often the total complexity is somewhat higher.)

[13:09:50.0000] <SamB_MacG5>
I guess you should try to decompose in a way that simplifies implementation?

[13:10:03.0000] <Hixie>
TabAtkins: sure, you should definitely design features to fit all the use cases, included use cases taht you come up with that are small tweaks of previous ones.

[13:10:08.0000] <jgraham>
TabAtkins: That doesn't obviously follow

[13:10:19.0000] <jgraham>
But my main point stands

[13:10:39.0000] <SamB_MacG5>
it's simpler to make progress in implementing something that's decomposed:

[13:11:00.0000] <jgraham>
Which is that if I were designing this feature I would be prepared to compromise on flexibility whereever it aided implementability

[13:11:00.0000] <SamB_MacG5>
you implement a piece that doesn't depend on any pieces you don't have yet

[13:11:02.0000] <TabAtkins>
SamB_MacG5: Yes, that's often the right thing to do, I think.  If you find the cleave points in the implementation, it's usually better for overall performance when you reuse individual bits.

[13:11:21.0000] <Hixie>
TabAtkins: my point is that you shouldn't prematurely decompose when doing so is _not_ necessary to address use cases, because (a) that makes the API more complicated, (b) it's not necessary (by definition), and (c) it likely doesn't address the unknown use cases, and in fact, can preclude addressing them due to over-designing (it's easier to shift direction later if you haven't over-decomposed)

[13:11:53.0000] <TabAtkins>
Hixie: I agree with you.  I believe we simply disagree on when it's "premature".

[13:12:06.0000] <TabAtkins>
Based on the types of APIs that we make in Parkour, and the types of APIs that you make in HTML. ^_^

[13:12:09.0000] <Hixie>
my definition is easy: you do the minimum necessary to address all the use cases

[13:12:22.0000] <jgraham>
TabAtkins: Really? e.g. slightlyoff's example of being able to reuse <canvas> to customise drawing of form controls doesn't seem like it would make anything easier or more performant

[13:12:25.0000] <SamB_MacG5>
Hixie: it could make the API more complicated, sure; but it might make it simpler to understand or implement

[13:12:40.0000] <jgraham>
(or rahter 2D context, I guess)

[13:12:57.0000] <Hixie>
SamB_MacG5: ease of implementation is a lower priority than ease of usability (because there's like 4 groups of implementors, and millions of authors.)

[13:13:16.0000] <SamB_MacG5>
Hixie: but understanding is something the users use

[13:13:21.0000] <Hixie>
SamB_MacG5: authors

[13:13:37.0000] <Hixie>
SamB_MacG5: but yes, and simpler APIs tend to be simpler to understand.

[13:13:43.0000] <TabAtkins>
Hixie: However, implementation often guides you to the correct cleave points for performance.

[13:13:59.0000] <Hixie>
SamB_MacG5: just compare HTML (high-level composed features) to XBL (very decomposed featureset) :-)

[13:14:10.0000] <SamB_MacG5>
Hixie: you'll have to excuse me when I say "user" when I mean "programmer"; I hang out in *nix circles ;-)

[13:14:33.0000] <Hixie>
TabAtkins: decomposition is _definitely_ not the way to get higher performance for hte common case (though it can lead to higher performance for the more unusual cases)

[13:15:00.0000] <Hixie>
SamB_MacG5: in web circles, user=the reader, author=the programmer, implementor=the browser vendor

[13:15:09.0000] <TabAtkins>
Yes, I've already stated that.  Decomposing can hurt performance, which is why you should also provide precomposed versions that you can black-box optimize.

[13:15:24.0000] <SamB_MacG5>
anyway, I like legos

[13:15:35.0000] <Hixie>
TabAtkins: i think we're more or less in agreement, we just tend to apply this all quite differently

[13:15:43.0000] <TabAtkins>
That's what I've been saying. ^_^

[13:15:49.0000] <Hixie>
TabAtkins: and somehow i'm happier with what we have overall than you :-P

[13:16:31.0000] <Hixie>
anyone understand https://www.w3.org/Bugs/Public/show_bug.cgi?id=17936 ?

[13:17:26.0000] <jgraham>
Hixie: I understand that it should be resolved INVALID for deviation from the English language as we know it

[13:17:46.0000] <Hixie>
just a minute, buzz for deviation?

[13:17:50.0000] <Ms2ger>
^

[13:17:54.0000] <jgraham>
:)

[13:18:00.0000] <TabAtkins>
How would you write the gerund of "arc"?

[13:18:01.0000] <Hixie>
man i miss that show

[13:18:07.0000] <Ms2ger>
It's still on ;)

[13:18:12.0000] <Hixie>
yeah, but there's no podcast

[13:18:17.0000] <TabAtkins>
"arcing"?

[13:18:20.0000] <jgraham>
There is iplayer

[13:18:24.0000] <Ms2ger>
Yeah

[13:18:27.0000] <Hixie>
really?

[13:18:29.0000] <Hixie>
oooh...

[13:18:35.0000] <Hixie>
i may have to hook myself up a manual podcast

[13:18:43.0000] <Hixie>
they VERY OCCASIONALLY put it on the comedy of the week podcast

[13:18:49.0000] <Ms2ger>
"Listen now (3 days left)"

[13:18:52.0000] <Hixie>
they put the indian one recently on

[13:19:02.0000] <jgraham>
http://www.bbc.co.uk/programmes/b01mqmsb

[13:19:08.0000] <Ms2ger>
When they were in India? That's ages ago! :)

[13:19:36.0000] <Hixie>
yeah, that was a while back

[13:19:42.0000] <Hixie>
that's the last one they had on though

[13:19:53.0000] <Hixie>
("recently" as in "in the past 2 years")

[13:20:02.0000] <jgraham>
It wasn't *that* long ago

[13:20:45.0000] <SamB_MacG5>
/me closes that as NEEDSINFO, on the theory that they could get someone to help them with their english

[13:20:59.0000] <SamB_MacG5>
/me has no idea why he's allowed to do that

[13:21:44.0000] <jgraham>
FWIW I think the point of the bug was that they want HTML to be simple for distributing textual information or something

[13:21:58.0000] <SamB_MacG5>
that is certainly a goal

[13:22:20.0000] <TabAtkins>
And is luckily already met!  RESOLVED WORKSFORME

[13:22:43.0000] <SamB_MacG5>
shouldn't do that unless you can actually understand the message ;-)

[13:23:14.0000] <TabAtkins>
Yeah, the current resolution is the best one. ^_^

[16:17:34.0000] <rniwa>
sicking: yt?

[16:17:46.0000] <sicking>
rniwa: yup

[16:17:50.0000] <rniwa>
sicking: hi!

[16:18:18.0000] <rniwa>
sicking: do you care about interop. of mutation observers in the presence of mutation events?

[16:18:43.0000] <rniwa>
sicking: in particular, what happens regards to delivering mutation records and the order thereof when mutation event listeners modify DOM.

[16:19:31.0000] <rniwa>
sicking: as far as we know, mutation events isn't spec'ed in DOM4 so we can't really spec it.

[16:19:44.0000] <sicking>
rniwa: i personally don't particularly care that much no

[16:19:56.0000] <rniwa>
sicking: okay.

[16:20:27.0000] <rniwa>
sicking: i'm a bit worried that some js libraries (notably rich text editors) rely on mutation events

[16:20:39.0000] <rniwa>
sicking: and other libraries on the same page that use mutation observers might get confused

[16:20:42.0000] <sicking>
rniwa: i can't speak for Olli, but it seems like that time would be better spent adding code that warns about mutationevents being used and otherwise discouraging people from using them

[16:20:48.0000] <rniwa>
sicking: but i guess that might be too much of an edge case to worry about :)

[16:21:10.0000] <rniwa>
sicking: true.

[16:21:25.0000] <rniwa>
sicking: but there will be some time before all major browsers on desktop & mobile start shipping mutation observers.

[16:21:30.0000] <sicking>
rniwa: so i take it that you will be adding mutationrecords in reverse order in some cases?

[16:21:31.0000] <rniwa>
sicking: e.g. Safari hasn't implemented mutation observers yet.

[16:21:38.0000] <rniwa>
sicking: no.

[16:21:50.0000] <rniwa>
sicking: we'll be enqueuing earlier sometimes

[16:21:56.0000] <sicking>
rniwa: Safari for iOS6 apparently has mutationobservers

[16:22:03.0000] <rniwa>
sicking: it does?

[16:22:05.0000] <rniwa>
interesting.

[16:23:21.0000] <sicking>
caniuse doesn't have them, but i read it on the internet so i'm sure it's true :0

[16:23:27.0000] <sicking>
:)

[16:25:42.0000] <rniwa>
sicking: apparently, safari doesn't get the end of task right :(

[16:25:49.0000] <rniwa>
sicking: so editing case is broken.

[16:26:04.0000] <sicking>
fabulous :(

[16:26:47.0000] <rniwa>
oh well… i guess we can file a apple bug.

[16:26:54.0000] <rniwa>
an*

[16:28:30.0000] <rniwa>
anyway, thanks.

[16:29:20.0000] <rniwa>
sicking: fwiw, https://bugs.webkit.org/show_bug.cgi?id=97372 is the relevant bug.

[16:52:10.0000] <sicking>
rniwa: so i'm still confused as to what you're actually doing?


2012-09-22
[18:25:45.0000] <Hixie>
sicking: might be interesting to just make mutation events intentionally slower, and then have advocacy to the effect of "mutation events are sloow, use this secret step the browser vendors don't want you to know to get fast mutation observers!"

[18:51:18.0000] <nessy>
Hixie: can I ask for some clarification on http://html5.org/tools/web-apps-tracker?from=7319&to=7320 ?

[18:52:59.0000] <nessy>
Hixie: did it close https://www.w3.org/Bugs/Public/show_bug.cgi?id=17680?

[18:53:20.0000] <nessy>
Hixie: or did it have to to with https://www.w3.org/Bugs/Public/show_bug.cgi?id=18784 ?

[19:03:56.0000] <nessy>
Hixie: I am asking because the commit message says it's preparation for closing those bugs, but then there are no further patches on those bugs

[01:40:05.0000] <jgraham>
nessy: I'm pretty sure that patch is expected to close https://www.w3.org/Bugs/Public/show_bug.cgi?id=17680 (it looks like it does enough to fix that issue at least)

[01:41:03.0000] <jgraham>
It would also be consistent with my reading of the commit message where the "preperation for" applies only to the first bug

[01:41:59.0000] <jgraham>
(I assume the problem here is that svn is <del>silly</del><ins>lacks something like git add -p</ins>)

[02:39:51.0000] <nessy>
jgraham, thanks that helps - I'm just surprised that 18784 is closed, too

[05:30:18.0000] <annevk>
tralalala

[05:32:14.0000] <Ms2ger>
trolololo?

[05:33:49.0000] <Ms2ger>
So I guess we're implementing https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html

[13:54:18.0000] <GPHemsley>
Hixie: If you put too many characters/bytes into your UTF-8 decoder (http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder), it acts as if you haven't entered any.


2012-09-23
[18:03:58.0000] <Hixie>
nessy: see bug 18789

[02:22:25.0000] <Ms2ger>
http://i.qkme.me/3r16wr.jpg

[02:50:44.0000] <annevk>
Ms2ger: you want to post that to @w3cmemes?


2012-09-24
[20:27:06.0000] <Hixie>
what's with all the bugs that the htmlwg is just marking invalid without even the boilerplate "how to reopen this bug" thing?

[20:27:11.0000] <Hixie>
anyone know anything about that?

[20:27:39.0000] <Hixie>
e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=18223 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16512 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16022

[20:57:20.0000] <cabanier>
that's an error on the editor's part.

[20:59:26.0000] <cabanier>
we've been told to always add the boilerplate

[21:09:29.0000] <Hixie>
k

[23:44:59.0000] <annevk>
I thought for obviously bogus bugs that was not required

[00:12:34.0000] <nessy>
I thought so, too - but I would have still added the boilerplate ;-)

[02:15:44.0000] <annevk>
I wish git and such had a thing similar to a "this is a minor edit" as seen on wikis

[02:17:31.0000] <jgraham>
git commit --fiuxup (revision)

[02:17:36.0000] <jgraham>
*--fixup

[02:18:04.0000] <jgraham>
typically git commit --fixup HEAD

[02:18:40.0000] <jgraham>
and then git rebase -i --autosquash rev_of_branch_base

[02:18:53.0000] <jgraham>
before you push to remove the fixups from the history entirely

[02:20:48.0000] <jgraham>
e.g. if you have the existing history A-B-C and you write new commits D-E-E1 so the history is A-B-C-D-E-E1, and E1 is a fixup of E (so you wrote git commit --fixup E to make that revision)

[02:21:13.0000] <jgraham>
You would git rebase -i --autosquash C

[02:21:33.0000] <jgraham>
Which would leave you with new history A-B-C-D-E'

[02:21:41.0000] <jgraham>
With E' = E + E1

[03:01:02.0000] <annevk>
karlcow: is splitting on ":" not simple enough?

[03:01:33.0000] <karlcow>
see the PS :)

[03:01:38.0000] <annevk>
heh

[03:02:20.0000] <annevk>
jgraham: I guess I should learn git

[03:02:55.0000] <annevk>
jgraham: I've been using github's tool for Mac, but it allows no such things

[03:14:37.0000] <annevk>
Is http://url.spec.whatwg.org/#goals clear enough?

[04:06:53.0000] <annevk>
have to hand it to Hixie, these new URLs are growing on me

[04:12:59.0000] <jgraham>
annevk: "Call them URLs" doesn't seem like a goal.

[04:13:15.0000] <jgraham>
That seems like something that you either do or you don't

[04:13:33.0000] <jgraham>
"standardize on the term URL" sounds more like a goal

[06:30:40.0000] <karlcow>
/me not replying to something which is about URL syntax only.

[07:03:07.0000] <adlwalrus>
Hixie: do you have any thoughts on http://coding.smashingmagazine.com/2011/11/11/our-pointless-pursuit-of-semantic-value/ ?

[08:44:49.0000] <Ms2ger>
krijn, seems like http://krijnhoetmer.nl/irc-logs/ isn't updating

[08:56:18.0000] <krijn>
That bastard!

[09:36:37.0000] <dglazkov>
good morning, Whatwg!

[09:39:57.0000] <espadrine>
dglazkov: good morning to you too! ☺

[11:34:23.0000] <Hixie>
annevk: none of those three were "obviously bogus", though

[12:31:01.0000] <Hixie>
any test suite people around? jgraham?

[12:31:09.0000] <Hixie>
not sure what to do about https://www.w3.org/Bugs/Public/show_bug.cgi?id=15042

[12:31:26.0000] <Hixie>
the W3C test suite is now intentionally actively testing something that is contrary to the good of the web and what browsers want to implement

[13:00:13.0000] <jgraham>
Hixie: bugger

[13:00:56.0000] <jgraham>
OK, I guess this is the point at which I propose doing something like branching the testsuite

[13:03:22.0000] <Hixie>
jgraham: where is it canonically hosted currently? github?

[13:08:47.0000] <jgraham>
dvcs.w3.org

[13:09:23.0000] <jgraham>
But this is Yet Another Reason to move to git, because branches in mercurial seem to be harder to use

[13:09:35.0000] <jgraham>
Or at least they have about three types of branch rather than one

[13:09:56.0000] <jgraham>
and the most useful of those three is a non-default extension

[13:10:37.0000] <Hixie>
you gonna need somewhere to host the fork? or?

[13:10:52.0000] <Hixie>
i can set up tests.whatwg.org or something if you want to manage it

[13:11:06.0000] <Hixie>
just say the word

[13:11:39.0000] <jgraham>
I think we are OK for now

[13:12:14.0000] <jgraham>
I am hopeful that we can end up with a single git repo with two branches rather than multiple repos

[13:12:26.0000] <Hixie>
jgraham: k

[13:12:35.0000] <Hixie>
jgraham: well, let me know what you want, if you need anything.

[13:12:37.0000] <Hixie>
off to lunch now

[13:12:42.0000] <jgraham>
Sure. Thanks

[14:07:07.0000] <chaotixx>
hi

[14:09:14.0000] <chaotixx>
is anyone here?  i am petty novice at web develoment, and could really use help with something....   on the page http://www.firestonecompleteautocare.com/maintenance/schedule.jsp  i am trying to copy the blue box contained on the page and its functions...  i am able to coy and recreate the box, but i dont know what i will need to do what it does

[15:19:24.0000] <SamB_MacG5>
well, it is certainly simple

[15:22:45.0000] <zewt_>
it should have been a lot simpler, heh

[15:26:43.0000] <SamB_MacG5>
/me supposes Python doesn't have any such facility for arrays either, come to think of it ...

[15:42:14.0000] <annevk_>
http://lists.w3.org/Archives/Public/uri/2012Sep/0002.html kind of an IETF-centric definition of obsolete there

[15:42:16.0000] <annevk_>
I was using it in the broad sense, in case anyone cares

[15:42:26.0000] <annevk_>
And is someone still subscribed to www-tag?

[15:42:49.0000] <annevk_>
It appears they are confused about where the URL Standard is located...

[15:44:48.0000] <SamB_MacG5>
zewt: on the other hand, if it was more complicated that might mean less bikeshedding ;-P

[15:48:01.0000] <zewt>
don't know that there's much bikeshedding on that api (though i havn't been following webgl-dev for a couple months)

[16:51:17.0000] <jamesr_>
Hixie_, so you've decided to let the UA pick a resolution however it likes for canvas 2d?

[16:51:31.0000] <TabAtkins>
That was the intent all along.

[16:51:47.0000] <jamesr_>
fwiw my thinking is that we'll always set this to 1 regardless of the display's properties. setting it to anything else is too problematic

[16:53:03.0000] <zewt>
jamesr: what problems are there that the addition of toDataURLHD and toBlobHD don't fix?

[16:53:04.0000] <jamesr_>
weird that it's tied to a task

[16:53:19.0000] <jamesr_>
and not the element (although all options here are weird)

[16:53:22.0000] <Hixie_>
jamesr_: webkit already picks higher res backing resolutions, at least for safari

[16:53:34.0000] <Hixie_>
jamesr_: are there any new problems that aren't handled?

[16:53:35.0000] <jamesr_>
safari on desktop does. chrome and mobilesafari don't

[16:55:31.0000] <Hixie_>
jamesr_: well not ever using higher res backing stores is a non-starter.

[16:55:44.0000] <Hixie_>
jamesr_: but if there are problems not currently addressed, please do mention them on the list

[16:55:48.0000] <jamesr_>
how do you mean?

[16:55:58.0000] <TabAtkins>
Hixie_: I'll be separately encouraging our implementation to name the function ellipseTo when we implement it.

[16:56:29.0000] <jamesr_>
Hixie_, we currently set the backing store to whatever the width/height attributes are set to. seems to work out fine

[16:56:39.0000] <Hixie_>
jamesr_: i mean, retina macbook pros look ugly as hell on chrome

[16:56:49.0000] <jamesr_>
depends on the content

[16:56:55.0000] <Hixie_>
when they have canvases

[16:57:35.0000] <Hixie_>
TabAtkins: i'll be encouraging us not to implement the more complicated path syntax too :-P

[16:58:35.0000] <Hixie_>
/me really does think it's a terrible design choice to be doing this


2012-09-25
[17:02:19.0000] <TabAtkins>
You don't seem to understand how much people hate A/a.

[17:02:33.0000] <TabAtkins>
They're *horrible* API for most use-cases.

[17:02:58.0000] <TabAtkins>
Anyway, your encouragement won't do much, since it's Dirk who'll be doing it for us. ^_^

[17:03:35.0000] <Hixie_>
i have no trouble understanding that A/a is bad

[17:03:43.0000] <Hixie_>
i have no trouble with the idea of adding new ways of doinh arcs

[17:03:54.0000] <Hixie_>
my problem is with this idea of adding new names for each command

[17:04:03.0000] <Hixie_>
or adding any names that aren't short one-letter names

[17:05:09.0000] <TabAtkins>
There are no reasonable letters left for new arc commands.

[17:06:23.0000] <TabAtkins>
I mean, the fact that a smooth quadratic uses T shows that we're out of reasonable letters already. ^_^

[17:06:38.0000] <Hixie_>
i don't understand the concern

[17:07:09.0000] <Hixie_>
why does it matter what the letters are?

[17:07:20.0000] <Hixie_>
you just find a mnemonic and go with it

[17:07:26.0000] <Hixie_>
e.g. E for ellipse

[17:07:35.0000] <TabAtkins>
?_?  You're asserting that we should continue with the practice of adding single-letter command names.  I'm claiming that there are no reasonable single-letter names for those commands.

[17:07:38.0000] <Hixie_>
or R for rounded corner

[17:07:51.0000] <Hixie_>
or O for circle

[17:08:03.0000] <Hixie_>
or V for curVe

[17:08:20.0000] <Hixie_>
you don't double the size of a language because of lack of imagination

[17:08:20.0000] <TabAtkins>
Separately, I assert that the single-letter names are stupid.  Syntax minimization at its worst.

[17:08:31.0000] <Hixie_>
that's fine, but that boat sailed years ago

[17:08:44.0000] <TabAtkins>
Yup, and it's returned, and we're changing the rigging on it now.

[17:08:51.0000] <Hixie_>
this is bad language design

[17:09:01.0000] <Hixie_>
if you're gonna start adding replacement features for everything SVG screwed up, you're gonna end up with the world's most confusing language

[17:09:10.0000] <Hixie_>
adding features doesn't simplify

[17:09:12.0000] <TabAtkins>
It's consistent with the names of the subpath *elements* we're adding.

[17:09:15.0000] <Hixie_>
it only makes things worse

[17:09:22.0000] <Hixie_>
oh god, you're adding elements too?

[17:09:24.0000] <TabAtkins>
I understand that you think that.  I agree some of the time.

[17:26:20.0000] <Hixie_>
TabAtkins: why is it not true here?

[17:38:40.0000] <jamesr_>
TabAtkins, y u n l c s?

[18:29:17.0000] <TabAtkins>
Hixie: Consistency is a virtue, but not an absolute one.  One must balance it against the benefits of whatever is breaking consistency.  Also, being consistent with the future and pushing the past to the side can mitigate a lot of the pain of inconsistency.

[18:29:42.0000] <TabAtkins>
Basically, it's just an error to reject something solely because it's inconsistent with the present.

[18:31:43.0000] <SamB_MacG5>
/me wonders why http://dev.w3.org/html5/spec/the-canvas-element.html#the-canvas-element suggests XBL as somehow being something you could use ...

[18:31:55.0000] <TabAtkins>
It was written a while ago.

[18:32:25.0000] <Hixie>
TabAtkins: i'm not talking about being consistent, though, i'm talking about adding redundant features

[18:32:52.0000] <TabAtkins>
Redundancy is fine!  Redundancy can be author-friendly.

[18:34:03.0000] <Hixie>
if you're starting from that assumption, i think it's unlikely we'll agree :-)

[18:34:24.0000] <TabAtkins>
I think it is obviously untrue that redundancy is an absolute bad.

[18:35:10.0000] <TabAtkins>
And when there is a choice between redundancy and inconsistency, redundancy should probably win.

[18:36:22.0000] <Hixie>
i think following that line of reasoning would easily double the API surface of the web

[18:36:27.0000] <Hixie>
which imho is _clearly_ a negative

[18:36:47.0000] <TabAtkins>
It would only double if you're adding redundant version of everything.

[18:37:18.0000] <TabAtkins>
Increasing the surface area of the web by 20% or so, in return for making shitty legacy things more consistent with the more glorious future, is a cost I'm willing to pay.

[18:38:06.0000] <Hixie>
but it doesn't make the old features more consistent with the future -- it makes a new feature consistent with the feature, while also keeping the old inconsistent features

[18:38:32.0000] <Hixie>
(and given how we don't know what the future is, it's unclear that one can be consistent with it)

[18:38:42.0000] <TabAtkins>
Yes?  We can't get rid of the old features, and twisting the future to be consistent with them just produces something horrible.

[18:41:15.0000] <Hixie>
having old+newold+new is worse than old+new (where newold = the new redundant feature)

[18:41:42.0000] <Hixie>
because basically the more you have, the more complicated it is, the harder it is to teach, to write tutorials, to test, to spec, to implement, to learn, etc

[18:42:24.0000] <Hixie>
it's arguable whether a new feature that isn't consistent with a bad old feature is better or worse than being consistent, given the cost of inconsistency, but that's a case-by-case thing

[20:25:43.0000] <Hixie>
othermaciej: htmlwg question -- if i notice an htmlwg bug that might be valid has been marked invalid without any comment (no boilerplate, rationale, etc), is this something anyone cares about that i should raise somewhere? i don't personally care but if i notice it and there's something trivial i can do to help, i'm happy to do so

[20:29:05.0000] <othermaciej>
Hixie: if you point such bugs out to an editor and/or a chair, it would be helpful

[20:29:46.0000] <Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18223 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16512 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=16022

[20:30:07.0000] <Hixie>
(fyi, see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=15042 )

[20:30:10.0000] <Hixie>
othermaciej: ^

[20:30:53.0000] <othermaciej>
I don't understand how to interpret "how do you set up the tracks in the html?" as spec feedback

[20:31:06.0000] <othermaciej>
if you understand what it means, I would appreciate if you could add a clarifying comment

[20:31:10.0000] <Hixie>
i presume it's asking for examples of <track>

[20:31:28.0000] <othermaciej>
likewise "I first saw this code suggested by Jeremy Keith in his excellent book ‘HTML5

[20:31:29.0000] <othermaciej>
For Web Designers’ ("

[20:31:50.0000] <othermaciej>
is it? it might be asking for an example, or the person might be confused, or they might think there is a bug with <track>

[20:32:19.0000] <Hixie>
well like i said, "might be"

[20:32:24.0000] <Hixie>
not saying they are :-)

[20:32:30.0000] <othermaciej>
what about the one citing Jeremy Keith?

[20:32:35.0000] <Hixie>
yeah that one is less clear

[20:32:42.0000] <othermaciej>
what does that mean?

[20:32:58.0000] <Hixie>
dunno. probably cut off. seemed likely to be an intentional question, though, not just invalid

[20:33:00.0000] <othermaciej>
seems invalid to me, or needs info at best

[20:33:12.0000] <Hixie>
oh definitely isn't directly actionable

[20:33:39.0000] <othermaciej>
I personally feel that one is of the same status as "asdfgh asdfgh"

[20:33:48.0000] <Hixie>
k

[20:34:01.0000] <othermaciej>
in that it does not even suggest either a problem with the spec or a proposed change

[20:34:20.0000] <othermaciej>
for 16022, I also am not really sure what it means

[20:34:25.0000] <othermaciej>
do you understand what it is saying?

[20:34:40.0000] <Hixie>
haven't studied it closely enough

[20:35:10.0000] <Hixie>
but if someone filed it and is watching the bug, it seems polite to ask for more info rather than just closing it without following the process :-)

[20:35:19.0000] <othermaciej>
I find myself unable to parse it

[20:35:27.0000] <Hixie>
given that the bug system is the w3c's main feedback mechanism

[20:35:43.0000] <Hixie>
it's like with the whatwg list, i promise replies to all feedback on the spec, even nonsensical feedback

[20:36:13.0000] <othermaciej>
the HTML WG policy is that INVALID may be applied if "Bug is obvious junk or spam. Or, originator decides upon reconsideration that the comment is wrong. Does not require a full Editor's response."

[20:36:29.0000] <othermaciej>
NEEDSINFO is "Additional information is required to accept or reject this comment. Editor's response required. Editor should be clear on what additional info is required. It is strongly recommended that bug reporters should provide the requested additional information, if the request is reasonable, before they consider escalating."

[20:36:36.0000] <othermaciej>
I would consider either acceptable for those three bugs

[20:36:50.0000] <Hixie>
i guess my definition of "junk" is less wide than yours :-)

[20:36:55.0000] <othermaciej>
as the required info would be "please clearly state a problem with the spec or identify a suggested change"

[20:37:08.0000] <Hixie>
(as editor i basically didn't mark any invalid, iirc)

[20:37:18.0000] <Hixie>
(so i was a bit surprised to see it being used)

[20:38:50.0000] <othermaciej>
I don't think your recollection is correct

[20:39:05.0000] <othermaciej>
I found 183 bugs in the "HTML5 spec" component that were marked INVALID while you were editor

[20:39:16.0000] <Hixie>
any of them marked that way by me?

[20:39:21.0000] <Hixie>
without boilerplate?

[20:40:31.0000] <othermaciej>
that's harder to do a quick query for

[20:41:01.0000] <othermaciej>
I see many marked as such by the editorial assistants or by Msg2er

[20:41:06.0000] <othermaciej>
in random sampling

[20:41:21.0000] <Hixie>
(search within that set for bugs closed by me, then search again for bugs closed by me with the boilerplate, and subtract the counts, that should do it. not that you need to bother :-) )

[20:41:53.0000] <othermaciej>
I can't readily search for bugs closed without the boilerplate

[20:42:06.0000] <Hixie>
right, search for them all, then with it

[20:42:09.0000] <Hixie>
the difference is those without

[20:42:49.0000] <Hixie>
(if you wanted the actual bugs, you could grab the IDs from the second set and list them as IDs to exclude in the first search, or something)

[20:42:53.0000] <Hixie>
(but that's getting messy)

[20:43:00.0000] <othermaciej>
point being, it has been accepted process that bugs which do not appear to state an issue and instead appear to be a copy/paste error, random typing, a non-bug question, or the like can be resolved w/o boilerplate

[20:43:00.0000] <Hixie>
anyway, it's no big deal

[20:43:08.0000] <Hixie>
k

[20:43:13.0000] <othermaciej>
I'm willing to believe you never personally used INVALID since I can't find any counter-examples

[20:43:49.0000] <Hixie>
the fourth one was a separate thing, just fyi. https://www.w3.org/Bugs/Public/show_bug.cgi?id=15042

[20:44:00.0000] <Hixie>
hopefully it'll solve itself.

[20:44:21.0000] <othermaciej>
it does seem to me the test suite bug you cited was probably wrongly closed, but the spec bug rules don't apply there and I have not followed test suite development, so I am not in a good position to comment further

[20:44:40.0000] <Hixie>
yeah i wasn't saying that one was part of the same issue.

[20:44:49.0000] <Hixie>
just making sure you had it on your radar.

[20:44:59.0000] <Hixie>
more in your role as webkit guy than htmlwg guy.

[20:45:39.0000] <othermaciej>
ok

[20:46:04.0000] <othermaciej>
it does seem necessary to figure out the answer to what toDataURL does for hi-res backing stores

[20:46:15.0000] <Hixie>
the whatwg spec is clear on that topic

[20:46:15.0000] <othermaciej>
perhaps it needs the "HD" treatment like getImageData and putImageData

[20:46:23.0000] <Hixie>
it has had that treatment in the whatwg spec.

[20:46:29.0000] <othermaciej>
ah, ok

[20:46:30.0000] <Hixie>
this is one of the areas where tho two specs have forked.

[20:46:40.0000] <othermaciej>
I believe our canvas implementors are tracking the whatwg spec more than the htmlwg spec on this

[20:46:51.0000] <Hixie>
yeah, i expect everyone but microsoft is in that boat.

[20:46:56.0000] <othermaciej>
it would be nice if the w3c version was at least not contrary to the high-res-compatible edition

[20:46:58.0000] <Hixie>
(sadly it was microsoft people who wontfixed the bug)

[20:47:03.0000] <Hixie>
agreed

[20:47:56.0000] <othermaciej>
is the canvas toBlob method a fork point?

[20:48:06.0000] <Hixie>
dunno

[20:48:08.0000] <othermaciej>
(wondering if toBlobHD or toBlob is the fork, to determine if this same issue applies)

[20:48:21.0000] <Hixie>
i'm guessing it's all the HD stuff

[20:48:25.0000] <Hixie>
i think we had toBlob long ago

[20:48:38.0000] <Hixie>
i definitely didn't add toBlob at the same time as the HD stuff

[20:48:44.0000] <Hixie>
the HD stuff is relatively new

[20:48:51.0000] <Hixie>
(in response to safari feedback, mainly)

[20:49:03.0000] <othermaciej>
yes, I'm aware, and I'm glad it was added

[20:49:14.0000] <othermaciej>
as you can see, all of Apple's product line is moving to 2x displays

[20:49:33.0000] <othermaciej>
so we got to be the first ones to test how the old spec worked in the face of 1x-only-tested content

[20:49:43.0000] <Hixie>
yeah

[20:49:49.0000] <Hixie>
(love the retina macbook btw)

[20:50:14.0000] <othermaciej>
I wish I had one, trying to order them for my engineers first though

[20:52:04.0000] <Hixie>
yeah, i don't have one personally, but i got one for my partner

[21:01:36.0000] <Hixie>
in other news, man, w3c bugzilla is being slow today

[21:01:40.0000] <Hixie>
keep getting 502s

[21:02:05.0000] <othermaciej>
me too :-(

[21:40:57.0000] <SamB_MacG5>
/me is surprised to discover that he is in the XSL or XQuery working group

[21:41:07.0000] <SamB_MacG5>
(well, that's what bugzilla thinks, anyway!)

[21:51:29.0000] <othermaciej>
Hixie: why did you move this bug to the whatwg product? https://www.w3.org/Bugs/Public/show_bug.cgi?id=10912

[21:51:36.0000] <othermaciej>
Hixie: are you going to back-clone it?

[21:52:01.0000] <othermaciej>
(HTML WG needs copies of resolved bugs in our product to be able to provide a record of responses to comments)

[22:02:42.0000] <nessy>
it's happening to many bugs - looks like all of the ones that were resolved later...

[22:05:24.0000] <kennyluck>
Can we have a QA contact (a mailing list) for all bugs in the WHATWG component? I'd like to subscribe to that list.

[22:46:16.0000] <Hixie>
othermaciej: oh, didn't realise you wanted the closed ones also. i moved all the bugs assigned to me that were marked LATER to the WHATWG component.

[22:46:23.0000] <Hixie>
othermaciej: so i wouln't lose them.

[22:48:57.0000] <Hixie>
othermaciej: there have been many bugs that get reassigned to other components, e.g. HTML.next, rather than get resolved, fwiw. so i don't know that it's possible to make such a list currently.

[22:49:08.0000] <Hixie>
kennyluck: contributor⊙wo should be that, iirc

[22:49:36.0000] <Hixie>
kennyluck: just follow that

[22:49:41.0000] <othermaciej>
Hixie: can you clone them in one direction or another please?

[22:49:54.0000] <Hixie>
othermaciej: yeah, send me a mail to remind me

[22:50:10.0000] <kennyluck>
Hixie, how to? Is that a mailing list?

[22:50:11.0000] <Hixie>
should be easy enough to set up my script to do that

[22:50:27.0000] <Hixie>
kennyluck: in bugzilla, you should be able to set your account to follow that one

[22:50:29.0000] <kennyluck>
oh, you mean Bugzilla following?

[22:50:37.0000] <Hixie>
https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email

[22:50:39.0000] <Hixie>
yeah

[22:50:50.0000] <Hixie>
gotta go, bbl

[00:17:15.0000] <jgraham>
othermaciej: BTW your more minimal filesystem API looks nicer than the Google one, but it does seem like one would quickly end up with a "pyramid of doom" if every single file operation needs to be in its own callback

[00:50:19.0000] <jgraham>
othermaciej: In addition I am worried that we have added, or attempted to add, 3 local storage mechanisms in the last 5 years, and our record of doing it well isn't that great

[00:50:44.0000] <jgraham>
(localStorage, WebSQL, IndexedDB)

[00:52:52.0000] <jgraham>
(so the platform total, including WebSQL, is 4 of which 3 are already known to be various degrees of broken)

[00:54:37.0000] <SimonSapin>
jgraham: which is the not-known-broken one?

[00:57:09.0000] <jgraham>
IndexedDB

[00:57:37.0000] <Ms2ger>
That one's just hated, right?

[00:57:38.0000] <jgraham>
By no one uses that yet

[00:57:50.0000] <jgraham>
So we probably haven't worked out why it is broken yet

[00:58:30.0000] <jgraham>
Hence I am worried about adding a new storage API before we even work out what the problems that need to be fixed with the previous one are

[00:59:14.0000] <jgraham>
(I suspect "callback hell" is one of the problems, and I don't think the filesystem API proposals address that)

[01:55:00.0000] <eighty4>
Any ideas on http://www.netmagazine.com/features/truth-about-structuring-html5-page ?

[02:00:08.0000] <zcorpan>
TabAtkins: maybe you should ask what the svg wg think about multiple-letter commands before discussing it in whatwg :-)

[02:14:45.0000] <annevk_>
eighty4: hard to argue with the truth

[02:15:08.0000] <eighty4>
annevk_: i.e. we shouldn't use the new html5 elements?

[02:16:10.0000] <annevk_>
/me was mocking the title

[02:16:11.0000] <hsivonen>
the outline algorithm is ill-clothed as long as there’s no selector for selecting by outline depth

[02:16:21.0000] <eighty4>
...

[02:16:34.0000] <eighty4>
/me is to stupid to get jokes just before lunch

[02:17:15.0000] <annevk>
eighty4: I stopped caring about semantics a while ago, so these days whenever people ask me I just tell them to use what works best for them

[02:17:40.0000] <annevk>
eighty4: I personally use <nav> and such as it's nicer than <div id=nav>, if some people prefer the latter, that's cool too

[02:17:50.0000] <eighty4>
annevk: I've been finding <header> and such in the same way

[02:18:02.0000] <eighty4>
makes my html cleaner and easier to maintain imo

[02:18:09.0000] <hsivonen>
Re: semantics: https://twitter.com/glazou/status/250516174473920512

[02:20:26.0000] <annevk>
eighty4: exactly, and in a decade from now or so someone will do a new study towards what people are doing and how markup is practiced and the definitions in the specification will be adjusted accordingly

[02:20:46.0000] <eighty4>
ah well. Back to figuring out how to move things around in this comment form I guess. Seems more important.

[02:20:52.0000] <annevk>
eighty4: just like the HTML4 element definitions have been adjusted (e.g. for <dl>)

[02:21:30.0000] <jgraham>
eighty4: I read a little bit of that article and found it was wrong on matters of fact, so I gave up and stopped reading

[02:22:04.0000] <jgraham>
If the facts taht you are using to support your opinion are fabrications, there's probably very little value in your opinions

[02:22:04.0000] <annevk>
hsivonen: that's "asshole" per pilgrim classification, no?

[02:22:13.0000] <eighty4>
jgraham: if anything you should point that out. Seems a shame if people read it and believe it :)

[02:22:44.0000] <annevk>
if people believe stuff they read online they might be in for some surprises down the road :)

[02:23:23.0000] <jgraham>
eighty4: If I pointed it out every time some clueless or malicious web developer used incorrect assertions to write controversial articles in the name of publicity I wouldn't have any time to do anything else

[02:23:37.0000] <eighty4>
annevk: lol

[02:24:05.0000] <hsivonen>
but see http://epubsecrets.com/ibooks-the-latest-epub-3-0-reader.php

[02:24:06.0000] <eighty4>
jgraham: meh!

[02:24:13.0000] <annevk>
eighty4: also, it's important to conserve one's energy http://xkcd.com/386/

[02:24:26.0000] <eighty4>
jgraham: (swedish for me not having a response but thinking you should do it anyways)

[02:24:53.0000] <eighty4>
annevk: I love that one. I live by it :)

[02:25:07.0000] <annevk>
I like to think I learned from it :p

[02:25:18.0000] <eighty4>
I never learn

[02:27:12.0000] <eighty4>
ah well, when I have the time I'll read som of the responses to the post. Should be fun

[02:30:01.0000] <annevk>
eighty4: you'll learn, might take a long time, mind you; I think I've done it for over half a decade at least with regards to standards discussions

[02:30:55.0000] <annevk>
and actually, I still do: http://krijnhoetmer.nl/irc-logs/whatwg/20120925#l-101 I just no longer bother sending email :)

[02:32:01.0000] <eighty4>
annevk: In truth I do get better. I've stopped arguing with trolls :)

[02:33:02.0000] <eighty4>
annevk: that log is from a couple of hours back :D

[03:34:56.0000] <jgraham>
hsivonen: Do you really want to encourage the W3C to have big monolithic releases where all known issues have to be fixed?

[03:40:01.0000] <hsivonen>
jgraham: no. they can drop stuff from snapshots instead of fixing: http://w3cmemes.tumblr.com/post/31865121758/the-joker-shares-his-approach-on-css2-1-issues

[03:40:56.0000] <hsivonen>
jgraham: I don't want Microsoft to create a new doc mode that implements stuff that others won't be able to implement across modes

[03:41:24.0000] <hsivonen>
jgraham: and I don't want to deflect n00b requests to implement the bogus REC in Gecko

[03:42:40.0000] <jgraham>
I don't want the navigation algorithm to be replaced by "now do magic stuff" just for fear that Microsoft might otherwise add in a mode that implements it

[03:42:55.0000] <jgraham>
In fact I don't think that's practically possible

[03:43:45.0000] <hsivonen>
jgraham: the W3C REC could say “do magic” and WHATWG and W3C ED’s could try to say something more precise

[03:44:25.0000] <eighty4>
annevk: ok, I know I shouldn't care but the authors html is kind of horrible :)

[03:44:26.0000] <jgraham>
In this specific case I don't see how that would work without undefining a bunch of stuff

[03:44:33.0000] <eighty4>
www.truthabouthtml5.com really isn't nice html

[03:44:42.0000] <annevk>
noobs caring about the navigation algorithm? not sure that would ever happen

[03:44:59.0000] <jgraham>
I mean, navigation spreads its tentacles all over the spec

[03:46:00.0000] <hsivonen>
eighty4: oh was the article trolling for attention in order to sell a book? ok.

[03:46:25.0000] <eighty4>
hsivonen: I would imagine so, given that the article seems taken from the book.

[03:46:54.0000] <jgraham>
hsivonen: I would much prefer that the W3C moved to a model where we got releases say every 6 months, and there was an understanding that the spec might not be bug-free

[03:47:43.0000] <jgraham>
Seems like the closest thing to a living standard that could be fig-leafed as process

[05:20:32.0000] <zcorpan>
i've moved this to a separate file so other specs can use it: http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/status-warning.js

[05:21:24.0000] <zcorpan>
(see http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.src.html for how it looks)

[07:03:40.0000] <annevk>
who the fuck cares about .mobi anyway?

[07:04:04.0000] <darobin>
.mobi is still around?

[07:04:58.0000] <annevk>
it was awkward when I ran into some people from Vodaphone couple of years after I published http://annevankesteren.nl/2004/12/mobi-stld and they recalled what I wrote

[07:06:03.0000] <darobin>
I reckon they're used to that :)

[07:10:42.0000] <hsivonen>
what’s the spec for window.screen?

[07:13:10.0000] <smaug____>
paul_irish: looks like robohornet does something odd with testharness, which causes tests to test something else than what is actually expected. https://github.com/robohornet/robohornet/issues/66

[07:13:58.0000] <hsivonen>
I miss zcorpan’s .mobi site that served a single-pixel GIF

[07:14:16.0000] <zcorpan>
hsivonen: i let the domain expire

[07:17:52.0000] <annevk>
Ms2ger: was just looking into merging that fix from hasather

[07:18:13.0000] <Ms2ger>
Too late ;)

[07:18:16.0000] <annevk>
guess we can now declare hosting specs on github a "great success"

[07:18:41.0000] <odinho>
and everyone had cake and was happy :-)

[07:18:43.0000] <Ms2ger>
Did someone change the case of whatwg again?

[07:19:46.0000] <Ms2ger>
/me mumbles about unnecessary merges

[07:20:15.0000] <annevk>
Ms2ger: my bad

[07:20:29.0000] <Ms2ger>
Hmm? No, github's bad :)

[07:20:38.0000] <annevk>
Ms2ger: well I renamed back to /whatwg

[07:20:42.0000] <Ms2ger>
Oh

[07:20:58.0000] <Ms2ger>
Keep it that way now? :)

[07:21:06.0000] <annevk>
but quite a while ago

[07:21:07.0000] <annevk>
yes

[07:22:03.0000] <zewt>
heh i read .mobi as the kindle ebook format

[07:23:11.0000] <annevk>
hsivonen: window.screen is in CSSOM View (at least when I worked on that)

[07:29:05.0000] <zewt>
google's search result stats must get pretty nastily broken for ED/TR results

[07:29:40.0000] <zewt>
-ED

[07:31:00.0000] <zewt>
since invariably the TR gets returned and i can't quickly find the ED in the results, so i click the TR result then click through to the ED--presumably making google thing the TR is what I wanted, making it even more likely to be at the top

[07:47:11.0000] <annevk>
whoa, Opera and Chrome accept http://017700000001/

[07:48:06.0000] <annevk>
http://www.amazon.com/The-Tangled-Web-Securing-Applications/dp/1593273886 is pretty interesting

[07:48:31.0000] <zewt>
octal, one of those things which are utterly useless yet somehow refuse to die

[07:49:09.0000] <zewt>
heh https://twitter.com/ID_AA_Carmack/status/243125862403297281

[07:51:22.0000] <othermaciej>
jgraham: doesn't the Google one also require a callback for each operation?

[07:51:38.0000] <othermaciej>
jgraham: (other than when using the sync API in a Worker)

[08:10:32.0000] <annevk>
zewt: the problem is more that IPv4 is only allowed to be written as DEC.DEC.DEC.DEC

[08:32:05.0000] <zewt>
annevk: when parsing a URL whose base URL is null, what does eg. "set scheme to base's scheme" mean? SIGSEGV? (i might be missing a default-base-url rule somewhere)

[08:32:32.0000] <annevk>
zewt: how did you get there?

[08:33:08.0000] <zewt>
new URL("http://foo.com");

[08:33:33.0000] <annevk>
you would not get there

[08:33:59.0000] <annevk>
you can never get in the "hierarchical" state if base URL is null

[08:36:01.0000] <annevk>
maybe I'll rename "hierarchical" to "relative"

[08:36:07.0000] <zewt>
new URL("?a=1"): 1: scheme start, step 1 does nothing, step 2 goes to no scheme; 2: no scheme goes to hierarchical

[08:36:18.0000] <zewt>
(the case I was actually tracing)

[08:37:11.0000] <annevk>
ah

[08:37:39.0000] <annevk>
small bug, thanks

[08:37:51.0000] <zewt>
(i guessed doing that would actually want to end up invalidated, but was trying to see if that's what actually happens)

[08:40:55.0000] <annevk>
fixed

[08:42:29.0000] <dglazkov>
good morning, Whatwg!

[08:43:26.0000] <zewt>
should the URL ctor throw on invalid URLs, since it does that for base anyway? seems confusing that eg. changing .path and querying .href silently gives the original URL if it was invalid

[08:44:21.0000] <annevk>
zewt: maybe, but a) that does not happen for <a> and such and b) it might make introducing new schemes that need parser integration trickier

[08:44:40.0000] <annevk>
zewt: you can check the new isInvalid flag

[08:44:46.0000] <annevk>
maybe that should be named isValid

[08:46:07.0000] <zewt>
seems confusing that changes are silently discarded in that state, though

[08:48:24.0000] <annevk>
you can still set .href

[08:48:43.0000] <zewt>
but nothing else

[08:49:00.0000] <annevk>
well doh, if the input is invalid it would be kinda hard to change anything

[08:49:49.0000] <annevk>
and it's largely an edge case anyway and it that case better extensibility wins

[08:49:57.0000] <annevk>
in*

[08:52:15.0000] <jgraham>
othermaciej: Yes, but their proposal sucks even more, so that's not a great argument

[08:53:00.0000] <othermaciej>
jgraham: I don't know of a reasonable way to avoid callback-per-operation while still avoiding synchronous I/O on the main thread

[08:53:18.0000] <zewt>
it just seems like a confusingly silent error condition, where the interface is still there, no errors are raised, but it doesn't do anything useful and the reason for why it's no-opping isn't necessarily obvious

[08:53:23.0000] <othermaciej>
jgraham: that being said, I am not really sure why any local sandboxed storage use cases would need this but couldn't use indexeddb

[08:53:34.0000] <jgraham>
othermaciej: I think we should perhaps spend some time trying to work out a pattern for that

[08:53:41.0000] <othermaciej>
jgraham: so I think maybe the right next step is to get very clear about the use cases

[08:53:52.0000] <jgraham>
Before adding yet more APIs that die under callback hell

[08:54:06.0000] <jgraham>
But yeah, I agree about IndexedDB and use cases

[08:54:15.0000] <annevk>
zewt: not too worried with error consoles and whatnot

[08:54:28.0000] <rwaldron>
annevk was just looking at the mutation methods—great stuff. One question though: Can these be specified to return the node they operate on?

[08:54:31.0000] <rwaldron>
http://dom.spec.whatwg.org/#mutation-methods

[08:54:52.0000] <zewt>
othermaciej: fwiw, i expect a portion of it is that everyone implicitly understands and "trusts" filesystem access as a basic storage mechanism for file-like data, where indexeddb is less known and proven in people's minds

[08:55:17.0000] <annevk>
rwaldron: I haven't done that because that would be inconsistent with every other platform API there is

[08:55:31.0000] <rwaldron>
I see

[08:55:39.0000] <rwaldron>
well, that's unfortunate.

[08:55:46.0000] <Ms2ger>
This ain't jquery

[08:56:28.0000] <othermaciej>
zewt: yeah, but - Chrome's sandboxed filesystem store is (I believe) in reality backed by a database

[08:56:42.0000] <othermaciej>
zewt: so the trust level is completely illusory

[08:56:52.0000] <zewt>
othermaciej: yeah that's pretty bad, defeats the benefits entirely

[08:56:55.0000] <annevk>
rwaldron: so yes, we can do whatever we want, but taking the rest of the platform into consideration is important

[08:57:11.0000] <annevk>
rwaldron: it's already inconsequential enough imo

[08:58:08.0000] <rwaldron>
Ms2ger what do you gain from saying that? Or better, what does the future of the platform gain?

[08:58:14.0000] <zewt>
(databases don't tend to be terribly good at file-like stuff, eg. storing a 500 MB file and then modifying a few bytes in the middle, appending data without compounding fragmentation, etc)

[08:58:37.0000] <Ms2ger>
rwaldron, the ability to have functions return something more useful than the this value

[08:58:50.0000] <rwaldron>
annevk I understand, but since these effectively supplant the previous API, it doesn't seem unreasonable.

[08:59:06.0000] <rwaldron>
Ms2ger such as?

[08:59:08.0000] <annevk>
rwaldron: by the platform I mean more than just DOM manipulation :)

[08:59:22.0000] <annevk>
I mean every API in every standard

[09:00:21.0000] <rwaldron>
annevk yes, the same ones that are abstracted over, because they are mostly miserable.

[09:00:29.0000] <Ms2ger>
/me yawns

[09:00:30.0000] <rwaldron>
Ok, well I can see that arguing this is pointless, so thanks for your time everyone.

[09:01:34.0000] <Ms2ger>
/me implements remove() instead

[09:01:47.0000] <Ms2ger>
I guess I get to write tests now

[09:02:10.0000] <annevk>
rwaldron: I'd prefer a more complete plan than just changing some APIs here and there into chaining APIs

[09:02:36.0000] <annevk>
rwaldron: it feels a bit irresponsible to just do it here and there

[09:02:50.0000] <annevk>
rwaldron: I'm not opposed to the idea though

[09:03:12.0000] <rwaldron>
Ms2ger seriously? I'm reaching out to spec authors, as a member of TC39 (representing jQuery), to coordinate efforts that will improve the use of APIs that will be used to create the future

[09:03:22.0000] <rwaldron>
I don't appreciate your dismissive comments

[09:03:39.0000] <rwaldron>
Considering I said nothing to you to deserve them

[09:04:18.0000] <Ms2ger>
This is an issue that would be better solved in JS proper

[09:04:36.0000] <Ms2ger>
If you're in tc39, you're better placed than me to do that

[09:04:42.0000] <rwaldron>
Ms2ger and what issue is that?

[09:04:53.0000] <Ms2ger>
You mean there is no issue?

[09:05:03.0000] <Ms2ger>
Then why do you want to change a few methods in DOM?

[09:05:14.0000] <rwaldron>
I'm asking you to clarify what issue you're referring to

[09:05:23.0000] <rwaldron>
"This is an issue that would be better solved in JS proper"

[09:05:40.0000] <Ms2ger>
Clearly you believe there is an issue with the mutation methods

[09:06:02.0000] <rwaldron>
I believe there is an issue with the way much of the DOM has been specified

[09:06:14.0000] <Ms2ger>
I never really understood which issue it is that returning the this value is supposed to solve

[09:06:30.0000] <rwaldron>
It's not a problem with the language, it's a problem with the authors of the specifications.

[09:06:42.0000] <Ms2ger>
But it is pointless to try to fix it by changing a few methods here and there

[09:07:49.0000] <paul_irish>
as pointless as adding a duplicate remove() method purely for improved usability?

[09:08:02.0000] <rwaldron>
If these methods represent a newly created API, why not specify them in a way that will match the expectations of web developers that are currently using libraries to abstract over the existing APIs

[09:08:23.0000] <rwaldron>
let me rephrase that...

[09:08:28.0000] <rwaldron>
"Give them what they want"

[09:08:53.0000] <Ms2ger>
paul_irish, I'm not sure what parallel you're trying to draw?

[09:08:54.0000] <zewt>
because adding a return value that has minor benefit just because you're not currently using the return value means you can never, ever in the future use the return value to represent something very useful

[09:09:06.0000] <rwaldron>
You're implementing methods that "almost" match the API of several DOM libraries

[09:09:27.0000] <rwaldron>
except that you've left out a significant part and that will just cause more confusion.

[09:10:13.0000] <Ms2ger>
"Do what jquery does" is not an argument

[09:10:35.0000] <ls_n>
not just jQuery

[09:10:37.0000] <danheberden>
Wow, that was a quick mis-characterization of what rwaldron said

[09:10:38.0000] <annevk>
rwaldron: can't blame Ms2ger and I for the DOM... that was done way back; we just fixed a bunch of holes

[09:10:52.0000] <annevk>
anyway, gotta go

[09:11:26.0000] <rwaldron>
Ms2ger that's amusing.

[09:11:34.0000] <paul_irish>
i'm saying these new methods are introduced for the purpose of improving the usability of the DOM.  I can guarantee you that developers would find a useful return value more intuitive

[09:11:38.0000] <Ms2ger>
You're clearly just trolling

[09:11:44.0000] <rwaldron>
paul_irish +1

[09:11:46.0000] <zewt>
(rwaldron: being rude is not going to convince anyone of much of anything)

[09:11:53.0000] <rwaldron>
Ms2ger I am absolutely not trolling

[09:12:33.0000] <rwaldron>
And I don't appreciate the name "name-calling"

[09:12:33.0000] <danheberden>
zewt, as someone mostly reading this conversation and not participating, I would hardly call rwaldron the rude one here

[09:12:51.0000] <rwaldron>
so far you've resorted to being unfairly dismissive and now to name calling.

[09:13:04.0000] <rwaldron>
I spoke up because I want a better DOM API

[09:13:20.0000] <rwaldron>
That's not trolling.

[09:13:25.0000] <ls_n>
From my review of the spec, I found it odd that the method names and intent seemed to be following popular library implementations, but without including a return value.

[09:13:30.0000] <zewt>
the addBefore/addAfter tend not to actually need chaining, since their pattern is e.addAfter(a, b, c); you don't need to say e.addAfter(a).addAfter(b).addAfter(c)

[09:13:47.0000] <rwaldron>
ls_n agreed, which is why I came to discuss

[09:14:23.0000] <ls_n>
If the spec had included a return value other than the calling node, I would have called that into question because there is precedence, but I could have been convinced.

[09:15:10.0000] <SamB_MacG5>
/me thinks it would be handy if the multi-page specs had auto-redirect pages, like epydoc makes: http://epydoc.sourceforge.net/faq.html#redirect

[09:15:31.0000] <rwaldron>
and all I've gotten in response is "yawn", some snide comments about jQuery and some misguided argument about fixing the issue in JS (ie. the language).

[09:15:40.0000] <ls_n>
Without a return value, it seems very confusing.  Almost purposeful.  Why not preserve least surprise, and follow precedence?

[09:16:23.0000] <Ms2ger>
Is there any reason it is "confusing" except for "it doesn't match jquery"?

[09:16:23.0000] <rwaldron>
ls_n before annevk left, he told me that having a return value doesn't match the rest of the platform

[09:16:48.0000] <ls_n>
Ms2ger: fwiw, YUI also includes these methods, and also returns the calling node.

[09:17:18.0000] <Ms2ger>
Let's take "jquery" as a shorthand for "jquery and other frameworks that look the same"

[09:17:23.0000] <Ms2ger>
if that makes you happy

[09:17:31.0000] <SamB_MacG5>
Ms2ger: if you take the name, well ...

[09:17:32.0000] <ls_n>
rwaldron: interesting.  I wonder what the definition of "platform" is in that context.  I'm thinking appendChild() has a return value.

[09:18:19.0000] <Ms2ger>
ls_n, appendChild() returns the argument, not the this value

[09:18:43.0000] <ls_n>
Ms2ger: I'm aware :) My point is that it returns something.

[09:18:47.0000] <Ms2ger>
Hah

[09:19:01.0000] <SamB_MacG5>
that doesn't sound like much of an argument

[09:19:06.0000] <Ms2ger>
Nobody claimed that returning something useful didn't match the rest of the patform

[09:19:07.0000] <zewt>
annevk obviously didn't say that DOM functions should never return anything at all, heh

[09:19:09.0000] <Ms2ger>
platform*

[09:19:19.0000] <danheberden>
Ms2ger: from a completely "read the statement" - you start with something, you do something to it, why did the thing go away?

[09:19:30.0000] <danheberden>
sorry, completely "read the statement" argument

[09:19:31.0000] <zewt>
(parse error, redo from start)

[09:19:44.0000] <Ms2ger>
So

[09:19:46.0000] <danheberden>
like - i think that while jQuery executed successfully, there is a natural tendency to expect that

[09:19:54.0000] <rwaldron>
Ms2ger as does Prototype (however, its use has significanlty diminished) and Dojo (which is widely used in the enterprise)

[09:20:12.0000] <Ms2ger>
Does anybody want to reply to my actual point instead of complaining about my use of "jquery"?

[09:21:01.0000] <danheberden>
Ms2ger: but youre combatting points with "because jQuery does it means nothing"

[09:21:02.0000] <jwalden>
/me suspects this scrollback would be marginally interesting to read, fires up logs

[09:21:08.0000] <SamB_MacG5>
Ms2ger: isn't "gratuitous mismatch with libraries" enough?

[09:21:50.0000] <ls_n>
appendChild() would be less useful if it didn't return something.  If it returned the calling node, it would still be useful.  Whether more or less useful than returning the argument is debatable, but not the point. There is utility there. There is less utility without a return value.

[09:22:21.0000] <Ms2ger>
SamB_MacG5, I was asking for a point besides that

[09:22:25.0000] <zewt>
SamB_MacG5: no, "we should do it because libraries do it" is not an argument at all

[09:22:42.0000] <rwaldron>
Ms2ger my response is this: devs use libraries because the DOM APIs are awful. Regardless of the libary, they all share common behaviours and returning the this value is one of them.

[09:22:54.0000] <SamB_MacG5>
zewt: not a strong argument, I'll grant

[09:22:59.0000] <Ms2ger>
That's not an answer to my question

[09:22:59.0000] <danheberden>
And how _else_ would you characterizing people's wants besides their use of these libraries?

[09:23:02.0000] <Ms2ger>
Let me try again

[09:23:04.0000] <rwaldron>
These new mutation methods will not ease any DOM API pain points

[09:23:05.0000] <zewt>
ls_n: as I already said, functions should *not* be given a return value soley for the sake of having a return value; it needs to have enough value to *commit* that return value to that purpose for all time

[09:23:09.0000] <SamB_MacG5>
but if you haven't got anything *better* to do ...

[09:23:15.0000] <danheberden>
there is no big online survey of "how do you want the dom to work"

[09:23:18.0000] <danheberden>
you look at library useage

[09:23:36.0000] <zewt>
using the return value for something of value 0.1 means you can never use it to support a use case that appears a year from now with value 5.0

[09:23:38.0000] <Ms2ger>
Is there any reason that not returning the this value is "confusing" except for "it doesn't match a number of JS libraries"?

[09:23:42.0000] <zewt>
you're stuck with the 0.1 forever

[09:23:56.0000] <SamB_MacG5>
zewt: okay, that's an argument

[09:24:31.0000] <ls_n>
zewt: A fair point, but fear of the future in the face of current usage with developers expectating a return value seems silly.

[09:24:38.0000] <rwaldron>
zewt but... the current API is the problem

[09:25:15.0000] <rwaldron>
library adoption over DOM API seems to indicate displeasure with the way it was originally done, in favor of what we are explaining

[09:25:19.0000] <danheberden>
My addition, Ms2ger, was that JS devs get the idea that "i have something, then i call something on it" and naturally expect that 'something' to be there again

[09:25:38.0000] <danheberden>
that there is a natural inclination, in addition to library buy-in

[09:25:41.0000] <zewt>
ls_n: can't say I agree with the premise; I expect functions to do what they're documented as doing

[09:26:10.0000] <SamB_MacG5>
zewt: probably best not to steal the names the libraries have been using, then ?

[09:26:11.0000] <danheberden>
and that "it doesn't match a number of JS libraries" might indeed be the only big reason, albeit a very big reason/indicator

[09:26:34.0000] <SamB_MacG5>
otherwise, the users are liable to read the wrong documentation

[09:27:11.0000] <jwalden>
/me never understood returning-this behavior, versus just naming the same variable a second time, which is inarguably clearer as it requires no knowledge of the return type of the method that's being called

[09:27:14.0000] <zewt>
rwaldron: that's merely saying "we should arbitrarily mimic jquery because people use jquery" and could be applied to any aspect of the library

[09:27:39.0000] <SamB_MacG5>
jwalden: well, the one problem with that is that you have to actually name a variable in the first place

[09:28:11.0000] <zewt>
SamB_MacG5: as long as it doesn't result in weird, contrived or hard to type function names, i don't mind trying to use different names, no

[09:28:16.0000] <rwaldron>
Ms2ger if the method is "setting" (which includes mutation of subtrees, etc) the this value should be returned. If the method is "getting" (eg. an attribute value by name) then return the value of thing we're requesting. I don't understand what is so hard about this. cc zewt

[09:28:19.0000] <jwalden>
SamB_MacG5: I don't believe that's a problem, only if you buy into the jquery mindset of chaining method-call upon method-call in the first place

[09:28:24.0000] <jwalden>
SamB_MacG5: it kind of begs the question

[09:28:39.0000] <danheberden>
rwaldron: you could also add 'creating' to that list

[09:28:39.0000] <SamB_MacG5>
jwalden: well, I didn't say it was a *big* problem

[09:28:48.0000] <Ms2ger>
rwaldron, nothing hard about "how it works", only about "why it's useless"

[09:28:49.0000] <rwaldron>
danheberden +1

[09:28:54.0000] <Ms2ger>
Sorry, useful*

[09:28:55.0000] <zewt>
(rwaldron: you're repeating yourself and ignoring the responses, so unless you have something new to say I'm not going to repeat responses :)

[09:29:02.0000] <SamB_MacG5>
but I must admit sometimes I have trouble naming my variables :-)

[09:29:36.0000] <danheberden>
zewt, i'll bite - there are known problems with how jQuery's API is - rather, some outstanding bugs of people saying they'd like certain api methods to work

[09:29:46.0000] <danheberden>
and we're backed into a corner because it's existing stuff or we want to match the dom

[09:29:49.0000] <jwalden>
/me sees naming variables as a quite-useful form of documentation, all the more for being an actual part of the code, so less apt to bitrotting

[09:29:56.0000] <ls_n>
So this argument boils down to a disagreement in the value of returning this?

[09:30:01.0000] <danheberden>
however, this concept - of return values - people like

[09:30:09.0000] <danheberden>
people comment on how helpful it is

[09:30:17.0000] <danheberden>
or how unhelpful it is that the DOM doesn't do that

[09:30:17.0000] <zewt>
SamB_MacG5: again the chaining pattern tends to be built around eg. "add this one element", but when you're able to pass a list of items to add, a lot of that goes away

[09:30:43.0000] <danheberden>
so taking a huge number of developers that _choose_ to use jQ's API in to consideration seems worth something, ya?

[09:31:54.0000] <zewt>
(danheberden: <zewt> rwaldron: that's merely saying "we should arbitrarily mimic jquery because people use jquery" and could be applied to any aspect of the library)

[09:32:02.0000] <Ms2ger>
danheberden, jquery has its advantages

[09:32:10.0000] <danheberden>
but no one is saying we should arbitrarily mimic jquery

[09:32:12.0000] <danheberden>
except you two

[09:32:18.0000] <Ms2ger>
Papering over browser differences, say

[09:32:36.0000] <danheberden>
instead of replying to points, you mis-characterize the argument

[09:32:36.0000] <zewt>
that's exactly what you just said--"lots of people choose to use jquery, and that's an argument for doing this one particular thing in jquery's way"

[09:32:38.0000] <Ms2ger>
I think that's a bigger reason that people would use it than just the chaining

[09:32:49.0000] <danheberden>
zewt - THAT PARTICULAR feature

[09:32:50.0000] <jwalden>
this late in the game, fighting against long-standing DOM precedent, consistency with the rest of the DOM seems the right thing, and let libraries do their thing however they want it as they always do

[09:32:59.0000] <rwaldron>
In addition to danheberden's argument about taking developer preference into consideration, I'd also like to share some third party statistics: http://trends.builtwith.com/javascript

[09:33:02.0000] <danheberden>
i'm talking about the return value

[09:33:12.0000] <zewt>
no, we've replied to many points; i suspect you're not paying attention

[09:33:31.0000] <danheberden>
zewt - i've agreed with some, i think, so perhaps i should add a +1 in reply if i don't have an argument

[09:33:52.0000] <rwaldron>
zewt sure, I'll bite... ready? Here goes...

[09:34:05.0000] <ls_n>
zewt: There are many differences between DOM libraries.  If they all, or even mostly, agree on a set of methods to improve the experience of working with the DOM, that's not mimicking jQuery, that's codifying accepted convention.

[09:34:45.0000] <zewt>
anyway, HTML API design is based around technical arguments, not statistics and +1s and "look how many people use jquery"; i can recall no technical arguments being given for this at all, so i'm going to go and do my day job unless one turns up

[09:35:00.0000] <rwaldron>
Developers that build real things on the real web prefer library APIs, such as jQuery, YUI, Dojo, etc. as such, the API decisions of those libraries should be taken into consideration when new DOM APIs are created.

[09:35:22.0000] <danheberden>
zewt, you're aware that these "people" are the ones using these APIs, ya?

[09:35:36.0000] <zewt>
i use these APIs every day

[09:35:36.0000] <danheberden>
and the technical arguments don't have to use the APIs daily?

[09:35:45.0000] <danheberden>
and you wouldn't like them at all easier to use?

[09:36:03.0000] <zewt>
returning "this" doesn't make them easier to use

[09:36:07.0000] <Ms2ger>
danheberden, sure, I want them to be easier to use

[09:36:16.0000] <danheberden>
or because YOU'VE used them and like them means the other thousand people should too

[09:36:16.0000] <zewt>
not significantly enough to commit the return value to it forever

[09:36:31.0000] <danheberden>
cuz zewt, personally, i agree with you

[09:36:31.0000] <Ms2ger>
I've been trying to get people to explain why returning "this" would make them easier to use

[09:36:35.0000] <Ms2ger>
I haven't heard anything

[09:36:37.0000] <danheberden>
i am so used to how it works it doesn't bother me

[09:36:46.0000] <danheberden>
but i see the need for many others

[09:36:59.0000] <danheberden>
mainly because i work support a lot

[09:37:03.0000] <danheberden>
so i get a sense of that

[09:37:29.0000] <danheberden>
i do trainings and deal with a lot of typical developers

[09:37:53.0000] <danheberden>
Ms2ger: what kind of metrics _would_ be helpful?

[09:38:09.0000] <danheberden>
like - what way could we get an idea of buy-in from people that would satisfy you?

[09:38:27.0000] <Ms2ger>
I don't care much about "buy-in"

[09:38:41.0000] <danheberden>
perhaps i'm not using the right word

[09:38:50.0000] <danheberden>
i'm meaning if people would find it useful

[09:38:54.0000] <danheberden>
how to track/measure that

[09:38:57.0000] <zewt>
it seems clear to me that having a few functions return this, and most (eg. the legacy ones) return nothing or (in the case of appendChild) its argument, both makes the chaining pattern much less useful and very brittle and confusing

[09:39:10.0000] <Ms2ger>
I'm looking for someone to explain why people would find it useful

[09:39:11.0000] <danheberden>
like if i asked all of my students in a training, and had my coworkers do the same

[09:39:28.0000] <rwaldron>
zewt... technical argument: ES1, 3, 5, 5.1 and 6 (draft) have set a precendent for objects whose prototype methods return either a specific value that is relevant to or the result of an operation on the calling object, or a newly created copy of the calling object itself, which allows further calls to be "chained"

[09:40:42.0000] <Ms2ger>
rwaldron, want to give a few examples?

[09:40:51.0000] <rwaldron>
the DOM has deviated for a long time and users of DOM APIs have been "fixing" it for a decade.

[09:40:52.0000] <jwalden>
rwaldron: what precedents can you name for chaining in ECMAScript?  I can think of exactly one

[09:41:02.0000] <jwalden>
rwaldron: (in the language, I mean)

[09:41:31.0000] <zewt>
the argument i'm looking for is "here's a thing which is made so much easier or less error-prone that it justifies committing the return value to this--and nothing else--even if it's inconsistent with lots of other functions that do related things"

[09:41:38.0000] <danheberden>
Ms2ger: as for the personal why, i've had people express their displeasure at it NOT returning `this`; i can try to gain more insight as to the motivation behind that

[09:41:57.0000] <rwaldron>
Ms2ger yes. Array.prototype.push returns a relevant value: the new length. Array.prototype.map returns a newly created array object with the values of the map operation

[09:42:05.0000] <Ms2ger>
danheberden, I would appreciate that

[09:42:06.0000] <rwaldron>
need more?

[09:42:21.0000] <rwaldron>
There is a whole spec full of examples.

[09:42:37.0000] <Ms2ger>
rwaldron, I think you misunderstood my question

[09:42:40.0000] <zewt>
rwaldron: what? the new length isn't "this", it's the new length

[09:42:58.0000] <Ms2ger>
rwaldron, I'm looking for cases where ES returns the this value

[09:43:06.0000] <zewt>
(and precedent isn't an argument that something should be done, it just means it has been)

[09:43:12.0000] <jwalden>
rwaldron: [].map is not an example of chaining, it's an example of a function with a return value, no?

[09:43:17.0000] <rwaldron>
zewt read my previous message before trying to argue something that I _just_ said

[09:43:40.0000] <jwalden>
rwaldron: the only example I can come up with is [].sort, for a method that chains but doesn't return a new value/object

[09:43:44.0000] <Ms2ger>
rwaldron, sorry, I misunderstood you

[09:43:46.0000] <rwaldron>
[12:40 PM] <rwaldron> zewt... technical argument: ES1, 3, 5, 5.1 and 6 (draft) have set a precendent for objects whose prototype methods return either a specific value that is relevant to or the result of an operation on the calling object, or a newly created copy of the calling object itself, which allows further calls to be "chained"

[09:44:00.0000] <Ms2ger>
rwaldron, I'm just not sure how that is relevant, then

[09:44:02.0000] <rwaldron>
jwalden push?

[09:44:09.0000] <rwaldron>
sorry, no

[09:44:12.0000] <rwaldron>
strike that

[09:44:22.0000] <Ms2ger>
rwaldron, I think we're all in violent agreement that there is a point to returning a useful value

[09:44:28.0000] <rwaldron>
(I missed the part where you said "chains but doesn't"

[09:44:55.0000] <rwaldron>
Ms2ger agreed.

[09:45:25.0000] <rwaldron>
But I argue that returning void 0/undefined is not doing anyone any favors

[09:45:25.0000] <Ms2ger>
Phew, we agreed on something ;)

[09:45:31.0000] <rwaldron>
+1

[09:45:35.0000] <danheberden>
Ms2ger: lol

[09:46:16.0000] <danheberden>
Ms2ger: what dangers do you think are present in returning `this` instead of undefined?

[09:46:26.0000] <Ms2ger>
I guess I don't really see the value of returning 'this' in a few cases where we would otherwise return undefined

[09:46:29.0000] <danheberden>
what bad issues or problems would arrise from that?

[09:46:32.0000] <zewt>
danheberden: i've already explained that repeatedly :)

[09:46:40.0000] <Ms2ger>
One is that you can't return anything else

[09:46:45.0000] <zewt>
<zewt> using the return value for something of value 0.1 means you can never use it to support a use case that appears a year from now with value 5.0

[09:47:05.0000] <Ms2ger>
Another is that you still need to remember which methods return something useful, and which return this

[09:47:33.0000] <danheberden>
zewt, so if addEventListener, after all these years, was going to support a different return value

[09:47:35.0000] <Ms2ger>
I think what would be more useful is a JS feature to call multiple functions on one object

[09:47:51.0000] <zewt>
if the value of returning "this" is 5.0--if it's a significant, measurable win--then sure; but "we should return *something*, so it may as well be this" is a bad idea

[09:48:26.0000] <danheberden>
zewt - it's more, like, "this function has no useful return value except for the original element"

[09:48:40.0000] <zewt>
danheberden: you're confusing foresight with hindsight: when addEventListener was first implemented, there was no way of knowing whether some other return value would have turned up

[09:48:56.0000] <danheberden>
zewt, i'm saying take advantage of that hindsight

[09:49:26.0000] <ls_n>
zewt: So the number of years that libraries have been using these methods, returning 'this', and not running into any major use case that would have been so much better than returning 'this' is not evidence? What would a reasonable wait time be?

[09:50:00.0000] <Ms2ger>
ls_n, who says they haven't found (even not particularly big) such use cases?

[09:50:02.0000] <danheberden>
zewt, i *do* understand your point

[09:50:09.0000] <danheberden>
and it's a good one

[09:50:10.0000] <zewt>
ls_n: it's not about "wait time", it's about adding a feature when there's a clear, measurable win, and that's exactly what nobody is giving--examples of things which are made measurably easier or less error-prone by doing this

[09:50:13.0000] <Ms2ger>
It's not like they could have implemented those

[09:50:15.0000] <danheberden>
i don't think this shoudl all be tackled super lightly

[09:50:45.0000] <rwaldron>
zewt Ms2ger I'm worried that the "avoid future hostility" argument is actually going to end up turning this into a lost opportunity (purely opinion)

[09:50:47.0000] <danheberden>
but i think there are some cases where one could ascertain whether or not returning this would be a safe future proof change

[09:50:48.0000] <rwaldron>
:|

[09:51:18.0000] <Ms2ger>
rwaldron, possibly

[09:51:20.0000] <danheberden>
and honestly, with this argument, you would NEVER change the return value from undefinded to something

[09:51:29.0000] <danheberden>
because of the fear you'd need that return value in the future

[09:51:42.0000] <Ms2ger>
danheberden, why not? Because something *even better* could come along?

[09:51:48.0000] <danheberden>
i do that too - i buy a really tasty snack and wait for the best time to eat it.. but in the end, it just goes bad

[09:51:55.0000] <danheberden>
because i waited and waited

[09:52:01.0000] <zewt>
danheberden: of course you would--when you have a clear benefit for doing so, just like adding any feature. that benefit isn't clear (at least to us) in this case

[09:52:24.0000] <danheberden>
zewt - so perhaps the question isn't as much of 'should we' or 'shouldn't we'

[09:52:33.0000] <danheberden>
but how can we gather the information necessary to make this decision

[09:52:55.0000] <jwalden>
/me doesn't think the "we might want to return something in the future" argument has much value here -- either there's an obvious return value, or there's nothing, and thinking something might turn up in the distant future seems unrealistic

[09:53:07.0000] <ls_n>
Ms2ger: what inconveniences people have come across have been inconveniences.  At least, speaking from the YUI side of things. At the end of the day, if these methods are implemented without return value, then the libraries will call them, then return 'this' manually.  It will still just be an inconvenience.

[09:53:22.0000] <danheberden>
jwalden i think it has some merit, for a period of time at least

[09:53:28.0000] <SamB_MacG5>
I think the "we might want to return something" argument should be judged based on what you could reasonably return

[09:53:41.0000] <jwalden>
danheberden: plausible, depending on the API I guess

[09:53:41.0000] <danheberden>
i think libraries like jQuery give an oppurtunity to see if stuff is garbage or not

[09:54:14.0000] <jwalden>
for most APIs it's kind of a stretch

[09:54:30.0000] <danheberden>
i mean, look at jQ - `.click and .mouseover` - seriously?

[09:54:39.0000] <danheberden>
we learned that kind of stuff is awful

[09:55:12.0000] <zewt>
and again, inconsistently returning "this" is confusing--for example, e.addBefore(e2).appendChild(e3).addBefore(e4) is very confusing, since appendChild returns e3, not e

[09:55:23.0000] <SamB_MacG5>
I'm guessing most methods have a three or less reasonable, non-vacuous return values

[09:55:33.0000] <SamB_MacG5>
s/a /

[09:56:01.0000] <SamB_MacG5>
zewt: yes, agreed

[09:56:05.0000] <ls_n>
zewt: yes is it

[09:56:15.0000] <danheberden>
(i have a call to take, my non-response isn't grumpy silence :)

[09:56:48.0000] <jwalden>
danheberden: fine, then, be that way

[09:56:49.0000] <jwalden>
;-)

[09:56:50.0000] <ls_n>
would e.appendChild(e2).append(e3).boom() be less confusing?

[09:56:51.0000] <zewt>
anyhow i'm out of time for now--day job and all--so afk

[09:57:22.0000] <jgraham>
It would be nicer if js made it easier to write a function like chain(elem, appendChild(e1), appendChild(e2), appendChild(e3)) and so on

[09:58:07.0000] <jgraham>
Rather than forcing each function to return this or not work with chaining

[09:58:23.0000] <Ms2ger>
^ that

[09:59:08.0000] <Hixie>
annevk: extending the legal url syntax lgtm

[09:59:35.0000] <Hixie>
annevk: do you have a plan for how to specify the authoring conformance criteria?

[10:01:25.0000] <annevk>
Hixie: not really, wanted to figure out browser stuff first

[10:01:36.0000] <Hixie>
k

[10:01:42.0000] <annevk>
Hixie: but I guess in the end I'll just take inspiration from one of your specs

[10:01:50.0000] <Hixie>
heh

[10:01:53.0000] <annevk>
Hixie: that's what I usually do anyway, look for some existing pattern

[10:03:13.0000] <Hixie>
well there's several options on this front even just amongst stuff i've done :-)

[10:03:34.0000] <Hixie>
in particular, BNF variants and straight prose

[10:05:01.0000] <annevk>
rwaldron: """and all I've gotten in response is "yawn", some snide comments about jQuery and some misguided argument about fixing the issue in JS (ie. the language). """ dude, I tried to explain where I came from

[10:06:25.0000] <annevk>
rwaldron: up to and including that I'm fine with changing it, if we have some kind of plan

[10:07:54.0000] <annevk>
rwaldron: thus far it's like "can we do x?" "well, most of y doesn't do x at the moment and although we could try it, it seems kind of irresponsible without a plan for y" "..."

[10:08:28.0000] <rwaldron>
annevk I wasn't referring my discussion with you

[10:09:28.0000] <rwaldron>
annevk while you were away I provided several arguments beyond simply "can we do x?"

[10:09:31.0000] <annevk>
I think Ms2ger is arguing the same point, but not as constructive and friendly unfortunately

[10:10:02.0000] <rwaldron>
Ms2ger and I actually both agree that returning something is better then nothing

[10:12:02.0000] <rwaldron>
I'm stepping out for a few

[10:12:21.0000] <annevk>
that's not what he agreed to

[10:12:25.0000] <annevk>
see e.g. "I guess I don't really see the value of returning 'this' in a few cases where we would otherwise return undefined "

[10:12:44.0000] <annevk>
but yeah, my point was in particular that the platform does not return "this"

[10:12:54.0000] <annevk>
I don't know such APIs anyway

[10:13:00.0000] <rwaldron>
annevk [12:45 PM] <Ms2ger> rwaldron, I think we're all in violent agreement that there is a point to returning a useful value

[10:13:07.0000] <annevk>
right

[10:13:23.0000] <annevk>
but he's not convinced (like me) "this" is useful

[10:13:33.0000] <annevk>
furthermore, nowhere in the platform is this returned

[10:13:52.0000] <rwaldron>
This is really frustrating

[10:13:52.0000] <annevk>
and fwiw, platform is http://platform.html5.org/ of course

[10:14:21.0000] <rwaldron>
at no point did i say that ms2ger had agreed to returning this

[10:14:35.0000] <rwaldron>
I'm not even sure how you came to that based on what I jsut said

[10:14:59.0000] <annevk>
because you said he thought something is better than nothing

[10:15:01.0000] <annevk>
which is not what he said

[10:15:26.0000] <rwaldron>
dude

[10:15:28.0000] <rwaldron>
wtf

[10:15:28.0000] <rwaldron>
[12:45 PM] <Ms2ger> rwaldron, I think we're all in violent agreement that there is a point to returning a useful value

[10:15:29.0000] <rwaldron>
[12:45 PM] <rwaldron> (I missed the part where you said "chains but doesn't"

[10:15:29.0000] <rwaldron>
[12:45 PM] <rwaldron> Ms2ger agreed.

[10:15:29.0000] <rwaldron>
[12:46 PM] <rwaldron> But I argue that returning void 0/undefined is not doing anyone any favors

[10:15:29.0000] <rwaldron>
[12:46 PM] <Ms2ger> Phew, we agreed on something ;)

[10:15:29.0000] <rwaldron>
[12:46 PM] <rwaldron> +1

[10:16:12.0000] <rwaldron>
I hate to leave while we're having so much, but I actually have to step out for an appointment

[10:16:20.0000] <annevk>
returning a useful value does not mean that returning something is better than nothing

[10:16:40.0000] <zewt>
... he was agreeing with the first line (returning something useful is useful), not that returning undefined is bad

[10:16:47.0000] <annevk>
right

[10:17:05.0000] <rwaldron>
Cool, well don't sweat it.

[10:17:10.0000] <annevk>
rwaldron: ttyl then

[10:17:51.0000] <rwaldron>
I'm actually not interested in participating in this discussion anymore

[10:18:33.0000] <rwaldron>
Good luck with further development, I wish you nothing but success.

[10:19:16.0000] <annevk>
rwaldron: that's unfortunate; I hope you'll still contribute to other discussions

[10:26:21.0000] <annevk>
I had not expected people would actually call Array.prototype.push "chaining" as well

[10:26:35.0000] <annevk>
I thought "chaining" was reserved for methods that return "this"

[10:27:34.0000] <Hixie>
annevk: ho does Array push() chain?

[10:27:45.0000] <Hixie>
heycam|away: you following this Location thread on whatwg?

[10:28:02.0000] <annevk>
Hixie: because it returns something on which you can do an operation reportedly

[10:28:05.0000] <ls_n>
it's not chaining

[10:28:21.0000] <Hixie>
every function that returns anything is chaining then?

[10:28:23.0000] <Hixie>
o_O

[10:28:46.0000] <zewt>
that was just one of many confusions in that discussion, heh

[10:28:50.0000] <ls_n>
well, maybe this is semantics...

[10:29:37.0000] <annevk>
or maybe I parsed http://krijnhoetmer.nl/irc-logs/whatwg/20120925#l-975 and subsequent lines incorrectly

[10:30:02.0000] <ls_n>
"chaining" == `return this` vs "returns object" vs ?

[10:30:30.0000] <Ms2ger>
ls_n, I understood it to mean `return this`

[10:30:32.0000] <annevk>
ls_n: dunno man, I thought it was about returning the object you invoked the method on

[10:30:46.0000] <Hixie>
yeah, me too

[10:31:16.0000] <Hixie>
imho chaining is a layering violation, taking what should be a syntactic issue and dragging it into the api layer

[10:31:28.0000] <ls_n>
Yeah, I can see it either way, because you're chaining operations through the return value, regardless of whether it's 'this'

[10:32:42.0000] <Ms2ger>
abarth, so the html test suite currently splits submitted tests by person/organization that submitted them, any preference where those location tests should go?

[10:32:42.0000] <zewt>
annevk: ms2 asked for "examples" (implied: of things in ES that return the calling object), but was taken literally and received examples of random-not-chaining-at-all return values

[10:32:48.0000] <Hixie>
bbiab

[10:33:01.0000] <annevk>
zewt: so are there examples for "this"?

[10:33:17.0000] <zewt>
annevk: (also, though the ES quote thing wasn't relevant, it also says "a newly created copy of the calling object itself"--which isn't chaining at all when applied to something like a DOM node)

[10:33:46.0000] <zewt>
annevk: dunno; i don't think it matters (precedent isn't an argument)

[10:34:15.0000] <zewt>
(or I sure hope it isn't, we have mountains of really bad precedent in the older APIs :)

[10:34:42.0000] <Ms2ger>
I think jwalden had one

[10:35:30.0000] <zewt>
(in case the above wasn't clear--that ES line would mean returning this.cloneNode(), not this)

[10:35:43.0000] <jwalden>
annevk: Array.prototype.sort returns this; that's the only example I can think of

[10:35:54.0000] <jwalden>
/me has no idea why it returns this

[10:36:04.0000] <annevk>
jwalden: interesting

[10:36:13.0000] <Ms2ger>
jwalden, arr.sort().sort() // Just making sure

[10:36:15.0000] <zewt>
well, sorting multiple times is useful

[10:36:27.0000] <jwalden>
/me took advantage of that when constructing XSS exploits against the original Facebook platform, back five years ago, by applying sort to the global object :-)

[10:36:32.0000] <zewt>
(with different orderings)

[10:36:35.0000] <annevk>
zewt: I think precedents matter, because the lack of the platform doing it now is one of the arguments I use

[10:37:01.0000] <ls_n>
jwalden: prior to forEach, I never found it practically useful.

[10:37:02.0000] <zewt>
annevk: i think that's sort of halfway right

[10:37:04.0000] <Ms2ger>
zewt, fair :)

[10:37:08.0000] <jwalden>
/me thinks lack-of-platform-doing-it-now is the strongest argument against suddenly doing it now for new methods

[10:37:25.0000] <zewt>
annevk: it's not exactly precedent, so much as that the chaining paradigm only works well when it's supported consistently

[10:37:54.0000] <zewt>
eg. we don't want two or three functions that do it (precedent), we'd want to be able to do it everywhere to satisfy that

[10:38:21.0000] <annevk>
well yeah, my other argument is that I want to see some kind of plan rather than "lets do this here and see what happens" (sicking argues for that)

[10:38:46.0000] <zewt>
personally i write lots of code without jQuery or any other monolithic library at all and have never gone "man, I wish I could chain these calls", which is my own basic rationale :)

[10:39:13.0000] <annevk>
and Hixie's point about solving it elsewhere I like too, because then I don't have to worry

[10:39:37.0000] <jwalden>
heh

[10:39:44.0000] <ls_n>
annevk: I think a great deal of the feedback is attached to the names.  These same methods exist, and behave consistently in libs. If you'd chosen different names, there might have been less reaction.

[10:40:12.0000] <zewt>
(i'm less enthusiastic about the language-level solution, since that's really hard to do in a sane way--adding new syntax to JS means you can't use it *at all* until it's widely supported, since the whole file will fail to parse)

[10:40:20.0000] <annevk>
ls_n: nah, this kind of feedback is relatively common also for non-lib methods

[10:40:32.0000] <annevk>
ls_n: e.g. the mutation observer stuff

[10:40:53.0000] <zewt>
(unless someone gets creative enough to find a way to avoid that, like the "use strict"; hack, but I doubt that'll happen)

[10:41:36.0000] <jwalden>
"use strict" was just a bad idea, given script concatenation

[10:41:42.0000] <jwalden>
c'est la vie

[10:41:59.0000] <annevk>
javascript folks should've learned from doctype switching, and didn't

[10:42:33.0000] <zewt>
(i've found it useful, but mostly as a linting thing and to aid my unit tests--until every browser supports it I'm not turning it on in live code)

[10:42:35.0000] <annevk>
but considering they were pretty far along with an out-of-band versioning strategy, maybe we're lucky :)

[10:43:46.0000] <annevk>
brendan considers this different strategies for developing the platform a good thing, but I'm not sure I'm quite with him as the technologies do need to work together at the end of the day

[10:44:20.0000] <ls_n>
There's attachment to the familiarity of appendChild() returning a node, and attachment to the existing behavior of append(str) in libs returning a node (though it is a different one).

[10:44:49.0000] <jwalden>
well, at this point tc39 is in theory all gung-ho about "no more language modes/versions", so there shouldn't be any more "use strict" mistakes, or even |use strict;| pragmas, or whatever

[10:45:11.0000] <jwalden>
new syntax will just break stuff, new editions will not break old code

[10:45:20.0000] <annevk>
jwalden: littlecalculist (iirc) is a great man

[10:45:59.0000] <jwalden>
:-)

[10:46:47.0000] <jwalden>
a little too much of the PL-theory propellerhead for me on rare occasion, but yeah

[10:46:53.0000] <jwalden>
and it takes all kinds anyway

[10:47:04.0000] <jwalden>
/me wouldn't want a committee of people like him :-)

[10:47:12.0000] <jwalden>
at least, not a whole committee of them

[10:47:34.0000] <zewt>
i don't really mind a bit of bumpiness for use strict, since some of the things it fixes are *really* annoying JS quirks (unintended globals being the most obvious; .freeze not causing exceptions is lame too, etc)

[10:47:46.0000] <zewt>
but i'd call that a one-time thing :)

[10:48:05.0000] <annevk>
anyone from Google here? What are the best email addresses for Alex Russell and Erik Arvidsson? I have their @google.com addresses, but if there's something they actually read and reply to, might be nice

[10:48:39.0000] <jwalden>
a better rollout strategy for use-strict probably would have helped some; jslint and json2.js picking it up prematurely was a large part of the problem

[10:49:03.0000] <jwalden>
even still, "backwards compatible" but not is just the worst of both worlds

[10:49:20.0000] <annevk>
in particular, I see arv is here, I'm looking for a reply to http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0069.html

[10:50:43.0000] <zewt>
jwalden: python 3's strategy is the worst of all worlds :) overlapping compatibility is much more copable

[10:51:12.0000] <jwalden>
/me is ambivalent about python 3's strategy

[10:51:18.0000] <zewt>
/me isn't

[10:51:31.0000] <jwalden>
although I am perfectly happy to say it would not at all at all at all work for the web :-)

[10:51:41.0000] <jwalden>
diff'rent strokes, perhaps

[10:51:50.0000] <zewt>
python 3.0 released in dec 2008; it's 2012 and I'm still on 2.7. migration failed :)

[10:52:30.0000] <jwalden>
if they were aiming for a less-than-four-years transition

[10:52:49.0000] <jwalden>
python's always been a with-all-deliberate-speed sort of group

[10:53:07.0000] <jgraham>
/me expects python 3 transition to work eventually

[10:53:09.0000] <jwalden>
I think as long as they get there eventually, they're more or less happy

[10:53:11.0000] <jwalden>
yeah

[10:53:31.0000] <jwalden>
expecting a turnaround by some particular time, or aiming for one, is setting oneself up for disappointment

[10:54:07.0000] <jwalden>
and I've seen enough signs from people that they're slowly working on the transition that I don't think it can be said to have failed, right now

[10:54:18.0000] <zewt>
much saner to make breaking changes slowly, and to keep reasonable compatibility overlap between adjacent versions, instead of making a ton of big breaking changes at once, which just seemed like they got impatient

[10:54:23.0000] <jwalden>
signs from people, and from projects implemented in python, that is

[10:59:06.0000] <Ms2ger>
I've seen work on py3 compat in Mozilla's new python code, fwiw

[11:25:35.0000] <zewt>
annevk: should path step 2 also set fregment to "#", like hierarchical does?

[11:27:50.0000] <zewt>
(don't know which is correct, just seems odd that they differ)

[11:35:54.0000] <annevk>
zewt: fixed

[11:42:42.0000] <Hixie>
"Your task is nontrivial"

[11:42:45.0000] <Hixie>
story of our lives

[11:43:36.0000] <zewt>
"queue a nontrivial task"

[11:44:15.0000] <zewt>
(a big queue)

[11:46:05.0000] <jgraham>
It does sound like the end of the introduction to a badly translated text adventure, or something

[11:48:48.0000] <Hixie>
cabanier: is your work on adding blending etc to canvas covering things like adding blur effects?

[11:52:32.0000] <annevk>
Hixie: not sure if trolling, or just misunderstanding what he's on about

[11:52:45.0000] <Hixie>
pretty sure he's not trolling

[11:53:06.0000] <Hixie>
he's right that defining the conformance criteria is non-trivial

[11:53:12.0000] <Hixie>
but wrong if he thinks that's unusual :-)

[11:53:28.0000] <Hixie>
i think it's just the regular culture clash -- ietf and w3c often tend to shy away from fixing hard problems

[11:54:02.0000] <Hixie>
same with the shock that we might even consider doing something that we view as obsoleting an IETF STD

[11:54:32.0000] <Hixie>
whereas from our point of view, we're like, "look, we said it was broken years ago, we gave you a chance to fix it, now we've timed out and are doing it ourselves"

[11:54:56.0000] <say2joe>
hixie: Hooray to that.

[11:56:15.0000] <annevk>
I guess indeed it's the regular culture clash, but using "finding URLs in text" as an example as to why we need to restrict the syntax...

[11:56:46.0000] <annevk>
but I'm happy you took the time to explain that one

[11:57:23.0000] <Hixie>
finding urls in text is indeed something that is impossible if we consider any random string valid

[11:57:34.0000] <Hixie>
but (a) we don't, and (b) people don't want to find only valid URLs so that doesn't matter anyway

[11:58:20.0000] <Hixie>
it's pretty common for people to will the use case to be different because the real use case is hard to fix :-P

[11:58:26.0000] <Hixie>
(i do it all the time too :-P)

[11:58:28.0000] <dsheets>
annevk: your assertion that the composition of parsing, resolving, and canonicalizing is trivial points to the problem. Your task is not trivial so why should your algorithm be?

[11:58:46.0000] <annevk>
dsheets: hey!

[11:58:51.0000] <zewt>
when I saw the "why don't you just patch RFC#whatever" post I just grimaced, pitied whoever had to reply to that noise, and moved on :)

[11:59:08.0000] <Hixie>
we did patch the RFC

[11:59:17.0000] <Hixie>
didn't work well enough. anne's now doing it properly. :-)

[11:59:31.0000] <zewt>
exactly :)

[11:59:49.0000] <annevk>
dsheets: well, 1) I said "quite trivial" and 2) I guess it is indeed non-trivial, but it is rather easy to follow

[12:00:26.0000] <Hixie>
something can be non-trivial to design, yet be trivial in its result

[12:00:46.0000] <Hixie>
in fact, the more trivial the solution, typically, the harder one had to work to develop it :-P

[12:01:05.0000] <Hixie>
(all other things, e.g. how much the solution solves, being equal)

[12:01:15.0000] <dsheets>
annevk: I find it very difficult to follow. What are the allowable alphabets of conforming productions? What normalization is done? It's all mixed together in a prose state machine.

[12:01:19.0000] <annevk>
dsheets: and what I like about it in particular is that it is much closer to implementations, so if we want to extend it or implementations want to follow it to fix bugs, things will be a lot easier

[12:01:54.0000] <annevk>
dsheets: "c" can be any code point basically, including surrogate code points

[12:02:09.0000] <annevk>
dsheets: that's about it

[12:02:16.0000] <Hixie>
there's a definition of conforming productions?

[12:02:26.0000] <annevk>
nope

[12:02:31.0000] <zewt>
dsheets: do you really find IETF-style specs easier to follow than HTML-style algorithmic specs? because you'd be the first I've heard of

[12:02:35.0000] <annevk>
need to add that under "Writing" at some point

[12:02:39.0000] <Hixie>
dsheets: he hasn't defined what's valid yet.

[12:03:08.0000] <Hixie>
zewt: lots of people think declarative is easier than imperative. They're right, when you don't care about defining timing and error handling.

[12:03:22.0000] <Ms2ger>
zewt, for authoring, sure

[12:03:23.0000] <Hixie>
zewt: see e.g. the websocket protocol hybi mailing list

[12:03:42.0000] <Hixie>
zewt: it's really hard to read complex algorithms and work out their implications.

[12:03:47.0000] <zewt>
Hixie: personally I find imperative easier even as a user--anne's DOM Events work made the event system infinitely clearer to me, for example

[12:03:59.0000] <dsheets>
zewt: for testing, yes

[12:04:02.0000] <zewt>
there's a breaking point, of course, depending on the complexity of the algorithm

[12:04:08.0000] <Hixie>
zewt: fair enough

[12:05:00.0000] <annevk>
dsheets: fwiw, I'm not opposed to including some ABNF somewhere

[12:05:29.0000] <annevk>
dsheets: at the moment I'm focused on figuring out parsing (mostly what code browsers/curl/search engines/etc. need to run)

[12:07:07.0000] <dsheets>
annevk: mixing parsing and normalization obscures the meaning of a given identifier. Separating the spec into phases and specifying exactly what will pass through unmangled would be very helpful.

[12:07:39.0000] <Hixie>
what is "normalisation" here?

[12:08:47.0000] <dsheets>
Hixie: producing identifiers over which serialize compose parse is identity

[12:09:09.0000] <dsheets>
Hixie: that is, nonconforming -> conforming

[12:10:04.0000] <dsheets>
Hixie: canonicalization is related, i believe, but concerns things like hexadecimal case changes where both input and output are conforming but one representation is 'canonical'

[12:10:33.0000] <Hixie>
dsheets: i have no idea what what you just said means

[12:11:14.0000] <Hixie>
dsheets: how does this differ from "parse"?

[12:11:30.0000] <dsheets>
Hixie: which bit? if you parse a conforming URI and then serialize it, the result should be the original URI

[12:12:16.0000] <annevk>
hmm; http://example.org is conforming yet gives http://example.org/; or http://example.org:/ gives http://example.org/

[12:12:51.0000] <dsheets>
Hixie: perhaps you say that there are conforming URIs that are not canonical and so the result is the canonicalization of the input… feeding this result back through should result in the same string

[12:12:54.0000] <Hixie>
dsheets: sounds like what you're saying is "normalisation" is the act of parsing then serialising.

[12:13:12.0000] <Hixie>
dsheets: so how could you separate it from parsing?

[12:13:41.0000] <zewt>
yeah. conforming and normalized are different things

[12:13:54.0000] <dsheets>
Hixie: normalization is whatever you do to produce a valid identifier from an arbitrary input

[12:14:12.0000] <Hixie>
dsheets: ok, so, parse then serialise.

[12:14:34.0000] <dsheets>
that is how you can test it, yes, but that is not the normalization algorithm

[12:14:41.0000] <Hixie>
dsheets: i guess i don't understand what you are asking for.

[12:14:48.0000] <annevk>
dsheets: it is in the new spec

[12:15:01.0000] <Hixie>
dsheets: the normalisation algorithm is "parse the string. serialise the bits into a url."

[12:15:06.0000] <annevk>
dsheets: and for sure parser/serialize is how a typical URL library works

[12:15:22.0000] <Hixie>
i don't see how else you could do it

[12:15:35.0000] <dsheets>
I am asking for the explicit separation of nonconforming -> conforming as well as conforming -> canonical

[12:16:16.0000] <dsheets>
http://www.example.com is conforming but noncanonical. http://www.example.com/ is canonical

[12:16:28.0000] <zewt>
to back up a little: what's the purpose of this?

[12:16:32.0000] <annevk>
sure, the former is input, the latter is output

[12:16:45.0000] <annevk>
that the former is conforming is yet to be written down

[12:17:28.0000] <Hixie>
dsheets: i don't think it makes sense to define two different parsers.

[12:17:38.0000] <dsheets>
If there are invalid inputs that produce valid outputs, those invalid inputs must undergo some sort of normalization to put them in the space of valid inputs

[12:17:43.0000] <Hixie>
dsheets: that would just be asking for them to end up out of sync.

[12:18:11.0000] <Hixie>
dsheets: it's better not to think of inputs as valid or invalid

[12:18:30.0000] <Hixie>
dsheets: whether a URL is valid or not is really just a minor detail for authoring conformance/lint tools

[12:18:40.0000] <dsheets>
Hixie: how can they be out of sync? they compose

[12:18:41.0000] <Hixie>
dsheets: to help authors avoid likely mistakes

[12:19:17.0000] <Hixie>
dsheets: i don't see how you could describe a parser that only parses invalid urls and that then passes the result of that to a parser that only accepts valid urls, that would be insane

[12:19:34.0000] <Hixie>
dsheets: you'd actually need three parsers then, one for invalid urls, one for valid urls, and one for unknown urls to determine if they were valid or not!

[12:19:37.0000] <annevk>
it would be twice the work and nobody would ever implement it that way

[12:19:41.0000] <Hixie>
dsheets: just have one parser, it's cleaner

[12:20:04.0000] <annevk>
this argument is interesting though

[12:20:14.0000] <annevk>
because it's the exact same argument we got from the W3C TAG about the HTML parser

[12:20:16.0000] <Hixie>
dsheets: can you imagine what a mess HTML parsing would be if we used that kind of strategy?

[12:20:20.0000] <annevk>
nobody else ever cared

[12:20:34.0000] <Hixie>
annevk: really? i guess i blissfully missed that

[12:20:42.0000] <Hixie>
annevk: or i've blocked it out of my memory :-P

[12:20:50.0000] <dsheets>
Hixie: not parsers, functions. You can compose all these functions in your parser and most implementations will.

[12:21:02.0000] <Hixie>
dsheets: function, parser, same thing

[12:21:02.0000] <annevk>
Hixie: I quite clearly remember DanC and such wanting a parser just for valid stuff

[12:21:07.0000] <Hixie>
annevk: weird

[12:21:28.0000] <Hixie>
dsheets: s/parser/algorithm/ in my argument above, it still holds.

[12:22:03.0000] <dsheets>
Hixie: no. Every parser is a function but not every function is a parser. Parsers operate on strings.

[12:22:29.0000] <Hixie>
dsheets: that doesn't affect my argument

[12:22:36.0000] <annevk>
hsivonen: sad news: "Unicode 6.2 will include the accelerated publication of the character U+20BA TURKISH LIRA SIGN"

[12:23:49.0000] <Hixie>
imho, the right way to do this is to have one function that turns a string into components (parser), one that turns components into strings (serialiser), one that turns an incomplete set of components and a complete set of components into one complete set of components (resolution), and one that takes a string and returns a boolean (conformance definition)

[12:24:00.0000] <dsheets>
Hixie: Does it? Specifying the composition of these functions for different inputs makes the meaning of the spec much clearer. It is then obvious what inputs are 'safe', what inputs will be mangled, and what inputs will never be mangled.

[12:24:23.0000] <Hixie>
dsheets: defining what inputs are safe is done by defining "valid URL", which is an entirely separate problem.

[12:25:00.0000] <Hixie>
dsheets: in the HTML spec, this is http://whatwg.org/html#writing vs http://whatwg.org/html#parsing

[12:25:59.0000] <dsheets>
Hixie: it would appear that inside of the parser, you generate a valid URL. Why is this obscured?

[12:26:06.0000] <annevk>
Hixie: parser and resolution are merged in the current spec

[12:26:39.0000] <annevk>
Hixie: I haven't written a serializer yet; though the API has various members that serialize URLs in various ways

[12:26:50.0000] <annevk>
Hixie: so I might not bother writing an explicit serializer

[12:27:10.0000] <annevk>
(never mind, I guess I should for HTTP and such)

[12:27:28.0000] <Hixie>
dsheets: i don't understand the question.

[12:27:58.0000] <Hixie>
annevk: i need a "parse" algorithm that returns components, and a "resolve" algorithm that returns an absolute url

[12:28:14.0000] <annevk>
Hixie: parse always returns an absolute URL

[12:28:25.0000] <Hixie>
annevk: how do i get the components?

[12:28:34.0000] <dsheets>
Hixie: Why specify only the composition instead of the factors?

[12:28:36.0000] <annevk>
Hixie: it returns a URL object that has components

[12:28:43.0000] <Hixie>
dsheets: i don't understand what that means

[12:28:47.0000] <annevk>
Hixie: but it's always a complete URL (or invalid)

[12:29:04.0000] <Hixie>
annevk: if it returns both an absolute URL and components, that's fine by me

[12:29:37.0000] <annevk>
Hixie: http://url.spec.whatwg.org/#concept-url is what you get back

[12:30:06.0000] <annevk>
Hixie: you parse an "input" into a concept-url, which has concept-url-scheme etc.

[12:30:12.0000] <Hixie>
annevk: k

[12:30:15.0000] <Hixie>
annevk: lgtm

[12:30:41.0000] <dsheets>
annevk: the base may be unknown or ambiguous. Can I defer relative resolution?

[12:31:13.0000] <Hixie>
just don't parse it until you need to resovle it

[12:32:41.0000] <annevk>
dsheets: hold the "input" until you have the base

[12:33:21.0000] <TabAtkins>
zcorpan: I sent email to WHATWG on *behalf* of the SVGWG, *because* we're adopting multi-letter commands. ^_^

[12:33:45.0000] <dsheets>
Hixie: so no means will be provided to manipulate relative references? Relative references can never be serialized?

[12:34:14.0000] <Hixie>
dsheets: you shouldn't ask me, anne is the editor of this url spec

[12:34:34.0000] <Hixie>
dsheets: but i'm sure if you give anne use cases, he will be more than happy to address them

[12:34:46.0000] <Hixie>
dsheets: does anything on the web serialise relative urls?

[12:35:24.0000] <dsheets>
Hixie: anything that manipulates data structures which use relative references and outputs said data structures...

[12:35:35.0000] <Hixie>
dsheets: such as?

[12:35:57.0000] <dsheets>
Hixie: DOM transformers

[12:36:32.0000] <zewt>
(how is it 2012 and gmail doesn't let you add filters to mark as spam?)

[12:36:36.0000] <annevk>
dsheets: and they manipulate URLs?

[12:37:10.0000] <dsheets>
annevk: sure, partial resolution of URLs is common

[12:37:26.0000] <Hixie>
dsheets: do you have an example i can look at?

[12:37:34.0000] <Hixie>
zewt: it does

[12:37:57.0000] <smaug____>
paul_irish: ping

[12:38:21.0000] <zewt>
Hixie: lets you delete, and "never spam", but not "always spam"

[12:38:23.0000] <annevk>
dsheets: in any event, if we decide that we do want parsing and resolution separate, that's not really a big deal

[12:38:42.0000] <zewt>
i guess since the difference between deleted and spam is so opaque with gmail (if it affects filtering, I can't measure it), i may as well not care

[12:38:44.0000] <Hixie>
zewt: huh

[12:38:46.0000] <TabAtkins>
zewt: I think the intent is that you just mark it as spam normally, and let your filters catch up.

[12:38:47.0000] <Hixie>
zewt: i stand corrected.

[12:39:00.0000] <paul_irish>
smaug____: yessir

[12:39:06.0000] <zewt>
anyway, sorry for the distraction, didn't notice that you were still talking with ds :)

[12:39:20.0000] <Hixie>
zewt: i am capable of having multiple conversations at once :-P

[12:39:29.0000] <TabAtkins>
s/filters/normal spam filter/

[12:39:31.0000] <Hixie>
zewt: (whenever i'm chatting here i'm also editing the spec :-P)

[12:39:38.0000] <dsheets>
Hixie: not off-hand, no. You can't conceive of converting a relative path into an absolute path or a schemed URI into a scheme relative URI?

[12:39:55.0000] <zewt>
well, i try to limit random irrelevant drop-ins to when there isn't an on-topic discussion going on :)

[12:40:02.0000] <Hixie>
dsheets: if you have no concrete examples, i have no trouble saying we don't need to address it.

[12:40:16.0000] <Hixie>
dsheets: i have never found a need to do so, personally

[12:40:18.0000] <smaug____>
paul_irish: just curious, based on what is some test added to robohornet

[12:41:05.0000] <dsheets>
Hixie: really? I have done this numerous times in numerous languages. Absolutizing URI references is useful.

[12:41:24.0000] <Hixie>
dsheets: i'd be happy to look at concrete examples

[12:41:44.0000] <Hixie>
dsheets: resolving urls is certainly useful, and the algorithm anne is defining does so

[12:42:01.0000] <smaug____>
(the range API for example looks very odd, since it ends up adding element with same id 50 times to document)

[12:42:19.0000] <Hixie>
smaug____: sounds realistic :-P

[12:42:29.0000] <dsheets>
Hixie: you are stonewalling. Please address the technical consideration.

[12:42:45.0000] <dsheets>
Hixie: resolution and partial resolution are different

[12:42:53.0000] <zewt>
he's asking for use cases--what you actually want to do (or would want to do) that the proposed API and spec doesn't handle

[12:42:54.0000] <smaug____>
paul_irish: you probably also saw https://github.com/robohornet/robohornet/issues/66 . It means that some tests are actually testing something else than what they are supposed to test

[12:42:59.0000] <smaug____>
Hixie: sure :)

[12:42:59.0000] <Hixie>
dsheets: i'm not the editor, anne is the one who will address issues on this spec. I'm just trying to explain to you how we work.

[12:43:07.0000] <paul_irish>
smaug____: based on isolated performance issues that have been identified in a few notable js applications and libraries. they've been reduced down to a useful quantity of code

[12:43:12.0000] <zewt>
that isn't stonewalling, it's the standard approach here

[12:43:19.0000] <Hixie>
dsheets: and the way we work is we don't address hypotheticals

[12:43:28.0000] <paul_irish>
smaug____: yeah 66 looks legit.

[12:43:38.0000] <Hixie>
dsheets: if you have done it as many times as you say, then you need but document them for us

[12:43:45.0000] <Hixie>
dsheets: e.g. a pointer to a page that does it

[12:44:12.0000] <dsheets>
Hixie: resolving foo/bar against /baz/ into /baz/foo/bar

[12:44:31.0000] <Hixie>
dsheets: do you have an example of something that does that?

[12:44:36.0000] <paul_irish>
smaug____: benchmark.js seems to be the strongest harness for benchmarking, but yeah produces some problems with this test in partic

[12:44:47.0000] <dsheets>
Hixie: resolving #frag against path into path#frag

[12:44:50.0000] <smaug____>
paul_irish: I was looking at DOM Range test, because I know that code is probably the least optimized code in Gecko... but then the test is actually spending time everywhere else but in Range code

[12:45:04.0000] <smaug____>
paul_irish: "some" problems

[12:45:08.0000] <Hixie>
dsheets: do you have an example of something that does that?

[12:45:24.0000] <smaug____>
paul_irish: if you run the innerHTML testfile itself, it ends up testing innerHTML

[12:45:30.0000] <paul_irish>
yeah

[12:45:34.0000] <Hixie>
dsheets: it's easy to come up with arbitrary needs, but those aren't use cases

[12:45:40.0000] <smaug____>
if you use the testharness, it tests something else too

[12:45:51.0000] <zewt>
dsheets: the question isn't what it is (we get that--modifying relative paths as-is without resolving them), it's why you want to do it

[12:45:52.0000] <Hixie>
dsheets: use cases are concrete examples of actual problems met by real users

[12:45:58.0000] <paul_irish>
smaug____:  really appreciate you, boris, kyle, others looking at these btw

[12:46:03.0000] <paul_irish>
yes

[12:46:19.0000] <smaug____>
paul_irish: anyhow, sounds like the usual problems with tests. Testing something else than one is supposed to test :)

[12:46:33.0000] <annevk>
dsheets: I have looked into this, and as far as http://platform.html5.org is concerned, only parsing input (maybe combined with a base URL) into a URL is what is visibly exposed

[12:46:55.0000] <annevk>
dsheets: and actually used

[12:47:17.0000] <dsheets>
Hixie: I am a real user and I have personally constructed systems to do this for real world use cases. It is useful in conjunction with pushState.

[12:47:26.0000] <annevk>
dsheets: and although I have found some libraries that do the kind of thing you mentioned just now, I have never seen a request for such functionality before

[12:47:44.0000] <zewt>
how, concretely, is it useful with pushState?

[12:48:03.0000] <paul_irish>
smaug____: is the range issue that the gEBId soaking up the time?

[12:48:07.0000] <zewt>
(i've used pushState extensively; I give it relative URLs, and it pushes a resolved absolute URL)

[12:48:42.0000] <zewt>
not doubting you, just trying to get closer to what you want to do

[12:48:50.0000] <Hixie>
dsheets: can you provide me with a URL to such a page?

[12:48:56.0000] <smaug____>
paul_irish: the range test is actually testing parsing time ( r.createContextualFragment(REPLACEMENT_HTML) ) and inserting something to DOM ( r.insertNode )

[12:49:40.0000] <smaug____>
very little about range specific stuff

[12:50:39.0000] <dsheets>
Hixie: http://ashimagroup.net/~sheets/demo/pano/mars/#?az=1.020944687796126&el=-0.11416091059502942 The same app is served for http://ashimagroup.net/~sheets/demo/pano/mars/msl/nav1/ after partial relative resolution to root the common assets to the domain

[12:51:31.0000] <Hixie>
can you elaborate on his this works? where do i see the partial resolution?

[12:51:39.0000] <annevk>
Hixie: btw, on http://url.spec.whatwg.org/ and http://xhr.spec.whatwg.org/ dfn.js does not work

[12:51:45.0000] <paul_irish>
smaug____: got it. making a ticket.

[12:51:51.0000] <Hixie>
annevk: any idea why not?

[12:52:05.0000] <annevk>
actually on xhr it just complaints about some cookie function

[12:52:08.0000] <annevk>
but on url it fails

[12:52:24.0000] <Hixie>
annevk: probably missing some other script it relies on

[12:52:26.0000] <smaug____>
paul_irish: Add rows to ticket seems to test reflow, so looks like the issue 66

[12:52:34.0000] <annevk>
Hixie: for url it says "Uncaught TypeError: Object function Object() { [native code] } has no method 'push' "

[12:52:58.0000] <dsheets>
Hixie: currently it is done at build time

[12:53:04.0000] <Hixie>
annevk: no idea

[12:53:16.0000] <zewt>
in other news, onerror in ios 6 safari finally gives useful info, huzzah

[12:53:20.0000] <annevk>
Hixie: Opera says

[12:53:22.0000] <zewt>
also usable remote debugging, huzzah^2

[12:53:23.0000] <annevk>
Error thrown at line 26, column 10 in <anonymous function>() in http://www.whatwg.org/specs/web-apps/current-work/dfn.js:

[12:53:23.0000] <annevk>
    dfnMap[s].push(links[k]);

[12:53:24.0000] <Hixie>
dsheets: can you elaborate? (this is exactly the kind of thing that is useful here)

[12:53:39.0000] <smaug____>
paul_irish: oh, AddRows explicitly wants to flush layout. Then it is testing the thing it tries to test :)

[12:53:54.0000] <paul_irish>
smaug____: whats your github username

[12:54:20.0000] <smaug____>
hmm, I did have one...

[12:54:33.0000] <smaug____>
can't recall

[12:54:56.0000] <smaug____>
I'll follow robohornet issues

[12:55:11.0000] <dsheets>
Hixie: elaborate on what? The absolute path is unknown in development. The host is unknown at deploy time. The scheme is unknown at run time.

[12:55:32.0000] <Hixie>
cabanier: your input on the most recent mail to whatwg would be most helpful (re your blending spec)

[12:55:49.0000] <Hixie>
dsheets: i'm trying to understand what happens in the build process.

[12:55:52.0000] <annevk>
Hixie: so if I want that fixed I will have to debug?

[12:56:01.0000] <Hixie>
annevk: yup :-)

[12:56:10.0000] <paul_irish>
smaug____: https://github.com/robohornet/robohornet/issues/69

[12:56:18.0000] <Hixie>
annevk: or send me mail

[12:56:21.0000] <Hixie>
annevk: no eta

[12:56:45.0000] <Hixie>
dsheets: e.g. why can't you just use relative URLs? Why do you have something to partially resolve?

[12:56:47.0000] <annevk>
yeah okay, I'll look into it some day, might learn a thing or two

[12:56:51.0000] <Hixie>
dsheets: how do you do it today?

[12:57:18.0000] <smaug____>
paul_irish: thanks

[12:58:09.0000] <dsheets>
Hixie: the relative path "panos/MER.jpg" is resolved to "/~sheets/demo/pano/mars/panos/MER.jpg"

[12:58:30.0000] <Hixie>
dsheets: but why? why not just leave it as panos/MER.jpg ?

[12:59:06.0000] <dsheets>
Hixie: the same source is served for all subpaths and the display is switched in JS to accomodate pushState

[12:59:53.0000] <Hixie>
why are there multiple subpaths

[13:00:09.0000] <Hixie>
sorry if it sounds like i'm being stupid here but this really feels like trying to get blood from a stone

[13:00:46.0000] <dsheets>
Hixie: I'm sorry you are having a hard time understanding. I will try to explain more clearly.

[13:02:15.0000] <dsheets>
Hixie: your question is "why are there multiple subpaths in your single-page pushState-using web app?"? Is that accurate? Why not?

[13:03:42.0000] <Hixie>
dsheets: well specifically, why would your one-page app be exposed using multiple URLs when its resources are only exposed at one URL each

[13:03:47.0000] <Hixie>
dsheets: what user-problem does this solve?

[13:04:05.0000] <Hixie>
dsheets: seems like a much simpler solution would be to just have one URL, and then you wouldn't have to resolve any resource URLs

[13:04:38.0000] <Hixie>
dsheets: in terms of spec problems, we don't solve hypotheticals, but we also don't solve unnecessary problems, hence i'm trying to work out why this is a necessary problem rather than just make-work

[13:05:35.0000] <dsheets>
Hixie: How do I have one URL for multiple resources? Doesn't pushState allow me to design my URI scheme in a way that keeps distinct resources distinct?

[13:05:53.0000] <dsheets>
Hixie: your dismissive attitude is unnecessary.

[13:07:01.0000] <Hixie>
dsheets: ok i'm going for lunch, i'll be back in a few. I recommend writing an e-mail the describes your use case, and why it is important, and sending it to the WHATWG list. I recommend doing so in a manner that actually describes the entirety of the problem and doesn't feel as reluctant to share as this conversation has.

[13:07:07.0000] <Hixie>
bbiab.

[13:08:57.0000] <annevk>
dsheets: so is your concern that the specification no longer addresses ../foo resolved against /bar/?

[13:09:09.0000] <annevk>
dsheets: or do you want an API that resolves ../foo against /bar/?

[13:09:40.0000] <annevk>
dsheets: there's certainly no such API now, so you must use a workaround of some kind

[13:10:32.0000] <annevk>
dsheets: in any event, concrete examples would go a long way (unfortunately does require some work)

[13:13:37.0000] <dsheets>
annevk: I want to be able to parse a URI reference in a JSON object, use the browser API to normalize/canonicalize/whatever it, and re-emit a relative URI reference in a JSON object. If parsing entails resolution into an absolute URI, I have to know which bits of the input URI are present, resolve it against a dummy base and then throw away the bits that come from the dummy base.

[13:14:29.0000] <annevk>
yeah, you can hack around it like that

[13:15:14.0000] <dsheets>
annevk: yeah, so that's not so cool because now I can't simply use the API, I have to inspect the string itself and bring my own code to understand which components are present.

[13:15:40.0000] <annevk>
but that wouldn't give you things like input: http://example.org/test/bar/ and /test/foo -> "../foo"

[13:16:07.0000] <annevk>
I mean there's all kinds of stuff you could write, but it's kinda nice to know the use cases

[13:16:16.0000] <dsheets>
annevk: which sort of makes the API (which is already doing this internally)  unusable

[13:16:51.0000] <dsheets>
annevk: that is not he algorithm I am talking about. relativization is significantly more complicated and I do not expect it in the API.

[13:18:34.0000] <annevk>
okay, so this complaint is about the API, not the way the spec is written?

[13:18:53.0000] <annevk>
because that wasn't really clear to me

[13:19:25.0000] <dsheets>
annevk: I want the browser to supply a function that takes "/%65/" and outputs "/e/" or "#%65" and outputs "#e", for example

[13:20:01.0000] <annevk>
the browser does no such thing now...

[13:20:15.0000] <annevk>
but you can use encodeURI and decodeURI for that

[13:20:39.0000] <annevk>
(it does no such thing if you put those in places that take actual URLs)

[13:21:00.0000] <annevk>
anyway, I need to get some sleep

[13:21:51.0000] <dsheets>
annevk: doesn't the spec specify the API? If the spec says parsing and relative resolution are always composed and parsing can only occur relative to a base URI, then I can't use its normalization.

[13:22:42.0000] <annevk>
there's no normalization like %65 -> e

[13:22:51.0000] <annevk>
%65 stays the same

[13:23:40.0000] <annevk>
™ will turn into %E2%84%A2

[13:23:50.0000] <annevk>
but %E2%84%A2 will never upon parsing turn into ™

[13:24:08.0000] <annevk>
but using JavaScript's encodeURI and decodeURI you can go both ways

[13:27:21.0000] <dsheets>
annevk: you are correct. Take relative path components, then. Or your trademark example… I have the string "#™" and want to encode/decode this… the "#" is not handled how I would expect by encode/decode.

[13:29:16.0000] <dsheets>
a = document.createElement("a"); a.href = "../foo"; a.href now stringifies to the absolute URI with relative path components resolved

[13:30:15.0000] <annevk>
yeah

[13:30:23.0000] <annevk>
you can get a.pathname if you just want the path

[13:31:07.0000] <annevk>
there's actually only very little code points affected in the fragment part

[13:31:24.0000] <annevk>
only some whitespace code points are ignored, that's it

[13:31:32.0000] <dsheets>
annevk: I want the same components that I passed in, but now normalized.

[13:32:23.0000] <dsheets>
annevk: ">" in fragment? "]" in fragment?

[13:32:35.0000] <annevk>
dsheets: stays the same

[13:33:20.0000] <annevk>
dsheets: even U+0000 although maybe we should drop that just like U+000A

[13:33:22.0000] <annevk>
dunno

[13:33:48.0000] <dsheets>
annevk: why aren't they percent encoded in the normal form? NUL seems dangerous.

[13:33:58.0000] <annevk>
because browsers don't do that

[13:34:16.0000] <annevk>
and it's not really needed anyway, it doesn't go over the wire

[13:34:46.0000] <annevk>
(even over the wire it's not strictly needed and IE is known for sending raw utf-8 octets in some cases)

[13:35:36.0000] <dsheets>
annevk: uhh? how do you mean? are the percent-encoded forms equivalent to the literal forms?

[13:36:14.0000] <annevk>
well they're "considered" equivalent but they're not if you do e.g. string comparison

[13:36:17.0000] <annevk>
as many people do

[13:38:19.0000] <dsheets>
annevk: How do I access a comparison function that returns true for "]" and "%5d"?

[13:38:38.0000] <annevk>
there's no such thing

[13:39:22.0000] <dsheets>
why not? aren't they equivalent in URI space?

[13:39:46.0000] <dsheets>
a.href === b.href returns false

[13:39:51.0000] <annevk>
there's no URI in user agents

[13:40:12.0000] <dsheets>
"URLUtils"

[13:40:47.0000] <annevk>
yeah they'd not be equivalent and you'd get different requests to the server

[13:40:56.0000] <annevk>
one containing ] and one containing %5d

[13:41:06.0000] <annevk>
even %5d and %5D result in different requests

[13:41:20.0000] <annevk>
STD 66 allows for all that btw

[13:41:30.0000] <annevk>
they don't really place any requirements

[13:41:35.0000] <annevk>
which is why it's quite useless

[13:42:46.0000] <dsheets>
yes… so you will not perform any canonicalization or normalization? just parse+resolve and that's it?

[13:43:48.0000] <annevk>
well there's some

[13:44:03.0000] <annevk>
see e.g. the bits about percent encoded

[13:44:09.0000] <annevk>
how \ turns into / most of the time, etc.

[13:44:23.0000] <annevk>
how http://example.org: turns into http://example.org/ etc.

[13:44:35.0000] <annevk>
or http://example.org:80 becomes http://example.org/

[13:45:07.0000] <annevk>
at some point it will define how http://EXAMPLE/ becomes http://example/ (host names and IP addresses need some more research)

[13:45:12.0000] <annevk>
schemes are lowercased

[13:45:15.0000] <annevk>
there's a bunch of stuff

[13:45:29.0000] <annevk>
(when I think about it)

[13:45:32.0000] <annevk>
anyway, bedtime

[13:46:05.0000] <tantek>
/me compares http://url.spec.whatwg.org/ to the table in http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces and wonders if he will need to add another row.

[13:47:26.0000] <annevk>
ah damn it, hey tantek!

[13:47:38.0000] <annevk>
tantek: I saw that table and it's pretty awesome

[13:48:04.0000] <annevk>
tantek: if you have any particular opinion on terms to use it's much appreciated

[13:48:09.0000] <annevk>
tantek: I'm pretty flexible on that front

[13:48:22.0000] <annevk>
nn

[13:54:25.0000] <tantek>
annevk nn - I have no / little particular preference on terms - was more just dismayed at how much a supposedly "simple" thing was reinvented/renamed. We can discuss when you get back online tomorrow morning.

[14:20:44.0000] <rniwa>
annevk: yt?

[14:21:50.0000] <Hixie>
tantek: man, if that's not a testament to the URL spec being deficient, i dunno what is :-) nice table

[14:22:33.0000] <tantek>
Hixie, yeah, this is what happen when I try to re-use existing work and end up documenting a mess instead :(

[14:22:53.0000] <rniwa>
Who here knows WebIDL?

[14:23:00.0000] <zewt>
death to "search"

[14:23:11.0000] <tantek>
also, I have maybe 2 more frameworks/standards that use different terms for URL pieces that I have yet to add to the table

[14:23:18.0000] <TabAtkins>
rniwa: Several of us, at least kinda?

[14:23:28.0000] <zewt>
also to "fragment" :(

[14:24:06.0000] <rniwa>
TabAtkins: so... how do I write a callback interface where callbacks are optional?

[14:24:18.0000] <rniwa>
TabAtkins: for undo manager's DOMTransaction interface, all properties are optional.

[14:24:27.0000] <rniwa>
TabAtkins: including callback methods

[14:24:35.0000] <tantek>
zewt - which is your preferred set of terms for the pieces of a URL?

[14:24:46.0000] <TabAtkins>
You can make any property optional, including ones that take a callback.

[14:24:57.0000] <rniwa>
TabAtkins: what's the syntax for that?

[14:25:55.0000] <zewt>
intuitively, "query" and "hash" (those are the only really "contended" ones)

[14:25:56.0000] <tantek>
btw - when I add the 2 pending splits, that will make 14 different ways people have come up with for expressing the parts of URLs. The URL spec will then be the 15th, thus fulfilling the prophecy foretold in XKCD 927.

[14:26:43.0000] <tantek>
so are you a "scheme" guy or a "protocol" guy?

[14:26:46.0000] <TabAtkins>
rniwa: I'm confused - it's the same as any other optional thing.  When you define a callback, it just creates a new type that you can use elsewhere.

[14:26:54.0000] <TabAtkins>
tantek: I'm more of a "boobs" guy.

[14:27:05.0000] <zewt>
("host" vs. "hostname", "path" vs "pathname" are trivial differences; i'd have preferred protocol to scheme, but that one's long gone)

[14:27:24.0000] <zewt>
TabAtkins: try dieting and exercise

[14:28:04.0000] <zewt>
*crickets*

[14:29:14.0000] <zewt>
the "1996 HTTP RFC" row makes me :|

[14:29:49.0000] <TabAtkins>
Why?

[14:30:03.0000] <zewt>
because it's five rows, heh

[14:30:21.0000] <TabAtkins>
jQuery 2011 is 6. ^_^

[14:31:48.0000] <Hixie>
"scheme" is the http: part of a URL, "protocol" is what set of rules the scheme maps to (HTTP)

[14:31:52.0000] <zewt>
interesting that (if I'm reading this table correctly) in every case, the "search" name includes the ? and the "query" name does not

[14:31:59.0000] <zewt>
a pattern I hadn't noticed

[14:32:14.0000] <tantek>
/me sends TabAtkins to the inclusivity dungeon.

[14:32:42.0000] <TabAtkins>
tantek: Yeah, I know, bad on me. It was too obvious for me to pass up. :(

[14:32:43.0000] <tantek>
zewt - that is correct.

[14:33:32.0000] <zewt>
almost the same pattern for hash/fragment, with a couple misses

[14:33:49.0000] <tantek>
I built the table for exactly that reason, to see what patterns (if any) would be revealed.

[14:33:59.0000] <zewt>
(wouldn't necessarily say it's a *useful* distinction, but it's an interesting one)

[14:34:28.0000] <tantek>
yeah

[14:34:35.0000] <zewt>
(that is, the pattern--whether you include it or don't include it is certainly important from an API standpoint)

[14:37:00.0000] <zewt>
Hixie: sure, I just don't think the distinction is necessary in this context (but as far as naming goes this one's been decided--scheme it is!)

[14:37:01.0000] <Hixie>
othermaciej: yt?

[14:37:20.0000] <Hixie>
zewt: yeah i dunno if the distinction makes sense either.

[14:37:35.0000] <Hixie>
zewt: people often refer to the thing, and the identifier for the thing, by the same name

[14:37:40.0000] <othermaciej>
Hixie: yeah, but I have weinig here in my office so not totally paying attention to IRC

[14:38:23.0000] <Hixie>
othermaciej: k, just had a quick q RE: the bugs you want cloned back; do you want them reresolved also? Most of them are things I never actually resolved, just punted for a few months, and was planning on reopening (i'll be doing that in january for the whatwg ones)

[14:38:55.0000] <othermaciej>
Hixie: my preference would be to leave them with their prior resolution, even if it was LATER or REMIND

[14:39:14.0000] <Hixie>
othermaciej: roger

[14:42:42.0000] <tantek>
Hixie, zewt, re: scheme vs. protocol, the real question is, does "protocol" include the trailing ":" or not? For a good time, see this github thread discussion that very issue in Node.js: https://github.com/joyent/node/pull/1580

[14:42:52.0000] <tantek>
*discussing

[14:43:18.0000] <Hixie>
i'll let anne worry about that :-)

[14:52:23.0000] <dsheets>
Hixie: zewt gave you your use case for un-resolved refs

[14:53:15.0000] <Hixie>
dsheets: anne's the one who needs the use cases

[14:53:24.0000] <Hixie>
i'm just an interested observer

[14:53:38.0000] <Hixie>
zewt: btw, HFS+ supports directory hardlinks

[14:53:49.0000] <zewt>
Hixie: weird

[14:53:58.0000] <Hixie>
Time Machine uses it to good effect

[14:54:13.0000] <zewt>
anyway simply discarding hardlink loops seems sane (very rare, and rarer within user data since you need to be root to create them)

[14:54:14.0000] <Hixie>
you can treat each incremental backup as a full backup

[14:54:19.0000] <Hixie>
they just hardlink the common bits

[14:54:46.0000] <zewt>
(i'm assuming hard linked directories work like file hard links, eg. you can detect them by comparing inodes, but I haven't played with it)

[14:54:58.0000] <Hixie>
yeah i dunno either

[14:55:06.0000] <dsheets>
Hixie: you were interested enough to inquire about use cases previously going so far as to tell me to draft mail

[14:55:25.0000] <dsheets>
annevk: zewt gave you your use case for un-resolved refs

[14:55:28.0000] <zewt>
someone also said that OSX somehow prevents hard links from creating loops (no idea if true or how)

[14:55:49.0000] <zewt>
(i'm pretty sure I didn't, but feel free to be more specific :)

[14:56:02.0000] <Hixie>
dsheets: well presumably once anne gets to zewt's e-mail, he will make sure it's handled

[14:56:24.0000] <Hixie>
dsheets: i was interested in helping you get your use case explained so that anne could make sure it was handled

[14:56:49.0000] <zewt>
(the case you're probably thinking of is where I want to use the parser for queries for entirely unrelated things--portions of the hash--which isn't what you were talking about)

[14:57:31.0000] <dsheets>
zewt: it was one of the many things I was talking about

[14:58:45.0000] <dsheets>
zewt: using only the query part of the parser without a dummy base requires the ability to parse without resolving

[14:59:44.0000] <Hixie>
anne's asleep now so really if you want to affect the url spec your best bet is e-mail

[15:02:07.0000] <jamesr_>
othermaciej, with sandboxed local storage area systems in general, is there any way to share resources with multiple origins? maybe with CORS or something? use case is having multiple (say) image editing applications on different domains and wanting to edit the same image offline

[15:02:45.0000] <othermaciej>
jamesr_: hadn't thought about that as a use case

[15:03:05.0000] <othermaciej>
jamesr_: if the persistent URL for a file is loadable from any origin, then you could share that way, for reading

[15:03:20.0000] <othermaciej>
jamesr_: that would require the URL format to have an unguessable unique token for each file

[15:03:49.0000] <othermaciej>
jamesr_: I do not know what would be a reasonable approach to shared write access

[15:04:13.0000] <othermaciej>
jamesr_: I could imagine creating shareable storage areas (not per-origin) that have an unguessable unique token identifier which can be shared between webapps

[15:04:21.0000] <othermaciej>
jamesr_: that would be the "capabilities" approach to it

[15:04:27.0000] <jamesr_>
would that require explicit cooperation between the webapps?

[15:04:42.0000] <jamesr_>
or would a user have some way to say "give this guy access to that space" in some fashion? i.e. let gimp.org access my local pictures?

[15:05:07.0000] <othermaciej>
jamesr_: I could imagine shared storage areas as described having a way to grant access

[15:05:12.0000] <othermaciej>
jamesr_: I have to go to meetings

[15:05:19.0000] <othermaciej>
jamesr_: happy to follow up on this on public-webapps

[15:05:22.0000] <TabAtkins>
Clearly a use-case for Web Intents!

[15:05:26.0000] <jamesr_>
ok. i'm not very caught up on these discussions

[15:05:30.0000] <TabAtkins>
 /kidding

[15:05:44.0000] <othermaciej>
I do think the non-shared case can be handled with IndexedDB, from what I can tell currently

[15:05:53.0000] <othermaciej>
just give IndexedDB a way to vend persistent URLs to a keypath

[15:06:02.0000] <Hixie>
hmm

[15:06:05.0000] <othermaciej>
and if you want a more filesystem-like API, that can be layered on top

[15:06:12.0000] <Hixie>
i wonder if i should reorder the sections in the Sections section

[15:06:16.0000] <Hixie>
so that <section> comes after <aside>

[15:06:27.0000] <TabAtkins>
I say yes, purely because I liked that sentence.

[15:06:27.0000] <Hixie>
or maybe have it body, article, section, nav, aside

[15:06:51.0000] <Hixie>
heh

[15:07:04.0000] <TabAtkins>
Your second ordering seems nice.

[15:07:26.0000] <jamesr_>
you should put that in <maincontent>, right?

[15:07:44.0000] <Hixie>
that's <body>

[15:07:51.0000] <Hixie>
tantek: k, will do that one

[15:07:51.0000] <nessy>
you should put nav ahead of article - it's header-type content

[15:08:11.0000] <nessy>
/me should have slept in

[15:08:19.0000] <Hixie>
<header> is much later :-)

[15:08:19.0000] <TabAtkins>
nessy: I think the ordering he suggested was roughly in terms of decreasing inclusiveness.

[15:08:39.0000] <nessy>
fair enough

[15:16:31.0000] <JonathanNeal>
hello

[15:19:18.0000] <TabAtkins>
Yo, JN.

[15:58:35.0000] <JonathanNeal>
I dig this new DOM stuff making its way into Chrome.

[15:58:36.0000] <JonathanNeal>
Is anyone maintaining a repo for the polyfills?

[16:03:10.0000] <TabAtkins>
JonathanNeal: Dunno!

[16:03:29.0000] <TabAtkins>
Though a snarky answer would be "jQuery".

[16:03:34.0000] <zewt>
email formatting in mail from BRIAN is making my head hurt

[16:03:39.0000] <zewt>
er, BRYAN

[16:04:05.0000] <zewt>
(as someone with a more-often-misspelled-than-not name, i guess I should get at least that right)

[16:08:45.0000] <TabAtkins>
"and since the Invited Expert route didn't work out" is a good euphemism for "because we were asshats".

[16:10:23.0000] <gavinc>
Hey, where exactly can I learn more about the URL living standard and the use cases being considered?

[16:10:36.0000] <TabAtkins>
From annevk, when he's awake.

[16:10:47.0000] <TabAtkins>
Or from the standard itself, maybe?  I haven't read it yet.

[16:13:24.0000] <gavinc>
well, it seems to be claiming to want to replace RFC 3986 and RFC 3987... and doesn't seem to explain how relative urls work with their base very clearly yet

[16:13:36.0000] <Hixie>
yeah, it's a work in progress

[16:13:46.0000] <Hixie>
i expect it will eventually completely define everything those rfcs define

[16:13:52.0000] <Hixie>
(plus everything they're missing)

[16:15:30.0000] <gavinc>
... is starting over REALLY necessary?

[16:15:36.0000] <Hixie>
no

[16:15:40.0000] <Hixie>
not even slightly

[16:15:50.0000] <Hixie>
for years we have been asking for the ietf to fix their rfcs

[16:16:09.0000] <gavinc>
is there a list of the issues some where?

[16:16:28.0000] <Hixie>
the url specs don't define error handling

[16:16:32.0000] <Hixie>
that's the big one

[16:17:00.0000] <Hixie>
and what they do define doesn't match implementations (e.g. implementations handle javascript: URLs differently than http: URLs, but the RFCs don't really define them differently)

[16:17:37.0000] <gavinc>
and working with IETF...?

[16:17:40.0000] <gavinc>
'cause uh...

[16:17:43.0000] <zewt>
hahahahahahahahaha

[16:17:49.0000] <zewt>
sorry :)

[16:17:58.0000] <Hixie>
the IETF was, how you say, not receptive

[16:18:06.0000] <Hixie>
nor very responsive

[16:19:04.0000] <gavinc>
perhaps, but throwing out the whole of both RFCs seems a bit... extreme?

[16:22:38.0000] <zewt>
from the results i've seen so far of anne's work vs. the legacy specs he's replaced, and if he's willing to do the work, i think it's just fine

[16:23:32.0000] <Hixie>
gavinc: there's not really that much of value in the RFCs when you get right down to it, to be honest

[16:23:47.0000] <Hixie>
gavinc: so as zewt says, if anne is willing to do the work...

[16:23:57.0000] <Hixie>
gavinc: it's very similar to the new HTML spec vs HTML4

[16:24:10.0000] <gavinc>
Hixie: I've found Normalization and Comparison from 3987 rather reasonable

[16:25:28.0000] <Hixie>
gavinc: if there are specific use cases that you want to make sure anne takes into account, i recommend e-mailing him (or the list, or filing a bug)

[16:25:47.0000] <Hixie>
that section in particular seems to use a lot of words to not say that much :-)

[16:26:19.0000] <zewt>
Hixie: sounds like just about every pre-HTML5 spec ever written :)

[16:26:34.0000] <Hixie>
gavinc: i expect anne's canonicalisation algorithm will actually end up doing a way cleaner job of that section, actually

[16:26:41.0000] <Hixie>
gavinc: but we'll see

[16:27:54.0000] <gavinc>
zewt: being less dismissive of other peoples work would go a long way

[16:28:09.0000] <gavinc>
gavin: okay, as a work in progress it's reasonable

[16:28:21.0000] <gavinc>
got a bit lost just from total change of language

[16:28:30.0000] <zewt>
i'm dismissive of things that i believe should be dismissed

[16:28:49.0000] <gavinc>
it seems resolving relative urls, is now hierarchical

[16:29:04.0000] <gavinc>
and yes, I do in fact agree that the hierarchical section is a great deal easier to understand then the RFC

[16:29:19.0000] <zewt>
fyi <annevk> maybe I'll rename "hierarchical" to "relative"

[16:29:29.0000] <gavinc>
/me snorts

[16:29:31.0000] <gavinc>
heh

[16:29:34.0000] <gavinc>
yeah, that would do it

[16:30:04.0000] <zewt>
it's quite a freenode day

[16:32:17.0000] <TabAtkins>
zewt: Yeah, they're maintaining some of the servers that a lot of us connect through.

[16:35:14.0000] <Hixie>
man, coming up with examples is hard

[16:35:33.0000] <Hixie>
heycam: you following this Location thread on whatwg?

[16:35:36.0000] <heycam>
Hixie, I had not been, I'll take a look

[16:36:38.0000] <Hixie>
thanks

[16:58:29.0000] <Hixie>
any opinions on http://www.whatwg.org/specs/web-apps/current-work/#usage-summary-0 ?


2012-09-26
[17:00:34.0000] <TabAtkins>
The styling leave something to be desired, but seems okay.

[17:01:09.0000] <Hixie>
yeah, too many lines

[17:01:43.0000] <TabAtkins>
Yeah, and I think the yellow is too much.  Just bolding would probably be enough.

[17:01:54.0000] <TabAtkins>
Also: whoops, forgot to never ever open up the Inspector on the single-page spec.

[17:02:16.0000] <Hixie>
heh

[17:02:19.0000] <Hixie>
i make that mistake regularly

[17:02:23.0000] <Hixie>
in dev builds it's not too bad

[17:02:30.0000] <Hixie>
it just doesn't do anything useful until you've done it three or four times

[17:02:30.0000] <TabAtkins>
Yeah, plus my new machine helps out.

[17:02:33.0000] <TabAtkins>
Woo z620!

[17:02:59.0000] <Hixie>
i think i'll keep the yellow, for some of the other examples it's really necessary to have more than bold

[17:03:04.0000] <Hixie>
and it'd be weird to be inconsistent

[17:03:31.0000] <TabAtkins>
Could you slightly reduce the brightness, then?  I don't like bright yellow against off-white backgrounds.

[17:03:36.0000] <Hixie>
yeah, could do that

[17:03:43.0000] <Hixie>
paste a hex code?

[17:04:50.0000] <TabAtkins>
Maybe #e6e600?

[17:05:00.0000] <TabAtkins>
hsl(60, 100%, 45%)

[17:05:16.0000] <Hixie>
reload?

[17:05:44.0000] <TabAtkins>
Ah, better!

[17:05:56.0000] <TabAtkins>
It's an ugly color, but it doesn't strain my eyes.

[17:07:45.0000] <Hixie>
hah

[17:07:52.0000] <Hixie>
yikes that is ugly

[17:07:55.0000] <Hixie>
i'll poke at it some more :-P

[17:09:12.0000] <Hixie>
how about http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#usage-summary-0 ?

[17:09:21.0000] <Hixie>
too bright again?

[17:09:56.0000] <TabAtkins>
Yeah.  It's just something about a light, bright color against gray or near-gray that causes eye-strain for me.

[17:10:02.0000] <TabAtkins>
I think it's because I can't clearly make out the boundary.

[17:10:23.0000] <Hixie>
oh i guess the examples _are_ gray, aren't they

[17:10:27.0000] <Hixie>
they're so light that i forget

[17:10:31.0000] <Hixie>
hmm

[17:10:46.0000] <TabAtkins>
Not a huge fan of it against white either, but I'm used to that.

[17:12:50.0000] <Hixie>
how about it now

[17:19:15.0000] <Hixie>
also, can we please make the right hand side of attribute selectors accept unquoted numbers

[17:19:40.0000] <TabAtkins>
Sigh, I've messed that up so often.

[17:19:55.0000] <Hixie>
glad it's not just me

[17:20:02.0000] <TabAtkins>
The colors are great, thanks.

[17:20:08.0000] <Hixie>
cool

[17:20:12.0000] <Hixie>
(every time, i spend minutes trying to work out what's wrong)

[17:20:30.0000] <Hixie>
reload for an attempt at cleaning up at least some of those lines

[17:20:35.0000] <Hixie>
wait

[17:20:38.0000] <Hixie>
not done yet

[17:20:41.0000] <TabAtkins>
Problem with accepting numbers, of course, is that it's not exact.  <foo x=05> won't match foo[x=05]

[17:20:42.0000] <Hixie>
/me twiddles thumbs

[17:20:54.0000] <Hixie>
yeah, maybe if it's numbers = should do a numeric comparison

[17:21:02.0000] <Hixie>
i proposed <= >= < > and so on years ago

[17:21:10.0000] <Hixie>
[rowspan>5]

[17:21:17.0000] <TabAtkins>
Makes sense to me.

[17:21:17.0000] <Hixie>
ok reload now

[17:21:31.0000] <Hixie>
http://www.whatwg.org/specs/web-apps/current-work/#usage-summary-0

[17:21:38.0000] <TabAtkins>
Yeah, better.

[17:21:48.0000] <Hixie>
cool.

[17:21:49.0000] <Hixie>
ok

[17:21:50.0000] <Hixie>
well

[17:22:11.0000] <Hixie>
that was an entire afternoon spent on one editorial bug that asked for something slightly different than what i provided, so clearly my time was well spent here

[17:22:18.0000] <Hixie>
home!

[17:22:21.0000] <Hixie>
bbl

[19:53:12.0000] <Hixie>
cabanier: canvas has always used web idl, ever since, in fact since before, web idl existed...

[19:53:24.0000] <Hixie>
cabanier: (as has the rest of HTML, since it's just one spec really)

[19:54:35.0000] <cabanier>
hixie: I agree

[19:54:59.0000] <Hixie>
what i just says contradicts what you said in http://www.w3.org/mid/83F37C1A4497B54589EAEDC750D03A9473B4B551⊙ncac

[19:55:00.0000] <cabanier>
hixie: I just didn't see any bug on the recent changes

[19:55:31.0000] <cabanier>
hixie: oops

[19:55:36.0000] <Hixie>
:-)

[19:55:58.0000] <cabanier>
hixie: yeah. the spec always referred to webIDL

[19:56:24.0000] <cabanier>
hixie: I should have proofread that email

[20:00:19.0000] <cabanier>
hixie: If that is so, were there bugs logged on WebIDL or did you just fix the interface?

[20:00:36.0000] <Hixie>
how do you mean?

[20:01:06.0000] <cabanier>
the old interface didn't match the behavior so you fixed it so it does.

[20:01:14.0000] <cabanier>
was that in response to a bug report?

[20:01:30.0000] <cabanier>
It's not in the change log...

[20:01:36.0000] <Hixie>
either a bug report, an e-mail, me seeing it while going through the spec proofreading, or any number of other things

[20:01:42.0000] <cabanier>
:-)

[20:01:43.0000] <Hixie>
which revision in particular are you talking about?

[20:02:03.0000] <cabanier>
http://svn.whatwg.org/webapps@7129 340c8d12-0b0e-0410-8428-c7bf67bfef74

[20:02:47.0000] <Hixie>
oh ages ago

[20:02:52.0000] <cabanier>
June 11: [giow] (2) Update to take into account WebIDL's 'double' vs 'unrestricted double' change.

[20:03:12.0000] <Hixie>
probably just did that because i saw an e-mail go by about the changes to webidl

[20:05:11.0000] <cabanier>
OK. I sent out a correction.

[20:05:58.0000] <cabanier>
thanks for letting me know!

[20:06:08.0000] <Hixie>
no worries, just got confused :-)

[20:14:47.0000] <SamB_MacG5>
/me wonders why the CSSWG can't manage to style their ToC links like links

[20:15:46.0000] <Hixie>
i imagine they don't want to

[20:16:37.0000] <SamB_MacG5>
is it spite?

[20:16:43.0000] <Hixie>
unlikely

[20:16:54.0000] <Hixie>
probably just a different sense of aesthetics

[20:17:14.0000] <SamB_MacG5>
/me continues to believe it is done to confuse him

[20:18:14.0000] <SamB_MacG5>
/me sorta wishes there was a way to specify userstyle based on what stylesheets a document used ...

[20:20:21.0000] <SamB_MacG5>
/me would make one to override http://dev.w3.org/csswg/default.css

[20:49:01.0000] <Hixie>
jgraham: dude, you need to indent your test cases. :-P  (e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1562 )

[23:36:32.0000] <zcorpan>
TabAtkins: apparently ed isn't on board, at least

[23:51:14.0000] <annevk>
oh lol, whether the ? or # is included matters for the terminology?

[23:51:32.0000] <hsivonen>
annevk: thanks. email sent to www-style about window.screen

[00:12:42.0000] <zcorpan>
annevk: why call it .isInvalid rather than simply .valid or .invalid (depending on which case is more likely to check for truthness in an if statement)?

[00:13:16.0000] <annevk>
But Klaasen, the Dutch national coordinator for counterterrorism and security: "Why can’t I trust people?"

[00:13:17.0000] <annevk>
hahahaha

[00:13:28.0000] <zcorpan>
(i'd think .valid since it seems more useful to do stuff with a valid url than with an invalid one)

[00:13:28.0000] <annevk>
-- http://arstechnica.com/tech-policy/2012/09/proposed-eu-plan-to-stop-terrorist-sites-even-more-ridiculous-than-thought/

[00:14:07.0000] <annevk>
mkay

[00:14:14.0000] <annevk>
looks like ValidityState has that too

[00:14:52.0000] <zcorpan>
ah yeah

[00:15:24.0000] <annevk>
zcorpan: you have the same nick on github?

[00:15:31.0000] <zcorpan>
yes

[00:18:06.0000] <annevk>
zewt: I think I'm going to leave relative URLs to libraries for now (in the manner you proposed on the list)

[00:18:30.0000] <annevk>
zewt: afaict there's no native code in browsers for those things at the moment

[00:33:21.0000] <annevk>
tantek: basically, I considered aligning the terminology with the API, but kept them different for now since a) names as scheme/query/fragment are quite widespread and understood (I think) and b) it makes it somewhat clearer there's an API on top of some internal concepts

[00:34:29.0000] <annevk>
tantek: this is in particular true for "scheme", which is the name exclusively used when defining new types of URLs

[00:42:26.0000] <zcorpan>
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html looks like an excellent example of how we want people to go about proposing a new feature

[00:45:03.0000] <zcorpan>
(asking people to come up with a solution and detailed processing model as in http://blog.whatwg.org/proposing-features has proven to be unhelpful for the forums since it makes people focus on a particular solution instead of focusing on use cases and requirements)

[00:50:06.0000] <annevk>
write an updated blog post ;)

[00:50:28.0000] <annevk>
and maybe update the FAQ

[00:54:01.0000] <zcorpan>
i edited http://forums.whatwg.org/bb3/viewtopic.php?f=3&t=41&p=159

[00:54:38.0000] <zcorpan>
but maybe the faq should say that directly and the forums post just point to the faq

[00:55:50.0000] <zcorpan>
for the faq, the step discussing with implementors i think puts people off and isn't really a requirement

[00:55:57.0000] <zcorpan>
i mean, not as a first step

[00:56:53.0000] <zcorpan>
i think step one should be "forget about your solution" :-P

[00:58:43.0000] <annevk>
yeah, I think you're right

[00:58:54.0000] <annevk>
the people typically directed to these things just need to know it's about "use cases"

[01:51:23.0000] <zcorpan>
i edited http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F to what i think works better in practice

[02:25:35.0000] <zcorpan>
Hixie: with the frameset change, don't you need to apply display:block on the frameset element?

[03:05:20.0000] <jgraham>
http://www.cs.washington.edu/research/constraints/web/ccss-uwtr.pdf is mildly interesting is something of a historical curio at this point

[03:05:27.0000] <jgraham>
*if something

[03:25:13.0000] <zcorpan>
hmm, document.all is undefined in standards mode in webkit now?

[04:37:49.0000] <zcorpan>
will "why can't i trust people" be the next meme?

[07:04:46.0000] <zcorpan>
[tm]: you know the status of the publishing in html wg?

[07:07:46.0000] <SamB_MacG5>
zcorpan: how are you checking for document.all ?

[07:08:12.0000] <SamB_MacG5>
you know that it's specified to pretend to be undefined, right?

[07:08:52.0000] <jgraham>
zcorpan: I heard that [tm] is unavaliable

[07:09:03.0000] <jgraham>
Maybe ask plh

[07:10:22.0000] <zcorpan>
SamB_MacG5: yeah i know. i got an exception when using it and removing the doctype made it work, but now when i test again it works in standards mode. dunno what happened last time

[07:11:25.0000] <SamB_MacG5>
typo or something?

[07:11:30.0000] <zcorpan>
SamB_MacG5: the test i had was http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1801

[07:11:56.0000] <Ms2ger>
zcorpan, throws in Gecko, as expected

[07:11:59.0000] <zcorpan>
(it saying 'undefined' in the log means document.all is available; it saying an exception was thrown means it wasn't)

[07:12:13.0000] <zcorpan>
(opera returns the param)

[07:12:16.0000] <SamB_MacG5>
ah

[07:12:52.0000] <zcorpan>
maybe i looked at firefox and thought i was looking at chrome? dunno :-)

[07:13:04.0000] <SamB_MacG5>
yeah, that's throwing in TenFourFox for me as well

[07:13:56.0000] <zcorpan>
browsers look much the same these days

[07:16:55.0000] <SamB_MacG5>
/me is a *bit* surprised that Gecko conditionalizes document.all on standards mode

[07:17:10.0000] <Ms2ger>
It's terrible, terrible code

[07:17:45.0000] <SamB_MacG5>
what does this "rendering mode: CSS1Compat" part mean?

[07:18:02.0000] <Ms2ger>
No quirks/limited quirks mode

[07:18:14.0000] <Ms2ger>
Also known as standards/almost standards

[07:18:38.0000] <zcorpan>
SamB_MacG5: http://dom.spec.whatwg.org/#dom-document-compatmode

[07:19:08.0000] <zcorpan>
Ms2ger: any change you're gonna make document.all available in standards mode? :-)

[07:19:17.0000] <Ms2ger>
No :)

[07:19:42.0000] <SamB_MacG5>
/me sees it in both Safari (WebKit 534.49.0) and TenFourFox 15

[07:20:22.0000] <Ms2ger>
zcorpan, we are planning to make doc.all emulate undefined rather than the mess we have now, though

[07:20:30.0000] <SamB_MacG5>
/me wonders how you're *supposed* to find out what version of WebKit Safari is using

[07:20:48.0000] <zcorpan>
Ms2ger: what does that mean?

[07:21:05.0000] <jgraham>
SamB_MacG5: Never, ever ask about how document.all works in Gecko. Trust me on this.

[07:21:35.0000] <SamB_MacG5>
okay

[07:22:05.0000] <Ms2ger>
jgraham, indeed so :)

[07:22:13.0000] <jgraham>
It's not so much "here be dragons" as "here be dragons guarding a minefield around a black hole"

[07:24:08.0000] <Ms2ger>
Try http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1803 for example

[07:26:14.0000] <zcorpan>
jgraham: ok, i'll email plh

[07:54:52.0000] <jgraham>
Hixie: Browsers need to work out that I am editing mixed javascript/html and give me a keybinding that indents nicely, like tab in emacs (except that doesn't work so well in mixed documents)

[08:55:44.0000] <Ms2ger>
krijnh, still not updating

[08:56:12.0000] <odinho>
/me pats his ~/irclogs folder

[09:05:50.0000] <Ms2ger>
zewt++

[09:48:57.0000] <Hixie>
zcorpan_: thanks for updating the faq, that's way better

[09:49:10.0000] <zcorpan_>
Hixie: cool, thanks

[09:49:31.0000] <Hixie>
zcorpan_: i might change it to say that you can stop after sending the use cases to the list, since at that point if the use cases are good it'll get added regardless, and if they're bad it doesn't matter how good the solutions are

[09:49:48.0000] <Hixie>
zcorpan_: and some people get attached to their solutions and get upset when others are picked

[09:50:04.0000] <zcorpan_>
Hixie: yeah i considered the same thing

[09:50:46.0000] <Hixie>
see also the bottom section of http://wiki.whatwg.org/wiki/What_you_can_do

[12:44:10.0000] <Hixie>
abarth: do you know what https://bugs.webkit.org/show_bug.cgi?id=85778 was about and whether i resolved it?

[12:44:31.0000] <Hixie>
abarth: i don't see e-mail pending on the topic

[13:05:36.0000] <krijnh>
Ms2ger: sorry, missed a line :/ Should be fixed now and auto-update again

[13:05:46.0000] <abarth>
Hixie: we had a thread about it on whatwg

[13:05:47.0000] <Ms2ger>
Yay :)

[13:05:58.0000] <abarth>
Hixie: i think we decided to put the requirement in the CSP spec rather than the HTML spec

[13:07:06.0000] <abarth>
Hixie: May 7

[13:07:21.0000] <abarth>
Subject: <iframe srcdoc> and Content-Security-Policy

[13:07:50.0000] <abarth>
on june 22 you said "Fair enough. I think this belongs in the CSP spec, though."

[13:28:26.0000] <SamB_MacG5>
/me wonders wtf happened to the "media" tab in tenfourfox's "Page Info" window

[13:28:51.0000] <SamB_MacG5>
/me thinks maybe tenfourfox needs a restart or something ...

[14:16:33.0000] <Hixie>
abarth: k, so i don't have to do anything here?

[14:16:40.0000] <abarth>
correct

[14:16:50.0000] <Hixie>
excellent

[15:54:30.0000] <zewt>
why am I being postincremented

[15:54:45.0000] <zewt>
do I look like an lvalue

[15:58:44.0000] <TabAtkins>
...yes?

[16:01:59.0000] <zewt>
Hixie: you must know that nothing will stop programmers from offering solutions to problems; it's sort of in our nature :)

[16:02:24.0000] <Hixie>
and nothing will force me to pay attention to them :-P

[16:02:38.0000] <Hixie>
(at least not until the problem has been established)

[16:52:47.0000] <annevk>
what's the deal with using @w3c.org? my filters use @w3.org :/


2012-09-27
[17:00:54.0000] <TabAtkins>
What mail is coming from w3c.org?

[17:01:43.0000] <annevk>
public-webapps email

[17:02:40.0000] <annevk>
nn

[17:18:17.0000] <tiglionabbit>
how can you tell the difference between a user dragging a file or a folder into the browser?

[17:18:43.0000] <tiglionabbit>
in either case,  event.dataTransfer.items[0].kind == "file"

[18:11:52.0000] <jamesr>
oh wise wizards, consider this test: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1805

[18:12:48.0000] <jamesr>
i can write a selector to match the span with id ":foo" by \ escaping, but querySelector("#\:foo") barfs in firefox/chrome/opera. TabAtkins thinks this is just a bug in querySelector which i tend to agree with but does anyone know of a good reason for the current behavior before i file a batch o' bugs?

[18:13:04.0000] <jamesr>
i get really suspicious when i see a seemingly bizarre behavior that has good interop

[18:13:10.0000] <TabAtkins>
I'll support myself and say that, no, there's no reason, and it's definitely a bug.

[18:14:06.0000] <TabAtkins>
Note that this interop is probably on something very bad for authors, since it's an exception rather than being silently ignored, and there's no way around it. (Omitting the escaping slash has the same effect.)

[18:14:49.0000] <jamesr>
even ie9 throws here

[18:14:53.0000] <TabAtkins>
Jeez, it even fails when you do "#\3a foo".

[18:15:01.0000] <jamesr>
yeah it's damn picky

[18:15:12.0000] <jamesr>
is http://www.w3.org/TR/css3-selectors/#grammar supposed to be up to date?

[18:15:15.0000] <TabAtkins>
I'm guessing there's an eager unescaping phase that runs before the syntax checker.

[18:15:17.0000] <jamesr>
it's on /TR/ so i suspect no

[18:15:30.0000] <TabAtkins>
Probably, yes.  Worst case, check Selectors 4.

[18:27:07.0000] <Hixie>
jamesr: querySelector("#\:foo") is exactly equivalent to querySelector("#:foo")

[18:27:10.0000] <TabAtkins>
jamesr: There is no grammar-based reason.  The escaping thing is part of CSS/Selectors, and I recall there being an example of using a weird character in a selector somewhere, either in 2.1 or in Selectors.

[18:27:15.0000] <Hixie>
jamesr: try querySelector("#\\:foo")

[18:27:30.0000] <TabAtkins>
Sigh, I forgot about that.  Goddam double escaping.

[18:27:39.0000] <jamesr>
aha!

[18:28:07.0000] <TabAtkins>
/me has memories of \\ in a PHP string to escape \ in a PHP regex to select a .

[18:28:18.0000] <zewt>
has any (real) language besides python attempted to solve that? heh

[18:28:30.0000] <TabAtkins>
You mean with Python's raw strings?

[18:28:40.0000] <jamesr>
writing code to deal with windows paths in any c-style language is fun

[18:28:52.0000] <zewt>
jamesr: it's easy. "c:/foo/bar"

[18:29:00.0000] <Hixie>
matching urls with regexps is fun for a similar reason -- /.../

[18:29:08.0000] <TabAtkins>
Most path apis accept either direction of slashes, no?

[18:29:26.0000] <jamesr>
yes, most. :)

[18:29:29.0000] <TabAtkins>
Hixie: Most decent languages (not JS ;_;) let you use different delimiters for the regex.

[18:29:36.0000] <zewt>
Hixie: that's why most things ... ^ that

[18:29:56.0000] <jamesr>
sed -e 's?check/this/out?arbitrary/delimiters/baby?'

[18:33:52.0000] <Hixie>
yeah, i usually am using perl so it's no biggie once i realise the pattern is gonna contain a path/url

[18:34:06.0000] <Hixie>
but i often don't notice until after the first set of syntax errors :-)

[23:20:27.0000] <zcorpan>
LOOOOOOOOOOOOOL https://www.w3.org/Bugs/Public/show_bug.cgi?id=19087

[23:23:31.0000] <Hixie>
aw man

[23:23:44.0000] <Hixie>
i'd better check with ben goodger to see if he agrees that it's offensive

[23:23:48.0000] <Hixie>
the word appears 12 times in the spec!

[23:24:41.0000] <Hixie>
/me ponders just reassigning it to the htmlwg :-P

[23:26:38.0000] <jgraham>
Oh look, W3C are hiring someone to work on tests

[23:26:54.0000] <jgraham>
Or testing, I guess

[23:27:26.0000] <jgraham>
Seems like a nice idea, but the requirment for fluent japanese cuts down the potential candidates by a lot :)

[23:28:09.0000] <jgraham>
(I wonder if it is one of those things where they already know who they want for the job and have written the advert to match)

[23:33:31.0000] <heycam>
I think it's more likely that they need to hire someone through Keio for whatever reason

[23:35:04.0000] <heycam>
I've never heard of a NZer being offended by the term kiwi before

[23:45:38.0000] <doublec>
I guess it depends if the term kiwi refers to be peeled and eaten

[23:57:06.0000] <jgraham>
doublec: You are saying that "I'm going to eat you like a kiwi, kiwi" is offensive, but "I'm going to eat you like a kiwi-fruit, kiwi" isn't? :p

[23:58:42.0000] <jgraham>
(or am I misunderstanding the bug? AFAICT it doesn't claim that New Zealanders are offended by "kiwi", except when it is used to denote a fruit)

[23:59:12.0000] <jgraham>
(which I agree doesn't make any sense)

[00:02:58.0000] <doublec>
I'm not offended but I assume the bug reporter didn't like the "peel the kiwi's skin, then eat the kiwi's flesh"

[00:30:09.0000] <othermaciej>
my favorite part is how an Australian is reporting that New Zealanders may be offended by the term "Kiwi"

[00:36:44.0000] <mpt>
As a kiwi, I'm not offended when people talk about eating kiwis, I just hope this age of cannibalism will one day come to an end.

[00:39:42.0000] <hsivonen>
at least the tag cloud example has context that suggests fruit rather than bird or people

[00:40:54.0000] <mpt>
Aww, tag clouds, how very oughties

[00:40:55.0000] <zcorpan>
"we will encourage modularity as a preferred way to approach introducing new features into the 5.1 release."

[00:41:19.0000] <Ms2ger>
Was the TAG involved?

[00:48:17.0000] <annevk>
no man, modularity is Team-speak for small specs

[00:48:33.0000] <annevk>
small specs with holes inbetween

[00:49:59.0000] <annevk>
I have oft wondered where that modular desire comes from. No young people talk about that stuff

[00:50:47.0000] <Ms2ger>
Should get to rec faster

[00:51:00.0000] <annevk>
Microsoft Program Managers?

[00:51:02.0000] <zcorpan>
gotta let each feature mature at its own pace and have its own community around it (i.e. 4 new mailing lists)

[00:51:30.0000] <annevk>
maybe the funding is per mailing list

[00:51:46.0000] <zcorpan>
that might explain things

[01:42:21.0000] <annevk>
hehe, I think I'm about to own wtw.tf

[01:51:16.0000] <jgraham>
/me wonders what a wt is

[02:31:43.0000] <annevk>
jgraham: I'm helping out dino

[02:31:44.0000] <annevk>
https://twitter.com/grorg/status/156849367448428545

[02:37:59.0000] <hsivonen>
since when has Opera not escaped < and > in attribute values in the innerHTML getter?

[02:45:34.0000] <zcorpan>
hsivonen: about since http://html5.org/tools/web-apps-tracker?from=2362&to=2363

[02:46:13.0000] <annevk>
nice URL there

[02:48:56.0000] <zcorpan>
hsivonen: iirc that page does something unusually stupid like eval()ing the innerHTML of an <a href=javascript:...> or some such, which didn't work when we escaped <> (and nobody else escaped them *for href=javascript:*)

[02:49:32.0000] <hsivonen>
zcorpan: we have a bug about the UI for a dark-matter Cisco appliance breaking because we stopped escaping <>

[02:49:51.0000] <hsivonen>
I gather it tries to parse innerHTML output as XML

[02:50:08.0000] <zcorpan>
hsivonen: ok. i guess we're screwed either way :-(

[02:50:21.0000] <hsivonen>
Don’t worry, your network is safe with Cisco.

[02:57:01.0000] <hsivonen>
by quick black-box testing, it seems the WebKit special case applies if the attribute reflects as URL and the URL has the scheme javascript

[03:05:45.0000] <zcorpan>
yeah i recall something along those lines as well. old gecko something similar.

[03:06:38.0000] <annevk>
I wonder who's going to edit XHR for the W3C

[03:08:44.0000] <zcorpan>
hsivonen: which attribute does cisco use here?

[03:18:12.0000] <hsivonen>
zcorpan: DOMParser barfs on <operator name="<" value="LESS_THAN"></operator>

[03:18:43.0000] <hsivonen>
this would be a non-issue if DOMParser did XML5

[03:21:20.0000] <hsivonen>
they have a massive “XML” island inside <xml>…</xml>

[03:21:35.0000] <zcorpan>
ok and the other page expected not-escaping for <a href=javascript:> (iirc)

[03:24:35.0000] <jgraham>
hsivonen: OOI, what are your travel plans for TPAC?

[03:29:31.0000] <hsivonen>
jgraham: plane from Helsinki to CDG, TGV from CDG to Lyon Part-Dieu

[03:30:04.0000] <hsivonen>
arrival on Sunday, leaving on Saturday

[03:30:13.0000] <jgraham>
OK

[03:30:58.0000] <jgraham>
/me is doing Test The Web Forward in Paris on the Friday/Saturday and so will also travel by train on the Sunday

[03:31:24.0000] <hsivonen>
this Cisco thing seems to expect there are three browsers: IE, Firefox and Safari

[03:31:37.0000] <smaug____>
/me will be in Lyon also Sun-Sat

[03:31:48.0000] <smaug____>
hsivonen: fun

[03:32:02.0000] <smaug____>
hsivonen: thanks for looking the issue

[03:32:18.0000] <hsivonen>
smaug____: now we need to decide what to do about it

[03:32:22.0000] <hsivonen>
which is harder

[03:32:28.0000] <jgraham>
Someone should do a list like http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ but for web browsers

[03:32:31.0000] <annevk>
jgraham: how much is the train?

[03:32:41.0000] <annevk>
I guess I could fly into Paris and then fly back from Lyon

[03:32:56.0000] <jgraham>
annevk: That probably depends, it's the last bit that I haven't booked

[03:33:09.0000] <hsivonen>
annevk: depends on time of day

[03:33:09.0000] <jgraham>
Seems to be somewhere in the range of 35-60 eur

[03:33:13.0000] <darobin>
the train can be relatively cheap if you book it ahead

[03:33:26.0000] <annevk>
ah okay

[03:33:40.0000] <darobin>
it's 2h — prolly shorter than flying to Lyon

[03:33:53.0000] <darobin>
(all told)

[03:34:07.0000] <hsivonen>
also, Lyon Part-Dieu has the airport code XYD

[03:34:20.0000] <smaug____>
hsivonen: I hate special cases

[03:34:23.0000] <hsivonen>
for plane-train bundle tickets

[03:34:28.0000] <smaug____>
hsivonen: so I like the current behavior

[03:34:37.0000] <hsivonen>
but I didn’t know that when I booked

[03:34:42.0000] <darobin>
hsivonen: you mean Lyon Saint-Exupéry — Part-Dieu is the train station

[03:34:44.0000] <darobin>
/me bbiab

[03:34:47.0000] <hsivonen>
smaug____: I like the current behavior, too

[03:34:57.0000] <hsivonen>
darobin: the airport is LYS

[03:35:57.0000] <hsivonen>
darobin: that magic code is for use for CDG–XYD train when bought through Air France ticketing

[03:35:58.0000] <SimonSapin>
Paris-Lyon by plane, you would spend as much time in the airports than in the air. The TGV train is 2h but you just have to get there a few minutes before.

[03:36:43.0000] <hsivonen>
also, TGV from CDG is cheaper than taxi from Saint-Exupéry to city center

[03:36:58.0000] <annevk>
"People’s names are all mapped in Unicode code points." is interesting

[03:37:08.0000] <annevk>
(that statement is false per the link from jgraham, fwiw)

[03:37:34.0000] <hsivonen>
annevk: cruel parents in this day and age, IMO, in that case

[03:37:39.0000] <smaug____>
silly me, I have flight from Paris to Lyon. Didn't know the train would be that much better.

[03:38:02.0000] <SimonSapin>
annevk: does that mean that Unicode needs more characters?

[03:38:54.0000] <hsivonen>
SimonSapin: no. Then parents who want to be special would invent something new that’s unique on not in Unicode

[03:38:56.0000] <annevk>
I don't know what it means

[03:39:42.0000] <hsivonen>
I’m pretty sure it means Han/Kanji names that are deliberately an unconventional combination of quill strokes to be unique

[03:39:51.0000] <annevk>
probably that the world is odd and full of unknown things, lots of which is created by us

[03:40:02.0000] <smaug____>
hsivonen: I wonder which all attributes webkit escapes

[03:40:45.0000] <jgraham>
Also consider the artist sometimes known as prince

[03:54:39.0000] <darobin>
hsivonen: ah, of course — I obviously never go through AF to get a train ride here :)

[03:55:40.0000] <darobin>
smaug____: if you're already on a flight and just connecting through Paris, then doing the last leg on a flight is okay

[03:56:00.0000] <darobin>
it's mostly shorter if you're in Paris, since the train is centre to centre

[03:56:41.0000] <hsivonen>
darobin: properly ticketed train is CDG to Lyon center

[03:57:08.0000] <darobin>
hsivonen: I know, but in that case I doubt it comes out shorter than flying to SaintEx (or by much of a diff)

[03:57:48.0000] <hsivonen>
shorter might not be the only thing to optimize

[03:59:32.0000] <hsivonen>
/me traveled from Finland to Switzerland and back without flying this summer

[03:59:34.0000] <darobin>
having gone from Grenoble to Å on a train, I can't easily disagree

[04:00:14.0000] <hsivonen>
the only part that was worse than a plane was Baltic buses from the worse company

[04:00:28.0000] <hsivonen>
(Baltic buses from the better company were better than plane)

[04:00:51.0000] <darobin>
heh

[04:01:30.0000] <darobin>
in my case we had a problem with the two boats that did the last leg having rammed one another in the port, and so being routed through another boat that went to the north of the Lofoten

[04:01:47.0000] <darobin>
which in turn went through a massive storm during fish migration period

[04:01:49.0000] <hsivonen>
Better company: http://www.luxexpress.eu/en Worse company: http://ecolines.net/en/

[04:02:05.0000] <darobin>
fish migration means that you can use sonar, which can be problematic when there are reefs

[04:02:19.0000] <darobin>
so the boat had to make way using spotlights — it took a while

[04:02:35.0000] <darobin>
I thoroughly enjoyed it though — but I think other passengers would've preferred to fly ;)

[04:06:55.0000] <annevk>
hmm, maybe I should finally add chunked to XHR

[04:07:24.0000] <annevk>
either that or work on that query API

[04:11:58.0000] <zcorpan>
hsivonen: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1807

[04:13:59.0000] <zcorpan>
smaug____: ^

[04:17:26.0000] <zcorpan>
maybe only a few of those need to be supported, since javascript: doesn't work in most places anyway (at least in opera)

[04:17:37.0000] <hsivonen>
zcorpan: supports my hypothesis of what the rule is

[04:17:56.0000] <hsivonen>
zcorpan: thanks

[04:17:57.0000] <zcorpan>
hsivonen: except <html manifest> doesn't have a reflecting IDL attribute

[04:18:05.0000] <hsivonen>
oh

[04:19:27.0000] <zcorpan>
well... per spec... webkit has one

[04:20:30.0000] <zcorpan>
that reflects as a URL

[04:22:04.0000] <annevk>
why did they add one? :/

[04:22:47.0000] <annevk>
hmm

[04:24:26.0000] <zcorpan>
i think innerHTML should use a fixed list instead of hooking in to "reflecting"... like: a href, iframe src, form action, frame src

[04:24:58.0000] <zcorpan>
or just a href if that's enough for compat

[04:26:25.0000] <zcorpan>
unfortunately this issue is hard to get compat data on

[04:30:31.0000] <smaug____>
I think innerHTML shouldn't escape

[04:30:41.0000] <smaug____>
if IE doesn't escape

[04:31:41.0000] <zcorpan>
if you evang Cisco, WFM :-)

[04:52:05.0000] <AryehGregor>
And everyone with outdated Cisco firmware, too?

[06:19:04.0000] <annevk>
seems nobody ever replied to other browsers being interested in chunked

[06:29:49.0000] <annevk>
btw

[06:29:58.0000] <annevk>
I don't like "Creating" for URLs at all

[06:30:17.0000] <annevk>
I want "Parsing"; what do I call what is named "parse" now?

[06:30:32.0000] <annevk>
the sweet generic "process"?

[07:03:54.0000] <zewt>
"Sorry but it is not late. The spec is still a working draft" ... heh

[07:13:13.0000] <zewt>
annevk: should the "remove any leading and trailing..." step be in create or parse? currently it seems like url = new URL(" http://foo.com "); may have a different result than url.href = " http://foo.com ";

[07:13:55.0000] <annevk>
I think it should be added to setting .href too

[07:13:56.0000] <zewt>
annevk: also the URL ctor doesn't define the case where base is a DOMString rather than a URL

[07:14:15.0000] <zewt>
in what case wouldn't you want it in parse?

[07:14:21.0000] <annevk>
setting pathname

[07:14:42.0000] <annevk>
zewt: I thought it did define that

[07:15:19.0000] <zewt>
it's probably somewhere else

[07:15:34.0000] <zewt>
oh yeah creating only deals with URL base so I imagine that's wherever the actual ctor is defined

[07:18:47.0000] <annevk>
I'll fix setting .href and rename Create to Parse and Parse to Process

[07:20:07.0000] <zewt>
annevk: btw. in encoding's "Unless stated otherwise emitting an encoder error", that might want to say something like "unless stated otherwise by the caller"; i interpreted that as "unless stated otherwise in the place that says emit an encoder error"

[07:20:10.0000] <zcorpan>
won't that result in more Process discussions?

[07:20:45.0000] <annevk>
zcorpan: what?

[07:21:04.0000] <zewt>
i think that was a joke :)

[07:21:16.0000] <annevk>
oh :)

[07:21:28.0000] <annevk>
/me is looking at http://en.wikipedia.org/wiki/Parser for a better word

[07:22:10.0000] <zewt>
(it would be nice for things that affect algorithm flow to be a part of the algorithm, instead of redefining things like "emit an encoder algorithm" externally, so the code paths of the spec are self-contained when possible)

[07:22:14.0000] <annevk>
maybe "interpret"?

[07:22:45.0000] <zewt>
annevk: it doesn't look like you'd ever (or very rarely) want to invoke the "parse" url algorithm from outside of the spec (you'd only use create), so that doesn't necessarily need to be short and sweet

[07:23:20.0000] <zewt>
eg. "update the URL state from the string..." or whatever

[07:23:41.0000] <zewt>
off to work, later

[07:24:11.0000] <annevk>
hmm, not sure if longer makes it better, but feel free to do a pull request :)

[11:21:17.0000] <Yuhong>
On legacy color parsing: https://news.ycombinator.com/item?id=4581362

[11:21:25.0000] <Yuhong>
http://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color

[11:22:52.0000] <annevk>
even on stackoverflow and ycombinator people don't bother to read the spec

[11:23:15.0000] <miketaylr>
s/even/especially/

[14:26:17.0000] <krijn>
annevk: y u no in #fronteers ? ;(

[15:42:28.0000] <Hixie>
anyone know if there's an animated gif spec, or something that passes for such a spec, anywhere?

[15:50:49.0000] <Hixie>
is http://www.ietf.org/rfc/rfc2818.txt the HTTPS spec?

[15:54:01.0000] <jsbell>
hixie: googling for "gif89a" suggests http://www.w3.org/Graphics/GIF/spec-gif89a.txt which seems reasonable (compuserve 1990). No idea if anyone has documented modern browser handling of the beasts, though.

[15:54:23.0000] <Yuhong>
Anyway, I am on StackOverflow and just posted a link to the spec as an answer.

[15:54:36.0000] <Yuhong>
http://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color/12630675#12630675

[15:55:56.0000] <Hixie>
jsbell: doesn't look like it specs the animated pars

[15:55:59.0000] <Hixie>
parts

[15:56:11.0000] <Hixie>
jsbell: at least not all the netscape extensions

[16:01:10.0000] <jsbell>
Huh; I didn't realize that looping was an extension.

[16:02:21.0000] <jsbell>
hixie: knowing the term "application extension" leads me to http://www.matthewflickinger.com/lab/whatsinagif/

[16:03:03.0000] <jsbell>
which leads to http://odur.let.rug.nl/~kleiweg/gif/netscape.html - a reasonable spec-like description of the NETSCAPE2.0 extension...

[16:03:16.0000] <zewt>
. o ( still dreaming of a css style to stop gif animation )

[16:04:26.0000] <zewt>
also horrifying fact of my week: ios safari (seemingly randomly) caches xhr POSTs : |

[16:08:49.0000] <Yuhong>
And on document.all, it is unfortunate that DOM1 became a REC just as Netscape "Mariner" was being cancelled.

[16:09:18.0000] <Hixie>
jsbell: thanks

[16:09:28.0000] <Hixie>
jsbell: i guess i'll go with that, it's better than nothing!

[16:09:52.0000] <jsbell>
worth what you paid for it.

[16:10:51.0000] <Hixie>
:-)

[16:10:57.0000] <Yuhong>
Which caused IE to gain market share.

[16:12:33.0000] <Yuhong>
To the point where other browsers had to implement document.all

[16:13:03.0000] <Yuhong>
And leaving no browser that supports both document.layers and document.getElementById.


2012-09-28
[23:56:39.0000] <zcorpan>
sigh. i want to demo incremental rendering and have problems with php flush thing not working :-(

[00:00:52.0000] <hsivonen>
<?php ob_flush(); flush(); ob_flush(); sleep(3); ?>

[00:00:58.0000] <hsivonen>
that works for me

[00:13:57.0000] <zcorpan>
doens't appear to work for me. http://simon.html5.org/sandbox/html/incremental-ajax-iframe/slow-load.php

[00:14:11.0000] <zcorpan>
i get chunked encoding but no incremental rendering

[00:19:58.0000] <zcorpan>
/me gives up

[00:21:31.0000] <annevk>
http://www.hixie.ch/tests/evil/page-loading/incremental/002.cgi?mime=text%2Fhtml&delay=1&repeats=100 doesn't work either for me

[00:21:39.0000] <annevk>
I wonder if browsers changed their rendering model maybe

[00:22:53.0000] <annevk>
actually, that one kinda does work

[00:23:10.0000] <annevk>
just wasn't waiting long enough

[00:23:21.0000] <annevk>
http://www.hixie.ch/tests/evil/page-loading/incremental/002.cgi?mime=text%2Fhtml&delay=1&repeats=20 makes it easier

[00:31:10.0000] <hsivonen>
argh. Opera on Linux is a pain to use with a non-QWERTY keyboard layout

[00:31:53.0000] <hsivonen>
it triggers keyboard shortcuts based on the hardware keycodes rather than the baked letters

[00:32:42.0000] <hsivonen>
just opening it for test cases is super-annoying, because ctrl-l and ctrl-v don’t work

[00:32:50.0000] <zcorpan>
annevk: a script with an alert doesn't run until the end so it's not just rendering

[00:33:26.0000] <hsivonen>
I guess this is what you get when you bypass the toolkits on Linux

[00:33:32.0000] <annevk>
I meant that in a broad way, but yeah, I should have said page loading

[01:03:48.0000] <[tm]>
hello friends

[01:04:25.0000] <[tm]>
back from my triumphant European tour 2012

[01:04:42.0000] <annevk>
mike[tm] 2012!!1!!

[01:04:57.0000] <[tm]>
heh

[01:05:21.0000] <[tm]>
hsivonen: planning to work on some validator bugs

[01:06:25.0000] <hsivonen>
[tm]: cool!

[01:17:37.0000] <jgraham>
[tm]: Did you sell t-shirts with the venues and dates on the back?

[01:18:59.0000] <annevk>
which reminds me, is that Docxs t-shirt made yet?

[01:19:42.0000] <jgraham>
Yeah, did you order one?

[01:19:57.0000] <annevk>
I thought I did

[01:20:06.0000] <jgraham>
OK, odinho is in charge

[01:20:10.0000] <jgraham>
Ask him

[01:20:28.0000] <odinho>
annevk: Yeah, I have one for you at my desk.

[01:20:35.0000] <odinho>
annevk: But you haven't been visiting me much lately :-(

[01:21:33.0000] <odinho>
09:32 < hsivonen> argh. Opera on Linux is a pain to use with a non-QWERTY keyboard layout   <----  only next.

[01:21:59.0000] <odinho>
hsivonen: It's a very well known bug, I'm using dvorak myself, so I get totally tripped up. :]

[01:23:07.0000] <odinho>
hsivonen: You can use F8 instead of CTRL+L

[01:23:35.0000] <odinho>
hsivonen: Or if you just want to go to an URL, just middle-click in the middle of a page (not over a textarea), it will go to the url by itself.

[01:23:46.0000] <[tm]>
jgraham: yeah but I spent all the proceeds on hash in Amsterdam

[01:42:16.0000] <hsivonen>
odinho: good to know it’s known. thanks

[02:26:54.0000] <[tm]>
/me only just now discovers https://github.com/whatwg

[02:54:00.0000] <annevk>
[tm]: since all web developers appear to be on github, seemed nice to have the web standards there too

[02:54:25.0000] <danbri>
might as well move all websites there too

[02:54:40.0000] <annevk>
some do

[02:59:04.0000] <jgraham>
google.github.com

[02:59:11.0000] <[tm]>
annevk: everybody except Ms2ger

[02:59:35.0000] <annevk>
[tm]: he is too actually, and pushed some stuff to whatwg/dom already

[02:59:43.0000] <jgraham>
Eventually we should just remove the .github.com suffix and wire browsers to assume that all sites are github subdomains

[02:59:45.0000] <[tm]>
omg

[02:59:45.0000] <annevk>
[tm]: with hggit it works fine for him

[02:59:53.0000] <annevk>
or her

[02:59:58.0000] <jgraham>
"it"

[03:00:02.0000] <[tm]>
annevk: hell hath frozen over

[03:00:02.0000] <annevk>
had anyone confirmed gender yet?

[03:00:08.0000] <annevk>
"it" works :)

[03:00:26.0000] <[tm]>
Ms2ger is more of a "phenomenon"

[03:00:36.0000] <[tm]>
a force of nature

[03:00:37.0000] <annevk>
danbri: we actually host the specs elsewhere, e.g. http://xhr.spec.whatwg.org/

[03:00:47.0000] <jgraham>
annevk: I have never seen Ms2ger naked if that's what you're asking

[03:00:50.0000] <[tm]>
神

[03:01:01.0000] <annevk>
danbri: so when github goes bankrupt we just have to upload the repository elsewhere

[03:01:49.0000] <[tm]>
annevk: btw have you been looking at Chris Weber's tests?

[03:01:54.0000] <[tm]>
URL tests

[03:02:09.0000] <annevk>
it appears he just converted WebKit's tests to some weird XML format

[03:02:13.0000] <annevk>
as far as I can tell anyway

[03:02:17.0000] <annevk>
so I just used those from WebKit

[03:03:20.0000] <[tm]>
https://github.com/cweb/iri-tests

[03:03:41.0000] <[tm]>
annevk: I'm pretty sure he has a bunch of tests in addition to the WebKit ones

[03:03:48.0000] <annevk>
okay

[03:03:59.0000] <annevk>
http://wiki.whatwg.org/wiki/URL links to it already

[03:04:54.0000] <[tm]>
OK

[03:05:16.0000] <[tm]>
ah yeah some tests from Julian

[03:05:38.0000] <[tm]>
http://greenbytes.de/tech/tc/uris/ and http://greenbytes.de/tech/webdav/urldecomp.xml

[03:06:10.0000] <annevk>
so his tests don't include expected results

[03:06:18.0000] <[tm]>
eh?

[03:06:19.0000] <[tm]>
wow

[03:06:21.0000] <annevk>
might as well write tests from scratch then...

[03:06:29.0000] <annevk>
well, some do, some don't

[03:08:35.0000] <[tm]>
yeah lack of expected results makes stuff pretty useless

[03:18:26.0000] <annevk>
so for javascript: and data: and basically all non-hierarchical schemes you do not escape <>?# etc.

[03:18:42.0000] <annevk>
and you can only modify fragment

[03:18:45.0000] <annevk>
I guess that works

[03:19:45.0000] <annevk>
and the value of a javascript URL is then path[0] + fragment

[03:20:01.0000] <annevk>
otherwise javascript:alert('#1') would not work

[03:20:05.0000] <annevk>
and it does

[03:39:15.0000] <AryehGregor>
annevk, props for the easy-to-remember DOM spec URL.

[03:39:38.0000] <AryehGregor>
(even if I'm worried Microsoft will fork it in the W3C -- couldn't you have gone with a CG?)

[03:45:26.0000] <annevk>
we can still publish FSA through a CG

[03:45:36.0000] <annevk>
through the WHATCG

[03:52:21.0000] <annevk>
AryehGregor: also, I'm not a member of any CGs at the moment, I've not taken the time yet to read all the legal things around it

[03:53:05.0000] <[tm]>
annevk: might be worth moving over MIME-sniffing draft from https://github.com/abarth/websec to https://github.com/whatwg too

[03:54:41.0000] <annevk>
I'll let abarth decide on that

[03:54:59.0000] <annevk>
I guess I can add him to /whatwg as a first step

[03:56:47.0000] <annevk>
[tm]: you want to be a member too? since you were editing URL at some point?

[03:57:18.0000] <annevk>
[tm]: also, I was wondering if we could add a box to http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html about it not being maintained

[03:57:46.0000] <[tm]>
annevk: yeah, I can add that

[03:58:21.0000] <[tm]>
and yeah please add me as a member and I'll copy over the current MIME sniff draft

[03:58:45.0000] <[tm]>
I am pretty sure abarth is not planning to work on that further

[03:59:31.0000] <annevk>
done

[04:09:11.0000] <annevk>
anyone from Gecko around that can tell me where Gecko's javascript URL code is located?

[04:14:23.0000] <[tm]>
annevk: gracias

[04:14:28.0000] <[tm]>
annevk: oh, btw, I rememer a while back on some list that abarth was explaining that

[04:14:49.0000] <annevk>
bz too I think

[04:15:50.0000] <[tm]>
annevk: abarth was explaining about some spec not dealing with IRIs but instead with just URIs

[04:16:53.0000] <[tm]>
because of failure of the RFCs to actually properly define how to get a URI from an IRI

[04:17:13.0000] <[tm]>
do you remember reading that? if so, which list?

[04:17:34.0000] <[tm]>
I been looking for it but can't remember where it was

[04:18:15.0000] <SimonSapin>
[tm]: this? http://tools.ietf.org/html/rfc3987#section-3.1

[04:19:25.0000] <annevk>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Nov/0317.html is the one I was talking about

[04:19:46.0000] <annevk>
[tm]: dunno, but I know browsers have one URL code path

[04:20:11.0000] <annevk>
[tm]: and "IRI like" input gets converted to percent escaped stuff when needed

[04:20:40.0000] <annevk>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Nov/0317.html is the one where bz explains some weird javascript: URL stuff

[04:26:36.0000] <annevk>
hmm

[04:26:40.0000] <annevk>
but it gets even weirder

[04:27:03.0000] <annevk>
e.g. javascript:alert('%e2%84') yields some weird character while in utf-8 it's bogus

[04:27:12.0000] <annevk>
%e2 is the start of a three-byte sequence

[04:29:38.0000] <Ms3ger>
Looks like I missed some interesting chatter earlier...

[04:29:44.0000] <Ms3ger>
Also, annevk, http://mxr.mozilla.org/mozilla-central/source/dom/src/jsurl/

[04:30:17.0000] <Ms3ger>
/me wanders off again

[04:50:18.0000] <[tm]>
annevk: thanks

[04:50:36.0000] <[tm]>
turns out http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/thread.html#msg5 is what I was forgetting

[04:50:50.0000] <[tm]>
"Interaction of CSP and IRIs " thread with bz and abarth

[04:51:20.0000] <[tm]>
[[

[04:51:22.0000] <[tm]>
Converting IRIs to URIs is a big mess.  It's something that needs to

[04:51:22.0000] <[tm]>
be solved for the whole platform.  I tried to solve it a couple years

[04:51:22.0000] <[tm]>
ago, but gave up.

[04:51:24.0000] <[tm]>
]]

[04:51:26.0000] <[tm]>
et.c

[04:54:08.0000] <annevk>
ah yeah

[04:54:14.0000] <annevk>
the IDNA2008 vs IDNA2003 thing

[04:54:39.0000] <annevk>
UTS #46 attempted to solve that

[04:55:56.0000] <AryehGregor>
Is it testable whether an object's NativeBrand is "NativeError" vs. something else?

[04:56:46.0000] <annevk>
not looking forward to solving the IDNA problem

[04:57:15.0000] <annevk>
well, I can solve it, just superset IDNA2003 somehow or say IDNA2008 is the way, either way some group is going to yell

[04:58:00.0000] <annevk>
how the fuck the IETF could ever decided to break compatibility in domain names is beyond me

[05:12:25.0000] <[tm]>
annevk: btw and just FYI, http://trac.tools.ietf.org/wg/iri/trac/report/6

[05:16:22.0000] <AryehGregor>
annevk, comments welcome on: http://w3c-test.org/webapps/DOMCore/tests/approved/exceptions.html

[05:16:29.0000] <AryehGregor>
(which I just committed)

[05:16:59.0000] <AryehGregor>
I can't think of anything else to test regarding exception-throwing, TBH.

[05:20:32.0000] <[tm]>
SimonSapin: see abarth comments in http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0005.html thread

[05:23:59.0000] <annevk>
[tm]: is that still maintained?

[05:24:17.0000] <annevk>
[tm]: guess I could check some of those to see if they're addressed or not

[05:26:23.0000] <[tm]>
annevk: that's why I suggested it

[05:26:42.0000] <[tm]>
not sure if it's still maintained

[05:26:47.0000] <[tm]>
will ask Larry

[05:27:26.0000] <[tm]>
annevk: do you think it would be useful to try to encourage some new discussion on the public-iri list/

[05:27:59.0000] <[tm]>
e.g., post a link to the current URL draft and ask for feedback?

[05:28:35.0000] <annevk>
I don't really plan to subscribe

[05:28:43.0000] <annevk>
and the www-tag discussion was kinda pointless

[05:29:20.0000] <annevk>
given the experience of interacting with those people for the past six years I'm not too hopeful for novel contributions, but we can try I suppose

[05:30:16.0000] <[tm]>
annevk: it would be good to find some way if we can

[05:30:31.0000] <[tm]>
annevk: btw http://trac.tools.ietf.org/wg/iri/trac/report/1?asc=1&sort=ticket is better view maybe

[05:30:45.0000] <[tm]>
shows only the open issues

[05:31:14.0000] <[tm]>
37 open

[05:31:28.0000] <annevk>
[tm]: you think there's some gain there?

[05:31:43.0000] <annevk>
[tm]: I don't mind subscribing and posting if you think we should

[05:31:48.0000] <annevk>
[tm]: just wonder what the upside is

[05:32:29.0000] <[tm]>
well I am getting some complaint that we are ignoring use cases

[05:32:30.0000] <annevk>
jreschke will point out once again how he thinks this should really be on top of the existing specs somehow rather than replacing them

[05:32:49.0000] <[tm]>
for non-Web considerations

[05:32:53.0000] <annevk>
that this is really about error handling instead of a better approach to define URLs, etc.

[05:32:58.0000] <[tm]>
and non-browsers

[05:33:10.0000] <[tm]>
annevk: yeah

[05:33:11.0000] <annevk>
we're addressing the problems curl and such have

[05:33:18.0000] <[tm]>
OK

[05:34:03.0000] <annevk>
and this should help every consumer of HTML too...

[05:34:08.0000] <annevk>
or consumer of CSS

[05:35:33.0000] <annevk>
back later, tuna steak time

[05:39:54.0000] <SimonSapin>
We have a CSS issue on the definition of what’s in the url(foo) syntax, and how it should be interpreted

[05:40:05.0000] <SimonSapin>
(CSS escaping allows any unicode string)

[05:40:49.0000] <zcorpan>
SimonSapin: what's the issue?

[05:41:20.0000] <SimonSapin>
the spec previously said URI, it should say IRI or something else

[05:41:42.0000] <zcorpan>
clearly it should say URL :-)

[05:42:33.0000] <SimonSapin>
well, the name of the "value type" is <url> and the syntax is url(...)

[05:46:01.0000] <zcorpan>
the syntax is defined in http://dev.w3.org/csswg/css3-syntax/

[05:46:15.0000] <zcorpan>
the value type should be updated to reference http://url.spec.whatwg.org/

[05:54:47.0000] <annevk>
[tm]: so hey, I guess you should go out about now ;) but lets look into writing to public-iri next week or so

[05:55:19.0000] <annevk>
[tm]: I'm definitely open to all kinds of use cases, but my primary concern is what's important for http://platform.html5.org

[05:56:23.0000] <annevk>
SimonSapin: yeah, CSS should reference the URL Standard, it should just pass the string (collection of code points) to the parser and set the base URL appropriately and that's that

[06:17:01.0000] <[tm]>
annevk: OK

[06:17:06.0000] <[tm]>
I been talking to Larry already

[06:17:25.0000] <[tm]>
will talk to Martin in persdon if I can get him  to make some time

[06:17:45.0000] <[tm]>
agreed about that use cases

[06:18:13.0000] <[tm]>
but I can understand others feeling like they're being blown off

[06:18:29.0000] <[tm]>
those the overstatement is tiresome

[06:18:53.0000] <[tm]>
sometimes

[06:21:05.0000] <zcorpan>
annevk: "Otherwise, set state to no scheme and start over (from the first code point in input)." why does this need to start over?

[06:26:14.0000] <[tm]>
annevk: wondering now if it might make sense for the URL spec to explicitly define some conformance classes

[06:26:27.0000] <[tm]>
if so I can take a shot at adding some language

[06:26:46.0000] <zcorpan>
though i guess it would be implemented by checking against /^[0-9a-zA-Z\+\-\.]*$/ so i guess it's fine

[06:26:51.0000] <[tm]>
e.g., based on subset of classes in the HTML spec

[06:43:43.0000] <SimonSapin>
annevk: the URL Standard, this one http://url.spec.whatwg.org/ ?

[06:43:51.0000] <Ms2ger>
Yep

[06:57:22.0000] <[tm]>
annevk: https://github.com/whatwg/mimesniff

[06:57:45.0000] <[tm]>
annevk: if you can set up http://mimesniff.spec.whatwg.org/ that'd be great

[06:57:53.0000] <[tm]>
oh

[06:57:56.0000] <[tm]>
cool

[06:58:03.0000] <[tm]>
I see it's already there

[06:58:19.0000] <[tm]>
automatic I guess

[06:58:21.0000] <[tm]>
nice

[06:58:51.0000] <[tm]>
ah no

[06:58:57.0000] <[tm]>
I guess it was already there before

[07:00:20.0000] <annevk>
yeah that was there before

[07:00:30.0000] <annevk>
[tm]: who is going to maintain whatwg/mimesniff?

[07:00:37.0000] <annevk>
[tm]: I can set up some kind of thing to make that work

[07:03:10.0000] <annevk>
need to coordinate with Hixie

[07:04:12.0000] <annevk>
SimonSapin: yup

[07:05:06.0000] <SimonSapin>
annevk: I wish I had this a few months ago :)

[07:05:29.0000] <annevk>
zcorpan: because you end up in "hierarchical" which does not reuse buffer

[07:05:37.0000] <annevk>
zcorpan: which means I need to reset buffer there I think

[07:07:17.0000] <annevk>
[tm]: the situation is a bit similar with DOM Events; it's easier to just write a better standard than get the people "in charge" to fix theirs

[07:11:07.0000] <annevk>
SimonSapin: ah, you are/were implementing a CSS parser?

[07:12:44.0000] <SimonSapin>
annevk: Yes. I’m making WeasyPrint (an UA with PDF output) and it’s dependency tinycss (CSS parser)

[07:13:07.0000] <annevk>
ah, in Python, sweet

[07:13:12.0000] <SimonSapin>
yes

[07:13:41.0000] <SimonSapin>
but weasyprint still has url-related bugs, so this new spec will be useful to me

[07:14:04.0000] <annevk>
it's not fully complete, but for http/https at least it should be pretty accurate

[07:14:27.0000] <annevk>
though I've yet to fully figure out IP addresses and host names, they're nasty

[07:14:33.0000] <annevk>
and then especially host names are nasty

[08:00:42.0000] <[tm]>
annevk: I can be responsible for whatever minimal maintenance it might need for now

[08:01:00.0000] <[tm]>
there are no open bugs against it as far as I know

[08:01:36.0000] <[tm]>
and it's fairly mature as far as I can tell

[08:01:51.0000] <annevk>
okay

[08:02:02.0000] <annevk>
so currently abarth owns mimesniff.spec.whatwg.org

[08:02:12.0000] <annevk>
I'll ask Hixie to change that to me so I can set up the syncing script

[08:05:21.0000] <annevk>
Never thought I would care about boring shit like copyright. I even feel slightly passionate about it

[08:06:33.0000] <karlcow>
ideally people would not sign at all their work

[08:06:48.0000] <SimonSapin>
slightly passionate :)

[08:06:58.0000] <karlcow>
but I guess it depends on the type of ideals the person has

[08:07:00.0000] <karlcow>
:)

[08:28:47.0000] <karlcow>
annevk: you have a date

[08:58:12.0000] <abarth>
annevk: thanks

[09:33:55.0000] <dglazkov>
good morning, Whatwg!

[09:47:52.0000] <smaug____>
error event handling is special only in onerror event handler, right?

[09:51:16.0000] <smaug____>
nm

[10:32:11.0000] <annevk>
Hixie: morning enough already?

[11:08:36.0000] <Hixie>
annevk: sup

[11:08:51.0000] <Hixie>
/me just realised he was working and hadn't yet checked irc and e-mail!

[11:17:10.0000] <annevk>
Hixie: can you change the user of mimesniff.spec.whatwg.org to be annevankesteren?

[11:17:25.0000] <Hixie>
abarth is handing it over to you?

[11:17:35.0000] <Hixie>
/me pokes abarth for confirmation

[11:17:39.0000] <abarth>
go for it

[11:17:43.0000] <Hixie>
thanks

[11:17:46.0000] <Hixie>
annevk: on it

[11:17:50.0000] <Hixie>
hm

[11:17:52.0000] <abarth>
annevk: thanks for taking up the cause

[11:17:57.0000] <Hixie>
this is going to nuke the directory, is that ok?

[11:18:00.0000] <Hixie>
or actually, i guess it won't

[11:18:07.0000] <Hixie>
it'll just move to pointing to an empty one

[11:18:09.0000] <annevk>
Hixie: (the complete story is that mike is going to do it and I will set up syncing between github and the spec)

[11:18:17.0000] <Hixie>
the old one is abarth's user will still be there

[11:18:21.0000] <Hixie>
annevk: nice

[11:18:23.0000] <annevk>
Hixie: yeah that's okay, it will be updated shortly

[11:18:25.0000] <Hixie>
k

[11:18:34.0000] <Hixie>
Please Stand By...

[11:18:52.0000] <annevk>
hopefully I can do it in ten minutes, otherwise it'll have to wait an hour

[11:19:25.0000] <Hixie>
oh sweet, dreamhost actually do support moving the files over

[11:19:37.0000] <annevk>
yeah I thought so

[11:19:38.0000] <Hixie>
abarth: you don't have anything secret in the directory, do you?

[11:19:44.0000] <Hixie>
abarth: if not, i'll just move it over

[11:20:04.0000] <Hixie>
annevk: ~/mimesniff.spec.whatwg.org/ ?

[11:20:13.0000] <annevk>
Hixie: yeah

[11:20:17.0000] <annevk>
just defaults

[11:21:17.0000] <Ms2ger>
I guess we should get parsing set up there too

[11:22:00.0000] <Hixie>
annevk: just in case abarth does have secret files there (e.g. svn password or something) I haven't copied the files over

[11:22:05.0000] <Hixie>
annevk: but it is otherwise done.

[11:22:18.0000] <annevk>
Hixie: sweet, I'll set up the sync script

[11:22:23.0000] <GPHemsley>
Is the WHATWG "official" MIME type for WAVE files "audio/wave"? Is this a willful violation of RFC 2361 (which specifies "audio/vnd.wave")? And where does that leave "audio/wav" and "audio/x-wav"?

[11:22:50.0000] <Hixie>
GPHemsley: the WHATWG "official" stance on MIME types in general is "sigh"

[11:22:54.0000] <GPHemsley>
:)

[11:23:07.0000] <GPHemsley>
s/official/canonical/

[11:23:15.0000] <annevk>
yeah, sanse quotes too :)

[11:23:21.0000] <annevk>
euh, sans*

[11:23:44.0000] <Hixie>
GPHemsley: the honest answer is we haven't fixed MIME types yet

[11:23:54.0000] <Hixie>
GPHemsley: it's on the roadmap, but probably not for this year

[11:24:16.0000] <GPHemsley>
I see

[11:24:17.0000] <Hixie>
GPHemsley: i expect to revamp the way registrations for everything is done at some point

[11:24:24.0000] <Hixie>
and that may affect mime types also

[11:24:29.0000] <GPHemsley>
what do you recommend in the meantime?

[11:24:45.0000] <annevk>
I have MIME in general as something I'd like to fix at some point

[11:24:48.0000] <Hixie>
for audio/wave, probably doesnt' matter, i'd assume it all gets sniffed anytway

[11:24:57.0000] <annevk>
at least define MIME type parsing and MIME type parameter parsing in more detail

[11:25:03.0000] <annevk>
because that's kind of a mess

[11:25:08.0000] <Hixie>
that too

[11:25:43.0000] <GPHemsley>
alright

[11:25:58.0000] <annevk>
http://mimesniff.spec.whatwg.org/ is up and running again

[11:26:51.0000] <annevk>
commits to https://github.com/whatwg/mimesniff will be propagated

[11:27:01.0000] <annevk>
thanks Hixie / abarth

[11:27:05.0000] <annevk>
and [tm] !

[11:28:22.0000] <Hixie>
Ms2ger: let me know if you do want me to set things up for you (or tell anne and have him ask me to set it up for him :-) )

[11:28:44.0000] <Ms2ger>
Having anne do it for me sounds good ;)

[11:29:09.0000] <annevk>
Ms2ger: ask Hixie for a URL and have him assign it to the annevankesteren account :p

[11:29:16.0000] <Ms2ger>
parsing?

[11:29:18.0000] <annevk>
Ms2ger: and make a github repo

[11:29:35.0000] <Hixie>
parsing.spec.whatwg.org?

[11:29:43.0000] <Ms2ger>
annevk, what did you use to convert the repo?

[11:29:47.0000] <annevk>
gotta catch a train

[11:29:57.0000] <Ms2ger>
See you, then :)

[11:30:00.0000] <annevk>
Ms2ger: the hggit stuff, I can do that for you if you want, later

[11:30:02.0000] <Hixie>
man, anne's getting jeff crashing his town to speak to him

[11:30:04.0000] <Hixie>
high roller

[11:30:32.0000] <Hixie>
domparsing.spec.whatwg.org?

[11:30:36.0000] <Hixie>
what spec are we talking about here?

[11:31:49.0000] <Ms2ger>
http://html5.org/specs/dom-parsing.html

[11:32:19.0000] <[tm]>
annevk: http://dvcs.w3.org/hg/url/raw-file/default/Overview.html

[11:32:22.0000] <Hixie>
so domparsing.spec ?

[11:32:36.0000] <Ms2ger>
That works

[11:32:49.0000] <Hixie>
[tm]: can you do that with html too? :-P

[11:33:11.0000] <[tm]>
heh

[11:33:31.0000] <Ms2ger>
[tm], and DOM4? :)

[11:33:32.0000] <[tm]>
my hit points are limited

[11:34:08.0000] <Hixie>
hah

[11:35:35.0000] <Hixie>
Ms2ger: please complete this sentence re that spec: "This specification defines "

[11:36:01.0000] <Hixie>
(for whatwg.org/specs)

[11:36:04.0000] <Ms2ger>
"DOM APIs related to parsing markup into DOM trees and serializing DOM trees into markup"? :)

[11:36:10.0000] <Hixie>
thanks

[11:36:27.0000] <Ms2ger>
/me is happy he wrote an abstract once

[11:37:54.0000] <Hixie>
:-)

[11:37:57.0000] <Hixie>
up to anne now

[11:39:16.0000] <[tm]>
this looks exciting: https://twitter.com/esdiscuss/

[11:48:22.0000] <Ms2ger>
annevk, everything set up

[11:55:56.0000] <Hixie>
"If the [script] element does not have a src attribute, and the element has been flagged as "parser-inserted", and [...] the parser that created the script is [...] an HTML parser whose script nesting level is zero [...]"

[11:56:00.0000] <Hixie>
how can that ever happen?

[11:57:34.0000] <Hixie>
i added that on 2012-08-28

[11:57:36.0000] <Hixie>
hmm

[11:57:42.0000] <Hixie>
that's only a month ago

[11:59:49.0000] <Hixie>
oh i think i meant "is 1"

[11:59:50.0000] <Hixie>
not zero

[11:59:55.0000] <Hixie>
(http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0231.html)

[12:14:57.0000] <Hixie>
annevk: re URLs: did you file a bug on updating the HTML spec to point to URL?

[12:15:30.0000] <Hixie>
annevk: and, is there any chance I can get you to define "URL" as a string, and use a slightly different term for the decomposed+absolute form? maybe "absolute URL"?

[12:15:50.0000] <Hixie>
annevk: (it would make merging way easier, and be more consistent with how people refer to URLs)

[12:16:38.0000] <annevk>
that would be kinda confusing with the URL object

[12:17:18.0000] <Hixie>
people think the value in href="foo.html" is a URL, I don't think we're going to convince them otherwise

[12:17:36.0000] <annevk>
you have a point there

[12:18:04.0000] <Hixie>
having the URL object represent an absolute URL is ok, i think. You can always _create_ a URL object from a relative one, right?

[12:18:09.0000] <Hixie>
it'll just resolve it first

[12:18:19.0000] <annevk>
you can if you provide a base URL

[12:18:29.0000] <Hixie>
oh it doesn't use the the script base URL? interesting

[12:18:47.0000] <annevk>
maybe it should fallback to that, didn't think of that

[12:19:18.0000] <Hixie>
didn't we define a Location.resolve() method at some point?

[12:19:21.0000] <annevk>
I hate the terminology minefield

[12:19:31.0000] <annevk>
Hixie: we removed it in favor of the URL constructor

[12:19:35.0000] <Hixie>
ah ok good

[12:19:40.0000] <Hixie>
i was about to suggest doing that

[12:19:53.0000] <Hixie>
ok so yeah, i'd say default to the script base URL or something

[12:20:15.0000] <Hixie>
but either way, i think it makes the name of hte URL object be fine

[12:20:32.0000] <Hixie>
even if we define URL as the string like in HTML today, and absolute URL as the decomposed thing that the algorithms use

[12:22:27.0000] <annevk>
Hixie: give it another two weeks or so and I'll file that bug; there's a conference here next week and I'm not sure how much time I have; I also want to try updating XMLHttpRequest first to use the new URL stuff to see how it works out

[12:23:11.0000] <annevk>
Ms2ger: you're ready to go btw

[12:23:26.0000] <Ms2ger>
Excellent, thanks :)

[12:23:44.0000] <annevk>
Ms2ger: do you want a redirect from http://html5.org/specs/dom-parsing.html or should I make it nice page like the one we have for ranges?

[12:23:56.0000] <Ms2ger>
A redirect, I think

[12:23:59.0000] <annevk>
kk

[12:24:22.0000] <Hixie>
annevk: lgtm

[12:25:41.0000] <annevk>
Hixie: if we call all strings URL I think we should reserve absolute URL for the form that is not relative, and use "parsed URL" or some such for the object

[12:26:04.0000] <annevk>
I'm not a big fan of that terminology personally though

[12:26:29.0000] <annevk>
having written a URL spec I can see why they went with relative reference and URI :)

[12:28:47.0000] <annevk>
Ms2ger: done

[12:29:09.0000] <Ms2ger>
Thanks

[12:32:40.0000] <Hixie>
annevk: "parsed URL" works for me. I'd just have to change "resulting absolute URL" throughout

[12:32:50.0000] <Hixie>
annevk: which is better than changing every instance of URL anywhere. :-)

[12:32:53.0000] <Hixie>
hsivonen: yt?

[12:33:13.0000] <Hixie>
hsivonen, abarth: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17872

[12:41:11.0000] <abarth>
Hixie: is that a feature request or a compat issue?

[12:42:02.0000] <Hixie>
feature request

[12:42:27.0000] <Hixie>
it's asking for  <form id=a></form> <fieldset form=a> <input> </fieldset>  to associate the input with the form

[12:42:36.0000] <annevk>
abarth: so to your knowledge WebKit is going to stick with IDNA2003? or are there plans to implement UTS #46?

[12:42:56.0000] <annevk>
abarth: I'm not too interested in what the IETF thinks, I just want to define what everyone wants to converge towards

[12:43:20.0000] <abarth>
annevk: I believe it's a port specific decision

[12:43:25.0000] <annevk>
abarth: I saw Gecko might just go to IDNA2008 by adopting some library

[12:43:31.0000] <abarth>
annevk: Chrome doesn't have any plans to move off IDNA2003

[12:43:34.0000] <annevk>
abarth: gotta love that

[12:44:12.0000] <annevk>
abarth: ah okay, I found some Chromium bug where Mark Davies suggested otherwise, but maybe he was wrong; I guess he's not on Chrome to begin with

[12:44:36.0000] <annevk>
Davis*

[12:45:07.0000] <annevk>
-- http://code.google.com/p/chromium/issues/detail?id=114375

[12:45:38.0000] <abarth>
(looking)

[12:46:50.0000] <abarth>
annevk: jshin is the person who will make the final decision

[12:46:53.0000] <abarth>
you can just ask him directly

[12:47:36.0000] <annevk>
guess I can try that, haven't had much luck in the past when asking about encoding stuff

[12:49:12.0000] <abarth>
I would be very surprised if Chrome adopted IDNA2008

[12:54:26.0000] <annevk>
thus far I know Safari has no immediate plans (and has a list of sites that will break if they do); I know Gecko is waiting for relicensing of some Japanese DNS library they want to adopt that implements IDNA2008; Opera implements IDNA2008 and faces compatibility issues (presumably including those on Safari's private list), Opera's IDNA2008 implementation might not entirely match the spec, they do support IDNA2003 label-separator

[12:54:27.0000] <annevk>
s for instance; Chrome you just mentioned; no idea about Microsoft

[12:57:08.0000] <annevk>
http://blogs.msdn.com/b/michkap/archive/2012/09/27/10353657.aspx suggests Microsoft goes with IDNA2008 + UTS #46 for Windows 8

[13:01:51.0000] <annevk>
http://blogs.msdn.com/b/michkap/archive/2012/02/27/10273315.aspx looks like IDNs are a world of hurt

[13:01:52.0000] <annevk>
joy

[13:08:24.0000] <[tm]>
lovely

[13:11:29.0000] <annevk>
[tm]: http://mimesniff.spec.whatwg.org/#acknowledgements has an encoding issue

[13:11:44.0000] <annevk>
[tm]: lacks a comma, too

[13:14:59.0000] <[tm]>
annevk: thanks will fix it now

[13:31:49.0000] <zewt>
annevk: IDNs seem like a pretty broken idea

[13:32:02.0000] <zewt>
i mean, they simply Don't Work(tm) in plaintext, short of evil heuristics

[13:32:06.0000] <hober>
zewt: i dunno, poopla is pretty awesome.

[13:33:14.0000] <annevk>
hober: one of those blogs.msdn.com links above suggests poopla might be breaking the rules

[13:33:37.0000] <zewt>
<- shocked

[13:38:08.0000] <annevk>
I'm not really shocked that much, just annoyed that nobody figures it out in full detail

[13:38:37.0000] <annevk>
IDNA2003 was pretty complete, but still did not cover things such as underscores or semicolons in labels

[13:39:46.0000] <annevk>
the same thing happened with URL, in theory URLs were pretty restricted, but nobody implemented the restrictions and just looked at the separators

[13:40:02.0000] <annevk>
and then when that became widespread, nobody updated the definition

[13:40:45.0000] <annevk>
you'd think with a billion people online or so, there must be more than one person that cares about fixing those things

[13:40:48.0000] <TabAtkins>
Unrelated to URLs, KLINGON STYLE http://www.youtube.com/watch?v=CayMeza487M (from what I understand, a pretty close translation from Korean to Klingon).

[13:43:19.0000] <annevk>
haha

[13:43:24.0000] <annevk>
has the elevator scene and everything

[13:43:59.0000] <TabAtkins>
yup! the only major scene i see them missing is the fake-snowstorm

[13:47:20.0000] <[tm]>
annevk: I see Thomas Ford left Opera

[13:49:36.0000] <annevk>
[tm]: oh? haven't seen him in ages

[13:50:41.0000] <annevk>
https://twitter.com/thomasford doesn't say much

[13:51:01.0000] <annevk>
does say he's working for Soundrop, doh

[13:51:01.0000] <[tm]>
annevk: linkedin

[13:51:07.0000] <[tm]>
yah

[13:51:12.0000] <[tm]>
whatever that is

[13:51:15.0000] <[tm]>
famous?

[13:51:39.0000] <[tm]>
Hixie: IANA approved the registration for text/html

[13:52:12.0000] <[tm]>
but the sent back questions on application/microdata+json

[13:52:54.0000] <danbri_>
got a link for that, re application/microdata+json questions?

[13:53:22.0000] <[tm]>
danbri_: no, private mail unfortunately

[13:53:36.0000] <danbri_>
ok, thanks

[13:53:36.0000] <[tm]>
that seems to be the way they handle these

[13:53:50.0000] <[tm]>
text/html updates is at http://www.iana.org/assignments/media-types/text/index.html

[13:53:58.0000] <[tm]>
http://www.iana.org/assignments/media-types/text/html

[13:54:07.0000] <danbri_>
/me finds http://www.ietf.org/mail-archive/web/ietf-types/current/msg01722.html

[13:54:17.0000] <danbri_>
the json-ld comparison seems fair; they're in similar territory

[13:55:16.0000] <[tm]>
dude subsequently posted to whatwg about that

[13:55:24.0000] <[tm]>
lemme find the thread

[13:56:04.0000] <[tm]>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/thread.html#msg73

[13:56:15.0000] <danbri_>
/me was reading http://www.ietf.org/mail-archive/web/ietf-types/current/msg01722.html

[13:56:18.0000] <[tm]>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/thread.html#msg80

[13:56:57.0000] <annevk>
man, can't wait when IANA is fully replaced by wiki.whatwg.org or specs

[13:57:06.0000] <annevk>
for when, even

[13:58:06.0000] <annevk>
not like it matters http://www.iana.org/assignments/media-types/text/html exists now

[13:59:16.0000] <annevk>
[tm]: so no fucks were given about versioning or the DOCTYPE stuff from the RFC?

[13:59:27.0000] <annevk>
[tm]: so weird!

[13:59:37.0000] <[tm]>
matters for me personally because it's one less thing i'm supposed to have got done that I have now got done

[13:59:42.0000] <[tm]>
level cleared

[13:59:58.0000] <[tm]>
annevk: I just push the buttons

[14:00:12.0000] <annevk>
bit hit with the ladies

[14:00:29.0000] <annevk>
big*; damn it

[14:01:01.0000] <[tm]>
PSY of web standards

[14:01:21.0000] <[tm]>
gangham style

[14:02:09.0000] <annevk>
still surprised no fucks were given about any of the things fucks were going to be given over

[14:03:25.0000] <[tm]>
I'm just always happy to slip stuff under the radar whenever I can

[14:03:58.0000] <[tm]>
and prepare to fly the "Too late now!" flag as needed later

[14:04:07.0000] <[tm]>
hey, that worked for the IDN WG

[14:05:23.0000] <annevk>
oh hey, sorry, we fucked over the primary means of accessing your site, have a nice day now

[14:07:14.0000] <annevk>
prolly the same guys that deleted http://en.wikipedia.org/wiki/.yu

[14:07:18.0000] <annevk>
or http://en.wikipedia.org/wiki/.cs

[14:08:16.0000] <[tm]>
hmm what's e10s?

[14:08:18.0000] <[tm]>
https://bugzilla.mozilla.org/show_bug.cgi?id=770778

[14:08:55.0000] <[tm]>
also https://twitter.com/kripken/status/251754496361914369 looks like good news

[14:09:05.0000] <[tm]>
"Initial support for websockets in emscripten now in incoming branch (i.e., use the C sockets API, and it uses websockets)"

[14:11:12.0000] <annevk>
kinda, you'd have to rewrite the server software though

[14:14:20.0000] <[tm]>
oh

[14:16:08.0000] <[tm]>
also me finds https://wiki.mozilla.org/Electrolysis ( = e10s(


2012-09-29
[21:58:29.0000] <synod>
Hi, where is the HTML source control repository?

[22:00:04.0000] <synod>
i did $ svn co http://svn.whatwg.org/webapps/ but it seems to be missing lots of things like the build system.

[22:15:29.0000] <synod>
spec build system? anyone?

[22:28:31.0000] <synod>
ok maybe build system for html is too hard... where are the parsing tests?

[22:43:37.0000] <synod>
no official html5 to xml tests?

[22:51:11.0000] <[tm]>
synod: build script isn't in the repo

[22:51:27.0000] <[tm]>
not really clear why anybody else would need it

[22:51:46.0000] <[tm]>
dunno what you mean by html5 to xml tests

[22:52:36.0000] <[tm]>
there's noththing that would make building something from html any harder than from xml

[22:53:08.0000] <synod>
[tm]: i would like to see how the spec is built... ?

[22:53:46.0000] <synod>
[tm]: as i understand it, html5 defines a way to parse invalid html into a valid dom? there is an xml version of each valid dom?

[22:56:33.0000] <[tm]>
xml version of each valid DOM...

[22:57:39.0000] <[tm]>
once the parser construcs the DOM it really doesn't matter where the serialized source it came from was text/html or XML

[22:58:19.0000] <synod>
how do i test my html5 parser? i have to diff the dom from html and the 'correct' dom, no?

[22:58:50.0000] <synod>
there are lots of xml -> dom parsers. are there html5 and xml test pairs?

[22:59:02.0000] <[tm]>
synod: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#coercing-an-html-dom-into-an-infoset might have something you want as far as generating XML from a DOM, I dunno

[22:59:19.0000] <[tm]>
what is a a "correct" DOM man?

[22:59:35.0000] <[tm]>
why dod you want "test pairs"?

[22:59:39.0000] <[tm]>
what are you trying to do?

[23:00:01.0000] <[tm]>
there are lots of html -> dom parsers of course

[23:00:12.0000] <synod>
[tm]: i am wanting to write an html5 parser... how do i test it

[23:01:26.0000] <[tm]>
ah

[23:01:49.0000] <[tm]>
OK, well, there's a testsuite in the html5lib source repoo

[23:02:16.0000] <[tm]>
http://code.google.com/p/html5lib/

[23:02:31.0000] <[tm]>
hg clone https://code.google.com/p/html5lib/

[23:03:00.0000] <[tm]>
synod: what language you writing your parser in?

[23:03:15.0000] <synod>
[tm]: ocaml

[23:04:28.0000] <synod>
html5lib tests are in some custom format?

[23:04:59.0000] <[tm]>
python/html5lib/tests subdir

[23:05:47.0000] <[tm]>
the ones there are in python scripts

[23:06:13.0000] <[tm]>
there's json test sources in testdata subdir

[23:06:32.0000] <synod>
and some weird format with #data and ||| stuff

[23:07:33.0000] <[tm]>
yeah

[23:07:55.0000] <synod>
is html5lib tests the most complete for parsing? others look like rendering and such

[23:08:22.0000] <synod>
does html5lib track whatwg or w3c?

[23:08:29.0000] <[tm]>
none of them are rendering tests

[23:09:06.0000] <synod>
i mean the other suites linked from the wiki

[23:09:17.0000] <[tm]>
synod: there is no difference between the parsing algorithm in the whatwg and the w3c specs

[23:09:34.0000] <[tm]>
html5lib test suite is the most complete

[23:09:38.0000] <synod>
oh, that's good

[23:09:52.0000] <[tm]>
browser teams have upstreamed tests back to it

[23:10:06.0000] <[tm]>
hundreds of tests

[23:11:14.0000] <synod>
cool

[23:11:34.0000] <synod>
thx 4 the info

[23:12:49.0000] <[tm]>
synod: https://github.com/w3c/html-testsuite/tree/master/tests/submission/Opera/html5lib has a runnable harness that may or not be useful to you

[23:13:29.0000] <[tm]>
for more answers, hang out here for a while and ping jgraham and zcorpan and annevk when they wake up

[23:13:35.0000] <[tm]>
(CET time)

[23:16:05.0000] <synod>
ok

[23:38:01.0000] <annevk>
synod: you want to write a spec?

[00:11:02.0000] <synod>
annevk: for a different language

[00:11:21.0000] <synod>
annevk: looks like anolis is what whatwg uses?

[00:11:32.0000] <annevk>
http://wiki.whatwg.org/wiki/Anolis is what most of our specs use

[00:11:53.0000] <annevk>
in particular "Setting up Anolis with cross-specification cross-references"

[00:12:17.0000] <annevk>
HTML uses Anolis, but has several pre-processing steps of its own too

[00:13:35.0000] <synod>
ok... and html5lib tests are the most complete parsing suite?

[00:17:27.0000] <annevk>
yup

[00:22:58.0000] <synod>
thx... ttyl

[00:49:37.0000] <SimonSapin>
annevk: I skimmed the state machine in the URL Standard. Do you think that parts of it could be expressed (more tersely) as regular expressions, like RFC 3986 did?

[00:52:23.0000] <annevk>
if you do something like that you'd need to explain a whole bunch of other things

[00:55:36.0000] <annevk>
in general I don't think using ABNF or regular expressions is a good way to explain how to process complex syntax

[01:04:59.0000] <Ms2ger>
/me kicks annevk out of the IETF

[01:05:02.0000] <Ms2ger>
... oh wait

[01:44:13.0000] <[tm]>
so I'm thinking about http://lists.w3.org/Archives/Public/public-html/2012Sep/0499.html

[01:44:55.0000] <[tm]>
"we simply ask browser vendors to provide

[01:44:55.0000] <[tm]>
the results they got when they regression tested the build that we are

[01:45:00.0000] <[tm]>
considering for conformance purposes"

[01:45:12.0000] <[tm]>
which sounds worth considering

[01:45:50.0000] <[tm]>
but would still want to be able to indepedently verify the results if possible

[01:46:59.0000] <[tm]>
I wonder if all browser teams have test runners that I could set up instances of

[01:48:27.0000] <Ms2ger>
Can you set up instances of Microsoft employees?

[02:11:00.0000] <[tm]>
Ms2ger: :-)

[07:43:08.0000] <jgraham>
[tm]: You are quite welcome to verify the results if you like, but I think it will take you a while :) I'm not sure that we would be desperate to go through the effort of releasing our test infrastructure

[07:48:05.0000] <jgraham>
Not because I see it as secret sauce, just because it would be quite a lot of work to unleash a mess of code that was designed to run in our particular environment on the world, and very little gain

[08:54:31.0000] <jgraham>
Is it just my computer or is clang/llvm roughly the slowest thing in the world to compile

[08:54:45.0000] <Ms2ger>
Nah

[08:54:48.0000] <Ms2ger>
Gecko is

[08:54:50.0000] <jgraham>
(I mean to compile clang itself, not to compile using clang)

[08:55:46.0000] <jgraham>
Well I think either this computer is more rubbish than I believed or I am doing something seriously wrong because so far this seems to have taken 3 hours

[08:58:38.0000] <Ms2ger>
bz says 15 minutes at most

[08:58:46.0000] <[tm]>
jgraham: thanks for comments about test stuff

[08:59:04.0000] <Ms2ger>
But he's got pretty fast hardware

[08:59:30.0000] <smaug____>
yeah, I don't think compiling clang is that slow

[08:59:38.0000] <zewt>
well, unless there's a huge RAM issue, the difference between crappy budget hardware and really fast consumer hardware isn't 15-minutes/3-hours

[09:00:10.0000] <smaug____>
swapping would make compiling really slow

[09:00:19.0000] <zewt>
that's a "huge RAM issue" :)

[09:03:47.0000] <jgraham>
It could well be. It has certainly swapped everything else out

[09:04:54.0000] <jgraham>
But is showing free memory so...

[09:05:20.0000] <zewt>
i don't even use swap on any of my linux systems, heh, but i don't run X on most of them

[09:05:28.0000] <jgraham>
This is OSX

[09:05:59.0000] <jgraham>
Which is super-annoying when you want to compile things

[09:06:06.0000] <jgraham>
Or really install anything

[09:06:23.0000] <zewt>
osx is super-annoying when you want to ... things

[09:07:49.0000] <zewt>
(keyboard navigation for menus? hahahaha)

[09:17:53.0000] <Ms2ger>
Mm, I think there's a clang in homeports or brews or whatever

[09:45:19.0000] <jgraham>
zewt: Well it's not like I plan to buy a Mac again. Would be nice if someone else was making comparably good hardware though

[09:45:35.0000] <jgraham>
Well specifically comparably good ouchpads

[09:45:40.0000] <jgraham>
*touchpads

[09:47:32.0000] <[tm]>
jgraham: I built llvm on my OS X laptop before and I am certain it took less that 3 hours

[09:48:18.0000] <[tm]>
from the sources, with defaults -- debug build plus all whatever test stuff and such it also builds

[09:48:56.0000] <[tm]>
so unless something major has changed in the sources since then, I wouldn't think it should take that long

[09:49:19.0000] <[tm]>
that said, I'm also sure it took more than 15 minutes

[09:49:25.0000] <[tm]>
it wasn't fast

[09:49:45.0000] <[tm]>
I'd guess it was probably 30 minutes or definitely less than hour

[09:49:59.0000] <[tm]>
fro llvm+clang

[09:51:03.0000] <[tm]>
2.7 GHz dual core

[09:52:04.0000] <[tm]>
it was faster than building some other stuff -- e.g., boost

[10:36:11.0000] <zewt>
random sad hilarity: tabbing to the search box in Steam with the keyboard, instead of clicking, lands you on an input box containing the text "search the store"

[15:31:54.0000] <teear>
hello


2012-09-30
[21:37:37.0000] <teear>
I'm on Cannabis

[07:46:26.0000] <GPHemsley>
so... RFC 4288 does not appear to specify how MIME type parameters should be separated from the MIME type itself...

[13:32:01.0000] <annevk>
"you sound surprised"

[13:36:35.0000] <zewt>
a special place in spec absurdity hall of fame must be reserved for OpenGL, and their omitting of "gl" on function calls in the spec, making it impossible to search for "glBegin"--it's just the unsearchable "begin" everywhere

[13:36:47.0000] <zewt>
those guys sure saved a couple letters!

[13:38:55.0000] <moo-_->
GPHemsley: if you have read Terry Pratchet's novels there are usually imps living in little boxes for tasks like these

[14:24:33.0000] <Philip`>
zewt: Sounds like you need a case-sensitive search function

[14:26:41.0000] <Philip`>
/me likes how he can't search for underscore-separated identifiers in the GL spec, unless he replaces the underscores with spaces

[14:27:14.0000] <zewt>
wouldn't really work, since begin can begin a sentence

[14:28:04.0000] <Philip`>
It can, but I expect it very rarely does

[14:41:37.0000] <annevk>
is begin a method?

[14:41:43.0000] <annevk>
begin( should work then

[14:43:52.0000] <zewt>
haha i copied text from the spec and the word "final" became "final"

[14:44:41.0000] <zewt>
"begin(" doesn't work since eg. "If the number of vertices speci?ed for a quadrilateral strip between Begin and End is odd, the ?nal vertex is ignored."

[14:48:47.0000] <annevk>
or if you know the interface... dom-XXX-begin

[14:48:57.0000] <annevk>
but I guess they don't follow that pattern

[14:49:44.0000] <zewt>
talking about the core opengl specs; webgl is more sane here

[14:50:08.0000] <zewt>
(webgl doesn't include "gl", but they're also not part of the symbols--opengl actually calls glBegin "begin")