00:46
<TabAtkins>
deadowl: ...why should they be synonymous? One's a time, one's a date, one's a datetime.
00:47
<TabAtkins>
The meeting takes place every day at 2pm. The next meeting is on Dec 20. The next meeting is at 2pm, Dec 20th.
04:01
<deadowl>
TabAtkins: javascript Date and html time both represent datetime.
08:19
<zcorpan>
is there a test suite for URL constructor?
08:20
<zcorpan>
annevk-cloud: why does URL throw TypeError and not SyntaxError when resolving fails?
08:55
<zcorpan>
"The SVG Working Group would like to thank the following people for contributing to this specification by raising issues that resulted in changes: David Zbarsky."
08:55
<zcorpan>
nice, http://www.w3.org/TR/SVG2/single-page.html#linking-processingIRI has a list i was looking for. wonder if it is complete
08:57
<zcorpan>
i guess i only need to test stuff that allow non-local
09:10
<zcorpan>
nice of svg 2 to reference dom core level 2
09:13
<zcorpan>
should we move click() to Element?
10:50
<odinho>
Ms2ger: lol, what you did! Sneaky.
10:50
<Ms2ger>
:)
10:50
<Ms2ger>
I thought you were complaining you couldn't see them!
10:50
<Ms2ger>
And if you don't believe that, I'll invent something else :)
10:51
<odinho>
I know how to use critic :P
10:51
<Ms2ger>
They really just need someone to double-check that what the old thing did with the documentation, really
11:35
<annevk-cloud>
zcorpan: better ES compat in case it ever moves to ES
11:36
<annevk-cloud>
zcorpan: see also various exception threads
11:37
<annevk-cloud>
zcorpan: as for the URL thing, HTML does that, look at the title/xref terms
12:13
<zcorpan>
annevk-cloud: i don't follow re look at the title/xref terms
12:51
<annevk-cloud>
zcorpan: ask again next week / file a bug
12:51
<zcorpan>
ok
14:21
<zcorpan>
what pass condition should i use for SVG? utf-8 or document's encoding? gecko uses document's encoding. blink uses document's encoding except for <image> which uses utf-8. presto uses utf-8 except for <a> which uses document's encoding
14:22
<Ms2ger>
<annevk> utf-8
14:22
Ms2ger
ducks
14:24
<odinho>
utf-8 ALL the things
14:27
<zcorpan>
i'm tempted to agree with Hixie that it might be better to be consistent and apply the quirk everywhere. imo including css and svg
14:31
<jgraham>
+1 or consistency
14:31
<jgraham>
*for
14:43
<zcorpan>
jgraham: can you say that in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23968 or so? :-)
14:43
<Ms2ger>
Your +1s have no power here! ;)
14:46
<zcorpan>
so far it seems like implementors used dice to decide which encoding to use for a given feature
14:48
<darobin>
at least the could document which type of die
14:50
<Ms2ger>
A d3
14:54
<darobin>
heh
18:42
<MikeSmith>
ensafened
18:44
<annevk-cloud>
I don't really buy the consistency thing. At an architecture level it means you have to keep around the encoding longer and pass it all over. For CSS we could probably avoid having to do that.
18:48
<odinho>
agree. and then also let it soread to other places due to the same consistenxy argument.
18:49
<odinho>
spread :]
18:49
<jgraham>
annevk-cloud: I don't think that
18:49
<jgraham>
's an argument that it's not more consistent
18:49
<jgraham>
It might be an argument that it's harder to implement
18:50
<TabAtkins>
I think he means that he doesn't find the consistency argument sufficiently worthwhile, and one of the reasons is the implemention difficulty.
18:50
<TabAtkins>
Also: fuck it all, utf-8 4 lyfe
18:54
<jgraham>
Well that
18:54
<jgraham>
's not rea;;y what "not buying" something means
18:58
<TabAtkins>
Sure it can.
18:59
<Ms2ger>
Anyway, just make arguments instead of arguing over what arguments could have been made?
20:09
<jgraham>
I don't know what other arguments there are. If you don't believe that making different parts of the platform behave differently given the same input is going to be more confusing for authors than not doing that it doesn't seem like there is much I can say that will convince you.
20:11
<jgraham>
The main counter argument seems to be "but the behaviour is not what we would design today". Well yeah, but if you can't deal with the legacy don't work on the web platform I guess.
20:17
<TabAtkins>
That's always the argument, though. Lots of features have a conflict between "shitty past" and "hopefully less shitty future", and we always have to decide which we want to follow.
20:18
<TabAtkins>
"shitty past" isn't a priori better - it does create consistency, but makes it harder to work with in other ways.
20:28
<jgraham>
In this case the author is literally using the same input in two different places. Making that work differently is more confusing than, say, creating an entirely new API to replace an existing API with bad design, or other cases where you might have a legacy-vs-future conflict
20:28
<tantek>
TabAtkins - I think the "consistency" in the "shitty past" is often what's up for debate/discussion.
20:29
<tantek>
if the "shitty past" is either inconsistent, or shrinking quickly (who cares if IE6 did it that way?), then it may be worth the trade-off to ignore it.
20:29
<TabAtkins>
jgraham: Of course, just telling the author "always use utf-8", like we've been doing for years (and gradually winning on!) makes it all consistent too.
20:29
<tantek>
agreed on telling authors "always use utf-8". that does seem to be working.
20:30
<jgraham>
TabAtkins: Sure, which is even more reason not to make misguided attempts to "fix" things for rare cases
20:30
<TabAtkins>
jgraham: That doesn't follow.
20:31
<TabAtkins>
Telling authors works, and it's supported by making a number of resources utf-8 only. It may be that making more resources utf-8 only would help the momentum of the process.
20:58
<jgraham>
So your position is that we should actively break stuff if you don't use utf8?
21:07
<TabAtkins>
Minor breakage is often a useful tool, yes.