2011-10-01
[17:21:00.0000] <Hixie>
didn't we decide, like, ten years ago, that the "$" syntax in selectors was a bad idea and :matches()/:has() were a better solution?

[17:23:00.0000] <TabAtkins>
I thought so, yes.

[17:24:00.0000] <Hixie>
someone should tell fantasai

[17:24:01.0000] <TabAtkins>
I plan to.

[17:24:02.0000] <Hixie>
excellent

[17:24:03.0000] <TabAtkins>
/me is writing ALL THE EMAILS today.

[17:24:04.0000] <TabAtkins>
Fridays are often my most productive day, in terms of emails written.

[17:24:05.0000] <TabAtkins>
It's the promise of free beer at the end that does it.

[17:27:00.0000] <hober>
indeed

[19:30:00.0000] <michaelw>
HTML5 chapter 3.4 used to have a section on innerHTML, where'd that go?

[19:42:00.0000] <Hixie>
michaelw: DOM Parsing

[19:42:01.0000] <Hixie>
michaelw: there's a link in the spec, search for [DOMPARS

[19:43:00.0000] <michaelw>
ah, thanks!

[19:43:01.0000] <michaelw>
Hixie: the fragment parsing algo is in both documents?

[19:43:02.0000] <Hixie>
fragment parsing is in HTML

[19:44:00.0000] <Hixie>
DOM Parsing references HTML and vice versa

[19:44:01.0000] <michaelw>
Hixie: DOMPARSING, sec 3.1 reads: "The following steps form the fragment parsing algorithm"

[19:44:02.0000] <Hixie>
(not sure why it was split out, but if people want to take over fixing parts of tehe spec, i'm not one to complain :-) )

[19:44:03.0000] <Hixie>
/me looks

[19:45:00.0000] <Hixie>
that's a bit confusing, but it's not duplicated

[19:45:01.0000] <Hixie>
the DOM Parsing spec defines the "fragment parsing algorithm"

[19:45:02.0000] <Hixie>
HTML defines the "HTML fragment parsing algorithm", which the DOM Parsing one references

[19:46:00.0000] <michaelw>
ah, I see

[19:51:00.0000] <michaelw>
Hixie: nodes that come from the HTML fragment parsing algorithm have as owner document the document created for that algorithm, correct?

[19:54:00.0000] <Hixie>
come again?

[19:56:00.0000] <michaelw>
the fragment parsing algorithm creates a new document in step 1, node that are then created by the parser with the fragment algo have that document as owner document.

[19:56:01.0000] <Hixie>
ah, then yes.

[19:56:02.0000] <michaelw>
hmm

[19:57:00.0000] <Hixie>
it's almost certainly changed by the caller of the algorithm though.

[19:57:01.0000] <Hixie>
e.g. the one in DOM Parsing does some adoption to a DocumentFragment from some other document, iirc

[19:58:00.0000] <michaelw>
yeah, thought so, but where is that written?

[19:58:01.0000] <michaelw>
aha

[19:59:00.0000] <michaelw>
DOM4 says "Nodes are implicitly adopted across document boundaries."

[19:59:01.0000] <Hixie>
yeah

[20:05:00.0000] <michaelw>
Hixie: the above appears to imply there is no way that a node ends up in one document and has an ownerdocument of another?

[20:05:01.0000] <michaelw>
er, what happened to my grammar

[20:06:00.0000] <michaelw>
I meant "ends up in one document and has a different owner document"

[20:08:00.0000] <Hixie>
correct

[00:01:00.0000] <annevk>
is anyone working on fullscreen already?

[00:01:01.0000] <annevk>
maybe I should start doing that soonish

[03:19:00.0000] <annevk>
Ms2ger, do you also think DOM4 should import all of the event loop stuff?

[03:20:00.0000] <Ms2ger>
If it's necessary, I guess yes

[03:24:00.0000] <annevk>
I wonder if that can be done without getting some dependency

[03:25:00.0000] <Ms2ger>
I think someone at Mozilla was working on fullscreen...

[03:26:00.0000] <Ms2ger>
Did you see http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html, btw?

[03:27:00.0000] <Ms2ger>
tantek, probably

[03:28:00.0000] <annevk>
okay, that works for me, just someone has to do it already

[03:28:01.0000] <annevk>
the WebApps WG agreed?

[03:28:02.0000] <annevk>
why is this deviating from our normal CfC?

[03:29:00.0000] <annevk>
oh well, at some point that'll blow up

[03:29:01.0000] <annevk>
some pretty poor communication with the rest of the WG

[03:35:00.0000] <annevk>
DOM4 has only a couple issues left

[03:35:01.0000] <annevk>
that's nice

[03:36:00.0000] <annevk>
should prolly look again into event handlers to see what the options are

[08:53:00.0000] <BenoitRen>
Hi everyone.

[08:54:00.0000] <BenoitRen>
I made this page a couple years ago when the HTML5 dialog element wasn't deprecated yet: http://www.pscave.com/pso/script/battletraining.shtml

[08:55:00.0000] <BenoitRen>
The spec has since dropped the element and recommended a different way to mark up conversations. But it doesn't work for this instance.

[08:56:00.0000] <BenoitRen>
A large part of the game script doesn't consist of conversations, but of monologues, which are often given in parts. Like when you first talk to A, (s)he says X, and when you talk to him/her a second time, (s)he says Y.

[08:57:00.0000] <annevk>
You should probably change it still as <dialog> is going to mean something else

[08:57:01.0000] <BenoitRen>
Oh, I do want to change it. My problem is that I don't know how. :(

[08:58:00.0000] <BenoitRen>
As it's HTML4, I didn't actually use the dialog element, but dl along with its siblings.

[08:58:01.0000] <BenoitRen>
It's the same idea, of course.

[08:59:00.0000] <annevk>
If http://www.whatwg.org/C#conversations does not work for you could you maybe file a bug on the specification?

[09:00:00.0000] <annevk>
You can ask e.g. if an example can be added for your specific scenario

[09:04:00.0000] <BenoitRen>
Yes, I guess I can do that.

[09:16:00.0000] <BenoitRen>
Comment submitted. I hope it was sent, as I don't see a confirmation.

[09:17:00.0000] <Ms2ger>
BenoitRen, http://www.w3.org/Bugs/Public/show_bug.cgi?id=14353

[09:18:00.0000] <BenoitRen>
Ms2ger: Thanks. :)

[09:39:00.0000] <annevk>
thanks BenoitRen

[09:39:01.0000] <BenoitRen>
No problem, annevk.

[10:30:00.0000] <BenoitRen>
I just remembered something else. Is there a guideline for marking up a message board? I've been struggling with that for ages.

[11:44:00.0000] <BenoitRen>
Bye.


2011-10-02
[04:26:00.0000] <smaug____>
/me files a spec bug

[04:36:00.0000] <smaug____>
Ms2ger: FYI, I'm pretty sure I won't accept a patch which overloads appendChild() etc

[04:40:00.0000] <annevk>
we overload everywhere else

[04:43:00.0000] <smaug____>
annevk: why to overload in this case?

[04:43:01.0000] <smaug____>
/me tries to find some reasoning in webapps mailing list archive..

[04:44:00.0000] <smaug____>
the original idea was .append(), which feels better

[04:46:00.0000] <smaug____>
/me can't find any reasoning for overloaded appendChild() etc

[04:52:00.0000] <annevk>
cause it makes sense and is convenient?

[04:53:00.0000] <annevk>
introducing a whole array of new methods seems rather expensive

[04:53:01.0000] <smaug____>
how is it convenient ?

[04:53:02.0000] <annevk>
and not really consinstent

[04:53:03.0000] <annevk>
consistent*

[04:53:04.0000] <smaug____>
how are new methods any more expensive than overloading existing ones ?

[04:54:00.0000] <smaug____>
overloading makes methods slower

[04:54:01.0000] <annevk>
you get way more methods to remember, objects get bigger, etc.

[04:55:00.0000] <smaug____>
(and appendChild etc are very "hot" methods in the web)

[04:55:01.0000] <smaug____>
objects get bigger?

[04:55:02.0000] <smaug____>
(shared) prototype may contain the new method, but that's it

[04:56:00.0000] <annevk>
i guess if the speed argument holds up that may be problematic

[04:56:01.0000] <annevk>
but not everyone was convinced it would

[04:59:00.0000] <annevk>
and if we introduce a new append() method that does the overloading and stuff you have the same basic problem

[04:59:01.0000] <annevk>
overloading appendChild further was also discussed in the Element.create threads btw

[04:59:02.0000] <annevk>
for consistency with how that would work

[04:59:03.0000] <smaug____>
append() would be the possibly-slower overloaded thingie

[04:59:04.0000] <smaug____>
I don't understand why to make backwards incompatible changes to appendChild

[05:00:00.0000] <smaug____>
(not that I'm really worried about backwards compatibility in this case)

[08:18:00.0000] <Ms2ger>
https://bugzilla.mozilla.org/show_bug.cgi?id=690287, for people with an interest in UA sniffing

[08:20:00.0000] <Rik`>
ah that reminds me I have to open a bug

[09:11:00.0000] <smaug____>
could someone educate me; what is the use case for iframe's srcdoc ?

[09:12:00.0000] <Hixie>
sandboxing comments in a blog post

[09:13:00.0000] <smaug____>
Hixie: how is srcdoc different from src="data:text/html,... ?

[09:13:01.0000] <Ms2ger>
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-January/024823.html

[09:13:02.0000] <Hixie>
smaug____: easier to not screw up the escaping

[09:13:03.0000] <smaug____>
Hixie: but that is the only difference?

[09:14:00.0000] <Hixie>
 smaug____: the only one of consequence, i think

[09:14:01.0000] <smaug____>
ok

[09:15:00.0000] <Hixie>
there's also some minor things like you don't need a <title> in a srcdoc document

[09:15:01.0000] <Hixie>
and i may have said that it's always in standards mode, i forget

[09:16:00.0000] <smaug____>
I think I didn't find the place which describes the structure of srcdoc document

[09:16:01.0000] <smaug____>
I thought it would be parsed like data:text/html,

[09:16:02.0000] <smaug____>
well, like anything else

[09:17:00.0000] <smaug____>
/me can't remember if parser creates <title> automatically

[09:17:01.0000] <Ms2ger>
No

[09:24:00.0000] <Hixie>
oh another difference is that relative URLs in srcdoc documents resolve relative to the parent doc

[09:24:01.0000] <Hixie>
with data: URLs you can't use relative URLs

[09:25:00.0000] <Hixie>
similarly, Referer: headers get set correctly for srcdoc docs but not data: docs

[09:27:00.0000] <Hixie>
anyway the net result is that a srcdoc works better than data: would and you don't have to be as verbose and you're less likely to screw up the escaping, which makes it more secure in practice

[10:13:00.0000] <smaug____>
Hixie: ah

[10:14:00.0000] <smaug____>
where is it spec'ed that relative URLs work like that

[10:15:00.0000] <smaug____>
/me found

[10:16:00.0000] <smaug____>
/me wishes the place where srcdoc is defined would mention that relative URLs work differently etc

[10:33:00.0000] <Hixie>
smaug____: click on the definition of "srcdoc document" and it links you to all the places that mention it

[10:34:00.0000] <smaug____>
oh

[10:34:01.0000] <smaug____>
that doesn't look like something one could click

[10:34:02.0000] <smaug____>
but ok

[10:34:03.0000] <smaug____>
thanks

[10:34:04.0000] <Hixie>
all the definitions are clickable (doesn't work so well in the multipage version, unfortunately)

[13:10:00.0000] <AryehGregor>
compiz is using 2.6G of resident memory.

[13:10:01.0000] <AryehGregor>
. . .

[13:13:00.0000] <AryehGregor>
/me wonders if it's related to his use of unsupported experimental video drivers

[13:20:00.0000] <AryehGregor>
/me wonders what happens if he kills compiz . . . probably ends his desktop session

[13:20:01.0000] <AryehGregor>
Let's find out!

[13:21:00.0000] <AryehGregor>
Absolutely nothing.

[13:21:01.0000] <AryehGregor>
Probably because of the compiz --replace I had already run.

[13:22:00.0000] <AryehGregor>
New incantation to reduce obscene memory usage: Alt-F2, exec compiz --replace, then kill -9 the old compiz from a terminal.

[13:22:01.0000] <AryehGregor>
<3 Linux

[13:26:00.0000] <bga_>
:)

[14:54:00.0000] <annevk>
Hixie, would probably still be useful to mention in a non-normative note what the differences are explicitly


2011-10-03
[02:14:00.0000] <zcorpan>
TabAtkins: each side of the equation had a multiplier, you can't just compare the numbers and call the equation untrue

[02:16:00.0000] <zcorpan>
TabAtkins: e.g. html = 1.1 and rdfa = 4.01 would solve the equation

[04:55:00.0000] <annevk>
colleague had this idea similar I guess to the JSON idea going around

[04:56:00.0000] <annevk>
representing a Node as an array so you can build templates and then create a whole structure using Element.create(templ)

[04:56:01.0000] <annevk>
something like:

[04:57:00.0000] <annevk>
TMPL = [NAME, optional ATTRS, optional HANDLERS, optional TEXT|TMPL...]

[04:57:01.0000] <annevk>
kind of neat

[04:59:00.0000] <Lachy>
Are the attrs, handlers, etc. represented as nested arrays or other structure?

[04:59:01.0000] <jgraham>
annevk: That's kind of how the templating system in testharness.js works

[04:59:02.0000] <annevk>
they would be objects

[04:59:03.0000] <jgraham>
I'm not sure if it's the idea that sucks or just the implementation

[04:59:04.0000] <annevk>
jgraham, apparently Dragonfly uses it as well

[05:00:00.0000] <annevk>
it seems everyone sort of invents this on their own

[05:01:00.0000] <Lachy>
ok, so like ["div", {"class": "foo"}] would represent <div class="foo">

[05:02:00.0000] <jgraham>
http://dvcs.w3.org/hg/html/file/1d201654fce1/tests/resources/testharness.js#l1390 is my version of that idea

[05:02:01.0000] <jgraham>
Like I said that particular implementation kind of sucks though

[05:03:00.0000] <annevk>
Lachy, yeah

[05:04:00.0000] <annevk>
jgraham why did you have the special text node thing?

[05:05:00.0000] <jgraham>
annevk: If you want to create a text node but also use the simple format string functionality I added. I think it might have been just to make the implementation easier.

[05:06:00.0000] <jgraham>
Well I guess the point is that you can't just pass in ["text"]. And there might be some reason that you can't pass in "text" that I forget

[05:06:01.0000] <annevk>
k

[05:06:02.0000] <annevk>
once heycam is back I guess I'll take a stab at this

[05:16:00.0000] <yaffle>
hello!

[05:18:00.0000] <yaffle>
@Hixie  what about this http://www.w3.org/Bugs/Public/show_bug.cgi?id=14331 ?

[05:19:00.0000] <yaffle>
@Hixie i create test case: currently Opera and Chrome fires "message" events even after "close()"

[05:19:01.0000] <annevk>
Hixie is in California so unlikely to be awake at the moment

[05:19:02.0000] <yaffle>
@Hixie and Firefox 7 doesn't fires any "message" after close()

[05:21:00.0000] <zcorpan>
annevk: for template you probably want to return a document fragment

[05:21:01.0000] <zcorpan>
annevk: maybe new DocumentFragment(template)

[05:22:00.0000] <annevk>
rather just an element

[05:22:01.0000] <annevk>
I think

[05:22:02.0000] <zcorpan>
what if the template has just a text node?

[05:22:03.0000] <jgraham>
Being able to create a list of elements to insert into an existing element is rather convenient

[05:23:00.0000] <zcorpan>
or several elements

[05:23:01.0000] <zcorpan>
or mixed

[05:23:02.0000] <annevk>
a template is by definition an element

[05:23:03.0000] <jgraham>
Huh?

[05:24:00.0000] <annevk>
see above

[05:24:01.0000] <zcorpan>
?

[05:24:02.0000] <jgraham>
Well sure, you can write a system that only allows generating a single element

[05:24:03.0000] <annevk>
http://krijnhoetmer.nl/irc-logs/whatwg/20111003#l-289

[05:25:00.0000] <jgraham>
But that's not the definition of template

[05:25:01.0000] <annevk>
it's the definition I gave

[05:25:02.0000] <annevk>
if we are discussing a different proposal, please say so :)

[05:26:00.0000] <jgraham>
We are discussing the proposal to generalise your system to allow more than just a single element :)

[05:26:01.0000] <jgraham>
Or single subtree

[05:26:02.0000] <zcorpan>
annevk: if one wants a list of elements or list of elements mixed with text nodes, the root element of your template proposal would just be in the way

[05:28:00.0000] <jgraham>
zcorpan: So I think this could be where things start to get hairy. My system supports this because it is clearly useful

[05:29:00.0000] <jgraham>
But you need to be clear on what is a list of elements and what is supposed to be a single element

[05:29:01.0000] <jgraham>
I guess using multiple arguments would work

[05:30:00.0000] <jgraham>
documentfragment.create(elm1, elm2, etc.)

[05:31:00.0000] <annevk>
if the DocumentFragment is just for later insertion shouldn't it be directly supported on appendChild and co somehow?

[05:32:00.0000] <zcorpan>
appendChild(elm1, elm2, 'foobar') ?

[05:32:01.0000] <annevk>
not sure that syntax works well given insertBefore

[05:32:02.0000] <zcorpan>
or appendChild([elm1, elm2, 'foobar'])

[05:33:00.0000] <annevk>
that you cannot disambiguate

[05:33:01.0000] <annevk>
unless inserting a single element would require it to be wrapped

[05:33:02.0000] <zcorpan>
right

[05:33:03.0000] <annevk>
eww

[05:35:00.0000] <jgraham>
I think using lists there was one of the major mistakes I made

[05:35:01.0000] <jgraham>
rather than variable number of arguments

[06:06:00.0000] <annevk>
anyone here with opinions on event handlers?

[06:06:01.0000] <annevk>
should they move to Element?

[06:06:02.0000] <annevk>
should content attributes?

[06:07:00.0000] <Ms2ger>
I think people wanted the IDL attributes to move to Element, at least

[06:07:01.0000] <annevk>
bz argued for that, indeed

[06:08:00.0000] <annevk>
I think we can import most of what HTML says about them

[06:08:01.0000] <annevk>
we might need to define BeforeUnloadEvent

[06:09:00.0000] <annevk>
hsivonen, are you going to reply to http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1787.html ?

[06:53:00.0000] <hsivonen>
annevk: today. I can prioritize it

[06:54:00.0000] <hsivonen>
today is one of those days when every press of the return key is an opportunity to crash xorg

[06:54:01.0000] <annevk>
no need to prioritize

[06:54:02.0000] <annevk>
I'm in no rush

[07:07:00.0000] <annevk>
zcorpan, about your bug: http://dev.w3.org/cvsweb/csswg/cssom/Overview.src.html.diff?r1=1.83;r2=1.84

[07:07:01.0000] <annevk>
zcorpan, I'm not quite sure what the rationale was though :(

[07:13:00.0000] <zcorpan>
annevk: maybe it's needed for .backgroundColor etc but not for setProperty?

[07:13:01.0000] <annevk>
I guess the rationale was that backgroundColor = null should be the same as backgroundColor = ""

[07:14:00.0000] <annevk>
TreatNullAs=... would prolly be a better directive to use then

[07:20:00.0000] <hsivonen>
annevk: I replied

[07:22:00.0000] <annevk>
"the chairs have reached consensus"

[07:22:01.0000] <annevk>
is that the goal these days?

[07:27:00.0000] <annevk>
thanks hsivonen

[07:30:00.0000] <annevk>
zcorpan, should I just remove it for now?

[07:30:01.0000] <annevk>
zcorpan, nobody mentioned this as compatibility concern, but maybe Microsoft did not test thoroughly

[07:33:00.0000] <zcorpan>
annevk: i'd like it removed from setProperty at least

[07:33:01.0000] <annevk>
removed it from both

[07:34:00.0000] <annevk>
if we need TreatNullAs=Empty annotations someone should let me know

[08:00:00.0000] <djr>
Hey guys, am looking at the validator.nu project with the idea of improving the build system for deployments

[08:01:00.0000] <Ms2ger>
hsivonen, ^

[08:02:00.0000] <djr>
by improving I mean managing all the java dependencies under maven. The current python build script is good for getting things up and running

[08:04:00.0000] <djr>
just, makes it a bit awkward to deploy on any of these platforms that support java ootb

[08:34:00.0000] <djr>
okay I've gotten so far in making each of the separate components under validator.nu have their own pom file

[08:36:00.0000] <djr>
just discovered there is a circular dependency between the 'syntax' and 'utils' repos

[08:37:00.0000] <djr>
hsivonen: MikeSmith: any thoughts?

[08:40:00.0000] <MikeSmith>
djr: there are probably other circular dependencies in there as well

[08:41:00.0000] <MikeSmith>
anyway, I don't reckon hsivonen would be too keen on switching the build system to use maven

[08:41:01.0000] <MikeSmith>
me neither, really

[08:41:02.0000] <MikeSmith>
if we were to switch it something else, I'd vote for just using make

[08:42:00.0000] <djr>
MikeSmith: well I read the reasoning behind the python build script as being, so you don't need maven :)

[08:44:00.0000] <MikeSmith>
djr: I've always thought that using a python script to do the actual build is a little odd

[08:44:01.0000] <MikeSmith>
but it does seem to work well enough for most people

[08:44:02.0000] <karlcow>
first mention of "What problem are you trying to solve?"— Roy T. Fielding http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996MayAug/0019.html

[08:44:03.0000] <djr>
MikeSmith: using maven and having all the libraries treated as separate components... not having circular dependencies... that would be awesome

[08:45:00.0000] <djr>
mainly cause I think it doesn't have to be, use one or the other

[08:45:01.0000] <MikeSmith>
true

[08:45:02.0000] <djr>
was surprised to find, http://mvnrepository.com/artifact/nu.validator.htmlparser

[08:46:00.0000] <djr>
which works great, am just hacking around trying to get the whole project built like that

[08:46:01.0000] <MikeSmith>
djr: but using a real dependency-aware build system would mostly be beneficial to developers working on the sources

[08:46:02.0000] <MikeSmith>
who need to make changes to the source and rebuild while they are doing development

[08:46:03.0000] <MikeSmith>
so it would save time if they didn't have to rebuild targets whose dependencies have not changed

[08:47:00.0000] <djr>
well the python stuff would work well for dev

[08:47:01.0000] <MikeSmith>
but the fact is that the full build only takes a minute or so to run

[08:47:02.0000] <djr>
I'm suggesting maven for a production friendly build

[08:47:03.0000] <MikeSmith>
ok

[08:48:00.0000] <MikeSmith>
djr: if you have ideas on how to resolve the circular dependencies, I would be happy to help test them

[08:48:01.0000] <MikeSmith>
the biggest current problem with the build is that it always fails the very first time you run it from a fresh checkout

[08:48:02.0000] <djr>
yeah

[08:49:00.0000] <MikeSmith>
and it also has no "clean" target

[08:49:01.0000] <djr>
I'm no java expert :) am just hacking around at present

[08:50:00.0000] <djr>
am thinking a way might be to create a complete clone of everything and have a complicated pom that just builds the whole thing and not care about the dependencies

[08:50:01.0000] <djr>
well, can use the httpclient, but that's about it.

[08:51:00.0000] <djr>
The only way I would see if resolving the circular dependencies would be to split some of the stuff out of the util library

[08:52:00.0000] <djr>
and put it in a thing which depends on org.whattf

[08:55:00.0000] <kling>
is there a downloadable version of the single-page html spec somewhere?

[08:55:01.0000] <Ms2ger>
ctrl-s?

[08:55:02.0000] <kling>
(that would open in the browser without needing external resources from whatwg.org etc)

[08:55:03.0000] <Ms2ger>
Or you could checkout from svn

[08:55:04.0000] <Ms2ger>
Oh, hmm

[08:55:05.0000] <Ms2ger>
I don't think sp

[08:55:06.0000] <Ms2ger>
so*

[08:56:00.0000] <Ms2ger>
Unless the epub stuff actually happened in the end

[08:56:01.0000] <kling>
mm, okay

[09:06:00.0000] <djr>
MikeSmith: do you know who actually maintains the production install of validator.nu ?

[09:07:00.0000] <MikeSmith>
djr: you mean the http://validator.nu/ site?

[09:07:01.0000] <djr>
aye

[09:08:00.0000] <djr>
maybe am jumping the gun with all this maven shite :) all I really want to do is improve our deployment of the validator

[09:09:00.0000] <hsivonen>
indeed I'm not keen on moving to Maven

[09:09:01.0000] <djr>
currently running a massive command to java, under screen

[09:09:02.0000] <djr>
maven would be amazing as it would be a simple, git push heroku

[09:10:00.0000] <djr>
that's the only real reason

[09:12:00.0000] <timeless>
hello hsivonen

[09:18:00.0000] <hsivonen>
timeless: hello

[09:18:01.0000] <timeless>
how's finland?

[09:18:02.0000] <hsivonen>
timeless: rainy.

[09:18:03.0000] <hsivonen>
timeless: well, Helsinki at least

[09:19:00.0000] <hsivonen>
djr: the parser component used to be in Maven

[09:19:01.0000] <hsivonen>
djr: it's not anymore, because the current packaging steps do stuff that I don't know how to do in Maven

[09:21:00.0000] <djr>
hsivonen: oh, right. Dang

[09:22:00.0000] <djr>
hsivonen: I'm abandoning my approach of making each of your repos a 'library' to be managed under maven... instead trying to do something with the whole project itself

[09:24:00.0000] <hsivonen>
note that "I don't know how to do with Maven" doesn't equal "can't be done in Maven"

[09:24:01.0000] <hsivonen>
I know very little about Maven except that it makes things more complicated for me

[09:24:02.0000] <djr>
:)

[09:26:00.0000] <Yaffle>
hi

[09:26:01.0000] <djr>
yeah, I think it would be possible but because of the circular dependency it would probably need some changes to the utils / syntax repos

[09:27:00.0000] <djr>
am happy to try hack with that in the future, but I think for now I can do something that won't need any changes on your end

[09:28:00.0000] <djr>
will let you know how it goes.

[09:28:01.0000] <djr>
Thanks hsivonen / MikeSmith

[09:29:00.0000] <timeless>
more complicated hardly sounds like progress :)

[09:29:01.0000] <MikeSmith>
djr: cheers

[09:29:02.0000] <timeless>
hi MikeSmith

[09:29:03.0000] <djr>
happy to help with any of these things we've been talking about!

[09:43:00.0000] <annevk>
anyone else read this?

[09:43:01.0000] <annevk>
http://infrequently.org/2011/10/real-constructors-webidl-last-call/

[09:44:00.0000] <annevk>
bit of a rant on magical constructors

[09:48:00.0000] <Ms2ger>
Oh, is that the guy who keeps arguing about changing the default?

[09:49:00.0000] <annevk>
yeah

[09:50:00.0000] <annevk>
he works on Chrome Frame for Google, but as far as standards go...

[09:51:00.0000] <jgraham>
Alex Russel is kind of lame. He tries to rant but doesn't have any style.

[09:51:01.0000] <Ms2ger>
Did he ever explain what new HTMLHeadingElement() should return?

[09:51:02.0000] <jgraham>
He should have described lack of constructors as "cancer for the web" or something equally silly

[09:52:00.0000] <jgraham>
*Russell

[09:55:00.0000] <annevk>
that he keeps pushing a proposal which hasn't been thought through in detail is annoying and a big waste of everyone's time

[09:55:01.0000] <Ms2ger>
Welcome to web standards

[09:55:02.0000] <jgraham>
Ah, so he is good at standards then

[09:56:00.0000] <jgraham>
Do people really want to do new HTMLDivElement?

[09:56:01.0000] <jgraham>
I mean jQuery doesn't work like that

[09:56:02.0000] <Ms2ger>
I've heard that claim

[09:56:03.0000] <jgraham>
Is there some framework that works with lots of new Foo() type syntax?

[09:57:00.0000] <jgraham>
Closure?

[09:57:01.0000] <Ms2ger>
Never from an actual webdev, though

[09:57:02.0000] <jgraham>
  var newHeader = goog.dom.createDom('h1', {'style': 'background-color:#EEE'},

[09:57:03.0000] <jgraham>
    'Hello world!');

[09:58:00.0000] <jgraham>
Doesn't look much like new Foo()

[09:59:00.0000] <jgraham>
(complaining that things don't look like javascript when you work for *Google*is pretty much the definition of irony. All their javascript libraries look like java)

[09:59:01.0000] <Ms2ger>
Maybe that's why he wants it in the DOM? Then he doesn't have to use their javaey stuff

[09:59:02.0000] <zewt>
heh

[10:00:00.0000] <zewt>
that'd be a pretty gigantic hammer to work around your company having annoying libraries: "get what you want built into every browser"

[10:01:00.0000] <jgraham>
zewt: But it's just flipping a default in the WebIDL spec!

[10:02:00.0000] <annevk>
flip the default already

[10:02:01.0000] <annevk>
magical ponies for everyone

[10:02:02.0000] <annevk>
also make work

[10:02:03.0000] <annevk>
but look, ponies!

[10:02:04.0000] <zewt>
unicorns?

[10:03:00.0000] <jgraham>
With the magic ponies obsession, it's no wonder people think annevk is a girl

[10:04:00.0000] <Ms2ger>
Well done, doctor

[10:05:00.0000] <annevk>
he's no psychologist though

[10:39:00.0000] <annevk>
"FOR something so central to the modern world, the internet is shambolically governed. It is run by a hotch-potch of organisations with three- to five-letter acronyms."

[10:39:01.0000] <annevk>
now it's even more clear how secretive the WHATWG is

[10:39:02.0000] <annevk>
not recognized by The Economist!

[10:40:00.0000] <hsivonen>
I thought the governance issues were with ICANN

[10:40:01.0000] <annevk>
http://www.economist.com/node/21531011 btw

[10:40:02.0000] <zewt>
a ... hotch-potch?

[10:40:03.0000] <zewt>
(and that's skimming right over "shambolically")

[10:40:04.0000] <annevk>
hsivonen, ah governance in that sense, fair enough

[10:41:00.0000] <annevk>
zewt, what's wrong?

[10:42:00.0000] <zewt>
pretty absurd writing, heh

[10:43:00.0000] <annevk>
pretty accurate though

[11:03:00.0000] <jcranmer>
annevk: to be fair, the WHATWG isn't exactly a governing body of the internet

[11:03:01.0000] <jcranmer>
ICANN and IANA are the primary "governing" bodies

[11:05:00.0000] <jcranmer>
"Most the IETF standards mirror ITU standards (e.g. email - smtp - X.400)." ... bwahahaha

[11:05:01.0000] <jcranmer>
I much prefer foo⊙bc over CN=foo,OU=bar,OU=com :-)

[11:06:00.0000] <annevk>
yeah

[11:07:00.0000] <annevk>
what is the three-letter acronym then though?

[11:07:01.0000] <annevk>
I initially thought W3C, but that is not governing either

[11:08:00.0000] <annevk>
ooh bitbucket has Git now

[11:09:00.0000] <karlcow>
ISO?

[11:09:01.0000] <annevk>
doh

[11:10:00.0000] <annevk>
well actually

[11:10:01.0000] <annevk>
oh well

[11:10:02.0000] <Hixie>
IANA isn't a governing body, it's a registration body

[11:30:00.0000] <AryehGregor>
Gmail's rich-text editor seems to be completely broken.  Professionally, I am unsurprised.

[11:31:00.0000] <zewt>
i wish the entire html-pasting "feature" would die

[11:31:01.0000] <zewt>
the only effect it's had on my life is that every single time I paste from a webpage into gmail, I have to paste mail into a text editor and re-copy it so it doesn't paste in some random font

[11:32:00.0000] <djr>
hsivonen: MikeSmith: I believe I'm quite close here > https://raw.github.com/gist/10e1e61ee4bb32639367/20e6937b5350221487272210f14680a186bd1861/validator-nu-maven-build-failure.sh

[11:32:01.0000] <zewt>
(at least presumably the undo work will fix gmail and every other web editor's undo, which seems to essentially put the cursor in a random place after each undo)

[11:33:00.0000] <AryehGregor>
zewt, you can use the "remove formatting" feature.

[11:35:00.0000] <zewt>
don't know where that is, but I'd sooner it just stop doing that, it's nothing but an annoyance

[11:36:00.0000] <zewt>
sometimes I've just converted to plain text and back to get rid of everything

[11:36:01.0000] <AryehGregor>
It's a little T with a red X next to it.

[11:37:00.0000] <zewt>
Meaningless Icon Syndrome

[11:49:00.0000] <timeless>
zewt: hey, i do that for Outlook calendar items!

[11:49:01.0000] <timeless>
(i can't find a way to tell outlook i don't want calendar items to be rich text)

[11:50:00.0000] <AryehGregor>
Yay, sane HTTPS URLs for Wikipedia: https://en.wikipedia.org/wiki/Main_Page

[11:52:00.0000] <tomasf>
aaah. no more secure.wikimedia.org

[11:52:01.0000] <AryehGregor>
With extensive use of protocol-relative URLs, incidentally.

[11:52:02.0000] <timeless>
AryehGregor: is there a news article for this?

[11:53:00.0000] <AryehGregor>
timeless, http://www.google.com/search?q=wikipedia+protocol-relative+urls has some relevant things.

[11:53:01.0000] <AryehGregor>
timeless, http://blog.wikimedia.org/2011/10/03/native-https-support-enabled-for-all-wikimedia-foundation-wikis/

[11:53:02.0000] <AryehGregor>
There you go.

[11:53:03.0000] <timeless>
thanks, that's what i wanted :)

[11:55:00.0000] <AryehGregor>
There are techy details here: http://wikitech.wikimedia.org/view/Https

[11:55:01.0000] <AryehGregor>
They work around lack of SNI support by having one IP address for each second-level domain.

[11:55:02.0000] <AryehGregor>
And wildcard certs.

[11:57:00.0000] <timeless>
> SNI is only supported in fairly modern browsers (IE7, FX2, Opera8).

[11:57:01.0000] <timeless>
yeah, Fx2 is fairly modern... :)

[11:57:02.0000] <timeless>
(the problem of course is IE6..)

[11:57:03.0000] <AryehGregor>
Yeah.

[11:57:04.0000] <AryehGregor>
There was a surprising amount of work needed to get it to work properly.  You'd think it would be relatively simple.

[11:57:05.0000] <timeless>
is it ok for me to change that page?

[11:57:06.0000] <timeless>
oh, i can't

[11:58:00.0000] <timeless>
can you?

[11:58:01.0000] <timeless>
> In our current CNAME approach we use three service names:

[11:58:02.0000] <timeless>
s/our current/our previous/; s/use/used/

[11:59:00.0000] <AryehGregor>
I don't have a wikitech.wikimedia.org account.  It's for sysadmins only, I think.

[12:00:00.0000] <AryehGregor>
I mean, I could get one if I was interested.

[12:00:01.0000] <timeless>
can you pass along a note?

[12:00:02.0000] <AryehGregor>
You can, in #wikimedia-tech.

[12:00:03.0000] <AryehGregor>
But the entire page was evidently written before deployment.

[12:00:04.0000] <AryehGregor>
Thus "current CNAME approach".

[12:00:05.0000] <timeless>
it seems rude for someone w/ no wikipedia affiliation to do it

[12:00:06.0000] <timeless>
it's mixed actually

[12:00:07.0000] <timeless>
> To support IP based virtual hosts, we created service CNAMEs on a per project basis. The -lb suffix means "load balancing".

[12:06:00.0000] <timeless>
AryehGregor: ok, i think that was a waste of breath

[12:07:00.0000] <timeless>
but thanks for the pointer, it's a reminder of why i don't go anywhere near that stuff

[12:07:01.0000] <AryehGregor>
timeless, well, they probably have better things to do than make the tense of a documentation page consistent.

[12:09:00.0000] <AryehGregor>
They're probably more interested in, e.g., reports of actual service problems.

[12:10:00.0000] <AryehGregor>
People who write standards might appreciate editorial feedback, but people who write transient project documentation pages, not so much.

[12:11:00.0000] <timeless>
/me sighs

[12:12:00.0000] <timeless>
wikimedia documentation exists partially so that others can use it as a guideline

[12:12:01.0000] <timeless>
if it's confusing, it hurts people who might try to do that

[13:42:00.0000] <ojan>
TabAtkins: i didn't realize collapse was != display:none. What's the use-case for only collapsing the block-progression direction?

[13:44:00.0000] <sicking>
annevk: for what it's worth, it *might* be tricky to make .responseText/.responseXML throw for .responseType != "" given that webkit has been shipping an unprefixed implementation for a while

[13:50:00.0000] <TabAtkins>
ojan: Ignore what that dude says.  collapse is nothing of the sort.

[13:51:00.0000] <Hixie>
visibility:collapse has nothing to do with display:none, if that's what we're talking about. it's equivalent to visibility:hidden except in some cases involving table cells.

[13:51:01.0000] <TabAtkins>
Collapsing a table cell is just like display:none'ing it, except that it maintains the "hole" in the table.  That's basic sensical stuff, though.  There's no real analog to that for Flexbox.

[13:52:00.0000] <ojan>
TabAtkins: what's the use-cases for maintaining the "hole"?

[13:52:01.0000] <TabAtkins>
ojan: Not fucking up your columns?

[13:52:02.0000] <Hixie>
if a whole row or column is visibility:collapse, the whole row or column is removed

[13:53:00.0000] <Hixie>
otherwise, visibility:collapse is just like visibility:hidden (which is basically like opacity:0)

[13:53:01.0000] <ojan>
Hixie: i see

[13:53:02.0000] <ojan>
interesting

[13:53:03.0000] <ojan>
now that i understand all this...i need to rethink how visibility:collapse should interact w flexbox

[13:54:00.0000] <Hixie>
it's highly unlikely that you want it to do anything at all if display:none already handles your case

[13:55:00.0000] <ojan>
Hixie: the question is whether visiblity:collapse should be the new display:none for new display types

[13:55:01.0000] <Hixie>
yikes why would we do that

[13:55:02.0000] <ojan>
Hixie: that would let you use visiblity state to collapse things instad of toggling display

[13:55:03.0000] <Hixie>
why would you toggle display even

[13:55:04.0000] <ojan>
Hixie: it's kind of sucktastic that you need to toggle display to get something to collapse

[13:55:05.0000] <Hixie>
just use .hidden

[13:55:06.0000] <TabAtkins>
Hixie: display:none is a legacy mistake.

[13:56:00.0000] <ojan>
Hixie: .hidden?

[13:56:01.0000] <Hixie>
div.hidden = true; div.hidden = false;

[13:56:02.0000] <Hixie>
and in css, [hidden] { display: none; } /* or opacity:0 or whatever you want to hide the thing with */

[13:56:03.0000] <ojan>
wait...wth. how have i never heard of this before.

[13:57:00.0000] <TabAtkins>
ojan: it's the global "hidden" attribute.

[13:57:01.0000] <ojan>
mind blown

[13:57:02.0000] <TabAtkins>
Heh.

[13:57:03.0000] <ojan>
Hixie: the case that doesn't work is if you're working from a pure JS library

[13:57:04.0000] <Hixie>
http://www.whatwg.org/specs/web-apps/current-work/complete/editing.html#the-hidden-attribute

[13:58:00.0000] <Hixie>
"pure JS library"?

[13:58:01.0000] <Hixie>
[hidden] { display: none; } is in the UA stylesheet

[13:58:02.0000] <ojan>
Hixie: sorry...that was imprecise

[13:58:03.0000] <ojan>
Hixie: i mean things like jquery

[13:58:04.0000] <Hixie>
so it'll even work in a JS library that doesn't dare touch the DOM to add a stylesheet (but does to add inline style?)

[13:58:05.0000] <annevk>
sicking, we're locked down these days by one implementation?

[13:58:06.0000] <ojan>
Hixie: that don't have an associated stylesheet in the page

[13:58:07.0000] <annevk>
sicking, your argument was sort of compelling though

[13:58:08.0000] <ojan>
Hixie: yeah...i don't know why we don't use the hidden attribute

[13:59:00.0000] <ojan>
Hixie: I think js library authors might just not know about it?

[13:59:01.0000] <Hixie>
it's relatively new

[13:59:02.0000] <ojan>
ah

[13:59:03.0000] <sicking>
annevk: well.. if they refuse to change then it'll be hard to write the spec otherwise

[13:59:04.0000] <ojan>
TabAtkins: given the hidden attribute, does it make sense to propagate visiblity:collapse to other elements?

[13:59:05.0000] <sicking>
annevk: but if my argument convinced you then it's not a problem anyway :-)

[14:00:00.0000] <TabAtkins>
ojan: Maybe not.

[14:00:01.0000] <ojan>
TabAtkins: i'll think about this more and comment on thread

[14:00:02.0000] <TabAtkins>
ojan: cool.

[14:01:00.0000] <annevk>
sicking, might be hard to change encoding stuff too then

[14:02:00.0000] <sicking>
annevk: yeah, i was worrying about that

[14:02:01.0000] <zcorpan>
something being shipped doesn't mean there are compat constraints necessarily

[14:02:02.0000] <sicking>
annevk: i am curious what they were going to do once they do .responseType in worker-xhr though

[14:02:03.0000] <sicking>
annevk: unless they're going to spin up a DOM-less HTML parser

[14:02:04.0000] <Hixie>
ojan: it was introduced as "placeholder" in April 2007, quickly changed to "irrelevant" a few hours later, and became "hidden" in August 2008.

[14:03:00.0000] <Hixie>
ojan: been pretty stable since, and is now implemented in a few browsers.

[14:04:00.0000] <sicking>
Hixie: by the way, did you consider my proposal to allow pointing internal references to stuff inside @hidden elements?

[14:04:01.0000] <annevk>
sicking, I wonder if XHR should account for Workers in the specification

[14:04:02.0000] <annevk>
hmm

[14:04:03.0000] <annevk>
also, you already have that problem with XML

[14:05:00.0000] <sicking>
annevk: you mean for .responseType=""

[14:05:01.0000] <sicking>
?

[14:05:02.0000] <sicking>
annevk: .responseXML always returns null or throws in workers. Don't recall which

[14:06:00.0000] <timeless>
abarth|gardener: hello

[14:06:01.0000] <zcorpan>
but responseText looks for an xml decl still?

[14:06:02.0000] <abarth|gardener>
timeless: hi

[14:06:03.0000] <timeless>
so... perhaps a small iteration round

[14:06:04.0000] <timeless>
>> If RDF-flag is 1 and RSS-flag is 1, then let the sniffed-type be "application/rss+xml" and abort these steps.

[14:06:05.0000] <nlogax>
i just noticed that chromium lets me nest anchors, and it works beautifully. bug or feature?

[14:06:06.0000] <abarth|gardener>
yessir

[14:06:07.0000] <sicking>
zcorpan: i think in our implementation it currently does, yeah. But that will change once we fix some architectural stuff

[14:07:00.0000] <timeless>
could you change that to: If both RDF-flag and RSS-flag are 1, then ...?

[14:07:01.0000] <abarth|gardener>
sure

[14:07:02.0000] <sicking>
zcorpan: right now worker-xhr runs on the main thread in gecko. Which severely affects performance

[14:07:03.0000] <sicking>
zcorpan: and implementation complexity

[14:07:04.0000] <timeless>
abarth|gardener: note that i have a tendency to read specs in text/plain

[14:07:05.0000] <timeless>
which can be why i might miss 'green' text :)

[14:07:06.0000] <AryehGregor>
nlogax, "nest anchors" how?

[14:08:00.0000] <AryehGregor>
nlogax, Chromium most likely follows the spec here.

[14:08:01.0000] <abarth|gardener>
timeless: done

[14:08:02.0000] <nlogax>
AryehGregor: var a = document.createElement("a"); var b = same...; a.appendChild(b);

[14:08:03.0000] <AryehGregor>
nlogax, yes, that will work in all browsers.

[14:08:04.0000] <nlogax>
AryehGregor: awesome :)

[14:08:05.0000] <AryehGregor>
Or should.

[14:08:06.0000] <AryehGregor>
.innerHTML will break, though.

[14:08:07.0000] <annevk>
sicking, responseText

[14:08:08.0000] <sicking>
annevk: ?

[14:08:09.0000] <timeless>
> >> Comparisons between media types, as defined by MIME specifications, are done in an ASCII case-insensitive manner. [RFC2046]

[14:09:00.0000] <AryehGregor>
It will serialize it to <a href=x><a href=y>foo</a></a>, which will become <a href=x></a><a href=y>foo</a><a></a> if you use it in actual markup.

[14:09:01.0000] <timeless>
so, the problem is that your `note` here is ambiguous

[14:09:02.0000] <annevk>
sicking, responseText uses XML

[14:09:03.0000] <AryehGregor>
The text/html syntax doesn't support nested anchors, but the DOM does.

[14:09:04.0000] <AryehGregor>
So beware.

[14:09:05.0000] <AryehGregor>
nlogax, ^^

[14:09:06.0000] <timeless>
it's hard to understand that you're just saying `mime rfc says that mime comparisons are insensitive`

[14:09:07.0000] <timeless>
v. `this specification wants mime comparisons to be insensitive`

[14:09:08.0000] <sicking>
annevk: you mean when .responseType == ""?

[14:09:09.0000] <timeless>
you want the former

[14:09:10.0000] <timeless>
but `note:` doesn't cause that result

[14:09:11.0000] <annevk>
sicking, currently either "" or "text"

[14:10:00.0000] <timeless>
nor does the `[rfc....]` at the end

[14:10:01.0000] <timeless>
does that kinda make sense?

[14:10:02.0000] <sicking>
annevk: right, only when "" in my proposal

[14:10:03.0000] <sicking>
annevk: but yes, it's a problem

[14:10:04.0000] <timeless>
> I'm tempted to just rename them to be less semantic.  They're just symbols that don't mean anything, really.

[14:10:05.0000] <timeless>
please do :)

[14:10:06.0000] <sicking>
annevk: i was actually thinking that we should make .responseType default to "text" for worker-xhr. But i'm not terribly excited by that idea

[14:10:07.0000] <timeless>
> That's a lot of editing!  I'm not sure that buys us much.

[14:11:00.0000] <timeless>
i ask, because it actually was useful when i was dealing w/ someone else's spec

[14:11:01.0000] <nlogax>
AryehGregor: thanks, yeah i saw that behavior when just opening a regular ol' html document. it's very useful, wish it worked there as well.. :)

[14:11:02.0000] <timeless>
they had hex digits and some of them were wrong

[14:11:03.0000] <annevk>
sicking, in workers we could make "" and "text" the same

[14:11:04.0000] <timeless>
it was much easier to read when the hex digits were in <tt>

[14:11:05.0000] <sicking>
annevk: yeah, that'd work too

[14:11:06.0000] <AryehGregor>
nlogax, it can't, because of legacy pages that rely on current browser behavior.

[14:11:07.0000] <timeless>
> That is intentional.  Sniffing SWF is bad times.

[14:11:08.0000] <annevk>
still not sure how much of the HTML parser we want to use

[14:12:00.0000] <nlogax>
AryehGregor: i see. oh well, can at least use it in this all-js thing. :)

[14:12:01.0000] <sicking>
annevk: when actually parsing into a DOM?

[14:12:02.0000] <annevk>
I guess what hsivonen suggested sounded okay

[14:12:03.0000] <AryehGregor>
nlogax, as long as you don't expect .innerHTML to work properly.

[14:12:04.0000] <timeless>
i think it might be worth an actual NOTE in the spec explaining that SWF is intentionally not sniffed, and what that means for untyped SWF files (actually explaining how it flows and to which resulting sniff type)

[14:12:05.0000] <AryehGregor>
nlogax, it's somewhat risky that way.  You might be better off making sure they don't overlap.

[14:12:06.0000] <AryehGregor>
Otherwise you risk hitting confusing bugs far down the line when something tries using .innerHTML or similar features somewhere.

[14:13:00.0000] <zcorpan>
AryehGregor: iirc the html parser can end up with nested <a>s

[14:13:01.0000] <zcorpan>
AryehGregor: with foster parenting

[14:13:02.0000] <timeless>
> Thanks to Alfred HÎnes Boris Zbarsky David Singer Mark Pilgrim, and Russ Cox.

[14:14:00.0000] <AryehGregor>
zcorpan, or maybe if there's an intervening <button> or something.  But not from plain <a><a>.

[14:14:01.0000] <nlogax>
AryehGregor: hmm yeah, i can't imagine why anyone would do that in this case, but you are right, less possible weirdness is good. but it's like it was made for this.. http://dl.dropbox.com/u/28029058/Screen%20Recording.mov

[14:14:02.0000] <timeless>
you  need some punctuation before `Boris`, `David`, and `Mark` :)

[14:14:03.0000] <nlogax>
was going to add a big anchor somewhere and just position it on top of the other stuff and so on.. but tried thatand was surprised to see it work

[14:15:00.0000] <sicking>
annevk: i really don't know how much encoding stuff will be a problem in some locales

[14:15:01.0000] <sicking>
locals

[14:15:02.0000] <timeless>
abarth|gardener: ok, i think that's all the comments for today

[14:15:03.0000] <timeless>
i'll try to serialize that into an email for the record

[14:16:00.0000] <annevk>
it's a new feature

[14:16:01.0000] <abarth|gardener>
thanks.  I appreciate all the comments

[14:16:02.0000] <annevk>
they'll adapt

[14:16:03.0000] <AryehGregor>
zcorpan, what's a case where it will work with foster parenting?

[14:16:04.0000] <sicking>
annevk: errr..

[14:17:00.0000] <zcorpan>
AryehGregor: <a><table><a>

[14:17:01.0000] <annevk>
also, more than 50% of the web or so already is UTF-8

[14:17:02.0000] <sicking>
annevk: do you have any idea how much they'll have to rewrite?

[14:17:03.0000] <zcorpan>
AryehGregor: button doesn't give nested a

[14:17:04.0000] <AryehGregor>
zcorpan, awesome.

[14:17:05.0000] <sicking>
annevk: 50% of the web is a lot of pages

[14:18:00.0000] <AryehGregor>
Are we talking about not supporting non-UTF-8 pages for new features?

[14:18:01.0000] <annevk>
I hope you don't believe the remaining 50% is untagged

[14:18:02.0000] <AryehGregor>
If so, I'm heartily in favor.

[14:18:03.0000] <AryehGregor>
Well, kind of.

[14:18:04.0000] <AryehGregor>
At least if it's a pain to support other encodings.

[14:18:05.0000] <timeless>
abarth|gardener: oh, i should be added to the list ;-)

[14:18:06.0000] <AryehGregor>
Maybe we can make UTF-8 the new XHTML: don't support any new features on sites using legacy encodings!

[14:19:00.0000] <AryehGregor>
It might work better than with XHTML, since UTF-8 actually is technically superior in every respect to the competitors for practically all sites . . .

[14:19:01.0000] <zcorpan>
hey, IE could add a new rendering mode that just accepts utf-8

[14:20:00.0000] <reggna>
Been playing #BF3 Beta with my laptop mouse during the weekend; bought a G400 today though, so everything is back to normal.

[14:20:01.0000] <Hixie>
jgraham: 503

[14:20:02.0000] <jamesr_>
yo standards monkeys and kibitzers

[14:20:03.0000] <AryehGregor>
zcorpan, I love how <a href=x><table><a href=y>foo</table> puts foo in a double link while leaving the actual table empty and invisible.

[14:20:04.0000] <jamesr_>
i want to read adobe's latest CSS proposal: https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html

[14:20:05.0000] <jamesr_>
but it throws mixed http/https warnings

[14:20:06.0000] <AryehGregor>
You could use that for parser hacks.

[14:20:07.0000] <AryehGregor>
jamesr_, use http://dvcs.w3.org instead?  :)

[14:20:08.0000] <sicking>
annevk: I would be very sad if we did something that so deeply affects other locals without even checking with them what that'll mean

[14:20:09.0000] <jamesr_>
because dvcs.w3.org serves resources over https, but they only server css/js resources over http

[14:20:10.0000] <timeless>
s/server/serve/

[14:20:11.0000] <annevk>
jamesr_, read http://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html instead?

[14:21:00.0000] <jamesr_>
AryehGregor, that works but why does it serve the https:// version at all?

[14:21:01.0000] <sicking>
annevk: It might mean that asian websites can't transition to use ajax as easily for example

[14:21:02.0000] <zcorpan>
AryehGregor: foster parenting is great for reordering content

[14:21:03.0000] <timeless>
jamesr_: it isn't wrong to support https

[14:21:04.0000] <jamesr_>
and all of the internal links are https://

[14:21:05.0000] <AryehGregor>
jamesr_, all of w3.org seems to be set up to serve either http or https interchangeably.

[14:21:06.0000] <timeless>
the adobe content could be changed to use protocol relative paths...

[14:21:07.0000] <jamesr_>
right, but parts seem to be intentionally http only

[14:21:08.0000] <jamesr_>
it could

[14:21:09.0000] <AryehGregor>
jamesr_, you should tell the draft authors to use protocol-relative URLs for the mixed-content resources.

[14:21:10.0000] <annevk>
sicking, what?

[14:21:11.0000] <sicking>
annevk: saying "it's a new feature, they'll adapt" might mean that they have a serious disadvantage for the next 5-10 years

[14:22:00.0000] <jamesr_>
does everyone support protocol-relative URLs?

[14:22:01.0000] <annevk>
sicking, euhm...

[14:22:02.0000] <annevk>
sicking, XHR is pretty much UTF-8 only at the moment

[14:22:03.0000] <timeless>
jamesr_: wikipedia is using them

[14:22:04.0000] <jamesr_>
timeless, kk

[14:22:05.0000] <timeless>
so presumably anyone who matters does :)

[14:22:06.0000] <annevk>
if they haven't adapted by now, they've had a disadvantage for a decade now

[14:22:07.0000] <AryehGregor>
jamesr_, Wikipedia just started using them on all sites, so I hope so.

[14:22:08.0000] <annevk>
would be kind of odd

[14:22:09.0000] <AryehGregor>
https://en.wikipedia.org/ <-- look at source

[14:22:10.0000] <sicking>
annevk: but we haven't been reading HTML contents until now

[14:22:11.0000] <ojan>
Hixie: oh right. i remember irrelevant. lol.

[14:22:12.0000] <sicking>
annevk: there's a lot of HTML contents in non-UTF8 out there

[14:22:13.0000] <sicking>
annevk: 50% of a few trillion pages

[14:23:00.0000] <sicking>
iirc

[14:23:01.0000] <AryehGregor>
AFAIK, Wikipedia's testing found no clients at all that didn't support them.  The only issues were things like "we don't want to output protocol-relative URLs to e-mail/print/feeds/..."

[14:23:02.0000] <annevk>
sure

[14:23:03.0000] <annevk>
but it's not all untagged

[14:23:04.0000] <AryehGregor>
So it required a bunch of work to get MW to work well with them.

[14:23:05.0000] <sicking>
annevk: gotta run

[14:23:06.0000] <AryehGregor>
jamesr_, alternatively, they could just unconditionally load the resources over HTTPS.  It looks like just a stylesheet and an icon.

[14:23:07.0000] <zcorpan>
don't we have data on how much unlabeled non-utf-8 html content there is?

[14:24:00.0000] <annevk>
but if they are just going to read some HTML content... I'm not even sure how that stuff would work

[14:24:01.0000] <jamesr_>
AryehGregor, W3C doesn't serve these over https

[14:24:02.0000] <AryehGregor>
jamesr_, https://www.w3.org/StyleSheets/TR/W3C-ED.css https://www.w3.org/Icons/w3c_home

[14:24:03.0000] <AryehGregor>
WFM

[14:24:04.0000] <zcorpan>
we could make xhr inherit the page's encoding for text/html

[14:24:05.0000] <jamesr_>
ooh

[14:24:06.0000] <zcorpan>
if there's no decl

[14:24:07.0000] <jamesr_>
i ran into some resource on the rAF spec that the w3 wasn't serving over https

[14:25:00.0000] <zcorpan>
and in workers it'd use utf-8 since workers are utf-8

[14:25:01.0000] <AryehGregor>
whatwg.org doesn't serve its stylesheets and things over HTTPS, so I can't make my spec work right now without mixed content.  :(

[14:25:02.0000] <AryehGregor>
Otherwise I'd use HTTPS URLs too.

[14:25:03.0000] <zcorpan>
or maybe that'd be annoying when moving from <script> to worker

[14:26:00.0000] <zcorpan>
AryehGregor: just write a script that copies the stuff over to your server every once in a while

[14:27:00.0000] <annevk>
inheriting the encoding sounds like a terrible idea

[14:28:00.0000] <annevk>
that stuff is already annoying with <script>, especially when it comes to caching and such

[14:28:01.0000] <AryehGregor>
Hixie, can we have whatwg.org stuff on HTTPS too?  I want https://www.whatwg.org/style/specification and https://www.whatwg.org/specs/web-apps/current-work/dfn.js so that https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html works without mixed content.  Also, a pony.

[14:30:00.0000] <AryehGregor>
/me votes for using DNSSEC stapling instead of buying a cert

[14:33:00.0000] <zcorpan>
annevk: yeah

[14:37:00.0000] <timeless>
AryehGregor: the pony might be cheaper than dnssec

[14:37:01.0000] <timeless>
AryehGregor: can you offer the poney room and board?

[14:37:02.0000] <timeless>
i could probably help you w/ the getting part

[14:38:00.0000] <AryehGregor>
timeless, are registrars charging for DNSSEC on supported TLDs?  You'd think it wouldn't really cost them anything extra.

[14:38:01.0000] <AryehGregor>
.org is signed.

[14:38:02.0000] <AryehGregor>
(.name is not :( )

[14:38:03.0000] <timeless>
AryehGregor: how many browsers support dnssec?

[14:38:04.0000] <AryehGregor>
(nor is .il :( )

[14:39:00.0000] <AryehGregor>
timeless, DNSSEC stapling in certs is supported by Chrome.  Firefox is looking at it last I heard.  The client doesn't need to actually support DNSSEC.

[14:39:01.0000] <timeless>
http://www.pir.org/get/registrars?order=field_dnssec_value&sort=desc

[14:39:02.0000] <AryehGregor>
It's clever: all it does is stick the signed DNS record where the cert should be.

[14:39:03.0000] <AryehGregor>
After all, with DNSSEC you know the record is correct no matter where it comes from, so there's no need for the client to actually query a DNSSEC server.

[14:41:00.0000] <timeless>
/me hasn't looked to see how many ways clients can screw up dnssec

[14:41:01.0000] <timeless>
/me is currently thinking about certain other technologies

[14:41:02.0000] <AryehGregor>
Answer: lots.

[14:41:03.0000] <AryehGregor>
Which is why it's great that the stapling solution doesn't require client DNSSEC support.

[14:41:04.0000] <timeless>
atm i'm more interested in how banks and credit card vendors can screw up deployments of things

[14:42:00.0000] <AryehGregor>
Answer: also lots of ways.

[14:43:00.0000] <timeless>
hrm

[14:43:01.0000] <timeless>
my office phone tells me someone rang my doorbell erev rosh hashanah

[14:43:02.0000] <timeless>
/me wonders why

[14:58:00.0000] <annevk>
AryehGregor, what's wrong with http?

[14:58:01.0000] <AryehGregor>
annevk, it's insecure.  Someone might MITM our precious specs!

[14:59:00.0000] <jamesr_>
chrome's getting more aggressive about warning about mixed http/https content, since when it's not just a precious spec MITM attacks do matter

[15:00:00.0000] <annevk>
TR/ is pretty successful at man-in-the-middle'ing them and will do so even when they are served over TLS :p

[15:00:01.0000] <annevk>
alright, really nap time now

[15:06:00.0000] <TabAtkins>
Macroeconomic theory, as explained via the medium of rap: http://www.youtube.com/watch?v=GTQnarzmTOc

[15:09:00.0000] <hober>
TabAtkins: classic, though the first one was better

[15:21:00.0000] <danbeam>
add 0 stevet⊙gc

[15:21:01.0000] <danbeam>
d'oh, sorry guys

[15:43:00.0000] <Hixie>
sicking: i do not recall (re the hidden thing), probably still an open bug. i think the spec says no currently.

[15:48:00.0000] <sicking>
Hixie: ok, I don't think i ever filed a bug on the spec, Want me to open one?

[15:49:00.0000] <Hixie>
didn't you send mail about it or something? i seem to recall seeing it discussed but i don't think i've gotten to it yet

[16:01:00.0000] <Hixie>
jgraham: dude pms isn't working for me at all anymore

[16:02:00.0000] <TabAtkins>
Hixie: I'm surprised pms every worked for you, given your gender.


2011-10-04
[17:09:00.0000] <ojan>
TabAtkins: aahhhhh. writing test-cases for some of these flexbox things is so confusing.

[17:09:01.0000] <ojan>
TabAtkins: it's surprisingly hard to think about what the correct rendering is for many cases.

[17:12:00.0000] <TabAtkins>
Yus.  Anything in particular?

[17:14:00.0000] <ojan>
TabAtkins: <div class="flexbox vertical-rl column"> versus <div class="flexbox vertical-lr column">

[17:14:01.0000] <ojan>
TabAtkins: assume the classnames set the display, writing-mode and flex-flow values respectively

[17:14:02.0000] <ojan>
TabAtkins: do those render the same? or is one the reverse order of the other

[17:15:00.0000] <ojan>
TabAtkins: in my current implementation it's rendering them reverse...but i think it might be wrong?

[17:15:01.0000] <TabAtkins>
The lr/rl set the block-flow direction.  The inline-flow direction is top-to-bottom in both.

[17:16:00.0000] <TabAtkins>
So, since 'column' makes the main direction follow the block-flow direction, they'd be reversed.

[17:16:01.0000] <ojan>
TabAtkins: ok. that explanation makes sense.

[17:17:00.0000] <ojan>
TabAtkins: so, ignoreing multiline, <div class="flexbox vertical-rl column"> would render the same as <div class="flexbox horizontal-tb row rtl">

[17:17:01.0000] <ojan>
TabAtkins: i say ignoring multiline because i haven't even sstarted thinking about how multiline affects things.

[17:18:00.0000] <TabAtkins>
Yes, they'd render the same.

[17:18:01.0000] <ojan>
TabAtkins: they'd render the same except for padding-start, etc would be ltr in the first case and rtl in the second

[17:18:02.0000] <TabAtkins>
They'd also render the same in multiline, since the perpendicular axises go in the same direction for both.

[17:18:03.0000] <TabAtkins>
Yes.

[17:18:04.0000] <ojan>
TabAtkins: great.

[17:19:00.0000] <ojan>
TabAtkins: thx for helping me think this through. you might want to give some of the above as examples in the spec.

[17:19:01.0000] <ojan>
TabAtkins: since they clarify expected behavior. i think the spec text matches what you just described, but it's hard to think all that through.

[17:20:00.0000] <TabAtkins>
Heh, kk.  I need to draw up pictures for some of these, because writing-modes are hard to wrap your head around.

[17:20:01.0000] <ojan>
yes!

[17:20:02.0000] <TabAtkins>
The spec text definitely matches what I just said, because I checked it before saying anything just to make sure.  ^_^

[17:20:03.0000] <ojan>
TabAtkins: by far, the hardest part of implementing any of this is thinking through the tests

[17:20:04.0000] <ojan>
TabAtkins: the C++ code is mostly relatively straightforward

[17:22:00.0000] <TabAtkins>
Related: urgh, writing the "figure out the hypothetical size of each flexbox item" is the hardest part of the algorithm.

[17:23:00.0000] <ojan>
TabAtkins: yup, the rest of the algorithm is relatively straightforward i think

[17:45:00.0000] <Hixie>
who's a good person to cc for perf wg issues?

[17:46:00.0000] <TabAtkins>
jamesr_ ?

[17:46:01.0000] <ojan>
Hixie: jamesr_ works with perf wg stuff a lot, i'm not sure how directly involved he is with the wg, but i believe he's editor of requestAnimationFram spec

[17:46:02.0000] <Hixie>
k

[17:49:00.0000] <jamesr_>
sup?

[17:49:01.0000] <jamesr_>
Hixie, i'm editor of requestAnimationFrame and sit close to people who follow the rest of the specs

[17:49:02.0000] <jamesr_>
heycam's also editor on rAF

[17:49:03.0000] <jamesr_>
i'm not sure of his level of involvement in other specs

[17:49:04.0000] <jamesr_>
(and i've been too busy lately to do much at all, but oh well)

[17:51:00.0000] <Hixie>
cced you on a bug

[17:51:01.0000] <Hixie>
w3c bug

[17:52:00.0000] <jamesr_>
Hixie, kk

[17:52:01.0000] <Hixie>
on another note, chrome trunk has an absurd regression rendering the html spec

[17:53:00.0000] <Hixie>
taking 100s of milliseconds to repaint, continuously

[17:53:01.0000] <Hixie>
even if nothing happens but mouse movement

[18:03:00.0000] <jamesr_>
can you file a bug?

[18:18:00.0000] <Hixie>
jamesr_: jamesr_ http://code.google.com/p/chromium/issues/detail?id=98963

[18:26:00.0000] <TabAtkins>
Hixie, ojan: fantasai reminded me why display:none isn't very good, and thus why we probably do want a different model of hiding, such as what visibility:collapse might be able to offer.

[18:27:00.0000] <TabAtkins>
display:none has additional magic effects beyond the hiding - it also suppresses list counter increments, and there's a good chance it'll be defined as suppressing animations too.

[18:27:01.0000] <ojan>
TabAtkins: i see that thread...i'll respond eventaully...if we want a different behavior, that's fine....but retro-fitting visibility:collapse for that seems wrong since it already does the wrong thing most of the time

[18:28:00.0000] <TabAtkins>
(This is because display:none subtrees are generally optimized away almost completely.)

[18:28:01.0000] <Hixie>
TabAtkins: sure, that's why i said you map [hidden] whatever you actually need

[18:28:02.0000] <TabAtkins>
ojan: Yeah, perhaps.

[18:28:03.0000] <Hixie>
TabAtkins: height:0, width:0, opacity:0, whatever it is you're styling

[18:28:04.0000] <Hixie>
s/styling/animating/

[18:28:05.0000] <ojan>
TabAtkins: fantasai basically wants visiblity:collapse to be height:0;overflow:hidden, right?

[18:29:00.0000] <ojan>
s/height/logicalHeight/

[18:29:01.0000] <TabAtkins>
Well, for block elements, yeah.

[18:29:02.0000] <ojan>
right

[18:29:03.0000] <TabAtkins>
That's not sufficient for flexbox items, because of flex-pack:justify.

[18:29:04.0000] <zewt>
it'd be unpleasant if using hidden results in a slower page than display: none

[18:30:00.0000] <TabAtkins>
I suspect a better definition might be "position:absolute; height:0; width:0;".  Still completely out-of-flow, but it generates boxes.

[18:30:01.0000] <zewt>
i guess that'd mean everyone would force [hidden] to display: none if it made a visible (err, ... perceptible, heh) difference

[18:31:00.0000] <ojan>
TabAtkins: regardless, this should clearly be a new property/value

[18:31:01.0000] <TabAtkins>
Yeah, you're probably right.  So I should still revert the visibility:collapse change.

[18:35:00.0000] <Hixie>
position:absolute is not much better than display:none, since it overrides 'display'

[18:35:01.0000] <Hixie>
but it does happen to not screw up counters

[18:35:02.0000] <TabAtkins>
It's much better in that it still generates a box, yeah.

[18:36:00.0000] <Hixie>
i think height:0 or width:0 is what you typically want if you want to affect layout

[18:36:01.0000] <Hixie>
then you'd get a transition and so on

[18:36:02.0000] <Hixie>
animating 'position' isn't likely to be useful

[18:37:00.0000] <TabAtkins>
Just setting height or width doesn't work for flexbox.  You can still detect the presence of the "hidden" element if "flex-pack:justify" is used, because it'll look like a double-wide space there.

[18:37:01.0000] <Hixie>
that seems... bad

[18:37:02.0000] <Hixie>
why is it not bad?

[18:37:03.0000] <TabAtkins>
Do you mean that it's bad that this effect occurs?

[18:38:00.0000] <Hixie>
well it seems like if your box has no height or width it should probably not make spaces appear

[18:38:01.0000] <Hixie>
but i'm not familiar with contemporary flexbox ideas

[18:39:00.0000] <TabAtkins>
flex-pack distributes the leftover space when all the items are done flexing.  'justify' puts it equally between every item.

[18:40:00.0000] <Hixie>
ah, i see

[18:40:01.0000] <Hixie>
so you want a margin-collapsing-like effect

[18:40:02.0000] <Hixie>
hmm

[18:40:03.0000] <TabAtkins>
Maybe?  Note, though, that even if you did have something that acted like margin-collapsing, it still wouldn't animate well.

[18:40:04.0000] <Hixie>
how would you transition from the element being there to the element not being there and the space being distibuted as if it was not?

[18:41:00.0000] <Hixie>
with the spacing animating properly the whole way through?

[18:41:01.0000] <TabAtkins>
As soon as you stopped meeting the requirements for collapsing through, the two spaces would uncollapse and you'd have a wider space again.

[18:41:02.0000] <Hixie>
seems like that's the problem to fix

[18:41:03.0000] <TabAtkins>
Yeah, you can't.

[18:41:04.0000] <TabAtkins>
As far as I can tell.

[18:41:05.0000] <TabAtkins>
Because that would require the algorithm to be stateful.

[18:41:06.0000] <Hixie>
that seems bad. people are all about their animations these days.

[18:41:07.0000] <Hixie>
that's probably the place to start in trying to fix this

[18:42:00.0000] <TabAtkins>
There's a difference between the desired spacing around an element that just un-hid and the desired spacing around an element of the same size that's been sitting there the whole time.

[18:43:00.0000] <Hixie>
there's a difference between the spaces around the other elements in those two cases too

[18:43:01.0000] <TabAtkins>
Yes.

[18:43:02.0000] <Hixie>
but it seems one needs a solution that allows for that value to transition smoothly

[18:43:03.0000] <Hixie>
for this to be useful in practice

[18:44:00.0000] <jamesr_>
Hixie, you're using Leopard?

[18:48:00.0000] <Hixie>
jamesr_: yes

[00:12:00.0000] <zcorpan>
Hixie: maybe we should count keystrokes in the comment box to prevent people from pasting a chunk of the spec and submitting that

[00:51:00.0000] <Hixie>
zcorpan: send me a patch

[00:51:01.0000] <Hixie>
zcorpan: going to bed now

[00:51:02.0000] <Hixie>
i haven't been able to update the spec today, jgraham's site has been down for me

[00:57:00.0000] <annevk>
http://infrequently.org/2011/10/real-constructors-webidl-last-call/#comment-238768 sadly true

[00:59:00.0000] <Hixie>
yet more reasons why "last call" is a waste of time...

[01:00:00.0000] <Hixie>
ok really gonig to bed now

[01:00:01.0000] <Hixie>
nn

[01:02:00.0000] <hsivonen>
http://www.adobe.com/devnet/html5/articles/css-shaders.html

[01:02:01.0000] <hsivonen>
it seems that Adobe has really decided to do their stuff in WebKit instead of Flash Player from now on

[01:06:00.0000] <hsivonen>
Do vertex shaders make it possible to do hit testing computations easily when the user interacts with a distorted mesh?

[02:24:00.0000] <Philip`>
hsivonen: The usual approach for hit testing on the GPU is to render the scene with a different solid colour per object, then read back the colour underneath the mouse cursor to figure out which object it was

[02:24:01.0000] <Philip`>
and doing it on the CPU instead sounds hard (since you'd have to emulate the vertex shaders, with adequate performance)

[02:25:00.0000] <Philip`>
so it doesn't seem like a trivial problem either way

[03:01:00.0000] <hsivonen>
Philip`: so you have to enumerate hit targets ahead of time

[03:02:00.0000] <hsivonen>
Philip`: what if the user clicks a distorted canvas. is there any feasible way to deliver the click coordinates to JS in the undistorted coordinate space?

[03:08:00.0000] <Philip`>
I don't think I've ever heard of anything like that (though it might be technically possible with some hack like rendering to a floating-point buffer with the R channel corresponding to the original x coordinate and G channel for y, then read back the colour to get the original coordinates, or something)

[03:08:01.0000] <Philip`>
/me would defer to someone with more experience of this kind of stuff, though

[03:10:00.0000] <foolip>
gsnedders, how old were you when you attended your first W3C meeting?

[03:10:01.0000] <foolip>
we have disagreement in the office, the lowest bid being 12 :)

[03:11:00.0000] <jgraham>
Wasn't it TPAC 2008 when he was, uh, 16?

[03:12:00.0000] <foolip>
that sounds more... sane

[03:13:00.0000] <annevk>
http://www.flickr.com/photos/gsnedders/2964101064/

[03:14:00.0000] <jgraham>
First post to WHATWG was january 2007 when he was 14ish

[06:33:00.0000] <RIch_Clark>
I'm seeing a few use cases for <output> like this http://jsfiddle.net/robertc/YCEKQ/ question is, is that an appropriate use case as it doesn't really represent "the result of a calculation" can anyone advise?

[06:36:00.0000] <zcorpan>
why is it not a result of a calculation?

[06:37:00.0000] <Rich_Clark>
because it's a single input, nothing is 'calculated' by moving a slider for type=range, it's just showing the current value

[06:40:00.0000] <zcorpan>
yeah. file a spec bug with the use case :)

[06:43:00.0000] <Rich_Clark>
Sure, to confirm do you think the output wording needs editing to allow a use case as this?

[06:44:00.0000] <zcorpan>
probably yeah

[06:44:01.0000] <Rich_Clark>
ok cheers

[09:38:00.0000] <annevk>
smaug____, so why exactly does the Gecko insertNode behavior make sense?

[09:39:00.0000] <annevk>
smaug____, from http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#Level-2-Range-Insertions it does seem like insert operations result in including the inserted node into the range

[09:39:01.0000] <annevk>
of course they are non-normative examples

[09:39:02.0000] <smaug____>
because of consistency, but since others changed behavior to match acid3, I think gecko may do so too

[09:39:03.0000] <annevk>
but what else can you go by with the standards from 2000

[09:39:04.0000] <smaug____>
per D2R Gecko behavio is right

[09:40:00.0000] <annevk>
consistency with what?

[09:40:01.0000] <smaug____>
consistency with other dom mutations

[09:40:02.0000] <annevk>
really?

[09:45:00.0000] <smaug____>
yes :)

[09:48:00.0000] <annevk>
where is that defined?

[09:49:00.0000] <annevk>
ah yeah

[09:49:01.0000] <annevk>
okay

[09:50:00.0000] <annevk>
so do we now do this for collapsed ranges in general?

[09:50:01.0000] <annevk>
or only for insertNode?

[09:50:02.0000] <annevk>
my apologies for being slow

[09:50:03.0000] <timeless>
has anyone here installed a `cvs` client on windows recently?

[09:50:04.0000] <timeless>
/me is having trouble *finding* cvsnt

[09:50:05.0000] <annevk>
cygwin?

[09:51:00.0000] <annevk>
when I had Windows, cygwin was the way

[09:51:01.0000] <annevk>
but IE6 was too, so...

[09:51:02.0000] <timeless>
cygwin gives me headaches

[09:51:03.0000] <timeless>
/me could probably get cvs from an old moztools

[09:53:00.0000] <timeless>
seems like the primary distributor of cvsnt stopped offering it around Wednesday June 30th, 2010

[09:53:01.0000] <zewt>
fortunately cvs is dead and buried out here in the civilized world :)

[09:54:00.0000] <timeless>
yeah, http://dev.w3.org/2009/dap/contacts/CVS/is uncivilized

[09:54:01.0000] <timeless>
s/is/ is/

[09:54:02.0000] <zewt>
y

[09:54:03.0000] <annevk>
if you promise MikeSmith beer he can move it

[09:55:00.0000] <timeless>
/me was hoping to be able to do a migration and offer it up

[09:55:01.0000] <timeless>
but clearly that's too hard :(

[09:59:00.0000] <annevk>
1) why is http://w3c-test.org/webperf/specs/ResourceTiming/ on w3c-test.org?

[09:59:01.0000] <annevk>
2) it does not define basic terms such as "browsing context" and "fetch" and went into Last Call anyway?

[10:00:00.0000] <annevk>
nobody does any basic checks anymore?

[10:01:00.0000] <arun_>
/me sets a trap for heycam and lurks

[10:08:00.0000] <jgraham>
annevk: There is a small community that doesn't totally suck at spec writing and they don't have time to follow all the specs people are trying to write

[10:08:01.0000] <annevk>
I'm not sure that spec is good

[10:09:00.0000] <annevk>
it's not really bad, but still

[10:09:01.0000] <annevk>
I gave some feedback

[10:09:02.0000] <annevk>
last time I gave feedback to web-perf however I think it went largely unaddressed because plh distracted it by focusing on a very simple thing

[10:10:00.0000] <annevk>
jgraham, the main problem here is that these specs are not developed in WebApps

[10:10:01.0000] <arun_>
Hmm... that spec. also has outdated references (why DOM3Core, for example?)

[10:10:02.0000] <timeless>
arun_: if he's in .nz, you might need to lurk for a while...

[10:10:03.0000] <annevk>
if they were in WebApps I'm sure people in WebApps would have steered them in the right direction

[10:11:00.0000] <timeless>
annevk: yep

[10:11:01.0000] <timeless>
/me would have given more feedback

[10:11:02.0000] <arun_>
timeless, guess you're right; was kinda hoping he lingered in MV after all hands at Moz' but oh well :-\

[10:11:03.0000] <timeless>
arun_: i certainly am not in a position to *know* that

[10:12:00.0000] <timeless>
i do know that some people tend to flee .us eagerly

[10:12:01.0000] <timeless>
(roc?)

[10:12:02.0000] <timeless>
but that's for accounting (irs) reasons

[10:12:03.0000] <timeless>
/me currently has to avoid leaving ON, CA for extended periods of time

[10:16:00.0000] <jgraham>
annevk: I haven't really understood the point of the web-perf stuff yet. But it seemed like people really wanted to rush some stuff through

[10:17:00.0000] <annevk>
arun_, sicking, I think I will just go with DOMError; given that the other has exception in the name that seems the clearest, even though it is arguably somewhat redundant

[10:17:01.0000] <jgraham>
And some really useful stuff (requestAnimationFrame) got put in the same WG for no real reason

[10:17:02.0000] <annevk>
arun_, sicking, and then e.g. HTML could have MediaError : DOMError or some such

[10:18:00.0000] <annevk>
if Hixie wants to go through with all the extensions

[10:18:01.0000] <annevk>
jgraham, yeah Microsoft and Google

[10:18:02.0000] <annevk>
and of course they don't care about API simplicity or correctness

[10:18:03.0000] <annevk>
just needs to be "good enough"

[10:19:00.0000] <annevk>
never mind that everyone with smaller teams will have a hard time learning and what not

[10:19:01.0000] <arun_>
annevk, I'm in agreement.  I'm sure there's some aesthetic reason why exceptions aren't reusable as interfaces, but I don't quite understand it.  DOMError just buys into this model, and I'm ok with that.

[10:19:02.0000] <TabAtkins>
Dude, we're in the WG to try and mitigate the train wreck.

[10:20:00.0000] <timeless>
TabAtkins: well, it seems anne's not giving you high marks for your efforts :)

[10:20:01.0000] <arun_>
annevk, do we need to extend DOMError, or can we reuse it as you define it, but merely say what to use for .name?

[10:20:02.0000] <annevk>
arun_, you can use it as is

[10:20:03.0000] <annevk>
arun_, Hixie seemed to have some other needs for it that would require extending it

[10:21:00.0000] <timeless>
(to be fair, trainwrecks abound)

[10:21:01.0000] <arun_>
annevk, yeah.  Hixie was actual lukewarm / neutral about even having a DOMError, but it seems useful to me.

[10:23:00.0000] <arun_>
As a general observation, staying on top of all relevant specs is hard, and the general tendency seems to be to link to Editor's drafts, not WDs.  This suggests a diminishing usefulness of WDs, but folks still crack the process whip :)

[10:24:00.0000] <timeless>
/me read that as full of crack

[10:24:01.0000] <annevk>
I don't care much about WDs versus EDs

[10:24:02.0000] <AryehGregor>
It seems like there are slight differences between the output of http://aryeh.name/tests-root/tests/submission/AryehGregor/reflection/reflection-embedded.html and http://dvcs.w3.org/hg/html/raw-file/tip/tests/submission/AryehGregor/reflection/reflection-embedded.html.  Anyone have suggestions on how to find them?

[10:24:03.0000] <annevk>
the problem arises when stuff gets implemented before it reaches the attention of anyone with some experience in web platform API design

[10:25:00.0000] <arun_>
annevk, well, I care about being up to date.  And I'm not sure WD are up to date always (I blame myself, of course.  It's just a general preference to keep specs dynamic).

[10:25:01.0000] <annevk>
strike some, some of these issues are subtle

[10:25:02.0000] <annevk>
arun_, I'm with you there :)

[10:26:00.0000] <AryehGregor>
/me tries Save as File and diff

[10:26:01.0000] <annevk>
I don't mind much how other people go about it I mean, as long as they ensure to get some review from WHATWG / WebApps

[10:26:02.0000] <arun_>
annevk, yeah, but in particular, within WHATWG/WebApps, to pester implementers for review.

[10:27:00.0000] <timeless_>
annevk: so...

[10:27:01.0000] <timeless_>
some WGs (i18n, TAG) manage to get themselves a wildcard demand for "please ask us for review before publishing"

[10:27:02.0000] <timeless_>
would it be impossible for webapps to manage the same?

[10:27:03.0000] <timeless_>
(for a slightly more limited domain)

[10:27:04.0000] <timeless>
/me hunts lunch

[10:28:00.0000] <annevk>
we get requests I guess, but usually when drafts are in Last Call

[10:28:01.0000] <arun_>
annevk, to wrap up DOMError discussion: I'll link to DOM4 ED, and optimistically hope that DOMError will magically appear before Art beats me up for LCWD :)

[10:28:02.0000] <annevk>
which is sort of counter to the point of Last Call

[10:28:03.0000] <timeless>
annevk: yeah

[10:28:04.0000] <timeless>
they're generally presented as fait a compli

[10:28:05.0000] <timeless>
which is unhelpful

[10:29:00.0000] <annevk>
because before you go to Last Call you have to make sure you have followed advice from other groups and generally expect them not to make comments

[10:29:01.0000] <annevk>
but whatever, it's a big mess

[10:29:02.0000] <annevk>
arun_, cool, I can do it now I guess

[10:34:00.0000] <Hixie>
annevk: i love how the person who asked the question in your g+ post is the chair of a group that just forked a part of the whatwg spec

[10:34:01.0000] <Hixie>
annevk: that just fills one with confidence

[10:35:00.0000] <annevk>
I love how he's your colleague :)

[10:36:00.0000] <annevk>
arun_, how about this language:

[10:37:00.0000] <annevk>
a "SyntaxError" <code>DOMError</code> object

[10:37:01.0000] <annevk>
means a DOMError object whose name is initialized to "SyntaxError"

[10:39:00.0000] <arun_>
annevk, works for me.  Question: the assumption here is that name/code pairs can be reusable across both DOMException/DOMError.  So the "new" errors I add for FileAPI are candidates for the 'non-normative" list, and usable in both DOMError and DOMException, right?

[10:40:00.0000] <arun_>
annevk, also: Israel, IndexedDB guy, suggests that code = 0 in newly introduced errors.  Is that something I should follow, or should I pick the next available number?

[10:42:00.0000] <annevk>
if you say "throw a 'SyntaxError' exception" that will set code appropriately

[10:42:01.0000] <annevk>
it is indeed 0 for non-legacy values but there's nothing other drafts need to say about that

[10:43:00.0000] <arun_>
annevk, Aha!  So, new (non-legacy) error types are always set to 0, but we don't need to ever mention code value, right?

[10:44:00.0000] <arun_>
annevk, so should I have a table for any new error names, which you can later appropriate into DOM4?

[10:44:01.0000] <arun_>
I'm tempted to just make a radical shift and have my spec. never mention constants and their affiliated numerical values, which I think is right.

[10:46:00.0000] <Hixie>
ok i'm nuking the Web Apps 1.0 spec and making the WHATWG TML spec contain everything that was in Web Apps 1.0

[10:46:01.0000] <Hixie>
having to generate both specs every time is killing pms

[10:46:02.0000] <Hixie>
plus it' kinda confusing to have bothe anyway

[10:48:00.0000] <arun_>
Hixie, expect some lamenting ;-)

[10:48:01.0000] <Hixie>
most people won't notice, i expect

[10:49:00.0000] <annevk>
arun_, yes you don't need to mention constants

[10:49:01.0000] <annevk>
arun_, you don't even need a table

[10:49:02.0000] <annevk>
arun_, you just need "throw a ... exception" and "must return a ... DOMError"

[10:49:03.0000] <annevk>
arun_, and then for the ... that DOM4 is missing you can file a bug or email

[10:50:00.0000] <annevk>
massive simplification is what we are aiming for :)

[10:50:01.0000] <arun_>
annevk, ok.  this is so radically simple, I can't help but feel happier and lighter about the whole damn morass of errors/exceptions :)

[10:50:02.0000] <Hixie>
annevk: for the DOMError thing are there integer constants at all? (e.g. the four from MediaError?)

[10:51:00.0000] <annevk>
Hixie, no; my thinking was that you could make MediaError inherit from it or something

[10:51:01.0000] <Hixie>
k

[10:51:02.0000] <annevk>
Hixie, or maybe it is not too late to change MediaError

[10:51:03.0000] <Hixie>
just making sure there was no conflict

[10:51:04.0000] <annevk>
there's only DOMError.name atm

[10:51:05.0000] <Hixie>
i swear, 80% of the traffic to the various browser security lists i'm on is people nominating other people to join the security lists

[10:51:06.0000] <arun_>
Hixie, I'm not sure why MediaError can't follow what we're going to do in File API.  Namely use language of the sort "must return a NOT_FOUND DOMError".

[10:52:00.0000] <Hixie>
arun_: well there's only one MediaError object, to start with

[10:52:01.0000] <arun_>
Hixie, ahahah I know what you mean.

[10:52:02.0000] <Hixie>
arun_: and its value changes over time

[10:52:03.0000] <Hixie>
arun_: iirc

[10:52:04.0000] <Hixie>
i don't see much value in converging the error objects

[10:53:00.0000] <annevk>
arun_, that would become "NotFound" DOMError fyi

[10:53:01.0000] <annevk>
fwiw*

[10:53:02.0000] <annevk>
it's a string-based world

[10:53:03.0000] <arun_>
Hixie, ok.  In the case of DOMException/DOMError, it eliminates the need for FileException/FileError, but I think MediaError may need to be more nuanced.

[10:53:04.0000] <arun_>
annevk, yes.

[10:53:05.0000] <arun_>
/me slaps his own face for getting all constant-y.

[10:53:06.0000] <Hixie>
arun_: MediaError is unrelated to exceptions, unlike the situation in FileAPI

[10:54:00.0000] <Hixie>
(sorry, i misspoke. There's one MediaError per error that triggered, its value doesn't change.)

[10:54:01.0000] <Hixie>
(but you can fetch it multiple times.)

[10:55:00.0000] <annevk>
arun_, http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-domerror

[10:56:00.0000] <arun_>
annevk, I am happy enough with it :)

[11:04:00.0000] <annevk>
Hixie, I fully support the merge btw

[11:04:01.0000] <annevk>
Hixie, though it'll require some updating to the FAQ et al

[11:04:02.0000] <Hixie>
yeah

[11:05:00.0000] <Hixie>
btw that means i'm no longer using philip`'s splitter, only yours

[11:06:00.0000] <Philip`>
Oh, so I can retire mine?

[11:06:01.0000] <Hixie>
yeah

[11:06:02.0000] <Hixie>
thanks for your service :-)

[11:07:00.0000] <Philip`>
/me will probably drop it when moving his server to a new machine, then

[11:09:00.0000] <timeless>
Hixie: how often do you see people dropping off security lists? :)

[11:09:01.0000] <Hixie>
i don't follow the lists closely enough to tell you

[11:09:02.0000] <Hixie>
i only follow the lists so that i can update the specs when the bugs found are intrinsic to hte platform

[11:10:00.0000] <annevk>
oh sweet, only the unmaintained splitter teehee

[11:10:01.0000] <annevk>
I wonder if it's in version control somewhere so I can still blame Philip`

[11:15:00.0000] <Philip`>
(The version in Google Code html5 is the exact one I was running, I think)

[11:17:00.0000] <annevk>
I was sort of planning on following this Apple event and then they post all the details ahead of time on the Japanese site

[11:17:01.0000] <annevk>
boring

[11:20:00.0000] <timeless>
heh

[11:21:00.0000] <timeless>
does someone post a translation of that?

[11:29:00.0000] <annevk>
yeah macrumors & co

[11:39:00.0000] <timeless>
oh right

[12:06:00.0000] <roc>
timeless: ?

[12:17:00.0000] <zcorpan>
Hixie: wait, you banned <h1> in <td>?

[12:18:00.0000] <Hixie>
not intentionally

[12:18:01.0000] <Hixie>
did i?

[12:18:02.0000] <Hixie>
no

[12:36:00.0000] <aho>
is there something like an aspect ratio css property planned? i.e. something that would allow you to crate a div which resizes like an image (you set the width and the height gets calculated)

[12:37:00.0000] <TabAtkins>
I've got a post on my blog with a proposal.  I'll work on it when fantasai and I (or maybe Anton) starts work on the Box Module.

[12:37:01.0000] <aho>
woo! :)

[12:39:00.0000] <aho>
something like that might be interesting for that "responsive image" stuff. the easiest way to get something like that is via inline svg, but that's all kinds of awkward :>

[12:47:00.0000] <annevk>
Hixie, the multipage copy still says Web Applications 1.0

[12:49:00.0000] <annevk>
Hixie, also whatwg.org/C used to be multipage; whatwg.org/c is single-page

[12:55:00.0000] <timeless>
hsivonen: grrr, why aren't you on #foxymonkies? :)

[13:02:00.0000] <Hixie>
annevk: the multipage copy saying Web Applications 1.0 is an issue on your side, i think

[13:03:00.0000] <Hixie>
annevk: the shortcuts should still work, did i break them?

[13:03:01.0000] <annevk>
it seems you reversed c and C?

[13:03:02.0000] <annevk>
uppercase was for multipage

[13:03:03.0000] <annevk>
lowercase for singlepage

[13:04:00.0000] <annevk>
i'll take a look at the script on html5.org

[13:04:01.0000] <Hixie>
where are they reversed?

[13:04:02.0000] <Hixie>
or do you mean they resolve reversed?

[13:05:00.0000] <Hixie>
oh i see, the link on the header is wrong

[13:05:01.0000] <Hixie>
got it

[13:05:02.0000] <annevk>
html5.org uses complete.html

[13:05:03.0000] <annevk>
is that wrong?

[13:05:04.0000] <Hixie>
oh oops hold on

[13:07:00.0000] <Hixie>
ok that should fix itself next time i regen

[13:07:01.0000] <Hixie>
thanks

[13:07:02.0000] <Hixie>
(i forgot to update complete.html)

[13:07:03.0000] <Hixie>
(i need to update it for svn too)

[13:07:04.0000] <annevk>
okay

[13:07:05.0000] <Hixie>
although, wait

[13:07:06.0000] <Hixie>
complete.html has been 301ing to index today

[13:08:00.0000] <Hixie>
shouldn't that fix it on your end?

[13:08:01.0000] <annevk>
so web-apps-tracker already uses index

[13:08:02.0000] <annevk>
Hixie, oh, I use svn

[13:08:03.0000] <Hixie>
ah ok

[13:09:00.0000] <Hixie>
well it'll get fixed when i next check in

[13:09:01.0000] <annevk>
svn update, then generate, etc.

[13:09:02.0000] <annevk>
k

[13:09:03.0000] <Hixie>
which is now

[13:09:04.0000] <Hixie>
so we'll see what happens

[13:09:05.0000] <Hixie>
interesting though. that means i have to do the svn checkin to get the multipage updated :-)

[13:09:06.0000] <Hixie>
didn't know that

[13:09:07.0000] <Hixie>
good to know

[13:10:00.0000] <annevk>
it'll generate a copy regardless, but it will generate it from complete.html as things stand

[13:10:01.0000] <annevk>
so yeah, if you want something new :)

[13:10:02.0000] <Hixie>
right

[13:10:03.0000] <Hixie>
that's fine

[13:13:00.0000] <annevk>
hsivonen, apple.com is giving access denied for me too

[13:13:01.0000] <annevk>
hsivonen, earlier it had some stuff on the iPhone 4S

[13:13:02.0000] <annevk>
I wonder if I should get one to do away with my camera

[13:13:03.0000] <annevk>
pretty expensive camera upgrade though

[13:13:04.0000] <annevk>
for a P&S

[13:15:00.0000] <annevk>
Hixie, but you can just drop the crossorigin attribute and get the image

[13:15:01.0000] <annevk>
oh well

[13:15:02.0000] <Hixie>
the server can return nothing at all for that case

[13:21:00.0000] <annevk>
Hixie, re multipage; success!

[13:21:01.0000] <Hixie>
yay

[13:33:00.0000] <FlorianX>
HTML and WebApplications 1.0 are now the same specifications, ist that right?

[13:37:00.0000] <annevk>
yes

[13:38:00.0000] <FlorianX>
annevk: may I ask why? (I am writing my master thesis about HTML5)

[13:38:01.0000] <annevk>
simplicity mainly

[13:38:02.0000] <FlorianX>
Is there an official announcement yet (because of one referral source)?

[13:38:03.0000] <annevk>
from a WHATWG perspective the split made little sense

[13:39:00.0000] <annevk>
there's http://twitter.com/WHATWG/status/121268735381221376

[13:39:01.0000] <annevk>
maybe I'll mention it in the WHATWG Weekly, not sure whether it's worth it

[13:39:02.0000] <FlorianX>
so the webapps 1.0 is now HTML or reverse?

[13:40:00.0000] <annevk>
what was called Web Applications 1.0 is now called HTML

[13:40:01.0000] <Hixie>
they're the same

[13:40:02.0000] <annevk>
HTML used to be a subset of that; the subset no longer exists

[13:40:03.0000] <FlorianX>
ok thats what i mean

[13:40:04.0000] <FlorianX>
thanks for help

[13:41:00.0000] <FlorianX>
But then what I write now in my thesis :-)

[13:41:01.0000] <Hixie>
what was called Web Apps 1.0 originally, many years ago, was at one point renamed HTML, then things were dropped from it to track the w3c, eventually they dropped so much that we added a separate spec at the whatwg to include everything again, and called it Web Apps 1.0 for nostalgic reasons

[13:42:00.0000] <Hixie>
and today i got tired of having two specs at whatwg (it makes various things annoying and some of our tools are overloaded by it) and so i just went back to the state after the first time we renamed the spec

[13:42:01.0000] <Hixie>
i think

[13:42:02.0000] <Hixie>
you'd have to check the svn archive to see how accurate that is

[13:43:00.0000] <annevk>
sounds about right

[13:45:00.0000] <FlorianX>
my thesis is half finished, in that I always refer to the two specifications. Now I have quite the problem that I need to rewrite everything. But so does the living.

[13:47:00.0000] <FlorianX>
thanks again for the explanations @ Hixie + annevk

[13:47:01.0000] <Hixie>
heh

[13:47:02.0000] <Hixie>
sorry man :-)

[13:48:00.0000] <FlorianX>
I just bribe my professor :-D

[14:13:00.0000] <rniwa>
AryehGregor: yt?

[14:13:01.0000] <AryehGregor>
rniwa, I'm just leaving, actually.

[14:13:02.0000] <rniwa>
AryehGregor: ah ok

[14:13:03.0000] <rniwa>
AryehGregor: did you my msg a couple of days about selectstart?

[14:13:04.0000] <AryehGregor>
rniwa, yeah.  I have a bug open: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13952

[14:13:05.0000] <rniwa>
AryehGregor: great

[14:14:00.0000] <rniwa>
AryehGregor: also, you may want to investigate interaction between selection & focus

[14:14:01.0000] <AryehGregor>
rniwa, could you file a bug with details?

[14:14:02.0000] <rniwa>
AryehGregor: right now WebKit's focus follows selection

[14:14:03.0000] <rniwa>
AryehGregor: whereas IE & FF's selection follows focus

[14:15:00.0000] <rniwa>
AryehGregor: will do

[14:15:01.0000] <smaug____>
selection follows focus?

[14:16:00.0000] <rniwa>
smaug____: when selection is set on some node

[14:16:01.0000] <rniwa>
smaug____: webkit automatically focuses its editing host

[14:16:02.0000] <rniwa>
smaug____: whereas in IE & FF, selection is automatically moved to wherever focus is

[14:16:03.0000] <smaug____>
webkit automatically focuses?

[14:16:04.0000] <smaug____>
that is surprising

[14:17:00.0000] <rniwa>
smaug____: someone told me this behavior might be some Mac-ism

[14:17:01.0000] <smaug____>
but I'm not sure I understand "selection is automatically moved to wherever focus"

[14:17:02.0000] <rniwa>
smaug____: yes, it has caused some compat issues for us but we haven't been able to change it

[14:17:03.0000] <smaug____>
ah, I'm very much not aware of Mac-isms

[14:17:04.0000] <rniwa>
smaug____: when a focus is set on some contenteditable region

[14:17:05.0000] <rniwa>
smaug____: and user starts pressing keys

[14:18:00.0000] <rniwa>
smaug____: IE & FF automatically moves the selection there

[14:18:01.0000] <rniwa>
smaug____: e.g. <div id="has_focus"><br></div><div id="has_selection"><br></div>

[14:18:02.0000] <smaug____>
rniwa: but webkit doesn't?

[14:18:03.0000] <rniwa>
smaug____: webkit inserts a letter in #has_selection whereas IE&FF inserts it in #has_focus

[14:22:00.0000] <rniwa>
AryehGregor: filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=14383

[15:31:00.0000] <hober>
AryehGregor: the formatting of http://dvcs.w3.org/hg/editing/raw-file/tip/source.html is all messed up

[15:41:00.0000] <annevk>
hmm

[15:41:01.0000] <annevk>
guess I have to look into XHR garbage collection yet again

[15:41:02.0000] <annevk>
joy joy joy


2011-10-05
[17:35:00.0000] <hdtdi>
hi. i have a question. if i have a website and on this website i have 5 short articles on under another wrapped in a div. is it appropriate to change the div with <section> </section> and in between to wrap every article with <article>text</article> i mean is this the purpose of this tags?

[20:50:00.0000] <franksalim>
I was hoping to find mark pilgrim

[20:50:01.0000] <paul_irish>
afk, as it were. :/

[20:50:02.0000] <franksalim>
paul_irish: away from internet

[20:53:00.0000] <karlcow>
franksalim: mark is 410

[20:55:00.0000] <karlcow>
http://reinout.vanrees.org/weblog/2011/10/04/github.html

[20:55:01.0000] <karlcow>
wrong chan

[21:07:00.0000] <jacobolus>
very surprising considering how damn useful mark's sites have been as educational resources

[21:07:01.0000] <jacobolus>
no one has any clue if he's okay?

[21:30:00.0000] <karlcow>
jacobolus: everything is gone so far https://twitter.com/diveintomark his twitter account, his domain names

[21:30:01.0000] <jacobolus>
karlcow: yes, all the domains 410

[21:31:00.0000] <jacobolus>
which is worrying, to say the least :/

[21:33:00.0000] <danbeam__>
/me should make his website give a HTTP/1.1 418

[21:33:01.0000] <jacobolus>
http://tools.ietf.org/html/rfc2616#section-10.4.11

[21:33:02.0000] <danbeam__>
make that HTCPCP/1.0

[21:35:00.0000] <danbeam__>
jacobolus: http://tools.ietf.org/html/rfc2324#section-2.3.2

[21:35:01.0000] <jacobolus>
yeah, I know the coffee-pot protocol :)

[21:35:02.0000] <shepazu>
he lives near me, but I don't know him well… only met him once, at a conference

[21:35:03.0000] <danbeam__>
jacobolus: yay

[21:36:00.0000] <shepazu>
wish I could contact him, but it seems unlikely he wants to be contacted

[21:36:01.0000] <karlcow>
shepazu: yup

[21:37:00.0000] <jacobolus>
I'm sure that people who know him will be trying to contact him. It would be very reassuring to hear some kind of news that it’s only his web presence that’s in trouble though.

[21:39:00.0000] <shepazu>
hopefully, yeah

[21:52:00.0000] <roc>
unless he has a very advanced deadman switch, presumably he's alive and in possession of his faculties

[22:03:00.0000] <paul_irish>
gsnedders: i want to document the ports (alive and dead) of html5lib on the google code project. can you add me so i can start a wiki page for it?

[22:22:00.0000] <Hixie>
sounds like mark is ok, fwiw

[22:31:00.0000] <MikeSmith>
Hixie: that's good to hear

[23:18:00.0000] <hsivonen>
not cool to make other people worry like that

[23:29:00.0000] <shepazu>
thanks, Hixie, good to know

[23:30:00.0000] <shepazu>
shame about his Web content though, especially Dive Into HTML5

[23:30:01.0000] <jacobolus>
franksalim points out that the doctype is html 2.0; are there any other web pages in existence with an html 2 doctype?

[23:30:02.0000] <jacobolus>
i.e. the doctype on the 410'd domain roots

[23:30:03.0000] <shepazu>
jacobolus: probably not, but I suspect this will start a new trend

[23:31:00.0000] <jacobolus>
also, writing <br /> is invalid in html 2, right?

[23:31:01.0000] <shepazu>
HTML5 is soooooooo 2011… HTML 2.0 will be the pixel graphics revival of markup

[23:31:02.0000] <Hixie>
HTML5 is soooooo 2009 :-P

[23:32:00.0000] <shepazu>
2009 is soooooo 2006!

[23:34:00.0000] <hsivonen>
jacobolus: IIRC, Apache uses an HTML 2.0 doctype for various error pages

[23:35:00.0000] <hsivonen>
shepazu: Dive into HTML5 is available at http://diveintohtml5.info/

[23:36:00.0000] <shepazu>
hsivonen: yeah, thanks… I guess it means that Mark won't be updating it, though

[23:36:01.0000] <hsivonen>
shepazu: maybe it's now like a paper book in that sense

[23:37:00.0000] <shepazu>
hsivonen: I've heard of those

[23:37:01.0000] <shepazu>
not saying it's not a great resource still… I just like the notion that there was this excellent reference that a smart guy was maintaining and keeping up-to-date

[23:38:00.0000] <hsivonen>
yeah :-(

[23:43:00.0000] <MikeSmith>
hsivonen: http://bugzilla.validator.nu/show_bug.cgi?id=860 is odd

[23:43:01.0000] <hsivonen>
so we went through all the effort to make the HTML parser not reparse on syntax failures and now Opera has made their XML code path reparse as HTML upon syntax failure

[23:44:00.0000] <Hixie>
imho opera's behaviour there is non-conforming and shouldn't be encouraged

[23:46:00.0000] <hsivonen>
If we're giving up on Draconian behavior, I think browsers should implement non-reparsing XML5 instead

[23:46:01.0000] <Hixie>
i'm not convinced we're ever going to give up draconian behaviour. frankly i'm not convinced there's a need anymore.

[23:46:02.0000] <hsivonen>
btw, what does Opera do in order to still pass Acid3?

[23:47:00.0000] <hsivonen>
are the Acid3 XML tests in XHR?

[23:47:01.0000] <Hixie>
(xml has been reduced to the equivalent of json, and json doesn't do error-recovery either)

[23:47:02.0000] <Hixie>
they've asked if we can change acid3

[23:47:03.0000] <Hixie>
so they might have a hack for now

[23:47:04.0000] <Hixie>
or they might fail it

[23:47:05.0000] <hsivonen>
Hixie: if you call them equilavent, the next thing we know is people asking for automatic mapping between JSON and XML

[23:47:06.0000] <Hixie>
equivalent in purpose, not data model

[00:55:00.0000] <jacobolus>
ugh, JSON libraries' not forgivingly parsing things is awful

[01:01:00.0000] <hsivonen>
my attempt to integrate with the JSON API of Delicious was stopped by the supposed JSON output from Delicions escaping ' as \'

[01:01:01.0000] <hsivonen>
Yes, I did report the bug to Delicious. No, it was not fixed in a timely manner

[01:06:00.0000] <Hixie>
JSON doesn't support JS escapes?

[01:08:00.0000] <annevk>
doesn't support single quotes or comments

[01:08:01.0000] <annevk>
it's a sad format

[01:09:00.0000] <annevk>
widely adopted though

[01:09:01.0000] <zcorpan>
FlorianX: you can just write an addendum to your thesis saying that the specs have now been merged

[01:09:02.0000] <annevk>
the problem with XML for us is that sites are broken and give everyone text/html and Opera application/xml or some such with broken content

[01:09:03.0000] <annevk>
now maybe the majority case of XML usage is not web-facing, but we certainly get our share and it blows

[01:10:00.0000] <annevk>
e.g. Gmail mobile did not work for three weeks in Opera at one point because of this

[01:10:01.0000] <Hixie>
it would help if opera had more market share, people would test for it more :-/

[01:28:00.0000] <zcorpan>
Hixie: http://www.whatwg.org/issues/ doesn't seem to work

[01:31:00.0000] <hsivonen>
why do the phone images at http://www.apple.com/iphone/ lack alpha in Gecko? is Apple using some -webkit-CSS instead of PNG alpha?

[01:33:00.0000] <hsivonen>
looks like they use JPEG for RGB and -webkit- stuff for alpha

[01:34:00.0000] <hsivonen>
I'm a bit surprised that Apple prefers ugliness in non-WebKit browsers over worse image compression

[01:45:00.0000] <annevk>
karlcow, what's wrong with corp.invalid and why did you add a slash?

[01:53:00.0000] <MikeSmith>
annevk: http://krijnhoetmer.nl/irc-logs/whatwg/20111005#l-158

[01:53:01.0000] <MikeSmith>
[06:11] <paul_irish> gsnedders: i want to document the ports (alive and dead) of html5lib on the google code project. can you add me so i can start a wiki page for it?

[01:54:00.0000] <annevk>
https://github.com/diveintomark

[01:54:01.0000] <annevk>
seems still alive

[01:54:02.0000] <MikeSmith>
annevk: I think that's a copy that some third-party set up

[01:55:00.0000] <annevk>
I added paul_irish to html5lib

[01:56:00.0000] <annevk>
MikeSmith, I see

[01:56:01.0000] <annevk>
all the blog posts gone

[01:56:02.0000] <annevk>
I wonder how much Google Reader has

[01:57:00.0000] <annevk>
man back in the days I used to read those quite a bit :(

[02:13:00.0000] <foolip>
so <video> is under the-iframe-element.html#the-video-element again after (zcorpan says) complete and web-apps were merged

[02:13:01.0000] <foolip>
is a different section splitter used?

[02:13:02.0000] <annevk>
it uses the complete splitter

[02:14:00.0000] <annevk>
do you still have access to html5.org foolip?

[02:15:00.0000] <jgraham>
Hixie: Having sites fail in Opera that work in other browsers due to incorrect labelling as XML is hardly helpful to that goal

[02:15:01.0000] <foolip>
annevk, I should

[02:16:00.0000] <jgraham>
(it's also not really clear it's non-conforming. It violates the *spirit* of the XML spec but not really the letter)

[02:17:00.0000] <jgraham>
(FWIW I would also prefer that we implemenetd XML5, but that would be a much bigger change and also cause us to fail ACID3)

[02:17:01.0000] <jgraham>
+that test in

[02:18:00.0000] <annevk>
it violates HTTP and HTML, not XML

[02:19:00.0000] <jgraham>
Well that part of HTTP is violated everywhere so I won't really cry about that

[02:20:00.0000] <annevk>
me neither, just explaining the Acid3 argument

[02:20:01.0000] <jgraham>
Fair enough

[02:31:00.0000] <annevk>
/me wonders if someone here can explain http://golem.ph.utexas.edu/~distler/blog/archives/002444.html in layman's terms

[02:39:00.0000] <Philip`>
annevk: It sounds like: If the neutrinos were travelling faster than the speed of light, they would lose energy along the way (due to some weird complex physicsy thing which is presumably believed to be true), but the measured energy doesn't show that loss, so the explanation for the measurements must be something different to simply travelling faster than light

[02:40:00.0000] <Philip`>
The rest of it's just numbers and equations

[02:42:00.0000] <MikeSmith>
Bremsstrahlung is a nice word

[02:42:01.0000] <jgraham>
That seems to basically be it, yes

[02:42:02.0000] <annevk>
thanks!

[02:43:00.0000] <annevk>
I wonder why I did not read about that anywhere else yet

[02:43:01.0000] <jgraham>
Although it doesn't seem that convincing to say "if neutrinos did (physically impossible thing) physics predicts they would also do (some other thing) so obviously they can't have done (impossible thing)"

[02:43:02.0000] <Philip`>
It's not nearly sensationalistic enough

[02:47:00.0000] <Philip`>
I guess the idea is to show that if one law of physics is broken in one particular case, then it can't just be fudged into the current model and instead the whole of the rest of physics will collapse around it, therefore physicists really really hope the law wasn't broken

[02:54:00.0000] <annevk>
Can you export from Google Reader?

[03:05:00.0000] <foolip>
MikeSmith, are you using spec-splitter.py from http://code.google.com/p/html5/ at the W3C, or can I remove the --w3c mode that only manages to print a double <!doctype> anyway?

[03:07:00.0000] <Philip`>
I thought it also made it not use HTML5, to satisfy W3C rules

[03:07:01.0000] <MikeSmith>
foolip: I think it does some other things as well

[03:07:02.0000] <foolip>
MikeSmith, ok, but are you using it?

[03:07:03.0000] <MikeSmith>
nope

[03:07:04.0000] <MikeSmith>
so feel free to remove it

[03:07:05.0000] <Philip`>
(The doctype thing seems to vary depending on exactly which libxml2 version you've got)

[03:08:00.0000] <MikeSmith>
I think I'm not even using the --w3c switch in the copy I run from

[03:11:00.0000] <foolip>
Philip`, oh, I guess I'll have to detect and handle it then

[03:12:00.0000] <foolip>
MikeSmith, in case you're not following the upstream changes I won't worry about breaking it

[03:13:00.0000] <foolip>
Philip`, do you know which libxml2 versions *don't* print a doctype?

[03:13:01.0000] <foolip>
is it just a question of old vs new?

[03:14:00.0000] <MikeSmith>
foolip: I'll probably just port over you upstream changes once you have them done

[03:14:01.0000] <foolip>
ok then

[03:15:00.0000] <MikeSmith>
anybody know a good algorithm for sorting dotted-decimal numbers?

[03:15:01.0000] <MikeSmith>
e.g.,. "4.10.7.2.8"

[03:16:00.0000] <foolip>
with a comparator that splits on period and then compares fields until one is not equal or there are not more fields?

[03:17:00.0000] <FlorianX>
will someone reorganize the whatwg-site? because html ist now webapps 1.0 ?

[03:17:01.0000] <Philip`>
foolip: Per http://krijnhoetmer.nl/irc-logs/whatwg/20110207#l-237 and subsequent lines, it sounds like 2.2.8 generated double doctypes, and some unknown earlier version didn't

[03:18:00.0000] <Philip`>
(Oh, this is lxml not libxml2)

[03:18:01.0000] <annevk>
FlorianX, Hixie has to do that

[03:18:02.0000] <FlorianX>
annevk ok

[03:18:03.0000] <annevk>
FlorianX, if you have a list of places the site is wrong sending an email could help

[03:19:00.0000] <foolip>
lxml is also based on libxml2

[03:19:01.0000] <foolip>
as is etree

[03:19:02.0000] <foolip>
so it sounds like recent libxml2 simply emit a doctype, so we don't have to ourselves

[03:19:03.0000] <Philip`>
Yeah, but different version numbers

[03:19:04.0000] <Philip`>
so it's lxml version 2.2.8+ that matters

[03:19:05.0000] <Philip`>
(probably)

[03:20:00.0000] <foolip>
well I'm getting double doctype in the etree code path now

[03:20:01.0000] <FlorianX>
annevk: I aim to the landigpage :-)

[03:20:02.0000] <Philip`>
Maybe the old ones just dropped the HTML5 doctype since it looked weird

[03:20:03.0000] <Philip`>
then they changed it later

[03:20:04.0000] <annevk>
FlorianX, ah yeah, best to just ping him when he's around

[03:20:05.0000] <annevk>
FlorianX, is your thesis going to be published btw?

[03:20:06.0000] <annevk>
/me is kind of curious

[03:21:00.0000] <FlorianX>
annevk: You say yesterday that you might want to write a blog post? Is that still the case? When can I expect with this (in order to source)?

[03:22:00.0000] <FlorianX>
annevk: i think so :-)

[03:23:00.0000] <FlorianX>
it's an overview of html(5) and some prototypical implementations

[03:24:00.0000] <annevk>
FlorianX, hopefully later today, it will likely be a footnote

[03:24:01.0000] <annevk>
/me is updating the FAQ on the wiki

[03:25:00.0000] <FlorianX>
annevk: thanks; I expect a tweet later:-D

[03:27:00.0000] <annevk>
seems Hixie updated the FAQ already

[03:55:00.0000] <annevk>
might become more than a footnote

[03:55:01.0000] <annevk>
there's not much other news :)

[03:56:00.0000] <hsivonen>
/me assumes that OPERA in Jacques Distler's post has nothing to do with Opera

[03:56:01.0000] <annevk>
correct

[03:56:02.0000] <annevk>
they're the group that found the "faster-than-light neutrino"

[03:59:00.0000] <zcorpan>
annevk: you should write a blog post saying "HTML is dead, long live HTML!"

[04:00:00.0000] <jgraham>
Well OPERA is the name of the experiment and I don't think they believe they found a faster-than-light neutrino

[04:01:00.0000] <annevk>
zcorpan, I went with "HTML is the new HTML"

[04:02:00.0000] <annevk>
jgraham, I don't think it's the name of the experiment

[04:04:00.0000] <jgraham>
annevk: http://operaweb.lngs.infn.it/spip.php?rubrique1

[04:05:00.0000] <Philip`>
"the most straightforward test of the phenomenon of neutrino oscillations" - seems to have turned out less straightforward than they hoped

[04:06:00.0000] <annevk>
it sounds like it's a construct as well

[04:06:01.0000] <annevk>
oh well

[04:09:00.0000] <Philip`>
/me is reminded of the person who first discovered a signal that turned out to be a pulsar, when they didn't know what it was and thought (half seriously) it could be communication by aliens, commenting that she was quite irritated with those aliens for happening to pick her radio frequency and her part of the sky and messing up her nice straightforward survey that she was going to do her PhD about

[04:55:00.0000] <karlcow>
annevk: you can remove the slash, oversight from me. Imagine that corp.invalid becomes a real domain name. example.org|net|com are reserved for examples in specs

[04:56:00.0000] <annevk>
.invalid is reserved

[04:56:01.0000] <annevk>
that's why I used it

[05:00:00.0000] <karlcow>
oooooh my bad then. Gomenasai

[05:00:01.0000] <karlcow>
http://en.wikipedia.org/wiki/Top-level_domain#Reserved_domains

[05:04:00.0000] <annevk>
http://blog.whatwg.org/weekly-simple-dom

[05:04:01.0000] <annevk>
oh, Florian just left!

[05:22:00.0000] <zcorpan>
annevk: so is there a reason the event handlers can't just be mixed with the attributes?

[05:22:01.0000] <annevk>
they'll prolly merge

[05:23:00.0000] <zcorpan>
['div', {onclick:func, class:'foo'}, 'hello']

[05:24:00.0000] <zcorpan>
i guess one problem with this is that svg and mathml are not supported

[05:24:01.0000] <jgraham>
zcorpan: It makes a bit of a confusing model if the type affects how the  property is set

[05:24:02.0000] <annevk>
we can just check the property

[05:24:03.0000] <jgraham>
Because ut should set attributes not properties in other cases

[05:25:00.0000] <annevk>
starts with "on", please go over there...

[05:25:01.0000] <zcorpan>
jgraham: i was thinking of looking at the attribute name, not the value type

[05:25:02.0000] <annevk>
http://html5.org/specs/dom-range.html

[05:25:03.0000] <jgraham>
Great, as only as there are no attributes called "only" or similar

[05:26:00.0000] <jgraham>
Which seems like a scary thing to assume

[05:26:01.0000] <zcorpan>
i was thinking of using the list of supported event handles

[05:27:00.0000] <annevk>
jgraham, seems like a silly attribute to introduce

[05:27:01.0000] <annevk>
zcorpan, yeah, you would have to do that anyway

[05:27:02.0000] <zcorpan>
so what do we do with svg and mathml?

[05:28:00.0000] <jgraham>
annevk: Magic prefix matching with no clear prefix delimiter seems bad compared to haven hidden rules about the avaliable namespace for new attributes

[05:29:00.0000] <jgraham>
Umm, that made no sense

[05:29:01.0000] <jgraham>
seems bad *because* it introduces hidden rules

[05:29:02.0000] <annevk>
zcorpan, "svg:svg" and "math:mtext" or some such

[05:30:00.0000] <annevk>
there are hidden rules in attribute naming already

[05:30:01.0000] <jgraham>
Such as?

[05:30:02.0000] <annevk>
cannot start a non-event handler with on

[05:30:03.0000] <jgraham>
Why not?

[05:31:00.0000] <zcorpan>
annevk: is the verbosity for svg acceptable to svg people?

[05:31:01.0000] <annevk>
verbosity?

[05:31:02.0000] <annevk>
come on

[05:33:00.0000] <zcorpan>
it's more verbose compared to html

[05:33:01.0000] <zcorpan>
but maybe it's ok

[05:34:00.0000] <zcorpan>
would it create elements with prefixes or without?

[05:34:01.0000] <Philip`>
Adding a scoping attribute, like [{'ns': 'svg'}, 'svg', ['circle', ...], ...]

[05:35:00.0000] <jgraham>
/me wonders if that is a serious suggestion

[05:35:01.0000] <jgraham>
Sometimes it is hard to tell :)

[05:36:00.0000] <Philip`>
It's better than ['svg', {'xmlns':'http://www.w3.org/2000/svg'}, ['circle', ...], ...] at least :-p

[05:36:01.0000] <Philip`>
(which was going to be my initial suggestion)

[05:37:00.0000] <zcorpan>
'svg:svg' seems better, especially if you're going to mix html and svg

[05:38:00.0000] <FlorianX1>
annevk THANKs!

[06:06:00.0000] <FlorianX1>
annevk: again to the master thesis, this is unfortunately in German

[06:09:00.0000] <annevk>
google translate :)

[06:14:00.0000] <FlorianX1>
annevk: ok nice i'll let you know if its finished

[06:15:00.0000] <hsivonen>
what did navigator.taintEnabled() actually mean?

[06:18:00.0000] <hsivonen>
hmm. it was an experimental thing in Netscape 3 and has always returned false since Netscape 4

[06:39:00.0000] <karlcow>
http://intertwingly.net/blog/2011/10/03/No-more-XML-parsing-failed-errors

[08:18:00.0000] <foolip>
yay, <video> is back on the-video-element.html

[08:18:01.0000] <hsivonen>
hmm. I'm seeing no server response to my subscribe email to public-html-data-tf-request

[08:35:00.0000] <foolip>
hsivonen, do you think it's worthwhile taking part in the TF?

[08:40:00.0000] <hsivonen>
foolip: not sure yet. I think it's worthwhile to try

[08:43:00.0000] <foolip>
hsivonen, maybe I'll join then

[08:59:00.0000] <manu`>
hsivonen, foolip - I'd certainly hope you guys would take part in the html-data TF - there isn't much representation from the Microdata camp and thus, the discussion is probably going to be skewed as a result (no matter how hard the participants try to be even-handed)

[09:00:00.0000] <foolip>
Hixie, are you in it?

[09:01:00.0000] <FlorianX1>
could someone explain me why the Geolocation APi is a "candidate recommendation" since 2010?

[09:02:00.0000] <FlorianX1>
what is happening there?

[09:02:01.0000] <manu`>
Also, does anyone know why Mark Pilgrim 410'd his identity yesterday (and people did check on him and he's fine, btw)

[09:34:00.0000] <karlcow>
FlorianX1: http://www.w3.org/2008/geolocation/drafts/API/Implementation-Report.html indeed the implementation report doesn't seem to be that bad

[09:36:00.0000] <FlorianX1>
karlcow: yeah

[09:36:01.0000] <karlcow>
maybe it is because the v2 is being worked on http://www.w3.org/2011/09/07-geolocation-minutes.html

[09:38:00.0000] <karlcow>
FlorianX1: http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0048.html

[09:38:01.0000] <karlcow>
Our normative reference to WebIDL has prevented us from moving past CR

[09:38:02.0000] <karlcow>
until WebIDL reaches Last Call. WebIDL is now expected to go to LC on

[09:38:03.0000] <karlcow>
June 30th, and we decided to keep the reference to that spec instead of

[09:38:04.0000] <karlcow>
copying the relevant IDL definitions into the Geolocation spec.

[09:39:00.0000] <karlcow>
http://www.w3.org/TR/WebIDL/

[09:39:01.0000] <karlcow>
W3C Working Draft 27 September 2011

[09:39:02.0000] <zewt>
... do they really think that's a reasonable alternative? heh

[09:39:03.0000] <zewt>
"fork the unfinished spec that you depend on and call it finished"

[09:41:00.0000] <karlcow>
http://lists.w3.org/Archives/Public/public-script-coord/2011JulSep/0467.html

[09:41:01.0000] <karlcow>
RfC: Last Call Working Draft of Web IDL; deadline October 18

[09:43:00.0000] <zewt>
"last call" hardly seems to mean "finished" these days; just "reasonable snapshot point" or something like that

[09:44:00.0000] <FlorianX1>
karlcow: thanks for help! so webidl is the blocker

[09:44:01.0000] <karlcow>
my pleasure. But you should thank the w3c list search engine implemented by Olivier Thereaux in the past ;)

[09:45:00.0000] <FlorianX1>
:D

[10:04:00.0000] <JonathanNeal>
benschwarz: how much of your theme at http://developers.whatwg.org/ is open?

[11:20:00.0000] <jacobolus>
http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0020.html looks an awful lot like s-exps

[11:21:00.0000] <jacobolus>
I like the idea though. I should make such a thing for working with Photoshop's horrific ActionDescriptor APIs

[11:24:00.0000] <jacobolus>
[horrific like here's the code photoshop's "script recorder" generates http://pastie.textmate.org/2644891 ]

[11:24:01.0000] <jacobolus>
[for using the curves tool once]

[11:26:00.0000] <zewt>
could be a little cleaner with some API shortcuts, but not that bad as generated code goes

[11:28:00.0000] <jacobolus>
it includes 16 identical copies of the line `var idPnt = charIDToTypeID( "Pnt " );`

[11:29:00.0000] <jacobolus>
but even cleaning up the mess made by the code generation, the API is a pretty nasty way to serialize a hierarchical object structure

[11:29:01.0000] <jgraham>
jacobolus: Well yes it is a lot like s-exps

[11:30:00.0000] <jgraham>
Turns out that lisp had some good ideas

[11:30:01.0000] <jacobolus>
jgraham: :)

[11:30:02.0000] <jgraham>
Don't tell TabAtkins though, he will never stop going on about it :p

[11:38:00.0000] <zewt>
it's a pretty straightforward recursive dump--when I think of ugly generated code I think of flex, heh

[12:01:00.0000] <Hixie>
zcorpan: sweet! (your data e-mail)

[12:05:00.0000] <Jockel>
hi

[12:06:00.0000] <Jockel>
is the feature of "channel messaging" new within html5?

[12:06:01.0000] <Hixie>
new relative to what?

[12:07:00.0000] <Hixie>
MessagePort was added in July 2008, I think.

[12:07:01.0000] <Hixie>
so, three years?

[12:07:02.0000] <Hixie>
kinda new

[12:07:03.0000] <zcorpan>
Hixie: thanks

[12:09:00.0000] <Jockel>
Hi Hixie, I guessed you will answering... ;-) saw some work from you in the web

[12:10:00.0000] <Jockel>
is there anybody, who tried to "modelcheck" the message passing communication?

[12:10:01.0000] <Hixie>
"modelcheck"?

[12:10:02.0000] <Jockel>
;-)

[12:11:00.0000] <Jockel>
yes, i guessed noone know "model checking" here

[12:11:01.0000] <Hixie>
we might know it under a different name :-)

[12:11:02.0000] <Jockel>
it is used in several formal lessons of computer science and was applied in critical system design

[12:12:00.0000] <Jockel>
space science at NASA :)

[12:12:01.0000] <Hixie>
yes but what is it? what does it tell us and how do we do it?

[12:12:02.0000] <Jockel>
Hixie: http://spinroot.com/gerard/

[12:13:00.0000] <Jockel>
this is one of the famous "model checker"

[12:13:01.0000] <Jockel>
model checker can check if there is a deadlock within the communication and everythig stands still

[12:13:02.0000] <Jockel>
for example

[12:14:00.0000] <Jockel>
model checker checks before something is going into runtime....

[12:14:01.0000] <Jockel>
so, for html5.....

[12:15:00.0000] <Jockel>
before somebody visits a website, a model checker would check the html5 for "communication errors"

[12:15:01.0000] <Jockel>
I do not know, if there occurs some cases of "communication errors" of html5?!?

[12:15:02.0000] <Hixie>
ah, i see. yes, we have checked if postMessage() can cause deadlocks. It cannot cause deadlocks on its own, but poor use of it can cause logical deadlocks.

[12:16:00.0000] <Jockel>
Hixie: Are you working in zurich?

[12:17:00.0000] <Hixie>
(it's a completely async model and there's no way to block on reading from a port)

[12:17:01.0000] <Hixie>
i do not

[12:17:02.0000] <Hixie>
though i have been to zurich

[12:17:03.0000] <Hixie>
it looked like a localized version of geneva :-)

[12:17:04.0000] <Jockel>
Hixie: I saw, you were working for G... and you came from ch?

[12:18:00.0000] <Jockel>
Hixie: I asked, because I know somebody, working at G-zürich

[12:18:01.0000] <Hixie>
what exactly do you mean by "came from"?

[12:19:00.0000] <Hixie>
(gotta go, bbiab)

[12:19:01.0000] <Jockel>
Hixie: Only I saw your webpage.... http://hixie.ch/

[12:20:00.0000] <Jockel>
so I  guessed you are working in zürich ;)

[12:23:00.0000] <Jockel>
Hixie: Synchronous communication is not possible in the html5, or?

[12:29:00.0000] <AryehGregor>
Jockel, Hixie hasn't lived in Switzerland for like 20 years, or close to it.  He's in Mountain View, IIRC.

[12:30:00.0000] <Jockel>
AryehGregor: Thanks ;)

[13:15:00.0000] <JonathanNeal>
microdata isn't part of html5?

[13:21:00.0000] <AryehGregor>
JonathanNeal, it's part of HTML, which is what the WHATWG spec is called.  It's not part of HTML5, which is what the W3C spec is called.

[13:21:01.0000] <AryehGregor>
The WHATWG spec also used to be called HTML5, so microdata was part of that.

[13:22:00.0000] <AryehGregor>
It also used to be part of the W3C HTML5 spec until it was split out by WG decision.

[13:24:00.0000] <JonathanNeal>
Complicated.

[13:24:01.0000] <AryehGregor>
Yes.

[14:18:00.0000] <AryehGregor>
jgraham, okay, so forget about performance.  I'm trying to debug an uncaught exception in testharness.js, and it's at the end of a stack of 20 recursive calls to render, substitute, substitute_single, substitute_children, and map.  Where render is called originally by Output.show_results.  If we just built the HTML directly, this problem would probably be trivial to debug if it occurred at all.

[14:18:01.0000] <AryehGregor>
This is really not a good level of abstraction.

[14:19:00.0000] <Hixie>
anyone know how i can find out what punctuation sorts below '"' in the en-US.utf8 locale on my linux box?

[14:20:00.0000] <AryehGregor>
If you're worried about safety, I'd take the slight extra length of direct use of DOM methods over this templating stuff anyday.

[14:20:01.0000] <AryehGregor>
/me writes a patch to see how long that would be

[14:35:00.0000] <AryehGregor>
jgraham, http://pastebin.com/mDEs9T4j

[14:35:01.0000] <AryehGregor>
-8 lines.

[14:35:02.0000] <AryehGregor>
And completely safe, innerHTML used only for static strings.

[14:36:00.0000] <AryehGregor>
Oh, wait, I was using the wrong brace style, so really it should be -7 lines.

[14:36:01.0000] <AryehGregor>
If you ignore lines that are blank or contain only brackets/braces/etc., still -3 lines.

[14:36:02.0000] <AryehGregor>
Would you object if I commit this?

[14:37:00.0000] <AryehGregor>
(BTW, it also fixed the mysterious deeply-nested exception I was getting with the templating stuff)

[14:49:00.0000] <jgraham>
AryehGregor: Yes, that is the worst problem

[14:49:01.0000] <AryehGregor>
Which is?

[14:50:00.0000] <jgraham>
When there is an error and the stack trace is, uh, confusing

[14:50:01.0000] <AryehGregor>
Yeah.

[14:50:02.0000] <AryehGregor>
And the advantage is . . . ?

[14:52:00.0000] <AryehGregor>
I mean, I can see how in theory you might want it to be shorter, but it's actually not.

[14:52:01.0000] <AryehGregor>
At least in this case.

[14:52:02.0000] <jgraham>
Well it seems like a nice model. Nice enough that annevk is pushing something not dissimilar for DOM :)

[14:52:03.0000] <AryehGregor>
In what way is it nice?

[14:52:04.0000] <jgraham>
But I won't object to this patch

[14:53:00.0000] <jgraham>
It is a very regular way of describing the tree that you want just using js objects

[14:53:01.0000] <AryehGregor>
/me pushes the patch

[14:54:00.0000] <jgraham>
Rather than having to use special code for each different case

[14:58:00.0000] <AryehGregor>
That might be useful in some theoretical circumstances, just not here.

[15:09:00.0000] <Hixie>
benschwarz: yt?

[15:18:00.0000] <AryehGregor>
/me strongly suspects that assert_*() is a bottleneck here too

[15:18:01.0000] <AryehGregor>
It seems to format the message even if it's not going to be used, which hopefully it rarely will be.

[15:22:00.0000] <benschwarz>
Hixie: am now.

[15:22:01.0000] <benschwarz>
JonathanNeal: heya

[15:23:00.0000] <JonathanNeal>
hey benschwarz! :)

[15:25:00.0000] <benschwarz>
I didn't understand your question…

[15:25:01.0000] <benschwarz>
how open?

[15:27:00.0000] <AryehGregor>
jgraham, I'm going to be pushing some microoptimizations to testharness.js that provide large quantifiable performance gains on large result sets.  I just pushed the first one.

[15:27:01.0000] <JonathanNeal>
I've had an idea for something like this benschwarz http://www.diveinto.org/html5/modern.index.html

[15:27:02.0000] <AryehGregor>
I'll ask you first if they involve any substantial refactoring or design changes.

[15:27:03.0000] <JonathanNeal>
but it's fully based on the themework you did for the developers whatwg

[15:28:00.0000] <benschwarz>
JonathanNeal: it looks gnarly

[15:28:01.0000] <benschwarz>
use it!

[15:28:02.0000] <JonathanNeal>
cool

[15:28:03.0000] <JonathanNeal>
thanks

[15:28:04.0000] <benschwarz>
I never licensed it or anything… mainly just didn't consider other uses for it

[15:29:00.0000] <JonathanNeal>
It's a good outline for any collection of papers on a subject.

[15:29:01.0000] <JonathanNeal>
design, I mean

[15:29:02.0000] <JonathanNeal>
I'm just experimenting with fonts to find something that will read comfortably on my iPad as well.

[15:31:00.0000] <jgraham>
AryehGregor: I think the commit message was harsh even if I don't entirely disagree

[15:31:01.0000] <jgraham>
(for the template removal)

[15:31:02.0000] <AryehGregor>
jgraham, sorry about that.

[15:32:00.0000] <benschwarz>
JonathanNeal: if anything is worth putting back into developers.whatwg.org, let me know :)

[15:32:01.0000] <AryehGregor>
I was a little frustrated after having to deal with a few too many giant stack traces and a little too much bad performance.  :)

[15:32:02.0000] <AryehGregor>
/me is working on the latter right now

[15:33:00.0000] <JonathanNeal>
benschwarz: i'll definitely let you know if it is.

[15:43:00.0000] <Hixie>
benschwarz: i was wondering how often the developers.whatwg.org site was resynced and whether it would make sense for me to only update the source file once a week or something

[15:45:00.0000] <benschwarz>
Hixie: Are you doing that manually?

[15:46:00.0000] <Hixie>
it's in a script that triggers each time i update, currently

[15:46:01.0000] <benschwarz>
Hixie: I just run it manually still… I always meant to make it a cron task

[15:47:00.0000] <benschwarz>
I run it every few weeks

[15:52:00.0000] <Hixie>
benschwarz: k

[15:52:01.0000] <Hixie>
benschwarz: let me know if you ever run it more often than once a week :-)

[15:53:00.0000] <Hixie>
benschwarz: i'll make my script not bother unless it's more than a week old

[15:53:01.0000] <Hixie>
saves me some CPU

[15:53:02.0000] <benschwarz>
sure thing

[15:54:00.0000] <benschwarz>
just re-deployed it now :)

[16:38:00.0000] <MikeSmith>
Hixie: about the sorting question, http://www.collation-charts.org/opensolaris/opensolaris.2008.05.en_US.UTF-8.html might be useful

[16:39:00.0000] <MikeSmith>
I don't know how to actually find/check the collation rules in the local environment

[16:39:01.0000] <MikeSmith>
would think it must be something under /usr/share/i18n/locales but no idea what

[16:40:00.0000] <Hixie>
i ended up just hard-coding it

[16:40:01.0000] <MikeSmith>
ok


2011-10-06
[17:39:00.0000] <MikeSmith>
Hixie, for future reference, on Debian Linux systems at least, the SPECIAL part of /usr/share/i18n/locales/iso14651_t1_common seems to be what ends up controlling collation for common symbols

[17:39:01.0000] <MikeSmith>
...and uncommon ones, too

[17:51:00.0000] <MikeSmith>
..

[17:51:01.0000] <MikeSmith>
Just now hearing the news about Steve Jobs

[23:31:00.0000] <hsivonen>
Hixie: does http://html5.org/tools/web-apps-tracker?from=6642&to=6643 have an effect on what the parser does? the "special" group is used for parsing, but does it matter in this case?

[23:33:00.0000] <Hixie>
i believe the answer is no, because they're void elements

[23:33:01.0000] <Hixie>
so in a sense we could have instead removed the void elements from the list

[23:34:00.0000] <hsivonen>
ok

[23:34:01.0000] <Hixie>
which i guess in a naive implementation might improve perf

[23:34:02.0000] <Hixie>
but in practice i presume everyone uses bits on the tag type id so it doesn't matter

[01:32:00.0000] <Dashiva>
/me wonders if <title> will soon become optional, what with browser after browser removing the title bar

[02:25:00.0000] <jgraham>
Am I missing something, or is there no ambiguity at all in the interpretation of a string in the proposed .create() format? A string at the strat of a lsit is always a tag name. A bare string is always a text node.

[02:25:01.0000] <jgraham>
*start

[02:25:02.0000] <jgraham>
(also *list, but that is easier)

[02:27:00.0000] <annevk>
inside a list that is true

[02:27:01.0000] <annevk>
the problem is with a list of lists, but we can avoid that I think

[02:28:00.0000] <jgraham>
Where would there be a list of lists?

[02:29:00.0000] <annevk>
it depends on how the overall design turns out

[02:30:00.0000] <jgraham>
Well yes… obviously

[02:30:01.0000] <annevk>
i think we can avoid it by having varargs

[02:32:00.0000] <jgraham>
Indeed

[06:01:00.0000] <hsivonen>
http://www.glazman.org/weblog/dotclear/index.php?post/2011/10/05/a-HTML-Spaghetti-Western%3A-The-Serializer-The-Parser-and-The-Ugly-Blank-Lines

[06:35:00.0000] <annevk>
hsivonen, he's having that fight with everything that defines an object model

[06:35:01.0000] <annevk>
hsivonen, e.g. CSS

[06:36:00.0000] <annevk>
an object model throws away information an editor needs, such as whitespace between attributes, order of attributes, etc.

[06:36:01.0000] <annevk>
I'm not sure why he can't accept that if you build a WYSIWYG editor that also has some kind of source editing you have to build a custom solution

[06:49:00.0000] <MikeSmith>
hsivonen: validator.nu enhancement request from Jukka!

[06:57:00.0000] <karlcow>
annevk: why? The choice could be just to have some rules for a certain class of products to ensure interop in between editors.

[07:00:00.0000] <hsivonen>
karlcow: it's more complicated than that

[07:00:01.0000] <hsivonen>
karlcow: depending on what level of source preservation you want

[07:00:02.0000] <hsivonen>
karlcow: for example, the DOM doesn't store the whitespace that was between attributes

[07:01:00.0000] <karlcow>
hsivonen: so you mean in case you do a round-trip browser/editor

[07:01:01.0000] <hsivonen>
karlcow: so when writing an editor, one should decide up front if it's going to be a DOM editor or a source-fidelity editor

[07:01:02.0000] <hsivonen>
karlcow: if you are using the DOM as the model but try to make a source-fidelity editor, there's going to be pain

[07:01:03.0000] <karlcow>
I guess humans are dealing with the physical organization of the markup not the dom

[07:02:00.0000] <hsivonen>
karlcow: I mean round-tripping aspects of the source that browsers consider meaningless or errors

[07:03:00.0000] <hsivonen>
I don't know how Dreamweaver does it, but clearly, they've designed for it from day 1

[07:03:01.0000] <jgraham>
I feel quite sorry for glazou really. He seems to be doing something hard and not that interesting with technology that makes it even harder.

[07:12:00.0000] <hsivonen>
jgraham: I think editors are interesting and having DOM-based editors is worthwhile

[07:13:00.0000] <hsivonen>
jgraham: the problem is when user expections don't match the realities of the editor being DOM-based

[07:13:01.0000] <jgraham>
hsivonen: I don't mean uninteresting as a problem space

[07:13:02.0000] <jgraham>
I mean "not a product many people are interested in"

[07:14:00.0000] <jgraham>
At least my perception is that that age of the dreamweaver-style editor is ending

[07:14:01.0000] <jgraham>
My perception could be wrong of course

[07:14:02.0000] <jgraham>
But I expect that on the low end people are going to use online contentEditable based tools

[07:15:00.0000] <jgraham>
and at the high end they will use either a text editor or some more fancy falsh-like thing that totally abstracts away the underlying markup

[07:15:01.0000] <hsivonen>
jgraham: why would Dreamweaver-style be ending?

[07:15:02.0000] <jgraham>
*flash

[07:15:03.0000] <hsivonen>
/me doesn't know of other Dreamweaver-style editors than Dreamweaver itself

[07:16:00.0000] <jgraham>
Isn't BlueGriffon dreamweaver-style?

[07:16:01.0000] <hsivonen>
jgraham: not in my opinion :-)

[07:16:02.0000] <jgraham>
Why not? I am curious

[07:17:00.0000] <hsivonen>
jgraham: because it doesn't preserve errors in the parts of source that you aren't editing on the visual side

[07:17:01.0000] <jgraham>
Hmm, that is quite a technical distinction

[07:17:02.0000] <hsivonen>
jgraham: I believe that's a key selling point of Dreamweaver to a part of its audience

[07:17:03.0000] <jgraham>
In terms of markets I think they occupy a similar space

[07:18:00.0000] <hsivonen>
jgraham: I think Dreamweaver's feature set could serve also the market that BlueGriffon's feature set can serve

[07:18:01.0000] <hsivonen>
jgraham: but not vice versa in the general case

[07:18:02.0000] <jgraham>
Right, it might not be as good as dreamweaver (in some respects), but it competes with it

[07:19:00.0000] <hsivonen>
jgraham: as I understand it, source preservation has been a marketable and marketed feature of Dreamweaver since forever

[07:19:01.0000] <hsivonen>
jgraham: so BlueGriffon doesn't have one of the key features of Dreamweaver

[07:20:00.0000] <hsivonen>
jgraham: when BlueGriffon tries to approximate that feature of Dreamweaver, there's pain

[07:20:01.0000] <jgraham>
Making a product that lacks a key feature of the market leader for deep technical reasons in a market that I claim is being squeezed doesn't make my feel like BlueGriffon is in a *better* position than I previously believed :)

[07:20:02.0000] <jgraham>
uh, that sentence changed focus half way through

[07:24:00.0000] <annevk>
karlcow, "some rules" you gonna write them up? ;)

[07:24:01.0000] <karlcow>
annevk: unrelated.

[07:25:00.0000] <hsivonen>
karlcow: in the CSS parsing and CSSOM case, throwing away unsupported rules is part of the fundamental operation of the CSS forward-compatible parsing rules

[07:26:00.0000] <hsivonen>
karlcow: yet, if you want Dreamweaver's source preservation features, you need not to throw away unsupported rules

[07:26:01.0000] <karlcow>
yup, understood, different class of products.

[07:27:00.0000] <hsivonen>
right, but there's really no need to standardized the internal data model of Dreamweaver, because it's not exposed to Web content

[07:27:01.0000] <hsivonen>
s/zed/ze/

[07:27:02.0000] <karlcow>
parsing for rendering and editing are two different use cases

[07:28:00.0000] <karlcow>
hsivonen: agreed. exposed to humans for web editing

[07:28:01.0000] <karlcow>
usability space

[08:29:00.0000] <annevk>
you can't just wave "classes of products" around as a magic wand and solve problems karlcow

[08:32:00.0000] <karlcow>
/me is still looking for his magic wand without understanding annevk

[08:34:00.0000] <jgraham>
annevk: (I don't think karlcow was trying to solve the problem so much as understand it)

[08:35:00.0000] <karlcow>
thanks jgraham :)

[09:08:00.0000] <FlorianX>
annevk: did you get the tweet? :-)

[09:15:00.0000] <annevk>
I did

[09:16:00.0000] <FlorianX>
ok

[09:26:00.0000] <bga_>
TabAtkins in var example slide $main-color$. Is it error?

[09:27:00.0000] <jgraham>
annevk: Should have answered on Google Plus

[09:28:00.0000] <annevk>
?

[09:31:00.0000] <jgraham>
Well if the question "did you get the tweet" is asked on irc, not using a third means of communication to reply is lame

[09:31:01.0000] <annevk>
i'm boring, remember?

[09:40:00.0000] <timeless>
heh

[09:43:00.0000] <jgraham>
annevk: So you're having bacon cheeseburger and yoghurt this evening?

[09:45:00.0000] <MikeSmith>
about video@controls, why does it not make more sense for the video play/pause/etc. buttons to be displayed by default?

[09:45:01.0000] <MikeSmith>
so in that case, the controls attribute would be more like spellcheck

[09:46:00.0000] <MikeSmith>
that is, you'd only need to specify it when you didn't want the controls displayed

[09:46:01.0000] <annevk>
jgraham, not sure about dinner, but I had delicious yoghurt

[10:15:00.0000] <karlcow>
"Tolerating broken HTML writers" http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Connolly/tolerated.html

[10:16:00.0000] <karlcow>
" Please stop generating HTML in this style!" :)

[10:17:00.0000] <karlcow>
also http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Connolly/errors.html

[10:48:00.0000] <Ms2ger>
MikeSmith, I believe the argument was that <video nocontrols> would be used by people with JS-based controls, and these would break when you disable JS

[10:48:01.0000] <MikeSmith>
I see

[11:03:00.0000] <Hixie>
MikeSmith: specifically, the lack of a controls="" attribute doesn't mean there's no controls

[11:03:01.0000] <Hixie>
MikeSmith: it has to be no controls="" attribute _plus_ JS disabled

[11:03:02.0000] <MikeSmith>
OK

[11:04:00.0000] <Hixie>
also, even with JS enabled, there can (should) still be controls e.g. in the context menu

[11:11:00.0000] <MikeSmith>
ah, yeah

[11:15:00.0000] <timeless>
anyone here know how to get to the Desktop version of google calendar?

[11:15:01.0000] <timeless>
/me hates sites that do discrimination

[13:02:00.0000] <rburton>
would this be a good place to get webidl help?

[13:14:00.0000] <timeless>
rburton: what's wrong?

[13:15:00.0000] <rburton>
just new to it mainly

[13:15:01.0000] <rburton>
is there a good tutorial/annotated reference?

[13:15:02.0000] <rburton>
but the main point is, i want an interface that has a string "uri" attribute, and a unlimited string-string hash "params" attribute

[13:15:03.0000] <rburton>
the spec seems to say that i can't do the hash bit

[13:16:00.0000] <timeless>
hash?

[13:16:01.0000] <rburton>
/me this appears to parse widlproc dictionary Options {};  interface ShareItem {  attribute DOMString uri;  attribute Options options;  };

[13:16:02.0000] <rburton>
/me just discovered a new keybinding in irccloud

[13:17:00.0000] <timeless>
tab? :)

[13:17:01.0000] <rburton>
control-enter makes a /me

[13:17:02.0000] <timeless>
btw, do you have a spare invite for irccloud?

[13:17:03.0000] <rburton>
sure

[13:17:04.0000] <rburton>
email?

[13:17:05.0000] <timeless>
timeless@gmail

[13:17:06.0000] <rburton>
sent

[13:17:07.0000] <timeless>
thanks!

[13:18:00.0000] <rburton>
so in js i want an object with a "uri" string attribute, and a plain object "options" attribute that can contain arbitrary key-value pairs

[13:18:01.0000] <rburton>
but id like to do it "properly" in webidl so there are sane docs for that arbitrary bit

[13:21:00.0000] <timeless>
offhand, it seems that webidl could definitely use some more text explaining how it expects things to be used, and especially whether it covers this use case

[13:21:01.0000] <timeless>
i believe it does, but it seems like reasonable feedback to send to the list

[13:21:02.0000] <timeless>
/me tries to use irccloud.com from a Torch

[13:27:00.0000] <timeless>
shiny!

[13:27:01.0000] <rburton>
timeless: what is the best list for webidl feedback?

[13:27:02.0000] <Hixie>
webapps

[13:27:03.0000] <Hixie>
public-webapps⊙wo

[13:28:00.0000] <Hixie>
(it should say at the top of the webidl spec)

[13:28:01.0000] <timeless>
Hixie: should; doesn't :(

[13:29:00.0000] <timeless>
also good feedback :)

[13:31:00.0000] <timeless>
sorry

[13:31:01.0000] <timeless>
/me is getting the hang of irccloud

[13:40:00.0000] <AryehGregor>
"Palpable"?  Really?

[13:40:01.0000] <timeless>
AryehGregor: context? :)

[13:40:02.0000] <AryehGregor>
timeless, html5.org/r/6640

[13:41:00.0000] <Hixie>
AryehGregor: you got a better word? :-)

[13:41:01.0000] <Hixie>
i'm running out of unique terms here

[13:41:02.0000] <rburton>
hehe

[13:41:03.0000] <rburton>
Hixie: thanks

[13:43:00.0000] <timeless>
heh

[13:44:00.0000] <timeless>
"Experiential"? :)

[13:48:00.0000] <Hixie>
too confusingly close to "experimental"

[13:49:00.0000] <Philip`>
If the conformance model is too complex to even come up with reasonable terms to describe it to people, maybe the model should be simplified, e.g. by removing the whole palpability should-level requirement entirely :-)

[13:50:00.0000] <timeless>
nah :)

[13:50:01.0000] <timeless>
Hixie: yeah, understood

[13:51:00.0000] <Hixie>
Philip`: i considered it, and may still do that. i think at a minimum it provides an interesting view into the language for our own purposes of sanity checking things.

[13:51:01.0000] <Hixie>
the requirement itself is essentially just an evolution of HTML4's "paragraphs musn't be empty" rule

[13:52:00.0000] <astearns>
evident?

[13:56:00.0000] <AryehGregor>
Does IE not support innerHTML on tbody or something crazy like that?

[13:56:01.0000] <Hixie>
astearns: considered it, but its meaning is a little too much on the side of "obvious" than just "visible"

[13:56:02.0000] <AryehGregor>
. . .

[13:56:03.0000] <timeless>
AryehGregor: http://ajaxian.com/archives/innerhtml-gotchas

[13:57:00.0000] <timeless>
> After some searching it seems IE has inconsistent support for the insertAdjacentHTML method, and apparently for elements like TR and TBODY IE will throw an exception if the method is called on those methods.

[13:57:01.0000] <AryehGregor>
Wow, that's insane.

[13:57:02.0000] <timeless>
> We can read about this on good ‘ole MSDN: innerHTML property.

[13:57:03.0000] <timeless>
The important piece is:

[13:57:04.0000] <timeless>
    The property is read/write for all objects except the following, for which it is read-only: COL, COLGROUP, FRAMESET, HTML, STYLE, TABLE, TBODY, TFOOT, THEAD, TITLE, TR.

[13:57:05.0000] <AryehGregor>
I hate IE.

[13:57:06.0000] <timeless>
of course, that link is dead

[13:58:00.0000] <timeless>
yay msdn

[13:58:01.0000] <AryehGregor>
http://msdn.microsoft.com/en-us/library/ms533897(v=vs.85).aspx

[13:58:02.0000] <timeless>
right, the comment at the end:

[13:58:03.0000] <timeless>
> "The property is read/write for all objects except the following, for which it is read-only: COL, COLGROUP, FRAMESET, HEAD, HTML, STYLE, TABLE, TBODY, TFOOT, THEAD, TITLE, TR."

[13:58:04.0000] <timeless>
/me wonders how it got lost from the body of the document

[13:59:00.0000] <timeless>
it's possible they removed that restriction by 10?

[13:59:01.0000] <timeless>
which vers of ie are you testing?

[13:59:02.0000] <timeless>
/me has ie10 previews available if there's a testcase

[13:59:03.0000] <timeless>
/me is *way* too lazy to write one

[14:01:00.0000] <AryehGregor>
9.

[14:21:00.0000] <jgraham>
Ms2ger: So why does WebIDL put attributes on prototypes? That doesn't seem to match non-gecko browsers or be very logical

[14:28:00.0000] <jgraham>
/me thinks we should introduce papal conformance conditions

[14:28:01.0000] <timeless>
/me sighs

[14:28:02.0000] <timeless>
/me read paypal]

[14:32:00.0000] <jgraham>
timeless: It's OK, so does google

[14:32:01.0000] <timeless>
oh, i feel much better now, thanks :)

[14:46:00.0000] <Ms2ger>
jgraham, I can only read the spec and complain when Gecko fails tests for matching it :)

[14:46:01.0000] <Ms2ger>
/me doesn't claim to understand WebIDL

[14:47:00.0000] <timeless>
heh

[15:04:00.0000] <jgraham>
Ms2ger: Dammit. Now I will have to ask on public-script-coord

[15:04:01.0000] <jgraham>
I don't like that list :-|

[15:04:02.0000] <Ms2ger>
-webapps is fine too, and I read that one :)

[15:09:00.0000] <timeless>
heh

[15:10:00.0000] <jgraham>
It is? I thought WebIDL was supposed to be discussed on public-script-coord so that the TC39 people could have a chance to get upset at things

[15:13:00.0000] <Ms2ger>
Exactly

[15:15:00.0000] <jgraham>
Heh

[15:19:00.0000] <jgraham>
sicking: I don't know why you said that the element.create / append proposal depends on knowing which strings are tags and which aren't. It doesn't

[15:21:00.0000] <jgraham>
In particular if we use the form [tagname, attributes, *children] there is no ambiguity

[15:21:01.0000] <jgraham>
a string at the head of a list is always a tag name. A string not at the head of a list is never a tag name

[15:23:00.0000] <jgraham>
It is true that appending multiple children to an existing node requires the use of append.apply

[15:23:01.0000] <jgraham>
If you have an array of templates

[15:58:00.0000] <smaug____>
I know there is JS error console somewhere in Opera, but I can't find it

[15:58:01.0000] <smaug____>
ah, there is was..

[15:58:02.0000] <smaug____>
hard to find

[16:05:00.0000] <smaug____>
does anyone know if it is possible to re-enable javascript: in the location bar in Opera?

[16:08:00.0000] <Hixie>
can one iframe in any way access a sibling iframe if the two iframes and their parent browsing context are in three different origins?

[16:11:00.0000] <bga_>
smaug____ f12

[16:11:01.0000] <Hixie>
to answer my question, per spec, yes.

[16:13:00.0000] <bga_>
Hixie iirc i can access only to {.frames} and {.name}

[16:13:01.0000] <Hixie>
window.frames === window

[16:13:02.0000] <bga_>
its gives me full tree

[16:13:03.0000] <Hixie>
but you can access window[n] which is what matters

[16:13:04.0000] <bga_>
hm

[16:13:05.0000] <bga_>
ok

[16:14:00.0000] <bga_>
ah. {.length}

[16:14:01.0000] <bga_>
now i understand :)

[16:14:02.0000] <smaug____>
bga_: sorry, what does f12 do?

[16:15:00.0000] <bga_>
smaug____ enable js, flash, proxy etc

[16:16:00.0000] <smaug____>
bga_: I do have js enabled. I want to enable javascript: in the location bar

[16:16:01.0000] <smaug____>
currently I get just "Access to this port is disabled for security reasons"


2011-10-07
[21:29:00.0000] <zcorpan>
jgraham: why isn't it logical to have attributes on the prototype?

[00:50:00.0000] <jgraham>
zcorpan: Attributes are properties of instances. Putting them on the prototype and using getter magic to return the value seems like a very muddy model that depends on implementation details

[00:50:01.0000] <JonathanNeal>
hiya

[00:54:00.0000] <zcorpan>
jgraham: but it makes feature detection simpler for authors

[00:56:00.0000] <jgraham>
Well not if 3/4 browsers don't use the model

[00:56:01.0000] <jgraham>
Since you will have to feature detect different things in different places

[00:57:00.0000] <jgraham>
Although I would agree in principle if that wasn't the case

[01:22:00.0000] <zcorpan>
so with authors > implementors, shouldn't we be moving to that model?

[01:24:00.0000] <hsivonen>
I wonder what kind of evil situations I should test with HTML in sync XHR that can be tested relatively deterministically in an automated test...

[01:25:00.0000] <hsivonen>
I'm now mainly testing charset stuff and that scripts don't run

[01:34:00.0000] <annevk>
<img> not loading?

[01:40:00.0000] <hsivonen>
annevk: oh yeah, I'm testing img, iframe, style sheet, video, object and script not loading

[01:41:00.0000] <hsivonen>
and the onload attribute in the loaded file doing nothing

[01:41:01.0000] <hsivonen>
my sync XHR testing is now on the level "seems to work. good."

[01:57:00.0000] <jgraham>
zcorpan: The point is that in the short term it makes things worse for authors. And in the long term it makes the mental model more confusing, although it will improve feature detection once we don't have to care about IE<11 (say)

[02:45:00.0000] <annevk>
sicking seems very confused with the proposal

[03:31:00.0000] <hsivonen>
annevk: which proposal?

[03:35:00.0000] <annevk>
oh sorry

[03:35:01.0000] <annevk>
the proposal for easier element creation

[03:49:00.0000] <hsivonen>
sigh. the reference maturity level issue just won't go away (now DAP and DOM4)

[03:50:00.0000] <annevk>
also see the geolocation list

[03:50:01.0000] <jgraham>
hsivonen: Making that issue go away would be admitting that the process is broken. Which it is. But there are still heads in the sand.

[03:50:02.0000] <annevk>
someone suggested referencing HTML4 for event handler attributes

[03:51:00.0000] <annevk>
trololol

[03:53:00.0000] <hsivonen>
Referencing HTML4 is even more sad than referencing DOM < 4

[03:56:00.0000] <smaug____>
/me hasn't even started to look at all the append/element creation proposals yet

[04:21:00.0000] <hsivonen>
/me finds <!DOCTYPE NETSCAPE-Bookmark-file-1>

[04:26:00.0000] <zcorpan>
hsivonen: does firefox use the html5 parser for importing bookmarks these days?

[04:34:00.0000] <hsivonen>
zcorpan: not yet

[04:35:00.0000] <hsivonen>
zcorpan: that's why I'm looking at a file that has a doctype like that

[04:37:00.0000] <zcorpan>
ok

[04:37:01.0000] <jgraham>
In unrelated news http://my.opera.com/desktopteam/blog/2011/10/07/ragnarok-css3-radial-gradients

[04:39:00.0000] <annevk>
yay for stig james arne et al

[04:39:01.0000] <hsivonen>
jgraham: cool

[04:40:00.0000] <annevk>
hmm

[04:40:01.0000] <annevk>
Opera Next says I'm using the latest snapshot

[04:40:02.0000] <annevk>
but I'm clearly not

[04:41:00.0000] <hsivonen>
annevk: the Ubuntu/Debian repo is also out of date

[04:41:01.0000] <jgraham>
annevk: They don't release the snapshots to autoupdate straight away

[04:41:02.0000] <smaug____>
hsivonen: still about parsing. Does the spec say that some elements can be moved in the DOM during parsing

[04:42:00.0000] <hsivonen>
smaug____: yes

[04:42:01.0000] <jgraham>
smaug____: s/can/must/

[04:42:02.0000] <smaug____>
hsivonen: I mean, are some elements really inserted to DOM and then moved to some other place?

[04:42:03.0000] <hsivonen>
smaug____: yes

[04:43:00.0000] <hsivonen>
smaug____: however, in the innerHTML case, per spec, that happens in the fragment that gets inserted but our optimization optimizes away the fragment so that it happens in the tree in that case

[04:43:01.0000] <smaug____>
right

[04:43:02.0000] <smaug____>
I

[04:43:03.0000] <hsivonen>
smaug____: which is why I suggested turning off the mechanism that turns notifications into MutationRecords when the fragment parser is running

[04:43:04.0000] <smaug____>
I'm thinking about mutations while parsing the page

[04:43:05.0000] <hsivonen>
and then faking the MutationRecord right after

[04:43:06.0000] <jgraham>
hsivonen: Thanks btw

[04:44:00.0000] <hsivonen>
smaug____: while parsing the page from the network, stuff can get moved around per spec

[04:44:01.0000] <smaug____>
though, that all happens per spec...

[04:44:02.0000] <smaug____>
so if someone listens for mutations before the page is loaded, surprises are ok, I guess

[04:47:00.0000] <hsivonen>
smaug____: is the new mechanism so lightweight that reporting parser-made mutations is OK for perf?

[04:47:01.0000] <hsivonen>
jgraham: thanks about what?

[04:47:02.0000] <smaug____>
hsivonen: well, it is up to the web app to decide whether to use it or not

[04:48:00.0000] <jgraham>
hsivonen: 05:42 < hsivonen> jgraham: cool

[04:50:00.0000] <annevk>
smaug____, should we really have mutations for the parser inserted elements?

[04:51:00.0000] <hsivonen>
jgraham: ah. you're welcome

[04:51:01.0000] <smaug____>
annevk: I'm not sure

[04:51:02.0000] <hsivonen>
jgraham: are you no longer in Sweden or is just your IRC not in Sweden?

[04:51:03.0000] <smaug____>
annevk: that is something I'm trying to figure out

[04:51:04.0000] <jgraham>
hsivonen: Just my IRC

[04:51:05.0000] <hsivonen>
smaug____: will the Skype extensions be able to use it on every page?

[04:52:00.0000] <smaug____>
I sure hope Skype isn't using mutation events anymore

[04:52:01.0000] <smaug____>
I somehow thought they moved to our internal mutationobserver thingie

[04:52:02.0000] <smaug____>
since skype extension is anyway a binary extension

[04:53:00.0000] <jgraham>
hsivonen: I am balancing out the fact that Hixie's IRC is in Norway :)

[04:58:00.0000] <hsivonen>
smaug____: ok. my main point is that parse-time perf can be affected for all pages if an extension can request to see the MutationRecords for all pages

[04:59:00.0000] <annevk>
smaug____, doesn't sound like a good idea

[04:59:01.0000] <smaug____>
annevk: any particular reason why

[05:00:00.0000] <annevk>
cause you can already get to the result easily enough

[05:00:01.0000] <smaug____>
how ?

[05:00:02.0000] <annevk>
just wait until the parser is done

[05:01:00.0000] <Cradam>
/me likes the version-less html idea

[05:01:01.0000] <smaug____>
(again, I don't really have opinion whether it should be possible get mutationrecords during parsing)

[05:02:00.0000] <smaug____>
annevk: well,  if you have a huge page, like HTML spec, some script might want to decorate elements  while the page is still loading

[05:02:01.0000] <smaug____>
basically initialize widgets or such during the page load

[05:03:00.0000] <annevk>
I think for those you should get mutations

[05:03:01.0000] <annevk>
I would expect the parser to use DOM methods that do not affect mutation observers

[05:04:00.0000] <annevk>
internal stuff

[05:04:01.0000] <smaug____>
I don't understand

[05:04:02.0000] <smaug____>
" I think for those you should get mutations" ... "use DOM methods that do not affect mutation observers"

[05:04:03.0000] <annevk>
everything the parser does uses internal methods that do not affect mutation observers

[05:05:00.0000] <smaug____>
for what should you get mutations ?

[05:05:01.0000] <annevk>
but if you have a script that while parsing does a call to insertBefore or some such that would affect them

[05:05:02.0000] <smaug____>
so it is not possible to initialize widgets during parsing

[05:06:00.0000] <smaug____>
I'm talking about widgets like <div foobar="element_with_foobar_attribute_is_a_widget">

[05:07:00.0000] <Cradam>
eugh i hate those wierd attributes people use

[05:07:01.0000] <annevk>
for that we are going to introduce a dedicated mechanism

[05:08:00.0000] <annevk>
<div is=something> or some such, see the component model discussion

[05:08:01.0000] <annevk>
it seems bad if you need all the overhead of mutation observers just for that

[05:08:02.0000] <Cradam>
i also find it wierd how people use "" when they arent needed

[05:09:00.0000] <bga_>
Cradam ++

[05:09:01.0000] <bga_>
and close <td>

[05:10:00.0000] <annevk>
</td> being optional was a great idea

[05:10:01.0000] <bga_>
yes

[05:11:00.0000] <Cradam>
tables... who uses them other than for ecommerce

[05:12:00.0000] <annevk>
me

[05:13:00.0000] <Cradam>
annevk: seriously?

[05:13:01.0000] <bga_>
Cradam table layout is easy than div layout

[05:13:02.0000] <Cradam>
bga_: :O

[05:13:03.0000] <annevk>
Cradam, http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw

[05:13:04.0000] <Cradam>
NEVER USE TABLES FOR LAYOUT!

[05:14:00.0000] <bga_>
:)

[05:14:01.0000] <smaug____>
tables are useful

[05:14:02.0000] <annevk>
or e.g. http://annevankesteren.nl/2010/07/matterhorn-tour

[05:14:03.0000] <annevk>
yeah, they're just annoying to author

[05:14:04.0000] <smaug____>
annevk: yes, I can see reasons to not fire create mutation records

[05:14:05.0000] <Cradam>
smaug____: yes for tabular data

[05:14:06.0000] <smaug____>
but for consistency they should be there...

[05:14:07.0000] <smaug____>
but I don't care too much

[05:15:00.0000] <smaug____>
I'm trying to get innerHTML + mutationrecords to work better first

[05:15:01.0000] <smaug____>
(in the implementation)

[05:16:00.0000] <Cradam>
annevk: why do i need that

[05:16:01.0000] <bga_>
/me crying each time when write {document.createEvent() ...}

[05:17:00.0000] <smaug____>
/me needs to find time to implement event ctors

[05:17:01.0000] <Cradam>
i repeat the NEVER part of my comment about not using tables for layout!

[05:17:02.0000] <annevk>
Cradam, what?

[05:18:00.0000] <Cradam>
annevk: why do i need that link about DOM

[05:18:01.0000] <annevk>
because you asked whether I used tables for something other than ecommerce and I said yes and then you asked if I was serious so I decided to give some examples

[05:18:02.0000] <hsivonen>
annevk: why can't I set responseType on XHR before the state is OPENED?

[05:19:00.0000] <Cradam>
ahh yes

[05:19:01.0000] <Cradam>
tables... who uses them other than for ecommerce and tabular data

[05:19:02.0000] <annevk>
hsivonen, because open() resets a bunch of things

[05:19:03.0000] <Cradam>
tables... who uses them other than for ecommerce and tabular data (other than newbs who don't know better)

[05:19:04.0000] <hsivonen>
annevk: hmmkay. failed my intuition

[05:20:00.0000] <annevk>
hsivonen, we could make it work I suppose, it kind of depends on how people want this to work

[05:20:01.0000] <annevk>
other than extensions there's not much love for XMLHttpRequest from people other than me

[05:21:00.0000] <hsivonen>
annevk: hey, I'm giving XHR some text/html love

[05:21:01.0000] <annevk>
technically that's an extension, but it's still great and appreciated :)

[06:58:00.0000] <hsivonen>
hrm. ES5 String.prototype.trim() affects more than space, tab, CR and LF

[06:58:01.0000] <hsivonen>
boo

[06:59:00.0000] <jgraham>
hsivonen: You won't liek any of the string stuff in ECMAScript

[07:00:00.0000] <jgraham>
It all depends on ever changing unicode standards

[07:00:01.0000] <hsivonen>
:-(

[07:02:00.0000] <Ms2ger>
hsivonen, and of course we should make HTML number parsing depend on it as well!

[07:03:00.0000] <hsivonen>
Can ES5 or Mozilla-specific JS do 64-bit ints these days?

[07:04:00.0000] <hsivonen>
maybe I should pass 64-bit ints as stringified in JS

[07:05:00.0000] <Ms2ger>
{ hi: ..., low: ... }?

[07:06:00.0000] <smaug____>
I don't recall 64 bit

[07:06:01.0000] <smaug____>
isn't Number 53 bits or something strange like that

[07:07:00.0000] <bga_>
Ms2ger i have choosed to have internal charset w/ EOL, a-z, a-Z, 0-9 and $#... its just look like stantdard ascii but i dont trust standards :) and i have abstract class for external charset which can convert string to internal charset and back, have 'isClass' fn like isLowerChar for transforming/parsing w/o convert to internal charset

[07:07:01.0000] <bga_>
i'll show you later

[07:07:02.0000] <Ms2ger>
Wasn't 53 bits how much SM allows pointers to use?

[07:08:00.0000] <hsivonen>
smaug____: Number is a 64-bit IEEE 754 value per spec

[07:08:01.0000] <bga_>
hsivonen https://developer.mozilla.org/en/js-ctypes/js-ctypes_reference

[07:09:00.0000] <Cradam>
a[href="./"],a:link[href="./"] {} FTW

[07:10:00.0000] <smaug____>
hsivonen: yeah, but you can't express all the 64bit values using JS Number

[07:10:01.0000] <smaug____>
I mean 64bit int

[07:12:00.0000] <hsivonen>
bga_: thanks

[07:14:00.0000] <Cradam>
bored and poor = not a good combo

[07:14:01.0000] <Ms2ger>
You could write specs

[07:18:00.0000] <Cradam>
Ms2ger: ...

[07:18:01.0000] <Cradam>
why would anyone respect specs that i write, its not like i have 10 years of experience or a phd

[07:18:02.0000] <Ms2ger>
Me neither

[07:19:00.0000] <bga_>
Cradam write spec and its will die in draft state :)

[07:21:00.0000] <Ms2ger>
There's a lot of stuff that still needs specifications

[07:28:00.0000] <Philip`>
Ms2ger: Pointers are 47 bits, I think

[07:29:00.0000] <jgraham>
I wonder how many people writing specs *do* have 10 years of experince and a PhD

[07:29:01.0000] <Philip`>
(64-bit doubles can store 53-bit integers losslessly)

[07:30:00.0000] <Ms2ger>
jgraham, all the people who got us DOM3? :)

[07:30:01.0000] <Philip`>
If spec writers had PhDs, surely they'd be more likely to write specs in LaTeX than in HTML

[07:31:00.0000] <Cradam>
also how will writing specs relieve boredom of poverty

[07:31:01.0000] <Ms2ger>
You have something to do, and Google might end up hiring you

[07:31:02.0000] <smaug____>
Ms2ger: not D3E

[07:31:03.0000] <Ms2ger>
Don't talk to me about d3e ;)

[07:32:00.0000] <smaug____>
Google, or Mozilla or Opera might hire you, perhaps even Microsoft

[07:32:01.0000] <Cradam>
*or

[07:32:02.0000] <Cradam>
baha google would never hire me

[07:32:03.0000] <jgraham>
smaug____: That's just mean

[07:32:04.0000] <Cradam>
smaug____: i would NEVER work for MS

[07:33:00.0000] <Ms2ger>
Apple?

[07:33:01.0000] <bga_>
Oracle :P

[07:34:00.0000] <Cradam>
Apple is also not high on my willing to have a job with them

[07:36:00.0000] <hsivonen>
when will epoch time as JS Number lose millisecond precision?

[07:36:01.0000] <hober>
Cradam: :(

[07:37:00.0000] <Cradam>
hober: why?

[07:37:01.0000] <Ms2ger>
hober is an Apple employee

[07:38:00.0000] <Philip`>
hsivonen: 2^53 msecs = 2^43 secs = quarter of a million years

[07:38:01.0000] <hsivonen>
Philip`: ok. good

[07:39:00.0000] <Cradam>
hober: i only mean that they sound like they have a very corporate environment, i would rather work for google or mozilla

[07:41:00.0000] <gsnedders>
In other news, the HbbTV and OIPF specs are scary.

[07:41:01.0000] <hsivonen>
/me looks up OIPF

[07:41:02.0000] <gsnedders>
hsivonen: No 64-bit ints, just 64-bit doubles.

[07:41:03.0000] <hsivonen>
Wikipedia doesn't know what OIPF is

[07:42:00.0000] <gsnedders>
Open IPTV Forum

[07:42:01.0000] <hsivonen>
Oh Open IPTV Forum

[07:42:02.0000] <hsivonen>
gsnedders: who is implementing those specs besides Opera?

[07:42:03.0000] <hsivonen>
a dozen WebKit ports?

[07:43:00.0000] <gsnedders>
http://www.mediatvcom.com/content.php?page=hbbtv&preview=true&lg=en

[07:43:01.0000] <gsnedders>
A lot of them are custom CE-HTML impls

[07:43:02.0000] <Cradam>
i think i have upset hober

[07:44:00.0000] <hsivonen>
gsnedders: custom CE-HTML impls as in not using a pre-existing Web engine?

[07:44:01.0000] <gsnedders>
Yeah.

[07:45:00.0000] <hsivonen>
gsnedders: the only browser vendors there that I've heard about are Opera, Access and ANT

[07:45:01.0000] <hsivonen>
I wonder how Web-compatible the non-Opera engines are

[07:46:00.0000] <gsnedders>
They aren't, pretty much.

[07:46:01.0000] <hsivonen>
gsnedders: who provides the content that these engines ingest? cable company extranets?

[07:46:02.0000] <gsnedders>
hsivonen: Pretty much. Sometimes widgets as well.

[07:47:00.0000] <hsivonen>
I wonder what the sales pitch for the non-Opera vendors is

[07:47:01.0000] <gsnedders>
These things do rather help our > 70% marketshare on TVs…

[07:47:02.0000] <hsivonen>
oh. the Comedia thing is said to be WebKit

[07:48:00.0000] <gsnedders>
I believe there are other WebKit based impls too.

[07:48:01.0000] <Cradam>
ie6 usage at 9% FTW

[07:48:02.0000] <gsnedders>
But certainly not with any large amount of development resources to practically have a good enough product to sell.

[07:49:00.0000] <hsivonen>
Recently, Poland joined Finland, Sweden, Norway and Denmark as a contry with < 1% IE6 usage share

[07:49:01.0000] <hsivonen>
/me wonders how security patches work with TVs

[07:49:02.0000] <hsivonen>
/me guesses they don't

[07:49:03.0000] <gsnedders>
Depends on the TV.

[07:50:00.0000] <gsnedders>
Some TVs have browsers in ROM, so they don't, at al.

[07:50:01.0000] <hsivonen>
Since our TV works, I've figured that there wouldn't be much of an upside to connecting it to the Internet and trying a software update

[07:51:00.0000] <hsivonen>
though I believe our TV doesn't have a browser

[07:51:01.0000] <hsivonen>
IIRC, it came with legal stuff that suggested it has some Mozilla software in it. NSS probably

[07:52:00.0000] <gsnedders>
In general Opera-based TVs updates are entirely up to the vendor.

[07:52:01.0000] <gsnedders>
Because for a lot of them we merely ship an SDK to the vendor.

[07:52:02.0000] <hsivonen>
It would suck to start relying on a browser, find out that it has an XSS-enabling hole and not get a fix

[07:53:00.0000] <hsivonen>
/me uses Firefox for TV browsing (Firefox running on a Mac Mini)

[07:54:00.0000] <Cradam>
hober: i am sorry

[08:07:00.0000] <zewt>
i don't think i've ever seen Android update its browser either, except during a full OS update

[08:09:00.0000] <Cradam>
i don't understand the use of TV's

[08:09:01.0000] <Cradam>
in modern cyber space

[08:12:00.0000] <gsnedders>
zewt: Heck, my Android phone has known security bugs in it, because the vendor (HTC) didn't want to support a year old phone. :\

[08:12:01.0000] <gsnedders>
/me gets tempted to get involved in web TV standards again, but doesn't really want to inflict that pain on himself

[08:12:02.0000] <gsnedders>
But they are such a mess. :\

[08:12:03.0000] <Ms2ger>
You could get involved with the IETF instead

[08:13:00.0000] <gsnedders>
Ms2ger: Considerably less painful.

[08:13:01.0000] <zewt>
the browser, at least, should be updated by market like every other google-provided app--but I've never once seen that happen

[08:13:02.0000] <gsnedders>
zewt: Probably not because WebKit is a system library, and that's where the interesting bits lies.

[08:13:03.0000] <gsnedders>
*lie

[08:14:00.0000] <gsnedders>
Like, the browser itself is fairly uninteresting, and unlikely to be where any security issues are.

[08:15:00.0000] <zewt>
it's pretty astounding that Google didn't set up their mobile OS to allow updating the browser easily, and ship with a solid browser (android's browser is very ... not)

[08:15:01.0000] <zewt>
(tried developing simple touchscreen webapps supporting it; not fun at all)

[08:17:00.0000] <hsivonen>
zewt: Firefox and Opera Mobile to rescue

[08:18:00.0000] <zewt>
google should not be creating new old, unupdated, buggy browsers that almost everyone on a platform uses; we're just getting rid of one of those D:

[08:19:00.0000] <hsivonen>
gsnedders: what kind of holes?

[08:20:00.0000] <zewt>
i still havn't found a really reliable way to make a webapp go fullscreen on androidbrowser (eg. without the gigantic address bar)

[08:20:01.0000] <zewt>
google images seems to do it but I don't think I figured otu how

[08:21:00.0000] <hsivonen>
zewt: Google employees could start giving presentations where they call the Android default browser a "boat anchor browser" :-)

[08:44:00.0000] <gsnedders>
hsivonen: http://www.dailytech.com/88+Serious+Security+Bugs+Identified+in+Android+22+Froyo/article20060.htm

[08:50:00.0000] <smaug____>
<meta http-equiv="X-UA-Compatible" content="IE=8" /> mean that the web site requires IE8 mode, right?

[08:50:01.0000] <Ms2ger>
Looks like it

[08:53:00.0000] <Cradam>
smaug____: and why would you use it rather than just getting IE8 portable

[08:53:01.0000] <smaug____>
I'm not using it

[08:53:02.0000] <smaug____>
a web page is using it, and it would apparently actually break without it

[08:54:00.0000] <Cradam>
smaug____: check what it looks like with it turned off with your dev tools

[08:54:01.0000] <Cradam>
and report whether it breaks

[08:57:00.0000] <hsivonen>
smaug____: well, if you see that, you don't really know if it really requires the IE8 mode or if would work in IE9 mode, too

[08:57:01.0000] <Cradam>
hsivonen: or you can press f12 and turn it off

[08:59:00.0000] <smaug____>
hsivonen: well, in this case I assume it would break in IE9 mode. The problem is what HTMLElement.prototype.onmouseenter = function() {} does

[08:59:01.0000] <smaug____>
Gecko and IE9 throws exception per spec

[09:00:00.0000] <smaug____>
but the web page doesn't expect that

[09:12:00.0000] <hsivonen>
unsuprisingly, the Netscape bookmark format doesn't adhere to HTML vocabulary design patterns

[09:13:00.0000] <hsivonen>
there's a boolean attribute that takes the value "true"

[09:13:01.0000] <hsivonen>
there are also attribute names with underscores in them

[09:16:00.0000] <timeless>
hsivonen: Cable boxes are more exciting for Updates than TVs :)

[09:16:01.0000] <timeless>
at least TVs have a UI

[09:16:02.0000] <timeless>
but in general, security updates on embedded devices are a disaster

[09:16:03.0000] <timeless>
odds generally are that they don't secure the transport

[09:16:04.0000] <timeless>
and do a bad job of validating the update package

[09:17:00.0000] <timeless>
and yes, it's like Windows 9x, where you probably will have a better chance of being rooted before you can get your box updated :)

[09:42:00.0000] <JonathanNeal>
mornin'

[09:49:00.0000] <JonathanNeal>
Would anyone be interested in helping me edit diveintohtml5 for accuracy with present technologies?

[10:00:00.0000] <timeless>
define edit?

[10:00:01.0000] <timeless>
i'm slightly willing to review documents that are less than 3 screens tall

[10:00:02.0000] <timeless>
(roughly under 2 printed pages?)

[10:03:00.0000] <JonathanNeal>
Well, if you could review some of the wording at http://diveinto.org/html5/ anywhere you please as little or as much as you please, it would be greatly appreciated.

[10:03:01.0000] <timeless>
it's easier for me to review in response to a specific request

[10:04:00.0000] <timeless>
so, i'll review the literal page you linked, you poke me on Tuesday for another page

[10:04:01.0000] <timeless>
ok? :)

[10:06:00.0000] <timeless>
actually, that page is too bland :)

[10:06:01.0000] <timeless>
http://www.diveinto.org/html5/introduction.html

[10:06:02.0000] <timeless>
> But you can detect support for individual features, like canvas, video, or geolocation.

[10:06:03.0000] <timeless>
offhand, i think you /might/ want s/or/and/

[10:06:04.0000] <timeless>
> That’s an important part of it, but it’s not the whole story.

[10:06:05.0000] <timeless>
I personally do s/it's not/it isn't/g

[10:07:00.0000] <timeless>
> The HTML5 specification also defines how those angle brackets interact with JavaScript, through the Document Object Model (DOM).

[10:07:01.0000] <timeless>
i'm not sure about the <comma> there, i believe it's valid both ways, but i wonder if it's better without it

[10:08:00.0000] <timeless>
> Even Microsoft — rarely known for blazing the trail of standards support — will be supporting most HTML5 features in the upcoming Internet Explorer 9.

[10:08:01.0000] <timeless>
IE9 shipped, so that `will be` needs to be redone

[10:09:00.0000] <AryehGregor>
What happened to diveintohtml5.org?

[10:09:01.0000] <timeless>
Mark disappeared from the face of the earth iiuc

[10:09:02.0000] <timeless>
> HTML5 features like geolocation (Chapter 6) and video (Chapter 5) were first provided by browser plugins like Gears or Flash.

[10:09:03.0000] <timeless>
s/or/and/

[10:09:04.0000] <AryehGregor>
Really?  Does anyone know the circumstances?

[10:10:00.0000] <timeless>
i don't, but there are some places that talked about it

[10:10:01.0000] <timeless>
i didn't spend the time reading it, i just filed it away as "i should remember that"

[10:10:02.0000] <timeless>
i'm not sure if it was the earth or the digital earth fwiw

[10:11:00.0000] <AryehGregor>
http://meyerweb.com/eric/thoughts/2011/10/04/searching-for-mark-pilgrim/

[10:12:00.0000] <Cradam>
timeless: mind making your speech easier to read

[10:12:01.0000] <annevk>
is he no longer working at Google?

[10:13:00.0000] <timeless>
Cradam: sorry, please clarify?

[10:13:01.0000] <timeless>
(suggestions welcome)

[10:13:02.0000] <timeless>
... i tend to write using w3 style scribe regexps (s///), which actually mean something to a scribe.pl script

[10:14:00.0000] <timeless>
they tend to be easier than diff -u output :)

[10:14:01.0000] <timeless>
AryehGregor: ok, thanks for making me read that :)

[10:15:00.0000] <timeless>
JonathanNeal: anyway, that's as much time as i can allocate today

[10:15:01.0000] <timeless>
poke me Tuesday w/ another page

[10:18:00.0000] <JonathanNeal>
thanks timeless

[10:22:00.0000] <Cradam>
timeless: yes well we kinda don't want to read regexps

[10:23:00.0000] <AryehGregor>
Cradam, some of us are accustomed to it.

[10:24:00.0000] <timeless>
i have a couple of editing styles, i can switch to one of the others

[10:24:01.0000] <JonathanNeal>
So, is it "HTML 4" and "HTML5"?  What's with the sometimes space?

[10:24:02.0000] <timeless>
i believe so

[10:24:03.0000] <timeless>
google: HTML4 yields About 9,800,000 results (0.17 seconds)

[10:25:00.0000] <timeless>
google: "HTML 4" yields About 15,000,000 results (0.19 seconds)

[10:25:01.0000] <timeless>
I'm not sure where blame lies for the change

[10:25:02.0000] <miketaylr>
are we on "H:TML" or "HTML LS™" now?

[10:25:03.0000] <timeless>
it's possible that it's the Media

[10:25:04.0000] <timeless>
miketaylr: *sigh*, i'm sure i should recognize those references, but i don't

[10:25:05.0000] <Cradam>
i type HTML5 because it is more of a name than a version

[10:26:00.0000] <miketaylr>
timeless: oh latter is living standard, former is... i may have just made it up

[10:26:01.0000] <timeless>
yeah, i think part of it is that "HTML 4" really referenced the "HTML 4" specification

[10:26:02.0000] <Cradam>
HTML LS sounds cool

[10:26:03.0000] <timeless>
/me has seen : notation *somewhere*

[10:27:00.0000] <miketaylr>
/me recalls something as well but forgets

[10:28:00.0000] <JonathanNeal>
timeless: that was great, I made all the changes you mentioned

[10:28:01.0000] <JonathanNeal>
minus the or/and for around "browsers already support" where there wasn't an "or" to replace.

[10:29:00.0000] <timeless>
sorry, what's "browsers already support"? which line of context failed?

[10:31:00.0000] <AryehGregor>
Is there some way to get the time when the page has been fully laid out and is actually interactive?

[10:31:01.0000] <AryehGregor>
Programmatically.

[10:31:02.0000] <timeless>
/me thought gecko had an event for that

[10:31:03.0000] <JonathanNeal>
timeless: nevermind, I found the "or" you were referring to.

[10:31:04.0000] <timeless>
do you want an event or a timestamp?

[10:31:05.0000] <timeless>
JonathanNeal: cool

[10:32:00.0000] <AryehGregor>
Either would do.

[10:32:01.0000] <timeless>
please feel free to respond like that indicating a failure, but preferably indicating which line i quoted and the regexp i specified

[10:32:02.0000] <JonathanNeal>
Is it wrong to say "HTML4".  Should it be "HTML 4" ?

[10:32:03.0000] <timeless>
JonathanNeal: it's 3:2 in favor of the latter

[10:32:04.0000] <timeless>
since the spec is called the latter, i believe it really should be

[10:33:00.0000] <timeless>
probably a page explaining the names for HTML 3.2 / HTML 4 / HTML5 would be useful

[10:33:01.0000] <JonathanNeal>
timeless: but it's "HTML5" all together, yes?

[10:33:02.0000] <timeless>
you can stick it in an appendix

[10:33:03.0000] <timeless>
yeah

[10:33:04.0000] <JonathanNeal>
Yea.

[10:33:05.0000] <JonathanNeal>
Okay, cool.

[10:36:00.0000] <Ms2ger>
HTML LS makes me think of DOM LS

[10:36:01.0000] <timeless>
indeed

[10:36:02.0000] <timeless>
did you cry or tear your hair out?

[10:37:00.0000] <Ms2ger>
I'm used to worse than that ;)

[10:40:00.0000] <miketaylr>
oh right, i remember. wasn't there a H:TML for HTML: The Markup Language at some point?

[10:41:00.0000] <miketaylr>
oh this guy, http://www.w3.org/TR/html-markup/

[10:43:00.0000] <sicking>
jgraham: i probably misunderstood the proposal

[10:43:01.0000] <sicking>
jgraham: will look at your library

[10:43:02.0000] <Ms2ger>
Don't, unless you want to poke your eyes out :)

[10:58:00.0000] <Hixie>
JonathanNeal: it's just "HTML" :-)

[10:58:01.0000] <JonathanNeal>
Right.

[10:59:00.0000] <JonathanNeal>
Well, I was meticulous.

[10:59:01.0000] <timeless>
HTML5 is just the Media's Brand Name

[11:31:00.0000] <Cradam>
its called a buzz word timeless

[11:32:00.0000] <timeless>
s/its/it's/ ;-), sure...

[11:34:00.0000] <JonathanNeal>
:)

[11:36:00.0000] <timeless>
/me leaves

[11:36:01.0000] <timeless>
גמר חתימה טובה

[11:36:02.0000] <AryehGregor>
timeless, same to you.

[11:37:00.0000] <AryehGregor>
jgraham, so if I use innerHTML with escaping in that one place, instead of textContent 75,000 times, it drops the time until the load event from about 35s to about 7s.

[11:37:01.0000] <AryehGregor>
(in Chrome 15 dev)

[11:37:02.0000] <AryehGregor>
In Firefox 8.0a2, it drops it from around 78s to 45s.

[11:41:00.0000] <AryehGregor>
jgraham, while I agree that in general it's better to use textContent instead of doing escaping manually, it's justifiable to use less-safe techniques in cases where they provide a large enough performance increase.

[11:41:01.0000] <AryehGregor>
FWIW, if I comment out your test suite and do function test(f) {try{f()}catch(e){}} and define assert_* as no-ops, it takes like one second to run the tests.

[11:42:00.0000] <AryehGregor>
So the time it's taking is basically all the test suite, not the tests.

[11:44:00.0000] <JonathanNeal>
http://www.diveinto.org/html51/ is what I'm putting together thus far.  It's juuuuust beginning.

[12:00:00.0000] <AryehGregor>
jgraham, diff: http://pastebin.com/wbAazWRk

[12:24:00.0000] <AryehGregor>
jgraham, additional proposed change: hide results by default if there are > 1000 rows.  This reduces my real-world test-case to about 7 seconds in Chrome from 25 or so, from starting to load it until the page is usable.

[12:24:01.0000] <AryehGregor>
http://pastebin.com/YKdPRTem

[12:24:02.0000] <AryehGregor>
Of course, checking either of the boxes will freeze the tab for ten seconds or more.

[12:39:00.0000] <AryehGregor>
jgraham, I pushed another performance change that should hopefully be unobjectionable.  I'll wait for your feedback before pushing the other two.

[12:59:00.0000] <Cradam>
one thing i love, PDF

[12:59:01.0000] <Cradam>
i love read-only files :P

[12:59:02.0000] <Ms2ger>
Philip`, so your PhD is done by now?

[13:00:00.0000] <smaug____>
AryehGregor: what is taking 35s in Chrome but 78s in FF ?

[13:00:01.0000] <smaug____>
/me would like to profile that

[13:00:02.0000] <Ms2ger>
The editcommands tests, I presume

[13:03:00.0000] <smaug____>
hmm, that might involve editor. /me leaves testing to ehsan

[13:03:01.0000] <Ms2ger>
Very much so

[13:25:00.0000] <Philip`>
Ms2ger: Yep

[13:25:01.0000] <Ms2ger>
Good, then you can start looking at my bugs :)

[13:25:02.0000] <AryehGregor>
smaug____, running 26,000ish tests in jgraham's test harness.  I don't think it has anything to do with the tests themselves, it's all test harness overhead AFAICT.

[13:25:03.0000] <AryehGregor>
/me goes to dig up a stable URL for an example

[13:26:00.0000] <smaug____>
ah, it would be interesting to know what in the testharness causes that difference

[13:26:01.0000] <AryehGregor>
The exact URLs I'm using are works-in-progress, not useful for me to hand them out to anyone.

[13:26:02.0000] <smaug____>
I think I haven't profiled textContent

[13:27:00.0000] <AryehGregor>
smaug____, e.g., this takes over twice as long for me in Firefox as Chrome (will freeze Firefox briefly): http://dvcs.w3.org/hg/editing/raw-file/98671dcd5b1f/selecttest/Selection-collapse.html

[13:28:00.0000] <AryehGregor>
In that case it's less drastic, since it's only 4-5s in Chrome to start with, 9-10s in Firefox.

[13:28:01.0000] <AryehGregor>
Beware, the version of testharness.js included with that will change.  I'm in the middle of optimizing it.

[13:29:00.0000] <AryehGregor>
So if you want to profile properly, I suggest saving the page and all includes.

[13:30:00.0000] <Philip`>
Ms2ger: Hopefully :-)

[13:31:00.0000] <Philip`>
/me needs to work through a backlog of things

[13:31:01.0000] <Ms2ger>
Yeah, I believe you do ;)

[13:32:00.0000] <smaug____>
AryehGregor: well, very briefly

[13:32:01.0000] <AryehGregor>
?

[13:33:00.0000] <smaug____>
AryehGregor: that test takes like 5s here

[13:33:01.0000] <smaug____>
and the freeze is very short

[13:33:02.0000] <AryehGregor>
smaug____, I've discovered my CPUs are older and cheaper than most people around here.  :)

[13:33:03.0000] <AryehGregor>
Freezes for more like 10 seconds for me.

[13:33:04.0000] <smaug____>
my macbook is ancient

[13:33:05.0000] <AryehGregor>
Well over a minute for longer test-cases.

[13:33:06.0000] <AryehGregor>
What CPU does it have?

[13:34:00.0000] <smaug____>
(I use macbook only for profiling. For other things I want reasonable UI)

[13:34:01.0000] <smaug____>
dunno what cpu

[13:35:00.0000] <AryehGregor>
Anyway, obviously, Chrome doesn't freeze at all, except that one tab.  One of the biggest reasons I use Chrome right now.

[13:35:01.0000] <smaug____>
2Ghz core 2 duo

[13:36:00.0000] <AryehGregor>
I'm using a 2.6 GHz AMD 64 X2.  So it's unsurprising that a Core 2 Duo is faster even at a slower clock speed, but a factor of two seems excessive.

[13:36:01.0000] <AryehGregor>
Oh well.

[13:38:00.0000] <smaug____>
bah, Shark doesn't work

[13:38:01.0000] <AryehGregor>
What's Shark?

[13:39:00.0000] <smaug____>
the profiler on OSX

[13:42:00.0000] <AryehGregor>
Ah

[13:42:01.0000] <AryehGregor>
.

[14:27:00.0000] <AryehGregor>
jgraham, so with my additional two patches applied, Chrome seems to be spending most of its time on a) actually running the test content and b) doing hard-to-optimize-further things like doing the giant innerHTML set, and make_message/format_value.

[14:28:00.0000] <AryehGregor>
(I could probably optimize make_message/format_value some, but it's only like 10% of the profile at this point, so it's not really worth it.)

[14:28:01.0000] <AryehGregor>
I.e., I don't see any really low-hanging optimizations at that point.

[14:28:02.0000] <AryehGregor>
Firefox is similar, but seems to do a bit worse -- it takes much longer on ancestor_windows for whatever reason, and maybe some others.  Firebug's profiling is worse than Web Inspector's, though, so not sure.

[14:30:00.0000] <AryehGregor>
Well, let me correct that: I bet I could still massively optimize layout.  But I don't have good tools for that.

[14:36:00.0000] <AryehGregor>
Hmm . . . it looks like if I defer layout, it takes much longer than if I do it right away.

[14:37:00.0000] <AryehGregor>
Probably the "add a bunch of consecutive visible nodes to DOM" case is much more optimized than the "remove display: none from a bunch of existing nodes".

[14:37:01.0000] <AryehGregor>
So perhaps we don't want that patch.

[14:38:00.0000] <AryehGregor>
/me tries to think what could possibly speed up layout here, but has no idea, since he doesn't know how layout works at all

[14:38:01.0000] <AryehGregor>
Other than having fewer things to lay out, naturally.

[14:54:00.0000] <AryehGregor>
jgraham, consider my second patch (hide results by default if there are >1000 tests) retracted.  It seems to do more harm than good.

[14:55:00.0000] <AryehGregor>
The innerHTML one still stands, though.

[15:19:00.0000] <annevk>
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0131.html

[15:19:01.0000] <annevk>
/me is somewhat surprised

[15:36:00.0000] <AryehGregor>
/me is only moderately surprised

[15:36:01.0000] <AryehGregor>
mpilgrim is a perennially surprising person.

[15:37:00.0000] <AryehGregor>
So it tends to dull over time.

[15:44:00.0000] <jgraham>
AryehGregor: Sigh. If we must have innerHTML stuff can we at least have a single escaping function

[15:50:00.0000] <annevk>
Hixie, you are not defining what happens when you set an event handler that is already non-null?

[15:51:00.0000] <annevk>
Hixie, or for that matter, what happens when you set a non-null event handler to null

[15:51:01.0000] <Hixie>
nothing happens (other than it gettings its new value)

[15:51:02.0000] <Hixie>
getting

[15:52:00.0000] <Hixie>
i can say that if you like

[15:52:01.0000] <annevk>
the event listeners associated with the EventTarget surely change in some way?

[15:53:00.0000] <Hixie>
no

[15:54:00.0000] <Hixie>
all that changes is the value of the event handler

[15:54:01.0000] <Hixie>
(which i think is already defined)

[15:54:02.0000] <Hixie>
(but i can check in a sec)

[15:54:03.0000] <Hixie>
the event listener itself is just a small anonymous function that calls the event handler if it's not null

[15:54:04.0000] <Hixie>
all event listeners that have ever been set to a non-null value have the same one

[15:54:05.0000] <Hixie>
the same anonymous function, i mean

[15:55:00.0000] <annevk>
oh interesting

[15:56:00.0000] <annevk>
I wonder if that's exposed in any way

[15:56:01.0000] <Hixie>
if it wasn't done that way "return false" wouldn't work

[16:09:00.0000] <Hixie>
annevk: what does "a Function object" mean in DOM Core?

[16:09:01.0000] <Hixie>
a JS Function object?

[16:09:02.0000] <Hixie>
or an object implementing the HTML spec's Function interface?

[16:11:00.0000] <Hixie>
and is the callback this value for addEventListener() really the target, not the currentTarget?

[16:11:01.0000] <Hixie>
for event handlers it's the currentTarget, right?

[16:12:00.0000] <annevk>
yeah, ECMAScript

[16:12:01.0000] <smaug____>
callback this value must be currentTarget

[16:15:00.0000] <smaug____>
(well, of course not if callback is actually an object, not a function)

[16:16:00.0000] <annevk>
smaug____, thanks fixed

[16:16:01.0000] <annevk>
Hixie, I wasn't sure how to mark up Function

[16:16:02.0000] <Hixie>
yeah

[16:17:00.0000] <annevk>
Hixie, it's currentTarget for both apparently, didn't test properly :(

[16:17:01.0000] <Hixie>
k

[16:17:02.0000] <annevk>
but the spec is fixed now

[16:19:00.0000] <annevk>
oops, bedtime, ttyl

[16:21:00.0000] <michaelw>
if a script element which has async or defer set is removed from the document tree *before* the script actually run, should it still run eventually?

[16:22:00.0000] <Hixie>
i believe the answer is no

[16:22:01.0000] <Hixie>
wait

[16:22:02.0000] <michaelw>
anything else would've raised more questions :)

[16:22:03.0000] <Hixie>
it depends on whether the element was inserted by the parser or not

[16:23:00.0000] <Hixie>
see a Function object

[16:23:01.0000] <Hixie>
er

[16:23:02.0000] <Hixie>
see http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block

[16:23:03.0000] <michaelw>
/me looks

[16:25:00.0000] <Hixie>
annevk: dom core doesn't pass the Event object to the listener!

[16:37:00.0000] <michaelw>
Hixie: hmm, I don't see it in the section you referenced, but in the section directly above (in particular, step 15), I could read it that way, because the defer scripts go to the "list of scripts that will execute when the document has finished parsing" (and async scripts to the "set of scripts that will execute ASAP")

[16:39:00.0000] <michaelw>
however, fun starts if a defer script is in that lists, and the document is blown away and a new one is created (which I understand is possible)...

[16:54:00.0000] <Hixie>
michaelw: if the document is blown away, the list is never used, is it?

[16:54:01.0000] <Hixie>
i don't recall exactly where the list is used

[16:54:02.0000] <Hixie>
in the parser is one place

[16:54:03.0000] <Hixie>
i think in the script section is the other, there's some text somewhere that talks about it

[16:54:04.0000] <Hixie>
this particular part of hte spec is one of the most complicated aspects of the web platform, fwiw

[16:58:00.0000] <michaelw>
Hixie: even for the case that a script wants to remove everything from a document, there is no way to avoid executing the (then potentially unneeded) async and defer scripts

[16:58:01.0000] <michaelw>
(by everything I mean all nodes)


2011-10-08
[17:25:00.0000] <danbeam>
anybody know if there's a specified way to remove a branch of the DOM tree from the tab order?

[17:26:00.0000] <smaug____>
removeChild

[17:26:01.0000] <smaug____>
(I guess you mean something else)

[17:29:00.0000] <Hixie>
michaelw: oh well you can just put an if statement at the top of the script and set a flag that it checks to decide to not bother :-)

[17:31:00.0000] <danbeam>
smaug____: no, from the tab order, not the DOM

[17:31:01.0000] <danbeam>
smaug____: i.e. tabindex="-1" works hiearchically

[17:32:00.0000] <danbeam>
I've always found a pain to have to remove every focusable element from the tab order manually rather than just set an indicator on an ancestor

[17:38:00.0000] <smaug____>
danbeam: you really want only remove tab-to-focus, not focus-using-mouse ?

[17:46:00.0000] <danbeam>
smaug____: tab focus, yeah

[00:23:00.0000] <erlehmann>
since most of you are probably older than me (23): how often do amok deletes like the one of mark pilgrim happen in general?

[07:09:00.0000] <Ms2ger>
Philip`, yt?

[09:21:00.0000] <Philip`>
Ms2ger: Yes

[09:22:00.0000] <Ms2ger>
Philip`, could you have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=407107#c1?

[09:25:00.0000] <Ms2ger>
Anyway, I'm off for today; please dump your answer in the logs :)

[09:39:00.0000] <Philip`>
Ms2ger: Replied on bug

[16:11:00.0000] <annevk>
I really think we should consider restricting the wiki similarly to the blog

[16:11:01.0000] <annevk>
or at least put some restrictions on new users and nuke users that haven't contributed

[16:11:02.0000] <annevk>
sort of feels like it's getting out of control, even though I somewhat keep up with the spam

[16:59:00.0000] <smaug____>
/me kicks tryserver


2011-10-09
[17:00:00.0000] <smaug____>
oops, wrong channel

[03:52:00.0000] <annevk>
lol http://www.youtube.com/watch?v=dK60hDNuTDo

[12:02:00.0000] <smaug____>
/me ponders whether to go to tpac...


2011-10-10
[18:56:00.0000] <milan>
hello

[02:11:00.0000] <jgraham>
http://www.dartlang.org/

[02:12:00.0000] <jgraham>
"To run this code please use Chrome, Safari or Firefox (or, try anyway). IE9 support is coming soon."

[02:12:01.0000] <jgraham>
Thanks Google

[02:25:00.0000] <hsivonen>
jgraham: what happened when trying to run it in Opera?

[02:25:01.0000] <hsivonen>
jgraham: do they not test in Opera or do they make it break in Opera?

[02:25:02.0000] <hsivonen>
either way is uncool

[02:26:00.0000] <jgraham>
hsivonen: I am told that it worked for other people but not for me

[02:27:00.0000] <hsivonen>
I wonder if they ever considered sticking Dalvik into Chrome and reviving the Java DOM bindings

[02:28:00.0000] <hsivonen>
is there an explanation that says how Dart makes things better than using Java with GWT?

[02:29:00.0000] <hsivonen>
As a total knee-jerk reaction, having num as a data type instead of int seems pointless to me

[02:29:01.0000] <hsivonen>
(I didn't actually look up what num means.)

[02:38:00.0000] <Philip`>
hsivonen: "Although you might expect int and double to be primitive types, they're actually interfaces that extend the num interface. This means that int and double variables are also nums."

[02:38:01.0000] <Philip`>
so it doesn't sound like "instead of int"

[02:45:00.0000] <hsivonen>
Philip`: hmmkay.

[02:45:01.0000] <hsivonen>
maybe that makes sense

[02:46:00.0000] <hsivonen>
I'm generally suspicious of something that looks like hiding low-level numbers

[02:46:01.0000] <hsivonen>
maybe this isn't that sort of thing and only looks like it

[02:54:00.0000] <Philip`>
hsivonen: I think it sort of looks like trying to be compatible with JS (so it's easier to learn the language and port code) by having a generic num type, while also letting people write better-performing code for an insufficiently clever compiler by explicitly annotating the types in integer-only code

[02:57:00.0000] <Philip`>
(Maybe also trying to be compatible with Java, to help Java programmers and Java code)

[04:18:00.0000] <Philip`>
Oh, actually per http://www.dartlang.org/articles/optional-types/ it seems the whole type system (including double vs int vs num) is entirely pointless at runtime

[04:23:00.0000] <hsivonen>
Philip`: whoa. what (if anything) is supposed to make Dart better for JIT perf than JS?

[04:29:00.0000] <Cradam>
does anyone have a link to a good css normalise file?

[04:29:01.0000] <divya>
?g normalize css @ Cradam

[04:29:02.0000] <divya>
oops no bot

[04:29:03.0000] <Cradam>
ok so you are saying google it

[04:29:04.0000] <divya>
http://necolas.github.com/normalize.css/

[04:31:00.0000] <Cradam>
eugh so many comments

[04:31:01.0000] <Philip`>
hsivonen: According to someone in #jsapi, the lack of prototypes might help

[04:32:00.0000] <Philip`>
(It looks like all objects have to belong to some statically-defined class)

[04:35:00.0000] <hsivonen>
Philip`: ok

[04:36:00.0000] <hsivonen>
Philip`: I find it strange that integers in Dart are bignums instead of being close-to-hardware integers that overflow

[04:39:00.0000] <hsivonen>
Are integers in Python overflowing or bignums?

[04:39:01.0000] <Cradam>
ehh the person also uses spaces rather than tabs

[04:39:02.0000] <Cradam>
this guy doesn't know much about optimisation by the looks of it

[04:40:00.0000] <hsivonen>
Cradam: does tabs vs. spaces matter after gzip?

[04:40:01.0000] <Cradam>
a properly minified file can be faster than gzip

[04:41:00.0000] <Cradam>
because with gzip the browser has to uncompresss the file

[04:41:01.0000] <divya>
hahaha Cradam really is that all you can find?

[04:41:02.0000] <divya>
to critize that is

[04:41:03.0000] <Cradam>
divya: well there are other things that i think are more minor

[04:42:00.0000] <divya>
i would think what you mentioned are already very minor

[04:42:01.0000] <jgraham>
hsivonen: They are automatically coerced to a larger type if they would overflow

[04:43:00.0000] <hsivonen>
jgraham: ok

[04:43:01.0000] <necolas>
cradam, where's your data to backup that claim about minify/gzip?

[04:43:02.0000] <Cradam>
divya: well i would never employ anyone who used spaces over tabs

[04:43:03.0000] <necolas>
Cradam: lol

[04:43:04.0000] <divya>
Cradam: hahahahha

[04:43:05.0000] <divya>
srry you cant use html5boilerplate then

[04:44:00.0000] <Cradam>
i prefer to minify stuff myself rather than let an algorithm do it

[04:45:00.0000] <hsivonen>
whoa. there's a lot of boilerplate in html5boilerplate these days

[04:45:01.0000] <divya>
hsivonen: elaborate?

[04:45:02.0000] <Cradam>
i can use it, i choose not to

[04:46:00.0000] <hsivonen>
divya: jQuery, Modernizr, Google Analytics, Chrome Frame stuff

[04:46:01.0000] <divya>
hsivonen: yeah all defaults people use.

[04:47:00.0000] <Cradam>
lol you seriously use chrome frame

[04:47:01.0000] <necolas>
hsivonen: delete key friendly

[04:47:02.0000] <divya>
we removed a lot of others

[04:47:03.0000] <hsivonen>
necolas: I'm not complaining. just suprprised at the size of the boilerplate

[04:47:04.0000] <necolas>
it's not that big tbh

[04:47:05.0000] <divya>
ah but hsivonen analytics is hardly more than a line.

[04:47:06.0000] <Cradam>
chrome frame requires the user to have a plugin to view your page - NO THANKS

[04:48:00.0000] <Cradam>
*=

[04:48:01.0000] <necolas>
doesnt require

[04:48:02.0000] <hsivonen>
divya: analytics seems to be 6 lines plus 1 line of comment :-)

[04:48:03.0000] <Cradam>
necolas: oh, elaborate

[04:48:04.0000] <tomasf>
could be nice if html5boiler had a checkbox form that let you choose what features to include

[04:49:00.0000] <necolas>
tomasf: it does

[04:49:01.0000] <divya>
tomasf: there is http://initializr.com

[04:49:02.0000] <divya>
or use the custom form

[04:49:03.0000] <Cradam>
tomasf: yes thats what backspace is for

[04:49:04.0000] <tomasf>
divya: oh, nice

[04:50:00.0000] <necolas>
re chrome-frame, pretty sure we're gonna ditch the script (which sucks) in favour of a prompt.

[04:52:00.0000] <divya>
yep

[04:52:01.0000] <divya>
just need to implement it

[04:56:00.0000] <Cradam>
what i want is not a prompt to install chrome frame but just a check to see if it is installed and if it is then use it

[04:57:00.0000] <Cradam>
oh

[04:58:00.0000] <necolas>
yeah we've always had that

[04:58:01.0000] <Cradam>
thats the default action

[05:12:00.0000] <Cradam>
hmm thats a shame, chrome frame doesn't change IE's css stuff

[05:15:00.0000] <necolas>
Cradam: really?

[05:16:00.0000] <Cradam>
well it didn't give me border-radius and box-shadow so i assume not

[05:18:00.0000] <necolas>
ah yes, seems so

[05:20:00.0000] <divya>
ryanseddon: ^ whats your view?

[05:33:00.0000] <smaug____>
hmm, so why do they call it Dart and not Java-- (or perhaps Java++)

[05:34:00.0000] <smaug____>
(and I don't still understand the reasons for Dart)

[05:43:00.0000] <jgraham>
They should have called it WebJava to annoy annevk5

[05:45:00.0000] <Philip`>
/me assumed the reasons were that Google developers like Java and classes for large-scale development, and V8 developers don't like JavaScript, so they made up their own language for their own goals

[05:45:01.0000] <Philip`>
(Also, designing languages is always fun)

[05:48:00.0000] <smaug____>
that is true, designing languages is fun

[05:49:00.0000] <Philip`>
If "hello world" programs turn into http://try-dart-lang.appspot.com/b/030iCprzxiLHwzM0fYRey0Cw5x4?cjY0NzIuMzUzODI0ODA3NDYxODYwNTUx for users of all browsers other than Chrome and cause terrible performance, then that's just a bonus

[05:57:00.0000] <hsivonen>
hmm. looks like the ES5 spec doesn't define "object literals" using the term object literal

[05:58:00.0000] <jgraham>
"Object Initialiser"

[05:58:01.0000] <hsivonen>
jgraham: thanks

[05:59:00.0000] <hsivonen>
and what's the deal with ES5 not using en-US as the spec language?

[05:59:01.0000] <jgraham>
What does it use? I thoughtAllen was a en-USE speaker. But maybe ECMA has funky rules

[06:00:00.0000] <hsivonen>
jgraham: it uses something that says initialiser instead of initializer

[06:00:01.0000] <hsivonen>
could be an artifact of the E in ECMA

[06:01:00.0000] <jgraham>
http://www.ecma-international.org/memento/EcmaRules.htm

[06:02:00.0000] <hsivonen>
HTML and CSS have made me weird in the way that when I write JS, I look at the ES5 spec

[06:02:01.0000] <hsivonen>
jgraham: ok.

[06:04:00.0000] <hsivonen>
smaug____: I don't really see why the delta between JS and Dart justifies a new language

[06:33:00.0000] <adtykfhyipoh>
Hello

[06:34:00.0000] <adtykfhyipoh>
Hey everyone, I am new to whatwg. Call me [random letters]

[06:34:01.0000] <tomasf>
Hi dforyebfdaé

[06:35:00.0000] <Kawner>
yo

[06:36:00.0000] <adtykfhyipoh>
sup tomasf

[06:37:00.0000] <Philip`>
Hello סמשה

[06:37:01.0000] <adtykfhyipoh>
Hey Phill when do people start joining this thing?

[06:37:02.0000] <adtykfhyipoh>
I am itching for conversation

[06:37:03.0000] <adtykfhyipoh>
and I need help with a web app :(

[06:38:00.0000] <Philip`>
People are already here but have nothing in particular to talk about

[06:38:01.0000] <adtykfhyipoh>
ok I've got one

[06:38:02.0000] <adtykfhyipoh>
who is here and how do you tell

[06:38:03.0000] <Philip`>
Your IRC client might have a list of names down the side of the screen

[06:39:00.0000] <adtykfhyipoh>
ok let's discuss this forum topic

[06:39:01.0000] <adtykfhyipoh>
http://forums.whatwg.org/bb3/viewtopic.php?f=10&t=4735&p=7482#p7482

[06:40:00.0000] <adtykfhyipoh>
I need some help

[06:41:00.0000] <Philip`>
I think you want the loop to be more like "for (i=1; i<=castles.x.length; i++){"

[06:42:00.0000] <Philip`>
Oops

[06:42:01.0000] <Philip`>
I think you want the loop to be more like "for (i=1; i<castles.x.length; i++){"

[06:42:02.0000] <Philip`>
("<" instead of "==")

[06:42:03.0000] <adtykfhyipoh>
ok

[06:42:04.0000] <adtykfhyipoh>
I will give that a shot

[06:43:00.0000] <tomasf>
and unless you want to skip the first entry, you may want i=0

[06:44:00.0000] <adtykfhyipoh>
It worked! Thanks man!

[06:44:01.0000] <adtykfhyipoh>
It totally works thanks a lot

[06:45:00.0000] <adtykfhyipoh>
I literally joined last night but I will try to be a big help here

[06:46:00.0000] <adtykfhyipoh>
(I joined because I got kicked out of stackoverflow for asking to many dumb questions)

[06:49:00.0000] <Philip`>
One option would be to read some kind of book/tutorial/etc on general introductory JavaScript programming, since that should resolve a lot of dumb questions more efficiently than asking about them one by one :-)

[06:50:00.0000] <adtykfhyipoh>
well actually I really expierienced, just new to canvas.

[06:50:01.0000] <Philip`>
/me doesn't know anything specific to recommend, though

[06:50:02.0000] <adtykfhyipoh>
I have been literally been doing javascript since I was nine.

[06:50:03.0000] <Philip`>
Your question about arrays and for loops is just general JS, nothing to do with canvas :-)

[06:51:00.0000] <adtykfhyipoh>
actually, my question was not about arrays it was about drawing on the canvas from an array.

[06:51:01.0000] <adtykfhyipoh>
also I haven't used many  arrays anyways.

[06:52:00.0000] <adtykfhyipoh>
I am a php guy most of the time

[08:59:00.0000] <jgraham>
What was the thing that people didn't like about postMessage(msg, ports, targetOrigin)?

[09:32:00.0000] <adtykfhyipoh>
I'm back

[09:32:01.0000] <adtykfhyipoh>
lol

[09:34:00.0000] <adtykfhyipoh>
anybody here?

[09:35:00.0000] <adtykfhyipoh>
sup jarek

[09:36:00.0000] <jarek>
hi

[09:36:01.0000] <_bga>
adtykfhyipoh any questions or comments about specs?

[09:37:00.0000] <_bga>
plz dont flood

[09:37:01.0000] <adtykfhyipoh>
what do you mean flood? I am new to IRC in general.

[09:37:02.0000] <adtykfhyipoh>
btw I answer to [random letters] so you don't have to copy my name.

[09:38:00.0000] <_bga>
adtykfhyipoh its wrong channel for irc newbies

[09:38:01.0000] <adtykfhyipoh>
ok then I take it back I am an IRC pro

[09:39:00.0000] <adtykfhyipoh>
Do you just sit here and wait for someone to ask a question without conversation? That is not like any of the other channels I have visited

[09:46:00.0000] <wilhelm>
Yes.

[09:47:00.0000] <webben>
adtykfhyipoh: "Do you just sit here and wait for someone to ask a question without conversation?" Yes. (Actually this is how most of the channels on freenode work.)

[09:47:01.0000] <zewt>
people talk when people talk

[09:49:00.0000] <adtykfhyipoh>
ok then I guess I will join you.

[09:50:00.0000] <adtykfhyipoh>
I just joined WHATWG and I am hoping to contribute to the community a lot. I know a good lot about HTML5 and Canvas game development.

[10:03:00.0000] <dglazkov>
good morning, Whatwg!

[10:03:01.0000] <jgraham>
Apart from dglazkov. He brings unwelcome daily cheer regardless of whether anyone wants it

[10:03:02.0000] <divya>
HI dglazkov!!

[10:03:03.0000] <divya>
hahahahahh

[10:03:04.0000] <divya>
UNWELCOME!

[10:03:05.0000] <divya>
</3

[10:04:00.0000] <dglazkov>
/me spreads cheer contagion on jgraham 

[10:05:00.0000] <jgraham>
Yuck

[10:05:01.0000] <dglazkov>
:P

[10:27:00.0000] <adtykfhyipoh>
Hey guys I've got a quick question

[10:28:00.0000] <adtykfhyipoh>
dbaron I've got a question

[10:28:01.0000] <adtykfhyipoh>
can you answer?

[10:28:02.0000] <Ms2ger>
Not if you don't ask it

[10:28:03.0000] <divya>
hahahha

[10:28:04.0000] <dbaron>
adtykfhyipoh, how can I tell if I don't know what the question is?

[10:29:00.0000] <adtykfhyipoh>
well I will tell you

[10:29:01.0000] <adtykfhyipoh>
I have a function in JavaScript, and said function needs to stop if a condition is true. How could I achieve this?

[10:29:02.0000] <adtykfhyipoh>
break; does not work because it is in a loop and that will stop the loop.

[10:30:00.0000] <Ms2ger>
Can you show code?

[10:30:01.0000] <dbaron>
return

[10:30:02.0000] <adtykfhyipoh>
return? I will try that

[10:31:00.0000] <adtykfhyipoh>
ok thanks return worked.

[10:31:01.0000] <adtykfhyipoh>
you guys rule

[14:49:00.0000] <michaelw>
Hixie: at <http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-handler-event-type>, there's an empty item in the event handler processing algorithm (step 4)

[14:57:00.0000] <TabAtkins>
Hixie: Did you ever come up with a better name than "superior parent"

[14:57:01.0000] <TabAtkins>
?

[15:56:00.0000] <heycam>
morning

[16:08:00.0000] <sicking>
heycam!

[16:09:00.0000] <Hixie>
heycam! you have returned!

[16:09:01.0000] <Hixie>
heycam: let me know when you're caught up with mail and so on, i have some questions for you :-)

[16:11:00.0000] <heycam>
Hixie, ok, gimme a day :)

[16:11:01.0000] <Hixie>
np!

[16:13:00.0000] <heycam>
/me starts remote working today, hopes it works out for him :)

[16:19:00.0000] <Hixie>
wait, tpac costs money again this year? wtf

[16:20:00.0000] <Hixie>
i don't even want to attend any meetings

[16:38:00.0000] <Hixie>
sicking: do you know if anyone at mozilla is looking at <iframe sandbox>?

[16:39:00.0000] <sicking>
Hixie: yes, Ian Melven expressed interest in working on it

[16:39:01.0000] <sicking>
Hixie: no ETA though, he's just starting

[16:39:02.0000] <sicking>
Hixie: on that topic though, the fallback story for sandboxes seem to be terrible

[16:40:00.0000] <Hixie>
yeah that's what i wanted to ask about

[16:40:01.0000] <Hixie>
the spec uses text/html-sandboxed currently

[16:40:02.0000] <Hixie>
apparently this fails in some old IEs that sniff like crazy

[16:40:03.0000] <Hixie>
i was wondering if anyone at mozilla had any better ideas

[16:41:00.0000] <Hixie>
(by "fails" i mean "gets interpreted as text/html so you can XSS someone by getting them to visit the framed content directly")

[16:45:00.0000] <jwalden>
\o/

[16:50:00.0000] <sicking>
Hixie: does the @sandbox attribute only work with text/html-sandboxed?

[16:50:01.0000] <sicking>
Hixie: i thought it was intended to work with plain "text/html" too?

[16:50:02.0000] <Hixie>
it works for both; there's use cases for sandboxing stuff that is safe to access directly

[16:50:03.0000] <Hixie>
(e.g. anything cross-domain)

[16:51:00.0000] <sicking>
Hixie: but then what's the purpose of the sandbox attribute in that use case?

[16:51:01.0000] <Hixie>
to e.g. prevent popups

[16:51:02.0000] <Hixie>
it's pretty flexible, you can do quite a lot with it

[16:52:00.0000] <sicking>
my concern is that it's *really* easy to write markup that looks fine, until you start thinking about browsers that don't implement @sandbox

[16:53:00.0000] <Hixie>
yeah, but there's so many use cases where sandbox="" is just extra defense in depth that it doesn't really make sense to make it not work at all in legacy UAs

[16:53:01.0000] <sicking>
not sure I agree, i'd prefer if websites in those cases detected that sandbox wasn't implemented and did the fallback themselves

[16:54:00.0000] <sicking>
i'm fine with having fallback for the less sensitive cases

[16:54:01.0000] <sicking>
but for the more sensitive ones, like disable scripting, it seems pretty bad with the current design

[16:54:02.0000] <sicking>
one alternative i was thinking about is something like this:

[16:55:00.0000] <sicking>
<iframe src="strictly_filtered_comments.cgi?blogpostid=123" sandbox_src="comments.cgi?blogpostid=123">

[16:55:01.0000] <sicking>
or

[16:55:02.0000] <sicking>
or rather "and:"

[16:57:00.0000] <sicking>
<iframe src="strictly_filtered_comments.cgi?blogpostid=123" sandbox_src="comments.cgi?blogpostid=123" sandbox="allow-top-navigation">

[16:58:00.0000] <sicking>
where the former cgi could do more agressive filtering of any HTML contents for example

[16:58:01.0000] <erlehmann>
sicking, can you explain why „strictly_filtered_comments“ would not be in both?

[16:58:02.0000] <erlehmann>
i seem to be missing something here.

[16:59:00.0000] <sicking>
erlehmann: say that you want to allow comments to use some basic HTML markup, like changing colors and fonts

[16:59:01.0000] <sicking>
erlehmann: but you don't trust that you'll get all the HTML filtering correctly


2011-10-11
[17:00:00.0000] <sicking>
erlehmann: so you do what you think is correct in comments.cgi, but remove *all* markup in strictly_filtered_comments.cgi

[17:00:01.0000] <erlehmann>
intredasting.

[17:00:02.0000] <sicking>
erlehmann: or say that you're hosting widgets on your site

[17:01:00.0000] <sicking>
erlehmann: you want the widgets to be able to run script

[17:01:01.0000] <erlehmann>
i'll still just use html5lib and think i am filtering absolutely, entirely correctly in that case.

[17:01:02.0000] <sicking>
erlehmann: but not if you can't sandbox them

[17:01:03.0000] <erlehmann>
that i understand.

[17:01:04.0000] <sicking>
erlehmann: then you'd let the first src filter out all scripts, but the second would be allowed to run scripts

[17:02:00.0000] <sicking>
erlehmann: if you're trusting your filtering, then would you ever need sandbox at all?

[17:02:01.0000] <sicking>
erlehmann: i.e. isn't HTML4 working fine for you?

[17:02:02.0000] <erlehmann>
still, that's not the graceful degradation i know. it is … something else. i hope i'll never need it.

[17:02:03.0000] <erlehmann>
last i checked, there was no html4lib ;)

[17:02:04.0000] <erlehmann>
but yes.

[17:03:00.0000] <sicking>
erlehmann: well then, if what exists already is good enough for you, then i think we're done here :)

[17:03:01.0000] <erlehmann>
we are. but now i understand why you did not just filter damn everything.

[17:04:00.0000] <erlehmann>
(which i, for the record, would do, if i were that unsure of my filtering capabilities.)

[17:04:01.0000] <erlehmann>
a friend made a wiki and is so paranoid, even internal functions check their assertions about the arguments.

[17:04:02.0000] <erlehmann>
that is properly paranoid.

[17:06:00.0000] <Hixie>
sicking: sure, in that use case you'd want to use something different in both cases. But most use cases will be <iframe sandbox src="something-i-think-is-safe-regardless"></iframe>

[17:06:01.0000] <Hixie>
(s/most/many/, certainly)

[17:08:00.0000] <sicking>
Hixie: then put the same url in both attributes

[17:08:01.0000] <Hixie>
sicking: as soon as we do that you're back to your original problem

[17:09:00.0000] <abarth>
the default-closed behavior is really hard to get for on-domain resources

[17:09:01.0000] <Hixie>
sicking: i.e. that it is easy to write markup that looks fine, until you start thinking about browsers that don't implement @sandbox

[17:09:02.0000] <Hixie>
how do you mean?

[17:09:03.0000] <abarth>
its really hard to host things on-domain and not have them be used against you

[17:09:04.0000] <abarth>
e.g., by Java or Flash

[17:10:00.0000] <abarth>
one thing you can do is to set a Content-Disposition: attachment

[17:10:01.0000] <abarth>
Flash will respect that

[17:10:02.0000] <abarth>
i haven't tested Flash recently

[17:10:03.0000] <abarth>
it turns out that sandbox is pretty useful even without text/html-sandbox

[17:11:00.0000] <Hixie>
well if we are assuming that anything same-domain is guaranteed to be unsandboxable when viewed directly, we might as well require that src="" be cross-origin if sandbox="" is specified

[17:11:01.0000] <Hixie>
but then that makes a lot of sandbox="" rather pointless

[17:11:02.0000] <abarth>
a very common way to use it is with an about:blank iframe

[17:11:03.0000] <abarth>
which you sandbox

[17:12:00.0000] <abarth>
and then fill up with stuff

[17:12:01.0000] <Hixie>
ok. so on the short-term, what i'm hearing is that we shoudl drop text/html-sandboxed like microsoft suggests

[17:13:00.0000] <Hixie>
and on the medium term there might be additional changes that would be useful?

[17:15:00.0000] <abarth>
in the medium term, i want to convince someone to implement seamless

[17:15:01.0000] <abarth>
;)

[17:20:00.0000] <sicking>
Hixie: and disable the ability to have same-origin sandboxes?

[17:20:01.0000] <Hixie>
that's the medium term question

[17:21:00.0000] <Hixie>
i recommend posting on the whatwg list about it

[17:21:01.0000] <sicking>
so what are the use cases when sandbox is useful? Assuming the aweful fallback in older browsers?

[17:21:02.0000] <Hixie>
(we'd have to drop allow-same-origin if we did that)

[17:22:00.0000] <Hixie>
well like i said, defense-in-depth is a huge use case

[17:22:01.0000] <sicking>
wouldn't that make it cover the same usecases as CSP then?

[17:23:00.0000] <Hixie>
CSP is far too complex for most authors who have just one domain to use, imho

[17:23:01.0000] <sicking>
CSP lets you completely disable scripting

[17:23:02.0000] <sicking>
which would seem like the main usecase for sandbox

[17:24:00.0000] <sicking>
if we're only talking about defence in depth

[17:24:01.0000] <Hixie>
i dunno that i'd say it's the main use case

[17:24:02.0000] <Hixie>
might be an important use case in the defence in depth subset of the use cases

[17:24:03.0000] <Hixie>
but then so's preventing form submission

[17:24:04.0000] <Hixie>
and disallowing frame navigation

[17:24:05.0000] <Hixie>
and blocking plugins...

[17:25:00.0000] <Hixie>
CSP is so complex that i see abarth asking about it :-P

[17:25:01.0000] <sicking>
ok, so assume a world where browsers implement CSP, convince me as a browser author what additional use cases would be covered by @sandbox

[17:26:00.0000] <abarth>
Hixie: CSP is crazy complex

[17:26:01.0000] <abarth>
its very hard for authors to use

[17:26:02.0000] <abarth>
i've been spending a bunch of time with early adopters to understand the snags they run into

[17:26:03.0000] <abarth>
sicking: oh, the use cases are really different

[17:26:04.0000] <Hixie>
sicking: if CSP was implemented and easy to use, it might obviate many use cases for same-origin sandbox=""

[17:26:05.0000] <Hixie>
sicking: though not any of the cross-origin ones

[17:27:00.0000] <abarth>
sicking: CSP is for restricting your own content.  sandbox is for restricting other people's content

[17:27:01.0000] <sicking>
abarth: i'm listening...

[17:27:02.0000] <Hixie>
sicking: but so far it does not seem that CSP is going to be easy to use, so...

[17:27:03.0000] <abarth>
sicking: here's a real example

[17:27:04.0000] <sicking>
yay

[17:27:05.0000] <abarth>
you've got a RSS feed that you've fetched via CORS

[17:28:00.0000] <abarth>
and you want to show it to the user in a nice pretty form

[17:28:01.0000] <abarth>
you send it into a sandboxed iframe

[17:28:02.0000] <abarth>
and make a nice presentation of it

[17:28:03.0000] <Hixie>
i love that microsoft's suggestion regarding what to do with the warning is just 'In section 4.8.2 "The iframe element," remove the text "Warning! It is important that the server serve the user-provided HTML using the text/html-sandboxed MIME type so that if the attacker convinces the user to visit that page directly, the page doesn't run in the context of the site's origin, which would make the user vulnerable to any attack found in the page."'

[17:28:04.0000] <abarth>
that works really well with @sandbox and isn't really doable with CSP

[17:28:05.0000] <Hixie>
they don't suggest changing it or anything, just removing it

[17:28:06.0000] <sicking>
abarth: what's the fallback story for old browsers?

[17:29:00.0000] <abarth>
in the actual case, it didn't matter because it's a browser extension that does this

[17:29:01.0000] <abarth>
in the case of a web site, you can probably have a lower fidelity rendering of the RSS feed

[17:29:02.0000] <abarth>
or take some security risks

[17:30:00.0000] <Hixie>
or wait a few years and then tell the 1% of legacy UAs that they're screwed

[17:30:01.0000] <sicking>
abarth: i'm much more interested in building features for websites than extensions

[17:30:02.0000] <abarth>
sure, i just mentioned that case

[17:30:03.0000] <abarth>
because its a place where this got used this past week

[17:31:00.0000] <sicking>
abarth: so the concern is that the RSS markup would contain onclick attributes or <script> elements

[17:32:00.0000] <sicking>
abarth: ?

[17:32:01.0000] <abarth>
the RSS feed contains HTML

[17:32:02.0000] <abarth>
e.g., the contents of the posts

[17:32:03.0000] <sicking>
right

[17:32:04.0000] <abarth>
and you don't want the content to call alert()

[17:33:00.0000] <abarth>
for example

[17:33:01.0000] <abarth>
because that's annoying

[17:33:02.0000] <sicking>
so it seems you're screwed if you inject that into a about:blank iframe

[17:33:03.0000] <abarth>
so you don't want script to run

[17:33:04.0000] <sicking>
since that can run any script

[17:33:05.0000] <abarth>
what this guy was actually doing

[17:33:06.0000] <abarth>
was using a data URL

[17:34:00.0000] <abarth>
and i advised him to just add the sandbox attribute

[17:34:01.0000] <abarth>
to his iframe

[17:34:02.0000] <abarth>
and everything worked great

[17:34:03.0000] <abarth>
he was a very happy customer :)

[17:34:04.0000] <sicking>
i don't understand how it would work great in the fallback situation

[17:34:05.0000] <sicking>
i.e. when the browser doesn't support sandbox

[17:35:00.0000] <sicking>
let me phrase it this way: it seems to me that @sandbox has such a terrible fallback story for browsers that don't support @sandbox, that I'm not sure that we'll want to implement it in firefox and thus encourage it's usage on the web

[17:35:01.0000] <abarth>
well, for example, we could just how the text of the posts

[17:35:02.0000] <abarth>
instead of the HTML formating

[17:36:00.0000] <sicking>
i think there's a word missing there?

[17:36:01.0000] <abarth>
s/how/show

[17:36:02.0000] <sicking>
ah

[17:37:00.0000] <abarth>
its seems like you could make the same argument about CSP

[17:37:01.0000] <sicking>
abarth: so the idea is that webdevelopers are responsible for checking that @sandbox is supported, and use a completely different codepath if it's not

[17:37:02.0000] <sicking>
abarth: certainly

[17:37:03.0000] <sicking>
abarth: CSP is explicitly a defence-in-depth mechanism

[17:37:04.0000] <abarth>
there are two choices

[17:37:05.0000] <abarth>
1) proceed as before and live with any additional risk

[17:37:06.0000] <sicking>
abarth: i was under the impression that @sandbox wasn't intended to be just defence-in-depth

[17:37:07.0000] <abarth>
2) check if its supported and do something else if its not

[17:38:00.0000] <sicking>
this discussion has made me more confused about whether it is or not :)

[17:38:01.0000] <abarth>
that's option (2), but option (1) exists too

[17:38:02.0000] <abarth>
well, consider the Secure attribute on cookies

[17:38:03.0000] <abarth>
is that defense in depth or is that a security measure?

[17:38:04.0000] <abarth>
what about browsers that don't support the Secure attribute?

[17:39:00.0000] <sicking>
are there any such browsers?

[17:39:01.0000] <abarth>
there were at one point in time

[17:39:02.0000] <abarth>
we'll be asking the same question about @sandbox in a few years

[17:39:03.0000] <sicking>
i'm not sure we made good decisions at that point in time :)

[17:39:04.0000] <abarth>
put another way,

[17:40:00.0000] <abarth>
what's a site supposed to do with browsers that don't support WebGL ?

[17:40:01.0000] <abarth>
use a different code path?

[17:40:02.0000] <Hixie>
sicking: sandbox="" is intended exclusively for defence in depth for now. It will eventually be usable for other things as well.

[17:40:03.0000] <abarth>
just because this is a security feature doesn't mean all the hard things about introducing new features go away

[17:40:04.0000] <sicking>
but yes, in a sense the Secure attribute is defense-in-depth. Though we know that MITM is easier than what was thought

[17:41:00.0000] <abarth>
ok, then you probably believe that every security feature is defense-in-depth

[17:41:01.0000] <Hixie>
except maybe TLS :-)

[17:42:00.0000] <Hixie>
what's teh fallback for https:// ? :-)

[17:42:01.0000] <sicking>
possibly. I'm a not huge fan of "security features" since most of them are patching mistakes of the past

[17:42:02.0000] <sicking>
but they are obviously needed

[17:43:00.0000] <Hixie>
"firefox developer not fan of security features" :-P

[17:43:01.0000] <sicking>
abarth: i'd just much rather that we fell back to a closed situation than an open situation

[17:43:02.0000] <Hixie>
sicking: falling back to a closed situation would be great, but falling back to nothing is not fallback, it's just the feature not being supported and the site being broken in old UAs

[17:44:00.0000] <sicking>
abarth: it seems very likely to me that people will do <iframe src="completely_untrusted_contents.cgi" sandbox>

[17:44:01.0000] <abarth>
i don't think there's any way to do that securely

[17:44:02.0000] <abarth>
regardless of the design

[17:44:03.0000] <Hixie>
if a site does <iframe src="completely_untrusted_contents.cgi" sandbox> they have far better problems than fallback

[17:44:04.0000] <Hixie>
even in completely compliant UAs they'll still get owned

[17:45:00.0000] <Hixie>
since you can just point a user to a page on another domain with that same iframe without sandbox=""

[17:45:01.0000] <Hixie>
and boom, you run script on the victim origin

[17:45:02.0000] <Hixie>
that was the idea behind text/html-sandboxed, which i've just removed from the spec and replaced with warnings saying to use a different origin for untrusted content

[17:49:00.0000] <sicking>
Hixie: so it seems to make sense to me to make <iframe src="same-origin/comments.cgi" sandbox="..."> refuse to load the iframe?

[17:49:01.0000] <Hixie>
would you block src="about:blank" too?

[17:50:00.0000] <sicking>
good question

[17:52:00.0000] <sicking>
i'd say no

[17:52:01.0000] <sicking>
since you can't do the thing of "use another site to navigate the user directly to the url thus avoiding the sandbox"

[17:55:00.0000] <Hixie>
sicking: if you block that then you completely prevent the use case adam brought up earlier

[17:55:01.0000] <Hixie>
sicking: of being able to generate a file on the fly that has scripting disabled

[17:55:02.0000] <sicking>
Hixie: yup

[17:56:00.0000] <Hixie>
ok so... that's bad

[17:56:01.0000] <sicking>
Hixie: you'll note that I said "no" above

[17:56:02.0000] <Hixie>
oh, sorry, i misunderstood

[17:56:03.0000] <Hixie>
i thought you meant no, it wouldn't work :-)

[17:56:04.0000] <TabAtkins>
Hixie: Random sidenote - we found a better term than "superior parent": "originating element"

[17:57:00.0000] <Hixie>
sicking: if you don't block it, then what stops someone from just redirecting the page to a same-origin url?

[17:57:01.0000] <sicking>
Hixie: redirecting about:blank?

[17:57:02.0000] <Hixie>
TabAtkins: i have no idea what either of those terms mean :-) are they xbl-related things?

[17:57:03.0000] <Hixie>
TabAtkins: "originating element" sounds like something to do with the origin policy?

[17:58:00.0000] <Hixie>
sicking: as in, you insert an <iframe sandbox> then you document.write() into it a "<meta http-equiv=refresh content=0;URL=local.html">

[17:58:01.0000] <Hixie>
but with my quotes not screwed up

[17:58:02.0000] <sicking>
Hixie: then it's a new load, so you'd block that

[17:59:00.0000] <Hixie>
ew

[17:59:01.0000] <TabAtkins>
Hixie: Dude, "superior parent" comes from css3-content, to refer to a pseudo-elements "parent".

[17:59:02.0000] <Hixie>
brb need to find power

[17:59:03.0000] <sicking>
you want different policies depending on if it's the first document or the second document to be loaded in an iframe?

[18:05:00.0000] <Hixie>
sicking: the current mechanism (not sandbox-specific) handles src="" differently than normal in-frame page loads

[18:06:00.0000] <sicking>
Hixie: huh??

[18:06:01.0000] <sicking>
Hixie: in what way?

[18:07:00.0000] <Hixie>
sicking: the src="" attribute loads go through the "process the iframe attributes" algorithm first

[18:07:01.0000] <Hixie>
sicking: the normal loads don't do anything iframe-specific

[18:08:00.0000] <sicking>
Hixie: so you can have an <iframe sandbox src="...> which contains a document that isn't sandboxed?

[18:08:01.0000] <sicking>
with proper quotes :)

[18:08:02.0000] <Hixie>
sicking: maybe i didn't understand you proposal though; are you saying that we should block any page loads that have the same origin if the browsing context's sandboxed origin browsing context flag is set?

[18:08:03.0000] <Hixie>
sicking: no

[18:08:04.0000] <Hixie>
sicking: the sandboxing is a feature of the browsing context

[18:09:00.0000] <Hixie>
TabAtkins: aaah

[18:09:01.0000] <Hixie>
TabAtkins: not sure "originating element" works since it's not necessarily an element, is it?

[18:09:02.0000] <Hixie>
TabAtkins: as someone who had forgotten what either term meant, i have to say, both terms seemed equally opaque to me just now

[18:10:00.0000] <sicking>
Hixie: the way it seems to me, we should block any same-origin loads if the browsing context is sandboxed

[18:10:01.0000] <sicking>
Hixie: or let me rephrase

[18:10:02.0000] <sicking>
Hixie: the way it seems to me, we should block any loads where the loaded document is same-origin with the parent document, if the browsing context is sandboxed

[18:14:00.0000] <Hixie>
sicking: that would block about:blank.

[18:15:00.0000] <Hixie>
(i assume by "is sandboxed" you mean specifically the case of it having the sandboxed origin browsing context flag, not all sandboxing)

[18:32:00.0000] <sicking>
Hixie: no, i meant all sandboxing, per the discussion we just had it seems that sandboxing is useless for same-origin loads

[18:33:00.0000] <sicking>
Hixie: i guess i don't consider about:blank as a "load". But if it is considered a load then add an exception for that

[18:35:00.0000] <Hixie>
well like i said, there's a difference in handling for initial loads and subsequent loads

[18:35:01.0000] <Hixie>
the initial load of src="" (empty) and src="about:blank" (normalised) is handled specially in the "process the iframe attributes" algorithm

[18:35:02.0000] <Hixie>
subsequent loads of about:blank are handled in the navigation algorithm

[18:36:00.0000] <Hixie>
but it would seem crazy to not allow about:blank to navigate to about:blank, say

[18:37:00.0000] <sicking>
sure, so exclude all about:blank loads

[18:40:00.0000] <Hixie>
i just said that would be crazy :-P

[18:40:01.0000] <Hixie>
oh by exlude you mean allow?

[18:40:02.0000] <Hixie>
man i'm confused

[18:41:00.0000] <Hixie>
this really seems like adding really obscure complexity to the platform to me

[18:41:01.0000] <Hixie>
are we going to do the same for CSP?

[18:41:02.0000] <Hixie>
i don't see the difference

[18:48:00.0000] <sicking>
CSP is totally different

[18:48:01.0000] <sicking>
it applies to all loads, no matter how they happen

[18:48:02.0000] <Hixie>
how is that different?

[18:48:03.0000] <sicking>
via sandboxed iframes, non-sandboxed iframes or page navigation

[18:48:04.0000] <Hixie>
only in new UAs

[18:49:00.0000] <Hixie>
just like text/html-sandboxed

[18:51:00.0000] <sicking>
yes, CSP is strictly defense-in-depth

[18:51:01.0000] <sicking>
that's different from the same-origin issue with sandboxes though

[18:51:02.0000] <Hixie>
sanbdox is strictly defense-in-depth too.

[18:52:00.0000] <Hixie>
but i have to go now. ttyl :-)

[18:52:01.0000] <sicking>
ok, ttyl

[18:52:02.0000] <Hixie>
i recommend e-mailing the whatwg list to get others in the loop

[19:01:00.0000] <TabAtkins>
Hixie or abarth: What should we reference for the definition of URL in CSS?  We're currently referring to RFC 3986.

[19:04:00.0000] <TabAtkins>
Hixie or abarth: Our current definition is at http://dev.w3.org/csswg/css3-values/#urls

[19:12:00.0000] <rniwa>
Hixie, sicking: yt?

[21:13:00.0000] <annevk>
TabAtkins, CSS URL values are parsed the same as in HTML

[21:14:00.0000] <annevk>
TabAtkins, though UTF-8 is enforced, just like in XMLHttpRequest

[21:14:01.0000] <annevk>
TabAtkins, 3986 is wrong, but there's not really a good replacement at the moment

[21:14:02.0000] <annevk>
I think we should just put everything into the URL specification

[21:14:03.0000] <annevk>
API, syntax, etc.

[21:58:00.0000] <sicking>
annevk: ping

[21:59:00.0000] <annevk>
hey sicking

[21:59:01.0000] <sicking>
annevk: i don't understand your email regarding the CORS change

[21:59:02.0000] <sicking>
annevk: can you give an example scenario which you're proposing should change

[22:00:00.0000] <annevk>
you xhr to from a to b

[22:00:01.0000] <annevk>
b doe set-cookie

[22:00:02.0000] <annevk>
withCredentials is true

[22:00:03.0000] <annevk>
does*

[22:00:04.0000] <annevk>
b also fails the sharing check

[22:00:05.0000] <annevk>
Gecko/WebKit set the cookie

[22:01:00.0000] <sicking>
"fails the sharing check" === "doesn't set access-control-allow-origin to the 'correct' value"?

[22:01:01.0000] <annevk>
a similar situation with <img crossorigin> is not supposed to set a cookie

[22:01:02.0000] <annevk>
sicking, for instance, or does not include the header

[22:01:03.0000] <annevk>
sicking, does not include the credentials header

[22:01:04.0000] <sicking>
ok

[22:02:00.0000] <sicking>
hmm.. why doesn't HTML5 simply defer to CORS on this?

[22:02:01.0000] <sicking>
i'm not sure how to implement this in Gecko...

[22:02:02.0000] <sicking>
by the time the response gets to the CORS code, the networking library has already set the cookie

[22:02:03.0000] <sicking>
so i guess we don't follow the HTML5 spec on this, if it indeed demands that behavior

[22:03:00.0000] <annevk>
HTML says

[22:03:01.0000] <annevk>
"For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained."

[22:03:02.0000] <annevk>
no resource obtained means no cookie

[22:03:03.0000] <sicking>
depends on what "the calling algorithm" refers to

[22:04:00.0000] <sicking>
does it refer to the <img> algorithm which downloads and parses an image?

[22:04:01.0000] <annevk>
fetch

[22:05:00.0000] <annevk>
we could also change HTML I suppose

[22:05:01.0000] <sicking>
which layers of the ISO layer model does "fetch" include?

[22:05:02.0000] <annevk>
it just seems slightly saner to not alter cookies

[22:05:03.0000] <annevk>
ISO?

[22:06:00.0000] <sicking>
OSI

[22:07:00.0000] <annevk>
still no clue :)

[22:07:01.0000] <sicking>
annevk: so the algorithm defined in the HTML spec also never sets the UAs cookies. So aborting the algorithm wouldn't seem to affect whether cookies are set

[22:07:02.0000] <sicking>
http://en.wikipedia.org/wiki/OSI_model

[22:07:03.0000] <annevk>
fetch sets cookies

[22:08:00.0000] <annevk>
we should define CORS and fetch in one spec really

[22:08:01.0000] <annevk>
but you know, lots of work refactoring those two

[22:09:00.0000] <sicking>
ah, yes

[22:09:01.0000] <sicking>
it'll still be hard to implement this, since it means violating the HTTP layer model

[22:10:00.0000] <sicking>
i.e. you can't use a plain HTTP library to do the load

[22:10:01.0000] <sicking>
i do sort of understand/like the idea. It'll just be very hacky to implement

[22:10:02.0000] <annevk>
a plain HTTP library does not do cookies

[22:11:00.0000] <sicking>
annevk: well.. i guess that's a matter of definition

[22:11:01.0000] <sicking>
ours does

[22:11:02.0000] <annevk>
if cookies are part of HTTP, so is CORS

[22:11:03.0000] <annevk>
aaah, so whatever Gecko's HTTP library does is plain :)

[22:12:00.0000] <sicking>
i don't expect we're the only ones to put cookies into the http library

[22:12:01.0000] <annevk>
for Opera it's no problem either way

[22:12:02.0000] <sicking>
for any browser it makes a lot of sense to have a layer that you can call into which does http including cookies and cache

[22:13:00.0000] <annevk>
that same library should prolly do CORS though

[22:13:01.0000] <annevk>
given the potentially CORS-enabled fetching stuff

[22:13:02.0000] <sicking>
annevk: arguably, but that'll require more refactoring than spec changes ;-)

[22:13:03.0000] <sicking>
annevk: i guess I'm fine with it if other browsers agree. Would be nice to have a more understandable email to the group though.

[22:18:00.0000] <annevk>
sicking, I emailed a reply to myself explaining it more clearly (hopefully)

[22:26:00.0000] <heycam>
hmm, 1323 unread public-html mails. wonder if there's anything worth reading in there...

[22:27:00.0000] <annevk>
hey

[22:27:01.0000] <annevk>
look who's back

[22:29:00.0000] <Hixie>
here now

[22:29:01.0000] <Hixie>
what's up

[22:30:00.0000] <heycam>
hi annevk

[22:30:01.0000] <heycam>
(and sicking, from before!)

[22:31:00.0000] <sicking>
annevk: thanks! I sent a reply. I generally think I agree with the change, though I have no idea when we'd be able to implement :(

[22:31:01.0000] <sicking>
annevk: our network library has this very silly policy of not having any security code in it.

[22:32:00.0000] <sicking>
annevk: We've abandoned the policy, but it's a slow process to change

[22:32:01.0000] <annevk>
Hixie, HTML applies a slightly stricter set of rules to CORS with respect to cookies

[22:32:02.0000] <Hixie>
that is unintentional if so

[22:33:00.0000] <Hixie>
let me check

[22:33:01.0000] <annevk>
Hixie, but we like it

[22:33:02.0000] <sicking>
/me wonders if darin actually made a bad decision!?!

[22:33:03.0000] <annevk>
Hixie, it's the bit about completely ignoring the response resource if the resource sharing check fails

[22:33:04.0000] <Hixie>
cookies get set in step 6.3 of the fetch algorithm

[22:34:00.0000] <annevk>
"For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained."

[22:34:01.0000] <annevk>
if there's no resource, there's no cookies

[22:34:02.0000] <Hixie>
that happnes long after the cookies are set

[22:35:00.0000] <annevk>
oh really?

[22:35:01.0000] <Hixie>
i'm assuming you're talking about a potentially CORS-enabled fetch  right?

[22:35:02.0000] <annevk>
no

[22:35:03.0000] <Hixie>
oh

[22:35:04.0000] <Hixie>
which case do you mean then

[22:35:05.0000] <annevk>
oh yes

[22:35:06.0000] <Hixie>
ok

[22:35:07.0000] <annevk>
<img crossorigin> for instance

[22:35:08.0000] <Hixie>
so assume mode = Use Credentials

[22:35:09.0000] <Hixie>
we start the algorithm

[22:36:00.0000] <Hixie>
step 1 calls CORS "cross-origin request", section 7.1 of CORS

[22:36:01.0000] <Hixie>
step 2 of that calls the "simple cross-origin request"

[22:36:02.0000] <Hixie>
section 7.1.4 of CORS

[22:36:03.0000] <Hixie>
step 1 of that calls "make a request steps"

[22:36:04.0000] <Hixie>
in section 7.1.7 of CORS

[22:37:00.0000] <Hixie>
that calls "fetch" in HTML

[22:37:01.0000] <Hixie>
oh but it has the block cookies flag set

[22:37:02.0000] <Hixie>
interesting

[22:37:03.0000] <Hixie>
ok then <img crossorigin> never sets cookies one way or the other currently

[22:37:04.0000] <Hixie>
oops

[22:39:00.0000] <Hixie>
annevk: when does XHR set cookies?

[22:42:00.0000] <annevk>
block cookies is only set if credentials is false

[22:42:01.0000] <annevk>
but credentials is true here

[22:42:02.0000] <annevk>
you said assume mode = Use Credentials

[22:42:03.0000] <annevk>
XHR sets cookies whenever "fetch" does

[22:43:00.0000] <annevk>
really need to merge CORS and fetch and I really do not want to

[22:43:01.0000] <annevk>
can't we have some Google code projects on specs next time that is up?

[22:43:02.0000] <annevk>
Google Summer of Code I meant

[22:45:00.0000] <heycam>
or a NaNo(WebSpec)Mo

[22:45:01.0000] <Hixie>
oh well

[22:45:02.0000] <Hixie>
ok

[22:45:03.0000] <Hixie>
so if credentials is true

[22:45:04.0000] <Hixie>
then let me continue:

[22:45:05.0000] <Hixie>
that calls "fetch" in HTML

[22:45:06.0000] <Hixie>
"fetch" then does the stuff, gets to step 6

[22:46:00.0000] <Hixie>
step 6.3 sets cookies

[22:46:01.0000] <Hixie>
then fetch starts firing tasks

[22:47:00.0000] <Hixie>
looks like you should be calling "fetch" with the synchronous flag set btw

[22:47:01.0000] <Hixie>
either that or talk about getting the data from the tasks it fires

[22:47:02.0000] <Hixie>
but anyway

[22:47:03.0000] <Hixie>
ignoring that

[22:47:04.0000] <Hixie>
back to "simple cross-origin request"

[22:47:05.0000] <Hixie>
it goes into the "otherwise" branch, which calls "resource sharing check"

[22:48:00.0000] <Hixie>
section 7.2 of CORS

[22:48:01.0000] <Hixie>
step 1 sees no  Access-Control-Allow-Origin header values so it returns fail

[22:48:02.0000] <Hixie>
so back to "simple cross-origin request"; it calls the "network error steps"

[22:48:03.0000] <Hixie>
in 7.1.7

[22:48:04.0000] <Hixie>
that sets cross-origin request status to /network error/

[22:49:00.0000] <Hixie>
and aborts "simple cross-origin request"

[22:49:01.0000] <Hixie>
so we're back to "cross-origin request", which just returns since it's finished too

[22:50:00.0000] <Hixie>
so, we're back to the HTML spec's "potentially CORS-enabled fetch"

[22:50:01.0000] <Hixie>
second branch, step 2. That waits for the CORS cross-origin request status to have a value, which it does

[22:50:02.0000] <Hixie>
so then step 3

[22:50:03.0000] <Hixie>
goes through the first branch, since it's not "success"

[22:50:04.0000] <Hixie>
all the tasks are discarded, and it returns a fatal network error

[22:50:05.0000] <Hixie>
but the cookies are already set

[22:51:00.0000] <Hixie>
since they were set way back when before CORS was checked

[22:51:01.0000] <Hixie>
here ends my story

[22:56:00.0000] <annevk>
o_O

[22:57:00.0000] <Hixie>
why o_O?

[23:00:00.0000] <annevk>
complicated :)

[23:00:01.0000] <Hixie>
you wrote most of it! :-P

[23:37:00.0000] <annevk>
yeah I guess we should do new Text()

[23:38:00.0000] <annevk>
prolly should revert the overloading change and start with that

[23:38:01.0000] <annevk>
still not really sure of the new EVERYTHING() plan

[23:38:02.0000] <annevk>
new HTMLDivElement() is so ugly

[23:38:03.0000] <annevk>
new Div() would be kind of neat

[23:38:04.0000] <Hixie>
new HTMLUnknownElement()

[23:38:05.0000] <Hixie>
new HTML*Element() in general just doesn't work

[23:39:00.0000] <annevk>
so alex thinks it should work and should just result in a useless object

[23:40:00.0000] <annevk>
but I'm not sure what the point of that is

[23:40:01.0000] <Hixie>
yeah i pretty strongly disagree with alex on this issue

[23:43:00.0000] <heycam>
new HTMLDivElement() is indeed ugly

[23:43:01.0000] <heycam>
I would like new Element("div")

[23:44:00.0000] <annevk>
that returns a non-Element object?

[23:44:01.0000] <heycam>
don't think it matters too much that the return type is something more specific than Element -- it at least is a kind of Element

[23:44:02.0000] <annevk>
hmm

[23:44:03.0000] <heycam>
I think "Element" is nice and short enough

[23:44:04.0000] <annevk>
Element.create is pretty short too

[23:44:05.0000] <heycam>
but not as :)

[23:45:00.0000] <annevk>
node.append(["div"]) would be even shorter

[23:45:01.0000] <annevk>
see some emails on www-dom

[23:45:02.0000] <heycam>
so I agree with Alex that we should encourage constructors where possible, it's just that I don't know that forcing spec writers to specify constructor behaviour on everything is the best (or most polite) way to do that

[23:46:00.0000] <annevk>
we can just add [NoConstructor] everywhere until the concrete proposals arrive

[23:46:01.0000] <heycam>
guess so

[23:46:02.0000] <annevk>
or we can skip the make work and wait for the latter

[23:46:03.0000] <heycam>
still seems kinda rude for webidl to force that

[23:46:04.0000] <annevk>
I was being sarcastic

[23:47:00.0000] <annevk>
I think what we have now is good and people should make concrete proposals for constructors where they are needed

[23:47:01.0000] <heycam>
sarcasm with no indicating punctuation!

[23:47:02.0000] <annevk>
if we end up with constructors everywhere, we can make them optional

[23:48:00.0000] <annevk>
heycam, the horror!

[23:48:01.0000] <annevk>
next you claim it's inaccessible

[23:48:02.0000] <Hixie>
i think the json-like description of elements is kinda crazy, personally

[23:48:03.0000] <annevk>
crazy-neat?

[23:49:00.0000] <heycam>
many people write helper functions to do that json-like thing

[23:50:00.0000] <Hixie>
crazy ugly and incomprehensible

[23:50:01.0000] <heycam>
i'm a bit wary of potential confusion over whether it sets js properties, dom attributes, magic with onfoo handlers, etc.

[23:50:02.0000] <Hixie>
if we're going that route, please for the love of kittens just use E4X or something similar

[23:50:03.0000] <heycam>
ha

[23:53:00.0000] <annevk>
E4X yeah right

[23:53:01.0000] <annevk>
heycam, ah yeah, guess we'll end up with attributes and on* as event handlers

[23:53:02.0000] <annevk>
if we do it

[23:53:03.0000] <heycam>
:/

[23:54:00.0000] <heycam>
hopefully as separate arguments?

[23:54:01.0000] <heycam>
i.e. not intermingled on the one object passed in?

[23:54:02.0000] <annevk>
that was the idea initially, but is that really worth it?

[23:55:00.0000] <heycam>
dunno, it just rubs me the wrong way somehow, treating /^on/ attributes differently

[23:55:01.0000] <heycam>
(do we have any non event listener attributes that begin with "on"?)

[23:56:00.0000] <annevk>
don't think so

[23:57:00.0000] <heycam>
even if we don't, I wouldn't like to rule out such attributes because Element.create or whatever would treat them as event names after the "on"

[23:58:00.0000] <heycam>
"1emu = 1pt/12700"

[23:58:01.0000] <heycam>
I would've expected an emu to be a kind of large unit

[00:02:00.0000] <annevk>
heycam, given that X is going to be optimized for web platform elements I do not think that's a problem

[00:04:00.0000] <annevk>
but then I'm still not sure whether we should do X (e.g. Element.create) at all, plus all the other various DOM methods ojan is proposing

[00:05:00.0000] <heycam>
/me probably skimmed past that email

[00:05:01.0000] <annevk>
"modifying the DOM WAS: Node append"

[00:15:00.0000] <annevk>
heycam, so the one thing we need for that is unbounded dictionaries

[00:16:00.0000] <heycam>
yeah

[00:16:01.0000] <annevk>
heycam, so there's still a defined processing order and everything

[00:16:02.0000] <heycam>
I just avoided adding that until there were concrete needs for it

[00:16:03.0000] <annevk>
okay

[00:18:00.0000] <annevk>
it would be great if we could discuss these proposals with various implementors

[00:18:01.0000] <annevk>
it seems pretty clear authors want some simplified way of doing things

[00:18:02.0000] <heycam>
(is that not what the www-dom discussion is achieving?)

[00:18:03.0000] <annevk>
everyone has their own convenience method / templating system

[00:18:04.0000] <annevk>
yeah, though I'm missing sicking / othermaciej

[00:18:05.0000] <heycam>
yeah, it is tough to standardise a templating system -- it's almost entirely a syntax debate

[00:19:00.0000] <annevk>
actually, not sicking

[00:19:01.0000] <annevk>
I do think that if we want to simplify the DOM having element templates would be huge step

[00:20:00.0000] <annevk>
and keeps people from using innerHTML which has all the badness of string concatenation

[00:20:01.0000] <annevk>
well hopefully keeps them away from it, no guarantees

[00:20:02.0000] <heycam>
sprintf

[00:20:03.0000] <Hixie>
the biggest problem with innerHTML is the lack of compile-time syntax checking

[00:23:00.0000] <annevk>
the array stuff gives you that to some extent

[00:23:01.0000] <annevk>
prolly about as far as E4X

[00:23:02.0000] <Hixie>
yes but it's 10x as verbose

[00:23:03.0000] <Hixie>
and uglier than Element.create()

[00:23:04.0000] <annevk>
hmm

[00:24:00.0000] <annevk>
<div class="test"/>

[00:24:01.0000] <annevk>
["div", {class:"test"}]

[00:24:02.0000] <annevk>
not too bad

[00:24:03.0000] <Hixie>
uh huh

[00:25:00.0000] <heycam>
I just some more sarcasm without punctuation :)

[00:25:01.0000] <heycam>
*detected some

[00:25:02.0000] <Hixie>
:-)

[00:25:03.0000] <annevk>
if you write </div> instead you even save a character

[00:26:00.0000] <Hixie>
what's <div><p><span>TEST</span></p></div> in your syntax?

[00:26:01.0000] <heycam>
I find the purely arrays/strings/object literals too hard to read

[00:26:02.0000] <Hixie>
yes

[00:26:03.0000] <heycam>
even though I'm guilty of writing functions like that for my own purposes

[00:26:04.0000] <heycam>
because I hate to use so many method calls :)

[00:27:00.0000] <Hixie>
i use duct tape for private use, too. i wouldn't try to sell a product made with duct tape.

[00:27:01.0000] <heycam>
so I wonder, without having written out an example, if a small amount of verbosity like requiring new Element("div", { class: "test" }) rather than just using an array with a string in first position to mean the tag name, would help make it more readable

[00:27:02.0000] <annevk>
["div", ["p", ["span", "TEST"]]]

[00:28:00.0000] <annevk>
it wins again

[00:28:01.0000] <Hixie>
wow

[00:28:02.0000] <Hixie>
wins is so not the word i was going to use

[00:28:03.0000] <heycam>
lol

[00:36:00.0000] <jacobolu_>
burn

[00:37:00.0000] <annevk>
I'm not sure

[00:37:01.0000] <jacobolus>
Hixie: you don't think having some kind of structured way to write these that's not a string would be helpful?

[00:37:02.0000] <annevk>
I'm not the one who claimed "10x as verbose"

[00:37:03.0000] <Hixie>
jacobolus: i absolutely think it would be helpful

[00:37:04.0000] <Hixie>
jacobolus: i think E4X would be the way to go

[00:37:05.0000] <Hixie>
jacobolus: or, within JS itself, nested Element.create() calls

[00:37:06.0000] <jacobolus>
oh. I'm not very familiar w/ e4x

[00:38:00.0000] <jacobolus>
wait, you just write xml inline w/ the javascript?

[00:38:01.0000] <Hixie>
annevk: not 10x longer, just 10x more verbose

[00:38:02.0000] <jacobolus>
ick

[00:38:03.0000] <heycam>
I think a structured way to write these things is good, it's just that using only [] and {} as the delimiters makes it far from readable

[00:38:04.0000] <heycam>
I would happily sacrifice some conciseness for readability

[00:38:05.0000] <Hixie>
annevk: there's way more punctuation going on in ways that really make it very hard to work out what's going on

[00:39:00.0000] <Hixie>
annevk: e.g. "foo", "foo" should never be able to represent an element containing a text node

[00:39:01.0000] <Hixie>
annevk: that's just batty

[00:39:02.0000] <heycam>
/me easily envisages calls to this Element.create ending with ]]]}]]]}]});

[00:40:00.0000] <annevk>
Hixie, hmm, at the end of the array you have either other elements or text nodes; I don't think it's too bad

[00:40:01.0000] <heycam>
would be nice if the whatwg mailing list software included an Archived-At header (probably someone has requested this before)

[00:40:02.0000] <annevk>
Hixie, you do have to know the model of course, otherwise it is indeed kind of hard

[00:40:03.0000] <annevk>
heycam, lots of people have

[00:41:00.0000] <annevk>
heycam, I was planning on writing some intermediary script at one point, but never did

[00:42:00.0000] <annevk>
my idea was passing he Message-ID after some URL that would have some kind of lookup and do redirects

[00:42:01.0000] <annevk>
the*

[00:43:00.0000] <Hixie>
heycam: tell dreamhost :-(

[00:43:01.0000] <heycam>
annevk, oh yeah, like w3.org/mid/...

[00:43:02.0000] <Hixie>
annevk: good APIs are intuitive

[00:44:00.0000] <annevk>
it's not exactly less or more intuitive than the Element.create proposal

[00:44:01.0000] <annevk>
or new Event()

[00:46:00.0000] <jacobolus>
Hixie: what's an intuitive DOM creation/query/manipulation API in your view?

[00:46:01.0000] <Hixie>
annevk: as an extreme example, I would say Element.create("div", {title: "bar"}, ["Hello"]); is more intuitive than Element.create(["div", {title: "bar"}, ["Hello"]]);, because in the latter one there's one argument, and it's not clear that one array's values mean different things, whereas in the former it's clear that the arguments mean different things, and it seems obvious that an element creation method would start with an element name, and you can work out the

[00:46:02.0000] <Hixie>
jacobolus: well, an intuitive creation one would be:  var mydiv = <div/>;

[00:47:00.0000] <jacobolus>
but just making that a string in a simple function is just as good at that point, ISTM

[00:47:01.0000] <Hixie>
(i wouldn't take anything from E4X other than the element literals, fwiw)

[00:47:02.0000] <Hixie>
jacobolus: strings aren't syntax-checked

[00:47:03.0000] <jacobolus>
syntax-checked by whom?

[00:47:04.0000] <Hixie>
the compiler

[00:48:00.0000] <Hixie>
jacobolus: consider the difference between  var mytree = <p><i>hello</b> world</p>;  and  var mytree = "<p><i>hello</b> world</p>";

[00:48:01.0000] <Hixie>
jacobolus: how long do you think it would take to catch those two errors?

[00:48:02.0000] <jacobolus>
so then a question... how do you make it dynamic?

[00:48:03.0000] <jacobolus>
i.e. if I want to stick some custom stuff in halfway through

[00:48:04.0000] <Hixie>
for the first one, i'd say about 1 second to catch it, and about 3 seconds to fix it. for the second, it might never get caught, but it's probably measured in weeks or months.

[00:49:00.0000] <Hixie>
E4X had a mechanism for that

[00:49:01.0000] <Hixie>
something like  var name = 'jacobolus'; var mydiv = <div>Hello {name}</div>;

[00:49:02.0000] <jacobolus>
hm

[00:50:00.0000] <jacobolus>
so why couldn't you just make it a function w/ some name

[00:50:01.0000] <Hixie>
(you can test it in mozilla, it ships with e4x)

[00:50:02.0000] <Hixie>
a function?

[00:50:03.0000] <jacobolus>
and pass in a string

[00:50:04.0000] <jacobolus>
and then have tooling

[00:50:05.0000] <Hixie>
strings aren't syntax checked

[00:50:06.0000] <jacobolus>
that would do the syntax checing

[00:50:07.0000] <jacobolus>
*checking

[00:50:08.0000] <jacobolus>
that could easily be done in e.g. a text editor, linter, etc.

[00:51:00.0000] <Hixie>
not as easily as "the compiler won't run the code while it's broken"

[00:51:01.0000] <Hixie>
and the difference is enough that nobody does what you're suggesting

[00:51:02.0000] <jacobolus>
they do for regexps in python, as one example

[00:52:00.0000] <Hixie>
maybe python developers are better than js developers?

[00:52:01.0000] <jacobolus>
heh

[00:53:00.0000] <jacobolus>
are there any people who have written descriptive praises of E4X?

[00:53:01.0000] <Hixie>
descriptive praises?

[00:53:02.0000] <jacobolus>
i.e. is there some testimonial I can read about how nice it was to deal with?

[00:53:03.0000] <jacobolus>
with like, specific problems it solved and so forth?

[00:53:04.0000] <Hixie>
i dunno, probably

[00:54:00.0000] <Hixie>
most commentary was about how it sucks

[00:54:01.0000] <jacobolus>
because just at first glance my guess is that I sort of wouldn't like it

[00:54:02.0000] <Hixie>
the suckitude being mostly related to the bits i haven't talked about :-)

[00:54:03.0000] <Hixie>
(it tried to solve too much imho)

[00:54:04.0000] <Hixie>
anyway, i gotta go

[00:54:05.0000] <Hixie>
bed time

[00:54:06.0000] <jacobolus>
cheers

[00:55:00.0000] <jacobolus>
I wonder if there are any DSLs embedded in other languages for XML manipulation that are particularly elegant

[00:55:01.0000] <jacobolus>
some lisp macros or some such

[00:56:00.0000] <jacobolus>
or I guess just for creating complex structured data with attributes and descendants at each level

[00:56:01.0000] <jacobolus>
wouldn't necessarily have to be based around xml

[00:57:00.0000] <jacobolus>
annevk: FWIW, I like your thing :)

[01:45:00.0000] <hsivonen>
Is webcam support in Opera 12 going to be WebRTC or something else?

[02:21:00.0000] <hsivonen>
hmm. Opera 12 doesn't have license legal stuff for Google's WebRTC code on the about page at least

[02:22:00.0000] <hsivonen>
is there some documentation about what kind of webcam integration Opera 12 has?

[02:25:00.0000] <hsivonen>
considering how portable Opera is, I'm a bit surprised Opera isn't using clang already on Mac: http://my.opera.com/desktopteam/blog/2011/09/28/mac-compiler-js-performance

[02:34:00.0000] <foolip>
hsivonen, it's not Google code

[02:41:00.0000] <doublec>
opera 12 has webrtc support?

[02:42:00.0000] <hsivonen>
foolip: what's the feature?

[02:42:01.0000] <hsivonen>
foolip: that is, what's the webcam integration feature? still upload via <input type=file>? WebRTC? something else?

[02:44:00.0000] <foolip>
hsivonen, I really don't know, but I assume it's in anticipation of future features that need it (WebRTC)

[02:45:00.0000] <hsivonen>
foolip: ok. I was wondering about https://twitter.com/#!/ComputerActive/status/123663408133451776 which was retweeted by @opera

[02:46:00.0000] <foolip>
hmm, yeah, I'm not sure what the sales pitch is, AFAICT you can do things like "augmented reality" now, for what it's worth

[02:46:01.0000] <foolip>
on mobile at least, on desktop I don't think we have device orientation events :)

[02:47:00.0000] <hsivonen>
I haven't verified, but IIRC, Firefox has device orientation events on laptops

[02:48:00.0000] <hsivonen>
though having to tilt the whole laptop might not be as good UI as tilting a phone

[02:48:01.0000] <foolip>
I'm just guessing though

[02:48:02.0000] <zcorpan>
orientation events worked for me in firefox on my macbook

[02:49:00.0000] <hsivonen>
http://news.ycombinator.com/item?id=3096398 is interesting. especially Brendan's follow-up at the bottom of the page

[02:59:00.0000] <MikeSmith>
hsivonen: indeed

[03:01:00.0000] <annevk>
what blog post of alex does Brendan mean?

[03:02:00.0000] <hsivonen>
annevk: I don't know. I'm guessing http://infrequently.org/2011/09/google-the-future-of-javascript/

[03:10:00.0000] <annevk>
hsivonen, afaik Opera 12 allows displaying the feed of a device camera via <video> (which you can then manipulate using <canvas>)

[03:11:00.0000] <hsivonen>
annevk: ok.

[03:11:01.0000] <hsivonen>
annevk: are there docs on how to do that from Web content?

[03:12:00.0000] <annevk>
I think we implemented getUserMedia()

[03:12:01.0000] <annevk>
there was a labs build with that a while ago

[03:12:02.0000] <annevk>
http://my.opera.com/core/blog/2011/03/23/webcam-orientation-preview

[03:13:00.0000] <annevk>
instead of URL.createObjectURL() we currently allow directly assigning a Stream object to <video>.src instead; I think that's the only deviation

[03:13:01.0000] <annevk>
it's just to let people play around a little bit

[03:19:00.0000] <hsivonen>
annevk: thanks

[03:24:00.0000] <hsivonen>
the new features in http://www.w3.org/2011/09/games/ look rather reasonable except for the hardware performance score

[03:25:00.0000] <hsivonen>
surely each per-sensitive app needs to run its own benchmark to find out the perf that's relevant to the app

[03:26:00.0000] <jgraham>
Yeah, that sounds like a bad idea

[03:29:00.0000] <hsivonen>
if the app uses requestAnimationFrame, it should be able to detect if the fps is bad and try throttle down whatever slow stuff it does

[03:30:00.0000] <hsivonen>
though that might not help. I tried the WebGL aquarium in Firefox on Galaxy S II and the level of detail had no bearing on the frame rate

[03:30:01.0000] <hsivonen>
I'm guessing the frame rate was terrible due to something like readbacks from the GPU

[05:44:00.0000] <smaug____>
where is Ms2ger

[05:45:00.0000] <smaug____>
annevk5: is the plan to move onfoo idl properties to DOM[4/web/Core/Math.random()] ?

[06:06:00.0000] <Ms3ger>
smaug____: you called?

[06:07:00.0000] <annevk>
Ms3ger--

[06:07:01.0000] <Ms3ger>
Postfix, so it would still return Ms3ger

[06:08:00.0000] <Ms3ger>
(I should note that I stole that joke from someone in #jsapi)

[06:09:00.0000] <smaug____>
Ms3ger: just about the thing I asked from annevk5

[06:09:01.0000] <smaug____>
onfoo properties

[06:09:02.0000] <smaug____>
whether those are going to DOM[4/web/Core/Math.random()]

[06:10:00.0000] <annevk>
it's been argued they should be

[06:10:01.0000] <Ms3ger>
Hmm, DOMWeb

[06:10:02.0000] <annevk>
makes a lot of sense in Dutch

[06:10:03.0000] <annevk>
so probably not a good name

[06:10:04.0000] <Ms3ger>
annevk++

[06:11:00.0000] <Ms3ger>
Anyway, not sure about the specific attributes

[06:11:01.0000] <Ms3ger>
It might be good to move the infrastructure to DOM4, though

[06:15:00.0000] <smaug____>
annevk: Ms3ger: I was just wondering the right component for http://www.w3.org/Bugs/Public/show_bug.cgi?id=14428 It could be DOM or HTML or WebIDL, I guess. I picked up the last one

[06:16:00.0000] <Ms3ger>
/me is happy to let heycam figure out what to do

[06:16:01.0000] <Ms3ger>
Also, welcome back, heycam!

[06:17:00.0000] <Ms3ger>
/me goes off again

[06:17:01.0000] <Ms3ger>
ttyl

[06:17:02.0000] <annevk>
yeah, I'm pretty happy for other people to figure out how event handlers should work before we include them

[07:51:00.0000] <jgraham>
So, why can't I find the spec for innerHTML anymore?

[07:53:00.0000] <annevk>
you're not looking carefully? http://html5.org/specs/dom-parsing.html

[07:54:00.0000] <jgraham>
Oh you made a whole new spec for it. You know that will confuse the hell out of people, right?

[07:55:00.0000] <annevk>
you always predict doom

[07:55:01.0000] <annevk>
;)

[09:28:00.0000] <hsivonen>
I wonder where this person gets his ideas about Mozilla http://news.ycombinator.com/item?id=3094880

[09:29:00.0000] <bga_>
open bytecode stantard is ok

[09:31:00.0000] <bga_>
i remeber http://code.google.com/p/chromium/issues/detail?id=64290

[09:33:00.0000] <jgraham>
hsivonen: Cynicism untempered by reality?

[09:34:00.0000] <dglazkov>
good morning, Whatwg!

[09:37:00.0000] <divya>
GOOD MORNING DGLAZKOV

[09:38:00.0000] <dglazkov>
all caps. Excellent choice.

[09:38:01.0000] <divya>
i really put in the effort for the cause of html5

[09:39:00.0000] <hsivonen>
I wonder if I'm reading too much into Opera's PR language when I observe that they don't say "Flash" when they've added Flash support

[09:39:01.0000] <hsivonen>
it looks like an attempt to downplay Flash as something that users are aware of

[09:39:02.0000] <timeless>
hsivonen: are they bundling flash now?

[09:40:00.0000] <hsivonen>
timeless: no, but on desktop, they are automating installation at least on Windows, IIRC

[09:40:01.0000] <hsivonen>
timeless: this is about the latest Opera Mobile release, though, which added Flash support on Honeycomb

[09:41:00.0000] <hsivonen>
apparently the way Flash presents itself to NPAPI is different in Android 2.x and 3.x

[09:42:00.0000] <timeless>
sandboxing related perhaps?

[09:43:00.0000] <hsivonen>
dunno

[09:43:01.0000] <hasather>
hsivonen: the guy writing that blog post is not an Opera employee btw (but I think the blog is official)

[09:45:00.0000] <jgraham>
We get random strangers to write our PR stuff? :)

[09:45:01.0000] <hasather>
jgraham: neither random nor stranger I think, but yea... :D

[09:46:00.0000] <beverloo>
I agree that it's hard to see which posts are and which posts aren't official at Opera's

[09:46:01.0000] <timeless>
jgraham: nokia did

[09:46:02.0000] <timeless>
we had contractors responsible for the official nokia connections or whatever it was blog

[10:09:00.0000] <hsivonen>
is the XHR error flag exposed to scripts?

[10:12:00.0000] <hsivonen>
looks like Gecko returns xhr.status == 0 for non-HTTP requests :-(

[10:21:00.0000] <smaug____>
Should http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch say something about caching

[10:23:00.0000] <smaug____>
especially, in which case is loading from browser cache ok, and in which case it isn't

[10:26:00.0000] <AryehGregor>
What's the story with &apos;?  What's the newest browser that doesn't support it?

[10:27:00.0000] <AryehGregor>
IE6, at least?

[10:27:01.0000] <AryehGregor>
Apparently IE7 also?

[10:28:00.0000] <AryehGregor>
/me uses &#39; instead

[10:29:00.0000] <AryehGregor>
jgraham, I pushed the innerHTML change, with a single escaping function defined as you requested.

[10:30:00.0000] <AryehGregor>
(am also looking at pushing other changes)

[10:33:00.0000] <gsnedders>
hasather: What blog post?

[10:37:00.0000] <gsnedders>
Oh, that one.~

[10:37:01.0000] <AryehGregor>
/me finds that 50% of total time in Chrome is in format_value now

[10:43:00.0000] <gsnedders>
/me is increasingly doubting the open-web nature of even the Dart to JS compiler.

[10:44:00.0000] <AryehGregor>
Is it any worse than GWT?

[10:45:00.0000] <gsnedders>
At a high-level it appears better, but looking into it it seems worse.

[10:45:01.0000] <AryehGregor>
/me hasn't looked into it

[10:45:02.0000] <AryehGregor>
/me doubts the utility of "let's introduce yet another language", though

[10:46:00.0000] <gsnedders>
Oh, yeah. Sure. But it's really a bit too late for me to start bitching about that now…

[10:47:00.0000] <gsnedders>
AryehGregor: It avoids the browser sniffing, but is supported on fewer browsers, and without any given reason (or bug reports)…

[10:47:01.0000] <AryehGregor>
"supported on" meaning "actually works on" or "is tested on"?

[10:48:00.0000] <gsnedders>
I believe the latter. Though it makes me the doubt the former.

[10:48:01.0000] <gsnedders>
Testing is hardly that expensive.

[10:48:02.0000] <AryehGregor>
Testing is very expensive if you do enough of it.

[10:48:03.0000] <AryehGregor>
If there's no browser-sniffing of any kind, all browsers should be able to work just by making sure they follow what other browsers do, right?

[10:48:04.0000] <gsnedders>
For a company like Google, with the amount of resources already thrown at Dart, it's cheap.

[10:49:00.0000] <AryehGregor>
Even compared to the benefit, taking market shares into account?

[10:49:01.0000] <gsnedders>
AryehGregor: Except that at least the Dart website (haven't looked to see if that uses Dart though, FWIW) breaks if we fix DOM 3 Events compliance bug to move inline with Fx/WebKit.

[10:50:00.0000] <gsnedders>
AryehGregor: IE has a non-negilable marketshare. We have enough marketshare that they care about us enough in GWT.

[10:50:01.0000] <gsnedders>
And our JS impl really should be good enough that it should work fine.

[10:50:02.0000] <gsnedders>
So the cost of supporting Carakan should be ~0.

[10:51:00.0000] <gsnedders>
Provided they actually follow ES5 in their impl and don't rely upon things where V8/SM intend on changing behaviour for it.

[10:52:00.0000] <gsnedders>
Same with Chakra, really.

[10:52:01.0000] <gsnedders>
Omitting the two JS engines that nowadays probably have the best support for ES5 is… odd.

[10:52:02.0000] <gsnedders>
To say the least.

[10:53:00.0000] <AryehGregor>
Well, supporting an extra browser is cheap if all your tests are automated.

[10:53:01.0000] <gsnedders>
And I'd hope they are.

[10:54:00.0000] <AryehGregor>
For a language converter, yeah.

[11:04:00.0000] <hsivonen>
what's the deal with WebM support in Opera Mobile for Android? Earlier, I was told Opera Mobile supported WebM from 2.3 onwards

[11:05:00.0000] <hsivonen>
I just tested the latest release on Android 3.1 and it supported H.264 but not WebM

[11:12:00.0000] <AryehGregor>
Is it possible for window.parent to change?

[11:12:01.0000] <gsnedders>
hsivonen: I believe we just use the system video decoder, so whatever that supports.

[11:12:02.0000] <AryehGregor>
I mean, for the same script to see different values at different times?

[11:12:03.0000] <AryehGregor>
For the same window object?

[11:12:04.0000] <timeless>
AryehGregor: hrm

[11:13:00.0000] <AryehGregor>
I'd think it should be impossible, but I wanted to check.

[11:13:01.0000] <timeless>
if a browser implements a user friendly version of <pop-frame-out-as-window-out

[11:13:02.0000] <timeless>
but i don't think that exists anywhere

[11:14:00.0000] <hsivonen>
gsnedders: maybe I should remove the advice that Opera Mobile supports WebM on Android, then

[11:15:00.0000] <hsivonen>
gsnedders: because it sucks to tell people it does if it doesn't

[11:15:01.0000] <gsnedders>
hsivonen: We should support it.

[11:15:02.0000] <hsivonen>
at least Firefox supports it consistently even if performance is unusable

[11:15:03.0000] <gsnedders>
/me has no Android 2.3.3+ device to test on

[11:16:00.0000] <AryehGregor>
Is it worthwhile to support it if performance is unusable?

[11:17:00.0000] <hsivonen>
well, at least I should edit the page not to suggest Opera 11+ users to install Opera as a remedy to WebM non-support

[11:17:01.0000] <AryehGregor>
Isn't it better in that case to fall back to the next source, if any?

[11:17:02.0000] <hsivonen>
AryehGregor: unclear

[11:17:03.0000] <hsivonen>
hmm. which reminds me that I haven't tested it with layers acceleration

[11:18:00.0000] <gsnedders>
hsivonen: I saw someone saying Mobile 11.5 at least had better WebM perf than Firefox on some Android device.

[11:18:01.0000] <timeless>
gsnedders: do you have an n900?

[11:19:00.0000] <timeless>
/me wonders which version Android is used for Nitdroid

[11:19:01.0000] <gsnedders>
timeless: No. HTC Legend.

[11:20:00.0000] <hsivonen>
the perf sucks even with layers acceleration enabled :-(

[11:21:00.0000] <gsnedders>
hsivonen: What device are you testing on, and on what Android version?

[11:21:01.0000] <gsnedders>
And what version of Mobile?

[11:22:00.0000] <hsivonen>
gsnedders: Samsung Galaxy Tab 10.1, Android 3.1 (latest build available), Opera Mobile 11.50 (the one released today)

[11:22:01.0000] <dglazkov>
AryehGregor: re window.parent, you should talk with dimich on #webkit about this. There's a thing called "magic iframe" in WebKit, which _may_ make window.parent change

[11:23:00.0000] <AryehGregor>
dglazkov, I suspect that for my use-case it's not the end of the world if it changes in crazy circumstances.

[11:23:01.0000] <gsnedders>
hsivonen: What page were you using for testing?

[11:23:02.0000] <dglazkov>
AryehGregor: k

[11:23:03.0000] <hsivonen>
gsnedders: http://webm.html5.org/

[11:23:04.0000] <gsnedders>
hsivonen: eh, we appear to have https://bugs.opera.com/wizard/mobile now, so can you just file a bug?

[11:23:05.0000] <hsivonen>
a friend on another channel reports that WebM doesn't work in GSII in Opera Mobile 11.x

[11:24:00.0000] <hsivonen>
gsnedders: ok

[11:24:01.0000] <gsnedders>
I'll make sure it gets attention, because that is /bad/ it doesn't work.

[11:26:00.0000] <hsivonen>
gsnedders: oh, the playback support is there. canPlayType is wrong

[11:26:01.0000] <hsivonen>
FAIL

[11:26:02.0000] <gsnedders>
hsivonen: That may be down to YouTube breaking if canPlayType is right, AIUI

[11:27:00.0000] <gsnedders>
(I wish I was joking)

[11:28:00.0000] <hsivonen>
even worse

[11:29:00.0000] <hsivonen>
gsnedders: ANDMEX-3236

[11:29:01.0000] <gsnedders>
"Enabling only webM audio for Android 2.3.3+ Video doesn't work well and causes Android media server to crash."

[11:30:00.0000] <AryehGregor>
Does anyone have any tips on how to speed up layout of a 40,000-row table?

[11:30:01.0000] <gsnedders>
So, uh, we seem to have it disabled because Android's WebM impl is unstable

[11:41:00.0000] <gsnedders>
Heheh, I like how in response to Dart people are again saying there should be a generic bytecode, "to avoid the cost of parsing", totally ignoring a large part of the cost is validating it, which will remain true for any bytecode.

[11:41:01.0000] <gsnedders>
The only real gain is a few fewer bytes to process, but the same number of tokens, pretty much…

[11:43:00.0000] <gsnedders>
AryehGregor: Also, Dart->JS compiler's output does UA sniff and blocks everything that isn't Chrome, Safari, or Firefox.

[11:43:01.0000] <gsnedders>
AryehGregor: They only talk about removing the UA block on IE9.

[11:43:02.0000] <AryehGregor>
Seriously?  That's massively lame.

[11:43:03.0000] <gsnedders>
AryehGregor: So Opera is totally fucked.

[11:44:00.0000] <AryehGregor>
Along with every other minor browser that uses WebKit or whatever but happens not to look like one of the major browsers.

[11:44:01.0000] <AryehGregor>
(although probably all of those pretend to be a major browser)

[11:45:00.0000] <gsnedders>
So Google care enough about us to give us however-many-million-dollars per year, but not enough to actually support us.

[11:45:01.0000] <AryehGregor>
It's independent people making different decisions.

[11:53:00.0000] <timeless>
AryehGregor: um

[11:54:00.0000] <AryehGregor>
?

[11:54:01.0000] <timeless>
i don't think we pretend to be a major browser

[11:54:02.0000] <timeless>
/me seems to recall getting crappy content

[11:54:03.0000] <AryehGregor>
You probably just get broken content in sites that whitelist browsers, then.

[11:56:00.0000] <timeless>
oh cute

[11:56:01.0000] <timeless>
we claim to be Safari :)

[11:56:02.0000] <AryehGregor>
So does Chrome, kind of.

[11:56:03.0000] <AryehGregor>
And Safari claims to be Mozilla, as does everyone else.

[11:56:04.0000] <AryehGregor>
UA strings are fun.

[11:56:05.0000] <timeless>
i thought Opera or IE stopped claiming to be Gecko

[11:57:00.0000] <TabAtkins>
annevk5 heycam|away: If HTMLDivElement is really ugly, but "new Div()" is probably too short, what about semi-namespacing?  "new HTML.Div()"?

[11:57:01.0000] <timeless>
HTMLDivElement is really ugly

[11:57:02.0000] <AryehGregor>
It still claims to be Mozilla, right?

[11:57:03.0000] <TabAtkins>
I think that might be a good way to expose CSS value constructors in a short manner as well.

[12:00:00.0000] <dglazkov>
HTML.Div() sounds nice.

[12:00:01.0000] <dglazkov>
maybe html.Div()?

[12:00:02.0000] <dglazkov>
/me breaks out his shed painting overalls

[12:00:03.0000] <timeless>
darn, ie9 still claims to be mozilla/5

[12:00:04.0000] <timeless>
/me sobs

[12:09:00.0000] <rniwa>
who knows about microdata well?

[12:10:00.0000] <AryehGregor>
rniwa, well, Hixie designed it . . . but a bunch of other people here know about it too.

[12:10:01.0000] <AryehGregor>
If you ask your question, it will probably be answered.

[12:10:02.0000] <rniwa>
okay

[12:11:00.0000] <rniwa>
would an element with itemscope and itemtype considered to be an top-level item even if there are some item-scope element that refers to that element via itemref?

[12:19:00.0000] <cygri>
rniwa: the spec says "An item is a top-level microdata item if its element does not have an itemprop attribute."

[12:20:00.0000] <rniwa>
cygri: on the other hand, it also says "Items that are not part of others are called top-level microdata items."

[12:20:01.0000] <AryehGregor>
The latter sounds non-normative.

[12:20:02.0000] <cygri>
note that itemref doesn't actually refer to items, despite its name. it just imports any property-value pairs on the target or its descendants

[12:20:03.0000] <AryehGregor>
Is it in a normative section?

[12:20:04.0000] <rniwa>
cygri: ah, that's good point.

[12:21:00.0000] <rniwa>
cygri: but what if we had an ancestor with itemscope?

[12:21:01.0000] <cygri>
yeah. it also sounds slighly wrong

[12:21:02.0000] <rniwa>
cygri: e.g. <div itemscope>hello<span itemscope itemtype="~~">

[12:21:03.0000] <rniwa>
I don't think span should be considered as the top-level microdata items in this case

[12:22:00.0000] <rniwa>
or maybe top-level isn't really top-level

[12:22:01.0000] <cygri>
according to the spec it is top-level

[12:22:02.0000] <rniwa>
huh...

[12:22:03.0000] <rniwa>
even if we had <div itemscope itemtype="~~">hello<span itemscope itemtype="~~"><b itemprop="~~"> ?

[12:22:04.0000] <cygri>
as AryehGregor said, the section you quoted is non-normative

[12:23:00.0000] <rniwa>
cygri: but in this case, div's item will contain b's content, right?

[12:23:01.0000] <rniwa>
cygri: so we'll have two top-level items in this case?

[12:26:00.0000] <rniwa>
cygri_: ?

[12:26:01.0000] <cygri_>
what?

[12:27:00.0000] <rniwa>
cygri: did you get my last question?

[12:27:01.0000] <rniwa>
cygri: if we had <div itemscope itemtype="~~">hello<span itemscope itemtype="~~"><b itemprop="~~">

[12:27:02.0000] <rniwa>
cygri: would we have two top-level items?

[12:27:03.0000] <cygri>
/me is on a bus. internet not good

[12:28:00.0000] <cygri>
that looks like two top-level items to me

[12:28:01.0000] <rniwa>
cygri: ok, thanks

[12:28:02.0000] <cygri>
yw!

[13:31:00.0000] <rniwa>
AryehGregor: regarding the -webkit-user-modify, the most important users are AIR and Inspector

[13:32:00.0000] <AryehGregor>
What's AIR?

[13:32:01.0000] <rniwa>
AryehGregor: but I've seen some users in the public Web

[13:32:02.0000] <rniwa>
AryehGregor: Adobe's new Web authoring tool

[13:32:03.0000] <rniwa>
AryehGregor: http://www.adobe.com/products/air.html

[13:32:04.0000] <AryehGregor>
Hmm.

[13:32:05.0000] <rniwa>
AryehGregor: we can probably ask them to use contenteditable instead

[13:32:06.0000] <AryehGregor>
Well, I don't like all these features being exposed permanently with vendor prefixes, but I guess there are more important things to worry about.

[13:33:00.0000] <rniwa>
AryehGregor: well, at least we don't expose user-modify :)

[13:33:01.0000] <rniwa>
in fact, that's the whole point of vendor-prefixing it, right?

[13:33:02.0000] <rniwa>
so that we can kill the feature from the standard

[13:33:03.0000] <AryehGregor>
Well, it's much better than non-vendor-prefixed, yes.

[13:33:04.0000] <rniwa>
without breaking the whole web

[13:43:00.0000] <jgraham>
Hixie: tables in email++

[13:47:00.0000] <Hixie>
heh

[13:47:01.0000] <Hixie>
i'm sure i'll get told it's inaccessible

[13:47:02.0000] <Hixie>
or i would if it was in public-html

[13:48:00.0000] <Hixie>
you'd be surprised how often i got told that my ascii art sig was a travesty and an insult to accessibility tool users everywhere

[13:49:00.0000] <TabAtkins>
Hixie: It would be less confusing to me if you didn't try to conflate the term "binding" and "component".  We've been trying to distinguish the terms for ease of discussion such that "component" implies permanence and "binding" implies decoration.

[13:49:01.0000] <Hixie>
the terms mean the same thing, and have since 1997 or so

[13:49:02.0000] <jgraham>
I'm not surprised. It wouldn't be so funny if accessibility advocates hadn't been responsible for the most confusing, inaccessible email I have ever received on a standards mailing list

[13:49:03.0000] <Hixie>
jgraham: yeah, tell me about it

[13:50:00.0000] <TabAtkins>
Hixie: Which is why we've been trying to distinguish them.  ^_^

[13:50:01.0000] <Hixie>
TabAtkins: trying to take terms that mean the same thing and distinguish them after more than 15 years of them meaning the same thing is pointless. use new terms. :-)

[13:50:02.0000] <jgraham>
TabAtkins: Those implications aren't at all clear from the names, so I wouldn't try that

[13:51:00.0000] <Hixie>
TabAtkins: "presentation transient binding" and "semantic API-defining binding", for instance

[13:51:01.0000] <TabAtkins>
Hixie: Those are horrible!

[13:51:02.0000] <AryehGregor>
They're long, is all.

[13:52:00.0000] <TabAtkins>
That's what I said.

[13:52:01.0000] <AryehGregor>
You can kill either of the two modifiers on both.

[13:52:02.0000] <Hixie>
TabAtkins: (i wasn't even aware that there were two concepts until i suggested there were a few e-mails ago, btw, and i'd no idea that there was any attempt to redefine the terms until today)

[13:52:03.0000] <TabAtkins>
Hixie: No wonder you've been so confused, then.  We've been talking solely about permanent bindings forever.

[13:53:00.0000] <Hixie>
TabAtkins: yeah stop that.

[13:53:01.0000] <TabAtkins>
What?  Why?

[13:53:02.0000] <Hixie>
because the two problems have almost identical solution spaces and it is pointless to ignore one of the two problems when designing the solution

[13:53:03.0000] <TabAtkins>
But they dont'!  They're so different!

[13:53:04.0000] <Hixie>
they're almost identical

[13:54:00.0000] <Hixie>
there's two differences

[13:54:01.0000] <Hixie>
see my most recent e-mail with the table

[13:54:02.0000] <TabAtkins>
One changes the prototype chain, exposes public API.  One can be swapped on-and-off because it makes no lasting changes.

[13:54:03.0000] <Hixie>
that's it

[13:54:04.0000] <Hixie>
that's the changes

[13:54:05.0000] <TabAtkins>
"Two" differences underscores the magnitude of the differences.

[13:54:06.0000] <Hixie>
i don't think you mean "underscores" but i agree with what you actually said, even if it's not what you meant :-)

[13:55:00.0000] <TabAtkins>
s/underscores/understates/

[13:55:01.0000] <Hixie>
the differences are nearly trivial. XBL2 could be adopted to separating them with barely a dozen edits.

[13:55:02.0000] <TabAtkins>
I... don't know how to respond to that, except by saying "No".

[13:56:00.0000] <Hixie>
let me know when you have a more coherent answer :-)

[13:56:01.0000] <TabAtkins>
"You're wrong"?

[13:56:02.0000] <Hixie>
maybe you can explain how?

[13:57:00.0000] <TabAtkins>
The ideal API for permanently changing something is a decent bit different from the ideal API for adding a swappable decorator.

[13:57:01.0000] <Hixie>
sure. One is is="foo" and the other is binding: foo;

[13:58:00.0000] <Hixie>
you're not suggesting that shadow trees would need to be defined differently, or that event handlers for one would look different than for the other, right?

[13:59:00.0000] <TabAtkins>
Shadow trees should use the same definition mechanism, obviously.  Binding event listeners may look different.  Exposing further API beyond that would definitely look different, since you can't do it at all in the decorator case.

[14:08:00.0000] <Hixie>
TabAtkins: just excluding certain features in one case doesn't make it look different, just excludes certain features

[14:08:01.0000] <Hixie>
bbiab lunch

[15:04:00.0000] <AryehGregor>
/me ponders the philosophy of testing features that depend on one another

[15:04:01.0000] <AryehGregor>
If you can't test one feature because an unrelated feature is buggy or unsupported, should the test pass or fail?

[15:04:02.0000] <AryehGregor>
If it fails, you're putting a lot of weight on possibly minor bugs in features that other features happen to depend on.

[15:05:00.0000] <AryehGregor>
If it passes, that takes more effort to handle, and also you penalize browsers for fixing bugs in features that other features depend on (because their score can only go down).

[15:05:01.0000] <AryehGregor>
(for the dependent tests, that is)

[15:06:00.0000] <gsnedders>
It's a failure, because you've failed to run the test.

[15:06:01.0000] <AryehGregor>
I guess it should generally fail, unless there's some way to avoid the bug in the underlying feature.

[15:06:02.0000] <gsnedders>
Unless the test is simply not applicable.

[15:07:00.0000] <AryehGregor>
Well, if you can easily work around the underlying bug, I think you should.

[15:07:01.0000] <AryehGregor>
Like WebKit throws WrongDocumentError if you try to set a range's endpoint to a node that's in another document from the one you created the range in.

[15:08:00.0000] <AryehGregor>
So when creating ranges for tests, other than in setStart/setEnd tests, I make sure that I call createRange() on the ownerDocument of the intended endpoints.

[15:08:01.0000] <AryehGregor>
Otherwise that one minor bug would create zillions of spurious failures in unrelated features.

[15:09:00.0000] <gsnedders>
You can always have it as a separate prereq function, and group results into pass, fail, prereq failed

[15:10:00.0000] <AryehGregor>
That doesn't really solve the problem.  It just obscures it.

[15:10:01.0000] <AryehGregor>
/me discovers that the Range tests all seem to be broken, since no one adjusted the relative URLs to testharness.js

[15:10:02.0000] <AryehGregor>
/me goes to fix

[15:16:00.0000] <jgraham>
AryehGregor: You should avoid unnecessarily depending on features that you aren't explicitly trying to test

[15:16:01.0000] <AryehGregor>
On the other hand, IE seemingly doesn't let you create Ranges whose boundary points don't descend from a Document.

[15:17:00.0000] <jgraham>
But you should always be conservative about handing out "pass"

[15:17:01.0000] <AryehGregor>
So if I have a test that starts by creating such a range, what am I supposed to do?

[15:17:02.0000] <AryehGregor>
In that case, I have to fail it.

[15:17:03.0000] <jgraham>
AryehGregor: Yes. They have a bug. They will fix the bug and the test will pass

[15:18:00.0000] <jgraham>
there isn't a problem unless you are creating unnecessary dependencies

[15:19:00.0000] <AryehGregor>
Now, WebKit/Opera mangle ranges when you do addRange(), so the range that winds up in the actual selection might not have the same boundary points as the one you gave to addRange().  In that case, when testing collapseToStart(), do I just test that whatever range ends up there gets collapsed to the start?  Or do I decide that's not really what I'm testing, if the range is substantially different from the one I put in, so I fail them?

[15:19:01.0000] <jgraham>
Judgement call

[15:19:02.0000] <AryehGregor>
What if they don't put any range in at all, so they wind up with a Selection that has no ranges?  Do I just test that they throw an exception, or do I fail them because that has no relationship to what I'm supposed to be testing?

[15:19:03.0000] <AryehGregor>
/me is ambivalent about this one

[15:20:00.0000] <jgraham>
I think I would prefer to be a bit conservative and always check that you have the right range

[15:20:01.0000] <AryehGregor>
/me thinks he'll let it slide if there winds up being some Range present, but not if there's no Range, because then you could pass all the tests if addRange() and collapseToStart() were both no-ops

[15:20:02.0000] <AryehGregor>
jgraham, that means WebKit fails almost every single test, even though its collapseToStart() implementation seems to be almost completely correct.

[15:21:00.0000] <jgraham>
AryehGregor: Well that doesn't seem ideal

[15:21:01.0000] <AryehGregor>
(Opera fails every test anyway, because its Selection implementation is broken beyond comprehension)

[15:21:02.0000] <jgraham>
But maybe it will motivate them to fix the bug :)

[15:21:03.0000] <gsnedders>
AryehGregor: But if you can't construct an environment to test that in, then how do you know it's almost completely correct?

[15:22:00.0000] <AryehGregor>
gsnedders, because it does add a range, just not the one I specified.  And then it collapses the range it did add correctly.

[15:23:00.0000] <gsnedders>
AryehGregor: Then should you not assert that it adds the range it does add correctly, regardless of what that is?

[15:23:01.0000] <AryehGregor>
gsnedders, yeah, that's what I'm doing.

[15:23:02.0000] <gsnedders>
Which means WebKit should pass?

[15:23:03.0000] <AryehGregor>
Yes.

[15:24:00.0000] <gsnedders>
Then I'm confused.

[15:26:00.0000] <AryehGregor>
Okay, so now Gecko passes everything because it's actually correct, Opera fails everything because it's actually completely broken, WebKit fails about half the tests because it doesn't add any range at all in some cases, and IE fails almost all the tests because it genuinely has a bug in collapseToStart/End.

[15:26:01.0000] <AryehGregor>
Seems good to me.

[15:32:00.0000] <gsnedders>
Are we actually that broken? The fact we manage to work with most sites tends to suggest we're not /that/ broken.

[15:33:00.0000] <AryehGregor>
gsnedders, it could be some artifact of my test setup.  I tend to find that addRange() routinely does nothing in Opera.

[15:33:01.0000] <AryehGregor>
So the selection remains empty.

[15:33:02.0000] <AryehGregor>
I suspect it has something to do with Opera deciding the range I give it isn't visible or something.

[15:34:00.0000] <AryehGregor>
Also, authors in real life commonly deal with user-created selections and don't use addRange at all.

[15:34:01.0000] <AryehGregor>
But obviously tests can't do that.

[15:34:02.0000] <rniwa>
AryehGregor: what is this range bug you're describing?

[15:34:03.0000] <AryehGregor>
rniwa, WebKit fails lots of Selection tests because addRange() doesn't add the same range it's given, it normalizes it.  As we've discussed.

[15:35:00.0000] <rniwa>
AryehGregor: ah I see.

[15:35:01.0000] <AryehGregor>
gsnedders, http://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/collapseToStartEnd.html

[15:36:00.0000] <AryehGregor>
rniwa, but there are two other tests here that fail for a different reason (not "Sanity check"), didn't look into it closely: http://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/collapseToStartEnd.html

[15:43:00.0000] <gsnedders>
AryehGregor: Where's the spec, again?

[15:43:01.0000] <AryehGregor>
gsnedders, it's wandered around a bit, but is now part of the editing spec.  http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections

[15:45:00.0000] <gsnedders>
AryehGregor: Okay, so addRange only does something if the range is not detached (in the DOM) and is collapsed.

[15:46:00.0000] <AryehGregor>
It only works if the range is collapsed?

[15:46:01.0000] <AryehGregor>
Wha?

[15:46:02.0000] <AryehGregor>
Not detached I understand, although it's not per spec.

[15:46:03.0000] <AryehGregor>
But collapsed?

[15:46:04.0000] <AryehGregor>
How are you supposed to create non-collapsed selections, then?

[15:46:05.0000] <gsnedders>
Don't ask me. I'm just reading the code. :)

[15:48:00.0000] <gsnedders>
Do you have tests for isCollapsed? That may help…

[15:48:01.0000] <AryehGregor>
Well, if you can suggest a sane way to create non-collapsed selections, I'm willing to add the workaround to my selection tests.

[15:49:00.0000] <AryehGregor>
I haven't tested isCollapsed yet, but if I did, it would consist of making a bunch of selections with addRange() and then checking isCollapsed, so it would still break in Opera.

[15:49:01.0000] <AryehGregor>
Also, Opera seems to not be adding even collapsed non-detached selections when I do addRange(), in my collapseToStart/End tests.

[15:50:00.0000] <AryehGregor>
All the nodes that are detached are named detached* in the test names, or foreign* for a foreign document, or xml* for a foreign XML document.

[15:55:00.0000] <rniwa>
AryehGregor: webkit supports setPosition

[15:55:01.0000] <rniwa>
AryehGregor: and setBaseAndExtent methods

[15:55:02.0000] <rniwa>
AryehGregor: perhaps you may want to standardize either

[15:56:00.0000] <gsnedders>
AryehGregor: Hmm.

[16:36:00.0000] <gsnedders>
AryehGregor: I'm fairly certain you're hitting some weird edge-case bug.

[16:36:01.0000] <gsnedders>
Or at least, I'm utterly confused. :)

[16:41:00.0000] <AryehGregor>
rniwa, those are totally redundant with collapse()/extend().  WebKit should get rid of them, IMO.

[16:42:00.0000] <AryehGregor>
I don't want to standardize them when they're not useful at all and just clutter an API that's already redundant.

[16:42:01.0000] <rniwa>
AryehGregor: not sure. setPosition seems useful when you want to set a collapsed selection

[16:42:02.0000] <AryehGregor>
rniwa, how does it differ from collapse()?

[16:42:03.0000] <rniwa>
AryehGregor: it seems too verbose to create a range and then remove all ranges and then add new range

[16:43:00.0000] <rniwa>
AryehGregor: hm... collapse takes node and index?

[16:43:01.0000] <AryehGregor>
rniwa, yes, but I only do that because IE doesn't support extend().  collapse()+extend() is only two lines.

[16:43:02.0000] <AryehGregor>
rniwa, Selection.collapse does.  Not to be confused with the totally different Range.collapse.

[16:44:00.0000] <AryehGregor>
gsnedders, yeah, my tests are probably hitting some kind of edge case.  I remember once before I tried debugging Opera test failures and found that moving the nodes I was selecting to the top of the document somehow fixed it.

[16:45:00.0000] <AryehGregor>
Could it have something to do with the fact that the nodes are created and then selected without any repaints/event loop spins in between?

[16:45:01.0000] <AryehGregor>
Since selections in Opera are somewhat visual.

[16:45:02.0000] <AryehGregor>
No, doesn't seem to be it.

[16:45:03.0000] <AryehGregor>
Well, if you find an explanation, let me know.

[16:46:00.0000] <AryehGregor>
I'd be happy to work around the bugs, since sometimes it's useful to see what Opera does.

[16:46:01.0000] <AryehGregor>
(although I'm unlikely to change the spec solely because Opera does something, given the relevant market shares, it can still sometimes provide useful insight)

[16:46:02.0000] <gsnedders>
AryehGregor: I know vaguely what's going on in the code, but no idea how it gets into that state

[16:47:00.0000] <AryehGregor>
I don't think it's just one issue, though.  I get the impression that Opera's Selection implementation is sulky and likes to throw its hands in the air and give up if it gets slightly confused.

[16:48:00.0000] <gsnedders>
The thing that's making addRange a no-op has nothing to do with the selection impl, though

[16:48:01.0000] <AryehGregor>
What does it have to do with?  The Range implementation?

[16:49:00.0000] <gsnedders>
Far lower-level window management stuff.

[16:49:01.0000] <AryehGregor>
Oh.

[16:49:02.0000] <AryehGregor>
So it's tied to display and not just the DOM?

[16:49:03.0000] <AryehGregor>
WebKit seems to be like that too.

[16:49:04.0000] <gsnedders>
No.

[16:49:05.0000] <AryehGregor>
Hmm.

[16:49:06.0000] <gsnedders>
(Or at least I don't think so.)

[16:50:00.0000] <gsnedders>
/me asks on IRC as to why it's in that state bug expects no answer until tomorrow

[16:51:00.0000] <gsnedders>
AryehGregor: Possibly because the tests run on load and before the document is visible.

[16:51:01.0000] <AryehGregor>
gsnedders, they run before load.

[16:51:02.0000] <AryehGregor>
But so does my minimal test case, which works.

[16:52:00.0000] <gsnedders>
s/on load/while loading/ was what I meant, really

[16:52:01.0000] <gsnedders>
AryehGregor: Possibly a race-condition as to when it first displays the frame.

[16:52:02.0000] <AryehGregor>
Would make sense.

[16:55:00.0000] <gsnedders>
(As for what's visible, well, I'd say ask the person why wrote that comment, but I don't know how you can ask someone who is dead (Geir). :))

[16:55:01.0000] <gsnedders>
I'm guessing it means the obvious thing.

[16:55:02.0000] <AryehGregor>
:(

[16:58:00.0000] <gsnedders>
(Nothing apart from the obvious thing really makes sense)


2011-10-12
[17:09:00.0000] <gsnedders>
AryehGregor: Really, seems to be exactly that.

[17:12:00.0000] <gsnedders>
AryehGregor: (like, it is exactly that it's running before first-draw)

[17:13:00.0000] <Hixie>
so right now the cue start time is defined as the time at which a cue becomes relevant

[17:13:01.0000] <Hixie>
this works ok (though not great) for subtitle cues

[17:13:02.0000] <Hixie>
but for chapter cues it's a bit weirder, since chapter titles aren't only "relevant" when you're watching the chapter

[17:14:00.0000] <Hixie>
anyone got a better definition? other than the redundant "the cue start time is the time at which the cue starts"

[17:14:01.0000] <Hixie>
(the latter seems a little too tautological)

[17:30:00.0000] <TabAtkins>
That seems fine to me,a ctually.

[17:31:00.0000] <mkanat>
Is the timeline position at which the cue starts?

[17:46:00.0000] <Hixie>
foolip: yt?

[18:10:00.0000] <AryehGregor>
Hixie, you can just say "every cue has a start time" or something and treat its definition as self-evident.  I mean, that's really equivalent to saying "the cue start time is the time at which the cue start", but it doesn't sound silly.

[18:10:01.0000] <Hixie>
i went with something similar to that

[18:32:00.0000] <jarek>
Hi

[18:32:01.0000] <annevk>
roc, hey, I wondered how likely it is Full Screen will drastically change

[18:32:02.0000] <jarek>
is there any point in using SVGZ instead of SVG?

[18:32:03.0000] <jarek>
it looks like even Chrome does not support it (at least not when used from CSS)

[18:32:04.0000] <annevk>
roc, e.g. the suggested change of not having a pseudo-class but instead just rendering the specified element and descendants

[18:33:00.0000] <annevk>
jarek, what is SVGZ?

[18:33:01.0000] <jarek>
annevk: it's a file format

[18:34:00.0000] <jarek>
annevk: a gzipped SVG file

[18:34:01.0000] <jarek>
at least this is how Inkscape calls it

[18:34:02.0000] <annevk>
it seems browsers should be able to handle compression of SVG just as well as they should handle compression of HTML

[18:35:00.0000] <annevk>
if you configure the headers right and such

[18:37:00.0000] <jarek>
when I send SVG files with proper mime type I'm getting a lot of errors like this one:

[18:38:00.0000] <jarek>
"Resource interpreted as Document but transferred with MIME type image/svg+xml"

[18:38:01.0000] <jarek>
though they render perfectly fine (unlike SVGZ files)

[18:41:00.0000] <annevk>
no idea what that means

[18:43:00.0000] <jarek>
it's actually a warning, not error (it shows up in yellow in console)

[18:43:01.0000] <jarek>
I tried googling it but there are few results

[18:44:00.0000] <jarek>
seems like SVG is not that popular on the web yet

[18:45:00.0000] <shepazu>
jarek: from what I understand, depending on your server settings, you don't need to use .svgz

[18:45:01.0000] <shepazu>
typically (IIUIC) the server will compress it for transmission anyway

[18:46:00.0000] <jarek>
shepazu: so if I send SVG files and my server is configured to use gzip compression then there would be no benefits in using SVGZ?

[18:46:01.0000] <shepazu>
jarek: that is my understanding, yes

[18:47:00.0000] <shepazu>
in fact, I've heard that it can even increase the number of transferred bytes

[18:47:01.0000] <shepazu>
but I won't swear to that

[18:47:02.0000] <shepazu>
it does save file size on the server itself, of course, if that's an issue

[18:47:03.0000] <roc>
annevk: I don't think that's likely, since we've implemented that proposal

[18:47:04.0000] <roc>
more or less as it is in the wiki

[18:47:05.0000] <jarek>
is it a good idea to use SVG file as a sprite?

[18:47:06.0000] <zewt>
well, runtime compression is more expensive, but most production webservers can cache compressed files, i think

[18:47:07.0000] <TabAtkins>
As good an idea as any other image format.

[18:48:00.0000] <TabAtkins>
Relying on your server to do runtime gzip is completely fine and standard and simple.

[18:48:01.0000] <jarek>
I mean if I had embedded 100 PNG images inside single SVG then it would load much faster, right?

[18:48:02.0000] <zewt>
and you want it doing that anyway; it makes a huge difference for HTML

[18:49:00.0000] <TabAtkins>
jarek: You mean like, 100 <image>s?

[18:49:01.0000] <annevk>
roc, okay, it did seem like a nice idea to me

[18:49:02.0000] <TabAtkins>
No, that would be even slower (by a single request) than just using the 100 PNGs directly.

[18:49:03.0000] <roc>
which idea?

[18:49:04.0000] <jarek>
TabAtkins: yeah, I mean embedding, not linking

[18:49:05.0000] <TabAtkins>
jarek: How are you embedding a PNG inside an SVG?

[18:50:00.0000] <jarek>
TabAtkins: uhm... I click "Embed all images" in Inkscape...

[18:50:01.0000] <jarek>
TabAtkins: I have to investigate this more

[18:50:02.0000] <shepazu>
base64 encoding, I think

[18:50:03.0000] <zewt>
ew

[18:50:04.0000] <TabAtkins>
Ew indeed.  ^_^

[18:50:05.0000] <zewt>
i wonder how efficient deflate is at compressing base64

[18:50:06.0000] <jarek>
yeah, I suspect it inserts the binary data directly into SVG file

[18:51:00.0000] <TabAtkins>
Well, using a single SVG with 100 base64-encoded images will almost certainly be faster than 100 individual images.

[18:51:01.0000] <shepazu>
useful if you want a single file

[18:51:02.0000] <jarek>
I remember reading somewhere that you can use base64 even inside CSS

[18:51:03.0000] <TabAtkins>
jarek: Yup, data: urls are just fine in pure CSS too.

[18:51:04.0000] <zewt>
heh it's pretty good

[18:51:05.0000] <zewt>
1048576 /dev/urandom -> 1416501 base64 -> 1076454 base64.gz

[18:51:06.0000] <shepazu>
TabAtkins: I'm going to be in the valley tomorrow night through saturday, if you have time to hang out

[18:52:00.0000] <jarek>
TabAtkins: but there won't be any image rendered on the screen until the whole file with 100 images is downloaded, right?

[18:52:01.0000] <jarek>
or would the images show progressively?

[18:52:02.0000] <TabAtkins>
jarek: All-at-once.  But a single slightly-larger download is usually *significantly* faster than 100 individual downloads.

[18:55:00.0000] <annevk>
roc, of just laying out the element and its descendants and not worrying about ancestors

[18:55:01.0000] <annevk>
roc, it would make any animations easier I imagine

[18:56:00.0000] <annevk>
roc, I had another question, why does the parent browsing context Document need to be full screen if one of its child browsing context Documents is full screen?

[18:56:01.0000] <roc>
that's a fairly violent change to CSS

[18:56:02.0000] <roc>
and the layout engine

[18:56:03.0000] <roc>
and creates various issues for the CSSOM etc

[18:57:00.0000] <annevk>
okay

[18:58:00.0000] <roc>
annevk: if the parent Document is not fullscreen, I'm not sure how the child could be fullscreen

[18:58:01.0000] <roc>
unless you have magic to rip the child document out and display it apart from the parent document

[18:59:00.0000] <roc>
that has similar problems to "just laying out the element and its descendants and not worrying about ancestors"

[18:59:01.0000] <roc>
such magic is not necessary

[19:02:00.0000] <annevk>
so if you invoke fullscreen on some iframe descendant element

[19:02:01.0000] <annevk>
does that also set styles for the iframe element itself when you go full screen?

[19:02:02.0000] <roc>
yes

[19:02:03.0000] <roc>
the iframe element is the fullscreen element in its document

[19:03:00.0000] <annevk>
including all its ancestor iframes?

[19:03:01.0000] <roc>
right, all the way up

[19:03:02.0000] <annevk>
ah okay, that works

[19:14:00.0000] <dbaron>
annevk, should I reserve constants for SUPPORTS_RULE and DOCUMENT_RULE in http://wiki.csswg.org/spec/cssom-constants or should I wait?

[19:14:01.0000] <annevk>
dbaron, please go ahead

[19:14:02.0000] <annevk>
dbaron, and thanks for the update!

[19:14:03.0000] <dbaron>
(and see http://lists.w3.org/Archives/Public/www-style/2011Oct/0388.html for a bit of a mess we'll need to fix)

[19:15:00.0000] <dbaron>
annevk, WebKit uses different constants for KEYFRAMES and KEYFRAME than what they wrote in the spec

[19:15:01.0000] <dbaron>
I just followed the spec

[19:15:02.0000] <erlehmann>
jarek, i use data uris in css.

[19:15:03.0000] <dbaron>
annevk, your wiki actually followed webkit rather than the spec, but I just changed it to follow the spec

[19:15:04.0000] <annevk>
dbaron, I noticed, wfm

[19:16:00.0000] <jarek>
erlehmann: but isn't this an overkill?

[19:16:01.0000] <annevk>
dbaron, if WebKit wants to change that around they better speak up I guess

[19:16:02.0000] <jarek>
erlehmann: how can you find anything in CSS file if there huge chunks of binary data?

[19:16:03.0000] <TabAtkins>
jarek: Tell your editor not to wrap lines in CSS files.

[19:16:04.0000] <erlehmann>
jarek, i am in the process of optimizing a page that had about 100 http requests for small decorative stuff. no, it is not.

[19:17:00.0000] <erlehmann>
TabAtkins, jarek, last one i used was data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQAAAAABCAYAAAAxWXB3AAAAAXNSR0IArs4c6QAAADdJREFUOMvt00ENACAMBMGtATThjJzAmil/Dg08SfoYCRO2D+DW2ieqYIynt0my2Z7MI8FaGCkupysHEkVP6dUAAAAASUVORK5CYII=

[19:17:01.0000] <erlehmann>
that is not much.

[19:17:02.0000] <erlehmann>
(background gradient png)

[19:17:03.0000] <TabAtkins>
Oh man, you really do mean "small".

[19:18:00.0000] <dbaron>
hmmm, should I give jdaggett 13 for css3-fonts? :-)

[19:18:01.0000] <erlehmann>
indeed. and the requests held up the page.

[19:18:02.0000] <erlehmann>
dbaron, what does “13” mean here?

[19:18:03.0000] <dbaron>
just a number

[19:18:04.0000] <TabAtkins>
erlehmann: Constants for CSSRule.

[19:20:00.0000] <dbaron>
oh, wait, he already put 11 in the spec

[19:20:01.0000] <dbaron>
I can fix this

[19:23:00.0000] <dbaron>
wait, two different specs took 11

[19:24:00.0000] <annevk>
anarchy

[19:25:00.0000] <TabAtkins>
I blame tyou, annevk.

[19:27:00.0000] <erlehmann>
wat

[19:28:00.0000] <TabAtkins>
dbaron: Oh, my usage is completely unimportant.

[19:28:01.0000] <TabAtkins>
IGNORE ME.

[19:28:02.0000] <annevk>
/me wonders if TabAtkins has seen the series "Ideal"

[19:29:00.0000] <TabAtkins>
annevk: Never heard of it.

[19:29:01.0000] <annevk>
there's a charater there that uses that phrase

[19:29:02.0000] <TabAtkins>
I usually think of the Observer from Venture Brothers when I say it.

[19:29:03.0000] <erlehmann>
dbaron, how can two different specs have the same number?

[19:29:04.0000] <erlehmann>
do constants work that way?

[19:30:00.0000] <dbaron>
erlehmann, by mistake

[19:30:01.0000] <erlehmann>
yeah, but how does it … err, work?

[19:30:02.0000] <dbaron>
TabAtkins, could you reply to the email I just sent, then?

[19:30:03.0000] <erlehmann>
or did you notice it right away?

[19:30:04.0000] <dbaron>
erlehmann, neither has been implemented yet

[19:30:05.0000] <erlehmann>
oh, okay

[19:30:06.0000] <erlehmann>
that i understand

[19:30:07.0000] <TabAtkins>
dbaron: Already did!  Woo!

[19:31:00.0000] <dbaron>
TabAtkins, I think jdaggett might have beaten you

[19:31:01.0000] <dbaron>
TabAtkins, don't end up both using 14 now!

[19:31:02.0000] <TabAtkins>
We shall continue politely vacating each integer until infinity.

[19:32:00.0000] <TabAtkins>
At which point I will use infinity and he will use infinity+1.

[19:33:00.0000] <erlehmann>
then “hark! a vagrant” will make a story out of it

[19:33:01.0000] <erlehmann>
or wait, let me shoop something together

[19:33:02.0000] <erlehmann>
before going to sleep

[20:00:00.0000] <annevk>
kind of odd how the HTML WG references WHATWG revision numbers

[20:00:01.0000] <annevk>
no trust in CVS?!

[20:28:00.0000] <erlehmann>
TabAtkins, history will remember you fondly http://daten.dieweltistgarnichtso.net/pics/zeichnungen/cssconstants.png

[20:29:00.0000] <annevk>
haha

[20:29:01.0000] <annevk>
more comics please!

[20:31:00.0000] <MikeSmith>
heh

[20:32:00.0000] <MikeSmith>
great depiction of Tab

[20:32:01.0000] <annevk>
so I booked in that Avatar hotel and tried getting W3C rate

[20:32:02.0000] <MikeSmith>
looks exactly like him

[20:32:03.0000] <heycam>
haha, awesome

[20:32:04.0000] <annevk>
initially I was just "Anne van Kesteren" and had to pay $1,007.43, now it's "ms. Anne van Kesteren" and $985.52

[20:33:00.0000] <annevk>
is the W3C discount really 20 bucks?

[20:33:01.0000] <annevk>
because that's a pretty sad negotiated discount, if any

[20:33:02.0000] <erlehmann>
annevk „ms“ ?

[20:34:00.0000] <annevk>
erlehmann, rest of the world has a hard time understanding the Netherlands

[20:34:01.0000] <erlehmann>
i do not know a language in which that is shorthand for discount

[20:35:00.0000] <annevk>
oh no, it's just that when they made an update to my reservation they set my gender as well

[20:35:01.0000] <erlehmann>
but anne is a male name. and a female name.

[20:35:02.0000] <erlehmann>
i see.

[20:36:00.0000] <erlehmann>
though i wonder why they store gender at all.

[20:36:01.0000] <annevk>
oh I see what happened

[20:36:02.0000] <annevk>
initially I had a night for 80 bucks

[20:36:03.0000] <annevk>
now they made that 150 bucks

[20:36:04.0000] <annevk>
and lowered some other nights with a few bucks

[20:37:00.0000] <erlehmann>
wat

[20:37:01.0000] <annevk>
awesome

[20:38:00.0000] <erlehmann>
i do not understand a thing

[20:39:00.0000] <erlehmann>
annevk, have fun stories about gender confusion? or do people just accept their error when they get the different pronounciation?

[20:40:00.0000] <erlehmann>
i knew an anne who wrote it änne, with diacritical marks. to make sure everyone knew how to pronounce it.

[20:45:00.0000] <erlehmann>
night

[20:47:00.0000] <dbaron>
is it really pronunced änne?

[20:47:01.0000] <Hixie>
annevk: don't encourage them to use cvs, i'll never be able to work out what's going on then :-P

[21:22:00.0000] <jacobolus>
thanks all for the talk slides at http://fronteers.nl/blog/2011/10/fronteers-2011-awesome

[21:22:01.0000] <jacobolus>
bruce wins for best title

[21:23:00.0000] <paul_irish>
hahaha

[21:31:00.0000] <jacobolus>
also, I like http://infrequently.org/11/fronteers/fronteers.html#6 :p

[21:45:00.0000] <paul_irish>
superfluous quotes

[21:49:00.0000] <annevk>
dbaron, depends on how you pronounce "än" I guess :)

[21:49:01.0000] <dbaron>
annevk, like Händel or länder in German?

[21:50:00.0000] <annevk>
ah, no

[21:51:00.0000] <annevk>
it's more like the "a" in "ah"

[21:51:01.0000] <annevk>
an-ne

[21:51:02.0000] <dbaron>
that's what I thought

[21:55:00.0000] <jacobolus>
TabAtkins: http://www.xanthir.com/talks/2011-10-06/ is not rendering very well here

[21:56:00.0000] <jacobolus>
either in chrome or safari

[22:57:00.0000] <annevk>
Hixie, so if we want bindings declarative and we don't want XML syntax anymore, do we want changes to the HTML parser?

[23:40:00.0000] <Hixie>
annevk: maybe

[23:41:00.0000] <annevk>
seems like if you have a separate document for your bindings you don't really want <body> and <head> there and such

[23:44:00.0000] <annevk>
http://blog.whatwg.org/weekly-binding-components

[02:10:00.0000] <foolip>
Hixie, I'm here, but I assume you are not.

[02:12:00.0000] <annevk>
TabAtkins, could have a per-property default type for attr()

[02:12:01.0000] <annevk>
TabAtkins, but then I'm not sure having attr() is really that useful

[02:12:02.0000] <annevk>
mixing markup & style = bad

[02:40:00.0000] <hsivonen>
annevk: major apps have moved on from mixing markup and style to generating both with script so that they mix all three

[02:42:00.0000] <annevk>
point being?

[02:44:00.0000] <hsivonen>
annevk: that "mixing markup & style = bad" focuses on mixing that has been superceded by even more mixing

[02:47:00.0000] <annevk>
not universally

[02:47:01.0000] <hsivonen>
true

[02:48:00.0000] <hsivonen>
speaking of markup and style, epub readers are an interesting time warp

[02:49:00.0000] <hsivonen>
epub readers are like from the time when Lynx and Mosaic roamed on earth

[02:49:01.0000] <hsivonen>
as far as markup and style go

[04:47:00.0000] <hsivonen>
gsnedders: it turns out that it's audio that sucks in Firefox on Android--not VP8 perf: https://bugzilla.mozilla.org/show_bug.cgi?id=693905

[08:32:00.0000] <bga_>
http://colinm.org/language_checklist.html

[08:45:00.0000] <jgraham>
Fun fact: Opera has it's own special dark matter from Unite applications

[08:46:00.0000] <Ms2ger>
Ah, finally :)

[08:48:00.0000] <Ms2ger>
Anyone have opinions on isElementContentWhitespace, btw? Kill it? Keep it? Meh?

[08:52:00.0000] <jgraham>
My opinion is somewhere on the "meh" part of the spectrum

[09:50:00.0000] <dglazkov>
good morning, Whatwg!

[09:51:00.0000] <timeless>
hsivonen: cute

[09:51:01.0000] <timeless>
grr

[09:51:02.0000] <timeless>
NoScript shows an Opera icon for hsivonen 's WebM video

[09:52:00.0000] <timeless>
which clearly means that Opera conquered the webm type on this computer..

[09:57:00.0000] <zewt>
opera took a bunch of media extension associations when i installed it recently

[09:57:01.0000] <zewt>
bizarre and quicktime-esque

[10:09:00.0000] <timeless>
yeah, i think i saw you complaining

[10:28:00.0000] <zcorpan>
's' and 'd' are next to each other on a qwerty keyboard. that would theoretically make it pretty easy to typo 'id' as 'is' and vice versa. however, i didn't find a lot of instances of is= with google code search.

[10:32:00.0000] <zewt>
random musings? :)

[10:42:00.0000] <Ms2ger>
Assumed related to the xbl thread

[11:11:00.0000] <smaug____>
so, does anyone here actually like Dart?

[11:11:01.0000] <smaug____>
and if so, why?

[11:12:00.0000] <Ms2ger>
Of course!

[11:12:01.0000] <Ms2ger>
Google knows what's good for you, even if you don't!

[11:14:00.0000] <smaug____>
huh, DOM bindings for Dart are silly

[11:15:00.0000] <smaug____>
/me decides not to care about Dart and moves on

[11:59:00.0000] <jgraham>
smaug____: Oh, I thought their plan was to replace DOM with Some Other API

[12:00:00.0000] <bga_>
smaug____ aeveryone have rights to make your own wrapper

[12:01:00.0000] <smaug____>
so?

[12:01:01.0000] <jgraham>
bga_: It sucks to be Not Google if they make a wrapper that they don't test in other browsers and implement natively in Chrome

[12:01:02.0000] <jgraham>
That hasn't happened yet ofc

[12:02:00.0000] <bga_>
oh

[12:02:01.0000] <bga_>
but Google want remove js too, replace to Dart + NaCl

[12:02:02.0000] <bga_>
new standards!

[12:03:00.0000] <Ms2ger>
bga_, interesting definition of "standard"

[12:04:00.0000] <bga_>
jgraham may be they wants to make Chrome as browser for intranet

[12:04:01.0000] <timeless>
Ms2ger: the wonderful thing about standards...

[12:04:02.0000] <bga_>
and will go away from internet

[12:04:03.0000] <timeless>
> . The wonderful thing about standards is that there are so many of them to choose from.

[12:08:00.0000] <bga_>
Ms2ger btw my view of ideal dom api is var div = doc.Div(){id: 'foo', style: doc.Style(){position: eStylePos.ABSOLUTE, left: 10, top: 10}  }

[12:08:01.0000] <bga_>
no new

[12:08:02.0000] <Ms2ger>
Not mine, obviously

[12:09:00.0000] <bga_>
Ms2ger and el.beforeClick._add(_fn) el.beforeClick._del(_fn)

[12:17:00.0000] <Hixie>
foolip: i cced you on the relevant bug

[12:26:00.0000] <TabAtkins>
jacobolus: You have to give it like 10 seconds, because I wait for onload before hooking up the JS, and some of the iframes take a little while.

[12:28:00.0000] <TabAtkins>
annevk5: Yeah, I mentioned that possibility in the telcon this morning.  Seems like a lot of overhead for little benefit.

[12:28:01.0000] <jacobolus>
TabAtkins: okay, in safari I waited minutes, and now it's at this state: http://imgur.com/JJ6E8

[12:29:00.0000] <TabAtkins>
That should not take minutes.  It should take maybe 10 seconds.

[12:29:01.0000] <TabAtkins>
That is the correct "loading" appearance, though.

[12:30:00.0000] <jacobolus>
TabAtkins: in chrome, it loads and turns blue, but then as I arrow through, each slide disappears halfway through trying to appear, so I get to read a nice blank blue screen

[12:30:01.0000] <jacobolus>
there's clearly stuff moving around, etc., but I can't really read it

[12:30:02.0000] <TabAtkins>
Um, blue?

[12:33:00.0000] <jacobolus>
oh, hmm

[12:33:01.0000] <jacobolus>
https://raw.github.com/LeaVerou/Incrementable/master/incrementable.js 405s

[12:35:00.0000] <TabAtkins>
Yeah, something's wrong with your connection.  That loads <1s for me.

[12:36:00.0000] <jacobolus>
it loads fine in a separate page

[12:37:00.0000] <jacobolus>
I guess it loaded in chrome too. not sure what's wrong there

[12:37:01.0000] <jacobolus>
I've got a "Unsafe JavaScript attempt to access frame with URL http://www.xanthir.com/talks/2011-10-06/ from frame with URL http://hacks.mozilla.org/2010/08/mozelement/. Domains, protocols and ports must match."

[12:37:02.0000] <TabAtkins>
That should be irrelevant.

[12:38:00.0000] <jacobolus>
http://i.imgur.com/AJX1P.png

[12:39:00.0000] <TabAtkins>
That's all kinds of crazy.  I don't have that color anywhere in my document.

[12:39:01.0000] <jacobolus>
in firefox the first page loads, and then the rest are just blank gray

[12:43:00.0000] <TabAtkins>
Oh, hm, you're right.  Somehow the scroll position isn't being set correctly.

[12:45:00.0000] <jacobolus>
TabAtkins: in firefox, trying to load that incrementable.js file, I get an error that <!DOCTYPE html> isn't valid javascript after the server returns 301 and sends https://github.com/LeaVerou/Incrementable instead

[12:47:00.0000] <bga_>
oh. github has becomed much faster

[12:47:01.0000] <bga_>
nice

[12:49:00.0000] <jacobolus>
hm, actually maybe that's not what it sends, dunno. in any event, all the javascript ends up broken somewhere along the line, and then the slides stop working :)

[12:56:00.0000] <Hixie>
Ms2ger: why http://www.w3.org/Bugs/Public/show_bug.cgi?id=13877 ?

[12:57:00.0000] <Ms2ger>
Why not? :)

[12:57:01.0000] <Hixie>
well because we're not the text/plain spec

[12:58:00.0000] <Hixie>
so really if a UA wants to, i dunno, embed notepad to handle text files, who are we to disagree?

[12:58:01.0000] <Ms2ger>
Is that the one part of the web you aren't speccing? ;)

[12:58:02.0000] <Ms2ger>
I don't think embedding notepad without creating a document as described would be web-compatible

[12:59:00.0000] <Hixie>
yeah, that's probably true

[12:59:01.0000] <Hixie>
i guess this stuff only applies to html uas anyway

[12:59:02.0000] <Hixie>
but then again, there's not any real difference to saying "must" or "should"

[12:59:03.0000] <Hixie>
since a UA could just pretend it's not an HTML UA when it comes across a text/plain file

[13:00:00.0000] <Hixie>
then again, it couldn't do that _and_ handle it in iframes...

[13:00:01.0000] <Hixie>
so i guess it makes sense to have must

[13:00:02.0000] <Hixie>
ok

[13:02:00.0000] <Ms2ger>
And then I don't have to argue about the tests

[13:26:00.0000] <Ms2ger>
An extra word, a missing word... Same thing, really :)

[13:26:01.0000] <Hixie>
:-)

[13:47:00.0000] <TabAtkins>
annevk5: You around?  What "other specifications" could make the extension requirements?

[13:53:00.0000] <Ms2ger>
TabAtkins, the ones that define the @-rule

[13:54:00.0000] <Ms2ger>
partial interface CSSWhatever { const MY_AT_RULE = 11; }

[13:54:01.0000] <TabAtkins>
I don't understand how they can define the wiki as being the required extensibility mechanism.

[13:54:02.0000] <Ms2ger>
The wiki is just a list of pointers to specs that define extensions

[13:57:00.0000] <TabAtkins>
Shrug.  Seems easier to just define the wiki as normative.

[13:58:00.0000] <Ms2ger>
But then you've got a normative wiki page

[13:58:01.0000] <TabAtkins>
Yes?

[13:58:02.0000] <TabAtkins>
HTML has several already.

[13:59:00.0000] <Ms2ger>
If that's the fight you want to fight, sure :)

[14:00:00.0000] <Ms2ger>
Also, how high on your todo list is the scary messages on obsolete specs? :)

[14:00:01.0000] <TabAtkins>
I need to do that sometime soon.

[14:03:00.0000] <TabAtkins>
Ms2ger: Why do you ask?

[14:03:01.0000] <Ms2ger>
Just that I want it to happen :)

[14:03:02.0000] <TabAtkins>
Ah.  Well, the WG resolved to do it, so it's completely up to me at this point.

[14:11:00.0000] <annevk>
TabAtkins, a normative wiki page doesn't really have the same effect as the partial interface construct afaict

[14:12:00.0000] <annevk>
though I guess it's "clear enough"

[14:13:00.0000] <bga_>
hm. plz ppl say me why UA dont add unknown properties to cssom and many ppl are forced to make own css parser

[14:13:01.0000] <bga_>
some CSSUnknownRule will be nice

[14:14:00.0000] <bga_>
w/ string contains not parsed rule

[14:14:01.0000] <TabAtkins>
bga_: There was discussion about this not long ago on www-style.

[14:14:02.0000] <Ms2ger>
bga_, use glazou's

[14:15:00.0000] <bga_>
TabAtkins and result?

[14:15:01.0000] <TabAtkins>
It's not a good idea.

[14:15:02.0000] <bga_>
:(

[14:16:00.0000] <annevk>
still might be nice to have something akin data-* for CSS properties

[14:16:01.0000] <TabAtkins>
Yes.

[14:16:02.0000] <TabAtkins>
I think we should use exactly that name: data-*

[14:16:03.0000] <annevk>
but given how the CSS parser is defined it seems rather tricky to get the details correct

[14:17:00.0000] <TabAtkins>
Hmm?  I wouldn't think so.  You'd still have to obey the generic grammar, but that's really loose.

[14:18:00.0000] <TabAtkins>
Basically you can take anything that's a space, comma, or slash separated list of numbers, dimensions, keywords, strings, or functions.

[14:19:00.0000] <erlehmann>
what exactly would you want?

[14:19:01.0000] <TabAtkins>
erlehmann: ?

[14:20:00.0000] <erlehmann>
i do not understand how „data-“ and CSS would come together.

[14:20:01.0000] <annevk>
e.g. data-t: x tralolol /**/ whatev ;

[14:20:02.0000] <annevk>
what is its string value?

[14:20:03.0000] <erlehmann>
so how would that be used?

[14:20:04.0000] <annevk>
and how does that follow from the CSS parser?

[14:20:05.0000] <TabAtkins>
The idea is that selectors + the cascade is a pretty useful model for assigning data to elements, so we could define an author-extensible set of properties that can take anything and mean nothing.

[14:21:00.0000] <erlehmann>
like with fonts, only more general?

[14:21:01.0000] <erlehmann>
like assigning the name of a font is?

[14:21:02.0000] <TabAtkins>
annevk: cssText is defined generically (as much as it's defined at all).

[14:21:03.0000] <bga_>
annevk just get all string between : and ;

[14:21:04.0000] <bga_>
or : and }

[14:21:05.0000] <annevk>
TabAtkins, well yeah, that's a bug

[14:21:06.0000] <TabAtkins>
annevk: Really?  Why?

[14:21:07.0000] <annevk>
TabAtkins, defining cssText however is easy for properties with normal values

[14:21:08.0000] <annevk>
because you just serialize those values

[14:22:00.0000] <TabAtkins>
I mean, your example is just three keywords and a comment.

[14:22:01.0000] <annevk>
but if you don't know the value, you cannot serialize it

[14:22:02.0000] <bga_>
annevk serialize as-ai

[14:22:03.0000] <annevk>
bga_, CSS doesn't work that way

[14:22:04.0000] <bga_>
*is

[14:22:05.0000] <TabAtkins>
If you restrict it to specifically the five data types I mentioned, it's easy and still extremely useful.

[14:22:06.0000] <bga_>
++

[14:23:00.0000] <annevk>
TabAtkins, yeah that might work

[14:23:01.0000] <bga_>
TabAtkins and custom bnf grammar

[14:23:02.0000] <TabAtkins>
Hmm.  I wonder if it would be possible to do calc() under that regime.

[14:23:03.0000] <annevk>
TabAtkins, though we don't have functions currently

[14:24:00.0000] <bga_>
for your own rules

[14:24:01.0000] <bga_>
it will be like edsl :)

[14:24:02.0000] <bga_>
in css

[14:24:03.0000] <TabAtkins>
annevk: Hm?  FUNCTION is a token in the core grammar.

[14:25:00.0000] <TabAtkins>
{ident}(<any>), plus whitespace, once you combine the token and the grammar.

[14:25:01.0000] <bga_>
hm

[14:26:00.0000] <bga_>
TabAtkins => we can make interface CSSUnknownRule { CSSAst cssAst }

[14:26:01.0000] <bga_>
not cssText

[14:27:00.0000] <TabAtkins>
It's not bad just for technical reasons.  It's also bad for practical reasons.

[14:27:01.0000] <dbaron>
hmmm, if an edit Hixie just made for a w3.org bug is wrong, should I reopen the bug or reply on the whatwg mailing list...?

[14:27:02.0000] <TabAtkins>
It's a good thing for it to be painful to invent your own syntax.

[14:27:03.0000] <TabAtkins>
dbaron: Either works.

[14:32:00.0000] <dbaron>
ok, reopened http://www.w3.org/Bugs/Public/show_bug.cgi?id=13915

[14:32:01.0000] <annevk>
yeah, data-* would be kind of last resort

[14:33:00.0000] <TabAtkins>
I don't think data-* is bad.  Inventing your own properties, though, interferes with our ability to mint new properties in the future.

[14:33:01.0000] <TabAtkins>
Similarly, inventing your own values for existing properties.

[14:33:02.0000] <annevk>
I never really considered that a viable option

[14:34:00.0000] <bga_>
TabAtkins its will gives right for authors to extents css standards, make css flexible and extendsible

[14:34:01.0000] <TabAtkins>
bga_: That is *very explicitly* something we do *not* want to give to authors.

[14:35:00.0000] <TabAtkins>
annevk: That's the end result of directly exposing "invalid" properties, which is why I mention it.

[14:35:01.0000] <bga_>
ok. not standards

[14:36:00.0000] <TabAtkins>
bga_: We do not want to make CSS author-extensible in a way that makes it hard for the WG to extend it in the future.

[14:36:01.0000] <TabAtkins>
If there are safe ways to make it extensible, like data-* properties, that's fine.

[14:36:02.0000] <TabAtkins>
This is similar to how HTML defines the data-* attributes rather than allowing authors to mint whatever new attributes they want.

[14:36:03.0000] <bga_>
TabAtkins ok. force authors to use data- prefix

[14:37:00.0000] <TabAtkins>
And how the component model is proposing that components must start with x-, rather than being some arbitrary element name.

[14:37:01.0000] <bga_>
but i must have right to inject own subparser in css parser and own rule in cssom

[14:38:00.0000] <TabAtkins>
I don't see how that follows.

[14:38:01.0000] <TabAtkins>
That would be a nightmare, actually.

[14:38:02.0000] <bga_>
TabAtkins it will true extensible browser

[14:38:03.0000] <bga_>
TabAtkins i can patch dom prototypes

[14:39:00.0000] <bga_>
i can register new protocols

[14:39:01.0000] <bga_>
can create new html elements

[14:39:02.0000] <bga_>
next - new css rules

[14:39:03.0000] <RobbertAtWork>
haha, the CSSRule.register() suggestion was inevitable

[14:39:04.0000] <bga_>
:)

[14:40:00.0000] <TabAtkins>
Minting your own data-* properties is fine.  You can then read them from script and do what you want.  There's no need for anything further (and I don't think it even makes sense to go further).

[14:48:00.0000] <annevk>
https://raw.github.com/gist/933cc4f7df97d553ed89/24386c6a79bb4b31fb818b70b34c5eab7f12e1ff/gistfile1.txt is quite a fun read

[14:50:00.0000] <Peter->
https://plus.google.com/112678702228711889851/posts/eVeouesvaVX

[14:50:01.0000] <Peter->
same message, got some comments as well

[14:51:00.0000] <jgraham>
The way CSS people always talk about "The WG" makes it sound very sinister

[14:51:01.0000] <TabAtkins>
At least we're not a cabal.

[14:52:00.0000] <jgraham>
You're way more of an actual cabal than whatwg every has been

[14:52:01.0000] <jgraham>
*ever

[14:52:02.0000] <TabAtkins>
But we're not *called* a cabal.

[14:54:00.0000] <jgraham>
Well it is apparently legitimate to be one if you brand it with the W3C logo, so no one complains

[14:55:00.0000] <TabAtkins>
Now you've got it.

[15:33:00.0000] <annevk>
"What we really need is Strict Mode for the DOM: The possibility to completely re-invent all of the DOM from scratch."

[15:33:01.0000] <annevk>
I wonder when we stopped thinking that quirks mode was a bad idea

[15:33:02.0000] <annevk>
Also, from http://www.dartlang.org/articles/improving-the-dom/ it does not seem like Dart is re-inventing the DOM

[15:34:00.0000] <annevk>
It just introduces some different names for the same concepts

[15:35:00.0000] <TabAtkins>
annevk: Quirks mode is bad for different reasons than "let's rename the DOM!" is.

[15:35:01.0000] <TabAtkins>
It involves parsing differences, CSS layout differences, etc.

[15:35:02.0000] <annevk>
It's bad because mode switching like that is bad

[15:36:00.0000] <annevk>
With the epitome being the IE versioning model

[15:36:01.0000] <TabAtkins>
No.  Mode switching is expensive.  Quirks mode is bad for more reasons than just mode switching.

[15:36:02.0000] <TabAtkins>
Javascript strict mode is a mode switch that we're okay with.

[15:37:00.0000] <annevk>
You might be, I think it's quite silly

[15:37:01.0000] <TabAtkins>
A mode switch is, eventually, the only answer to "shit sucks forever".

[15:37:02.0000] <bga_>
annevk ++

[15:38:00.0000] <TabAtkins>
Either you mode switch, or you have duplicate functionality that can be used at the same time, or you just stick with the sucky stuff forever.

[15:38:01.0000] <TabAtkins>
I think those are the only three choices.

[15:39:00.0000] <annevk>
Mode switch is duplicate functionality too

[15:39:01.0000] <TabAtkins>
Yes, but the old functionality is hidden and in the unicorn future can be eventually removed.

[15:39:02.0000] <annevk>
that sounds like crock

[15:40:00.0000] <annevk>
I'm not sure why we would start believing that now

[15:40:01.0000] <TabAtkins>
Even if we cant' remove it ever, having everyone opt-in to the new stuff makes newer code easier to understand, at least.

[15:40:02.0000] <annevk>
what Google seems to be advocating is pretty much XHTML2

[15:40:03.0000] <TabAtkins>
Where eventually the definition of "newer" is "everything that anyone cares about".

[15:40:04.0000] <annevk>
minor improvement with major cost

[15:40:05.0000] <TabAtkins>
I haven't mentioned Dart at all, and am not talking about it.

[15:40:06.0000] <TabAtkins>
It's irrelevant.

[15:41:00.0000] <annevk>
I was not talking about that either

[15:41:01.0000] <TabAtkins>
My mistake, then.  Anytime someone mentions Google at the moment, they're talking about Dart.

[15:42:00.0000] <jgraham>
TabAtkins: "Dart ... it's irrelevant" - is that the official position ;)

[15:42:01.0000] <TabAtkins>
Google has no official position.  Ever.

[15:42:02.0000] <jgraham>
Uh huh

[15:43:00.0000] <paul_irish>
haha

[15:43:01.0000] <Philip`>
Is the official position that it has no official position?

[15:43:02.0000] <annevk>
paul_irish, the jQuery thing was a joke right? I wasn't sure

[15:43:03.0000] <TabAtkins>
We don't have an official position on that.

[15:43:04.0000] <TabAtkins>
annevk: Yes, it was.

[15:43:05.0000] <jgraham>
annevk: That looks quite like reinventing the DOM to me

[15:43:06.0000] <jgraham>
I mean sure it has the same concepts

[15:43:07.0000] <paul_irish>
annevk: yea

[15:44:00.0000] <jgraham>
But a totally different API

[15:44:01.0000] <annevk>
if you rename a few things, but you keep the event, node, range, exception model around you are not reinventing anything

[15:44:02.0000] <annevk>
you are just making things more confusing for authors

[15:45:00.0000] <annevk>
oh, right, in Dart I use .elements, not .children

[15:45:01.0000] <annevk>
such a win!

[15:45:02.0000] <TabAtkins>
annevk: You're completely ignoring the fact that even just the *naming* of the DOM is horribad and confusing for authors.

[15:45:03.0000] <bga_>
longer :(

[15:45:04.0000] <jgraham>
Well it also makes things worse for implementors that they don't bother to test with

[15:45:05.0000] <smaug____>
and Dart+DOM seems to manage to make naming even worse

[15:46:00.0000] <TabAtkins>
Having unique names for DOM collections different from the rest of the platform is bad.  Making them all collections is good.

[15:46:01.0000] <TabAtkins>
Having nearly a dozen DOM searching methods is bad.  Having one, which we know from experience people love to use, is good.

[15:46:02.0000] <TabAtkins>
Etc.

[15:46:03.0000] <Philip`>
/me thought Strict Mode wasn't about adding any features or syntax or renaming anything or reinventing anything, it was just about enforcing that you don't use certain dodgy features

[15:47:00.0000] <TabAtkins>
Philip`: Yeah, but it helps pave the way for new features less painfully.

[15:47:01.0000] <jgraham>
Just dealing with the language as JS is likely to be bearable because JS engines are relatively small and not that buggy. Having it also layer new stuff on top of DOM practically means that there will have to be lots of spcial casing for different browsers in the generated JS which means lots of breakage

[15:48:00.0000] <annevk>
TabAtkins, sure, simplicity is good, but it's not groundbreaking enough to do away with the old

[15:48:01.0000] <TabAtkins>
annevk: I disagree.  The pain of millions of authors struggling with the old mistakes is significant.

[15:49:00.0000] <annevk>
most authors hardly deal with the DOM so that seems somewhat overstated

[15:49:01.0000] <TabAtkins>
Yeah, because it's so sucky that everyone uses libraries.

[15:49:02.0000] <TabAtkins>
Are you using that as an argument that we don't need to fix the DOM?

[15:50:00.0000] <annevk>
I'm saying that what you are saying is not true

[15:50:01.0000] <TabAtkins>
How, precisely, is it not true?

[15:50:02.0000] <annevk>
I do think we should simplify certain constructs as should be evident from my www-dom emails

[15:51:00.0000] <bga_>
looks like wine that implemets bugs oа win32 too

[15:51:01.0000] <TabAtkins>
Authors *do* use the DOM *all the time*.  They just don't use the W3C DOM, because it blows.

[15:51:02.0000] <jgraham>
I don't understand why you think tying this to a new language is a sensible idea

[15:51:03.0000] <TabAtkins>
jgraham: I didn't say anything about that.  See my above comments about how I'm not talking about Dart.

[15:52:00.0000] <jgraham>
TabAtkins: In what way? The discussion is precisely about the DOM replacement in Dart

[15:52:01.0000] <jgraham>
If you're not talking about it, you are the only one

[15:52:02.0000] <TabAtkins>
jgraham: Not at all.  Dart happens to be provoking the discussion, but I don't give a crap about Dart.  I care about better DOM.

[15:52:03.0000] <TabAtkins>
jgraham: Um, Anne's not talking about Dart either.  By his own direct admission.

[15:53:00.0000] <smaug____>
TabAtkins: isn't the DOM4 work exactly about fixing the problems of old DOM API

[15:53:01.0000] <jgraham>
TabAtkins: So propose the better DOM APIs

[15:53:02.0000] <TabAtkins>
smaug____: In general, yes.  I think annevk is too conservative, though.  ^_^

[15:53:03.0000] <jgraham>
I haven't really seen people do that

[15:53:04.0000] <jgraham>
Apart from all the hand-wringing about what new HTMLFooElement should do

[15:53:05.0000] <TabAtkins>
jgraham: The Dart APIs are, roughly, what several of us Google engineers working on JS would like to see in DOM.

[15:53:06.0000] <bga_>
TabAtkins sometimes any even very  good software is needed to be completely rewritten

[15:54:00.0000] <smaug____>
TabAtkins: propose better DOM APIS ;)

[15:54:01.0000] <TabAtkins>
Me, Alex Russell, Erik Arvidsson, etc.

[15:54:02.0000] <jgraham>
TabAtkins: So propose them then...

[15:54:03.0000] <smaug____>
APIs

[15:54:04.0000] <krijn>
Don't fight kids!

[15:54:05.0000] <annevk>
TabAtkins, conservative how? I just think mode switching is bad idea

[15:54:06.0000] <TabAtkins>
annevk: You underestimate the aggregate pain that the sucky DOM causes to authors, and assert that nobody uses the DOM, so it's all right.

[15:55:00.0000] <jgraham>
krijn: In England we fight kids: http://www.guardian.co.uk/uk/2011/sep/21/eight-year-old-children-cage-fight-preston

[15:55:01.0000] <annevk>
I didn't say the DOM is all right

[15:55:02.0000] <krijn>
o_O

[15:56:00.0000] <jgraham>
TabAtkins: But there's no one trying to fix it. So far we have the Element.create suggestion (which I like) and the new HTMLElement suggestion (which doesn't work at all)

[15:56:01.0000] <jgraham>
That's it

[15:56:02.0000] <jgraham>
krijn: Indeed

[15:56:03.0000] <bga_>
TabAtkins how many times you deprecate oк remove some ability during dom0-dom4?

[15:57:00.0000] <annevk>
TabAtkins, anyway, what I think does not really matter, what matters so far is that there is a lot of noise, but not so much signal, about a better DOM

[15:57:01.0000] <TabAtkins>
jgraham: No one trying to fix it?  Alex and Arv have been pushing forever on making NodeList be an array, for example.

[15:57:02.0000] <bga_>
i never heard that some feature was removes

[15:57:03.0000] <smaug____>
/me is having hard time to find good things in the (dart) DOM API

[15:57:04.0000] <TabAtkins>
smaug____: I... I don't understand how that is possible.

[15:57:05.0000] <jgraham>
TabAtkins: iirc that doesn't work either

[15:57:06.0000] <annevk>
I guess tied to Dart there is some signal now, but I am personally hoping for it to be on www-dom

[15:58:00.0000] <jgraham>
It is easy to come up with unworkable ideas of course

[15:58:01.0000] <TabAtkins>
smaug____: Or pehraps you're not looking at the negative space, the fact that the Element interface is, like, a dozen methods/attributes now.

[15:58:02.0000] <krijn>
I want Element.nyanCatify()

[15:59:00.0000] <TabAtkins>
annevk: Dart is useful as a "hey look at this!", since individual feature suggestions are often shot down with "the DOM isn't really that painful" by you and others.  ^_^

[15:59:01.0000] <krijn>
annevk: btw, did we meet on Wednesday?

[16:00:00.0000] <annevk>
krijn, last week, briefly?

[16:00:01.0000] <krijn>
Hm

[16:00:02.0000] <krijn>
Don't know what was in the beer on that boat, but I'm missing some parts

[16:01:00.0000] <smaug____>
"(For mysterious reasons, these are named allinlowercase unlike the rest of the DOM.)" ?

[16:01:01.0000] <TabAtkins>
elem.onclick="..."

[16:01:02.0000] <smaug____>
what is mysterious about onfoo handlers

[16:01:03.0000] <TabAtkins>
As opposed to elem.onClick="..."

[16:02:00.0000] <smaug____>
they are all lowercase because the content attributes in HTML are lowercase

[16:02:01.0000] <TabAtkins>
We usually camelcase in JS.

[16:02:02.0000] <smaug____>
nothing mysterious there

[16:02:03.0000] <TabAtkins>
smaug____: That's not a general pattern.

[16:02:04.0000] <bga_>
TabAtkins dom isnt painful because we can completely change it api via dom prototypes. s/length/size/ for example

[16:02:05.0000] <TabAtkins>
We camelcase some things that are uncased in the content attributes.

[16:03:00.0000] <TabAtkins>
bga_: That's not a valid argument.  Libraries *can* fix anything.  They shouldn't be required, though.

[16:03:01.0000] <smaug____>
the new event registration mechanism looks also broken

[16:03:02.0000] <smaug____>
what if I want to add listener for event "foo"

[16:04:00.0000] <smaug____>
would it be then elem.on.foo.add (...)

[16:04:01.0000] <smaug____>
and that foo property would magically appear in the 'on' object

[16:04:02.0000] <bga_>
smaug____ el.onFoo.add is better

[16:05:00.0000] <smaug____>
ah, it says "we also put a subscript operator on NodeEvents."

[16:05:01.0000] <TabAtkins>
smaug____: Yes, though I think you have to use the subscript operator.

[16:05:02.0000] <TabAtkins>
elem.on['foo'].add()

[16:06:00.0000] <smaug____>
anyway, don't understand why to change onclick = value to on.click.add(value);

[16:06:01.0000] <bga_>
because its not add

[16:06:02.0000] <bga_>
its assign

[16:07:00.0000] <annevk>
smaug____, the latter allows for multiple

[16:08:00.0000] <smaug____>
I wonder where <element onclick="adlfkm"> handler appears

[16:08:01.0000] <smaug____>
ah, it does allow multiple

[16:08:02.0000] <smaug____>
but it breaks onfoo idl vs content attribute mapping

[16:08:03.0000] <smaug____>
ah, well

[16:08:04.0000] <smaug____>
I just don't care this

[16:08:05.0000] <smaug____>
won't implement any of this stuff anyway

[16:08:06.0000] <bga_>
smaug____ my friend made small monkey patch which replace on* properties to setters which calls addEventLisneters

[16:09:00.0000] <smaug____>
bga_: how does that work?

[16:09:01.0000] <smaug____>
er

[16:10:00.0000] <smaug____>
ah, yes, defineProperty or some such

[16:10:01.0000] <bga_>
yes

[16:10:02.0000] <smaug____>
replacing Element.property.onclick by assigning a new value wouldn't ofc work

[16:10:03.0000] <bga_>
smaug____ but its points vector

[16:10:04.0000] <arv>
One of the goals with the on property was to unify the onfoo and the addEventListener("foo") mess

[16:11:00.0000] <smaug____>
what is the mess with onfoo and addEventListener?

[16:12:00.0000] <TabAtkins>
onfoo is annoying because it can only accept a single listener.  However, it's short, while addEventListener is super-verbose and painful.

[16:12:01.0000] <arv>
I assume you think it is good to have 2 different ways? I know there are minor differences but who cares?

[16:12:02.0000] <TabAtkins>
You want short and easy for such a common thing.  You also want a single way to do it if possible.

[16:12:03.0000] <smaug____>
how is addEventListener painful?

[16:13:00.0000] <smaug____>
ok, it is a bit long method name, but that is all

[16:13:01.0000] <arv>
and having strings as type sucks because it does not catch typos

[16:13:02.0000] <TabAtkins>
"That is all"?  That's the whole problem.  The DOM is stuffed full of painfully long names for no reason.

[16:13:03.0000] <TabAtkins>
That just makes your code huge and hard to both type and read.

[16:13:04.0000] <smaug____>
you elem.on['foo'] doesn't catch typos either

[16:13:05.0000] <smaug____>
yuor

[16:13:06.0000] <smaug____>
your

[16:14:00.0000] <smaug____>
:)

[16:14:01.0000] <dominicc|home>
and boolean parameters make understanding call sites harder

[16:14:02.0000] <TabAtkins>
It's impossible to catch typos in arbitrary user-creted events, obviously.

[16:14:03.0000] <arv>
That is all? Seriously. You don't think it is flawed in any other way than the length?

[16:14:04.0000] <TabAtkins>
Oh god, I completely forgot abotu the boolean parameter in aEL.  >_<

[16:14:05.0000] <smaug____>
dominicc|home: you don't need to use boolean parameters with add/removeEventListener

[16:14:06.0000] <bga_>
1st what you can do is make Element.prototype.on = Element.prototype.addEventListener

[16:14:07.0000] <TabAtkins>
...yes you do.

[16:14:08.0000] <TabAtkins>
If you don't use it, it's a violation, and makes FF angry.

[16:14:09.0000] <smaug____>
there is no need to use boolean parameter

[16:14:10.0000] <smaug____>
no

[16:15:00.0000] <arv>
ff was fixed so, it is a step in the right direction

[16:15:01.0000] <arv>
but

[16:15:02.0000] <arv>
still

[16:15:03.0000] <TabAtkins>
Ah, wasn't aware it was fixed.

[16:15:04.0000] <arv>
reading a true or false at the end is still painful for the cases where it does matter

[16:15:05.0000] <annevk>
wait are we looking at DOM4 or Firefox?

[16:15:06.0000] <smaug____>
spec was fixed (and then gecko started to follow the spec)

[16:15:07.0000] <dominicc|home>
They’re optional I think. But still there… MDN says Mozilla has a second optional bool now.

[16:15:08.0000] <TabAtkins>
Still, seeing "someMethod(foo, bar, true)" kills me.

[16:15:09.0000] <annevk>
because that's been optional since forever

[16:16:00.0000] <TabAtkins>
dominicc|home: Oh jeezus.

[16:16:01.0000] <smaug____>
they were may optional actually because it was a bug in webkit that it allowed to leave out the last parameter :)

[16:16:02.0000] <smaug____>
s/may//

[16:17:00.0000] <dominicc|home>
So addEventListener has many infelicities.

[16:17:01.0000] <arv>
WebKit just followed common js practice. Makes me smile every time when that happens

[16:17:02.0000] <arv>
(but it does not happen often enough)

[16:17:03.0000] <smaug____>
and not following the spec?

[16:17:04.0000] <smaug____>
and not even filing spec bug

[16:17:05.0000] <arv>
The specs should follow reality, not the other way around

[16:18:00.0000] <annevk>
it's nice to tell the spec list if you think reality has shifted though

[16:18:01.0000] <smaug____>
is webkit the reality ?

[16:18:02.0000] <annevk>
also

[16:18:03.0000] <annevk>
webkit is changing their practice

[16:18:04.0000] <annevk>
and making arguments required

[16:19:00.0000] <annevk>
so it's not as simple as you say

[16:19:01.0000] <arv>
nothing is as simple as I say

[16:19:02.0000] <annevk>
that fourth addEventListener argument is something Mozilla did not propose anywhere btw smaug____

[16:19:03.0000] <TabAtkins>
Not even the DOM.

[16:21:00.0000] <smaug____>
annevk: very true. But if I do something wrong doesn't make it ok for others to do wrong  ;)

[16:21:01.0000] <smaug____>
and unfortunately 4th parameter was added long ago

[16:21:02.0000] <arv>
 annevk: I'm well aware that it is hard work to spec these things and I appreciate all the good work you (and others) are doing

[16:22:00.0000] <arv>
One of the reasons why we chose to experiment with this in the Dart DOM was because we could do this without the risk of not breaking anything since there is no Dart code out there

[16:23:00.0000] <dominicc|home>
arv: And since Dart is "developer preview" you expect to be able to make breaking changes for a while, right?

[16:24:00.0000] <arv>
and we were tired of doing another blind webidl to dart conversion which would fit dart as badly as webidl fits js today

[16:24:01.0000] <arv>
do

[16:24:02.0000] <arv>
m 

[16:24:03.0000] <arv>


[16:24:04.0000] <arv>
dominicc|home: yes

[16:24:05.0000] <smaug____>
what is wrong with webidl <-> js?

[16:25:00.0000] <TabAtkins>
smaug____: WebIDL still encourages horrifyingly bad impedance mismatch with what good JS APIs should be.

[16:26:00.0000] <smaug____>
really?

[16:26:01.0000] <annevk>
I don't really mind Dart that much. What I mind is all the screaming that the DOM is broken and then either not proposing anything or coming up with proposals that are unworkable when you look at the details.

[16:26:02.0000] <annevk>
And of course there are some more constructive proposals too, e.g. from Ojan, so it's not all bad.

[16:26:03.0000] <arv>
annevk: I totally agree with that point. There are too many haters out there

[16:27:00.0000] <arv>
Also Ojan is awesome =D

[16:27:01.0000] <annevk>
TabAtkins, yeah, I hear that all the time, "omgwtfbbq Web IDL is terrible"

[16:28:00.0000] <annevk>
please do propose a workable alternative or just appreciate the fact it's so much vastly better than what we had before

[16:28:01.0000] <TabAtkins>
annevk: I know it's vastly better than what we had before.

[16:28:02.0000] <TabAtkins>
It's not perfect, though, dammit!

[16:31:00.0000] <smaug____>
TabAtkins: but really, what is bad in WebIDL?

[16:31:01.0000] <TabAtkins>
arv would be able to answer better than I, but in general it's still relatively hard to design properly idiomatic APIs in WebIDL.

[16:31:02.0000] <smaug____>
(I apparently just don't know why people are complaining about WebIDL)

[16:33:00.0000] <arv>
One of the problem with WebIDL is that it is language neutral which leads to impedance mismatch. For example, webidl attributes almost always have side effects and as such needs to be done as getters and setters to follow JS semantics. Some of these things are hidden in prose in webidl

[16:34:00.0000] <arv>
other things include interceptors which cannot be done in JS without ES6 proxies

[16:35:00.0000] <dominicc|home>
arv: And your contention is that, because the attribute setters have side effects, it would be more idiomatic in JS if they were functions?

[16:35:01.0000] <arv>
dominicc|home: JS has setters and getters (unlike java which uses getFoo and setFoo)

[16:36:00.0000] <dominicc|home>
arv: Right. So… what is the problem with mapping attributes to getters and setters?

[16:36:01.0000] <rniwa>
Hixie: ping

[16:36:02.0000] <Hixie>
pong

[16:36:03.0000] <arv>
yes, and this is being taken care of in the latest webidl spec

[16:37:00.0000] <rniwa>
Hixie: i'm confused about your comment on https://bugs.webkit.org/show_bug.cgi?id=68610

[16:37:01.0000] <rniwa>
Hixie: are you saying that itemtype is a space-separated list of types?

[16:37:02.0000] <rniwa>
Hixie: or are you saying it is not

[16:37:03.0000] <Hixie>
it is now a space-separated list of types

[16:37:04.0000] <Hixie>
as of about 24 hours ago

[16:37:05.0000] <rniwa>
:(

[16:39:00.0000] <annevk>
arv, do you mean in Web IDL the specification or in the language it defines?

[16:39:01.0000] <rniwa>
Hixie: ok, but I'm more inclined to prefix all attributes now

[16:39:02.0000] <Hixie>
heh

[16:39:03.0000] <rniwa>
I thought the spec was relatively stable but apparently not

[16:40:00.0000] <Hixie>
it should be a backwards-compatible change for any existing content

[16:40:01.0000] <arv>
annevk: I'm not fully sure. Can you clarify that question?

[16:40:02.0000] <rniwa>
that seems to indicate that there's a chance we'll have incompatible changes in the future

[16:40:03.0000] <rniwa>
or that we might end up wanting to make incompat. changes but can't due to backward compat.

[16:40:04.0000] <Hixie>
rniwa: we make changes to things that have been "stable" for 15 years sometimes

[16:40:05.0000] <Hixie>
rniwa: doesn't mean it won't change

[16:40:06.0000] <rniwa>
Hixie: does any other vendor besides WebKit implement this?

[16:40:07.0000] <Hixie>
rniwa: what i try to ensure is that changes don't break shipped code

[16:41:00.0000] <Hixie>
rniwa: opera may, not sure (foolip?)

[16:41:01.0000] <annevk>
arv, is it a problem that specifications need to use "attribute DOMString x;" for what is essentially a getter/setter? Or is it a problem with how Web IDL defines "attribute"?

[16:42:00.0000] <arv>
annevk: I would have been happier if the specification was done in ES5 code

[16:42:01.0000] <arv>
annevk: I think the part that explains how to map Web IDL to ES5 already says that they should be implemented as getters and setters on the prototype.

[16:42:02.0000] <smaug____>
rniwa: microdata?

[16:43:00.0000] <smaug____>
rniwa: there is a patch for gecko, but it needs to be updated ...

[16:43:01.0000] <rniwa>
smaug____: ok. are you prefixing attributes?

[16:43:02.0000] <rniwa>
smaug____: or new methods on Document/Element?

[16:43:03.0000] <annevk>
how would you enforce any kind of consistency if specifications need to define all the ES details themselves?

[16:43:04.0000] <smaug____>
/me is looking at the patch

[16:44:00.0000] <Hixie>
rniwa: prefixing attributes doesn't solve this, btw

[16:44:01.0000] <Hixie>
rniwa: it just adds even more trouble, with authors having to use multiple apis

[16:44:02.0000] <annevk>
Opera is unprefixed fwiw

[16:44:03.0000] <rniwa>
Hixie: yeah but it'll at least discourage ppl from widely deploying it until we remove prefixing

[16:44:04.0000] <smaug____>
optional_argc] nsIDOMNodeList  getItems([optional] in DOMString types);

[16:44:05.0000] <Hixie>
rniwa: we don't _want_ to discourage people

[16:45:00.0000] <Hixie>
smaug____: it's itemType that's changed, not getItems()

[16:45:01.0000] <rniwa>
Hixie: well, I'd like to discourage until API is stable

[16:45:02.0000] <Hixie>
rniwa: the API won't be stable for decades

[16:45:03.0000] <rniwa>
smaug____: no prefixes then?

[16:45:04.0000] <Hixie>
rniwa: and then it'll be obsolete

[16:45:05.0000] <rniwa>
Hixie: I disagree.

[16:45:06.0000] <Hixie>
rniwa: what do you mean by "Stable"?

[16:45:07.0000] <rniwa>
Hixie: by stable, I mean that it won't have radial changes like WebSocket did

[16:45:08.0000] <smaug____>
rniwa: in the patch I don't see prefixes

[16:46:00.0000] <rniwa>
smaug____: ok, I guess we can follow the same suite then

[16:46:01.0000] <rniwa>
smaug____: btw, would you mind giving me the bugzilla url

[16:46:02.0000] <TabAtkins>
rniwa: "radical" meaning what?  The sensible definition is "not backwards-compatible".

[16:46:03.0000] <smaug____>
rniwa: https://bugzilla.mozilla.org/show_bug.cgi?id=591467

[16:46:04.0000] <Hixie>
rniwa: i will never make radical changes like websocket. that was a travesty.

[16:46:05.0000] <rniwa>
smaug____: so that I can post it on WebKit's bugzilla

[16:46:06.0000] <Hixie>
rniwa: and the ietf can be entirely blamed for that

[16:46:07.0000] <TabAtkins>
By that definition, this change is not radical.

[16:46:08.0000] <rniwa>
TabAtkins: this was not

[16:46:09.0000] <Hixie>
we should never have moved websocket to ietf

[16:47:00.0000] <Hixie>
it literally delayed us by a year

[16:47:01.0000] <rniwa>
smaug____: wow! you're implementing all of it in one patch?

[16:47:02.0000] <Hixie>
we'd have compression and multiplexing by now if we'd stayed at whatwg

[16:47:03.0000] <Hixie>
but anyway

[16:47:04.0000] <smaug____>
rniwa: I don't know much about it

[16:47:05.0000] <Hixie>
water under the bridge

[16:47:06.0000] <smaug____>
hsivonen would know

[16:47:07.0000] <smaug____>
but I guess it is late for him

[16:48:00.0000] <smaug____>
(for some reason it is not that late for me although I live in the same city as hsivonen )

[16:49:00.0000] <Hixie>
heh

[16:57:00.0000] <annevk>
arv, basically, IDL handles a whole bunch of details that specifications do not need to take care of now and because of IDL they are taken care of consistently; is your idea that we should replace all that by just having "raw" ECMAScript definitions for each method in specifications?

[16:57:01.0000] <annevk>
arv, because to me such an idea sounds like it will lead to a hell of a lot more prose and less consistency across specifications

[16:59:00.0000] <arv>
annevk: I can see that. Since Web IDL has type annotations and JS does not.


2011-10-13
[17:00:00.0000] <arv>
annevk: one of the benefits I see though is that it would prevent new APIs that cannot be expressed in JS without proxies

[17:00:01.0000] <annevk>
yeah, that is the biggest win

[17:02:00.0000] <TabAtkins>
Clearly we should write idl in Dart.

[17:02:01.0000] <annevk>
arv, I don't know what proxies are

[17:03:00.0000] <annevk>
arv, what APIs cannot be expressed in JS? Last time this came up Brendan discussed things such as document.all

[17:03:01.0000] <arv>
annevk: Proxies are interceptors

[17:03:02.0000] <Hixie>
(what's wrong with APIs not being implementable in JS? We don't want JS to implement them, we want browsers to implement them. They only need to be _usable_ from JS.)

[17:04:00.0000] <arv>
arv: Yah, things like HTMLCollection and all other collections in DOM

[17:04:01.0000] <arv>
arv: Other things include dataSet (I don't remember the interface name)

[17:05:00.0000] <arv>
I want JS to be able to host the DOM. I think the right thing to do is to fix JS in this case though

[17:06:00.0000] <Hixie>
why on earth would you want JS to be able to host the DOM?

[17:06:01.0000] <Hixie>
the requirements for doing that seem like a whole bunch of things that aren't useful for general purpose web authoring

[17:06:02.0000] <Hixie>
so that seems like a very odd thing to prioritise

[17:07:00.0000] <smaug____>
https://github.com/andreasgal/dom.js/

[17:07:01.0000] <arv>
Consistency. No more alien behavior

[17:07:02.0000] <Hixie>
consistency is not a goal

[17:07:03.0000] <arv>
smaug____: Andreas uses proxies

[17:07:04.0000] <smaug____>
indeed

[17:07:05.0000] <smaug____>
for implementation

[17:07:06.0000] <arv>
smaug____: Which we created for this purpose

[17:07:07.0000] <arv>
smaug____: and other use cases of course

[17:08:00.0000] <TabAtkins>
Being unable to write a library with functionality similar to the native DOM is bad.

[17:08:01.0000] <zewt>
(well, the interface of an API should always be implementable in JS; the underlying functionality not so much, of course)

[17:09:00.0000] <Hixie>
TabAtkins: you can write a library with functionality similar to the native DOM, but I disagree with the premise that if you couldn't that would be bad. Why would it be bad?

[17:10:00.0000] <TabAtkins>
Hixie: You couldn't do so, before we added proxies.

[17:10:01.0000] <Hixie>
sure you could, for some value of "similar"

[17:10:02.0000] <TabAtkins>
Hixie: It's bad because it means that libraries are forever different and possibly substandard to the native version.

[17:10:03.0000] <Hixie>
why is that bad

[17:10:04.0000] <zewt>
how is it not bad?

[17:10:05.0000] <TabAtkins>
Yes.

[17:11:00.0000] <annevk>
I'm also having a hard time seeing why it's bad.

[17:11:01.0000] <zewt>
for example, i should be able to implement standardized, drop-in-compatible APIs in JS, as far as is possible given their underlying functionality

[17:11:02.0000] <Hixie>
zewt: why???

[17:12:00.0000] <Hixie>
has anyone actually got an argument here that explains why we would ever want proxies or all this "self-hosting js dom" stuff other than a flat assertion that we should?

[17:12:01.0000] <zewt>
(eg. implementing things like the hidden attribute on browsers that don't support it yet, as an obvious and simple example)

[17:12:02.0000] <annevk>
We don't apply that principle anywhere else. E.g. as we discussed earlier with CSS exposing access for any kind of property is not going to fly.

[17:13:00.0000] <Hixie>
we don't make it possible for authors to implement http in a web browser

[17:13:01.0000] <Hixie>
or implement css

[17:13:02.0000] <TabAtkins>
Hixie: I don't understand how you don't understand why having magical syntax capabilities that only the native platform can use is bad.

[17:13:03.0000] <zewt>
^

[17:13:04.0000] <TabAtkins>
Um, neither of those are turing-complete languages.

[17:13:05.0000] <zewt>
it seems to obvious to me that I don't know how to explain it further, heh

[17:14:00.0000] <TabAtkins>
Also, it turns out there may actually be a performance win from hosting the DOM in pure JS, since you're not having to call across FFI boundaries.

[17:14:01.0000] <annevk>
TabAtkins, what makes it being turing-complete relevant?

[17:14:02.0000] <zewt>
APIs exposed to JS should be using the *same vocabulary as the language itself*

[17:14:03.0000] <TabAtkins>
annevk: DSLs are not the same thing as full languages.

[17:14:04.0000] <Hixie>
(imho proxies in js are a terrible idea, fwiw. they are massively complex and don't provide anything authors actually need. I'm all for providing things like getters and setters, and maybe syntax to make some members private or have "real" classes, but having an API that lets you fiddle with the low-level bits of objects is just asking for authors to shoot themselves in the feet.)

[17:15:00.0000] <TabAtkins>
Hixie: Things like proxies are useful for reimplementing the DOM.  They're also useful for other things.  Almost any feature that could be a magical native feature could be useful somewhere else too.

[17:15:01.0000] <Hixie>
TabAtkins: every platform has capabilities only the native platform has. e.g. only the kernel can allocate memory to a process. What's wrong with that?

[17:15:02.0000] <zewt>
(don't know anything about proxies; I'm only talking at the JS language level)

[17:15:03.0000] <smaug____>
from implementation point of view implementing DOM using a "safe" (!= C++) language would be good. JS is such a safe language, and browser devs happen to be familiar with it.

[17:15:04.0000] <smaug____>
bu that is all just implementation detail

[17:16:00.0000] <TabAtkins>
The kernel isn't a programming language.  We're talking syntax.

[17:16:01.0000] <smaug____>
but yes, performance can be also better when implemented in JS

[17:16:02.0000] <zewt>
Hixie: anyone can implement a function with the same API as malloc/free or brk, though

[17:16:03.0000] <TabAtkins>
Functionality can be special and magical; by definition, some it has to be.  Syntax doesn't need to be, though.

[17:16:04.0000] <Hixie>
syntax is basically irrelevant to anything, imho

[17:16:05.0000] <annevk>
TabAtkins, still not an argument

[17:16:06.0000] <Hixie>
who cares what the syntax is

[17:17:00.0000] <TabAtkins>
And that's fundamentally why you're wrong, Hixie.

[17:17:01.0000] <annevk>
TabAtkins, in reply to "not the same"

[17:17:02.0000] <Hixie>
it's like people who say that they prefer python to perl or whatever because it has spaces indenting or doesn't or whatever

[17:17:03.0000] <Hixie>
who cares

[17:17:04.0000] <zewt>
what?

[17:17:05.0000] <Hixie>
TabAtkins: so far your argument has consistent of no more than an assertion, so i'm pretty confident that i'm not wrong :-)

[17:17:06.0000] <Hixie>
consisted

[17:18:00.0000] <Hixie>
or at least, that you haven't in any way provided a reason why i should think that i'm wrong

[17:18:01.0000] <TabAtkins>
annevk: A DSL has a special, limited purpose.  It's not meant as a general-purpose computing language.  It does one thing and does it well.

[17:18:02.0000] <Hixie>
JavaScript is not meant as a general-purpose computing language.

[17:18:03.0000] <TabAtkins>
A general purpose computing language is, well, general-purpose.

[17:18:04.0000] <Hixie>
It's a language for writing Web apps.

[17:18:05.0000] <annevk>
TabAtkins, you are just explaining what a DSL is, you are not giving an argument

[17:18:06.0000] <zewt>
i should be able to implement a class with a drop-in-compatible interface to, say, IDB or Blob or any other API, and pass the object to something that expects that API, and make it work; if that's impossible because the API is something that can't be expressed in JS itself, that's a flaw

[17:18:07.0000] <Hixie>
zewt: i strongly disagree with that

[17:18:08.0000] <zewt>
why/

[17:19:00.0000] <zewt>
also ?

[17:19:01.0000] <TabAtkins>
I strongly agree with zewt, and think you're a bad person for disagreeing, Hixie.

[17:19:02.0000] <hober>
Consider the desire to write a polyfill library

[17:19:03.0000] <zewt>
heh

[17:19:04.0000] <TabAtkins>
^_^

[17:19:05.0000] <Hixie>
zewt: you should absolutely _not_ be able to create an API that fakes a native, privileged object. That ways lies security nightmares.

[17:19:06.0000] <zewt>
how so?

[17:19:07.0000] <hober>
you write the library in js and want it to be a drop-in replacement for the equivalent dom feature

[17:19:08.0000] <zewt>
if your security model depends on not being able to have the same interface as some native object, your security model is deeply broken

[17:20:00.0000] <zewt>
that doesn't even make sense

[17:20:01.0000] <mkanat>
zewt: The security model does depend on people not being able to replace certain objects themselves, though.

[17:20:02.0000] <TabAtkins>
annevk: People do not expect to be able to self-host DSLs.

[17:20:03.0000] <zewt>
this is simple duck typing (as it's called in Python, at least)

[17:20:04.0000] <zewt>
caring about the interface and not the object type

[17:20:05.0000] <Hixie>
i don't even know where to begin in explaining why it's a bad idea to be able to replace native objects

[17:20:06.0000] <Hixie>
take Event for example

[17:20:07.0000] <TabAtkins>
annevk: Largely because, since a DSL is designed for a specific domain by definition, self-hosting is virtually never that domain.

[17:20:08.0000] <Hixie>
dispatching an Event has all kinds of special infrastructure

[17:20:09.0000] <Hixie>
like whether the event is trusted

[17:21:00.0000] <Hixie>
what phase the event is in

[17:21:01.0000] <Hixie>
etc

[17:21:02.0000] <annevk>
you are not making sense

[17:21:03.0000] <annevk>
TabAtkins that is

[17:21:04.0000] <Hixie>
a real (native) Event object implements all that machinery in a way that the UA knows it can trust

[17:21:05.0000] <zewt>
obviously we're not talking about passing reimplementations to native methods

[17:21:06.0000] <Hixie>
you can't just fake an Event and dispatch it

[17:21:07.0000] <TabAtkins>
annevk: I don't know what else to say.  ;_;  You asked me why a DSL doesn't need to be able to self-host.  I explained why.

[17:21:08.0000] <Hixie>
zewt: "obviously" nothing

[17:21:09.0000] <Hixie>
zewt: i have no idea what you're talking about!

[17:21:10.0000] <zewt>
no, obviously, we're talking about *within javascript*, not to native non-JS methods

[17:22:00.0000] <TabAtkins>
Hixie: Pay attention to zewt's example.  Look at IDB, for example

[17:22:01.0000] <Hixie>
zewt: ok let's reset this conversation. what is it you want to do?

[17:22:02.0000] <Hixie>
zewt: that you can't do without JS being all kinds of more complicated?

[17:22:03.0000] <TabAtkins>
Being able to fake idb via some other mechanism to polyfill older browsers is a Good Thing(tm).

[17:22:04.0000] <Hixie>
i have no idea what "idp" and "polyfill" are

[17:22:05.0000] <Hixie>
"idb"

[17:22:06.0000] <TabAtkins>
IndexedDB.

[17:22:07.0000] <TabAtkins>
Polyfilling.  Shimming.  Whatever.

[17:22:08.0000] <hober>
use case: this browser doesn't support the new form validation dom api. i want to have a drop-in replacement "formvalidationapi.js"

[17:22:09.0000] <TabAtkins>
The fact that you don't know this word is a strong indicator that you're out of touch with webdev needs.  ^_^

[17:23:00.0000] <Hixie>
o_O

[17:23:01.0000] <zewt>
i didn't know that word D:

[17:23:02.0000] <TabAtkins>
Polyfilling = using JS in an older browser to fake a feature that isn't implemented in the old browser yet.

[17:24:00.0000] <TabAtkins>
Allowing you to pretend that the new feature exists everywhere.

[17:24:01.0000] <Hixie>
if the use case we're talking about is "i want to reimplement the API that the UA doesn't provide because it's an old API" then the solution is IMHO not to reimplement the API but to provide an API of your own that abstracts away what background API exists

[17:24:02.0000] <Hixie>
don't just reimplement whatever shit i came up with

[17:24:03.0000] <zewt>
strongly disagree

[17:24:04.0000] <TabAtkins>
No, that's wrong.  That way means that we live with libraries forever, or someday make a painful migration back to native.

[17:24:05.0000] <Hixie>
(or even better, just wait til it's implemented everywhere)

[17:24:06.0000] <TabAtkins>
We want to work with the native stuff.

[17:25:00.0000] <zewt>
i want to implement the standard API (or as close as I can get) in a self-contained way that I can drop in on browsers that need it, and forget about it, and then other code (that other people may have to read) don't have to learn my new special wrapper API, it just uses the standard one that everyone knows

[17:25:01.0000] <Hixie>
adding a whole bunch of complexity to the platform purely so that in the future, new APIs can be shimmed by script, seems like an incredible waste of time

[17:25:02.0000] <Hixie>
(frankly, if we're creating APIs that you _can_ shim, then we're clearly not adding APIs that matter)

[17:25:03.0000] <TabAtkins>
...

[17:26:00.0000] <TabAtkins>
I don't understand you at all, Hixie.

[17:27:00.0000] <Hixie>
ditto :-)

[17:27:01.0000] <TabAtkins>
That seems to argue that there's no reason to every make a convenience api, if it's at all possible for a library, no matter how complex, to implement the same functionality.

[17:27:02.0000] <zewt>
lots of APIs can be implemented in JS that you really don't want to if you can help it (obvious examples being performance-critical stuff, like SHA-1 and crypto)

[17:28:00.0000] <Hixie>
i'm strongly inclined to avoid adding convenience APIs and performance-critical stuff should just be implemented in JS and JS should be fast enough

[17:28:01.0000] <zewt>
wow, we just diverged from reality by about a light year :)

[17:28:02.0000] <Hixie>
hey, you're the one who wants JS to be able to fake native code!

[17:28:03.0000] <TabAtkins>
Everything you  have just said is wrong-headed, Hixie.

[17:28:04.0000] <Hixie>
TabAtkins: i'm eager to hear your arguments showing how that is the case

[17:29:00.0000] <arv>
Take dataSet for example, it adds no new semantic value. Only convenience. But since it requires interceptors/proxies it cannot be emulated in older browsers

[17:29:01.0000] <Hixie>
TabAtkins: but so far all you've done is ad hominem and argument from assertion

[17:29:02.0000] <zewt>
i'm the one who wants to be able to implement APIs as fallbacks when I have to, for compatibility; i certainly do want to be able to use ones with decent native performance when they're available

[17:30:00.0000] <Hixie>
zewt: i don't see why the shims have to implement the native APIs perfectly down to the last "readonly" or whatnot. JS today is quite close enough for shim purposes.

[17:30:01.0000] <arv>
...and if you wrap it in another library all platforms, now and forever suffer the extra latency of downloading that library

[17:30:02.0000] <Hixie>
not now and forever, only now and up to when the API is widely implemented

[17:31:00.0000] <arv>
Hixie: es5 is not close enough

[17:31:01.0000] <Hixie>
(it's not like that latency is that big a deal -- measure it)

[17:31:02.0000] <Hixie>
arv: do you have any examples of how it is not close enough?

[17:31:03.0000] <zewt>
Hixie: i'm not saying it needs to be an exact implementation (i did say "as close as I can get"); I'm saying implementing the APIs is a generally useful thing to be able to do

[17:31:04.0000] <Hixie>
arv: (i think es3 was close enough)

[17:31:05.0000] <arv>
Hixie: so you expect people to go back and update web pages?

[17:31:06.0000] <Hixie>
arv: ones that are still used? yeah. the web moves on.

[17:32:00.0000] <arv>
element.dataSet.newProperty = newValue; // try to emulate that

[17:32:01.0000] <Hixie>
arv: (apps aren't like docs in that regard)

[17:32:02.0000] <arv>
Hixie: fair enough

[17:32:03.0000] <zewt>
(being able to implement them more closely is a good thing, and the bits where we can't I'd consider flaws, but whether they're enough of flaws to spend a lot of engineering fixing is a different question)

[17:32:04.0000] <Hixie>
arv: just use setAttribute('data-new-property') until it's widely available. next?

[17:32:05.0000] <arv>
Hixie: but more and more docs have jQuery in them

[17:32:06.0000] <TabAtkins>
Hixie: No, I haven't, but you dont' seem to be understanding me well enough.  So, let's try again.

[17:32:07.0000] <arv>
Hixie: so why did we add dataSet then?

[17:33:00.0000] <Hixie>
arv: i thought we were talking about cases where people _weren't_ useing libraries?

[17:33:01.0000] <Hixie>
arv: for convenience in 10 years

[17:33:02.0000] <TabAtkins>
!_!

[17:33:03.0000] <Hixie>
same reason we add new CSS features

[17:33:04.0000] <TabAtkins>
And with sufficient JS powers, we can achieve convenience *today*.

[17:33:05.0000] <arv>
Hixie: my point re jquery was that most content today are more than just static pages

[17:34:00.0000] <Hixie>
arv: that's _clearly_ not the case.

[17:34:01.0000] <Hixie>
arv: the vast majority of content is docs

[17:34:02.0000] <Hixie>
arv: without script at all

[17:34:03.0000] <Hixie>
arv: other than ads and analytics

[17:34:04.0000] <Hixie>
TabAtkins: why does it matter if we get the convenience at t=-5y, t=0, or t=5y?

[17:35:00.0000] <TabAtkins>
t=5y is five years away!

[17:35:01.0000] <Hixie>
so?

[17:35:02.0000] <Hixie>
5 years ago today was five years away

[17:35:03.0000] <zewt>
not all of us are vampires

[17:35:04.0000] <TabAtkins>
We don't have infinite time to wait for things!  We often dont' even have moderate finite amounts of time!

[17:35:05.0000] <annevk>
Got to love the IE blog " WebVTT  originated from W3C discussions last year after a need for simple caption authoring was identified."

[17:35:06.0000] <zewt>
wait do vampires age, i'm not a vampireologist

[17:35:07.0000] <Hixie>
impatience is _certainly_ not the reason to add orders of magnitude of complexity to the platform

[17:36:00.0000] <TabAtkins>
If you characterize it as "impatience", you'll never see the value in it of course.

[17:36:01.0000] <Hixie>
if you're impatient, you'll never see the value in waiting? :-)

[17:37:00.0000] <Hixie>
seriously, the web moves so fast these days compared to any point in the past, it's incredible that there are still people who want it to move faster

[17:37:01.0000] <TabAtkins>
Now is always better than later.  The faster you can innovate in one area, the faster innovation happens everywhere else.

[17:37:02.0000] <zewt>
patience doesn't enter into it; a page that I have to write today I have to write today, I don't get to tell my boss "let's wait five years"

[17:37:03.0000] <Hixie>
we're probably the fastest moving industry there is

[17:37:04.0000] <Hixie>
there's such a thing as going _too_ fast, imho :-)

[17:37:05.0000] <TabAtkins>
I'm trying to force the Singularity here, dammit!

[17:37:06.0000] <Hixie>
now is _not_ always better than later. Later you have more experience, and waiting means you can fix things.

[17:37:07.0000] <hober>
Hixie: indeed

[17:38:00.0000] <zewt>
you don't have nearly as much experience if you never use a feature because you have to wait 5 years for it to become widely available :)

[17:38:01.0000] <TabAtkins>
Hixie: Plus, some parts of the platform do *not* move quickly.  Mobile, for example.

[17:38:02.0000] <Hixie>
just look at the issue rniwa raised earlier, where itemtype changed and rniwa wanted to use prefixes because of it

[17:38:03.0000] <TabAtkins>
Or, you know, the ~40% of the web still on IE7 or lower.

[17:39:00.0000] <TabAtkins>
Plus zewt's point, that adoption in JS means more experimentation and more experience.

[17:39:01.0000] <TabAtkins>
It would have taken much longer to get querySelector if jQuery hadn't existed.

[17:40:00.0000] <hober>
/me thinks mobile is moving pretty quickly actually

[17:40:01.0000] <TabAtkins>
Hixie: out of curiosity, since you said that you don't think convenience APIs should exist, do you think we shouldn't have done querySelector?

[17:40:02.0000] <zewt>
mobile is sort of crippled because phone manufacturers rarely update browsers

[17:40:03.0000] <TabAtkins>
hober: The edge is moving roughly as fast as the edge of the desktop.  The tail is still pretty slow, though.

[17:40:04.0000] <TabAtkins>
Because of what zewt just said.

[17:41:00.0000] <zewt>
(which is gross and embarrassing; all mobile platforms are *new* platforms, and there's no excuse that they don't all have well-built upgrade systems for browsers)

[17:41:01.0000] <hober>
I can think of some phone manufacturers who are pretty good at updating their browsers :)

[17:41:02.0000] <TabAtkins>
Still not the majority.  ^_^

[17:42:00.0000] <smaug____>
hober: tell me one. (I may actually change my phone reasonable soon)

[17:42:01.0000] <TabAtkins>
smaug____: Presumably he was referring to iphone

[17:42:02.0000] <zewt>
no android phone does, since it pretty much takes a full OS update to update the browser

[17:42:03.0000] <smaug____>
( though, I can just use Nightly and update the browser every day )

[17:43:00.0000] <smaug____>
does iphone's Safari get updated often?

[17:44:00.0000] <miketaylr>
zewt: of course there are browsers available on the android platform that update much faster than the OS

[17:44:01.0000] <hober>
It doesn't come out every six weeks, but then again, like Hixie said, there's such a thing as moving too fast. :)

[17:50:00.0000] <hober>
un-derailing the conversation for a moment, I think both Hixie & TabAtkins are making reasonable points:

[17:50:01.0000] <hober>
I agree with Tab that it would be nice for JS authors to be able to write polyfills for features, and at least in some cases JS should be augmented to facilitate that.

[17:50:02.0000] <hober>
Hixie's right, though, that if a new API is easily polyfillable, that's a smell that the API probably doesn't belong in the platform

[17:51:00.0000] <TabAtkins>
I still disagree with that.  We can produce high-value convenience APIs that are easily polyfillable.

[17:51:01.0000] <TabAtkins>
They are still worthwhile to add to the platform.

[17:52:00.0000] <TabAtkins>
For example, getting the mouse location relative to a target element is pretty easy.  I reinvent it every time I write anything using the mouse.

[17:52:01.0000] <TabAtkins>
It's still a high-value thing to provide natively, precisely *because* I have to reinvent it every single time I write anything using the mouse.

[17:53:00.0000] <TabAtkins>
(Plus, something can be easy to polyfill the primary use-case for, but still offer additional value in providing corner-cases that are harder to polyfill.)

[17:53:01.0000] <hober>
Yeah, I have "probably" in my line above to give myself enough rhetorical wiggle room to agree with you in some cases and not in others. :) it's a judgement call

[17:53:02.0000] <TabAtkins>
Plus, it's still surprisingly easy to get the mouse thing wrong.

[17:53:03.0000] <zewt>
miketaylr: but most people use the stock browser, and people should be able to do so

[17:54:00.0000] <miketaylr>
(for sure)

[17:54:01.0000] <zewt>
TabAtkins: there's also a lot of value in standardizing basic stuff like that that's used a lot, instead of every page reinventing it slightly differently

[17:54:02.0000] <TabAtkins>
Yup.

[17:55:00.0000] <TabAtkins>
So whether or not it can be polyfilled easily is, I think, a useless signal when deciding whether to add it.

[17:55:01.0000] <TabAtkins>
Whether it's useful and commonly-needed is really what you need to account for.

[17:59:00.0000] <TabAtkins>
(I suppose if something is rarely needed, but really useful when it is needed, whether or not it's easy to duplicate in JS can be a useful factor to consider.)

[17:59:01.0000] <Hixie>
TabAtkins: (sorry, was afk)

[18:00:00.0000] <TabAtkins>
It's cool, I can talk enough for both of us.

[18:00:01.0000] <Hixie>
TabAtkins: i think querySelector() is fine, because the UA has all kinds of knowledge and ability to optimise that the script doesn't

[18:00:02.0000] <Hixie>
TabAtkins: but equally, i think it doesn't make much sense to implement a JS version of it

[18:01:00.0000] <TabAtkins>
Well, not *now* it doesn't.  It made all kinds of sense when jQuery did it.

[18:01:01.0000] <Hixie>
TabAtkins: having said that, i think ES3 is quite capable of providing enough of a shim for it that we don't need more magical syntax features.

[18:01:02.0000] <TabAtkins>
Actually, though, it does still make sense to implement it in JS, because there are still significant browsers that don't have it.

[18:02:00.0000] <TabAtkins>
Yes, querySelector requires nothing special on the syntax front to shim.  That was just a question about your general point that convenience features shouldn't be added.

[18:03:00.0000] <Hixie>
TabAtkins: what are examples of things that you think need shimming that can't be sufficiently shimmed with JS?

[18:04:00.0000] <TabAtkins>
arv gave an example in the form of dataSet.

[18:04:01.0000] <TabAtkins>
It can be shimmed now, with Proxies.

[18:04:02.0000] <Hixie>
an example that isn't trivially dealt with by just using getAttribute

[18:05:00.0000] <Hixie>
that is, an example where the convenience provided is great enough to justify adding a bunch of features to support providing the convenience

[18:05:01.0000] <TabAtkins>
No.  The syntax is the important part there.  dataSet is exactly equivalent in *functionality* to setAttribute.  It's more convenient to use because of syntax.

[18:05:02.0000] <Hixie>
sure but it's not important enough to matter

[18:05:03.0000] <TabAtkins>
The fact that it was an obvious enough syntax win for you to add it should be a sufficient answer as to why outside JS libs would want it.

[18:05:04.0000] <zewt>
if it wasn't important enough to matter then why was it added in the first place?

[18:05:05.0000] <Hixie>
given the choice between a bunch of syntax to allow authors to emulate dataSet and just using DOM Core, DOM Core is the obviously better choice.

[18:07:00.0000] <Hixie>
to add a feature to the platform you have to compare the cost of not having it to the cost of implementing it. The cost of not having dataSet is minimal, the cost of implementing dataSet is even less so. The cost of not having dataSet is minimal, the cost of implementing a bunch of additions to JS to enable authors to fake it is comparatively huge.

[18:07:01.0000] <arv>
another one is classList

[18:07:02.0000] <TabAtkins>
The cost of never having anything like dataSet is larger.

[18:07:03.0000] <arv>
same issues as dataSet but more useful (IMO)

[18:08:00.0000] <Hixie>
you can surely fake enough of classList today

[18:09:00.0000] <Hixie>
it's just a bunch of methods

[18:09:01.0000] <Hixie>
where's the problem?

[18:09:02.0000] <annevk>
it's dataset not dataSet btw

[18:10:00.0000] <TabAtkins>
annevk: I always forget.  arv said dataSet early, so I copied him.

[18:12:00.0000] <zewt>
... by the way, what's so badly complex about proxies? google isn't finding much about them, but https://gist.github.com/1202328 looks fairly straightforward

[18:13:00.0000] <zewt>
(not as nice as Python's __getattr__, but I assume performance is the problem with that interface)

[18:13:01.0000] <TabAtkins>
zewt: Decent tutorial at http://soft.vub.ac.be/~tvcutsem/proxies/

[18:14:00.0000] <arv>
classList[index] cannot be emulated

[18:14:01.0000] <zewt>
looks fairly self-contained

[18:16:00.0000] <paul_irish>
fwiw https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills lists basically every shim/polyfill for all newish features there is.

[18:16:01.0000] <paul_irish>
elem.classList[methodname]('classname') is unsupported in the polyfill listed.

[18:17:00.0000] <Hixie>
arv: so just use classList.item(index)

[18:17:01.0000] <zewt>
heh Video Timed Track (subtitles)

[18:17:02.0000] <Hixie>
arv: you don't have to duplicate the entire API, only enough of the API for it to be usable

[18:17:03.0000] <zewt>
an assured way of making sure nobody can find VTT: call it Video Timed Track

[18:18:00.0000] <TabAtkins>
Hixie: The fact that the platform has a nice convenient way of doing something, but libraries can't ever duplicate it, is a bug.

[18:18:01.0000] <Hixie>
TabAtkins: so you keep saying, but that doesn't follow from the use cases you describe

[18:18:02.0000] <TabAtkins>
Again, if it was sufficiently obvious of a win to be included in the first place, it's clearly a useful thing for libraries to have as well.

[18:18:03.0000] <paul_irish>
zewt: just updated so the abbv is present in the page

[18:19:00.0000] <Hixie>
TabAtkins: you are assuming that something was added to the platform because it was a good idea and not just because i copied-and-pasted other parts of the platform that did it too

[18:19:01.0000] <Hixie>
TabAtkins: there's plenty of stuff in the platform that isn't a win at all, let alone a "sufficiently obvious win"

[18:19:02.0000] <TabAtkins>
Are you saying that relatively new APIs you've designed are mistakes?

[18:19:03.0000] <zewt>
i'd suggest that one of the following must be true: 1: being able to write foo.bar and have bar looked up dynamically is a useful idiom in APIs, and it should be possible to do this in JS libraries; or 2: it's not very useful, and no new APIs should do that

[18:20:00.0000] <zewt>
(speaking of getattr(foo, "bar"), not getters, of course)

[18:20:01.0000] <Hixie>
TabAtkins: many have plenty of mistakes or bits that are consistent merely for the sake of consistency, or have features that are made available because they can be but where if i was designing the API for an environment where they could not be i wouldn't blink at omitting it

[18:21:00.0000] <Hixie>
TabAtkins: .item(n) vs [n] being a classic example of the latter

[18:21:01.0000] <Hixie>
TabAtkins: (having said that, i've no objection to JS adding a neat syntax to support index getters in classes)

[18:21:02.0000] <TabAtkins>
Sigh.  It seems like every feature that we point out, you say wasn't necessary in the first place and doesn't need to be done in library code.

[18:22:00.0000] <Hixie>
TabAtkins: yes, it is my argument that everything you can't do in JS is stuff you needn't do in JS

[18:22:01.0000] <annevk>
I think [n] is nice to have

[18:22:02.0000] <erlehmann>
best browser ever http://vttynotes.blogspot.com/2011/10/cve-2011-3230-launch-any-file-path-from.html

[18:22:03.0000] <TabAtkins>
Hixie: That's a stupid argument.  ^_^

[18:22:04.0000] <annevk>
emulating IDL [replaceable] and such however goes a bit far

[18:22:05.0000] <zewt>
i'm still not understanding what's so objectionable about this proxy interface; it looks self-contained and already implemented in FF

[18:22:06.0000] <Hixie>
TabAtkins: it's backed up by the fact that every concrete example you've given has in fact supported my argument

[18:22:07.0000] <Hixie>
TabAtkins: if you have a counter-example i'm certainly open to it

[18:23:00.0000] <TabAtkins>
Hixie: Only in your mind.  ;_;  Because you self-admitedly don't consider syntax important.

[18:23:01.0000] <Hixie>
TabAtkins: also, note that i have no objection to specific features being added to JS, my objection is to the explicit goal of adding everything necessary to emulate DOM APIs in JS

[18:23:02.0000] <Hixie>
TabAtkins: because i think that goal is sufficiently met already

[18:24:00.0000] <TabAtkins>
I consider self-hosting a valuable property for a language to have.

[18:24:01.0000] <Hixie>
a valuable feature for a turing-complete language and an API to have but not a language like CSS?

[18:25:00.0000] <TabAtkins>
Yes?

[18:26:00.0000] <TabAtkins>
Again, DSL is, by definition, domain-specific, not general-purpose.

[18:27:00.0000] <Hixie>
the DOM API is not domain-specific?

[18:27:01.0000] <Hixie>
_JS_ is not domain-specific?

[18:27:02.0000] <zewt>
js certainly is not

[18:28:00.0000] <TabAtkins>
Nobody's asking to be able to self-host the DOM API in the DOM API.  We want to host the DOM in JS.

[18:28:01.0000] <TabAtkins>
JS is most certainly not domain-specific!  What possibly could possess you to think it is?

[18:28:02.0000] <erlehmann>
DOMain-specific!

[18:28:03.0000] <TabAtkins>
erlehmann: :headdesk:

[18:28:04.0000] <zewt>
/me eyes Unity editor open with a couple JS scripts that have nothing to do with the web

[18:28:05.0000] <Hixie>
it's the web's programming language, i can't imagine any other context in which i'd actually want to use it

[18:28:06.0000] <erlehmann>
careful, TabAtkins. or i shall make a new comic.

[18:28:07.0000] <zewt>
TabAtkins: (the important question: whose head)

[18:29:00.0000] <TabAtkins>
Hixie: You are operating under an incorrect definition of "domain-specific" and "general purpose".

[18:29:01.0000] <Hixie>
TabAtkins: and you're mis-using "self-hosting" :-)

[18:29:02.0000] <TabAtkins>
No I'm not.  ^_^

[18:29:03.0000] <Hixie>
JS implementing DOM is not self-hosting

[18:29:04.0000] <Hixie>
that would be JS implementing JS

[18:30:00.0000] <Hixie>
if JS is "general purpose", why is CSS not "general purpose"?

[18:30:01.0000] <TabAtkins>
Yes.  DOM is a library built in JS.  By definition, if JS is self-hosting, it can host the DOM too.

[18:30:02.0000] <Hixie>
DOM is _not_ a library build in JS!

[18:30:03.0000] <Hixie>
it's an API exposed to JS built typically in C++

[18:30:04.0000] <TabAtkins>
Hixie: Um, because CSS is a DSL.  It's nowhere near turing-complete, and not intended for generic computation.

[18:30:05.0000] <Hixie>
...

[18:30:06.0000] <zewt>
"..." what?

[18:31:00.0000] <Hixie>
we're going around in circles

[18:31:01.0000] <TabAtkins>
I don't understand how!

[18:31:02.0000] <Hixie>
whether something is turing complete or not doesn't have any bearing on whether it's general purpose or not

[18:31:03.0000] <TabAtkins>
How can you possibly think CSS is a general-purpose computer language?!?

[18:31:04.0000] <zewt>
i don't understand the question--of course you can't implement CSS features in CSS; CSS isn't even a programming language

[18:31:05.0000] <TabAtkins>
zewt: Sure it is.  It's just a very limited one.

[18:31:06.0000] <zewt>
it's not, not by any definition of the term I've ever seen or used

[18:32:00.0000] <TabAtkins>
It's a styling and layout programming language.

[18:32:01.0000] <TabAtkins>
You're probably just not very familiar with declarative languages.

[18:32:02.0000] <zewt>
it's a layout language; it's not a layout *programming* language

[18:32:03.0000] <TabAtkins>
CSS is a program that accepts a DOM as input and produces a laid-out page.

[18:32:04.0000] <Hixie>
none of us seem to agree on terminology here

[18:32:05.0000] <zewt>
heh

[18:33:00.0000] <Hixie>
anyway

[18:33:01.0000] <Hixie>
i have to go

[18:33:02.0000] <zewt>
TabAtkins: i disagree, but let's skip this debate :)

[18:33:03.0000] <TabAtkins>
Hixie: Pretty sure everyone extra-disagrees with your terms, though, if you consider CSS a general-purpose alnguage and JS not.

[18:33:04.0000] <zewt>
(was: re: third-order tangent)

[18:33:05.0000] <Hixie>
but i must first say that i continue to see no intrinsic reason why a library that implements a DOM shim would need to support every last subtlty of the DOM

[18:33:06.0000] <Hixie>
it just has to be close enough

[18:33:07.0000] <Hixie>
TabAtkins: i consider both to be domain-specific

[18:34:00.0000] <TabAtkins>
Hixie: Is C domain-specific?

[18:34:01.0000] <annevk>
extra-disagree lol

[18:34:02.0000] <Hixie>
no, C is general-purpose

[18:34:03.0000] <TabAtkins>
Then your definition is broken.

[18:34:04.0000] <Hixie>
ko

[18:34:05.0000] <Hixie>
ok

[18:34:06.0000] <zewt>
in every other language I've used at any length, every API exposed to the language can be exposed by code written in the language itself; JS being the weird exception

[18:34:07.0000] <Hixie>
the point is moot, since i don't think whether something is general purpose or not should control whether it needs to have the syntactic ability to emulate its APIs or not

[18:35:00.0000] <Hixie>
zewt: you haven't used many languages

[18:35:01.0000] <annevk>
Wikipedia sides with Hixie fwiw http://en.wikipedia.org/wiki/General-purpose_programming_language

[18:35:02.0000] <Hixie>
zewt: there are tons of languages that can't describe all their APIs

[18:35:03.0000] <TabAtkins>
annevk: How so?

[18:36:00.0000] <zewt>
perhaps badly-designed languages, which I do try hard to avoid

[18:36:01.0000] <Hixie>
zewt: e.g. Perl (some of its APIs are especially crazy), Pascal (normal Pascal can't implement its own Writeln function)

[18:36:02.0000] <zewt>
nice timing bringing up Perl :)

[18:36:03.0000] <TabAtkins>
JS is a perfectly fine general-purpose functional programming language.  It happens that in its most common implementations there are a couple of additional libraries built-in that are designed for easier writing of webapps, is all.

[18:36:04.0000] <zewt>
(pascal is a toy language, as far as I'm concerned)

[18:36:05.0000] <zewt>
(havn't touched it in ... 15 years?)

[18:37:00.0000] <Hixie>
i happen to be particularly familiar with those two so can comment authoratively off the top of my head

[18:37:01.0000] <Hixie>
i'd be surprised if there weren't similar limitations in most languages

[18:37:02.0000] <Hixie>
but i really have to go

[18:37:03.0000] <Hixie>
bbl

[18:38:00.0000] <TabAtkins>
annevk: Yup, reading further, I'm quite certain that Wikipedia disagrees with Hixie.  There is no reasonable definition of "domain-specific" under which JS is one.

[18:38:01.0000] <zewt>
(C, C++, Python)

[18:47:00.0000] <erlehmann>
C is general purpose. I make music with a compiler. :3

[18:48:00.0000] <annevk>
TabAtkins, I meant for "C"

[18:48:01.0000] <erlehmann>
#include <math.h>

[18:48:02.0000] <erlehmann>
#include <stdio.h>

[18:48:03.0000] <erlehmann>
main(){long int t;int sample;for(t=0;;t++){sample=(((t&512)>>(int)(3*sin(t*4&(int)(t/256))))>>(t>>18)|((t&512)>>(int)(4*sin(t*4&(int)(t/512))))>>(t>>27));fputc(sample, stdout);}}

[18:49:00.0000] <erlehmann>
just pipe this to /dev/audio :3

[18:49:01.0000] <annevk>
given that JavaScript is used on e.g. servers and elsewhere it does not really seem that domain specific to me

[18:49:02.0000] <TabAtkins>
annevk: Did you think I was saying that C was domain-specific?

[18:49:03.0000] <annevk>
but I don't really care

[18:49:04.0000] <erlehmann>
javascript ist used on servers … and desktops. doesn't gnome have javascript?

[18:50:00.0000] <bga_>
gnome3 - yes

[18:50:01.0000] <TabAtkins>
Even if JS was only ever used in webpages in browsers, it's still not domain-specific.  It is capable of (and designed for) arbitrary computation.

[18:50:02.0000] <erlehmann>
i concur.

[18:51:00.0000] <TabAtkins>
This isn't like, I dunno, using XSLT to compute mandelbrots.

[18:51:01.0000] <bga_>
also qml

[18:51:02.0000] <erlehmann>
hey, i wrote a CMS abomination in XSLT once. i think everyone has to live through that, coming-of-age-story.

[18:53:00.0000] <TabAtkins>
bga_: From wikipedia's description, it looks like QML is a DSL.

[18:53:01.0000] <TabAtkins>
It looks like you can run arbitrary JS, but it's designed for designing UI.

[18:54:00.0000] <TabAtkins>
And the syntax is clearly slanted towards that end.

[19:11:00.0000] <TabAtkins>
erlehmann: By the way, it would be great if you could put in a Kate Beaton credit in your comic.

[19:12:00.0000] <erlehmann>
TabAtkins, oh. i thought people knew that already.

[19:12:01.0000] <erlehmann>
after all, it was for and about you, i spotted the fat pony in your sig!

[19:12:02.0000] <TabAtkins>
Some of us do, sure.  It's always good manners to credit, though, for the people who aren't already aware of an awesomic comic.

[19:12:03.0000] <erlehmann>
s/sig/avatar/

[19:12:04.0000] <erlehmann>
okay.jpg

[19:13:00.0000] <TabAtkins>
It gives you an opportunity to evangelize a bad-ass comic.  ^_^

[19:13:01.0000] <erlehmann>
i am actually right now reading through “hark, a vagrant”

[19:13:02.0000] <erlehmann>
and must admit i have no idea what the title says

[19:14:00.0000] <TabAtkins>
The title?

[19:14:01.0000] <TabAtkins>
Oh, the phrase "hark, a vagrant"?

[19:14:02.0000] <erlehmann>
yesss

[19:14:03.0000] <TabAtkins>
It's a phrase from an early bio comic.  Kate is walking past a homeless dude, who shouts for her.  She responds (to no one in particular), "Hark, a vagrant!".

[19:14:04.0000] <TabAtkins>
Where "hark" is an archaic term meaning "Hey!"

[19:15:00.0000] <erlehmann>
what is a vagrant

[19:15:01.0000] <erlehmann>
then

[19:15:02.0000] <TabAtkins>
A homeless dude.

[19:15:03.0000] <erlehmann>
intredasting.

[19:16:00.0000] <erlehmann>
so i learned something

[19:16:01.0000] <erlehmann>
thanks, tab atkins.

[19:17:00.0000] <erlehmann>
i was just thinking that kate beaton could make erotic comics, but then i remembered the workings of jess fink.

[19:17:01.0000] <erlehmann>
screw that.

[19:18:00.0000] <TabAtkins>
Hey, I kinda like Chester 5000.

[19:19:00.0000] <erlehmann>
i would like to draw that way. alas, i can only make icons and pixel graphics :/

[19:20:00.0000] <erlehmann>
in before over 9000 years of mastering

[19:20:01.0000] <erlehmann>
the skill of drawing

[19:29:00.0000] <annevk>
ooh, roc is at that conference today

[19:29:01.0000] <annevk>
that's too bad

[19:29:02.0000] <annevk>
can someone else answer my fullscreen questions?

[19:29:03.0000] <annevk>
(if so, see the WHATWG list)

[19:39:00.0000] <zewt>
personally I don't understand the "full screen without input" idea--that's crippling to essentially every usage, i can't imagine anyone ever using it

[19:39:01.0000] <zewt>
even a trivial video player wants space to pause

[19:40:00.0000] <annevk>
you get some keyboard always

[19:40:01.0000] <annevk>
but even then I fail to see the concern given the various things that are in place

[19:42:00.0000] <zewt>
the entire "go fullscreen first and ask if that was okay" model that it seems everyone is implementing is really worrisome

[19:43:00.0000] <zewt>
i don't want sites taking my browser window fullscreen to show a gigantic interstitial ad (at which point the browser asking permission is basically going "wow, that was annoying, wasn't it?")

[19:43:01.0000] <zewt>
i'm surprised i havn't seen sites do that with flash, though i guess i wouldn't since i flashblock by default

[19:43:02.0000] <annevk>
it's going to use the "trusted click" model for sure

[19:43:03.0000] <zewt>
that doesn't help, it just moves the annoyance to the first time you click anywhere

[19:44:00.0000] <annevk>
i guess some sites do that with popups these days

[19:44:01.0000] <zewt>
lots of pages listen for clicks on document to open a popup yeah what you said

[19:44:02.0000] <zewt>
the only benefit, IMO, to the only-on-click model is preventing infinite recursion

[19:45:00.0000] <zewt>
not so much preventing the annoyance itself, just keeping it from exploding

[19:45:01.0000] <zewt>
(and it's clearer than magic behind-the-scenes heuristics like "has this site opened a popup/tried to go fullscreen already in the last few seconds")

[19:48:00.0000] <annevk>
so you prefer upfront confirmation?

[19:49:00.0000] <zewt>
as long as there's an easy "always allow for this site" option, yeah

[19:50:00.0000] <annevk>
ugh

[19:50:01.0000] <zewt>
the API already allows it, but it seems like both FF and Chrome are going the ask-afterwards route

[19:50:02.0000] <annevk>
seems better to just nuke it permanently for the few sites that abuse it

[19:50:03.0000] <zewt>
it's the sort of thing that seems really tempting for low-grade advertisers to push sites to do

[20:12:00.0000] <erlehmann>
annevk, with geolocation, upfront notification is working.

[20:12:01.0000] <erlehmann>
also, what zewt said. madness.

[20:15:00.0000] <zewt>
what happens with ask-after notifications if a page goes fullscreen, shows an ad for 2-3 seconds, then exits before the user has a chance to click "stop doing that"? browsers would also need to keep the "allow/block fullscreen" question open after exiting fullscreen to prevent that

[21:13:00.0000] <annevk>
zewt, sure

[21:13:01.0000] <annevk>
erlehmann, you want to optimize for the positive case

[21:13:02.0000] <annevk>
these DOM Level 3 Events emails sure are entertaining

[21:18:00.0000] <erlehmann>
annevk, too many asshats out there. let me be the first to abuse SUDDEN FULLSCREEN MADNESS.

[21:18:01.0000] <erlehmann>
just think: this, combined with shock sites.

[21:31:00.0000] <annevk>
erlehmann, yeah I totally see myself browsing shock sites all day

[22:07:00.0000] <annevk>
heycam|away, hey

[22:08:00.0000] <annevk>
heycam|away, I guess we could reuse Error, but is it worth it?

[22:21:00.0000] <annevk>
is cpearce on IRC?

[22:43:00.0000] <zewt>
synchronous calls waiting for an animation to complete? D:

[23:42:00.0000] <zcorpan>
s/may only be called/must be called/ is a "worthy grammatical clarification"? ok

[23:59:00.0000] <Hixie>
zcorpan: if by "worthy grammatical clarification" you mean "correction for bogus use of RFC2119 terms" :-)

[00:08:00.0000] <zcorpan>
d3e is full of it it seems

[00:12:00.0000] <Hixie>
d3e?

[00:13:00.0000] <Hixie>
oh dom events?

[00:13:01.0000] <Hixie>
hm

[00:18:00.0000] <Hixie>
what's the state of the art in terms of networking protocols to transfer responsibility for a token from one server on the Internet to another server?

[00:18:01.0000] <Hixie>
that is, is there an established solution, or is it a known unsolveable problem, or something else?

[00:19:00.0000] <Hixie>
(that is, say there are two servers A and B, and A currently has ownership/responsibility of a token X, and wants to transfer it to B, but wants B to only take it if B knows that A knows that B has taken it)

[00:20:00.0000] <Hixie>
(abarth?)

[00:20:01.0000] <abarth>
Hixie: sorry, playing bridge

[00:20:02.0000] <abarth>
send email

[00:20:03.0000] <Hixie>
nothing important, just my question above

[00:21:00.0000] <Hixie>
not a web standard thing

[00:21:01.0000] <Hixie>
enjoy your bridge :-)

[00:54:00.0000] <RobbertAtWork>
I had this idea about the Component Model: if you allow to register existing tagNames without the x- prefix, web pages could reserve the privilege of creating scripts (against XSS). (function() { var script = HTMLScriptElement; var secretTagName = randomTagName(); Element.register("script", function(){}); Element.register(secretTagName, HTMLScriptElement); })()

[00:55:00.0000] <RobbertAtWork>
execute this in the <head> and no scripts after that will be evaluated.

[02:31:00.0000] <annevk>
zcorpan, good question

[02:31:01.0000] <annevk>
zcorpan, sicking suggested we keep it because browsers keep the state around internally

[02:32:00.0000] <zcorpan>
the isWhiteSpace thing?

[02:32:01.0000] <annevk>
yes

[02:32:02.0000] <foolip>
Hixie, rniwa, Opera support document.getItems(), but not the spec changes that were made a few days ago of course

[02:33:00.0000] <annevk>
I'll add a comment to https://bugzilla.mozilla.org/show_bug.cgi?id=687422

[02:57:00.0000] <RobbertAtWork>
annevk: I always though element content whitespace was a different thing

[02:57:01.0000] <RobbertAtWork>
[

[02:58:00.0000] <RobbertAtWork>
http://www.w3.org/TR/REC-xml/#dt-elemcontent says element content is content of elements that must contain only child elements

[02:58:01.0000] <RobbertAtWork>
so the contents of a <ul> element for example

[02:58:02.0000] <jgraham>
/me reads a little backscroll, finds js being described as a "functional" language, gives up

[02:58:03.0000] <annevk>
yeah it is a different thing, but browsers never implemented the attribute based on semantics of the language so it became to mean isWhiteSpace as far as implementations go

[02:58:04.0000] <RobbertAtWork>
so I figured for white-space text nodes between <ul> and <li> isElementContentWhitespace would be true

[02:59:00.0000] <RobbertAtWork>
while for whitespace text nodes in <li> elements it would be false

[02:59:01.0000] <annevk>
yeah

[03:00:00.0000] <RobbertAtWork>
So I'd say: add isWhiteSpace to the DOM4 standard, rename the current implementations, and let isElementContentWhitespace return false as long as it isn't implemented

[03:00:01.0000] <annevk>
is the latter useful?

[03:01:00.0000] <annevk>
or the former for that matter, nobody brought up a use case yet :)

[03:01:01.0000] <RobbertAtWork>
yeah, it would fix implementations that depend on it's functionality

[03:02:00.0000] <annevk>
it's probably going to return undefined

[03:02:01.0000] <annevk>
as it already does in some browsers

[03:03:00.0000] <Philip`>
jgraham: Would you prefer it to be called a dysfunctional language?

[03:04:00.0000] <jgraham>
Philip`: Depends how annoyed I am with it at the time :)

[03:04:01.0000] <RobbertAtWork>
XML Information Set says on the subject of element content whitespace "If there is no declaration for the containing element, …, this property has no value", so I guess null or undefined is okay with me, although null is more like other DOM properties

[03:06:00.0000] <annevk>
RobbertAtWork, I mean we would remove it for now

[03:07:00.0000] <RobbertAtWork>
annevk: fine

[03:11:00.0000] <RobbertAtWork>
annevk: isWhiteSpace is quite useful for minifying, for scripts that know what whitespace is ignorable. Xopus uses it to minimize the amount of nodes in memory, removes the ignorable whitespace according to the current Schema

[03:16:00.0000] <zcorpan>
wouldn't you want to minify on the server side?

[03:19:00.0000] <RobbertAtWork>
wouldn't you want to use the DOM for that?

[03:20:00.0000] <RobbertAtWork>
using the DOM is the easiest approach for several minifying passes

[03:20:01.0000] <zcorpan>
using the DOM for that seems horrible

[03:20:02.0000] <RobbertAtWork>
removing all type attributes from style elements is way easier using DOM than regexp

[03:21:00.0000] <zcorpan>
you're not limited to DOM and regexp on the server

[03:23:00.0000] <zcorpan>
anyway, i think we shouldn't design the DOM around server-side use cases

[03:23:01.0000] <zcorpan>
doing so introduced a lot of bloat to the DOM that we're now trying to clean up in DOM4

[03:23:02.0000] <RobbertAtWork>
then I want to minify on the client

[03:24:00.0000] <zcorpan>
why?

[03:33:00.0000] <RobbertAtWork>
zcorpan: I'll get back to you on that, have to go now

[03:35:00.0000] <zcorpan>
k

[04:37:00.0000] <jgraham>
Hixie: BTW one concreate reason to prefer DOM-in-JS is that it may provide performance wins. JS-C++ boundaries are generally bad for perf. especially as you can't JIT across them

[04:43:00.0000] <smaug____>
(that argument was covered last night.)

[04:44:00.0000] <smaug____>
(and it is very valid one, although kind of implementation detail)

[04:44:01.0000] <jgraham>
Oh, like I say hundreds of lines of argument were too much to read

[04:45:00.0000] <smaug____>
:)

[04:47:00.0000] <jgraham>
I'm not sure dismissing it as an implementation detail is valid though; implementation details can be critical particularly if they are a fundamental characteristic of all sucessful implementations

[05:49:00.0000] <gsnedders>
(Esp. with a tracing JIT DOM-in-JS should be able to provide good perf, because you'll simply cut out a lot of the complexity)

[05:52:00.0000] <jgraham>
What's extra sensory perception got to do with anything?

[05:53:00.0000] <gsnedders>
…

[05:54:00.0000] <jgraham>
  o

[05:54:01.0000] <jgraham>
^man with third eye

[05:54:02.0000] <jgraham>
Unless you are using a proportionally spaced font for irc, in which case it sucks to be you

[06:35:00.0000] <matjas>
what’s the appropriate markup for stuff like “Note: foo bar baz” or “Update: foo bar baz” in blog posts? currently i just use <p> for both, with an extra <ins> for updates

[06:35:01.0000] <matjas>
perhaps <small> would be better?

[06:36:00.0000] <annevk>
<p> seems fine

[06:36:01.0000] <annevk>
in specs we use <p class=note>foo bar baz

[06:36:02.0000] <annevk>
we don't do updates

[06:37:00.0000] <matjas>
cool, thanks

[06:49:00.0000] <annevk>
oooooh yeeah

[06:49:01.0000] <annevk>
Xbox 360 is finally getting server-side storage for gamertags and such

[08:41:00.0000] <annevk>
discussing standards on twitter sucks badly

[08:41:01.0000] <annevk>
can someone make it stop?

[08:42:00.0000] <annevk>
Google+ sort of works, but excludes Ms2ger; mailing lists really would be best

[08:43:00.0000] <jgraham>
echo '127.0.0.1 twitter.com' >> /etc/hosts

[08:46:00.0000] <Philip`>
The W3C ought to develop a social network platform designed for discussing and developing specifications, rather than expecting people to use antiquated things like mailing lists or inappropriate things like Twitter

[08:47:00.0000] <astearns>
tldr: gamily standards!

[08:47:01.0000] <astearns>
*gamify

[08:48:00.0000] <hsivonen>
annevk: yeah, I can't figure out how slightlyoff_afk wants node renames to behave or what the use case for node renames is

[08:48:01.0000] <annevk>
he just wants everything to be a function

[08:49:00.0000] <annevk>
and then since new Element() would be pointless, he suggested something about a writable local name, which of course would not work, but never mind that

[08:50:00.0000] <hsivonen>
it would be kinda unfortunate if the platform implementation couldn't be organized into classes the way it can be organized if a node can't change what element it represents

[08:51:00.0000] <hsivonen>
node renaming is like every element being input type=foo

[08:52:00.0000] <jgraham>
Making the interface of an Element immutable seems like an important invariant to preserve

[08:53:00.0000] <annevk>
anyway I doubt he really wants to change that

[08:54:00.0000] <annevk>
he's just trying to make his vague case for constructors everywhere

[08:56:00.0000] <hsivonen>
"constructors everywhere" isn't a use case. what's the motivation for constructors everywhere? is there a blog post about this?

[09:05:00.0000] <annevk>
yes, but I didn't get it

[09:05:01.0000] <annevk>
I think it has something to do with the idea that the DOM has to be written in terms of ECMAScript

[09:05:02.0000] <annevk>
and ECMAScript does not know objects you cannot new?

[09:06:00.0000] <annevk>
but how this helps anyone...

[09:06:01.0000] <jgraham>
http://www.w3.org/mid/CANr5HFU5PVs0ad_KDE+zVjKgrKFfpF_E0zFvVPx7BymJc9nedQ⊙mgc

[09:06:02.0000] <jgraham>
Well of course you can create objects that you cannot new using ES

[09:10:00.0000] <jgraham>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1186 is a trivial example

[09:11:00.0000] <jgraham>
The problem seems to be a belief that not being able to do new HTMLFooElement() even where that doesn't make sense, is screwing over authors

[09:12:00.0000] <jgraham>
In general having constructors where they make sense doesn't seem like a bad idea

[09:13:00.0000] <jgraham>
They don't really make sense on HTMLElement and "subclasses" though becase there isn't a 1:1 mapping between interface objects and instances

[09:14:00.0000] <jgraham>
(that is, not every instance you might want to create has a corresponding interface object)

[09:17:00.0000] <annevk>
yeah, I think we should add them for Text/Comment/Document

[09:17:01.0000] <annevk>
dunno about Element

[09:44:00.0000] <dglazkov>
good morning, Whatwg!

[09:44:01.0000] <Hixie>
mornin'

[09:44:02.0000] <smaug____>
hyvää iltaa

[09:45:00.0000] <dglazkov>
anything with umlauts is cool by definition

[09:46:00.0000] <jgraham>
Finnish isn't a real language it's just a conspiracy to make the rest of the world feel stupid

[09:46:01.0000] <smaug____>
:p

[09:46:02.0000] <Hixie>
what's vietnamese then? :-)

[09:49:00.0000] <astearns>
a conspiracy to prop up the diacritic industry

[09:50:00.0000] <miketaylr>
a purveyor of fine sandwiches

[09:50:01.0000] <jgraham>
Oh is that the basis you were comparing on? I was going to say that vietnamese didn't seem very gramatically complex

[09:51:00.0000] <jgraham>
(although I only glanced at wikipedia, so maybe it is)

[09:51:01.0000] <jgraham>
whereas the dead giveaway that Finnish is a conspiracy is that they go around talking about 15 cases for nouns

[09:51:02.0000] <astearns>
omniglot tells me that Vietnamese has six tones. that seems complex

[09:51:03.0000] <jgraham>
To speak, sure

[09:52:00.0000] <jgraham>
I rather suspect it would entirely exclude me from the set of potential vietnamese speakers, for example

[09:54:00.0000] <scor>
Hixie: what was the rationale for conflatin type and vocabulary into @itemtype?

[10:02:00.0000] <Hixie>
scor: i don't understand the question

[10:19:00.0000] <hsivonen>
the rules under "If the element is a time element with a @datetime attribute" in https://dvcs.w3.org/hg/htmldata/raw-file/24af1cde0da1/microdata-rdf/index.html illustrate what's wrong with RDF datatyping

[10:20:00.0000] <Hixie>
hey, i'm an author on that document

[10:20:01.0000] <Hixie>
go figure

[10:20:02.0000] <Hixie>
i didn't even know it existed!

[10:21:00.0000] <hsivonen>
Hixie: is part of the text copied and pasted from something you wrote?

[10:21:01.0000] <Hixie>
i assume so

[10:23:00.0000] <scor>
Hixie: sorry, got side tracked. when you took RDFa and designed microdata, what drew you to combine the concepts of vocabulary namespace with the type (in @itmetype)?

[10:25:00.0000] <scor>
Hixie: RDFa distinguishes the two, but afaik microdata conflates them (this is not a critizism, I just trying to understand what was the rational for combining them)

[10:26:00.0000] <gkellogg>
About @datetime data typing, I didn't invent this, but found it in a tracker bug I thought Hixie had agreed with; it makes sense to me anyway.

[10:26:01.0000] <Hixie>
scor: i didn't take RDFa to design microdata

[10:27:00.0000] <hsivonen>
http://lists.w3.org/Archives/Public/public-html-xml/2011Oct/0022.html

[10:27:01.0000] <gkellogg>
About the new Microdata-RDF doc, Jeni asked me to resurrect it, and of course, it borrows heavily from the previous Microdata spec

[10:27:02.0000] <Hixie>
gkellogg: the text hsivonen mentions is the right way to map <time> to RDFa but it illustrates what's wrong with RDF datatyping nonetheless

[10:27:03.0000] <Hixie>
gkellogg: (note, <time> is likely going away)

[10:28:00.0000] <Hixie>
scor: RDF doesn't really have a concept of a vocabulary at the syntax level

[10:28:01.0000] <annevk>
hsivonen, you posted that for entertainment I hope?

[10:29:00.0000] <gkellogg>
Hixie: I heard that, to be replaced by <data> I suppose?

[10:29:01.0000] <annevk>
surprised nobody has replied with, "Agreed, it's called XHTML5, you can use it today."

[10:29:02.0000] <annevk>
or some such

[10:29:03.0000] <Hixie>
gkellogg: yeah, something like that

[10:30:00.0000] <Hixie>
gkellogg: wouldn't affect the spec you're writing much except you'd have to add more types to the list hsivonen mentioned (and rename the element and attribute names, of course)

[10:30:01.0000] <gkellogg>
Martin Heff has complained about the lack of data typing in Microdata, and would like to see a way to infer this from referenced vocabularies. We considered this for RDFa but rejected it.

[10:31:00.0000] <gkellogg>
Hixie: I intend to follow both HTML5 and Microdata specs as they continue to evolve. Your participation, direct or indirect would be welcome.

[10:31:01.0000] <annevk>
Hixie, I looked at the fullscreen stuff and integrating it directly into HTML might not be a bad idea

[10:31:02.0000] <Hixie>
gkellogg: microdata has data typing, it's just in the vocabularies rather than in the data (since otherwise you have to repeat it with every property use, which seems silly)

[10:32:00.0000] <annevk>
Hixie, then again, I can probably define most methods as a separate thing and HTML would just define things such as <iframe allowfullscreen>

[10:32:01.0000] <Hixie>
annevk: let's do that (the split), i'd rather not have to start defining rendering if i can help it

[10:32:02.0000] <Hixie>
annevk: the rendering section is bad enough

[10:33:00.0000] <gkellogg>
Hixie: to be more specific, rules for creating RDF from Microdata with data typed literals. Vocabulary-based typing relies on the processor to do this on it's own, without it's being stated explicitly in the generated RDF. Otherwise, I agree that the way to do it is through datatype inference.

[10:36:00.0000] <Hixie>
gkellogg: no i mean the microdata vocabulary, not the rdf vocalubary. The microdata to RDF convertor would have to know about the microdata vocabulary to add the data typing

[10:36:01.0000] <cygri>
/me how about strongly deprecating?

[10:36:02.0000] <Hixie>
gkellogg: (there's not really much point in processing data for which you don't know the vocabulary, anyway, it's not like you can actually do anything with the type information in that case)

[10:36:03.0000] <cygri>
/me </joking>

[10:37:00.0000] <cygri>
/me is an idiot. wrong chat window

[10:38:00.0000] <gkellogg>
In my spec, there's always a vocabulary as in every @itemprop results in a URI. If that URI can be dereferenced and it is an RDFS (or OWL) schema, you could use it to find range information that could be used for datatype inference, but this isn't the SWIG discussion list :)

[10:39:00.0000] <scor>
Hixie: in microdata, is there any difference between a vocabulary and a type? it seems the type in @itemtype defines the vocabulary

[10:39:01.0000] <Hixie>
scor: a vocabulary in microdata is a group of short names that are defined in a spec and grouped under one (or more) type(s)

[10:40:00.0000] <Hixie>
scor: it's not equivalent to the type concept in rdf

[10:40:01.0000] <Hixie>
scor: which is just another property value

[10:40:02.0000] <scor>
Hixie: so would you say that a microdata vocabulary has the same URI as the type or not?

[10:40:03.0000] <Hixie>
scor: a vocabulary in microdata doesn't have a url

[10:41:00.0000] <scor>
ah, so how is it defined? by its popular name?

[10:41:01.0000] <Hixie>
the same way, e.g., HTML's vocabulary is defined. In a spec.

[10:41:02.0000] <hsivonen>
annevk: I posted it out of bewilderment about how XHTML5 connects to "Obama Care"

[10:44:00.0000] <gkellogg>
hsivonen: I missed your discussion on mapping <time> datatypes, can you re-post?

[10:45:00.0000] <Hixie>
gkellogg: http://krijnhoetmer.nl/irc-logs/whatwg/20111013#l-1181

[10:46:00.0000] <gkellogg>
Hixie: sorry, I can't fix RDF data typing, it is what it is :)

[10:46:01.0000] <jgraham>
hsivonen: He could have been honest and titled the email "XHTML5: THINK OF THE CHILDREN!"

[10:46:02.0000] <Hixie>
gkellogg: i highly recommend ignoring RDF in general :-)

[10:47:00.0000] <gkellogg>
Hixie: I gathered that :) Sadly, RDF tends to be a kind of addiction, perhaps we need a 12-step program :)

[10:49:00.0000] <Hixie>
can't help you there :-)

[10:49:01.0000] <jgraham>
gkellogg: Don't they ask about that at immigration? "Are you now, or have you ever been, addicted to RDF? YES [ ] NO [ ]"

[10:51:00.0000] <scor>
lol. is it a crime nowadays?

[11:10:00.0000] <hsivonen>
gkellogg: http://krijnhoetmer.nl/irc-logs/whatwg/20111013#l-1181 was all I said

[11:12:00.0000] <gkellogg>
hsivonen: got it, thanks. The main problem here is that there's really no way, except if the property range can be narrowed, do do _any_ datatype inference without performing datatype inference from the corresponding vocabulary description. If there's another way to get better datatype information out of a doc without relying on external resources, I'd like to know.

[11:15:00.0000] <hsivonen>
gkellogg: I wasn't suggesting that the algorithm was wrong

[11:16:00.0000] <hsivonen>
gkellogg: I was suggesting that RDF could do without having datatyping in the first place

[11:18:00.0000] <Hixie>
when i tell a group that use cases would be helpful if they want the spec changed, after three years of telling them this, they should not respond with "ah, thanks, that's helpful, we'll look for use cases" as if this was the first time they'd heard that use cases might be the best way to give feedback.

[11:19:00.0000] <gkellogg>
Hixie: W3C HTML Data TF is specifically chartered to identify such use cases.

[11:20:00.0000] <Hixie>
jeni's reply suggested that the idea of getting use cases was a novel one

[11:20:01.0000] <Hixie>
so if you're right, apparently not everyone has read the charter

[11:22:00.0000] <gkellogg>
Hixie: http://www.w3.org/2011/htmldata/track/actions/7

[11:23:00.0000] <Hixie>
gkellogg: http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0068.html "OK, that's helpful"

[11:23:01.0000] <Hixie>
anyway

[11:23:02.0000] <Hixie>
i'm not complaining or anything

[11:24:00.0000] <Hixie>
use cases are great

[11:24:01.0000] <Hixie>
i've been asking for them for forever now

[11:27:00.0000] <gkellogg>
Hixie: experience with other groups indicates that collecting use cases is always problematic; it seems like a chore. However, as you point out, you can't really derive requirements without use cases. But in their absence, you may need to draw on anecdotal evidence.

[11:27:01.0000] <Hixie>
no, in their absence, you don't do anything. :-)

[11:31:00.0000] <hsivonen>
Why does MapsGL use WebGL for 2D vector graphics maps?

[11:31:01.0000] <Hixie>
what does it use?

[11:31:02.0000] <zewt>
why not?

[11:31:03.0000] <hsivonen>
instead of using SVG or Canvas 2D

[11:31:04.0000] <Hixie>
ah, dunno

[11:31:05.0000] <hsivonen>
zewt: WebGL isn't a 2D graphics API

[11:31:06.0000] <zewt>
sure it is

[11:31:07.0000] <zewt>
2d is a subset of 3d

[11:32:00.0000] <Hixie>
probably easier to just code 2d as a special case of 3d?

[11:32:01.0000] <zewt>
opengl is very good at 2d graphics

[11:32:02.0000] <Hixie>
i honestly have no idea

[11:32:03.0000] <hsivonen>
zewt: well, MapsGL fails at anti-aliasing where SVG or Canvas 2D would give it "for free"

[11:32:04.0000] <hsivonen>
Hixie: maybe the reason indeed is using the same thing for both streets and the buildings

[11:33:00.0000] <hsivonen>
so the rendering tech doesn't change when zooming in to the building level

[11:33:01.0000] <zewt>
you can open antialiased webgl contexts (may or may not actually be supported, of course)

[11:33:02.0000] <Hixie>
drawing a map is quite a complicated problem, so i wouldn't be surprised if it was just a matter of wanting to only do it once

[11:34:00.0000] <zewt>
(easy to do 2d vector AA in software on anything; no so easy with OpenGL if the underlying hardware isn't good at it)

[11:34:01.0000] <hsivonen>
anyway, great to see Maps features that previously required Android or Flash Player now supported on the Open Web Platform

[11:34:02.0000] <Hixie>
indeed

[11:36:00.0000] <zewt>
also if you already have GPU-based map rendering for some other platform, porting to WebGL is probably easier

[11:37:00.0000] <arv__>
One of the reason to use WebGL over canvas/svg is performance

[11:37:01.0000] <hsivonen>
I wonder how long it will take for a WebGL version of Google Earth to emerge

[12:11:00.0000] <gsnedders>
hsivonen: Well, supported on the "Open Web" if your UA string is correct.

[12:12:00.0000] <gsnedders>
(which I'm not sure really counts as open web, thus the scare quotes)

[12:49:00.0000] <manu-db>
hsivonen, dglazkov, Hixie: Any public feedback on http://convergence.io/ from browser manufacturers yet? (removing CAs via Network Perspectives and Notaries?)

[12:57:00.0000] <hober>
gsnedders: indeed

[13:44:00.0000] <Hixie>
Philip`: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14421

[14:32:00.0000] <adtykfhyipoh>
hey

[14:32:01.0000] <adtykfhyipoh>
I've got a question

[14:34:00.0000] <adtykfhyipoh>
sicking

[14:34:01.0000] <adtykfhyipoh>
hello

[14:34:02.0000] <sicking>
hello

[14:34:03.0000] <adtykfhyipoh>
I have a question about javascript

[14:34:04.0000] <adtykfhyipoh>
I need to save an array of the image tags on a website (var images = document.getElementsByTagname("img");) and I need it stored in another array

[14:35:00.0000] <adtykfhyipoh>
so that when all the images are changed, the copy of the images array is unchanged

[14:41:00.0000] <zewt>
irc is hard

[14:43:00.0000] <bga_>
dom has so many shortcuts. doc.images,  doc.links, window[id] etc

[14:43:01.0000] <bga_>
but ppl use long пУИЕТ

[14:44:00.0000] <bga_>
*gEBTN

[14:44:01.0000] <bga_>
Ж.

[14:44:02.0000] <bga_>
*:/

[14:44:03.0000] <bga_>
stupid autoswitcher

[14:58:00.0000] <smaug____>
window[id] works in general only in quirks mode

[14:58:01.0000] <smaug____>
(and it should be actually removed since it is so error prone)

[14:59:00.0000] <bga_>
but its handy :)

[15:08:00.0000] <ojan>
TabAtkins: do you know any of the editors of http://dev.w3.org/csswg/css3-writing-modes ?

[15:08:01.0000] <ojan>
TabAtkins: I'd like to see the spec change for http://lists.w3.org/Archives/Public/www-style/2011Sep/0375.html

[15:08:02.0000] <ojan>
TabAtkins: not sure who/how to nag about it

[15:45:00.0000] <smaug____>
ojan: so you want fantasai

[15:50:00.0000] <ojan>
smaug____: oh? is she one of the editors?

[15:50:01.0000] <ojan>
/me doesn't know her real name

[15:50:02.0000] <smaug____>
ojan: the spec says Elika

[15:51:00.0000] <ojan>
smaug____: thx

[15:51:01.0000] <smaug____>
ojan: anyway, I copy-pasted your comment to her (she is in  moznet)

[15:51:02.0000] <smaug____>
though, apparently afk

[15:52:00.0000] <ojan>
smaug____: thanks! it's nothing urgent, but just wanted to make sure it doesn't get lost.

[16:12:00.0000] <Hixie>
heycam: ping

[16:12:01.0000] <Hixie>
heycam: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13093

[16:58:00.0000] <Hixie>
man, my css-fu these days is week

[16:58:01.0000] <Hixie>
weak even

[16:59:00.0000] <Hixie>
what's the practical difference between a presentational attribute css rule and a UA stylesheet css rule? just that the user style sheet overrides the UA one but not the pres hints?


2011-10-14
[17:04:00.0000] <dbaron>
Hixie, yeah

[17:05:00.0000] <Hixie>
k

[17:05:01.0000] <dbaron>
Hixie, also affects their interaction with each other, though

[17:05:02.0000] <Hixie>
well sure

[17:06:00.0000] <Hixie>
i thought there might have been a compat reason for the way i made a lot of the border-width rules preshints but the border-style rules ua.css rules

[17:06:01.0000] <Hixie>
but i guess not if that's the only difference

[17:12:00.0000] <zewt>
heh, cheers for everyone making the same mistakes http://unity3d.com/support/documentation/Manual/Security%20Sandbox.html

[17:12:01.0000] <zewt>
You are allowed to download images from servers that do not have a crossdomain.xml file. However, the only thing you are allowed to do with these images is use them as textures in your scene. You are not allowed to use GetPixel() on them. You are also no longer allowed to read back from the screen.

[18:35:00.0000] <heycam>
Hixie, that "global scope polluter property" term disappeared after simplifying the window named property thing

[18:35:01.0000] <Hixie>
ah ok

[18:35:02.0000] <Hixie>
can you update the bug with whatever i need to do, if anything?

[18:35:03.0000] <Hixie>
seems every time i get around to addressing that particular issue, the solution has changed again ;-)

[18:35:04.0000] <heycam>
sure ;)

[18:35:05.0000] <Hixie>
thanks!!

[18:36:00.0000] <heycam>
just gotta go and buy a couch, will leave a comment later today

[18:40:00.0000] <Hixie>
cool, thanks

[19:59:00.0000] <erlehmann>
zewt, Y unity cannot into CORS headers?

[20:05:00.0000] <zewt>
what?

[23:24:00.0000] <annevk>
How do CSS animations or transitions interact with the task queue?

[00:49:00.0000] <zcorpan>
"User agents that support a constructor for an event interface must return true for that interface's extended feature string and the version "4.0"." http://html5labs.interoperabilitybridges.com/dom4events/

[00:51:00.0000] <annevk>
pretty good at ignoring feedback given thus far

[01:15:00.0000] <annevk>
why does ancestor Documents not exist

[01:15:01.0000] <annevk>
now you have to say something like

[01:15:02.0000] <annevk>
documents of the browsing contexts that are ancestor of the document's browsing context

[01:15:03.0000] <annevk>
which is like confusing

[01:32:00.0000] <Hixie>
isn't hasFeature(), like, gone

[01:33:00.0000] <Hixie>
annevk: document.parentNode === null because otherwise security error

[01:33:01.0000] <annevk>
it is, but requests to kill extensions to hasFeature() from DOM Level 3 Events have fallen on death ears

[01:34:00.0000] <annevk>
I just pointed it out again that my comments have been ignored

[01:34:01.0000] <annevk>
now I have to wait another month of course

[01:34:02.0000] <annevk>
but I've only been waiting for answers since March or so, so whatever

[01:34:03.0000] <annevk>
Hixie, I meant more as a concept

[01:35:00.0000] <Hixie>
well i can't complain about people taking long to answer to feedback

[01:35:01.0000] <annevk>
Hixie, not really something we'd expose

[01:35:02.0000] <annevk>
it's more like ignoring feedback

[01:35:03.0000] <annevk>
since they claim they have addressed all feedback

[01:35:04.0000] <Hixie>
just use "document's parent browsing context's document"

[01:35:05.0000] <Hixie>
yeah ignoring feedback is a better thing to complain about

[01:35:06.0000] <annevk>
and then I have to do the work to look up what they missed

[01:36:00.0000] <annevk>
which sucks donkey balls, or something like that

[01:39:00.0000] <annevk>
Hixie, ah, that makes it slightly shorter, thanks

[01:39:01.0000] <annevk>
pretty close to a pretty crappy draft of Fullscreen

[01:40:00.0000] <Hixie>
cool

[01:40:01.0000] <Hixie>
btw if you want all acnestors i think i've got a term like "ancestor browsing contexts" defined

[01:40:02.0000] <Hixie>
check the bc section

[01:40:03.0000] <annevk>
since everyone seems to do something different I specced something close to what Gecko has, left out the keyboard stuff for now, and hope feedback will make it nice

[01:40:04.0000] <annevk>
Hixie, yeah, using that

[01:40:05.0000] <Hixie>
k

[01:51:00.0000] <annevk>
btw, if HTML defined browsing contexts as http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#trees I would get "descendant" for free

[01:52:00.0000] <annevk>
i'll just define descendant for now and leave that as possible future cleanup

[01:52:01.0000] <Hixie>
browsing contexts are weirder, they have openers, secondaries, all kinds of crap

[02:13:00.0000] <jgraham>
/me cowers from the death ears

[03:50:00.0000] <annevk>
/me looks up "cowers"

[04:15:00.0000] <hsivonen>
hmm. I see no mention of ANGLE on Opera 12's about page. Does this mean Opera wrote its own shader validation?

[04:22:00.0000] <hsivonen>
MapsGL not offered to Opera :-(

[04:49:00.0000] <hasather>
hsivonen: I think so yes, see http://www.khronos.org/assets/uploads/developers/library/2011_GDC_WebGL/Opera_GDC-Mar11.pdf

[04:55:00.0000] <hsivonen>
hasather: thanks

[04:56:00.0000] <hasather>
hsivonen: also see http://www.youtube.com/watch?v=BnVy_uCk_es at 06:50

[05:31:00.0000] <gsnedders>
hsivonen: Our DirectX backend is as old as Vega itself (and was mentioned with its announcement) — it predates ANGLE existing.

[05:46:00.0000] <hsivonen>
gsnedders: interesting. I had missed that somehow.

[05:56:00.0000] <gsnedders>
hsivonen: But yeah, we have separate DirectX 9, DirectX 10, OpenGL, and OpenGL ES backends.

[06:53:00.0000] <gsnedders>
Wow. Just had Android crash and lose all my text messages. And not the first time I've had messages vanish due to Android bugs. Not exactly endearing…

[07:36:00.0000] <erlehmann>
gsnedders, intredasting. do you have cyanogen or an old version?

[07:37:00.0000] <gsnedders>
erlehmann: old version

[07:41:00.0000] <erlehmann>
gsnedders, get cyanogen then :3

[07:41:01.0000] <erlehmann>
i won a g1 and even there cyanogen runs. magic.

[07:43:00.0000] <erlehmann>
the bootloader is called the DangerSPL because it has a chance of bricking the device

[07:43:01.0000] <erlehmann>
SUSPENSE

[07:43:02.0000] <gsnedders>
Not exactly impressive that HTC ship something unusable.,

[07:44:00.0000] <gsnedders>
And at least one of the bugs that has annoyed me with Android is unfixed upstream.

[07:53:00.0000] <hsivonen>
I'm waiting for Nexus Prime, because I don't trust non-Nexus devices to get proper software updates

[07:54:00.0000] <gsnedders>
I'm really, very seriously, considering getting a Windows Phone 7 device.

[07:54:01.0000] <gsnedders>
Just… there's something wrong that I've reached the conclusion that they might be the best devices today.

[07:54:02.0000] <hsivonen>
gsnedders: does Windows Phone 7 run any Opera products?

[07:55:00.0000] <gsnedders>
hsivonen: Nope.

[07:55:01.0000] <gsnedders>
(Mobile obviously will never come to it as long as they forbid native code)

[07:56:00.0000] <hsivonen>
gsnedders: I find it a bit surprising that Opera hasn't repurposed the Java version of the Mini front end for WP7 by now

[08:06:00.0000] <erlehmann>
hsivonen, everything with nexus in name is probably a good idea.

[08:06:01.0000] <erlehmann>
gsnedders, WP-7 may have a nice interface, but hackability?

[08:06:02.0000] <erlehmann>
i like the python scripting thing of androi

[08:06:03.0000] <erlehmann>
d

[08:07:00.0000] <gsnedders>
erlehmann: I'm not massively bothered. As long as I have an ssh client…

[08:07:01.0000] <erlehmann>
dumb terminals, here they are again.

[08:08:00.0000] <hsivonen>
sigh. I contacted the front-line support of a corporation that shall remain nameless explaining to them that their site doesn't work with the HTML5 parser in Firefox and I'm the person who wrote the parser and asking them to put me in touch with their technical staff

[08:09:00.0000] <hsivonen>
I got back a canned reply that instructed me to flip a pref in about:config

[08:09:01.0000] <hsivonen>
a pref I implemented

[08:09:02.0000] <hsivonen>
html5.parser.enable

[08:09:03.0000] <zewt>
heh

[08:09:04.0000] <zewt>
so there's a site out there telling people to flip a global preference

[08:10:00.0000] <Ms2ger>
I would be surprised if there was only one

[08:10:01.0000] <hsivonen>
maybe I should accelerate the removal of the pref

[08:11:00.0000] <Ms2ger>
Or rename it again

[08:11:01.0000] <zewt>
html5.parser.enable.by.the.way.the.person.that.told.you.to.set.this.is.dumb

[08:13:00.0000] <zewt>
the most discouraging thing is when you google for an error message, and the first google hit is a mailing list post of: you asking about the error

[08:26:00.0000] <miketaylr>
hsivonen: after finally getting ahold of someone at symantec re: http://www.symantec.com/ja/jp/business/security_response/graphs.jsp?graphid=attacktrends, i was told i probably had a virus

[08:27:00.0000] <miketaylr>
( <title/> )

[08:28:00.0000] <zcorpan>
miketaylr: i guess generally that's true

[08:29:00.0000] <miketaylr>
heh

[08:29:01.0000] <Ms2ger>
Well no, Chrome is the virus ;)

[08:29:02.0000] <hsivonen>
miketaylr: :-(

[08:56:00.0000] <smaug____>
I don't understand 4.8.14.2

[08:56:01.0000] <smaug____>
the "...and then fired again..." part

[08:56:02.0000] <smaug____>
/me files a spec bug

[08:57:00.0000] <Ms2ger>
In which document? :)

[08:57:01.0000] <smaug____>
HTML spec

[09:08:00.0000] <michel_v>
Karl made me do it

[09:11:00.0000] <miketaylr>
whatever it was, my condolences

[09:11:01.0000] <Ms2ger>
/me goes for kicking out isElementContentWhitespace

[09:38:00.0000] <dglazkov>
good morning, Whatwg!

[09:39:00.0000] <Ms2ger>
MORNING

[09:40:00.0000] <gsnedders>
Back from vacation?

[09:41:00.0000] <dglazkov>
gsnedders: me? yes!

[09:42:00.0000] <dglazkov>
gsnedders: a REAMDE vacation

[09:42:01.0000] <gsnedders>
dglazkov: Can't see many words on you.

[09:43:00.0000] <dglazkov>
gsnedders: ok I googled that and still don't understand what you said :)

[09:44:00.0000] <gsnedders>
dglazkov: I tried you READYOU.

[09:44:01.0000] <gsnedders>
a/you/to/

[09:44:02.0000] <dglazkov>
gsnedders: :)

[09:50:00.0000] <Ms2ger>
Does Opera support CORS already?

[09:54:00.0000] <jgraham>
No. Known defect

[10:59:00.0000] <TabAtkins>
jgraham: reading the backscroll, do you honestly disagree that JS is a functional language?  Just to be sure, we're both using the sense of "uses first-class functions quite a lot", right?

[10:59:01.0000] <TabAtkins>
Because if you're just being snarky about the non-CS definition of "functional", then whatever.

[11:32:00.0000] <hober>
annevk5: /me keeps reloading https://bitbucket.org/annevk in anticipation of a fullscreen draft :)

[12:19:00.0000] <Hixie>
TabAtkins: js is not a pure-functional language (it has side-effects) but it can be used as a functional programming language

[12:19:01.0000] <Hixie>
TabAtkins: generally the term "functional programming" refers to not relying on side-effects or state, though, not so much whether the language has first-class functions

[12:19:02.0000] <TabAtkins>
That would be why I didn't call it pure-functional, because that's trivially false. ^_^

[12:19:03.0000] <Hixie>
TabAtkins: though having first-class functions is probably a necessary component

[12:20:00.0000] <Hixie>
or at least, having function references

[12:20:01.0000] <Hixie>
they don't necessarily have to be objects per se

[12:32:00.0000] <Ms2ger>
Hixie, yt?

[12:47:00.0000] <Hixie>
Ms2ger: yo

[12:48:00.0000] <Ms2ger>
Looking at setTimeout

[12:48:01.0000] <Ms2ger>
It takes a float for the timeout argument

[12:49:00.0000] <Hixie>
sounds appropriately crazy

[12:49:01.0000] <Ms2ger>
And then turns it into an int using a custom algorithm that looks almost-entirely-but-not-quite like ToInt32

[12:50:00.0000] <Hixie>
yeah i seem to recall there was some weirdness around that

[12:50:01.0000] <Hixie>
something about not wrapping around or something

[12:50:02.0000] <Hixie>
i forget

[12:50:03.0000] <Hixie>
svn blame might know more

[12:50:04.0000] <Ms2ger>
Ah

[12:52:00.0000] <Ms2ger>
Well, afaict from the code, Gecko doesn't do that

[12:52:01.0000] <Hixie>
it's possible webidl has advanced to the point where it can describe the behaviour necessary for compat, this stuff predates a lot of webidl

[12:53:00.0000] <Hixie>
or the browsers might have become more sane

[12:53:01.0000] <Hixie>
feel free to file a bug saying it should be simplified

[12:57:00.0000] <Ms2ger>
Looks like Opera doesn't wrap

[12:58:00.0000] <Ms2ger>
But I'm not going to wait 2**32 milliseconds to confirm

[12:59:00.0000] <Hixie>
yeah that's the problem :-)

[13:00:00.0000] <Ms2ger>
Filed bug 14469, you can open the testcase now so it's finished when you get there ;)

[13:00:01.0000] <Hixie>
heh

[14:23:00.0000] <jgraham>
TabAtkins: I don't think "has first class functions" is a good definition of "functional programming language"

[14:23:01.0000] <jgraham>
Although I will allow that it supports a functional style

[14:23:02.0000] <jgraham>
In more important questions, wtf is EventException?

[14:23:03.0000] <jgraham>
Is this something I should know about or did D3E invent it?

[14:25:00.0000] <Ms2ger>
D3E nonsense

[14:25:01.0000] <jgraham>
Does anyone apart from Microsof care about that?

[14:25:02.0000] <jgraham>
+t

[14:26:00.0000] <jgraham>
They want to add EventException to testharness.js and I think it is stupid, but I'm not really sure that "this spec shouldn't exist" is a good enough reason to complain

[14:27:00.0000] <jgraham>
Oh, it's in DOM 2 Events too

[14:27:01.0000] <jgraham>
UNSPECIFIED_EVENT_TYPE_ERR

[14:27:02.0000] <jgraham>
Nice

[14:27:03.0000] <Ms2ger>
I just removed it from Gecko

[14:27:04.0000] <Ms2ger>
Anyway, what's up with not being able to make useCapture optional in Java?

[14:28:00.0000] <Ms2ger>
  public void addEventListener(String type, Object listener) {}

[14:28:01.0000] <Ms2ger>
  public void addEventListener(String type, Object listener, boolean capture) {}

[14:28:02.0000] <Ms2ger>
wfm

[14:28:03.0000] <jgraham>
People haven't seriously been complaining about that, have they?

[14:28:04.0000] <jgraham>
You need to make the third param optional for web compat

[14:29:00.0000] <jgraham>
So it's optionality isn't optional to specify

[14:29:01.0000] <Ms2ger>
It is for D3E

[14:29:02.0000] <Ms2ger>
It's a MAY there

[14:29:03.0000] <jgraham>
For real?

[14:29:04.0000] <Ms2ger>
Yes

[14:30:00.0000] <smaug____>
Ms2ger: did I r+ UNSPECIFIED_EVENT_TYPE_ERR patch?

[14:30:01.0000] <smaug____>
maybe I did

[14:30:02.0000] <Ms2ger>
You did

[14:30:03.0000] <smaug____>
maybe I shouldn't have :)

[14:30:04.0000] <jgraham>
That's just... wow... I don't even know what to say

[14:30:05.0000] <smaug____>
since I'm not quite sure I like the DOM4 way to have all the exception type in one spec

[14:30:06.0000] <smaug____>
s/type/types/

[14:32:00.0000] <jgraham>
smaug____: I guarantee to you that in all the cases where it makes a difference having two types there just causes problems (e.g. when authors want to handle exceptions but forget that there are different exceptions for events)

[14:32:01.0000] <Ms2ger>
Also, other specs can define their own types

[14:38:00.0000] <oojacoboo>
hey, anyone on the chrome team?

[14:38:01.0000] <oojacoboo>
I'm seeing a new behavior with tables in Canary

[14:38:02.0000] <oojacoboo>
was curious to know what is causing the change

[14:41:00.0000] <jgraham>
In other news, google dropping code search sucks

[14:48:00.0000] <smaug____>
what is the reason for dropping code search?

[14:49:00.0000] <smaug____>
and where was it announced?

[14:52:00.0000] <Velmont>
They said thei're pulling entire Google Labs. Today. -- I read it in a we're deleting Buzz-post on some google blog.

[14:52:01.0000] <Velmont>
But guess there are much better sources out there on the intarwebs.

[15:02:00.0000] <Ms2ger>
http://googleblog.blogspot.com/2011/10/fall-sweep.html

[15:02:01.0000] <Ms2ger>
/me attempts to improve d3e once more

[15:05:00.0000] <jgraham>
Don Quixote would be proud

[15:09:00.0000] <Ms2ger>
Mm

[15:09:01.0000] <Ms2ger>
If it doesn't work out, I'll just object


2011-10-15
[17:17:00.0000] <fishd>
does anyone know where Element.requestFullScreen is spec'd?

[17:17:01.0000] <fishd>
(other than https://wiki.mozilla.org/Gecko:FullScreenAPI)

[17:18:00.0000] <Hixie>
fishd: anne is speccing it

[17:18:01.0000] <fishd>
Hixie: cool, which wg?  is there a draft already posted someplace?

[17:19:00.0000] <fishd>
there are a lot of funky things w.r.t. the user agent stylesheet rules that webkti implements

[17:19:01.0000] <Hixie>
dunno if it's in the context of a wg

[17:19:02.0000] <Hixie>
he was posting about it on whatwg

[17:19:03.0000] <fishd>
ok

[17:19:04.0000] <fishd>
ah, thanks

[17:19:05.0000] <Hixie>
dunno if he has anything public yet

[17:19:06.0000] <Hixie>
but he said he was nearly ready earlier today

[17:20:00.0000] <Hixie>
so i expect if it's not public yet it'll be public soon

[17:22:00.0000] <fishd>
cool

[18:33:00.0000] <annevk>
fishd, once MikeSmith sets up a repository and I fix a few more things it'll be published

[20:31:00.0000] <MikeSmith>
annevk: http://dvcs.w3.org/hg/fullscreen/

[20:31:01.0000] <annevk>
sweet

[20:31:02.0000] <annevk>
now it's up to me I guess

[20:32:00.0000] <annevk>
/me has not really finished his draft

[22:08:00.0000] <annevk>
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html

[22:08:01.0000] <annevk>
pretty pleased

[22:34:00.0000] <MikeSmith>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9659

[22:35:00.0000] <MikeSmith>
annevk: ↑

[22:35:01.0000] <MikeSmith>
https://bitbucket.org/validator/html-spec/changeset/a1b1ca8f99db

[15:30:00.0000] <zewt>
heh, the idb spec formatting is a bit hard to read

[15:30:01.0000] <zewt>
too many types of text styles all smushed together

[16:45:00.0000] <bga_>
gsnedders http://spa-s3c.blogspot.com/2011/10/spas3c-sv-006opera-browser-101112-0-day.html


2011-10-16
[20:08:00.0000] <robman>
afternoon all 8)  does anyone know if you can get an ImageData directly from an HTMLVideoElement in some way?   or is the only solution to do a 2dcontext.drawImage(video) -> 2dcontext.getImageData(...) pipeline?

[20:09:00.0000] <annevk>
it's the only way

[20:09:01.0000] <robman>
boo

[20:09:02.0000] <robman>
very innefficient

[20:09:03.0000] <robman>
thanks annevk

[21:26:00.0000] <jwalden>
robman: not necessarily inefficient; I could imagine the former call living entirely in GPU memory in the right circumstances, and with good enough implementations

[21:26:01.0000] <jwalden>
whether any of that is the case, I couldn't say, tho

[21:28:00.0000] <zewt>
jwalden: vanishingly unlikely

[21:28:01.0000] <jwalden>
yeah, we're probably not there yet

[21:28:02.0000] <zewt>
well, no--unlikely for both calls

[21:29:00.0000] <zewt>
the first call, perhaps eventually

[21:30:00.0000] <jwalden>
sure, the second basically never will, don't disagree there

[21:30:01.0000] <jwalden>
never said anything about the second :-)

[21:31:00.0000] <zewt>
of course, having the first be on the GPU would mean the second call would be even slower :)

[21:32:00.0000] <zewt>
(if it has to make a GPU to RAM transfer, instead of RAM to RAM, or even better a copy-on-write of the original)

[02:37:00.0000] <annevk>
Ms2ger, congrats on getting all those patches landed

[02:37:01.0000] <annevk>
guess isWhiteSpace should be LATER/WONTFIX

[02:37:02.0000] <Ms2ger>
Mm

[03:13:00.0000] <robman>
zewt / jwalden - wondered what your thoughts on drawImage(video)/getImageData(...) on a hidden canvas context were - does that add any performance improvements or is it effectively just the same

[03:16:00.0000] <robman>
or if anyone else has a view on that too 8)

[07:46:00.0000] <sanxiyn>
Hi!

[07:46:01.0000] <sanxiyn>
This may be of your interest: https://github.com/sanxiyn/csstty

[07:46:02.0000] <sanxiyn>
Started today.

[08:02:00.0000] <sanxiyn>
Hi

[08:44:00.0000] <zewt>
robman: don't have to even put the canvas in a document

[14:23:00.0000] <zewt>
must resist the urge to reply "what about triggering standards mode?"

[16:57:00.0000] <robman>
zewt - thanks for the tip about the DOM-less canvas - will that save much overhead?

[16:57:01.0000] <zewt>
compared to it being hidden? probably not (but you'd have to try it)


2011-10-17
[17:00:00.0000] <robman>
cool...thnx

[17:00:01.0000] <robman>
/me goes off to do some performance tests

[19:54:00.0000] <ttepasse>
Hixie: The example in section 10.1.2.2 still uses the Web SQL Database as an example for Web Workers. Maybe that should change to IndexedDB or clientside DB du jour.

[20:29:00.0000] <annevk>
cpearce, so it sounds like the "fullscreen flag" really ought to be on top-level browsing context instead of Document if all Documents need to have it set

[20:30:00.0000] <annevk>
cpearce, also, thanks for the great comments

[20:39:00.0000] <annevk>
oh wait

[20:39:01.0000] <annevk>
you are saying something else

[20:39:02.0000] <annevk>
maky

[20:39:03.0000] <annevk>
mkay*

[20:40:00.0000] <cpearce>
annevk: heh, comments are all the edge cases I've bumped into so far. ;)  hmm... without the Document.fullscreen attribute we can't represent that a document remains in fullscreen state if its fullscreen element is inserted into another document. Unless we cause that to exit fullscreen mode... not sure we want to do that.

[20:41:00.0000] <annevk>
I guess my idea was that all Documents would be fullscreen if their top-level browsing context is fullscreen

[20:42:00.0000] <annevk>
and then the documents which are highlighted is determined by the "fullscreen element"

[20:43:00.0000] <annevk>
are there use cases to make the moving around of elements not do the simplest thing?

[20:44:00.0000] <annevk>
it seems to me that removing an element that is the fullscreen element should simply clear the fullscreen element for that document and the fullscreen element of any descendant browsing context documents (if any)

[20:44:01.0000] <annevk>
(and a move in the DOM is a remove followed by an insert so that would behave the same)

[20:45:00.0000] <cpearce>
that makes sense. I think that's implied by the gecko spec, it's how I've implemented it so far.

[20:46:00.0000] <annevk>
then for the scenario where a new element becomes the fullscreen element I think nicest would be to find the nearest common ancestor fullscreen element of old and new, remove all old and dispatch events and then set new and dispatch mutation events

[20:46:01.0000] <annevk>
s/mutation/fullscreenchanged/

[20:47:00.0000] <cpearce>
Yup. :)

[20:47:01.0000] <annevk>
the alternative would be to clear "fullscreen element" everywhere, set it anew, and dispatch fullscreenchanged on all documents

[20:48:00.0000] <cpearce>
right, but then you'd see fullscreenchange twice on docs that toggle off and back on again.

[20:48:01.0000] <cpearce>
which could confuse script.

[20:48:02.0000] <annevk>
good point

[20:48:03.0000] <annevk>
okay I'll take a look at fixing this

[20:49:00.0000] <annevk>
time for lunch here

[20:49:01.0000] <annevk>
thanks!

[20:49:02.0000] <cpearce>
np.

[21:41:00.0000] <Hixie>
ttepasse: if you have an example to replace it with, that'd be awesome. send me mail to ian⊙hc if you can help with that.

[22:29:00.0000] <annevk>
ah, cpearce left

[22:33:00.0000] <annevk>
so when removing a "fullscreen element" the order of fullscreenchange, fullscreenElement, and mutation listeners, may be somewhat tricky

[22:34:00.0000] <Hixie>
btw anne i noticed when glancing at your draft that there's a step that says something like "do animations" in what looks like a synchronous algorithm

[22:34:01.0000] <Hixie>
but animations need to spin the event loop to be done

[22:35:00.0000] <annevk>
I guess fullscreenchange cannot be synchronous, because then it would be synchronous mutation event of sorts, but then is fullscreenElement changed by the time the mutation listener is there?

[22:35:01.0000] <annevk>
hmm

[22:35:02.0000] <annevk>
Hixie, so while doing the animation it needs to spin the event loop?

[22:43:00.0000] <annevk>
Also, I guess we should name the event fullscreenchange and not fullscreenchanged

[23:02:00.0000] <Hixie>
annevk: well more likely the algorithm just needs to be async while the event loop continues normally

[23:02:01.0000] <Hixie>
annevk: but you need to handle what happens if fullscreen mode is exited while that's going on

[23:04:00.0000] <annevk>
:(

[23:48:00.0000] <myakura>
MIkeSmith: ping

[23:48:01.0000] <MikeSmith>
myakura: hey man

[23:48:02.0000] <MikeSmith>
we are downstairs in front of the Square Tower

[23:48:03.0000] <myakura>
hiya

[23:48:04.0000] <myakura>
we?

[23:49:00.0000] <myakura>
/me noticed that he typed MIke and wonder if MIke is TM'd or not.

[23:50:00.0000] <MikeSmith>
myakura: me & secret visitor

[23:53:00.0000] <myakura>
hm. I have a meeting at 3pm and will back in an hour. Do you think you two'll still be there?

[23:54:00.0000] <MikeSmith>
yeah, probably

[23:54:01.0000] <MikeSmith>
if our battery power holds up

[23:54:02.0000] <MikeSmith>
but if you don't find us, just ping me

[23:54:03.0000] <myakura>
alright.

[23:55:00.0000] <myakura>
MikeSmith: so, I'm writing about the Testing Activity for my next Web Designing article.

[23:55:01.0000] <MikeSmith>
aha

[23:55:02.0000] <MikeSmith>
cool

[23:55:03.0000] <MikeSmith>
I'm happy to talk with you about it

[23:56:00.0000] <Hixie>
annevk: probably not that big a deal. If anything happens during that step to cancel the fullscreening, just reverse the animation and don't fire anything.

[23:56:01.0000] <myakura>
MikeSmith: and http://www.w3.org/testing/browser/ says like that it hasn't been chartered yet.

[23:56:02.0000] <MikeSmith>
myakura: oh, lemme change that now

[23:56:03.0000] <myakura>
MikeSmith: thanks!

[23:57:00.0000] <myakura>
okay, bbl.

[23:57:01.0000] <MikeSmith>
cheers

[23:58:00.0000] <annevk>
Hixie, yeah, but I guess exitFullscreen() can be invoked then too and requestFullscreen() could be invoked again on some other element

[23:58:01.0000] <annevk>
Hixie, so there probably needs to be some kind of state for all these edge cases

[23:59:00.0000] <Hixie>
annevk: ah, yeah, i forgot this was element-based

[23:59:01.0000] <Hixie>
annevk: btw, did you end up needing anything on the html side?

[23:59:02.0000] <Hixie>
attribute or anything?

[23:59:03.0000] <annevk>
yeah we want <iframe allowfullscreen>

[23:59:04.0000] <Hixie>
is there a bug on it?

[23:59:05.0000] <annevk>
I will file one

[23:59:06.0000] <Hixie>
cool

[23:59:07.0000] <Hixie>
mark it blocker if you need it sooner rather than later

[00:00:00.0000] <annevk>
and the Gecko guys want to exit fullscreen when you navigate

[00:00:01.0000] <Hixie>
roger

[00:00:02.0000] <Hixie>
i can add a hook

[00:00:03.0000] <annevk>
but I'm not sure how that would work yet with events yet

[00:00:04.0000] <annevk>
and what happens when you navigate when of the child browsing contexts instead of the top-level

[00:01:00.0000] <annevk>
sounds good btw

[00:26:00.0000] <annevk>
man if you want to be explicit about how to deal with moving the fullscreen element around it gets hairy

[00:27:00.0000] <annevk>
the fullscreen elements can be in the same document, one can be an ancestor document of the other, and they can share a common ancestor

[00:33:00.0000] <annevk>
in the ancestor case the fullscreen element in the ancestor might also need to be changed depending on what it is

[00:34:00.0000] <annevk>
i guess it's kind of equivalent to the common ancestor case in that way, except there are no descendant documents to notify

[00:48:00.0000] <annevk>
hmm

[00:48:01.0000] <annevk>
"first inclusive ancestor" can probably work

[01:03:00.0000] <annevk>
* A is the old fullscreen element

[01:03:01.0000] <annevk>
* DA is A's node document

[01:03:02.0000] <annevk>
* B is the new fullscreen element

[01:03:03.0000] <annevk>
* DB is B's node document

[01:03:04.0000] <annevk>
* X is the first inclusive ancestor common to A and B

[01:03:05.0000] <annevk>
* Notify changes for descendant documents of X with a non-null fullscreen element

[01:03:06.0000] <annevk>
* Let Z be all descendants of X that are inclusive ancestors of DB

[01:03:07.0000] <annevk>
* Does X's fullscreen element change; if so change/notify

[01:03:08.0000] <annevk>
* Change/notify Z

[01:03:09.0000] <annevk>
that's a whole lot of complexity for a "simple" feature

[01:05:00.0000] <annevk>
open question is when the events are best dispatched

[01:05:01.0000] <annevk>
like do you update all the flags first and then dispatch all the events?

[01:06:00.0000] <annevk>
or do you do that kind of thing on a per document basis? change flag, dispatch event, change flag in next document, dispatch event in next document, etc.

[01:40:00.0000] <annevk>
whether X's fullscreen element changes is also fun...

[01:41:00.0000] <annevk>
  - If Z is empty and X's fullscreen element is not B

[01:41:01.0000] <annevk>
    - X needs to change

[01:41:02.0000] <annevk>
  - Let child be X's child document that is also in Z

[01:41:03.0000] <annevk>
  - If child's browsing context container is not X's fullscreen element

[01:41:04.0000] <annevk>
    - X needs to change

[01:42:00.0000] <annevk>
90% of the complexity of this feature is for something people will not run into

[01:42:01.0000] <annevk>
then again I don't really see a good alternative

[04:50:00.0000] <markss>
Hey I registered for a http://www.w3techcourses.com account but the email failed to send so now I can't confirm my registration. Is there anyone I can contact to fix this?

[05:07:00.0000] <Lachy>
markss, this channel isn't affiliated with the W3C. Try #sysreq on the W3C's IRC server.

[05:29:00.0000] <markss>
Lachy: Alright thanks

[09:43:00.0000] <dglazkov>
good morning, Whatwg!

[09:59:00.0000] <Hixie>
every time i try to talk to people in the Semantic Web community i have the same troubles

[09:59:01.0000] <Hixie>
sigh

[12:37:00.0000] <timeless>
zewt: the reason phone manufacturers rarely update *anything* is because there's no financial incentive to do so, and there is a fiscal penalty for doing so: if it breaks something on an operator's network, the operator will get pissed and ask for money back

[12:38:00.0000] <timeless>
plus, a mobile vendor (like nokia) makes money by selling (new) units, it doesn't make money from units once they are sold

[12:39:00.0000] <timeless>
and in the rare case that a browser actually results in revenue (home/search kickbacks), that money is not sent back to a maintenance team for the product that generated it, instead it is treated as some sort of windfall and absorbed by the company or some future product at large team

[12:41:00.0000] <timeless>
smaug____: fwiw, iPhone Safari doesn't get updated often, just look at how long it took for them to fix the certificate disaster

[12:42:00.0000] <smaug____>
k

[12:42:01.0000] <smaug____>
/me is certainly not going to buy any iPhone anyway

[12:43:00.0000] <smaug____>
N9 might be one option

[12:43:01.0000] <smaug____>
but it is a bit too expensive

[12:43:02.0000] <zewt>
... but google should not have put phone manufacturers in control of updating the browser, just as they're not in control of updating google apps

[12:45:00.0000] <smaug____>
depends on which browser the OS has

[12:46:00.0000] <smaug____>
/me hopes phone manufacturers would use some better browsers than stock browser

[12:47:00.0000] <zewt>
/me hopes Google will supply a sane browser (because it's their job) and phone manufacturers won't fragment things further

[12:47:01.0000] <smaug____>
it is bad if Google controls the whole stack

[13:01:00.0000] <gsnedders>
smaug____: AIUI unless you pay Google (instead of getting Android for free) you can't ship the Google Apps and any non-standard application

[13:02:00.0000] <gsnedders>
smaug____: So OEMs take the default apps and Android for free

[13:06:00.0000] <smaug____>
huh

[13:09:00.0000] <gsnedders>
smaug____: The Google Apps are non-free.

[13:09:01.0000] <gsnedders>
smaug____: (like Gmail, Market, etc.)

[13:12:00.0000] <gsnedders>
smaug____: So you have to get a license from Google to distribute them. They let you have it free in return for advertising revenue, or you can pay and change stuff.

[13:12:01.0000] <timeless>
zewt: the reason phone manufacturers rarely update *anything* is because there's no financial incentive to do so, and there is a fiscal penalty for doing so: if it breaks something on an operator's network, the operator will get pissed and ask for money back

[13:13:00.0000] <timeless>
plus, a mobile vendor (like nokia) makes money by selling (new) units, it doesn't make money from units once they are sold. and in the rare case that a browser actually results in revenue (home/search kickbacks), that money is not sent back to a maintenance team for the product that generated it, instead it is treated as some sort of windfall and absorbed by the company or some future product at l

[13:13:01.0000] <timeless>
arge team

[13:13:02.0000] <timeless>
hober: out of curiosity, which mobile vendors are actually good at browser updates?

[13:13:03.0000] <timeless>
smaug____: fwiw, iPhone Safari doesn't get updated often, just look at how long it took for them to fix the certificate disaster

[13:13:04.0000] <zewt>
deja vu?

[13:13:05.0000] <timeless>
i'm using irccloud

[13:13:06.0000] <zewt>
you're repeating yourself, heh

[13:13:07.0000] <timeless>
i thought i was offline and that things i had said weren't said

[13:14:00.0000] <timeless>
so i queued them in notepad and then sent them again

[13:14:01.0000] <timeless>
it didn't occur to me that they would have been sent

[13:14:02.0000] <timeless>
stuff in other places wasn't sent!

[13:14:03.0000] <timeless>
i believe gsnedders is correct about the Google Apps

[13:14:04.0000] <timeless>
which is a pretty good reason for major vendors to pay in

[13:14:05.0000] <timeless>
as for the n9... dunno

[13:15:00.0000] <timeless>
what's shocked me of late is that i've met a couple of people interested in n8s

[13:15:01.0000] <timeless>
s/people/women/

[13:16:00.0000] <gsnedders>
timeless: AFAIK almost no vendors pay.

[13:27:00.0000] <smaug____>
timeless: n8?

[13:28:00.0000] <smaug____>
isn't that, hmm, old

[13:28:01.0000] <smaug____>
n9 has got lots of media time in Finland

[13:28:02.0000] <timeless>
the n8 is what i got nokia to buy for me right before i left

[13:28:03.0000] <timeless>
and yeah, it's old and sucks

[13:28:04.0000] <timeless>
but has a 12mp camera

[13:29:00.0000] <timeless>
oh, and it turns out that the "new" ui for symbian actually eventually made it out the doors!

[13:29:01.0000] <timeless>
so if i can find Lucy, i can let her consider replacing the old symbian ui with a worse one!

[13:29:02.0000] <timeless>
(but hey, it's "newer")

[13:34:00.0000] <Hixie>
does nobody implement body.onmessage?

[13:35:00.0000] <Hixie>
or does nobody implement window.postMessage()?

[13:36:00.0000] <timeless>
nobody⊙mo or nobody⊙se ?

[13:36:01.0000] <zewt>
the latter exists in Chrome, anyway

[13:36:02.0000] <timeless>
https://developer.mozilla.org/en/DOM/window.postMessage

[13:36:03.0000] <Hixie>
every browser i've tested fails http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/002.html

[13:36:04.0000] <timeless>
msdn.microsoft.com/en-us/library/cc197057(v=vs.85).aspx

[13:36:05.0000] <Hixie>
and i can't work out if it's my fault or not :-)

[13:37:00.0000] <timeless>
it seems that ms has documented body.onmessage

[13:37:01.0000] <timeless>
FAIL (message not received)

[13:37:02.0000] <Hixie>
guess i should test windows

[13:37:03.0000] <timeless>
in IE10 on w8

[13:37:04.0000] <Hixie>
IE?

[13:37:05.0000] <Hixie>
k

[13:37:06.0000] <Hixie>
so

[13:37:07.0000] <Hixie>
is it my fault or what

[13:37:08.0000] <Hixie>
i'm confused

[13:37:09.0000] <Hixie>
oh i guess i nuke the iframe

[13:37:10.0000] <Hixie>
maybe that's why

[13:37:11.0000] <Hixie>
let's fix that

[13:38:00.0000] <Hixie>
timeless: how about now?

[13:39:00.0000] <timeless>
FAIL (message not received); TEST FRAME

[13:39:01.0000] <zewt>
test() not called from anywhere?

[13:39:02.0000] <timeless>
i.e. there's a frame with that other text

[13:39:03.0000] <timeless>
but i'm still getting the fail

[13:39:04.0000] <Hixie>
zewt: 002a.html calls it onmessage

[13:39:05.0000] <Hixie>
timeless: k. thanks for the help.

[13:39:06.0000] <Hixie>
i'll figure this out after lunch.

[13:39:07.0000] <Hixie>
hopefully it's my fault...

[13:39:08.0000] <Hixie>
bbiab

[13:44:00.0000] <smaug____>
Hixie: FF9/10 have "onmessage" in document.body

[13:53:00.0000] <timeless>
fwiw, i get the same results in my slightly dated 32bit Nightly on w8 as i do w/ IE10

[14:03:00.0000] <zcorpan>
Hixie: i guess browsers don't support <body onmessage> properly

[15:07:00.0000] <Hixie>
zcorpan: seems that way

[15:12:00.0000] <Hixie>
yup, looks like no browser implements onmessage="" right

[15:12:01.0000] <Hixie>
oh well

[15:12:02.0000] <zcorpan>
/me files a bug

[15:12:03.0000] <Hixie>
http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/002.html if you need a testcase

[15:12:04.0000] <Hixie>
003.html tests window.onmessage and seems to work everywhere

[15:15:00.0000] <jgraham>
Hixie: Convert the tests to something that can be put in the oficial testsuite, please :)

[15:15:01.0000] <Hixie>
is there documentation on how to do that?

[15:16:00.0000] <jgraham>
http://www.w3.org/html/wg/wiki/Testing/Authoring/

[15:17:00.0000] <Hixie>
wait why does a test have to include a js file?

[15:17:01.0000] <Hixie>
i just want to report the result to the harness

[15:17:02.0000] <jgraham>
Because there are tradeoffs in both directions

[15:17:03.0000] <jgraham>
And this is the one we went with

[15:17:04.0000] <Hixie>
wow this is far too complicated

[15:18:00.0000] <Hixie>
the "basic usage" section of the documentation of the library is longer than most test harnesses i've written :-P

[15:18:01.0000] <jgraham>
Hixie: Having used the "just report a result" system at Opera, it turns out that often "wow this is far too simplistic"

[15:19:00.0000] <jgraham>
Anyway in your case there's no reason not to include the js file

[15:20:00.0000] <Hixie>
tests should never include anything other than what is needed to run the test

[15:21:00.0000] <jgraham>
I really don't see the problem here

[15:22:00.0000] <jgraham>
If it actually changes the results you get, that's differnet

[15:22:01.0000] <jgraham>
But part of the point is that there isn't a way to "just report the results to the harness"

[15:22:02.0000] <Hixie>
the test is 21 lines long. The script library is 1689 lines long. Reporting the result takes one line of code (if (parent.report) (parent.report(result))).

[15:22:03.0000] <Hixie>
that's the problem

[15:23:00.0000] <Hixie>
er, with one fewer parenthesis

[15:23:01.0000] <jgraham>
That's not a problem

[15:23:02.0000] <jgraham>
Also, one of the main points is that there isn't a harness

[15:23:03.0000] <jgraham>
everyone does something slightly different

[15:24:00.0000] <Hixie>
including a library that is 80 times bigger than the test is a problem, imho. it means that the bulk of what the test is really testing has nothing to do with what it is trying to test.

[15:24:01.0000] <jgraham>
We use some weird POST-to-localhost thing that will hopefully be replaced soon. Mozilla use moxhitests. Webkit use something that prints to stdout (I think?)

[15:24:02.0000] <jgraham>
The library almost entirely assumes a good ecmascript implementation

[15:25:00.0000] <jgraham>
That turns out to be a reasonable assumption

[15:26:00.0000] <jgraham>
I consider the requirement to run the test in an iframe or popup window to be much more worrying

[15:27:00.0000] <Hixie>
to each his own, i guess

[15:29:00.0000] <zewt>
when it comes to official test sets, i hope not :)

[15:37:00.0000] <Hixie>
i don't understand opera's behaviour in http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/001.html

[15:38:00.0000] <Hixie>
webkit's behaviour is interesting. looks like it handles both postMessage(data, [], '*') and postMessage(data, '*', [])

[15:38:01.0000] <Hixie>
might be worth putting that in the spec

[15:48:00.0000] <zcorpan>
ugh. please no

[15:49:00.0000] <Hixie>
looks like only webkit implements it at all in a usable way, so i've changd the spec to match webkit

[15:49:01.0000] <Hixie>
the number of people who have gotten confused as to the correct order of those arguments is sufficiently high that i think it's worth it

[15:49:02.0000] <Hixie>
there doesn't seem to be a downside really

[15:50:00.0000] <zcorpan>
O_O

[15:50:01.0000] <zewt>
making code 50/50 inconsistent instead of people getting an error and learning to do it right is a very clear downside

[15:51:00.0000] <zcorpan>
i'm pretty sure our developers will refuse to implement that

[15:51:01.0000] <Hixie>
well opera's implementation of the spec so far seems quite broken anyway, so... :-)

[15:51:02.0000] <zcorpan>
what's broken?

[15:52:00.0000] <Hixie>
you fire a SYNTAX_ERR if there's three arguments

[15:52:01.0000] <Hixie>
regardless of what they are

[15:52:02.0000] <Hixie>
unless they're both '*'

[15:52:03.0000] <Hixie>
(or presumably any valid origin, i haven't tested other origins)

[15:53:00.0000] <annevk>
what did you pass as argument?

[15:55:00.0000] <zcorpan>
i'll have to look at that tomorrow i guess. now sleep

[15:55:01.0000] <annevk>
Hixie, I think we throw because you pass the arguments in the wrong order

[15:55:02.0000] <Hixie>
i tried both orders

[15:55:03.0000] <annevk>
targetOrigin comes before transfer

[15:55:04.0000] <Hixie>
i tried both orders

[16:07:00.0000] <Hixie>
hey, check it out. my test was bogus after all and opera is not buggy, and webkit doesn't support both orders

[16:07:01.0000] <Hixie>
<-- idiot

[16:08:00.0000] <Hixie>
still, opera should throw, and does not, for postMessage('', '*', '*')

[16:08:01.0000] <annevk>
if only you could read what you wrote the first time around

[16:08:02.0000] <gsnedders>
Hixie: throw TypeError?

[16:08:03.0000] <Hixie>
yeah

[16:24:00.0000] <annevk>
cpearce, if fullscreen element or its ancestor is removed from document and that document has descendant documents with non-null fullscreen elements, should we fire events on those documents?

[16:24:01.0000] <annevk>
cpearce, in Gecko per http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1210 that does not even seem possible

[16:24:02.0000] <annevk>
cpearce, also, I guess the other question is in what scenario something like that happens and whether we need to deal with it

[16:25:00.0000] <cpearce>
annevk: if the descendents change out of full-screen mode due to an ancestor being removed, then yes, we should fire fullscreenchanged in them.

[16:26:00.0000] <annevk>
cpearce, but as my test shows in e.g. Gecko you no longer have Document objects in such a scenario

[16:27:00.0000] <cpearce>
annevk: hmmm....

[16:27:01.0000] <annevk>
I also sort of fail to see the use case for catching this case, but it's not too hard

[16:28:00.0000] <annevk>
The other question I had was about order of events relative to setting the "fullscreen element"

[16:28:01.0000] <annevk>
do you fire the event after you have set/unset "fullscreen element" for the entire chain or do you do it per document?

[16:29:00.0000] <cpearce>
I queue a task to fire the event as I traverse the doc tree making changes.

[16:30:00.0000] <cpearce>
I'm in fact firing the change events for enter before change events for exit, but that's easily changeable.

[16:30:01.0000] <annevk>
e.g. say the order becomes top-down when setting and bottom-up when unsetting, if I set and there's two documents, and the event dispatches on the first, the second still has a null fullscreen element?

[16:31:00.0000] <cpearce>
The events won't dispatch until all docs in the tree have their fullscreen element set

[16:31:01.0000] <annevk>
but you just said you fire them as you traverse?

[16:31:02.0000] <annevk>
oh, queue a task

[16:31:03.0000] <cpearce>
bingo.

[16:32:00.0000] <annevk>
but then you can observe state separately

[16:32:01.0000] <cpearce>
how?

[16:32:02.0000] <annevk>
state change* e.g. in mutation events

[16:33:00.0000] <annevk>
or from a timer

[16:33:01.0000] <annevk>
state change and event dispatch should always be coupled I think

[16:34:00.0000] <annevk>
and I guess it makes sense you do it on a per-document basis since they might not be all related browsing contexts

[16:34:01.0000] <cpearce>
I'm not sure what you mean. All the state change happens in the task which queues tasks to fire the events.

[16:35:00.0000] <annevk>
doesn't that mean you can have other tasks running before the event is dispatched?

[16:35:01.0000] <cpearce>
yep...

[16:35:02.0000] <annevk>
e.g. in XHR you queue a task to change readyState and dispatch an event

[16:36:00.0000] <annevk>
I think pretty much all APIs work that way

[16:36:01.0000] <cpearce>
we have the same problem with the video spec, state can change before the event runs.

[16:36:02.0000] <cpearce>
but fortunately you can query Document.fullscreen to tell if the target has entered or exited fullscreen...

[16:38:00.0000] <annevk>
I don't really know the media API

[16:39:00.0000] <annevk>
so why not have a single task which changes state and dispatches the event?

[16:43:00.0000] <cpearce>
annevk: It is simpler to implement with the events queued, since if you dispatch them synchronously in the task to change state, the world could change underneath you in the event handler. I can't really think of any reason from a user's perspective though.

[16:46:00.0000] <annevk>
cpearce, so is requestFullscreen and exitFullscreen fully synchronous then?

[16:46:01.0000] <cpearce>
annevk: at the moment they are for us.

[16:46:02.0000] <cpearce>
we don't have an animation for enter, if you wanted an animation I think you'd need to make them async though.

[16:47:00.0000] <annevk>
yeah, it seems like we would want that down the road

[16:47:01.0000] <cpearce>
we have a bug on file for that too.

[16:47:02.0000] <annevk>
I wonder what sicking thinks of changing state sync and notifying async

[16:49:00.0000] <annevk>
I guess you pretty much have to change state sync for :fullscreen

[16:51:00.0000] <annevk>
and someone needs to verify for me this doesn't fuck with "unit of related similar-origin browsing contexts"

[16:51:01.0000] <annevk>
because I cannot really work it out

[16:52:00.0000] <annevk>
I guess it might in a way

[16:53:00.0000] <annevk>
cpearce, what if the top-level browsing context is already busy while you call requestFullscreen, don't you get blockage?

[16:53:01.0000] <annevk>
I guess currently there's no multi-process going on for that in Gecko

[16:54:00.0000] <cpearce>
mmmm.... we have one process, and are moving to conceptually one process per tab, so that can't happen (I think...).

[16:55:00.0000] <cpearce>
and in multi-process firefox I dispatch an event to the chrome process to make it fullscreen, so it is technically async to make the window full-screen, but I've not focused too much on that yet.

[16:56:00.0000] <cpearce>
since we're a few months out from enabling multi-process by default.

[16:58:00.0000] <annevk>
yeah I guess the method can just wait

[16:58:01.0000] <annevk>
you can probably not cause deadlock so I guess it should be okay, but it would be nice if someone could verify

[16:59:00.0000] <annevk>
don't really want to prevent implementations that have multi-process outside per-tab

[16:59:01.0000] <annevk>
I think e.g. Chrome wanted to move in that direction

[16:59:02.0000] <cpearce>
yeah.


2011-10-18
[17:01:00.0000] <annevk>
btw

[17:01:01.0000] <annevk>
fullscreendeny, would that fire async too?

[17:02:00.0000] <cpearce>
I think it should match fullscreenchange, so yes.

[17:03:00.0000] <annevk>
do we use "deny" elsewhere in the platform?

[17:03:01.0000] <annevk>
could make it fullscreenerror I suppose... meh

[17:05:00.0000] <cpearce>
fullscreendenied matches tense with fullscreenchanged, and matches tense with the events fired in the video spec, many of which are past tense. I don't really know the other HTML specs.

[17:06:00.0000] <annevk>
well "changed" is going to become "change"

[17:07:00.0000] <annevk>
we have hashchange for instance

[17:08:00.0000] <cpearce>
I think it makes sense for it to be past tense if it's dispatched async.

[17:10:00.0000] <AryehGregor>
hashchange is surely dispatched async.

[17:11:00.0000] <annevk>
generally events do not use past tense

[17:11:01.0000] <annevk>
there's a couple for which it was a mistake

[17:12:00.0000] <annevk>
but we have volumechange, durationchange, ratechange

[17:12:01.0000] <Hixie>
hashchange is fired synchronously from within a task that is itself async

[17:14:00.0000] <cpearce>
argh, what am I saying, our implementation already dispatches mozfullscreenchange, not *changed. :P

[17:14:01.0000] <annevk>
Hixie, can you dispatch events on documents that are not the active document?

[17:14:02.0000] <cpearce>
I do think it sounds funny having a fullscreendeny event though.

[17:15:00.0000] <Hixie>
annevk: well

[17:15:01.0000] <annevk>
fullscreenerror might be somewhat better

[17:15:02.0000] <cpearce>
well, it's not really an error though.

[17:15:03.0000] <Hixie>
annevk: you mean using that document as the context? you can, but the task would just sit in the queue until it became active

[17:15:04.0000] <annevk>
okay

[17:15:05.0000] <Hixie>
i would avoid it where possible though

[17:16:00.0000] <Hixie>
since the doc could get discarded any minute anyway

[17:16:01.0000] <annevk>
Hixie, if you remove an <iframe> from a document does that <iframe>'s document become inactive?

[17:17:00.0000] <Hixie>
this part of the spec is a little controversial, but:

[17:17:01.0000] <annevk>
cpearce, if you navigate a child browsing context that has a fullscreen element in it, and then navigate back, is it still the fullscreen element?

[17:17:02.0000] <Hixie>
annevk: it is "active" but not "fully active"

[17:18:00.0000] <annevk>
okay

[17:18:01.0000] <Hixie>
annevk: it stops getting events and stuff though, iirc

[17:18:02.0000] <cpearce>
annevk: We should exit full-screen mode when a full-screen document navigates.

[17:19:00.0000] <Hixie>
annevk: (because the event loop only takes tasks for docs that are fully active)

[17:20:00.0000] <annevk>
cpearce, the top-level browsing context?

[17:20:01.0000] <annevk>
Hixie, thanks

[17:21:00.0000] <cpearce>
annevk: If we navigate a non-full-screen child iframe and the parent is full-screen, there's no need to break out of full-screen.

[17:21:01.0000] <annevk>
cpearce, right

[17:22:00.0000] <annevk>
cpearce, but what if you navigate a child frame that contains a fullscreen element?

[17:22:01.0000] <annevk>
I mean the top-level browsing context will still have a fullscreen element in that case too

[17:23:00.0000] <cpearce>
annevk: It seems that if a document has a full-screen element, it must be full-screen? So since it's full-screen we should exit full-screen mode?

[17:24:00.0000] <smaug____>
annevk: how does "fullscreendeny"/"...error" solve the problem that it may take arbitrary amount time for user to decide whether to allow the fullscreen mode

[17:24:01.0000] <annevk>
your use of fullscreen confuses me, do you mean exit it for that document only or the whole top-level-browsing context?

[17:25:00.0000] <cpearce>
smaug: we use a ask forgiveness model now, so the decision to deny can be made synchronously.

[17:25:01.0000] <smaug____>
?

[17:25:02.0000] <cpearce>
annevk: If we exit for one, we exit for all.

[17:25:03.0000] <smaug____>
user many not allow or deny

[17:25:04.0000] <smaug____>
user may just be slow to say anything

[17:26:00.0000] <zewt>
i notify in advance that i will not forgive any browser vendor that lets pages show fullscreen ads at me

[17:26:01.0000] <annevk>
cpearce, okay

[17:26:02.0000] <cpearce>
smaug: I mean, *we* don't have UI which requires the user to approve requests for full-screen, we just go full-screen and give them the option to exit. I guess though you're concerned about vendors which do want to implement an approval UI...

[17:27:00.0000] <smaug____>
that is no-go

[17:27:01.0000] <smaug____>
I'm pretty sure vendors don't want to implement such thing

[17:27:02.0000] <zewt>
(pretty disconcerting that it seems nobody but me seems to care if pages are allowed to show fullscreen ads)

[17:28:00.0000] <smaug____>
going to fullscreen *must* ask permission

[17:28:01.0000] <smaug____>
(or the permission can be given beforehand)

[17:28:02.0000] <cpearce>
if you put ads in an iframe they won't be able to go full-screen unless there's a fullscreenallowed attribute on the iframe.

[17:28:03.0000] <zewt>
smaug____: but from what i've heard, both FF and Chrome intend to go fullscreen without asking (and then asking after it's too late) ...

[17:28:04.0000] <smaug____>
uh

[17:29:00.0000] <smaug____>
that sure hasn't been security reviewed

[17:29:01.0000] <zewt>
which i find horrifying

[17:29:02.0000] <smaug____>
it sounds absolute horrifying

[17:29:03.0000] <cpearce>
That has. We show a bug warning to make it obvious you've gone fullscreen.

[17:29:04.0000] <zewt>
i don't want a big, obnoxious warning every time i go fullscreen (like Flash does), that's also bad

[17:29:05.0000] <gsnedders>
IMO Flash's behaviour is fine.

[17:30:00.0000] <zewt>
and ... again, that doesn't solve the problem that it's letting pages go fullscreen to show ads (asking after is *too late* then)

[17:30:01.0000] <zewt>
(it's already shoved a gigantic ad in my face)

[17:30:02.0000] <gsnedders>
To go full-screen, the change must either happen as a result of a user initiated action, or must be confirmed by the user, IMO.

[17:30:03.0000] <smaug____>
cpearce: what is the reason to allow web page to do such a major change to the UI without asking user's permission?

[17:31:00.0000] <gsnedders>
Which addresses all the major uses of Flash full-screen I can think of.

[17:31:01.0000] <cpearce>
right, the fullscreen request is only granted in user initiated action.

[17:31:02.0000] <zewt>
gsnedders: both of those are still intending to require it to be within a click/keypress, but that doesn't solve these problems

[17:31:03.0000] <cpearce>
So permission is implicit.

[17:31:04.0000] <zewt>
uh

[17:31:05.0000] <gsnedders>
/me is rather out-of-touch of all of this stuff, though

[17:31:06.0000] <zewt>
sorry, "implicit permission" doesn't make sense, heh

[17:32:00.0000] <gsnedders>
zewt: If it's harder to do than in Flash, people will keep using Flash for stuff like full-screen video.

[17:32:01.0000] <smaug____>
clicking something on the page is not the same as giving permission

[17:32:02.0000] <gsnedders>
So we can't make it considerably harder than with Flash, IMO.

[17:32:03.0000] <gsnedders>
Like, a site moving to HTML for video shouldn't regress the UX.

[17:32:04.0000] <gsnedders>
By asking permission extra times.

[17:33:00.0000] <zewt>
gsnedders: importing major problems of Flash into HTML because people will continue to use Flash is a very poor rationale--there's a *reason* i use flashblock!

[17:33:01.0000] <zewt>
(of course, any sane UI would have the major response be "allow this, and don't ask in the future", so you usually only have to agree to it the first time)

[17:34:00.0000] <gsnedders>
If I press a button on YouTube to go full screen, I damn well want it to go full screen. I don't want to then have to confirm it. Even the first time.

[17:34:01.0000] <smaug____>
(there is a reason why I don't have Flash installed in this browser profile)

[17:34:02.0000] <zewt>
gsnedders: that implies pages being able to smear gigantic ads in my face without permission; so I say, too bad, live with it

[17:34:03.0000] <zewt>
no way that I can see of allowing one without the other

[17:36:00.0000] <zewt>
it's bad enough that I'm afraid to click anywhere in the window on things like image hosts, for fear that a page will use it to open a popup; this would be so much worse

[17:36:01.0000] <annevk>
not "too bad", if we're not competitive with the usability of Flash people will just use that

[17:36:02.0000] <gsnedders>
Yeah. If it's too restrictive people simply won't use it.

[17:37:00.0000] <smaug____>
zewt: with Chrome you can fear also that clicking anywhere in the window starts recording and sending your audio to google ;)

[17:37:01.0000] <zewt>
if flash lets people format the user's hard drive, we'd have to let them do that too, or they'll just keep using flash? heh

[17:38:00.0000] <gsnedders>
zewt: There's a rather large difference.

[17:38:01.0000] <zewt>
smaug____: sounds like a massive security hole

[17:38:02.0000] <annevk>
non-rational arguments ftw

[17:38:03.0000] <zewt>
gsnedders: difference of magnitude only

[17:38:04.0000] <annevk>
o_O

[17:38:05.0000] <zewt>
the idea that html has to let people do everything flash does, regardless of if that causes serious, obnoxious problems on the web, is a bad one

[17:38:06.0000] <smaug____>
zewt: that is Google's "clicking gives permission" -permission model

[17:38:07.0000] <annevk>
but that's not the idea

[17:39:00.0000] <zewt>
sure seems like it

[17:40:00.0000] <annevk>
then you haven't really been paying attention

[17:40:01.0000] <zewt>
non-rational arguments ftw

[17:41:00.0000] <zewt>
disagreeing with me doesn't mean i havn't been paying attention

[17:41:01.0000] <annevk>
e.g. we didn't copy the crossdomain.xml disaster

[17:41:02.0000] <zewt>
no, you designed something better for its use cases; you're not doing that here

[17:42:00.0000] <annevk>
I don't really see a better way here to be honest

[17:42:01.0000] <annevk>
I also hardly see the popup abuse you talk about

[17:43:00.0000] <annevk>
making the popular use case impossibly annoying is just not going to work

[17:43:01.0000] <zewt>
plenty of random sites open popups during the first click event they see, to work around the user-interaction restriction

[17:43:02.0000] <zewt>
(don't have one off-hand)

[17:44:00.0000] <zewt>
how is it "impossibly annoying"? it's the model used by geolocation

[17:47:00.0000] <annevk>
geolocation is infrequent, fullscreen is frequent

[17:47:01.0000] <zewt>
hardly infrequent if you're searching on mobile

[17:47:02.0000] <smaug____>
how often do you use fullscreen, I mean from different domains?

[17:48:00.0000] <gsnedders>
I find it annoying in the geolocation case, but I think that's partly a UI issue.

[17:49:00.0000] <annevk>
smaug____, pretty often I think, mostly for video, sometimes slideshows

[17:49:01.0000] <smaug____>
and they are really from different domains?

[17:50:00.0000] <zewt>
smaug____: FF6's geoloc confirmation box is sort of annoying, because you have to open a dropdown to get to the most common answer for most people (always)

[17:50:01.0000] <gsnedders>
/me is more than happy to try full-screen with explicit user confirmation first, but will need to watch for user feedback

[17:50:02.0000] <smaug____>
I would have guessed most of the fullscreen usage comes from youtube

[17:50:03.0000] <zewt>
three "yes"/"no"/"just this once" buttons would be nicer

[17:50:04.0000] <annevk>
smaug____, there's quite a bit of self-hosted video out there as well

[17:52:00.0000] <zewt>
i suppose also because the confirmation is "out-of-line"; at least for mouse-initiated events, it'd be nicer (at least for fullscreen buttons) if the box appeared over the button you clicked

[17:52:01.0000] <smaug____>
zewt: I don't recall what FF6 did. Nightly has IMO quite good UI for geolocation permission

[17:52:02.0000] <annevk>
cpearce, can you reply to Darin Fisher on the mailing list with Mozilla's use cases for not ignoring calls to requestFullscreen while fullscreen?

[17:53:00.0000] <cpearce>
sure.

[17:53:01.0000] <zewt>
smaug____: http://zewt.org/~glenn/ff6%20doorhanger.png

[17:53:02.0000] <smaug____>
zewt: seems like Nightly has that

[17:53:03.0000] <smaug____>
and it is IMO ok API

[17:54:00.0000] <smaug____>
s/API/UI/

[17:54:01.0000] <zewt>
it's not bad, but could be streamlined as I said ^

[17:54:02.0000] <smaug____>
you can click share, or just ignore the whole thing

[17:54:03.0000] <zewt>
better than a modal dialog, obviously

[17:55:00.0000] <smaug____>
the point is that if you don't want to share, you don't need to do anything

[17:55:01.0000] <smaug____>
and if you explicitly want to share always, you need to click once more

[17:56:00.0000] <zewt>
yeah, but again, my most common answer (always) is a clumsier two-step UI, and if that was used for confirming fullscreen, it's inconveniently way in the corner instead of near whatever fullscreen button I clicked (putting aside keyboard events)

[17:57:00.0000] <smaug____>
is always the most common answer?

[17:57:01.0000] <zewt>
i can't speak for everyone :)

[17:57:02.0000] <smaug____>
to me the most common answer is "I don't care", so I don't click anything

[17:57:03.0000] <smaug____>
and next most common answer is, "ok, allow this time"

[17:58:00.0000] <zewt>
for me in the fullscreen case, i'm pretty sure the only two i'd use are "always" and "no"

[17:59:00.0000] <zewt>
("always" if it's a fullscreen I actually requested; "never" if it's a mysterious attempt to go fullscreen that I didn't ask for)

[18:07:00.0000] <Hixie>
why does opera not work on http://www.hixie.ch/tests/adhoc/dom/css/StyleSheet/002.html ?

[18:08:00.0000] <Hixie>
wait, IE doesn't either now

[18:08:01.0000] <Hixie>
aw man, what have i done now

[18:08:02.0000] <zewt>
Hixie: the tried and true "paste on irc" debugging technique

[18:10:00.0000] <Hixie>
ok IE's problem is it misteriously only finds 2 links

[18:10:01.0000] <Hixie>
but what's opera doing

[18:10:02.0000] <Hixie>
o_O

[18:10:03.0000] <Hixie>
opera's not running the timeout? o_O

[18:10:04.0000] <gsnedders>
Hixie: I wonder if the setTimeout is running not when you think it is

[18:11:00.0000] <Hixie>
maybe

[18:11:01.0000] <gsnedders>
Hixie: It's running it. After it has run the second script.

[18:11:02.0000] <Hixie>
how can that be

[18:11:03.0000] <Hixie>
it's a 100ms timeout and the third link takes 2 seconds to load

[18:12:00.0000] <gsnedders>
Hixie: DSE enabled?

[18:12:01.0000] <Hixie>
DSE?

[18:12:02.0000] <gsnedders>
Delayed Script Execution

[18:12:03.0000] <Hixie>
what is that?

[18:12:04.0000] <gsnedders>
opera:config#Extensions|DelayedScriptExecution

[18:13:00.0000] <gsnedders>
Hmm, has no effect.

[18:13:01.0000] <gsnedders>
Hixie: speculative parsing + some more complexity

[18:16:00.0000] <gsnedders>
Hixie: Are you sure Opera blocks on link elements?

[18:17:00.0000] <gsnedders>
Hixie: Note that behaviour is likely different between Op12 and Op11.50

[18:18:00.0000] <Hixie>
yes, opera is blocking (for more than 150ms) on the link elements.

[18:18:01.0000] <Hixie>
but it's blocking less than 1000ms

[18:18:02.0000] <Hixie>
or something

[18:18:03.0000] <Hixie>
i can't say i understand what opera is doing

[18:19:00.0000] <Hixie>
oh no

[18:19:01.0000] <_bga>
http://www.youtube.com/watch?v=Ws6AAhTw7RA

[18:19:02.0000] <Hixie>
i was timing it wrong

[18:19:03.0000] <Hixie>
ok, opera isn't blocking at all

[18:19:04.0000] <Hixie>
ok that's another bug then :-)

[18:20:00.0000] <Hixie>
it acts like it's blocking

[18:20:01.0000] <Hixie>
i mean, the page takes 2 seconds to load and all

[18:20:02.0000] <annevk>
that you can detect it is prolly a bug

[18:20:03.0000] <Hixie>
i don't understand what opera's doing at all. it has all the disadvantages of blocking and none of the advantages.

[18:20:04.0000] <annevk>
oh

[18:20:05.0000] <annevk>
that does sound wrong

[18:22:00.0000] <gsnedders>
AFAIK it only blocks on a CSSOM call while there is a stylesheet yet to load

[18:23:00.0000] <gsnedders>
Or at least that's the theory

[18:23:01.0000] <gsnedders>
So, on the whole, I think the .sheet accesses block

[18:33:00.0000] <Hixie>
gsnedders: so why doesn't the script run until after parsing has finished?

[18:33:01.0000] <Hixie>
gsnedders: note how parsed gets set to true

[18:33:02.0000] <Hixie>
oh wait, i see what you're saying

[18:34:00.0000] <Hixie>
interesting

[18:34:01.0000] <Hixie>
so opera blocks the script itself

[18:34:02.0000] <Hixie>
huh

[18:35:00.0000] <annevk>
yeah, we just stop script executing until loading and parsing is done

[18:35:01.0000] <annevk>
execution*

[19:04:00.0000] <annevk>
when is Chrome going to return "" for canPlayType("video/mp4")?

[19:05:00.0000] <annevk>
"next couple months" in http://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html for a reasonable definition of "next couple" has not really happened it seems

[19:05:01.0000] <annevk>
or am I missing something?

[19:16:00.0000] <annevk>
cpearce, so given what Hixie said earlier about inactive documents it seems not dispatching fullscreenchange on removed documents or documents navigated away from is the way to go

[19:18:00.0000] <cpearce>
no. we should still dispatch, so that if the document is re-added or navigated back to, it gets a notification. otherwise if we navigate back, it will still think it's in fullscreen mode. we'd need to rely on the event not being dispatched until the doc is reactivated though (if I understood that correctly that should happen?)

[19:19:00.0000] <cpearce>
does that make sense?

[19:19:01.0000] <annevk>
I guess we could do that too, but Hixie said he rather avoids it

[19:20:00.0000] <annevk>
cpearce, btw, for requestFullscreen if you are already fullscreen, exitFullscreen is going to do the wrong thing

[19:20:01.0000] <cpearce>
how so?

[19:21:00.0000] <annevk>
I'm on site A that embeds site B

[19:21:01.0000] <annevk>
site A does requestFullscreen

[19:21:02.0000] <annevk>
then site B does requestFullscreen

[19:21:03.0000] <annevk>
then site B does exitFullscreen

[19:21:04.0000] <annevk>
A is no longer fullscreen

[19:22:00.0000] <cpearce>
hmmm. true.

[19:23:00.0000] <annevk>
so either the entire design needs a revamp to allow for a single browsing context go in and out of fullscreen rather than a whole set or we should give up on this use case

[19:24:00.0000] <annevk>
I think

[19:31:00.0000] <cpearce>
how annoying.

[19:31:01.0000] <annevk>
is it easy to display a single browsing context (including descendants of course) fullscreen?

[19:32:00.0000] <annevk>
basically displaying fullscreen on a per-Document basis

[19:32:01.0000] <annevk>
that way you can have a nested stack if so desired

[19:33:00.0000] <annevk>
and it would definitely make the whole dispatch "fullscreenchange" everywhere stuff easier

[19:33:01.0000] <annevk>
since that will only affect a single document

[19:34:00.0000] <annevk>
also solves the potential cross-process issue

[19:34:01.0000] <cpearce>
Not really. then you need to pop the rendering of documents out of their rendering targets, which greatly complicates things. With the nested full-screen approach, all you need is to apply css rules, and you're there.

[19:37:00.0000] <annevk>
sigh

[19:38:00.0000] <annevk>
the other way is pretty silly too though

[19:38:01.0000] <annevk>
not being able to fullscreen a video while fullscreen

[19:45:00.0000] <cpearce>
annevk: I think we should just have exitFullScreen() exit fullscreen state on the document and all descendent documents. Then in my powerpoint/video use case, users can use the video controls to exit fullscreen on the video element but remain in fullscreen in the slide deck. The UA can and should break out of all fullscreen on ESC keypress though, where they'll call exitFullScreen() on the...

[19:45:01.0000] <cpearce>
...root doc.

[19:46:00.0000] <cpearce>
where the UA will call exitFullScreen() on the root doc that is. Users should be absolutely sure that when they press ESC, they've exited fullscreen.

[19:47:00.0000] <annevk>
it should probably also set the frame element of the parent document to null or some such

[19:48:00.0000] <annevk>
otherwise B is still fullscreen

[19:48:01.0000] <annevk>
just not its embedded video (maybe)

[19:50:00.0000] <cpearce>
right, exitFullScreen() on the root document should reset fullscreen state (Document.fullscreenElement, Document.fullscreen) on the root document and all its descendents. So it would exit fullscreen in all documents completely.

[19:50:01.0000] <cpearce>
I wonder if that's going to confuse people...

[19:51:00.0000] <annevk>
I'm not talking about the root document

[19:51:01.0000] <annevk>
A embeds B

[19:51:02.0000] <annevk>
through <iframe> A1

[19:51:03.0000] <annevk>
if B goes fullscreen A1 will become the fullscreen element of A

[19:52:00.0000] <annevk>
if B then invokes exitFullscreen that should be reset somehow

[19:54:00.0000] <cpearce>
right, I get you. I guess that should become null as you suggest, which is equivalent to making A's document fullscreen without a specific fullscreen element.

[19:56:00.0000] <annevk>
I think it would also make sense that requestFullscreen can only be invoked for a descendant of the current fullscreen document

[19:57:00.0000] <annevk>
so you only traverse in one direction

[19:57:01.0000] <annevk>
cpearce, should we add document.requestFullscreen?

[20:00:00.0000] <cpearce>
annevk: I don't think we really need document.requestFullscreen, you can just use document.body.requestFullscreen(). When I said "making A's document fullscreen..." the result is its body is displayed fullscreen, though it's not reported as the fullscreen element in Document.fullscreenElement.

[20:02:00.0000] <annevk>
given the current styling rules the result is most definitely not the same

[20:03:00.0000] <annevk>
we could of course have exitFullscreen on a descendant of the top-level browsing context make it set the fullscreen element of its parent to its parent root element

[20:05:00.0000] <cpearce>
how is document.body.requestFullScreen() not the same as document.requestFullScreen()?

[20:05:01.0000] <cpearce>
I guess document.body != root?

[20:05:02.0000] <annevk>
depends on how you define things

[20:06:00.0000] <annevk>
I'm just saying that setting A's fullscreen element to null is probably not the correct way here

[20:08:00.0000] <cpearce>
If we dispatch a fullscreenchange event when we change A's fullscreen element (to whatever) then A will have the opportunity to request the fullscreen element to what it meant it to be.

[20:09:00.0000] <cpearce>
And yeah, only granting requests for fullscreen in a descendant of the fullscreen document (if there is one) simplifies implementation. I can't really think of a case were it would be useful to grant requests from sibling/cousin documents.

[20:09:01.0000] <annevk>
that'll give you flickering, but I guess that's somewhat acceptable

[20:09:02.0000] <annevk>
for this use case you want the root element to be the fullscreen element anyway I think

[20:10:00.0000] <annevk>
cpearce, about the styling rules, should we have transform:none for :fullscreen-ancestor and probably disable transitions/animations?

[20:10:01.0000] <annevk>
cpearce, also seems like background:black needs to be complemented by color:#fff or some such

[20:12:00.0000] <cpearce>
annevk: not sure about transfoms etc. That's outside of my expertise. Probably worth suggesting.

[20:14:00.0000] <annevk>
they create stacking contexts afaik, so...

[20:14:01.0000] <annevk>
will discuss with roc at some point I guess

[20:14:02.0000] <annevk>
better sort the API side out first

[20:17:00.0000] <roc>
yeah we should have transform:none

[20:19:00.0000] <roc>
whether cancelling fullscreen on a subdocument also cancels fullscreen on the parent document is a tricky one

[20:20:00.0000] <roc>
we may need some per-document flag to indicate whether the document requested fullscreen

[20:21:00.0000] <annevk>
yeah

[20:21:01.0000] <annevk>
because now in the A B case above

[20:21:02.0000] <annevk>
if B calls requestFullscreen and then exitFullscreen

[20:21:03.0000] <annevk>
A would still be fullscreen

[20:21:04.0000] <annevk>
which is obviously wrong

[20:21:05.0000] <roc>
there are use-cases where it should cancel fullscreen on the parent, and use-cases where it shouldn't

[20:21:06.0000] <annevk>
cpearce, ^^

[20:21:07.0000] <roc>
maybe if we have a per-doc flag to indicate whether it wants to be fullscreen

[20:21:08.0000] <annevk>
I guess we need to track which documents went fullscreen

[20:22:00.0000] <roc>
which is set on requestFullScreen, and cleared on exitFullScreen

[20:22:01.0000] <roc>
and then exitFullscreen would remove fullscreen status from all the ancestors up to and excluding the first one that has the want-fullscreen flag set

[20:23:00.0000] <annevk>
exitFullscreen also needs to clear all descendants

[20:23:01.0000] <roc>
yes ok

[20:23:02.0000] <annevk>
yeah that additional state is needed otherwise you get sad behavior

[20:23:03.0000] <Hixie>
annevk: re earlier, i'd rather avoid sending events to inactive documents if we can by arranging the api so it's not needed, but if it's needed, sobeit

[20:24:00.0000] <annevk>
Hixie, is it better to state "do animation async" or "spin the event loop until the animation is finished"

[20:24:01.0000] <annevk>
and what is the difference?

[20:24:02.0000] <cpearce>
roc: what element would become fullscreen when then want-fullscreen doc returns to being fullscreen? its root element? what was formerly its fullscreen eleent?

[20:25:00.0000] <annevk>
former fullscreen element is prolly best

[20:25:01.0000] <jamesr>
so you have a stack of fullscreen elements to pop out of?

[20:26:00.0000] <annevk>
yeah

[20:26:01.0000] <Hixie>
annevk: not much different. "spin the event loop" is defined as just queuing a task to continue running the algorithm :-)

[20:27:00.0000] <Hixie>
annevk: so it depends on whether you want stuff happening in the background or whether you want it in a task

[20:27:01.0000] <Hixie>
annevk: ("stuff" being anything in your algorithm other than the animation)

[20:28:00.0000] <annevk>
method -> state change -> non blocking animation -> events

[20:28:01.0000] <annevk>
is prolly the order we should have

[20:29:00.0000] <annevk>
not sure what should happen if requestFullscreen or exitFullscreen is invoked during the non-blocking animation

[20:29:01.0000] <annevk>
i guess you would get some additional events

[20:36:00.0000] <roc>
ugh, the idea of a stack kinda sucks

[20:37:00.0000] <jamesr_>
/me dislikes stack

[20:38:00.0000] <roc>
what if we let each document have it's own fullscreen element, and define the concept of an effective fullscreen element, which is either the document's own fullscreen element, or the element for a fullscreen subdocument

[20:38:01.0000] <annevk>
alternatives: 1) not make this work 2) make it possible for a single document to go fullscreen

[20:39:00.0000] <roc>
jamesr_: it would be helpful if we had more feedback from Webkit people; I met two different Chrome people working on fullscreen last week yet it's Mozilla and Opera working on the spec

[20:39:01.0000] <annevk>
roc, darin fisher asked questions on list

[20:39:02.0000] <roc>
good, I'm behind

[20:40:00.0000] <roc>
ah, only three hours ago, I don't feel bad about that :-)

[20:40:01.0000] <annevk>
:)

[20:40:02.0000] <annevk>
how does the effective fullscreen element concept help?

[20:41:00.0000] <roc>
define styling in terms of it

[20:42:00.0000] <annevk>
oh I read it wrong

[20:42:01.0000] <annevk>
they could be the same right?

[20:42:02.0000] <roc>
they could be

[20:43:00.0000] <roc>
it means that if a subdocument exits fullscreen then the fullscreen element reverts to whatever the document requested

[20:43:01.0000] <roc>
without needing a stack

[20:43:02.0000] <annevk>
if a subdocument goes fullscreen does the document get a notification change?

[20:43:03.0000] <roc>
yes

[20:45:00.0000] <annevk>
it's sort of the same as a stack I guess, it's just an implementation detail

[20:45:01.0000] <jamesr_>
roc, the apple guys rambo'd an implementation into 5.1 as i understand it

[20:45:02.0000] <jamesr_>
roc, including such wonderful things like overriding offsetWidth/offsetHeight for some crazy compat hack in some scenario

[20:46:00.0000] <annevk>
should prolly go with "fullscreen element" and "original fullscreen element" so it's clear what fullscreenElement and :fullscreen refer to

[20:46:01.0000] <roc>
jamesr_: sweet

[20:46:02.0000] <jamesr_>
so now we're mostly trying to play catch-up. i'll try to prod the googlers involved with the chromium implementation to participate more as the opportunity arises

[20:50:00.0000] <annevk>
"fullscreen element", "original fullscreen element", "requestfullscreen invoked", and "fullscreen allowed"

[20:50:01.0000] <annevk>
is the state required I guess

[20:51:00.0000] <roc>
thanks

[20:58:00.0000] <annevk>
lunch and stuff, I'll redo my sketches from yesterday to work out this new model

[20:58:01.0000] <annevk>
I haven't committed anything thus far

[20:58:02.0000] <annevk>
on the plus side this does seem easier than the call requestFullscreen method anywhere model

[21:01:00.0000] <jarek->
Hi

[21:01:01.0000] <jarek->
CSS2 spec defines {nonascii} as [\240-\377]

[21:01:02.0000] <jarek->
but I'm not sure what actually 240-377 range refer too

[21:02:00.0000] <jarek->
this is obviously not range from ASCII table

[21:02:01.0000] <jarek->
it also doesn't look like UTF

[21:02:02.0000] <jarek->
s/refer/refers

[21:10:00.0000] <annevk>
jarek, isn't there some note explaining it?

[21:10:01.0000] <annevk>
jarek, so there is, which says the octal codes are Unicode

[21:12:00.0000] <jarek>
annevk: I see, thanks

[21:20:00.0000] <jarek>
so it is allowed to have signs such as ® or µ inside css ID names?

[21:20:01.0000] <jarek>
that's interesting

[21:21:00.0000] <Hixie>
what's a "css ID name"?

[21:21:01.0000] <Hixie>
do you mean the #foo syntax or id="foo"?

[21:21:02.0000] <jarek>
Hixie: e.g. #headyer® > h1

[21:21:03.0000] <Hixie>
ah. well you can have anything in that, even spaces, if you escape it

[21:21:04.0000] <Hixie>
e.g. #\  { ... }

[21:22:00.0000] <Hixie>
matches elements whose id is a space

[21:22:01.0000] <jarek>
but id="foo®" is not allowed, right?

[21:22:02.0000] <Hixie>
not that that's a legal ID in HTML

[21:22:03.0000] <jarek>
so what's the point in allowing it in CSS idents?

[21:22:04.0000] <Hixie>
in HTML, id="" can take any value except one containing spaces, and except the empty string

[21:23:00.0000] <Hixie>
well, nothing stops someone from applying CSS to a language that uses spaces in IDs

[21:23:01.0000] <annevk>
once we tie CSS closer to the DOM there will be

[21:24:00.0000] <annevk>
but then it will still have to work

[21:24:01.0000] <annevk>
really going now

[21:24:02.0000] <Hixie>
even then someone could define a mapping

[00:53:00.0000] <annevk>
lunch breaks these days take a while

[00:53:01.0000] <annevk>
I do know a whole lot more about the component model so that's nice

[00:54:00.0000] <Hixie>
every time i end up in a discussion with semantic web people, i end up questioning why we even do microdata at all

[00:55:00.0000] <Hixie>
(then i remember there's some interesting use cases with drag and drop)

[00:55:01.0000] <Hixie>
(but those are never the ones they mention, and the ones they mention almost always seem to be either unrealistic or theoretical)

[00:58:00.0000] <annevk>
it's such a time sink

[00:59:00.0000] <annevk>
and HTML is really somewhat unique in that

[01:30:00.0000] <annevk>
hmm

[01:30:01.0000] <annevk>
so I think the fullscreen model still does not work cpearce :(

[01:31:00.0000] <annevk>
cpearce, Document is fullscreen, same document hosts a couple of videos by means of <video> elements

[01:31:01.0000] <annevk>
cpearce, document.exitFullscreen is going to do the wrong thing

[01:44:00.0000] <MikeSmith>
hsivonen: small patch review when you have time

[01:44:01.0000] <MikeSmith>
https://gist.github.com/1294834

[01:44:02.0000] <MikeSmith>
for http://bugzilla.validator.nu/show_bug.cgi?id=865

[02:00:00.0000] <annevk>
cpearce, I wrote an email

[02:00:01.0000] <annevk>
guess I'll write the WHATWG Weekly if there's anything to report on

[02:00:02.0000] <jgraham>
annevk: This concept of nested fullscreen seems like it will make for a confusing user experience

[02:00:03.0000] <jgraham>
I could be wrong

[02:01:00.0000] <annevk>
your site is displayed fullscreen, you have a video in it

[02:01:01.0000] <annevk>
the user hits the fullscreen button on the video, then exits

[02:02:00.0000] <annevk>
what is the expected user experience?

[02:02:01.0000] <annevk>
to me it seems pretty obvious you want the site to remain fullscreen

[02:02:02.0000] <annevk>
but I could be wrong

[02:02:03.0000] <jgraham>
I'm not sure

[02:03:00.0000] <jgraham>
It seems like you could get into a situation where you think "exit fullscreen" will actually cause you to exit fullscreen when it won't

[02:04:00.0000] <annevk>
the alternative is to not support nesting and if you want nesting you need to implement your own concept of fullscreen

[02:04:01.0000] <annevk>
which is kind of sucky given all the benefits of using fullscreen

[02:05:00.0000] <jgraham>
I wonder if it is a problem if a site takes you two levels of fullscreen deep, gives you an "exit fullscreen" button and meanwhile draws something that looks like maximised browser chrome on the inner fullscreen

[02:05:01.0000] <foolip>
won't calling requestFullscreen when already in fullscreen cause the fullscreen'd element to change?

[02:05:02.0000] <foolip>
if so, they could just have the "exit fullscreen" button call fullscreen on another element in this situation

[02:05:03.0000] <foolip>
although the native UI won't do the same thing

[02:05:04.0000] <jgraham>
Maybe it's not, since you could do that even without the concept of nested fullscreen

[02:06:00.0000] <jgraham>
(but if there is a browser escape hatch that only works one level deep, it could be more confusing)

[02:06:01.0000] <foolip>
still, if I ever actually wanted to really exit fullscreen, I'd be pretty annoyed if I found myself in n levels of fullscren

[02:06:02.0000] <annevk>
foolip, yeah, then you get a disparity between <video controls> and <video> with site-supplied controls

[02:06:03.0000] <annevk>
to exit fullscreen you press "Esc"

[02:07:00.0000] <annevk>
we'll clearly advertise that in the UI and it will go through everything

[02:08:00.0000] <jgraham>
I guess as long as browsers implement a method that blows away all fullscreen there's no problem

[02:08:01.0000] <foolip>
anyway, the user putting a page into fullscreen with F11 isn't the same as requestFullscreen right?

[02:08:02.0000] <jgraham>
Is it possible for sites to bind to the esc key? Or is that forbidden?

[02:08:03.0000] <foolip>
so the case where a site just happens to be in fullscreen without knowing it can be handled

[02:09:00.0000] <annevk>
foolip, I would sort of like it to be the same

[02:09:01.0000] <annevk>
jgraham, the site would never get hold of this key basically

[02:09:02.0000] <annevk>
jgraham, while in fullscreen

[02:09:03.0000] <annevk>
foolip, i.e. have the API and UI work together

[02:10:00.0000] <foolip>
hmm, that does sound nice I agree

[02:11:00.0000] <jgraham>
So that is equivalent to requestFullscreen on the root element?

[02:11:01.0000] <annevk>
or on a video element

[02:11:02.0000] <annevk>
kind of depends

[02:11:03.0000] <jgraham>
What? Why would video be special?

[02:17:00.0000] <foolip>
A fullscreen button in native controls and option in the context menu of <video> would make sense, but not so much for <input>

[02:18:00.0000] <annevk>
we should definitely have it on the native controls

[02:18:01.0000] <jgraham>
But also for <canvas> or <svg> or <div> with a video and some other stuff in

[02:19:00.0000] <annevk>
dunno about those

[02:19:01.0000] <jgraham>
Well I don't necessarily think we should

[02:19:02.0000] <jgraham>
But video isn't really that special

[02:19:03.0000] <annevk>
yes it is

[02:19:04.0000] <foolip>
the spec could allow it, but I doubt anyone will implement it

[02:19:05.0000] <annevk>
for <video>?

[02:19:06.0000] <foolip>
for <input> :)

[02:19:07.0000] <annevk>
oh

[02:19:08.0000] <jgraham>
Only in the case it has native controls. Even then it could be using other stuff synced to the video

[02:20:00.0000] <jgraham>
That would mean that taking it fullscreen alone didn't make sense

[02:20:01.0000] <annevk>
sounds like an edge case

[02:20:02.0000] <foolip>
jgraham, then the page author will have to provide fullscreen controls

[02:20:03.0000] <foolip>
UI for picking a random element to fullscreen would have to look something like dragonfly's focus rectangles, i.e. intolerable

[02:21:00.0000] <jgraham>
Right, I'm not saying that will work

[02:21:01.0000] <jgraham>
I'm saying that the converse will break sometimes

[02:21:02.0000] <foolip>
absolutely

[02:21:03.0000] <jgraham>
I don't know how often that will be

[02:21:04.0000] <foolip>
all of my <track> demos so far will break

[02:21:05.0000] <foolip>
but that's fine I think

[02:22:00.0000] <jgraham>
An end user that doesn't understand the implementation may disagree ofc

[02:22:01.0000] <jgraham>
Anyway, I don't know

[02:22:02.0000] <foolip>
uh, yeah, users...

[02:23:00.0000] <foolip>
I do look forward for bug reports that the captions don't show in fullscreen because the page author did it using scripts

[02:23:01.0000] <jgraham>
Possibly people only use video with native controls in testcases so this is irrelevant

[02:23:02.0000] <foolip>
s/for/to/

[02:24:00.0000] <foolip>
yeah, you don't see them a lot

[02:25:00.0000] <zcorpan>
annevk: video with custom controls isn't an edge case

[02:26:00.0000] <zcorpan>
custom controls for video and fullscreen is kind of a problem. you might want to allow the user to enter fullscreen from the context menu of the video, but you still want to show the custom controls in fullscreen

[02:28:00.0000] <jgraham>
There could be some mechanism for changing the element that will go fullscreen. That could be evil though

[02:28:01.0000] <foolip>
zcorpan, presumably not without some involvement from the script managing the controls?

[02:28:02.0000] <annevk>
zcorpan, we were not talking about custom controls

[02:35:00.0000] <zcorpan>
what were you talking about? custom captions?

[02:35:01.0000] <zcorpan>
seems like you'd want those in fullscreen too

[02:35:02.0000] <zcorpan>
foolip: what can the script do if the user fullscreened from the video's context menu?

[02:36:00.0000] <foolip>
zcorpan, if there is an event when fullscreen happens and some kind of container element then presumably it can make the controls visible in fullscreen as well

[02:37:00.0000] <annevk>
yeah, the site could check fullscreenchange events and retarget accordingly

[02:37:01.0000] <foolip>
but I doubt anyone would, scripts will mostly assume that the context menu and native controls do not exist

[02:37:02.0000] <foolip>
and break if they do

[02:38:00.0000] <annevk>
it seems reasonable for browsers to provide native controls if the fullscreen element is the video element itself

[02:38:01.0000] <roc>
what problem are you guys talking about?

[02:38:02.0000] <annevk>
UI and API-based fullscreen interaction

[02:39:00.0000] <roc>
ah

[02:39:01.0000] <annevk>
roc, could you look at my most recent email to the WHATWG list?

[02:40:00.0000] <roc>
ok

[02:41:00.0000] <roc>
I would not allow cancelFullScreen to leave full-screen state if the user initiated it

[02:42:00.0000] <annevk>
is that in reply to my email?

[02:46:00.0000] <zcorpan>
foolip: you mean you would change the 'fullscreen element' after the user fullscreened the video?

[02:47:00.0000] <annevk>
fwiw, if there are custom controls I very much doubt the user will right-click

[02:48:00.0000] <roc>
annevk: yes

[02:49:00.0000] <annevk>
because it doesn't address my email

[02:50:00.0000] <annevk>
site goes fullscreen (either API or UI-wise, I don't really care) then you want to view some video in it that's in the same document

[02:50:01.0000] <annevk>
and you want to continue using the site

[02:50:02.0000] <annevk>
after viewing the video, or maybe halfway

[03:04:00.0000] <foolip>
zcorpan, either that or if there is always a container into which more elements can be stuffed

[03:04:01.0000] <foolip>
but that seems a bit magical

[03:14:00.0000] <annevk>
roc, did you see http://krijnhoetmer.nl/irc-logs/whatwg/20111018#l-783 ?

[03:19:00.0000] <roc>
yeah

[03:19:01.0000] <roc>
well, I just read your link

[03:20:00.0000] <annevk>
I haven't really figured out a simple way to make the single document case work yet :(

[03:21:00.0000] <annevk>
I guess authors can hack around it using <iframe srcdoc=""> but that seems like a really ugly workaround

[03:24:00.0000] <roc>
one option is that the video fullscreen controls could explicitly save the previous fullscreen element, if any, and then when un-full-screening the element you either requestFullScreen on the old element or else cancelFullScreen if there wasn't one

[03:25:00.0000] <annevk>
does that assume custom controls?

[03:26:00.0000] <annevk>
it doesn't seem nice if the API and UI have wildly different implementations

[03:27:00.0000] <annevk>
I suppose you could also make this work UI-wise somehow, but it's not pretty

[06:11:00.0000] <annevk>
http://www.identityblog.com/?p=1201

[07:05:00.0000] <smaug____>
annevk: ttp://www.identityblog.com/?p=1201 is interesting

[07:05:01.0000] <smaug____>
annevk: http://www.identityblog.com/?p=1201 is interesting

[07:06:00.0000] <smaug____>
thanks for the link

[09:41:00.0000] <dglazkov>
good morning, Whatwg!

[10:00:00.0000] <jarek>
Hi

[10:00:01.0000] <jarek>
which specification introduces the "@supports" atrule?

[10:01:00.0000] <jarek>
I have stumbled upon it in one example in http://www.w3.org/TR/css3-fonts

[10:02:00.0000] <hasather>
jarek: http://www.w3.org/TR/css3-conditional/#at-supports

[10:03:00.0000] <jarek>
hasather: thanks

[10:04:00.0000] <jarek>
btw, do you know if any browser supports @supports?

[10:09:00.0000] <zewt>
@supports (@supports)

[10:18:00.0000] <jarek>
http://www.w3.org/TR/css3-fonts/ uses following code in one example:

[10:18:01.0000] <jarek>
font-family: Mercury Serif, serif;

[10:18:02.0000] <jarek>
is this really valid? Shouldn't Mercury Serif be put between quotes?

[10:21:00.0000] <jarek>
"Font family names must either be given quoted as strings, or unquoted as a sequence of one or more identifiers. This means most punctuation characters and digits at the start of each token must be escaped in unquoted font family names."

[10:22:00.0000] <miketaylr>
i would quote mercury serif, yes

[10:25:00.0000] <jarek>
so Mercury Serif is a valid name, but 9Mercury Serif would fail :/

[10:49:00.0000] <Ms2ger>
jarek, yes

[10:49:01.0000] <Ms2ger>
Fun, isn't it?

[14:01:00.0000] <jgraham>
So is David Flanagan writing a html parser in js?

[14:06:00.0000] <Ms2ger>
Along with his dom implementation, yes

[14:06:01.0000] <Ms2ger>
https://github.com/andreasgal/dom.js

[14:06:02.0000] <Ms2ger>
"all HTML parser tests pass!"

[14:10:00.0000] <jgraham>
So is that actually a necessary part of dom.js?

[14:11:00.0000] <jgraham>
And what's next, the network layer?

[14:17:00.0000] <Ms2ger>
That'll be in rust, more likely

[14:18:00.0000] <jgraham>
So what I don't understand is where script scheduling fits is

[14:18:01.0000] <jgraham>
*in

[14:18:02.0000] <jgraham>
That is tightly coupled to the parser

[14:19:00.0000] <jgraham>
So it seems weird to have those in different languages

[14:19:01.0000] <jgraham>
But writing the scheduler in javascript seems... unlikely

[14:19:02.0000] <jgraham>
But maybe I am wrong about one of those things

[14:20:00.0000] <Ms2ger>
Dunno, haven't been following closely

[14:20:01.0000] <Ms2ger>
What I know is from http://dl.dropbox.com/u/4186469/rust-all-hands-w2011/assets/fallback/index.html around slide 38

[14:21:00.0000] <Ms2ger>
Though that claims the HTML parser would be in rust

[14:32:00.0000] <zcorpan>
TabAtkins: now this is some flippin https://twitter.com/#!/wilto/status/126342267337318400


2011-10-19
[17:18:00.0000] <jarek>
Hi

[17:18:01.0000] <jarek>
what's the difference between '::before' and ':before", and '::after' and ':after'?

[17:19:00.0000] <jarek>
the CSS3 spec defines only '::before' and '::after'

[17:19:01.0000] <jarek>
but I can see the other format all over the web

[17:21:00.0000] <jarek>
nvm

[17:21:01.0000] <jarek>
just found this http://www.impressivewebs.com/before-after-css3/

[19:38:00.0000] <annevk>
Hixie, hey, I'll file bugs once we sorted out the fullscreen model

[19:38:01.0000] <annevk>
still seems a bit unclear (to me anyway)

[19:42:00.0000] <annevk>
jarek, note how that article is missing the point; the single-colon syntax does not work for new pseudo-elements, only those introduced prior to the double-colon syntax

[19:42:01.0000] <annevk>
oh you are not her

[19:42:02.0000] <annevk>
e

[20:33:00.0000] <annevk>
on the other hand API-based and UI-based fullscreen necessarily have to be different already of course as navigation should not cause UI-based fullscreen to exit

[20:34:00.0000] <zewt>
annevk: "UI-based" is ambiguous--F11 fullscreen and native-video-controls-fullscreen are very different

[20:35:00.0000] <erlehmann>
it is funny: in the evince PDF reader there exist „presentation“ and „fullscreen“ side-by-side with different semantics. quite some time, they behaved funny (yet predictable) when interleaving them.

[20:37:00.0000] <annevk>
zewt, I guess they are

[20:39:00.0000] <annevk>
maybe we should just not bother with nesting of requestFullscreen

[20:39:01.0000] <zewt>
i do like the possibility of native and scripted fullscreen being identical, though

[20:40:00.0000] <erlehmann>
in during category error.

[20:40:01.0000] <zewt>
what? heh

[20:40:02.0000] <erlehmann>
not true?

[20:40:03.0000] <zewt>
("native" referring to video controls, not F11)

[20:40:04.0000] <erlehmann>
oh.

[20:40:05.0000] <zewt>
don't know what you said

[20:41:00.0000] <zewt>
parse error :)

[20:41:01.0000] <erlehmann>
a category error is, basically, treating things from different categories the same. in software, this is almost guaranteed to lead to problems later on. but i thought of “F11”.

[20:42:00.0000] <zewt>
... it's also conceivable that native video fullscreen could use the fullscreen API, while still not allowing nesting

[20:42:01.0000] <zewt>
at least then the interactions would be clear, and the other useful side-effects

[20:43:00.0000] <erlehmann>
nested fullscreen … fullception. or screenception?

[20:43:01.0000] <erlehmann>
WE NEED TO SCREEN FULLER.

[20:43:02.0000] <zewt>
erlehmann: enterFullscreen followed by the user clicking a native video fullscreen box

[20:44:00.0000] <erlehmann>
my angler sense tingles. fishing possibilities ahead?

[20:45:00.0000] <erlehmann>
(users may or may not be confused. it is unclear to me what they would expect.)

[20:45:01.0000] <annevk>
maybe we should have document.requestFullscreen and it would be quite a bit different

[20:45:02.0000] <annevk>
and element.requestFullscreen would be for the <video> case and such

[20:45:03.0000] <zewt>
annevk: why have them be different?

[20:46:00.0000] <annevk>
if you press F11 you don't want a black background and such

[20:46:01.0000] <annevk>
you just want your document to be fullscreen

[20:46:02.0000] <zewt>
confused--F11 is browser fullscreen, pages don't have control over that

[20:46:03.0000] <annevk>
the idea would be to give them control

[20:47:00.0000] <zewt>
but it's a separate mode entirely (affects all tabs in the window; doesn't go away on navigation)

[20:53:00.0000] <erlehmann>
ha!

[20:53:01.0000] <erlehmann>
see? confusion everywhere.

[20:58:00.0000] <annevk>
zewt, i guess the navigation would be different

[21:07:00.0000] <zewt>
annevk: if you want to fullscreen the tab without getting the black background (etc), you can just document.documentElement.enterFullscreen(), right? due to :not(:root)

[21:07:01.0000] <annevk>
oh right, I forgot about that hack

[21:08:00.0000] <zewt>
better than having two entry points, IMO

[21:08:01.0000] <annevk>
given that they're fundamentally different I'm not so sure

[21:09:00.0000] <zewt>
well, i'm just talking about the black background, etc--the fullscreen API shouldn't have any control over whole-window fullscreen

[21:09:01.0000] <zewt>
(if it should--why?)

[21:10:00.0000] <annevk>
I don't really see the difference

[21:10:01.0000] <zewt>
("window fullscreen" being F11 "affects the whole window", vs. tab-specific fullscreen that this API deals with)

[21:11:00.0000] <zewt>
i don't see the similarity :)

[21:11:01.0000] <zewt>
if I hit F11, I want the browser to stay fullscreen permanently until I hit F11 again; individual pages shouldn't affect (or care) about that

[21:11:02.0000] <zewt>
(or necessarily even be able to tell)

[21:12:00.0000] <annevk>
they can tell pretty easily

[21:12:01.0000] <zewt>
that is, F11 fullscreen shouldn't affect eg. fullscreenElement

[21:14:00.0000] <zewt>
why would a page want to activate window fullscreen (instead of just fullscreening the document)?

[21:14:01.0000] <annevk>
I don't think they'd want that, but the visual effect is pretty much identical

[21:15:00.0000] <annevk>
I mean sure one allows you to navigate and probably switch tabs, but things within the current document should probably work identical

[21:16:00.0000] <zewt>
i just think--well, what Darin said, that it's a separate UA feature that the UA can deal with, fullscreen api doesn't need to talk about it

[21:23:00.0000] <Hixie>
annevk: roger

[21:52:00.0000] <annevk>
zewt, yeah I guess

[21:52:01.0000] <annevk>
so how about this

[21:53:00.0000] <annevk>
since each Document has the fse (fullscreen element) and original fse, you can allow one-level of nesting per-Document

[21:53:01.0000] <annevk>
first time you do requestFullscreen fse gets set

[21:53:02.0000] <erlehmann>
oh well. i quite like the way i have to press F11.

[21:53:03.0000] <erlehmann>
to get fullscreen. it is the only way now.

[21:53:04.0000] <erlehmann>
goodbye, F11.

[21:54:00.0000] <annevk>
second time you do reqeustFullscreen original fse becomes fse, and fse becomes whatever requestFullscreen was invoked upon

[21:54:01.0000] <annevk>
erlehmann, huh?

[21:54:02.0000] <erlehmann>
annevk, i will probably not need it for the stuff i need it now. mainly web-based presentations and games.

[21:54:03.0000] <annevk>
if you then exitFullscreen fse becomes original fse again

[21:55:00.0000] <erlehmann>
because they will use the scripted fullscreen facilities, right?

[21:55:01.0000] <erlehmann>
so, goodbye F11. :3

[21:55:02.0000] <zewt>
annevk: what's the "original fse"? that's just ... null, isn't it?

[21:55:03.0000] <annevk>
well, I sort of think F11 should still give you fullscreenchange events

[21:55:04.0000] <annevk>
zewt, initially fse and original fse are null

[21:56:00.0000] <zewt>
annevk: are you basically suggesting a stack with a max size of 2? (implemented as two values rather than an array)

[21:56:01.0000] <erlehmann>
annevk, anythink you could use fullscreenchange events in that case for that is not layout?

[21:56:02.0000] <annevk>
zewt, you need original fse also if you are doing fullscreen in a descendant document, but yeah, that's the suggestion

[21:57:00.0000] <annevk>
erlehmann, not sure what you are suggesting

[21:57:01.0000] <zewt>
i'm not sure either way if it's really important to be able to do the "api fullscreen -> second fullscreen -> exit to the first fullscreen" thing

[21:57:02.0000] <erlehmann>
annevk, i am not suggesting. just musing and  asking.

[21:57:03.0000] <zewt>
(not necessarily saying it's not, just not sure)

[21:58:00.0000] <annevk>
zewt, yeah, I sort of think we should maybe disallow that for now (requestFullscreen would just fail) and we'll see what happens

[21:58:01.0000] <zewt>
annevk: i think maybe it should succeed, and switch the element

[21:59:00.0000] <zewt>
eg. so video fullscreen buttons still work (they just don't stack)

[21:59:01.0000] <annevk>
so you have your powerpoint, go fullscreen in your video, and then you exit and it all falls apart?

[21:59:02.0000] <zewt>
maybe if there's a way to implement the stack behavior manually, for people who really want to ... not sure if that would work

[22:00:00.0000] <zewt>
doesn't fall apart, it behaves predictably--just not necessarily the way the page wanted

[22:00:01.0000] <zewt>
hmm

[22:01:00.0000] <zewt>
i'm biased by wanting to see video native controls just be defined as "transition to fullscreen" (with some trusted flag to ignore fullscreenEnabled, perhaps)

[22:01:01.0000] <zewt>
because it seems like that would make it all fit together a lot better

[22:03:00.0000] <zewt>
(if there's any possibility of that happening, it probably needs to happen early, or pages might start depending on it *not* happening)

[22:38:00.0000] <annevk>
I emailed the list with an update on UI/API and nesting

[22:39:00.0000] <annevk>
hopefully it is somewhat coherent and hopefully it helps moving this discussion forward

[23:39:00.0000] <TabAtkins_>
annevk5: Good email.

[00:24:00.0000] <annevk>
hg diff -c REV --reverse is kind of cool

[00:24:01.0000] <annevk>
need to remember that one

[00:34:00.0000] <annevk>
where did https://developer.mozilla.org/presentations/xtech2005/e4x/ go?

[00:34:01.0000] <annevk>
broken links on mozilla.org, when did that start happening?

[00:34:02.0000] <erlehmann>
dead links are the cancer that is killing the web.

[00:35:00.0000] <erlehmann>
i recently made a script to check for them in link lists. and found sites not answering to HEAD.

[00:35:01.0000] <annevk>
lets not get overly dramatic

[00:35:02.0000] <erlehmann>
that site is not even properly 410

[00:35:03.0000] <annevk>
dude that's impossible, HTTP has no problems

[00:35:04.0000] <erlehmann>
but sadly, as mpilgrim has killed off his stuff, no one will read his article on 410.

[00:42:00.0000] <annevk>
oh man

[00:43:00.0000] <annevk>
that made me look up http://intertwingly.net/blog/2004/06/13/Gone-Really-I-mean-it and read about Dave Winer tried to reinvent HTTP in some XML and several others did too, and aah

[00:48:00.0000] <erlehmann>
my simple trick on HTTP 410 is to have it delivered on files with zero length

[00:49:00.0000] <erlehmann>
so when a file goes poof, i just nul it.

[01:11:00.0000] <annevk>
Hixie, I emailed public-script-coord to see if there's interest in reviving E4X as H4E (does not mean "Husband for ever")

[01:12:00.0000] <Hixie>
yeah we should just trim down E4X to just the literal stuff, and make it a short hand for DOM nodes

[01:12:01.0000] <Hixie>
drop all the query stuff

[01:12:02.0000] <annevk>
Hixie, if there's no interest I guess we're back to H4J (HTML for JSON)

[01:12:03.0000] <Hixie>
and drop comment support

[01:12:04.0000] <Hixie>
/me shudders at the idea of H4J

[01:13:00.0000] <annevk>
I suggested something to that effect, yes

[01:13:01.0000] <annevk>
drop cdata, comment, pi, drop namespaces, drop xpath

[01:13:02.0000] <annevk>
simplify the API, was my suggestion more or less

[01:13:03.0000] <Hixie>
yeah

[01:13:04.0000] <Hixie>
cool

[01:14:00.0000] <Hixie>
btw iirc mozilla only does e4x in certain modes

[01:14:01.0000] <Hixie>
so there's not really a compat risk

[01:15:00.0000] <annevk>
Brendan did make it work outside the es4=true flag

[01:15:01.0000] <Hixie>
oh ok

[02:36:00.0000] <smaug____>
ok, if Websocket protocol forces the API to be as bizarre as it is, we should not use the protocol

[02:39:00.0000] <zcorpan>
smaug____: ?

[02:40:00.0000] <smaug____>
"If reason is longer than 123 bytes, then throw a SyntaxError exception and abort these steps."

[02:41:00.0000] <smaug____>
There is also "is not an integer equal to 1000 or in the range 3000 to 4999, throw an InvalidAccessError exception", but I'm not sure where that insanity comes from

[02:42:00.0000] <annevk>
maybe you should read the protocol

[02:44:00.0000] <zcorpan>
smaug____: they wanted close frames (and controls frames in general) to be short. seems reasonable?

[02:45:00.0000] <annevk>
I wonder if http://wiki.ecmascript.org/doku.php?id=harmony:quasis will get the same lovely definition as new Date(...) i.e. undefined

[02:45:01.0000] <smaug____>
annevk: yes, I should read the latest version of the protocol

[02:45:02.0000] <smaug____>
zcorpan: no, as far as I see, there is no readon to limit the reason

[02:45:03.0000] <annevk>
Or ECMAScript would need some kind of normative dependency on CSS, HTML, etc. to define how strings are contextually escaped

[02:45:04.0000] <smaug____>
limit it more than limiting normal message length

[02:47:00.0000] <annevk>
seems like the reason is API-defined

[02:50:00.0000] <zcorpan>
smaug____: send feedback to hybi

[02:51:00.0000] <zcorpan>
i guess it could be useful to dump a stack trace or something in the reason

[02:55:00.0000] <jgraham>
annevk: It isn't clear to me from that page whether the intention is to have any built-in handlers at all

[02:55:01.0000] <jgraham>
I didn't read it all though

[03:01:00.0000] <annevk>
jgraham, the use cases and examples seem to imply so

[03:01:01.0000] <annevk>
not sure what you mean with handlers

[03:02:00.0000] <jgraham>
The function at the start is called a handler, isn't it?

[03:06:00.0000] <annevk>
oh

[06:09:00.0000] <annevk>
iPhone 4S (32GiB) in the US: 550 EUR thereabouts, in NL via T-Mobile: 750 EUR

[06:10:00.0000] <annevk>
I guess the US one does not include tax, but still

[06:24:00.0000] <Lachy>
annevk, is VAT 25% in NL?

[06:27:00.0000] <Timz>
19%

[06:27:01.0000] <Lachy>
550 * 1.19 = 654.5. Still 100 EUR difference.

[06:28:00.0000] <Timz>
yes and also a dollar !== euro so more..

[06:28:01.0000] <annevk>
I already took that into account

[06:28:02.0000] <Timz>
ok

[06:32:00.0000] <Lachy>
woah, the EUR prices are even more than the AUD prices.  64GB model is 849 EUR in France, $999 AUD in Aus (~= 745.75 EUR)

[06:33:00.0000] <micheil>
Lachy: the US is probably not allowing you to buy out right

[06:34:00.0000] <micheil>
the 999$AU is for buying it completely unlocked from an apple store with no sim attached

[06:34:01.0000] <micheil>
(that's how I bought mine)

[06:34:02.0000] <Lachy>
micheil, yeah, I know. So is the France price

[06:36:00.0000] <annevk>
micheil, actually you can buy an unlocked iPhone in the US

[06:36:01.0000] <Lachy>
micheil, http://store.apple.com/us/browse/home/shop_iphone/family/iphone/iphone4s

[06:36:02.0000] <micheil>
annevk: last I recall it was pretty damn hard to

[06:36:03.0000] <Lachy>
select a phone, then click "Or get iPhone unlocked and contract-free. Coming in November."

[06:36:04.0000] <Lachy>
the prices are tehre

[06:36:05.0000] <Lachy>
*there

[06:36:06.0000] <annevk>
I believe there is some delay, but come November the iPhone 4S should be available

[06:37:00.0000] <micheil>
hmm.. anyone happen to know where to go for developer support with firefox?

[06:37:01.0000] <Lachy>
"The unlocked iPhone will not work with CDMA carriers such as Verizon Wireless or Sprint." :-(

[06:39:00.0000] <annevk>
why does that matter Lachy?

[06:44:00.0000] <Lachy>
annevk, it means that people who want to buy an unlocked phone are still effectively locked to using GSM networks in the US, and that they can't switch between Verizon and Sprint easily in the future if they get a locked phone.

[06:46:00.0000] <Lachy>
that's not really a problem in countries where CDMA isn't used any more though, so at least it won't affect me.

[06:50:00.0000] <annevk>
just means CDMA is crappy

[09:39:00.0000] <zcorpan>
annevk5: so jgraham and i wondered earlier why the dom has no way to dispatch an event async

[09:39:01.0000] <zcorpan>
annevk5: currently if you want that you have to abuse postMessage or xhr or something

[09:46:00.0000] <zewt>
setTimeout(0) seems like the general way of doing anything "async" in JS

[10:02:00.0000] <dglazkov>
good morning, Whatwg!

[10:19:00.0000] <jarek>
Hi

[10:19:01.0000] <jarek>
CSS3 selectors specification defines {simple_selector_sequence} as follows:

[10:19:02.0000] <jarek>
[ type_selector | universal ]

[10:19:03.0000] <jarek>
[ HASH | class | attrib | pseudo | negation ]*

[10:19:04.0000] <jarek>
| [ HASH | class | attrib | pseudo | negation ]+

[10:20:00.0000] <jarek>
why there is no '*' or '+' or '?' sign after [ type_selector | universal ] ?

[10:20:01.0000] <jarek>
does it mean that there should be exactly one {type_selector} or {universal} at the start of  {simple_selector_sequence}?

[10:21:00.0000] <jarek>
this would mean that something like '#header' is not a simple selector

[10:28:00.0000] <jarek>
no, wait... it makes sense...

[10:28:01.0000] <Philip`>
jarek: "#header" matches HASH so it matches "[HASH | ...]+" so it matches "... | [HASH | ...]+", I think

[10:34:00.0000] <jarek>
s/one of both/one from the two

[10:38:00.0000] <jarek>
"A sequence of simple selectors is a chain of simple selectors that are not separated by a combinator. It always begins with a type selector or a universal selector. No other type selector or universal selector is allowed in the sequence."

[10:39:00.0000] <jarek>
now I'm confused, selectors starting with '.blah' or '#blah' are not a sequence of simple selectors?

[10:42:00.0000] <jarek>
"If a universal selector represented by * (i.e. without a namespace prefix) is not the only component of a sequence of simple selectors selectors or is immediately followed by a pseudo-element, then the * may be omitted and the universal selector's presence implied."

[10:42:01.0000] <Philip`>
jarek: [ A | B ] means either A, or B

[10:43:00.0000] <Philip`>
(not both, and not neither)

[10:43:01.0000] <jarek>
so the grammar definition is wrong? It assumes that universal selector or type selector are always there

[10:43:02.0000] <jarek>
it doesn't take into account the fact that universal selector's presence might be implied

[10:44:00.0000] <Philip`>
I think the grouping is equivalent to "[ [type_selector|universal] [stuff]* ] | [stuff]+", not like "[type_selector|universal] [ [stuff]* | [stuff]+ ]"

[10:44:01.0000] <Philip`>
so if you don't have type_selector or universal, you need at least one of the stuff

[10:45:00.0000] <Philip`>
(i.e. you can't just have the empty string)

[10:51:00.0000] <zewt>
Philip`: (clearer to say "means A xor B")

[14:21:00.0000] <rniwa>
Hixie: yt?

[14:25:00.0000] <Hixie>
rniwa: about to go to lunch

[14:25:01.0000] <rniwa>
Hixie: k.

[14:25:02.0000] <rniwa>
Hixie: will ping you back later then :)

[14:25:03.0000] <Hixie>
k

[15:52:00.0000] <Hixie>
annevk5: is a concept-event different than an Event? they seem to be treated as equivalent in DOM Core

[16:05:00.0000] <Hixie>
anyone know if i'm just mistesting this again or whether it's possible for opera to return non-null for input.selectedOption?

[16:09:00.0000] <Hixie>
ok i'll just drop it


2011-10-20
[17:32:00.0000] <Hixie>
what's an example of a url that can't be parsed even given the parsing rules in html?

[17:33:00.0000] <Hixie>
"::"?

[17:34:00.0000] <Hixie>
no, browsers parse that...

[17:58:00.0000] <zewt>
going in circles with joao and not sure why

[18:28:00.0000] <jarek>
Hi

[18:28:01.0000] <annevk>
Hixie, yeah, concept-event is the preferred way of talking about Event or something that inherits from it

[18:28:02.0000] <jarek>
in CSS2.1 spec, why A is defined like this:

[18:28:03.0000] <jarek>
A  a|\\0{0,4}(41|61)(\r\n|[ \t\r\n\f])?

[18:28:04.0000] <jarek>
while Z is defined like this:

[18:28:05.0000] <jarek>
Z  z|\\0{0,4}(5a|7a)(\r\n|[ \t\r\n\f])?|\\z

[18:29:00.0000] <jarek>
the difference is the last part, why '\\z' should be treated as Z but '\\a' might not be treated as A?

[18:32:00.0000] <jarek>
124\\cm is a valid LENGTH token, while 124c\\m is not?

[18:32:01.0000] <Hixie>
annevk: ah, because of the inheritance, ok

[18:32:02.0000] <Hixie>
annevk: it would be helpful imho if the dom core spec said that somewhere

[18:32:03.0000] <Hixie>
annevk: i thought they were different (the way "text track" and "TextTrack" are different)

[18:35:00.0000] <annevk>
oh, "text track" being the concept and "TextTrack" exposing it?

[18:35:01.0000] <annevk>
I guess it's pretty similar, but I'll make a clarification

[18:42:00.0000] <Hixie>
gah

[18:43:00.0000] <Hixie>
the semantic web guys have a way of thinking that is so utterly foreign to me it's mind blowing

[18:54:00.0000] <MikeSmith>
Hixie: something in particular you reading at the moment?

[18:54:01.0000] <MikeSmith>
bug report?

[18:55:00.0000] <annevk>
I guess for http://html5.org/r/6707 the pedant way would currently be /event listeners/ whose /capture/ variable is false

[18:56:00.0000] <annevk>
we should probably make it a "capture flag" given that it's a boolean, but that would actually make defining it more verbose

[18:56:01.0000] <annevk>
Hixie, fwiw, "DOM Range" is gone and part of DOM4 now

[18:58:00.0000] <jarek>
I have done some testing and it turns out that chars from 'a' to 'f' might not be escaped with '\' in CSS

[18:58:01.0000] <jarek>
why is it so?

[18:59:00.0000] <annevk>
because \ is also used for Unicode character escapes

[19:02:00.0000] <jarek>
is it allowed to have Unicode character escapes *anywhere* in the stylesheets?

[19:02:01.0000] <annevk>
pretty much

[19:02:02.0000] <jarek>
I thought those were allowed only inside strings

[19:03:00.0000] <annevk>
no CSS is crazy

[19:03:01.0000] <annevk>
they did not go with simplest syntax possible

[19:03:02.0000] <jarek>
that's going to complicate tokenizer implementation :/

[19:03:03.0000] <annevk>
oh yes

[19:03:04.0000] <annevk>
that's why at-rules are defined as @{N}{A}{M} etc.

[19:04:00.0000] <annevk>
each of those characters can be escaped

[19:04:01.0000] <annevk>
why?

[19:04:02.0000] <annevk>
because crazy

[19:04:03.0000] <jarek>
I think I have an idea

[19:04:04.0000] <jarek>
I will run the stylesheet through a processor that converts all escapes into regular signs before tokenization

[19:05:00.0000] <jarek>
it's also lame that comments are allowed everywhere, even between '!' and 'important'

[19:05:01.0000] <jarek>
what was the point of that?

[19:06:00.0000] <jarek>
is something like '! /* this is important flag*/ !important' really needed?

[19:16:00.0000] <annevk>
even -/**/2em

[19:16:01.0000] <annevk>
there is no point

[19:16:02.0000] <annevk>
it's just how that tokenizer language works to some extent I believe

[19:17:00.0000] <annevk>
I think we can still get away with making it much much simpler, but nobody is really interested in it I guess

[19:54:00.0000] <Hixie>
MikeSmith: the task force

[19:54:01.0000] <MikeSmith>
ah

[19:54:02.0000] <Hixie>
MikeSmith: jeni dragged me into some thread about multiple types

[19:55:00.0000] <Hixie>
MikeSmith: so i asked what the use case was

[19:55:01.0000] <Hixie>
MikeSmith: and basically the answer was "hope"

[19:55:02.0000] <MikeSmith>
I see

[19:55:03.0000] <MikeSmith>
I think somebody filed a spec bug about that yesterday

[19:55:04.0000] <Hixie>
"we're publishing data because we hope one day it'll be used, and we need multiple types because we're trying to use as many types as possible"

[19:55:05.0000] <annevk>
Hixie, you want a bug on removing DOMRANGE?

[19:55:06.0000] <Hixie>
annevk: send mail

[19:55:07.0000] <Hixie>
annevk: trying to get bugs to zero so i can get back to mail, i'm way behind on mail :-)

[19:56:00.0000] <Hixie>
course this means that right now if you file a bug it'll get done faster :-)

[19:58:00.0000] <annevk>
it's not like removing an obsolete reference is high priority :)

[19:58:01.0000] <Hixie>
:-)

[20:16:00.0000] <annevk>
god

[20:16:01.0000] <annevk>
sometimes I wonder why I even bother trying to get people their API design correct

[20:16:02.0000] <zewt>
fighting the fight

[20:16:03.0000] <annevk>
and at the same time take a lot of flack for not having constructors in the DOM

[20:18:00.0000] <annevk>
there's this urge in people that says "you know, I know better than all these other guys, lets do the API this way" and many web developer kittens die

[20:18:01.0000] <zewt>
heh, i prefer python's design--there are no constructors and everything's just a factory

[20:18:02.0000] <annevk>
but this person does not think about the kittens

[20:18:03.0000] <annevk>
only about his own sense of style

[20:18:04.0000] <annevk>
this was not about the constructors btw, I think we should have more of them

[20:19:00.0000] <annevk>
this was about having constants for strings, which are intrinsically meaningful

[20:19:01.0000] <annevk>
oh, I know how to solve this, remove string constants from IDL

[21:59:00.0000] <TabAtkins_>
Does anyone know off the top of their head what spec box-sizing appears in?

[22:01:00.0000] <jarek>
TabAtkins: http://www.w3.org/TR/css3-ui/#box-sizing0

[22:01:01.0000] <jarek>
TabAtkins: I use this site for finding where the properties come from: http://meiert.com/en/indices/css-properties/

[23:05:00.0000] <annevk>
I wonder if the people talking about querySelector realize that you cannot simply substring on ":scope"

[23:06:00.0000] <annevk>
Still seems like a bad idea to me to design it in a way that does not look at the entire tree

[23:15:00.0000] <annevk>
If A inherits from B, B is a ??? of A

[23:15:01.0000] <annevk>
(with respect to interfaces)

[23:18:00.0000] <annevk>
oh well, went with verbosity instead

[23:21:00.0000] <Hixie>
B is a superclass

[23:21:01.0000] <Hixie>
or I guess superinterface, if A and B are interfaces?

[23:34:00.0000] <annevk>
"I can't believe the politics involved in the OWL for JSON mailing list." didn't know there was such a thing

[23:34:01.0000] <annevk>
guess I don't want to know more

[23:58:00.0000] <annevk>
Hixie, btw, given the arguments in the Web Intents thread, Microdata really should use simple string identifiers as well...

[23:59:00.0000] <annevk>
too late now I guess

[23:59:01.0000] <Hixie>
simple string identifiers for what?

[23:59:02.0000] <annevk>
instead of "http://schema.org/Blog" we should just have "blog"

[00:00:00.0000] <annevk>
and if Example wants his own blog, they could have "example-blog" or some such

[00:01:00.0000] <annevk>
because in the end, only a few vocabularies will be supported

[00:01:01.0000] <Hixie>
well we can still do that i guess

[00:01:02.0000] <Hixie>
since while the syntax says they're urls, they aren't resolved and they are treated as opaque

[00:01:03.0000] <Hixie>
the API currently drops non-URL values

[00:02:00.0000] <Hixie>
still, i don't think it's a big deal

[00:02:01.0000] <Hixie>
the microdata feature is explicitly intended to be used for lots of vocabs

[00:03:00.0000] <annevk>
I guess, but simple strings scale too, or simple strings with a prefix

[00:04:00.0000] <annevk>
but then I have a hard time seeing a lot of people taking the effort to use all this additional markup so I don't really feel that strongly about making it simple

[00:05:00.0000] <Hixie>
yeah, we could have gone with the rel="" approach as well

[00:05:01.0000] <Hixie>
/me shrugs

[00:05:02.0000] <Hixie>
best to let it be

[00:06:00.0000] <annevk>
i guess if in like 5 years only schema.org is adopted we can just alias what they have and make it simple for the masses

[00:06:01.0000] <annevk>
experiment a bit more first

[01:24:00.0000] <annevk>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14516 I wish the IETF held to the same values

[01:38:00.0000] <annevk>
Well, per my non-scientific twitter survey, it seems web developers would like markup literals

[01:38:01.0000] <annevk>
The only negative responses thus far were from Arve (says it might break text editors) and glazou (no reason given)

[01:43:00.0000] <krijn>
E4X!

[01:47:00.0000] <frank_salim>
annevk: is that something people are asking for?

[01:50:00.0000] <jacobolus>
annevk: the thing I don't like is that people will try to copy/paste stuff around, and there are all kinds of edge cases that will break

[01:51:00.0000] <jacobolus>
and the result will be confusion

[01:51:01.0000] <jacobolus>
things that are conceptually strings should have some delimiters :)

[01:53:00.0000] <annevk>
they are not conceptually strings

[01:54:00.0000] <jgraham>
annevk: It's not really clear to me that using strings instead of constants is better btw. Apart from the feature detection issue, constants work better with IDEs for autocompletion

[01:55:00.0000] <annevk>
jgraham, so you would prefer people type responseType = XMLHttpRequest.RESPONSE_JSON rather than responseType = "json"

[01:55:01.0000] <jgraham>
annevk: People who use IDEs might prefer the latter certainly

[01:55:02.0000] <annevk>
I find the IDE argument not really compelling

[01:55:03.0000] <jgraham>
er former

[01:56:00.0000] <jgraham>
Any particular reason?

[01:56:01.0000] <zcorpan>
we *could* have both (making the constant return a string)

[01:56:02.0000] <annevk>
it makes the code a whole lot harder to read; the only benefit seems to be that it makes it easier to integrate it with existing tools

[01:56:03.0000] <annevk>
zcorpan, it would return a string

[01:57:00.0000] <jgraham>
I don't think it is harder to read

[01:57:01.0000] <annevk>
o_O

[01:57:02.0000] <jgraham>
It is a bit ugly

[01:57:03.0000] <jgraham>
But totally comprehensible

[01:57:04.0000] <annevk>
it's extremely ugly and verbose

[01:57:05.0000] <zcorpan>
you could write x.responseType = x.RESPONSE_JSON also

[01:58:00.0000] <jgraham>
In the average js library this is a molecule in a drop in the ocean in terms of the difficulty of understanding what the code does

[01:58:01.0000] <annevk>
zcorpan, doesn't really make a difference

[01:58:02.0000] <annevk>
jgraham, if it's in a library there's even less need for constants

[01:58:03.0000] <zcorpan>
annevk: makes it a bit shorter and less ugly

[01:58:04.0000] <annevk>
jgraham, because you'd just do requestJson(url) or some such

[01:59:00.0000] <jgraham>
annevk: By "library" I just meant "body of code"

[02:00:00.0000] <annevk>
jgraham, it seems people developing large libraries care a lot about brevity still

[02:00:01.0000] <annevk>
jgraham, ask e.g. Alex Russell

[02:00:02.0000] <jgraham>
(it is also quite nice to have clear rules about case; everyone knows that constants are always uppercase whereas JSON could be spelt  "json" or "JSON" and so could "2d" vs "3D")

[02:00:03.0000] <annevk>
anyway if you feel like making a case for constants go ahead :)

[02:01:00.0000] <jgraham>
annevk: Alex Russel seems to be about 50% troll so I have difficulty taking him seriously

[02:01:01.0000] <jgraham>
*russell

[02:02:00.0000] <annevk>
I always have the feeling you are about 50% or more against every idea mentioned; still try to take you seriously though :)

[02:02:01.0000] <jgraham>
Heh

[02:02:02.0000] <jgraham>
I'm not sure that's true

[02:03:00.0000] <jgraham>
Although about 50% of the things that I thought were really good ideas turned out to not be :)

[02:22:00.0000] <annevk>
Hixie, is there some construct for tasks to have conditions?

[02:23:00.0000] <annevk>
Hixie, like do this task unless something got cancelled along the way?

[02:26:00.0000] <annevk>
It's funny though how people suddenly jump up to support string constants while there was never a single suggestion for them for either the <canvas> API or XMLHttpRequest

[02:27:00.0000] <annevk>
This is the reason asking forgiveness is so much better

[02:27:01.0000] <jgraham>
I find the canvas thing moderately annoying

[02:27:02.0000] <jgraham>
and don't follow XHR much

[02:27:03.0000] <jgraham>
So my experience suggests that no-constants doesn't work that well

[02:28:00.0000] <annevk>
You use an IDE?

[02:28:01.0000] <jgraham>
Nope

[02:28:02.0000] <jgraham>
But it really took me a while to remember whether it should be "2d" or "2D"

[02:29:00.0000] <annevk>
Oh that string

[02:29:01.0000] <annevk>
enums of that kind should simply always be lowercase

[02:29:02.0000] <annevk>
simple enough

[02:31:00.0000] <jgraham>
Yes, but different from either other named constants or the normal english usage of "2D"

[02:31:01.0000] <annevk>
Is there a browser where HTML is still fast?

[02:31:02.0000] <annevk>
yeah man, hard times

[02:32:00.0000] <annevk>
Chrome is superslow these days

[02:33:00.0000] <annevk>
I guess I can queue a task that says to check "unless cancelled do x

[02:33:01.0000] <annevk>
"

[02:33:02.0000] <annevk>
hmm that would still be quite hairy

[02:34:00.0000] <TabAtkins_>
Anyone got an IE that they can visit http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1214 in?

[02:34:01.0000] <TabAtkins_>
Any IE will do.

[02:35:00.0000] <krijn>
TabAtkins_: what do you want to know?

[02:35:01.0000] <TabAtkins_>
Are the two marquees the same height?  And does the text overflow?

[02:35:02.0000] <krijn>
Yes, no

[02:35:03.0000] <krijn>
(IE8)

[02:35:04.0000] <TabAtkins_>
Neither overflows?  Interesting.

[02:35:05.0000] <TabAtkins_>
So both are tall enough to fully contain their text.  Huh.

[02:35:06.0000] <krijn>
No

[02:36:00.0000] <krijn>
They clip the text

[02:36:01.0000] <TabAtkins_>
Oh, that's what I meant.  ^_^  clipping is an overflow strategy.

[02:37:00.0000] <krijn>
https://skitch.com/krijnhoetmer/gnfy3/ie8-marquee-stuffs

[02:39:00.0000] <espadrine>
annevk: About the responseType = XMLHttpRequest.RESPONSE_JSON rather than responseType = "json" argument, wouldn't having Ruby's symbols in JS solve the issue?

[02:40:00.0000] <annevk>
dunno what Ruby's symbols are

[02:40:01.0000] <espadrine>
mostly, they behave just like strings

[02:40:02.0000] <jgraham>
Something like responseType = :json

[02:40:03.0000] <jgraham>
I think

[02:41:00.0000] <espadrine>
but they are in some sort of global hashtable

[02:41:01.0000] <espadrine>
so that we only compare constant integers most of the times

[02:41:02.0000] <annevk>
I personally don't really see why an IDE can't provide support for strings

[02:42:00.0000] <annevk>
espadrine, sounds neat if JavaScript had that already :)

[02:42:01.0000] <espadrine>
that can be fixed… well, within 3 years at least

[02:43:00.0000] <jgraham>
annevk: it seems like a much harder problem to track that x is a XHR object so that you know that x.responseType should be a string corresponding to an XHR response type than to just know that the global XMLHttpRequest object has some constants

[02:45:00.0000] <annevk>
/me shrugs

[02:49:00.0000] <zcorpan>
annevk: the thing that cancels should just say to remove the task from the queue, i think

[02:50:00.0000] <annevk>
so this is for fullscreen

[02:51:00.0000] <annevk>
you queue a task for each document (cannot do one task because they can be cross-origin)

[02:51:01.0000] <annevk>
then you do some asynchronous animation which can be aborted

[02:51:02.0000] <annevk>
at that point one of those tasks might have already done something

[02:52:00.0000] <zcorpan>
so half of the documents will have run the task and the other half haven't ?

[02:52:01.0000] <annevk>
that could happen in theory I think

[02:52:02.0000] <TabAtkins_>
Thanks, krijn .

[02:53:00.0000] <annevk>
i guess when that happens you notify those documents that things have been changed again

[02:53:01.0000] <zcorpan>
why can't you just let the rest of the documents run the task too then?

[02:53:02.0000] <annevk>
so you need to keep track of where events have dispatched

[02:53:03.0000] <annevk>
zcorpan, yeah, and then dispatch another set of events to notify it has changed again?

[02:53:04.0000] <annevk>
that might be easiest

[02:53:05.0000] <zcorpan>
yeah

[03:06:00.0000] <MikeSmith>
can somebody please visit http://w3c-test.org/framework/test/DUMMY/single/attributes.html/

[03:06:01.0000] <MikeSmith>
and just press the Fail button at the bottom

[03:07:00.0000] <MikeSmith>
test framework is not properly collecting results when I visit it

[03:08:00.0000] <MikeSmith>
*not properly recording

[03:08:01.0000] <MikeSmith>
hmm, or more like "not properly reporting"

[03:08:02.0000] <MikeSmith>
I can see results getting entered into the DB

[03:08:03.0000] <MikeSmith>
but not getting reported back

[03:12:00.0000] <zcorpan>
done

[03:12:01.0000] <zcorpan>
is that for manual tests?

[03:13:00.0000] <zcorpan>
can there be a button for "this test can be automated, tell the test author to automate it" ?

[03:14:00.0000] <zcorpan>
maybe w3c-test doesn't keep track of test authors

[03:16:00.0000] <MikeSmith>
there is a way you can automatically run it and submit the results

[03:16:01.0000] <MikeSmith>
http://w3c-test.org/framework/suite/DUMMY/

[03:17:00.0000] <MikeSmith>
if you go there and select the "Submit test results automatically when possible" option

[03:19:00.0000] <zcorpan>
seems Hixie is in denial about the name DOM4

[03:20:00.0000] <jgraham>
Should of called it DOM4Web Then everyone could have hated on it

[03:22:00.0000] <annevk>
once we sort out living standards I'll just name it "DOM Standard" like HTML is "HTML Standard"

[03:23:00.0000] <MikeSmith>
sigh

[03:23:01.0000] <MikeSmith>
I figured out my problem

[03:23:02.0000] <annevk>
there's a yay in there too

[03:24:00.0000] <MikeSmith>
the framework is currently hard-coded to expect every test case to have a spec fragment ID associated with it

[03:28:00.0000] <annevk>
I updated the Fullscreen specification somewhat

[03:28:01.0000] <annevk>
I have not yet addressed the problem mentioned above adequately, but I did simplify it a whole lot

[03:29:00.0000] <annevk>
And addressed the problem of not dispatching fullscreenchange on each document

[03:29:01.0000] <annevk>
I removed Document.fullscreen as currently it's no different from Document.fullscreenElement

[03:30:00.0000] <annevk>
I guess I will email the list later as I have to go

[03:30:01.0000] <annevk>
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html

[03:57:00.0000] <decthomas>
hi TabAtkins

[03:57:01.0000] <decthomas>
just posted this tweet http://twitter.com/#!/decthomas/status/126958851072327680

[03:57:02.0000] <decthomas>
can you help me out ? :)

[04:04:00.0000] <decthomas>
or anyone else for that matter :)

[04:27:00.0000] <zcorpan>
experience suggests that people will copy examples verbatim even if the example says to change placeholder values - http://www.w3.org/Bugs/Public/show_bug.cgi?id=14117

[04:28:00.0000] <annevk>
Ms2ger, do you have better terminology?

[04:28:01.0000] <annevk>
Ms2ger, I did not get further than "event listener whose capture variable is false" which is what we already have

[04:45:00.0000] <zcorpan>
enumSupportedValues(XMLHttpRequest, 'responseType')

[04:46:00.0000] <annevk>
over engineering?

[04:47:00.0000] <zcorpan>
likely :)

[07:16:00.0000] <MikeSmith>
this is crashing my Opera 11.52:

[07:16:01.0000] <MikeSmith>
http://w3c-test.org/framework/test/DUMMY/auto/Range-cloneContents.html/

[07:17:00.0000] <miketaylr>
me too, boooooo

[07:18:00.0000] <wilhelm>
Boom. Indeed.

[07:32:00.0000] <smaug____>
using range is an easy way to crash any engine

[07:33:00.0000] <smaug____>
unfortunately

[07:33:01.0000] <smaug____>
s/crash/crash or hang/

[08:06:00.0000] <krijn>
Wil je er zelf een?

[08:06:01.0000] <krijn>
Whoops

[08:08:00.0000] <Drogos>
Hi, I have two ideas / suggestions for changes to the html standard, where should I post them?

[08:08:01.0000] <zcorpan>
whatwg⊙wo

[08:08:02.0000] <annevk>
(need to subscribe first)

[08:10:00.0000] <Drogos>
No forum or such where my inbox does not get affected?

[08:11:00.0000] <annevk>
there's forums.whatwg.org

[08:11:01.0000] <Drogos>
ah, good, thanks :)

[08:14:00.0000] <annevk>
AryehGregor, could you please revert http://dvcs.w3.org/hg/webapps/rev/8879ca39afaa

[08:14:01.0000] <annevk>
AryehGregor, tests are not supposed to be run on dvcs, they are checked out on w3c-test.org

[08:30:00.0000] <zcorpan>
Drogos: however, spec feedback on the forums usually doesn't get to the spec editor's attention. i'd suggest you file a bug instead if you don't want to subscribe

[08:31:00.0000] <zcorpan>
"(I killed the useless testharnessreport.js references at the same time, instead

[08:31:01.0000] <zcorpan>
 of updating them. As far as I can tell, we aren't supposed to use it anymore.)"

[08:31:02.0000] <zcorpan>
we aren't?

[08:31:03.0000] <zcorpan>
jgraham: ^

[08:36:00.0000] <jgraham>
What?

[08:36:01.0000] <jgraham>
Where is that from?

[08:37:00.0000] <Drogos>
aha, thanks zcorpan :)

[08:40:00.0000] <zcorpan>
 http://dvcs.w3.org/hg/webapps/rev/8879ca39afaa

[08:41:00.0000] <jgraham>
AryehGregor: We are still supposed to use testharnessreport.js

[08:41:01.0000] <jgraham>
AryehGregor: That patch is exactly wrong

[08:42:00.0000] <jgraham>
using /resources/testharness.js is right and using an absolute url is wrong

[08:42:01.0000] <jgraham>
The tests work on w3c-test.org

[08:52:00.0000] <annevk>
just before I asked for a revert

[08:52:01.0000] <annevk>
changes like that really ought to be discussed first

[08:53:00.0000] <jgraham>
Where did you ask?

[08:54:00.0000] <annevk>
here on IRC

[08:55:00.0000] <jgraham>
I see

[08:55:01.0000] <jgraham>
I thought maybe there was a mailing list I wasn't on

[08:56:00.0000] <annevk>
well I'm sure that's true too :)

[09:03:00.0000] <MikeSmith>
easy enough to roll that change back

[09:03:01.0000] <MikeSmith>
I can understand why Aryeh made that change

[09:03:02.0000] <MikeSmith>
I probably would have done the same if I were him and trying to get stuff to work

[09:04:00.0000] <zewt>
it'd be nice if the spec comment box didn't overlap the spec; it's annoying that whenever you search for text in firefox, the text it finds ends up hidden underneith the comment overlay

[09:04:01.0000] <MikeSmith>
from the way things are set up, it's not very clear that the tests are intended to be executed from a different host

[09:04:02.0000] <zewt>
also underneath (why do I always do that?)

[09:09:00.0000] <MikeSmith>
I like "underneith" better

[09:10:00.0000] <MikeSmith>
it looks more similar to "Kool Keith"

[09:10:01.0000] <MikeSmith>
and somehow seems slightly closer to "underthings" as well

[09:11:00.0000] <zewt>
can I use my native speaker card and declare it a correct alternative

[09:11:01.0000] <zewt>
google says 311000 vs. 108 million; i guess not :(

[09:14:00.0000] <jgraham>
MikeSmith: Yes, it is an understandable mistake to make

[09:33:00.0000] <dglazkov>
good morning, Whatwg!

[09:33:01.0000] <Drogos>
I was on the html5 code camp in Norway last year, is anyone of the people from that camp here?

[10:39:00.0000] <Hixie>
annevk5: just start the task with a check for the condition and if it's not true don't do anything

[10:40:00.0000] <Hixie>
zcorpan: not in denial about the name, i can just never work out what it is, it keeps changing!

[10:51:00.0000] <smaug____>
interesting. Chrome + Gnome 3 can go to state where you can't even close Chrome

[10:51:01.0000] <smaug____>
nor actually do anything with it

[11:16:00.0000] <Hixie>
ok julian has just crossed the threshold from wasting my time to actively harming the spec

[11:25:00.0000] <hober2>
Hixie: what did he do now?

[11:25:01.0000] <Hixie>
first he asked for me to move the definition of rel=sidebar to the wiki instead of in the spec

[11:26:00.0000] <Hixie>
so i did that

[11:26:01.0000] <Hixie>
now he's asking for the text that actually defines how sidebars work to be removed

[11:26:02.0000] <Hixie>
which would break the definition of rel=sidebar in the wiki

[11:26:03.0000] <hober>
is he suggesting that there be a separate sidebar spec?

[11:26:04.0000] <hober>
or simply that the feature be dropped?

[11:26:05.0000] <Hixie>
neither, he's just asking for the text to be removed

[11:27:00.0000] <Hixie>
a separate sidebar spec wouldn't really work since it would have to do invasive patches to the html spec

[11:27:01.0000] <hober>
indeed

[13:12:00.0000] <adtykfhyipoh>
Hello

[13:13:00.0000] <adtykfhyipoh>
Can I have some help here?

[13:14:00.0000] <adtykfhyipoh>
Hello?

[13:21:00.0000] <adtykfhyipoh>
MikeSmith do you know about Canavs? I need some help

[13:24:00.0000] <Philip`>
adtykfhyipoh: You should just ask your question, and then someone might answer it

[13:25:00.0000] <adtykfhyipoh>
I have been asking for hours but no one answered. Since then, I figured it out myself. Usually I wait for someone to join then ask them so they have the window open and they can see it

[13:26:00.0000] <adtykfhyipoh>
In fact Philip` I have done that to you in the past

[13:30:00.0000] <miketaylr>
so what is the actual question?

[13:34:00.0000] <adtykfhyipoh>
Well I was trying to figure out how to make a canvas object move along a line, but I figured it out.

[13:34:01.0000] <adtykfhyipoh>
Bye

[13:34:02.0000] <bga_>
heh

[13:34:03.0000] <miketaylr>
later

[13:34:04.0000] <miketaylr>
:)

[13:35:00.0000] <bga_>
miketaylr but is it real? Opera 12 support window.onerror?

[15:19:00.0000] <jgraham>
Hixie: I still don't see that a javascript IDE can really know that x.responseType should take the values from XMLHttpRequest.responseType without actually running the code

[15:22:00.0000] <Hixie>
how can it know it should take the value XMLHttpRequest.WHATEVER?

[15:23:00.0000] <bga_>
jgraham window.XMLHttpReqest = ... my wrapper

[15:24:00.0000] <zcorpan>
Hixie: so about onerror. what is unclear?

[15:24:01.0000] <Hixie>
zcorpan: all of the bugs were way too vague, i had no idea what you meant

[15:25:00.0000] <zcorpan>
ok

[15:25:01.0000] <Hixie>
zcorpan: e.g. "If the script is not same-origin, window.onerror should be invoked with arguments ("Script error.", "", 0)" -- which script? same-origin with what? what window? why fire it at all? etc

[15:25:02.0000] <Hixie>
when should it be fired?

[15:25:03.0000] <heycam>
jgraham, I expect the argument is that the author will type "XMLHttpRequest." and can then do completion

[15:26:00.0000] <heycam>
jgraham, but otherwise yes it would require some analysis to work out what function is really being called and what values it can be called with

[15:26:01.0000] <Hixie>
heycam: that's jgraham's argument. My argument is that the IDE should just guess that x.responseType is the XMLHttpRequest.responseType attribute (based on looking at what |x| is last initialized to, e.g.) and knowing that responseType takes certain strings.

[15:27:00.0000] <Hixie>
that = that the author will type "XMLHttpRequest." and can then do completion

[15:27:01.0000] <jgraham>
Hixie: It can't. But it can know that if you type XM then XMLHttpRequest is a valid completion and then if you type . it can list all the other completions

[15:27:02.0000] <Hixie>
jgraham: that's a pretty lame IDE

[15:27:03.0000] <jgraham>
Hixie: How can you do better

[15:27:04.0000] <jgraham>
?

[15:27:05.0000] <jgraham>
With javascript?

[15:27:06.0000] <zcorpan>
Hixie: so it's not actually the scirpt's origin, but the script's *URL's* origin, compared to the script's origin

[15:27:07.0000] <heycam>
Hixie, I think that is possible too. once you've done the analysis to know that you're using XHR's responseType, you can autocomplete for property names, strings, whatever

[15:27:08.0000] <bga_>
/me just use notepad++

[15:28:00.0000] <Hixie>
zcorpan: don't tell me here, put it in the bug :-)

[15:28:01.0000] <Hixie>
heycam: right

[15:28:02.0000] <zcorpan>
will do

[15:28:03.0000] <Hixie>
jgraham: you don't have to be perfect, you just have to be good enough to handle non-obtuse code

[15:28:04.0000] <Hixie>
zcorpan: awesome, thanks

[15:28:05.0000] <heycam>
maybe browsers will expose their type inference results at some point to make this easier

[15:28:06.0000] <heycam>
Hixie, yeah it wouldn't be the first IDE whose autocomplete you could trick

[15:29:00.0000] <Hixie>
indeed

[15:29:01.0000] <jgraham>
Seems like it is at least rather non trivial in any case where you don't declare the variable statically in the same function

[15:29:02.0000] <Hixie>
tricking an IDE autocomplete is like tricking a bicycle pump

[15:29:03.0000] <Hixie>
the only loser is yourself

[15:29:04.0000] <jgraham>
If I write function (x) {x.responseType =

[15:30:00.0000] <Hixie>
jgraham: you can guess pretty easily that "responseType" might be an XHR responseType, even without looking at the variable it's used on

[15:30:01.0000] <jgraham>
it seems highly unclear how it can know nything

[15:30:02.0000] <heycam>
I'm assuming that with the kind of IDE assistance being argued for on the list, you could start typing "x.responseType = Node.", press tab, and get a list of node types

[15:30:03.0000] <jgraham>
Well yeah it could do that. Sucks if there is more than one possibility though

[15:30:04.0000] <heycam>
so not completely helpful, you need to know the constant is on XMLHttpRequest

[15:31:00.0000] <jgraham>
heycam: Node.? where is that from?

[15:31:01.0000] <jgraham>
Oh I see

[15:31:02.0000] <heycam>
jgraham, you type it. this is when you're typing some code I assume

[15:31:03.0000] <jgraham>
Well yes, you need to know what type of object it is

[15:32:00.0000] <Hixie>
how do you know that Node is the Node we defined?

[15:32:01.0000] <Hixie>
anyone in JS can override Node

[15:32:02.0000] <jgraham>
and guess that the object's constants live on its interface object

[15:32:03.0000] <Hixie>
var Node = null;

[15:32:04.0000] <heycam>
it's a good question, it'd be another assumption unless you have wicked analysis

[15:32:05.0000] <jgraham>
Sure, but you can get it right in a lot more situations than with pure strings

[15:32:06.0000] <Hixie>
if you can just guess that Node is the Node interface we spec, then why not just guess that responseType is is the XHR responseType?

[15:33:00.0000] <jgraham>
Because one is likely to be right and the other is quite likely to be wrong?

[15:33:01.0000] <Hixie>
responseType being the one likely to be right and Node likely to be wrong?

[15:33:02.0000] <jgraham>
Who redefines Node in their code?

[15:33:03.0000] <jgraham>
I men people add to it

[15:33:04.0000] <Hixie>
who uses responseType in their code?

[15:34:00.0000] <Hixie>
it doesn't have to be perfect

[15:34:01.0000] <Hixie>
just has to be good enough

[15:34:02.0000] <jgraham>
Seems like a reasonable name to use when you have a response with a type

[15:34:03.0000] <Hixie>
the drop down can easily just say "XMLHttpRequest.responseType values: \n "this" \n "that" \n FooBar.responseType values: \n "this" \n "that""

[15:34:04.0000] <jgraham>
And I'm sure there are other examples where the DOM reuses an attribute name to mean different things on differnet interfaces

[15:35:00.0000] <Hixie>
i see no problem here

[15:35:01.0000] <jgraham>
Anyway I don't really know what IDEs actually do

[15:35:02.0000] <jgraham>
But I would guess they will get the named constants right and not help with the string constants

[15:36:00.0000] <franksalim>
has anyone mentioned that named constants are discoverable without documentation?

[15:36:01.0000] <franksalim>
by looking at the object?

[15:37:00.0000] <jgraham>
franksalim: Yes

[15:37:01.0000] <franksalim>
ok, good. that seems very compelling to me

[15:38:00.0000] <jgraham>
heycam: So, in other questions, why are attributes on prototypes not on instances?

[15:38:01.0000] <jgraham>
zcorpan points out that it can help feature detection

[15:38:02.0000] <jgraham>
But to me it seems like a very odd setup

[15:38:03.0000] <heycam>
jgraham, because it's common behaviour across all instances of a particular interface?

[15:39:00.0000] <heycam>
jgraham, seemed natural to me

[15:39:01.0000] <jgraham>
heycam: An attribute is a property of an instance

[15:39:02.0000] <heycam>
jgraham, sure, but I think that modelling really only works if you are using data properties

[15:40:00.0000] <heycam>
jgraham, I think it's fine for internal state to be modelled with an accessor property coming from a prototype

[15:40:01.0000] <zcorpan>
heycam: it's not defined what attributes on the prototype should return, or is it?

[15:40:02.0000] <heycam>
zcorpan, if you do Node.prototype.nodeType?

[15:40:03.0000] <heycam>
zcorpan, defined to throw

[15:40:04.0000] <jgraham>
Conceptually it feels wrong to say that the attribute is a property of the prototypical object rather than of the actual object

[15:41:00.0000] <zcorpan>
heycam: ah

[15:41:01.0000] <heycam>
jgraham, I can see where you're coming from

[15:41:02.0000] <heycam>
jgraham, especially if you think of Node.prototype as a prototypical Node

[15:41:03.0000] <heycam>
jgraham, though in practice of course it's not itself a Node

[15:43:00.0000] <jgraham>
Right.

[15:43:01.0000] <jgraham>
My argument is entirely that the model used does not match the most likely mental model of authors

[15:44:00.0000] <heycam>
probably true

[15:45:00.0000] <jgraham>
Who might expect some_node.hasOwnProperty("tagName") to be true

[15:45:01.0000] <heycam>
especially if unfamiliar with accessor properties

[15:45:02.0000] <jgraham>
s/node/element/

[15:45:03.0000] <heycam>
("tagName" in some_node is true tho)

[15:45:04.0000] <jgraham>
Yeah

[15:45:05.0000] <heycam>
an author might also expect some_node.hasOwnProperty("appendChild") to be true for the same reason

[15:45:06.0000] <heycam>
unless they have some experience with using prototypes to write "classes"

[15:46:00.0000] <heycam>
such an author probably isn't using hasOwnProperty though :)

[15:46:01.0000] <jgraham>
Right, but it is easier to understand that shared behaviour is a property of the "superclass"

[15:46:02.0000] <jgraham>
Well doesn't Crockford promote hasOwnProperty?

[15:46:03.0000] <jgraham>
At least for enumeration

[15:46:04.0000] <heycam>
don't know...

[15:47:00.0000] <jgraham>
for (foo in bar) {if bar.hasOwnProperty(foo) {/*do stuff*/}}

[15:47:01.0000] <jgraham>
So people might come across it that way

[15:48:00.0000] <heycam>
ok

[15:48:01.0000] <heycam>
well, I haven't really had any pushback on what's in the spec at the moment. but you're welcome to start a thread on the list about it!

[15:48:02.0000] <bga_>
if(!obj.hOP(k)) break is better

[15:49:00.0000] <jgraham>
bga_: doesn't that make assumptions about the order of enumeration?

[15:49:01.0000] <jgraham>
I assure you that they are not supported by the spec :)

[15:49:02.0000] <bga_>
* continue

[15:49:03.0000] <bga_>
sorry

[15:49:04.0000] <jgraham>
Ah, OK

[15:50:00.0000] <bga_>
but break works too

[15:50:01.0000] <jgraham>
heycam: I fear that list

[15:50:02.0000] <bga_>
for non IE

[15:50:03.0000] <jgraham>
:)

[15:50:04.0000] <heycam>
:)

[15:50:05.0000] <heycam>
i tend to reply in bursts to minimise exasperation :)

[15:51:00.0000] <jgraham>
Also, iven zcorpan's point, I'm not sure whether it is worth pushing for a change

[15:51:01.0000] <bga_>
jgraham i just have Object#_each like Array#forEach

[15:51:02.0000] <jgraham>
I *think* only gecko implements the current spec

[15:51:03.0000] <jgraham>
But that is from memory and might be outdated even if it was once true

[15:51:04.0000] <jgraham>
(my memory is quite terrible)

[15:52:00.0000] <heycam>
heh

[15:53:00.0000] <heycam>
pretty sure we do accessors for attributes tho

[15:54:00.0000] <zcorpan>
Hixie: clearer now?

[15:54:01.0000] <zcorpan>
webkit and opera don't match the spec

[15:54:02.0000] <zcorpan>
no idea about ie

[15:55:00.0000] <heycam>
zcorpan, oh I've been meaning to test, what about the new Opera.next release?

[15:55:01.0000] <heycam>
zcorpan, since they do ES5 now

[15:55:02.0000] <zcorpan>
same

[15:55:03.0000] <heycam>
s/they/you/ :)

[15:55:04.0000] <heycam>
ok

[15:56:00.0000] <zcorpan>
i don't object to changing the spec to match opera/webkit/ie (?), the only thing is that it makes it a bit harder for authors to do feature detection

[15:56:01.0000] <heycam>
zcorpan, how so?

[15:56:02.0000] <heycam>
beacuse you have to create an instance first?

[15:56:03.0000] <zcorpan>
yes

[15:56:04.0000] <heycam>
k

[15:57:00.0000] <zcorpan>
consider WebSocket

[15:57:01.0000] <zcorpan>
checking the prototype is a one-liner

[15:57:02.0000] <zcorpan>
var support = 'binaryType' in WebSocket.prototype;

[15:57:03.0000] <zcorpan>
creating an instance without side effects is harder

[15:58:00.0000] <zcorpan>
and not a one-liner :)

[15:58:01.0000] <bga_>
not so

[15:58:02.0000] <bga_>
just small wrapper

[15:59:00.0000] <Hixie>
zcorpan: yeah, much better. thanks.

[15:59:01.0000] <bga_>
which do real init if you perform real actions

[15:59:02.0000] <Hixie>
zcorpan: looks like the spec is pretty vague about the onerror arguments right now anyway, so i guess i'll use those bugs as an opportunity to clean it up

[16:00:00.0000] <zcorpan>
var support = (function() {

[16:00:01.0000] <zcorpan>
    var s = new WebSocket('ws://example.invalid/');

[16:00:02.0000] <zcorpan>
    return 'binaryType' in s;

[16:00:03.0000] <zcorpan>
})();

[16:00:04.0000] <zcorpan>
ok, not that hard

[16:00:05.0000] <heycam>
or 'binaryType' in new WebSocket...

[16:00:06.0000] <heycam>
but yes your point is generally true

[16:00:07.0000] <franksalim>
zcorpan: does that cause a DNS lookup for invalid?

[16:00:08.0000] <bga_>
except user will see error in console

[16:00:09.0000] <zcorpan>
franksalim: yes

[16:00:10.0000] <Hixie>
you really don't want to be creating a WebSocket just to do feature detection

[16:00:11.0000] <franksalim>
so it isn't completely side effect free...

[16:01:00.0000] <zcorpan>
right

[16:01:01.0000] <heycam>
/me gtg

[16:06:00.0000] <zcorpan>
Hixie: we decided to copy firefox for onerror. webkit always uses empty string as location for setTimeout scripts, otherwise i think they behaved pretty much the same

[16:09:00.0000] <Hixie>
makes sense

[16:10:00.0000] <zcorpan>
what part makes sense? copying firefox or using empty string for setTimeout? :)

[16:22:00.0000] <Hixie>
zcorpan: copying firefox

[16:33:00.0000] <zcorpan>
ok

[16:45:00.0000] <Hixie>
heycam|away: advice on the first bullet point of http://www.w3.org/Bugs/Public/show_bug.cgi?id=14037#c29 would be helpful

[16:48:00.0000] <smaug____>
jgraham: IIRC IE implements most of webidl. at least things like interface.prototype.property handling

[16:48:01.0000] <Hixie>
annevk5: ping

[16:55:00.0000] <karlcow>
http://www.amazon.com/gp/feature.html/ref=amb_link_357613442_1?ie=UTF8&docId=1000729901&pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-5&pf_rd_r=0QAERWX4FF6S17ZXDZRR&pf_rd_t=1401&pf_rd_p=1321300302&pf_rd_i=1000729511

[16:59:00.0000] <karlcow>
"<?xml?> This tag identifies a document as an XML document"  ?


2011-10-21
[17:15:00.0000] <zcorpan>
Hixie: +partial interface <a href=#document>Document</a> {

[17:15:01.0000] <zcorpan>
+  readonly attribute <code><a href=#document>Document</a></code> <a href=#htmldocument title=HTMLDocument>HTMLDocument</a>;

[17:15:02.0000] <zcorpan>
Hixie: that doesn't make sense

[17:15:03.0000] <Hixie>
nonetheless it is what i intended, I believe

[17:15:04.0000] <Hixie>
see the bug in question for more details

[17:15:05.0000] <zcorpan>
Hixie: don't you want that on Window ?

[17:15:06.0000] <Hixie>
oh, right

[17:16:00.0000] <Hixie>
oops

[17:16:01.0000] <Hixie>
good point

[17:16:02.0000] <zcorpan>
now sleep

[17:16:03.0000] <Hixie>
also i made it return the document instead of the interface!

[17:16:04.0000] <Hixie>
man i suck

[17:17:00.0000] <zcorpan>
heh

[17:37:00.0000] <Hixie>
abarth: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13776 makes my head hurt

[17:37:01.0000] <Hixie>
er

[17:37:02.0000] <Hixie>
s/abarth: //

[17:43:00.0000] <Hixie>
OH MY GOD BROWSERS MAKE NO SENSE

[17:43:01.0000] <Hixie>
<form> <img name=y><img name=y> </form>   form.y == HTMLCollection with length 2, containing two images

[17:44:00.0000] <Hixie>
<form> <img name=y><img name=y><input name=y> </form>   form.y == the <input> element.

[17:44:01.0000] <Hixie>
WHAT IS THIS I DON'T EVEN

[17:55:00.0000] <sicking>
Hixie: do they all do the same thing?

[17:56:00.0000] <sicking>
Hixie: with a lot of edge cases around this I wouldn't expect them to

[18:01:00.0000] <Hixie>
sicking: yeah, more or less

[18:02:00.0000] <sicking>
that's awesome

[18:10:00.0000] <jarek>
Hi

[18:10:01.0000] <jarek>
the {url} is defined in CSS as follows:

[18:10:02.0000] <jarek>
([!#$%&*-~]|{nonascii}|{escape})*

[18:11:00.0000] <jarek>
what does exactly [!#$%&*-~] sequence mean? One char from !,#,$,%,&,*,-,~ ?

[18:11:01.0000] <jarek>
is so, it doesn't make sense to me

[18:26:00.0000] <Hixie>
sicking: for extra amusement, <form> <img name=y><img name=y><input name=y type=image> </form>   form.y == HTMLCollection with length 2, containing the two <img>s

[18:26:01.0000] <Hixie>
jarek__: it means one char from ,#,$,%,& or any char from * to ~

[18:26:02.0000] <sicking>
Hixie: yeah, the old type=image bug that we inherited from ancient netscape days is hilarious

[18:26:03.0000] <Hixie>
yeah

[18:27:00.0000] <sicking>
i suspect it annoys websites as much as it annoys us

[18:27:01.0000] <Hixie>
also, <form><input name=x></form> form.x == the input; now change form.x.name to 'y' and form.x STILL returns the input

[18:27:02.0000] <sicking>
but there's just too much old content depending on it to change it

[18:27:03.0000] <Hixie>
yeah

[18:27:04.0000] <sicking>
Hixie: the latter might have just changed in Firefox

[18:27:05.0000] <sicking>
Hixie: try nigtlies

[18:28:00.0000] <sicking>
Hixie: <3 proxies

[18:28:01.0000] <sicking>
Hixie: i suspect the web doesn't depend on that

[18:28:02.0000] <Hixie>
seems to me it still does it

[18:28:03.0000] <sicking>
Hixie: in general, behavior around mutations is much less depended on since old content didn't do it

[18:29:00.0000] <Hixie>
so do all the other browsers

[18:29:01.0000] <Hixie>
my understanding is that this one is required by compat

[18:29:02.0000] <sicking>
Hixie: ooh, form.x, not form.elements.x

[18:29:03.0000] <Hixie>
the html spec has required it for some time and that's not the kind of craziness i put in without good reason ;-)

[18:29:04.0000] <Hixie>
yeah, none of this is .elements.

[18:29:05.0000] <Hixie>
.elements is somewhat better behaved

[18:29:06.0000] <Hixie>
at least in non-webkit

[18:29:07.0000] <jarek__>
Hixie: thanks

[19:49:00.0000] <annevk>
Hixie, pong

[19:54:00.0000] <annevk>
heycam|away, I meant exceptions "thrown by" Web IDL

[20:20:00.0000] <Hixie>
annevk: XMLDocument thing, see bugmail

[20:22:00.0000] <MikeSmith>
hmm, http://validator.nu/?doc=https%3A%2F%2Fdvcs.w3.org%2Fhg%2Fwebperf%2Fraw-file%2Ftip%2Fspecs%2FPageVisibility%2FOverview.html&showsource=yes

[20:23:00.0000] <annevk>
I see, we've been trying to avoid such a dependency

[20:23:01.0000] <MikeSmith>
«The encoding "utf-8" is not the preferred name of the character encoding in use. The preferred name is utf-8.»

[20:26:00.0000] <annevk>
Maybe HTML should simply define createDocument() as well then

[20:26:01.0000] <annevk>
if it's for creating XMLDocument

[20:27:00.0000] <annevk>
/me sighs

[20:27:01.0000] <MikeSmith>
Content-Type: text/html; charset="UTF-8"

[20:28:00.0000] <Hixie>
annevk: you should be fine

[20:28:01.0000] <Hixie>
annevk: no dependency

[20:28:02.0000] <Hixie>
annevk: just put  interface XMLDocument : Document { }  after you define Document

[20:28:03.0000] <Hixie>
annevk: and made createDocument() return an XMLDocument

[20:29:00.0000] <Hixie>
annevk: that's all

[20:29:01.0000] <annevk>
aah

[20:29:02.0000] <annevk>
you made it partial

[20:29:03.0000] <annevk>
sweet

[20:29:04.0000] <Hixie>
yup

[20:29:05.0000] <annevk>
thanks Hixie

[20:29:06.0000] <Hixie>
np

[20:53:00.0000] <annevk>
Hixie, http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domimplementation-createdocument

[20:58:00.0000] <ojan>
annevk: i have yet to respond to the e4x thread, but just fyi, i disagree with alex that quasi's are the right solution to this

[20:59:00.0000] <ojan>
annevk: we should either move forward with an html-ified e4x variant or with your earlier array based proposal

[20:59:01.0000] <ojan>
i'll try and compose a proper email response tomorrow

[20:59:02.0000] <ojan>
too many threads going on at once to get any coding done :(

[21:01:00.0000] <annevk>
yay another supporter :)

[21:02:00.0000] <annevk>
though qfox might have a point that convincing TC39 is beyond the realm of possibility

[21:36:00.0000] <annevk>
http://stackoverflow.com/questions/6905167/javascript-parser-for-rdf-json-from-webvtt seems like this WebVTT thing is taking off

[22:23:00.0000] <rniwa>
annevk: yt?

[22:24:00.0000] <annevk>
yeah, just about to go though

[22:24:01.0000] <annevk>
back in an hour or so

[22:24:02.0000] <rniwa>
k

[22:25:00.0000] <rniwa>
Hixie: yt?

[22:41:00.0000] <annevk>
rniwa, back

[22:41:01.0000] <annevk>
/me is bad with estimates

[22:42:00.0000] <rniwa>
hi

[22:43:00.0000] <rniwa>
annevk: did you see my email about restoring selection?

[22:43:01.0000] <annevk>
hadn't read it yet

[22:43:02.0000] <rniwa>
ok

[22:44:00.0000] <rniwa>
so the thing is that there's a slight difference in the way selection is restored on Mac and IE/Firefox

[22:44:01.0000] <rniwa>
when undoing deletion

[22:45:00.0000] <rniwa>
annevk: say you have "hello world" and deleted "world" from the end by repeatedly pressing the backspace key

[22:45:01.0000] <rniwa>
until you get "hello"

[22:45:02.0000] <rniwa>
then you undo this on IE/Firefox, you'll get "hello world" with the caret collapsed at the end of "world"

[22:46:00.0000] <rniwa>
however on Mac's NSTextView, notepad, and WebKit, you'll see "world" being selected.

[22:46:01.0000] <annevk>
also in Opera

[22:46:02.0000] <rniwa>
annevk: oh you select the deleted contents?

[22:47:00.0000] <annevk>
i just tried and it seems like it

[22:47:01.0000] <rniwa>
I see.

[22:47:02.0000] <annevk>
not sure if we should standardize one way or the other though

[22:47:03.0000] <rniwa>
hm... but I think we might want to match the platform convetion

[22:47:04.0000] <rniwa>
at least for WebKit, we always try to match NSTextView's behavior whenever possible

[22:48:00.0000] <rniwa>
given that the feature already works as expected, I'm not sure people would like us to change the behavior.

[22:48:01.0000] <rniwa>
on the other hand, this gives us a lot of headache with respect to automatic transactions

[22:48:02.0000] <rniwa>
because when an author creates a DOM transaction group with a bunch of automatic transactions

[22:49:00.0000] <rniwa>
there's no way for us to delete whether a given DOM transaction is deleting stuff, inserting stuff, or replacing stuff

[22:49:01.0000] <rniwa>
since just deleting contents may involve inserting new brs, replacing p's and div's to fix up paragraphs :(

[22:49:02.0000] <othermaciej>
for user actions, it is almost certainly the right thing to follow platform convention

[22:49:03.0000] <othermaciej>
for programmatically initiated commands, it is a tradeoff

[22:49:04.0000] <rniwa>
othermaciej: hi maciej!

[22:50:00.0000] <rniwa>
othermaciej: I think the point of automatic transaction is to replace browser's native editing support

[22:50:01.0000] <othermaciej>
on the one hand, for a programmatically initiated command, the following JS code may make assumptions about the specific change that was made

[22:50:02.0000] <rniwa>
othermaciej: or add a custom editing action

[22:50:03.0000] <annevk>
hey othermaciej, long time!

[22:50:04.0000] <othermaciej>
on the other hand, ideally you want such code to follow platform conventions

[22:50:05.0000] <othermaciej>
hello annevk

[22:50:06.0000] <othermaciej>
I'm here every day, I just usually don't have much to say

[22:51:00.0000] <rniwa>
othermaciej: yeah, it's quite a dillema :(

[22:51:01.0000] <annevk>
rniwa, I don't think I really know about this to give useful input, other than that for user initiated actions, we usually don't require much in the spec

[22:51:02.0000] <rniwa>
annevk: yeah... I should probably talk to AryehGregor about this as well

[22:51:03.0000] <othermaciej>
if you programatically trigger an undo, it really should do the same thing as a user-level undo command would

[22:51:04.0000] <rniwa>
but then his spec doesn't really deal with undo/redo at the moment

[22:52:00.0000] <rniwa>
othermaciej: right. otherwise, it'll be way too confusing

[22:52:01.0000] <rniwa>
othermaciej: but it seems like the only way to restore selection properly

[22:53:00.0000] <rniwa>
othermaciej: is if author provided us of some information such as whether a DOM transaction deletes contents or not

[22:53:01.0000] <rniwa>
othermaciej: or use some heuristics to determine if a given DOM transaction looks like deleting contents

[22:53:02.0000] <rniwa>
I'd like to avoid the latter because that'll make things unpredictable

[22:54:00.0000] <othermaciej>
rniwa: are there special cases other than a series of backspace actions?

[22:54:01.0000] <rniwa>
since selection behavior is quite visible to scripts

[22:54:02.0000] <rniwa>
othermaciej: well you can insert text then delete

[22:54:03.0000] <othermaciej>
rniwa: cause if so, the only special case is deleting immediately behind the caret

[22:54:04.0000] <rniwa>
othermaciej: or you can delete then insert

[22:54:05.0000] <othermaciej>
does insert then delete collapse into a single undo transaction in normal editing?

[22:54:06.0000] <rniwa>
othermaciej: yeah but that's almost impossible to detect if the author was to implement it themselves

[22:54:07.0000] <rniwa>
othermaciej: yes

[22:55:00.0000] <rniwa>
othermaciej: at least on WebKit & Gecko

[22:55:01.0000] <othermaciej>
how about paste followed by backspace?

[22:55:02.0000] <rniwa>
othermaciej: also on MS Word, WordPad and NSTextView but NOT on notepad

[22:55:03.0000] <rniwa>
/me checks

[22:55:04.0000] <rniwa>
othermaciej: paste is treated a separate action

[22:55:05.0000] <zewt>
well, notepad doesn't even have multi-level undo, and its single-level undo is horrid ... safe to ignore it, i think

[22:56:00.0000] <rniwa>
othermaciej: so undoing paste+deletion will only undoes the deletion

[22:56:01.0000] <rniwa>
zewt: good point

[22:56:02.0000] <othermaciej>
rniwa: hmm, so typing a single character is observably different from a one-char paste

[22:56:03.0000] <rniwa>
othermaciej: yeah

[22:56:04.0000] <rniwa>
othermaciej: copy & paste (including drag & drop) are very special beasts

[22:56:05.0000] <zewt>
i don't think windows really has any strong platform-specific undo conventions, most of the platform core stuff has very weak undo

[22:57:00.0000] <zewt>
(eg. win32 text boxes also don't have multi-level undo)

[22:57:01.0000] <rniwa>
zewt: RichTextEdit has multi-level undo

[22:57:02.0000] <othermaciej>
rniwa: it sounds like, to capture this behavior correctly, you need an indication of author intent

[22:57:03.0000] <rniwa>
zewt: that's what WordPad uses as far as I know.

[22:57:04.0000] <rniwa>
othermaciej: yeah

[22:57:05.0000] <othermaciej>
rniwa: specifically, actions in response to "typing" are a special case

[22:58:00.0000] <othermaciej>
and you can't tell from the DOM change alone whether it is "typing"

[22:58:01.0000] <zewt>
(of course, undo particulars are still UA-specific at least, so an undo API should still be able to handle existing browser undo behavior)

[22:58:02.0000] <rniwa>
othermaciej: right

[22:58:03.0000] <zewt>
(eg. regardless of whether that behavior comes from the UA or the OS)

[22:59:00.0000] <rniwa>
zewt: yeah, I think we need to have some granularity on how undo/redo is done

[22:59:01.0000] <zewt>
personally i'd be happy if this fixes undo cursor positions and nothing else, that's the #1 thing that drives me crazy about rich text editors in browsers by a *huge* margin

[22:59:02.0000] <rniwa>
othermaciej: so maybe isTyping boolean?

[23:00:00.0000] <rniwa>
othermaciej, annevk: another headache I have is the fact that some automatic transaction may not want to mess with selection at all

[23:00:01.0000] <othermaciej>
rniwa: I suppose one implicit way to do it is to look at the event being processed, though key events can sometimes trigger non-typing actions (even for keys that would normally just enter text)

[23:00:02.0000] <rniwa>
othermaciej: not sure if that works because authors can do whatever they please to do

[23:01:00.0000] <rniwa>
othermaciej: e.g. they can decide to insert stuff when delete key is pressed

[23:01:01.0000] <zewt>
also in theory you could implement a touchscreen keyboard (where mouse events might want to behave like keystrokes)

[23:02:00.0000] <rniwa>
zewt: yeah

[23:02:01.0000] <rniwa>
othermaciej: another thing to consider is that authors may want to emulate typing commands without actually receiving user inputs

[23:03:00.0000] <rniwa>
also... another problem is that even if authors hinted us that some DOM transaction is deleting stuff or is a typing command

[23:03:01.0000] <rniwa>
it might be still hard for us to detect exactly what has been deleted

[23:04:00.0000] <rniwa>
since deleting a line break for example may end up fixing up the entire paragraph by inserting div's, p's, br's :(

[23:04:01.0000] <annevk>
Man, the way WebVTT is defined makes for a terrible read

[23:05:00.0000] <zewt>
havn't really followed this, but the basic idea is being able to coalesce edit transactions, right?

[23:05:01.0000] <zewt>
three delete-character edits coalescing into a single action, etc

[23:05:02.0000] <rniwa>
zewt: if author wishes to, yes

[23:05:03.0000] <rniwa>
zewt: the key issue is that how we restore selection in those cases

[23:06:00.0000] <rniwa>
zewt: in the case of non-typing commands, it's quite simple

[23:06:01.0000] <rniwa>
zewt: you just remember what the selection looked like before an automatic transaction

[23:06:02.0000] <rniwa>
zewt: and restore exactly that

[23:06:03.0000] <zewt>
btw. how can you delete a character when you have a selection? that normally turns backspace actions into delete-the-whole-selection

[23:07:00.0000] <rniwa>
when the DOM transaction is undone

[23:07:01.0000] <rniwa>
zewt: well selection can be either collapsed or uncollapsed

[23:07:02.0000] <rniwa>
it doesn't really matter

[23:08:00.0000] <rniwa>
zewt: the problem is when something is deleted and that deletion is undone

[23:08:01.0000] <rniwa>
zewt: in that case WebKit and Opera currently select the contents that have been added back to the document

[23:09:00.0000] <rniwa>
zewt: but when authors implement some automatic transactions, there is no good way for us to tell what has been deleted

[23:09:01.0000] <rniwa>
zewt: or worse, whether the command was deleting something at all

[23:09:02.0000] <rniwa>
 s/something/anything/

[23:10:00.0000] <zewt>
yeah i see what you mean

[23:10:01.0000] <zewt>
is the coalescing of transactions under the browser's control?

[23:10:02.0000] <rniwa>
zewt: it's under author's control 'til it's added to an UndoManager

[23:10:03.0000] <zewt>
eg. control-backspace two words in firefox is one undo transaction, two in webkit (chrome at least)

[23:11:00.0000] <zewt>
er, two undos

[23:11:01.0000] <zewt>
er no that was right (tired/late)

[23:11:02.0000] <rniwa>
zewt: really? that's surprising to me

[23:11:03.0000] <rniwa>
zewt: I thought we treat those as one undo item

[23:11:04.0000] <zewt>
don't know if that's chrome-specific behavior

[23:11:05.0000] <zewt>
(would have to load a vm to try in safari)

[23:11:06.0000] <rniwa>
interesting...

[23:12:00.0000] <rniwa>
zewt: it's webkit behavior probably copied from Mac

[23:12:01.0000] <Hixie>
rniwa: here now

[23:13:00.0000] <zewt>
rniwa: even more fun is multi-selects in firefox, where a single user action might delete noncontiguous text D:

[23:13:01.0000] <zewt>
(guess the same thing could happen in other browsers, if there's hidden text about)

[23:14:00.0000] <rniwa>
zewt: that, i'm not too worried about because only gecko supports multi-range selection at the moment

[23:14:01.0000] <rniwa>
zewt: so gecko can do whatever it wants to do

[23:15:00.0000] <zewt>
i want to see stats on how many people have ever used that :)

[23:15:01.0000] <zewt>
(manual distinct selections with control-click)

[23:15:02.0000] <rniwa>
Hixie: hi Hixie, so now that undomanager & dom transaction stuff are getting some traction, I want to propose more crazy ideas LOL

[23:15:03.0000] <zewt>
probably in the vicinity of: 0

[23:15:04.0000] <rniwa>
Hixie: namely I want to fix the way key binding works on the web

[23:15:05.0000] <zewt>
gooood luck

[23:16:00.0000] <Hixie>
rniwa: have browsers implemented the last set of improvements to key bindings yet?

[23:16:01.0000] <rniwa>
zewt: yeah, ehsan told me that there are some gecko users that really love that multi-rage stuff

[23:16:02.0000] <rniwa>
Hixie: which one?

[23:16:03.0000] <Hixie>
rniwa: <command>, the new accesskey="", accessKey, accessKeyLabel, etc

[23:16:04.0000] <rniwa>
Hixie: yes, that's exactly what i'm about to tell you

[23:17:00.0000] <rniwa>
Hixie: not sure if we had already talked about it on whatwg and elsewhere

[23:17:01.0000] <rniwa>
Hixie: but we'd like to be able to support ctrl, alt, cmd, and other modifiers

[23:17:02.0000] <rniwa>
Hixie: in accessKey

[23:17:03.0000] <zewt>
i'm surprised that opera *way* stepped back the number of keys it eats ... that was endless headaches trying to implement keyboard shortcuts

[23:17:04.0000] <rniwa>
/me is almost certain there is some bug about this

[23:17:05.0000] <Hixie>
rniwa: baby steps, we have to get the basics implemented first ;-)

[23:18:00.0000] <rniwa>
Hixie: yeah, but it's good to think about modifier keys first so that we don't get stuck with the basic ones

[23:18:01.0000] <Hixie>
rniwa: it's already planned

[23:18:02.0000] <rniwa>
Hixie: great.

[23:18:03.0000] <rniwa>
Hixie: anyway, on top of that, I want to die command element to editing commands

[23:18:04.0000] <rniwa>
Hixie: and provide a way to define an editing  command easily using command elements

[23:19:00.0000] <rniwa>
Hixie: so that authors can add new editing command like this: <command name="InsertDate" onapply="insertAtSelection(formattedDate())" isautomatic="true" accessKey="accel+d">

[23:19:01.0000] <Hixie>
rniwa: (namely, http://www.w3.org/Bugs/Public/show_bug.cgi?id=13958 is for modifiers, and http://www.w3.org/Bugs/Public/show_bug.cgi?id=13576 is for specific labeled keys)

[23:19:02.0000] <rniwa>
Hixie: right. this is more stuff on top of that

[23:20:00.0000] <Hixie>
rniwa: (i expect to support modifiers via something like accesskey="ctrl+a command+a" or something once we've established whether the multiple key thing works at all

[23:20:01.0000] <Hixie>
rniwa: (hence the way it's specced so far, with all the room for expansion)

[23:20:02.0000] <Hixie>
rniwa: i don't really understand your proposal for editing commands, but the general idea seems sound

[23:20:03.0000] <Hixie>
rniwa: i expect we'll add that once browsers actually support <menu>, <command>, etc

[23:20:04.0000] <rniwa>
Hixie: so basically it lets you register you execCommand

[23:21:00.0000] <Hixie>
yeah

[23:21:01.0000] <rniwa>
new*

[23:21:02.0000] <rniwa>
Hixie: but I don't quite get what menu does

[23:21:03.0000] <rniwa>
given that we don't have any ways to define a toolbar

[23:21:04.0000] <rniwa>
why do we just support menu?

[23:21:05.0000] <Hixie>
<menu type=toolbar> is how you define a toolbar

[23:22:00.0000] <Hixie>
and <menu type=context> defines a context menu

[23:22:01.0000] <rniwa>
hm...

[23:22:02.0000] <Hixie>
see the spec :-)

[23:22:03.0000] <rniwa>
I must have missed it when I skimmed through the spec

[23:25:00.0000] <rniwa>
Hixie: ok, I might look into implementing that for WebKit then

[23:26:00.0000] <Hixie>
that'd be great. i've got a ton of improvements in that area that are just waiting for solid implementations of the stuff there so far

[23:26:01.0000] <Hixie>
one big open question is styling of the toolbars; i think we should have some sort of pseudo-element or something, but i dunno exactly how that would work

[23:26:02.0000] <Hixie>
(not an issue for menus since those should just match the platform conventions)

[23:27:00.0000] <rniwa>
Hixie: what do we need pseudo-elements for?

[23:28:00.0000] <Hixie>
well e.g. for <menu type=toolbar> <a href="/">Home</a> <input type=button value=Save> <command type=checkbox label="Enable Spellcheck"> </menu>

[23:28:01.0000] <Hixie>
how do you style the three buttons to fit your site?

[23:28:02.0000] <Hixie>
the usual :link, <input> and <command> styles obviously don't apply

[23:28:03.0000] <rniwa>
Hixie: can't you just do menu > * {~~} ?

[23:29:00.0000] <Hixie>
rniwa: not really, the elements involved have such different ways of being represented

[23:29:01.0000] <Hixie>
rniwa: e.g. <a> has contents, but <input> has a value

[23:29:02.0000] <Hixie>
rniwa: usual CSS doesn't really work here

[23:30:00.0000] <Hixie>
rniwa: also, <menu type=toolbar> <hr> <button></button> <hr><hr> <button></button> FOO </menu> only has one separator and shouldn't say "FOO", CSS can't really represent that

[23:30:01.0000] <Hixie>
rniwa: so you really want to construct the menu, per the spec, and then style the constructed menu, not the DOM directly

[23:30:02.0000] <Hixie>
rniwa: hence, pseudo-elements

[23:30:03.0000] <Hixie>
rniwa: but it's not exactly clear how it'd work

[23:31:00.0000] <rniwa>
hm...

[23:32:00.0000] <rniwa>
Hixie: why don't we restrict things that can appear in menu more?

[23:32:01.0000] <Hixie>
rniwa: how do you mean?

[23:32:02.0000] <rniwa>
e.g. only commands and hr can appear inside menu

[23:32:03.0000] <Hixie>
rniwa: that would be lame

[23:32:04.0000] <Hixie>
rniwa: e.g. how would you do a command that follows a link?

[23:33:00.0000] <Hixie>
rniwa: also, the fallback story is terrible

[23:33:01.0000] <Hixie>
rniwa: we have HTML elements with the semantics we want, it seems to make sense to use them

[23:33:02.0000] <Hixie>
rniwa: in any case, it still wouldn't really solve our problem

[23:34:00.0000] <Hixie>
rniwa: even with just <command> and <hr>, you still have the separator-collapsing logic to handle, and <command> doesn't render as anything (it's display:none) so styling it isn't helpful

[23:34:01.0000] <rniwa>
Hixie: that's one thing I don't like about the current spec

[23:35:00.0000] <rniwa>
Hixie: why can't we just make command element take contents?

[23:35:01.0000] <rniwa>
Hixie: then you can wrap whatever you want inside command elements

[23:35:02.0000] <Hixie>
rniwa: three reasons

[23:35:03.0000] <rniwa>
Hixie: and whatever algorithm we use to generate toolbars and menus can just look at command elements

[23:36:00.0000] <Hixie>
rniwa: 1. on the long term that will make pages really verbose (<command></command>) which is bad for authoring

[23:36:01.0000] <Hixie>
rniwa: 2. it doesn't make the algorithms any simpler, really.

[23:36:02.0000] <Hixie>
rniwa: 3. it means authors would have to implement everything twice to get fallback (once in <command> and once the old way)

[23:36:03.0000] <Hixie>
more reasons: 4. it would mean having to define what happens to the fallback elements for purposes of form submission

[23:37:00.0000] <Hixie>
also, the idea long term is to have <command> be able to refer to other elements, e.g. <a href="/" id=home>Home</a> with somewhere else <command ref=home>

[23:37:01.0000] <Hixie>
so that you only have to disable things or update thinsg once (e.g. only have to update the a.href here once) even if the command is in many menus and toolbars and so on

[23:38:00.0000] <Hixie>
that's really the only reason <command> exists at all

[23:38:01.0000] <rniwa>
Hixie: if we're adding ref/for to command, it seems more natural to make it wrap the elements that it refers to.

[23:38:02.0000] <Hixie>
that and being able to define commands that _don't_ have legacy fallback (which is useful if, e.g., your context menu is completely redundant with some "real" buttons)

[23:39:00.0000] <Hixie>
no i mean being able to reference the command from multiple places

[23:39:01.0000] <rniwa>
Hixie: you can define a fallback-less command by omitting the contents, right?

[23:39:02.0000] <Hixie>
yeah but that's way too verbose

[23:39:03.0000] <rniwa>
hm...

[23:39:04.0000] <rniwa>
i disagree > way too verbose

[23:40:00.0000] <Hixie>
you don't think littering the DOM with </command> end tags is verbose? o_O

[23:40:01.0000] <rniwa>
no

[23:40:02.0000] <rniwa>
I think that's much better than having to add random ref/for attributes

[23:40:03.0000] <rniwa>
I hate having to add id's just so that I can refer from elsewhere

[23:40:04.0000] <Hixie>
i don't understand how they are related

[23:43:00.0000] <rniwa>
okay let's take the example in 4.11.4.1 Introduction

[23:43:01.0000] <rniwa>
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html

[23:43:02.0000] <rniwa>
Hixie: what if I wanted to attach an icon to <button type="button" onclick="fnew()">New...</button> ?

[23:43:03.0000] <rniwa>
Hixie: how do I do that under the current spec?

[23:44:00.0000] <Hixie>
you can't, <button> doesn't have icons.

[23:44:01.0000] <rniwa>
Hixie: right but I want it to have an icon when it's shown in the menu

[23:44:02.0000] <rniwa>
Hixie: so I'd end up adding a command element anyway to work-around this limiation

[23:44:03.0000] <Hixie>
oh actually no

[23:45:00.0000] <Hixie>
the spec does define a way to give an icon

[23:45:01.0000] <Hixie>
you just put an <img> inside the <button>

[23:45:02.0000] <rniwa>
:(

[23:45:03.0000] <Hixie>
see http://www.whatwg.org/specs/web-apps/current-work/#using-the-a-element-to-define-a-command

[23:45:04.0000] <Hixie>
(the <button> section basically copies the <a> section)

[23:46:00.0000] <rniwa>
Hixie: ok, what if I wanted to disable <li><a href="help.html">Help</a></li> ?

[23:46:01.0000] <Hixie>
rniwa: how would you do that irrespective of menus?

[23:47:00.0000] <rniwa>
Hixie: well, if it were a menu item

[23:47:01.0000] <rniwa>
Hixie: then I can always disable it regardless of what it does at least on Windows

[23:47:02.0000] <rniwa>
to begin with, a link in a context menu shouldn't show up as a link

[23:47:03.0000] <rniwa>
it should look like any other menu item

[23:47:04.0000] <Hixie>
exactly

[23:47:05.0000] <Hixie>
which the spec requires

[23:47:06.0000] <rniwa>
but I should still be able to disable that

[23:47:07.0000] <Hixie>
(whence, for toolbars, the styling issue)

[23:48:00.0000] <Hixie>
why?

[23:48:01.0000] <Hixie>
what's the use case for disabling a link?

[23:48:02.0000] <rniwa>
because maybe help doesn't exist for some content

[23:48:03.0000] <rniwa>
and I don't want users to click that

[23:48:04.0000] <Hixie>
if there's a use case for disabling a link, we should fix that with <a>, it's not menu-specific

[23:48:05.0000] <rniwa>
I mean these are just examples

[23:49:00.0000] <rniwa>
but I feel like the current spec is way too complicated to be adopted

[23:49:01.0000] <Hixie>
(if help doesn't exist, the right UI is to remove the item from the menu altogether, which you would do by adding a hidden="" attribute)

[23:49:02.0000] <rniwa>
due to all the fallback consideration

[23:49:03.0000] <Hixie>
i don't understand what is complicated here

[23:49:04.0000] <Hixie>
it's really simple

[23:50:00.0000] <Hixie>
certain elements implement this "command" concept. menus just collect all their commands and render them.

[23:50:01.0000] <Hixie>
where's the problem?

[23:50:02.0000] <Hixie>
the fallback just falls out of the design

[23:50:03.0000] <Hixie>
and doesn't get in the way once it's no longer needed

[23:50:04.0000] <Hixie>
it's essentially free

[23:50:05.0000] <Hixie>
plus, in the future, we reuse all the infrastructure to get <command ref=""> essentially for free again

[23:50:06.0000] <rniwa>
as an author, I don't care about fallbacks

[23:51:00.0000] <rniwa>
I just want to be able to do everything using command element

[23:51:01.0000] <Hixie>
and you can, if you want to

[23:51:02.0000] <Hixie>
meanwhile, authors who _do_ care about fallback, can still do it

[23:51:03.0000] <rniwa>
hm...

[23:51:04.0000] <Hixie>
and authors who have links and buttons in parts of their app that do the same as commands in their menus, in the future, once we add <command ref>, get all the indirection magic for free

[23:51:05.0000] <Hixie>
so they don't have to disable every last menu item that does the same thing

[23:52:00.0000] <Hixie>
they just disable it once and boom, all the menus and toolbars update

[23:54:00.0000] <rniwa>
now I see some command-element-only example in the spec

[23:54:01.0000] <rniwa>
I guess this might work

[23:54:02.0000] <rniwa>
<command ref> thing definitely sounds useful

[23:55:00.0000] <rniwa>
alright, let me look into implementing this thing then

[23:55:01.0000] <Hixie>
cool

[23:56:00.0000] <rniwa>
then I'll know whether I like or hate the spec :)

[23:56:01.0000] <Hixie>
:-)

[23:57:00.0000] <rniwa>
Hixie: btw, I don't quite get what you're seeing in http://www.w3.org/Bugs/Public/show_bug.cgi?id=14337

[23:57:01.0000] <rniwa>
Hixie: are you referring to DOM changes made by scripts or IE?

[00:19:00.0000] <Hixie>
both

[00:20:00.0000] <Hixie>
e.g. do changes from a setInterval()

[00:20:01.0000] <Hixie>
they get undone

[00:20:02.0000] <Hixie>
if you undo immediately after the drag

[00:20:03.0000] <Hixie>
i'm not sure we really want this behaviour; i specced it just cos i was speccing whatever IE did

[00:20:04.0000] <Hixie>
it's probably better to call it a bug

[01:07:00.0000] <annevk>
Glenn Adams...

[02:27:00.0000] <zcorpan>
Hixie: so i think it's still not right. :-)

[02:27:01.0000] <zcorpan>
Hixie: +  readonly attribute <code><a href=#document>Document</a></code> <a href=#htmldocument title=HTMLDocument>HTMLDocument</a>;

[02:27:02.0000] <zcorpan>
Hixie: the Document interface object is not an instance of Document

[02:27:03.0000] <zcorpan>
Hixie: so the return type should be something else

[02:29:00.0000] <annevk>
what does interface Document {} expose then?

[02:36:00.0000] <zcorpan>
annevk: i don't understand the question

[02:37:00.0000] <annevk>
I get what you mean now, I think

[02:40:00.0000] <annevk>
I guess it needs to be defined in terms of http://dev.w3.org/2006/webapi/WebIDL/#dfn-relevant-namespace-object and below

[02:43:00.0000] <zcorpan>
"Interface objects are always function objects." - i guess s/Document/Function/ then

[02:51:00.0000] <danbri>
http://www.downforeveryone.com/www.whatwg.org/

[02:52:00.0000] <danbri>
'Hey, it's not just you! http://www.whatwg.org/ looks down from here. '

[04:30:00.0000] <annevk>
why does WebVTT require decimal separators?

[04:32:00.0000] <annevk>
I mean milliseconds

[04:34:00.0000] <Lachy>
Huh? Why shouldn't it? Milliseconds give the required precision.

[04:39:00.0000] <annevk>
if they happen to zero

[04:40:00.0000] <annevk>
I guess it does not matter much

[05:07:00.0000] <annevk>
I don't really get these WebVTT settings

[05:09:00.0000] <annevk>
e.g. some line ending in "00:13.000 X A:start" has that A:start to discarded with the current parsing algorithm

[05:09:01.0000] <annevk>
seems wrong

[06:10:00.0000] <zcorpan>
annevk: why does it seem wrong? that's the same as css decl, basically

[06:13:00.0000] <annevk>
I'm more confused by e.g. D:vertical followed by two spaces

[06:13:01.0000] <annevk>
and that followed by A:start or some such

[06:14:00.0000] <annevk>
afaict "setting will be set to the second "space"

[06:14:01.0000] <annevk>
or maybe even the first

[06:14:02.0000] <annevk>
which seems highly undesirable

[06:15:00.0000] <annevk>
there's some skip.spaces step missing after you consumed a setting

[06:15:01.0000] <zcorpan>
/me hasn't looked at settings parsing yet

[06:17:00.0000] <zcorpan>
also D: vertical fails to parse

[06:18:00.0000] <annevk>
yeah it does in my validator

[06:18:01.0000] <annevk>
I guess I should upload something so people can teach me how to write code

[06:18:02.0000] <zcorpan>
/me isn't a fan of single-letter settings

[06:19:00.0000] <annevk>
guess I'll continue tomorrow

[06:20:00.0000] <annevk>
will upload something so people can leave comments

[06:22:00.0000] <annevk>
http://quuz.org/webvtt/

[06:22:01.0000] <annevk>
http://quuz.org/webvtt/parser.js

[06:23:00.0000] <annevk>
zcorpan, ^^

[06:25:00.0000] <zcorpan>
found a bug :-)

[06:25:01.0000] <zcorpan>
space after signature should be allowed

[06:25:02.0000] <divya>
zcorpan knows how to crush dreams

[06:26:00.0000] <zcorpan>
:S

[06:26:01.0000] <divya>
:))

[06:26:02.0000] <annevk>
I wonder what's wrong with my SIGNATURE code

[06:28:00.0000] <zcorpan>
00::51.000 and 00:0:51.000 validate

[06:28:01.0000] <annevk>
yeah I noticed that too

[06:31:00.0000] <annevk>
fixed that bug

[06:32:00.0000] <zcorpan>
the sig check seems bogus

[06:35:00.0000] <annevk>
needs to be &&

[06:35:01.0000] <zcorpan>
you could do line.match(/^WEBVTT(( |\t).*)?/) or some such

[06:35:02.0000] <annevk>
also fixed

[06:36:00.0000] <annevk>
could also replace || with &&

[06:36:01.0000] <annevk>
there's no requirements for anything after that tab or space

[06:37:00.0000] <annevk>
although I guess "WEBVTT TEST" should maybe not be valid even though it should be processed

[06:39:00.0000] <zcorpan>
it's valid

[06:40:00.0000] <hsivonen>
Opera Reader is very cool. however, I'd like to have "tap edge for page turn" in addition to swiping

[06:40:01.0000] <annevk>
zcorpan, not per the syntax section

[06:40:02.0000] <hsivonen>
swiping a lot isn't very ergonomic

[06:40:03.0000] <zcorpan>
annevk: yes it is :)

[06:41:00.0000] <annevk>
oh right

[06:41:01.0000] <annevk>
bah

[06:41:02.0000] <zcorpan>
hsivonen: send an email to h&kon :-)

[06:41:03.0000] <annevk>
don't really think it should be valid though

[06:41:04.0000] <annevk>
makes no sense

[06:41:05.0000] <zcorpan>
doesn't manifest do the same thing?

[06:41:06.0000] <hsivonen>
zcorpan: I'll see if there's a www-style thread I could send email to first

[06:42:00.0000] <annevk>
zcorpan, dunno, never wrote a validator for that one

[06:42:01.0000] <hsivonen>
Also, Opera Reader really needs some kind of easy-to-use way of forcing the paged mode on legacy sites

[06:44:00.0000] <zcorpan>
i suspect that forcing paged mode on legacy sites would often break in more horrible ways than fit-to-width

[07:10:00.0000] <hsivonen>
zcorpan: I guess sites that would break horrible wouldn't be very printer-friendly either

[07:10:01.0000] <hsivonen>
maybe the Web isn't printer-friendly in general

[07:34:00.0000] <Ms2ger>
annevk5, thanks for fixing XMLDocument in DOMPS

[07:40:00.0000] <annevk>
Ms2ger, hey no worries

[07:41:00.0000] <annevk>
Ms2ger, I was wondering though, should that really be XMLDocument?

[07:41:01.0000] <annevk>
Ms2ger, in that Document == XMLDocument bug people suggested only createDocument should return XMLDocument

[07:41:02.0000] <Ms2ger>
I dunno, I just defined what Gecko did

[07:41:03.0000] <Ms2ger>
It probably doesn't matter

[07:43:00.0000] <smaug____>
createDocument doesn't always return XMLDocument

[07:43:01.0000] <Ms2ger>
In Gecko

[07:43:02.0000] <smaug____>
yes, in Gecko

[07:43:03.0000] <smaug____>
and I think Acid3 even had some tests for that

[07:44:00.0000] <smaug____>
at least ACID3 is the reason why Gecko's createDocument behaves the way it does

[07:44:01.0000] <annevk>
I doubt Acid3 has the DocumentType nonsense

[07:44:02.0000] <smaug____>
IIRC it does had

[07:44:03.0000] <annevk>
Ms2ger, guess we'll sort it out later then

[07:45:00.0000] <Ms2ger>
It had a lot of nonsense, that much is clear

[07:45:01.0000] <annevk>
trololol

[07:47:00.0000] <gsnedders>
/me is wondering whether E4H is really a good idea at all

[07:47:01.0000] <gsnedders>
E4X is too far one way, E4H is too far the other

[07:47:02.0000] <annevk>
it's H4E man

[07:47:03.0000] <gsnedders>
w/e

[07:47:04.0000] <annevk>
for extra confusion

[07:48:00.0000] <gsnedders>
I care about the semantics of the proposal.

[07:48:01.0000] <annevk>
the proposal had virtually no details though

[10:36:00.0000] <Hixie>
zcorpan: Function is not a function object (possibly confusingly)

[10:37:00.0000] <Hixie>
zcorpan: Function is just a [Callback=FunctionOnly, NoInterfaceObject] callback interface with one member that takes any any arguments and returns any

[10:39:00.0000] <linclark>
does anyone know what the current thinking on the time element is?

[10:39:01.0000] <linclark>
I'm looking at this bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240

[10:41:00.0000] <hsivonen>
linclark: I expect different people to have different current thinking

[10:43:00.0000] <linclark>
hsivonen: right, but are there any discussions that are more current

[10:43:01.0000] <linclark>
I'm asking because we're working on implementing a theme_time function in Drupal

[11:01:00.0000] <franksalim>
Hixie: that is...quotable...and it reminds me of the "a monad is just a monoid in the category of endofunctors, what's the problem?" joke about Haskell...probably because you said "is just a" and then gave a precise and complicated definition. :)

[11:02:00.0000] <dglazkov>
good morning, Whatwg!

[11:02:01.0000] <hsivonen>
linclark: I'm not aware of more current discussions, but my mailing list reading isn't up to date

[11:02:02.0000] <hsivonen>
dglazkov: good evening

[11:04:00.0000] <linclark>
hsivonen: ok, thanks... as long as it ends up being one of the proposed alternatives, it shouldn't take long for us to update

[11:07:00.0000] <jarek>
Hello

[11:07:01.0000] <jarek>
why MEDIA_SYM CSS token is defined like this:

[11:07:02.0000] <jarek>
@{M}{E}{D}{I}{A}

[11:08:00.0000] <jarek>
while CHARSET_SYM token is defined this way:

[11:08:01.0000] <jarek>
"@charset "

[11:08:02.0000] <jarek>
does it mean that "@cha\rset 'utf-8'" is not a valid charset declaration?

[11:09:00.0000] <jarek>
while something like "@med\ia" would be valid?

[11:11:00.0000] <jarek>
yup, W3C validator fails on @cha\rset "UTF-8";

[11:16:00.0000] <jarek>
this seems to be rather inconsistent, what is the reason behind not allowing the escapes inside "@charset" or "url("? " or "~="?

[11:21:00.0000] <jarek>
validator marks @med\ia as error as well, I don't get it

[11:21:01.0000] <zewt>
"In fact, it's possible to implement ES functionality with better performance then the native implementations."

[11:21:02.0000] <zewt>
do people realize how silly they sound when they make claims like that

[11:22:00.0000] <jarek>
ahh... it accepts only hex escapes

[11:22:01.0000] <zewt>
there's no such thing as faster than native, sorry, next

[11:30:00.0000] <Hixie>
franksalim: heh

[11:31:00.0000] <Hixie>
jarek: @charset is special

[11:31:01.0000] <Hixie>
jarek: because we don't want people to have to run a complicated css parser just to get the character encoding which they need to know in order to create a css parser :-)

[11:31:02.0000] <Hixie>
bbiab

[15:20:00.0000] <rniwa>
Hixie: yt?

[15:20:01.0000] <rniwa>
or anyone else familiar with microdata?

[15:29:00.0000] <Hixie>
rniwa: here

[15:30:00.0000] <rniwa>
Hixie: I was a bit confused about DOMSettableTokenList

[15:30:01.0000] <rniwa>
Hixie: I just filed a bug saying that section 2.8.1 (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#reflect)

[15:30:02.0000] <rniwa>
Hixie: should probably define IDL attributes in terms of content attribute

[15:30:03.0000] <rniwa>
instead of defining in terms of types of IDL attributes

[15:31:00.0000] <Hixie>
why?

[15:31:01.0000] <Hixie>
and what does that have to do with DOMSettableTokenList :-)

[15:32:00.0000] <rniwa>
Hixie: e.g. if an idl attribute is reflecting a content attribute of the type "unordered set of unique space-separated tokens" then its type will be http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#domsettabletokenlistt or something like

[15:32:01.0000] <rniwa>
Hixie: because I usually look for the type of content type.

[15:33:00.0000] <rniwa>
Hixie: when an IDL attribute reflects a content attribute

[15:33:01.0000] <rniwa>
I usually know the type of content attribute

[15:33:02.0000] <rniwa>
but not necessarily of the type of idl attribute

[15:33:03.0000] <rniwa>
anyway, it's not that important though

[15:33:04.0000] <Hixie>
content attributes don't have a type

[15:33:05.0000] <Hixie>
well, i mean, they're all strings

[15:34:00.0000] <Hixie>
or am i misunderstanding...?

[15:35:00.0000] <rniwa>
Hixie: well but they do have different kinds like space separted tokens, etc...

[15:35:01.0000] <rniwa>
separated*

[15:35:02.0000] <Hixie>
oh you mean the conformance requirements for what's allowed in them?

[15:35:03.0000] <Hixie>
i guess

[15:35:04.0000] <Hixie>
not sure how you'd use those to define UA requirements

[15:35:05.0000] <rniwa>
Hixie: sort of

[15:36:00.0000] <rniwa>
I want a way to lookup the type of idl attribute given a description of content attribute

[15:36:01.0000] <Hixie>
there's not a 1:1 mapping

[15:36:02.0000] <rniwa>
hm...

[15:36:03.0000] <rniwa>
that explains it but also sucks :(

[15:38:00.0000] <Hixie>
welcome to the web

[15:39:00.0000] <Hixie>
what are you looking up that makes it easier for you to look things up based on the content attribute than the idl type?

[15:39:01.0000] <rniwa>
Hixie: i was looking at microdata API

[15:39:02.0000] <rniwa>
Hixie: and in particular itemProp idl attribute

[15:42:00.0000] <jgraham>
zewt: I assume they meant "faster than C++", which could be true

[15:42:01.0000] <jgraham>
Depending on where the bottlenecks are

[15:45:00.0000] <rniwa>
jgraham: talking about some JS engine performance?

[15:45:01.0000] <Hixie>
rniwa: i don't understand why that was easier to do using the content attribute than the idl type

[15:45:02.0000] <Hixie>
abarth: yt?

[15:45:03.0000] <abarth>
hi

[15:45:04.0000] <rniwa>
Hixie: yeah, I guess my comment was useless given the definitions aren't bijective

[15:45:05.0000] <Hixie>
abarth: the origin spec doesn't have special dispensation for cases where urls with a domain part that are supported by the UA might have per-url origin

[15:45:06.0000] <rniwa>
Hixie: thought they were bijective

[15:45:07.0000] <Hixie>
abarth: e.g. an NNTP post

[15:45:08.0000] <Hixie>
rniwa: k

[15:46:00.0000] <rniwa>
Hixie: sorry about the noise

[15:46:01.0000] <Hixie>
rniwa: (one example is that class="" and itemprop="" (className and itemProp) have roughly the same definition, but reflect very differently)

[15:46:02.0000] <abarth>
Hixie: i see

[15:46:03.0000] <Hixie>
rniwa: (and indeed className and classList both reflect class="")

[15:46:04.0000] <Hixie>
rniwa: (in different ways)

[15:46:05.0000] <rniwa>
:(

[15:47:00.0000] <Hixie>
abarth: third bullet point of http://www.whatwg.org/specs/web-apps/current-work/#origin

[15:47:01.0000] <rniwa>
/me is annoyed by the complexity

[15:47:02.0000] <Hixie>
abarth: er, third <li> i should say

[15:47:03.0000] <Hixie>
rniwa: dude if you think that's bad, wait til you hear about HTMLFormElement's named property access

[15:47:04.0000] <Hixie>
rniwa: (see my public g+ post)

[15:48:00.0000] <rniwa>
Hixie: yes, I know the badness in that area

[15:48:01.0000] <rniwa>
Hixie: I've worked on fixing selectionStart/selectionEnd in input/textarea :(

[15:48:02.0000] <abarth>
Hixie: i guess it boils down to the notion of "support"

[15:48:03.0000] <rniwa>
they are the worst properties :(

[15:48:04.0000] <abarth>
        <t>If the implementation doesn't support the protocol given by

[15:48:05.0000] <abarth>
        uri-scheme, then return generate a fresh globally unique identifier

[15:48:06.0000] <abarth>
        and return that value.</t>

[15:48:07.0000] <Hixie>
abarth: it has to not be a fresh one, it has to be teh same one each time

[15:48:08.0000] <rniwa>
although input.type is pretty bad-ass too

[15:49:00.0000] <Hixie>
abarth: so e.g. different documents that are in one multipart/something e-mail all get the same origin, but not the same origin as other e-mails on that same IMAP server

[15:49:01.0000] <Hixie>
rniwa: i mean specifically the named property access stuff on <form>

[15:49:02.0000] <rniwa>
Hixie: oh, I haven't looked at that one in particular

[15:50:00.0000] <abarth>
ok

[15:50:01.0000] <Hixie>
rniwa: it makes the reflection stuff look positively mundane

[15:50:02.0000] <jgraham>
rniwa: Yeah

[15:50:03.0000] <abarth>
that's just a question of when you run the algorithm

[15:50:04.0000] <Hixie>
abarth: how so?

[15:50:05.0000] <abarth>
you just need to run it once for the whole multi-part package

[15:50:06.0000] <abarth>
rather than once for each part of the package

[15:51:00.0000] <Hixie>
abarth: each part has a differnet url

[15:51:01.0000] <Hixie>
abarth: so clearly it has to be run for each part

[15:51:02.0000] <abarth>
won't they be different origins if you're treating the whole URL as the origin?

[15:51:03.0000] <abarth>
maybe i misunderstood

[15:52:00.0000] <Hixie>
say you have a scheme  foo://example.org/document1/part1

[15:52:01.0000] <Hixie>
and everything in foo://example.org/document1/* has to have the same unique origin

[15:52:02.0000] <abarth>
but if you use all of foo://example.org/document1/part1 as the origin, that won't be the case

[15:53:00.0000] <Hixie>
right

[15:53:01.0000] <abarth>
so, you want the ability to do something implementation-defined on a per-scheme basis?

[15:53:02.0000] <abarth>
e.g., be able to return whatever you want as the origin?

[15:54:00.0000] <Hixie>
well you have me rapidly wanting to not care about news readers and e-mail clients at this point, but previously, i just wanted something equivalent to the third <li> in the HTML spec

[15:54:01.0000] <rniwa>
jgraham: yeah, I think dynamic optimization can beat optimizing compilers in many cases

[15:54:02.0000] <Hixie>
"If url identifies a resource that is its own trust domain (e.g. it identifies an e-mail on an IMAP server or a post on an NNTP server) then return a globally unique identifier specific to the resource identified by url, so that if this algorithm is invoked again for URLs that identify the same resource, the same identifier will be returned."

[15:54:03.0000] <abarth>
IMHO, we shouldn't worry about these cases

[15:55:00.0000] <Hixie>
ok

[15:55:01.0000] <abarth>
i think there's code in Gecko that does something like that

[15:55:02.0000] <abarth>
but I don't think other UAs have anything like that

[15:55:03.0000] <Hixie>
well yeah, other UAs don't have newsreaders or e-mail clients

[15:56:00.0000] <jgraham>
(cough)

[15:57:00.0000] <Hixie>
jgraham: how do you handle origins in your newsreaders or e-mail clients?

[15:58:00.0000] <jgraham>
No idea :)

[15:58:01.0000] <jgraham>
But I could probably ask if you are interested

[16:05:00.0000] <Hixie>
jgraham: well, i'm stripping the text that made them work like in Firefox from HTML and deferring to [ORIGIN].

[16:05:01.0000] <Hixie>
jgraham: so if that affects you, let abarth know :-)

[16:47:00.0000] <rniwa>
AryehGregor: yt?


2011-10-22
[18:34:00.0000] <annevk>
Is anyone following the URL work?

[18:35:00.0000] <annevk>
It seems to be going completely wrong

[18:35:01.0000] <annevk>
http://trac.tools.ietf.org/wg/iri/trac/ticket/40 e.g. seems to suggest they somehow think the query component think is related to HTML forms...

[18:35:02.0000] <annevk>
s/think/thing/

[18:36:00.0000] <annevk>
I hope abarth will just define all URL processing together with the URL API

[18:36:01.0000] <abarth>
its a dream!

[19:20:00.0000] <annevk>
abarth, pretty good one :)

[19:20:01.0000] <annevk>
Maybe once I'm a bit further with this WebVTT fun I can give the URL work one more chance and submit some comments

[19:23:00.0000] <annevk>
Oh man, Hixie's idea of ranges exposed to CSS in a <textarea> would make things pretty awesome for my WebVTT validator

[19:23:01.0000] <annevk>
I guess the alternative is dealing with the pain that is contenteditable=""

[19:52:00.0000] <annevk>
Hixie, hey you here?

[19:53:00.0000] <annevk>
Hixie, wondering if you are interested in fixing WebVTT settings parsing

[19:54:00.0000] <annevk>
dinnertime I guess

[20:34:00.0000] <annevk>
The cue text tokenizer also seems buggy

[20:34:01.0000] <annevk>
Why would you append 0-9 to the buffer?

[20:34:02.0000] <annevk>
in fact, any character other than one of ampltg will result in the failure

[21:03:00.0000] <annevk>
Hixie, I just realized you were talking about getting the number of bugs down

[21:03:01.0000] <annevk>
Hixie, I hope that does not apply to WebVTT bugs

[21:03:02.0000] <annevk>
Hixie, if it does, sorry

[21:03:03.0000] <annevk>
Hixie, maybe next time just opt for writing perfect text :p

[22:22:00.0000] <annevk>
Hixie, should we set it up so that for bugs such as http://www.w3.org/Bugs/Public/show_bug.cgi?id=14541 one email goes to the WHATWG list so people at least know a bug has been filed?

[22:23:00.0000] <annevk>
Hixie, because currently there's no mailing list that gets such an indication which means it might end up getting ignored

[22:23:01.0000] <divya>
o i c

[22:23:02.0000] <divya>
(wrong window)

[22:25:00.0000] <annevk>
o i c

[22:25:01.0000] <divya>
:P

[23:15:00.0000] <annevk>
Wait JavaScript does still not have "string"[-1] == "g"?!

[23:15:01.0000] <annevk>
What is the fun in writing val[val.length-1]?

[23:16:00.0000] <zewt>
bill by the character

[23:16:01.0000] <divya>
wow someone is discovering javascript i notice :)

[23:17:00.0000] <divya>
SOMEONE

[23:17:01.0000] <MikeSmith>
zewt: I too am faster than native, by the way

[23:17:02.0000] <zewt>
you should slow down, enjoy the scenery

[23:17:03.0000] <divya>
:)))

[23:17:04.0000] <MikeSmith>
heh

[23:18:00.0000] <zewt>
annevk: "string".substr(-1) works

[23:19:00.0000] <divya>
annevk: are u trying to write with python syntax in JS?

[23:19:01.0000] <zewt>
not a question of syntax...

[23:19:02.0000] <annevk>
divya, well I do sometimes forget the braces

[23:19:03.0000] <annevk>
divya, including the parenthesis

[23:19:04.0000] <annevk>
o_O

[23:20:00.0000] <annevk>
but they are caught quickly

[23:20:01.0000] <annevk>
[-1] just returns undefined

[23:20:02.0000] <divya>
hahahah travails of learning a new language.

[23:20:03.0000] <zewt>
uh heh

[23:22:00.0000] <annevk>
I think it's because Python is Dutch and therefore makes more sense

[23:22:01.0000] <annevk>
to me anyway

[23:23:00.0000] <zewt>
python is good at everything except templating :(

[23:27:00.0000] <MikeSmith>
I'm trying to decide if my python skills are worse than my JS skills

[23:27:01.0000] <annevk>
Anyway, I have a working WebVTT cue text parser

[23:28:00.0000] <annevk>
Including serializer it is less than 200 lines of JavaScript

[00:27:00.0000] <annevk>
hober, don't put energy into Robert Leif man

[00:28:00.0000] <annevk>
hober, although you did get him to cite w3schools.com, which is fun

[00:31:00.0000] <annevk>
Is there some kind of common serialization format in use for WebVTT I can use for tests?

[02:07:00.0000] <annevk>
foolip, I filed a bunch of WebVTT bugs, but I did not include <track> in the title

[02:26:00.0000] <annevk>
zcorpan, I posted an update

[02:27:00.0000] <annevk>
zcorpan, need some kind of test suite format

[02:49:00.0000] <zcorpan>
annevk: nice. will check later

[03:22:00.0000] <Philip`>
/me wonders if abarth reads logs

[03:23:00.0000] <Philip`>
abarth: "then return generate a fresh globally unique identifier" has too many verbs

[03:24:00.0000] <MikeSmith>
Philip`: I think abarth intended a compound verb there

[03:25:00.0000] <MikeSmith>
either "then return-generate a fresh globally unique identifier" or "then generate-return a fresh globally unique identifier"

[03:25:01.0000] <MikeSmith>
he's very efficient that way

[03:25:02.0000] <MikeSmith>
Philip`: btw, the canvas test suite should be made to use testharness.js

[03:25:03.0000] <MikeSmith>
maybe somebody could work on that

[03:26:00.0000] <Philip`>
Somebody maybe could indeed

[06:34:00.0000] <Ms2ger>
<!-- Welcome to crazy town. Population: The Web. -->

[06:34:01.0000] <Ms2ger>
Hixie, so you noticed? :)

[06:34:02.0000] <Ms2ger>
+  <!-- Now leaving crazy town. -->

[06:34:03.0000] <Ms2ger>
+

[06:34:04.0000] <Ms2ger>
   <hr>

[06:34:05.0000] <Ms2ger>
   <p>The <dfn title="dom-form-submit"><code>submit()</code></dfn>

[06:34:06.0000] <Ms2ger>
Ha. Ha. Ha.

[11:36:00.0000] <Ms2ger>
MikeSmith, btw, I did some work on making Philip`'s canvas tests use testharness.js, it's in a W3C bug somewhere

[11:36:01.0000] <Ms2ger>
Waiting for Philip`'s review

[12:07:00.0000] <Hixie>
Ms2ger: hey compared to the part i labeled crazy town, form.submit() is nice and obvious. :-P

[12:09:00.0000] <Philip`>
It's crazy suburbs


2011-10-23
[17:02:00.0000] <zewt>
heh, unreadable examples on msdn ... because, as usual, of someone using nonstandard tab stops

[18:41:00.0000] <MikeSmith>
"You are really good master. It’s easy and enjoying to work with you."

[18:41:01.0000] <MikeSmith>
He is indifferent to music of Kraftwerk.

[18:42:00.0000] <annevk>
Well that explains it, Kraftwerk is awesome

[18:54:00.0000] <annevk>
http://quuz.org/webvtt/ now with <title> and <h1>

[19:16:00.0000] <MikeSmith>
I made some personal fashion changes recently

[19:16:01.0000] <MikeSmith>
this is my new look:

[19:16:02.0000] <MikeSmith>
http://www.oneyeartrip.com/2010/04/isawa-onsen.html

[19:16:03.0000] <MikeSmith>
feedback welcom

[19:16:04.0000] <MikeSmith>
oops

[19:17:00.0000] <MikeSmith>
http://2.bp.blogspot.com/_88RoabsTacs/S92ZA4h7NDI/AAAAAAAACZ4/VBy0WeKWj9U/s1600/IMG_2060.JPG

[20:27:00.0000] <jarek>
Hi

[20:27:01.0000] <jarek>
what's the correct way for implementing toggle buttons with HTML5?

[20:27:02.0000] <jarek>
I can't find anything like <button type="toggle">

[20:28:00.0000] <jarek>
should I be doing it the old-fashioned way? (a couple of divs with click events attached to them)

[20:30:00.0000] <jarek>
but this won't work when uses keyboard for navigation

[20:33:00.0000] <jarek>
another idea is to have something like <button data-is-toggled="true">, but I would still need event listeners to to watch and update button state

[20:34:00.0000] <jarek>
s/uses/user uses

[20:43:00.0000] <Hixie>
jarek: <input type=checkbox>

[02:19:00.0000] <annevk>
why is string lastIndexOf not the same as array lastIndexOf

[02:19:01.0000] <annevk>
what insanity is this?

[04:06:00.0000] <MikeSmith>
Ms2ger: so do the canvas test-suite changes to add testharness.js need to be reviewed by anybody other than Philip` ?

[04:06:01.0000] <Ms2ger>
Anyone who's interested, I guess :)

[05:18:00.0000] <annevk>
why does onhashchange not expose old and new hash rather than old and new URL?

[05:28:00.0000] <hsivonen>
hmm. the Reader version of Opera Mobile Labs allows getUserMedia go through without prompting the user

[05:29:00.0000] <hsivonen>
i.e. it turns on the camera without prompting the user

[05:29:01.0000] <hsivonen>
not cool

[05:41:00.0000] <zcorpan>
hsivonen: "The device API does not have a user interface yet. This will be added soon.

[05:41:01.0000] <zcorpan>
These are proof of concept builds, and should be considered experimental and for developer use only."

[05:48:00.0000] <hsivonen>
zcorpan: ok. I reported it as a bug anyway, because I didn't like having the camera turn on without permission

[05:50:00.0000] <hsivonen>
btw, https://www.cs.columbia.edu/~smb/blog//2011-10/2011-10-21.html is interesting as far as the implications of an "always allow" option goes for allowing a given origin access the camera or the microphone

[05:58:00.0000] <zcorpan>
abarth: so does script need crossorigin=""? would it break the web to include an Origin header for script requests?

[07:38:00.0000] <adtykfhyipoh>
Hey, is anyone here? I need help.

[07:39:00.0000] <divya>
ask adtykfhyipoh

[07:40:00.0000] <adtykfhyipoh>
Hey, I am building a javascript application, and I have an if statement, and in the condition, I need to know if one variable equals the value of any item in an array. How can I do this?

[07:40:01.0000] <divya>
array.indexOf(variable)

[07:41:00.0000] <adtykfhyipoh>
that might work I'll try it

[07:48:00.0000] <adtykfhyipoh>
thanks mate it worked

[07:48:01.0000] <divya>
np mate

[08:21:00.0000] <gsnedders>
divya: You need indexOf(foo) >= 0 or !== -1

[08:21:01.0000] <gsnedders>
divya: [1].indexOf(1) === 0

[08:22:00.0000] <divya>
gsnedders: yep, I just wanted to point what f() to use to adty

[08:22:01.0000] <gsnedders>
divya: Kinda unclear from what you said, though

[08:23:00.0000] <divya>
yeah probably :P

[09:10:00.0000] <_bga>
heh but new trend is ~a.indexOf :/

[09:10:01.0000] <divya>
coz that looks like you know what you are doing even if nobody else does

[09:12:00.0000] <_bga>
divya its for waste your brain "tacts", each time you remember that ~-1  == 0 and Bool(0) == false

[09:14:00.0000] <divya>
hah

[09:15:00.0000] <zewt>
bga: i'd smack anyone who tried to put garbage like that in my codebase

[09:15:01.0000] <_bga>
:)

[09:15:02.0000] <zewt>
leave that crap to obfuscated programming competitions; it belongs nowhere else

[09:16:00.0000] <Philip`>
How about "if (1+a.indexOf(b))" ?

[09:17:00.0000] <_bga>
i have some patterns for string lookup

[09:17:01.0000] <zewt>
that'd also incite me to install an "upside the head" device in someone's desk

[09:18:00.0000] <_bga>
https://github.com/bga/jbasis/blob/77683e222909279548a1fdc3e3ee03d4c83d96b4/src/$jb.Url.js

[09:18:01.0000] <_bga>
>>> 0, ~(~a || ~b || ~c)

[09:19:00.0000] <_bga>
+ 1 for lastIndexOf

[09:19:01.0000] <zewt>
__this $$code _$_is $somewhat _unpleasant ___to __$$$read

[09:19:02.0000] <_bga>
:)

[09:19:03.0000] <zewt>
return ~(~s.lastIndexOf('?', s.lastIndexOf('#') >>> 0) || ~s.length) <- yeah sorry this is bad :)

[09:21:00.0000] <_bga>
writing something like if(i < 0) i = s.length is annoing

[09:22:00.0000] <zewt>
write a helper for it

[09:22:01.0000] <Philip`>
return urlSubstringAfterQueryBeforeFragment(s);

[09:22:02.0000] <zewt>
that's what functions are for :)

[09:22:03.0000] <Philip`>
Easy to write *and* to read

[09:23:00.0000] <_bga>
zewt i made it when illed by "perfomance"

[09:25:00.0000] <_bga>
Philip` and you will have *alot* of fns, its not orthogonal

[09:25:01.0000] <_bga>
get intexes and slice is better

[09:25:02.0000] <zewt>
at least there are no yoda conditionals :P

[09:26:00.0000] <Philip`>
/me wonders why JS developers seem to focus so much on micro-optimisations like loop iteration conditions, rather than on profiling and optimising what actually matters

[09:27:00.0000] <_bga>
zewt i use _ prefix for fns to differ map which is hashtable from _map which is Array#_map

[09:27:01.0000] <_bga>
var a = a.map

[09:27:02.0000] <_bga>
what is that?

[09:27:03.0000] <_bga>
fn or data?

[09:28:00.0000] <zewt>
sorry, it's just hard on the eyes (and harder since there are both _functions and __functions)

[09:28:01.0000] <_bga>
__fn is private fn

[09:29:00.0000] <_bga>
zewt may be

[09:29:01.0000] <zewt>
bga: so use a clearer name ("mapping", "addressToUserMap", etc)

[09:30:00.0000] <_bga>
i do ir

[09:30:01.0000] <_bga>
*it

[09:58:00.0000] <gsnedders>
Philip`: Because profilers for JS engines almost uniformly suck.

[11:02:00.0000] <Philip`>
/me wonders why profilers for JS engine almost uniformly suck, given the relatively large amounts of effort put into JS engine performance

[12:55:00.0000] <zewt>
Philip`: most profilers in all categories suck

[13:01:00.0000] <smaug____>
Shark is good. (Apple has managed to do something I like)

[15:25:00.0000] <jgraham>
Probably profiling jitted code is moderately hard

[15:26:00.0000] <jgraham>
At least you need to keep extra information around

[15:33:00.0000] <Philip`>
/me often feels that JIT people talk too much about how their clever dynamic compilation systems can produce code that's as fast as C, and ignore that practical performance optimisation actually depends on a feedback cycle between programmer and compiler, and that C/C++ are good for performance because that feedback cycle is pretty easy to understand

[15:34:00.0000] <Philip`>
(since they have adequate profiling tools and the compiler isn't too clever)

[15:35:00.0000] <Philip`>
I suppose working on profiling tools is less fun than working on clever compilers, though

[15:35:01.0000] <Philip`>
and doesn't help with benchmark results

[15:35:02.0000] <jgraham>
Yeah, that's what I was going to say

[15:36:00.0000] <jgraham>
Although maybe in the future it will be more important to have non-sucky profilers if games are going to take off in browsers

[15:36:01.0000] <Philip`>
That's even harder since you have to worry about GPU performance too :-(

[15:37:00.0000] <jgraham>
Being able to use the profiler to tune an application (or game) to work better in on javascript engine than another seems like a likely vector for things that only work acceptably well in one browser in the future

[15:38:00.0000] <Philip`>
That sounds like an excellent incentive for each browser vendor to produce the best profiling tools, so games are optimised for their browser rather than for their competitors

[15:39:00.0000] <jgraham>
Right, I think it probably will be

[15:39:01.0000] <zewt>
Philip`: well, there are endless cases in low-level languages of people who think they intuitively understand performance without profiling (and don't) ... high-level languages aren't unique there, it just raises the bar of understanding that much further

[15:39:02.0000] <jgraham>
It will also cause people to copy each other's optimisations of course

[15:40:00.0000] <zewt>
in particular since a single function may have differently-optimized versions under the hood for different arguments

[15:40:01.0000] <zewt>
(at least in C++, it's explicit when that's likely to happen--templates)

[15:43:00.0000] <jgraham>
I wonder if anyone published a reasonably up-to-date piece about how to get decent perf. from javascript. Just basic things like "don't change he types of variables"

[15:43:01.0000] <Philip`>
zewt: There will always be people who do it wrong, but at least with C/C++ you can run a compiler and profiler and look at assembly code and get a fair idea of what's going on if you want to, whereas higher-level languages seem to make that pretty much entirely impossible for anybody except the language implementers themselves

[15:44:00.0000] <Philip`>
(e.g. with SpiderMonkey it seems the only way to see what code compiles into is to run in the command-line shell with various environment variables to trigger dumps of the assembly code of the entire script, which isn't very practical for non-trivial applications)

[15:49:00.0000] <Laster>
naive question from a nube. why doesn't editor.html implement fontsize, fontcolor and a lot of other functionality?

[15:55:00.0000] <zewt>
Philip`: browsers should definitely expose more internals to their debuggers (bytecode, jit output, etc); browsers seem to treat developers like babies

[16:02:00.0000] <Philip`>
zewt: Are any other similar languages any better than JS at this?

[16:04:00.0000] <zewt>
you can read back the bytecode of a function in Python (but it doesn't JIT so there's no analogue there, and I'm not sure how documented its bytecode is)

[16:05:00.0000] <zewt>
there's also the dis module, but i havn't looked at it much

[16:07:00.0000] <zewt>
(i wouldn't suggest that anything about this sort of thing should be anything but browser extensions; not limiting optimizations is far more important)


2011-10-24
[03:54:00.0000] <annevk>
zcorpan, hey did you think about a test format?

[03:54:01.0000] <annevk>
it would be great to have something like the HTML stuff

[03:54:02.0000] <annevk>
input, output, and input contains errors

[03:55:00.0000] <annevk>
and I guess we should have some shortcuts for input, so that you e.g. do not need to provide the signature, or cue time information

[03:55:01.0000] <annevk>
(in such a scenario they would just be pre-filled)

[04:03:00.0000] <annevk>
lol

[04:03:01.0000] <annevk>
webrtc fork uses respec

[04:03:02.0000] <smaug____>
so, of the pages which nightly telemetry users have loaded, 2% has had mutation listeners :/

[04:04:00.0000] <annevk>
with the silly <dl> way of defining methods

[04:04:01.0000] <smaug____>
of course it is possible that gmail or some such has mutation listeners

[04:04:02.0000] <smaug____>
and every new message loads a new page or something...

[04:05:00.0000] <annevk>
is a different fragment identifier a new page?

[04:06:00.0000] <smaug____>
in this case? this is not based on urls, but effectively js windows

[04:06:01.0000] <smaug____>
s/js/dom/

[04:07:00.0000] <smaug____>
different pages get a new window

[04:07:01.0000] <smaug____>
(expect in certain cases with about:blank)

[04:07:02.0000] <smaug____>
except

[04:08:00.0000] <annevk>
ah, I think Gmail is pretty much all one window

[04:08:01.0000] <annevk>
oh, or maybe not

[04:08:02.0000] <smaug____>
it is using iframes everywhere

[04:08:03.0000] <annevk>
yeah, forgot about that, ignore me

[04:09:00.0000] <smaug____>
I should probably count usage per domain

[04:09:01.0000] <annevk>
gotta catch a train

[04:09:02.0000] <annevk>
yeah

[04:12:00.0000] <foolip>
zcorpan, do you have any suggestions for what to do about the "separating cues" issue?

[04:16:00.0000] <annevk>
I wonder how wildly different Opera's <track> implementation is compared to mine

[04:30:00.0000] <karlcow>
http://research.microsoft.com/apps/pubs/default.aspx?id=155295

[04:30:01.0000] <karlcow>
Refactoring the Web Interface

[04:30:02.0000] <karlcow>
John R. Douceur, Jon Howell, Bryan Parno, and Michael Walfish

[04:30:03.0000] <karlcow>
24 October 2011

[04:30:04.0000] <karlcow>
http://research.microsoft.com/pubs/155295/SOSP2011Poster.pdf and http://research.microsoft.com/pubs/155295/SOSP2011PosterAbstract.pdf

[04:36:00.0000] <zcorpan>
foolip: i'm thinking either tolerating whitespace between cues or starting a new cue when seeing a timing line

[04:37:00.0000] <smaug____>
karlcow: looks like they want to bring not only one but many proprietary stacks to web

[04:38:00.0000] <karlcow>
yup looks like this

[04:38:01.0000] <zcorpan>
foolip: where timing line is a line containing -->. if you want --> in data, you'd need to escape it

[04:38:02.0000] <karlcow>
or I didn't understand and it also seems like an interop nightmare

[04:39:00.0000] <karlcow>
and also the HTTP layer is placed in a strange place in their diagram.

[04:39:01.0000] <smaug____>
it certainly looks like interop nightmare

[04:39:02.0000] <zcorpan>
foolip: another thing that might be common is to not have two blank lines in "header", so the first cue gets eaten

[04:39:03.0000] <smaug____>
oh, hmm, http is nowhere near network

[04:40:00.0000] <foolip>
zcorpan, I would also prefer to have timing lines always start new cues and require escaping to allow "-->" inside cues

[04:41:00.0000] <karlcow>
this post is a lot more fun http://sebleedelisle.com/2011/09/pixelphones-a-huge-display-made-with-smart-phones/

[04:41:01.0000] <karlcow>
websocket inside

[04:41:02.0000] <smaug____>
people in research centers can propose many silly things. I certainly did at my time :)

[04:41:03.0000] <foolip>
zcorpan, second best would be to strip whitespace when collecting a line, but meh

[04:42:00.0000] <karlcow>
using the light sequences for localizing the phones is genius

[04:46:00.0000] <zcorpan>
foolip: WDYT about cue in header?

[04:46:01.0000] <foolip>
zcorpan, you mean directly following WEBVTT?

[04:46:02.0000] <zcorpan>
yes

[04:47:00.0000] <foolip>
if we make a timing line always start a new cue I don't see why we couldn't make that work as well

[04:47:01.0000] <annevk>
we want this because 1.3% contains an error currently?

[04:47:02.0000] <annevk>
of SRT files, no less...

[04:47:03.0000] <foolip>
however, that particular error you are actually quite likely to notice, since it's the first cue

[04:47:04.0000] <annevk>
the current format seems much easier to read

[04:48:00.0000] <annevk>
and we have a validator of sorts now :)

[04:48:01.0000] <foolip>
annevk, except a validator doesn't complain about cues in cues, right?

[04:48:02.0000] <zcorpan>
annevk: i don't see any reason the error would be less common in VTT

[04:49:00.0000] <annevk>
foolip, it could warn

[04:49:01.0000] <foolip>
annevk, but it's valid per the syntax right now

[04:49:02.0000] <zcorpan>
annevk: "easy to read" is irrelevant since we're not suggesting changing what valid files look like

[04:50:00.0000] <annevk>
foolip, yeah making --> in cues invalid might be a good idea

[04:51:00.0000] <zcorpan>
making it invalid and start a new cue might be an even better idea :)

[04:51:01.0000] <zcorpan>
since it's what the author intended and what the user wants

[04:51:02.0000] <zcorpan>
and what SRT does

[04:52:00.0000] <annevk>
euh okay...

[04:55:00.0000] <annevk>
SRT also does , and not .

[04:55:01.0000] <annevk>
still not sure why we don't do SRT if that's what everyone wants

[04:55:02.0000] <annevk>
can't really both argue we need a new format but UAs are also going to support SRT

[04:58:00.0000] <zcorpan>
SRT parsers support both , and .

[04:59:00.0000] <zcorpan>
personally i think we should have specified and extended SRT, but that's not where we're at

[05:00:00.0000] <zcorpan>
anyway, i'm not doing this to end up with SRT. i'm doing this to get error handling in VTT better based on what errors people do in SRT

[05:01:00.0000] <zcorpan>
e.g. it turned out that errors in timestamps was pretty rare, so i'm not proposing to make that more lax after researching that

[05:13:00.0000] <bga_>
http://kizu.github.com/Castle-of-Sinister-Sorcerers/

[05:34:00.0000] <MikeSmith>
anybody know when the content model for the <dt> element was changed to allow flow content?

[05:34:01.0000] <MikeSmith>
(instead of just phrasing content)

[05:36:00.0000] <MikeSmith>
seems it was some time after May 25

[05:40:00.0000] <zcorpan>
http://html5.org/tools/web-apps-tracker?from=6617&to=6618

[05:43:00.0000] <zcorpan>
hmm. <b\n> gets dropped but <b \n> is parsed

[05:44:00.0000] <annevk>
yeah white space rules in the parser are funky

[05:45:00.0000] <annevk>
I filed a bug on that

[05:45:01.0000] <annevk>
as they do not handle FF either

[05:45:02.0000] <annevk>
while the timing/setting algorithm does

[05:47:00.0000] <zcorpan>
yeah

[05:58:00.0000] <MikeSmith>
zcorpan: thanks

[06:47:00.0000] <zcorpan>
MikeSmith: why was http://www.w3.org/Bugs/Public/show_bug.cgi?id=14552 not emailed to public-html?

[06:48:00.0000] <MikeSmith>
zcorpan: maybe because of teh component

[06:48:01.0000] <MikeSmith>
checking now

[06:49:00.0000] <MikeSmith>
yeah

[06:49:01.0000] <MikeSmith>
I have "other Hixie drafts" component set up to don't generate notifications to public-html

[06:50:00.0000] <MikeSmith>
but I can change that if you wan

[06:51:00.0000] <zcorpan>
foolip: ^

[07:07:00.0000] <foolip>
MikeSmith (when back), was this changed recently? I've filed loads of bugs and can't remember this happening before

[08:05:00.0000] <annevk>
foolip, <track> is in W3C HTML, WebVTT is not

[08:05:01.0000] <annevk>
foolip, I filed quite a few bugs on WebVTT nobody got emailed about either :(

[08:10:00.0000] <foolip>
annevk, how can I find them?

[08:11:00.0000] <annevk>
14536 - 14543

[08:11:01.0000] <annevk>
and 14547

[08:11:02.0000] <foolip>
will add <track> to all of them

[08:11:03.0000] <annevk>
thanks!

[08:12:00.0000] <rillian_>
indeed!

[08:12:01.0000] <annevk>
I will add <track> in the future

[08:12:02.0000] <rillian_>
thanks annevk, I didn't see them either

[08:15:00.0000] <foolip>
annevk, check http://wiki.whatwg.org/wiki/WebVTT to see if they're all listed

[08:15:01.0000] <foolip>
will mark the non-editorial ones as blocker as well

[08:25:00.0000] <foolip>
annevk, http://www.w3.org/Bugs/Public/show_bug.cgi?id=14547 is not very clear

[08:26:00.0000] <foolip>
two issues in one

[08:26:01.0000] <foolip>
oops, was I mistaken to mark http://www.w3.org/Bugs/Public/show_bug.cgi?id=14551 as <track>?

[08:28:00.0000] <zcorpan>
you didn't mark it as <track> :)

[08:28:01.0000] <foolip>
zcorpan, did you?

[08:28:02.0000] <foolip>
oh, I'm not even CC'd, it must have been someone else

[08:29:00.0000] <zcorpan>
i filed it

[08:29:01.0000] <annevk>
foolip, tried to clarify it, did not bother with splitting the issue for now...

[08:31:00.0000] <AryehGregor>
jgraham, 1) If we're supposed to still use testharnessreport.js, why does the "Basic usage" section in testharness.js docs at the top of the file not mention it?  It just says to add <script src="http://w3c-test.org/resources/testharness.js"></script>

[08:31:01.0000] <AryehGregor>
And 2) why is using an absolute URL wrong?  Using a relative URL like that will break any checkout of the tests other than w3c-test.org.  Users of other checkouts might not be able to put a resources directory in the web root.

[08:32:00.0000] <AryehGregor>
Or even if they can, why should they have to?

[08:34:00.0000] <AryehGregor>
I guess using a relative URL makes sense if you want to test what effect changes to the harness have on webapps tests, so you don't have to manually change the <script> URLs.

[08:34:01.0000] <AryehGregor>
(which is what I was doing)

[08:34:02.0000] <AryehGregor>
Anyway, if we want people to use relative URLs, testharness.js should say that.  The way it says it should be used is with an absolute URL.

[08:34:03.0000] <AryehGregor>
annevk, ^^

[08:37:00.0000] <jgraham>
AryehGregor: That example should prbably be changed

[08:37:01.0000] <AryehGregor>
jgraham, please do.  It's what I was looking out to figure out how the harness should be used.

[08:38:00.0000] <jgraham>
Using absolute urls is wrong because it makes it harder for people to import the tests into their local testing systems

[08:39:00.0000] <timeless>
i'm not sure that's really true fwiw

[08:39:01.0000] <jgraham>
Using resources on external servers is horrible badness so one would need to muck about with DNS or something

[08:39:02.0000] <timeless>
mozilla's testharness actually redirects dns lookups iirc

[08:39:03.0000] <AryehGregor>
Or you could just do a search-and-replace on all the URLs as part of the process of checking them out.

[08:39:04.0000] <AryehGregor>
That would work too.

[08:39:05.0000] <timeless>
search and replace otoh tends to lead to merge hell

[08:39:06.0000] <jgraham>
AryehGregor: Non-trivial patches are always a source of pain

[08:39:07.0000] <AryehGregor>
You can search-and-replace it back before doing any kind of merge.

[08:40:00.0000] <zewt>
D:

[08:40:01.0000] <jgraham>
AryehGregor: GLWT if the person who made the original changes isn't the same person doing the update

[08:40:02.0000] <jgraham>
timeless: Yes, I think Mozilla do that. We typically don't (but could of course)

[08:41:00.0000] <AryehGregor>
If we're going to do it this way, then 1) don't assume people have control of the web root, or want to add a resources directory there -- make it relative to the current directory, not the root.  2) Post clear instructions somewhere on how you're supposed to clone the webapps tests, because as it stands a simple clone will be completely broken.

[08:41:01.0000] <jgraham>
In any case using relative URLs isn't bad for browser vendors, but absolue urls can be

[08:41:02.0000] <timeless>
fwiw, i'm not really sure where i sit on this

[08:41:03.0000] <timeless>
i have a spec i'm working on which has the absolute url in it

[08:41:04.0000] <AryehGregor>
Also, the dvcs.w3.org versions should really work if possible, so that you can easily look at old versions of the tests.

[08:42:00.0000] <timeless>
and i kind of wanted to be able to have a local instance w/o web access and w/o having to install a test harness

[08:42:01.0000] <jgraham>
AryehGregor: I think for any non-trivial use you will have to install locally

[08:42:02.0000] <AryehGregor>
Plus because it's confusing that they don't work.

[08:42:03.0000] <AryehGregor>
jgraham, yes, if only so that your tests don't suddenly behave differently one day because the remote copy changed . . .

[08:47:00.0000] <AryehGregor>
jgraham, is there a place to file bugs on the harness?

[08:48:00.0000] <jgraham>
AryehGregor: I think bugzilla has a componen

[08:48:01.0000] <jgraham>
t

[08:48:02.0000] <jgraham>
Dunno if I get email though

[08:48:03.0000] <jgraham>
I hink I might

[08:49:00.0000] <jgraham>
+t

[08:49:01.0000] <jgraham>
Anyway fixed the documentation

[08:50:00.0000] <jgraham>
I think you could fix the webapps wiki to tell people how to set up a local copy of the testsuite

[08:50:01.0000] <jgraham>
Really testharness.js should be in its own repository

[08:50:02.0000] <jgraham>
Or one called "resources"

[08:55:00.0000] <AryehGregor>
Is there any way to set up hg so that it automatically clones a second repo when you clone the first?

[08:55:01.0000] <AryehGregor>
So cloning the tests also clones the harness?

[08:55:02.0000] <AryehGregor>
Like SVN deps or git submodules or whatever?

[08:55:03.0000] <timeless>
hg subrepo

[08:55:04.0000] <AryehGregor>
/me hasn't used either of those features much, so might not understand how they work

[08:56:00.0000] <timeless>
basically you create a repo and add a .hgsub file which lists the two other repos you actually want

[08:56:01.0000] <AryehGregor>
So it would still be possible to clone the subrepo separately even though that might make no sense, I guess?

[08:57:00.0000] <timeless>
yes

[08:57:01.0000] <timeless>
http://stackoverflow.com/questions/5621670/hg-sub-repository-dependencies

[08:57:02.0000] <timeless>
is probably worth reading (i haven't)

[08:57:03.0000] <timeless>
you could skip the mostly empty repo if you like and just have the main content one also have the subrepo directives

[08:57:04.0000] <timeless>
but if someone for instance has 5 wgs

[08:57:05.0000] <timeless>
or specs

[08:57:06.0000] <AryehGregor>
/me is catching up on ten days of e-mail

[08:58:00.0000] <timeless>
and each spec has a sub dependency for the same third party repo

[08:58:01.0000] <timeless>
(call it "testharness")

[08:58:02.0000] <timeless>
then making them have 5 copies as subrepos is cruel

[08:58:03.0000] <timeless>
when they could instead have 5 repos as siblings to their one copy of that testharness repo

[08:58:04.0000] <timeless>
make sense?

[08:59:00.0000] <timeless>
http://mercurial.selenic.com/wiki/Subrepository is the official documentation

[09:16:00.0000] <_bga>
oh new js min trend, if(a != 15) -> if(a^15)

[09:19:00.0000] <nlogax>
too bad they give different results

[09:20:00.0000] <_bga>
for a = 15.3 - yes

[09:20:01.0000] <nlogax>
4294967311 ^ 15, 4294967311 != 15, oops

[09:20:02.0000] <_bga>
too

[09:21:00.0000] <nlogax>
but i'm sure it will take off anyway :D

[09:29:00.0000] <_bga>
hm. if(a-15) !

[09:31:00.0000] <zewt>
a somewhat more effective way of making code smaller: deflate.

[09:31:01.0000] <Philip`>
An even more effective way: write less code

[09:32:00.0000] <_bga>
i know but for guys from 140bytes its sport

[09:39:00.0000] <dglazkov>
good morning, Whatwg!

[09:41:00.0000] <divya>
காலை வனக்கம் dglazkov!

[09:41:01.0000] <dglazkov>
that looks curly

[09:42:00.0000] <_bga>
i need google translate plugin for IRC client

[09:43:00.0000] <nlogax>
http://scripts.irssi.org/scripts/gtrans.pl

[09:45:00.0000] <_bga>
thanks :)

[09:52:00.0000] <annevk>
AryehGregor, I didn't know about the bogus documentation (does it also say to not have testharnessreport.js?), hopefully it's not too hard to revert

[09:52:01.0000] <hsivonen>
Gnome Terminal fails with Tamil :-(

[10:07:00.0000] <dglazkov>
divya: what language is it?

[10:08:00.0000] <divya>
dglazkov: tamil :)

[10:08:01.0000] <divya>
CURLYY

[10:08:02.0000] <divya>
hahaha it is curly

[10:09:00.0000] <dglazkov>
cool. India is a crazy place. So many languages. So many people. So many foods to try

[10:09:01.0000] <divya>
http://translate.google.com/#auto|en|காலை%20வனக்கம்

[10:09:02.0000] <divya>
almost there I meant good morning. :P

[10:09:03.0000] <divya>
it is very crazy

[10:09:04.0000] <divya>
and I am trying all the delish foood now.

[10:12:00.0000] <dglazkov>
has anyone figured out why some countries are really big on delicious food and some are like, "Potatoes!!!"

[10:13:00.0000] <divya>
hahahah

[10:13:01.0000] <divya>
good point.

[10:14:00.0000] <divya>
ya funny thing chillies were not native to India but indians are big on spice.

[10:14:01.0000] <divya>
err i mean heat

[10:31:00.0000] <jgraham>
dglazkov: Climate, mostly, I think

[10:47:00.0000] <rabbi1>
how to make a website I view float left ?

[11:29:00.0000] <AryehGregor>
annevk, yes, it didn't mention testharnessreport.js anymore.  jgraham fixed it: http://dvcs.w3.org/hg/html/rev/bcf81d8686ab

[12:35:00.0000] <AryehGregor>
Are init*Event() methods deprecated in new APIs?  If so, what's the correct replacement, event constructors?

[12:35:01.0000] <Hixie>
yes and yes

[12:35:02.0000] <AryehGregor>
k.

[12:35:03.0000] <Hixie>
not just deprecated, they shouldn't be added at all

[12:35:04.0000] <AryehGregor>
That's what I mean.

[12:37:00.0000] <AryehGregor>
Where's an example of event constructors in a spec that I can point to?

[12:37:01.0000] <Hixie>
all of HTML's events are done that way

[12:37:02.0000] <AryehGregor>
Okay.

[12:37:03.0000] <Hixie>
search for ": Event {"

[12:43:00.0000] <heycam>
Hixie, you didn't remove the existing init* methods though did you?

[12:43:01.0000] <Hixie>
yes

[12:44:00.0000] <Hixie>
they are gone

[12:44:01.0000] <heycam>
even for interfaces that have been deployed for a while?

[12:44:02.0000] <Hixie>
none of the events defined in the html spec are particularly old

[12:44:03.0000] <Hixie>
none of the event interfaces, i should say

[12:44:04.0000] <heycam>
ah, ok

[12:53:00.0000] <AryehGregor>
Hixie, is the "resolve a URL" algorithm in the spec correct/stable?

[12:53:01.0000] <AryehGregor>
I seem to recall it wandered around a bit.

[12:59:00.0000] <AryehGregor>
/me determines it's way too complicated to incorporate into reflection tests anyway, bleh

[13:49:00.0000] <TabAtkins>
Hm, it appears that all of my windows have lost their decorations.  Time to reboot, I guess.

[13:50:00.0000] <bga_>
http://mobile.twitter.com/wendyg/status/128554733714669568

[13:50:01.0000] <paul_irish>
"R.I.P. John McCarthy, father of AI, inventor of Lisp, suddenly at home last night. Pls RT."

[13:56:00.0000] <AryehGregor>
jgraham, what should we do when doing assert_throws() with new exception types, like INVALID_NODE_TYPE_ERR?

[13:57:00.0000] <AryehGregor>
Oh, wait, never mind.

[13:57:01.0000] <AryehGregor>
It was a typo on my part.

[13:58:00.0000] <AryehGregor>
I mean, the current testharness.js still doesn't match the spec, but that can be fixed.

[15:00:00.0000] <rniwa>
AryehGregor: yt?

[15:03:00.0000] <zewt>
chrome accepts xhr.responseType = "blob" but xhr.response comes back as null? :(

[15:03:01.0000] <zewt>
(maybe I'm doing something wrong, but if they don't support it yet, it shouldn't accept "blob" in the first place)

[15:04:00.0000] <AryehGregor>
rniwa, yep.

[15:04:01.0000] <AryehGregor>
(not for long, though)

[15:05:00.0000] <AryehGregor>
(around half an hour)

[15:06:00.0000] <rniwa>
AryehGregor: k

[15:06:01.0000] <rniwa>
AryehGregor: thanks for responding to my emails :)

[15:06:02.0000] <AryehGregor>
rniwa, I'll write some more tomorrow.

[15:06:03.0000] <rniwa>
AryehGregor: I totally understand the delays and all that jazz so take your time :)

[15:06:04.0000] <rniwa>
AryehGregor: especially given that you're no longer compensated for your work

[15:06:05.0000] <AryehGregor>
rniwa, actually, I am.

[15:06:06.0000] <rniwa>
oh good!

[15:06:07.0000] <AryehGregor>
If I weren't, I wouldn't be doing it.  :)

[15:06:08.0000] <rniwa>
glad to hear that

[15:06:09.0000] <AryehGregor>
(but I expect to continue to be compensated by someone)

[15:07:00.0000] <rniwa>
okay, I feel less guilty to delegate more work to you then :P

[15:07:01.0000] <rniwa>
AryehGregor: anyway, the immediate concern for me is whether my spec should define what undo/redo events do or not

[15:08:00.0000] <AryehGregor>
rniwa, it would make sense.

[15:08:01.0000] <rniwa>
ok

[15:08:02.0000] <rniwa>
AryehGregor: the biggest problem I have with how selection is restored on undo/redo

[15:09:00.0000] <rniwa>
AryehGregor: also, there are many selection behaviors that can't be cross-plaform

[15:09:01.0000] <rniwa>
e.g. extending between word boundaries on Windows and Mac use different conventions to include/exclude trailing whitespace

[15:09:02.0000] <rniwa>
so those things probably need to be investigated

[15:10:00.0000] <AryehGregor>
Yes.

[15:10:01.0000] <rniwa>
though I don't think it'll affect undo/redo that much

[15:10:02.0000] <rniwa>
except the one case I pointed out which is whether or not the deleted content should be selected after undo

[15:52:00.0000] <Hixie>
AryehGregor: any particular aspect of it?

[16:10:00.0000] <rniwa>
AryehGregor: btw, we might want to consider supporting contenteditable=plaintext

[16:10:01.0000] <rniwa>
AryehGregor: it seems like websites like facebook, google+, code editors, etc... are working around the issue

[16:10:02.0000] <rniwa>
by emulating contenteditable

[16:11:00.0000] <rniwa>
but it'll be much better if UA just provided a way to enable plain text editing

[16:20:00.0000] <Hixie>
hm, i wonder how the existence of at least one vendor having extended TTF to support colour will affect svg fonts

[16:21:00.0000] <heycam>
Hixie, pointer?

[16:21:01.0000] <heycam>
Hixie, I'm hoping to work further on the SVG glyphs within opentype proposal

[16:21:02.0000] <Hixie>
OS X Lion has a colour font for emoji

[16:22:00.0000] <heycam>
Hixie, they're bitmaps in the font

[16:22:01.0000] <heycam>
(afaik)

[16:22:02.0000] <Hixie>
must be pretty huge bitmaps, they scale rather well

[16:22:03.0000] <zewt>
do they scale well downwards? bitmaps tend to do poorly at that

[16:22:04.0000] <heycam>
/me should try and get lion at some point

[16:22:05.0000] <Hixie>
they seemed to work well for me at small and large sizes

[16:24:00.0000] <heycam>
althought what I had read about this "sbix" table was for the iPhone emoji font

[16:24:01.0000] <heycam>
so it might be that the Lion one is different

[16:29:00.0000] <Hixie>
the iphone one is definitely bitmaps

[16:29:01.0000] <Hixie>
i wonder how big the bitmaps are if it is bitmaps

[16:29:02.0000] <Hixie>
i'll have to play with it when i get back home to my lion box

[16:33:00.0000] <AryehGregor>
rniwa, could you file a bug on that?  I thought I had one, but it seems not.

[16:33:01.0000] <rniwa>
AryehGregor: oh w3c?

[16:33:02.0000] <rniwa>
s/oh/on/

[16:33:03.0000] <AryehGregor>
rniwa, yeah.  There's a link in the spec, at the top: http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html

[16:34:00.0000] <rniwa>
AryehGregor: ah nice

[16:34:01.0000] <rniwa>
AryehGregor: I should really move my spec to W3C as well

[16:34:02.0000] <AryehGregor>
Hixie, I was thinking of whether it was worth it to implement it in JS for my reflection tests, but concluded it wasn't anyway, it'd be much easier to just compute expected values for tests by hand.

[16:36:00.0000] <Hixie>
unless you're playing with some quite dodgy URLs, I doubt any future spec changes will affect you

[16:36:01.0000] <rniwa>
AryehGregor: filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=14554

[16:36:02.0000] <Hixie>
but that seems like a reaonable conclusion


2011-10-25
[17:11:00.0000] <Hixie>
heycam: ToUInt32(-1) == 2**32-1?

[17:11:01.0000] <Hixie>
right?

[17:11:02.0000] <bga_>
yes

[17:11:03.0000] <heycam>
Hixie, yep\

[17:11:04.0000] <Hixie>
k

[18:07:00.0000] <roc>
I need to add an API to extract a MediaStream from an HTML media element

[18:08:00.0000] <roc>
I have to decide whether the stream should represent "whatever's currently playing in the media element" or "just the current resource, until it ends"

[18:09:00.0000] <roc>
in the latter case, loading a new resource or restarting playback after "ended" would start a new stream

[18:09:01.0000] <roc>
Hixie: any opinion?

[18:09:02.0000] <Hixie>
hmm

[18:09:03.0000] <Hixie>
what's the use case?

[18:09:04.0000] <Hixie>
pushing to a peer / WebAudio processing?

[18:09:05.0000] <Hixie>
or saving the resource to disk?

[18:09:06.0000] <roc>
those are all use-cases

[18:10:00.0000] <Hixie>
displaying it in a monitor <video>?

[18:10:01.0000] <roc>
the latter is less interesting I think

[18:10:02.0000] <Hixie>
if the use case is to take whatever the user is currently watching and essentially fork it for use elsewhere, i'd go with having a "live" copy that just streams whatever is being rendered

[18:10:03.0000] <roc>
my main use cases are audio/video playback with mixing and processing; stream it out to a peer is a secondary use-case

[18:10:04.0000] <Hixie>
so e.g. it would start displaying a static image if the media element was paused, etc

[18:11:00.0000] <Hixie>
though that would act really weird if you then could pause and rewind it

[18:11:01.0000] <roc>
the main problem with the "whatever's currently playing" approach is that it means the stream can end, and then start producing data again later

[18:11:02.0000] <roc>
the RTC people don't like that

[18:11:03.0000] <Hixie>
why would it end?

[18:12:00.0000] <roc>
if you treat the "ended" state of the media element as ending the stream

[18:12:01.0000] <roc>
which would be intuitively appealing, and useful as well

[18:13:00.0000] <Hixie>
if you're just outputting what the media element is playing, i don't think you'd do that

[18:14:00.0000] <Hixie>
"ended" just means that the current playback position is at the end

[18:14:01.0000] <Hixie>
doesn't mean that there won't be more later

[18:14:02.0000] <roc>
then we'd need a different API to let authors load a media resource and get a MediaStream for it that ends when the resource ends

[18:15:00.0000] <Hixie>
well, i could certainly see a use case for "get a mediastream for a resource", but it wouldn't "end", it would just represent the (possibly finite) resource, right?

[18:15:01.0000] <roc>
we could have both APIs on the media element, but that might be confusing

[18:16:00.0000] <Hixie>
i guess it would "end" when the whole resource was obtained

[18:16:01.0000] <Hixie>
which might be immediately if the resource is cached

[18:16:02.0000] <roc>
MediaStreams end when they will no longer produce any new data

[18:17:00.0000] <Hixie>
right

[18:17:01.0000] <roc>
the MediaStream for a resource ends when we've finished playing it back

[18:17:02.0000] <Hixie>
so a MediaStream of a finite resource that happens to be already cached would end immediately after providing all the data to whatever consumer exists

[18:17:03.0000] <roc>
MediaStreams play back in real time, they can't instantly deliver all their data to some consumer

[18:18:00.0000] <Hixie>
oh

[18:18:01.0000] <roc>
at least, the way I understand it

[18:18:02.0000] <Hixie>
well then it doesn't make much sense to get one for a static resource

[18:18:03.0000] <Hixie>
surely

[18:18:04.0000] <roc>
sure it does

[18:18:05.0000] <Hixie>
what if the user wants to fast-forward?

[18:19:00.0000] <Hixie>
it'd be really weird to tell the user that he can pause, rewind, etc, but he can't fast-forward ahead of where the mediastream happens to have reached

[18:19:01.0000] <roc>
you can't fast-forward a MediaStream

[18:19:02.0000] <roc>
you can pause, but not rewind

[18:19:03.0000] <Hixie>
especially if the user just gave you the File in question

[18:20:00.0000] <roc>
if the user just gave you a File then you can make a BlobURL and just play that

[18:20:01.0000] <roc>
MediaStreams need not be involved

[18:20:02.0000] <roc>
and then you can do everything

[18:21:00.0000] <roc>
defining a media processing graph where you can control the playback rate of individual streams gets very problematic

[18:21:01.0000] <Hixie>
well to answer your original question, i think if mediastream represents live data and only live data, and you create one from an HTMLMediaElement, it should represent whatever frame/audio is currently playing

[18:21:02.0000] <Hixie>
and it shouldn't ever "end"

[18:22:00.0000] <roc>
(you end up being able to consume a single stream at different rates, and therefore at different time offsets, which is not really implementable)

[18:22:01.0000] <roc>
ok

[18:23:00.0000] <roc>
then we'll need a separate API to create a MediaStream for a resource that ends when the resource playback ends

[18:23:01.0000] <roc>
any suggestions on where that should lvie?

[18:23:02.0000] <Hixie>
what's the use case for that one?

[18:23:03.0000] <roc>
because if it doesn't live on the media element, then we have to duplicate all the source selection logic and probably more, which would really suck

[18:24:00.0000] <Hixie>
why wouldn't you just create an HTMLMediaElement that the user can't mess with, and use that to feed the MediaStream?

[18:24:01.0000] <roc>
I can do that I guess

[18:24:02.0000] <roc>
then I have to add an API somewhere to forcibly end the stream

[18:25:00.0000] <Hixie>
MediaStream.end()

[18:25:01.0000] <roc>
people want to add features that trigger when streams end

[18:25:02.0000] <roc>
OK

[18:25:03.0000] <Hixie>
if it's the kind of feature where precise timing matters, i guess you could just create a MediaStream from a fixed URL, and screw the source selection stuff

[18:26:00.0000] <roc>
precise timing is not really an issue

[18:26:01.0000] <Hixie>
if someone needs to pick a source, they can create a <video> and have it do the source selection and then use the result from that

[18:26:02.0000] <roc>
that's a bit ugly

[18:26:03.0000] <Hixie>
not the most efficient, certainly

[18:26:04.0000] <Hixie>
what kind of thing are we triggering on end?

[18:27:00.0000] <TabAtkins>
Hmm.  <http://jsfiddle.net/leaverou/e77P2/> shows a style element being disabled, and then it gets automatically reenabled when you set .textContent on it.  Is that supposed to happen?

[18:27:01.0000] <roc>
disconnecting the stream from downstream mixers, for example

[18:27:02.0000] <Hixie>
roc: oh if it's just cleanup then yeah, i'd go with an explicit .end().

[18:27:03.0000] <Hixie>
ok i gotta go, bbl

[18:27:04.0000] <roc>
ta

[20:28:00.0000] <jarek>
what is the more efficient way to convert DOM tree into string (with all HTML tags stripped)?

[20:28:01.0000] <jarek>
I have created a new range that wraps the whole tree, then I do:

[20:29:00.0000] <jarek>
myRange.toString()

[20:29:01.0000] <jarek>
but it strips all new lines

[20:30:00.0000] <annevk>
that sounds like a bug...

[20:31:00.0000] <annevk>
only Selection should do that

[20:31:01.0000] <jarek>
http://stackoverflow.com/questions/1146730/problem-detecting-newlines-in-javascript-range-object

[20:32:00.0000] <jarek>
the poster says this behavior could be reproduced on all major browsers

[20:32:01.0000] <jarek>
(I have checked only Chrome)

[20:33:00.0000] <jarek>
no, wait... he is using getSelection() method

[20:34:00.0000] <annevk>
hmm, I thought only Selection.toString() was affected by this

[20:34:01.0000] <annevk>
but maybe it normalizes its Ranges somehow, that sound weird

[20:34:02.0000] <annevk>
AryehGregor would prolly know

[20:35:00.0000] <jarek>
annevk: the specification does not say anything about how new lines should be handled

[20:35:01.0000] <jarek>
I would expect them to be preserved

[20:35:02.0000] <Hixie>
jarek: element.textContent

[20:37:00.0000] <jarek>
Hixie: thanks, exactly what I needed

[21:26:00.0000] <annevk>
Hixie, is the whitespace thing clear now?

[21:26:01.0000] <annevk>
Hixie, note that cue text tokenizing uses a different notion of whitespace (there's a bug on that too)

[21:35:00.0000] <annevk>
paul_irish_, querySelectorAll is not discussed on a WHATWG list, it's discussed on public-webapps

[22:05:00.0000] <Hixie>
annevk: that part of the parser can never hit a newline, because it is parsing a string that was created by collecting characters that aren't newlines

[22:05:01.0000] <annevk>
except for FF

[22:06:00.0000] <annevk>
there's 5 white space characters and you only work with 4 of them

[22:06:01.0000] <Hixie>
oh right

[22:06:02.0000] <Hixie>
you confused me with your talk of newlines

[22:06:03.0000] <annevk>
I think that was sylvia

[22:07:00.0000] <annevk>
nm

[22:07:01.0000] <Hixie>
aah, indeed

[22:07:02.0000] <Hixie>
sorry about that

[22:07:03.0000] <Hixie>
hmmm

[22:08:00.0000] <Hixie>
looking at this i think it would just be confusing to list FF as an allowed character

[22:08:01.0000] <Hixie>
i think it's the right thing to do to be consistent in the parsing, but not much point allowing it

[22:08:02.0000] <Hixie>
any opinions?

[22:08:03.0000] <annevk>
that works for me

[22:09:00.0000] <annevk>
are you willing to annotate the parser section at some point btw with things that are conformance errors?

[22:09:01.0000] <annevk>
that'd be so much more useful

[22:09:02.0000] <Hixie>
i saw the bug about it

[22:09:03.0000] <Hixie>
i dunno

[22:09:04.0000] <Hixie>
is it really worth it?

[22:09:05.0000] <Hixie>
for html it made sense because the parsing is so messed up

[22:09:06.0000] <annevk>
for http://quuz.org/webvtt/ yes

[22:09:07.0000] <Hixie>
that you really need to implement it to do conformance checking

[22:09:08.0000] <Hixie>
but webvtt is so simple in comparison...

[22:10:00.0000] <annevk>
still you need to figure out the differences which is kind of awkard

[22:10:01.0000] <Hixie>
yeah

[22:10:02.0000] <annevk>
I can imagine browsers also want to say things in their error console

[22:10:03.0000] <annevk>
the syntax section is useful for authors I guess

[22:10:04.0000] <annevk>
but the parser section is used by everyone else I'd imagine

[22:10:05.0000] <Hixie>
it's kind of a pain to add though

[22:11:00.0000] <Hixie>
i would imagine most syntax checkers would just be implemented as regexp or bnf-like things

[22:11:01.0000] <Hixie>
you wouldn't want to write a parser, surely

[22:11:02.0000] <annevk>
I wrote a parser to give better error messages

[22:11:03.0000] <annevk>
I could at some point also highlight the errors in the input stream this way

[22:12:00.0000] <annevk>
and you can report multiple errors

[22:12:01.0000] <annevk>
not just the first instance

[22:13:00.0000] <Hixie>
i dunno, just doesn't seem that hard to find the errors even if you do the parser by hand

[22:13:01.0000] <Hixie>
whereas updating the spec to list all the places will mean bugs in the spec all over the place, which confuses people, makes the parser look more complicated than necessary...

[22:14:00.0000] <Hixie>
i don't think i would have done it for html were it not for the way html is just ridiculously complicated to parse

[22:17:00.0000] <annevk>
okay that is fair I guess and it is not too hard, just might miss a lot of things

[22:17:01.0000] <annevk>
and if you want to simplify the parser, pre-process CRLF like you do with zero bytes

[22:18:00.0000] <Hixie>
yeah, i should do something like that

[22:18:01.0000] <Hixie>
foolip suggested it already once

[22:18:02.0000] <annevk>
I also wanted to say that you yourself once said that writing a good validator requires custom code and cannot be done by schema. Even if you're no longer convinced of that I very much think it's true

[22:18:03.0000] <Hixie>
for writing a good validator for HTML that is certainly true

[22:18:04.0000] <Hixie>
it's not true for everything

[22:19:00.0000] <Hixie>
if the language is sane and regular, that's what regular languages are for :-)

[22:19:01.0000] <Hixie>
it rarely works well for XML languages because it is so trivially easy to make an XML language too complicated to sanely describe in a schema

[22:19:02.0000] <annevk>
WebVTT is not that regular, it's a lot of different syntaxes compounded :)

[22:20:00.0000] <Hixie>
regular in this sense http://en.wikipedia.org/wiki/Regular_language

[22:20:01.0000] <Hixie>
though i've no idea what "it is the preimage of a subset of a finite monoid under a homomorphism from the free monoid on its alphabet" means

[22:21:00.0000] <annevk>
"it can be defined in monadic second-order logic" makes total sense

[22:21:01.0000] <Hixie>
man the math and theoretical CS parts of wikipedia are so opaque

[22:21:02.0000] <Hixie>
anyway

[22:21:03.0000] <Hixie>
i didn't just mean "simple" :-)

[22:22:00.0000] <annevk>
fair enough

[22:22:01.0000] <Hixie>
validating the cue text part probably wouldn't be sane with regexp-like tech

[22:23:00.0000] <erlehmann>
nothing is sane with regexes

[22:23:01.0000] <annevk>
I guess once I've fixed some more of the bugs my validator, people can use that to write new validators if they desire

[22:24:00.0000] <annevk>
or at least look up the error conditions

[22:28:00.0000] <erlehmann>
Ḫ̣̩e̞̺ ̮̣w͎̬̰h̼̜͉̹̳͉͙͚o̮̬̜̟̞ ͙̻W̩̮̪̝a̖̩̣͍̠̜̯̮̺i̱͇̼̗t͎͇̘͖̼͖͈͕ͅs̹̲͎̝̳ ͎̬͔B̟͎̯͔̮͕̰͉ͅe̞̦̭̗͎̩͎̯h͙̳͍̖͚̳i͈̝͔ṋ̭̜d̰͉͇̳̖̩̻̞ ͔̳̝̰̭͍ͅT̳̰̦̺̩̜̳̖h͎̩̜̞̬̬̻̖e̪͕͇̻̺̱ ̘R͕̯̮̩̺e͇̺g̱ẹ̖x͓͇.̟

[22:28:01.0000] <erlehmann>
ZALGO!

[22:28:02.0000] <Hixie>
oh dear

[22:40:00.0000] <Hixie>
any opinions on http://www.w3.org/Bugs/Public/show_bug.cgi?id=14101 ? (queuing a task to fire an event on <details> when open="" is added or removed)

[23:19:00.0000] <zewt>
feels like people are selectively reading threads, heh

[23:20:00.0000] <zewt>
<me> do X <me> do X <sicking> do X <other people> thanks sicking

[23:48:00.0000] <nessy>
offff! glad that newline change to WebVTT time specs didn't get included - that just didn't feel right

[23:50:00.0000] <annevk>
newline change?

[23:50:01.0000] <annevk>
form feed is just some weird whitespace character

[23:50:02.0000] <annevk>
we decided it would still be parsed as whitespace, but would not be conforming

[23:52:00.0000] <annevk>
Hixie, seems like a good idea

[23:52:01.0000] <annevk>
Hixie, otherwise you have synchronous mutation events

[01:23:00.0000] <zcorpan>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14210 do we want "http://foo bar" to be a resolvable url?

[01:27:00.0000] <mkanat>
zcorpan: It would seem that the last comment indicates so, no?

[01:33:00.0000] <annevk>
I guess I don't really care

[01:33:01.0000] <annevk>
but I would have to update XMLHttpRequest and maybe CORS if everything resolves

[01:33:02.0000] <annevk>
and we should really define URLs somewhere

[01:35:00.0000] <zcorpan>
maybe someone from mozilla cares about this

[01:38:00.0000] <annevk>
could ask the network guys

[01:38:01.0000] <annevk>
from Opera that is

[06:41:00.0000] <MikeSmith>
http://www.lemonodor.com/archives/images/dijkstra-quick-n-dirty.jpg

[06:42:00.0000] <MikeSmith>
http://blografia.net/vicm3/wp-content/uploads/2011/10/doing-it-wrong1.jpg

[07:28:00.0000] <jgraham>
http://blog.jquery.com/2011/10/24/announcing-the-jquery-standards-team/ - with the word "sub-team" appearing in the first sentence, these people are clearly ahead of the game

[07:28:01.0000] <jgraham>
I suggest that the subteam be further split into task forces

[07:30:00.0000] <annevk>
is this the new http://www.css11.navy.mil/ ?

[07:30:01.0000] <annevk>
they never did anything either

[07:31:00.0000] <zcorpan>
jgraham: i think you have misunderstood. you don't split subteams into task forces. you introduce task forces for each pair of subteams.

[07:32:00.0000] <annevk>
doesn't that depend on the chair?

[07:32:01.0000] <jgraham>
zcorpan: You do both, afaict

[07:32:02.0000] <Philip`>
But how will the task forces coordinate with each other, unless you set up a task subforce for each pair of task forces?

[07:32:03.0000] <zcorpan>
use the force

[07:33:00.0000] <annevk>
and extra mailing lists

[07:33:01.0000] <annevk>
one can never have enough mailing lists

[07:33:02.0000] <jgraham>
Philip`: It can all be neat as long as you have the number of top level task forces as a power of two

[07:34:00.0000] <jgraham>
Or, I guess that's not really how it works

[07:40:00.0000] <hsivonen>
annevk: awesome URL for css11

[07:40:01.0000] <miketaylr>
i'm tempted to call the EMO office at http://www.css11.navy.mil/Contact.htm

[07:42:00.0000] <hasather>
miketaylr: this is him: http://a4.l3-images.myspacecdn.com/images02/129/82213099634047f79eb60293e6b17156/l.jpg

[07:42:01.0000] <miketaylr>
D:

[07:42:02.0000] <miketaylr>
maybe i won't then...

[07:48:00.0000] <karlcow>
maybe the two subteams parts have confidence on the pillow. (Pardon my French)

[08:04:00.0000] <jgraham>
/me wonders what pillows have to do with anything

[08:05:00.0000] <hsivonen>
is there a spec for parsing HTTP headers?

[08:06:00.0000] <hsivonen>
in particular, is the a parsing spec for the Content-Type header?

[08:11:00.0000] <karlcow>
jgraham: it is because you are not French. anythni

[08:11:01.0000] <karlcow>
ooops

[08:12:00.0000] <karlcow>
anything which needs coordination, resolution in France goes on a trajectory which crosses a bed at a point in time.

[08:13:00.0000] <jgraham>
Politics is obviously more sexy in France

[08:13:01.0000] <karlcow>
jgraham: definitely :)

[08:15:00.0000] <kennyluck>
Everytime I see something like "The reality is that whilst many of us would like to see change, due to … lengthy formal processes", I get angry.

[08:15:01.0000] <zewt>
the word "whilst" automatically makes me take someone less seriously

[08:23:00.0000] <broquaint>
Where do the docs for the URL API mentioned in this change live? http://html5.org/tools/web-apps-tracker?from=6744&to=6745

[08:24:00.0000] <miketaylr>
https://github.com/abarth/url-spec ?

[08:26:00.0000] <broquaint>
Thanks, miketaylr :)

[08:26:01.0000] <miketaylr>
np

[08:27:00.0000] <karlcow>
kennyluck: yup, it seems like there is a magical process which shorten agreements in distributed communities.

[08:28:00.0000] <karlcow>
more exactly it shows a poor understanding of what are communities and their social dynamics.

[08:32:00.0000] <zewt>
formal processes != social dynamics, heh

[09:35:00.0000] <hsivonen>
MikeSmith: I pushed the html parser patch.

[09:50:00.0000] <dglazkov>
good morning, Whatwg!

[10:10:00.0000] <Ms2ger>
Evening, dglazkov

[10:11:00.0000] <Ms2ger>
broquaint, http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html

[10:12:00.0000] <miketaylr>
ah, better link

[10:16:00.0000] <broquaint>
Brilliant, thanks :)

[10:47:00.0000] <AryehGregor>
rniwa, thanks for the bug.

[10:47:01.0000] <rniwa>
AryehGregor: np

[10:48:00.0000] <zewt>
an unlikely thing to be thankful for

[10:48:01.0000] <AryehGregor>
jarek/annevk (in case you read logs), I don't think Range.toString() should do that, but I don't think I ever wrote tests for it, so I dunno how browsers actually behave.

[10:48:02.0000] <AryehGregor>
On reflection, my guess is that "strips all newlines" means "doesn't add newlines", i.e., <div>foo</div><div>bar</div> -> "foobar".  This is expected behavior.

[10:49:00.0000] <AryehGregor>
At least, for spec writers.

[10:49:01.0000] <AryehGregor>
For authors, not so much.

[10:49:02.0000] <AryehGregor>
Oh well.

[10:50:00.0000] <AryehGregor>
Good grief, does Google Docs really have to advertise every little new not-even-deployed feature with an obnoxious popup when I visit it?

[10:50:01.0000] <AryehGregor>
Part of the reason I use Linux is to keep annoying unsolicited popups to a few per week max.

[11:28:00.0000] <paul_irish>
there isn't a standard for test cases is there? like standalone pages with pass/fail.. seems that everyone has their own setup, yah?

[11:31:00.0000] <miketaylr>
paul_irish: http://www.w3.org/html/wg/wiki/Testing/Authoring/

[11:33:00.0000] <paul_irish>
thx

[11:36:00.0000] <rniwa>
AryehGregor: every developer thinks their feature is the best thing that happened to the world

[11:36:01.0000] <rniwa>
it's hard to convince them his/her feature is not worthly of a big giant popup i guess

[12:30:00.0000] <Hixie>
smaug____: re http://www.w3.org/Bugs/Public/show_bug.cgi?id=14534 - what if there's no documentElement?

[12:30:01.0000] <Hixie>
smaug____: shouldn't we just target the Document if there's no body?

[12:30:02.0000] <Ms2ger>
Crash

[12:31:00.0000] <smaug____>
Hixie: just a second, testing..

[12:31:01.0000] <Hixie>
if you have a test case i can poke at, that would be great

[12:31:02.0000] <smaug____>
Hixie: and currently implementation target documentElement if there is no body

[12:31:03.0000] <smaug____>
implementations

[12:32:00.0000] <Hixie>
IE/opera/mozilla/webkit ?

[12:32:01.0000] <Hixie>
wow

[12:32:02.0000] <Hixie>
well if there's interop who am i to argue, i guess

[12:33:00.0000] <smaug____>
Hixie: I just uploaded a patch to make Gecko to work like IE9 and Webkit

[12:33:01.0000] <smaug____>
Opera had still some issues with my test case

[12:33:02.0000] <smaug____>
but let me test

[12:33:03.0000] <Hixie>
looks like webkit doesn't fire the event in the no-dE case

[12:35:00.0000] <Hixie>
yeah i can't get opera to remove the body or html nodes

[12:36:00.0000] <smaug____>
you can remove body in opera

[12:37:00.0000] <Hixie>
as soon as i do, a new one replaces it

[12:37:01.0000] <Hixie>
oh, that's only while parsing

[12:37:02.0000] <Hixie>
ok, onload i can remove it

[12:37:03.0000] <smaug____>
oh, removing root has strange effects in Opera

[12:37:04.0000] <smaug____>
the ui isn't updated, but event handling breaks down or something

[12:38:00.0000] <Hixie>
i don't get any events if there's no body

[12:38:01.0000] <Hixie>
similar to what the other browsers do when there's no root element

[12:38:02.0000] <Hixie>
so i guess they're just sending the events to the body element or nowhere

[12:38:03.0000] <Hixie>
whereas webkit sends it to the body element or the root element or nowhere

[12:38:04.0000] <Hixie>
haven't tested IE, don't have it easily accessible right now

[12:38:05.0000] <Hixie>
ok

[12:39:00.0000] <Hixie>
i guess i'll spec that the order of precedence is activeElement, body, root element, nowhere

[12:39:01.0000] <Hixie>
sound right?

[12:39:02.0000] <smaug____>
sounds right

[12:39:03.0000] <smaug____>
that is how gecko and webkit works now, and I think also IE9

[12:39:04.0000] <Hixie>
k

[12:39:05.0000] <smaug____>
though I haven't tested the nowhere case in it

[12:46:00.0000] <AryehGregor>
Opera's DOM handling is just generally messed up.

[12:46:01.0000] <AryehGregor>
It also behaves very strangely with doctype nodes, I've found.

[12:47:00.0000] <smaug____>
Hixie: just curious, has there ever been talk about reviewing spec changes before changing the spec?

[12:47:01.0000] <smaug____>
similar to how software/code development happens

[12:47:02.0000] <Hixie>
there's been talk, but since nobody is willing to review the changes at the rate i make them, it wouldn't really work

[12:47:03.0000] <smaug____>
are you sure it wouldn't work?

[12:48:00.0000] <Hixie>
have you seen the rate at which i make changes?

[12:48:01.0000] <AryehGregor>
Also, no one but Hixie actually understands more than about half the spec.

[12:48:02.0000] <Ms2ger>
Does Hixie?

[12:48:03.0000] <smaug____>
AryehGregor: that is no good argument.

[12:48:04.0000] <AryehGregor>
smaug____, well, it's really a matter of resources.  We have *very* few people willing to put much time into spec editing.

[12:49:00.0000] <smaug____>
I do understand most of Gecko's event handling, yet I do want someone to review my patches

[12:49:01.0000] <Hixie>
i don't really see how it would be better to do review-then-commit instead of commit-then-review, anyway

[12:49:02.0000] <smaug____>
AryehGregor: I know, it is a problem to have so few having time for spec editing

[12:49:03.0000] <AryehGregor>
smaug____, if implementers devoted more resources to it, we might have the capacity to do more review.  But as it stands, we don't have enough people to write the specs in the first place.

[12:49:04.0000] <smaug____>
but reviewing is different thing

[12:49:05.0000] <Hixie>
in practice the patches do get reviewed, and when there's a problem, it's reverted pretty quickly.

[12:49:06.0000] <AryehGregor>
smaug____, there is a mailing list that all the changes get posted to, but no way for people to sign off on them.

[12:50:00.0000] <michaelw>
Hixie: a proposed/stable split wouldn't be bad, IMO

[12:50:01.0000] <AryehGregor>
If someone wanted to make a system that let people mark diffs as reviewed or approved or whatever, I'm sure no one would expect.

[12:50:02.0000] <AryehGregor>
michaelw, then you have to deal with merges.

[12:50:03.0000] <Hixie>
michaelw: yeah, that's been suggested

[12:50:04.0000] <AryehGregor>
Since Hixie still uses SVN . . . :)

[12:50:05.0000] <Hixie>
michaelw: nobody's volunteered to maintain that either :-)

[12:51:00.0000] <michaelw>
AryehGregor: why is that a problem? that's how much software development works...

[12:51:01.0000] <Hixie>
smaug____: what might make sense is to have two trees, and to have one be what i edit, and another be what i edit but only with the patches up to the oldest not-reviewed patch

[12:51:02.0000] <AryehGregor>
michaelw, if it has enough resources, sure.

[12:51:03.0000] <Hixie>
smaug____: we could automate that that pretty well

[12:51:04.0000] <AryehGregor>
Also, the spec automatically gets review before implementation, because the implementers review it to some degree.

[12:51:05.0000] <smaug____>
Hixie: in software development review-then-commit has so far been better than the opposite

[12:51:06.0000] <Hixie>
smaug____: so people could look at the patches, and if they ok them, the tree moves on

[12:52:00.0000] <AryehGregor>
/me agrees that review-then-commit works better, but *only* if you have suitable review resources

[12:52:01.0000] <Hixie>
smaug____: software development has some key differences: there's multiple checking in, and it matters if the code doesn't compile

[12:52:02.0000] <AryehGregor>
If you don't have enough review resources to promptly review every revision, review-then-commit simply doesn't work.

[12:52:03.0000] <michaelw>
Hixie: from experience, the overhead is little.  you would commit to a "proposed" branch, and when people sign-off of a commit, or there has been no outcry, you merge every now and then

[12:52:04.0000] <Hixie>
michaelw: if you're willing to do the "sign-off of a commit, or there has been no outcry, you merge every now and then" part, go for it

[12:52:05.0000] <smaug____>
AryehGregor: we haven't even tried the "review-before-commit" approach for HTML spec, or WebApps WG specs

[12:53:00.0000] <zewt>
nothin' like more layers of procedure

[12:53:01.0000] <smaug____>
AryehGregor: have you tried implementing anything from spec drafts. It is quite frustrating that you know even before reading the spec that it will have bugs which need to be fixed before implementing it

[12:54:00.0000] <Hixie>
basically at the moment we could add review-then-commit or proposed/stable as a trivial layer on top of what we have now, without it affecting me at all

[12:54:01.0000] <Hixie>
so anyone who wants to do either of those should just set it up

[12:54:02.0000] <Hixie>
smaug____: that applies to all specs

[12:54:03.0000] <michaelw>
Hixie: actually, I might, a bit later this year.  have to convince $COMPANY to allocate resources

[12:55:00.0000] <Hixie>
michaelw: cool. it would be awesome to have a more stable branch.

[12:55:01.0000] <zewt>
smaug: heh, well, trying to reliably find bugs in a spec without implementing it is like trying to find bugs in source without compiling it

[12:56:00.0000] <michaelw>
zewt: good observation, hence that's what I'm doing :)

[12:57:00.0000] <smaug____>
Hixie: if http://twitter.com/#!/WHATWG shows all the changes to HTML spec, it isn't *that* many changes per day

[12:57:01.0000] <smaug____>
there sure are several possible reviewers

[12:57:02.0000] <zewt>
michaelw: reviewing a spec change by eye is not testing it in the same way as compiling and testing a code change

[12:57:03.0000] <smaug____>
and most of the changes, I hope, would be trivial  to review

[12:57:04.0000] <zewt>
you'll find more bugs than one pair of eyes, of course

[12:57:05.0000] <Hixie>
smaug____: nothing is stopping you from setting it up. do it! :-) i'm certainly all for more review.

[12:58:00.0000] <smaug____>
Hixie: so, would you upload patches to bugzilla for each patch :)

[12:58:01.0000] <zewt>
but you won't fix the "implementing a draft spec finds bugs" problem, any more than you can fix the "your code doesn't compile on the first attempt" "problem" :)

[12:58:02.0000] <Hixie>
smaug____: no, i'd just check them into svn, and that would be my working copy, and the reviewed copy would be a separate tree

[12:59:00.0000] <smaug____>
well, how could I see the patch then

[12:59:01.0000] <Hixie>
smaug____: http://html5.org/tools/web-apps-tracker lists them

[12:59:02.0000] <smaug____>
I hope there is some better tool for svn

[13:00:00.0000] <Hixie>
well it's an open svn repo so any tool you like can do it

[13:00:01.0000] <zewt>
sort of seems like the case for git

[13:00:02.0000] <zewt>
not that i'd argue heavily for git (i use it, but ... it's cranky)

[13:02:00.0000] <zewt>
has anyone implemented BlobBuilder at all? (it's not in FF6 or Chrome stable)

[13:04:00.0000] <smaug____>
zewt: it is in FF

[13:04:01.0000] <smaug____>
Moz prefixed, IIRC

[13:04:02.0000] <smaug____>
zewt: isn't FF6 kind of ol

[13:04:03.0000] <smaug____>
d

[13:05:00.0000] <zewt>
dunno, the "new version every 3 hours" thing gets tiresome

[13:05:01.0000] <Ms2ger>
Chrome stable, you mean?

[13:05:02.0000] <smaug____>
zewt: https://bugzilla.mozilla.org/show_bug.cgi?id=648997

[13:05:03.0000] <smaug____>
that says FF6

[13:06:00.0000] <zewt>
(and it'll be a long time before I'm willing to trust Firefox to autoupdate, I always back up my profile, make sure extensions still work, etc. before committing)

[13:06:01.0000] <zewt>
k

[13:06:02.0000] <Ms2ger>
/me shrugs

[13:18:00.0000] <_bga>
http://plan9.bell-labs.com/plan9/img/mirtchov/plan9-normal.png << Opera & plan9

[13:21:00.0000] <Hixie>
blimey there's a lot of <track> bugs. ok, guess i know what i'm doing this afternoon.

[13:21:01.0000] <Ms2ger>
Emails? :)

[13:22:00.0000] <Hixie>
soon, soon.

[13:22:01.0000] <Hixie>
i'm at record low numbers of bugs

[13:22:02.0000] <Hixie>
record in like a year

[13:24:00.0000] <smaug____>
time to file some more bugs :)

[13:24:01.0000] <Hixie>
noooooo

[13:24:02.0000] <Hixie>
at some point soon i'm going to switch back to e-mail

[13:25:00.0000] <Ms2ger>
Then we'd better get in our bugs before that

[13:26:00.0000] <Hixie>
just don't file a bug that's too much work, cos that will then make me switch early :-)

[14:01:00.0000] <jgraham>
Hmm, we can't even manage review-then-commit for testcases and they are updated *way* less often than the spec

[14:02:00.0000] <jgraham>
And not only will the tools not save us, they don't even exist

[14:02:01.0000] <jgraham>
Seriously, there are like 0 good code review tools for mercurial and 0 I have seen for svn

[14:03:00.0000] <jgraham>
I don't know how people cope

[14:03:01.0000] <jgraham>
Are they all emailing patches around or something?

[14:03:02.0000] <AryehGregor>
/me cough git cough

[14:03:03.0000] <jgraham>
git has one code review tool which might be good

[14:04:00.0000] <zcorpan>
foolip: maybe supporting comments in cue data is a bad idea, regardless of syntax

[14:04:01.0000] <jgraham>
In that I have heard it is a bit like the rather excellent homebrew thing we use at opera

[14:28:00.0000] <zewt>
maybe the spec comment form should throw away inputs with no vowels, heh

[14:39:00.0000] <zcorpan>
zewt: Hixie accepts patches :)

[14:39:01.0000] <zcorpan>
zewt: i had an idea the other week about counting keystrokes to prevent bugs where the reporter pasted something

[14:40:00.0000] <zcorpan>
but didn't look into implementing that

[14:52:00.0000] <TabAtkins>
One helpful change would be to auto-reject things that have a significant portion of the instructions for submitting a bug (or the introduction text in general).  Those make up a decent chunk of the junk bugs.

[14:52:01.0000] <TabAtkins>
You could probably do a really simple entropy analysis to find the keyboard-mashing junk bugs, too.

[14:54:00.0000] <zewt>
zcorpan: well, i'm not the one that has to spend time cleaning them up :)

[15:33:00.0000] <zewt>
so tired of the ridiculous "encryption is useless without a trusted certificate" from people who should know better

[15:35:00.0000] <_bga>
trusted certificate is another way to get your money

[15:35:01.0000] <zewt>
that's a separate issue, heh

[15:40:00.0000] <abarth>
Hixie: http://html.spec.whatwg.org/ has broken images and is missing the style sheet

[15:41:00.0000] <zcorpan>
hsivonen: afaik, the answer is "no" (re content-type header parsing)

[15:43:00.0000] <Hixie>
abarth: yeah, that url isn

[15:43:01.0000] <Hixie>
't live yet

[15:43:02.0000] <abarth>
ah

[15:43:03.0000] <abarth>
ok

[15:43:04.0000] <abarth>
what's the best way to hack into the Referer calculation in the spec

[15:44:00.0000] <abarth>
?

[15:44:01.0000] <Hixie>
have me change it :-)

[15:44:02.0000] <abarth>
2.7 Fetching resources ?

[15:44:03.0000] <abarth>
http://wiki.whatwg.org/wiki/Meta_referrer

[15:44:04.0000] <Hixie>
it happens in the "fetch" algorith, yeah

[15:44:05.0000] <abarth>
is the context

[15:44:06.0000] <abarth>
i'm trying to write the "semantics" section

[15:45:00.0000] <Hixie>
ah, i see

[15:45:01.0000] <Hixie>
ok

[15:45:02.0000] <Hixie>
hopld on

[15:46:00.0000] <zcorpan>
abarth: what's the difference between default and always? (use case for always?)

[15:47:00.0000] <Hixie>
zcorpan: https

[15:47:01.0000] <abarth>
zcorpan: suppose you want to move your search engine over to HTTPS but folks are sad that they don't get referrers anymore

[15:47:02.0000] <Hixie>
abarth: ok yeah. You'd override step 3 (I recommend just giving an entirely new replacement text), and then providing a replacement for the relevant paragraph in step 4

[15:47:03.0000] <zcorpan>
aha

[15:48:00.0000] <abarth>
Hixie: ok, I didn't see the HTTPS -> HTTP supression there, but maybe i need to override that from HTTP

[15:48:01.0000] <Hixie>
abarth: you might also need something in the HTTP spec, i think that may be where that is, yeah

[15:48:02.0000] <abarth>
ok

[15:48:03.0000] <abarth>
i think techincally its illegal in HTTP to send the origin in the Referer header

[15:48:04.0000] <abarth>
but Firefox has had an option to do that for a while

[15:49:00.0000] <zcorpan>
abarth: does origin act like default or like always?

[15:49:01.0000] <Hixie>
abarth: (if you don't find it there, add it to your new text, and if your new text doesn't end up in the spec for whatever reason, let me know and i'll fix the spec for that particular part of it anyway)

[15:49:02.0000] <abarth>
ok

[16:03:00.0000] <Hixie>
abarth: you want to replace the text of step 3 in all cases, and have the text examine the state of the (first/last) meta header

[16:03:01.0000] <Hixie>
abarth: you can't exactly have the user agent be required to change the spec based on the state of a meta header each time it loads a page :-P

[16:03:02.0000] <abarth>
ok

[16:03:03.0000] <abarth>
which meta header usually controls?

[16:03:04.0000] <abarth>
meta element

[16:03:05.0000] <abarth>
rather

[16:03:06.0000] <abarth>
(the first or the last)

[16:04:00.0000] <Hixie>
this is a meta name="" value?

[16:04:01.0000] <Hixie>
looks like none of the existing meta name values have UA requirements

[16:05:00.0000] <Hixie>
abarth: for http-equiv, looks like there's a slight preference for first-wins

[16:05:01.0000] <Hixie>
of course, <base> is last-wins

[16:50:00.0000] <michaelw>
after "e.onload = f;" (f being a valid function object), what should e.getAttribute("onload"); return?


2011-10-26
[17:03:00.0000] <_bga>
michaelw null in webkit

[17:03:01.0000] <_bga>
you set propety

[17:03:02.0000] <_bga>
not attibute

[17:06:00.0000] <michaelw>
_bga: with that reasoning, the value of the attribute should not change from what it was previously

[17:07:00.0000] <michaelw>
_bga: also getAttribute returns a DOMString

[17:07:01.0000] <michaelw>
IMO, it should return

[17:07:02.0000] <michaelw>
""

[17:08:00.0000] <michaelw>
(the empty string), sorry for the extra newline

[17:08:01.0000] <_bga>
of course

[18:02:00.0000] <Hixie>
zewt: i think if you think that a self-signed cert provides any security you have not attempted to mitm anyone

[18:04:00.0000] <TabAtkins>
Hixie: Still better than nothing.

[18:04:01.0000] <Hixie>
i think it might actually be worse than nothing

[18:04:02.0000] <TabAtkins>
/me is annoyed at browsers being paranoid about self-signed certs when they don't say a thing about login forms over http.

[18:04:03.0000] <Hixie>
because it gives a significantly distorted sense of security

[18:05:00.0000] <TabAtkins>
The correct sense is "better than nothing, worse than CA-signed".

[18:05:01.0000] <Hixie>
it's really not particularly better than nothing

[18:05:02.0000] <Hixie>
it's trivial to mitm somebody and offer them an identical-looking cert

[18:10:00.0000] <zewt>
it doesn't create any sense of security when implemented correctly; and it's very hard (impossible) to MITM on a large scale without anyone being able to find out

[18:11:00.0000] <Hixie>
it's very hard to passively sniff on a large scale too

[18:11:01.0000] <zewt>
orders of magnitude easier

[18:11:02.0000] <Hixie>
actually not really

[18:11:03.0000] <zewt>
untrusted crypto shouldn't be presented to users as a "secure connection"; it should just be there, invisible to the user as part of the protocol

[18:12:00.0000] <Hixie>
mitm'ing self-signed certs on a network where you control all the inbound and outbound traffic can be done completely transparently to anyone except those actually checking the fingerprints

[18:12:01.0000] <zewt>
eg. if all of my HTTP traffic was encrypted but not signed, and I suspected my ISP of MITM'ing to work around it, I could find out

[18:12:02.0000] <zewt>
but none of it is encrypted, so I have no way whatsoever of finding out

[18:13:00.0000] <Hixie>
you just have the routers do the TLS handshake and switch the server's cert for a dynamically-generated one

[18:13:01.0000] <Hixie>
why would you suspect your ISP?

[18:13:02.0000] <zewt>
why would I not?

[18:13:03.0000] <zewt>
or any other party with access

[18:13:04.0000] <Hixie>
have you _ever_ checked the fingerprint of _any_ self-signed cert?

[18:14:00.0000] <Hixie>
btw, in the context of this discussion (websocket) the user isn't presented with anything, secure or not

[18:14:01.0000] <zewt>
like i said, i didn't mean this as an objection against this particular case

[18:14:02.0000] <Hixie>
that's why it's critical to only accept secure connections if the requested protocol is wss:

[18:15:00.0000] <zewt>
my objection is to convincing innocent bystanders that untrusted crypto is the same as cleartext, which it just isn't

[18:15:01.0000] <Hixie>
my objection is to convincing innocent bystanders that untrusted crypto is any better than cleartext, which it just isn't

[18:16:00.0000] <zewt>
then your objection is factually wrong

[18:16:01.0000] <Hixie>
as is yours :-P

[18:16:02.0000] <Hixie>
but worse, yours instills a false sense of security

[18:17:00.0000] <zewt>
if there was large-scale MITM'ing of unsigned SSL connections taking place by ISPs or backbone routers, I'd expect to see people notice; it'd be an easy thing to honeypot

[18:17:01.0000] <Hixie>
luckily, as there's no large-scale use of self-signed certs, it's not an issue

[18:17:02.0000] <zewt>
(wrong term, but right meaning)

[18:18:00.0000] <zewt>
i don't subscribe to the "hixie says trust-me" model of security, sorry :)

[18:18:01.0000] <Hixie>
my model is "don't trust me or anyone"

[18:19:00.0000] <Hixie>
https://blog.startcom.org/?p=125#more-125

[18:19:01.0000] <zewt>
and in order to (not) do so, i prefer protocols that cause sniffing to require stream tampering to those that don't

[18:20:00.0000] <Hixie>
when was the last time you or anyone you know actually checked the fingerprint of a self-signed cert?

[18:20:01.0000] <Hixie>
that is the _only_ way you could tell if it was happening

[18:20:02.0000] <zewt>
ff's cert stuff is completely bogus--not that it shows bad certs, it's that it intentionally has a bad UI for it to make it annoying, which is never okay

[18:21:00.0000] <zewt>
we're not in an environment where that makes sense, because most of the traffic that could be in that category (encrypted but not signed) is currently cleartext

[18:21:01.0000] <Hixie>
i really think you underestimate the difficulty of mounting a mitm attack

[18:22:00.0000] <zewt>
even if so, i don't understate the detectability

[18:22:01.0000] <Hixie>
from personal experience, i can tell you that it is not even remotely difficult to do it in a way that nobody can notice

[18:22:02.0000] <Hixie>
s/can notice/does notice/

[18:22:03.0000] <Hixie>
nobody knows the fingerprint of any of the servers they use

[18:22:04.0000] <zewt>
right now there's no reason to set up "honeypot traffic" like that; everything's just plaintext, so nobody has any incentive to do those sorts of large-scale MITMs, all they have to do is sniff

[18:24:00.0000] <Hixie>
all the interesting stuff is encrypted with signed certs

[18:24:01.0000] <zewt>
1: cleartext traffic becomes encrypted 2: passive attacks no longer work; everyone using them either has to stop sniffing traffic or start tampering with data; 3: now you have a good reason to implement detection for that (eg. machines that just talk to random servers with known certificates to see if anyone's being evil)

[18:25:00.0000] <Hixie>
in a world where everyone used encryption with no signing, sure

[18:25:01.0000] <Hixie>
we're not, and never will be, in that world

[18:25:02.0000] <Hixie>
so it's irrelevant

[18:25:03.0000] <zewt>
hixie knows the future!

[18:26:00.0000] <zewt>
SPDY encrypts everything, signed or not, for example

[18:26:01.0000] <zewt>
(not to say i expect SPDY to take over)

[18:29:00.0000] <zewt>
i don't rule out a meaningful amount of cleartext data turning into encrypted data, but the chances of that definitely decrease when people claim that unsigned == cleartext

[18:29:01.0000] <zewt>
which is why it bothers me when I see it

[18:30:00.0000] <Hixie>
it bothers me because what you advocate increases the odds of people using unsigned encryption instead of signed encryption, which is extremely insecure

[18:31:00.0000] <Hixie>
users don't understand any of this stuff. They think "encrypted" means "safe" and that simply isn't the case.

[18:31:01.0000] <zewt>
we're not talking to users, we're talking to developers

[18:31:02.0000] <zewt>
users should certainly never see unsigned traffic as "secure"

[18:31:03.0000] <Hixie>
it's better to have plaintext that we can assume is sniffed than encrypted that we falsely assume is not

[18:31:04.0000] <Hixie>
users, developers, they don't understand it any better

[18:31:05.0000] <zewt>
if a developer doesn't understand it then he should have nothing to do with implementing it

[18:32:00.0000] <zewt>
i have little pity for developers who implement a "secure protocol" without knowing what they're doing, heh

[18:32:01.0000] <Hixie>
web developers do this all the time

[18:32:02.0000] <Hixie>
so in the real world, we have to take that into account

[18:32:03.0000] <zewt>
web developers use browser facilities, they don't implement encryption themselves

[18:34:00.0000] <zewt>
until someone has an epiphany and figures out a signing scheme where everyone can sign all of their traffic for free, I'll take partial security with known, quantifiable weaknesses than no security in a second

[18:34:01.0000] <zewt>
s/than/over/

[18:35:00.0000] <Hixie>
web developers decide whether to use self-signed certs or not

[23:23:00.0000] <hsivonen>
hmm. "Bug reports submitted from a group of experts however can give more weight to bug reports, and assure browser/tool vendors that suggested fixes are appropriate."

[23:24:00.0000] <hsivonen>
from http://www.html4all.org/staging/a11y-bugs/

[23:29:00.0000] <hsivonen>
The intro text on http://a11ybugs.org/ reminds me of CSS11

[23:29:01.0000] <hsivonen>
a11y15?

[23:34:00.0000] <hsivonen>
what's the deal with the bad escaping in the <title> at https://tools.ietf.org/html/rfc2854 ?

[23:34:01.0000] <hsivonen>
I guess HTML is hard. no wonder they prefer plain text.

[23:35:00.0000] <hsivonen>
Which RFC has the syntax for the charset parameter?

[23:37:00.0000] <hsivonen>
/me tries https://tools.ietf.org/html/rfc2046

[23:38:00.0000] <hsivonen>
RFCs need more hypertext

[23:49:00.0000] <hsivonen>
aargh. where does https://tools.ietf.org/html/rfc2045 say what a quoted-string is?

[00:53:00.0000] <hsivonen>
haha. since when has the HTML LS spec had a photo of a sink in it?

[00:54:00.0000] <hsivonen>
kitchen sink even, though it's not immediately obvious that the photo is indeed from a kitchen

[00:58:00.0000] <hsivonen>
is http://www.whatwg.org/specs/web-apps/current-work/#interactive the closest the spec has for defining how to tell the XHTML syntax and the HTML syntax apart?

[01:12:00.0000] <hsivonen>
filed as http://www.w3.org/Bugs/Public/show_bug.cgi?id=14565

[01:51:00.0000] <foolip>
zcorpan, context?

[01:56:00.0000] <zcorpan>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14552

[01:58:00.0000] <zcorpan>
foolip: in particular supporting // in cue data seems annoying

[01:59:00.0000] <foolip>
zcorpan, I think it's not a big deal as it will mostly mess with URLs, but not having it also doesn't seem like a problem

[02:08:00.0000] <zcorpan>
breaking URLs seems annoying :)

[02:14:00.0000] <foolip>
Hixie still seems to like his COMMENT --> blocks

[02:18:00.0000] <nessy>
hi foolip

[02:18:01.0000] <foolip>
hi nessy

[02:18:02.0000] <nessy>
do you have a different suggestion for how to get comment blocks and similar header style information into WebVTT?

[02:18:03.0000] <foolip>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14552 is what we've implemented

[02:23:00.0000] <nessy>
 // is a really bad idea because we won't get urls easily then

[02:23:01.0000] <nessy>
also, are you suggesting to use comment syntax to make header blocks in WebVTT, such as style, metadata etc?

[02:28:00.0000] <foolip>
No, we're suggest that it just be comments, things that can be pre-processed away and has no effect on anything whatsoever

[02:28:01.0000] <foolip>
not visible by scripts, unlike DOM comments

[02:29:00.0000] <foolip>
zcorpan, http://www.w3.org/Bugs/Public/show_bug.cgi?id=14260#c17 seems reasonable, right?

[02:32:00.0000] <zcorpan>
seems reasonable

[02:33:00.0000] <nessy>
foolip, we need some kind of sectioning of header stuff (not for browsers, but for desktop players), and the cue syntax provides for that

[02:33:01.0000] <nessy>
so, unless we find a better parsing landmark that helps with sectioning, I am with Ian

[02:33:02.0000] <foolip>
nessy, sure, I think that's an orthogonal issue to comment syntax, though

[02:34:00.0000] <nessy>
I think we could tolerate /* */

[02:34:01.0000] <nessy>
but using // is a really bad idea IMHO

[02:35:00.0000] <foolip>
sure, please comment as such

[02:58:00.0000] <nessy>
ok, done :-)

[03:54:00.0000] <zcorpan>
nessy: what you wrote in http://www.w3.org/Bugs/Public/show_bug.cgi?id=14552 doesn't work

[03:54:01.0000] <zcorpan>
00:01.000 --> <00:02.000

[03:54:02.0000] <zcorpan>
that will just cause that cue to be dropped

[03:55:00.0000] <nessy>
oh, because of the empty line?

[03:55:01.0000] <nessy>
hmm, I guess you're right

[03:55:02.0000] <zcorpan>
no

[03:55:03.0000] <zcorpan>
because the timings line is invalid

[03:55:04.0000] <zcorpan>
so the cue gets dropped

[03:56:00.0000] <nessy>
ah, that, too

[05:13:00.0000] <nessy>
gah, issue-179 raises its head! I was hoping it would be forgotten...

[09:14:00.0000] <AryehGregor>
Hmm, I just realized the Selection stuff in the editing spec wasn't all written by me.

[09:14:01.0000] <AryehGregor>
I think that means other people who contributed parts of it have to agree to the contributor agreement, or somesuch.

[09:32:00.0000] <dglazkov>
good morning, Whatwg!

[09:56:00.0000] <J_Voracek>
Good morning dglazkov!

[09:57:00.0000] <dglazkov>
I think he totally joined only to greet me.

[09:57:01.0000] <dglazkov>
that proves it that I am famous

[09:57:02.0000] <myakura>
night whatwg.

[09:57:03.0000] <myakura>
/me yawns.

[10:17:00.0000] <AryehGregor>
For out-of-range indices, should getters return null or undefined?

[10:20:00.0000] <AryehGregor>
localStorage returns null, but I thought everyone agreed that was a bad idea.

[10:21:00.0000] <AryehGregor>
UndoManager also seems to return null, and I'm not sure whether to suggest it change to undefined.

[10:30:00.0000] <AryehGregor>
Ugh, no ICS upgrade for Nexus One: http://www.telegraph.co.uk/technology/google/8848669/Android-upgrade-for-Google-Nexus-S-in-weeks.html

[10:31:00.0000] <AryehGregor>
That stinks.  I thought the whole point of Google's official phones was that they'd actually upgrade the OS.

[10:38:00.0000] <zewt>
google does not have much of a track record for updating "flagship" android devices

[10:38:01.0000] <zewt>
(rather the opposite)

[10:40:00.0000] <hsivonen>
zewt: better track record than the track record vendors have with non-Nexus phones

[10:41:00.0000] <zewt>
that's like saying "mcdonalds has better food than that box of broken glass and rusty staples"

[10:41:01.0000] <zewt>
likely true, but...

[10:42:00.0000] <hsivonen>
Everyone's except Apple's phone OS update story is really sad

[12:29:00.0000] <bencc>
what browsers plan to support webrtc?

[13:20:00.0000] <AryehGregor>
Hmm.

[13:20:01.0000] <AryehGregor>
Looks like my gentest.html produces a sad tab in Chrome dev now.

[13:20:02.0000] <AryehGregor>
That's bad.

[13:45:00.0000] <AryehGregor>
/me isolates the issue

[13:51:00.0000] <AryehGregor>
http://code.google.com/p/chromium/issues/detail?id=101791

[15:18:00.0000] <leaverou>
hi there, can somebody please tell me what output they get in IE10 from this? http://jsfiddle.net/leaverou/bFetP/show Thanks!

[15:22:00.0000] <TabAtkins>
The IE DOM is so bizarre sometimes...

[15:23:00.0000] <leaverou>
yeah, it keeps unknown properties

[15:23:01.0000] <leaverou>
and drops unknown values in known properties!

[15:23:02.0000] <leaverou>
and alas, I was hoping those flags might solve it for IE, but no

[15:23:03.0000] <leaverou>
maybe outerHTML

[15:30:00.0000] <leaverou>
geez, it's even removed from outerHTML /cc TabAtkins

[15:31:00.0000] <TabAtkins>
leaverou: Yeah, it must happen during parsing.

[15:31:01.0000] <leaverou>
so there's absolutely no workaround you think?

[15:31:02.0000] <bga_>
oh leaverou here

[15:31:03.0000] <leaverou>
bga_: hey

[15:31:04.0000] <bga_>
:)

[15:32:00.0000] <TabAtkins>
leaverou: Unless there's something really tricky, at this point I think not.

[15:32:01.0000] <TabAtkins>
But IE has surprised us in the past with nonsensical workarounds.

[15:32:02.0000] <leaverou>
TabAtkins: I'll ping Rey, it's our last hope I guess

[15:33:00.0000] <leaverou>
TabAtkins: so that's why CSS3PIE requires different properties even for values!!

[15:34:00.0000] <TabAtkins>
Ah, that makes sense.

[15:34:01.0000] <smaug____>
TabAtkins: haven't all the browsers surprised us with nonsensical workarounds. :)

[15:34:02.0000] <TabAtkins>
smaug____: I don't know if anything will ever top the IE shiv for the new elements.  ^_^

[15:34:03.0000] <leaverou>
smaug____: I think IE is the champion of that though

[15:52:00.0000] <zewt>
constructors that return a different type? that sounds ... evil

[15:52:01.0000] <TabAtkins>
zewt: Agreed.

[15:52:02.0000] <TabAtkins>
Either have real constructors or an honest factory.

[15:53:00.0000] <zewt>
also wouldn't translate well to most other languages (even if that's not a top concern for web APIs)

[15:55:00.0000] <smaug____>
zewt: huh, where was such ctors suggested

[15:56:00.0000] <smaug____>
oh, webapps

[15:56:01.0000] <smaug____>
/me kicks heycam

[15:58:00.0000] <bencc>
is there a spec about webcam other than webrtc?

[15:58:01.0000] <bencc>
I mean, will ie10 be able to stream webcam without supporting webrtc?

[15:58:02.0000] <smaug____>
you mean using camera input ?

[15:58:03.0000] <smaug____>
there is some draft from  DAP

[15:59:00.0000] <bencc>
DAP?

[15:59:01.0000] <bencc>
IE10 won't support plugins

[15:59:02.0000] <TabAtkins>
zewt: We really don't care at all other non-JS languages.  But it's still bad.

[15:59:03.0000] <bencc>
but html5 doesn't have support for p2p connections and media streaming yet

[16:00:00.0000] <bencc>
so there is a gap

[16:00:01.0000] <smaug____>
bencc: DAP WG in W3C

[16:00:02.0000] <Hixie>
bencc: yes it does

[16:00:03.0000] <bencc>
Hixie: ?

[16:00:04.0000] <Hixie>
bencc: http://www.whatwg.org/specs/web-apps/current-work/#video-conferencing-and-peer-to-peer-communication

[16:01:00.0000] <bencc>
Hixie: thanks. how does it relates to webrtc?

[16:01:01.0000] <bencc>
and do you know if any browser support it?

[16:01:02.0000] <Hixie>
you mean the w3c webrtc thing?

[16:02:00.0000] <bencc>
yes

[16:02:01.0000] <Hixie>
the w3c webrtc thing is a fork of the text above

[16:03:00.0000] <bencc>
so which one is the "standard"?

[16:03:01.0000] <smaug____>
there isn't anything even close to stable spec yet

[16:03:02.0000] <smaug____>
afaik

[16:03:03.0000] <Hixie>
whatdo you mean by "standard"?

[16:03:04.0000] <bencc>
it seems that chrome, firefox and opera are going to support webrtc

[16:03:05.0000] <smaug____>
for video or audio streaming, not audio handling in general

[16:03:06.0000] <bencc>
but ie10 and safari?

[16:05:00.0000] <smaug____>
ask MS and Apple;)

[16:05:01.0000] <Hixie>
beats me

[16:05:02.0000] <Hixie>
i can't even work out which one chrome, firefox and opera are implementing :-)

[16:06:00.0000] <Hixie>
(not that i've investigated, been too busy with other things)

[16:06:01.0000] <bencc>
I see this in IE: http://html5labs.interoperabilitybridges.com/prototypes/media-capture-api/media-capture-api/info

[16:06:02.0000] <zewt>
("forkable specs are bad, see watch we'll show you why!")

[16:06:03.0000] <bencc>
not sure if it supports streaming

[16:07:00.0000] <Hixie>
zewt: yeah pretty much

[16:08:00.0000] <smaug____>
bencc: that page is talking about DAP spec

[16:08:01.0000] <Hixie>
w3c really lost all credibility with their no-forking argument after that

[16:08:02.0000] <bencc>
smaug____: what does DAP means?

[16:09:00.0000] <zewt>
Hixie: are the specs conflicting? (same interface or renamed interfaces)

[16:09:01.0000] <Hixie>
zewt: yes

[16:09:02.0000] <smaug____>
bencc: the page is also talking about HTML Speech, which will probably rely on webrtc to get microphone input

[16:09:03.0000] <smaug____>
bencc: Device APIs and Policy Working Group

[16:09:04.0000] <smaug____>
DAP WG

[16:09:05.0000] <Hixie>
zewt: (in that they forked the whatwg one, and i haven't changed the whatwg since and they have changed their incompatibly)

[16:10:00.0000] <bencc>
this stuff is more complicated than programming :)

[16:11:00.0000] <zewt>
it's just complicated on a somewhat different axis :)

[16:17:00.0000] <heycam>
smaug____, is it really controversial to write things like `function Element(tagname) { return document.createElement(tagname); } var e = new Element("div");`?

[16:17:01.0000] <heycam>
`new Element("div")` looks like a lovely pattern to me

[16:17:02.0000] <heycam>
I mean, it reads pretty nicely

[16:18:00.0000] <smaug____>
but you get different interface back

[16:18:01.0000] <smaug____>
that is very strange

[16:18:02.0000] <smaug____>
and so far not used anywhere else in web platform

[16:20:00.0000] <TabAtkins>
heycam: new Element.Div() reads just as well without being a factory in disguise.

[16:21:00.0000] <smaug____>
heycam: also, what should new Element("a") return? an HTML Element or SVG Element?

[16:21:01.0000] <Hixie>
except you then have to create a mapping for all the elements which is really quite ugly

[16:21:02.0000] <TabAtkins>
Or hell, new Element.div(), so you can do new Element["div"]() easier.

[16:21:03.0000] <TabAtkins>
Hixie: You're talking about something hidden in the implementation which is completely irrelevant to real people.

[16:21:04.0000] <smaug____>
TabAtkins: how does that work with SVG vs HTML ?

[16:22:00.0000] <heycam>
smaug____, at least the returned thing is instanceof Element...

[16:22:01.0000] <TabAtkins>
smaug____: HTML wins!  Woo!

[16:22:02.0000] <Hixie>
TabAtkins: it's not hidden, it's right there on Element

[16:22:03.0000] <heycam>
smaug____, the new Element("a") question is good

[16:22:04.0000] <heycam>
but you get the same thing with Elemetnt.a()

[16:22:05.0000] <TabAtkins>
(SVG is trying to put some effort into unifying style/script/a with HTML.)

[16:23:00.0000] <zewt>
heycam: everyone expects "new XXX()" to return an XXX, whether or not it's technically required; a factory doesn't make that implication

[16:23:01.0000] <smaug____>
heycam: I'm not saying new Element["a"]() is any better

[16:23:02.0000] <zewt>
best to honor the basic assumptions of what a constructor does

[16:24:00.0000] <TabAtkins>
zewt: Agreed.  That's my "or be an honest factory" objection.

[16:24:01.0000] <heycam>
new new new new new new function Constructors4Life() { return Constructors4Life }

[16:24:02.0000] <TabAtkins>
heycam: Can you stack news like that?

[16:25:00.0000] <heycam>
oh what, maybe not :)

[16:25:01.0000] <heycam>
you need parens it seems

[16:25:02.0000] <TabAtkins>
That's what I thought. ^_^

[16:25:03.0000] <heycam>
new (new (new ...

[16:26:00.0000] <zewt>
Could not join server since it couldn't be found.

[16:26:01.0000] <zewt>
hay wrong window

[16:26:02.0000] <TabAtkins>
Slightly unfortunate.  Having to do (new Foo()).bar() is slightly annoying.

[16:26:03.0000] <TabAtkins>
But shrug, minor inconvenience.

[16:27:00.0000] <zewt>
similar annoyance to having to parenthesize functions

[16:27:01.0000] <Hixie>
i think the quasi strings are a more interesting approach than all the above, personally

[16:28:00.0000] <TabAtkins>
Hixie: Disagree.  Quasi strings are a great complement, but they don't let you easily, say, make an element with a bag of properties.

[16:29:00.0000] <Hixie>
bag of properties?

[16:31:00.0000] <Hixie>
you can trivially do that in a helper function:  function createElementWithBag(name, bag) { var r = document.createElement(name); for (var i in bag) r[i] = bag[i]; return r; }

[16:31:01.0000] <TabAtkins>
Hixie: new Video({autoplay: false, loop:true}) or something.

[16:31:02.0000] <Hixie>
we don't need to provide an API for that

[16:31:03.0000] <TabAtkins>
Hixie: I know you hate convenience APIs.

[16:31:04.0000] <Hixie>
i don't hate convenience APIs, I hate wasting our time adding stuff to the platform that is trivially already possible when we have way bigger fish to fry

[16:31:05.0000] <Hixie>
it's a huge opportunity cost

[16:32:00.0000] <TabAtkins>
You go fry those bigger fish.  I'll cheerlead for making the fish easier to catch.

[16:33:00.0000] <Hixie>
you really think adding an API that does the equivalent of literally one line of code that can be banged out in 10 seconds in going to be a good use of our time?

[16:37:00.0000] <TabAtkins>
Hixie: Yes, when it improves consistency, readability, and writeability and is used so often.

[16:37:01.0000] <Hixie>
wow

[16:37:02.0000] <Hixie>
what other trivial things do you think we should add?

[16:37:03.0000] <TabAtkins>
Ponies, if you please?

[16:37:04.0000] <Hixie>
i'm not being sarcastic. i'm honestly curious.

[16:38:00.0000] <Hixie>
if it's a short list, it might make sense to just create a JS file that browsers are required to run by default or something.

[16:38:01.0000] <TabAtkins>
The two painfully annoying parts of the DOM that I regularly experience are (1) element creation and (2) meaurement/positioning.  Both of these can be fixed by libraries, but are worthwhile fixing in the core.

[16:38:02.0000] <Hixie>
i'm all for making element creation easier, but what's hard about it is creating trees, not creating an element and setting some properties

[16:38:03.0000] <TabAtkins>
(Not all of the measurement features are actually doable in current JS, but a lot are.)

[16:39:00.0000] <Hixie>
the measurement/positioning thing is hopefully something that can be solved in CSSOM using some of the things i proposed a decade or so ago, or something derived from it

[16:39:01.0000] <Hixie>
anne's on that, i think

[16:39:02.0000] <TabAtkins>
Hixie: Trees are easy.  "new Element.div({props}, "some text" , new Element.p({}, "more text in a <p>"))

[16:39:03.0000] <TabAtkins>
Hixie: Anne or me or roc, yeah.

[16:41:00.0000] <Hixie>
that's harder than `<div props>{text}<p>{moretext}`, or whatever syntax we come up with based on quasis

[16:41:01.0000] <Hixie>
e4x-like syntax

[16:41:02.0000] <TabAtkins>
Agreed, if your elements and attributes are known at write-time.

[16:41:03.0000] <TabAtkins>
The function appraoch is easier if you only know them at runtime.

[16:41:04.0000] <Hixie>
and uglier, imho, than Element.create("div", {props}, ["some text", Element.create("p", ["more text"])])

[16:41:05.0000] <TabAtkins>
Both are good.  ^_^

[16:42:00.0000] <Hixie>
but in either case i agree that that's worth adding

[16:42:01.0000] <Hixie>
it was the implication of "Quasi strings are a great complement, but they don't let you easily, say, make an element with a bag of properties" that i object to

[16:42:02.0000] <smaug____>
In many cases innerHTML works quite well

[16:42:03.0000] <TabAtkins>
Hixie: Personal taste on that I guess.  I like constructors better than factories, and omitting arrays when possible (since ES6 should have a way to expand arrays into varargs).

[16:42:04.0000] <Hixie>
namely that "easily, say, make an element with a bag of properties" is a use case that on its own should be fixed

[16:43:00.0000] <Hixie>
smaug____: innerHTML fails hard because it doesn't give you compile-time syntax checking

[16:43:01.0000] <Hixie>
smaug____: it also fails even harder due to XSS

[16:43:02.0000] <TabAtkins>
smaug____: Plus, injection woo!

[16:43:03.0000] <Hixie>
smaug____: (it makes injection easier than doing it right)

[16:44:00.0000] <smaug____>
I don't understand how Element.create gives syntax checking...

[16:45:00.0000] <Hixie>
smaug____: you can't do the equivalent of <b>x<i>y</b>z</i> with it

[16:45:01.0000] <smaug____>
creating Element.create("<") shouldn't work

[16:45:02.0000] <smaug____>
ah, you mean that

[16:45:03.0000] <TabAtkins>
Plus, it's theoretically possible to do content-model checking among the children passed to the function.

[16:46:00.0000] <Hixie>
well, it would be in some languages

[16:46:01.0000] <TabAtkins>
Dunno if that's a good idea or not.

[16:46:02.0000] <Hixie>
i don't think we'll see that in JS any time soon

[16:46:03.0000] <Hixie>
and the HTML rules are probably far too complex to be sanely represented in a type system

[16:47:00.0000] <TabAtkins>
Yeah, likely.

[16:47:01.0000] <bga_>
heh

[16:48:00.0000] <bga_>
sec

[16:48:01.0000] <TabAtkins>
Well, you don't need to use a formal type system to verify parameters passed to a function.  That can be done manually.

[16:49:00.0000] <othermaciej>
I suspect not even Haskell's type system could do all HTML5 content model checks correctly

[16:49:01.0000] <Hixie>
TabAtkins: oh i meant at compile time

[16:49:02.0000] <Hixie>
TabAtkins: you could do runtime checking even of innerHTML, that's not so interesting

[16:52:00.0000] <TabAtkins>
Hixie: You're right.

[16:58:00.0000] <bga_>
http://pastie.org/2764698

[16:58:01.0000] <bga_>
i hope it will in future web

[16:59:00.0000] <bga_>
and smart compiler can validate html


2011-10-27
[17:01:00.0000] <TabAtkins>
bga_: We (subset of Chrome team working on this stuff) want something very similar to that.

[17:04:00.0000] <bga_>
i need time to implement it

[17:35:00.0000] <bga_>
lol http://www.firefoxwithbing.com/

[18:20:00.0000] <Hixie>
anne: need your input on http://www.w3.org/Bugs/Public/show_bug.cgi?id=14284

[00:39:00.0000] <bitgod>
hello?

[02:53:00.0000] <zcorpan>
http://doctype.com/figure-used-background-images

[02:53:01.0000] <annevk>
ah, Mike must be traveling

[02:54:00.0000] <annevk>
I guess I should write a weekly

[02:54:01.0000] <annevk>
hmm

[02:59:00.0000] <annevk>
hsivonen, what did you implement for http://www.w3.org/Bugs/Public/show_bug.cgi?id=14284 ?

[02:59:01.0000] <annevk>
hsivonen, I don't really mind either way

[02:59:02.0000] <annevk>
hsivonen, it seems sicking feels somewhat strongly for lots of sniffing though he has no figures to back that up...

[03:00:00.0000] <annevk>
hsivonen, I would personally be fine with the simple rules or GTFO

[03:01:00.0000] <erlehmann>
hahaha

[03:01:01.0000] <erlehmann>
tha attribute styling stuff is COMEDY GOLD

[03:04:00.0000] <annevk>
erlehmann: ?

[03:06:00.0000] <hsivonen>
annevk: I implemented the following:

[03:06:01.0000] <erlehmann>
annevk, Jukka K. Korpela <jkorpela⊙ctf> suggested using <div type="nav"> instead of <nav> for IE compatibility.

[03:06:02.0000] <erlehmann>
and then simon pieters was like “<div type="nav"> is not stylable in IE6 because it doesn't support

[03:06:03.0000] <erlehmann>
attribute selectors.”

[03:06:04.0000] <erlehmann>
i pooped a little.

[03:06:05.0000] <hsivonen>
text/html in non-default, non-document modes works like an unknown type

[03:07:00.0000] <hsivonen>
annevk: in the default and document modes, for text/html first honor HTTP, failing that BOM, failing that <meta> within the first 1024 bytes

[03:08:00.0000] <hsivonen>
annevk: if we have to look for <meta>, stall output until the parser has seen the <meta> or received 1024 bytes

[03:08:01.0000] <hsivonen>
if the parser sees 1024 bytes without a <meta> (and without BOM or HTTP-level charset), use UTF-8

[03:08:02.0000] <hsivonen>
annevk: HOWEVER

[03:08:03.0000] <hsivonen>
annevk: doing this breaks our mochitests

[03:09:00.0000] <hsivonen>
annevk: specifically, we have something that tests redirects and tries to read the resource body of a redirect response

[03:09:01.0000] <hsivonen>
which is marked text/html without an explicit charset

[03:09:02.0000] <hsivonen>
annevk: so this stuff may not be entirely done yet

[03:10:00.0000] <hsivonen>
annevk: I've been pondering the idea of not stalling as long as the data before the <meta> is in the printable ASCII range

[03:11:00.0000] <hsivonen>
annevk: not stalling responseText that is

[03:11:01.0000] <annevk>
ow

[03:11:02.0000] <annevk>
that sounds tricky

[03:11:03.0000] <roc>
hsivonen: are you just worried about the test, or are you worried that the same pattern is likely to show up in real life?

[03:11:04.0000] <hsivonen>
annevk: I'll analyze the situation and see if it's reasonable to try to change the test

[03:12:00.0000] <hsivonen>
roc: so far, only a test

[03:15:00.0000] <annevk>
hsivonen: did you consider completely disabling the <meta> thing?

[03:16:00.0000] <annevk>
hsivonen: Hixie: I updated the bug saying we're waiting for implementation experience from Gecko

[03:17:00.0000] <annevk>
the CSS WG decided to not change vm/vw

[03:17:01.0000] <annevk>
grmbl

[03:26:00.0000] <hsivonen>
annevk: I considered it briefly after Hixie suggested it, but disabling <meta> altogether would mean deviating even more from what sicking wanted and I'm in principle uncomfortable with not supporting all conforming documents

[03:33:00.0000] <annevk>
http://www.w3.org/html/wg/wiki/ChangeProposals/av_param o_O

[03:34:00.0000] <annevk>
insanity is prevailing it seems

[03:34:01.0000] <annevk>
hsivonen: fair enough, sounds good to me generally

[03:39:00.0000] <boblet>
annevk: quick q about HTML5 diffs doc. It mentions absent elements "are not in HTML5". I thought they were obsolete (not for author use) but still covered by HTML5 (=in the spec with guidance for implementors)

[03:39:01.0000] <boblet>
it’s re: https://github.com/html5doctor/diveintohtml5/issues/1

[03:40:00.0000] <roc>
who's behind av_param?

[03:41:00.0000] <annevk>
Glenn Adams

[03:41:01.0000] <annevk>
he contracts for some unnamed entity I believe

[03:41:02.0000] <roc>
Samsung

[03:42:00.0000] <annevk>
yeah, but also an unnamed entity

[03:42:01.0000] <boblet>
for me using obsolete elements in HTML5 doesn’t break the doc, just the validation. maybe I need to read defn of obsolete…

[03:42:02.0000] <roc>
he was involved in a large furore on the wwww-font list

[03:43:00.0000] <annevk>
and apparently co-chair of the Timed Text WG at some point

[03:43:01.0000] <annevk>
boblet, you should tell the guy that HTML4 is obsolete

[03:44:00.0000] <boblet>
annevk: you’re not helping :p

[03:44:01.0000] <boblet>
purist vs pragmatist, fight! ;)

[03:44:02.0000] <annevk>
boblet: just saying how it is

[03:45:00.0000] <annevk>
boblet: anyway html5-diff is written towards authors primarily

[03:45:01.0000] <annevk>
boblet: as they seem to find it most useful, and for authors, the elements are absent

[03:45:02.0000] <boblet>
annevk: for me Mark’s sentence is correct, but from an author perspective (if there are obsolete elems/attribs) maybe not so much huh

[03:48:00.0000] <annevk>
you should not read books like you read specs man

[03:49:00.0000] <annevk>
specs you can read in an anal-retentive way, maybe even should

[03:49:01.0000] <annevk>
books not so much

[03:49:02.0000] <annevk>
I would link to a blog entry where Mark explains this, but it's no longer up :(

[03:51:00.0000] <boblet>
annevk: agree. can u give me a rough title or keywords re: Mark's article? might check archive

[03:52:00.0000] <annevk>
boblet: ietf, cat pictures, w3c

[03:53:00.0000] <annevk>
boblet: maybe specs or standards

[03:54:00.0000] <boblet>
annevk: thanks as always yo

[04:15:00.0000] <karlcow>
annevk: http://web.archive.org/web/20110514114618/http://diveintomark.org/archives/2004/08/16/specs ?

[04:21:00.0000] <annevk>
no

[04:23:00.0000] <akamike>
Amusing to read though

[04:25:00.0000] <annevk>
he has written many great posts

[04:34:00.0000] <hsivonen>
I wonder how much YouTube's autocaptioning has been tested with different accents. it fails pretty hard with a typical Finnish accent (when speaking English that is)

[04:36:00.0000] <zcorpan>
i tried it on a presentation timj held. it pretty much failed

[04:37:00.0000] <hsivonen>
zcorpan: the WebGL developer?

[04:37:01.0000] <zcorpan>
yes

[04:37:02.0000] <hsivonen>
zcorpan: is he from Finland (his English sounded more like spoken by a Finn that like spoken by a Swede)

[04:38:00.0000] <zcorpan>
no

[04:41:00.0000] <annevk>
pointer?

[04:42:00.0000] <zcorpan>
http://www.youtube.com/watch?v=BnVy_uCk_es

[04:43:00.0000] <hsivonen>
annevk: http://www.youtube.com/watch?v=K6QjOjgwuWk particularly between 1:00 and 1:20 shows the speech recognition failing pretty hard

[04:46:00.0000] <zcorpan>
it transcribed "firefox" correctly but "chrome" became "croats"

[04:46:01.0000] <zcorpan>
(4:30)

[04:48:00.0000] <zcorpan>
"fragment shaders" -> "pregnant shakers" :)

[04:52:00.0000] <boblet>
annevk: “There are no exceptions to Postel’s Law”? http://web.archive.org/web/20110514120305/http://diveintomark.org/archives/2004/01/08/postels-law

[04:53:00.0000] <hsivonen>
it's nice that Mark didn't request archive.org to hide his writings

[04:54:00.0000] <hsivonen>
btw, did I miss something that I should have mentioned in http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0266.html ?

[05:00:00.0000] <annevk>
boblet: good find

[05:00:01.0000] <annevk>
zcorpan: haha

[05:03:00.0000] <hsivonen>
I wonder if anyone has fed yesterday's Nokia Lumia 800 announcement to a text to speech engine to see how often the said "800" in a way that sounded like "Android"

[05:03:01.0000] <hsivonen>
doh. speech to text

[05:07:00.0000] <annevk>
hsivonen: looks accurate

[05:07:01.0000] <annevk>
hsivonen: blog post worthy

[05:09:00.0000] <hsivonen>
annevk: ok. thanks. I might copy and paste it to my blog later.

[05:13:00.0000] <hsivonen>
sigh. so we have a separate parsing algorithm for WebVTT but make it treat Form Feed as white space for consistency. FAIL. :-(

[05:18:00.0000] <hsivonen>
whoa. a thread about "Signed XHTML". XML tech rathole warning!

[05:19:00.0000] <annevk>
hsivonen, we can remove the FF handling

[05:19:01.0000] <annevk>
hsivonen: should we?

[05:19:02.0000] <hsivonen>
annevk: my gut says we should

[05:19:03.0000] <hsivonen>
space, tab, cr and lf is the One True set of space characters

[05:20:00.0000] <annevk>
what does CSS have?

[05:20:01.0000] <annevk>
and why does HTML have FF?

[05:20:02.0000] <hsivonen>
HTML has FF due to beliefs about legacy

[05:21:00.0000] <hsivonen>
dunno how real the need to have FF in HTML is

[05:22:00.0000] <hsivonen>
CSS has FF. :-(

[05:22:01.0000] <annevk>
seems better to just keep FF around then

[05:22:02.0000] <hsivonen>
:-(

[05:23:00.0000] <annevk>
it's not very sad, it just means it's 5 true whitespace characters instead of 4

[05:27:00.0000] <hsivonen>
I failed to resist replying to the signature thread

[05:55:00.0000] <zcorpan>
annevk: FF after signature would be inconsistent with cache manifests

[06:02:00.0000] <annevk>
maybe we should update those too then

[06:21:00.0000] <annevk>
http://www.firefoxwithbing.com/ is all kinds of odd, but it also makes sense I suppose

[06:36:00.0000] <hsivonen>
annevk: odd how?

[06:40:00.0000] <annevk>
Microsoft promoting the usage of a non-Microsoft browser in order to more successfully compete in the search market

[07:06:00.0000] <erlehmann>
annevk, bing even uses webm ;)

[07:06:01.0000] <erlehmann>
btw, do you know a good minimalistic contentEditable editor?

[07:54:00.0000] <hsivonen>
erlehmann: where does Bing use WebM? or did I misunderstand the smiley?

[07:56:00.0000] <hsivonen>
annevk: does Microsoft promote the firefoxwithbing.com site somewhere to users who aren't already seeking to download Firefox?

[07:56:01.0000] <erlehmann>
hsivonen, here? http://www.bing.com/?scope=web&setmkt=en-US&setlang=match&FORM=W5WA&uid=879B42B5

[07:57:00.0000] <hsivonen>
erlehmann: cool

[07:59:00.0000] <miketaylr>
unless you're using Opera, then you get a static image

[07:59:01.0000] <miketaylr>
yay

[08:02:00.0000] <AryehGregor>
MS was never against WebM, they just don't want to ship the codecs.

[08:02:01.0000] <AryehGregor>
For liability reasons.

[08:03:00.0000] <AryehGregor>
Shipping an encoder or decoder is presumably a lot more likely to expose you to liability than providing a file.

[08:04:00.0000] <AryehGregor>
I guess patents are likely to cover the encoding or decoding process, not the file format itself.

[08:06:00.0000] <erlehmann>
AryehGregor, that is what they want you to believe.

[08:06:01.0000] <AryehGregor>
Plus, your liability for distributing one file has got to be more limited than your liability for distributing a codec that lets users view zillions of files.

[08:06:02.0000] <AryehGregor>
erlehmann, I've seen nothing to indicate that Microsoft is anything but honest in its reasons for non-support of WebM.

[08:07:00.0000] <erlehmann>
AryehGregor, non-support of vorbis?

[08:07:01.0000] <AryehGregor>
Everything they've said and done accords with their explanation that they're only concerned about patent liability.

[08:07:02.0000] <AryehGregor>
. . . Vorbis I don't know.  I haven't seen any statements by them on that.

[08:07:03.0000] <AryehGregor>
People seem to not talk about the audio part much, mostly video.

[08:08:00.0000] <erlehmann>
i am interested in audio. i sometimes do podcasts.

[08:08:01.0000] <erlehmann>
also, streaming vorbis (well, anything in ogg) is easy.

[08:08:02.0000] <gsnedders>
AryehGregor: They already ship VP8.

[08:08:03.0000] <gsnedders>
AryehGregor: In Skype.

[08:08:04.0000] <AryehGregor>
gsnedders, typical.  One hand doesn't know what the other is doing . . .

[08:08:05.0000] <erlehmann>
http://en.wikipedia.org/wiki/Microsoft_PlaysForSure#Criticisms

[08:08:06.0000] <AryehGregor>
Like how they argued fiercely against OTF embedding while Silverlight supported it.

[08:08:07.0000] <gsnedders>
AryehGregor: They only officially owned Skype a few days ago

[08:09:00.0000] <erlehmann>
>The license prohibited makers of portable devices compatible with Windows Media Player from using non-Microsoft audio encoding formats.

[08:09:01.0000] <gsnedders>
AryehGregor: But the risk is now their's

[08:09:02.0000] <AryehGregor>
Oh, so MPEG LA's patent search has come up with something.  I didn't notice that when it happened.

[08:09:03.0000] <AryehGregor>
gsnedders, oh, well, that's different.

[08:09:04.0000] <AryehGregor>
That does change things, though.

[08:09:05.0000] <gsnedders>
AryehGregor: Different, yes, but the liability is their's.

[08:09:06.0000] <gsnedders>
AryehGregor: And it's only really the liaibility  that matters.

[08:10:00.0000] <AryehGregor>
Yes.

[08:10:01.0000] <erlehmann>
AryehGregor, i have one question. if a vendor has already paid or is part of the patent consortium, what is to fear, legally, by including free codecs?

[08:10:02.0000] <jgraham>
AryehGregor:

[08:10:03.0000] <AryehGregor>
Of course, they might decide to phase out VP8 from Skype.  But if they don't, it seems hard to understand why they wouldn't allow WebM in IE too.

[08:10:04.0000] <gsnedders>
AryehGregor: MPEG LA's H.264 portfolio is meant to be about 20% bogus, but the cost of going through and proving prior art for all of them is considered more costly than paying the fee

[08:11:00.0000] <gsnedders>
AryehGregor: the number of units sdhipped would have an affect on any fine. IE ships more units than Skype.

[08:11:01.0000] <AryehGregor>
erlehmann, the MPEG LA has separate patent pools for different formats.  If you're paying into the H.264 patent pool, that doesn't mean you get licenses to VP8 patents, even from the same parties.

[08:11:02.0000] <gsnedders>
*shipped

[08:11:03.0000] <gsnedders>
*effect

[08:11:04.0000] <AryehGregor>
gsnedders, damages, I think, not fine.  But that's true.

[08:11:05.0000] <erlehmann>
AryehGregor, to obstruct the web as a platform, of course. in before do not assume malice.

[08:11:06.0000] <gsnedders>
AryehGregor: What legally it is is rather non-important here :P

[08:12:00.0000] <annevk>
Since the initial argument Microsoft bought Skype

[08:12:01.0000] <AryehGregor>
erlehmann, I think there's decent evidence here of non-malice.

[08:12:02.0000] <AryehGregor>
Such as, they support WebM if you install the codec, which they don't do for any other format.

[08:12:03.0000] <AryehGregor>
And they publicly pledged that they'll support it if Google agrees to indemnify them.

[08:12:04.0000] <erlehmann>
they don't? isn't directShow like quicktime, supporting everything installed?

[08:12:05.0000] <gsnedders>
erlehmann: They whitelist it.

[08:13:00.0000] <AryehGregor>
Right.

[08:13:01.0000] <gsnedders>
erlehmann: To stop things like WMV from being used with video.

[08:13:02.0000] <erlehmann>
gsnedders, did not know that.

[08:13:03.0000] <AryehGregor>
Because a lot of codecs are dodgy and they don't want them exposed to the web.

[08:13:04.0000] <gsnedders>
erlehmann: The only video codecs they allow are H.264 and WebM.

[08:14:00.0000] <erlehmann>
how unfortunate for theora (hey, my laptop is from 2007).

[08:14:01.0000] <AryehGregor>
My prediction: MPEG LA announces a patent pool.  Google either buys out the patents, or declares they're blatantly invalid/inapplicable and offers to indemnify Microsoft and Apple against them, or changes VP8 to avoid them.

[08:14:02.0000] <erlehmann>
wellr, i am a behaviourist. actions speak louder than words, particularly regarding software.

[08:14:03.0000] <AryehGregor>
Microsoft and Apple will then support WebM.

[08:14:04.0000] <AryehGregor>
But I'm speculating here.

[08:15:00.0000] <gsnedders>
AryehGregor: That wouldn't make Opera/Mozilla/any other browser vendor happy.

[08:15:01.0000] <AryehGregor>
Which part?

[08:15:02.0000] <gsnedders>
Especially anyone wanting to move into the browser market, as they'd have a alrger risk than anyone else.

[08:15:03.0000] <erlehmann>
AryehGregor, even more so than microsoft, apple is not a friend of open formats when there is a position to hold.

[08:15:04.0000] <gsnedders>
AryehGregor: indemification

[08:16:00.0000] <erlehmann>
gsnedders is a very clever person.

[08:16:01.0000] <gsnedders>
erlehmann: I am? Okay. :D

[08:17:00.0000] <AryehGregor>
gsnedders, I'm guessing they'd either offer indemnification to Mozilla too, or only offer the indemnification secretly and require Microsoft/Apple to not admit to it, only say "Hey, Google convinced us to support it".

[08:17:01.0000] <AryehGregor>
I doubt they'd care about Opera.

[08:17:02.0000] <AryehGregor>
Opera will be forced to support it regardless if everyone else does.

[08:17:03.0000] <gsnedders>
AryehGregor: Then why both having us as one of the initial impls at WebM's original announcement?

[08:17:04.0000] <AryehGregor>
They want to have everyone possible.

[08:18:00.0000] <AryehGregor>
They also had, like, Grab Networks.

[08:18:01.0000] <AryehGregor>
I have no idea what that even is.

[08:18:02.0000] <AryehGregor>
. . . Actually, I don't see Opera here.

[08:18:03.0000] <AryehGregor>
Oh, I see.

[08:18:04.0000] <gsnedders>
AryehGregor: Håkon was there

[08:18:05.0000] <AryehGregor>
Opera gets called out in the start with Mozilla/Opera/Google Chrome/Adobe.

[08:19:00.0000] <AryehGregor>
Well, whatever.

[08:19:01.0000] <gsnedders>
At Google I/O.

[08:19:02.0000] <gsnedders>
AryehGregor: Also, if they care about mobile, not caring about us would be silly.

[08:19:03.0000] <AryehGregor>
That's very different from offering a potentially large sum of money to fight legal battles for you.

[08:19:04.0000] <AryehGregor>
http://www.mpegla.com/main/pid/vp8/default.aspx

[08:19:05.0000] <AryehGregor>
Feh, no details.

[08:19:06.0000] <AryehGregor>
Oh well.

[08:19:07.0000] <gsnedders>
We could just go down the road of not wanting to run the risk and just support H.264 on mobile.

[08:22:00.0000] <AryehGregor>
If MS and Apple support WebM, then congrats, you'd no longer be web-compatible.

[08:24:00.0000] <erlehmann>
AryehGregor, you are speculating. I bet two mozarella cheeseburgers with fried egg that in 6 months, neither Apple nor Microsoft will deliver a desktop or moible web browser supporting any of the following: Ogg. Vorbis, Theora, Matroska, VP8.

[08:24:01.0000] <AryehGregor>
erlehmann, I doubt this will take anywhere close to as short as six months.  There are lawyers involved.

[08:24:02.0000] <AryehGregor>
I'd guess more like within three years.

[08:25:00.0000] <erlehmann>
18 Months.

[08:25:01.0000] <erlehmann>
And four mozarella cheeseburgers.

[08:25:02.0000] <AryehGregor>
Eighteen months is possible, but I wouldn't bet on it.

[08:25:03.0000] <erlehmann>
See?

[08:25:04.0000] <AryehGregor>
I'd bet a modest sum on three years.

[08:25:05.0000] <AryehGregor>
Not cheeseburgers, though, they aren't kosher.  In fact, I'm not even allowed to have any benefit from them.  If you gave me one I'd have to throw it out.

[08:25:06.0000] <erlehmann>
Wat.

[08:26:00.0000] <AryehGregor>
Yus.

[08:26:01.0000] <erlehmann>
they don't mix milk and patties!

[08:26:02.0000] <erlehmann>
it is a fat blob of fried mozarella instead of meat.

[08:26:03.0000] <erlehmann>
in fact, i might just go out and get one.

[08:26:04.0000] <erlehmann>
now.

[08:26:05.0000] <erlehmann>
ha.

[08:27:00.0000] <erlehmann>
or write on some part of my blog engine.

[08:27:01.0000] <erlehmann>
hmm.

[08:27:02.0000] <AryehGregor>
Oh, that does sound appetizing.

[08:30:00.0000] <jgraham>
Fried mozarella?

[08:31:00.0000] <jgraham>
That sounds like a bad idea...

[08:32:00.0000] <AryehGregor>
It sounds extremely unhealthful, which makes it right up my alley.

[08:38:00.0000] <jgraham>
I was more concerned with the logistics of frying mozarella. It should melt!

[08:38:01.0000] <jgraham>
Also, this is the worst network I have ever been on

[08:39:00.0000] <annevk>
Is that the Avatar hotel?

[08:39:01.0000] <wilhelm>
I've seen worse. But yes, this high speed broadband really isn't.

[08:39:02.0000] <jgraham>
No, Hotel Zico

[08:39:03.0000] <jgraham>
I have like 50% packet loss

[08:40:00.0000] <annevk>
How is the weather?

[08:40:01.0000] <wilhelm>
12-20° and no clouds.

[08:46:00.0000] <annevk>
not too bad

[08:52:00.0000] <annevk>
do you need to update ESTA each time you go to the US?

[08:52:01.0000] <annevk>
I guess I better do it just in case

[09:40:00.0000] <dglazkov>
good morning, Whatwg!

[09:42:00.0000] <annevk>
good afternoon, dglazkov!

[09:44:00.0000] <dglazkov>
I just realized that the Whatwg cabal is slowly converging upon the San Francisco Bay Area

[09:45:00.0000] <annevk>
terrorists with the intent of slowing down development of the web would do good striking next week

[09:45:01.0000] <dglazkov>
one can easily visualize the map with red arrows punching through the georgraphy, WW2 style

[09:45:02.0000] <annevk>
hehe

[09:58:00.0000] <bfrohs>
Is there any chance of the label element receiving :valid, :invalid, :required capabilities in CSS? Use cases: 1) Adding an asterisk or other symbol after the text in a label that uses the for attribute. 2) Targeting elements that come after a label with an input child (<p>Label <label><input></label> <small>Text</small></p>)

[10:00:00.0000] <bfrohs>
3) Formatting the text in a label accordingly (e.g. different color or weight)

[10:04:00.0000] <timeless>
/me wants to see that map

[10:05:00.0000] <annevk>
bfrohs, I think the idea is to have a selector that allows selecting the associated label

[10:06:00.0000] <dglazkov>
timeless, jgraham should do it. He's already arrived, barely has any Internets -- perfect time for doodling.

[10:07:00.0000] <bfrohs>
annevk, that would be ideal. I guess I was just thinking that it would fall under the "can't have parent selectors" argument and would be easier to just set it on the label when setting it on the input.

[10:09:00.0000] <timeless>
heh

[10:28:00.0000] <TabAtkins>
bfrohs: "?label /for/ :invalid"

[10:29:00.0000] <TabAtkins>
/me likes combining together multiple crazy selectors.

[10:30:00.0000] <hober>
TabAtkins majored in crazy selector combinatorics

[10:30:01.0000] <TabAtkins>
Well, it was a minor with honors.

[10:30:02.0000] <hober>
ahh, fair enough

[10:31:00.0000] <bfrohs>
TabAtkins: Yeah, that's the general idea. Those are just hypothetical though, right? Not used in any browser?

[10:31:01.0000] <TabAtkins>
bfrohs: They exist only in spec right now.  No implementations yet.

[10:32:00.0000] <bfrohs>
TabAtkins: Have a link to said spec? So you guys can spend time on improving everything even more, instead of looking things up for me? ;)

[10:32:01.0000] <TabAtkins>
http://dev.w3.org/csswg/selectors4

[10:32:02.0000] <bfrohs>
Thank ya much :)

[10:33:00.0000] <TabAtkins>
Specifically http://dev.w3.org/csswg/selectors4/#subject and http://dev.w3.org/csswg/selectors4/#idref-combinators

[10:36:00.0000] <TabAtkins>
jgraham: You've never had a fried cheesestick before?

[10:37:00.0000] <bfrohs>
TabAtkins: http://dev.w3.org/csswg/selectors4/#subject -- Paragraph 3: "with or without the dollar sign" - should be "with or without the question mark", shouldn't it?

[10:37:01.0000] <jgraham>
TabAtkins: My arteries are clogging just thinking about it

[10:37:02.0000] <TabAtkins>
bfrohs: Yes, it was originally a dollar sign until we made fantasai change it.

[10:38:00.0000] <TabAtkins>
jgraham: Go to any low-budget italian place in america.

[10:38:01.0000] <TabAtkins>
Or a fair.

[10:38:02.0000] <bfrohs>
TabAtkins: Saving dollar sign for vars, perhaps? :)

[10:39:00.0000] <TabAtkins>
bfrohs: We *were*, but now we're shifting gears to a different design.

[10:52:00.0000] <zcorpan>
so uh, where's the webm video on bing's front page?

[10:53:00.0000] <hsivonen>
zcorpan: in Firefox--not in Opera :-(

[10:55:00.0000] <zcorpan>
i don't see it in firefox either

[10:59:00.0000] <hsivonen>
zcorpan: do you see a woodpecker on the front page?

[10:59:01.0000] <hsivonen>
zcorpan: do you have an en-US version of Firefox?

[11:00:00.0000] <hsivonen>
zcorpan: having you chosen United States as your Bing locale?

[11:00:01.0000] <hsivonen>
s/having/have/

[11:02:00.0000] <hsivonen>
it seems you need to choose United States to see a woodpecker

[11:02:01.0000] <hsivonen>
and then Opera gets a still woodpecker and Firefox gets a video of a woodpecker

[11:03:00.0000] <zewt>
it's pining for the fjords

[11:07:00.0000] <zcorpan>
hsivonen: needed to change the bing locale to US

[11:07:01.0000] <zcorpan>
hsivonen: i can mask as firefox in opera to get the video

[11:12:00.0000] <zcorpan>
hmm the bing home page used a lot of cpu for me (in both firefox and opera)

[11:25:00.0000] <bfrohs>
TabAtkins: Just realized that the code you gave me ("?label /for/ :invalid") won't work for use case #2: Targeting elements that come after a label with an input child (<p>Label <label><input></label> <small>Text</small></p>)

[11:26:00.0000] <TabAtkins>
bfrohs: Correct.  This is why I don't like the subject indicator very much.  It would be better to use :has().

[11:26:01.0000] <TabAtkins>
bfrohs: "label:has( :scope /for/ :invalid ) + small

[11:26:02.0000] <TabAtkins>
Alternately, use Hierarchies to get the same functionality (this is silly, though):

[11:26:03.0000] <zcorpan>
can:has(cheezeburger)

[11:27:00.0000] <TabAtkins>
"?label /for/ :invalid { & + small { <properties go here> } }

[11:27:01.0000] <bfrohs>
But won't both :has and nesting with subject specified lead to parent relationships that vendors have said no to for years due to performance issues?

[11:28:00.0000] <TabAtkins>
The subject indicator all by itself leads to those problems.

[11:28:01.0000] <TabAtkins>
But yes.  We're trying to push on it to see if they're usable in practice these days.

[11:28:02.0000] <bfrohs>
Well, to an extent, but it isn't in a loop

[11:29:00.0000] <bfrohs>
Once you add nesting (and force them to use the subject, rather than the normal hierarchy), or add :has(), it will have a loop that will cause *more* of an issue.

[11:29:01.0000] <bfrohs>
I think that's been the main reason behind it (but only one deep isn't as bad).

[11:30:00.0000] <bfrohs>
Whereas if :invalid and all of that was also available to label, this could be avoided

[11:30:01.0000] <bfrohs>
I think it would be an easier idea for vendors to accept, but I could be wrong.

[11:32:00.0000] <mbatle_>
anybody knows if any browser is implementing mediagroup property in media elements ?

[12:01:00.0000] <AryehGregor>
jgraham, proposed testharness patch for review: http://pastebin.com/1MLYd24H

[12:02:00.0000] <AryehGregor>
Currently the specs say RangeException shouldn't exist, and there are new exception types added to DOMException that browsers don't implement yet, so the preexisting code was incorrect.

[12:03:00.0000] <AryehGregor>
E.g., if INVALID_NODE_TYPE_ERR is supported on DOMException, then assert_throws("INVALID_NODE_TYPE_ERR", ...) will expect that, but if it's not, it will expect a RangeException.

[12:04:00.0000] <AryehGregor>
This means that Gecko incorrectly passes many tests in http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Range-selectNode.html that WebKit fails, because WebKit implements the new INVALID_NODE_TYPE_ERR.

[12:04:01.0000] <hsivonen>
I probably should have saved a pre-HTML5 parser WebKit-based browser somewhere...

[12:04:02.0000] <AryehGregor>
Why?

[12:05:00.0000] <hsivonen>
I wonder if Android has an outdated WebKit

[12:05:01.0000] <hsivonen>
AryehGregor: for testing

[12:05:02.0000] <AryehGregor>
Why would you want to test browsers that have rapidly become so obscure?

[12:06:00.0000] <AryehGregor>
Chrome that old is massively irrelevant, and Safari/other WebKit that old must have tiny market share by now.

[12:06:01.0000] <hsivonen>
AryehGregor: to figure out if we changed something in HTML5

[12:07:00.0000] <hsivonen>
turns out that WebKit in Android 3.1 is too fresh. (I'm surprised. The Android stock browser has a reputation of being behind the times.)

[12:08:00.0000] <AryehGregor>
Is othermaciej on vacation or something?  I haven't seen him say anything for a long time now.

[12:08:01.0000] <AryehGregor>
Oh, he talked yesterday.

[12:08:02.0000] <AryehGregor>
Okay, so he still exists.

[12:12:00.0000] <smaug____>
hsivonen: are you still trying to test document.close() handling

[12:13:00.0000] <smaug____>
hsivonen: and sorry, I was offline for some time. What was the reason to append EOF and not insert it?

[12:14:00.0000] <hsivonen>
smaug____: I'm testing my reimplementation of the buffer queue management at this point. I think the code I have for document.close() doesn't need more testing today

[12:14:01.0000] <hsivonen>
smaug____: the reason for appending is that you can do:

[12:14:02.0000] <hsivonen>
doc.open();

[12:14:03.0000] <hsivonen>
doc.write("<script src=whatever.js></script>);

[12:14:04.0000] <hsivonen>
doc.write("something else");

[12:15:00.0000] <hsivonen>
doc.close();

[12:15:01.0000] <hsivonen>
and have "something else" appear in the document

[12:16:00.0000] <smaug____>
well, I would assume doc.write("<script src=whatever.js></script>); would insert something to stream and keep the stream "open" until the script is executed. After that "Something else" would be inserted

[12:16:01.0000] <smaug____>
and then doc.close

[12:16:02.0000] <smaug____>
since that is the order of insertion

[12:17:00.0000] <hsivonen>
smaug____: okay, better example: assume the doc.write("something else"); statement is in whatever.js instead

[12:18:00.0000] <smaug____>
and ?

[12:18:01.0000] <smaug____>
that would insert "something else".

[12:18:02.0000] <hsivonen>
smaug____: in that case, document.write("something else"); executes after document.close();, but you still want "something else" to appear in the document

[12:19:00.0000] <smaug____>
right

[12:19:01.0000] <smaug____>
but that document.write() would insert something to be before the EOF

[12:19:02.0000] <hsivonen>
smaug____: yes

[12:20:00.0000] <smaug____>
so that would work just fine

[12:20:01.0000] <hsivonen>
smaug____: oh, you meant why document.close() appends when called from a nested script

[12:20:02.0000] <smaug____>
well, in any case

[12:20:03.0000] <hsivonen>
smaug____: I'm going to go with "that's the way document.close() works"

[12:20:04.0000] <smaug____>
why it doesn't insert EOF but appends

[12:21:00.0000] <smaug____>
hsivonen: ok

[12:22:00.0000] <smaug____>
hsivonen: do you know if this behavior was actually defined based on how browsers behave

[12:22:01.0000] <hsivonen>
smaug____: I don't recall anymore

[12:22:02.0000] <smaug____>
k

[12:22:03.0000] <hsivonen>
let's see what my clashtest does in Firefox 3.5

[12:23:00.0000] <smaug____>
would be interesting to know what IE6-8 do

[12:23:01.0000] <hsivonen>
smaug____: HTML5 specs old Firefox-style document.write()

[12:23:02.0000] <hsivonen>
IE8 was different

[12:23:03.0000] <smaug____>
hsivonen: but this is about document.close, not document.write ;)

[12:25:00.0000] <hsivonen>
AryehGregor: see this is what old browsers are kept around for

[12:26:00.0000] <hsivonen>
smaug____: IE8 hangs

[12:26:01.0000] <hsivonen>
w00t. I have discovered two ways to hang IE8 today

[12:26:02.0000] <hsivonen>
smaug____: Firefox 3.5 behaves like HTML5 says

[12:30:00.0000] <smaug____>
that doesn't mean I like what the spec defines

[12:30:01.0000] <hsivonen>
smaug____: would it be possible to define document.write and document.close in a likeable way?

[12:31:00.0000] <smaug____>
document.close could insert EOF

[12:31:01.0000] <smaug____>
not append

[12:31:02.0000] <smaug____>
but, again, I'm not very familiar with parsing, so perhaps there is some reason for the current behavior

[12:31:03.0000] <hsivonen>
smaug____: I'd rather rock the boat based on aesthetics and stick to something that's known to be successful on the Web

[12:32:00.0000] <smaug____>
it is strange that some data can be inserted to document after document.close()

[12:32:01.0000] <smaug____>
hsivonen: yeah, I guess I don't care too much

[12:32:02.0000] <hsivonen>
I'd rather *not* rock the boat

[12:33:00.0000] <hsivonen>
smaug____: the possibility of calling document.write() on a document.open()ed doc from scripts that are neither the one that called open() nor scripts that are in the open()ed doc bothers me more

[12:33:01.0000] <hsivonen>
smaug____: particularly that those other scripts can run from nested event loops

[12:35:00.0000] <AryehGregor>
TabAtkins, does something define how to determine the actual value for numeric markers?  E.g., saying what number to display if you have <ol><li style=display:none>abc<li>def</ol>, or style=list-style:none, or whatever?

[12:36:00.0000] <AryehGregor>
It seems changing the display causes it to be skipped, at least in Gecko and WebKit, but I didn't see that in a glance at the spec.

[12:40:00.0000] <hober>
AryehGregor: yes, that's in the lists module; let me try to find the spot

[12:41:00.0000] <TabAtkins_>
AryehGregor: Yes, 2.1 defines that.

[12:41:01.0000] <hober>
AryehGregor: http://dev.w3.org/csswg/css3-lists/#declaring-a-list-item

[12:42:00.0000] <hober>
AryehGregor: "To declare a list item, the 'display' property must be set to 'list-item' or 'inline-list-item' (defined later in this section). This, in addition to generating a ::marker pseudo-element and enabling the properties described below for that element, causes that element to increment the list item counter 'list-item'."

[12:42:01.0000] <AryehGregor>
Ah, I see.

[12:42:02.0000] <AryehGregor>
Thanks.

[12:42:03.0000] <AryehGregor>
/me was looking at the TR -- of course -- but it says the same thing

[12:45:00.0000] <TabAtkins_>
AryehGregor: I intend to work on fixing 'display', such that the special behavior of "list-item" can be triggered independently of the layout.

[12:46:00.0000] <AryehGregor>
Yes, that would be awesome.

[12:46:01.0000] <TabAtkins_>
Since "list-item" is really just "block with magic"

[12:46:02.0000] <AryehGregor>
Things like inline-block really need to die.

[12:47:00.0000] <hober>
well, display-inside and display-outside need to happen

[12:47:01.0000] <TabAtkins_>
Yup.

[12:47:02.0000] <AryehGregor>
While we're talking about CSS, can someone explain to me why there's an extra line break after the steps with comments here in Gecko but not WebKit?  http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#methods-to-query-and-execute-commands

[12:48:00.0000] <AryehGregor>
Like after steps 3 and 4 at the top there.

[12:48:01.0000] <AryehGregor>
I remember I tried to figure it out once before and gave up.

[12:49:00.0000] <TabAtkins_>
AryehGregor: It's because the exact treatment of the (currently implicit) ::marker is undefined.

[12:49:01.0000] <AryehGregor>
Oh.

[12:49:02.0000] <AryehGregor>
Great.

[12:50:00.0000] <TabAtkins_>
Firefox treats it as an inline element, which creates a linebox, and forces the block (<div> element) below it.

[12:50:01.0000] <TabAtkins_>
(The behavior now defined in Lists matches Chrome here.  More propertly, it's almost exactly IE's behavior, which is the sanest of anyone.)

[12:51:00.0000] <AryehGregor>
I can't seem to easily come up with a minimal test-case, though.

[12:51:01.0000] <TabAtkins_>
I came up with plenty during testing.  One sec.

[12:51:02.0000] <AryehGregor>
Also, IIRC, IE displayed them like Gecko.

[12:53:00.0000] <jgraham>
Hmm, I wonder what the lowest-hanging fruit is in terms of untested stuff in HTML5

[12:54:00.0000] <jgraham>
And by "untested" I mean "wihout a test in the offical repo"

[12:56:00.0000] <AryehGregor>
jgraham, good grief, practically nothing is tested.  Just start at page one.

[12:56:01.0000] <jgraham>
AryehGregor: Yeah, I know :)

[12:57:00.0000] <jgraham>
I just want something that is both stupidly simple and useful

[12:57:01.0000] <jgraham>
It is the "simple" part that is difficult

[12:57:02.0000] <jgraham>
"useful" can be determined by sticking  a pin in the spec at random and assuming there are no tests

[12:59:00.0000] <TabAtkins_>
Hm, I'm having trouble reducing a testcase too.  >_<

[13:00:00.0000] <TabAtkins_>
Oh man, Firefox has a native inspector now!

[13:00:01.0000] <TabAtkins_>
It's not very good yet, but still.

[13:01:00.0000] <gsnedders>
jgraham: Do you mean simple as in to test the whole feature?

[13:01:01.0000] <AryehGregor>
It's had one for a while.

[13:02:00.0000] <AryehGregor>
jgraham, I don't know why you use the word "assume" there.

[13:04:00.0000] <smaug____>
strange that in Gecko and Presto <a> can be used in place of <area>.  Don't know about old IEs

[13:05:00.0000] <jgraham>
gsnedders: Not really

[13:06:00.0000] <jgraham>
Alhough if that was possible it would be double plus good

[13:06:01.0000] <smaug____>
oh, cvs commit says this is because of HTML4 ...

[13:07:00.0000] <smaug____>
or no

[13:08:00.0000] <timeless>
smaug____: i presume you're going to tpac?

[13:09:00.0000] <smaug____>
I'm not

[13:10:00.0000] <timeless>
aww

[13:10:01.0000] <jgraham>
timeless: No need to assume; http://www.w3.org/2002/09/wbs/35125/TPAC2011/registrants

[13:11:00.0000] <AryehGregor>
TabAtkins_, okay, so sometimes refreshing the exact same document repeatedly in Gecko will change whether the effect occurs.

[13:11:01.0000] <timeless>
jgraham: i don't suppose there's a ?groupby=sponsor

[13:12:00.0000] <jgraham>
timeless: Not that I know of

[13:12:01.0000] <AryehGregor>
TabAtkins_, I strongly suspect that in the case of my page, it's a timing issue, because the floated buttons are created by script.

[13:12:02.0000] <smaug____>
oh, Gecko and Presto do actually work per HTML4 spec

[13:12:03.0000] <timeless>
> Virginie GALINDO <virginie.galindo⊙gc> () : attending Thursday, Friday

[13:12:04.0000] <timeless>
is interesting, how did that person end up w/o content in ()?

[13:12:05.0000] <AryehGregor>
If they're created fast enough, it seems to be fine.

[13:12:06.0000] <smaug____>
I wonder how support for <a> got removed from HTML spec

[13:13:00.0000] <AryehGregor>
Including if they're in the original DOM.

[13:15:00.0000] <timeless>
AryehGregor: hey, i'm looking for someone @google who can pass along a bug report about gmm

[13:15:01.0000] <AryehGregor>
timeless, I'm not @google.

[13:15:02.0000] <AryehGregor>
In any meaningful sense, other than that they give me money occasionally.

[13:15:03.0000] <timeless>
i'm open to suggestions :)

[13:16:00.0000] <timeless>
oh, TabAtkins ?

[13:16:01.0000] <timeless>
/me pokes

[13:18:00.0000] <AryehGregor>
TabAtkins_, got it!  http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1237

[13:19:00.0000] <AryehGregor>
It seems like it reserves space for the thing and then doesn't reflow properly when it moves.

[13:22:00.0000] <AryehGregor>
That's why it was so hard to track down.

[13:22:01.0000] <smaug____>
Hixie: do you remember the reason why HTML spec removes coords and shape from <a> element, and also removes support for <a> inside <map> ?

[13:22:02.0000] <wilhelm>
Agenda for the testing meeting tomorrow: http://lists.w3.org/Archives/Public/public-test-infra/2011OctDec/0014.html

[13:26:00.0000] <AryehGregor>
Ooh.  Now it doesn't reproduce properly anymore.

[13:26:01.0000] <AryehGregor>
Of course.

[13:27:00.0000] <AryehGregor>
. . .

[13:27:01.0000] <AryehGregor>
/me doesn't know what to do now

[13:27:02.0000] <AryehGregor>
It repros consistently in Live DOM Viewer, but not in a data URL.

[13:28:00.0000] <Hixie>
smaug____: only firefox implemented it

[13:28:01.0000] <smaug____>
also Opera

[13:29:00.0000] <Hixie>
and nobody used it

[13:29:01.0000] <smaug____>
that is possible

[13:29:02.0000] <smaug____>
I'm trying to decide whether  to remove support for it

[13:29:03.0000] <Hixie>
i vote yes :-)

[13:30:00.0000] <AryehGregor>
Oooh, I think I see.

[13:30:01.0000] <smaug____>
but it was basically random removal based on that IE didn't support it

[13:30:02.0000] <AryehGregor>
It must be something to do with margins.

[13:30:03.0000] <smaug____>
but yeah, I think it should be ok to remove it

[13:30:04.0000] <Hixie>
smaug____: it's not a compelling feature, very few people use it, and the feature it's a part of (image maps) is itself not a compelling feature

[13:30:05.0000] <Hixie>
smaug____: but it has a non-trivial level of complexity

[13:30:06.0000] <AryehGregor>
Well, it should still not be dependent on how the DOM was created.

[13:30:07.0000] <Hixie>
smaug____: so imho it's a good candidate for removal

[13:31:00.0000] <Hixie>
smaug____: we don't get many :-(

[13:31:01.0000] <smaug____>
yup

[13:31:02.0000] <smaug____>
I think I'll add a warning that the feature is deprecated

[13:31:03.0000] <smaug____>
and remove it later

[13:31:04.0000] <Hixie>
seems reasonable

[13:31:05.0000] <Hixie>
does mozilla have any way of instrumenting how often a warning triggers?

[13:32:00.0000] <smaug____>
I could add a telemetry probe

[13:32:01.0000] <smaug____>
but telemetry is opt-in

[13:32:02.0000] <smaug____>
ofc

[13:32:03.0000] <Hixie>
btw when i was doing research on this i found it was used extremely rarely in image maps, but that a number of authoring tools would put the attributes on <a> with their default values

[13:32:04.0000] <Hixie>
so you might see an elevated number of <a shape="rect" coords=""> elements despite them not being part of actual image maps

[13:33:00.0000] <smaug____>
right

[13:33:01.0000] <Hixie>
which is to say, if you do set up telemetry, i'd make sure to distinguish <a>s actually used in image maps from those just with those attributes for no good reaosn

[13:34:00.0000] <Hixie>
hsivonen: yt?

[13:34:01.0000] <Hixie>
hsivonen: re defining the term "xhtml document", an alternative is for me to drop all usage of the term. Would that be acceptable, or do you prefer a definition?

[13:35:00.0000] <Hixie>
hsivonen: if the latter, do you want it to refer to the byte stream, or to the DOM structure?

[13:40:00.0000] <Hixie>
annevk: i think we may have to seriously consider renaming the terms "html document" and "xml document" so that they don't get confused with references to text/html documents and text/html documents.

[13:43:00.0000] <AryehGregor>
Okay, can other people reproduce my minimal test-case here with various Firefox versions, or am I just insane?  https://bugzilla.mozilla.org/show_bug.cgi?id=697793

[13:44:00.0000] <AryehGregor>
annevk, does anything still throw a WRONG_DOCUMENT_ERR, or should it be marked historical?

[13:47:00.0000] <AryehGregor>
annevk, filed a bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14576

[14:01:00.0000] <smaug____>
AryehGregor: Gecko seems to use that still in Range code

[14:01:01.0000] <AryehGregor>
smaug____, the spec says it shouldn't, though, AFAIK.  Where does it use it?

[14:01:02.0000] <AryehGregor>
Generally we prefer to silently adopt the node.

[14:01:03.0000] <AryehGregor>
It's friendlier.

[14:02:00.0000] <smaug____>
AryehGregor: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-range-ispointinrange

[14:02:01.0000] <smaug____>
"WrongDocumentError"

[14:02:02.0000] <AryehGregor>
Aha.

[14:02:03.0000] <AryehGregor>
I was searching for the wrong string.

[14:02:04.0000] <AryehGregor>
Duh.

[14:02:05.0000] <AryehGregor>
Thanks.

[14:02:06.0000] <smaug____>
and that is, IMO, a valid use case

[14:03:00.0000] <AryehGregor>
It actually seems friendlier to just return false in that case, IMO.

[14:03:01.0000] <AryehGregor>
But it's reasonable, yeah.

[14:03:02.0000] <AryehGregor>
(I mean, if it's in a different tree, it's not in the range, right?)

[14:05:00.0000] <smaug____>
but it is not quite outside the range either

[14:05:01.0000] <smaug____>
it is just invalid state for the parameter or something

[14:06:00.0000] <smaug____>
so a case when throwing is ok

[14:06:01.0000] <smaug____>
though, I guess specs aren't consistent

[14:06:02.0000] <smaug____>
node.contains() doesn't throw

[14:06:03.0000] <AryehGregor>
If I were writing it from scratch, I'd return false.  Seems less surprising.  But it's okay as-is, if that's what browsers do.

[14:07:00.0000] <AryehGregor>
I didn't write or test that method, so I dunno.

[14:09:00.0000] <hsivonen>
Hixie: I think it's good to have a definion for an XHTML document, because we've spent years saying that HTML5 has an XML flavor called XHTML5

[14:09:01.0000] <AryehGregor>
smaug____, data:text/html,<!doctype html><script>try {document.createRange().isPointInRange(document.createElement("a"), 0); throw "No exception"} catch(e) {alert(e)}</script> alerts "No exception" for me in both Gecko and WebKit.

[14:09:02.0000] <Hixie>
hsivonen: see the bug, i checked in some changes

[14:15:00.0000] <smaug____>
AryehGregor: oh, indeed

[14:15:01.0000] <smaug____>
AryehGregor: but comparePoints throws in Gecko

[14:16:00.0000] <AryehGregor>
That makes sense.

[14:16:01.0000] <AryehGregor>
There's no sensible return value for that case.

[14:19:00.0000] <AryehGregor>
Oh, I think I found an infinite loop in my spec.

[14:19:01.0000] <TabAtkins_>
AryehGregor: I suspect it's a stale painting bug, then.

[14:19:02.0000] <AryehGregor>
Yippee!

[14:19:03.0000] <Hixie>
don't you hate that

[14:22:00.0000] <annevk>
Hixie, we could have a "HTMLness flag"

[14:22:01.0000] <Hixie>
yeah

[14:22:02.0000] <annevk>
Hixie, because that's essentially what it comes down to anyway

[14:22:03.0000] <Hixie>
though frankly i'm a little scared of changing this

[14:23:00.0000] <Hixie>
because it would mean going through the whole spec changing zillions of little sentences

[14:23:01.0000] <annevk>
for the DOM it's relatively straightforward

[14:23:02.0000] <Hixie>
and would surely lead to mistakes

[14:23:03.0000] <annevk>
I'm willing to review the result

[14:23:04.0000] <Hixie>
maybe one day

[14:23:05.0000] <annevk>
k

[14:27:00.0000] <annevk>
TabAtkins, /for/ does not cover all <label> scenarios

[14:28:00.0000] <annevk>
TabAtkins, I guess the other one is covered by ?label input but it's annoying that you have to spell it out like that

[14:29:00.0000] <Hixie>
wtf is ?label

[14:35:00.0000] <AryehGregor>
Hmm.

[14:37:00.0000] <TabAtkins_>
Hixie: ? is the "subject indicator", which changes the subject of a selector.

[14:37:01.0000] <AryehGregor>
What should commands like insertOrderedList do if the editing host is an inline element?

[14:37:02.0000] <TabAtkins_>
annevk: I agree.

[14:37:03.0000] <AryehGregor>
Insert a list anyway, or refuse to do anything, or what?

[14:37:04.0000] <Hixie>
TabAtkins_: aw man, i thought we'd done away with the idea of selecting anything but the end of the selector years ago

[14:37:05.0000] <Hixie>
TabAtkins_: how did that make a comeback?

[14:38:00.0000] <AryehGregor>
Gecko seems to refuse to do anything, even if it would make sense to do something.  WebKit seems to just eat the editing host.

[14:39:00.0000] <TabAtkins_>
Hixie: It's a persistent author request.

[14:39:01.0000] <AryehGregor>
Opera behaves somewhat sensibly, for once.

[14:39:02.0000] <AryehGregor>
TabAtkins_, I thought it will kill perf.

[14:39:03.0000] <Hixie>
TabAtkins_: doesn't :matches() take care of it?

[14:39:04.0000] <AryehGregor>
?foo bar = ancestor selector.

[14:39:05.0000] <TabAtkins_>
AryehGregor: That's the fear.  We're pushing to see if we can get around that, or at least make it "good enough".

[14:39:06.0000] <Hixie>
or :has()?

[14:39:07.0000] <TabAtkins_>
Hixie: ? is equivalent to :has(), if you limit :has() to the end of the selector.

[14:39:08.0000] <TabAtkins_>
(I prefer :has().)

[14:40:00.0000] <AryehGregor>
TabAtkins_, how is it even conceptually possible to support ?foo bar without killing perf?

[14:40:01.0000] <Hixie>
TabAtkins_: so why '?"

[14:40:02.0000] <TabAtkins_>
AryehGregor: Shrug.  Browsers be crazy.

[14:40:03.0000] <Hixie>
wow i got confused with punctuation there

[14:40:04.0000] <Hixie>
let me try that again

[14:40:05.0000] <Hixie>
TabAtkins_: so why "?"?

[14:40:06.0000] <TabAtkins_>
Hixie: Because fantasai prefers that, and she's the Selectors editor.

[14:40:07.0000] <Hixie>
aah

[14:40:08.0000] <Hixie>
well that makes sense

[14:40:09.0000] <Hixie>
ok

[14:41:00.0000] <AryehGregor>
/me would prefer a :thingie(), to avoid more cryptic punctuation in CSS

[14:41:01.0000] <AryehGregor>
What does :has() do?

[14:41:02.0000] <TabAtkins_>
AryehGregor: Matches an element if it has something.

[14:41:03.0000] <AryehGregor>
Meaning?

[14:41:04.0000] <AryehGregor>
Like a descendant or something?

[14:41:05.0000] <TabAtkins_>
So, to match a label that has an invalid input, do "label:has( :scope /for/ :invalid )"

[14:41:06.0000] <Hixie>
:has() is like :matches() except that the selector is assumed to start with a simple selector that selects the element on which the pseudo is

[14:41:07.0000] <AryehGregor>
That sounds like it would suffer from the same horrible perf issues.

[14:41:08.0000] <AryehGregor>
What's wrong with :for()?

[14:42:00.0000] <AryehGregor>
Could we keep syntax simple here?

[14:42:01.0000] <Hixie>
and yes, :matches, :has, and ? are all horrible for perf

[14:42:02.0000] <Hixie>
i'm surprised browsers are ok with any of them

[14:42:03.0000] <TabAtkins_>
AryehGregor: :for() only goes one way.

[14:42:04.0000] <TabAtkins_>
Hixie: Nobody's implemented one yet.  ^_^

[14:42:05.0000] <AryehGregor>
I doubt anyone will, based on past statements.

[14:42:06.0000] <TabAtkins_>
AryehGregor: In general, /foo/ is a reference combinator, following the idref named in the combinator.

[14:42:07.0000] <AryehGregor>
Except perhaps for querySelector().

[14:43:00.0000] <TabAtkins_>
We don't yet have an established syntax for functional combinators.

[14:43:01.0000] <TabAtkins_>
Though perhaps we should invent one.

[14:44:00.0000] <annevk>
the /idref/ thing is crazy though, because it also works for elements that do not have a predefined relationship

[14:47:00.0000] <Hixie>
annevk: no different from how [foo~=bar] also works for attributes that don't exist or don't take a space-separated list

[14:52:00.0000] <hsivonen>
I see "This might be overkill." in the commit message for "palpable content". No kidding.

[14:52:01.0000] <hsivonen>
/me mumbles about the time when Opera ignored empty paragraphs thanks to HTML4

[14:53:00.0000] <Hixie>
heh

[14:53:01.0000] <Hixie>
at least this text clearly only applies to conformance checkers, or even not those but to linters.

[14:58:00.0000] <ojan>
Hixie: webkit and gecko have implemented :matches, but as :any

[14:58:01.0000] <ojan>
Hixie: why is :matches bad for perf?

[14:59:00.0000] <TabAtkins_>
ojan: Hixie's talking about something else that happens to have the same name.

[14:59:01.0000] <ojan>
oh

[14:59:02.0000] <Hixie>
ojan: what does :any() do?

[14:59:03.0000] <ojan>
um...ok

[14:59:04.0000] <TabAtkins_>
ojan: His old proposal, basically identical to :has(), was called :matches().

[14:59:05.0000] <TabAtkins_>
Hixie: :any() takes a list of selectors, and matches any of them.

[14:59:06.0000] <ojan>
TabAtkins_: oh, that's totally different

[14:59:07.0000] <ojan>
nm

[14:59:08.0000] <TabAtkins_>
Hixie: It can be thought of as a selector macro.

[14:59:09.0000] <Hixie>
simple selectors, or selector chains?

[15:00:00.0000] <Hixie>
as in, are combinators involved?

[15:00:01.0000] <ojan>
Hixie: it's currently specced as "a sequence of simple selectors" i believe

[15:00:02.0000] <TabAtkins_>
Hixie: ":any(ul,ol) :any(ul,ol) {}" is equal to "ul ul, ul ol, ol ul, ol ol".

[15:00:03.0000] <ojan>
Hixie: currently no

[15:00:04.0000] <Hixie>
ah ok

[15:00:05.0000] <Hixie>
so basically just an "or"

[15:00:06.0000] <ojan>
Hixie: yeah

[15:00:07.0000] <TabAtkins_>
Hixie: Yeah, no combinators.  List of compound selectors.

[15:00:08.0000] <TabAtkins_>
Using the current Selectors4 terminology.

[15:00:09.0000] <ojan>
even with combinators it would still just be an "or" no?

[15:00:10.0000] <annevk>
Hixie, true enough, not sure how much sense that made

[15:00:11.0000] <ojan>
any(div > span, #foo)

[15:00:12.0000] <TabAtkins_>
ojan: It's less clear what's going on if combinators are involved, unless you define it basically as a macro.

[15:01:00.0000] <ojan>
TabAtkins_: i don't see what's unclear about it

[15:01:01.0000] <TabAtkins_>
(I think it *should* be defined that way.)

[15:01:02.0000] <ojan>
TabAtkins_: I guess I only see one way to define it

[15:02:00.0000] <ojan>
TabAtkins_: conceptually, when seeing if a element matches the selector, you evaluate each selector in the list and it matches if any of them do.

[15:02:01.0000] <ojan>
TabAtkins_: what am i missing?

[15:02:02.0000] <TabAtkins_>
ojan: Another way to define it is to match an element to any of the selectors within.  It's somewhat less clear what that means if you have complex selectors.

[15:03:00.0000] <ojan>
TabAtkins_: i don't understand the difference

[15:03:01.0000] <TabAtkins_>
ojan: You *can't* just say "does the element match 'div span' or 'p' in ':any(div span, p)'?".

[15:03:02.0000] <TabAtkins_>
"foo :any(bar baz, qux)" is equivalent to "foo bar baz, foo qux", not "foo bar baz, foo qux, bar foo baz".

[15:04:00.0000] <TabAtkins_>
There's an ordering constraint in there.

[15:04:01.0000] <Hixie>
wow that's confusing

[15:04:02.0000] <ojan>
TabAtkins_: yes, i don't see how that's controversial

[15:04:03.0000] <ojan>
or confusing

[15:04:04.0000] <ojan>
it seems to me like the obvious meaning

[15:04:05.0000] <ojan>
Hixie: which one is confusing?

[15:04:06.0000] <TabAtkins_>
ojan: If you define it as just "does the element match any of the arguments?", it's unclear which of those interpretations you want.

[15:05:00.0000] <TabAtkins_>
I think it's obvious, yes, but you have to define it properly.

[15:05:01.0000] <Hixie>
ojan: that :any(...).a > :any(...).b might match a situation where .a and .b are not parent and child respectively

[15:05:02.0000] <TabAtkins_>
Hixie: No, you misunderstand.

[15:05:03.0000] <ojan>
TabAtkins_: sure, but if you define it the obvious way, what is the perf problem?

[15:06:00.0000] <ojan>
Hixie: i don't see how

[15:06:01.0000] <TabAtkins_>
Hixie: In ".a :any(.b .c, .d)", if you go with the 'simple' interpretation of "does the element match any selector, when evaluated globally?", the following are equivalent:

[15:06:02.0000] <TabAtkins_>
.a .b .c, .b .a .c, .a.b .c, .a .d

[15:07:00.0000] <TabAtkins_>
Because the unrestricted "does it match?" question loses the constraints you want.

[15:07:01.0000] <Hixie>
TabAtkins_: so what does :any(q r, s).a > :any(w x, y).b expand to?

[15:07:02.0000] <TabAtkins_>
In the *proper* way of doing it, or the sillier way I just talked about?

[15:07:03.0000] <ojan>
TabAtkins_: lets just talk the proper way

[15:08:00.0000] <ojan>
TabAtkins_: the silly way is clearly crazy

[15:08:01.0000] <Hixie>
TabAtkins_: whatever you think is the right way

[15:08:02.0000] <TabAtkins_>
In the proper way, it's "q r.a > w x.b, q r.a > y.b, s.a > w x.b, s.a > y.b".

[15:08:03.0000] <Hixie>
ok so like i said, it means :any(...).a > :any(...).b might match a situation where .a and .b are not parent and child respectively

[15:08:04.0000] <TabAtkins_>
Huh?

[15:08:05.0000] <TabAtkins_>
How did you get that?

[15:09:00.0000] <Hixie>
it can match in a situation where <r class=a> is the grandparent of <x class=b>

[15:09:01.0000] <TabAtkins_>
Oh, yes.

[15:09:02.0000] <TabAtkins_>
If you allow complex selectors, not just compound.

[15:10:00.0000] <ojan>
Hixie: oh i see...meh. i don't see the problem with that.

[15:10:01.0000] <ojan>
Hixie: it's a contrived example that you wouldn't really hit in the real world

[15:10:02.0000] <Hixie>
on what do you base that?

[15:10:03.0000] <TabAtkins_>
Hixie: Right now, though, we restrict it to taking compound selectors.

[15:11:00.0000] <ojan>
Hixie: let me rephrase....

[15:11:01.0000] <TabAtkins_>
So the .a and .b elements will always have a parent-child relationship.

[15:11:02.0000] <ojan>
Hixie: what TabAtkins_ said...there is always a parent-child relationship there...

[15:11:03.0000] <Hixie>
come gain?

[15:11:04.0000] <ojan>
Hixie: which, if you were to write it without :any would have the same problem

[15:11:05.0000] <TabAtkins_>
ojan: No, Hixie's right given the higher-powered version of :any

[15:12:00.0000] <Hixie>
now i'm really confused :-P

[15:12:01.0000] <ojan>
Maybe i'm not understanding....

[15:12:02.0000] <TabAtkins_>
ojan: It's just that, in the current spec, we have a lower-powered version that doesn't have the problem.

[15:12:03.0000] <Hixie>
but we may be talking at cross-purposes

[15:12:04.0000] <ojan>
we need a DOM for this example

[15:12:05.0000] <TabAtkins_>
"problem"

[15:12:06.0000] <Hixie>
anyway

[15:12:07.0000] <ojan>
TabAtkins_: i get that the current version doesn't have the issue

[15:12:08.0000] <Hixie>
/me goes back to picketing for his original :matches(), despite the perf isues

[15:12:09.0000] <ojan>
in either case, there's no perf issue if we allow combinators

[15:12:10.0000] <ojan>
it's just a question of whether the semantics are confusing

[15:13:00.0000] <TabAtkins_>
Hixie: You really need to stop calling it "matches".  It confuses everyone else.  ^_^

[15:13:01.0000] <TabAtkins_>
ojan: Yes, that's right.

[15:13:02.0000] <ojan>
=TabAtkins_

[15:13:03.0000] <ojan>
:matches is way overloaded now

[15:13:04.0000] <Hixie>
TabAtkins_: hey, dude, i made it up first. :-P

[15:13:05.0000] <TabAtkins_>
Hixie: Too bad!

[15:13:06.0000] <Hixie>
TabAtkins_: plus, :matches() is _exactly_ what it does

[15:13:07.0000] <ojan>
I still would like to see the selectors4 spec s/matches/any/

[15:13:08.0000] <Hixie>
TabAtkins_: the other one should be renamed :or()

[15:13:09.0000] <AryehGregor>
Can anyone else reproduce this?  http://code.google.com/p/chromium/issues/detail?id=101791

[15:14:00.0000] <ojan>
I'd be fine with :or or :any

[15:14:01.0000] <TabAtkins_>
Hixie: :or() is confusing, because we're used to "or" coming *between* options, rather than being the name of a function that precedes the options.

[15:14:02.0000] <TabAtkins_>
ojan: Agreed that :any() is better.

[15:14:03.0000] <Hixie>
:any() wfm too

[15:14:04.0000] <ojan>
Hixie: you have a pointer to your :matches proposal?

[15:14:05.0000] <ojan>
i saw it ages ago, but i don't remember how it worked now

[15:14:06.0000] <TabAtkins_>
AryehGregor: wfm (no sad tab)

[15:15:00.0000] <AryehGregor>
TabAtkins_, what version/platform?

[15:15:01.0000] <annevk>
/me also thought renaming it to :matches was weird

[15:15:02.0000] <TabAtkins_>
ojan: Linux 64bit, Chrome 15 beta.

[15:15:03.0000] <TabAtkins_>
I mean AryehGregor in that last line.

[15:15:04.0000] <AryehGregor>
It's a regression.

[15:15:05.0000] <Hixie>
ojan: not off-hand, it'll be in www-style around 2002 or so. But in principle, :matches(...) takes a selector that must be matched by the eelement on which the pseudo is given

[15:15:06.0000] <AryehGregor>
Only started in Chrome 16, I think.

[15:15:07.0000] <AryehGregor>
It used to work for me too.

[15:15:08.0000] <TabAtkins_>
Ah, kk.  Let me upgrade.

[15:16:00.0000] <Hixie>
ojan: so p:matches(.a .b) is equivalent to .a p.b

[15:16:01.0000] <AryehGregor>
Thanks.

[15:16:02.0000] <Hixie>
ojan: but p:matches(.a .b):matches(.x .b) is equivalent to saying that the p.b element must have as ancestor both a .x and a .a, though it doesn't matter if they're the same or if not which is the deeper ancestor

[15:17:00.0000] <ojan>
Hixie: why is this better?

[15:17:01.0000] <Hixie>
ojan: (the only other aspect is that you can use "#" in the :matches() selector to say where the pseudo's element is to match, as in p:matches(a # b) is equivalent to "a p b")

[15:17:02.0000] <Hixie>
ojan: better than what?

[15:17:03.0000] <ojan>
than :any

[15:17:04.0000] <TabAtkins_>
ojan: Don't try and compare it to the Selectors4 :matches.  They're not the same thing.

[15:17:05.0000] <Hixie>
ojan: :any and :matches are unrelated

[15:18:00.0000] <TabAtkins_>
Completely different function.

[15:18:01.0000] <ojan>
oh...so they're not mutually exclusive

[15:18:02.0000] <ojan>
i see

[15:18:03.0000] <ojan>
what's the use-case for Hixie's :matches?

[15:18:04.0000] <TabAtkins_>
ojan: The same use-case as :has() or the subject indicator.

[15:18:05.0000] <Hixie>
ojan: (:any() would complement :matches() quite well in fact)

[15:18:06.0000] <Hixie>
ojan: :has() is basically :matches() but always starting with the #

[15:18:07.0000] <Hixie>
ojan: as in :has(foo) is equivalent to :matches(# foo)

[15:19:00.0000] <ojan>
i see

[15:19:01.0000] <Hixie>
ojan: :matches() basically solves almost all the limitations of selectors in one simple (and performance-impacting) swoop.

[15:19:02.0000] <Hixie>
well, not all the limitations

[15:19:03.0000] <Hixie>
it doesn't help with grouping

[15:19:04.0000] <Hixie>
but all the limitations of being able to reference ancestors, descendants, etc

[15:19:05.0000] <ojan>
oh i see...because it gives one syntactic way of doing all the things we're adding extra stuff for (e.g. parent combinators)

[15:20:00.0000] <Hixie>
yeah

[15:20:01.0000] <ojan>
makes sense to me

[15:20:02.0000] <ojan>
and it gives one thing to tell web devs not to ever use because it's crazy slow

[15:20:03.0000] <Hixie>
yeah

[15:20:04.0000] <ojan>
instead of a dozen tthings

[15:20:05.0000] <ojan>
i buy it

[15:20:06.0000] <Hixie>
mind you, it really does make it _crazy_ slow

[15:21:00.0000] <ojan>
i expect it does in degenerate cases

[15:21:01.0000] <ojan>
but i haven't really thoguht it through

[15:21:02.0000] <AryehGregor>
This is why I'm so much more interested in filing bugs against Gecko than any other piece of software I know about: https://bugzilla.mozilla.org/show_bug.cgi?id=697793

[15:21:03.0000] <Hixie>
:matches(# .foo) -- matches every element that has a .foo descendant. imagine a 5mb doc like the html spec.

[15:21:04.0000] <Hixie>
for every element, you have to crawl the entire subtree

[15:21:05.0000] <AryehGregor>
It should be fine for querySelector(), right?

[15:22:00.0000] <Hixie>
AryehGregor: well it'd still be slow, but it wouldn't have to happen every time the mouse moved, at least

[15:22:01.0000] <AryehGregor>
I mean, it might be slow, but authors have the tools to notice that.

[15:22:02.0000] <Hixie>
(:focus:matches(# :hover) *shudder*)

[15:22:03.0000] <ojan>
Hixie: ok...you've sold me. :matches makes sense to add and what's currently :matches should really be :any.

[15:22:04.0000] <Hixie>
sweet

[15:22:05.0000] <Hixie>
i wasn't even trying to sell you :-)

[15:23:00.0000] <AryehGregor>
Allowing such a thing in actual CSS files sounds like a seriously bad idea.

[15:23:01.0000] <ojan>
AryehGregor: we should either allow none of them, or add something generic like :matches

[15:23:02.0000] <annevk>
Hixie, cache manifests don't seem to allow for FF, maybe it should simply be banned from text/vtt?

[15:23:03.0000] <ojan>
AryehGregor: what we seem to be doing currently is adding a bunch of one-offs

[15:23:04.0000] <Hixie>
AryehGregor: it's certainly better than $ or ? or < or :has(), so if we're adding any of those, we should just do :matches(), imho

[15:24:00.0000] <ojan>
=Hixie

[15:24:01.0000] <Hixie>
annevk: *shrug*

[15:24:02.0000] <ojan>
I'd also be OK with not adding any of them.

[15:24:03.0000] <annevk>
Y U NO CARE

[15:25:00.0000] <ojan>
annevk: will you be in town for TPAC?

[15:25:01.0000] <Hixie>
bbiab, meeting

[15:25:02.0000] <hober>
ojan: annevk: there will be beers involved (re: tpac)

[15:26:00.0000] <ojan>
it'll be nice to meet everyone in person

[15:28:00.0000] <annevk>
I'm coming on Sunday

[15:28:01.0000] <annevk>
and yes, I'm looking forward to meeting everyone too :)

[15:29:00.0000] <ojan>
annevk: are you staying in SF or the south bay while you're here?

[15:29:01.0000] <annevk>
and beers :)

[15:29:02.0000] <annevk>
I'm staying in Santa Clara but might go to SF in the weekend

[15:30:00.0000] <annevk>
after not sure yet, leaving the ninth

[15:30:01.0000] <ojan>
annevk: k. i'll probably only be at tpac monday and tuesday, but i live/work in SF.

[15:31:00.0000] <annevk>
ah, in the Google SF office?

[15:31:01.0000] <ojan>
annevk: yeah

[15:31:02.0000] <annevk>
cool

[15:31:03.0000] <ojan>
annevk: you're welcome to come for lunch here one day

[15:31:04.0000] <annevk>
might take you up on that :)

[15:31:05.0000] <wycats>
Hixie: hey... I was wondering why the new validation events don't bubble

[15:32:00.0000] <wycats>
there's an open thread on the jQuery Standards list about it :)

[15:32:01.0000] <ojan>
annevk: a lot of the chromium folk who work on webkit work in SF

[15:33:00.0000] <ojan>
annevk: we should chat in person about the various dom creation proposals

[15:33:01.0000] <wycats>
ojan: what do you think about the Element constructor proposal?

[15:33:02.0000] <ojan>
wycats: which one?

[15:34:00.0000] <wycats>
I guess the one that takes an object of attributes and children?

[15:34:01.0000] <ojan>
wycats: there are things i really like about it and things i like less...

[15:34:02.0000] <ojan>
wycats: well...there are multiple such proposals...

[15:35:00.0000] <annevk>
ojan, yeah that'd be nice

[15:35:01.0000] <ojan>
wycats: the one i really like is the one annevk suggested with the funky json/array syntax

[15:35:02.0000] <ojan>
wycats: the thing i really like about that is that in theory, you can construct DOMs much faster than you could if you needed to parse HTML

[15:35:03.0000] <wycats>
ojan: I like it too

[15:35:04.0000] <ojan>
wycats: on the other hand, it's not terribly readable

[15:36:00.0000] <wycats>
ojan: the fact that new DivElement straight up doesn't work today is pretty broken

[15:36:01.0000] <wycats>
ojan: I was thinking that allowing a tagName as first param might make it more readable

[15:36:02.0000] <wycats>
new Element("div", { id: "zomg" })

[15:36:03.0000] <ojan>
i've slowly come to believe that the quasis approach may be the best

[15:36:04.0000] <ojan>
wycats: yeah, it's hard to come up with a syntax that works better than what annevk suggested

[15:37:00.0000] <wycats>
ojan: I think the only thing I could improve over annevk would be allowing new Element instead of new FooElement

[15:37:01.0000] <ojan>
wycats: because i think it's important we maintain that passing just a string can get you a text node

[15:37:02.0000] <wycats>
ah interesting

[15:37:03.0000] <wycats>
even to new Element

[15:37:04.0000] <wycats>
I guess the problem is that new Element wouldn't return a direct instance of Element

[15:37:05.0000] <ojan>
maybe not...but then what do you for the children case

[15:37:06.0000] <wycats>
you would want new Element("div") to return a DivElement

[15:38:00.0000] <ojan>
new Element(tagName, attributes, children...)

[15:38:01.0000] <wycats>
new Element("div", { id: "foo" }, [ new Element("span"), "some text" ])

[15:38:02.0000] <ojan>
Needing to repeat "new Element" when constructing the children is too bloated IMO

[15:38:03.0000] <ojan>
it's less readable and just too much typing

[15:38:04.0000] <wycats>
ojan: you could allow a hash, I guess?

[15:38:05.0000] <ojan>
remember the thing we're competing with is innerHTML here

[15:39:00.0000] <wycats>
new Element("div", { id: "foo" }, [ { span: { id: "hi", children: ["string", { em: ["some text"] }] } } ])

[15:39:01.0000] <ojan>
if i could have my cake and eat it too, right now I'd want to see us implement *both* annevk's array-based proposal and quasis with a native "html" function.

[15:39:02.0000] <ojan>
they're not actually mutually exclusive in any way

[15:40:00.0000] <TabAtkins_>
ojan: Yes, both are complementary for different things.

[15:40:01.0000] <ojan>
and actually meet different use-cases, althought there is certainly overlap

[15:40:02.0000] <ojan>
and annevk's array-based proposal is really straightforward to spec and implement, so it doesn't really present a burden on browser vendors

[15:41:00.0000] <ojan>
annevk: i liked the E4H proposal at first, but people have convinced me that quasis are a better solution...we can chat about it in person next week

[15:42:00.0000] <wycats>
ojan: the most useful thing for jQuery would be the ability to do fragment.innerHTML = "<tr><td>hi</td></tr>"

[15:42:01.0000] <wycats>
essentially have a way to make HTML nodes where the root nodes don't care about their context

[15:43:00.0000] <wycats>
we jump through major hoops in jQuery to make $("<tr><td>hi</td></tr>").appendTo("table") work

[15:43:01.0000] <ojan>
wycats: yeah...i agree it's totally balls

[15:43:02.0000] <ojan>
wycats: but all of these proposals address that use-case fine

[15:43:03.0000] <wycats>
ojan: not really

[15:43:04.0000] <wycats>
because the jQuery API is "gimme string"

[15:43:05.0000] <wycats>
not "gimme some structure"

[15:44:00.0000] <wycats>
I see the new APIs as competing with document.createElement more than innerHTML tbh

[15:44:01.0000] <kennyluck>
Is there any problem if browsers ignore media type of a manifest? I think this was probably discussed to death but I would be grateful if someone reminds me again.

[15:44:02.0000] <ojan>
wycats: but if you implement $("<tr><td>hi</td></tr>") in terms of the new API, it should just work, no?

[15:44:03.0000] <wycats>
how do we do that?

[15:45:00.0000] <wycats>
parse the HTML manually?

[15:45:01.0000] <ojan>
hm...i guess you're right...this doesn't help jquery at all.

[15:46:00.0000] <wycats>
"[

[15:46:01.0000] <wycats>
:p

[15:47:00.0000] <ojan>
wycats: i think it's an orthogonal issue...erik arvidsson made a proposal recently to whatwg@ make createContextualFragment do what you want if the range is in a detached context

[15:47:01.0000] <wycats>
ojan: nice

[15:47:02.0000] <ojan>
wycats: i'm still pro that as the solution to your problem

[15:47:03.0000] <wycats>
ojan: do you know what the subject line is?

[15:47:04.0000] <wycats>
ojan: I think right now that case throws an error

[15:48:00.0000] <ojan>
wycats: yeah, so it's probably backwards compatible to change it...

[15:48:01.0000] <ojan>
wycats: "createContextualFragment in detached contexts"

[15:48:02.0000] <wycats>
ojan: I'll go +1

[15:48:03.0000] <wycats>
it would save a ton of work in jQuery

[15:48:04.0000] <wycats>
I was able to make jQuery a lot faster in the case of $("table").append("<tr><td>...</td></tr>")

[15:49:00.0000] <wycats>
because I have a context for a contextual fragment in that case

[15:58:00.0000] <hober>
Hixie: thanks for the Emacs examples in r6773 :)


2011-10-28
[17:29:00.0000] <MikeSmith>
Hixie: fwiw, I'd vote for dropping the term "xhtml document" altogether

[17:34:00.0000] <MikeSmith>
Hixie: if you need an alternative, consider "document in the XHTML syntax"

[17:35:00.0000] <MikeSmith>
or "conforming document in the XHTML syntax" or "document conforming to the XHTML syntax"

[17:52:00.0000] <Hixie>
hober: gotta represent!

[17:52:01.0000] <Hixie>
MikeSmith: i think hsivonen convinced me we should give the term lip service

[17:59:00.0000] <MikeSmith>
Hixie: OK

[18:05:00.0000] <Hixie>
i just looked up "complicated" in the thesaurus to find a better word to use somewhere in the spec and wow, that's just a long list of words to describe HTML

[18:05:01.0000] <paul_irish>
:D

[18:05:02.0000] <MikeSmith>
byzantine?

[18:05:03.0000] <MikeSmith>
baroque?

[18:06:00.0000] <Hixie>
intricate... bewildering... perplexing... labrynthine... tortuous...

[18:06:01.0000] <Hixie>
tricky... knotty... thorny... tangled...

[18:06:02.0000] <MikeSmith>
intertwingly

[18:08:00.0000] <Hixie>
in other news

[18:08:01.0000] <Hixie>
turns out i'd never specced how input.width and input.height actually worked

[18:08:02.0000] <Hixie>
they were hyperlinked to a section that described a bunch of other width and height IDL attributes, but didn't list <input>

[18:08:03.0000] <Hixie>
so, oops

[18:09:00.0000] <Hixie>
how the blazes am i supposed to test http://www.w3.org/Bugs/Public/show_bug.cgi?id=14526

[18:17:00.0000] <jgraham>
Hixie: That's what you get for using the word "just" before "build one" :p

[18:18:00.0000] <Hixie>
:-)

[18:20:00.0000] <jgraham>
But, uh, doesn't OSX use NFD for filenames? So test what browsers on OSX do with a filename that could contain a decomposed character, maybe?

[18:36:00.0000] <Hixie>
http://damowmow.com/playground/demos/filename-upload/ leads me to be even more confused

[18:37:00.0000] <Hixie>
some used 0xCC 0x88 and some used 0xC3 0xBC

[18:38:00.0000] <Hixie>
oh sorry

[18:38:01.0000] <Hixie>
some used u 0xCC 0x88 and some used 0xC3 0xBC. that makes more sense.

[18:55:00.0000] <jarek>
Hi

[18:55:01.0000] <jarek>
the DOM3 spec has following line:

[18:55:02.0000] <jarek>
"Authors should use the KeyboardEvent.char and KeyboardEvent.key attributes instead of the charCode and keyCode attributes, respectively."

[18:56:00.0000] <jarek>
is this really what developers should do currently? KeyboardEvent.char and KeyboardEvent.key does not seem to be supported by latest version of Chrome

[18:56:01.0000] <jarek>
s/does/do

[18:56:02.0000] <jgraham>
DOM3 events?

[18:56:03.0000] <jarek>
yeah

[18:57:00.0000] <jgraham>
That spec is not noted for being useful

[18:57:01.0000] <zewt>
did you cut out the "... if they don't want anything to work" part

[18:58:00.0000] <jarek>
uhm... let me check :)

[18:58:01.0000] <jgraham>
jarek: Anyway, you are all good per RFC2119

[18:59:00.0000] <jarek>
yeah, it says something between those lines...

[19:00:00.0000] <jarek>
I was worried because it called keyCode and charCode as legacy

[19:06:00.0000] <jamesr_>
dom3 events can't really call anything else legacy

[19:06:01.0000] <jarek>
jamesr_: http://www.w3.org/TR/DOM-Level-3-Events/#legacy-key-attributes

[19:12:00.0000] <jgraham>
Seeriously, I wouldn't expect DOM3 events to be accurate

[19:15:00.0000] <jamesr_>
jarek, what i meant is that dom3 events is so old and incorrect you should ignore it

[19:15:01.0000] <jgraham>
d3e isn't old

[19:15:02.0000] <jamesr_>
jarek, what i meant is that dom3 events is so old and incorrect you should ignore it

[19:15:03.0000] <jamesr_>
sorry, mistaken

[19:15:04.0000] <jamesr_>
jgraham, well it has many old parts

[19:16:00.0000] <jamesr_>
some parts are newly edited

[19:16:01.0000] <jgraham>
Yes

[19:16:02.0000] <jamesr_>
many important parts are not

[19:16:03.0000] <jamesr_>
and it's a total mystery to me why anyone bothers editing it

[19:17:00.0000] <jarek>
is there any other specification that would describe keyboard events?

[19:17:01.0000] <jarek>
afair there was something on touch events

[19:18:00.0000] <jarek>
but that's different story

[19:19:00.0000] <jarek>
http://www.w3.org/TR/touch-events/

[19:20:00.0000] <jarek>
^ why it is not part of DOM3 events?

[19:20:01.0000] <jarek>
is it going to be merged in the future?

[19:39:00.0000] <wycats>
Hixie: above I asked why the new form validation events don't bubble

[20:04:00.0000] <kennyluck>
(ask again) Is there any problem if browsers ignore media type of a manifest? I think this was probably discussed to death but I would be grateful if someone reminds me again.

[20:16:00.0000] <Hixie>
wycats: in case the form control is in a form that isn't the form it's associated with

[20:16:01.0000] <Hixie>
kennyluck: well it would violate the HTTP spec...

[20:16:02.0000] <wycats>
Hixie: it basically breaks event delegation though

[20:16:03.0000] <wycats>
event delegation is a pretty standard way to build apps

[20:20:00.0000] <Hixie>
event delegation?

[20:24:00.0000] <wycats>
Hixie: it's common for people to register for events in entire regions of the page

[20:24:01.0000] <wycats>
and use event.target to identify where the event came from

[20:24:02.0000] <wycats>
this has two positive effects

[20:24:03.0000] <wycats>
1) no need to register handlers for all elements you are interested in (performance)

[20:25:00.0000] <wycats>
2) ability to dynamically generate markup without having to worry about also binding events

[20:25:01.0000] <wycats>
http://api.jquery.com/delegate/ jQuery provides widely-used facilities for this

[20:25:02.0000] <Hixie>
sure

[20:25:03.0000] <Hixie>
you can still do that

[20:25:04.0000] <Hixie>
just register a capture listener on whatever element you want to do it on

[20:27:00.0000] <wycats>
Hixie: almost no existing delegation facilities use capture

[20:27:01.0000] <wycats>
and further, capture has the reverse intended effect

[20:28:00.0000] <wycats>
namely, it bubbles backwards from the expected direction

[20:29:00.0000] <Hixie>
if all you want to do is delegate, it doesn't matter what direction it goes in

[20:33:00.0000] <wycats>
Hixie: it matters if you want to avoid conflicting with event handlers that some other code may have registered

[20:33:01.0000] <Hixie>
i don't really understand the use case here

[20:33:02.0000] <Hixie>
but you can always work around it by adding a capture handler on the root that refires the event as a bubbling event :-)

[20:36:00.0000] <wycats>
refiring isn't particularly reliable, especially with events with native handling

[20:36:01.0000] <wycats>
Hixie: trust me when I say "events that don't bubble are broken to most developers"

[20:36:02.0000] <wycats>
https://groups.google.com/forum/#!topic/jquery-standards/SKdrgth7igY

[20:41:00.0000] <kennyluck>
Hixie, can you elaborate on this a little bit? (re. it would violate the HTTP spec) Is that a strong reason given how many times "willful violation" appears in the spec?

[22:04:00.0000] <Hixie>
wycats: i don't see why refiring wouldn't work if you really needed it

[22:04:01.0000] <Hixie>
wycats: bubbling would be broken too, for this particular feature

[22:04:02.0000] <Hixie>
wycats: if there are specific uses cases you want me to look at, though, that might show that i am wrong, which would be useful

[22:04:03.0000] <Hixie>
wycats: it's hard to discuss in the abstract

[22:05:00.0000] <Hixie>
kennyluck: the wilful violations are all because i had no choice, e.g. because the other spec contradicts reality

[22:49:00.0000] <roc>
I have an interesting spec philosophy question

[22:51:00.0000] <heycam>
choice of font?

[22:51:01.0000] <roc>
yeah right

[22:51:02.0000] <roc>
I have an API that lets a Worker generate data for a MediaStream. This is done by periodically firing an event at the Worker to fetch more data. Suppose the MediaStream isn't connected to anything and is eventually GCed.

[22:52:00.0000] <roc>
Should I keep firing events at the Worker to preserve the non-observability of GC?

[22:52:01.0000] <roc>
(Which means, of course, keeping the Worker alive)

[22:52:02.0000] <heycam>
hmm, well are you required to fire the event at any particular rate?

[22:52:03.0000] <heycam>
can the worker tell that the worker should have fired an event by a particular time?

[22:53:00.0000] <roc>
not really

[22:53:01.0000] <roc>
but I think it'd be reasonable to expect the event to fire *eventually*

[22:54:00.0000] <heycam>
yeah. is it just theoretical observability that you're worried about? or practical web compat problems due to different gc strategies?

[22:54:01.0000] <jgraham>
I don't understand what events would be fired once the stream wasn't connected to anything

[22:54:02.0000] <roc>
conceptually the stream keeps playing, but no-one's listening

[22:55:00.0000] <roc>
I haven't thought about Web compat problems

[22:55:01.0000] <heycam>
i know: kill the worker, then it won't know a thing ;)

[22:55:02.0000] <roc>
I have written a test that accidentally broke because the stream got GCed and my worker stopped getting called, and I was waiting for it to get through a certain amount of work

[22:55:03.0000] <zewt>
fwiw you could get the same effect (logically) without workers complicating the question, if you were firing progress events on a stream and the same thing happened

[22:55:04.0000] <jgraham>
Can't you make that explicit?

[22:56:00.0000] <roc>
make what explicit?

[22:56:01.0000] <zewt>
(on an abstract stream--not talking about any particular API, not sure if there are any that fit)

[22:57:00.0000] <roc>
one possibility I just thought of is that I could try making MediaStreams that aren't connected to anything block

[22:58:00.0000] <roc>
then if a MediaStream gets GCed, it must have been blocked, in which case it's correct to stop firing processmedia events at the worker

[22:58:01.0000] <zewt>
i don't know that API, but that seems better than requesting info and throwing it away if nobody's connected to it; that just seems wasteful

[23:00:00.0000] <roc>
but that means if you want a ProcessedMediaStream whose worker just analyzes input samples and doesn't produce anything, you'll need to nevertheless connect it to a dummy muted audio element :-(

[23:00:01.0000] <zewt>
from an I/O-pin-based API perspective that's not too horrible

[23:02:00.0000] <jgraham>
roc: That sounds OK to me. Conceptually having no low if there is no sink sounds reasonable

[23:02:01.0000] <jgraham>
*flow

[23:02:02.0000] <roc>
hmm ho

[23:03:00.0000] <zewt>
out of curiosity, if you start a chain like that, and drop all references to the objects, is there any way to get it back (eg. a "array of currently playing streams" attribute somewhere), or is it effectively leaked and playing forever?

[23:04:00.0000] <zewt>
(leaking like that isn't too bad--don't do that--but a little unusual on the platform)

[23:04:01.0000] <zewt>
(of course, you can't say "the input element gets GC'd and it stops", since then you're back at square one with exposed GC behavior :)

[23:05:00.0000] <roc>
in this API I use media elements for output

[23:06:00.0000] <roc>
and media elements already handle this issue

[23:06:01.0000] <roc>
basically you can go (new Audio(...)).play();

[23:06:02.0000] <roc>
dropping the reference to the element

[23:06:03.0000] <roc>
and it will play until the stream ends

[23:06:04.0000] <roc>
and then everything gets cleaned up

[23:06:05.0000] <roc>
of course, the stream might not end, but whatever

[23:07:00.0000] <roc>
also, if the document becomes "inactive" (which is very carefully defined), the element pauses automatically, and since there's no reference to it there's no way to start it again so again we can clean up

[23:08:00.0000] <roc>
jgraham: thanks for the reassurance, I'll probably go that way :-)

[23:16:00.0000] <wycats>
Hixie: can you explain the use-case for it not bubbling better?

[23:24:00.0000] <Hixie>
wycats: if someone were to use the fact that it bubbled to put a handler on a <form>, that handler would fire even for controls that were children of the form but had a form="" attribute and were thus associated with another form.

[23:25:00.0000] <wycats>
them's the breaks with bubbling in general

[23:25:01.0000] <wycats>
we could fire a different event on associated forms

[23:25:02.0000] <wycats>
invalidform

[23:25:03.0000] <Hixie>
or we could just not bubble, since there doesn't seem to be a use case for it :-)

[23:26:00.0000] <wycats>
Hixie: it's inconsistent

[23:26:01.0000] <wycats>
other events bubble

[23:26:02.0000] <Hixie>
not all of them

[23:27:00.0000] <wycats>
and look what jQuery does -- it creates bubbling versions of the non-bubbling events

[23:27:01.0000] <wycats>
nobody wants non-bubbling events

[23:27:02.0000] <Hixie>
clearly not nobody

[23:27:03.0000] <Hixie>
maybe jquery's authors don't

[23:27:04.0000] <wycats>
web authors don't :)

[23:27:05.0000] <Hixie>
some web authors do

[23:27:06.0000] <wycats>
which ones?

[23:27:07.0000] <Hixie>
me, for one

[23:28:00.0000] <wycats>
Hixie: the fact that focus doesn't bubble, for instance, is the source of considerable pain

[23:29:00.0000] <Hixie>
and if 'invalid' were to bubble, _that_ would cause pain

[23:29:01.0000] <hsivonen>
I wonder what would be the most effective way to get the person implementing HTML parsing in IE take a look at http://hsivonen.iki.fi/test/moz/bug696651-1.html and compare with Gecko/WebKit/Ragnarök

[23:29:02.0000] <wycats>
Hixie: in the case where people use form="..."?

[23:29:03.0000] <Hixie>
wycats: yup

[23:30:00.0000] <Hixie>
wycats: what's the use case for looking at the 'invalid' event anywhere but the control?

[23:30:01.0000] <wycats>
Hixie: using the standard event delegation infrastructure that people use for every other event

[23:30:02.0000] <Hixie>
hsivonen: is that related to a potential spec change?

[23:30:03.0000] <hsivonen>
Hixie: AFAIK, no

[23:30:04.0000] <Hixie>
wycats: that's not a use case, that's a bunch of buzzwords.

[23:30:05.0000] <Hixie>
hsivonen: thank god.

[23:30:06.0000] <Hixie>
hsivonen: that test case looks scary.

[23:30:07.0000] <hsivonen>
Hixie: rather, it seems to me IE is failing to follow the spec

[23:30:08.0000] <Hixie>
hsivonen: i was worried i might have to understand it. :-P

[23:30:09.0000] <wycats>
Hixie: "event delegation" how is that a buzzword?

[23:31:00.0000] <wycats>
what you're saying is that people should build their own event delegation specifically for the invalid event

[23:31:01.0000] <wycats>
using capture

[23:31:02.0000] <wycats>
which isn't available in all browsers, so it would fail on polyfills

[23:31:03.0000] <Hixie>
wycats: no, i'm saying that there hasn't been any description of a use case for event delegation for the 'invalid' event on form controls

[23:32:00.0000] <wycats>
Hixie: I explained above why people want event delegation - it's to make it easy to dynamically insert markup without having to worry about also binding events

[23:32:01.0000] <Hixie>
wycats: that makes no sense for a form control's invalid event

[23:32:02.0000] <Hixie>
wycats: the whole point of that event is to do different things for each control

[23:33:00.0000] <wycats>
the point of event delegation libraries is to have an event that behaves as-if it was bound directly, but without having to bind it

[23:34:00.0000] <wycats>
$(document).delegate("input.something", function() { /* handle invalid events for elements with "something" class here */ })

[23:35:00.0000] <Hixie>
show me a use case for giving multiple controls the same oninvalid handler

[23:35:01.0000] <wycats>
one moment please

[23:39:00.0000] <wycats>
what, in your mind, is the use case for the invalid event on individual elements

[23:40:00.0000] <hsivonen>
maybe I should submit the test I mentioned above to html5lib test suite (in one of the scripted tree builder test files)

[23:43:00.0000] <zewt>
Hixie: the "dynamic elements" case doesn't need multiple controls with the same behavior, fwiw

[23:43:01.0000] <hsivonen>
/me sighs at av_param. 

[23:43:02.0000] <hsivonen>
looks like I will have to write a counter change proposal if that one is submitted to the WG

[23:43:03.0000] <hsivonen>
or was it submitted already?

[23:44:00.0000] <zewt>
not very familiar with form validation just yet, but i could easily see the same "invalid data" behavior for eg. multiple phone numbers (work, home, mobile) in the same form ("awooga, bad phone number")

[23:44:01.0000] <hsivonen>
Risks: None identified

[23:44:02.0000] <wycats>
Hixie: I'm honestly at a loss for how to explain this to you -- do you understand that you may find that you want the same behavior on the case of invalidity in several places on a page? and that you might now want all of the annotated elements to have to be present on that page when you initially register the handlers?

[23:44:03.0000] <zewt>
wycats: s/now/not/, presumably :)

[23:44:04.0000] <hsivonen>
right. as if I didn't identify a risk in the bug. :-( how hard would it have been to copy and paste it over?

[23:44:05.0000] <wycats>
Hixie: keeping in mind that you have access to the target element no matter where the event itself was bound

[23:45:00.0000] <hsivonen>
Negative Effects: None identified

[23:45:01.0000] <hsivonen>
Conformance Classes Changes: None identified

[23:45:02.0000] <hsivonen>
seriously?

[23:47:00.0000] <Hixie>
wycats: sorry, was afk

[23:47:01.0000] <Hixie>
wycats: pretty much the only use case is displaying very specialised error notifications, e.g. on a field with a complicated pattern, displaying a graphic showing the allowed pattern.

[23:48:00.0000] <wycats>
Hixie: you assume CSS will handle all other cases you care about?

[23:48:01.0000] <Hixie>
hsivonen: fwiw in the past when a decision has been made that browsers haven't wanted to implement, it's been dealt with quite quickly without much work from vendors

[23:49:00.0000] <Hixie>
wycats: no need for CSS even

[23:49:01.0000] <wycats>
Hixie: the invalid event allows you to customize the behavior / style of invalid elements - it's only irrelevant if CSS picks up all the remaining slack

[23:50:00.0000] <Hixie>
wycats: why would you style anything at all? just let the browser do it

[23:50:01.0000] <Hixie>
wycats: styling the error messages is like styling the form controls, it's bad ui

[23:50:02.0000] <Hixie>
wycats: just trust the browser to use platform conventions

[23:51:00.0000] <wycats>
I'm honestly at a loss; I'll compose an email

[23:51:01.0000] <wycats>
and let others chime in

[23:51:02.0000] <wycats>
:)

[23:51:03.0000] <Hixie>
e-mail and bugs are the only way changes are going to be made anyway :-)

[23:51:04.0000] <wycats>
Hixie: yep

[23:51:05.0000] <Hixie>
but make sure to give use cases

[23:51:06.0000] <Hixie>
that's pretty much all i look at

[23:52:00.0000] <Hixie>
(that and what the browsers are doing)

[23:52:01.0000] <wycats>
Hixie: I'm seriously baffled that you think that the entire problem of form validation and the related UI is now a solved problem

[23:52:02.0000] <wycats>
I would love for that to be true

[23:52:03.0000] <Hixie>
why would it not be true?

[23:52:04.0000] <Hixie>
(for common controls, that is)

[23:53:00.0000] <wycats>
because the semantics of what invalidity actually means can differ

[23:53:01.0000] <Hixie>
(obviously for complicated cases there are needs for scripted ui, but that's why we have oninvalid)

[23:53:02.0000] <wycats>
and I'll bet dollars to donuts that we didn't hit even close to every case

[23:53:03.0000] <Hixie>
can you possibly give a concrete example

[23:53:04.0000] <wycats>
Hixie: I will email the list

[23:53:05.0000] <Hixie>
make sure to include concrete examples and use cases

[23:53:06.0000] <wycats>
Hixie: no problem

[23:54:00.0000] <Hixie>
it's _some_ problem, i've been asking for them for over 30 minutes now without luck :-/

[23:55:00.0000] <wycats>
I need to figure out how to articulate what you think are "buzzwords" in a way that you will consider valid

[23:55:01.0000] <wycats>
so I will think about it and send an email

[23:56:00.0000] <Hixie>
a use case is something like "on this web page i'm writing at http://foobar.example.net/bla/quux.html, you'll notice there's an airline seat chart, and when the user clicks on the seat i fill in an input field, and..." etc

[23:56:01.0000] <Hixie>
referencing common development methodologies isn't a use case, however you phrase it

[23:56:02.0000] <Hixie>
it needs to be a real-world actual problem

[23:56:03.0000] <Hixie>
faced by a specific author and user

[23:58:00.0000] <wycats>
is the user allowed to be using popular libraries?

[23:58:01.0000] <wycats>
or are they required to be writing everything by hand using the raw DOM API?

[23:59:00.0000] <zewt>
use cases do not have to be real-world actual problems; realistic, theoretical uses are also use cases

[23:59:01.0000] <Hixie>
you mean the author? the user doesn't use libraries :-)

[23:59:02.0000] <zewt>
otherwise you'd never have any use cases for apis that don't exist yet, and you couldn't create any new apis :)

[00:00:00.0000] <wycats>
Hixie: yes, the author

[00:00:01.0000] <Hixie>
wycats: doesn't matter, doesn't affect the use case

[00:01:00.0000] <wycats>
Hixie: so as long as the author can solve their problem without libraries, it's invalid?

[00:01:01.0000] <Hixie>
wycats: author = author code + library code

[00:02:00.0000] <Hixie>
wycats: (abviously any problem that can be solved with libraries can be solved without libraries)

[00:02:01.0000] <wycats>
Hixie: yes that is true mathematically

[00:03:00.0000] <Hixie>
wycats: if you mean "is a problem caused by a library a valid problem", the answer is obviously no, since it's far easier to fix the library than every browser

[00:03:01.0000] <wycats>
I'm not sure why common development techniques for working with events are irrelevant

[00:03:02.0000] <wycats>
Hixie: it's a new event

[00:03:03.0000] <wycats>
and it may not be easy to fix libraries, if you're asking them to deviate from their standard practice for one specific event

[00:04:00.0000] <wycats>
Hixie: my point is purely that people use bubbling to bind events to elements that don't exist yet, based on some annotation on the element

[00:04:01.0000] <wycats>
your point is that the invalid event is largely useless anyway

[00:04:02.0000] <Hixie>
honestly i don't see much point in using a library to hook an event, unless it's to work around browser differences

[00:04:03.0000] <Hixie>
it's not like dom events is a difficult api to use

[00:04:04.0000] <wycats>
Hixie: you're trolling me right?

[00:04:05.0000] <Hixie>
no?

[00:05:00.0000] <wycats>
Hixie: let's get drinks with Alex Russell and discuss this some time

[00:05:01.0000] <Hixie>
if you were talking about indexeddb that would be different

[00:05:02.0000] <Hixie>
alex and i have rather different views of how the web should work

[00:05:03.0000] <wycats>
Hixie: in your mind, users should type as much as possible and pass as many boolean flags as possible?

[00:05:04.0000] <Hixie>
( and every time we talk about it, he convinces me further that he's wrong :-) )

[00:05:05.0000] <Hixie>
users shouldn't type anything

[00:05:06.0000] <wycats>
authors

[00:06:00.0000] <Hixie>
not sure what you mean by "boolean flags" here

[00:06:01.0000] <wycats>
Ajax sync/async, capture/bubbling phase

[00:06:02.0000] <wycats>
APIs have mandatory boolean flags where 99.999% of usage is one or the other

[00:06:03.0000] <Hixie>
neither of those requires passing any boolean flags

[00:06:04.0000] <Hixie>
as the last argument to addEventListener() is optional

[00:06:05.0000] <Hixie>
and XMLHttpRequest defaults to async

[00:07:00.0000] <zewt>
wycats: i think you're getting distracted--not having to pass flags to a function isn't why delegation is useful (if that was all it was for, you'd just use a helper function)

[00:08:00.0000] <wycats>
zewt: I am in fact getting distracted

[00:10:00.0000] <wycats>
zewt: I'm just getting frustrated by the need to provide a use-case for event delegation being useful

[00:11:00.0000] <wycats>
I'm going to organize my thoughts and try to apply them clearly to the invalid event

[00:11:01.0000] <wycats>
and then send an email

[00:12:00.0000] <zewt>
wycats: by the way, there's no reason to frame use cases for delegation in terms of delegation

[00:13:00.0000] <zewt>
use cases for delegation are all really use cases for event bubbling, since delegation is just bubbling with some helpers wrapped around it

[00:13:01.0000] <zewt>
(so you can strip a layer of abstraction away from what you're talking about by putting that aside)

[00:15:00.0000] <wycats>
zewt: event delegation is bubbling that makes use of event.target

[00:15:01.0000] <wycats>
no?

[00:15:02.0000] <zewt>
yep

[00:15:03.0000] <wycats>
zewt: that's what I mean by "event delegation"

[00:15:04.0000] <zewt>
i know

[00:15:05.0000] <wycats>
I think without the target property, bubbling would in fact not be very useful here

[00:16:00.0000] <wycats>
if there is a case for direct binding, there defacto is a case for bubbling + target

[00:16:01.0000] <wycats>
but I need to figure out how to clearly explain that

[01:41:00.0000] <annevk>
foolip, I keep forgetting that Microdata has no relationship to the rest of the page

[01:42:00.0000] <annevk>
I wonder whether I'm the only one

[01:51:00.0000] <annevk>
foolip, your Live Microdata has a giant XSS hole

[01:51:01.0000] <annevk>
foolip, not sure if that's problematic for your site or not

[01:57:00.0000] <annevk>
Argh. DOM Level 3 Events also changes the way dispatchEvent() works from DOM Level 2 Events

[01:57:01.0000] <annevk>
And http://w3c-test.org/webapps/DOMEvents/tests/submissions/Microsoft/converted/dispatchEvent.NOT_SUPPORTED_ERR.html tests one of those new silly conditions...

[02:01:00.0000] <hsivonen>
annevk: the Microdata API encourages the kind of thinking that Microdata has a relationship to the DOM structure :-/

[02:03:00.0000] <annevk>
So actually Hixie didn't think of it either when he made that new Microdata-inspired Atom example

[02:05:00.0000] <hsivonen>
aargh. http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Oct/0051.html

[02:05:01.0000] <Hixie>
annevk: which one?

[02:06:00.0000] <Hixie>
hsivonen: i'm sure he feels the same way in reverse :-)

[02:07:00.0000] <Hixie>
annevk: oh the pubdate thing

[02:07:01.0000] <Hixie>
annevk: interesting point

[02:07:02.0000] <annevk>
Hixie, http://www.w3.org/Bugs/Public/show_bug.cgi?id=14202

[02:07:03.0000] <annevk>
yeah

[02:07:04.0000] <annevk>
foolip spotted it

[02:07:05.0000] <annevk>
I had forgotten about it again

[02:08:00.0000] <zcorpan>
hsivonen: it makes perfect sense to use RDFa in XML Schema and XSLT

[02:11:00.0000] <Hixie>
annevk: i wonder what the use case is for pubdate. is it just a replacement for Atom, for syndication?

[02:12:00.0000] <Hixie>
annevk: if so, we can just also tell people to specify a "url" and make sure that the permalink is what is used

[02:12:01.0000] <Hixie>
annevk: and then say that syndicators should grab all the items of type Blog or whatever and then find their URLs and look those up and get the <article>s that they point to, or something

[02:14:00.0000] <zcorpan>
Hixie: r6773 - you can't bind Esc with accesskey

[02:14:01.0000] <Hixie>
not yet, no

[02:14:02.0000] <zcorpan>
so the example is confusing because it implies that you can

[02:17:00.0000] <annevk>
Hixie, I don't know really; I just thought Microdata might be a nice way to solve this rather niche case but then it turns out I don't understand Microdata...

[02:18:00.0000] <Hixie>
zcorpan: can you think of another example that would have a different last symbol in windows and mac that _is_ possible with the first version of this new accesskey?

[02:19:00.0000] <zcorpan>
no

[02:19:01.0000] <FlorianX>
could someone tell me when the canvas was integrated into html5? Thanks

[02:19:02.0000] <Hixie>
2007? around when safari first came out with it.

[02:20:00.0000] <zcorpan>
http://www.whatwg.org/specs/web-apps/2005-09-01/#dynamic

[02:20:01.0000] <FlorianX>
Hixie: thank this limited the search in your commits  :-)

[02:21:00.0000] <FlorianX>
zcorpan: Thanks!

[02:21:01.0000] <zcorpan>
2005 there was no svn

[02:21:02.0000] <Hixie>
2005, wow

[02:21:03.0000] <Hixie>
canvas has been in the spec longer than the w3c had existed by the time it decided html was dead

[02:22:00.0000] <FlorianX>
ok thanks

[02:22:01.0000] <Hixie>
ok i really have to go to bed

[02:22:02.0000] <Hixie>
nn

[02:22:03.0000] <FlorianX>
gn8

[03:20:00.0000] <Margle>
what's the objective of this channel?

[03:22:00.0000] <annevk>
allow people to communicate?

[03:24:00.0000] <Margle>
to what end?

[03:26:00.0000] <annevk>
creating standards typically

[03:30:00.0000] <Margle>
I've reached the beginning?

[03:34:00.0000] <abarth>
Margle: its a loop.  there is no beginning

[03:37:00.0000] <Margle>
and thus: standards immatate time.

[03:37:01.0000] <abarth>
well, time is a cube

[03:37:02.0000] <Margle>
abarth: and standards are a donut?

[03:45:00.0000] <zcorpan>
Margle: no. standards suck

[03:45:01.0000] <abarth>
what ever happened to standards suck?

[03:45:02.0000] <abarth>
maybe there will be new ones after TPAC?

[03:46:00.0000] <Margle>
ok

[03:46:01.0000] <Margle>
so… why does everyone come here to talk about stuff that sucks?

[03:47:00.0000] <Margle>
can't be just talk about other stuff?

[03:47:01.0000] <zcorpan>
seems like it hasn't been active in two years

[03:47:02.0000] <annevk>
tried making one with hasather but that really didn't go anywhere

[03:48:00.0000] <zcorpan>
you should interview abarth :)

[03:49:00.0000] <zcorpan>
"can you explain how web security works in three sentences?"

[03:49:01.0000] <abarth>
it doesn't

[03:49:02.0000] <abarth>
(sort interview)

[03:49:03.0000] <abarth>
short

[03:49:04.0000] <annevk>
:)

[04:34:00.0000] <hasather>
The classList methods would be more useful if they took a space separated list of class names

[04:36:00.0000] <zcorpan>
hasather: file a bug

[04:37:00.0000] <hasather>
zcorpan: yea

[04:47:00.0000] <karlcow>
http://raven.io/

[05:30:00.0000] <asmodai>
awesome, logos in CSS: http://www.ecsspert.com/twitter.php

[05:30:01.0000] <asmodai>
Pity the site references w3schools though :(

[07:30:00.0000] <foolip>
nessy, I'm making some tweaks to http://www.w3.org/html/wg/wiki/ChangeProposals/issue-179_no_change

[07:30:01.0000] <nessy>
oh, I am still working on it

[07:30:02.0000] <nessy>
give me about 10 min

[07:31:00.0000] <foolip>
ok, will do

[07:42:00.0000] <nessy>
ok, it's still a bit raw, but I am grateful you want to chip in

[07:42:01.0000] <nessy>
go for it :-)

[07:49:00.0000] <foolip>
ok, I just changed the formatting a bit, it was way too wide for me

[07:59:00.0000] <nessy>
ah, oops

[08:02:00.0000] <foolip>
nessy, do you know what the appropriate way of entering complaints about the original proposal is?

[08:03:00.0000] <foolip>
for example, I want to complain that it doesn't have any implementation details, but under which section of the counter proposal does that belong?

[08:11:00.0000] <nessy>
I don't know either

[08:11:01.0000] <nessy>
I thought I'd put it under "Details", but that's really for proposing what to enter into the spec

[08:12:00.0000] <nessy>
http://dev.w3.org/html5/decision-policy/decision-policy.html#change-proposal <- doesn't really describe what a counter change proposal should include

[08:13:00.0000] <nessy>
looking at this http://www.w3.org/html/wg/wiki/ChangeProposals/KeepMicrodata it seems the "Rationale" section needs to contain the details

[08:14:00.0000] <nessy>
let's remove the "Details" header then

[08:14:01.0000] <nessy>
are you editing?

[08:16:00.0000] <foolip>
not right now

[08:16:01.0000] <foolip>
I'm done for today I think, but I'm monitoring it and might throw and some stuff if you don't object

[08:17:00.0000] <foolip>
uh

[08:17:01.0000] <foolip>
throw in, as in add, not throw as in remove :)

[08:18:00.0000] <nessy>
sure

[08:18:01.0000] <nessy>
I am about to go to bed, so will likely not edit anything in about 15 hours (have to take my son to Basketball in the morning)

[08:21:00.0000] <foolip>
have a nice weekend, then :)

[08:23:00.0000] <nessy>
thanks :-) you, too

[08:23:01.0000] <nessy>
I'll monitor the situation :-)

[08:23:02.0000] <nessy>
nn

[08:28:00.0000] <zewt>
... g+ seriously doesn't do rss? what?

[08:56:00.0000] <karlcow>
zewt: ... seriously why using g+? what?

[09:03:00.0000] <zewt>
... i'm not?

[09:31:00.0000] <bfrohs>
Has there been any suggestions for a relative tabindex based on the current section? For example, a form that you know what order you want each field to be selected, but you don't know the placement on the actual page?

[09:32:00.0000] <bfrohs>
Code example: http://bit.ly/vxrjt5 -- obviously with a different attribute or format for doing it relatively instead

[09:37:00.0000] <AryehGregor>
I haven't heard such suggestions, but it would make sense.

[09:39:00.0000] <bfrohs>
It's been the one thing I never liked about tabindex (and the only reason I almost never use it). Because, quite frankly, websites are built in sections. Back when every page was simple and linear, the tabindex the way it is made sense (to an extent), but with websites nowadays, there needs to at least be an option for relative tabindex.

[09:42:00.0000] <bfrohs>
And I believe it may be good enough to simply rely on the outline algorithm, but some may want it to take into account fieldsets and the like as well.

[09:43:00.0000] <AryehGregor>
Or have an attribute like accesskeyscope, similar to itemscope and undoscope, which indicates that all descendants' accesskeys are to be interpreted as relative.

[09:52:00.0000] <bfrohs>
Well, in a limited way, that could work. But that makes it impossible to mark an item with an absolute tabindex.

[09:53:00.0000] <AryehGregor>
Why would you want to mix relative and absolute in the same subtree?  We don't have to satisfy all use-cases if that will make things more complicated.

[09:53:01.0000] <AryehGregor>
If you want to do fancy stuff, you can always work out absolute tabindexes.

[09:53:02.0000] <bfrohs>
Also, if you had two forms, both of which you wanted to have relative tabindexes, but the second form to be accessed first, you would be limited there as well.

[09:53:03.0000] <bfrohs>
Oh, just thinking up all use-cases cause my mind is terrible like that.

[09:54:00.0000] <bfrohs>
But honestly, for my needs, accesskeyscope would be more than enough

[09:54:01.0000] <annevk>
tabindexscope, no?

[09:54:02.0000] <bfrohs>
well, yeah, just using the attribute AryehGregor provided

[09:55:00.0000] <AryehGregor>
I misspoke, obviously.

[09:56:00.0000] <bfrohs>
The only issue with tabindexscope (and piggybacking off of tabindex) is backward compatibility with older browsers. Get two or more forms on the same page using tabindexscope, and it makes it a huge pain to fill out a form using tab.

[09:57:00.0000] <bfrohs>
(tab goes to first field in second form, instead of second in first)

[09:57:01.0000] <AryehGregor>
True.

[09:58:00.0000] <bfrohs>
So, even if everyone was using an updated browser, we would have to wait until every major browser supported it before it could be used (and not piss off a lot of other people).

[09:59:00.0000] <bfrohs>
And that's in a perfect world. Can't imagine how it would work in this world ;)

[09:59:01.0000] <AryehGregor>
It doesn't seem worth it, really.

[10:02:00.0000] <annevk>
especially since keyboards are sort of moving away from being the dominant way to browse the web

[10:02:01.0000] <zewt>
ehh

[10:03:00.0000] <bfrohs>
Yes, but someday we may talk to our websites. "Next field" for example

[10:03:01.0000] <zewt>
the existance of other input methods does not mean it's okay to ignore keyboard accessibility as if keyboards are somehow going away

[10:04:00.0000] <zewt>
bfrohs: mobile browsers already use "next field" during form inputs, btw

[10:04:01.0000] <annevk>
wow, way to go from does not seem worth it to optimize for to ignore them altogether

[10:04:02.0000] <zewt>
...

[10:05:00.0000] <zewt>
you suggested that improvements should not be made to keyboard navigation [because of touchscreens], which is a terrible idea

[10:06:00.0000] <zewt>
improvements -> this improvement

[10:07:00.0000] <annevk>
this is not an even an improvement to keyboard navigation

[10:07:01.0000] <annevk>
it's an improvement to authoring for it, but whatever

[10:07:02.0000] <zewt>
same thing, IMO

[10:07:03.0000] <bfrohs>
Well, in a way, it is an improvement. Because, right now, people rarely do tabindex on more than one form.

[10:07:04.0000] <bfrohs>
If they do it for one at all

[10:08:00.0000] <bfrohs>
Example: Facebook has it for their log in form. They don't use it for any other form on their site that I can find.

[10:27:00.0000] <annevk>
oh, Apple is "only" charging EUR 700

[10:30:00.0000] <michel_v>
as for touchscreens, tabindex might still be useful to consider when some browsers (Safari on iOS comes to mind) do have "previous field / next field" buttons when filling forms

[10:31:00.0000] <zewt>
<zewt> bfrohs: mobile browsers already use "next field" during form inputs, btw <- :)

[10:32:00.0000] <michel_v>
oh, sorry. missed that line while reading the backlog

[10:39:00.0000] <bfrohs>
With these touchscreen/mobile/keyboard-is-dead arguments, should 'tabindex' be rethought entirely with the knowledge we now have of some of the new technologies that have come out (and will come out)? Because tabindexscope is only to fix the 'documents are no longer basic and linear' problem. Would there be another solution that would be better suited for touchscreens/non-keyboard-based-technologies?

[10:49:00.0000] <karlcow>
bfrohs: for inspiration there might be things to check into http://www.w3.org/standards/techs/multimodal#w3c_all

[10:50:00.0000] <annevk>
bfrohs, I actually think CSS is probably the better place to put these kind of things

[10:51:00.0000] <annevk>
bfrohs, the UI module has nav-index and some similar properties already

[10:51:01.0000] <annevk>
bfrohs: if you tie it markup it might not make sense if you apply a different style sheet that reorders some controls

[10:51:02.0000] <MikeSmith>
karlcow: I'm not inspired by that page

[10:52:00.0000] <karlcow>
:D

[10:52:01.0000] <karlcow>
/me will inspire MikeSmith in a few days

[10:57:00.0000] <karlcow>
http://www.w3.org/wiki/MeetingTaxis#Arrivals

[11:03:00.0000] <annevk>
oh interesting

[11:04:00.0000] <annevk>
I arrive an hour before you and dom

[11:04:01.0000] <Rik`>
btw, have you noted that there is a summer time change those weeks?

[11:06:00.0000] <AryehGregor>
jgraham, did you ever review the assert_throws patch I posted here?

[11:06:01.0000] <AryehGregor>
(we really need to set up a better patch review system than me pastebinning stuff and pinging you on IRC)

[11:06:02.0000] <MikeSmith>
you guys should share a taxi

[11:06:03.0000] <MikeSmith>
costed about $100 for a taxi I took last night

[11:06:04.0000] <MikeSmith>
which is nuts

[11:06:05.0000] <MikeSmith>
they have this thing of charging 150% over what the meter shows

[11:06:06.0000] <MikeSmith>
if the trip is farther than 15 miles

[11:06:07.0000] <MikeSmith>
btw, on http://platform.html5.org/, should I just change "DOM4" to "DOM"?

[11:06:08.0000] <MikeSmith>
and still link to the DOM4 spec of course

[11:07:00.0000] <MikeSmith>
annevk: ↑

[11:08:00.0000] <bfrohs>
annevk, nav-index has the same problem as tabindex in that it is absolute. If there was a nav-index-scope, AND counter() could be used as the value for nav-index, then it would be sufficient.

[11:09:00.0000] <annevk>
MikeSmith, yeah

[11:11:00.0000] <bfrohs>
(where nav-index-scope was 'absolute' (or inherit) by default, with 'absolute' or 'relative' as values)

[11:12:00.0000] <MikeSmith>
annevk, OK, done

[11:15:00.0000] <karlcow>
annevk: I'm adding you the mail I'm sending to dom

[11:16:00.0000] <bfrohs>
Where would be the best place to suggest adding nav-index-scope to css ui? And making sure counter() values can be used for nav-index?

[11:16:01.0000] <karlcow>
rha my mail is  in French :D

[11:16:02.0000] <karlcow>
retranslating in English

[11:22:00.0000] <karlcow>
annevk: mail sent.

[11:23:00.0000] <annevk>
thanks

[11:24:00.0000] <karlcow>
my pleasure

[11:24:01.0000] <karlcow>
/me is out 

[11:25:00.0000] <AryehGregor>
annevk, what's the procedure for updating DOM4?  Should I just push to both dvcs.w3.org and bitbucket.org?

[11:30:00.0000] <annevk>
yeah

[11:30:01.0000] <AryehGregor>
Okay.

[11:35:00.0000] <AryehGregor>
Should isPointInRange() throw IndexSizeError if the offset is too large or negative, or should it return false?  WebKit throws, Gecko returns false.

[11:35:01.0000] <AryehGregor>
I'll go with WebKit here, since it's more consistent with other Range APIs, unless anyone has objections.

[11:35:02.0000] <AryehGregor>
(the API was never standardized before now, it's not in DOM 2 Range)

[11:36:00.0000] <smaug____>
I'd go for false

[11:36:01.0000] <AryehGregor>
Why?  The other Range APIs all throw IndexSizeError in those cases, right?

[11:36:02.0000] <smaug____>
because of the reason you gave yesterday ;)

[11:36:03.0000] <AryehGregor>
/me reviews the other APIs for inspiration

[11:37:00.0000] <smaug____>
but, need to go now

[11:37:01.0000] <AryehGregor>
If the point is in a different document, it makes sense to return false.  It's a legitimate point that's not in the range.

[11:37:02.0000] <AryehGregor>
If the point isn't a valid boundary point at all, the question doesn't even make sense.

[11:37:03.0000] <AryehGregor>
It's not clear that false is the right answer.

[11:37:04.0000] <AryehGregor>
If I do range.isPointInRange(node, -1) and node is entirely contained within range, is false really the correct answer?

[11:38:00.0000] <AryehGregor>
Oh, wait.

[11:38:01.0000] <AryehGregor>
Gecko actually returns true in that case . . .

[11:38:02.0000] <AryehGregor>
/me tests a bit more

[11:39:00.0000] <AryehGregor>
For an invalid offset, Gecko seems to return true if the node is entirely contained in the range, like with selectNode.  But false if it's not, even if every legitimate boundary point in it is contained, like with selectNodeContents.

[11:39:01.0000] <AryehGregor>
Too weird.

[11:39:02.0000] <AryehGregor>
I'll go with WebKit.

[11:47:00.0000] <erlehmann>
AryehGregor, throwing is more useful than false.

[11:47:01.0000] <erlehmann>
from a dev point of view

[11:47:02.0000] <AryehGregor>
Agreed.

[11:48:00.0000] <erlehmann>
no error console will log false

[11:49:00.0000] <erlehmann>
“should asking for the fifth element in a list with four elements return an empty string or crash the program” is actually an interesting question to ask people, even those who have nothing to do with programming.

[11:50:00.0000] <erlehmann>
i think it tells me something about their approach to solving problems.

[11:51:00.0000] <erlehmann>
my little sister, who is 10 and only recently learned a tiny bit of python was convinced that such a program should crash.

[11:51:01.0000] <erlehmann>
because it would help her to fix the program.

[11:51:02.0000] <erlehmann>
my mother says it should return empty or null or just something.

[11:51:03.0000] <erlehmann>
to not interrupt the flow of things.

[11:57:00.0000] <AryehGregor>
What should isPointInRange() do if passed a doctype?  WebKit throws InvalidNodeTypeError, while Gecko ignores the offset and returns true or false depending on whether the doctype is in the range or not.

[11:58:00.0000] <AryehGregor>
Hmm.

[11:58:01.0000] <AryehGregor>
Kind of like with bogus offsets.

[11:58:02.0000] <AryehGregor>
I think I'll go with WebKit for consistency.

[11:59:00.0000] <AryehGregor>
It seems like if the point isn't a valid boundary point, Gecko just ignores the offset and tests whether the node itself is in the range.

[11:59:01.0000] <AryehGregor>
Ooh, WebKit treats the second argument as optional.

[11:59:02.0000] <AryehGregor>
/me tests that

[12:00:00.0000] <AryehGregor>
It just defaults to 0.

[12:00:01.0000] <AryehGregor>
I think I won't allow that.

[12:07:00.0000] <AryehGregor>
What should a function throw if passed too few arguments, per spec?

[12:07:01.0000] <AryehGregor>
I guess that's in WebIDL?

[12:07:02.0000] <AryehGregor>
Or shouldn't it?

[12:10:00.0000] <AryehGregor>
What is R here?  http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm

[12:10:01.0000] <AryehGregor>
I don't see it defined.

[12:14:00.0000] <jgraham>
AryehGregor: Umm, maybe?

[12:14:01.0000] <jgraham>
We need a better review tool for sure

[12:16:00.0000] <AryehGregor>
I'd start with *any* review system.

[12:17:00.0000] <jgraham>
Yeah :)

[12:17:01.0000] <AryehGregor>
Like, attaching patches to Bugzilla.

[12:17:02.0000] <AryehGregor>
I'd do that if there were a Bugzilla component.

[12:17:03.0000] <jgraham>
I think there is

[12:17:04.0000] <jgraham>
I don't know if I get email from it though

[12:17:05.0000] <jgraham>
I can probably set it up if not

[12:22:00.0000] <AryehGregor>
Where is it?

[12:23:00.0000] <jgraham>
I don't know, I never needed to file a bug :p

[12:23:01.0000] <jgraham>
Maybe MikeSmith or plh knows

[12:24:00.0000] <MikeSmith>
bugzilla component for what?

[12:24:01.0000] <MikeSmith>
WebIDL?

[12:24:02.0000] <jgraham>
testharness.js

[12:26:00.0000] <MikeSmith>
oh

[12:26:01.0000] <MikeSmith>
yeah, we have component for it

[12:26:02.0000] <MikeSmith>
/me finds it

[12:26:03.0000] <MikeSmith>
http://www.w3.org/Bugs/Public/enter_bug.cgi?product=Testing&component=testharness.js

[12:30:00.0000] <bfrohs>
Where would be the best place to suggest adding nav-index-scope to css ui? And making sure counter() values can be used for nav-index? Anyone?

[12:34:00.0000] <AryehGregor>
bfrohs, www-style is for CSS changes.

[12:34:01.0000] <AryehGregor>
CC the editor of the relevant spec.

[12:35:00.0000] <bfrohs>
AryehGregor, thank ya

[12:36:00.0000] <heycam>
AryehGregor, extra arguments are ignored

[12:36:01.0000] <heycam>
AryehGregor, and that last line should be "Return candidates"

[12:36:02.0000] <heycam>
though I thought I'd already fixed that...

[12:36:03.0000] <AryehGregor>
heycam, but passing too few throws a TypeError, if I'm reading right?

[12:37:00.0000] <heycam>
AryehGregor, yeah

[12:37:01.0000] <AryehGregor>
There's another mention of R a couple lines before, by the way.

[12:37:02.0000] <heycam>
oh ok

[12:37:03.0000] <heycam>
/me notes it down

[12:46:00.0000] <AryehGregor>
jgraham, http://www.w3.org/Bugs/Public/show_bug.cgi?id=14589

[12:46:01.0000] <AryehGregor>
You're the assignee, so I assume you got e-mail.

[12:47:00.0000] <AryehGregor>
I'll commit the patch if you like, just give me the okay.

[13:19:00.0000] <AryehGregor>
Hmm.  Can we kill detach()?  It seems utterly, absolutely useless.

[13:19:01.0000] <AryehGregor>
And it adds a line to every single Range attribute/method.

[13:23:00.0000] <Hixie>
how do i create a file on windows with a specific set of bytes as the file name?

[13:23:01.0000] <Hixie>
i want to do the equivalent of:

[13:23:02.0000] <Hixie>
echo -e '\xE1\xBA\x9B\xCC\xA3\xE2\x84\xAB.txt' | xargs touch

[13:24:00.0000] <AryehGregor>
Are Windows filenames sequences of bytes?

[13:24:01.0000] <AryehGregor>
They're not UCS-2 or something?

[13:24:02.0000] <Hixie>
i can do sequences of unicode characters if there's a way to do that too

[13:25:00.0000] <Hixie>
U+1E9B U+0323 U+212B . t x t

[13:25:01.0000] <Hixie>
but i don't want, e.g., notepad.exe to be doing any munging of the characters before i save

[13:25:02.0000] <Hixie>
so i don't want to use a text box to do it

[13:25:03.0000] <Hixie>
if i can avoid it

[13:27:00.0000] <Hixie>
(how would i even do it there?)

[13:27:01.0000] <hober>
Hixie: you could use emacs

[13:28:00.0000] <_bga>
Hixie i recomend you install msys

[13:28:01.0000] <Hixie>
msys?

[13:29:00.0000] <Hixie>
hober: no emacs (and don't really want to install anything if i can help it)

[13:29:01.0000] <_bga>
Hixie http://www.mingw.org/wiki/MSYS

[13:29:02.0000] <Hixie>
i wouldn't trust such a system not to futz with the bytes between the shell and the file system

[13:29:03.0000] <Hixie>
too many levels of indirection involved

[13:39:00.0000] <zewt>
Hixie: filenames on ntfs are stored in UTF-16 (actually, just arbitrary 16-bit characters), so you can't use a "specific set of bytes"

[13:40:00.0000] <MikeSmith>
learning about https://wiki.mozilla.org/Auto-tools/Projects/Marionette

[13:51:00.0000] <zewt>
Hixie: also, notepad is a pretty safe way to create filenames in unicode, because it's a unicode application itself (most programs are ANSI, which will trigger locale-specific conversions)

[13:52:00.0000] <Hixie>
zewt: 16 codepoints are bytes too :-)

[13:52:01.0000] <Hixie>
zewt: my concern is over unicode normalisation

[13:52:02.0000] <Hixie>
zewt: see http://www.w3.org/Bugs/Public/show_bug.cgi?id=14526

[13:56:00.0000] <zewt>
well, i created \u03D3\u03D2\u0301.txt in File Explorer, and it doesn't appear to have normalized it at all

[13:56:01.0000] <Hixie>
yeah that was my experience too, see the last comment on the bug

[13:59:00.0000] <zewt>
for real headaches: illegal code sequences in filenames exposed to JS ...

[13:59:01.0000] <zewt>
(a question FileAPI will have to figure out at some point)

[14:02:00.0000] <Hixie>
Philip`: would be good to have tests like http://test.w3.org//html/tests/submission/PhilipTaylor/canvas/security.pattern.canvas.fillStyle.html that check interaction with document.domain (i'm about to change the spec on this to use the effective origin)

[16:00:00.0000] <kennyluck>
Hmm.. the mbox archive output by whatwg.org doesn't do >From quotation.

[16:06:00.0000] <ojan>
Hixie: is the case-sensitivity of attribute names for svg in html specified anywhere?

[16:06:01.0000] <ojan>
Hixie: i'm having trouble finding it in the html spec

[16:06:02.0000] <Hixie>
case-sensitivity in what sense?

[16:07:00.0000] <ojan>
Hixie: in regular html, attribute names are lowercased

[16:07:01.0000] <Hixie>
you mean when parsing?

[16:07:02.0000] <ojan>
Hixie: in regular svg, attribute names keep their case

[16:07:03.0000] <ojan>
Hixie: yeah

[16:07:04.0000] <Hixie>
aah

[16:08:00.0000] <Hixie>
yeah that's in the parser

[16:08:01.0000] <Hixie>
hold on

[16:08:02.0000] <Hixie>
i'll give you a search string

[16:08:03.0000] <ojan>
Hixie: great

[16:08:04.0000] <Hixie>
search for "adjust SVG attributes"

[16:10:00.0000] <ojan>
Hixie: so basically, we parse it ignoring case and then spit out the case-sensitive result?

[16:10:01.0000] <Hixie>
yeah

[16:10:02.0000] <Hixie>
well

[16:10:03.0000] <Hixie>
we spit out a case-normalised result

[16:10:04.0000] <ojan>
Hixie: e.g. paThLength -> pathLength ?

[16:10:05.0000] <Hixie>
right

[16:10:06.0000] <ojan>
Hixie: ok...here's the problem we're running into...

[16:11:00.0000] <Hixie>
paThLength in the markup becomes pathlength in the parser becomes pathLength in the DOM

[16:11:01.0000] <ojan>
Hixie: selector parsing says the case-sensitivity of attirbute name/value parsing depends on the document type

[16:11:02.0000] <ojan>
Hixie: so, webkit always lowercases attribute names in html documents

[16:12:00.0000] <Hixie>
that's changed iirc

[16:12:01.0000] <ojan>
Hixie: so now *[pathLength] doesn't match <svg pathLength="...">

[16:12:02.0000] <ojan>
because the attribute name in the selector is lowercased and the one on the svg element isn't

[16:12:03.0000] <ojan>
Hixie: it doesn't seemd changed to me in the selectors 4 spec

[16:13:00.0000] <Hixie>
hmm, i may be thinking of attribute _values_

[16:13:01.0000] <ojan>
Hixie: http://dev.w3.org/csswg/selectors4/#attribute-case

[16:13:02.0000] <Hixie>
yeah i'm thinking of values, don't mind me

[16:13:03.0000] <Hixie>
let's see

[16:14:00.0000] <Hixie>
ok so the HTML spec says that "and element names of HTML elements in HTML documents must be treated as ASCII case-insensitive for the purposes of selector matching"

[16:14:01.0000] <Hixie>
so [pathLength] should match <div pathlength> but not <svg pathlength>

[16:15:00.0000] <ojan>
Hixie: yes...but the problem is that it's currently impossible as speced to match <svg pathlength>

[16:16:00.0000] <Hixie>
[pathLength] would match it

[16:16:01.0000] <Hixie>
since the parser would convert it to pathLength in the DOM

[16:17:00.0000] <ojan>
Hixie: oh...i guess it's technically wrong that webkit lowercases the attribute name in the css parser

[16:17:01.0000] <ojan>
it should just be doing a case-insensitive compare

[16:17:02.0000] <ojan>
for html elements

[16:17:03.0000] <Hixie>
yeah

[16:17:04.0000] <Hixie>
html elements in html documents

[16:17:05.0000] <ojan>
right

[16:17:06.0000] <ojan>
sigh

[16:24:00.0000] <ojan>
Hixie: arv is suggesting that selector attribute matching in an HTML document shoudl always be case-insensitive regardless of what element you're matching

[16:26:00.0000] <ojan>
Hixie: why not make svg attributes in html documents lowercase like all other attributes?

[16:26:01.0000] <Hixie>
well the attributes being lowercase would mean that there'd be two SVG vocabularies

[16:26:02.0000] <Hixie>
one with lowercase names and one not

[16:26:03.0000] <Hixie>
which would have rammifications i can't even fully imagine

[16:27:00.0000] <hober>
ojan: DOM Consistency, basically

[16:27:01.0000] <Hixie>
but would certainly be a disaster for implementors

[16:27:02.0000] <Hixie>
consider the confusion that would result from taking an SVG file and moving the nodes to an HTML file and finding it all stopped working, e.g.

[16:27:03.0000] <Hixie>
anyway, that's one thing

[16:28:00.0000] <Hixie>
the other thing is case-sensitivity

[16:28:01.0000] <Hixie>
i don't really mind what we do there, that's an issue for the css and svg groups to decide

[16:28:02.0000] <Hixie>
i expect css would say it's up to svg, css just delegates to the host language

[16:28:03.0000] <Hixie>
and i've no idea what the svg group would want

[16:28:04.0000] <Hixie>
i haven't worked out what their operating principles are

[16:28:05.0000] <shepazu>
I could ask them

[16:29:00.0000] <shepazu>
for SVG2, we are not claiming it is an XML syntax, but a DOM one

[16:29:01.0000] <Hixie>
ojan, shepazu; shepazu, ojan.

[16:29:02.0000] <Hixie>
/me steps back :-0

[16:29:03.0000] <shepazu>
(though there is, of course, an XML parsing)

[16:30:00.0000] <ojan>
Hixie, shepazu: people here are suggesting that maybe we should do the HTML normalization of svg attribute names at attribute matching time

[16:30:01.0000] <shepazu>
Hixie: at least, that's what I said in the charter that's up for review now

[16:30:02.0000] <Hixie>
ojan: what would that mean?

[16:30:03.0000] <shepazu>
/me is not sure what the implications of that are, ojan 

[16:32:00.0000] <shepazu>
Hixie: fyi http://www.w3.org/Graphics/SVG/2011/charter.html

[16:32:01.0000] <shepazu>
[[

[16:32:02.0000] <shepazu>
The SVG WG develops the following technologies:    A markup syntax, compatible with XML and HTML5 parsing, for describing shapes, text, and painting effects, including gradients, filters, and other graphical effects, through a set of elements and attributes.

[16:32:03.0000] <shepazu>
]]

[16:33:00.0000] <shepazu>
so, I don't say "DOM", but that's the implication

[16:33:01.0000] <shepazu>
(or something)

[16:34:00.0000] <ojan>
shepazu: the implication is that *[pathlength] would match <svg pathLength=5>

[16:35:00.0000] <Hixie>
ojan: would it match <div pathlength>?

[16:35:01.0000] <shepazu>
ojan: seems friendly to me, but not sure about the implementation fallout

[16:35:02.0000] <ojan>
Hixie: yeah

[16:35:03.0000] <Hixie>
shepazu: "a markup syntax, compatible with XML and HTML5 parsing" is, like, the opposite of a "DOM"...

[16:35:04.0000] <shepazu>
Hixie: ok, patches welcome

[16:35:05.0000] <ojan>
it's a performance tradeoff as far as implementation is concerned

[16:36:00.0000] <Hixie>
shepazu: i think charters are irrelevant, so i don't mind either way, i'm just saying that if you meant to say DOM, you should be aware that what you just quoted says the opposite :-)

[16:36:01.0000] <shepazu>
ojan: I'm more concerned about backward-compatibility

[16:36:02.0000] <Hixie>
ojan: i don't understand what "do the HTML normalization of svg attribute names at attribute matching time" means then.

[16:36:03.0000] <ojan>
with *[pathlength] matching <svg pathLength=5>, you can store only the lower-cased copy of the attribute name and for html elements, the name comparison is very fast, but it's slower for svg elements

[16:36:04.0000] <shepazu>
Hixie: too jetlagged to follow you, but interested to hear an explanation I could unpack later

[16:37:00.0000] <ojan>
Hixie: basically...when parsing *[pathLenGTH] we'd normalize it to *[pathlength]...

[16:37:01.0000] <Hixie>
shepazu: sure, ping me if you want to talk about it

[16:37:02.0000] <Hixie>
ojan: how do you know to normalize it?

[16:37:03.0000] <ojan>
Hixie: then when doing selector matching, if it's an SVG element we'd actually compare to pathLength

[16:37:04.0000] <erlehmann>
ojan, but pathLenGTH is WRONG

[16:37:05.0000] <erlehmann>
oh okey

[16:37:06.0000] <ojan>
erlehmann: for HTML elements, it would match

[16:38:00.0000] <erlehmann>
i hate every single member of your working group for that

[16:38:01.0000] <erlehmann>
;)

[16:38:02.0000] <Hixie>
ojan: i mean, what if MathML had a "foobar" attribute and SVG had a "fooBar" attribute?

[16:38:03.0000] <erlehmann>
Hixie, namespac- oh wait.

[16:39:00.0000] <Hixie>
ojan: and would you match [pathlength] to an <svg> element that had a "pathlength" attribute manually set in the DOM? (lowercase, so not the real pathLength one?)

[16:39:01.0000] <ojan>
Hixie: what about it? *[foobAr] would match both of them

[16:39:02.0000] <ojan>
Hixie: yeah...i guess that doens't make sense

[16:39:03.0000] <ojan>
Hixie: sigh...svg in html... :(

[16:39:04.0000] <erlehmann>
well, seems “claiming SVG is not XML, but a DOM syntax” needs some work.

[16:40:00.0000] <Hixie>
ojan: "just" do the comparison case-insensitively against HTML elements and case-sensitively against non-HTML elements

[16:40:01.0000] <ojan>
Hixie: yeah...fine.

[16:40:02.0000] <Hixie>
ojan: it means having both strings in the comparison function, and one extra pointer check for each node

[16:40:03.0000] <Hixie>
ojan: not the end of the world

[16:40:04.0000] <ojan>
Hixie: yeah

[16:40:05.0000] <Hixie>
perf-wise

[16:41:00.0000] <ojan>
Hixie: yeah...it means storing an extra string if you want to keep the performance for html element matching

[16:41:01.0000] <Hixie>
yeah but you have that extra string anyway today, right

[16:41:02.0000] <ojan>
but attribute selectors are not widely used enought for it to really matter

[16:41:03.0000] <erlehmann>
why not something like *[html:pathlenght|svg:pathLength]

[16:41:04.0000] <Hixie>
or are you flattening it during parsing?

[16:41:05.0000] <ojan>
Hixie: no, right now webkit only stores the lowercased string

[16:41:06.0000] <erlehmann>
what am i missing?

[16:41:07.0000] <Hixie>
css parsing

[16:41:08.0000] <ojan>
yeah

[16:41:09.0000] <Hixie>
ah ok

[16:41:10.0000] <Hixie>
yeah that's unfortunate

[16:41:11.0000] <Hixie>
are you atom-ifying these strings?

[16:41:12.0000] <ojan>
meh, like you said it's not a big deal

[16:42:00.0000] <ojan>
Hixie: atom-ifying?

[16:42:01.0000] <Hixie>
whatever terminology webkit uses... converting them to a pointer rather than storing the literal string

[16:42:02.0000] <ojan>
Hixie: ah. yes.

[16:42:03.0000] <Hixie>
ok so it's really just one extra pointer

[16:42:04.0000] <Hixie>
plus a pointer check

[16:43:00.0000] <Hixie>
plus you get to flatten the logic for xml and html

[16:43:01.0000] <ojan>
Hixie: i'm not sure we'd atomify the non-lowercased string

[16:44:00.0000] <Hixie>
why not?

[16:44:01.0000] <ojan>
Hixie: creating AtomicStrings isn't free

[16:44:02.0000] <ojan>
Hixie: the main reason you do it is so you can have quick string comparisons

[16:44:03.0000] <Hixie>
yeah but the cost has to be offset against the many comparisons you're going to be doing

[16:44:04.0000] <Hixie>
and the same string will likely exist in the DOM too, right

[16:44:05.0000] <Hixie>
anyway

[16:45:00.0000] <Hixie>
what do i know :-)

[16:45:01.0000] <ojan>
oh...i guess for the non-lowercase one we'd still just be doing a case-senstiive comapre...so we probably would. you're right

[16:45:02.0000] <ojan>
yeah...so in the common case it would not be considerably more memroy


2011-10-29
[19:49:00.0000] <roc>
/me wonders where annevk is

[19:55:00.0000] <ojan>
roc: u gonna be a tpac?

[19:55:01.0000] <roc>
no

[19:56:00.0000] <ojan>
roc: k...just wondering

[19:56:01.0000] <roc>
I'm not a huge fan of face-to-face standards work to be honest

[19:57:00.0000] <ojan>
me neither really

[19:57:01.0000] <ojan>
but it's good to meet people in erspon

[19:57:02.0000] <roc>
yeah, I like that, but large groups freak me out

[19:58:00.0000] <roc>
where are you based btw?

[20:15:00.0000] <ojan>
roc: sorry, was afk...

[20:15:01.0000] <ojan>
roc: i'm in SF..so this tpac is easy for me :)

[20:15:02.0000] <ojan>
i'll probably only be there mon/tues though

[20:16:00.0000] <ojan>
there was a while where i was in sydney frequently...but haven't been since april

[21:33:00.0000] <jgraham>
AryehGregor: You should be able to test for type error using assert_throws(TypeError(), fun);

[22:41:00.0000] <annevk>
Yeah so currently storing two pointers for Selector matching would yield the incorrect result.

[22:42:00.0000] <annevk>
Because if you define an attribute named "HREF" through the DOM on an HTML element, that should still match [href] per current specifications.

[22:42:01.0000] <annevk>
And it will in e.g. Gecko.

[22:43:00.0000] <annevk>
So either we need to drop the notion that Selector matching happens case-insensitively for HTML and require the double-pointer approach, or we all need to do case-insensitive matching.

[22:43:01.0000] <annevk>
Edge cases...

[23:46:00.0000] <annevk>
Hmm, seems I should really get around to writing a WHATWG Weekly

[23:46:01.0000] <Hixie>
well i just gave you something to talk abuot

[23:47:00.0000] <annevk>
Yeah, but I already had a big list :)

[00:11:00.0000] <boblet>
is there a <data> equivalent of <time pubdate> besides schema.org?

[00:11:01.0000] <boblet>
also, http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html doesn't seem to load for me?

[00:12:00.0000] <Hixie>
boblet: well you can use any microdata vocabulary or microformats vocabulary, i guess :-)

[00:12:01.0000] <Hixie>
boblet: e.g. hAtom

[00:13:00.0000] <Hixie>
what is section-index supposed to be?

[00:14:00.0000] <Hixie>
looks like i'm getting it that way from anne

[00:15:00.0000] <Hixie>
annevk: i'm getting some weird stuff in the zip file, in fact

[00:15:01.0000] <boblet>
Hixie: trying to load http://www.whatwg.org/specs/web-apps/current-work/multipage/section-index.html#attributes-1 to confirm @pubdate is dropped :)

[00:15:02.0000] <Hixie>
including a do-multipage-... file?

[00:15:03.0000] <boblet>
that’s the link in Index at the bottom of http://www.whatwg.org/specs/web-apps/current-work/multipage/

[00:15:04.0000] <Hixie>
let me try to regen it manually

[00:18:00.0000] <Hixie>
boblet: how's now?

[00:18:01.0000] <annevk>
Hixie, oh again? :(

[00:18:02.0000] <boblet>
Hixie: wfm

[00:18:03.0000] <annevk>
foolip made some changes recently

[00:18:04.0000] <Hixie>
annevk: looks like the section thing was a one-off error

[00:18:05.0000] <Hixie>
annevk: but there's a do-multipage-... file that seems odd

[00:18:06.0000] <Hixie>
annevk: dunno what it is

[00:19:00.0000] <Hixie>
annevk: it's ok otherwise

[00:19:01.0000] <boblet>
needing to move to a microdata/microformats vocab to convey pubdate (which I’d assume search engines would like) seems like a big increase in code. otoh i was wanting updated date anyhow. hrm

[00:20:00.0000] <annevk>
Hixie, I think that's the file it fetches in order to do the update

[00:20:01.0000] <Hixie>
boblet: search engines want schema.org apparently :-)

[00:20:02.0000] <Hixie>
annevk: but why is it ending up in the archive?

[00:20:03.0000] <annevk>
because I'm doing a wget

[00:20:04.0000] <Hixie>
use -O - :-)

[00:21:00.0000] <boblet>
Hixie: if it works as an encouragement for everyone to change time@pubdate to schema.org/blogpost then sure that’s great

[00:22:00.0000] <boblet>
will have to write something for HTML5 Doctor now too, and publish something about microdata blogpost vocab. making us work again! sheesh :)

[00:23:00.0000] <Hixie>
:-)

[00:23:01.0000] <Hixie>
<time pubdate> was going nowhere fast

[00:23:02.0000] <Hixie>
and was disproportionally expensive in terms of what it required of implementations

[00:24:00.0000] <Hixie>
so...

[00:26:00.0000] <boblet>
I was siding with <time> needing some time to implement (l10n stuff always takes forever), but if browsers can use <data itemprop="datePublished"> for the same purpose… <data> def. helps with adding microdata (crap, another two articles I’ll need to update >_<)

[00:27:00.0000] <annevk>
<time> would prolly have ended up like counters in CSS

[00:27:01.0000] <annevk>
kind of cool, but hardly used, and disproportionate complexity

[00:27:02.0000] <boblet>
Hixie: btw, did you read the <u> element article? I had several quotes from you in there http://html5doctor.com/u-element

[00:28:00.0000] <boblet>
annevk: is this CSS2.1 or CSS3? ;)

[00:28:01.0000] <boblet>
TabAtkins’ rewrite is much cleaner

[00:28:02.0000] <boblet>
really looking forward to that being implemented

[00:30:00.0000] <annevk>
boblet, 2

[00:30:01.0000] <annevk>
boblet, is css3-lists touching counters?

[00:30:02.0000] <annevk>
boblet, I thought that was just lists and stuff

[00:34:00.0000] <boblet>
annevk: I thought css3 lists would be flexible enough to do the same use-cases, but I’m prolly just confused

[00:36:00.0000] <annevk>
boblet, counters can be used for way more than lists

[00:38:00.0000] <annevk>
boblet, does not seem like css3-lists defines counter-increment and such, it does refer to them

[00:52:00.0000] <matjas>
so, is <data data-data=data>data</data> now valid HTML?

[00:52:01.0000] <annevk>
no

[00:53:00.0000] <annevk>
value is required

[00:53:01.0000] <matjas>
i see

[00:59:00.0000] <matjas>
no replacement for `valueAsDate`? :(

[01:02:00.0000] <annevk>
does new Date() not do that?

[01:03:00.0000] <annevk>
bah

[01:03:01.0000] <annevk>
web-apps-tracker is generating errors :(

[01:05:00.0000] <matjas>
hovering over the data element section brings up a link to the abbr element: http://i.imgur.com/HIWhh.png typo?

[01:06:00.0000] <matjas>
in the last example, should the <data> element be closed explicitly? <tr> <td> 1830 <td> <data value="8">Eight</data> <td> <data value="93">19+74 hexes (93 total)

[01:06:01.0000] <annevk>
the first is prolly because <data> does not have its own section yet

[01:06:02.0000] <annevk>
the second is a bug

[01:07:00.0000] <annevk>
I guess html5.org went over some storage limit

[01:07:01.0000] <annevk>
50 GiB or so

[01:08:00.0000] <annevk>
I'll just empty the cache as a hack

[01:10:00.0000] <annevk>
whoa, it was approaching 60

[01:10:01.0000] <annevk>
way to go for simple SVN diffs

[01:10:02.0000] <matjas>
annevk: thanks for confirming, I’ll file it

[01:30:00.0000] <annevk>
http://blog.whatwg.org/weekly-time-data

[03:30:00.0000] <roc>
annevk: what did you think about my fullscreen suggestion for a fullscreen element stack?

[03:31:00.0000] <annevk>
I suggested that in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-October/033549.html but responses were not enthusiastic

[03:34:00.0000] <roc>
I don't think they thought through the implications

[03:35:00.0000] <roc>
the nested case is not some complex edge case that most apps can't hit. You can hit it as soon as you can make a document full-screen that contains some other content that supports full-screen, which could easily happen by accident even

[03:36:00.0000] <roc>
as soon as you have a document that supports full-screen that might contain an embedded Youtube video, for example

[03:37:00.0000] <roc>
I'll follow up to that thread

[03:40:00.0000] <annevk>
Please only talk about making elements fullscreen though

[03:40:01.0000] <annevk>
We're not really making documents fullscreen

[03:40:02.0000] <roc>
ok

[03:43:00.0000] <annevk>
One alternative is making requestFullscreen always do its thing and exitFullscreen always do a full exit

[03:43:01.0000] <roc>
that seems broken

[03:44:00.0000] <annevk>
Yeah, though given the number of different scenarios I think the user will always find it confusing :(

[03:44:01.0000] <roc>
we can at least make the simple things work

[03:45:00.0000] <annevk>
If the user is already fullscreen for instance (by using F11) and then gets the message that "Esc" will get him/her out but it will actually not...

[03:45:01.0000] <roc>
actually it will

[03:46:00.0000] <roc>
"Esc" has to always bust out of all fullscreening

[03:46:01.0000] <annevk>
Gecko will exit browser fullscreen if element fullscreen is quit?

[03:46:02.0000] <annevk>
I doubt users will like that... It's not how browser fullscreen and YouTube behave today

[03:47:00.0000] <roc>
I'm not sure what the current behavior is, but I think it needs to break out

[03:48:00.0000] <annevk>
If I use fullscreen mode on Mac OS I don't want the browser to just exit that after I have watched a video

[03:48:01.0000] <roc>
well, that can be up to the UA

[03:50:00.0000] <roc>
if the UA is permanently in fullscreen mode then I don't think "press ESC to exit fullscreen" would ever be the right message to display

[04:47:00.0000] <benschwarz>
heyo

[04:47:01.0000] <benschwarz>
annevk: whats the scoop with <time> ? #whatwg list?

[04:48:00.0000] <annevk>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 ?

[04:48:01.0000] <benschwarz>
w3 change?

[04:48:02.0000] <annevk>
suggestion has been out there for several months

[04:48:03.0000] <annevk>
not sure what you mean

[04:48:04.0000] <benschwarz>
never caught it…

[04:49:00.0000] <benschwarz>
I was wondering where it orginated from

[04:49:01.0000] <benschwarz>
… people have already implemented time

[04:50:00.0000] <benschwarz>
annevk: so is the resolve to use <data> with a rel attribute? or… data-*?

[04:50:01.0000] <annevk>
depends on what you are trying to do

[04:51:00.0000] <benschwarz>
ok. so display the time that an article was published…

[04:51:01.0000] <benschwarz>
and er… I can't think of a more data driven example.

[04:51:02.0000] <benschwarz>
… its a strange change

[04:51:03.0000] <annevk>
prolly just <p class=meta> as before

[04:52:00.0000] <annevk>
just displaying doesn't need to be machine readable

[04:52:01.0000] <annevk>
but if you want it to be machine readable, the specification includes some examples using the http://schema.org/Blog vocabulary

[04:55:00.0000] <benschwarz>
no one uses schema vocabularies :)

[04:56:00.0000] <benschwarz>
(you know, in the real world)

[05:00:00.0000] <annevk>
yeah, I don't really care

[05:01:00.0000] <annevk>
I mean, I don't really care about schema.org or Microdata that much

[05:01:01.0000] <annevk>
it's better than RDFa, but still pretty complex and not too useful

[05:03:00.0000] <Tuju>
is there a way to define CSS version when introducing it in xhtml headers?

[05:04:00.0000] <annevk>
CSS has no versions

[05:04:01.0000] <benschwarz>
annevk: well, I tend to agree. It means nothing to the real world, acedemics might argue… but the rest of the world isn't convinced :)

[05:05:00.0000] <Tuju>
i just read about CSS tag overflow and it had comment 'this might change in version 2.1'  - how are people supposed to design some appearance if terminal software don't know how they're supposed to interpret it?

[05:06:00.0000] <Ms2ger>
good morning, Whatwg!

[05:06:01.0000] <annevk>
Tuju, where does it say that?

[05:06:02.0000] <annevk>
Ms2ger, more like, midday?

[05:07:00.0000] <Tuju>
http://www.w3.org/TR/CSS21/visufx.html#overflow-clipping  "Note. In CSS 2.1, all clipping regions are rectangular. We anticipate future extensions to permit non-rectangular clipping. Future updates may also reintroduce a syntax for offsetting shapes from each edge instead of offsetting from a point."

[05:07:01.0000] <Ms2ger>
annevk, sure

[05:08:00.0000] <annevk>
Tuju: the future extensions will degrade gracefully

[05:08:01.0000] <Tuju>
meaning that they don't change earlier behaviour?

[05:08:02.0000] <annevk>
Tuju: none of the languages for the web has versioning, software just interprets per whatever they implemented

[05:09:00.0000] <annevk>
Tuju: typically, though sometimes earlier behavior is changed if it doesn't cause too much problems

[05:09:01.0000] <smaug____>
JS has versioning

[05:09:02.0000] <Tuju>
annevk: that could very well be the reason why the web is such a mess.

[05:09:03.0000] <smaug____>
(thought I don't recall what HTML spec says about js versioning )

[05:09:04.0000] <annevk>
Tuju: see http://www.w3.org/TR/html-design-principles/#degrade-gracefully for more information

[05:09:05.0000] <Tuju>
devs use that constantly as an excuse to produce invalid crap that don't render correctly.

[05:09:06.0000] <smaug____>
s/thought/though/

[05:09:07.0000] <annevk>
smaug____: mostly Mozilla proprietary

[05:10:00.0000] <annevk>
smaug____: and the "use strict"; mode switch of course

[05:10:01.0000] <annevk>
Tuju: "invalid crap" might change in the future

[05:11:00.0000] <Tuju>
annevk: what do you mean by that?

[05:11:01.0000] <annevk>
Tuju: so whoever is using that as excuse is wrong

[05:11:02.0000] <Tuju>
that's not a big relief.

[05:11:03.0000] <annevk>
Tuju: e.g. overflow-x:scroll was invalid at some point, but now it is valid

[05:11:04.0000] <Tuju>
page still does not work.

[05:11:05.0000] <Ms2ger>
smaug____, the HTML spec doesn't say anything, I believe.. It just says to support all the mime types

[05:12:00.0000] <annevk>
it might say something about E4X

[05:12:01.0000] <annevk>
but that's obsolete now

[05:12:02.0000] <Ms2ger>
Mm, yeah

[05:12:03.0000] <annevk>
someone should prolly file a bug on that

[05:13:00.0000] <Ms2ger>
Why is it obsolete?

[05:13:01.0000] <smaug_____>
interesting. did I just manage to overheat this laptop

[05:14:00.0000] <annevk>
Ms2ger: a) Brendan made E4X work without that flag and b) E4X is disabled in strict mode meaning it is on its way out

[05:14:01.0000] <annevk>
Ms2ger: well, got disabled

[05:14:02.0000] <annevk>
/me wonders why smaug____ is not just smaug

[05:14:03.0000] <Ms2ger>
Because it's a common nick

[05:14:04.0000] <smaug____>
because someone else is smaug

[05:14:05.0000] <smaug____>
in some other channel

[05:14:06.0000] <Ms2ger>
Lots of dragons on freenode

[05:14:07.0000] <gsnedders>
Why so many underscores?

[05:15:00.0000] <smaug____>
because someone else is using all the other forms of smaug_*

[05:15:01.0000] <smaug____>
____ is just the tail

[05:17:00.0000] <smaug____>
annevk: what you mean with "Brendan made E4X work without that flag" ?

[05:17:01.0000] <smaug____>
I thought you need a flag to enable it

[05:18:00.0000] <annevk>
no

[05:18:01.0000] <annevk>
you can just do

[05:18:02.0000] <annevk>
var x = <fancy/>

[05:18:03.0000] <annevk>
and you have some XML in your x

[05:20:00.0000] <smaug____>
really

[05:20:01.0000] <smaug____>
I thought you need some flag in the <script> element

[05:25:00.0000] <annevk>
yeah before, but Brendan figured something out that worked around why that was required in the first place

[05:28:00.0000] <Ms2ger>
The problem was <!--, IIRC

[05:29:00.0000] <hsivonen>
does Harmony try to do out of band or per-.js file versioning?

[05:30:00.0000] <annevk>
I hope neither

[05:31:00.0000] <Ms2ger>
The idea was using type= :/

[05:33:00.0000] <annevk>
ffs

[06:31:00.0000] <MikeSmith>
hsivonen: when you have time, please take a look at http://www.w3.org/Bugs/Public/show_bug.cgi?id=10174#c4

[06:32:00.0000] <MikeSmith>
reproducible intermittent bug when trying to validate http://nisza.org/rendering_tests/utf-8-validation.html

[06:40:00.0000] <MikeSmith>
hsivonen: in my environment, from a clean install and build from the upstream sources, I can reproduce this 100% of the time

[06:40:01.0000] <MikeSmith>
with that http://nisza.org/rendering_tests/utf-8-validation.html file

[06:41:00.0000] <MikeSmith>
I don't actually understand why in the W3C validator environment it doesn't occur 100% of time, except that must sometimes be gzipping it and other times not

[11:34:00.0000] <smaug____>
annevk: does Opera use NSS?

[11:39:00.0000] <gsnedders>
smaug____: No.

[11:40:00.0000] <gsnedders>
smaug____: Uses OpenSSL


2011-10-30
[20:19:00.0000] <crocket>
hi

[20:19:01.0000] <crocket>
Will there be a volume attribute for <video> an <audio> tags in case some internet boards don't allow javascript?

[23:08:00.0000] <annevk>
crocket, I don't think there are plans for that

[01:42:00.0000] <crocket>
hmm

[01:42:01.0000] <crocket>
Please make a plan to place a volume attribute in <audio> and <video> tags.

[01:43:00.0000] <Ms2ger>
Why?

[01:43:01.0000] <crocket>
On internet boards that don't allow javascripts, the initial volume should be set with a tag attribute.

[01:44:00.0000] <crocket>
Ms2ger, You know most of internet boards prohibit javascripts for security.

[01:44:01.0000] <Ms2ger>
Why would you need to set the volume?

[01:44:02.0000] <crocket>
The default volume is 100%

[01:44:03.0000] <crocket>
which is too loud for some audio files.

[01:44:04.0000] <crocket>
I need to pre-configure it to be 10~20%.

[01:45:00.0000] <crocket>
I don't want to surprise people with music.

[01:45:01.0000] <crocket>
I myself was surprised many times with 100% volume.

[01:45:02.0000] <crocket>
BGM

[01:46:00.0000] <crocket>
Ms2ger, interested

[01:46:01.0000] <crocket>
Ms2ger, interested?

[01:46:02.0000] <Ms2ger>
Not particularly, but it's not me you have to convince

[03:25:00.0000] <hsivonen>
I haven't incremented the version number of Validator.nu in ages. I think I should change the version number to "Living Validator@

[03:25:01.0000] <hsivonen>
s/@/"/

[08:33:00.0000] <Hixie>
hsivonen: google search doesn't show a version number

[08:52:00.0000] <david_carlisle>
whatwg weekly highlighted that microdata attributes don't apply to MathML. If we wanted them to apply to MathML, what would be the right course of action?

[08:55:00.0000] <Ms2ger>
One hint: it's not namespaces ;)

[08:55:01.0000] <david_carlisle>
good:-)

[09:01:00.0000] <david_carlisle>
Ms2ger: I don't think an author a document should be too concerned with which WG specified which element, so if microdata works in most places I'd rather it worked in mathml too

[09:02:00.0000] <Ms2ger>
Makes sense

[09:02:01.0000] <david_carlisle>
Ms2ger: but as noted in the topic of this channel, sense isn't always enough

[09:06:00.0000] <Ms2ger>
I'm sure Hixie can tell you how to approach it :)

[09:25:00.0000] <Ms2ger>
TabAtkins, should there be an obsoletion notice on css3-cascade?

[09:31:00.0000] <TabAtkins_>
Ms2ger: The WG decided no, since we're going to chunk the "value computation steps" from Values to Cascade.

[09:38:00.0000] <TabAtkins_>
(In other words, we plan to attach an editor to it.)

[09:38:01.0000] <Ms2ger>
And editor time? :)

[09:38:02.0000] <TabAtkins_>
Editors are composed of editor time.  Names by themselves don't qualify as editors. ^_^

[09:44:00.0000] <smaug____>
Ms2ger: default value for optional boolean parameter is false, right?

[09:44:01.0000] <Ms2ger>
Yes

[09:44:02.0000] <Ms2ger>
Unless stated otherwise in prose

[09:45:00.0000] <smaug____>
ah, right

[09:45:01.0000] <smaug____>
ok

[09:45:02.0000] <smaug____>
I'm thinking about importNode

[09:46:00.0000] <smaug____>
webkit supports optional parameter (probably the generic bug to allow leaving out some parameters), but it defaults to deep=false

[09:46:01.0000] <Ms2ger>
Mm

[09:46:02.0000] <Ms2ger>
And the spec defaults to true

[09:46:03.0000] <smaug____>
well, spec makes more sense

[09:46:04.0000] <smaug____>
er

[09:46:05.0000] <smaug____>
I mean true means more sense in this case

[09:47:00.0000] <Ms2ger>
Agreed

[09:48:00.0000] <smaug____>
s/means/makes/

[09:48:01.0000] <smaug____>
ugh

[09:49:00.0000] <Ms2ger>
/me files a webkit bug

[09:55:00.0000] <Ms2ger>
Once I figure out where they put DOM bugs

[13:53:00.0000] <Ms2ger>
And the WG is redesigning gradients again!

[13:55:00.0000] <smaug____>
nice

[13:55:01.0000] <smaug____>
I wonder how many different syntaxes there has been

[13:56:00.0000] <Ms2ger>
I don't want to know

[13:56:01.0000] <Rik`___>
they can't even choose the room temperature :)

[13:57:00.0000] <smaug____>
Ms2ger: btw, I tried to change the component of your webkit bug, but could figure out any what component could be the right one

[13:57:01.0000] <smaug____>
s/could/couldn't/

[13:57:02.0000] <Ms2ger>
Same here

[13:57:03.0000] <smaug____>
why am I typing so badly today

[14:04:00.0000] <Ms2ger>
smaug____, yep, random insanity is what we spec writers are good at ;)

[14:06:00.0000] <smaug____>
sorry :)

[14:07:00.0000] <Ms2ger>
Well, it's true

[14:08:00.0000] <Ms2ger>
But we really should get you to write some specs yourself ;)

[14:09:00.0000] <smaug____>
obviously it would be full of random typing errors

[14:09:01.0000] <smaug____>
but otherwise 100% sane

[14:10:00.0000] <smaug____>
well, I could try first 10% sanity level

[14:12:00.0000] <Ms2ger>
:)


2011-10-31
[00:28:00.0000] <zcorpan>
"Table having datatable="0" attribute is layout table (Firefox 10)" http://asurkov.blogspot.com/2011/10/data-vs-layout-table.html

[00:30:00.0000] <hsivonen>
zcorpan: I tried to comment to ask what that was about, but the commenting system didn't work in Firefox

[00:31:00.0000] <hsivonen>
oh, now there are additional comments explaining that it's a JAWSism

[00:31:01.0000] <hsivonen>
sigh

[00:37:00.0000] <hsivonen>
I was able to comment using Opera

[00:38:00.0000] <hsivonen>
could be due to Blogger sniffing problems with Firefox 10

[00:38:01.0000] <hsivonen>
or I have some privacy settings in Firefox that Blogger doesn't like

[01:33:00.0000] <foolip>
annevk, doesn't http://jsconsole.com/ and http://software.hixie.ch/utilities/js/live-dom-viewer/ have the same issue?

[01:34:00.0000] <zcorpan>
foolip: yes

[01:34:01.0000] <zcorpan>
foolip: but they don't have a blog in the same origin

[01:35:00.0000] <zcorpan>
foolip: so i can XSS your blog

[01:35:01.0000] <foolip>
zcorpan, my blog is at blog.foolip.org, but I guess that doesn't help for cookies?

[01:35:02.0000] <zcorpan>
oh, i thought it was at foolip.org

[01:39:00.0000] <zcorpan>
foolip: btw, your viewer loses styles when going back/forward in opera

[01:39:01.0000] <foolip>
zcorpan, yeah, I've seen that, but don't understand why

[01:55:00.0000] <foolip>
nessy1, <data> isn't relevant to http://www.w3.org/html/wg/wiki/ChangeProposals/issue-179_no_change

[01:56:00.0000] <foolip>
and neither are data-* attributes if the point is to forward information to a plugin architecture

[01:57:00.0000] <zcorpan>
foolip: the textarea has class "processed" when it's rendered correctly

[01:57:01.0000] <zcorpan>
foolip: and no class after navigation

[01:59:00.0000] <foolip>
zcorpan, the side-effects make it seem like scripts aren't re-run on navigation, or that the previous state is not kept, whichever it is we do when navigating history

[02:01:00.0000] <zcorpan>
foolip: in your case i think we do a bfcache navigation, so scripts aren't rerun. but i don't know why the state isn't kept

[02:02:00.0000] <foolip>
I'll file a site compat bug

[02:02:01.0000] <zcorpan>
so both :)

[03:36:00.0000] <foolip>
Hixie, what's the vocabs-index file in the spec source? It's out of sync, at least.

[05:12:00.0000] <hsivonen>
Can someone remind me what the latest thinking on data: URL origin inherince is?

[05:13:00.0000] <hsivonen>
Does a doc loaded from a data: URL have a unique origin or the origin of the document that created the data: URL?

[06:12:00.0000] <smaug____>
Ms2ger: is moznet down?  (or is it just me who has problems to connect to that irc server)

[06:12:01.0000] <Ms2ger>
gravel.m.o wfm

[06:20:00.0000] <smaug____>
ping irc.mozilla.org

[06:20:01.0000] <smaug____>
ping: unknown host irc.mozilla.org

[06:25:00.0000] <plutoniix>
smaug____, dns problem ?- -

[06:25:01.0000] <smaug____>
could be

[06:25:02.0000] <smaug____>
but works now

[06:40:00.0000] <bga_>
hm

[06:40:01.0000] <bga_>
is it possible to style <area>?

[07:04:00.0000] <annevk>
via dino: http://www.youtube.com/watch?v=0Z09bNgSeMI

[07:04:01.0000] <annevk>
seems like something I have to watch

[07:16:00.0000] <annevk>
hsivonen, origin of the document that created it

[07:21:00.0000] <hsivonen>
annevk: thanks. And WebKit hasn't fixed that yet?

[07:23:00.0000] <annevk>
hsivonen, correct

[07:23:01.0000] <hsivonen>
ok

[08:32:00.0000] <foolip>
/me must be out of touch with reality, seeing all the shock and outrage over the end of <time>

[08:32:01.0000] <Ms2ger>
I see what you did there

[08:33:00.0000] <J_Voracek>
Nice ;-)

[08:37:00.0000] <zcorpan>
yeah i don't understand why the fuzz

[08:37:01.0000] <foolip>
Is it only inside this echo chamber that it seems to make sense, and in that case why?

[08:37:02.0000] <Ms2ger>
Because a spec in LC must be "STABLE"

[08:38:00.0000] <foolip>
Actually, I haven't seen anyone pulling the "stop changing things at random" argument

[08:38:01.0000] <foolip>
More "but it's so useful, I use it all the <time>!"

[08:38:02.0000] <Ms2ger>
I saw shelly make that argument

[08:40:00.0000] <foolip>
So maybe I missed that, in any case most people seem to be upset about the substance of the change rather than the fact that a change happened

[08:42:00.0000] <bga_>
http://lukeplant.me.uk/blog/posts/why-learning-haskell-python-makes-you-a-worse-programmer/

[08:43:00.0000] <zcorpan>
brucel argued that <data value> can't be validated. it can, of course, but it moves from the html layer validation to the microdata vocab layer validation

[08:44:00.0000] <zcorpan>
i guess i should comment on his blog

[08:45:00.0000] <miketaylr>
http://twitter.com/#!/LeaVerou/status/130837370185580545

[08:46:00.0000] <miketaylr>
/me shrugs

[08:48:00.0000] <zcorpan>
i agree with brucel's point though that data-* and <data> are for different uses is confusing

[08:49:00.0000] <zcorpan>
is there a need for an element at all? can it be a global itemvalue="" instead?

[08:49:01.0000] <zcorpan>
microformats can't use that, but they refused to use <time> anyway, so anything we introduce for microformats won't be used by microformats according to the track record

[08:52:00.0000] <zcorpan>
maybe itemvalue="" would be confusing on <a>, <object> etc

[08:53:00.0000] <miketaylr>
zcorpan: i don't think this sentence is going to help alleviate confusion between <data> and data-*: "The element can also, however, be used in conjunction with scripts in the page, for when a script has store a literal value alongside a human-readable value. In such cases, the format to be used depends only on the needs of the script. (The data-* attributes can also be useful in such situations.)"

[08:59:00.0000] <foolip>
miketaylr, file a bug?

[08:59:01.0000] <miketaylr>
foolip: can do. already filed one on the typo.

[09:01:00.0000] <miketaylr>
/me filed

[09:04:00.0000] <Hixie>
foolip: it's historical

[09:04:01.0000] <foolip>
mkay, otherwise I'd have told you that you left <time> in it

[09:05:00.0000] <Hixie>
i should probably remove it

[09:06:00.0000] <Hixie>
there, it's gone

[09:41:00.0000] <Ms2ger>
"Alex: Let's make floats work."

[09:41:01.0000] <Ms2ger>
Hear, hear

[09:42:00.0000] <gsnedders>
heheheh.

[09:42:01.0000] <gsnedders>
Oh Alex…

[09:42:02.0000] <gsnedders>
(Mogilevsky, I presume?)

[09:43:00.0000] <Ms2ger>
Yep

[09:57:00.0000] <Ms2ger>
"arronei: Next is insect-rect."

[10:42:00.0000] <myakura>
http://www.w3.org/2011/11/TPAC/live/ "W3C's serving capacity for various XML schemata (.dtd, .mod, .ent, .xsd) is exceeded at present."

[10:44:00.0000] <Ms2ger>
Let's get rid of them!

[10:46:00.0000] <AryehGregor>
It's what, less than a hundred files?  You should be able to serve ten thousand requests per second from one machine if it's configured properly and doesn't have terrible hardware.

[10:47:00.0000] <AryehGregor>
Periods of sustained bandwidth usage of 350 Mbps is going to be kind of expensive, but mostly just for the bandwidth.

[10:47:01.0000] <wilhelm>
/me holds down F5. That probably helps.

[10:48:00.0000] <AryehGregor>
Server-wise, you'd need only a handful of boxes running Varnish or Squid.

[10:51:00.0000] <Philip`>
Won't you tend to run out of things like port numbers if you have tens of thousands of requests on a single machine?

[10:53:00.0000] <Philip`>
(Apache seems to have problems with even dozens of requests per second, so I've used Squid on some site for that, but haven't had to worry about really high traffic)

[10:54:00.0000] <zewt>
Philip`: not going to run out of remote port/remote ip pairs

[10:55:00.0000] <Hixie>
how many browsers have <details> now? is it worth adding an event for when it opens yet?

[10:56:00.0000] <Hixie>
do we have an event that would be suitable for that?

[10:56:01.0000] <Hixie>
i'm thinking onchange, but it bubbles normally which seems bad for this kind of thing

[11:03:00.0000] <annevk>
wtf

[11:03:01.0000] <annevk>
there's like >200 people in the room

[11:03:02.0000] <annevk>
TabAtkins just blamed me

[11:03:03.0000] <myakura>
/me thinks better no to go..

[11:04:00.0000] <karlcow>
annevk: more like 20,000.

[11:04:01.0000] <annevk>
over 9000!

[11:04:02.0000] <jgraham>
Hixie: I thought just webkit, but lst I saw the implementation was horrible

[11:04:03.0000] <karlcow>
;)

[11:04:04.0000] <paul_irish>
Hixie: why would a bubble be bad for details onchange?

[11:05:00.0000] <smaug____>
paul_irish: because change event has been traditionally used for other things

[11:05:01.0000] <paul_irish>
aye

[11:05:02.0000] <paul_irish>
event.target.nodeName wasssupppp

[11:05:03.0000] <jgraham>
onchange seems like a horrible event to use

[11:06:00.0000] <hober>
/me says hi to jgraham from the next seat

[11:06:01.0000] <paul_irish>
i would mostly agree with that part. the bubbling i'd want though

[11:06:02.0000] <smaug____>
ontoggle or some such would be better, I think

[11:07:00.0000] <jgraham>
Right, that seems like a better name and less chance of conflict with existing code

[11:08:00.0000] <myakura>
Hixie: AFAIK, WebKit has some support but Safari preffed it off, so Chrome is the only browser which currently supports <details>

[11:11:00.0000] <jernoble>
Hixie: MediaController question for you: is the "most recently reported readiness state" intentionally left out of the IDL for MediaController? Same Q for the "playback state".

[11:12:00.0000] <karlcow>
http://www.cloudfour.com/device-detection-as-the-future-friendly-img-option/

[11:12:01.0000] <jernoble>
Hixie: it just seems weird to me that you can't ask a MediaController what it's playbackState is.

[11:19:00.0000] <slightlyoff>
why is bubbling bad for that?

[11:19:01.0000] <slightlyoff>
bubbling is nearly always good

[11:31:00.0000] <Hixie>
paul_irish: because otherwise if you nest them, it would be hard to use an onfoo="" event handler on the outer one

[11:31:01.0000] <Hixie>
paul_irish: (or indeed if you put any form controls in it, if we reuse change)

[11:31:02.0000] <Hixie>
myakura: k, thanks

[11:32:00.0000] <Hixie>
jernoble: how do you mean?

[11:32:01.0000] <jernoble>
Hixie: so, i'm in the middle of doing a first-pass implementation of MediaController in WebKit

[11:32:02.0000] <jernoble>
Hixie: and so i'm writing some test cases to double check my implementation

[11:33:00.0000] <jernoble>
Hixie: and i realize halfway through that I have no way of testing, from within a running page, what the ready state of a given MediaController is

[11:33:01.0000] <Hixie>
hm, good point

[11:33:02.0000] <Hixie>
i guess you can work it out pretty easily

[11:33:03.0000] <Hixie>
it's just the lowest value of all the slaves, right?

[11:33:04.0000] <jernoble>
Hixie: sure, you could do the same work in the script as you do in the UA.

[11:34:00.0000] <jernoble>
Hixie: but the UA has to calculate it anyway, and it would be very simple for me to wire up a new accessor for that pre-calculated value

[11:34:01.0000] <Hixie>
that's probably why it's not exposed -- i just needed to calculate it to expose the events, not for the IDL

[11:34:02.0000] <Hixie>
but if there's a use case for it, we can add it to the IDL

[11:35:00.0000] <Hixie>
send mail describing the use case :-)

[11:35:01.0000] <jernoble>
Hixie: sure thing. :)

[12:11:00.0000] <Hixie>
if anyone wants to play openttd with us, btw, we have a server running -- server name is TPAC, /msg me for the password

[12:11:01.0000] <Hixie>
we'll be running it all week

[12:33:00.0000] <TabAtkins_>
Ms2ger, annevk: Is there anything fundamentally wrong with a DOM event firing on an element that's no longer in the DOM (but not deleted, just removed)?

[12:34:00.0000] <TabAtkins_>
Specifically in the context of animationEnded events.

[12:34:01.0000] <Ms2ger>
Not in a document? No

[12:34:02.0000] <TabAtkins_>
Nothing wrong?

[12:35:00.0000] <Ms2ger>
Don't think so

[12:35:01.0000] <TabAtkins_>
kk

[12:37:00.0000] <TabAtkins_>
smaug____: Any second opinions?  (The CSSWG is just wanting to make sure.)

[12:39:00.0000] <zewt>
DOM events are used on things that aren't nodes at all, anyway

[12:40:00.0000] <zewt>
i'd think lots of events would already be received on nodes already in that case, if you remove the node when the task is already queued, but maybe they're cleared somehow

[13:34:00.0000] <AryehGregor>
TabAtkins, I'm pretty sure all kinds of events already fire on nodes that don't descend from a Document.

[13:35:00.0000] <AryehGregor>
Like what if you do var audio = new Audio(url); audio.play()?

[13:35:01.0000] <annevk>
yes events can fire whenever

[13:35:02.0000] <AryehGregor>
Mutation events presumably fire on such nodes too.

[13:38:00.0000] <AryehGregor>
"Microsoft Corp. has joined the HTML Editing APIs Community Group"

[13:38:01.0000] <AryehGregor>
Awesome!

[13:39:00.0000] <AryehGregor>
/me does a little dance

[13:56:00.0000] <dglazkov>
yay AryehGregor

[14:06:00.0000] <MikeSmith>
AryehGregor: booyah

[14:08:00.0000] <hober>
word

[14:10:00.0000] <slightlyoff>
hooray

[14:11:00.0000] <jgraham>
Hmm, using getOwnPropertyDescriptor on native objects seems to be problematic. Or I am doing something wrong?

[14:11:01.0000] <slightlyoff>
on host objects?

[14:11:02.0000] <jgraham>
Yeah

[14:12:00.0000] <jgraham>
One day I will get those terms the right way around

[14:12:01.0000] <slightlyoff>
/me checks the spec

[14:15:00.0000] <jgraham>
Hmm, seems to work OK in some cases. It's probably more of a WebIDL compliance problem

[14:17:00.0000] <jgraham>
(alternate point of view: WebIDL is a lie)

[14:17:01.0000] <Ms2ger>
All specs are cake

[14:17:02.0000] <heycam>
mmmm spec cake

[14:17:03.0000] <dglazkov>
Can someone throw something at Ms2ger so that I can identify him in the room?

[14:17:04.0000] <Ms2ger>
/me waves at dglazkov 

[14:18:00.0000] <dglazkov>
Ms2ger: ah, so you're not in the room :)

[14:18:01.0000] <Ms2ger>
Indeed

[14:19:00.0000] <slightlyoff>
so these things should be able to return property descriptors

[14:19:01.0000] <slightlyoff>
they're required to have semantics for all of the [[]] opeations

[14:19:02.0000] <jgraham>
slightlyoff: Yup

[14:19:03.0000] <slightlyoff>
implementation bug

[14:20:00.0000] <jgraham>
It seems like I was being unreasoably optimistic about how closely anyone followed the inheritance/accessor property requirements in WebIDL

[14:20:01.0000] <heycam>
:)

[14:21:00.0000] <dglazkov>
slightlyoff: where are you?

[14:22:00.0000] <slightlyoff>
webapps

[14:29:00.0000] <gsnedders>
jgraham: Does ES5 guarantee that getOwnPropertyDescriptor will work on a host-object? I think not. The intention of WebIDL is that it should, though.

[14:30:00.0000] <jgraham>
gsnedders: Dunno

[14:32:00.0000] <dglazkov>
This TPAC thing is highway robbery. I came to see famous people. And they don't even have Ms2ger!

[14:32:01.0000] <Ms2ger>
Hah

[14:33:00.0000] <Scorchin>
dglazkov: What's TPAC?

[14:33:01.0000] <Scorchin>
/me wants it to be a 2pac conference

[14:33:02.0000] <gsnedders>
What's Ms2ger? Is it a person?

[14:33:03.0000] <dglazkov>
it's a week-long celebration of Tupac Shakur

[14:33:04.0000] <Scorchin>
8D

[14:33:05.0000] <Philip`>
I'm not sure that Ms2ger actually has a corporeal existence

[14:33:06.0000] <dglazkov>
that's disappointing

[14:34:00.0000] <gsnedders>
Nor am I.

[14:35:00.0000] <Scorchin>
"... brings together W3C Working, Interest, and Incubator Groups, the Advisory Board, the TAG and the Advisory Committee for an exciting week of coordinated work"

[14:38:00.0000] <hober>
Scorchin: well, it is Halloween, so 2pac and t-pain costumes are preferred.

[14:39:00.0000] <Hixie>
heycam: what's the default default value of a dictionary member?

[14:39:01.0000] <Scorchin>
hober: :D

[14:39:02.0000] <heycam>
Hixie, default default? :)

[14:39:03.0000] <heycam>
Hixie, there's no such thing. the dictionary member is not present.

[14:39:04.0000] <tantek>
hello, is this the unofficial TPAC 2011 backchannel?

[14:40:00.0000] <Scorchin>
Wow, that Marriott has meeting rooms named after Californian cities/towns. That's not at all confusing to hear over the phone.

[14:40:01.0000] <heycam>
tantek, I thought that would be #tpac in irc.w3.org

[14:41:00.0000] <Philip`>
That doesn't sound very unofficial

[14:41:01.0000] <tantek>
heycam, #tpac in irc.w3.org is the *official* backchannel

[14:41:02.0000] <Hixie>
heycam: ah ok

[14:41:03.0000] <gsnedders>
How about #nottpac on irc.w3.org? :P

[14:41:04.0000] <Hixie>
heycam: so basically it's whatever the prose says?

[14:41:05.0000] <Hixie>
ok

[14:41:06.0000] <heycam>
/me missed the "un"

[14:41:07.0000] <heycam>
Hixie, yes, it's invalid for the prose to uncondtionally get the value of such a dictionary member, since it may not be present

[14:42:00.0000] <Hixie>
[24~k

[14:43:00.0000] <zewt>
tty smash

[14:44:00.0000] <Ms2ger>
Did Hixie bring a cat to TPAC?

[14:44:01.0000] <annevk>
heycam, setting it to undefined, is that the same as not present?

[14:44:02.0000] <Ms2ger>
No

[14:45:00.0000] <annevk>
guess it would end up meaning the same

[14:45:01.0000] <gsnedders>
annevk: No, it wouldn't.

[14:45:02.0000] <gsnedders>
annevk: hasOwnProperty would return a different value.

[14:46:00.0000] <heycam>
annevk, wouldn't mean the same thing. maybe the default value is something not just a constant value. you need to describe that in prose rather than idl.

[14:47:00.0000] <annevk>
gsnedders, I was talking about new EventSource(..., {withCredentials:undefined})

[14:47:01.0000] <heycam>
annevk, oh sorry I misunderstood

[14:47:02.0000] <heycam>
that's the topic of the recent thread on public-script-coord

[14:47:03.0000] <annevk>
heycam, should event dictionaries have default values?

[14:48:00.0000] <annevk>
euh, dictionaries

[14:48:01.0000] <annevk>
I guess in general you don't really want that

[14:48:02.0000] <annevk>
so maybe that should just be dropped

[14:49:00.0000] <heycam>
default values are probably sensible in most cases I would've thought

[14:53:00.0000] <slightlyoff>
if you don't have a default, you should throw when you don't get everything. I'd have thought that defaults are obviously useful

[14:53:01.0000] <jgraham>
+1

[14:55:00.0000] <annevk>
ew

[14:55:01.0000] <slightlyoff>
ew?

[14:55:02.0000] <annevk>
for event constructors you don't need a default

[14:55:03.0000] <annevk>
but you don't want to require everything

[14:55:04.0000] <jgraham>
The defult could be "undefined"

[14:56:00.0000] <slightlyoff>
if you're passing property bags, you should have defaults for things you don't pass in as configuration

[14:56:01.0000] <slightlyoff>
that's part of the win

[14:56:02.0000] <annevk>
the defaults can be magic in case of events

[14:56:03.0000] <slightlyoff>
so if I have a ctor like "new Thinger({ ... });

[14:56:04.0000] <jgraham>
It should make it easier to spec

[14:56:05.0000] <annevk>
e.g. MouseEvents

[14:56:06.0000] <slightlyoff>
the value of the arguments object is that it doesn't require everything

[14:56:07.0000] <slightlyoff>
you could *optionally* have, say, 15 params

[14:56:08.0000] <jgraham>
If you don't have defaults you have to say if x is missing...

[14:56:09.0000] <slightlyoff>
but this might still be legal:

[14:56:10.0000] <annevk>
jgraham, I don't think it is

[14:57:00.0000] <slightlyoff>
new Thinger({ prop: "value" });

[14:57:01.0000] <annevk>
jgraham, feel free to rewrite event constructors in an easier way though

[14:57:02.0000] <slightlyoff>
the other 14 should be defaulted

[14:57:03.0000] <heycam>
yes

[14:57:04.0000] <jgraham>
annevk: I don't understand why you think it is bad

[14:57:05.0000] <Hixie>
if you change event constructors please bear in mind this requires changes to a bunch of specs now

[14:57:06.0000] <annevk>
jgraham, I don't understand why you think it is simpler

[14:57:07.0000] <slightlyoff>
that's not design feedback = )

[14:57:08.0000] <jgraham>
Because you know that you always have a value for everything

[14:57:09.0000] <heycam>
it's simpler because the defaults are in the idl for these cases

[14:58:00.0000] <jgraham>
It cuts down the number of cases

[14:58:01.0000] <annevk>
but you already need to define a default anyway

[14:58:02.0000] <heycam>
you don't need to with dictionaries

[14:58:03.0000] <heycam>
i think in this case we should though!

[14:58:04.0000] <annevk>
because the whole property bag is optional

[14:58:05.0000] <heycam>
but that's different, you probably will have a step in your constructor that says "if the options param was specified..."

[14:58:06.0000] <jgraham>
Right, but a missing bag is obviously the same as a bag with all the default values

[14:58:07.0000] <heycam>
and that's easier than having that conditional on every dictionary member when you say in the algorithm to look it up

[14:58:08.0000] <slightlyoff>
well, missing == {}

[14:59:00.0000] <annevk>
jgraham, not sure how that would even work for defining createEvent

[14:59:01.0000] <heycam>
there are no default values for operation arguments though

[14:59:02.0000] <slightlyoff>
in ES 6, you'd write it as:

[14:59:03.0000] <heycam>
so that still needs to be handled in rpose too

[14:59:04.0000] <slightlyoff>
function Thinger(args={}) { ... }

[14:59:05.0000] <slightlyoff>
new Thinger();

[14:59:06.0000] <heycam>
so ES6 is a different thing then

[14:59:07.0000] <annevk>
the way it currently works is that you have requirements for when you create an event

[14:59:08.0000] <slightlyoff>
or if you want defaults in the param:

[14:59:09.0000] <heycam>
if we want to update webidl to allow targetting es6 stuff then that's fine, but atm you can't

[14:59:10.0000] <annevk>
and separately requirements for what to do with the init dictionary

[15:00:00.0000] <annevk>
if there is any

[15:00:01.0000] <slightlyoff>
function Thinger(args={ prop1: "...", prop2: "...", ...});

[15:00:02.0000] <slightlyoff>
that's just strictly sugar

[15:00:03.0000] <heycam>
in fact that may be how an ES6-targetting webidl is written

[15:00:04.0000] <slightlyoff>
I was using it as an example of what you can obviously have WebIDL do for us today

[15:00:05.0000] <slightlyoff>
*sigh*

[15:01:00.0000] <heycam>
/me is confused

[15:01:01.0000] <heycam>
defaults for option objects are workable in webidl today

[15:01:02.0000] <slightlyoff>
yep

[15:01:03.0000] <slightlyoff>
and it's valuable!

[15:01:04.0000] <heycam>
yes :)

[15:01:05.0000] <slightlyoff>
we should have it, full stop

[15:02:00.0000] <zcorpan>
annevk: would be nice if parser.js had a comment at the top saying which rev it implements and how it differs from the spec (at that rev)

[15:02:01.0000] <annevk>
zcorpan, I should just fix the bugs

[15:02:02.0000] <annevk>
but probably not this week :(

[15:03:00.0000] <zcorpan>
annevk: i was planning on using it

[15:03:01.0000] <annevk>
not anymore?

[15:03:02.0000] <annevk>
it implements the revision just before hixie made all the changes based on your feedback :)

[15:04:00.0000] <zcorpan>
no i still am :)

[15:05:00.0000] <zcorpan>
was it in github or something?

[15:06:00.0000] <annevk>
zcorpan, https://bitbucket.org/annevk/webvtt

[15:06:01.0000] <annevk>
zcorpan, just uploaded my local changes

[15:07:00.0000] <zcorpan>
thanks

[15:07:01.0000] <Ms2ger>
/me runs away before someone pulls off his mask

[15:08:00.0000] <annevk>
trololol

[15:08:01.0000] <zcorpan>
annevk: maybe i can run it on the "srt converted to vtt" data and see which conformance errors are most common :)

[15:15:00.0000] <zcorpan>
/me thinks it would be nicer with align:middle instead of A:middle

[15:16:00.0000] <zcorpan>
why use one-letter for the setting but not the value?

[15:18:00.0000] <zewt>
definitely not a fan of vtt's abbreviations, personally

[15:23:00.0000] <zcorpan>
ok filed a bug

[15:24:00.0000] <zewt>
i forget the rationale for the abbreviations, just feels like trying to do deflate's job at the wrong level

[15:25:00.0000] <zcorpan>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14646 - please bikeshed what the settings should be called :)

[15:32:00.0000] <annevk>
"please bikeshed" oh god

[15:42:00.0000] <gsnedders>
What was the conclusion with innerText and Gecko?

[15:43:00.0000] <annevk>
no conclusion?

[15:44:00.0000] <gsnedders>
That's what I thought.

[15:51:00.0000] <zcorpan>
i think Hixie dropped <time> just for the puns

[15:52:00.0000] <gsnedders>
All the <data> is Hixie's?

[15:52:01.0000] <annevk>
All the <base> are belong to Hixie?

[15:53:00.0000] <gsnedders>
annevk: Dude, it's not 2001.

[15:55:00.0000] <annevk>
<br>eaking <b>ad

[15:55:01.0000] <annevk>
/me is bad at HTML puns

[15:57:00.0000] <annevk>
okay

[15:57:01.0000] <annevk>
so you have

[15:57:02.0000] <annevk>
new Event(x, dict)

[15:57:03.0000] <annevk>
and you have

[15:57:04.0000] <annevk>
document.createEvent(eventInterface)

[15:57:05.0000] <annevk>
the latter does not have access to x and dict

[15:57:06.0000] <annevk>
but they still need to be defined

[15:58:00.0000] <annevk>
so instead DOM defines how they are all initialized when you create an event object

[15:58:01.0000] <annevk>
and how dict overwrites anything, if any

[15:58:02.0000] <annevk>
(everything from okay above is for jgraham)

[16:02:00.0000] <jgraham>
Just define createEvent(x) as being equivalent to new Event(x, {})

[16:02:01.0000] <heycam>
not exactly

[16:03:00.0000] <heycam>
x == "MouseEvent" for example

[16:03:01.0000] <heycam>
for the former

[16:03:02.0000] <heycam>
but "click" for the latter

[16:03:03.0000] <heycam>
(well the latter you'd want new MouseEvent(...))

[16:03:04.0000] <annevk>
x != eventInterface

[16:03:05.0000] <jgraham>
Oh, OK

[16:04:00.0000] <heycam>
but I agree with the general approach

[16:04:01.0000] <heycam>
we need to make sure though that individual event/constructors always have default values for all dictionary members

[16:04:02.0000] <heycam>
so that createEvent's definition doesn't need to worry about that

[16:04:03.0000] <jgraham>
Yes

[16:04:04.0000] <heycam>
or, that constructors for events are all defined in the same way

[16:04:05.0000] <annevk>
you don't do that by defining default values for dictionary members

[16:05:00.0000] <annevk>
you do that by defining default values for the attributes

[16:06:00.0000] <heycam>
/me is not sure about that

[16:06:01.0000] <heycam>
unless that's part of the definitions you have in dom4

[16:06:02.0000] <jgraham>
It just seems like a reasonable invariant that dictionary members always have values

[16:07:00.0000] <annevk>
heycam, it is, and it is how HTML defines it's events as well

[16:07:01.0000] <heycam>
ok

[16:07:02.0000] <annevk>
leading to me thinking that we should not have "= false" or some such in dictionaries

[16:09:00.0000] <heycam>
and just assume whatever undefined converts to?

[16:12:00.0000] <annevk>
well you have boolean withCredentials

[16:12:01.0000] <zewt>
annevk: looking at Progress Events as an example, where is the initialization of ProgressEvent from a ProgressEventInit defined? somewhere in webidl? (don't see it in [Constructor])

[16:12:02.0000] <annevk>
if you set that to undefined, I guess it will make that false

[16:12:03.0000] <annevk>
zewt, DOM4

[16:13:00.0000] <zewt>
found it

[16:13:01.0000] <zewt>
annevk: might be useful for eventInitDict to be a ref to dom4 Constructing events

[16:14:00.0000] <annevk>
maybe for "Constructor"

[16:14:01.0000] <zewt>
well that would ref webidl [Constructor] if anything, right?

[16:14:02.0000] <annevk>
no

[16:15:00.0000] <annevk>
typically it refers the definition in the draft

[16:15:01.0000] <zewt>
i mean the word Constructor is from webidl, it's "eventInitDict" that ties to dom4

[16:15:02.0000] <annevk>
no

[16:15:03.0000] <annevk>
eventInitDict is just a meaningless name

[16:16:00.0000] <zewt>
it's definitely not meaningless, the name is given specific meaning in dom4

[16:16:01.0000] <annevk>
no

[16:16:02.0000] <annevk>
you cannot give parameter names meaning

[16:16:03.0000] <annevk>
that's nonsense

[16:16:04.0000] <zewt>
you did give parameter names meaning

[16:16:05.0000] <annevk>
in fact

[16:16:06.0000] <annevk>
if I did that, type would be undefined

[16:16:07.0000] <annevk>
no I didn't

[16:16:08.0000] <zewt>
anyway the only point was to make it easier to see where this is defined

[16:17:00.0000] <annevk>
right, for that it would make sense to link Constructor, as we do elsewhere

[16:18:00.0000] <zewt>
jgraham: i think a (the?) benefit of defining the defaults anne's way is that if you ever construct an event interface in more than one way (eg. internally), you have all of the defaults in one place

[16:19:00.0000] <zewt>
since if you construct an event internally (eg. "fire a progress event"), you're not using the dictionary at all

[16:19:01.0000] <jgraham>
Yeah, I see that. But I am not sure that is the most important property

[16:20:00.0000] <zewt>
other than that they seem roughly equivalent to me

[16:20:01.0000] <jgraham>
I could be wrong of course

[16:20:02.0000] <zewt>
if you could drop the prose initialization entirely then I'd agree, since it's just more concise to put them in the idl

[16:21:00.0000] <zewt>
(agree on first look anyway, might be other factors I don't know about)