01:30
<dbaron>
fyi (re http://lists.w3.org/Archives/Public/public-html/2012Apr/0033.html ) -- I'm probably not planning to write up an objection to the Media TF (in case someone else wants to)
06:58
<annevk>
man, these JavaScript conference peeps sure have a sense for drama
07:05
<othermaciej>
?
08:09
<annevk>
hmm, gbk seems more or less similar
08:29
<annevk>
so the main difference between browsers seems to be the amount of PUA
08:30
<annevk>
and then there's some subtle differences between the two-byte mapping in gbk and gb18030 in Chrome/Gecko
08:30
<annevk>
but in Opera they are identical
08:40
<annevk>
http://lists.w3.org/Archives/Public/www-archive/2012Apr/0030.html
09:54
<annevk>
ok that's specced
09:54
<annevk>
now four byte sequences...
09:54
<annevk>
ugh
10:07
<smaug____>
annevk must be some sort of masochist ;)
10:11
<annevk>
smaug____: slow weekend :)
10:13
<smaug____>
hmm, I guess you don't really have Easter in Holland
10:14
<annevk>
we do
10:14
<smaug____>
at least the time I was in Amsterdam during Easter, it was hardly see anything special
10:14
<annevk>
yeah, you might eat an extra egg or so, or find chocolate eggs if you're a kid
10:15
<smaug____>
comparing to Finland where the country is closed from mid-Thursday to the end of Monday
10:16
<annevk>
the gym is closed today, I think the supermarket is open, but I haven't checked
11:09
<kennyluck>
muh, "Please ensure that your comment is descriptive enough that the editor can understand it."
11:10
<kennyluck>
What is the algorithm used behind?
13:21
<kennyluck>
(text.length <= 5) || (text.indexOf(' ') == text.lastIndexOf(' ')) huh
13:21
<kennyluck>
I was going to send "(editorial) s/pseudo-elements/pseudo-classes/". I guess I'll just add " " at the end.
13:23
<kennyluck>
This conditional looks useless though. All the junk I see on public-html-bugzlla pass this.
13:23
<kennyluck>
s
13:23
<kennyluck>
a
13:23
<kennyluck>
y,
13:23
<kennyluck>
13:23
<kennyluck>
say, "please help me"
13:27
<Philip`>
kennyluck: Surely the reason the junk you see on public-html-bugzilla passes that conditional, is that junk that doesn't pass the conditional doesn't get posted to public-html-bugzilla
13:28
<kennyluck>
Philip`, oh. So this is not something new?
13:29
<kennyluck>
Hmm.. makes sense.
13:29
<Philip`>
I think the junk filter has been there quite a while
13:30
<kennyluck>
Hmm… I guess I am just too unlucky for this case :(
13:35
<kennyluck>
Typo reports would fail this not surprisingly though. I see "s/ECMAScript/JavaScipt/" filed for the HTML5diff document, for example.
13:35
<zewt>
heh, nothing's annoying quite like "fiddle with your message to satisfy the arbitrary filters" filters
13:36
<zewt>
like stackoverflow that refuses to post a comment if it's less than like 15 characters, so I ended up adding junk to comment responses like "yep"
14:17
<jarek>
Hi
14:17
<jarek>
is the usage of custom namespace inside SVG documents considered to be a bad practice?
14:19
<jarek>
the current trend at W3C is to HTMLize the SVG syntax, is that correct?
14:19
<annevk>
dunno about W3C
14:19
<jarek>
if I'm developing SVG editor and I would like to identify some groups as layers, should I be doing it via custom XML namespace (like Inkscape) or should I be using element.dataset?
14:20
<annevk>
dataset is only for things pertaining to the document itself
14:20
<annevk>
e.g. a script library or some such
14:21
<annevk>
it's not supposed to have meaning outside the document
14:22
<jarek>
annevk: so something like <g data-layer-id="circles"></g> would not be semantic?
14:22
<jarek>
it feels cleaner than XML namespace, especially if SVG document is going to be embedded directly in HTML5
14:23
<jarek>
btw, are there any plans to standardize SVG layers?
14:24
<jarek>
those can be easily emulated with groups, but each SVG editor uses different naming scheme
14:24
<annevk>
XML namespaces don't work in HTML
14:25
<jarek>
annevk: really? I think that answers me question
14:25
<jarek>
s/me/my
14:26
<jarek>
I can't use XML namespace if my editor will be implemented on top of HTML5
14:30
<jgraham>
jarek: That sounds like a reasonable usecase for data- to me
14:31
<jgraham>
since the data is not intended to be consumed by arbitary third party tools
14:31
<zewt>
jgraham: but it seems like tools shouldn't be generating data into data-, since if you use another tool on the same document that also uses data-, you're in the same namespace
14:31
<zewt>
at least, that seems to be the theory
14:32
<jgraham>
Although I would use a name like data-mysvgedit-layer="circles" where 'mysvgedit' is something reasobaly unique to your tool
14:32
<zewt>
(easily worked around--add your own namespace on top, eg. data-product-whatever)
14:32
<jgraham>
zewt: We seem to eb agreeing :)
14:32
<jgraham>
*be
14:33
<zewt>
(but of course that also defeats the purpose of data-, which I've never bothered to use myself)
14:33
<jgraham>
I don't think it defeats the purpose of data- really
14:33
<zewt>
well, rather than defeats the purpose, it makes it unnecessary
14:33
<zewt>
as a namespacing tool, I mean
14:34
<zewt>
(if whatever the helper accessor is is supported, that's still useful, but not necessary)
14:34
<jgraham>
Well it allows for easy machine checking of validity compared to just mysvgedit-layers
14:34
<jarek>
is there something like iframe's sandbox attribute, but for SVG?
14:34
<jgraham>
And makes it even less likely that there will be collisions in the future
14:35
<jarek>
when you allow users to upload SVG images, you do not want them to inject any scripts
14:35
<jarek>
it looks like the only workaround at the moment is to either sanitize the SVG file or put it inside iframe
14:35
<zewt>
jgraham: if you're using a reasonable prefix, i think the chances of that are already small enough to not be worth uglifying things with a second prefix
14:39
<jarek>
CSS namespaces are pretty much dead
14:40
<jarek>
XHTML is almost dead as well
14:40
<jarek>
I guess it's safe to assume that SVG namespaces have no future
14:42
<jarek>
would would be really cool is if vendors could agree on some common CSS and SVG prefixes
14:43
<jarek>
s/would would/what would
14:44
<Philip`>
I thought data-* was currently only permitted on HTML elements, not on SVG elements
14:44
<jgraham>
Oh, that is probably true
14:45
<jgraham>
Silly artificial boundaries in the platform
14:45
<jarek>
Philip`: it's defined on Element.prototype
14:45
<jarek>
Philip`: if I recall correctly datasets on SVG were standardized recently
14:46
<jarek>
but they are already supported by Chrome
14:47
<Philip`>
I mean "permits" in a document conformance sense
14:47
<Philip`>
in which case the IDL is irrelevant
14:47
<Philip`>
and http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes only states that it's allowed on HTML-namespace elements
14:48
<jarek>
then the spec needs to change
14:49
<Philip`>
That's quite probable
14:49
<jarek>
I see no reason why dataset should not be allowed on SVG elements
14:49
<Philip`>
Because of silly artificial boundaries in the platform
14:50
<Philip`>
I think adding custom data to SVG elements was one of the use cases considered when adding data-*, and the conclusion was "data-* would solve this problem but it's the SVG WG's responsibility to allow those attributes on their elements"
14:51
<Philip`>
I have no idea if the SVG WG has considered that (or even been told about it)
14:55
<jarek>
you mean SVG WG does not even follow HTML5 standarization? :P
14:56
<jarek>
someone should also tell them about element.classList
15:08
<jarek>
SVG attributes are written either in camelCase, lower-case-with-dashes or lowercasewithoutdashes
15:08
<jarek>
no cool
15:08
<jarek>
s/no/not
15:12
<jgraham>
Well IDL stuff is pretty easy to make work everywhere, just put it on Element
20:57
<jarek>
Hello
20:57
<jarek>
are there any plans for having 3d transforms on SVG elements?
20:58
<jarek>
there is already syntax for that in CSS3
21:02
<jarek>
3d transforms can't be described with 3x3 matrixes, right?
21:22
<gsnedders>
Anyone able to recommend any hotel in Madrid?
21:31
<jarek>
http://www.w3.org/TR/SVG-Transforms/#threed-translate-definition
21:31
<jarek>
^ that's interesting, is it implemented anywhere?
21:46
<remysharp>
not sure if I dreamt this, but isn't there a new method for executing on next event loop/tick - like setTimeout(foo, 10)?
21:47
<remysharp>
setImmediate - I didn't dream javascript - phew!
21:54
<zewt>
not mutually exclusive
21:59
<zewt>
gaaaaaaah
22:00
<zewt>
awesomeness is firefox crashing while spending half an hour trying to composite a message in jp
22:00
<zewt>
time for a test of session restoration!
22:36
<jgraham>
gsnedders: I have stayed at http://www.hostaladriano.com/ a couple of times. Hardly amazing but good/cheap enough to go back to
22:36
<jgraham>
Also very central
23:14
<heycam>
Philip`, yes, the SVG WG is planning on having data-* attributes on SVG elements