00:03
<JonathanNeal>
( in the event you had a table in a table )
00:04
<JonathanNeal>
Also, "style" won't take when defineProperty'd on Node, Element, or HTMLElement.
00:06
<Velmont>
Hm. If I hadn't used both odinho and Velmont as nick, I'd be on the list and not have two entries on the "didn't really make the cut". :-)
00:10
<JonathanNeal>
makes me wonder about creating a .css that returns the computedStyle but also accepts being overwritten.
00:20
<Hixie>
if a <table> has a <thead> with some <th>s in it, and then has some <tr>s and <tbody>s interspaced (as in, tr, tr, tbody-with-tr-tr-tr, tr, tr, another tbody-with-tr-tr, etc), and you try to sort a column
00:20
<Hixie>
the trs in each tbody need to be sorted within the tbody
00:20
<Hixie>
the tbodies don't move themselves
00:20
<Hixie>
but what about the trs that are children of the table itself?
00:20
<Hixie>
do they sort all together and end up above the tbodies?
00:21
<Hixie>
do they sort only within the sequence they're in?
00:21
<Hixie>
so first we sort the first two trs, then the tbody's three trs, then the two trs, then the next tbody's trs, etc?
01:03
<TabAtkins>
Oh man, you actually care about which tbody the tr is in?
01:03
<TabAtkins>
:/
01:03
<Hixie>
only because it's the easiest solution so far, i'm wide open to being convinced we should do otherwise
01:03
<TabAtkins>
I have no opinion on whether you should sort the naked trs all together or per-sequence.
01:04
<TabAtkins>
Right solution is to rewrite the dom into a single tbody containing all the sorted rows. ^_^
01:04
<zewt>
i don't think i've ever used more than one tbody, so i have no idea what makes sense for sorting
01:04
<TabAtkins>
I've only used them for styling purposes.
01:04
<Hixie>
TabAtkins: why would the author bother to use two <tbody>s in that case?
01:04
<TabAtkins>
Man, I dunno.
01:05
<Hixie>
consider the table at http://www.whatwg.org/specs/web-apps/current-work/#the-input-element
01:05
<zewt>
seems vaguely weird to move tr's between tbody's, since you're changing the tree structure (eg. events propagate up a different list of parents)
01:05
<zewt>
oh god i loaded that in firefox again
01:06
<Hixie>
(note, i have no answer for how you keep the tbody headings in the right place on that table)
01:07
<Hixie>
that table does seem to argue for supporting each tbody as being its own sorting domain
01:08
<zewt>
(i'd force the headings to the top by giving it a sort key of "")
01:08
<Hixie>
what if the user reverses the sort order?
01:08
<zewt>
mm
01:08
<zewt>
make them separate tbody's?
01:09
<Hixie>
that seems dubious
01:09
<Hixie>
i think something about the spanning should probably suffice
01:09
<Hixie>
or the scope
01:09
<Hixie>
but anyway
01:09
<Hixie>
not worried about that for now
01:10
<TabAtkins>
Yeah, sorting the tbodys separately does seem the right idea.
01:11
<TabAtkins>
But I still have no clue about sorting the naked trs separately or together.
01:11
<zewt>
unrelated: is the default text sort case-insensitive?
01:11
<Hixie>
i'll just sort sequences of them
01:11
<Hixie>
zewt: currently that's my plan but again, that's just cos nobody has argued otherwise
01:12
<zewt>
(for most regular-user stuff it's probably best)
01:12
<TabAtkins>
It probably makes the most sense, yeah.
01:13
<zewt>
turn on sorting for all tables on random pages that use tables for layout, just for entertainment
01:14
<zewt>
welcome to the picassoweb
01:14
<TabAtkins>
Haha, nice.
01:14
<TabAtkins>
They'd all end up sorting by string, generally, I assume.
01:31
<TabAtkins>
Signing off for 2 weeks. See you all on Jan 8th!
04:18
<JonathanNeal>
No more Tab.
05:01
<JonathanNeal>
http://secure.codepen.io/joe/fulldetails/KIgFx Hixie console.log(document.body.css) I think it's exactly what you wanted (but under the wrong namespace).
09:16
<MikeSmith>
Ms2ger: refixed http://w3c-test.org/html/
09:16
<MikeSmith>
I think the fix will take this time
09:17
<MikeSmith>
problem yesterday was, it turned out the cause was something that got rsynced over from dvcs.w3.org
09:18
<MikeSmith>
and I had made the change locally, so the next rsync just ended up clobbering it
09:19
<MikeSmith>
but I think Robin has removed it now from dvcs.w3.org, so should not show up again
09:57
<Ms2ger>
Ah, fun
09:57
<Ms2ger>
MikeSmith, thanks!
10:25
<annevk>
Oh, sortable is being drafted already
11:16
<annevk>
Hixie: requiring <thead> seems overkill for simple tables
11:16
<annevk>
Hixie: also, there's a number of xref problems and some missing <dfn> around the new members
13:01
<Ms2ger>
Anyone feel like reviewing some bug fixes? https://github.com/w3c/html-testsuite/pull/12
13:06
<annevk>
your bug fix seems to remove the original test
13:07
<annevk>
in particular you no longer test the relation between the content and IDL attribute
13:07
<annevk>
oh you do, but the reverse
13:07
<annevk>
sorry
13:14
<Ms2ger>
I removed a part that just wasn't backed by the spec
13:22
<heycam>
Ms2ger, re your question about testharness.js tests for SVG
13:23
<heycam>
Ms2ger, we are just starting to get our SVG 2 test suite together
13:23
<Ms2ger>
I asked something about that?
13:23
<heycam>
(I think so?)
13:23
<heycam>
Ms2ger, and I haven't written any testharness.js tests before; do they relate to the Shepherd-run reftests?
13:23
<heycam>
or are they completely separate/
13:23
<Ms2ger>
testharness.js is for JS tests, reftests are rendering tests :):
13:24
<heycam>
ok :)
13:24
<heycam>
but they don't use the reftest harness at all
13:24
<heycam>
well
13:24
<heycam>
does the shepherd harness do automatic reftest testing yet?
13:24
<Ms2ger>
Automatic? No
13:25
<Ms2ger>
Ah, here it is
13:25
<Ms2ger>
Do you have a repository set up?
13:25
<heycam>
Ms2ger, you asked here https://bugzilla.mozilla.org/show_bug.cgi?id=816778#c47
13:25
<Ms2ger>
Yeah, just found that
13:25
<heycam>
oh that's like already a week ago
13:26
<heycam>
my how time (and email inbox buildup) passes
13:26
<heycam>
Ms2ger, so we have http://svgwg.org/hg/svg2-tests/
13:26
<heycam>
Ms2ger, which I think has the right directory structure for shepherd
13:27
<Ms2ger>
Ugh
13:27
<heycam>
though we don't have sheperd configured to present our tests anywhere
13:27
<heycam>
(and we haven't started importing our SVG 1.1 tests there yet)
13:27
<Ms2ger>
I don't think shepherd actually requires such a silly directory structure, and if it did, it'd have to be changed for html/webapps anyway
13:28
<heycam>
for testharness.js tests?
13:28
<heycam>
(I'm assuming webapps tests don't have any reftests?)
13:28
<Ms2ger>
HTML has some
13:28
<heycam>
ok
13:28
<heycam>
do you have link?
13:28
<Ms2ger>
https://github.com/w3c/html-testsuite
13:28
<heycam>
I'll just copy the location/directory structure
13:29
<heycam>
nice unicorn
13:29
<Ms2ger>
We just got rid of the approved/contributors stuff
13:29
<heycam>
ah it's loaded now
13:29
<heycam>
I see
13:29
<heycam>
I think we'll see how we go in terms of WG approval/review of tests for us
13:29
<Ms2ger>
Instead, pull requests
13:29
<heycam>
seems easiest just to copy CSS for the moment
13:30
<heycam>
fair enough
13:30
<Ms2ger>
Fwiw, I tend to think we should just throw everything in one repo
13:30
<heycam>
(though we aren't using github of course)
13:30
<Ms2ger>
Anyway, want to submit dzbarsky's test?
13:31
<heycam>
yeah I will
13:31
<heycam>
once I sort out our repo
13:31
<heycam>
but I guess we don't have a syncing script like the one for reftests/w3c-css/
13:31
<heycam>
?
13:32
<heycam>
Ms2ger, do you use the same format for these js tests too? I see like <link rel=author>, <link rel=help>, etc.
13:32
<Ms2ger>
We have a syncing script under dom/imptests
13:33
<Ms2ger>
links are optional, because they're not terribly useful
13:33
<heycam>
yeah I'm kind of skeptical about manually maintained metadata
13:34
<heycam>
perhaps I should just read the code in there, but do the importing scripts require a particular directory structure or anything?
13:34
<Ms2ger>
No
13:34
<Ms2ger>
Just a MANIFEST file
13:35
<heycam>
ok
13:35
<heycam>
and it just copies those files
13:35
<Ms2ger>
Yep
13:35
<heycam>
ok cool, sounds easy :)
13:35
heycam
will look into that
13:36
<Ms2ger>
It should be easy, I'm lazy :)
13:37
heycam
is three glasses of wine in at at 12:30am so is not going to try now
13:38
<Ms2ger>
Oh, AM, that makes more sense :)
13:42
<annevk>
Ms2ger: all tests in one repo?
13:42
<Ms2ger>
Yeah
13:42
<annevk>
Ms2ger: I tend to agree
13:42
<annevk>
but I haven't done much with tests...
13:43
<Ms2ger>
Maybe you should ;)
13:59
<annevk>
Yeah one day. I should do a set of tests for Encoding and URL...
13:59
<annevk>
In other news, this prototype stuff... What does document.open() do with that? If you keep the document, but the global object is replaced, are the prototypes weird?
14:00
<annevk>
Hmm, running out of time...
14:06
<Ms2ger>
bz can tell you stories about that, I'm sure :)
16:37
<Hixie>
gsnedders: pretty sure the people editing the w3c spec don't know either (Re your tweet)
16:38
<Hixie>
annevk: requiring <thead> is because otherwise you have to handle <th>s in weird places
16:39
<Hixie>
annevk: e.g. if you have <tr><th><td> <tr><td<td> <tr><td><th> <tr><td><td>
16:39
<Hixie>
not sure what should happen in that case
16:40
<Hixie>
gsnedders: (in particular, i'm almost certain none of them have read the spec cover to cover in the first place; the CR has all kinds of weird stuff that makes no sense e.g. parts of ping="")
16:42
<gsnedders>
Yeah, I'd rather got that impression.
16:43
<gsnedders>
Oh well, time for me to work out how I'm getting to my parents. Flooding and landslides makes this... interesting.
16:44
<Hixie>
enjoy
16:44
<gsnedders>
On the whole I expect I'll just stay here another day, but currently trying to figure out diversions of trains to work out how late they'll be running.
16:45
<gsnedders>
And maybe take a coach. Easier to divert them. :)
16:50
<Hixie>
oh, around the water
16:50
<Hixie>
i thought you meant you wanted to hijack one or something
16:51
<gsnedders>
I'm sure my lack of any practical experience driving would help with that :)
17:28
<volkmar>
according to the specs, what should happen if I do: input.valueAsNumber=NaN (for a type='number' and type='date')
17:29
<volkmar>
setting seems to always assume the new value is valid
17:32
<Hixie>
yeah, that's bogus
17:32
<Hixie>
heycam|away: here's another example of wanting a different setter type than getter type
17:32
<Hixie>
heycam|away: i want to return NaN sometimes (unrestricted double), but the setter needs to just be double
17:33
<gsnedders>
NaN is a double by most defintiions.
17:33
<Hixie>
not WebIDL's
17:33
<gsnedders>
Shows what I know :)
17:33
<Hixie>
volkmar: i filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20496
17:34
<Hixie>
volkmar: if you're implementing, assume it will be fixed to treat NaN/Infinity the same way as a WebIDL "double" would
17:34
<Hixie>
(which i think means TypeError is thrown)
17:35
<volkmar>
hmm, ok
17:36
<volkmar>
right now our implementation is setting the empty string if NaN is passed
17:36
<Hixie>
i could see an argument for that behaviour
17:36
<Hixie>
how about Infinity?
17:37
<volkmar>
let me check
17:37
<Hixie>
(i added a comment to the bug)
17:44
<volkmar>
Hixie: seems like we handle Infinity like NaN
17:44
<Hixie>
that seems a bit less justifiable
17:45
<volkmar>
indeed
17:45
<volkmar>
but I don't really not what would make sense
17:45
<Hixie>
i think Infinity should just throw TypeError
17:45
<Hixie>
i could buy NaN setting the value to "" though, that seems somewhat useful
17:46
<Hixie>
that'd be my recommendation, anyway
17:46
<Hixie>
it's your call really :-)
17:46
<volkmar>
eh
17:47
<Hixie>
if you do something other than Infinity=>TypeError, NaN=>"", please do comment on the bug so i make sure to make the spec match implementations
17:47
<volkmar>
I think I will do that
17:47
<volkmar>
will try to update the bug
17:47
<Hixie>
excellent
17:47
<Hixie>
thank you sir
17:47
<volkmar>
yw
18:16
<Hixie>
is there some name for the level of a key in a sort? i.e. a secondary key's ___ is 2, a primary key's ___ is 1, a tertiary key's ___ is 3, etc
18:16
<Hixie>
the key's ordinality, maybe?
18:22
<Hixie>
should <tr><th sorted="1">A <th sorted="3"> B</tr> be valid? (i.e. skipping ordinalities)
18:28
<Hixie>
huh, autocomplete is case-insensitive
18:28
<Hixie>
was that intentional, i wonder
18:29
<Hixie>
ah, yes.
18:29
<Hixie>
ok
18:56
<Hixie>
if we sort the following table: <table>....<tbody><tr><td rowspan=2>B</tr><!----><tr></tr><tr><td>A</table>
18:56
<Hixie>
...what should the resulting DOM look like?
18:57
<Hixie>
the B row and the next row are kept together, but are they kept together along with the comment between them?
18:57
<Hixie>
i'm thinking no.
19:15
<Ms2ger>
gsnedders, hey, bz's latest email on www-dom sounds like something you'd know about
19:21
<gsnedders>
Ms2ger: If you say so.
19:21
<Ms2ger>
I did :)
19:21
<Ms2ger>
Or at least find someone who does :)
19:25
<gsnedders>
Ms2ger: Or I don't know and can look :)
19:26
<Ms2ger>
Thanks :)
19:27
<gsnedders>
(I believe we never change, off hand)
19:27
<gsnedders>
(In case I vanish)
19:31
<Ms2ger>
That would be unfortunate
19:42
<gsnedders>
Ms2ger: Emailed, if you so care.
19:44
<Ms2ger>
Thanks
21:52
<SimonSapin>
annevk: "The encoding attribute must return the encoding." That’s the encoding *name*, right?
21:53
<SimonSapin>
In http://encoding.spec.whatwg.org/#dom-textdecoder-encoding
22:05
SamB
wonders about the point of this step in the font type pattern matching algorithm: Let the byte sequence to be matched be the byte sequence to be matched.
22:15
<Hixie>
SamB: is part of that a variable name or something? (e.g. in italics, if using a graphical browser?)
22:16
<SamB>
Hixie: well, I didn't *spot* anything formatted differently on one side than the other ...
22:16
<Hixie>
dunno then
23:19
SamB
doesn't get why I-Ds expire so quickly ...
23:32
<Hixie>
gsnedders: where do we expose GC behaviour?
23:32
<Hixie>
i thought we'd worked pretty hard to not expose it at all
23:33
<gsnedders>
Hixie: getElementsByTagName NodeList
23:36
<Hixie>
that's more exposing caching behaviour than GC behaviour
23:37
<Hixie>
no?
23:37
<Hixie>
i mean i guess they might be correlated
23:37
<gsnedders>
But you can observe when GCs happen due to cache invalidation happening at the same time, no?
23:40
<Hixie>
i guess if you put a property on the object, then keep no references, then keep asking for the object and checking if there is a property on it...
23:40
<Hixie>
but there doesn't have to be a correlation between GC and caching there
23:41
<Hixie>
the UA could start returning a new object even when the other isn't GCed, and could have a strong reference from the cache to the object
23:41
<gsnedders>
I'm going to claim that either way exposing caching behaviour in such a way is bad.
23:50
<zewt>
i'd call those basically equivalent problems
23:50
<zewt>
that is, exposing nondeterministic, implementation-specific behavior is bad (and GC just happens to be the most common manifestation of that)