00:58
<Hixie>
wow there is really no freaking interop between browsers on Location
01:02
<Hixie>
wow, IE actually lets you detect which properties are on another origin's Location object
01:03
<heycam>
that sounds bad
01:04
<Hixie>
parent.location instanceof Location => false in IE, true in Gecko, false in Opera, and there's no Location object in WebKit.
01:04
<heycam>
should be false in Gecko once Location is implemented with new Web IDL bindings
01:05
<Hixie>
Location.test = 1; w(parent.location instanceof Location); w(Location.test); w(parent.location.test) => true, 1, undefined in Gecko
01:05
<Hixie>
wtf Gecko
01:06
<Hixie>
wait, i'm on crack
01:06
<Hixie>
i should have been doing Location.prototype.test = 1
01:06
<Hixie>
and gecko throws if i do that...
01:07
<heycam>
hmm
01:50
<Hixie>
abarth: https://bugs.webkit.org/show_bug.cgi?id=83493#c20
01:51
<abarth>
Hixie: hi
01:52
<Hixie>
abarth: haven't yet paged in the details here but that bug has a question for you
01:52
<abarth>
Hixie: answered
01:52
<Hixie>
cool
01:52
<Hixie>
thanks
01:53
<Hixie>
anything to report on ancestorOrigins btw? did it work out as expected?
01:53
<abarth>
yes, the people for whom it solves a problem are very happy with it
01:54
<abarth>
it certainly doesn't solve every problem though
01:54
<abarth>
the main people who like it are people who write widgets
01:54
<abarth>
and want to know something about their embedded context
01:54
<Hixie>
cool
01:54
<Hixie>
do you know of any implementation in other UAs?
01:54
<Hixie>
annevk: you around?
01:55
<abarth>
I don't know of any
01:55
<abarth>
in other user agents, you can try to access things and catch security exceptions
01:55
<abarth>
so there's less of a need
01:55
<abarth>
but that doesn't help with the clickjacking use cases
01:55
<Hixie>
oh, why doesn't that work in webkit?
01:56
<abarth>
WebKit doesn't throw exceptions for security errors
01:56
<abarth>
in some cases
01:56
<abarth>
and it logs to the console when there is a security error
01:56
<abarth>
the widget authors don't like the console spam
01:56
<abarth>
because people who embed the widgets complain about it
01:58
<Hixie>
oh
01:58
<Hixie>
why not fire an exception?
01:58
<abarth>
two reasons:
01:59
<abarth>
1) we're worried about breaking content that doesn't expect the exception
01:59
<abarth>
2) othermaciej is concerned about making it too easy to probe whether security checks will pass or fail
01:59
<abarth>
(i'm not really sold on (2), so I might not be explaining it the most clearly)
02:00
<abarth>
i've got to run
02:00
<Hixie>
laer
02:00
<abarth>
l8r
02:01
<TabAtkins>
Damn punk kids and your txt spk
02:36
<othermaciej>
abarth: I am not all that concerned about it, certainly not enough to outweigh any actual pragmatic benefit in a given case if there is one
02:49
<Hixie>
abarth: ok so looks like ancestorOrigins in webkit uses a DOMStringList, and isn't blocked by sandboxing, is that right?
02:51
<abarth>
othermaciej: oh, maybe I misunderstood the earlier discussion. sounds like (1) is the main issue then
02:51
<abarth>
Hixie: yes
02:51
<othermaciej>
abarth: I don't know what you mean by "the earlier discussion"
02:52
<othermaciej>
abarth: I personally do think it is a bad idea to return informative exceptions to the caller when a security violation occurs, but not enough to fight the weight of other implementations, or what have you
02:52
<abarth>
its from a message you wrote on Aug 13, 2010
02:53
<abarth>
let me find the link
02:54
<abarth>
http://lists.webkit.org/pipermail/webkit-dev/2010-August/013883.html
02:54
<abarth>
sounds like you weren't overly concerned then either
02:55
<abarth>
but just raising it as a possible issue
05:42
<Hixie>
in webkit, does securityOrigin()->toString() return a unicode origin or an ascii origin?
05:44
<Hixie>
(abarth?)
06:58
<MikeSmith>
Hixie: I looked at the sources myself to try to figure out but can't tell from that either
06:59
<MikeSmith>
http://trac.webkit.org/browser/trunk/WebCore/platform/SecurityOrigin.h?rev=30184
06:59
<MikeSmith>
I can't tell from that at least
07:13
<MikeSmith>
Hixie: question about the outline algorithm behavior for the case of <hgroup>foo <h1>bar</h1> <h2>baz</h2></hgroup>
07:14
<MikeSmith>
it's not clear to me what the spec says should be the heading that goes into the outline for that
07:15
<MikeSmith>
all the implementations of the outline algorithm I've tried use just "bar"
07:16
<MikeSmith>
but I don't see where the spec requires that instead of using "foo"
07:18
<Hixie>
MikeSmith: the heading is "foo" with subheading "bar"
07:19
<MikeSmith>
aha
07:19
<Hixie>
oh wait
07:19
<Hixie>
i misread your example
07:19
<Hixie>
it's bar with subheading baz
07:19
<Hixie>
the foo is bogus
07:19
<MikeSmith>
ok
07:19
<Hixie>
hopefully the spec actually agrees
07:19
<MikeSmith>
I can't tell that it does actually
07:20
<MikeSmith>
will file a bug
07:21
<Hixie>
outline algorithm says the hgroup is the heading, right?
07:21
<MikeSmith>
yeah
07:22
<MikeSmith>
that part's clear
07:23
<JonathanNeal>
hgroup can't contain anything that isn't a <h1-6>.
07:23
<JonathanNeal>
That's why us <subline>rs were rabble rousing.
07:24
<MikeSmith>
JonathanNeal: it can contain them in the DOM
07:24
<MikeSmith>
I realize it's not valid
07:24
<Hixie>
MikeSmith: ok so if hgroup is the heading, then the question is just what does the hgroup represent
07:25
<Hixie>
...which i guess is indeed rather vague
07:25
<MikeSmith>
ah damn
07:25
<MikeSmith>
I think it might be clear
07:25
<MikeSmith>
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#headings-and-sections
07:26
<MikeSmith>
"The first element of heading content in an element of sectioning content represents the heading for that section."
07:26
<MikeSmith>
oh no sorry
07:26
<MikeSmith>
not that
07:26
<Hixie>
right that's just saying the hgroup is the heading
07:26
<MikeSmith>
yup
07:27
<JonathanNeal>
rah rah <hgroup> poorly thought out rah rah <subline> solves all problems rah rah rahn paul rah
07:31
<JonathanNeal>
rah rah clear up :heading(n) confusion, reduce ambiguity of headings, spend more time solving issue of multiple subheadings of different weights.
07:32
<Hixie>
(in other news, i hate document.domain)
07:36
<MikeSmith>
Hixie: recent changes and subsequent bz bugs?
07:36
<Hixie>
everything around the effective script origin crap
07:36
<Hixie>
worst security design ever
07:51
<Hixie>
someone really should review the HTML spec's security stuff, I'm sure I have all kinds of bugs where I talk about the origin (should it be effective origin) of scripts (first script? calling script?)
08:00
<pottersson>
Does anyone know where I can download a copy of the WHATWG spec for HTML5?
08:02
<Hixie>
wow, he didn't stick around long
08:06
<zcorpan>
annevk: do you know what ie does with % in host?
08:07
<Hixie>
zcorpan: any idea where sigbjoern got the idea of commas in CORE-35269?
08:08
<Hixie>
zcorpan: it seems to contradict the data in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18228
08:11
<zcorpan>
Hixie: i guess he looked at the URL in the bug, saw that it worked in firefox and webkit but not in opera, didn't test IE and didn't research other content
08:12
<Hixie>
the url doesn't use a comma
08:12
<Hixie>
and never did, per the comments
08:12
<zcorpan>
CORE-40846 does though
08:14
<Hixie>
i can't get to that url
08:14
<Hixie>
so can't check
08:15
<zcorpan>
url for that is https://bespin.mozillalabs.com/
08:15
<zcorpan>
http://code.google.com/codesearch#search/&q=%3Cmeta%5Cs%2Bhttp%5C-equiv%5C=%5C%22refresh%5C%22%5Cs%2Bcontent%5C=%5C%22%5Cd%2B%5C,&type=cs
08:17
<Hixie>
zcorpan: right, that url doesn't work for me
08:17
<zcorpan>
ah.
08:18
<zcorpan>
i don't have a login either
08:19
<Hixie>
that second link is good though, i've reopened the bug for it
08:21
<Hixie>
ok, bed time. nn.
08:23
<zcorpan>
nn
08:43
<zcorpan>
i guess the html spec is full of things that can be changed to webidl enums
08:45
<Ms2ger>
There are a number in canvas, at least
09:08
<MikeSmith>
so http://qa-dev.w3.org:8888/ no has an experimental "Show outline" feature
09:09
<MikeSmith>
implemented in JavaScript, using h5o
09:10
<MikeSmith>
so you can do, e.g., http://qa-dev.w3.org:8888/?doc=http://quirks.spec.whatwg.org/&showoutline=yes
09:10
<MikeSmith>
or http://qa-dev.w3.org:8888/?doc=http://quirks.spec.whatwg.org/&showoutline=yes#outline to go straight to the outline
09:19
<MikeSmith>
and a separate feature at http://qa-dev.w3.org:8888/outline/?doc=http://quirks.spec.whatwg.org/ that generates the outline on the server side
09:21
<zcorpan>
MikeSmith: why isn't the server-side thing used for the validator?
09:22
<zcorpan>
MikeSmith: can you flip the order of the outline and source checkboxes so they match the output?
09:23
<MikeSmith>
yeah can flip that
09:24
<MikeSmith>
and the I'm not using the server-side one directly yet is that it's harder to integrate on the server side
09:24
<zcorpan>
ok
09:24
<zcorpan>
looks nice!
09:25
<MikeSmith>
thanks
09:25
<MikeSmith>
also I'm more suspicious of the server-side code
09:25
<MikeSmith>
I didn't write it
09:25
<MikeSmith>
well, not most of it
09:25
<MikeSmith>
but I may have already spent more time rewriting it than it would have taken me to write it myself from scratch
09:30
<jgraham>
"01:36 < MikeSmith> Hixie: recent changes and subsequent bz bugs?" - I literally have no idea if that's bz as-in "Bugzilla" or "Boris"
09:31
<abarth>
Hixie: I think ascii, but you should check
09:35
<zcorpan>
jgraham: i haven't seen bugzilla abbreviated to bz
09:46
<jgraham>
zcorpan: They talk about the bzapi
09:47
<jgraham>
Which I don't think is for controlling Boris
09:47
<zcorpan>
oh
09:47
<zcorpan>
well you never know. I'm not convinced Boris is human.
09:47
<jgraham>
Indeed
09:50
Ms2ger
denies everything
09:55
<jgraham>
In unrelated news, tobie added something to testharness.js that required the use of ancestorOrigins in WebKit to avoid meaningless console spam. I don't think "happy with it" is quite accurate; it was horrible to have to make this workaround and the API wasn't a great fit. (See https://github.com/w3c/testharness.js/commit/e1918cae6e743247ad58842aae58196b229101c6#L0R2029 )
09:57
<annevk>
zcorpan: no
10:01
<zcorpan>
if ancestorOrigins exists because webkit doesn't throw on cross-origin access, i see little reason for other browsers to implement it
10:04
<odinho>
jgraham: All that strange code was added to testharness, -- is there some timeout where we can remove it again if it's not being used for these hypotetichal web services that'll gather results?
10:19
<jgraham>
I thought there was some use case that wasn't tied to the deficiencies of WebKit
10:21
<zcorpan>
there are use cases for getting your origin, but that's addressed by http://url.spec.whatwg.org/#dom-url-origin AFAICT
10:22
<zcorpan>
if there's a use case for knowing that you're in a cross-origin sandbox, i've probably missed it
10:39
<MikeSmith>
me sees lots of heycam|away code arriving for style@scoped
10:40
<MikeSmith>
https://bugzilla.mozilla.org/show_bug.cgi?id=508725#attachment_table
10:47
<jgraham>
zcorpan: I think the use case was something like widgets wanting to behave differently in same-origin vs different origin cases?
10:48
<jgraham>
In unrelated news, it seems that the postMessage change to testharness.js broke stuff
10:49
<zcorpan>
heycam|away: ideas for tests: style scoped as root element, style scoped with svg parent, in head, as child of the root, in quirks mode, changing scopedness and textContent in a timeout (not sure if onload happens after layout)
10:50
<zcorpan>
heycam|away: check CSSOM stuff together with scoped
10:51
<zcorpan>
heycam|away: interaction with !important
10:52
<zcorpan>
oh there were a couple of tests with !important
10:54
<darobin>
jgraham: you mean tobie's patch?
10:54
<zcorpan>
heycam|away: moving a style scoped element to another document
10:54
<jgraham>
darobin: Yes
10:55
<jgraham>
In particular tests that postMessage results from one frame/window to another will now get confused by extra messages coming from the harness
10:55
<jgraham>
As I said on #testing, I think the right solution is probably just not to postMessage on the document with testharness included but only on ancestors
10:58
<annevk>
I guess today I should tackle percent-encoded bytes :/
11:00
<darobin>
jgraham: mmmm, I reckon that actually makes sense yes
11:07
<zcorpan>
annevk: option 1 without the weirdness seems like the least insane option, though i'd be happy with 2
11:08
<annevk>
zcorpan: I think we need 2, and that means either deferring to Unicode for valid utf-8 sequence or defining it in Encoding (either way is pretty simple though)
11:08
<zcorpan>
annevk: ok
11:09
<zcorpan>
annevk: why do we need 2?
11:09
<annevk>
zcorpan: in particular 2 is likely needed for UI anyway, and if we need it there we might as well use it for a slightly better result
11:09
<zcorpan>
ok
11:11
<zcorpan>
annevk: isn't valid utf-8 sequence implicitly defined in Encoding as part of the decode algorithm?
11:11
<annevk>
although I guess the result is not that much better... if you really tried to put bytes higher than 0x7F over DNS you could not use this system anyway
11:11
<annevk>
zcorpan: yeah it is
11:11
<annevk>
zcorpan: seems nicer to give something to pattern match against though, but maybe you'd use the decoder for that anyway
11:12
<annevk>
maybe I should go with what Chrome has first and see if people complain...
12:01
<SimonSapin>
was colspan="0" removed in html?
12:03
<annevk>
"For the purposes of the CSS table model, the colspan and rowspan attributes on td and th elements are expected to provide the special knowledge regarding cells spanning rows and columns."
12:04
<annevk>
SimonSapin: and within the HTML table model it seems 0 and 1 are equivalent
12:05
<zcorpan>
i thought 0 was supported in one of rowspan or colspan
12:06
<annevk>
SimonSapin: oh, and it must be non-zero as conformance requirement
12:06
<annevk>
zcorpan: prolly rowspan then
12:09
<odinho>
I remember hearing implementations differ on it :-)
12:10
<zcorpan>
yeah. and gecko does (or did?) different things in quirks and non-quirks, iirc
12:21
<SimonSapin>
MDN documents colspan=0 as "extends until the end of the <colgroup>"
12:22
<SimonSapin>
which is the definition in html4
12:22
<SimonSapin>
(and is also what I want to do)
12:22
<annevk>
SimonSapin: what do implementations do?
12:23
<SimonSapin>
don’t know
12:23
<SimonSapin>
let me try
12:24
<SimonSapin>
0 is the same as 1 in Opera and Chromium; as in HTML4 in Firefox
12:25
<annevk>
and IE?
12:26
<SimonSapin>
I don’t have it available right now
12:26
<annevk>
be sure to test soon, HTML WG might declare consensus based on Opera/Chromium
12:26
<annevk>
and then... well nothing really
12:27
<annevk>
it's not like previous W3C RECs withstood the test of time
12:28
<annevk>
I kinda wish IDL had a participate box
12:30
<SimonSapin>
Here is a test case, if someone wants to test in IE : http://dabblet.com/gist/4117646
12:50
<annevk>
SimonSapin: IE9 I get the same as in Opera
12:50
<annevk>
SimonSapin: using http://netrenderer.com/ anyway
12:54
<SimonSapin>
annevk: treating colspan="0" like 1 is what is specified in HTML now, so no problem here
12:55
<SimonSapin>
But I’d still like to achieve the functionality
12:55
<SimonSapin>
huge values like colspan="999999" are to be ignored sometimes, colspan="99" seems to be ok
12:56
<Ms2ger>
I believe anything over a thousand or so is set to 1
12:56
<SimonSapin>
apparently
12:57
<annevk>
SimonSapin: do you want this for hand authoring tables?
12:57
<SimonSapin>
yes
12:57
<annevk>
http://encoding.spec.whatwg.org/#concept-encoding-get uses rowspan, but it's just computed in Python
12:57
<annevk>
I guess it would be kinda nice if I didn't have to do that
12:58
<SimonSapin>
I know the table currently has 5 columns so I can use colspan="5", but it’s been 4 and then 6 in the past hour before I changed my mind
12:59
<SimonSapin>
rowspan="0" is still supported
12:59
<SimonSapin>
at least in the spec
13:00
<annevk>
does that do what I need?
13:00
<SimonSapin>
yes
13:00
<annevk>
oh
13:00
<annevk>
:)
13:00
<annevk>
well maybe I'll replace that len(...) with 0 at some point
13:01
<SimonSapin>
and add some <tbody>s
13:01
<annevk>
oh you need <tbody>?
13:01
<annevk>
it uses <tbody> already for something
13:02
<SimonSapin>
"if its value is set to 0, it extends until the end of the table section (<thead>, <tbody>, <tfoot>, even if implicitly defined), that the cell belongs to."
13:02
<annevk>
ah so it wouldn't work
13:09
<marcosc_>
does anyone know if there is any practical difference between HTML's algorithm for parsing floats and ECMAScript's parseFloat()?
13:13
<jgraham>
Don't they disagree about scientific notation?
13:13
<jgraham>
1.2e7 and so on?
13:13
jgraham
didn't check
13:18
<marcosc_>
jgraham: yeah, that's what I'm wondering... but for most common cases I guess they are functionally the same (i.e., for parsing the value some attribute)
13:26
<Ms2ger>
marcosc_, yep, agree in the common case and disagree if you try
13:29
marcosc_
lazy, just wants to use parseFloat() for prototyping in a small parser
13:30
<darobin>
marcosc_: don't be a baby and go write a JS version of the HTML5 algo
13:31
<darobin>
then we can run coverage tools on that to see if we're testing it properly ;)
13:31
<marcosc_>
tools. will. save.
13:31
<annevk>
wasn't it the case that implementations used the JS algo?
13:31
annevk
forgot the details
13:32
<Ms2ger>
No
13:38
<annevk>
Ms2ger: what was the thing AryehGregor pointed out then?
13:38
<annevk>
Ms2ger: had something to do with number parsing too I believe
13:39
<Ms2ger>
Hmm? I think Aryeh suggested changing spec and implementations to use the JS algorithm instead
13:39
<annevk>
there were at least some implementations on his side
13:39
<annevk>
iirc
13:39
<Ms2ger>
Hmm
13:40
<marcosc_>
would be nice to have a single algo instead of two
13:40
<Ms2ger>
Was that about negative zero, maybe?
13:40
<annevk>
maybe it was floating point precision?
13:40
<annevk>
ooh, and maybe JS whitespace versus HTML whitespace
13:40
<annevk>
stuff like that
13:41
marcosc_
checks if he implemented the JS one
13:42
<marcosc_>
hmm... nope
13:54
<annevk>
heh
13:55
<annevk>
open DragonFly, > document.location.host="x"
13:55
<annevk>
hit cmd+back
13:55
<annevk>
crash
13:56
<annevk>
in Chrome if you do that a few times you end up at data:text/html,chromewebdata
13:56
<annevk>
Gecko just throws
13:56
<annevk>
Film at 11?
13:56
<annevk>
maybe there's something to be said for making Location members both Unforgeable and readonly
14:11
<marcosc_>
Hixie: I think there might be a mistake in the img@srcset parsing algorithm. In the "Descriptor parser:", where it says "If width is *not* absent, then let error be yes". But if a value is not absent and is valid, then it's not in error. When I follow the algorithm, I can't build the entry list with valid candidate entries. Note this also applies to height, and density. Or am I missing something?
14:14
<annevk>
width can only be not absent at that point if it's double
14:15
<annevk>
duplicated*
14:15
<annevk>
marcosc_: so you're missing something I think
14:21
<marcosc_>
annevk: to me that reads "if the width exists, then error = yes "
14:22
<annevk>
marcosc_: you're not reading it correctly then
14:22
<annevk>
marcosc_: it explicitly says to split the list on spaces, then to set various variables, including width to absent
14:22
<annevk>
marcosc_: then it says to process what you just split
14:23
<annevk>
marcosc_: if you start with the first token in what you just split, width is obviously still absent
14:23
<annevk>
marcosc_: simple English...
14:24
<marcosc_>
if it was simple English, we would not be having this discussion (i.e., please refrain from passably insulting me :) )
14:24
<annevk>
I'm saying it simple English because people have a tendency to read stuff into specifications that are not there
14:24
<marcosc_>
annevk: let me show you a 1 to 1 with code
14:26
<marcosc_>
annevk: https://github.com/ResponsiveImagesCG/picture-refimp/blob/master/srcsetfill.js#L369
14:27
<annevk>
yeah you're code is not doing what the English says
14:27
<annevk>
you need if(!width) error = 'yes';
14:28
<annevk>
or if (width == undefined) if you want to be more careful
14:28
<annevk>
your code, oh god
14:28
<marcosc_>
what's wrong with it?
14:28
<annevk>
I just told you?
14:28
<marcosc_>
right, but then you said "oh god"
14:29
<annevk>
because I made a typo
14:29
<annevk>
in spelling "your"
14:32
<annevk>
marcosc_: code looks well documented :)
14:33
<marcosc_>
annevk: I tried to keep the code 1.1 with the spec
14:35
<marcosc_>
annevk: but yes, I f'ed up it seems by using undefined instead of "absent"
14:36
<annevk>
euh no
14:36
<annevk>
using undefined is fine, you just didn't check for it
14:50
<zcorpan>
marcosc_: typo? ulr: rawCandidates[i].url,
14:50
<marcosc_>
zcorpan: thanks
14:50
marcosc_
debugging at the moment, first time I've managed to run the code
14:52
<zcorpan>
marcosc_: i hear from people who know js better than me that delete should be avoided
14:53
<marcosc_>
zcorpan: what's a good alternative?
14:53
<marcosc_>
just copy into new array?
14:53
<zewt>
github's javascript syntax coloring is the worst
14:54
<zewt>
grey on white is not okay
14:54
<marcosc_>
zewt: yeah, agree
14:54
<zewt>
zcorpan: well, presumably only if it's a hot code path; if not, that seems like premature optimization
14:56
<jgraham>
Right, I think I might make candidates a map and have a bool indicating whether it should be considered or not, but that might not be better
14:56
<zewt>
(not necessarily in the "making code more complicated by optimizing it" sense, but in the "thinking about performance in places where it doesn't matter" sense)
14:57
<jgraham>
Oh, so it is sort of a map already
14:57
<jgraham>
But yeah, this seems like it could be premature optimisation
14:59
<annevk>
marcosc_: so I would make error a boolean and use undefined or some such for the others...
14:59
<marcosc_>
annevk: ok, I'll add that
14:59
<annevk>
marcosc_: though I suppose that only matters if you want to make this a little faster
15:00
<zewt>
later, work
15:00
<marcosc_>
annevk: right now, I just want to make sure it's running as spec'ed... then I can optimize it. There is _a lot_ of redundancy in the spec (which is good for legibility and all that)
15:00
<annevk>
marcosc_: also, you check height after you set it...
15:01
<annevk>
marcosc_: which doesn't match the spec
15:01
<marcosc_>
annevk: you are looking at the latest version?
15:02
marcosc_
just checked in an update
15:02
<zcorpan>
this isn't about optimization. this is about not having to worry that farre will find your code, haunt you down and kill you slower than delete is slow.
15:03
<marcosc_>
:)
15:03
<Ms2ger>
Pseudonymity is useful in such cases :)
15:03
<annevk>
marcosc_: yes?
15:03
<jgraham>
Ms2ger: He might just kill everyone that can't prove they aren't you
15:04
<marcosc_>
that makes sense, I don't want to die.
15:04
<marcosc_>
annevk, ok, fixing
15:04
<annevk>
marcosc_: unless your latest commit is not "fixed typo and bug" and you fixed that
15:04
<Ms2ger>
jgraham, I'd just ask him if he can prove he isn't me :)
15:06
<marcosc_>
annevk: thanks, well spotted.
15:07
<jgraham>
Ms2ger: Well now he has a good way to tell if it is you or not
15:07
<Ms2ger>
So if he wouldn't ask himself... I give up
15:19
<Ms2ger>
Is http://dev.w3.org/html5/webvtt/ the canonical?
15:21
<annevk>
think so
15:58
<annevk>
http://annevankesteren.nl/2012/11/github-whatwg
15:58
<annevk>
wasn't quite sure what else to write down
15:59
<annevk>
in the process of writing that I found http://annevankesteren.nl/2004/11/whatwg-is-alive again which is kinda amusing
15:59
<annevk>
"There could be a place for what you call HTML 5.0 but it needs to be submitted to a standards body and approved by them once it is finished before we can start using it."
15:59
<marcosc_>
annevk: are you allowing people to file bugs on GH?
15:59
<marcosc_>
(i see that is currently enabled)
16:00
<annevk>
marcosc_: it's only enabled for whatwg/javascript I think
16:00
<marcosc_>
annevk: https://github.com/whatwg/xref/issues
16:01
<darobin>
"you can't rely on HTML alone these days"
16:01
<darobin>
shorter annevk: "in the Netherlands, we don't need your stinky document conformance criteria"
16:02
<marcosc_>
"Pardon me for not seeing the point of HTML5.0. I see XHTML as the rightful heir of HTML."
16:02
<marcosc_>
heh
16:03
<annevk>
marcosc_: I guess I haven't disabled it for that one, but that should prolly stay there as there's no alternative
16:03
<annevk>
marcosc_: though I'll close the wiki, thanks
16:03
<jgraham>
In related news, I see myself as the rightful heir of Arthur, legendary king of England
16:05
<darobin>
annevk: reckon HTML might move to GH at some point?
16:05
<annevk>
darobin: my magic eight ball says no
16:05
<jgraham>
darobin: Good luck convincing Hixie of that
16:05
<darobin>
oh, I wasn't planning on trying to convince anyone — just curious
16:06
<annevk>
darobin: only thing I considered was setting up a mirror, but wasn't sure what the use would be
16:06
<darobin>
the W3C repo has a git-happy copy anyway
16:06
<darobin>
annevk: a copy would only make sense if you plan on taking pull requests there
16:06
<darobin>
and I'm guessing that's not really the spirit
16:07
<annevk>
darobin: it is the spirit for many of the stuff WHATWG writes these days, but Hixie has a different preference
16:08
<darobin>
I know, I know, as I said I was just curious
16:09
<annevk>
fair enough, I thought of actually mentioning it in the blog post, but explaining that took too much text, but now I wrote all these lines maybe I should have done it :)
16:11
<darobin>
hahaha
16:16
<annevk>
darobin: so https://github.com/w3c/html/commits/feature/whatwg is your WHATWG copy right?
16:17
<annevk>
seems to match the commits in any case
16:21
<darobin>
annevk: yeah, that should be it
16:21
<darobin>
there are further branches that are subsets of that
16:22
<darobin>
I don't know how often it's updated, I think hourly or so
16:22
<darobin>
at any rate it's never far behind
17:10
<TabAtkins>
heycam|away: Re <style scoped>, the effects on the cascade are now well-defined in the Cascade spec. Please either match it or file bugs on us with arguments to change. ^_^
17:23
<GPHemsley>
Argh, Apache. Why you gotta be so frustrating?
17:29
<GPHemsley>
There is apparently no way to turn off Apache's type-detection-by-file-extension behavior.
17:30
<GPHemsley>
oh! maybe I spoke right too soon!
17:32
<GPHemsley>
ahh... :)
17:32
<GPHemsley>
so simple: RemoveType
17:32
<GPHemsley>
(but off in another part of the docs)
17:34
<annevk>
don't use a file extension?
17:35
<GPHemsley>
annevk: I'm testing whether browsers assume anything from it.
17:38
<matjas>
annevk: can haz link to the javascript spec on http://www.whatwg.org/specs/?
17:39
<annevk>
matjas: Hixie can arrange that
17:42
<GPHemsley>
oh, hmm...
17:42
<GPHemsley>
I'm realizing now that I'm not testing any mismatches
17:43
<_divya>
matjas: are you an editor these days?!
17:44
<annevk>
_divya: uhuh, when do you start?
17:44
<matjas>
_divya: i’ve been working on that spec occasionally since August or so
17:45
<matjas>
_divya: anyone can become an editor! http://annevankesteren.nl/2012/11/github-whatwg :)
17:45
<_divya>
annevk: i only gossip about specs.
17:45
<_divya>
who wants to do the hard work
17:45
<matjas>
haha
17:45
<_divya>
matjas: very nice!! I want to say congratulations but unsure of what the official stance of whatwg/w3c is
17:45
<annevk>
heh, I wish we had weekly gossip magazines about specs, that'd be great
17:46
<_divya>
isnt that w3cmemes annevk?
17:46
<annevk>
only @mattur is left I think
17:46
<_divya>
ahahaha
17:46
<_divya>
yes
17:46
<annevk>
ah yeah @w3cmemes is there
17:46
<_divya>
and steve faulkner
17:46
<annevk>
no more mr last week
17:46
<_divya>
that was a bit weird
17:47
<annevk>
and there's the occasional culture clash
18:42
<annevk>
TabAtkins: I think TC39 reads public-script-coord, but we'll see
18:42
<[tm]>
speaking of culture clashes, i normally disagree with pretty much everything Great Leader Roy says, but in pretty much every discussion about DNT, dude is speaking the gospel truth
18:42
<annevk>
TabAtkins: that was sort of my idea behind posting it there
18:43
<[tm]>
e.g., http://lists.w3.org/Archives/Public/public-tracking/2012Nov/0290.html
18:44
<Ms2ger>
[tm], damn gray, black&white is much easier
18:45
<[tm]>
Heh
18:45
<[tm]>
yeah
18:47
<TabAtkins>
annevk: kk
18:48
<TabAtkins>
annevk: Alex Russell makes the point that we might not need to really do the stringifying eagerly in this case - we can wait and do it upon requesting things instead. Thoughts?
18:48
<TabAtkins>
(This isn't a general argument - there are definitely cases where you need the values to be eagerly checked/converted.)
18:48
<annevk>
that doesn't work, you directly manipulate the URL
18:48
<TabAtkins>
Ah, yeah.
18:49
<annevk>
and even if you did set a string, it needs to be further converted
18:49
<TabAtkins>
Okay, that's what I thought.
18:49
<annevk>
e.g. lone surrogates need to be replaced with U+FFFD, "&" needs to be escaped, etc.
18:49
<TabAtkins>
Cool, thanks, I'll argue appropriately.
19:00
<annevk>
TabAtkins: seems you might also have to argue with TC39
19:00
<annevk>
TabAtkins: also, I'm not sure I want to wait for ES7 before getting this in browsers; I was actually hoping to have this specced within one or two months
19:04
<TabAtkins>
annevk: Yes, I'm willing to do that arguing. And also to get this resolved in a short period of time. ^_^
19:04
<annevk>
cool
19:04
<annevk>
I guess my writing won't be impacted by much of it, I'll just keep in mind it needs to tie into something at some point
19:04
<Velmont>
Upgrading my Piwik. Find it funny that a new fix disables DNT header and still tracks, if the user agent shows that it's IE10. Because they set DNT on to standard, Piwik won't respect it :-)
19:05
<annevk>
Apache did that too, I think that's one of the bad things Roy did <- [tm]
19:06
<Velmont>
Nah, I think Microsoft was totally in the wrong.
19:06
<Velmont>
How would it even be useful when it's on by default?
19:06
<Velmont>
Then you don't actually get only the crazies that care about it, -- but even your father and everyone else who doesn't really care.
19:22
<annevk>
huh? nobody wants to be tracked
19:28
<Velmont>
annevk: you crazy :D
19:34
<annevk>
I think I might be
19:34
<annevk>
I somehow ended up on http://www.koalastothemax.com/ and moved the mouse around until I saw a dog, then reloaded and did it again, only to see an owl
19:35
<TabAtkins>
That's the best site.
19:51
<annevk>
Hixie: btw, these longer diff lines suck on the iPhone
19:51
<annevk>
Hixie: but maybe not on the iPhone 5... hmm
19:57
<Hixie>
annevk: dude, who reads diffs on a phone -_-
19:58
<annevk>
Hixie: who edits the HTML spec with the ultimate goal of controlling his model train set?
20:04
<Hixie>
annevk: details
20:10
<annevk>
btw, I finally found where that " " makes the host invalid comes from: http://tools.ietf.org/html/rfc3454#appendix-C
20:10
<annevk>
of course, per IDNA2008 that's no longer used
20:20
<gsnedders>
Hixie: Has your train set got out of a box yet?
20:21
<gsnedders>
Or are you still working on the HTML side of things in the first instance? :)
20:32
<Hixie>
"train set"
22:10
<heycam>
TabAtkins, thanks for the pointer to css3-cascade. I think my patches do match what you've got in there.
22:11
<TabAtkins>
heycam: Cool.