00:00
<rniwa>
arv: as far as I read the spec, the spec doesn't provide anyway to get selection inside the shadow DOM ;(
00:00
<rniwa>
:'(
00:00
<rniwa>
arv: meaning that we can't implement any editing widgets inside the shadow DOM
00:00
<smaug____>
selection inside shadow dom is tricky
00:01
<smaug____>
what if user starts outside, then tries to continue selection to inside shadow dom
00:01
<rniwa>
smaug____: it shoudln't allow it
00:01
<smaug____>
gecko just doesn't allow that
00:01
<rniwa>
smaug____: I don't think selection that crosses shadow boundary makes much sense
00:01
<rniwa>
smaug____: it should act as if there's editing boundary
00:02
<smaug____>
well, it depends
00:02
<smaug____>
if UI looks like it should be selectable, it is quite strange for user to not be able to select it
00:04
<smaug____>
IIRC mozilla bugzilla hass bugs open because of this
00:04
<smaug____>
s/hass/has/
00:04
<smaug____>
(the bugs might become wontfix)
00:59
<gsnedders>
TabAtkins: The general reason to put stuff on the prototype is because then you only have a single function object, not n function objects for n objects
01:00
<gsnedders>
Esp. when JIT'd code is linked to function objects, that's important. A bit less so in the built-in function object case.
01:02
<gsnedders>
rniwa, if you read logs, too
01:02
<gsnedders>
and AryehGregor ^^
01:06
<TabAtkins>
gsnedders: Yeah, I agree that's the reason normally.
01:08
<gsnedders>
In this case it's mainly making it easier to override the behaviour, by replacing a single function, and not having needless function objects eating memroy
01:09
<TabAtkins>
In that case I'm back to wondering why the getters/setters establish own properties.
01:09
<gsnedders>
This is in WebIDL?
01:09
<gsnedders>
Or what?
01:09
<gsnedders>
Because there's no reason for that to be.
01:10
<TabAtkins>
Yes.
01:10
<TabAtkins>
The WebIDL getter/setter extended operations establish own properties.
01:10
<gsnedders>
(__proto__ will be an accessor property (i.e., a property with a getter and/or setter) on Object.prototype in ES6, probably)
01:10
<gsnedders>
(For example)
01:56
<erlehmann>
helo again
06:24
<rniwa>
AryehGregor: are you there?
08:39
<RobbertAtWork>
multiple selections can be used to programmatically deselect readonly parts of the users selection
08:39
<RobbertAtWork>
cc: AryehGregor
08:47
<hsivonen>
http://botornot.net/project/test correctly identifies @whatwg as a bot with human tendencies
08:51
<annevk>
should do some replies then!
08:57
<zcorpan>
annevk: automated replies?
09:47
<annevk>
well I do the retweets manually already
09:48
<annevk>
but I think the policy is to do replies from personal accounts
09:52
<annevk>
ok, so now in Gecko cloneNode defaults to true
09:56
<annevk>
I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16102 on removing DOMStringList from Microdata
09:57
<bga>
http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx
09:58
<annevk>
is Clipboard.types no longer defined anywhere?
09:58
<annevk>
I guess that is now DataTransfer.types?
09:58
<annevk>
because if we also change Document.styleSheetSets and Indexed DB, DOMStringList can be removed from the platform
10:05
<annevk>
oh, I think glenn put cssom-view in public domain
10:05
<annevk>
sweet
10:05
<annevk>
http://dvcs.w3.org/hg/cssom-view/rev/d977913408be
10:06
<annevk>
anyone here still subscribed to www-style who can lobby for removing DOMStringList usage from CSSOM?
10:06
<annevk>
Document.styleSheetSets uses it
10:06
<annevk>
should just become an array
10:07
<zcorpan>
annevk: don't need to be subscribed to send email to www-style
10:08
<annevk>
it's easier for potential follow up though
10:08
<zcorpan>
just send from noreply⊙an and set reply-to: www-style⊙wo :-)
10:39
<annevk>
zcorpan: meh, ok done
10:39
<annevk>
zcorpan: though not like that
10:41
<Ms2ger>
Didn't we just get pywebsocket installed on w3c-test?
10:42
<jgraham>
Yes, but there are still open questions about that
10:42
<jgraham>
e.g. is it actully safe to run when it clearly says in the source that itsn't
10:42
<jgraham>
*it isn't
10:44
<Ms2ger>
Since you know about this, reply to Kris please? :)
10:45
<jgraham>
and say what?
10:45
<annevk>
is there some kind of holiday going on btw?
10:45
<annevk>
or are people just getting tired of twitter?
10:45
jgraham
hopes for that latter, expects the former
11:27
<Taggnostr>
if I want to report bugs about the HTML5 standard, should I select "HTML WG" as "product"?
11:40
<Ms2ger>
Sure
11:41
<Taggnostr>
I hope I got everything right: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16106
11:41
Taggnostr
moves on with the next bug
11:42
<Ms2ger>
lgtm
11:43
jgraham
doesn't like lgtm because it it too close to lmgt
11:43
<jgraham>
As in "Let Me Google That for you"
11:43
<Ms2ger>
Lockeed Martin Global Telecommunications?
11:44
<Taggnostr>
there's also lgbt, but that's another thing
11:52
<Taggnostr>
is "Validator (Nu)" the right product for bugs about http://livedom.validator.nu/ ?
11:53
<Ms2ger>
I think so
11:53
<Taggnostr>
ok, thanks again
12:00
<Taggnostr>
I think I'll wait a reply to #16106 before opening the next one
12:00
<Ms2ger>
Heh
12:00
<Ms2ger>
Don't expect one before July or so
12:01
<Taggnostr>
is Hixie on holiday?
12:03
<Ms2ger>
Just lots of outstanding feedback that's before you in the queue: http://www.whatwg.org/issues/data.html
12:10
<Taggnostr>
I think most of the ranges I listed in #16106 should return U+FFFD instead of returning the corresponding character
12:30
<Ms2ger>
Woo, -moz-box-shadow and -moz-border-radius-* are dead
12:32
<Philip`>
Taggnostr: http://bugzilla.validator.nu/ is the right place for validator.nu bugs, I believe
12:33
<zcorpan>
Ms2ger: yay!
12:33
<Ms2ger>
(Apple, take notice)
12:36
<jgraham>
Ms2ger: ha ha ha
12:46
<annevk>
maybe I should subscribe to apps-discuss
12:46
<annevk>
it's rather amusing
12:47
<annevk>
Taggnostr: that's going to be wontfixed
12:47
<annevk>
Taggnostr: we cannot change what code point is going to be returned
12:48
<annevk>
Taggnostr: we could make it not be a parse error potentially
12:48
<Taggnostr>
not even if the unicode standard says that's wrong?
12:48
<Ms2ger>
Maybe search the spec for "willful violation"
12:49
<annevk>
Taggnostr: does it actually say that?
12:49
<annevk>
Taggnostr: Unicode is quite flexible
12:49
<Ms2ger>
Does WebKit support css3multicol unprefixed already?
12:50
<Taggnostr>
annevk, see the quotes at http://bugs.python.org/issue12729#msg143392 (the context is a bit different, but they are relevant here)
12:51
<Taggnostr>
most of those ranges are "noncharacters"
12:52
<Taggnostr>
but even there is not clear what it should be done
12:53
<kennyluck>
hmm… "If a noncharacter is received in open interchange, an application is not required to interpret it in any way. It is good practice, however, to recognize it as a noncharacter and to take appropriate action, such as replacing it with U+FFFD replacement character, to indicate the problem in the text."
12:53
<Taggnostr>
it's suggested in a few places that they should be replaced with FFFD, but in others basically says that the application can do other things
12:53
<kennyluck>
I have the feeling that nobody is going to implement this for the utf-8 decoder.
12:53
<Ms2ger>
Bah, vague specs
12:54
<annevk>
Taggnostr: this is not about encodings or interchange formats
12:54
<annevk>
Taggnostr: this is just about what ends up in your tree, it's perfectly acceptable that any code point can end up there, even if it's not a character
12:55
<Taggnostr>
but FFFD is used for other ranges, e.g. for surrogates ("Otherwise, if the number is in the range 0xD800 to 0xDFFF or is greater than 0x10FFFF, then this is a parse error. Return a U+FFFD REPLACEMENT CHARACTER.")
12:56
<Taggnostr>
I wonder if the decoder behaves in the same way as the character reference when a noncharacter is found
12:57
<annevk>
currently some reserved code points are being put out by some encodings
12:57
<annevk>
at least per http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html
12:57
<annevk>
not everything is defined yet though
13:01
<annevk>
http://www.extremetech.com/computing/119571-mozilla-partners-up-with-lg-to-combat-apple-and-google-with-its-own-device
13:02
<Taggnostr>
I think that if a codepoint is forbidden during regular decoding, it should be forbidden for character references too
13:03
<annevk>
JavaScript nor the DOM work that way, not sure it makes sense for HTML to be any different
13:05
<Taggnostr>
maybe they should be fixed too (assuming that this is a real bug)
13:08
<annevk>
we cannot change that
13:39
<Velmont>
sicking: Mozilla doesn't support lowerBoundOpen, fact or false?
13:41
<woef>
Weird question, but can you have two <header>s within an <article> or <section>?
13:43
<Ms2ger>
What's lowerBoundOpen?
13:43
<Velmont>
Ms2ger: Woops, IndexedDB, sorry :-)
13:44
<Velmont>
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBKeyRange-lowerBound-static-IDBKeyRange-any-bound-boolean-open
13:44
<annevk>
woef: i don't think it's forbidden
13:44
<sicking>
Velmont: outright lie
13:44
<woef>
Cool.
13:44
<sicking>
Velmont: :)
13:45
<woef>
Need it for a bad use case, but wireframes are already validated -_-
13:45
<Velmont>
sicking: Heh. OK. -- You see, I'm trying to understand how it works. And the implementation doesn't agree with me.
13:45
<Velmont>
(it seems, barring any bugs in my testing).
13:46
<Velmont>
[1, 2, 3] -> openCursor(lowerBound(1), false) would iterate 2 and 3. openCursor(lowerBound(1), true) would iterate 1, 2 and 3.
13:46
<AryehGregor>
RobbertAtWork, by "multiple selections" you mean "multi-range selections"? They definitely have use-cases, but they're evil anyway and we don't want them.
13:47
<Velmont>
sicking: Am I right in that? -- If so, I'm a bit at loss, because Mozilla seems to return the same no matter what I set "open" to do.
13:47
<sicking>
Velmont: i guess we might have bugs somewhere. Do you have a testcase?
13:47
<RobbertAtWork>
yeah that's what I meant, and that's fine with me
13:48
<Velmont>
sicking: Yep, - it's kinda in the middle of everything though, I can either make a small one, or I can upload what I've got now. It's part of a test suite.
13:48
<Ms2ger>
Upload it :)
13:49
<sicking>
Velmont: please file a bug in our bugzilla and attach a testcase. Should be an easy fix
13:49
<sicking>
Velmont: though if you want i can have a looksee at the testcase first
13:50
<sicking>
Velmont: huh?
13:51
<sicking>
Velmont: you mean openCursor(IDBKeyRange.lowerBound(1, false)), right?
13:51
<sicking>
Velmont: i have no idea what syntax you're using above
13:52
<sicking>
Velmont: also, i think you're getting the meaning of 'open' switched around
13:53
<Velmont>
sicking: http://test.s0.no/idb/extra/idbcursor-advance.htm
13:54
<Velmont>
Right now it's at the default (which should be false), but I've also tried with "cupcake", false, and true, -- still the same error, expecting pancake but getting cupcake.
13:55
<sicking>
Velmont: the default is false, which means that the range is inclusive
13:56
<sicking>
Velmont: i.e. the current testcase you have looks wrong to me
13:56
<sicking>
Velmont: i would expect "cupcake" to be the first result
13:56
<Velmont>
OK, but having true still gives me pancake
13:57
<sicking>
Velmont: true should give pancake
13:57
<sicking>
Velmont: false should give cupcake
13:58
<sicking>
Velmont: using default should give cupcake
13:59
<sicking>
Velmont: so "OK, but having true still gives me pancake" doesn't sound like a bug to me
14:00
<Velmont>
sicking: I mean still gives me cupcake :-( I'm getting all confused what with all the cakes
14:00
<Velmont>
sicking: I changed it to true now, -- and still fails.
14:01
<Velmont>
Said like this: it always gives cupcake no matter what I write as open argument.
14:01
<sicking>
Velmont: your code is incorrect
14:01
<sicking>
.openCursor(IDBKeyRange.lowerBound("cupcake"), true);
14:01
<sicking>
should be
14:01
<sicking>
.openCursor(IDBKeyRange.lowerBound("cupcake", true));
14:01
<Velmont>
fsck
14:02
<Velmont>
OK. Good. Then I only have my understanding of the open-ness inverted. :-)
14:03
<sicking>
Velmont: you're welcome ;-)
14:03
<annevk>
wait in what way would the DRM proposal help with privacy?
14:03
<annevk>
I guess with laughable hsivonen meant bullshit?
14:04
<annevk>
hey sicking, kill DOMStringList! kill kill kill
14:04
<sicking>
i don't even remember what it is
14:04
<sicking>
oh, in indexeddb?
14:04
<sicking>
annevk: is DOMString[] equivalent?
14:04
<sicking>
annevk: i.e. does it return a live object?
14:05
sicking
doesn't particularly care about liveness, but needs something well defined
14:05
<annevk>
sicking: if you say it's live it's live
14:06
<sicking>
annevk: so it's not the same as a JS-array containing DOMStrings then?
14:06
<smaug____>
http://blogs.msdn.com/b/wer/archive/2011/08/03/why-you-should-use-xmlhttprequest-asynchronously.aspx is interesting
14:06
<smaug____>
8.4% is a lot
14:06
<annevk>
sicking: what is not the same?
14:07
<annevk>
sicking: DOMStringList is not necessarily live either, it all depends on what you say about it when you use it
14:07
<annevk>
DOMString[] can be both static and live afaik
14:08
<sicking>
annevk: a JS-Array can't be live
14:08
<sicking>
annevk: since we can't prevent mutations
14:09
<annevk>
Web IDL has readonly []
14:09
<annevk>
http://dev.w3.org/2006/webapi/WebIDL/#idl-array
14:13
<annevk>
yeah so you get arrays with limitations: http://dev.w3.org/2006/webapi/WebIDL/#es-array
14:20
<Velmont>
sicking: Hmmm. Reading the attribute lowerOpen I get the correct meaning. --- But the lowerBound() function says the opposite...
14:21
<Velmont>
So it's trying to confuse people. I'll open a bug. :)
14:22
<sicking>
Velmont: the text looks correct to me
14:22
<sicking>
Velmont: if you pass false we set lowerOpen to false, if you pass true we set lowerOpen to true
14:23
<annevk>
sicking: a response to http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0823.html would be nice too
14:23
<sicking>
Velmont: and lowerOpen says that false means the value is included
14:23
<sicking>
annevk: the change looks good to me, but I'd prefer to get smaugs input
14:23
<annevk>
k i'll ask him
14:24
<Velmont>
open - Is the lower-bound value included in the key range. Defaults to false.
14:24
<sicking>
Velmont: indeed
14:24
<sicking>
oh
14:24
<Velmont>
I'm parsing it differently :/
14:25
<sicking>
Velmont: i see, the text there is wrong yes
14:25
<Velmont>
yesssss
14:25
<sicking>
Velmont: i was looking at the definition for the lowerOpen attribute
14:25
<Velmont>
sicking: Yep, that one was correct.
14:25
<sicking>
Velmont: please file bug yes
14:33
<AryehGregor>
What are examples of integer-valued CSS properties other than z-index?
14:34
<AryehGregor>
I'm particularly interested in animatable ones.
14:34
<AryehGregor>
Hmm, column-count.
14:37
<StoneCypher>
counters in general
14:37
<StoneCypher>
like lists
14:37
<StoneCypher>
well i guess those aren't properties
14:37
<annevk>
counter-increment and such are
14:37
<annevk>
AryehGregor: line-height
14:38
<AryehGregor>
annevk, that's a <number> . . .
14:38
<annevk>
counter-increment isn't
14:38
<annevk>
counter-reset
14:39
<AryehGregor>
Right, but will we ever want to animate those?
14:39
<annevk>
orphans, widows...
14:39
<annevk>
doubt it
14:39
<AryehGregor>
With mq, how can I inspect a patch that's not applied, akin to hg log -r foo?
14:39
<AryehGregor>
Er, hg log -r foo -p?
14:40
<AryehGregor>
It's not applied, so it has no revision id and non-mq commands won't work.
14:41
AryehGregor
waits for "look in the .hg directory"
14:42
AryehGregor
does that
14:57
<annevk>
http://en.wikipedia.org/wiki/Sony_formats o_O
14:57
<StoneCypher>
yeah
14:58
<StoneCypher>
sony's made a long and profitable history of custom media
14:58
<StoneCypher>
notice that their ps3 media is basically just repackaged sdhc, but it's form-factor incompatible, so they can sell it at 5x market price
14:58
<StoneCypher>
basically the same thing as memory stick, which was reorganized mmc
14:58
<StoneCypher>
that list is incomplete
14:59
<StoneCypher>
it only lists things that are solely sony
14:59
<StoneCypher>
they also did a lot of shared format work
14:59
<StoneCypher>
like cd was sony and philips magnavox
15:07
<Ms2ger>
Lovely: http://www.ipetitions.com/petition/html-version-of-ecmascript-5-now/
15:11
<divya>
hsivonen: w.r.t tweets, my point of view was the primary goal of that interface was to tell outright if some type is definitely not playable, is that incorrect?
15:11
<hsivonen>
divya: it's mainly to give something to people who want to know what can't be known
15:12
<gsnedders>
Ms2ger: The previous issue mentioned was managing to meet the ECMA publishing guidelines while producing a good HTML copy from the same source.
15:12
<hsivonen>
divya: but your framing is correct in practice
15:12
<Ms2ger>
Prince?
15:12
<gsnedders>
And the general attitude was that changing the publishing guidelines was about as hard as W3C Process
15:12
<gsnedders>
Ms2ger: I don't know, I presume it could be done, but it might need a fair bit of preprocessing and the like to pull-off.
15:12
<hsivonen>
Prince++
15:13
<divya>
hsivonen: :)) in that case I think the api needs to be optimized for that practice, maybe/probably optimizes for the reverse case leading to even more confusion.
15:14
<divya>
hsivonen: my thought was it should be IsUnplayable() and return true or false. so we know true means it definitely cannot be played. false means needs more testing.
15:14
<annevk>
TC39 should just move into the W3C
15:14
<Ms2ger>
How about WHATWG? :)
15:15
<annevk>
there's no need for ECMA
15:15
<annevk>
Ms2ger: I reckon W3C is an easier sell, although it may have to be over Bert's dead body or something
15:16
<akamike>
WHATWGScript - sounds less like a skin condition
15:18
jgraham
can hear it now... "You want me to program in WHATScript?"
15:19
<annevk>
"WHATScript is crazy!" "WHATScript is crazy?" "WHATScript!" "Euh."
15:19
<wilhelm>
Too bad this isn't a task force. WTFScript would be a much more appropriate name.
15:19
<annevk>
you mean like http://whattf.org/ ?
15:19
<gsnedders>
annevk: The problem is ECMA own the spec
15:20
<wilhelm>
Yes.
15:20
<gsnedders>
And I doubt anybody wants to rewrite it.
15:21
<jgraham>
We will put AryehGregor on that just after he rewrites CSS from scratch
15:21
<gsnedders>
There's not much need to rewrite it, though
15:22
<AryehGregor>
ES5 is actually pretty good AFAICT.
15:22
<jgraham>
It's fine
15:22
<jgraham>
It's just in PDF format and owned by ECMA
15:22
<StoneCypher>
i like pdfs.
15:22
<annevk>
gsnedders: not sure that's what's holding everything back
15:22
<StoneCypher>
they're a reliable target for complex rendering.
15:23
<jgraham>
If only what we had was a need for complex rendering rather than a need for hyperlinks and non-sucky search
15:23
StoneCypher
has that need.
15:23
<StoneCypher>
so
15:23
StoneCypher
shrugs
15:24
<jgraham>
In the ECMAScript spec?
15:24
<StoneCypher>
oh. no.
15:24
<StoneCypher>
sorry, i didn't mean "i think pdf is good for that case"
15:24
<StoneCypher>
i just like pdf.
15:24
<StoneCypher>
because it lets me print silly shit on amazon and cafepress that wouldn't be realistic otherwise.
15:24
<annevk>
gsnedders: at least I never heard that given as a reason before
15:25
<gsnedders>
annevk: It came up on es-discuss before. The reason is ECMA publishing policies. If someone wants to convert the current draft and make some stylesheet/processing that makes it follow ECMA publishing rules, then there's no objection.
15:26
<annevk>
I meant about leaving ECMA
15:26
<gsnedders>
annevk: Ah.
15:26
<gsnedders>
Well, it's a practical concern.
15:26
<Ms2ger>
gsnedders, are those policies public?
15:26
<gsnedders>
I don't know most of the real internal politics.
15:26
<gsnedders>
Ms2ger: I don't think so.
15:26
<gsnedders>
Ms2ger: Certainly I've never seen them.
15:27
<Velmont>
Always helpful standards bodies.
15:28
<RobbertAtWork>
http://es5.github.com/
15:28
<Velmont>
RobbertAtWork: Can't link to that from specs.
15:28
<RobbertAtWork>
Velmont: I see
15:29
<gsnedders>
RobbertAtWork: The concern is ECMA publications, not in general.
15:29
<hsivonen>
Velmont: I bet you could link to that from html5.org or whatwg.org specs
15:30
<AryehGregor>
Velmont, I link to it from specs.
15:30
<AryehGregor>
Specifically, my Editing CG spec.
15:30
<AryehGregor>
Which is W3C-hosted, although it's not a W3C spec, or somesuch.
15:31
<Velmont>
AryehGregor: Oh great. Think it's possible to sneak it into W3C hosted specs such as IndexedDB etc also?
15:31
<Ms2ger>
Unlikely
15:32
<AryehGregor>
Velmont, it's probably not going to get into a REC-track spec without someone objecting (if they notice).
15:32
<AryehGregor>
My editing spec isn't REC-track.
15:32
<AryehGregor>
It's a CG spec.
15:32
<AryehGregor>
So I can ignore all process.
15:33
<Velmont>
Yep. Thought so :] So it would be very helpful to get a canonical, official HTML version that can be linky-linked.
15:33
<AryehGregor>
You could give it as an informative reference.
15:34
<AryehGregor>
I assume.
15:34
<AryehGregor>
I don't think those have to be stable or "official".
15:34
<Ms2ger>
Oh?
15:34
<StoneCypher>
it's not clear to me how much chatty stuff is desired here. i stumbled across a startlingly high quality non-germane tech talk video. should i crosspaste it here?
15:34
<StoneCypher>
one of those "everybody should see this" things.
15:34
<Velmont>
What is non-germane?
15:34
<AryehGregor>
Do they?
15:34
<AryehGregor>
I don't know.
15:34
<Ms2ger>
We can't publish DOM4 with an informative reference to WHATWG HTML
15:34
<StoneCypher>
has nothing to do with whatwg
15:35
<StoneCypher>
at all
15:35
<gsnedders>
The official answer is this is a social channel, where we happen to end up talking about HTML5 a lot.
15:35
<AryehGregor>
Well, the W3C has a political ax to grind against WHATWG HTML.
15:35
<annevk>
StoneCypher: everything goes until someone asks you to stop
15:35
<annevk>
StoneCypher: I sometimes chat about grocery shopping for instance :)
15:35
<StoneCypher>
okay :) i found this mind blowing. the first five minutes are boring as hell and i almost gave up on it, but once he gets rolling, holy crap. http://vimeo.com/36579366
15:35
<AryehGregor>
StoneCypher, I suspect people will get annoyed if any given person's ratio of useful to non-useful topics gets too low.
15:36
<StoneCypher>
basically he's talking about applying a concrete specific bifurcating principle globally
15:36
<AryehGregor>
Regulars will sometimes chat about random stuff, but it's predominantly work-related.
15:36
<StoneCypher>
which sounds dreary
15:36
<StoneCypher>
but when he shows how his choice of principle started driving him to make useful new tools
15:36
<Velmont>
StoneCypher: Oh yes. I saw that a week ago. Very nice. Sent it to some friends.
15:36
<StoneCypher>
the tools he actually made are stunning to me
15:36
<StoneCypher>
just stunning
15:36
<StoneCypher>
Velmont: i'm currently trying to figure out how to make his js live view thing for erlang
15:37
<StoneCypher>
Want So Badly (tm)
15:38
<gsnedders>
AryehGregor: I scarcely talk on topic, to be fair! :P
15:38
<StoneCypher>
huhu
15:38
<StoneCypher>
i'll try to keep it rare.
15:40
<AryehGregor>
StoneCypher, I admit that I personally always considered your off-topic posting to be too frequent in #mediawiki, but I have a lot less clout here than I used to there, so here it really depends more what other people think.
15:40
<Ms2ger>
gsnedders, well, you're the youngest around :)
15:40
AryehGregor
guesses he's middle-aged in this group
15:41
<gsnedders>
Ms2ger: And it's not as if there isn't plenty else discussed here, or as if I'm not a regular who has discussed plenty of on-topic stuff before.
15:41
<gsnedders>
And I seem to be the go-to JS guy :P
15:41
<StoneCypher>
AryehGregor: ... i barely spoke in #mediawiki; i think you might have me swapped with someone else.
15:41
<jgraham>
gsnedders: We are all just scared that if we don't leave you alone you will start playing loud emo music
15:41
<AryehGregor>
I know you barely spoke there, but I felt like it was mostly off-topic, so it annoyed me anyway. Maybe I'm easily annoyed, though.
15:42
<StoneCypher>
AryehGregor: almost the only time i talked in that channel was when I was talking to someone I'd lost touch with elsewhere
15:42
<AryehGregor>
Anyway, doesn't matter. Do as you will, don't mind me.
15:42
<gsnedders>
jgraham: Well, I think we're alone now…
15:42
<gsnedders>
Oh, wait, that's not emo.
15:42
<gsnedders>
Sorry, I'm not 14.
15:42
<Ms2ger>
gsnedders, where "we" is you and your other identity?
15:42
<annevk>
damn it gsnedders why do you grow up?
15:43
StoneCypher
can't remember what nick they used in that channel (one of those new-nick-every-thursday types.) Kate something.
15:43
<AryehGregor>
River Tarnell, a.k.a. Kate Turner?
15:43
<StoneCypher>
yes, kate turner
15:44
<StoneCypher>
sorry, i knew river under the previous name
15:44
<AryehGregor>
A.k.a. flyingparchment, and about nine other nicks that I forget?
15:44
<annevk>
I wonder if gsnedders is still the youngest (cf http://www.flickr.com/photos/gsnedders/2964101064/ )
15:44
<AryehGregor>
River Tarnell is his real name, Kate Turner was an adopted persona.
15:44
<StoneCypher>
ah, you know he's a he
15:44
<StoneCypher>
yes, i knew him under his birth name, from before any of that started, from efnet #c++
15:44
<gsnedders>
annevk: I dunno, I'm certainly still youngest at Opera…
15:44
<gsnedders>
Ms2ger: Maybe. No comment.
15:45
<StoneCypher>
it's sort of hard to know what i'm supposed to be open about with regards to him :)
15:45
<StoneCypher>
anyway
15:45
<StoneCypher>
he's brilliant if you get to know him, so finding him in #mediawiki was a blast
15:46
<wilhelm>
annevk: The note on that picture is excellent.
15:49
<annevk>
haha
15:49
<annevk>
missed that
15:49
<Ms2ger>
Finally!
15:50
Velmont
found an unused exercise ball and took it to his office. yay
15:51
<Ms2ger>
Be warned, Opera people
16:04
<annevk>
https://bitbucket.org/ms2ger/dom-core/changeset/193f1831efe0
16:04
<annevk>
Introduction to "The DOM"
16:05
<annevk>
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#introduction-to-the-dom
17:47
AryehGregor
remembers that the editing spec gives him a headache
17:47
<AryehGregor>
Far too complicated.
17:47
<AryehGregor>
Spec work is hard.
17:47
AryehGregor
guesses he likes small, self-contained problems, but . . .
17:48
<AryehGregor>
Someone has to do it.
18:01
<AryehGregor>
There's no easy way for a script that's submitting a big POST to gzip it, is there?
18:01
<AryehGregor>
Or otherwise compress it?
18:01
<AryehGregor>
HTTP should be able to do that transparently in theory, right?
18:13
<ksweeney>
Not sure on the base HTTP side of things, but I remember seeing a JS library that would compress files locally before posting. Think that might rely on the File API though (not sure what your support needs are)
18:16
<ksweeney>
http://jszip.stuartk.co.uk/
18:16
<zewt_>
AryehGregor: transfer-encoding
18:16
<AryehGregor>
zewt, yes, but how can you get that from JS when posting a form?
18:17
<AryehGregor>
Or can you get it with XHR but not forms? Or neither?
18:17
<AryehGregor>
ksweeney, I only need to support latest Chrome and Firefox.
18:17
<AryehGregor>
Meaning Chrome dev, and mozilla-central.
18:17
<AryehGregor>
(so different definitions of "latest" here)
18:37
<zewt>
AryehGregor: it should just always happen if supported
18:37
<AryehGregor>
zewt, does it actually, though?
18:37
AryehGregor
could test, of course
18:44
<AryehGregor>
Nope, doesn't seem to happen (at least in Chrome).
20:46
<AryehGregor>
Blech, my execCommand() test data is 4.8M. :(
20:47
AryehGregor
should think about if it's possible to reduce that for the future . . .
20:55
<Philip`>
AryehGregor: "less .hg/patches/foo" is what I always use
21:06
<Ms2ger>
Any Opera people around who feel like poking at DSK-358181?
21:11
<rniwa>
AryehGregor: thanks for those spec cahnges!
21:12
<rniwa>
AryehGregor: I think we're gonna make those changes in near future :)
21:16
<TabAtkins>
heycam|away: I didn't understand a single part of your email about named properties.
21:16
<TabAtkins>
heycam|away: I'm not sure how I managed that.
21:17
<TabAtkins>
Wait, hm.
21:53
<Ms2ger>
TabAtkins, easy solution, document those areas :)
21:59
<TabAtkins>
Ms2ger: Indeed.
21:59
<Ms2ger>
And thank you
21:59
<TabAtkins>
Ms2ger: Now we have another hard problem: finding time to do so.
21:59
<TabAtkins>
You're welcome, but for what?
22:00
<Ms2ger>
Fixing everything
22:00
<TabAtkins>
I haven't fixed *everything* yet. There's still world hunger.
22:00
<TabAtkins>
But I'm glad you believe in me.
22:01
<Ms2ger>
Hrm
22:01
<Ms2ger>
World hunger or the box model...
22:01
<Ms2ger>
Go for the box model, please :)
22:02
<TabAtkins>
I think there's about a billion hungry people that would disagree with you.
22:02
<TabAtkins>
But I'll probably do what you say instead.
22:56
<Hixie>
so to introduce path primitives, i think i need to split CanvasRenderingContext2D into two interfaces Path and CanvasRenderingContext2D, where CanvasRenderingContext2D inherits from Path
22:57
<Hixie>
that way you can do pretty much everything you want to a path that you can to a canvas, short of doing anything with colour or shadows
22:58
<TabAtkins>
OO - ruining everything since the 80s or whatever.
22:58
<Hixie>
heh
22:58
<TabAtkins>
Does WebIDL make mixins easy?
22:59
<Hixie>
whether we do it as a mixin or inheritance is a detail
22:59
<Hixie>
i don't really care either way
22:59
<TabAtkins>
Sure. Until you want to abstract something else out of Canvas.
22:59
<Hixie>
sure
22:59
<Hixie>
i'm just talking high level here
23:00
<Hixie>
hmm.... maybe it should be a separate interface anyway, since path.fill(path) and context.fill(path) would do rather different things
23:00
<Hixie>
adding one path to another path, and drawing colour to the canvas, respectively
23:00
<Hixie>
hmm
23:00
<TabAtkins>
...that sounds like a weird behaviro for path.fill(path).
23:00
<Hixie>
it would be called something else if we did it that way
23:01
<TabAtkins>
I don't understand how you can fill a path with a path, unless it's in the layering way, like <pattern> in SVG.
23:01
<Hixie>
i don't want to define arcTo() etc twice... maybe the right structure is for Path and Context to both inherit/mixin something of an AbstractPath
23:01
<Hixie>
TabAtkins: path.add(path) if you prefer
23:02
<TabAtkins>
Yeah, that's definitely better. ^_^
23:02
<Hixie>
TabAtkins: as opposed to path.addStroke(path), which outlines the path with a particular line width and adds that
23:02
<TabAtkins>
Though, keeping path.fill(foo) is useful. If we're going retained, you can use that to get better AA behavior.
23:02
<Philip`>
Maybe it'd be cleaner to have a totally independent Path object, and have a CanvasRenderingContext2D.globalPath property (which is a Path), and have CanRenCon2D.arcTo() etc be defined as delegating to globalPath.arcTo(...)
23:03
<Hixie>
Philip`: yeah, i was thinking of doing that too. and have .fill(), etc, default to the .globalPath object if there's not an explicit argument saying which to use.
23:03
<Hixie>
Philip`: seems weird to actually expose .globalPath though
23:03
<Hixie>
since it wouldn't add anything
23:04
<Philip`>
(Using some kind of explicit delegation (instead of inheritance etc) would also make it possible for Path to have a slightly different API to CRC2D, if there was any desire for that (to clean up things without compat concerns, or something), and CRC2D can define whatever mapping is needed)
23:06
<Hixie>
yeah, though having two different sets of path api is a bit ugly
23:06
<Hixie>
is there anything to clean up?
23:06
<Hixie>
if not i'd much rather keep them identical
23:06
<Philip`>
I don't remember
23:06
Philip`
has forgotten most of the API currently
23:07
<Hixie>
also it's kind of weird to have the transform be on context.globalPath yet affect the context's own methods (even those not delegating to the globalPath object)
23:07
<Hixie>
(we'd want transforms on path objects so you can do things like add text pointing in various directions to a single path)
23:07
<Hixie>
(same reason we'd want the font properties on the path object)
23:25
<Hixie>
hmmmmmm
23:25
<Hixie>
how to make isPointInPath() useful when applied to a path you use to stamp out a bunch of things in different places
23:26
<Hixie>
it doesn't work just to have a path = context.transformPath(path) feature, because you might want just to have the translate and rotation transforms applied but not the scale
23:26
<Hixie>
you really want "transformPathUsingOnlyTheTransformsImGoingToUndoBeforeCallingIsPointInPath(path)"
23:26
<Hixie>
hmmm
23:37
<Hixie>
how else can we make hit testing easier on canvas without making it retained-mode...
23:37
<TabAtkins>
Optional set of transforms you can pass to isPointInPath along with the path itself?
23:38
<TabAtkins>
Something like, I dunno, isPointInPath(path, {offset:[x,y], transform:<string>})
23:38
<Hixie>
it would be sad to have to have two ways to express transforms in one api
23:38
<TabAtkins>
Sure.
23:38
<Hixie>
we could have a way to register a callback for a path on the canvas, and have the UA be responsible for discarding callbacks that relate to paths that have been entirely overlapped
23:39
<TabAtkins>
Make a transform object?
23:39
<Hixie>
(and have clearRect() clear the callbacks from the given region)
23:39
<Hixie>
could have some kind of transform object
23:40
<Hixie>
though i don't really see how it would work
23:40
<TabAtkins>
I presume that other drawing libraries, particularly ones built on canvas, have run into this problem.
23:40
<Hixie>
(i mean, a transform object is essentially what "path = context.transformPath(path)" gives you, and that fails as described above)
23:43
<Hixie>
http://stackoverflow.com/questions/3146424/html5-canvas-hittesting suggests two things, one, be retained (scene graph) and two, basically what i suggest above, have a way to register a callback for a path and have the UA throw away the paths once overlapped
23:43
<Hixie>
(they give a particular implementation strategy for case two)
23:44
<TabAtkins>
Oh, I see what you were asking about.
23:44
<TabAtkins>
Yeah.
23:45
<TabAtkins>
Using those color hacks for picking is pretty awesome.
23:45
<Hixie>
http://simonsarris.com/blog/510-making-html5-canvas-useful basically says scene graph
23:46
<Hixie>
http://atomicrobotdesign.com/blog/htmlcss/build-a-vertical-scrolling-shooter-game-with-html5-canvas-part-3/ says scene graph
23:47
<Hixie>
if we do a ua-maintained stack of data, i wonder if we should use structured-cloned data that's made available in the mouse events on the canvas, or whether we should use callbacks
23:47
<Hixie>
i'm thinking the former is probably more useful
23:48
<Hixie>
since then you can do this for mouse down, move, up, wheel events, etc
23:48
<TabAtkins>
What do you mean by "structured-cloned data"?
23:50
<Hixie>
arbitrary JS object that has gone through http://www.whatwg.org/specs/web-apps/current-work/#structured-clone
23:50
<TabAtkins>
Yeah, I know that. ^_^ I meant what data are you expecting to pass?
23:50
<Hixie>
oh
23:51
<Hixie>
index of the space ship, stuff like that
23:51
<Hixie>
whatever info you need to be able to process the click
23:51
<TabAtkins>
Hm. For large scenes, doing picking directly from teh scene graph is slow. It becomes a linear search through the tree.
23:52
<Hixie>
well the advantage of having the UA do it is that the UA can do lots of optimisations that a JS author might not bother with
23:52
<TabAtkins>
Yeah, definitely.
23:52
<TabAtkins>
The UA should be the one in charge of picking.
23:52
<Hixie>
(there are plenty of ways to optimise a hit test like this)
23:52
<Hixie>
(even without using a backing coloured bitmap)
23:53
<TabAtkins>
(though from what I understand sitting next to some game devs, the backing colored bitmap is pretty much state-of-the-art)
23:53
<Hixie>
it's certainly going to be the fastest
23:53
<Hixie>
not the most memory efficient though
23:53
<TabAtkins>
True.
23:53
<Hixie>
maybe we don't bother with structured clone, and only do an index
23:54
<Hixie>
since you wouldn't want authors to clone parts of their scene graph accidentally
23:54
<TabAtkins>
So, if you're talking about the UA still doing this, what is this data for? Who's getting it?
23:54
TabAtkins
is behind your thinking.
23:54
<Hixie>
addHitRegion(path, mySpaceShipObjectThatReferencesMyEntireGameState)
23:54
<Hixie>
i'd add it to the click event MouseEvent object
23:55
<Hixie>
so <canvas onclick="processClickOn(event.hitTargetID)">
23:55
<TabAtkins>
Ah, and paths have some accessible index that you can store on your own objects?
23:56
<Hixie>
i was imagining you'd do something like addHitRegion(path, spaceship.id);
23:56
<Hixie>
where spaceship is your internal state object for the thing you are drawing with path
23:56
<TabAtkins>
Ah, the opposite direction. Sure, either way works.
23:57
<TabAtkins>
Unfortunately JS isn't quite ready yet for having the Path return a unique object for its id.
23:57
<Hixie>
that would also allow addHitRegion(path, 'text label', ariaRole); or addHitRegion(path, myButtonElement);
23:58
<Hixie>
which would enable haptic feedback AT features for devices with touch screens where the user brushes the screen to find what's on it, with audible descriptions
23:58
<Hixie>
which right now totally fail for canvas
23:59
<TabAtkins>
Okay, so the author has to have some way to produce unique ids for their objects that they want to attach paths to.
23:59
<TabAtkins>
Right?
23:59
<Hixie>
right