2014-02-01
[16:03:38.0000] <annevk>
sad pandas

[02:13:59.0000] <jgraham>
Hixie: Yeah, I got confused by how it even got as far as a 500 then ran out of time, then forgot about it

[11:27:52.0000] <MikeSmith>
jobs

[12:55:23.0000] <Ms2ger>
https://twitter.com/tabatkins/status/429281803719823360


2014-02-02
[07:45:32.0000] <MikeSmith>
http://msopentech.com/blog/2014/01/30/pointer-events-progress-mozilla-blink-communities-reach-significant-engineering-milestone/ seems like good news


2014-02-03
[21:17:58.0000] <foolip>
Hixie: sorry, I was not around, but I'll check your fix

[21:18:28.0000] <foolip>
Hixie: I'm in UTC+7 (Vietnam) now so I'll seldom be online when you are

[02:25:09.0000] <zcorpan>
should DOMException have [Exposed] also? annevk-cloud__ heycam|away

[02:57:30.0000] <annevk>
zcorpan: DOMException will be defined as part of IDL

[02:57:31.0000] <annevk>
zcorpan: in terms of JavaScript

[02:59:10.0000] <annevk>
hmm not being logged

[05:16:54.0000] <annevk>
oh, is

[05:20:22.0000] <zcorpan_>
annevk: ok. could you put in a note saying that the plan is to have it available in workers?

[05:25:44.0000] <annevk>
What's the rush?

[05:25:45.0000] <annevk>
Is [Expsosed] even defined for non-interface things?

[06:03:03.0000] <MikeSmit1>
about https://www.w3.org/Bugs/Public/show_bug.cgi?id=24480 maybe we should add back the "Web developer view" button

[06:03:22.0000] <MikeSmit1>
or "Hide UA implementation details" or whatever it was called

[06:05:26.0000] <MikeSmit1>
because the commenter appears to be perturbed about the "run synthetic click activation steps" algorithm being in the section that gives info about the various types of content (flow, phrasing, etc.)

[06:06:13.0000] <MikeSmit1>
and because the experiment of providing a separate "Developer Edition" spec doesn't appear to have become a huge success

[06:08:29.0000] <annevk>
It hasn't?

[06:08:29.0000] <annevk>
People rave about it on Twitter quite often

[06:08:29.0000] <annevk>
developers.whatwg.org that is

[06:09:16.0000] <MikeSmit1>
really?

[06:09:22.0000] <MikeSmit1>
I guess I'm just out of touch

[06:10:13.0000] <MikeSmit1>
and personally I really prefer Hixie's styling to the styling in that developer version

[06:10:48.0000] <MikeSmit1>
I find that developer version harder to read

[06:11:05.0000] <Ms2ger>
Habit? :)

[06:13:17.0000] <annevk>
MikeSmit1: also, the person giving feedback in that bug is zcorpan, he's well aware of all those things

[06:13:36.0000] <MikeSmit1>
eh?

[06:13:37.0000] <Ms2ger>
"The MathML3 DTD has been updated"

[06:13:46.0000] <Ms2ger>
Good that someone is doing useful work

[06:13:56.0000] <MikeSmit1>
annevk: zcorpan filed that bug?

[06:14:21.0000] <MikeSmit1>
oh yeah I see he did

[06:30:37.0000] <zcorpan_>
MikeSmith: i filed it because of https://www.w3.org/Bugs/Public/show_bug.cgi?id=24473

[06:31:02.0000] <MikeSmith>
/me loooks

[06:31:29.0000] <MikeSmith>
ah yeah

[06:33:31.0000] <Domenic_>
I <3 the developer version and refer people to it often

[06:33:33.0000] <zcorpan_>
annevk: no rush but it might help test writers an implementers when deciding what self.DOMException should be in workers :-)

[06:34:37.0000] <annevk>
zcorpan_: what is self.Error in a worker?

[06:35:41.0000] <annevk>
I suspect we're basically waiting for heycam to recover from jetlag at this point

[06:35:41.0000] <annevk>
Unless he went somewhere else after Seattle

[06:38:05.0000] <zcorpan>
annevk: it's a function

[06:38:06.0000] <zcorpan>
annevk: everything defined in JS is available in workers i think

[06:39:19.0000] <Ms2ger>
I would assume that, yes

[06:39:46.0000] <annevk>
So http://people.mozilla.org/~jorendorff/es6-draft.html#sec-%realm%.prototype.eval lacks a hook for CSP

[06:39:55.0000] <annevk>
Domenic_: should I just file a bug against JS for that?

[06:47:36.0000] <Ms2ger>
/me wonders how chromium people look at diffs

[06:52:22.0000] <annevk>
I filed https://bugs.ecmascript.org/show_bug.cgi?id=2494

[07:24:20.0000] <Domenic_>
annevk: interesting. might be worth bringing in dave to the conversation since i think he's heading up the realm work.

[07:24:59.0000] <annevk>
Domenic_: added dherman

[07:36:17.0000] <annevk>
Domenic_: I'm curious if there's more such trickery

[07:37:10.0000] <Domenic_>
annevk: I think in pure ES5, eval and Function are the only eval-er.

[07:37:33.0000] <Domenic_>
ES6 adds Realm and GeneratorFunction; it might add some stuff in Loader but I think that was all encapsulated by Realm.

[07:37:35.0000] <annevk>
Domenic_: there's structured clones of course which apparently are handled in the JS engine already

[07:37:35.0000] <annevk>
Seems bad to set these precedents that specification authors can just hack the JS engine on the side, although you wouldn't want to gate everything on TC39 either

[07:38:00.0000] <Domenic_>
yeah...

[07:40:54.0000] <annevk>
Oooh, so Realm needs a flag too for CSP

[07:44:26.0000] <Domenic_>
Loader too http://people.mozilla.org/~jorendorff/es6-draft.html#sec-loader.prototype.eval

[07:44:52.0000] <Domenic_>
Hmm both reference IndirectEval but that doesn't exist according to Ctrl+F

[07:44:56.0000] <Domenic_>
seems like this stuff is still WIP

[07:45:42.0000] <annevk>
Note that I also filed a complaint with those responsible: http://lists.w3.org/Archives/Public/public-webappsec/2014Feb/

[07:47:22.0000] <annevk>
At some point we need some kind of low-tolerance policy for forking someone else their algorithm in your own specification without prior coordination

[07:47:23.0000] <Ms2ger>
/me looks for someone with experience with the v8 api

[07:49:07.0000] <ondras>
/me has some

[07:49:23.0000] <ondras>
being the author of an embedding alternative to node

[07:49:50.0000] <ondras>
Ms2ger: ^

[07:49:58.0000] <ondras>
but I have to leave soon, so I might reply later

[07:59:22.0000] <gsnedders>
Domenic_: Function isn't relevant as an eval-er in ES5, given it's creates a new scope whose containing environment is the global-scope.

[07:59:32.0000] <gsnedders>
(likewise indirect eval)

[08:02:39.0000] <Domenic_>
gsnedders: I imagine CSP still cares.

[08:03:08.0000] <Domenic_>
if CSP doesn't care about indirect eval then it won't care about Loader or Realm either

[08:03:16.0000] <annevk>
It cares

[08:04:13.0000] <Domenic_>
annevk: changes to the URL spec seem pretty great.

[08:04:31.0000] <annevk>
I like my new advice section

[08:04:44.0000] <annevk>
I made it up in bed in SF and then forgot about it for a while

[08:04:48.0000] <gsnedders>
Domenic_: Yeah. CSP cares. But CSP also needs to care about things at the DOM level to do what it needs.

[08:05:23.0000] <gsnedders>
Domenic_: (e.g., var s = document.createElement("script"); s.textContent = "blah"; document.documentElement.appendChild(s); or whatever)

[08:05:39.0000] <annevk>
And fetch. CSP affects all.

[08:06:09.0000] <gsnedders>
This would be so much less confusing if I weren't in two conversations about two different CSPs. :)

[08:06:25.0000] <Domenic_>
annevk: still not sure i get "scheme data." An example or two of the decomposition might be useful.

[08:06:58.0000] <annevk>
Domenic_: data:text/html,teehee

[08:07:09.0000] <annevk>
text/html,teehee is scheme data, but noted

[08:07:12.0000] <Domenic_>
ahhh interesting.

[08:07:26.0000] <zcorpan>
annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=580234 is INVALID now right?

[08:07:49.0000] <annevk>
zcorpan: yeah I guess

[08:07:57.0000] <annevk>
zcorpan: depending on what UAs align on for the URL parser

[08:08:08.0000] <annevk>
zcorpan: but yeah, that bug won't be used for aligning that

[08:08:15.0000] <Ms2ger>
zcorpan, as long as you have a test :)

[08:09:21.0000] <annevk>
Domenic_: most of this rewrite was done to fix blob URLs btw

[08:10:00.0000] <annevk>
Domenic_: where we introduce a component called "object" that holds a structured clone of the Blob the scheme data of a "blob" URL points to, which is then used when fetching...

[08:10:57.0000] <Domenic_>
ah interesting... it might be worth pointing out in a non-normative section how blob URLs are indeed covered by the spec. I didn't even think of them, but it's great that they are covered.

[08:11:14.0000] <zcorpan>
Ms2ger: http://web-platform.test:8000/websockets/constructor/017.html

[08:11:17.0000] <annevk>
Well, I need to write that integration bit still :-)

[08:11:30.0000] <annevk>
It's going to be fairly explicit once everything is done

[08:12:25.0000] <Ms2ger>
zcorpan, nice how I can just click that link now :)

[08:12:43.0000] <zcorpan>
hmm i don't get a result for that test

[08:13:03.0000] <Ms2ger>
I get all passes

[08:20:30.0000] <zcorpan>
yeah now i do too. had messed up my working copy

[08:21:52.0000] <TabAtkins_>
Domenic_: What were the Promise changes that were decided against?

[08:23:00.0000] <TabAtkins_>
Domenic_: I assume it was "welp, monads suck".

[08:23:14.0000] <TabAtkins_>
Also, presented without comment: http://lists.w3.org/Archives/Public/www-style/2014Feb/0024.html

[08:23:55.0000] <Ms2ger>
I see the stack of links

[08:23:58.0000] <Ms2ger>
I see the sender

[08:24:03.0000] <Ms2ger>
/me closes tabs

[08:24:06.0000] <Ms2ger>
*tab

[08:24:10.0000] <Ms2ger>
And not you

[08:24:16.0000] <TabAtkins_>
Good job, you passed the test.

[08:25:02.0000] <Ms2ger>
TabAtkins_, do you know if there's a way to look at a side-by-side diff of a blink revision?

[08:25:12.0000] <TabAtkins_>
No, I don't know.

[08:25:45.0000] <TabAtkins_>
/me is not much of a Blink dev.

[08:26:09.0000] <Ms2ger>
/me looks for blink devs, then :)

[08:28:32.0000] <Domenic_>
TabAtkins_: yeah that's what it sounds like. Minutes coming out soon...

[08:29:32.0000] <TabAtkins_>
I hate that the existing shitty promises led to monadic promises seeming like a complication rather than a simplification, as they got bolted on to the side.

[08:30:00.0000] <TabAtkins_>
And it means that we *will* have the possibility of problems with async maps, as we discussed in the Service Worker f2f. :/

[08:30:09.0000] <Ms2ger>
/me sees monads, tunes out

[08:30:48.0000] <TabAtkins_>
Le sigh.  I also fucking hate the word "monad", because it's a crappy nonsense word that looks confusing.

[08:30:58.0000] <TabAtkins_>
Like using "Functor" for "Mappable".

[08:31:31.0000] <jgraham>
"monad" just sounds like a lonely nomad

[08:31:50.0000] <jgraham>
Which isn't at all scary

[08:32:06.0000] <TabAtkins_>
But anyway, if we're stuck with crappy promises, it means you'll never be able to get a useful API out of an async map.

[08:32:26.0000] <Ms2ger>
I also tune out on "responsive images" :)

[08:32:37.0000] <TabAtkins_>
Because it'll inherently mix up "failed because the key wasn't in the map" and "key was in the map, but it was for a failed promise".

[08:32:53.0000] <jgraham>
I thought there was a whole debate in which you had some way of getting monadic promises to coexist with whatever other people liked

[08:32:55.0000] <TabAtkins_>
You'll have to handle both of these completely separate cases in the same .then() branch.

[08:33:18.0000] <TabAtkins_>
jgraham: Yes, there was.  But Domenic_ is making it sound like people gave up on that at last week's tc39 meeting.

[08:33:21.0000] <TabAtkins_>
I'll wait for minutes, I guess.

[08:34:07.0000] <TabAtkins_>
(Getting them to coexist is easy - it's basically equivalent to saying that arrays can nest, but we'll also give you an iterator that moves through the flattened array instead so you can pretend they don't.)

[08:34:08.0000] <jgraham>
TabAtkins_: There are certain choice words that you should use when people try to make decisions at face to face meetings like that

[08:34:36.0000] <Ms2ger>
This is why you're careful with "may": https://twitter.com/aloria/status/429375273625452544

[08:34:37.0000] <TabAtkins_>
(Actually it's exactly equivalent to that, because MONADS.)

[08:37:03.0000] <TabAtkins_>
jgraham: I also see the word "gonad" when I write "monad", which isn't great either.

[08:39:19.0000] <annevk>
Tentative plan: recast current parser as base URL parser. Introduce new URL parser that invokes that and adds blob magic. Allows rest of the world to pretend blobs don't exist, makes it likely web standards pick the right parser.

[08:39:27.0000] <gsnedders>
You should just follow SPJ's view that it is misnamed and should instead be a "warm fuzzy thing", because people won't be scared of it.

[08:40:38.0000] <TabAtkins_>
gsnedders: It's not even a *thing*, though.  It's an interface or typeclass or abstract base class or trait or whatever-the-hell your language calls "here's some behavior that multiple things can implement".

[08:41:23.0000] <TabAtkins_>
Giving it a "thing" name confused me when I first started learning about it, and I'm sure messes with a lot of other people too.

[08:45:08.0000] <jgraham>
Well the same applies to "algebra" or something; it's the name for a set of rules that allow computation. Actually "algebra" is worse because it's the general name to mean any set of rules that allow some kind of abstract computation.

[08:45:40.0000] <jgraham>
But I'm not sure that people find algebra confusing because of the name

[08:46:12.0000] <jgraham>
They find it confusing because it's hard to internalise a system of rules and the consequences of those rules

[08:48:02.0000] <TabAtkins_>
And yet they find it easy to internalize "Mappable" as being "a thing with .map()".

[08:48:14.0000] <TabAtkins_>
Or "Iterable" as being "a thing I can iterate".

[08:48:38.0000] <Ms2ger>
Or "Monad" as being "a thing I can moon"

[08:48:40.0000] <TabAtkins_>
"Monad" is just a terrible name for "Map-then-Flatten-able".  (Which, granted, is also a terrible name.)

[08:49:00.0000] <TabAtkins_>
You get it, Ms2ger!

[08:49:00.0000] <jgraham>
Well iterable is easy because there is only a single operation which is familiar from other contexts

[08:49:25.0000] <TabAtkins_>
Monad just combines two extremely familiar operations - map and flatten.

[08:50:28.0000] <Ms2ger>
Flatten?

[08:50:48.0000] <Ms2ger>
/me isn't sure he's ever had to use it

[08:51:06.0000] <TabAtkins_>
You've never flattened an array?

[08:52:07.0000] <Ms2ger>
Not that I can remember

[08:52:25.0000] <Ms2ger>
I certainly wouldn't say its on the same level as map

[08:52:36.0000] <TabAtkins_>
All right.  Yeah, I grant that it's less common than "map", but still not anything exotic.

[08:53:23.0000] <Ms2ger>
So it's a map that can push multiple values, or what?

[08:53:56.0000] <TabAtkins_>
In terms of arrays and other containers, yeah, that's it.  (Or zero values.)

[08:54:14.0000] <TabAtkins_>
"Flatten" ends up being a really generic concept that gets stretched all over the place, but for the most common cases, it's just that.

[08:54:16.0000] <Ms2ger>
Fascinating

[08:54:27.0000] <gsnedders>
Yay, back on this side of the split!

[08:54:42.0000] <TabAtkins_>
(It's just "how do I turn Thing<Thing<Foo>> into Thing<Foo>?".)

[08:54:43.0000] <annevk>
You want to avoid the word monad

[08:54:48.0000] <Ms2ger>
That may well be the first time someone managed to explain monads in an understandable way

[08:54:55.0000] <TabAtkins_>
Ms2ger: BLAME HASKELL

[08:55:07.0000] <Ms2ger>
Sure, I'll blame haskell for a great good

[08:56:00.0000] <gsnedders>
TabAtkins_: A monad is just a definition of a sequence of computational actions. It is pretty much a thing that can do anything.

[08:56:04.0000] <TabAtkins_>
Monads are among the simplest things I can describe in terms of generic behaviors, but they've built up this terrible mystique and also everyone's crap at explaining them for no reason I can fathom.

[08:56:18.0000] <TabAtkins_>
gsnedders: So you're also one of the people who's crap at explaining them. ^_^

[08:56:23.0000] <Ms2ger>
Clearly :)

[08:56:55.0000] <TabAtkins_>
Jumping straight to the "but 'flatten' is really just a way of describing computational sequencing!" is why everyone hates monads.

[08:57:56.0000] <TabAtkins_>
You've got a Thing which contains a value. You define .map() so functions can work on the value without caring about the Thing. But sometimes your functions want to return a Thing too, and now you've got nested Things. Define a way to flatten a nested Thing into a single Thing, and you've got monads.

[08:59:01.0000] <gsnedders>
TabAtkins_: It's not even any behaviour.

[08:59:01.0000] <gsnedders>
TabAtkins_: It's not really a type.

[08:59:07.0000] <TabAtkins_>
Yes, it's a typeclass.

[08:59:19.0000] <TabAtkins_>
Or interface, or trait, or ABC.

[08:59:34.0000] <TabAtkins_>
Just like "Mappable" isn't a type.

[08:59:40.0000] <TabAtkins_>
You don't inherit from Mappable.

[09:00:49.0000] <gsnedders>
A map is a perfectly common name in category theory for functors. :P

[09:00:52.0000] <gsnedders>
TabAtkins_: :)

[09:01:02.0000] <gsnedders>
TabAtkins_: It's hard to explain *because* it's so abstract.

[09:01:35.0000] <astearns>
monads are living mirrors of the entire universe

[09:01:49.0000] <astearns>
(I only ever knew the philosophical term)

[09:01:54.0000] <Ms2ger>
/me puts astearns on the list too

[09:02:42.0000] <TabAtkins_>
gsnedders: Only if you're trying to explain it the most abstract terms.  Explain it in concrete terms, same as .map(), and nobody gets lost.  Let them build up to the abstract shit later, after they've gotten a hold on the most useful forms of it.

[09:03:11.0000] <TabAtkins_>
Most people don't need to know that functions are containers for their return value, and thus are monads, with composition being the flattening operation.

[09:03:29.0000] <TabAtkins_>
Sorry, composition is the mapping operation.

[09:03:59.0000] <TabAtkins_>
Flattening is just calling the return value with the same args again.

[09:04:10.0000] <jgraham>
TabAtkins_: Your way gives false insight though

[09:04:35.0000] <TabAtkins_>
jgraham: No, it gives useful insight.  All learning goes from concrete to abstract, and most people are actually totally fine with staying at some level of concreteness.

[09:04:49.0000] <jgraham>
You take something that people already understand (lists)

[09:05:06.0000] <jgraham>
And then you say "look this thing is an example of X, so now you understand X"

[09:05:20.0000] <TabAtkins_>
Yes.

[09:05:29.0000] <jgraham>
But they don't. They understand what they understood to begin with.

[09:05:30.0000] <TabAtkins_>
For most purposes, you *do* understand X.

[09:06:11.0000] <jgraham>
From your example I couldn't tell you whether any non-list thing was a monad

[09:06:21.0000] <TabAtkins_>
Specifically, for the purpose of stopping remarks like "sees monads, tunes out", when we're not doing anything that needs more than that basic understanding.

[09:06:37.0000] <TabAtkins_>
jgraham: From my example, no.  From my accompanying explanation (map, then flatten), you can.

[09:07:10.0000] <jgraham>
TabAtkins_: "map then flatten" still doesn't tell me anything much

[09:07:24.0000] <TabAtkins_>
You map, then you flatten.  What's there to tell?

[09:07:41.0000] <TabAtkins_>
If you map and end up with a nested Thing, you flatten back to a single Thing.

[09:08:07.0000] <TabAtkins_>
It's not complicated.  Don't try to make it so.

[09:08:08.0000] <jgraham>
I suspect you are taking people from "thing I don't understand" to "thing that TabAtkins_ keeps insisting is easy and to do with lists, but I don't understand and therefore I am too stupid to understand"

[09:08:46.0000] <TabAtkins_>
Do you understand "turn a nested Thing<Thing<value>> back to Thing<value>", and how flattening arrays is an example of that?

[09:09:57.0000] <jgraham>
TabAtkins_: Sure. For the record, I don't claim to have a good grasp of this, but I am slightly above the level at which I have given examples of how people will not understand

[09:10:52.0000] <TabAtkins_>
That's literally all you need to understand for most monads in practice.  If you've got a class with a .map() method, and a .flatten() method that will turn it from being nested to being flat, you're good.

[09:11:26.0000] <gsnedders>
Also, "most functions in most languages are actually monads".

[09:11:37.0000] <jgraham>
TabAtkins_: So, for example, one of the things that "everyone knows" about Monads is that Haskell uses them for IO (this is small values of "everyone", I admit). But it is entirely unclear from your example how monads work for that. Or for many of the other things that they are used for

[09:11:56.0000] <jgraham>
It is also very unclear why one would want to make one's own code monadic

[09:12:00.0000] <TabAtkins_>
Monads for IO are one of those abstract things that you dont' need to know to understand monads.

[09:12:18.0000] <TabAtkins_>
jgraham: Sure, that takes a few (easy, concrete) examples to show.

[09:12:34.0000] <TabAtkins_>
Arrays (and other containers), Option types, and you're pretty much good.

[09:13:12.0000] <TabAtkins_>
The IO monad leverages the "flatten is just a way to sequence computations" abstraction that is way above most uses of monads.

[09:16:42.0000] <jgraham>
I'm not sure that map/flatten is very obvious for maybe.

[09:18:13.0000] <jgraham>
(which is about the most trivial example)

[09:18:48.0000] <mathiasbynens>
Domenic_: does http://domenic.me/aplus-tests-against-the-browser/ match what’s in ES6 spec draft completely?

[09:19:03.0000] <TabAtkins_>
Sure, it's the first step outside of the base "container" concrete examples.

[09:19:36.0000] <TabAtkins_>
But it's easy to show - a Maybe either holds a value, or holds nothing.  When you map, you either map the value and return a new Maybe holding the return value, or just return an empty Maybe again.

[09:20:08.0000] <Domenic_>
mathiasbynens: it matches a subset of the ES6 spec.

[09:20:36.0000] <TabAtkins_>
If you have nested Maybes (because your mapped function also returned a Maybe), then you flatten a Maybe<Maybe<val>> into just a Maybe<val>, and a Maybe<Nothing> into a Nothing.

[09:20:44.0000] <mathiasbynens>
Domenic_: thanks for confirming

[09:22:03.0000] <TabAtkins_>
(Maybe can be implemented as an Array that holds either 0 or 1 values, where its .map() is Array.map(), and it's .flatten() is Array.flatten().)

[09:32:11.0000] <dglazkov>
good morning, Whatwg!

[09:35:04.0000] <aleray>
hi, using html5lib python I would like to clean up a webpage. For instance I would like to remove (including it's content) the script tags

[09:35:41.0000] <aleray>
I'm confused between filters, tokenizer and sanitizer

[09:35:48.0000] <aleray>
what is the difference?

[09:51:17.0000] <gsnedders>
aleray: The honest answer is the sanitizer API is a mess and needs completely changed. If you want something more stable, Bleach may or may not be suitable for your purposes.

[09:52:21.0000] <jgraham>
(Bleach uses html5lib internally)

[09:52:44.0000] <gsnedders>
(But provides a stable API, and will magically stay up-to-date with html5lib when all the breakage happens there.)

[09:53:12.0000] <jgraham>
But basically the tokenizer takes the tokens produced by reading the HTML before they are built into a tree (start-tag, end-tag, etc.)

[09:53:34.0000] <jgraham>
Using this for sanitising is rather broken and will not be supported in the future

[09:53:44.0000] <gsnedders>
s/sanitising/anything/

[09:54:01.0000] <jgraham>
Using it for treebuilding is just fine :)

[09:54:59.0000] <jgraham>
A filter is something that runs on the output of a treewalker. A treewalker is something that takes a parsed HTML tree and produces a series of events like start-tag, end-tag, etc. that would reconstruct that tree

[09:55:16.0000] <gsnedders>
Some filters currently operate (and only work) on the tokeniser. Such as the sanitizer.

[09:55:23.0000] <jgraham>
So it's a bit like a tokenizer with different input

[09:55:32.0000] <jgraham>
No, no

[09:55:42.0000] <jgraham>
The sanitiser tries to operate on both

[09:55:46.0000] <jgraham>
Badly

[09:56:06.0000] <gsnedders>
But only works on the tokenizer. It will *always* fail with a tree-walker.

[09:56:16.0000] <gsnedders>
Though it tries to work with it.

[09:56:47.0000] <jgraham>
A serializer takes the output from a tree walker, possibly after it passed though a filter, and writes it as markup

[09:57:22.0000] <jgraham>
So the setup you want is tokenizer -> treebuilder -> treewalker -> sanitizer filter -> serializer

[09:57:34.0000] <jgraham>
But that doesn't wuite work right now

[09:57:37.0000] <jgraham>
*quite

[09:57:47.0000] <gsnedders>
I think it might if the document has no attributes.

[09:57:51.0000] <jgraham>
(the first two parts are just called "parser")

[09:58:11.0000] <gsnedders>
On the other hand, the probability of having a document with no attributes… :)

[10:03:34.0000] <annevk>
http://esdiscuss.org/topic/specification-styles#content-11 Well, anti-IDL camp, curious to see your move :-)

[10:07:34.0000] <annevk>
Domenic_: you're missing that there's associated state with running a script

[10:08:00.0000] <Domenic_>
annevk: I don't get it. What state. Where is it captured.

[10:08:20.0000] <Domenic_>
Is this another thing where DOM specs have forked ES execution semantics?

[10:08:31.0000] <Domenic_>
so that [[Call]] takes some invisible parameter in DOM land?

[10:08:32.0000] <annevk>
Domenic_: it's script thread state

[10:08:46.0000] <annevk>
Domenic_: no, it's just some global associated with the current task

[10:08:58.0000] <annevk>
Domenic_: ES is just not complete in its task description

[10:08:59.0000] <Domenic_>
so that state isn't captured in the ES spec anywhere?

[10:09:06.0000] <aleray>
gsnedders, sorry I missed your answer.

[10:09:06.0000] <annevk>
Domenic_: it doesn't have tasks

[10:09:46.0000] <aleray>
I'm actually using bleach, but I don't find how to remove a tag and its content (eg. script tags)

[10:10:54.0000] <Domenic_>
.then, and ES in general, does not specify or care about this DOM thing. It just invokes [[Call]]. If window.postMessage.bind(...) has a special [[Call]] that uses some global state, then it needs to be specified by window.postMessage; it's not the promise spec's job

[10:11:56.0000] <aleray>
gsnedders, so if I don't want to use bleach, I'd rather use filters right?

[10:15:03.0000] <annevk>
Domenic_: ES5 doesn't queue tasks

[10:46:32.0000] <SimonSapin__>
annevk-cloud: I don’t really like the idea of "initial value" for the components of URL objects

[10:47:24.0000] <SimonSapin__>
or rather, baking mutability in the standard

[10:57:45.0000] <SimonSapin__>
annevk-cloud: Should the model also define constraints like "in the ASCII range" or "ASCII digits" (port) ?

[11:06:42.0000] <SimonSapin__>
annevk-cloud: Also, was it deliberate to go with a "flat" model where every component always exists, rather than expressing in the model constraints like "scheme data is exclusive with (user, password, host, port, path)"? https://github.com/SimonSapin/rust-url/blob/1db0239ec2c2cfcee5b7fb6e7402571844cb2135/url.rs#L33

[11:45:25.0000] <jsbell>
TabAtkins_: Any motion on (or interest in) EventStream since last April?

[11:56:31.0000] <TabAtkins_>
jsbell: Nope.

[12:25:09.0000] <SimonSapin>
annevk-cloud: only file URLs can have a null host, right?

[13:16:01.0000] <smaug____>
dglazkov: I assume with http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.html  you mean that blink will ship something but changes are still expected

[13:16:04.0000] <smaug____>
to shadow dom handling

[13:16:10.0000] <smaug____>
(like event propagation and what not)

[13:16:24.0000] <dglazkov>
smaug____: yep

[13:16:33.0000] <smaug____>
and you just want some css stuff to be a bit more stable

[13:16:36.0000] <TabAtkins_>
But syntax has a habit of freezing much faster than those things.

[13:16:37.0000] <TabAtkins_>
Yeah.

[13:17:25.0000] <dglazkov>
smaug____: also CSS stuff is hard to tweak with polyfills :-\

[13:17:30.0000] <smaug____>
sure

[13:17:47.0000] <Domenic_>
Does blink have plans to implement <style scoped> independent of shadow DOM?

[13:18:01.0000] <TabAtkins_>
It's not a priority right now, I don't think.

[13:18:03.0000] <dglazkov>
there was an implementation in there, but nobody watned it

[13:18:07.0000] <Domenic_>
sad

[13:18:19.0000] <smaug____>
It is just that http://lists.w3.org/Archives/Public/www-style/2014Feb/0036.html used rather strong and generic language

[13:19:01.0000] <smaug____>
(I hadn't noticed those emails but bz mentioned  in moznet#content)

[13:19:07.0000] <TabAtkins_>
smaug____: Sorry for the generic language - I was addressing the CSSWG, so "API" was understood to be "CSS API".

[13:19:35.0000] <Ms2ger>
CSS has APIs? :)

[13:41:23.0000] <yoav>
zcorpan: You around?

[13:41:29.0000] <zcorpan>
yes

[13:41:54.0000] <yoav>
Regarding the <img src crossorigin> stuff discussed on blink-dev

[13:42:56.0000] <yoav>
I can't find a browser that complies with the spec

[13:44:27.0000] <yoav>
zcorpan: see http://jsbin.com/OnOkuQE/1

[13:45:07.0000] <yoav>
Can't find a browser where bla.gif is requested with an "origin" header

[13:45:27.0000] <Hixie_>
so...

[13:45:35.0000] <Hixie_>
did ES kill the convenience type "ArrayBufferView"?

[13:50:26.0000] <zcorpan>
yoav: quite possible yeah. also i don't see the origin header in either request in firefox, but 'crossOrigin' in new Image() returns true

[13:51:14.0000] <yoav>
Hmm

[13:51:26.0000] <yoav>
Firefox does fail to add "origin" on both

[13:51:48.0000] <yoav>
Chrome adds it to bla2.gif, as well as IE

[13:52:07.0000] <jcgregorio>
Hixie_, annevk-cloud: per our discussion on Friday about Path/Path2D, this should work in Safari http://goo.gl/2uY5aA

[13:52:14.0000] <yoav>
I'm guessing Opera would too, but I can't test it, since there's no Linux version :P

[13:52:55.0000] <Hixie_>
wtf is "c.currentPath"

[13:53:09.0000] <Hixie_>
jcgregorio: yeah, ok, i didn't realise the safari implementation had no bearing on reality

[13:53:12.0000] <Hixie_>
jcgregorio: let's rename it!

[13:53:45.0000] <jcgregorio>
that was a proposed attribute, it's in Webkit, and behind a flag in blink

[13:53:52.0000] <yoav>
zcorpan: The point is, the part in the standard you pointed at regarding "stable state" doesn't seem to be implemented anywhere

[13:54:03.0000] <jcgregorio>
reading the list it looks like it got shot down, but still

[13:54:13.0000] <jcgregorio>
ended up implemented

[13:54:36.0000] <zcorpan>
yoav: right

[13:55:07.0000] <Hixie_>
jcgregorio: yeah the attribute doesn't make much sense

[13:55:10.0000] <zcorpan>
yoav: that's bad :-)

[13:55:12.0000] <Hixie_>
jcgregorio: (hence the result on the list)

[13:55:35.0000] <Hixie_>
jcgregorio: Path objects are supposed to be just used in arguments to e.g. fill() and stroke()

[13:55:52.0000] <Hixie_>
jcgregorio: changing the canvas' implied default path (or whatever i called it) is just weird

[13:56:12.0000] <jcgregorio>
Hixie_: agreed, which is what I'm trying to land in Blink

[13:56:21.0000] <Hixie_>
jcgregorio: cool

[13:56:39.0000] <Hixie_>
jcgregorio: if you land it with a different name for Path, like Path2D or CanvasPath or whatever, i'll use whatever name you used

[13:56:45.0000] <yoav>
zcorpan: Yeah. Not sure what the next step should be. I can open a bug about it,but with it not working in all other browsers, it might be tough

[13:57:30.0000] <Domenic_>
Hixie_: not sure about "killed" but http://people.mozilla.org/~jorendorff/es6-draft.html#sec-typedarray-objects seems relevant

[13:57:31.0000] <jcgregorio>
Hixie_: ok

[13:57:55.0000] <Hixie_>
Domenic_: yeah looks like the spec just dropped that name on the floor, probably didn't realise that a bunch of other specs were depending on it

[13:58:16.0000] <Hixie_>
Domenic_: i'm introducing a typedef on my side to ease the transition

[13:58:32.0000] <zcorpan>
yoav: indeed, it seems high risk, but still is easy to argue that the spec's behavior is better for authors

[13:58:40.0000] <Hixie_>
still no idea what i can do about "ArrayBuffer implements Transferable" though

[13:58:54.0000] <Hixie_>
i wish the JS spec was more WebIDLy

[13:59:05.0000] <yoav>
zcorpan: I agree. It's also better for srcset, not just crossorigin

[13:59:17.0000] <zcorpan>
yoav: <video> already does this (presto follows the spec closely there, not sure about other engines)

[13:59:18.0000] <zcorpan>
yep

[13:59:28.0000] <zcorpan>
and picture too

[13:59:33.0000] <yoav>
yeah

[14:02:29.0000] <Hixie_>
i wonder if JS still has the concept of a "readonly ArrayBuffer"

[14:02:40.0000] <Domenic_>
frozen?

[14:03:21.0000] <Hixie_>
no frozen means all kinds of other crap

[14:03:24.0000] <Hixie_>
like you can't change its properties

[14:03:35.0000] <Domenic_>
indeed.

[14:03:44.0000] <Domenic_>
I guess I don't know what readonly means

[14:03:45.0000] <Hixie_>
i basically never want frozen in my specs except for the Window and Location objects in cross-origin situations, if then

[14:03:52.0000] <Hixie_>
read only means "can't mutate underlying data"

[14:04:14.0000] <TabAtkins_>
So you can still add expandos?

[14:04:27.0000] <Hixie_>
sure

[14:05:42.0000] <TabAtkins_>
Yeah, that's a useful definition of it for me, for most purposes.  Just that the properties the spec defines can't be altered by userland code.

[14:09:04.0000] <Hixie_>
i wonder if you can mutate teh data returned by an xhr.response

[14:09:57.0000] <TheSeeker>
Is the work at http://wiki.whatwg.org/wiki/Adaptive_Streaming just a proposal, or is that able to be implemented immediately?

[14:10:28.0000] <Hixie_>
given that it starts with "Here is a (rough and incomplete) proposal", i'm going to guess "proposal"

[14:14:53.0000] <Hixie_>
wow. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2794

[14:14:56.0000] <Hixie_>
it's mutable.

[14:21:36.0000] <TheSeeker>
Hixie_: I was hoping that maybe someone might have implemented some proof of concepts of the idea since 2011, I guess not? :/

[14:21:51.0000] <Hixie_>
no idea

[14:22:00.0000] <Hixie_>
/me doesn't recall seeing this page before

[14:22:11.0000] <heycam>
zcorpan, annevk-cloud, so do we want to expose DOMException to workers? I guess yes, as there's nothing really DOM-ish about it, and if we have APIs that use DOMExceptions that we then want to expose to workers it would be good not to use a different exception there.

[14:22:15.0000] <Hixie_>
TheSeeker: (the wiki is more a scratch space for the whatwg, we don't really work on the wiki)

[14:22:26.0000] <Hixie_>
TheSeeker: (work happens on the mailing list or in bugs, mainly)

[14:22:45.0000] <Hixie_>
heycam: i throw DOMExceptions on workers, fwiw

[14:22:59.0000] <heycam>
Hixie_, ok cool, will make it so

[14:23:06.0000] <zcorpan>
heycam: we already have WebSocket, EventSource, XMLHttpRequest...

[14:23:40.0000] <Hixie_>
zcorpan: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24454 is proving to be a pain in the ass to fix btw :-P

[14:23:42.0000] <heycam>
zcorpan, since DOMException is going to be built in, I'll just make it exposed in all globals

[14:24:18.0000] <TheSeeker>
I'm trying to work out the best way to get streaming video working over Freenet ... which will require either major changes to Freenet (allowing for range-requests) or some kind of chunked video format where chunks are <= 4 MB each...

[14:24:56.0000] <zcorpan>
Hixie_: oh, does it affect everything that uses typed arrays?

[14:25:03.0000] <Hixie_>
yeah

[14:25:11.0000] <Hixie_>
zcorpan: i'm having to rework all the prose to use the new hooks

[14:25:21.0000] <zcorpan>
ok :-|

[14:25:27.0000] <Hixie_>
it had to happen eventually

[14:25:42.0000] <zcorpan>
heycam: sounds good

[14:30:03.0000] <TheSeeker>
oh well, I guess I'll start lookign somewhere else, thanks anyway.

[14:31:07.0000] <Hixie_>
i've really no idea how to use these hooks

[14:32:00.0000] <Hixie_>
do they really expect the HTML spec to have lots of [[blabla]] %blabla% BlaBla(...) so on in the prose?

[14:35:10.0000] <Hixie_>
zcorpan: i'm actually going to not bother trying to call the precise hooks. if you think it needs to be more closely defined, then please file a bug saying exactly what you want the spec to say. i can't work out what to say short of making the spec full of ugly things that i'm not convinced would actually improve interop.

[14:36:44.0000] <zcorpan>
Hixie_: ok i'll have a look tomorrow

[14:38:00.0000] <zcorpan>
/me is a bit surprised <svg>'s content model allows stuff in any order

[14:39:51.0000] <Hixie_>
structured clone of arraybufferview

[14:39:51.0000] <Hixie_>
ow

[14:41:48.0000] <Hixie_>
wtf does https://people.mozilla.org/~jorendorff/es6-draft.html#sec-new-dataview-argumentslist mean

[14:43:17.0000] <Domenic_>
It's the standard boilerplate for saying that calling new on DataView does the normal thing, not a special thing like it does on e.g. Array

[14:44:02.0000] <Domenic_>
the meat is in https://people.mozilla.org/~jorendorff/es6-draft.html#sec-dataview-buffer-byteoffset-bytelength and a bit in https://people.mozilla.org/~jorendorff/es6-draft.html#sec-dataview-@@create

[14:44:07.0000] <Hixie_>
i'm all for making specs be well-defined and all

[14:44:24.0000] <Hixie_>
but this goes beyond that and reaches a level of obscurity that i can't even dream of achieving.

[14:45:21.0000] <Domenic_>
it does seem a bit redundant. i can't actually find any examples that are nonstandard. (Array wasn't one of them it turns out.)

[14:46:05.0000] <Domenic_>
Ah, wow, Object is the exception it seems. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-new-object-argumentslist

[14:46:29.0000] <Hixie_>
ok, open this:

[14:46:30.0000] <Hixie_>
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data

[14:46:35.0000] <Hixie_>
and look where it says "ArrayBufferView"

[14:46:40.0000] <Hixie_>
how do i translate that to match the JS spec?

[14:46:45.0000] <Hixie_>
i cannot figure it out at _all_

[14:46:51.0000] <heycam>
zcorpan, for <title>?

[14:47:09.0000] <heycam>
zcorpan, it's just like in HTML where <title> can be any child of <head>, doesn't need to be the first or whatever

[14:47:41.0000] <zcorpan>
heycam: yeah i for some reason expected the descriptive elements to have to come first

[14:48:06.0000] <zcorpan>
heycam: well html separates <head> stuff from <body> stuff

[14:49:01.0000] <heycam>
zcorpan, oh you know SVG Tiny 1.2 has more strict author requirements about the position of <title>/<desc>

[14:49:15.0000] <heycam>
it's not in SVG 2 though (yet? maybe should port some of that wording across)

[14:49:17.0000] <Domenic_>
Hixie_: https://bugs.ecmascript.org/show_bug.cgi?id=2495 FWIW

[14:49:47.0000] <Hixie_>
Domenic_: it's not that it's repeated that i find confusing, btw. it's that it's utterly impenetrable.

[14:49:53.0000] <Hixie_>
Domenic_: i've literally no idea what that means

[14:50:09.0000] <Domenic_>
oh, well, i'm guessing that's just a matter of ES spec familiarity

[14:50:42.0000] <Domenic_>
I would translate it this way:

[14:50:46.0000] <Hixie_>
there's spec familiarity, and then there's the %foo% @@foo [[foo]] Foo() stuff that they use instead of English

[14:51:03.0000] <Hixie_>
Domenic_: do you have any idea how to translate the above HTML spec prose into JS-compatible prose?

[14:51:12.0000] <hober>
as a rule of thumb, if Hixie_ doesn't understand your spec prose after multiple reads, your spec is wrong. :)

[14:51:20.0000] <hober>
sorry, "prose"

[14:51:37.0000] <Hixie_>
i dunno about wrong, but i could certainly get behind "overly obtuse"

[14:52:14.0000] <hober>
s/wrong/bad/ then

[14:52:35.0000] <zcorpan>
heycam: now you made me try to read svg tiny 1.2's relaxng schema :-P

[14:52:50.0000] <heycam>
zcorpan, sorry

[14:53:08.0000] <heycam>
zcorpan, it may or may not describe the requirements reflected in the prose, who knows :)

[14:53:50.0000] <zcorpan>
heycam: i didn't find it in prose so i guessed maybe it just has its content model requirements in the schema

[14:53:51.0000] <Domenic_>
Hixie_: I see the rough outlines of how to do this. But getting the appropriate references right will take some time. I will work on it later tonight.

[14:54:05.0000] <heycam>
zcorpan, yeah it might be where I'm remembering it from

[14:54:13.0000] <zcorpan>
heycam: anyway i think any order seems better

[14:54:18.0000] <Hixie_>
Domenic_: don't worry about it, it'll become moot when JS takes over defining this stuff

[14:54:20.0000] <heycam>
zcorpan, ok

[14:56:55.0000] <Domenic_>
Hixie_: wait, I think it's as simple as: "Let _output_ be %TypedArray%(_input_)"

[14:57:06.0000] <Domenic_>
Using https://people.mozilla.org/~jorendorff/es6-draft.html#sec-%typedarray%-typedarray

[14:57:18.0000] <zcorpan>
i sometimes don't understand Hixie_'s spec prose after multiple reads, too. but i think that has more to do with the relevant thing being complex than with the way it is written

[14:57:35.0000] <hober>
zcorpan: right

[14:57:50.0000] <Domenic_>
You could change the predicate to "If _input_ has a [[TypedArrayName]] internal slot" as well.

[14:57:50.0000] <Hixie_>
Domenic_: the underlying buffer is changed by this (to a new buffer that's in the algorithm's "memory")

[14:58:16.0000] <Hixie_>
Domenic_: i think [[DataView]] is the internal property you're supposed to look for

[14:58:29.0000] <Domenic_>
Hixie_: I think that matches; %TypedArray% re-allocates a new buffer for its return value

[14:58:30.0000] <heycam>
"W3C DOM4"

[14:58:55.0000] <Hixie_>
Domenic_: i don't want it to allocate a new buffer, i need it to use the buffer that was cloned from the original one

[14:58:56.0000] <Domenic_>
Hixie_: I would bet they come together. The %TypedArray% algorithm does a predicate assert for [[TypedArrayName]] though.

[14:59:02.0000] <Domenic_>
ahhh

[14:59:27.0000] <Domenic_>
wow where is that captured in the HTML spec?

[14:59:32.0000] <annevk-cloud>
Hixie_: there are a bunch of IDL bugs open on integrating with ArrayBuffer and friends, I recommend waiting for that

[15:00:46.0000] <Hixie_>
Domenic_: it's the result of calling the algorithm recursively

[15:00:47.0000] <annevk-cloud>
SimonSapin: patches welcome

[15:01:11.0000] <annevk-cloud>
heycam: yes to workers :)

[15:01:27.0000] <SimonSapin>
annevk-cloud: Some of it is opinions rather than clear bugs

[15:01:34.0000] <Domenic_>
Hixie_: which clause gets entered on the recursion? I don't know what the IDL attributes of ArrayBufferViews are

[15:01:34.0000] <Hixie_>
Domenic_: (if you're cloning the ArrayBuffer, then it'll be cloned and put in the /memory/ variable before you get to this algorithm)

[15:02:00.0000] <Hixie_>
Domenic_:

[15:02:01.0000] <Hixie_>
er

[15:02:05.0000] <Hixie_>
Domenic_: "buffer", primarily

[15:02:12.0000] <annevk-cloud>
SimonSapin: I agree with some, eg immutable, but not clear how to do it simply

[15:02:23.0000] <SimonSapin>
annevk-cloud: btw, https://github.com/SimonSapin/rust-url/blob/master/parser.rs now passes your tests, with functional-style code rather than a state machine

[15:02:23.0000] <Domenic_>
So "If input is an ArrayBuffer object"?

[15:02:34.0000] <Hixie_>
Domenic_: no, it gets as far as step 1, then returns

[15:02:40.0000] <Hixie_>
Domenic_: because the buffer is in /memory/

[15:02:46.0000] <SimonSapin>
though I found some issues (meaning we need more tests :))

[15:02:47.0000] <Hixie_>
Domenic_: the mapping of old buffer to new buffer, that is

[15:03:30.0000] <Hixie_>
Domenic_: (it's cloned as part of creating the "transfer map" in the postMessage() methods)

[15:03:37.0000] <Domenic_>
hmm

[15:04:14.0000] <annevk-cloud>
SimonSapin: cool

[15:07:13.0000] <zcorpan>
heycam: i think document.title should be strict about using an svg:title child of the root when the root is svg:svg

[15:07:36.0000] <heycam>
zcorpan, yes I agree. what's the alternative though?

[15:08:12.0000] <zcorpan>
heycam: alternatives include ignoring the root and return the first html:title or svg:title in the document, for instance

[15:08:48.0000] <heycam>
zcorpan, ok. but yes selecting the first svg:title child of the root sounds like the right thing to me.

[15:09:33.0000] <zcorpan>
same on setting, and appending a title to the root if there isn't a title

[15:10:24.0000] <heycam>
yeah

[15:10:32.0000] <zcorpan>
and here i started to wonder about <svg>'s content model :-)

[15:10:39.0000] <Domenic_>
for comic relief http://stackoverflow.com/questions/21405066/is-this-an-ie11-radio-button-rendering-bug-they-look-like-googly-eyes

[15:12:09.0000] <zcorpan>
optical illusion, heh

[15:12:44.0000] <annevk-cloud>
Structured clone proposal Dimitry and I wrote was accepted by TC39 last week btw I saw somewhere

[15:13:18.0000] <annevk-cloud>
So at some point that too should be somebody else their problem

[15:13:40.0000] <Hixie_>
well, it'll still be my problem for a lot of it, i assume

[15:13:53.0000] <Hixie_>
i mean, i doubt they're going to actually spec how postMessage() works, for example

[15:13:59.0000] <annevk-cloud>
You get hooks

[15:14:14.0000] <Hixie_>
i hope they're better hooks than i get for ArrayBuffer

[15:14:59.0000] <annevk-cloud>
They are similar in need, no?

[15:15:18.0000] <Hixie_>
the hooks for ArrayBuffer are incomprehensible

[15:15:30.0000] <annevk-cloud>
You are hacking around something ES does not define but ES engines have

[15:15:58.0000] <annevk-cloud>
It has no hooks for the host environment afaict

[15:16:55.0000] <annevk-cloud>
Anyway, I recommend postponing those issues for a bit

[15:17:56.0000] <Hixie_>
btw what's the status on the event loop hooks?

[15:18:11.0000] <Hixie_>
i still haven't heard anything from anyone about that

[15:18:28.0000] <Hixie_>
which you'd think i'd hear about, since right now i'm the guy speccing the event loop

[15:19:07.0000] <Domenic_>
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-enqueuetask

[15:19:46.0000] <Domenic_>
I think the idea was to do a minimal amount of work and leave most of that in your capable hands still

[15:20:53.0000] <Domenic_>
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-nexttask-result-algorithm-step is probably the most likely to step on your toes, but seems sufficiently small and vague as to not do so that badly

[15:21:23.0000] <zcorpan>
Hixie_: maybe you can take inspiration from microsoft and close spec bugs claiming optical illusion

[15:21:52.0000] <Hixie_>
zcorpan: i believe the w3c already uses that kind of approach, so i'll let them be in charge of that

[15:22:04.0000] <Hixie_>
Domenic_: so should i be invoking this stuff somewhere?

[15:22:05.0000] <Domenic_>
allen has so many typos... -_-

[15:22:52.0000] <Hixie_>
seems like EnqueueTask() should invoke a callback on my side so i can add an HTML-spec "task" to an HTML-spec "task queue" to do something useful

[15:23:28.0000] <Domenic_>
I think the intent is to let the "implementation defined" stuff give control back over to your more-fleshed-out event loop

[15:23:45.0000] <Domenic_>
e.g. "If all Task Queues are empty, the result is implementation defined."

[15:24:04.0000] <annevk-cloud>
Note that ES task === HTML microtask

[15:24:09.0000] <annevk-cloud>
:/

[15:24:15.0000] <Domenic_>
I am trying to find how you get *in* to this system though

[15:24:16.0000] <Domenic_>
yeah that was unnecessarily confusing annevk-cloud

[15:24:23.0000] <Hixie_>
for some definition of "==="

[15:24:23.0000] <Domenic_>
in earlier drafts he showed me it said microtask

[15:25:19.0000] <annevk-cloud>
Hixie_: 😀

[15:25:38.0000] <zcorpan>
does the ES event loop know about 'stable state'?

[15:25:55.0000] <Domenic_>
Ah this is how you get in. "When there is no running execution context and the execution context stack is empty, the ECMAScript implementation removes the first PendingTask from a Task Queue and uses the information contained in it to create an execution context and starts execution of associated Task abstraction operation."

[15:26:03.0000] <Domenic_>
interestingly that sounds related to "stable state"?

[15:27:43.0000] <Domenic_>
so e.g. that prose sentence will launch you into something like PromiseReactionTask. Which will then call NextTask when it's done with its stuff. Which when there are no more ES microtasks, will have an implementation-defined result. Which is where things can go back to HTML's control

[15:30:29.0000] <Domenic_>
I think it would be more friendly if instead of that prose sentence there was some kind of Drain(Micro)TaskQueue operation you could call

[15:38:52.0000] <Hixie_>
Domenic_: k well... i'll await a bug or e-mail requesting integration with a proposal for how to do it, i guess :-)


2014-02-04
[17:31:32.0000] <falken>
Hixie_: Regarding https://www.w3.org/Bugs/Public/show_bug.cgi?id=20418, I thought the idea was to change non-modals to not be centered, not clipped, not in the initial containing block... and just be regular boxes. Which is different than what was spec'd before.

[17:38:37.0000] <aleray>
is it possible to achieve this: http://dpaste.com/1584387/

[17:38:40.0000] <aleray>
?

[17:38:51.0000] <aleray>
(moving the id attribute up)

[17:45:14.0000] <TabAtkins_>
aleray: ...yes, it is possible, through any number of means.  What are you trying to do?  Did you mean to ask that question in this room?

[17:54:20.0000] <aleray>
TabAtkins_, oups sorry

[17:54:29.0000] <aleray>
I meant using html5lib python

[17:55:14.0000] <aleray>
(or lxml since I'm using that too)

[17:55:43.0000] <TabAtkins_>
Oh, yeah.  Just remove the id from the first element, move up with .getparent(), and add it back.

[17:56:03.0000] <aleray>
TabAtkins_, perfect

[17:56:17.0000] <TabAtkins_>
LXML is horribly documented. I sympathize.

[18:10:13.0000] <aleray>
something like this? line 11 http://dpaste.com/1584436/

[18:10:17.0000] <aleray>
TabAtkins_,

[18:11:12.0000] <TabAtkins_>
That looks approximately right.

[18:33:12.0000] <aleray>
TabAtkins_, nice

[18:34:08.0000] <aleray>
can I make this code agnostic to the lib I use? ex using dom instead of lxml?

[18:34:32.0000] <JosephSilber>
TabAtkins_: Is it possible to have a flexbox with align items strech, while still extending beyond the container if needed?

[18:35:37.0000] <JosephSilber>
TabAtkins_: http://stackoverflow.com/questions/21515042/scrolling-a-flexbox-with-overflowing-content/21541021

[18:36:06.0000] <TabAtkins_>
aleray: Dunno if there's a DOM library on top of lxml.  I wrote some custom stuff for myself that's DOM-like because lxml is crap.

[18:37:39.0000] <aleray>
TabAtkins_, thanks. Time to sleep, I'll dive into it tommorow

[18:37:45.0000] <aleray>
thanks for helping

[18:38:47.0000] <TabAtkins_>
JosephSilber: Yes, just do the normal thing you would do with overflowing and such.

[18:38:53.0000] <TabAtkins_>
It works exactly normally.

[18:39:13.0000] <JosephSilber>
TabAtkins_: It doesn't http://codepen.io/anon/pen/Enjqg

[18:39:38.0000] <JosephSilber>
Oops. Wrong link. Here: http://codepen.io/anon/pen/qFbKg

[18:41:21.0000] <JosephSilber>
See the borders there? They don't extend beyond the container's size

[18:42:06.0000] <TabAtkins_>
JosephSilber: Ah, indeed.  Sorry, I was looking at a smaller testcase where the flex item itself overflowed, rather than its contents.

[18:42:31.0000] <TabAtkins_>
I don't *think* there's a way to solve that, but I'll have to look later.  Gotta head home now.

[18:53:17.0000] <TabAtkins_>
JosephSilber: Okay, looked into it more.

[18:53:30.0000] <TabAtkins_>
JosephSilber: You're right that it won't work by default.

[18:54:11.0000] <TabAtkins_>
To make it work, you'll need a min-height: min-content; declaration, from <http://dev.w3.org/csswg/css-sizing/>, which I don't think is supported anywhere yet.

[18:54:22.0000] <JosephSilber>
:(

[18:55:02.0000] <JosephSilber>
thanks though

[18:55:14.0000] <TabAtkins_>
Such is life in today's paucity of sizing controls.

[18:55:59.0000] <TabAtkins_>
Alternately, setting align-self:flex-start and height:fill-available should probably work (but again, no support).

[18:56:19.0000] <JosephSilber>
No support for fill-available?

[18:57:12.0000] <JosephSilber>
TabAtkins_: There is a way to hack it, if the container has a set height. I can remove the display: flex from the container, then nest another element inside. Make *that* the flex container, and give it a min-height: 100%

[18:57:44.0000] <TabAtkins_>
Right, fill-available is also from Sizing, and also unsupported iirc.

[18:58:01.0000] <TabAtkins_>
Interesting hack.

[18:58:10.0000] <JosephSilber>
But the layout I'm dealing with needs the container to be fluid height :(

[19:02:45.0000] <TabAtkins>
JosephSilber: Then yeah, you're screwed until we get more sizing controls.

[19:03:09.0000] <JosephSilber>
TabAtkins: seems there is some support: http://caniuse.com/#feat=intrinsic-width

[19:07:38.0000] <TabAtkins>
Yup yup, but at least in Chrome, it's only supported for 'width'/etc *I think*.

[19:08:18.0000] <JosephSilber>
TabAtkins: Well, it kinda works here: http://codepen.io/anon/pen/qFbKg

[19:08:48.0000] <JosephSilber>
Just can't figure out why it forces scrollbars, even though I set box-sizing to border-box

[19:08:54.0000] <TabAtkins>
Not in Chrome, as far as I can tell.

[19:09:13.0000] <JosephSilber>
Interesting. I'm looking at it in Chrome.

[19:09:44.0000] <TabAtkins>
Hm.  Oh, that pen isn't showing any use of the keywords at all.

[19:10:12.0000] <JosephSilber>
Hadn't saved. Here you go again: http://codepen.io/anon/pen/qFbKg

[19:21:23.0000] <TabAtkins>
That fill-available behavior is a bug.  Mind reporting it?

[19:22:36.0000] <JosephSilber>
TabAtkins: Yep. I'll build an isolated case.

[19:23:31.0000] <TabAtkins>
If you swap around and use min-height:min-content instead, it works: http://codepen.io/anon/pen/dIlho

[19:24:03.0000] <TabAtkins>
Unfortunately you have to remove the box-sizing declaration.  The behavior of box-sizing in my example is terrible, but not technically a bug, since that's what the spec actually mandates.

[19:24:07.0000] <TabAtkins>
I'll have to fix that tomorrow.

[19:25:26.0000] <JosephSilber>
min-height:min-content does fix it, but I don't understand why.

[19:26:01.0000] <TabAtkins>
stretch tries to set it to the flexbox's height, unless it's too tall explicitly.  Setting min-height:min-content makes it as tall as its contents, so it triggers the "too tall" behavior.

[19:26:02.0000] <JosephSilber>
By default it should anyhow be expanding to it's content's height

[19:26:18.0000] <TabAtkins>
Nope, that's not how stretch works.

[19:26:43.0000] <JosephSilber>
So steretch doesn't care about the element's intrinsic height

[19:27:17.0000] <TabAtkins>
It does.  An element's contents don't contribute to its intrinsic height.

[19:27:27.0000] <TabAtkins>
"intrinsic height" being a technical term with a specific definition in CSS.

[19:27:40.0000] <JosephSilber>
oh. ok. thanks a million. will play with it.

[19:28:29.0000] <TabAtkins>
No problem! Glad to find out that we did indeed fix 'height'/etc and make the keywords work on those properties.

[19:28:53.0000] <TabAtkins>
Now I just need to get that spec out the door so we can unprefix.

[19:30:55.0000] <JosephSilber>
I can't reproduce that m fill-available bug

[19:31:26.0000] <TabAtkins>
I'll try to reduce it later.

[19:48:45.0000] <JosephSilber>
TabAtkins: using min-height: min-content only stretches the ones whose content are actually taller, but it doesn't affect their siblings. Any flex item whose content doesn't extend beyong the parent's height will still be cut off there: http://codepen.io/anon/pen/ehLFl

[20:05:46.0000] <TabAtkins>
JosephSilber: Hm, you're right.  Try inserting another container around the columns, and make *that* a flexbox with min-height:min-content.

[20:05:55.0000] <TabAtkins>
Then the columns should all stretch to the maximum height, I think.

[20:06:32.0000] <TabAtkins>
Unfortunately you can't just put those properties on .content, because .content has to host the scrollbar.

[20:06:48.0000] <TabAtkins>
(In the middle of making dinner, or I'd be trying this out myself.)

[20:07:06.0000] <JosephSilber>
TabAtkins: sorry for bothering you. will try

[20:17:18.0000] <JosephSilber>
That does the trick

[20:18:07.0000] <JosephSilber>
I just hate haviong to nest so many containers

[20:18:25.0000] <TabAtkins>
Yeah, I know. :/

[20:18:35.0000] <TabAtkins>
Grid will help remove most of them.

[20:18:46.0000] <JosephSilber>
That's still some way out

[20:19:50.0000] <TabAtkins>
Not too far out. Chrome's gonna try to ship it early-ish this year.  As soon as I take the spec to CR, which I plan to do Real Soon Now®.

[20:20:51.0000] <JosephSilber>
That's great news.

[20:21:18.0000] <JosephSilber>
How compatible would that be with what IE has today?

[20:21:30.0000] <TabAtkins>
Very close.

[20:21:55.0000] <TabAtkins>
I think property names changed a lot, like Flexbox, but that's it.

[20:22:08.0000] <TabAtkins>
And we added the template syntax, but that's not required to use Grid, just very helpful.

[20:22:14.0000] <JosephSilber>
TabAtkins: autoprefixer should be able to handle that just fine

[20:22:22.0000] <TabAtkins>
Yup.

[20:22:56.0000] <JosephSilber>
TabAtkins: I love you. Irally adore you. You've brought the most useful stuff to the web in a long time.

[20:23:12.0000] <JosephSilber>
Thanks

[20:23:30.0000] <TabAtkins>
Welcome. ^_^

[20:51:00.0000] <JosephSilber>
<TabAtkins> JosephSilber: Hm, you're right.  Try inserting another container around the columns, and make *that* a flexbox with min-height:min-content.

[20:51:14.0000] <JosephSilber>
Turns out, that *doesn't* work :(

[20:51:36.0000] <JosephSilber>
It removes the stretching from the columns.

[20:52:44.0000] <JosephSilber>
nvm.

[20:53:10.0000] <JosephSilber>
I keep on jumping between the pen and my real project, but I keep on running into issues in my real project.

[20:53:23.0000] <JosephSilber>
Hopefully I'll work it out

[02:31:43.0000] <yoav>
zcorpan: PhillipJ beat me to it :)

[02:32:14.0000] <zcorpan>
heh

[02:48:13.0000] <annevk>
zcorpan: can the stable state stuff even work?

[02:48:34.0000] <annevk>
zcorpan: iirc there's pages depending on img.src = x; if(img.width == 400) to work

[02:48:55.0000] <annevk>
zcorpan: combined with the document image map of course

[02:49:07.0000] <zcorpan>
annevk: the spec supports that. it's loaded immediately if the image is in cache

[02:49:18.0000] <annevk>
zcorpan: I see

[02:49:28.0000] <annevk>
What's up with the new Twitter?

[02:49:44.0000] <yoav>
annevk: Wouldn't such pages be racy even with immediate download?

[02:50:18.0000] <annevk>
yoav: ideally normally you'd queue a task before you update attributes

[02:51:03.0000] <annevk>
zcorpan: some aspects of that you might want to fix for <picture> btw

[02:51:19.0000] <annevk>
zcorpan: <img> being so broken is one of the main reasons lazyload is proposed

[02:52:49.0000] <zcorpan>
annevk: what would you want changed?

[02:53:33.0000] <annevk>
zcorpan: I think I'd prefer the whole thing to queue a task and then do the fetch

[02:54:09.0000] <annevk>
zcorpan: and not have the document image cache lookup

[02:54:23.0000] <annevk>
zcorpan: sorry, do have that lookup, but don't have it be sync

[02:54:40.0000] <zcorpan>
annevk: how can it not be sync if pages depend on it?

[02:54:54.0000] <annevk>
zcorpan: you can't change it for <img>

[02:55:43.0000] <zcorpan>
lunch

[02:55:49.0000] <yoav>
annevk: Do you have an example of such a page? I find it odd that pages would rely on width and get away with it, even today

[02:56:22.0000] <annevk>
see topic

[02:58:13.0000] <yoav>
annevk: The "sense of logic" part? :)

[03:00:19.0000] <yoav>
All I'm saying is that I doubt there's lots of contents relying on it, since it's likely to fail to work today, at least when the image is not in cache

[03:01:19.0000] <annevk>
they rely on the special image cache to be there, that's the whole reason the special image cache is defined

[03:01:28.0000] <annevk>
well, expected perf is another I suppose

[03:01:38.0000] <annevk>
I don't really have any example pages though

[03:01:49.0000] <annevk>
I'm sure you can find some crawling through browser bugs

[03:03:54.0000] <yoav>
OK

[03:39:41.0000] <annevk>
SimonSapin: is your parser complete?

[03:39:46.0000] <annevk>
SimonSapin: I like it

[04:07:44.0000] <zcorpan>
annevk: picture uses img so it can't not use the image cache

[04:10:23.0000] <SimonSapin>
annevk: I think some corner cases with file: are wrong

[04:10:31.0000] <SimonSapin>
but yeah, should be mostly complete

[04:11:16.0000] <Ms2ger>
SimonSapin, wouldn't the while i < input.len() { loops look better with iterators?

[04:39:17.0000] <annevk>
zcorpan: what do you mean uses img?

[04:39:57.0000] <zcorpan>
annevk: it's the <img> element that runs the selection algorithm

[04:48:15.0000] <annevk>
zcorpan: hmm, is there a spec for picture?

[04:48:26.0000] <zcorpan>
http://picture.responsiveimages.org/

[04:49:53.0000] <SimonSapin>
Ms2ger: the thing is, I often want i to outlive the loop

[04:51:34.0000] <annevk>
Are we really putting CSS syntax into HTML attributes zcorpan?

[04:51:43.0000] <annevk>
I guess we did it for media queries...

[04:51:58.0000] <zcorpan>
for some value of css syntax

[04:54:21.0000] <annevk>
Well now you can use CSS escapes to define the URL

[04:54:29.0000] <SimonSapin>
the CSS Syntax spec deliberately makes the tokenizer available separately

[04:54:41.0000] <Ms2ger>
zcorpan, r? https://critic.hoppipolla.co.uk/r/645

[04:54:45.0000] <annevk>
The original srcset did not have that

[04:54:58.0000] <annevk>
SimonSapin: that's very generous

[04:55:12.0000] <zcorpan>
annevk: hmm. not sure that's intentional. TabAtkins?

[04:56:10.0000] <zcorpan>
Ms2ger: i'll get to it :-)

[04:56:15.0000] <Ms2ger>
Thanks!

[05:17:59.0000] <MikeSmith>
hmm Samsung intending to implement context menus in blink

[05:43:41.0000] <darobin>
annevk: hey, do you know if Encoding has a test suite?

[05:44:00.0000] <annevk>
no, just adhoc stuff

[05:44:52.0000] <darobin>
ok, thanks

[05:49:37.0000] <darobin>
annevk: do you have that stuff somewhere? I wonder if I could find someone foolish enough to take a stab at this one

[05:49:50.0000] <darobin>
and even ad hoc stuff can help bootstrap

[05:50:59.0000] <annevk>
darobin: oh, I actually did write a test for single-byte encodings

[05:51:00.0000] <annevk>
darobin: http://dump.testsuite.org/encoding/

[05:51:13.0000] <darobin>
annevk: cool, ta!

[05:51:28.0000] <annevk>
darobin: I have a bunch more scattered locally and some old hard drive that's online somewhere, but it's probably easier to start from scratch for those

[05:51:48.0000] <darobin>
those single byte tests even look pretty sane

[05:52:12.0000] <annevk>
Yeah, I forgot about those

[05:52:30.0000] <darobin>
thanks, that's useful

[05:52:45.0000] <darobin>
I reckon the TS could be bootstrapped with just a port of this to testharness.hs

[05:52:47.0000] <darobin>
*js

[05:53:07.0000] <gsnedders>
You really just want to write a testharness.hs to generate the testharness.js

[05:53:24.0000] <darobin>
/me whacks gsnedders behind the ears

[05:53:57.0000] <gsnedders>
Deep inside, you know you really want to be using Haskell.

[05:55:38.0000] <annevk>
darobin: note that some of that might be out of date a bit

[05:55:47.0000] <annevk>
darobin: haven't kept it up to date with changes to the spec

[05:57:47.0000] <darobin>
annevk: an out of date starting place is better than nothing at all

[05:58:04.0000] <darobin>
gsnedders: no, at jgraham's behest I only code in Coq

[05:59:18.0000] <gsnedders>
darobin: But then you can at least programmatically extract Haskell from your theorems!

[06:03:53.0000] <darobin>
gsnedders: I don't often programmatically extract from my theorems, but when I do, it's in Haskell

[06:10:39.0000] <annevk>
what's all this Haskell love

[06:13:36.0000] <jgraham>
Haskell :: p -> ♡ p

[06:22:03.0000] <gsnedders>
annevk-cloud: Dude, I worked on Carakan post-release. Of course I'm a Haskell fanboy.

[06:33:43.0000] <zcorpan>
/me notices hsivonen.iki.fi is now hsivonen.fi

[06:35:22.0000] <zcorpan>
hsivonen: /test is gone?

[06:35:38.0000] <zcorpan>
oh needs trailing slash

[06:46:06.0000] <zcorpan>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24485 is why ping="" would be nice

[06:46:56.0000] <smaug____>
dglazkov: so what is the plan with shipping shadow dom?

[06:47:11.0000] <smaug____>
I hope we'll get it a bit more stable and spec reviewed before anyone ships it

[06:48:12.0000] <MikeSmith>
smaug____: there as an intent message on blink-dev yesterday

[06:48:16.0000] <MikeSmith>
intent to ship I guess

[06:49:04.0000] <smaug____>
that is why I ask

[06:49:27.0000] <smaug____>
what does that mean in practice

[06:49:30.0000] <smaug____>
like when

[06:49:48.0000] <smaug____>
and how major changes they are ok to still make

[06:50:16.0000] <MikeSmith>
I assume Chrome 34 but maybe it's later

[06:50:40.0000] <smaug____>
need to be more careful with this kind of major change comparing to some smaller APIs

[06:52:29.0000] <MikeSmith>
smaug____: you could post a reply to blink-dev

[06:54:20.0000] <smaug____>
/me wonders if that requires use of a google account

[06:55:10.0000] <MikeSmith>
no

[06:55:19.0000] <MikeSmith>
I don't think

[06:55:55.0000] <MikeSmith>
it's just a mailing list with a really horrible Web UI dropped on top of it

[06:56:32.0000] <MikeSmith>
ah shit maybe you actually do need a google account

[06:56:43.0000] <MikeSmith>
as far as subscribing

[06:58:03.0000] <MikeSmith>
/me checks the message headers for a subscribe thingey

[06:58:10.0000] <hsivonen>
zcorpan: good catch. Try /test/

[06:58:21.0000] <zcorpan>
hsivonen: yeah that worked

[06:58:40.0000] <MikeSmith>
smaug____: http://groups.google.com/a/chromium.org/group/blink-dev/subscribe

[07:00:10.0000] <MikeSmith>
smaug____: blink-dev+subscribe⊙co

[07:18:31.0000] <MikeSmith>
smaug____: anyway as far as I can tell you can actually subscribe to it using any arbitrary e-mail address you want. They just go out of their way to make it a massive PITA to do it

[07:20:21.0000] <jgraham>
Everyone uses google, right?

[07:22:52.0000] <annevk-cloud>
I subscribe using an email address that does not have a Google Account

[07:22:59.0000] <smaug____>
MikeSmith: I think I managed to subscribe using my spam-email account

[07:23:42.0000] <annevk-cloud>
smaug____: I suspect you need to give some detailed feedback though

[07:24:30.0000] <annevk-cloud>
I wonder if they ended up special casing Text nodes

[07:24:39.0000] <smaug____>
annevk-cloud: yeah, that is the problem. Would need to have time to review the stuff again

[07:25:05.0000] <smaug____>
but I'm actually mostly wondering why they think the spec is stable enough

[07:25:25.0000] <annevk-cloud>
Seems like a fair question

[07:25:38.0000] <annevk-cloud>
Also, I recommend making time :)

[07:32:14.0000] <foolip>
annevk-cloud: sorry about that, see your inbox :/

[09:01:38.0000] <yoav>
annevk-cloud: Regarding what we discussed earlier - I see Gecko returning width when the image is cached, but not Chrome

[09:01:40.0000] <yoav>
http://jsbin.com/OdOqiSO/2

[09:02:47.0000] <yoav>
And even in Gecko it (rightfully) breaks when the page is refreshed (F5, not even ctrl+F5)

[09:04:01.0000] <yoav>
So it seems like a very fragile thing for authors to count on

[09:30:27.0000] <annevk-cloud>
yoav: interesting, maybe things can be made better

[11:03:46.0000] <dglazkov>
good morning, Whatwg!

[11:14:18.0000] <zcorpan>
"identical elements are replace with a 'use' element; " ;_; http://libregraphicsworld.org/blog/entry/svg-cleaner-0-6

[12:22:43.0000] <zcorpan>
yoav: what does http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2795 log for you?

[12:24:11.0000] <yoav>
log: 0

[12:24:11.0000] <yoav>
rendering mode: CSS1Compat

[12:24:11.0000] <yoav>
document has no title

[12:24:11.0000] <yoav>
log: 195

[12:25:02.0000] <zcorpan>
that means it makes the width available immediately when the image is cached

[12:30:32.0000] <yoav>
zcorpan: If I understand correctly, the second log, that shows the width, is printed after onload,so after the image was loaded (regardless of caching)

[12:31:29.0000] <zcorpan>
yoav: in window.onload, test() is run again which creates a new <img> and logs its width

[12:31:43.0000] <yoav>
Right

[12:31:59.0000] <zcorpan>
yoav: so at that point the image it points to will be in the cache, because a different <img> loaded it earlier

[12:32:41.0000] <zcorpan>
yoav: if caching was disabled completely, both would log 0

[12:33:13.0000] <yoav>
Yeah, I get your point

[12:35:20.0000] <yoav>
So, does that mean that the stable state stuff cannot work?

[12:42:56.0000] <yoav>
zcorpan: Or must be simulated, rather than implemented as is?

[12:43:59.0000] <zcorpan>
yoav: the stable state stuff is about waiting to fetch an image that is *not* in the cache

[12:44:12.0000] <zcorpan>
yoav: the spec requires images that are in the cache to be available immediately

[12:44:59.0000] <zcorpan>
yoav: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#update-the-image-data step 7 substep 3

[12:46:21.0000] <zcorpan>
yoav: "A user agent that obtains images immediately must also synchronously update the image data of an img element whenever that element has its src, srcset, or crossorigin attribute set, changed, or removed." #the-img-element

[12:47:38.0000] <yoav>
zcorpan: Need to dig up and see how this translates to code...

[13:05:30.0000] <zcorpan>
yoav: btw i found https://bugzilla.mozilla.org/show_bug.cgi?id=466586 when searching for bugs in this area. not sure what the bug is there exactly but it seems the page in question expects .width to be available

[13:07:07.0000] <yoav>
zcorpan: Basically, it seems like we'd need to split/duplicate ImageLoader::updateFromElement and create an updateFromElementIfCached or something of that sort

[13:09:17.0000] <zcorpan>
yoav: i'm not familiar with the code so i'm not sure what that means :-) maybe foolip does

[13:10:28.0000] <yoav>
zcorpan: :) Basically I'm looking for ways to split out the "image is already cached" case, so that all other algos will be activated on stable state

[13:10:58.0000] <zcorpan>
yoav: ok

[13:11:30.0000] <yoav>
The alternative is to start loading the image, and cancel it if something changes, which gets complicated once we have src, srcset,crossorigin and picture to take into consideration

[13:12:04.0000] <zcorpan>
yeah we don't want to do that

[13:13:17.0000] <zcorpan>
at least if "start loading" means we can hit the network before we decide to cancel

[13:14:37.0000] <yoav>
zcorpan: Oh, definitely. But even if it doesn't hit the network, it can get really complicated to juggle all that

[13:15:12.0000] <zcorpan>
yeah

[13:17:26.0000] <zcorpan>
i wonder if it's a good idea to make the sync cache thing unaware of srcset/picture, if that makes the implementation simpler

[13:21:15.0000] <yoav>
zcorpan: for srcset, it shouldn't matter much

[13:21:58.0000] <yoav>
for picture, maybe. I need to think about it

[14:26:26.0000] <sicking>
Hixie: why navigator.getLanguages() rather than navigator.languages?

[14:26:45.0000] <Hixie>
what would navigator.languages return?

[14:27:07.0000] <sicking>
A frozen Array of string values

[14:27:16.0000] <sicking>
the frozen is part is still being debated

[14:27:38.0000] <sicking>
but we'll only remove it if it's what authors actually think is more JSy

[14:27:42.0000] <Hixie>
a new one each time?

[14:27:55.0000] <sicking>
no, same Array until the contents changes

[14:27:56.0000] <Domenic_>
can the languages change?

[14:28:00.0000] <sicking>
see https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682

[14:28:02.0000] <Domenic_>
ah right hte compromise

[14:28:04.0000] <sicking>
this is use-case B

[14:28:30.0000] <sicking>
Domenic_: heycam should be drafting you and a few others an email about whether to freeze or not

[14:28:37.0000] <heycam>
yeah

[14:28:40.0000] <heycam>
will do that this week

[14:29:05.0000] <Domenic_>
cool. excited that people are hammering this out.

[14:29:08.0000] <sicking>
Domenic_: it seems like freezing is the closest thing we have to the desired behavior that we have. Though I know freezing is frowned upon by a lot of people

[14:29:13.0000] <Hixie>
sicking: returning a frozen anything seems like a bad idea since it means you can't use it like a normal object (even Node can have expandos, e.g.). returning an Array seems like a bad idea since it means that n.languages !== n.languages sometimes.

[14:29:52.0000] <sicking>
Hixie: no, n.languages === n.languages will always return true. It only changes value from a task

[14:29:58.0000] <Domenic_>
sicking: I think freezing works really well. I will be sure to give it some thought though when that email comes around.

[14:30:07.0000] <Hixie>
sicking: n.languages !== oldnlanguages

[14:30:26.0000] <sicking>
Hixie: sure, Node.nodeValue !== oldNodeValue too sometimes

[14:30:42.0000] <sicking>
Hixie: Same thing with Element.innerHTML

[14:30:51.0000] <Hixie>
sicking: those don't return objects.

[14:31:01.0000] <sicking>
Hixie: so?

[14:31:19.0000] <sicking>
Hixie: Node.firstChild !== oldNodeFirstChild

[14:32:28.0000] <Hixie>
sicking: sure but if you change the first child back, then it goes back to its old value

[14:32:39.0000] <Hixie>
sicking: it doesn't start returning a new object with the same value as the old old object

[14:32:53.0000] <sicking>
Hixie: true, but if you create a new Node with the same contents then that's not the case

[14:32:57.0000] <Hixie>
sicking: it's just bad API design to return a non-live array from a property, imho. Causes all kinds of weird behaviour.

[14:33:06.0000] <Hixie>
especially a non-live mutable array.

[14:33:07.0000] <sicking>
Hixie: like?

[14:34:15.0000] <sicking>
Hixie: As an implementor, I'm more interested in following concentions used elsewhere. I'm happy to wait until we've established a recommended syntax in WebIDL though. But if so, please remove getLanguages() in the meantime

[14:34:46.0000] <Hixie>
is there any other API anywhere where we return an array?

[14:35:10.0000] <Hixie>
hm, i guess there are some

[14:35:20.0000] <Hixie>
oh but those are live and readonly

[14:35:27.0000] <sicking>
See the use-cases in the bug

[14:35:34.0000] <Domenic_>
live and readonly arrays do not exist

[14:35:40.0000] <sicking>
live is generally hated by everyone

[14:36:06.0000] <sicking>
it's generally not something i'm willing to implement for anything new

[14:36:25.0000] <Hixie>
i agree

[14:36:44.0000] <Hixie>
i'm just saying if they're _not_ live then we shouldn't return them from an attribute

[14:36:50.0000] <Hixie>
it's just wacked

[14:37:11.0000] <sicking>
Hixie: you appear to be in minority in that opinion

[14:37:15.0000] <Hixie>
e.g. it forces the UA to remember what it last returned

[14:37:38.0000] <sicking>
yup, we've already added that ability into our WebIDL code

[14:37:54.0000] <Hixie>
we chaned a bunch of APIs specifically to avoid doing this, i'm kinda surprised this is even controversial

[14:37:58.0000] <sicking>
with a specific hook for throwing away that cache

[14:37:59.0000] <Hixie>
changed

[14:38:19.0000] <sicking>
Hixie: which APIs were changed? from what to what?

[14:39:09.0000] <Hixie>
e.g. this is why PropertyNodeList has .getValues() rather than .values

[14:39:43.0000] <sicking>
where is that used?

[14:39:59.0000] <sicking>
is this in the microdata API?

[14:40:04.0000] <Hixie>
yeah

[14:40:08.0000] <sicking>
ah

[14:40:30.0000] <sicking>
i don't know that api well enough to comment

[14:41:20.0000] <sicking>
Generally I think property vs. function should be a choise based on what the specific thing is/does. Not what type it returns

[14:42:33.0000] <Hixie>
to answer your earlier question, the problems are things like setting an expando on the array, and then it being there until magically one day it isn't because the user happened to tweak the settings

[14:42:59.0000] <Hixie>
or getting the length of the array, and iterating over it in a timeout loop, and half-way-through it changes length

[14:43:04.0000] <sicking>
Hixie: if it's frozen that won't happen

[14:43:12.0000] <Hixie>
being frozen is even worse

[14:43:17.0000] <Hixie>
since then you can't even _set_ expandos

[14:43:28.0000] <Hixie>
which is unlike everything on the Web

[14:43:36.0000] <sicking>
not being able to set them seems like a good thing if you can't reliably get them

[14:43:43.0000] <Hixie>
a method gives you a much clearer affordance that what you're getting is a new array

[14:43:50.0000] <Hixie>
then you can set them and get them and it all works

[14:43:59.0000] <Hixie>
i honestly am quite baffled by wanting a non-method here

[14:44:03.0000] <sicking>
i'm not going to get into the frozen vs. non-frozen debate though. I'll leave that to people with more JS experience than me

[14:44:18.0000] <Hixie>
why would you want a property to return a (non-live) array?

[14:44:47.0000] <sicking>
it seems like a property of the navigator. Not a function of it

[14:45:11.0000] <sicking>
Hixie: would you have made navigator.language a function too?

[14:45:12.0000] <Hixie>
can you think of any attribute that returns a non-live array where suddenly the attribute returns a new array?

[14:45:21.0000] <Hixie>
no, that returns a primitive value

[14:45:43.0000] <sicking>
Hixie: right, like I said, i think property vs. function should not be a decision based on return-type

[14:45:55.0000] <sicking>
that answers the why

[14:46:01.0000] <sicking>
but i agree it's an opinion

[14:46:26.0000] <Hixie>
i'm just trying to be consistent with the platform here

[14:46:42.0000] <sicking>
i think the property way will be more consistent with where things are heading

[14:46:46.0000] <Hixie>
(my _opinion_ is that all of this sucks either way :-) )

[14:46:56.0000] <Hixie>
things shouldn't be heading to something different than they already are

[14:47:05.0000] <Hixie>
because then we'll have an even more multiple-personality platform

[14:47:20.0000] <Hixie>
it's the Web's biggest failing as a platform

[14:47:31.0000] <Hixie>
that every API is idosyncratic in its own way

[14:47:42.0000] <sicking>
this is the old "stick with old suckyness and be consistent vs. create something better even though it breaks with old" debate

[14:48:06.0000] <sicking>
generally i come down on the "create something better" side

[14:48:18.0000] <sicking>
but it's a judgement call

[14:48:54.0000] <sicking>
however I'll note that we get a lot of complaints that "the DOM" isn't very consistent with other JS APIs

[14:48:58.0000] <Hixie>
i'm very strongly on the "be consistent" side, because if it's inconsistent, it isn't better regardless.

[14:49:22.0000] <Hixie>
yes, our APIs being inconsistent is what i'm saying

[14:50:10.0000] <Hixie>
anyway. i don't want to be the one to first introduce an attribute that returns a non-live same-object array

[14:50:20.0000] <Hixie>
imho that's a mistake, and one we've intentionally avoided before

[14:56:28.0000] <sicking>
Hixie: at least IDBObjectStore.indexNames IDBDatabase.objectStoreNames navigator.gamepads and HTMLInputElement.files will all be doing that soon

[14:56:45.0000] <sicking>
Hixie: if you don't want to go first then that's fine, but please remove getLanguages in the meantime

[14:57:09.0000] <Hixie>
wait, what is happening to HTMLInputElement.files?

[14:57:42.0000] <sicking>
we're working on removing the FileList class (since it's icky and live) and just having .files return an Array

[14:57:57.0000] <sicking>
it's unclear if .files should be readonly or not still, but either way it'll return an Array

[14:58:01.0000] <Hixie>
sicking: (what's with this "my way or remove it" thing you've got going recently? can't we instead try to come up with designs we both think are good?)

[14:58:51.0000] <Hixie>
hm, yeah, HTMLInputElement.files does have this behaviour already (not with an array, but the problem is the same either way)

[14:59:41.0000] <sicking>
Hixie: I just don't want features in the spec drafts that implementors don't like. I know you don't think what's in the draft matters and what's in the implementations is the only thing that does. However there's a lot of work trying to convince other people that what's in the spec draft is just a proposal and not to be taken as written in stone

[15:00:26.0000] <Hixie>
sicking: "sicking doesn't like" isn't the same as "implementors don't like". i haven't heard any other implementors, including those who wanted this feature, say that getLanguages() is bad.

[15:00:46.0000] <Hixie>
but in any case you have provided compelling evidence that this is already a pattern, so i'm happy to change to an attribute

[15:00:57.0000] <sicking>
Hixie: which other implementors have asked for this feature

[15:01:25.0000] <sicking>
Hixie: it isn't a pattern yet since WebIDL doesn't really support it. But we've spent a lot of time debating how to make WebIDL support this

[15:01:31.0000] <Hixie>
arv commented that he wanted it for chrome at some point

[15:01:46.0000] <Hixie>
nah, HTMLInputElement.files already does this

[15:01:50.0000] <sicking>
Hixie: and has arv said that he prefers getLanguages() over .languages?

[15:01:56.0000] <Hixie>
he hasn't said either way

[15:02:12.0000] <sicking>
so the only feedback you have is that it's not good? I.e. the one from me?

[15:02:30.0000] <arv>
getFoo is an anti pattern. I prefer using real getters

[15:02:30.0000] <Hixie>
i have feedback that one person didn't like the way it was specced, yes

[15:02:37.0000] <Hixie>
two now :-)

[15:03:05.0000] <arv>
I was in favor of exposing the capability

[15:03:19.0000] <Hixie>
right

[15:04:11.0000] <sicking>
Hixie: generally, whatever you put in the spec gets a lot of momentum, no matter if you've put it in there as a proposal and have no feedback from the people that asked for the feature or not

[15:04:26.0000] <Hixie>
i wish

[15:04:31.0000] <Hixie>
but sure

[15:04:36.0000] <Hixie>
i'm not saying the spec should have bad stuff in it

[15:04:47.0000] <Hixie>
i'm just saying that one person saying it's bad doesn't mean it's bad :-)

[15:05:07.0000] <Hixie>
and moreover, that rather than removing it, we should just find a better solution

[15:05:12.0000] <Hixie>
and then replace it

[15:05:38.0000] <sicking>
Hixie: sure, add navigator.languages which returns sequence<DOMString>

[15:06:08.0000] <sicking>
Hixie: i'm happy to replace with something better. But until we agree on what's better I prefer to not have bad features in there

[15:06:38.0000] <Hixie>
you can't have an attribute return sequence<>s. But they can return DOMString[], which is what i'm speccing.

[15:07:23.0000] <Hixie>
sicking: i think it's worth at least trying to find common ground for a few minutes before demanding that something be removed, is all i'm saying. "hey, you just did what i wanted, except not quite, so immediately remove it!" is how it comes across.

[15:07:25.0000] <sicking>
Hixie: cool. Hopefully DOMString[] will go away when we fix the webidl bug. But using it until then seems fine

[15:08:19.0000] <sicking>
Hixie: i tried to find common ground first. Which is why I pushed for .languages. But since we couldn't reach agreement I asked that it was removed until there was agreement

[15:08:39.0000] <Hixie>
"i want X" "i want Y" "remove Y" is not trying to find common ground.

[15:09:01.0000] <Hixie>
"i want X" "i want Y" "how about Z" would be trying to find common ground.

[15:09:16.0000] <sicking>
what would the Z be here?

[15:09:26.0000] <Hixie>
i've no idea

[15:09:34.0000] <Hixie>
that's the "finding" part of "finding common ground"

[15:09:51.0000] <Hixie>
"i want X" "i want Y because R" "R is false because D" "ok let's do X" would be good too

[15:10:20.0000] <Hixie>
instead of "i want X" "i want Y because R" "remove Y" "but R!" "R is false because D" "ok let's do X" which is what we did above

[15:10:37.0000] <Hixie>
anyway

[15:10:48.0000] <sicking>
a lot of this stuff comes down to opinions

[15:11:00.0000] <sicking>
you felt that getFoo was an ok pattern, i did not

[15:11:20.0000] <Hixie>
sure, but the opinions aren't what mattered in the end

[15:12:23.0000] <sicking>
no?

[15:12:56.0000] <Hixie>
you showed me a feature that already existed that had the semantics you wanted, disproving my argument regarding lack of precedent.

[15:13:50.0000] <sicking>
my strategy was always to do that. Which is why I asked it to be removed until there was precedence

[15:17:38.0000] <Hixie>
sicking: it felt more like "you're wrong, i'm right, i'd rather the spec not have this feature than have it be your way, and i'll just wait until i have more specs to point to rather than convince you now". but whatever.

[15:17:47.0000] <Hixie>
sicking: see new checkin, let me know if it's ok!

[15:22:40.0000] <sicking>
Hixie: I generally don't know how to convince you given that a lot API design is not about X being provaly better than Y

[15:23:15.0000] <sicking>
Hixie: I still don't know how to convince you that .foo is better than .getFoo()

[15:24:04.0000] <sicking>
especially since that's not always the case. I would have done .innerHTML as getInnerHTML() or as serializeToHTML()

[15:25:09.0000] <Hixie>
i wouldn't have done innerHTML at all :-)

[15:25:50.0000] <Hixie>
IMHO attributes are good when you can treat them like variables - cheap to access, unsurprising to reuse

[15:26:12.0000] <Hixie>
methods are good when you want the author to consider the call expensive, or when you want them to cache the result and operate on that

[15:26:17.0000] <sicking>
Hixie: another reason that it's hard to convince you in this case is that we disagree on the "do the best we can for new APIs vs. do the most consistent we can for new APIs" issue

[15:26:26.0000] <Hixie>
yeah

[15:26:36.0000] <Hixie>
well

[15:26:50.0000] <Hixie>
more to the point, i disagree with that characterisation of the issue

[15:27:01.0000] <sicking>
Hixie: sounds like we do agree on the attributes vs. function thing

[15:27:27.0000] <Hixie>
i think it's "do the best we can for new APIs vs keep changing patterns so authors have to know what year the API was invented to know how to use it"

[15:28:09.0000] <Hixie>
or more to the point, i don't think it's "best" vs something, it's "consistent" vs "using new idioms"

[15:28:22.0000] <Hixie>
and it's not at all clear to me that using new idioms is automatically better than being consistent

[15:28:37.0000] <Hixie>
consistency is a huge part of what makes an API usable

[15:28:49.0000] <sicking>
Hixie: Another way to put it would be "be consistent with popular JS libraries so that the DOM doesn't look like an alien spaceship vs. be self-consistent within the DOM so that people can find their way around the spaceship"

[15:29:14.0000] <sicking>
I think it's a judgement call

[15:29:45.0000] <sicking>
but ultimately I think that I'm more agressive about abandoning existing conventions in the DOM

[15:30:22.0000] <Hixie>
well, the problem is that "popuplar JS libraries" change every other year

[15:30:41.0000] <Hixie>
we can't target today's libraries or yesterday's or tomorrow's. We have to design an API for decades.

[15:31:11.0000] <Domenic_>
i like the spaceship analogy

[15:31:27.0000] <Hixie>
(also, i'd argue it's the libraries that are the aliens!)

[15:32:05.0000] <sicking>
Hixie: I've made the same judgement call in the past btw. FileReader was designed to be consistent with XHR. On direct request from authors

[15:32:21.0000] <sicking>
Hixie: (same judgement call as you made I mean)

[15:32:39.0000] <Hixie>
well, you have to be consistent with the right thing :-P

[15:32:41.0000] <Hixie>
XHR is a disaster

[15:32:58.0000] <sicking>
Hixie: many people argue that the DOM is a disaster

[15:33:06.0000] <Hixie>
including me, sure

[15:33:32.0000] <Hixie>
i wouldn't be consistent with .getElementById() over introducing something like .find(), e.g.

[15:33:49.0000] <Hixie>
but i probably would argue for .getElementsByClassName() rather than .searchClasses()

[15:33:57.0000] <sicking>
Hixie: patch looks good

[15:34:50.0000] <sicking>
Hixie: like I said, most if this is judgement calls. Which is why I don't know how to convince you

[15:35:05.0000] <Hixie>
nor i you

[15:36:21.0000] <Hixie>
it's probably a case-by-case basis thing

[15:36:36.0000] <sicking>
yup

[15:36:43.0000] <sicking>
Hixie: re bug 23988

[15:36:53.0000] <sicking>
Hixie: you need some asynchronousness there

[15:37:06.0000] <Hixie>
hm, good point

[15:37:07.0000] <sicking>
Hixie: the iterator should probably be a Stream<File>

[15:37:09.0000] <zewt>
"authors" will request everything, since there are a lot of authors, heh

[15:37:17.0000] <Hixie>
Stream<> ?

[15:37:28.0000] <zewt>
this author sure doesn't care much for "consistent with xhr" as a design goal

[15:37:39.0000] <sicking>
I.e. a Stream where all the returned objects are Files

[15:37:47.0000] <sicking>
Hixie: though...

[15:37:58.0000] <zewt>
(i copy and paste code every time i use xhr since I can never remember it, heh)

[15:38:04.0000] <Hixie>
i figured Stream<File> was a Stream which returned Files, but what's a Stream?

[15:38:30.0000] <sicking>
Hixie: basically an asynchronous iterator

[15:38:37.0000] <Hixie>
is that documented anywhere?

[15:39:02.0000] <Hixie>
i figured async stuff should use promises

[15:39:03.0000] <sicking>
there's a spec. I don't know how finished it is yet. Nor if it handles objects yet

[15:39:20.0000] <Hixie>
do you have a url to this spec? WebIDL doesn't mention it...

[15:39:23.0000] <sicking>
Hixie: Domenic_ is editing. He can fill you in on its status

[15:39:30.0000] <Domenic_>
https://github.com/whatwg/streams. I would not call it finished (and definitely not polished.) But it does handle objects.

[15:40:21.0000] <Hixie>
aha, i was wondering when that spec would become something i had to read :-)

[15:41:08.0000] <Domenic_>
Here is a version that is more readable but omits the crunchy details because I haven't ported them over yet. Click "this one" at https://github.com/whatwg/streams/issues/62

[15:41:15.0000] <Domenic_>
(the actual URL is too long for my IRC client)

[15:41:19.0000] <zewt>
(the only thing I saw about streams was a bug that said "this is replacing blob, so ...", which is silly so I stopped paying attention)

[15:41:45.0000] <sicking>
zewt: it's not replacing Blob

[15:41:51.0000] <zewt>
i know that :P

[15:41:54.0000] <sicking>
similar but separate use cases

[15:42:02.0000] <sicking>
ah

[15:42:21.0000] <zewt>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23975 i'm sure there's a context I'm not aware of, all I saw was "stream will replace most roles of Blob"

[15:43:40.0000] <zewt>
guess I should look at the actual pre-spec so I at least know what it's about

[15:46:15.0000] <Hixie>
i don't really understand either of these specs

[15:46:40.0000] <Hixie>
Domenic_: so i have a method that returns an object that represents an asynchronously iterated list of File objects

[15:47:00.0000] <Hixie>
Domenic_: var list = input.getFileIterator()

[15:47:28.0000] <Hixie>
Domenic_: how do i use "file", if it's one of these thingies, to pass each File to a method process(file) ?

[15:47:31.0000] <Hixie>
er

[15:47:35.0000] <Hixie>
how do i use "list"...

[15:48:37.0000] <zewt>
<- can't read the examples

[15:49:55.0000] <Hixie>
i'd like something like   function iterate (list) { if (list.done) return; process(list.value); list.moveNext(iterate); }; list.moveNext(iterate);

[15:50:10.0000] <zewt>
promises are the least intuitive api i've seen on the platform in a long time

[15:50:12.0000] <Hixie>
though ideally without hte duplicate list.moveNext()

[15:50:17.0000] <Hixie>
even better would be:

[15:50:30.0000] <Hixie>
list.readAll(process);

[15:50:51.0000] <Hixie>
(where readAll's callback gives you controls to pause the iteration)

[15:50:58.0000] <Hixie>
(e.g. return false to stop)

[15:54:29.0000] <Domenic_>
Hixie: search for streamToConsole in the anolis-ified version.

[15:55:05.0000] <Hixie>
yeah that seemed pretty long, i was assuming there was some briefer alternative

[15:55:14.0000] <Domenic_>
yeah.

[15:55:20.0000] <Domenic_>
i am not sure streams are perfect for this use case

[15:55:23.0000] <Hixie>
k

[15:56:03.0000] <Domenic_>
the benefit would be that you could integrate with a larger ecosystem of streams, e.g. pipe to a transform stream that transforms files into decoded video data, then another transform that muxes them, then pipe them into a video tag.

[15:56:18.0000] <Domenic_>
but for naive usage something like an iterator of promises would get you closer to your original code

[15:57:30.0000] <Domenic_>
an iterator of promises would give `function iterate(list) { var entry = list.next(); if (entry.done) { return; } entry.value.then(v => { process(v); iterate(list); }); }`

[15:57:46.0000] <Domenic_>
anyway got to run

[15:57:47.0000] <Hixie>
shouldn't streams be simple enough that you could use them here?

[15:58:02.0000] <Domenic_>
they are meant as a pretty low-level primitive

[15:58:07.0000] <Domenic_>
for e.g. raw file or socket I/O

[15:58:31.0000] <Hixie>
low-level doesn't mean they can't be simple...


2014-02-05
[16:07:08.0000] <Hixie>
so many ways to design an iterator

[22:14:24.0000] <tyoshino__>
zewt: sorry. i didn't mean replacing all the use cases of Blob. Use cases where stream fits, stream would play the role instead of Blob. Like Domenic_'s examples, we could have elements to work as WritableStream and pipe to it from some source

[22:14:53.0000] <tyoshino__>
elements, video, audio, etc.

[22:39:09.0000] <tyoshino__>
Corrected on the bug

[01:20:56.0000] <annevk>
https://twitter.com/hober/status/430907579061915648 hahaha

[01:24:59.0000] <yoav>
zcorpan: I'm adding the essence of http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2795 as a Blink layout test, if you're cool with it

[01:25:54.0000] <zcorpan>
yoav: no need to ask for permission to write tests :-)

[01:26:04.0000] <zcorpan>
or to steal my tests

[01:54:40.0000] <yoav>
zcorpan: awesome!

[02:39:20.0000] <annevk>
Hixie: I agree with you with respect to frozen

[02:39:30.0000] <annevk>
Hixie: frozen has the wrong semantic, you want immutable

[02:39:47.0000] <annevk>
Hixie: the inability to mutate the array, but the ability to add expandos

[02:40:00.0000] <annevk>
Hixie: of course that doesn't really exist

[02:42:38.0000] <jgraham>
If only there were people working on the platform who could make it exist

[02:46:11.0000] <darobin>
jgraham++ # funny

[02:52:08.0000] <annevk>
I think sicking's idea is that by using frozen, we can more easily switch to immutable later. Whereas if they are not frozen, we cannot switch to immutable later.

[03:13:09.0000] <MikeSmith>
I guess I shouldn't admit I don't know what frozen is

[03:23:24.0000] <SteveF>
MikeSmith: its a movie http://en.wikipedia.org/wiki/Frozen_%282013_film%29

[03:28:59.0000] <jgraham>
Hmm, nice to know that shadow-DOM is stilll a trainwreck

[03:30:15.0000] <MikeSmith>
/me wonders if smaug e-mailed blink-dev yet

[04:01:58.0000] <zcorpan>
https://github.com/bholley/web-platform-tests/compare/submission;bholley isn't actually a pull request yet, is it? i can't find it listed in w3c/web-platform-tests PRs

[04:11:08.0000] <jgraham>
zcorpan: No

[04:13:16.0000] <jgraham>
I think this is the wrong hour to ask bholley if he meant it to be

[04:23:06.0000] <zcorpan>
i commented in the bug so he'll see it at the right hour i hope :-)

[04:36:07.0000] <jgraham>
Look like interesting tests, but I  want to make comments ;)

[04:45:04.0000] <zcorpan>
hsivonen: MikeSmith: does v.nu not support <foreignObject>?

[04:46:25.0000] <MikeSmith>
zcorpan: it's meant to

[04:48:21.0000] <MikeSmith>
zcorpan: test document?

[04:50:52.0000] <zcorpan>
MikeSmith: <!DOCTYPE html><title>x</title><svg><foreignobject></foreignobject></svg>

[04:52:23.0000] <zcorpan>
foreignObject has a weird content model per spec. is it intentional that any element in the svg namespace is allowed?

[04:56:02.0000] <MikeSmith>
foreignObject should only allow <math>, <html>, <body>, or flow content

[04:56:46.0000] <MikeSmith>
zcorpan: <!DOCTYPE html><title>x</title><svg><switch><foreignobject></foreignobject></switch></svg>

[04:58:01.0000] <MikeSmith>
is foreignobject now allowed outside of switch?

[04:58:06.0000] <zcorpan>
switch huh

[04:58:19.0000] <zcorpan>
MikeSmith: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#svg-0 seems to ban <html> and <body>

[04:58:30.0000] <MikeSmith>
/me looks

[04:58:56.0000] <MikeSmith>
oh

[04:59:26.0000] <zcorpan>
MikeSmith: and http://www.w3.org/TR/SVG11/struct.html#SVGElement seems to allow foreignObject as child of svg

[04:59:27.0000] <MikeSmith>
I wonder if that was added later. Anyway, I can fix that

[04:59:46.0000] <MikeSmith>
zcorpan: hmm yeah

[04:59:59.0000] <zcorpan>
maybe first edition didn't

[05:00:13.0000] <MikeSmith>
yeah I think probably so

[05:00:28.0000] <MikeSmith>
anyway I can fix that too

[05:00:34.0000] <zcorpan>
cool

[05:01:48.0000] <MikeSmith>
"This appendix summarizes the changes from the previous publication of SVG 1.1 Second Edition"

[05:02:24.0000] <MikeSmith>
hey geniuses how about listing the changes sinces actual 1.1

[05:03:22.0000] <MikeSmith>
http://www.w3.org/TR/2010/WD-SVG11-20100622/changes.html#WholeDocument

[05:03:43.0000] <MikeSmith>
zcorpan: have to go all the way back to that WD to figure out what they actually changed

[05:03:53.0000] <MikeSmith>
"The content models of container elements were changed to allow ‘foreignObject’ children. Previously, according to the DTD, ‘foreignObject’ was allowed only as the child of a ‘switch’."

[05:04:18.0000] <MikeSmith>
whatever "container elements" is

[05:05:01.0000] <zcorpan>
http://www.w3.org/TR/SVG11/intro.html#TermContainerElement

[05:05:37.0000] <MikeSmith>
ok

[05:06:15.0000] <zcorpan>
is there a plan with svg2?

[05:06:17.0000] <zcorpan>
/me finds http://www.w3.org/TR/SVG2/changes.html#extend

[05:29:55.0000] <hsivonen>
MikeSmith: surely we don't want to allow <body> in <foreignObject> in text/html

[05:30:09.0000] <hsivonen>
zcorpan: but yeah, v.nu is supposed to support <foreignObject>

[05:30:37.0000] <hsivonen>
zcorpan: I might have made stuff up here, because the specs didn't make sense.

[05:30:44.0000] <hsivonen>
zcorpan: it's been a while. can't recall

[05:31:16.0000] <zcorpan>
hsivonen: appears like it does but follows and old svg 1.1 spec and made up content model for html or something (probably predates html spec's rules)

[05:32:08.0000] <hsivonen>
zcorpan: quite possible

[05:39:01.0000] <MikeSmith>
hsivonen: working on it now

[05:39:23.0000] <MikeSmith>
we inherited that schema from the SVG WG

[05:39:51.0000] <MikeSmith>
and I am finding now that it in some ways it doesn't actually even follow the original SVG 1.1 spec

[05:40:12.0000] <MikeSmith>
for example, it says SVG.glyph.content = SVG.Description.class*, SVG.glyph.class*

[05:40:59.0000] <MikeSmith>
so glyph if it had "description" elements, would need to have them before any other elements

[05:41:17.0000] <MikeSmith>
but the 1.1 spec says the child elements can be in any order

[05:53:34.0000] <annevk>
/me wonders what https://twitter.com/RobbertAtWork/status/429271270052872193 was about

[05:53:38.0000] <annevk>
/me finds it to work fine

[06:05:26.0000] <MikeSmith>
zcorpan: foreignObject changes fixed and pushed to http://validator.w3.org/nu/

[06:05:29.0000] <MikeSmith>
thanks

[06:05:33.0000] <MikeSmith>
http://validator.w3.org/nu/?doc=data:text/html;charset=utf-8,<!DOCTYPE html><title>x</title><svg><foreignobject height width></foreignobject></svg>

[06:07:51.0000] <MikeSmith>
we really need some SVG-in-HTML test documents for wpt conformance-checkers/

[06:08:09.0000] <zcorpan>
MikeSmith: <svg><foreignobject width height><svg></svg></foreignobject></svg> "Error: Element svg is missing a required instance of child element foreignObject. " ?

[06:08:37.0000] <MikeSmith>
hmm

[06:08:42.0000] <MikeSmith>
um dunno

[06:08:48.0000] <MikeSmith>
/me looks back at schema

[06:09:04.0000] <zcorpan>
/me -> train

[06:12:02.0000] <MikeSmith>
whoops forgot the "*" (zero or more)

[06:14:21.0000] <MikeSmith>
see what I said before about having test documents..

[06:35:32.0000] <zcorpan>
MikeSmith: how do i enable XML parser?

[06:36:01.0000] <zcorpan>
file upload maybe

[06:36:22.0000] <MikeSmith>
zcorpan: mime type

[06:36:30.0000] <MikeSmith>
or .xhtml file upload

[06:37:00.0000] <MikeSmith>
zcorpan: data: URL

[06:37:45.0000] <MikeSmith>
zcorpan: fixed the "Error: Element svg is missing a required instance of child  element foreignObject. "

[06:37:56.0000] <MikeSmith>
and pushed it

[06:38:01.0000] <zcorpan>
MikeSmith: i meant from textarea input

[06:38:02.0000] <zcorpan>
nice

[06:39:14.0000] <MikeSmith>
zcorpan: yeah can't do with for textarea any more at http://validator.w3.org/nu/

[06:40:03.0000] <MikeSmith>
experimenting with dropping most of those XML-related options

[06:40:46.0000] <MikeSmith>
or really pretty much all the options except the "Show x" options

[06:42:45.0000] <annevk>
Reasons for Fetch to know about Document: referrer, Origin?, tasks, CSP

[06:43:27.0000] <annevk>
Reasons for Fetch to not know about Document: CSP (if allowed to be manipulated through script), only works in specification land

[06:43:44.0000] <gsnedders>
I read that as French, not Fetch.

[06:47:09.0000] <annevk>
JakeA: you around?

[06:47:21.0000] <JakeA>
Yep!

[06:47:46.0000] <annevk>
JakeA: do you remember when, from the perspective of the service worker, you want to do URL rewrites?

[06:48:27.0000] <annevk>
JakeA: i.e. the request is for /a, and you reply with /b and don't want a redirect to happen and want URLs in /b to be resolved with /a as base?

[06:49:07.0000] <JakeA>
If you respondWith anything, the browser sees it as a response to the request url

[06:49:31.0000] <annevk>
JakeA: it seems to me we could always do a conceptual redirect if there's a mismatch between request URL and response URL and if you don't want that redirect you'd rewrite the response URL to match the request URL

[06:50:19.0000] <annevk>
JakeA: so if the request was for /a and you have a response from /b and you don't want the browser to redirect you'd do response.url = "/a" first

[06:51:17.0000] <annevk>
/me is trying to define response's url

[06:51:37.0000] <JakeA>
I'm trying to remember why that wasn't ok…

[06:51:45.0000] <JakeA>
If it is ok, then it's the right thing to do

[06:52:37.0000] <JakeA>
Does it reveal redirect info in a way we don't want?

[06:53:41.0000] <annevk>
No, that would be impossible. I guess the weird case is the navigate/popup/child scenario as redirecting there could affect the service worker in use

[06:54:06.0000] <annevk>
At which point you probably would not want to use the given response?

[06:55:59.0000] <JakeA>
/me is flip flopping

[06:56:26.0000] <JakeA>
Maybe rewrite is the best thing to do, as it most closely resembles the serverside model

[06:56:53.0000] <JakeA>
"For the request url, here is your response"

[07:08:58.0000] <annevk>
JakeA: okay, rewrite meaning the page would never know about it?

[07:09:15.0000] <annevk>
JakeA: e.g. XHR's responseURL (to be added, hence these questions) would return "/a"?

[07:10:20.0000] <annevk>
JakeA: the main problem there is that sometimes you do want redirect to be followed, e.g. for a CSS resource it seems unlikely you ever wanted to rewrite it

[07:10:48.0000] <annevk>
JakeA: because then all subresources might end up having the wrong URL fetched

[07:12:45.0000] <JakeA>
annevk: yeah, I feel like we've swapped sides on this. I argued for this because of CSS on the last day of the meeting, Jonas talked me round.

[07:12:56.0000] <JakeA>
annevk: But yeah, it makes sense for CSS, but not so much for pages

[07:13:24.0000] <JakeA>
annevk: Eg, if I was delivering /static/page-shell.html in place of /

[07:14:07.0000] <annevk>
JakeA: even in that case if /static/page-shell.html had <img src=logo.png> you could be in trouble

[07:14:27.0000] <annevk>
JakeA: though I agree you do not want a redirect there, that'd look ugly

[07:14:55.0000] <annevk>
JakeA: so you should probably have absolute-path-relative URLs

[07:15:20.0000] <annevk>
http://url.spec.whatwg.org/#concept-absolute-path-relative-url

[07:15:26.0000] <JakeA>
Agreed

[07:15:53.0000] <annevk>
zcorpan: encoding="text/html" reads so weird

[07:16:16.0000] <zcorpan>
annevk: yeah

[07:16:18.0000] <JakeA>
Could be a problem if the shell was served from a CDN, but I don't know how common that would be

[07:16:32.0000] <annevk>
JakeA: mkay, rewrite-always makes sense if we advice people to use absolute-path-relative URLs

[07:16:52.0000] <annevk>
JakeA: do we allow CORS filtered responses as top-level?

[07:16:58.0000] <annevk>
JakeA: I guess we might as well

[07:16:59.0000] <JakeA>
Also, what happens if the reponseUrl isn't set, is the request url substituted in?

[07:17:29.0000] <JakeA>
annevk: Yeah, I don't see why not. Doesn't seem insecure.

[07:17:34.0000] <annevk>
JakeA: so Fetch will determine the response's URL solely based on the last request URL

[07:17:55.0000] <JakeA>
Guess it's only opaque ones that cause issues

[07:18:40.0000] <annevk>
JakeA: so I think within the context of responseWith() the url property of the Response object is not relevant

[07:19:06.0000] <annevk>
JakeA: Response.url is only relevant for fetch() and maybe caches

[07:19:21.0000] <JakeA>
Yeah, although it's used for CSP right?

[07:19:52.0000] <JakeA>
(btw, I'm really jetlagged so sorry for slow thinking)

[07:20:00.0000] <annevk>
Nah, this is great

[07:21:03.0000] <annevk>
Given Document -> Fetch -> Service Worker -> Network, CSP should only govern the last arrow I suppose

[07:21:28.0000] <annevk>
So if the service worker gets a Response object or creates one itself it's already trusted at that point from the CSP perspective

[07:22:46.0000] <JakeA>
Doesn't that circumvent a lot of the CSP stuff? Eg, I lose the ability to say "scripts can come from domain x, css can come from domain y"

[07:23:56.0000] <MikeSmith>
hsivonen: yeah dunno why the vnu schema had allowed body in there before. anyway it's fixed now

[07:24:49.0000] <JakeA>
Although if an attacker gets to create a serviceworker on the origin, the castle's walls are completely down anyway

[07:32:33.0000] <annevk>
JakeA: the moment you put a service worker in the middle you can no longer really control that I think

[07:33:11.0000] <annevk>
JakeA: e.g. the service worker could take the bytes of a response from domain y and serve it up as a fresh response to a fetch for a script

[07:33:59.0000] <JakeA>
annevk: Only if it non-opaue, but if the script is an attacker's script, they can control that

[07:34:02.0000] <JakeA>
yeah, makes sense

[07:34:09.0000] <JakeA>
opaque*

[07:34:37.0000] <annevk>
JakeA: we could make service workers CSP-opt-in maybe

[07:34:50.0000] <annevk>
JakeA: given how big of a foot gun they might be to you

[07:34:58.0000] <annevk>
JakeA: but that kinda sucks

[07:35:28.0000] <JakeA>
annevk: Setting content-type was a huge barrier to entry for appcache

[07:36:12.0000] <JakeA>
Requiring serviceworkers to be on the same origin feels good enough

[07:36:43.0000] <annevk>
But yeah, service workers make the whole fetch purpose/context discussion that CSP is having kind of irrelevant

[07:37:54.0000] <annevk>
I'll write an email to the CSP guys I guess. I wish I was a bit further today. Such a slow day

[07:38:15.0000] <JakeA>
I've managed about 3 paragraphs of a blog post

[09:06:49.0000] <dglazkov>
good mornign, Whatwg!

[09:25:40.0000] <Ms2ger>
Hey dglazkov!

[09:25:59.0000] <Ms2ger>
If you want to ship all this stuff soon, there'd better be a test suite ;)

[09:39:33.0000] <jgraham>
(and a spec :p)

[09:50:54.0000] <m4nu>
Anyone know what the best way to discover the final URL is after a bunch of redirects have been followed by XMLHttpRequest? Is there a solution to this problem yet?

[09:57:11.0000] <hober>
annevk: re: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2798 i'm surprised to see .children on DocumentFragment in Gecko

[09:57:50.0000] <hober>
annevk: i would have expected you to write http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2799

[09:57:59.0000] <hober>
annevk: (which works in both webkit and gecko)

[09:58:25.0000] <Ms2ger>
It's on ParentNode?

[09:59:14.0000] <annevk>
hober: http://dom.spec.whatwg.org/#parentnode

[09:59:37.0000] <annevk>
hober: however, I always forget what the non-children one is called, didn't even realize I was operating on a DocumentFragment :-)

[10:00:09.0000] <annevk>
hober: please don't tell my employer I don't know what I'm doing

[10:01:29.0000] <hober>
heh

[10:02:02.0000] <hober>
i must have missed it when HTMLCollection things got added to DocumentFragment

[10:02:22.0000] <hober>
do we really want to have more HTMLCollections?

[10:02:45.0000] <Ms2ger>
It's the same HTMLCollection as before

[10:08:44.0000] <hsivonen>
MikeSmith: thanks

[10:10:07.0000] <hober>
tracked down the relevant bug, thanks

[10:46:03.0000] <TabAtkins>
zcorpan: It's not really *intentional* to allow CSS escapes in srcset, but doing anything less would require defining my own private tokenizer.

[10:46:28.0000] <TabAtkins>
Or defining a full parsing algorithm, which seems like overkill.

[10:47:54.0000] <Hixie>
i wonder what i was smoking when i wrote "This specification does not define any processing for elements in SVG fragments that are not in the HTML namespace; they are considered neither conforming nor non-conforming from the perspective of this specification."

[10:48:00.0000] <Hixie>
that's completely meaningless

[10:50:46.0000] <jgraham>
It depends if SVG fragments is well defined

[10:51:53.0000] <jgraham>
If an SVG fragment was, say, a subtree consisting of all nodes with a common ancestor that is the SVG element in the SVG namespace, it would seeem to make sense

[10:53:17.0000] <Hixie>
jgraham: it adds no conformance statements, despite sounding like it does, and it doesn't point the reader to any conformance statements, and it doesn't give the implications of conformance statements, nor give best practices...

[10:53:29.0000] <Hixie>
in other news, anyone know where MathML defines its content models? MikeSmith maybe?

[10:53:48.0000] <MikeSmith>
yeah

[10:54:17.0000] <MikeSmith>
but if you're asking about annotation-xml they don't define it

[10:54:21.0000] <MikeSmith>
you have to :)

[10:54:27.0000] <Hixie>
i was asking about <mi>, mainly

[10:54:34.0000] <MikeSmith>
ok

[10:55:14.0000] <Hixie>
(the idea being to see how they phrased that, so i could remain somewhat consistent)

[10:55:21.0000] <Hixie>
(for a-xml)

[10:55:52.0000] <MikeSmith>
ah cool

[10:55:56.0000] <MikeSmith>
man you fast

[10:55:57.0000] <MikeSmith>
http://www.w3.org/TR/MathML3/chapter3.html#presm.mi

[10:56:10.0000] <jgraham>
Hixie: The first part seems like a statement of fact

[10:56:11.0000] <MikeSmith>
is where I'm looking myself now

[10:56:31.0000] <MikeSmith>
... and they don't say it there, I see

[10:56:36.0000] <Hixie>
jgraham: it's definitely trying to be a statement of fact, but not a useful one, is what i'm saying :_)

[10:56:46.0000] <MikeSmith>
I guess you probably already looked there. I'll dig further

[10:56:58.0000] <Hixie>
MikeSmith: i was expecting them to have a DTD or something

[10:57:13.0000] <MikeSmith>
they have a RelaxNG schema

[10:58:20.0000] <MikeSmith>
but I think there's prose somewhere in teh spec

[10:58:25.0000] <MikeSmith>
I hope so at least

[10:59:08.0000] <Hixie>
did we just make up the fact that <mi> can contain HTML phrasing elements from whole cloth?

[10:59:28.0000] <MikeSmith>
um um

[10:59:44.0000] <MikeSmith>
I seem to remember I filed an HTML spec bug about it a long time agao

[11:00:00.0000] <MikeSmith>
and I also asked the Math WG bout it

[11:00:04.0000] <Hixie>
we list mi, mo, mn, ms, and mtext as "MathML text integration points"

[11:00:09.0000] <Hixie>
which means they can receive HTML nodes

[11:00:26.0000] <Hixie>
but i can't find anything that actually says the content model for those allows anything but text, mglyph, and the other mathml text stuff

[11:00:29.0000] <MikeSmith>
yeah I remember we actually discseed it

[11:03:21.0000] <Hixie>
bummer, my blame records aren't precached for the edits around there

[11:03:33.0000] <Hixie>
/me sets up some more blame caches

[11:05:32.0000] <MikeSmith>
Hixie: I raised https://www.w3.org/Bugs/Public/show_bug.cgi?id=9859 back when, but you wontfixed it

[11:05:36.0000] <MikeSmith>
/me keeps looking

[11:07:07.0000] <Hixie>
that bug is a great example of why i don't actually mark a bug WONTFIX when i wontfix it, but leave it open for people to argue back for a while :-)

[11:07:14.0000] <Hixie>
don't any more, i mean

[11:08:18.0000] <Hixie>
i'm not really sure i understand that bug though

[11:08:40.0000] <MikeSmith>
that bug kinda diverged from teh description

[11:08:47.0000] <MikeSmith>
Hixie: http://www.w3.org/TR/MathML3/chapter6.html#world-int-combine-other is what you want I think

[11:09:08.0000] <MikeSmith>
well hmm not much there either

[11:09:26.0000] <Hixie>
yeah i think my wontfix is for the original description, and it makes sense relative to that (you don't have to ban things that aren't allowed in the content model, by definition)

[11:10:05.0000] <MikeSmith>
yeah

[11:11:15.0000] <MikeSmith>
"When designing a compound document format in which MathML is included in a larger document type, the designer may extend the content model of MathML to allow additional elements." is the main relevant part I guess

[11:12:04.0000] <MikeSmith>
before it said, "In the lax schema profile, elements from non-MathML namespaces are allowed in token elements, but not in other elements"

[11:12:23.0000] <MikeSmith>
where "token elements" = mi, mo, mn, ms, and mtext

[11:14:21.0000] <Hixie>
aha! excellent, that's exactly what we need

[11:14:33.0000] <MikeSmith>
cool

[11:15:12.0000] <MikeSmith>
(sorry it took me so long to find it -- it's been a while since we had those discussions)

[11:15:27.0000] <Hixie>
oh no worries, i couldn't find it either!

[11:17:14.0000] <MikeSmith>
yeah actually I remember not how painful it was to try to find anything in that spec

[11:19:00.0000] <Hixie>
do we have to say anything about annotation-xml's encoding attribute? or just say that if it contains html, it must be flow content?

[11:25:44.0000] <Hixie>
MikeSmith: ok, check what i just checked in, reopen the bug if it's no good. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24526

[11:26:04.0000] <Hixie>
heycam|away: ping

[11:26:19.0000] <MikeSmith>
/me looks at commmit

[11:28:52.0000] <MikeSmith>
Hixie: Thanks -- looks great as-is to me. I don't think we need to say anything explicit in the HTML spec about annotation-xml's encoding attribute but I'll ping David Carlisle to confirm.

[11:29:01.0000] <Hixie>
k.

[11:29:02.0000] <Hixie>
thanks!

[11:29:06.0000] <MikeSmith>
cheers

[11:29:29.0000] <MikeSmith>
/me goes off to fiddle this into the validator code

[13:02:56.0000] <heycam>
Hixie, pong

[13:03:00.0000] <heycam>
and good morning

[13:03:41.0000] <Hixie>
hey

[13:03:49.0000] <Hixie>
you following the Window/Location security thing?

[13:04:45.0000] <heycam>
I have seen the comments come in but not read them

[13:04:51.0000] <heycam>
is it time for me to read them now? :)

[13:06:10.0000] <Hixie>
well, probably not

[13:06:11.0000] <Hixie>
but

[13:06:18.0000] <Hixie>
i was thinking about how to do this

[13:06:35.0000] <Hixie>
and it is probably going to end up being best partly done in WebIDL

[13:06:46.0000] <Hixie>
so i wanted to give you a heads-up

[13:06:56.0000] <bholley>
Hixie: who is the abarth/bholley/travis equivalent at WebKit?

[13:07:10.0000] <Hixie>
bholley: no idea, but hober would know

[13:07:15.0000] <bholley>
hober: ^

[13:07:38.0000] <Hixie>
abarth and eseidel might know also

[13:08:00.0000] <heycam>
Hixie, ok well let me know when it's figured out what bits should be on the Web IDL side

[13:08:25.0000] <Hixie>
heycam: basically cross-origin Window and Location objects are gonna behave very differently than same-origin Window and Location objects. so i was thinking maybe the way to spec this is to have two actual separate interfaces, a Window and a WindowCrossOrigin, where the second has some sort of [CrossOriginObjectFor=Window] attribute or some such

[13:08:31.0000] <abarth>
bholley: what expertise exactly are you looking for?

[13:08:40.0000] <abarth>
JS bindings?

[13:08:56.0000] <Hixie>
heycam: and then webidl would take care of killing the prototype, making things act frozen, returning the right Function objects, etc

[13:08:58.0000] <bholley>
abarth: I'm just wondering who we want to get feedback from on the Window/Location stuff

[13:09:10.0000] <Hixie>
heycam: anyway, i'll let you know when it's ready, we're still trying to get people on board at this point

[13:09:17.0000] <heycam>
Hixie, ok

[13:09:18.0000] <abarth>
bholley: I'd ask sam wenig

[13:09:35.0000] <abarth>
he might be a manager now and direct you to someone else

[13:09:40.0000] <bholley>
abarth: do you have his email?

[13:09:42.0000] <abarth>
but he's a good person to start with

[13:09:45.0000] <abarth>
yeah

[13:10:27.0000] <abarth>
http://trac.webkit.org/search?q=sam%40webkit.org&noquickjump=1&changeset=on&wiki=on

[13:11:01.0000] <bholley>
abarth: great, thanks

[13:53:14.0000] <hober>
he's also in #whatwg

[13:53:19.0000] <hober>
/me summons weinig

[14:17:03.0000] <Hixie>
bholley: re your mail, as per my comments with heycam earlier, i think most of the details will hopefully end up specced in WebIDL, and HTML will just have to have its 900+ mentions of Window and Location updated to return the right objects

[14:17:10.0000] <Hixie>
heycam: in the meantime, https://etherpad.mozilla.org/html5-cross-origin-objects is the current thinking

[14:17:26.0000] <bholley>
Hixie: sgtm

[14:17:46.0000] <bholley>
Hixie: I forgot to CC heycam - did you forward, or should I?

[14:18:05.0000] <Hixie>
feel free to

[14:18:16.0000] <heycam>
thx

[15:01:25.0000] <jgraham>
bholley: Did you mean your push to web-platform-tests to be a pull request? Because you didn't create one

[15:01:46.0000] <bholley>
jgraham: no, I'm waiting until we sort out the spec

[15:02:11.0000] <bholley>
jgraham: I wasn't sure about the branch naming convention - did I make it look like I wanted it to be a PR?

[15:02:47.0000] <jgraham>
bholley: I think you put submissions/ in the name, which kind of suggests a PR

[15:03:13.0000] <bholley>
jgraham: yeah, ok. I was just quickly following the instructions for adding tests

[15:03:18.0000] <bholley>
but makes sense

[15:03:33.0000] <jgraham>
BTW since we are using critic for review it is better to create a PR early and add an issue stating that you are waiting for spec feedback

[15:03:56.0000] <jgraham>
You don't need a mozilla-style complete patch before submitting for review

[15:04:52.0000] <jgraham>
(that doesn't mean *right now* is best of course, just that push early, push often is a good rule)

[15:09:05.0000] <bholley>
ok, I'll look into that after the initial round of feedback

[15:38:26.0000] <zewt>
things pages should not be able to do: prevent pasting text into forms.

[15:38:40.0000] <TabAtkins>
Hostile password entry?

[15:39:25.0000] <zewt>
pages that want to coerce you into typing your email address or password or whatever twice

[15:40:11.0000] <Hixie>
i always just bring up the dom inspector and nuke the relevant attributes

[15:40:30.0000] <TabAtkins>
Yeah, me too.

[15:40:58.0000] <zewt>
my normal (non-development) browser is firefox, and its inspector is too cumbersome to bother with

[15:41:27.0000] <TabAtkins>
I have a solution to that.

[15:41:52.0000] <zewt>
the main reason I don't switch to chrome for general usage is lack of vertical tabs

[15:42:00.0000] <TabAtkins>
Ah, kk.

[15:42:05.0000] <TabAtkins>
Yeah, you're screwed then.

[15:42:39.0000] <zewt>
which I really, seriously don't understand--horizontal tabs are pretty unusable

[15:43:01.0000] <TabAtkins>
If you use a lot of tabs.

[15:43:06.0000] <zewt>
if you have a list of horizontal things, you stack them vertically

[15:43:07.0000] <TabAtkins>
Switch to only using a few.

[15:43:29.0000] <zewt>
i'm not going to reengineer how I use browsers to suit chrome's crippled ui, heh

[15:43:50.0000] <TabAtkins>
LifeHacks®

[15:44:56.0000] <JosephSilber>
When a parent

[15:45:21.0000] <JosephSilber>
When a parent's height depends on it's children, you can't use percentage heights for the children.

[15:45:36.0000] <TabAtkins>
Yes.

[15:45:39.0000] <zewt>
i tend to switch to chrome when doing a search, because switching browsers is faster than using firefox's dog-slow address bar search, heh

[15:45:46.0000] <JosephSilber>
What if the parent's height isn't fixed, but it doesn't depend on its children.

[15:45:58.0000] <TabAtkins>
Example?

[15:46:09.0000] <JosephSilber>
an absolutely positioned parent

[15:46:25.0000] <JosephSilber>
all corners set to 0

[15:46:51.0000] <Hixie>
wtf is a vertical tab in this context?

[15:47:17.0000] <zewt>
browser tab bar with tabs vertical, not horizontal

[15:47:52.0000] <TabAtkins>
JosephSilber: Then it's fixed for those purposes.

[15:48:16.0000] <TabAtkins>
The relevant term is "definite" versus "indefinite": http://dev.w3.org/csswg/css-sizing/#definite

[15:48:39.0000] <TabAtkins>
Percentage width/heights can resolve against definite parent width/heights.

[15:49:59.0000] <TabAtkins>
In terms of abspos, though, if you set top and bottom, then height is *implicitly* set as well.  Same with left/right/width - setting any two to a definite value implicitly sets the third to a definite value as well.

[15:50:06.0000] <JosephSilber>
TabAtkins: see this? stretches in ff, but not in chrome: http://codepen.io/anon/pen/qItFp

[15:51:13.0000] <TabAtkins>
JosephSilber: Is this related to what we were just discussing?

[15:51:46.0000] <TabAtkins>
I see an abspos, but no percentages on its children.

[15:51:57.0000] <JosephSilber>
TabAtkins: It is. I've solved it for my project using min-height. This is just me trying to understand what's supposed to happen according to the spec

[15:52:19.0000] <JosephSilber>
.box has a min-height: 100%

[15:52:40.0000] <TabAtkins>
This case is too busy for me to figure out.  It needs to be reduced pretty badly.

[15:52:43.0000] <JosephSilber>
...I meant that I solved it with min-content...

[15:53:06.0000] <JosephSilber>
ok. I'll try stripping stuff out and report back

[15:55:47.0000] <zewt>
(https://zewt.org/~glenn/tabs.png <- that)

[15:56:28.0000] <zewt>
(usually with 30-40 tabs, of course, not 9)

[15:59:14.0000] <JosephSilber>
TabAtkins: ok. so I got it down to this: http://codepen.io/anon/pen/qItFp


2014-02-06
[16:01:45.0000] <JosephSilber>
ff respects the percentage height, while chrome does not

[16:03:28.0000] <TabAtkins>
Ah, this is due to a disagreement over whether "stretched" things are definite or not when the container is definite in the cross axis.

[16:08:18.0000] <zewt>
(oh yeah, the other big killer for chrome, the broken address bar autocompletion)

[16:09:09.0000] <TabAtkins>
JosephSilber: Firefox is correct - this was updated in the spec a while ago, and WK/Blink havent' updated yet: http://dev.w3.org/csswg/css-flexbox/#algo-stretch

[16:11:46.0000] <JosephSilber>
Is min-content considered a definite size?

[16:12:40.0000] <TabAtkins>
Nope.

[16:13:01.0000] <TabAtkins>
Just read the definition: http://dev.w3.org/csswg/css-sizing/#definite

[16:13:40.0000] <JosephSilber>
I thought so, but then why does it work? I guess it's considered an intrinsic height, but not a definite.

[16:14:05.0000] <TabAtkins>
I don't understand the question.  Why does what work?

[16:28:43.0000] <Hixie>
zewt: oh ok

[16:28:48.0000] <Hixie>
zewt: weird

[16:30:26.0000] <zewt>
i guess

[16:30:35.0000] <zewt>
works well for me anyway :)

[16:32:46.0000] <Hixie>
i run out of room for my tabs going horizontally, nevermind vertically :-)

[16:40:02.0000] <zewt>
well the whole point is i can fit several times as many tabs vertically than horizontally

[21:54:02.0000] <Domenic_>
I want to start a conversation about adding GZIP and/or .zip file APIs to the web platform. What mailing list would people recommend? I'm thinking public-webapps?

[21:54:50.0000] <Domenic_>
Or whatwg@whatwg, perhaps.

[22:08:57.0000] <hendry>
Domenic_: talk to marcosc about zip files :-)

[22:17:21.0000] <Hixie>
Domenic_: anne was working on a zip: scheme or something for a bit

[22:21:21.0000] <Domenic_>
Hixie: yeah, but from what I remember he gave up on it.

[23:19:40.0000] <zcorpan>
Hixie: that svg paragraph, iirc it was added after people asking whether <svg xmlns:lol="wat"><lol:metadata such="wow"/> was valid in html

[03:03:40.0000] <zcorpan>
jgraham: Ms2ger: what do i need to do to run http://web-platform.test:8000/html/dom/interfaces.html ?

[03:03:53.0000] <Ms2ger>
Oh, right

[03:04:01.0000] <Ms2ger>
git submodules are broken

[03:04:24.0000] <Ms2ger>
Go into wpt/resources and git submodule update, or something

[03:06:58.0000] <jgraham>
Yeah, in theory git submodule update --recursive should work

[03:07:08.0000] <jgraham>
But it doesn't seem to for some reason

[03:11:23.0000] <MikeSmith>
I don't have a problem getting wpt/resources to update

[03:11:34.0000] <MikeSmith>
it updates fine for me with git submodule update --recursive

[03:11:44.0000] <MikeSmith>
the problem I run into is for wpt/tools

[03:12:42.0000] <MikeSmith>
which I deal with by doing "mv ./tools tools-old; git submodule init; git submodule update"

[03:12:45.0000] <MikeSmith>
or something like that

[03:14:35.0000] <MikeSmith>
hmm or at least dirtiness for wpt/resources goes away after submodule update --recursive

[03:15:11.0000] <MikeSmith>
but I guess that doesn't mean it's necessarily pulling the latest from the resources repo

[03:15:29.0000] <MikeSmith>
question mark

[03:18:16.0000] <jgraham>
MikeSmith: It's resources/idlharness that's the problem (that might not be the right name)

[03:18:23.0000] <MikeSmith>
ah ok

[03:19:03.0000] <MikeSmith>
/me shuts up and tries pulling to see what happens

[03:20:09.0000] <Ms2ger>
MikeSmith, if you just follow the readme, you get an empty wpt/resources/webidl2

[03:20:59.0000] <MikeSmith>
oh, initially you mean?

[03:21:03.0000] <MikeSmith>
the very first time?

[03:21:38.0000] <MikeSmith>
so yeah I guess I remember having needed to do that

[03:21:44.0000] <zcorpan>
well... http://web-platform.test:8000/resources/WebIDLParser.js is still 404 for me

[03:22:05.0000] <webben>
I'm looking for prior art on how an application (a server in my case) should handle query strings like http://example.com?%atfoobar

[03:22:10.0000] <Ms2ger>
zcorpan, is webidl2 non-empty?

[03:22:26.0000] <webben>
note the "t" which makes %at not represent a percent-encoded code point

[03:22:38.0000] <zcorpan>
Ms2ger: it's empty

[03:23:07.0000] <webben>
as far as i can tell the url parsing algo at https://dvcs.w3.org/hg/url/raw-file/tip/Overview.html#parsing just would return me "http://example.com?%atfoobar" again

[03:24:02.0000] <Ms2ger>
Don't look at that

[03:24:12.0000] <Ms2ger>
The spec is at url.spec.whatwg.org

[03:24:16.0000] <webben>
I'm wondering if it's "correct" ("safe"?) error handling to treat such it equivalently to http://example.com?%25atfoobar

[03:24:30.0000] <webben>
Ms2ger: oooh. ty

[03:24:44.0000] <Ms2ger>
zcorpan, okay, I don't remember what the incantation is to get it updated

[03:26:22.0000] <webben>
hmm

[03:26:40.0000] <MikeSmith>
yeah I just tried a fresh resources/ submodule update from there and I get an empty webidl2 dir

[03:26:44.0000] <webben>
so looking at that, it's the same result, "http://example.com?%atfoobar", except it's a non-fatal parse error

[03:27:46.0000] <MikeSmith>
if I cd into resources/ and do git pull it fails because it's a detached branch

[03:28:09.0000] <webben>
so I guess from the perspective of a server it's not unreasonable to correct to http://example.com?%25atfoobar (?)

[03:29:00.0000] <webben>
oh actually

[03:29:10.0000] <webben>
maybe that's what the spec is saying to do

[03:30:03.0000] <webben>
mmm ... ok only in the case of the fragment not the query

[03:30:35.0000] <zcorpan>
webben: what do you mean from the perspective of a server? what are you trying to do?

[03:32:45.0000] <webben>
Third-parties are generating query strings like ?a=quux&foo=bar&somethingelse=%atfoobar to my server. I'd like to capture these URLs, pull out data from the query strings, and generally process the request.

[03:33:27.0000] <webben>
My server happens to be delegating parsing the query string to some Jetty code, which emits from its depths an InvalidArgumentException when it tries to percent-decode %at

[03:33:42.0000] <webben>
I'm just wondering what the least incorrect error handling could be

[03:34:17.0000] <webben>
(and whether jetty's behavior could be improved for that matter)

[03:34:52.0000] <webben>
(this deep exception is thrown from a call like httpRequest.getRequestParams() )

[03:35:24.0000] <MikeSmith>
zcorpan: it appears you have to cd to resources/ and then do a git init && git submodule update within there too and then the webidl2 directory will get populated. I don't know if that's that only way or the right way, but it does actually work at least. (And so I guess the --recursive flag to git submodule udpate doesn't really mean what it claims to mean)a

[03:35:59.0000] <webben>
so I'm wondering whether, for example, we should try to "correct" the url to http://example.com?a=quux&foo=bar&somethingelse=%25atfoobar before delegating to jetty

[03:37:31.0000] <zcorpan>
MikeSmith: not git submodule init ?

[03:37:34.0000] <webben>
zcorpan: Does this make any sense as a problem statement, at least?

[03:37:58.0000] <zcorpan>
webben: yes

[03:38:28.0000] <zcorpan>
webben: so either jetty could implement the url spec and not throw an exception

[03:39:02.0000] <zcorpan>
webben: or you could regexp fixup the url before handing it to jetty

[03:40:53.0000] <webben>
i wonder if jetty behavior were to change, how they should best signal a parse error without throwing an exception.

[03:41:04.0000] <MikeSmith>
zcorpan: yeah sorry I meant git submodule init (I should have just pasted it instead of retyping)

[03:49:29.0000] <jgraham>
MikeSmith: If the readme is wrong, maybe you could fix it?

[04:01:31.0000] <zcorpan>
ok now the tests run

[04:01:50.0000] <zcorpan>
i failed to recover from git init though

[04:03:23.0000] <jgraham>
Shouldn

[04:03:34.0000] <jgraham>
't git init on an existing repo be a noop

[04:03:35.0000] <jgraham>
?

[04:04:14.0000] <jgraham>
I guess it might not interact well with submodules, but if so that seems like a bug

[04:06:28.0000] <zcorpan>
it wasn't a noop for me when i ran it in resources/

[04:21:28.0000] <MikeSmith>
zcorpan: sorry :(

[04:21:46.0000] <MikeSmith>
jgraham: yeah I will update the readme

[07:25:31.0000] <Ms2ger>
Are he blink UseCounter results public?

[07:26:37.0000] <Ms2ger>
*the

[07:54:24.0000] <mathiasbynens>
Ms2ger: there’s http://www.chromestatus.com/metrics/css/animated but other than that, I don’t think so

[07:54:49.0000] <mathiasbynens>
i meant http://www.chromestatus.com/metrics/css/popularity

[07:54:54.0000] <Ms2ger>
I found some 0% claims in another thread, which made me happy :)

[08:03:08.0000] <SimonSapin>
annevk-cloud, hsivonen: Do you agree that CSS’s "environment encoding" is a legacy thing and we don’t want new formats or linking mechanisms to define it?

[08:33:48.0000] <gsnedders>
SimonSapin: Do we not just want it to be UTF-8 in any new case?

[08:34:17.0000] <SimonSapin>
gsnedders: That’s the idea. If not provided, the next fallback is UTF-8

[08:34:52.0000] <gsnedders>
SimonSapin: Well surely it doesn't matter if they define it or not, given the environment encoding will be UTF-8 :)

[08:35:07.0000] <SimonSapin>
Well :)

[08:35:22.0000] <SimonSapin>
This includes not having a charset attribute, for example

[09:07:13.0000] <dglazkov>
good morning, Whatwg!

[09:15:24.0000] <Ms2ger>
My dear dglazkov!

[10:48:32.0000] <jgraham>
MikeSmith: So git submodule update --init --recursive does what you might think that git submodule update --recursive would do

[10:56:45.0000] <Hixie>
foolip: wtf is MSE?

[10:58:23.0000] <jgraham>
Hixie: Media Source Extensions

[10:59:24.0000] <Ms2ger>
Is that ROT13(DRM)?

[10:59:29.0000] <Hixie>
what are those?

[10:59:45.0000] <jgraham>
https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

[10:59:57.0000] <jgraham>
No, this is for adaptive streaming using javascript

[11:00:56.0000] <Hixie>
(aw, another non-rfc-2119 spec)

[11:01:03.0000] <Hixie>
looks like a cool idea, i guess

[11:01:16.0000] <Hixie>
though seems like more effort than just having the browsers do it

[11:01:17.0000] <Hixie>
but ok

[11:01:46.0000] <Hixie>
any idea why they try to change TextTrack?

[11:11:41.0000] <annevk>
Hixie: to add SourceBuffer?

[11:11:51.0000] <annevk>
but I guess you could tell as much

[11:11:57.0000] <annevk>
/me goes back to doing useful stuff

[11:28:05.0000] <Hixie>
annevk: i mean, why do they make kind and language mutable

[11:29:25.0000] <Hixie>
falken: did the patch on https://www.w3.org/Bugs/Public/show_bug.cgi?id=20418 fix all our problems?

[11:30:07.0000] <Ms2ger>
Hixie, fyi, updates in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22118

[11:30:24.0000] <Hixie>
thanks

[11:30:52.0000] <Ms2ger>
Also, we might be able to drop document.all()

[11:31:06.0000] <Hixie>
yeah i saw that

[11:31:08.0000] <Hixie>
that's great!

[11:35:14.0000] <Hixie>
Ms2ger: more comments in that bug :-)

[11:35:33.0000] <Ms2ger>
\o/

[11:35:44.0000] <Hixie>
anyone want to make a call on https://www.w3.org/Bugs/Public/show_bug.cgi?id=24312 regarding what exactly i should spec?

[11:35:52.0000] <Hixie>
(<img> reloading when adopting)

[11:36:06.0000] <Ms2ger>
Aaaand I'm out :)

[11:37:00.0000] <annevk>
Hixie: hmm weird, I suppose language can change over time, dunno about kind

[11:37:15.0000] <Hixie>
languages of subtitles changing over time seems wildly crazy to me

[11:37:34.0000] <Hixie>
i'll be back later. gonna go get food.

[11:50:03.0000] <annevk>
SimonSapin: new formats or linking mechanisms should enforce utf-8 for themselves and subresources

[11:51:53.0000] <SimonSapin>
annevk: that’s different still. But I guess they can always do UTF-8 decoding themselves and parse the result like they would <style>

[11:52:19.0000] <annevk>
SimonSapin: yeah, you want some kind of override flag like the HTML parser has

[11:52:23.0000] <annevk>
SimonSapin: for these contexts

[11:53:32.0000] <SimonSapin>
annevk: I mean, parsing from code points is an existing hook, so CSS Syntax does not need to add a "UTF-8 only" hook for parsing from bytes

[12:14:14.0000] <Hixie>
annevk: does https://www.w3.org/Bugs/Public/show_bug.cgi?id=19505 look right? (the final proposal)

[12:28:18.0000] <annevk>
Hixie: yeah I think so

[12:28:38.0000] <annevk>
SimonSapin: you don't really want to have to decode / parse in some other spec when all you need is parse

[12:29:04.0000] <annevk>
SimonSapin: especially since it might lead implementers astray from doing the right thing

[12:32:35.0000] <Hixie>
annevk-cloud: k, i'm putting it in

[13:54:36.0000] <aleray>
hi, how can I prettyprint with html5lib python? I'm using lxml but this code does not output pretty html: http://dpaste.com/1589423/

[13:55:24.0000] <aleray>
not sure if I should serialize using lxml or if I should rather use the html5lib serializer

[14:27:30.0000] <TabAtkins>
I'd like an answer to that, too - I haven't investigated pretty-printing yet, but Bikeshed's output is *really* ugly. ^_^


2014-02-07
[18:12:05.0000] <falken>
Hixie: Thanks for the patch. I'm implementing it now and may have comments later.

[23:28:53.0000] <othermaciej>
at this point I can't tell whether w3cmemes is my fan club or is making fun of me

[23:46:55.0000] <annevk-cloud>
othermaciej: I would go with both

[23:47:19.0000] <annevk-cloud>
Looking forward to read up on that thread

[23:47:29.0000] <othermaciej>
oh man

[00:05:35.0000] <hsivonen>
what's a lone 'i' in attribute selectors? http://html5.org/tools/web-apps-tracker?from=8469&to=8470

[00:32:47.0000] <MikeSmith>
hsivonen: from those examples I'd guess case-insensitive

[00:33:06.0000] <MikeSmith>
but doesn't it match case-insensitively anyway?

[00:33:21.0000] <MikeSmith>
oh the attribute values

[00:35:37.0000] <MikeSmith>
me finds http://dev.w3.org/csswg/selectors4/#attribute-case

[00:48:25.0000] <hsivonen>
MikeSmith: ok. thanks. I learned something new about Selectors.

[00:48:43.0000] <MikeSmith>
me too

[00:48:48.0000] <MikeSmith>
must have been added recently

[00:48:54.0000] <MikeSmith>
it's onlyin the ED

[00:49:20.0000] <hsivonen>
in other news, I'm eager to see telemetry from Firefox 29 release and 30 release

[00:50:00.0000] <hsivonen>
people who do experimental science by following the health of people from birth to death must have awesome patience

[00:50:28.0000] <MikeSmith>
heh

[00:50:58.0000] <MikeSmith>
I would think that'd be some group of people doing the following of the other people

[00:51:07.0000] <MikeSmith>
and handing off the data

[00:51:11.0000] <MikeSmith>
but I get your point

[00:51:54.0000] <hsivonen>
MikeSmith: well, you need to have even more patience when knowing the experiment won't finish in your own lifetime

[00:52:27.0000] <hsivonen>
at least these Firefox releases will be out this year

[00:54:08.0000] <MikeSmith>
jgraham: so I'm testing a fresh wpt submodule checkout with plan to update the readme with "git submodule update --init --recursive" but I find now that no matter what flavor of submodule update I do, I end up with a resources/ subdir that only has the pywebsocket/ and wptserve/ and not the coverage/ etc. subdirs

[00:54:29.0000] <hsivonen>
Now I'm mainly hoping that management won't decide to add the charset menu to Firefox OS before telemetry from Fennec 30 is ready

[00:55:00.0000] <MikeSmith>
hsivonen: wait why are they thinking about that

[00:55:19.0000] <hsivonen>
MikeSmith: because CJK

[00:55:43.0000] <MikeSmith>
/me shakes head

[01:02:56.0000] <MikeSmith>
jgraham: nm what I just said (pilot error)

[01:08:31.0000] <zcorpan>
hsivonen: also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24005

[01:18:04.0000] <annevk>
To be fair to Google, Apple hasn't exactly been good at standardizing some of its inventions either, such as touch events.

[02:08:15.0000] <annevk>
zcorpan: I'm not sure how to fix that paragraph :/

[02:11:05.0000] <zcorpan>
annevk: say "the HTML standard"?

[02:11:17.0000] <annevk>
zcorpan: did you see my comment?

[02:11:55.0000] <zcorpan>
/me looks

[02:12:50.0000] <zcorpan>
annevk: if it's no longer a goal, just drop the whole paragraph?

[02:13:42.0000] <annevk>
But then some of the features coming from HTML would no longer be explained

[02:23:41.0000] <annevk>
http://lists.w3.org/Archives/Public/www-style/2014Feb/0242.html :/

[02:23:45.0000] <annevk>
There's a lot of those emails

[02:39:39.0000] <yoav>
zcorpan: Going over the Blink image loading code, I bumped into an old comment :https://github.com/yoavweiss/Blink/blob/master/Source/core/loader/ImageLoader.h#L61

[02:40:10.0000] <yoav>
I want to make sure I understand current behavior and cement it with tests before touching these parts

[02:41:03.0000] <yoav>
So, if I understand correctly, a load event must be fired for every time 'src' (and prob 'srcset' is set from JS, even if the selection algo came up with the same final image

[02:41:07.0000] <yoav>
is that correct?

[02:43:16.0000] <zcorpan>
yoav: interesting, that's different from what the spec says. see "change" in http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#dom-trees

[02:44:02.0000] <zcorpan>
and http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element "A user agent that obtains images immediately must also synchronously update the image data of an img element whenever that element has its src, srcset, or crossorigin attribute set, changed, or removed."

[02:44:58.0000] <yoav>
Hmm

[02:46:02.0000] <yoav>
So maybe I'm mis-reading the comment

[02:46:43.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2800

[02:46:56.0000] <zcorpan>
no i think you read it right

[02:48:27.0000] <yoav>
Firefox & Chrome show different results here...

[02:49:36.0000] <yoav>
IE fires the event twice as well

[02:50:31.0000] <zcorpan>
i happen to have old chrome 21 which fires the event once

[02:51:15.0000] <zcorpan>
firefox 27 fires it once

[02:52:02.0000] <yoav>
Firefox 26 fires it twice...

[02:52:48.0000] <yoav>
OK, so current behavior is firing it once (module IE)

[02:52:57.0000] <yoav>
s/module/modulo)

[02:53:35.0000] <yoav>
So the comment probably outlived the actual code behavior

[03:07:21.0000] <SteveF>
questions for MikeSmith: https://twitter.com/stevefaulkner/status/431738798314369024

[04:16:12.0000] <hsivonen>
for those at home who are wondering what Pasifika Nexus is, it looks like it's a Fiji-based think-tank.

[04:16:46.0000] <hsivonen>
how come there's not w3cmeme about this yet? www-style getting all the attention?

[04:23:06.0000] <Ms2ger>
Pasi-what?

[04:23:24.0000] <hsivonen>
Ms2ger: still not reading HTML WG administrative email, eh?

[04:23:31.0000] <Ms2ger>
No

[04:23:57.0000] <Ms2ger>
Still perfectly happy without that timesink :)

[04:24:39.0000] <Ms2ger>
r? https://critic.hoppipolla.co.uk/r/744

[05:06:22.0000] <annevk>
hsivonen: that list

[05:06:24.0000] <annevk>
o_O

[05:08:23.0000] <darobin>
since hsivonen seems to read it anyway, I wonder how much he'd charge to give me a summary every once in a while :)

[05:09:04.0000] <Ms2ger>
darobin, I can offer that service too

[05:09:26.0000] <Ms2ger>
I'll just set up a monthly cronjob to send you an email saying "Nothing interesting happened."

[05:18:37.0000] <zcorpan>
anyone object if i add webvtt stuff to HTML IDL tests?

[05:19:23.0000] <Ms2ger>
Not me

[05:24:06.0000] <zcorpan>
ok good

[05:29:06.0000] <darobin>
Ms2ger: I so saw that one coming :)

[05:46:32.0000] <smaug____>
good that the shadow dom encapsulation is being discussed again. Not that I'm optimistic that to lead any changes in the spec

[05:53:15.0000] <zcorpan>
Ms2ger: r? https://critic.hoppipolla.co.uk/showcommit?first=cb28b226&last=acab08eb&review=74

[06:06:19.0000] <jgraham>
Is someone trying to do something with critic and experiencing an error?

[06:27:45.0000] <Enzo90910>
Hi everyone. I am currently working on a JavaScript project in which in response to a user event, a Javascript loads data from local storage, works on it a bit, and then writes a new version in localStorage. My problem is that when a user has several tabs open on my site, data corruption happens because several threads are reading/writing the localStorage at the same time. My understanding is that it happens only on Ch

[06:27:46.0000] <Enzo90910>
because Chrome uses one event loop for each tab and doesn't use a storage mutex. I am currently investigating several possible solutions: implementing mutexes using localStorage (hard, maybe impossible), trying to leverage the "storage" event to implement transactions (hard), or switching to IndexedDB (not supported by Safari). Has anyone encountered such use cases yet and how do you suggest to solve it? Any input is

[06:27:47.0000] <Enzo90910>
appreciated.

[06:31:34.0000] <Ms2ger>
zcorpan: r+

[06:31:38.0000] <Ms2ger>
jgraham, no error

[06:32:52.0000] <Ms2ger>
zcorpan: (I didn't review carefully, but I assume you can c/p)

[06:34:41.0000] <jgraham>
Ms2ger: I am getting an error about git merge-base failing, but I'm not sure why

[06:34:48.0000] <Ms2ger>
Weird

[06:43:00.0000] <zewt>
i haven't even really tried indexeddb yet; far too unidiomatic compared to every other database system i've used...

[07:05:14.0000] <odinho>
I know idb, but never used for anything. :p

[07:28:10.0000] <Ms2ger>
odinho!

[07:40:35.0000] <Ms2ger>
http://www.theregister.co.uk/2014/02/07/opera_founder_its_all_gone_to_crap/

[07:48:50.0000] <zewt>
the words "unprofessional" and "childish" spring to mind

[08:31:16.0000] <smaug____>
how could we kill non-worker-sync XHR

[08:33:32.0000] <annevk>
smaug____: more warnings?

[08:33:40.0000] <annevk>
smaug____: sendBeacon?

[08:34:10.0000] <smaug____>
sendBeacon maybe, though I've seen plenty of non-beacon-like usage too

[08:35:07.0000] <smaug____>
but would need to get all the browser engines start warning

[08:35:15.0000] <smaug____>
and then just kill it next year or so

[08:35:58.0000] <smaug____>
2% is way too much

[08:36:17.0000] <smaug____>
that is what telemetry data seems to hint currently

[08:36:34.0000] <annevk>
JakeA: getting to your email now

[08:36:41.0000] <annevk>
JakeA: should've done this earlier :/

[08:36:53.0000] <annevk>
smaug____: ouch

[08:37:08.0000] <annevk>
smaug____: we cannot just kill it with 2%

[08:37:15.0000] <smaug____>
yeah

[08:37:37.0000] <smaug____>
web sites do silly things like start sync xhr on keydown and such

[08:38:27.0000] <smaug____>
right now we don't warn about sync xhr, I think

[08:39:25.0000] <JakeA>
annevk: I'm over the jet lag so I can think things

[08:39:42.0000] <JakeA>
Although I have a beer so the thinking is temporary

[08:45:31.0000] <annevk>
smaug____: we should warn, we should warn harder for showModalDialog

[08:46:03.0000] <annevk>
JakeA: depends, https://xkcd.com/323/ :p

[08:46:04.0000] <smaug____>
sync XHR is worse

[08:46:24.0000] <annevk>
dunno, nested event loops...

[08:47:02.0000] <smaug____>
well, in Gecko sync XHR uses nested event loop. And in all the browsers it means the UI of the website isn't responsive during the XHR processing

[08:47:14.0000] <annevk>
fair

[08:47:27.0000] <JakeA>
annevk: do we still get a lot of JS served without a js content type?

[08:48:11.0000] <annevk>
JakeA: JavaScript MIME types are not really a thing in browsers, although it seems developer consoles made them into some kind of thing which is odd

[08:49:50.0000] <Domenic_>
developer consoles?

[08:49:52.0000] <Domenic_>
how so?

[08:50:40.0000] <JakeA>
annevk: ahh ok, I was hoping a js content type wouldn't be a barrier to entry these days

[08:50:44.0000] <Domenic_>
re: sync XHR. I wonder if you could convince the jQuery core team to remove the ability to do it.

[08:51:06.0000] <annevk>
Domenic_: I think they complain if you don't specify a MIME type, even though you don't have to per spec

[08:51:29.0000] <annevk>
Domenic_: and then the list of MIME types developer tools support depends on who implemented the tool prolly

[08:51:37.0000] <smaug____>
Domenic_: yeah, I think we'd need to get all the script libraries stop using it

[08:51:43.0000] <smaug____>
that would be the first step

[08:53:55.0000] <annevk>
Well, best of luck!

[08:54:11.0000] <annevk>
smaug____: if you want me to add something to the specification I could do that I suppose, not sure where the best place would be

[08:55:47.0000] <Soraya_>
Enzo90910: n8dy84xuwt

[08:55:51.0000] <smaug____>
annevk: somewhere near open() I guess

[08:56:01.0000] <smaug____>
another thing to deprecate is mutation events

[08:56:44.0000] <Soraya_>
Hi guys ?

[08:58:09.0000] <smaug____>
hmm, mutation event usage has been going down

[09:04:04.0000] <Domenic_>
blink already killed several..

[09:04:47.0000] <smaug____>
well, no one has ever supported them all

[09:07:39.0000] <annevk>
smaug____: http://xhr.spec.whatwg.org/#sync-warning

[09:08:58.0000] <smaug____>
thanks

[09:09:35.0000] <smaug____>
annevk: I wonder if we should have a version of open without async param

[09:10:17.0000] <smaug____>
void open(ByteString method, [EnsureUTF16] DOMString url, [EnsureUTF16] DOMString? username = null, optional [EnsureUTF16] DOMString? password = null);

[09:11:11.0000] <annevk>
You cannot distinguish that from what we have now

[09:28:08.0000] <annevk>
Domenic_: any timeline for getting streams in browsers?

[09:28:40.0000] <annevk>
I sorta think we should have streams before we design a "replacement" for XMLHttpRequest

[09:29:40.0000] <Hixie>
annevk: i don't follow https://www.w3.org/Bugs/Public/show_bug.cgi?id=23810 - what's the story there?

[09:30:22.0000] <annevk>
Hixie: http://www.whatwg.org/specs/web-apps/current-work/#affected-by-a-base-url-change

[09:30:34.0000] <annevk>
Hixie: since I removed it, it's no longer in DOM

[09:31:11.0000] <Hixie>
annevk: why did you remove it?

[09:31:20.0000] <Hixie>
annevk: you just want me to move the relevant bits to HTML?

[09:31:28.0000] <Hixie>
annevk: is this part of dropping xml:base?

[09:31:32.0000] <annevk>
Hixie: seemed better to just inline it

[09:31:53.0000] <Hixie>
wasn't this in HTML originally?

[09:32:04.0000] <annevk>
Hixie: in HTML it can also be inlined, but yeah, given that xml:base will be gone the only thing that will change is the document base URL going forward

[09:32:19.0000] <annevk>
Hixie: yeah could be

[09:32:28.0000] <Hixie>
and DOM doesn't want to handle base URLs changing?

[09:32:46.0000] <annevk>
Hixie: it has "base URL change steps"

[09:32:55.0000] <annevk>
Hixie: I think that's all we need as a concept

[09:32:57.0000] <Hixie>
?

[09:33:00.0000] <Hixie>
i thought you just said it was removed

[09:33:02.0000] <Hixie>
/me is confoosed

[09:33:18.0000] <annevk>
Hixie: there's also "affected by a base URL change" which is kinda double

[09:33:23.0000] <annevk>
Hixie: that was removed

[09:33:56.0000] <Hixie>
ok so this is very confusing

[09:34:01.0000] <Hixie>
we originally just had one term

[09:34:08.0000] <Hixie>
then you took over that term and split it into two

[09:34:15.0000] <Hixie>
and now you've removed the first term, leaving only the second?

[09:34:20.0000] <annevk>
Are you sure?

[09:34:29.0000] <Hixie>
see r1970

[09:34:56.0000] <Hixie>
actually it dates from even before that

[09:35:36.0000] <Hixie>
r1820

[09:37:58.0000] <Hixie>
r6505 is when i converted to your terminology

[09:38:11.0000] <Hixie>
r1820 is when i added the base URL processing stuff

[09:38:33.0000] <annevk>
http://html5.org/tools/web-apps-tracker?from=1819&to=1820

[09:38:50.0000] <annevk>
oh http://html5.org/tools/web-apps-tracker?from=1820&to=1821

[09:38:56.0000] <Hixie>
sorry, r1821

[09:39:37.0000] <Hixie>
i think all i really need from DOM here is that when a node is adopted, its subtree is "affected by a base URL change"

[09:40:00.0000] <Hixie>
i don't really understand why we need the "base URL change steps" term

[09:40:06.0000] <Hixie>
but anyway

[09:40:26.0000] <Hixie>
you just want me to change "is affected by a base URL change" to "must cause the user agent to run the base URL change steps for that node"?

[09:40:33.0000] <annevk>
yeah

[09:40:35.0000] <annevk>
sorry :/

[09:40:55.0000] <annevk>
there might be some more churn here going forward because of custom elements and the xml:base stuff

[09:41:09.0000] <Hixie>
my bigger concern is over <img> adoption

[09:41:11.0000] <annevk>
I prefer change steps because that's consistent with copy steps and such

[09:41:24.0000] <Hixie>
i need a hook for <img> adoption that isn't the same as the hook for base URL changing

[09:41:42.0000] <annevk>
so we might actually start offering some kind of callback thing for adoption

[09:41:44.0000] <Hixie>
does DOM actually do anything with base URL changes?

[09:41:56.0000] <annevk>
no, it just notifies

[09:41:59.0000] <Hixie>
maybe the right thing here is for DOM to forget about base URL change notification, and just notify on adoption

[09:42:09.0000] <annevk>
yeah that actually makes sense

[09:42:11.0000] <Hixie>
and then i can make that notification cause the element to be "e base URL

[09:42:16.0000] <annevk>
that ties in with that callback thing before

[09:42:21.0000] <Hixie>
and then i can make that notification cause the element to be "affected by a base URL change" (even)

[09:42:29.0000] <annevk>
can you update the bug? I need to go

[09:42:32.0000] <Hixie>
sure

[09:42:34.0000] <Hixie>
thanks

[09:42:34.0000] <annevk>
thanks!

[09:42:39.0000] <annevk>
hah

[09:44:26.0000] <Ms2ger>
https://github.com/operasoftware/presto-testo

[09:57:00.0000] <Domenic_>
annevk-cloud: we're trying to move pretty fast on streams, but a timeline seems hard to nail down at this point. we do have buy-in now after convergence that should help get it in everywhere, and lots of specs want it, so those are all forces pushing things quickly.

[09:57:30.0000] <Hixie>
who's implementing?

[09:58:05.0000] <Ms2ger>
There's various vaguely positive noises, I think

[09:58:11.0000] <Domenic_>
there's interest from mozilla, blink, and microsoft

[09:58:48.0000] <Domenic_>
i think blink actually had a guy working on code; mozilla mostly wants it to support other of their specs like TCP socket

[10:11:45.0000] <MikeSmith>
blink already had an implementation of the webapps Streams API from last year

[10:11:51.0000] <MikeSmith>
Zach Kuznia did it

[10:12:18.0000] <MikeSmith>
partial implementation at least but most if what was there at the time

[10:12:48.0000] <MikeSmith>
but maybe that's largely been overcome by circumstances

[10:14:26.0000] <MikeSmith>
maybe tyoshino is on deck for implementing for where it's at now

[10:15:47.0000] <smaug____>
scott_gonzalez: ping

[10:16:50.0000] <smaug____>
Ms2ger: boo, I thought they released their engine source code

[10:17:08.0000] <Ms2ger>
Heh

[10:17:12.0000] <Ms2ger>
That'd have been interesting too

[10:17:23.0000] <smaug____>
/me still wants to know what kind of garbage/cycle collector they have

[10:18:24.0000] <Ms2ger>
I've heard claims that the gc was simple mark-and-sweep

[10:20:32.0000] <jgraham>
I think it's true — although perhaps others would disagree — that the Opera philosophy was to avoid overengineering where possible

[10:31:18.0000] <smaug____>
Ms2ger: but what about edges to and from C++ side?

[10:31:27.0000] <smaug____>
or maybe everything was GCed

[10:32:09.0000] <Ms2ger>
That seems somewhat plausible

[10:59:50.0000] <Ms2ger>
Yay, a new JAM season next week

[11:07:13.0000] <jgraham>
Isn't this more the time of year for marmalade?

[11:07:32.0000] <jgraham>
(I note that I did actually understand and it is indeed something to look forward to :)

[11:23:27.0000] <karlcow>
lady marmalade

[11:35:32.0000] <GPHemsley>
For your consideration: https://bugs.freedesktop.org/show_bug.cgi?id=41155

[11:36:08.0000] <GPHemsley>
(re MIME types, Google, WebP...)

[11:40:14.0000] <GPHemsley>
(also re registries, specs, intent...)

[12:35:35.0000] <Domenic_>
Report from a Real Web Developer sitting next to me at work: "I really enjoyed the Shadow DOM kerfluffle, as now I'm more aware of the technologies and actors involved, whereas before web components was all very abstract to me."

[12:47:39.0000] <othermaciej>
so kerfuffles have one positive side effect, I guess

[12:47:53.0000] <hober>
:/

[12:49:46.0000] <arunranga>
Hi #whatwg :) Would anyone weep for DOMError if we take it out of IndexedDB and File API (and others) as per https://www.w3.org/Bugs/Public/show_bug.cgi?id=21740#c11 ?

[12:50:30.0000] <alecf>
just replace with DOMException?

[12:50:32.0000] <Domenic_>
Kill it!1!1!!one kill it with fire!

[12:50:53.0000] <arunranga>
Yes, Domenic_, I think we know how you feel :)

[12:51:05.0000] <alecf>
if so SGTM

[12:51:10.0000] <Domenic_>
just making sure... :)

[12:51:34.0000] <arunranga>
alecf, yes, pretty much use DOMException, which becomes a first class citizen of WebIDL.

[12:53:53.0000] <alecf>
as long as it has the same/subset of attributes as DOMError (I can't figure out if the attributes line up) that sounds good to me

[12:55:25.0000] <arunranga>
alecf, snooping around in Chromium (and Fx) source, you find DOMError, so there'll have to be some code changes going forward, since I think Chrome returns one during an error event for IDB and File*

[12:55:41.0000] <alecf>
heh yes, I implemented DOMError in blink

[12:56:53.0000] <arunranga>
alecf, heh :) OK, so, unless others object (on the mailing list or here), I'll change the spec. I'll weep a bit for DOMError, but connecting to the Error object for stack and stuff outweighs my tears

[13:02:01.0000] <Ms2ger>
"Awaiting decision in WhatWG. May 2007."

[13:04:26.0000] <arunranga>
Along those same lines, does anyone care if we strip out FileList and just make it an Array, along the lines of https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 ?

[13:05:41.0000] <Domenic_>
/me stays quiet this time

[13:06:30.0000] <Ms2ger>
arunranga, please wait for that bug to be fixed

[13:06:48.0000] <arunranga>
Heh :)  We'll lose code of the sort files.item(0) (which was weird anyway) and we'll have to think carefully about adding to FileList.

[13:07:37.0000] <arunranga>
Ms2ger, are you talking about waiting on replacing FileList with Array, or waiting before we strip out DOMError?

[13:07:57.0000] <Ms2ger>
arunranga, FileList

[13:09:51.0000] <arunranga>
OK, that seems reasonable; what will break for sure is stuff like files.item(0) but I don't know how common that usage is. Also, extending FileList will be tricky (e.g. fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125).

[13:09:59.0000] <arunranga>
Ms2ger ^^

[13:10:34.0000] <Ms2ger>
I'm staying out of the specifics :)

[14:08:00.0000] <Hixie>
hsivonen: yt?

[14:08:54.0000] <Hixie>
/me wonders how to make progress on this registry thing

[14:45:38.0000] <Hixie>
abarth|gardener: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22731

[14:47:10.0000] <Hixie>
/me is months behind reading his bugmail, and just got to the closures mentioned in http://www.w3.org/2011/webappsec/minutes/webappsec-minutes-27-Aug-2013.html

[14:47:17.0000] <Hixie>
good times, good times.

[14:47:19.0000] <abarth|gardener>
Hixie: looking

[14:50:19.0000] <abarth|gardener>
Hixie: what is the security concern?

[14:50:27.0000] <abarth|gardener>
that two different strings decode to the same thing?

[15:16:20.0000] <TabAtkins>
annevk-cloud: Yo, I finally did like you wanted and just said that the data model for Selectors in an HTML document is just the DOM.

[15:17:15.0000] <TabAtkins>
http://dev.w3.org/csswg/selectors/#data-model

[15:20:48.0000] <Hixie>
abarth|gardener: not sure, hence asking you :-)

[15:28:11.0000] <scott_gonzalez>
smaug____: pong

[15:28:31.0000] <smaug____>
scott_gonzalez: I was going to ask about sync XHR and unload

[15:28:53.0000] <scott_gonzalez>
I figured :-)

[15:29:03.0000] <smaug____>
so , I think I'll add warning for the cases when we're not in unload/beforeunload/pagehide listeners

[15:29:11.0000] <scott_gonzalez>
I've been pushing to replace jQuery.ajax() with jQuery.xhr() and kill sync XHR requests.

[15:29:42.0000] <smaug____>
any other cases you think would be somewhat valid before we have sendBeacon

[15:30:25.0000] <scott_gonzalez>
I think that's the only case that comes up, but the whole jQuery team will be together next week in San Diego, so I can see if anyone else knows of other scenarios.

[15:31:05.0000] <smaug____>
k

[15:31:16.0000] <smaug____>
I'll probably push this change even before that

[15:31:23.0000] <smaug____>
I'm sure there will be tons of warnings

[15:31:32.0000] <smaug____>
I don't even know if google has fixed their docs

[15:32:54.0000] <scott_gonzalez>
Dave Methvin has already said he's going to file a jQuery ticket about the warning in anticipation of lots of duplicates as soon as a browser starts logging the warning.

[15:33:14.0000] <scott_gonzalez>
Anything a browser warns about, we get dozens of tickets for.

[15:33:24.0000] <smaug____>
good

[15:33:54.0000] <smaug____>
hmm, can I file blink bugs without a google account?

[15:38:39.0000] <TabAtkins>
Yeah, I think you can sign up for a chromium.org account without a google account.

[15:38:46.0000] <TabAtkins>
(I could be wrong - I had one given to me.)

[15:44:17.0000] <jamesr__>
i believe you need a google account to use chromium/blink's bug tracker

[15:45:00.0000] <smaug____>
anyone want to then file a blink bug to warn about use of sync XHR in main thread

[15:45:17.0000] <smaug____>
jamesr__: TabAtkins: similar to https://bugzilla.mozilla.org/show_bug.cgi?id=969671


2014-02-08
[16:14:28.0000] <smaug____>
ojan: do you have UseCounter data about sync XHR in main thread?

[16:43:22.0000] <jamesr__>
i don't see one in the code

[16:44:25.0000] <jamesr__>
it'd probably be useful to have ones for sync xhr outside of (unload|beforeunload) and for within those

[16:49:59.0000] <jamesr__>
smaug____: do you have telemetry data on showModalDialog() ?

[16:50:18.0000] <smaug____>
I think we don't have

[16:50:23.0000] <smaug____>
let me look

[16:51:16.0000] <smaug____>
jamesr__: don't see anything

[18:57:14.0000] <GPHemsley>
/me prefers kerfluffles.

[19:48:32.0000] <zewt>
that's illegal in several southern states

[20:50:20.0000] <tyoshino>
MikeSmith: yes. i'm the owner of streams work for blink, currently

[03:12:47.0000] <Ms2ger>
"FileReader-a-065-001.html"

[03:12:56.0000] <Ms2ger>
These file names are so useful

[03:15:52.0000] <annevk-cloud>
Microsoft?

[03:16:55.0000] <annevk-cloud>
"ShowModalDialog 0.006267935289" :-)

[03:21:08.0000] <Ms2ger>
annevk-cloud, almost, Opera :)

[05:22:21.0000] <jgraham>
Ms2ger: Compared to bug678456.html you mean? ;)

[06:06:20.0000] <Ms2ger>
jgraham, ssh

[15:04:13.0000] <rniwa>
hayato: yt?


2014-02-09
[07:45:51.0000] <GPHemsley>
This is really starting to get out of hand: https://bugs.freedesktop.org/show_bug.cgi?id=41155

[07:46:10.0000] <GPHemsley>
Chrome/Chromium/WebP dev comments welcome ^

[07:59:35.0000] <zewt_>
> The bit of the spec you quoted is very clear on the SHOULD - not MUST.

[07:59:35.0000] <zewt_>
I wrote that bit of spec. So consider it a MUST.

[07:59:41.0000] <zewt_>
moving well along...

[08:02:11.0000] <zewt>
help, I'm about to actually try bing :|

[08:02:52.0000] <zewt>
google becoming a constant aggravation with its (relatively) new habit of just ignoring search terms

[08:04:46.0000] <Ms2ger>
>.>

[08:46:23.0000] <Ms2ger>
Of course: https://bugzilla.mozilla.org/show_bug.cgi?id=924386#c19

[08:47:47.0000] <Ms2ger>
Fwiw, current Nightly doesn't support document.all(foo)

[09:16:01.0000] <gsnedders>
Oh dear. We're actually Googling for instructions as to how the aircon in CS lab works. Seeing if it can heat us up. :P

[09:16:31.0000] <jgraham>
gsnedders: You don't have any old P4s?

[09:17:18.0000] <gsnedders>
Nah, all Ivy Bridge i5s in here.

[09:18:14.0000] <jgraham>
Pretty sure you can dig something out from somewhere. Raid a professor

[09:18:23.0000] <jgraham>
's office for an SGI

[09:25:31.0000] <gsnedders>
All in another building we don't have access to. :(

[10:36:51.0000] <gsnedders>
(amusingly, core/standards/scripts/opjsunit/tests will also give away a fair bit about Carakan in comments :))

[10:37:07.0000] <gsnedders>
(Esp. around its bytecode and object representations)

[15:56:37.0000] <smaug____>
am I missing something. http://www.w3.org/TR/webmidi/ Latest editor's draft: points to web audio api :/


2014-02-10
[16:24:05.0000] <Domenic_>
yeah i had to dig around github to find that

[16:24:17.0000] <Domenic_>
http://webaudio.github.io/web-midi-api/

[19:27:54.0000] <crocket>
How do I test if a web browser supports filename* in Content-Disposition?

[23:17:58.0000] <Domenic_>
tyoshino: thanks so much for your careful review :). I have to go to sleep very soon, but am happy to reply in the morning.

[23:29:57.0000] <zcorpan>
looks like blink is on a killing spree

[00:05:32.0000] <abarth|gardener>
zcorpan: hopefully we'll get back to working on those features once we've fixed some of the other problems we've got

[00:06:39.0000] <zcorpan>
abarth|gardener: which features do you mean?

[00:06:57.0000] <abarth|gardener>
oh, maybe I misunderstood your comment above

[00:08:18.0000] <zcorpan>
i was referring to the flow of intent to remove of legacy things

[00:08:38.0000] <abarth>
ah, yes.  I don't think the Attr node stuff is coming back :)

[00:09:11.0000] <abarth>
Do you know what a notation Node is/was?

[00:09:21.0000] <abarth>
I read the spec for it, but it didn't really say anything

[00:10:25.0000] <zcorpan>
it's for representing an xml Notation, which i've forgotten what it's supposed to be used for

[00:11:17.0000] <zcorpan>
something that goes in the internal subset of the doctype

[00:11:23.0000] <abarth>
"A notation is a processing instruction that tells the parser what to do with information of a particular format (binary files, image files, sound files, database files etc.) by assigning an external application to process it."

[00:11:30.0000] <abarth>
<!NOTATION my_format SYSTEM "http://my_website.com/my_application.exe">

[00:11:32.0000] <abarth>
oh man

[00:11:36.0000] <abarth>
that sounds like a terrible idea

[00:11:41.0000] <abarth>
from http://pic.dhe.ibm.com/infocenter/rsysarch/v11/index.jsp?topic=%2Fcom.ibm.sa.xml.design.doc%2Ftopics%2Ft_Notation.html

[00:11:58.0000] <abarth>
please download this EXE to view this content o_O

[00:13:48.0000] <abarth>
zcorpan: I meant that we're removing things like CSS variables that we'll hopefully get back to working on at some point

[00:14:10.0000] <zcorpan>
abarth: ok, yep

[01:25:54.0000] <JakeA>
Anyone got stats on the content types <script src> is served with?

[01:26:07.0000] <JakeA>
Actually, *.js urls would be good enough

[02:07:49.0000] <annevk>
JakeA: should get someone of that company that employs you to look into that, I hear they're pretty good at it

[02:25:37.0000] <JakeA>
annevk: hah, actually, it was easier to use http://www.igvita.com/2013/06/20/http-archive-bigquery-web-performance-answers/

[02:26:35.0000] <annevk>
JakeA: oh cool

[02:26:49.0000] <annevk>
I know about http://webdevdata.org/ but that seems to be mostly HTML pages

[02:34:43.0000] <JakeA>
96.7% of *.js urls are served with application/x-javascript, text/javascript, or application/javascript

[02:34:55.0000] <JakeA>
(in the top 3000 sites)

[02:37:12.0000] <wilhelm_>
And the remaining? No content-type?

[02:37:32.0000] <wilhelm_>
text/plain? (c:

[02:42:22.0000] <JakeA>
Raw data https://docs.google.com/spreadsheet/ccc?key=0Am8BnxIvH5DudFV4dG82WEtveGY5RnJUNXdZNVNnSUE&usp=sharing

[02:42:37.0000] <JakeA>
the next most popular is no type, then text/html

[02:45:23.0000] <annevk>
JakeA: I rather not require something different for a service worker compared to a normal worker

[02:45:59.0000] <annevk>
JakeA: but we could I suppose, note that we still don't really have defined content-type parsing in an interoperable way

[02:46:13.0000] <annevk>
JakeA: e.g. HTTP says "Content-Type: text/html;" is invalid

[02:46:54.0000] <JakeA>
annevk: Yeah, I'm not set on requiring a content type for serviceworkers, but it's a possibility if there's a perceived security risk

[02:47:14.0000] <JakeA>
annevk: Oh, didn't know that

[03:08:50.0000] <annevk>
https://bugs.freedesktop.org/show_bug.cgi?id=41155#c18 o_O

[03:09:37.0000] <annevk>
If you've been maintaining a MIME type module for 10 years and have still not realized the way MIME types work (including the whole standards process) is broken, the problem is really with you...

[03:30:15.0000] <darobin>
"I wrote that bit of spec. So consider it a MUST."

[03:30:31.0000] <darobin>
I'd buy that on a sticker

[03:31:30.0000] <JakeA>
Haha

[03:35:16.0000] <charl>
lol, a bit lower down: "I see a disconnect between your insistance on rejecting a MIME type because it's not registered and your opinion that a "SHOULD" can become a "MUST" on a whim."

[03:35:23.0000] <charl>
indeed

[04:00:35.0000] <JakeA>
annevk: Btw, had a catchup with Alex, he's been speaking to http people, apparently having http-style matching in a serviceworker cache would be pretty trivial

[04:08:03.0000] <annevk-cloud>
Cool. Does feel somewhat dangerous as it's high-level, but hopefully it works out

[05:30:22.0000] <GPHemsley>
annevk, JakeA: I have defined an algorithm for parsing a MIME type in mimesniff: http://mimesniff.spec.whatwg.org/#parsing-a-mime-type

[05:32:09.0000] <GPHemsley>
It's somewhat hard to test whether it's implemented, though

[05:48:34.0000] <annevk>
GPHemsley: you can test it with <script type=> maybe to some extent

[05:48:42.0000] <annevk>
GPHemsley: whether CSS is applied is another good test

[05:48:52.0000] <annevk>
GPHemsley: might depend on the exact context for CSS loading

[05:49:02.0000] <GPHemsley>
ah, hmm, interesting ideas

[05:49:50.0000] <annevk>
oh, and whether CORS does a preflight or not

[05:50:05.0000] <annevk>
GPHemsley: http://fetch.spec.whatwg.org/#simple-header

[05:51:07.0000] <GPHemsley>
alright, I'll have a look at it at some point

[05:51:11.0000] <GPHemsley>
gotta run now, though

[06:30:40.0000] <espadrine>
Is document.activeElement going to be deprecated?

[06:30:42.0000] <espadrine>
cf https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475#c16

[06:49:14.0000] <annevk>
espadrine: looks like Ian is proposing that to make focus behavior for <dialog> sane

[06:49:47.0000] <annevk>
espadrine: he asked people to review his proposal and people haven't really been doing that yet I think

[07:29:31.0000] <zcorpan>
GPHemsley: canPlayType

[07:31:32.0000] <zcorpan>
GPHemsley: annevk: <script type> doesn't parse as mime type. http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#support-the-scripting-language

[07:33:20.0000] <Ms2ger>
Anyone else have gsoc project ideas for the w3c? We've got https://etherpad.mozilla.org/GBHx8UkC9k so far

[07:34:57.0000] <zcorpan>
dig into presto-testo

[07:36:56.0000] <jgraham>
It would have to be something with a significant element of coding though; something purely about moving/rewriting tests would probably not be a valid project

[08:17:39.0000] <annevk-cloud>
zcorpan: same for <style>?

[09:01:45.0000] <dglazkov>
good morning, Whatwg!

[09:16:34.0000] <jcgregorio>
good afternoon dglazkov!

[09:50:39.0000] <guzzlefry>
quick question, is <div>some text</div> valid HTML?

[09:50:54.0000] <guzzlefry>
Does that text need to be wrapped in anything?

[09:51:03.0000] <Ms2ger>
Is fine

[09:51:18.0000] <guzzlefry>
cool, thank you

[11:25:15.0000] <annevk>
Is it just me or is the new Twitter site really ugly?

[11:30:53.0000] <jgraham>
Has it only changed if you sign in?

[11:39:22.0000] <TabAtkins>
annevk: It's just change aversion.

[11:40:02.0000] <annevk>
TabAtkins: It just doesn't make sense that the navigation buttons are all the way on the left whereas most everything else is in a column in the center

[11:40:32.0000] <TabAtkins>
There's not all the way on the left for me.  On narrower monitors I suppose the width of the thing spans the screen?

[12:07:09.0000] <zcorpan>
annevk-cloud: it looks like the spec assumes a real mime type in <style type> but i would be surprised if browsers do that

[12:08:17.0000] <zcorpan>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2803

[13:09:14.0000] <Hixie>
annevk-cloud: i don't understand https://www.w3.org/Bugs/Public/show_bug.cgi?id=24599

[13:25:01.0000] <Hixie>
"Refused to display 'http://www.trustlogo.com/images/cot_bgf0.gif' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'."

[13:25:04.0000] <Hixie>
that's pretty funny.

[13:25:20.0000] <Hixie>
doesn't give me great faith in the image though

[13:41:35.0000] <GPHemsley>
Hmm... some interesting behavior with <style type>

[13:42:04.0000] <GPHemsley>
If there's a semicolon before "text/css" (or a number of other similar variants), it still works

[13:42:44.0000] <GPHemsley>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2804

[13:43:00.0000] <GPHemsley>
oh

[13:43:07.0000] <GPHemsley>
I guess it's just assuming empty MIME type

[13:43:14.0000] <GPHemsley>
I guess that makes sense

[13:50:28.0000] <Hixie>
still works where?

[13:55:02.0000] <GPHemsley>
Hixie: In Firefox, you mean?

[13:55:10.0000] <Hixie>
ah, in firefox

[13:55:15.0000] <Hixie>
doesn't in chrome

[13:55:20.0000] <GPHemsley>
interesting

[13:55:59.0000] <GPHemsley>
I think Firefox patterns closely to the "parse a MIME type" algorithm

[13:56:21.0000] <GPHemsley>
in part because I used Firefox primarily when writing it, but in part because it's the sane thing to do

[13:58:10.0000] <Hixie>
i don't think chrome parses a mime type at all for <style type>

[14:41:33.0000] <TabAtkins>
Yeah, wouldn't be surprised if we just do a literal text check.


2014-02-11
[00:01:20.0000] <annevk-cloud>
Literal check may be better there, btw

[00:01:36.0000] <annevk-cloud>
Especially if we do that for script

[00:39:15.0000] <zcorpan>
jgraham: not being able to use {{host}} etc in tests directly is a bit annoying. would it be possible to enable it with __dir__ or something?

[01:38:33.0000] <darobin>
annevk-cloud: do you know what the cases are, if any, in which it isn't possible to convert a string to punycode?

[01:38:50.0000] <darobin>
looking at it it would seem to happily munge anything

[01:40:54.0000] <darobin>
I ask because HTML says "Constraint validation: While the user interface is representing input that the user agent cannot convert to punycode, the control is suffering from bad input." (for email inputs)

[01:41:13.0000] <darobin>
but deniak has been having trouble writing a test for that :)

[01:47:32.0000] <Ms2ger>
So, when is an object element rendered as a replaced element?

[02:58:23.0000] <jgraham>
zcorpan: Yeah. Not sure how to solve that best

[03:10:10.0000] <annevk-cloud>
darobin: not sure if punycode can fail, but ToASCII can

[03:22:45.0000] <zcorpan>
jgraham: would it be bad to have sub enabled for all .html files?

[03:25:32.0000] <jgraham>
zcorpan: Yeah, I think so. I strongly suspect it makes things much slower

[03:44:59.0000] <jgraham>
zcorpan: We could make some hack like a file extension to indicate that substitutions should be applied

[03:45:06.0000] <jgraham>
like foo.sub.html

[03:46:27.0000] <zcorpan>
wfm

[05:17:49.0000] <annevk>
Hixie: elsewhere you do use :not(.classname) fwiw

[06:12:11.0000] <annevk>
smaug____: yo, could you maybe comment on your preference with regards to GC of Notification objects in https://github.com/whatwg/notifications/issues/9 ?

[06:12:23.0000] <annevk>
I wonder what we've done so far in such scenarios

[06:14:22.0000] <smaug____>
github

[06:14:26.0000] <smaug____>
uh

[06:14:33.0000] <smaug____>
looking...

[06:14:43.0000] <smaug____>
(while eating lunch )

[06:19:12.0000] <smaug____>
annevk: is there really any other option than returning always new notification

[06:19:46.0000] <annevk>
smaug____: Notification objects could be tied to the lifetime of the global

[06:20:32.0000] <smaug____>
so over timer there can be tons of them...

[06:20:35.0000] <smaug____>
say an email app

[06:21:30.0000] <annevk>
smaug____: well, notifications that are closed can be collected

[06:21:44.0000] <smaug____>
sure

[06:21:50.0000] <smaug____>
what was the reason to add .get()

[06:22:30.0000] <annevk>
smaug____: if you close your email page and then open it again later while notifications are still in the notification center

[06:23:01.0000] <annevk>
smaug____: or if you open your email page again in another window and you want to know about existing notifications

[06:23:21.0000] <smaug____>
ah, right

[06:24:07.0000] <smaug____>
but it is getOrCreate

[06:24:27.0000] <smaug____>
currently

[06:26:06.0000] <annevk>
well, it gets notifications, either as existing Notification objects, or as newly created ones if the global didn't have any representation for them yet

[06:26:25.0000] <annevk>
it doesn't create new notifications, just new Notification objects

[06:26:46.0000] <smaug____>
could we call get() something else and always create a new Notification for each notifications

[06:28:13.0000] <annevk>
getCopies()

[06:28:22.0000] <annevk>
getClones()

[06:28:24.0000] <smaug____>
since it is a bit odd if (new Notification({})) != Notification.get({}),<add_random_promise_stuff_here>;

[06:28:48.0000] <smaug____>
yeah, either one

[06:28:53.0000] <smaug____>
perhaps Clones

[06:29:03.0000] <annevk>
mkay

[06:29:18.0000] <annevk>
I guess I also need to clarify that GC should not happen if we have event listeners attached?

[06:29:29.0000] <annevk>
At least for particular events

[06:29:41.0000] <smaug____>
right

[06:29:43.0000] <annevk>
Something similar to http://xhr.spec.whatwg.org/#garbage-collection

[06:30:02.0000] <smaug____>
WebSocket has something similar too

[06:30:40.0000] <annevk>
Mkay, we'll go with this I guess

[06:33:56.0000] <annevk>
smaug____: so the annoying thing with always new is the event listeners I think

[06:34:06.0000] <annevk>
smaug____: you don't want to add them all over

[06:34:45.0000] <smaug____>
well, if you don't want to add new ones, you keep ref to the original Notification or something

[06:35:38.0000] <annevk>
smaug____: sure you would, but now you got a copy of that one so you need to make some kind of crappy comparison between the two

[06:35:57.0000] <Ms2ger>
.isEqualNotification

[06:36:06.0000] <annevk>
Ms2ger: right :/

[06:36:37.0000] <annevk>
That's mostly why my design tried to preserve === but I guess once you add an <iframe> or a worker you're already in trouble

[06:40:00.0000] <mathiasbynens>
smaug____: just wanted to say i loved your performance in the hobbit 2

[06:40:48.0000] <smaug____>
I was pretty good

[06:44:20.0000] <smaug____>
.equals() is a bit annoying

[06:45:02.0000] <smaug____>
but works

[06:46:11.0000] <annevk>
oh my

[06:48:49.0000] <annevk>
bah Ms2ger, now I found some buggy wording in isEqualNode

[06:49:17.0000] <annevk>
/me remembers TabAtkins mentioning he fixed Selectors

[06:49:44.0000] <Ms2ger>
annevk, the recursive call?

[06:50:38.0000] <annevk>
Ms2ger: yeah, both it not being in terms of an abstract algorithm and the way it is invoked

[06:51:10.0000] <Ms2ger>
Clearly I should have caught that :)

[06:51:47.0000] <annevk>
Ms2ger: I also never really tested this method so now I'm wondering what it does for <input>.value and a <script> that has run versus one that hasn't and such

[06:52:07.0000] <Ms2ger>
Mm

[06:52:11.0000] <Ms2ger>
I think nothing special

[06:52:33.0000] <Ms2ger>
But that's without leaving my sense of logic at the door

[06:54:07.0000] <annevk>
.value is ignored :-)

[06:54:45.0000] <annevk>
But yeah, I guess I'll rewrite this in terms of a concept-node-equals

[06:54:58.0000] <Ms2ger>
Oh right, the domparsing review

[06:55:02.0000] <Ms2ger>
Thanks zcorpan

[06:55:31.0000] <Ms2ger>
annevk, mm, I pretty much did that in servo too :)

[06:56:59.0000] <Ms2ger>
/me had a good laugh at the compatibility section on https://businessportal.alcatel-lucent.com/

[06:58:02.0000] <annevk>
Ms2ger: what about all this purported upstream Servo specification review then?!

[06:59:47.0000] <Ms2ger>
I didn't read well enough :)

[07:55:27.0000] <TabAtkins>
annevk: http://dev.w3.org/csswg/selectors/#data-model Just using the DOM as the Selectors element tree in HTML.

[07:56:24.0000] <annevk>
TabAtkins: the whole "in HTML" thing doesn't make much sense to me

[07:56:31.0000] <annevk>
TabAtkins: by the team you get to Selectors, there's no HTML

[07:56:36.0000] <annevk>
time*

[07:56:44.0000] <TabAtkins>
Yes there is.  That's the host document.

[07:56:54.0000] <annevk>
HTML is syntax, DOM is representation

[07:57:12.0000] <TabAtkins>
Oh, I see.  So something more like - in documents represented by a DOM?

[07:57:24.0000] <annevk>
What if I created the whole thing through createDocument() and createElement() and then did matching?

[07:57:25.0000] <annevk>
Yeah

[07:58:34.0000] <TabAtkins>
annevk: Except wouldn't that suggest that Selectors should never mention HTML in any way?

[07:58:52.0000] <annevk>
TabAtkins: well that is kind of my opinion

[07:59:07.0000] <annevk>
TabAtkins: you could talk about HTML elements

[07:59:14.0000] <TabAtkins>
But some of that's completely wrong.  The DOM doesn't give the table pseudos any meaning.

[07:59:17.0000] <TabAtkins>
Ah, okay.

[07:59:19.0000] <annevk>
TabAtkins: but you also happily match against elements that are not HTML elements

[07:59:24.0000] <TabAtkins>
Yeah.

[07:59:28.0000] <TabAtkins>
All right, I'm satisfied.

[08:00:07.0000] <annevk>
The way the table pseudos get meaning is because certain elements have additional flags, such as whether those pseudos match :-)

[08:00:10.0000] <TabAtkins>
I wonder how I should handle XML here.  Invoke Infoset? Or just lean on DOM?

[08:00:16.0000] <annevk>
DOM

[08:01:03.0000] <annevk>
At least as far as browsers are concerned DOM is the model we use and operate on. Other players can easily map DOM to their own model. That seems easiest

[08:20:18.0000] <dglazkov>
good morning, Whatwg!

[08:25:36.0000] <annevk>
smaug____: any thoughts on https://www.w3.org/Bugs/Public/show_bug.cgi?id=23268 ?

[08:26:28.0000] <smaug____>
mtg

[08:27:48.0000] <annevk>
smaug____: sounds like a good reason to give it a thought

[08:28:00.0000] <smaug____>
ha

[08:37:37.0000] <annevk>
W3C is now using CORS as example for security propaganda? http://www.w3.org/blog/2014/02/strengthen-web-security-on-the-day-we-fight-back/

[08:45:00.0000] <Domenic_>
hehehe

[08:46:21.0000] <jgraham>
You have to love campaigns about global issues that assume all internet users are from the USA

[08:46:32.0000] <marcosc>
:)

[08:47:35.0000] <marcosc>
I wonder who here works for the NSA :)

[08:48:52.0000] <marcosc>
"We do not believe any of W3C’s Recommendations were weakened through interference"... it says nothing about WHATWG specs, which no doubt have been meddled with. My money is on MikeSmith as a double agent.

[08:49:18.0000] <qrwteyrutiyoup>
lol :)

[08:53:45.0000] <foolip>
Ms2ger: ping?

[08:54:51.0000] <foolip>
Ms2ger: ok if I do both the things you asked in https://critic.hoppipolla.co.uk/r/767 on separate branches? there's lots of things to fix here but I'd like to keep it to one topic per branch as much as possible...

[08:55:37.0000] <annevk>
jgraham: I got excited there for a minute, thought you were talking about global object issues

[08:56:05.0000] <Ms2ger>
foolip, if it happens, sure :)

[08:56:22.0000] <jgraham>
annevk: I thought we didn't have global objects, just realms :p

[08:57:39.0000] <foolip>
Ms2ger: it will

[08:57:55.0000] <SimonSapin>
annevk for Protector of the Realm?

[08:57:56.0000] <Ms2ger>
Thanks :)

[08:58:25.0000] <Ms2ger>
I thought he didn't stand for re-election?

[09:02:22.0000] <odinho>
Hmm. They must've meant CSP.

[09:04:15.0000] <gsnedders>
Can we make a rule that all initalisms must be universally unique?

[09:05:58.0000] <SimonSapin>
haha

[09:06:40.0000] <gsnedders>
I keep thinking Communicating Sequential Processes. Which are quite different to the Content Security Policy.

[09:06:50.0000] <SimonSapin>
"There aren't enough small numbers to meet the many demands made of them."

[09:07:23.0000] <jgraham>
I keep thinking Continuation Passing Style, so I'm not sure that uniqueness is all it's cracked up to be

[09:07:57.0000] <gsnedders>
But that's CPS, not CSP!

[09:10:36.0000] <jgraham>
Hence uniqueness not being all it's cracked up to be

[09:29:18.0000] <TabAtkins>
I kinda like that moment in the conversation when you realize the person you're talking to has absolutely no clue what they're talking about.

[09:30:18.0000] <jgraham>
Like the inverse of http://xkcd.com/451/ ?

[09:30:21.0000] <TabAtkins>
In this case, it was some rando saying that with Blink dropping Regions, he might as well go native.

[09:30:45.0000] <TabAtkins>
He citied iOS Regions (they have something *similar* to Regions, but much less complex), then pointed to a web page as an example.

[09:31:07.0000] <TabAtkins>
Talking about how pretty it was in Safari. I was confused, so I pressed him on how it was native.

[09:31:23.0000] <TabAtkins>
He responded that he'd just develop apps wrapped around a webview.

[09:31:26.0000] <TabAtkins>
 /headdesk

[09:32:00.0000] <TabAtkins>
(If he's targetting iOS, Blink doesn't matter anyway, because it doesn't even *exist* on the platform. iOS Chrome is just a wrapper around Safari.)

[09:32:45.0000] <TabAtkins>
jgraham: If it had been in person, the conversation would have been over in a minute or two.

[10:09:05.0000] <GPHemsley>
CPS = Child Protective Services; Crown Prosecution Service

[10:11:19.0000] <Ms2ger>
foolip, got more? :)

[10:46:17.0000] <TabAtkins>
Anyone in here got Chrome Beta or newer, on Mac or Windows? Mind seeing if this looks messed up? http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2805

[10:47:50.0000] <TabAtkins>
Anyone in here got Chrome Beta or newer, on Mac or Windows? Mind seeing if this looks messed up? http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2805

[10:48:26.0000] <amtiskaw>
Looks OK to me in Canary on Windows

[10:48:58.0000] <TabAtkins>
Okay, might be just a Linux issue then.

[10:50:05.0000] <TabAtkins>
amtiskaw: Just to make sure - you're seeing three distinct character on each line? The characters aren't jumbled up and overlapping each other?

[10:51:13.0000] <amtiskaw>
TabAtkins: Yep, all distinct. Rendering matches Firefox Nightly almost exactly, as far as I can see.

[10:51:31.0000] <TabAtkins>
Thanks!

[13:51:37.0000] <Domenic_>
How do you use :has to emulate `a !b ~ c`?

[13:51:52.0000] <Domenic_>
TabAtkins ^

[13:52:29.0000] <TabAtkins>
Domenic_: That's almost exactly the same selector we have in the poll.

[13:52:33.0000] <TabAtkins>
a b:has(~ c)

[13:53:04.0000] <Domenic_>
Yeah I guess it makes sense. It's a bit weird because I only think of elements as "having" their children

[13:53:58.0000] <TabAtkins>
They also "have" siblings.

[13:54:11.0000] <Domenic_>
wfm

[13:56:47.0000] <Hixie>
a b:matches(# ~ c) { }

[13:57:10.0000] <Hixie>
the real question is how do you do  b:matches(a #):matches(b #) with !

[13:57:56.0000] <Hixie>
or b:matches(# a):matches(# b) { }

[14:04:24.0000] <Domenic_>
Can `p:has(a) ~ .legal { display: block }` be translated to using `!`?

[14:57:24.0000] <TabAtkins>
Domenic_: :matches(!p a) ~ .legal

[14:57:41.0000] <TabAtkins>
Hixie: That's a <b> with both <a> and <b> ancestors?

[14:58:05.0000] <TabAtkins>
:matches(a b, b b)

[14:58:31.0000] <Hixie>
right

[14:58:47.0000] <Hixie>
yeah, commas can get you some of the way, but they don't scale well

[15:00:09.0000] <Hixie>
:matches(!p a) ~ .legal  is kinda ugly (why would the p be in the :matches?).  p:matches(!* a) ~ .legal  is basically the same as  p:matches(# a) ~ .legal  which is what i proposed years ago

[15:00:42.0000] <TabAtkins>
p:matches(!* a) doesn't match anything.

[15:00:52.0000] <Hixie>
why not?

[15:00:56.0000] <TabAtkins>
The subject of the :matches() selector is the thing the :matches() pseudo-class is attached to.

[15:01:01.0000] <TabAtkins>
p:matches(a) is nonsense.

[15:01:39.0000] <Hixie>
p:matches(# a) and p:matches(a) are completely different.

[15:02:02.0000] <TabAtkins>
Only if you're using a different definition of :matches() than the spec has.

[15:02:04.0000] <Hixie>
(and in my original proposal, p:matches(a) would match any <p> in a document with an <a>)

[15:02:24.0000] <Hixie>
(which i still think makes way more sense)

[15:02:51.0000] <Hixie>
how is :matches(!p a) not equivalent to p:matches(!* a) ?

[15:03:47.0000] <TabAtkins>
In "A:matches(B C)", the C part of the selector refers to the same element as the A part.

[15:03:59.0000] <TabAtkins>
The subject of the :matches() selector arguments is A.

[15:05:41.0000] <Hixie>
sure

[15:05:53.0000] <Hixie>
and in A:matches(!B C), the subject of the argument is the B, which is the same element as the A

[15:06:19.0000] <Hixie>
and in the original proposal, A:matches(# C), the # is the subject of the argument, which is the same elmeent as the A

[15:06:21.0000] <TabAtkins>
Oh, right.  Yes, you're right.

[15:06:36.0000] <TabAtkins>
*:matches(!p a) is identical to p:matches(!* a)

[15:07:00.0000] <Hixie>
that's why the original proposal for :matches and :has had two separate pseudo-classes

[15:07:37.0000] <Hixie>
because in :matches(), the condition was just "there is an element that matches this", without the # it wasn't linked to the element on which the pseudo was found

[15:07:48.0000] <Hixie>
:has() was then :matches() with an implied "#" at the start of the selector argument

[15:08:28.0000] <Hixie>
("!" is net inferior since it is a subset of the expressiveness, without actually limiting what can be said, it just makes it more verbose, as far as i can tell)


2014-02-12
[17:22:39.0000] <GPHemsley>
/me wonders what memo he missed about the meaning of #, @, : as search filters

[17:24:02.0000] <TabAtkins>
If you use an @ in your selector, it matches the Twitter user with that username.

[17:25:55.0000] <GPHemsley>
I mean in things like devtools inspector and such

[17:26:09.0000] <GPHemsley>
/me realized after he said that that this was not the topic of conversation earlier.

[21:32:25.0000] <rniwa>
annevk: yt?

[00:39:32.0000] <Ms2ger>
Hixie, https://www.w3.org/Bugs/Public/show_bug.cgi?id=24628

[02:22:37.0000] <annevk>
well, I'm here now, but rniwa is not

[02:31:05.0000] <annevk>
Aah, TabAtkins realized I was right due to http://dev.w3.org/csswg/shadow-styling/

[02:31:23.0000] <annevk>
Ms2ger: is Editing easily maintainable at the moment?

[02:32:19.0000] <Ms2ger>
I think I have access to it

[02:34:30.0000] <annevk>
Cool, it's available under CC0

[02:35:37.0000] <annevk>
I wonder if Hixie is interested in taking it back into HTML

[03:02:10.0000] <annevk>
"[Bug 24627] New: [Shadow]: Support disconnected nodes" o_O

[03:02:23.0000] <annevk>
Glad that was fixed swiftly

[03:03:49.0000] <Ms2ger>
zcorpan, https://gist.github.com/zcorpan/8952688

[03:05:26.0000] <zcorpan>
Ms2ger: i noticed i managed to mistype "errorVideo" as "video"

[03:05:39.0000] <zcorpan>
Ms2ger: i don't understand your comment

[03:06:27.0000] <Ms2ger>
I don't know what the issue is, but one of the tests clears the page for me

[03:11:09.0000] <zcorpan>
maybe it does document.write() or something which clears the page after onload

[03:13:03.0000] <zcorpan>
ok now i've got something working

[03:34:05.0000] <annevk>
Sigh. I feel like I'm explaining to everyone how to write specifications

[03:34:55.0000] <Ms2ger>
Write it down

[03:36:47.0000] <jgraham>
Make a specification-specification

[03:37:45.0000] <zcorpan>
what if other people want to write a specification-specification and get it wrong?

[03:38:17.0000] <jgraham>
Well we could write a specification-specification-specification to avoid that

[03:38:34.0000] <jgraham>
"specification-specifications MUST be written by annevk"

[03:38:58.0000] <annevk>
You guys are not helping

[03:39:11.0000] <Ms2ger>
:)

[03:40:02.0000] <jgraham>
annevk: Are you kidding? I found a base case so we could avoid specification^N recursion!

[03:40:12.0000] <jgraham>
I saved you an infinite amounbt of work!

[03:40:18.0000] <annevk>
But yes, maybe I should put my comment about monkey patching in a blog post, with a slight elaboration so it also applies to the web perf group

[03:40:29.0000] <Ms2ger>
You should

[03:41:24.0000] <jgraham>
The slight elaboration being "btw web-perf wg: you don't read my blog, but this applies to you guys too"?

[03:47:10.0000] <annevk>
jgraham: well I guess I still need to tell them about it

[03:47:34.0000] <annevk>
e.g. http://www.w3.org/TR/resource-timing/ is guilty of this

[04:48:54.0000] <Ms2ger`>
zcorpan, r+ https://critic.hoppipolla.co.uk/r/74

[04:49:16.0000] <jgraham>
\o/

[04:49:32.0000] <jgraham>
zcorpan, foolip: Awesome work :)

[04:49:44.0000] <zcorpan>
woot

[04:49:58.0000] <zcorpan>
should i click the green button or squash or something first?

[04:50:45.0000] <jgraham>
I don't mind either way

[04:50:54.0000] <jgraham>
It's OK to just merge, I think

[04:51:28.0000] <zcorpan>
ok done

[04:53:48.0000] <Ms2ger`>
Didn't even take 10 months!

[04:56:02.0000] <Ms2ger`>
zcorpan, r? https://critic.hoppipolla.co.uk/r/744 :)

[05:08:16.0000] <Ms2ger`>
foolip, html/semantics/embedded-content-0/the-video-element/video_width_reflect.html might be removable

[05:31:21.0000] <bhanu_>
hi, I have submitted a patch for #25571 few days back, I am waiting for someone to review it

[05:32:09.0000] <annevk>
bhanu_: what bug database?

[05:32:51.0000] <bhanu_>
annevk : on HTML DOM

[05:33:19.0000] <annevk>
bhanu_: pointer?

[05:33:49.0000] <bhanu_>
range methods not working with detached nodes

[05:34:51.0000] <annevk>
bhanu_: I meant an actual URL to the issue you're talking about

[05:35:07.0000] <annevk>
bhanu_: because I'm having a hard time following this

[05:36:23.0000] <bhanu__>
annevk: https://bugs.webkit.org/show_bug.cgi?id=25571

[05:37:39.0000] <annevk>
bhanu_: #whatwg is not #webkit, though reading that bug I wonder why you think the specification is wrong

[05:37:56.0000] <zcorpan>
TabAtkins: i get "FATAL ERROR: Couldn't find 'respimg-usecases' in bibliography data." in https://api.csswg.org/bikeshed/ with https://github.com/ResponsiveImagesCG/picture-element/blob/gh-pages/index.src.html as input

[05:42:19.0000] <zcorpan>
bhanu__: you had asked earlier whether to implement stuff from dom2. both annevk and i said you should ignore dom2. what gives?

[05:45:06.0000] <bhanu__>
annevk: I think we had mail communication on this issue few days back, and I came to know that we should only follow the latest one, but when I saw the chromium source code, I got confused

[05:46:19.0000] <annevk>
bhanu__: I see

[05:47:18.0000] <annevk>
bhanu__: Anything in particular that was confusing? You should only have to read http://dom.spec.whatwg.org/

[05:50:07.0000] <bhanu__>
annevk: Going by one is never a confusion, I could completely follow http://dom.spec.whatwg.org/ ignoring what chromium has done in their source code which will fix the issue.

[05:51:46.0000] <annevk>
bhanu__: that sounds good

[05:51:57.0000] <annevk>
bhanu__: Chrome has a bunch of issues with "disconnected" nodes

[05:52:11.0000] <annevk>
bhanu__: so much even that they baked their own silly assumptions into new specs

[05:52:12.0000] <annevk>
:/

[05:52:57.0000] <bhanu__>
annevk, zcorpan: thank you for your help

[05:53:25.0000] <annevk>
bhanu__: thank you for fixing bugs

[06:07:20.0000] <annevk>
I cannot believe I am writing this out. Why monkey patching is bad should be so obvious!!1!

[06:12:47.0000] <Ms2ger`>
Ha

[06:12:56.0000] <Ms2ger`>
Remember when we did it? :)

[06:18:47.0000] <annevk>
Ms2ger`: we did?

[06:18:58.0000] <annevk>
Ms2ger`: oh, Web Forms 2.0? :-)

[06:19:03.0000] <Ms2ger`>
For example :)

[06:19:06.0000] <annevk>
Ms2ger`: it was a disaster

[06:19:10.0000] <Ms2ger`>
dom xpath comes to mind

[06:19:16.0000] <Ms2ger`>
Or plain xpath

[06:19:20.0000] <Ms2ger`>
Whatever that bit was

[06:19:43.0000] <annevk>
I hope that dies at some point. Otherwise we'll need to fix that too. There's an even an additional Node type there that apparently ties into attributes?

[06:20:15.0000] <annevk>
Ms2ger`: http://wiki.whatwg.org/wiki/DOM_XPath

[06:20:58.0000] <annevk>
Although that page does not deal with the new node type

[06:22:55.0000] <jgraham>
annevk: I plan to monkey patch your blog post so that every time it reads "monkey patching", it instead reads "not monkey patching"

[06:23:21.0000] <annevk>
jgraham: I'll monkey patch your desk

[06:23:23.0000] <Ms2ger`>
Yeah, I know that page, I wrote it :)

[06:23:33.0000] <zewt>
don't run that monkey patch on itself, you'll destroy the universe

[06:24:17.0000] <jgraham>
annevk: With a real monkey?

[06:24:33.0000] <annevk>
jgraham: no spoilers

[06:24:53.0000] <zewt>
i guess monkeys need help quitting too

[06:26:14.0000] <annevk>
I guess I'll just post it and then update it per comments here

[06:27:18.0000] <annevk>
http://annevankesteren.nl/2014/02/monkey-patch

[06:35:01.0000] <annevk>
Why do the crypto people keep coming back to me talking about CORS?

[06:59:03.0000] <annevk>
Because they don't understand structured clones is the answer it seems

[06:59:08.0000] <annevk>
It is very silly

[06:59:35.0000] <gsnedders>
Well why aren't they explained better?

[06:59:49.0000] <gsnedders>
If they keep on coming back to you, that implies you haven't explained it well enough!

[07:00:33.0000] <annevk>
I'm not sure, I have the feeling someone with half a clue hears origin and things "oh CORS!" and then all the people with less of a clue start asking about it

[07:00:46.0000] <annevk>
thinks*

[08:05:24.0000] <TabAtkins>
zcorpan: Did you grab *just* that file?  There's also a biblio.json file in the repo that you need.

[08:07:26.0000] <arv>
annevk: Is there a spec bug related to enumerability of named properties in HTMLCollection?

[08:07:37.0000] <annevk>
arv: I just fixed it

[08:07:55.0000] <annevk>
arv: last commit has a pointer

[08:09:26.0000] <arv>
annevk: thanks

[08:11:19.0000] <arv>
annevk: If bz and Christophe is happy with that I'm happy

[08:11:40.0000] <annevk>
bz has a patch for Gecko he said

[08:11:54.0000] <annevk>
arv: btw, if we add iterators, should they make snapshots? so live becomes static?

[08:12:15.0000] <annevk>
arv: we're leanings towards yes, makes for-of and such nicer

[08:12:22.0000] <annevk>
leaning*

[09:06:30.0000] <Jabberwock>
Hello, all. Could someone point me to some documentation regarding websocket security testing? (and any security concerns)

[09:19:57.0000] <Hixie>
annevk: i really don't have the bandwidth to take over editing again right now, but it'd be fantastic if someone did

[09:20:15.0000] <annevk>
Hixie: yeah figured

[09:20:17.0000] <dglazkov>
good morning, Whatwg!

[09:20:25.0000] <Hixie>
long-term i'd love to take it up again

[09:20:32.0000] <Hixie>
i mean, that was the original plan and all

[09:24:59.0000] <Hixie>
dglazkov: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24312#c19 implies you're supposed to be telling me things

[09:33:13.0000] <dglazkov>
Hixie: annevk was doing great work at coordination! :)

[09:33:36.0000] <annevk>
dglazkov: I'm kind of tired of being a project manager for custom elements though

[09:34:19.0000] <marcosc>
annevk: it's all a ploy to convert you into a middle manager. Didn't you get that tie for xmas?

[09:34:24.0000] <annevk>
at least, my job is to write specs, not clean up other specs

[09:34:29.0000] <dglazkov>
Hixie: annevk is right, there needs to be gooder coordination here.

[09:34:53.0000] <dglazkov>
annevk: can I fix it by making you the editor of custom elements?

[09:35:20.0000] <marcosc>
aaawww snap!

[09:35:27.0000] <annevk>
dglazkov: well that's what it feels like, apart from writing the prose :p

[09:35:52.0000] <dglazkov>
annevk: btw, I am super-grateful for your work.

[09:36:36.0000] <dglazkov>
and filing bugs

[09:36:56.0000] <dglazkov>
I've been caught in the storm of basically answering emails all day, and haven't made a lot of progress myself

[09:38:47.0000] <annevk>
It does feel like we're getting closer

[09:42:21.0000] <dglazkov>
annevk: asymptotically approaching it, yup

[09:43:26.0000] <annevk>
dglazkov: I'm back to wondering why the hooks are related to the document with a view rather than simple insert and delete as the DOM has, but it seems that might have been based on bugs in Chrome

[09:44:20.0000] <annevk>
dglazkov: and at that point we can look at the callbacks HTML has for insert/remove and see how "sync" they need to be and if they can be done at the point we want them to be done for custom elements

[09:44:22.0000] <dglazkov>
annevk: what bugs in Chrome?

[09:44:31.0000] <annevk>
dglazkov: around disconnected nodes not being proper trees

[09:48:49.0000] <dglazkov>
annevk: I don't think disconnected nodes was a consideration at that time. Originally, that callback was born out of the element's need to have a hint at whether they're being shown on screen. esprehn had the example of <google-maps> element wanting to know when to start drawing their WebGLey stuff.

[09:49:17.0000] <esprehn>
back then <template>'s contents also issued callbacks, so it was even more important

[09:50:03.0000] <annevk>
But the point of this exercise is also to actually expose the primitives and be able to implement "native" elements in terms of this right?

[09:50:21.0000] <annevk>
At which point you need to study what hooks they are using at the moment and if they can be refactored somehow

[09:50:22.0000] <esprehn>
<template> no longer issues callbacks, so we could possibly make this simpler if we give you an easy way to tell if you're in an import (imports also have a defaultView so a component can't just if (!defaultView) return;

[09:52:16.0000] <annevk>
esprehn: the check is node.ownerDocument === document && document.defaultView or some such, rniwa mentioned it in the bug

[09:52:32.0000] <esprehn>
annevk: that's not enough, what if you move across an iframe boundary?

[09:52:56.0000] <annevk>
esprehn: I don't understand

[09:53:28.0000] <esprehn>
you do node.ownerDocument === document, but if you're inserted into a document in an iframe that check will be against the other window

[09:53:36.0000] <esprehn>
it'll be false, and your callback will abort incorrectly

[09:55:24.0000] <annevk>
Okay, in any event, we could expose a check for that, but basing the callbacks around that seems incorrect given the precedent we have for HTML elements

[09:56:24.0000] <esprehn>
what precedent?

[09:59:21.0000] <annevk>
esprehn: the DOM exposes (sync) node inserted/removed callbacks that HTML elements use

[10:01:15.0000] <esprehn>
do you want callbacks that fire in detached subtrees too?

[10:01:58.0000] <esprehn>
we found that excessively spammy, and not what developers wanted. I'd support making the callbacks "inserted" and "removed" and they act when you enter/leave any document tree

[10:02:18.0000] <annevk>
esprehn: consider e.g. implementing <select> or <video> yourself

[10:02:48.0000] <annevk>
esprehn: you need to know when new child elements are inserted and update yourself (or do that from the child elements, which can be custom too)

[10:03:07.0000] <esprehn>
annevk: MutationObservers let you observe child changes

[10:03:22.0000] <annevk>
esprehn: not in a way that allows for re-implementing HTML elements

[10:03:26.0000] <esprehn>
yes

[10:03:33.0000] <annevk>
esprehn: no, the delivery is too late

[10:03:36.0000] <esprehn>
Inside any getter on <select> you call takeRecords() and update the state

[10:03:48.0000] <esprehn>
that's fine, querying the state forces a sync takeRecords(), just like offsetTop forces a layout

[10:04:55.0000] <annevk>
hmm interesting, I wonder if that would break anything

[10:08:57.0000] <annevk>
esprehn: can you bring that up in the "Extending Mutation Observers to address use cases of" thread?

[10:10:48.0000] <esprehn>
annevk: sure

[10:11:20.0000] <annevk>
esprehn: the amount of callbacks for "node is removed" seems worrying though http://mxr.mozilla.org/mozilla-central/ident?i=ContentRemoved

[10:12:14.0000] <esprehn>
annevk: internally we react synchronously usually, but as far as the page is concerned it could have been a MutationObsever and a takeRecords() in the getter

[10:12:26.0000] <annevk>
esprehn: e.g. I could append two Text nodes to a <style>, remove one text node, then do getComputedStyle(), which would then have to ask <style> to do takeRecords() but that might happen as part of the general flush I suppose

[10:13:00.0000] <annevk>
esprehn: "in the getter" is nice when it's easy

[10:13:17.0000] <esprehn>
any getter causes a state synchronization, so getComputedStyle() would force the <style> to synchronize with it's records

[10:13:42.0000] <esprehn>
since getComputedStyle() conceptually calls style.sheet

[10:14:23.0000] <annevk>
yeah, I guess I can see how that might work

[10:14:39.0000] <annevk>
hopefully the others agree

[10:14:50.0000] <esprehn>
it shouldn't be any harder than making all rendering queries force a style recalc or a layout like offsetTop or getComputedStyle(...).color

[10:34:36.0000] <annevk>
I wonder what the best way would be to define the DOM meanwhile

[10:41:19.0000] <annevk>
In terms of mutation records and takeRecords() could be interesting, but also somewhat verbose

[11:43:51.0000] <arv>
annevk: Iterators of live node lists... Maybe not add them at all to discourage people from using live node lists?

[11:44:22.0000] <annevk>
arv: people will use getElementsByTagName() and then try for-of

[11:44:40.0000] <arv>
annevk: :'(

[11:44:42.0000] <annevk>
arv: in fact everyone is asking for HTMLCollection and NodeList and such to have iterator and Gecko already has it

[11:45:01.0000] <arv>
annevk: I think we should keep them live. ArrayIterator is live

[11:45:57.0000] <arv>
annevk: Doing `NodeList.prototype[Symbol.iterator] = Array.prototype[Symbol.iterator]` works fine with live lists

[11:47:00.0000] <annevk>
arv: added that to https://www.w3.org/Bugs/Public/show_bug.cgi?id=17648#c6

[11:48:34.0000] <arv>
annevk: thanks

[13:33:01.0000] <SamB_>
/me mumbles something about <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24628>, and also wonders why Selection needs to be tied up with so many editing commands ...

[13:36:53.0000] <SamB_>
/me isn't finding https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html very easy to read without it's proper styling

[14:14:03.0000] <TabAtkins>
SamB_: Complain to Hixie to support https on whatwg.org.

[14:14:42.0000] <SamB_>
Hixie: consider yourself complained to

[14:15:04.0000] <Hixie>
/me looks into it

[14:15:31.0000] <Hixie>
(though the real solution would be for someone to take over editing that spec and host it somewhere like whatwg.org)

[14:23:03.0000] <SamB>
should it be marked "orphaned"?

[14:23:44.0000] <Hixie>
SamB: ok, i need a cert to make this work. can you provide me with a cert? :-)

[14:24:14.0000] <SamB>
maybe TabAtkins's plan wasn't the best after all

[14:24:46.0000] <Hixie>
right now i have it set up as a self-signed cert

[14:25:25.0000] <Hixie>
but that doesn't solve your problem

[14:25:45.0000] <Hixie>
oh wait, the page is loading it straight from http://

[14:25:49.0000] <Hixie>
so that won't help anyway

[14:25:51.0000] <SamB>
yeah, true

[14:26:07.0000] <SamB>
I thought that's what you meant when you said "that doesn't solve your problem"

[14:26:29.0000] <TabAtkins>
Yeah, the spec needs to be changed to use https, *and* whatwg.org needs to support https.

[14:26:33.0000] <TabAtkins>
It doesn't, currently.

[14:26:40.0000] <SamB>
because I could clearly teach *my* browser that it's okay to accept the self-signed cert

[14:44:39.0000] <annevk-cloud>
Someone maintaining it would be great

[14:45:16.0000] <annevk-cloud>
Maybe if someone takes over some of my smaller specs

[14:46:24.0000] <Hixie>
man i wish you had posted that blog post on G+ just so that I could +1 the hell out of it

[14:46:53.0000] <TabAtkins>
You can link to it from your own g+ post, then +1 it yourself.

[14:47:01.0000] <Hixie>
that sounds like work

[14:49:17.0000] <Hixie>
lol

[14:49:30.0000] <Hixie>
i tried getting an ssl cert with startssl.com, since they have free 1 year certs

[14:49:36.0000] <Hixie>
but they asked for a phone number and i don't have one

[14:49:57.0000] <Hixie>
so i gave them +1 555 555 5555

[14:50:12.0000] <Hixie>
then they e-mailed me, "we need a valid number", so i said i didn't have one and which would they suggest

[14:50:20.0000] <Hixie>
to which they replied, and i quote, "you parent's"

[14:50:40.0000] <Hixie>
/me may have misjudged the level of professionalism involved with these free certs

[14:50:48.0000] <TabAtkins>
Hahahahaha

[14:52:31.0000] <Hixie>
ooh, another reply

[14:52:36.0000] <Hixie>
"So [...] If someone wants to reach you, they can't?"

[14:52:40.0000] <Hixie>
um, YOU ARE REACHING ME RIGHT NOW

[14:54:14.0000] <Hixie>
gotta give them one thing, they're pretty responsive

[14:57:37.0000] <Hixie>
oh hey, i convinced them

[14:57:38.0000] <Hixie>
excellent

[14:57:43.0000] <gavinc>
... yeah, they are in fact a very decent cert provider that's done a better job checking things out then plenty of them.

[14:58:26.0000] <Hixie>
holy jeepers, a <keygen> element

[14:59:35.0000] <Hixie>
woah, hold on, how the heck did they install a new user cert

[15:01:26.0000] <gavinc>
<keygen>... that's what it does

[15:01:48.0000] <Hixie>
i thought that uploaded a cert to them

[15:01:59.0000] <Hixie>
how did they cause my browser to install the one they sent back?

[15:02:45.0000] <gavinc>
No, you generated a private key, and sent them the public

[15:02:53.0000] <gavinc>
the private cert is installed locally

[15:03:55.0000] <gavinc>
private key is just added to the local keystore

[15:05:10.0000] <gavinc>
they just send back the signed client cert

[15:05:10.0000] <annevk-cloud>
Hixie defined the element…

[15:05:20.0000] <gavinc>
yeah that's why I'm confused?

[15:05:48.0000] <TabAtkins>
If you think that "defined X" means "understands X permanently", I have some bad news for you.

[15:06:14.0000] <gavinc>
/me doesn't

[15:08:10.0000] <Hixie>
(i barely understood it then)

[15:08:19.0000] <Hixie>
so it's the "they just send back the signed client cert" part i have a problem with

[15:08:23.0000] <Hixie>
how do they "send it back"?

[15:10:04.0000] <annevk-cloud>
New 2014 goal: get bz to spell it URL

[15:10:36.0000] <annevk-cloud>
/me does no get <keygen> either, to be clear

[15:19:40.0000] <TabAtkins>
Random fun element demo: http://maklesoft.github.io/shape-shifter/

[15:25:04.0000] <SimonSapin>
startssl uses client certs for auth (no password)

[15:25:27.0000] <zewt>
yeah, that site is terrible

[15:25:34.0000] <SimonSapin>
I recently renewed a server cert, but my client cert had expired so I had to create a new account

[15:25:59.0000] <zewt>
so the first thing everyone on that site does is create an account and get immediately locked out of it because they didn't create a cert before they logged out

[15:27:13.0000] <zewt>
so i decided i'd rather pay a couple bucks for a cert than deal with a site with that little common sense, heh

[15:27:59.0000] <gavinc>
So by using SSL to secure an CA provider they demonstrated to you that they didn't have common sense?

[15:28:13.0000] <jamesr__>
Hixie: why is the storage mutex still in the spec?

[15:28:23.0000] <jamesr__>
has anyone indicated that they'll ever implement it?

[15:28:44.0000] <zewt>
by having an auth system that lets you get locked out that trivially in the normal first-time-user UI flow

[15:29:38.0000] <jamesr__>
another developer was just confused by trying to interpret what the storage mutex does

[15:29:47.0000] <jamesr__>
which in practice is absolutely nothing, since nobody implements or will ever implement it

[15:31:26.0000] <Hixie>
jamesr__: implementations that don't implement the storage mutex will corrupt user data.

[15:31:29.0000] <Hixie>
jamesr__: so...

[15:32:32.0000] <TabAtkins>
Which is what all implementations do, and plan to continue doing.

[15:33:19.0000] <Hixie>
i'm not writing a spec where the only valid implementation corrupts user data.

[15:33:40.0000] <Hixie>
it's fine if it gives two options, fast and corrupting vs slow and safe, but removing the "safe" option is silly.

[15:34:00.0000] <Hixie>
having said that, i'm happy to make the spec clearer about the fact that all current UAs ignore it, if that would help

[15:34:19.0000] <Hixie>
in other news, https://whatwg.org now has a real cert

[15:34:44.0000] <Hixie>
so https://www.whatwg.org/style/specification should work now

[15:35:34.0000] <Hixie>
at least for the next year

[15:35:38.0000] <Hixie>
then i have to do all this nonsense again

[15:40:02.0000] <annevk-cloud>
We plan to implement it in Servo

[15:40:12.0000] <annevk-cloud>
The storage mutex

[15:43:16.0000] <SimonSapin>
(do we?)

[15:47:44.0000] <annevk-cloud>
roc said so at one point


2014-02-13
[16:04:46.0000] <jamesr__>
Hixie: do you want to spec what browsers do or what you want them to do?

[16:08:01.0000] <jamesr__>
if you want to say "all major UAs ignore this section of the spec and always will" then go ahead

[16:12:54.0000] <Hixie>
i _want_ to spec what i want them to do and then have them follow it :-P

[16:13:07.0000] <Hixie>
but what i want is hardly relevant here

[16:13:25.0000] <Hixie>
jamesr__: the spec does describe what browsers do, since it gives two options (corrupt data, or use locks)

[16:15:22.0000] <zewt>
sounds like it's really describing just one thing, since "use locks" is a subset of "corrupt data" ("corrupt N bytes of data" where N might be 0)

[16:15:49.0000] <zewt>
in other words, it may as well be non-normative "it'd be nice if you did this" instead of hand-wavey normative language

[16:16:01.0000] <Hixie>
?

[16:16:16.0000] <Hixie>
"corrupt data" is not the same as "don't corrupt data"...

[16:16:26.0000] <zewt>
no, it's a superset of it

[16:16:48.0000] <Hixie>
no, they're mutually exclusive

[16:16:57.0000] <zewt>
the amount of data corrupted might happen to be zero, which is equivalent to not corrupting data

[16:18:05.0000] <Hixie>
that's like saying that stabbing yourself is a superset of not stabbing yourself because you might miss.

[16:18:15.0000] <zewt>
i guess the real sort-of-detectable distinguishing point has nothing to do with corruption (or not) of data, but of scripts blocking each other in different tabs

[16:18:35.0000] <Hixie>
the corruption is quite detectable...

[16:19:15.0000] <Hixie>
the only reason the storage mutex exists is to provide an interoperable way to avoid corruption

[16:21:04.0000] <zewt>
put differently, is there something the storage mutex option allows browsers to do that they would otherwise be prohibited from doing?

[16:22:16.0000] <Hixie>
no, it prohibits things, it doesn't allow things

[16:22:39.0000] <Hixie>
it defines observable behaviour

[16:22:54.0000] <Hixie>
that is required (if the browser opts in to it)

[16:23:32.0000] <TabAtkins>
MikeSmith: I'm trying to fix the Editing spec to refer to its stylesheet over https, now that Hixie fixed that issue.  But I get access denied when pushing to the /hg/editing/ repo.  Can you fix this?

[16:23:34.0000] <Hixie>
(and which really should be required of all browsers, but some vendors feel data corruption is no big deal compared to performance of multiple similar-origin tabs)

[16:23:45.0000] <Hixie>
TabAtkins: thanks for doing that

[16:23:57.0000] <TabAtkins>
np

[16:24:29.0000] <zewt>
well, that's the point: giving an option B that does nothing but prohibit things allowed by option A isn't an extra option; they can do it anyway, since if you implement B, you've implemented the requirements of A too

[16:24:36.0000] <zewt>
anyway

[16:24:58.0000] <zewt>
the consequences aren't explosions, just a bit of noise in the spec

[16:27:06.0000] <Hixie>
zewt: there are multiple ways to implement not corrupting data, certainly, but some would be detectably not the same as what the spec allows

[16:27:35.0000] <Hixie>
zewt: (for example, you could do the storage mutex thing but not implement the yield API)

[16:29:35.0000] <Hixie>
jamesr__: (if you do want something in the spec, please file a big at http://whatwg.org/newbug and i'll get to it asap -- i'm in the middle of the focus model rewrite so i can't do it right now)

[16:37:42.0000] <jamesr__>
bug filed. a spec's no place for wishful thinking, as sad as the current state is

[19:52:38.0000] <MikeSmith>
TabAtkins: try now

[21:37:01.0000] <TabAtkins>
MikeSmith: I'll try in the morning.  Thanks!

[21:39:06.0000] <MikeSmith>
k

[01:33:44.0000] <Ms2ger>
And document.all() restored

[01:43:07.0000] <annevk-cloud>
That was quick

[01:43:21.0000] <annevk-cloud>
.tags still dead?

[01:47:44.0000] <Ms2ger>
Yeah

[01:51:14.0000] <zcorpan>
0.03% is too damn high

[01:52:27.0000] <Ms2ger>
And the fact that someone noticed that their bank broke within a week :/

[01:54:22.0000] <annevk_>
esprehn: I think you forgot to reply

[01:54:24.0000] <zcorpan>
bratell's point seems relevant here (we need to know *which* URLs will break, not just how many pageviews)

[01:54:51.0000] <annevk>
Maybe Opera should do its own telemetry ;-)

[01:56:38.0000] <zcorpan>
for finding urls i think the conclusion was that a separate research is needed (like webdevdata but better)

[02:10:36.0000] <zcorpan>
TIL: 'errorVideo' is a really bad variable name

[02:11:37.0000] <darobin>
zcorpan: how so?

[02:12:12.0000] <zcorpan>
darobin: i failed to type it correctly in all places i intended to use the variable

[02:12:28.0000] <zcorpan>
first as 'video' and then 'videoError'

[02:12:33.0000] <darobin>
haha

[02:12:44.0000] <zcorpan>
but it could be that i just suck

[02:13:35.0000] <darobin>
well, if it makes you feel any better, I'm getting close to 20 years of programming and I still can't type "length" without getting it wrong at least once

[02:13:58.0000] <darobin>
this, of course, shows that I'm just dying to become a Python lover

[02:14:20.0000] <zcorpan>
i think my most common typo is documetn

[02:14:48.0000] <zcorpan>
maybe i should make a PR to add that to the dom spec

[02:14:54.0000] <darobin>
lol

[02:15:09.0000] <darobin>
my favourite standards typo is "specifiction"

[02:15:30.0000] <darobin>
https://www.google.com/search?q=specifiction+site%3Aw3.org&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a&channel=fflb

[02:15:50.0000] <annevk>
darobin: coming from a W3C employee, doesn't seem like it has to be a typo :p

[02:16:05.0000] <darobin>
annevk: my point exactly

[02:17:09.0000] <darobin>
annevk: quite fittingly, it shows up in the GCGP introduction http://www.w3.org/TR/2006/WD-css3-gcpm-20060919/

[02:18:02.0000] <darobin>
GCPM

[02:18:23.0000] <darobin>
I reckon I'll actually call my next company "Specifiction"

[02:20:29.0000] <annevk>
darobin: hehe

[03:09:26.0000] <Ms2ger>
Since some people seem to be confused about what's happening to document.all: http://lists.w3.org/Archives/Public/www-archive/2014Feb/0012.html

[03:25:06.0000] <zcorpan>
wpt-serve documentation isn't so discoverable from web-platform-tests or even testthewebforward.org

[03:25:42.0000] <jgraham>
zcorpan: No. That seems fixable though

[03:26:48.0000] <darobin>
zcorpan: just go ahead and patch the readme maybe?

[03:27:36.0000] <zcorpan>
no i prefer to whine in irc and hope someone else fixes it while i enjoy my soup with bacon :-)

[03:27:51.0000] <jgraham>
And pancakes?

[03:28:00.0000] <zcorpan>
no pancakes

[03:28:44.0000] <jgraham>
Breaking with tradition there

[03:29:05.0000] <zcorpan>
wrong kind of soup to boot

[03:29:54.0000] <jgraham>
They'll take away your passport if you're not careful

[03:30:40.0000] <zcorpan>
nsa has my back

[03:51:31.0000] <annevk>
Where is Ms2ger?

[03:56:23.0000] <jgraham>
annevk: Is this a new series of books?

[03:56:44.0000] <jgraham>
You have to spot Ms2ger, but you don't get to know what he looks like

[03:56:53.0000] <annevk>
Why is jgraham obtuse?

[03:57:53.0000] <annevk>
Who is MrLastWeek really?

[04:47:44.0000] <zcorpan>
TabAtkins: i cloned the repo, but i don't have bikeshed installed on this computer so i thought i'd upload to https://api.csswg.org/bikeshed/ instead

[04:52:34.0000] <zcorpan>
Hixie: if you put the stylesheet in resources.whatwg.org it'll get synced to https://w3c-test.org/resources.whatwg.org/

[04:57:45.0000] <zcorpan>
oh you got a cert now, ok

[05:40:31.0000] <bhanu__>
annevk: for surroundContents method, won't HierarchyRequestError be thrown any more as per http://dom.spec.whatwg.org/#dom-range-surroundcontents?

[05:41:29.0000] <annevk>
bhanu__: surroundContents is defined in terms of several other methods that can throw that exception

[05:42:06.0000] <annevk>
/me is studying a range bug as well; https://www.w3.org/Bugs/Public/show_bug.cgi?id=17541

[05:45:09.0000] <Ms2ger>
Ohi annevk

[05:45:25.0000] <annevk>
Ms2ger: I'm thinking of fixing the insertAdjacent stuff

[05:45:36.0000] <Ms2ger>
Which?

[05:45:41.0000] <annevk>
Ms2ger: adding the two methods

[05:45:53.0000] <Ms2ger>
Which?

[05:46:15.0000] <annevk>
Ms2ger: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19962 ?

[05:46:36.0000] <annevk>
Ms2ger: and if we do that I sort of feel we should also merge DOM Parsing into DOM at some point

[05:46:44.0000] <Ms2ger>
Why would you add those?

[05:46:58.0000] <Ms2ger>
/me looks

[05:46:59.0000] <annevk>
Ms2ger: see the bug

[05:47:03.0000] <zcorpan>
TabAtkins: ignoring the biblio thing, api.csswg.org/bikeshed gives me "UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 4282: ordinal not in range(128)" although my source just has ascii (i guess some reference has non-ascii)

[05:47:48.0000] <Ms2ger>
Given that nobody actually filed a Firefox bug about it in the past decade, I'd rather leave it out

[05:49:18.0000] <annevk>
Ms2ger: what's your plan to get others to remove them?

[05:49:28.0000] <Ms2ger>
Whine?

[05:50:10.0000] <Ms2ger>
/me goes back to paying attention to class

[05:56:32.0000] <bhanu__>
annevk: ok

[06:00:17.0000] <Ms2ger>
Styling on https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html works again

[06:04:19.0000] <jgraham>
/me wonders if we can make annevk's official title "Brahma of Web Components"

[06:05:02.0000] <Ms2ger>
Barman of Web Components?

[06:05:25.0000] <jgraham>
Hmm, that might be the wrong god

[06:05:27.0000] <annevk>
"According to the Brahmā Purāņa, he is the father of Manu, and from Manu all human beings are descended." o_O

[06:06:30.0000] <jgraham>
Vishnu

[06:06:32.0000] <jgraham>
Dammit

[06:06:40.0000] <jgraham>
/me starts again

[06:06:54.0000] <jgraham>
/me wonders if we can make annevk's official title "Vishnu of Web Components"

[06:07:13.0000] <jgraham>
(it turns out that my Hindu mythology is weak)

[06:07:38.0000] <jgraham>
dglazkov is presumbably Brahma

[06:08:03.0000] <annevk>
"[Vishnu Sahasranama] describes Vishnu as the all-pervading essence of all beings, the master of—and beyond—the past, present and future, the creator and destroyer of all existences, one who supports, preserves, sustains and governs the universe and originates and develops all elements within."

[06:08:07.0000] <annevk>
Still o_O

[06:08:15.0000] <jgraham>
Heh

[06:08:39.0000] <MikeSmith>
annevk is vighneshvara the remover of obstacles

[06:08:40.0000] <annevk>
But I guess this is a welcome distraction from trying to figure out what the right resolution is for that bug

[06:08:41.0000] <jgraham>
Well I was thinking of it as "the creator, the preservor and the destroyer"

[06:09:15.0000] <jgraham>
So I am trying to pitch you in the role of the one who comes in and tidies up after the creators have made everything, but left a mess ;)

[06:23:29.0000] <GPHemsley>
/me has always wondered how to pronounce "Ms2ger"...

[06:24:03.0000] <Ms2ger>
There's no canonical pronunciation

[06:24:47.0000] <jgraham>
GPHemsley: First expand it to Msmsger

[06:27:09.0000] <GPHemsley>
Miss Messenger?

[06:27:53.0000] <jgraham>
He's actually former "Glamour Model" Melinda Messenger in disguise

[06:28:19.0000] <yoav>
zcorpan: Quick Q. I need a bunch of test cases for a tokenizer based on http://www.w3.org/TR/css3-syntax

[06:29:13.0000] <yoav>
Is there something like that in the test treasure trove that is https://github.com/operasoftware/presto-testo

[06:29:15.0000] <yoav>
?

[06:29:38.0000] <zcorpan>
yoav: don't think so

[06:29:57.0000] <Ms2ger>
Dammit, cover blown

[06:30:17.0000] <Ms2ger>
SimonSapin might have some

[06:33:46.0000] <SimonSapin>
yoav: yes!

[06:33:55.0000] <SimonSapin>
https://github.com/SimonSapin/css-parsing-tests

[06:34:17.0000] <SimonSapin>
and the ED is more up-to-date: http://dev.w3.org/csswg/css-syntax/

[06:35:45.0000] <yoav>
SimonSapin: Awesome!!! Thanks :)

[06:35:58.0000] <SimonSapin>
yoav: these tests are not suitable for a W3C test suit since the tokenizer is not exposed to the platform, but if you’re writing code in an implementation that’s not a problem

[06:37:19.0000] <SimonSapin>
you’ll need to write a test harness to convert whatever memory representation of tokens/component values you have to or from the tests’s JSON structure

[06:37:26.0000] <yoav>
SimonSapin: Yeah, I need them for unit testing, so it's perfect

[06:37:47.0000] <SimonSapin>
feel free to ping me or write a github issue

[06:53:26.0000] <Domenic_>
I always say "emm ess two gee-er"

[06:53:46.0000] <Domenic_>
(... in my head)

[07:02:26.0000] <GPHemsley>
yeah, that's roughly what I do

[07:02:47.0000] <GPHemsley>
the few times I've said it aloud, I generally provide multiple pronunciations

[07:07:55.0000] <zcorpan>
miss-two-ger, emm-ess-two-gee-er, miss-toger, em... es... two... gee... er. yep, him

[07:08:33.0000] <Ms2ger>
- Who?

[07:42:35.0000] <annevk>
cloneContents and extractContents are so similar

[09:11:47.0000] <dglazkov>
good morning, Whatwg!

[09:52:38.0000] <annevk>
dglazkov: objects already have an associated realm or global or whatever you want to call it

[09:52:44.0000] <annevk>
dglazkov: they need one

[09:54:52.0000] <dglazkov>
annevk: the realms are at the horizon of my peripheral vision, I just was coordinatin' :)

[09:55:15.0000] <dglazkov>
I was like, yay realms! and slightlyoff was like, ugh. I was like, wat! I must tell annevk!

[09:55:29.0000] <annevk>
hah

[09:55:56.0000] <dglazkov>
see? I am a coordinator!

[10:00:56.0000] <slightlyoff>
/me is so confused

[10:01:42.0000] <TabAtkins>
zcorpan: Ah, I don't have a way of inlining biblio extensions right now, so the API version won't work.

[10:02:02.0000] <TabAtkins>
zcorpan: What's the source you're using?  I just changed my unicode handling, and am very interested in tracking down remaining bugs.

[10:23:52.0000] <annevk>
slightlyoff: blame dglazkov

[10:24:29.0000] <slightlyoff>
always do. always do.

[10:25:37.0000] <annevk>
Oh man, someone asked me to review the Beacon specification

[10:25:55.0000] <annevk>
Someone should seriously teach those guys how to write a specification, or maybe first code

[10:26:09.0000] <jgraham>
I hear that only takes a day

[10:26:17.0000] <annevk>
They asked: is it ready for LC? I replied: http://lists.w3.org/Archives/Public/public-web-perf/2014Feb/0048.html

[10:26:35.0000] <hober>
annevk: you could ask them to stay after class and write something 100 times on the board

[10:26:43.0000] <annevk>
I almost added, "So, for W3C's purposes this does indeed seem ready for LC."

[10:27:35.0000] <annevk>
But that would be mean, and the people I want to understand that sentiment would probably not get it either

[10:27:37.0000] <jgraham>
They would have taken you seriously

[10:27:54.0000] <jgraham>
(I am not being sarcastic)

[10:28:18.0000] <Ms2ger>
I can confirm that

[10:40:20.0000] <annevk>
hober: oh lol, TabAtkins actually said that o_O

[10:40:27.0000] <TabAtkins>
Hahaha

[10:41:31.0000] <annevk>
Doing Type 4 with sync accessors from the parent is going to be fun

[10:41:48.0000] <annevk>
I really wonder how people imagine something like <video> would work in such a setup

[10:51:51.0000] <TabAtkins>
If not full-on this-is-how-you-explain-crossorigin-iframes Type 4, you at least need something much stronger than anything that has been presented as an example of "Type 2".

[11:01:03.0000] <aklein>
anyone know what the right way to get someone to take a look at a web-platform-tests pull request is? maybe Ms2ger knows?

[11:01:20.0000] <Ms2ger>
aklein, ask me, I guess :)

[11:01:23.0000] <Ms2ger>
aklein, which?

[11:02:53.0000] <aklein>
Ms2ger: https://github.com/w3c/web-platform-tests/pull/624 brings the tests up to spec

[11:03:08.0000] <aklein>
ms2ger: er, the <template> tests

[11:03:13.0000] <Ms2ger>
Ah, shadow stuff

[11:03:29.0000] <Ms2ger>
I'll poke

[11:03:33.0000] <aklein>
not shadow related. or rather, <template> wormholes

[11:03:46.0000] <Ms2ger>
s/shadow/components/

[11:03:53.0000] <Ms2ger>
/me lumps everything in together

[11:04:12.0000] <aklein>
heh, no, must decouple ALL the things! :)

[11:06:59.0000] <aklein>
Ms2ger: I'm especially interested in making sure that I've properly explained which spec change this is about

[11:12:58.0000] <Ms2ger>
aklein, I found a victim :)

[11:28:12.0000] <annevk>
TabAtkins: how then, btw, does Chrome use shadow DOM today to implement some stuff?

[11:28:52.0000] <TabAtkins>
Magic.

[11:29:01.0000] <TabAtkins>
Shadow DOM is an implementation detail there.

[11:30:09.0000] <Domenic_>
what extra magic is necessary?

[11:30:30.0000] <dglazkov>
the magic bit is that we have a nice C++/JS boundary that serves as trust boundary

[11:30:32.0000] <TabAtkins>
All the magic that blocks every leak of shadow access.

[11:30:53.0000] <Ms2ger>
Is that #2?

[11:31:41.0000] <TabAtkins>
Nope, at least not as ever defined in any way by Maciej or others.

[11:32:04.0000] <TabAtkins>
There are lots of data leaks, but only a few of them have ever been mentioned as part of "Type 2".

[11:32:35.0000] <TabAtkins>
It's *possible* that Maciej always meant "the kind of encapsulation that native elements get", but he's never expressed that, and if he does want that, it's a much bigger job.

[11:32:57.0000] <dglazkov>
well, to be fair -- it does have some of type 2 properties. But there's that trust boundary that actually does most of the work.

[11:41:19.0000] <jsbell>
Any AppCache experts/interested parties hereabouts?

[11:49:35.0000] <zcorpan>
TabAtkins: i used picture index.src.html but with s/Cáceres/Caceres/

[12:14:23.0000] <TabAtkins>
zcorpan: Okay, let me check that out.

[13:03:15.0000] <SamB>
hmm, is there a standard that prescribes the behaviour of the "Refresh:" header?

[13:06:50.0000] <Hixie>
jsbell: i'm around if you have a question

[13:07:00.0000] <Hixie>
SamB: the header, or the <meta> pragma?

[13:07:19.0000] <SamB>
Hixie: well, this is in fact the header

[13:07:51.0000] <Hixie>
for the header i don't think there's a spec, but i could be wrong. See IETF.

[13:10:53.0000] <SamB>
So I guess if I said the meta tag, you'd have said "it's in HTML5" or "it's in HTML trunk"?

[13:11:28.0000] <Hixie>
the html standard defines how the pragma works, yeah. http://whatwg.org/html/#attr-meta-http-equiv-refresh

[13:11:52.0000] <jsbell>
Hixie: When an AppCache update fails we'd like to provide some sort of diagnostic that could be e.g. sent back to the server. Right now the "error" event is just an Event, so there's nowhere to stick the message.

[13:12:41.0000] <Hixie>
jsbell: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22702

[13:13:20.0000] <Hixie>
jsbell: i'm kinda waiting to see what happens with service workers before i add anything to appcache, but if you and another vendor are ready to implement now, i can fast-track it

[13:15:23.0000] <SamB>
step 7 of that algorithm looks most unusual ...

[13:16:47.0000] <Hixie>
yeah... welcome to the web

[13:17:58.0000] <jsbell>
Hixie: a sensible stance; we have a real need to pursue this before SW is ready; can't speak for any other vendors, though. I can propose something in the bug. ISTM a semi-generic event type for errors w/ a place to stuff a name + message would be handy in the platform

[13:19:08.0000] <jsbell>
There's ErrorEvent already which has an error property (so, could hold a DOMError/DOMException/js Error); the source/line number fields aren't useful in this case, though.

[13:19:30.0000] <Hixie>
jsbell: if it's a generic string, we'll end up having to spec the exact strings, because authors are gonna do regexps on them

[13:19:39.0000] <Hixie>
jsbell: we'd create a new event, presumably (assuming we just use an event)

[13:20:03.0000] <Hixie>
jsbell: more information on exactly what the need is would be good to add to the bug

[13:20:11.0000] <SamB>
hmm, looks like Firefox does exactly the same thing with an actual Refresh header

[13:20:52.0000] <Hixie>
seems plausible

[13:57:25.0000] <SamB>
hmm, it would be cool if there was a "diff" view between the latest html5 "release" and html5 tip ...

[13:57:42.0000] <Hixie>
there is

[13:58:04.0000] <SamB>
yeah, I was just about to say "oh, it looks like there is"

[13:58:08.0000] <Hixie>
http://html5.org/tools/web-apps-tracker?from=8476&to=8477 is the diff between the "html tip" and the last thing we released

[13:58:19.0000] <Hixie>
http://html5.org/tools/web-apps-tracker for the home page

[13:58:46.0000] <SamB>
but wow is that overwhelming ...

[13:58:50.0000] <Hixie>
(s/last thing/previous thing/, i guess)

[13:59:05.0000] <SamB>
I'm not quite *that* pedantic

[13:59:20.0000] <Hixie>
uncheck "show editorial checkins" or whatever it's called

[13:59:26.0000] <Hixie>
it'll remove the minor stuff

[14:01:56.0000] <SamB>
hmm, mediawiki's diff-picking UI (with the radio buttons plus the "current" and "prev" links on each row) is better

[14:03:01.0000] <Hixie>
patches welcome :-)

[14:04:15.0000] <Hixie>
i _think_ the source is https://code.google.com/p/html5/source/browse/#svn%2Ftrunk%2Fweb-apps-tracker but it might have moved to github

[14:04:21.0000] <SamB>
yeah, I might have more hope of patching this than of building the spec (or was that validator.nu?) on OS X 10.5 ...

[14:04:53.0000] <SamB>
Hixie: see, this is why you should link to source for the webapp in question from the bottom of each page

[14:05:12.0000] <Hixie>
patches welcome for that too :-)

[14:05:17.0000] <Hixie>
i didn't write that

[14:05:25.0000] <Hixie>
that was mainly anne, i think

[14:05:44.0000] <Hixie>
ah, no, latest source is at https://github.com/whatwg/web-apps-tracker

[14:06:05.0000] <SamB>
and that patch would presumably be a great deal easier even than the diff-picking

[14:07:06.0000] <SamB>
/me wonders why he has an empty ~/hacking/whatwg directory ...

[14:07:31.0000] <Hixie>
check when you created it, then check irc logs for that day :-)

[14:08:39.0000] <SamB>
too late, I modified it now

[14:12:25.0000] <SamB>
Hixie: you seem to have assigned some rather unusual semantics to span ;-)

[14:12:36.0000] <Hixie>
hm?

[14:13:32.0000] <SamB>
in the spec sources I mean

[14:13:44.0000] <Hixie>
oh, for cross-references?

[14:13:45.0000] <Hixie>
yeah

[14:13:56.0000] <Hixie>
it gets all preprocessed and the <span>s go away in the output, mostly

[14:14:06.0000] <Hixie>
the source file isn't realy HTML

[14:14:23.0000] <Hixie>
it's HSML ("HTML Specification Markup Language")

[14:14:40.0000] <Hixie>
which is strongly influenced by HTML, certainly...

[14:14:41.0000] <SamB>
then why use an existing element name at all for that?

[14:14:57.0000] <Hixie>
inertia from a previous time where we used a different preprocessor

[14:15:05.0000] <SamB>
/me is reminded a bit of Lore, though that's not so un-HTML

[14:15:27.0000] <Hixie>
i'm slowly making myself a new pipeline that'll let me change all this to me much saer

[14:15:30.0000] <Hixie>
saner

[14:15:42.0000] <Hixie>
but it's one free-time project of many

[14:18:46.0000] <SamB>
<http://twistedmatrix.com/documents/current/lore/howto/lore.html>, which I clicked through surprisingly many links to get to, gives a very clear idea of what lore does, I think

[14:19:32.0000] <Hixie>
yeah, there's lots of variants like this around

[14:19:41.0000] <Hixie>
even in the web spec world there's like half a dozen

[14:20:44.0000] <SamB>
I guess nowadays you could even do most/all of that in JS ...

[14:21:05.0000] <Hixie>
ideally a spec should be readably without JS, but yeah

[14:21:40.0000] <SamB>
I was thinking it might be handy for previewing, if it could be faithful to the other version

[14:22:02.0000] <SamB>
or I guess we have crazy things like node.js that might let us use the same thing for both

[14:22:37.0000] <Hixie>
to be honest, given the size of the html spec, the processing isn't likely to be very fast when it comes to previewing, JS or not

[14:22:42.0000] <Hixie>
(i rarely preview, heh)

[14:23:28.0000] <Hixie>
i realised the other day that the file i edit is literally 5% of the size of the first hard disk i had growing up

[14:23:35.0000] <SamB>
/me was also thinking aloud about what *lore* does, which is much less

[14:23:46.0000] <Hixie>
and wouldn't even remotely fit in the RAM of that computer, let alone earlier ones i used

[14:25:38.0000] <TabAtkins>
Nearly all specs are written as not-quite-HTML.

[14:25:56.0000] <TabAtkins>
And then passed through either Anolis or Bikeshed, or include the ReSpec js library for formatting client-side.

[14:26:06.0000] <TabAtkins>
Hixie just uses a really hacked-up version of Anolis.

[14:26:32.0000] <Hixie>
it's anolis, it just has some stuff in front and behind it

[14:27:09.0000] <TabAtkins>
ah, ok.

[14:27:34.0000] <TabAtkins>
Oh, and I forgot that SVG uses an XSLT thing as their formatter.

[14:27:49.0000] <TabAtkins>
With Dirk doing some of his fxtf specs by starting with the XSLT transformer and then passing through Bikeshed.

[14:28:00.0000] <Hixie>
there's also bert's old thing, dunno if anyone is using that any more, which was the tool that predated anolis

[14:28:14.0000] <TabAtkins>
A handful of CSS specs are still using it, but I've changed over at least half of the repo.

[14:28:29.0000] <TabAtkins>
Just converted another spec this afternoon.

[14:28:44.0000] <heycam>
TabAtkins, what?

[14:28:53.0000] <TabAtkins>
heycam: Don't you?

[14:28:55.0000] <heycam>
TabAtkins, oh that changed a while ago. it's pure JS now.

[14:28:59.0000] <heycam>
(a while = about a year ago)

[14:29:00.0000] <TabAtkins>
Oh, didn't realize!

[14:29:11.0000] <Hixie>
and that would make 6 :-)

[14:29:29.0000] <heycam>
Removing forceRedraw, suspendRedraw, unsuspendRedraw from SVG2

[14:29:31.0000] <heycam>
er

[14:29:32.0000] <heycam>
https://svgwg.org/hg/svg2-tools/file/ee0a80076e9b/publish

[14:29:57.0000] <heycam>
Web IDL is still XSLT though ;)

[14:30:09.0000] <SamB>
ah, https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html is looking much nicer today. Thanks, TabAtkins and Hixie and whoever you needed help from!

[14:30:31.0000] <TabAtkins>
Ms2ger actually did it, and then I *also* did it without realizing he'd already done the work.

[14:30:52.0000] <SamB>
well, thanks to him too then ;-)

[14:30:53.0000] <TabAtkins>
Ugh, still doesn't have a max-width.

[14:31:01.0000] <TabAtkins>
max-width:50em or gtfo

[14:31:32.0000] <Hixie>
<crazy wolf>just increase your font size</crazy wolf>

[14:32:19.0000] <SamB>
speaking of max-width, I was trying to find a way to apply that to anonymous block-level boxes that hold inline-level boxes ...

[14:32:34.0000] <Hixie>
css really needs a way to address those

[14:32:36.0000] <SamB>
or something like that

[14:32:46.0000] <TabAtkins>
Hixie: Yes, we do. :/

[14:32:48.0000] <Hixie>
/me has no idea how to do it, though

[14:32:56.0000] <Hixie>
i tried with the whoel move-to thing, but that sucks ass

[14:34:00.0000] <SamB>
so that I could make mediawiki stuff use a limited text width, without also cramming everything else into the same space, and so that indented blocks wouldn't have to be narrower necessarily

[14:35:58.0000] <SamB>
if you want to see what I *don't* want, try out the typography revamp beta on any of WMF's sites (wikipedia being the most popular) ;-)

[14:37:24.0000] <SamB>
Oh, have I mentioned my puzzlement as to why Selection needs to be bundled with *all* of those editing commands?

[14:37:53.0000] <Hixie>
the stuff in that spec is mostly the stuff aryeh worked on

[14:38:13.0000] <SamB>
so basically because Ranges died?

[14:38:16.0000] <Hixie>
really there should be one spec called "The Web Living Standard"

[14:38:24.0000] <Hixie>
but we've split it up for ease of editing

[14:38:33.0000] <Hixie>
so all the stuff I edit is in the HTML Standard, for instance

[14:38:47.0000] <Hixie>
Anne splits his parts up even more

[14:38:55.0000] <Hixie>
anyway, Range is in dom.spec.whatwg.org

[14:38:59.0000] <SamB>
not for ease of explaining piecemeal implementation?

[14:39:12.0000] <Hixie>
no, definitely not for that

[14:39:25.0000] <Hixie>
everything on the web is interconnected

[14:39:27.0000] <Hixie>
especially the old stuff

[14:39:35.0000] <Hixie>
like selection, dom, html, etc

[14:39:51.0000] <Hixie>
webidl, js...

[14:41:51.0000] <SamB>
true

[15:13:41.0000] <Hixie>
so... is there a spec that has a "must" for firing key-related events?

[15:20:18.0000] <jamesr__>
is there a spec that has even a "should" for firing key events?

[15:20:30.0000] <jamesr__>
afaik nobody even tries

[15:24:05.0000] <Hixie>
yeah, that's what i feared

[15:24:11.0000] <Hixie>
i'm speccing where the events should go, fwiw

[15:24:16.0000] <Hixie>
but not which ones they should be!

[15:34:18.0000] <TabAtkins>
Hixie: Any clue why <dfn>s can't be nested?

[15:34:28.0000] <Hixie>
what would it mean?

[15:34:36.0000] <TabAtkins>
...two <dfn>s?

[15:34:46.0000] <TabAtkins>
I have an example of it in my spec, and the validator's flagging it. :/

[15:34:55.0000] <Hixie>
paste the example here?

[15:35:10.0000] <Hixie>
it's invalid because i had never seen a use case for it and it seemed likely to be an unintentional mistake

[15:35:16.0000] <Hixie>
but if there's valid use cases, it can be valid

[15:35:43.0000] <TabAtkins>
http://dev.w3.org/csswg/css-font-loading/#dom-fontface-fontface

[15:35:47.0000] <Hixie>
(wouldn't it be really confusing to the user?)

[15:35:50.0000] <Hixie>
/me looks

[15:35:58.0000] <TabAtkins>
The Constructor function is <dfn>d, but so are the arguments to the function.

[15:36:23.0000] <Hixie>
why are the arguments <dfn>ed? that doesn't give the definition of the arguments

[15:36:58.0000] <Hixie>
that's very confusing

[15:37:11.0000] <Hixie>
with the multiple #-links showing up and all

[15:37:26.0000] <Hixie>
i can't tell what's actually being defined

[15:37:48.0000] <Hixie>
(as a side note, you have a method called Constructor()?)

[15:37:48.0000] <TabAtkins>
The arguments don't have an independent definition.  That's the best place to put it.

[15:37:57.0000] <TabAtkins>
No, it's the constructor itself.

[15:37:58.0000] <Hixie>
i wouldn't bother <dfn>ing the arguments at all

[15:38:02.0000] <TabAtkins>
those are called Constructor in webidl.

[15:38:12.0000] <Hixie>
ah ok. s/method/constructor/ then probably

[15:38:32.0000] <TabAtkins>
That's cool, but Bikeshed's data model includes it, which lets me link directly to those arguments.

[15:38:40.0000] <TabAtkins>
And distinguish each use from other argumetns of the same name.

[15:38:50.0000] <Hixie>
(also, the constructor has a name (the interface name), so s/Constructor/whateveritsnameis/)

[15:39:23.0000] <TabAtkins>
All right, sure.

[15:39:40.0000] <Hixie>
i guess if i had to do this, i'd put the <dfn> for the constructor around its name, then put the arguments after it, much like i do in the domintro blocks

[15:40:04.0000] <Hixie>
as in, <code><dfn>MyFoo</dfn>(DOMString <dfn>arg</dfn>)</code>

[15:40:15.0000] <TabAtkins>
But why?

[15:40:18.0000] <Hixie>
that would make it clearer what the terms were

[15:40:38.0000] <TabAtkins>
If I don't have separatley-defined arguments, I'd definitely do <dfn>foo()</dfn>

[15:40:52.0000] <Hixie>
i mean, the constructor isn't called "Constructor(DOMString family)", it's called "Constructor" (or actually, "FontFace")

[15:41:14.0000] <TabAtkins>
That's a notation convention, not an absolute fact.

[15:41:23.0000] <Hixie>
(another side note, clicking FontFace in the IDL takes me to a 404)

[15:41:39.0000] <TabAtkins>
In prose, I usually write them as foo().

[15:42:09.0000] <Hixie>
i agree

[15:42:20.0000] <TabAtkins>
Yeah, that 404 is temporary - I just moved some things.

[15:42:20.0000] <Hixie>
what i tend to do these days is actually not duplicate the arguments there

[15:42:34.0000] <Hixie>
i just leave them in the IDL and don't bother in the prose

[15:42:42.0000] <Hixie>
and i refer to them as foo()

[15:42:46.0000] <Hixie>
(methods and constructors)

[15:43:06.0000] <Hixie>
mostly i started doing that because it got really hard to write the prose with optional arguments and overloads and so on otherwise

[15:43:39.0000] <Hixie>
note that the argument names are arbitrary, which would be another reason <dfn> would be inappropriate for them

[15:43:49.0000] <Hixie>
since you're not really defining that term per se

[15:44:17.0000] <Hixie>
i mean, it's a "local" definition, i guess, for the sake of the following prose

[15:44:33.0000] <Hixie>
but to the reader it's a bit confusing to have a <dfn>-level definition for that, imho

[15:44:40.0000] <Hixie>
makes them seem more formally defined than they relaly are

[15:44:42.0000] <Hixie>
really

[15:45:31.0000] <TabAtkins>
Arguments do have defined names.

[15:45:41.0000] <TabAtkins>
You can't see that when calling, but that doesnt' change the fact that they're defined.

[15:46:49.0000] <TabAtkins>
One thing that might be confusing you is that your publishing pipeline only has global definitions.

[15:47:18.0000] <TabAtkins>
Bikeshed's definition data model has nesting relationships - this is defining the "family" argument for the "FontFace()" method of the "FontFace" interface.

[15:48:06.0000] <Hixie>
i'm not confused :-)

[15:48:31.0000] <Hixie>
argument names to IDL-defined methods and constructors are arbitrary, they're just a spec editing help

[15:48:43.0000] <Hixie>
you could name them all arg1, arg2, arg3, etc and it wouldn't change anything normatively detectable

[15:48:53.0000] <Hixie>
s/normatively/black-box/

[15:49:01.0000] <TabAtkins>
They're 'arbitrary' in the same sense that every term in every spec is arbitrary.

[15:49:16.0000] <Hixie>
right

[15:49:26.0000] <Hixie>
as opposed to the method name, which isn't arbitrary, say

[15:49:43.0000] <Hixie>
anyway that's a side issue

[15:49:51.0000] <TabAtkins>
Exactly. ^_^

[15:50:27.0000] <Hixie>
as far as <dfn> goes, the point is just that it's confusing to users to have nested <dfn>s. to put it as you might put it: "one thing that might be confusing you is that bikeshed's data model has nesting relationships"

[15:50:32.0000] <Hixie>
whereas people don't tend to think that way

[15:50:41.0000] <TabAtkins>
...yes they do.

[15:50:49.0000] <TabAtkins>
A given "auto" value belongs to a particular property.

[15:50:53.0000] <TabAtkins>
That's nesting.

[15:51:04.0000] <TabAtkins>
There are like 30 different definitions (or more) of "auto" in CSS.

[15:51:06.0000] <Hixie>
it's a hierarchy, sure

[15:51:14.0000] <Hixie>
"nesting" implies more than hierarchy though

[15:51:31.0000] <Hixie>
it implies scoping

[15:51:32.0000] <TabAtkins>
I'm implying hiearchy.

[15:51:54.0000] <TabAtkins>
...never mind.  Let's not have random semantic debates, because they aren't winnable by either side.

[15:52:08.0000] <Hixie>
k

[15:52:12.0000] <TabAtkins>
Back to the question - I provided a valid use of nested definition.

[15:52:19.0000] <TabAtkins>
nested <dfn>s, rather.

[15:52:30.0000] <Hixie>
whether it's valid or not depends entirely on the semantic debate we were having

[15:52:56.0000] <Hixie>
imho it's not valid, it's obviously confusing to the reader and is semantically wrong in that the term you're defining doesn't include the other term.

[15:53:35.0000] <Hixie>
and, the other term probably shouldn't be <dfn>-defined anyway because it's arbitrary and local to that algorithm.

[15:53:42.0000] <TabAtkins>
Only if you're inferring something weird.  A <dfn> is just a <dfn>.  The fact that, in this case, the inner definitions are nested in the outer definition, mirroring the markup structure, is irrelevant.

[15:54:28.0000] <TabAtkins>
The inner <dfn>s don't change meaning just because there's another <dfn> wrapped around them.  The outer <dfn> treats every other inline contained within it neutrally; there doesn't seem to be any reason why it should treat a contained <dfn> differently

[15:55:08.0000] <Hixie>
i do not disagree with what you are saying, but what you're saying is orthogonal to the problems i described.

[15:55:15.0000] <TabAtkins>
You're using "arbitrary" as a synonym for "not web-exposed".  That's not a useful definition when we're discussing spec definition models.

[15:55:34.0000] <Hixie>
no, i mean "arbitrary" as in "the name doesn't matter"

[15:55:53.0000] <TabAtkins>
Yes, but saying "this definition is arbitrary, thus it shouldn't be <dfn>'d" is wrong.

[15:56:18.0000] <TabAtkins>
Important terms in specs are <dfn>'d all the time.

[15:56:56.0000] <TabAtkins>
If you're just saying that you don't think *method arguments* are sufficiently useful to justify <dfn>ing, that's a cool opinion, but I differ in it.

[15:57:02.0000] <TabAtkins>
And it's irrelevant here.

[15:57:24.0000] <Hixie>
i think i could be convinced that <dfn>-defining arguments to algorithms before the algorithm is defensible, but if one did do that, i do not think doing it via nested <dfn> would be a good way to do it.

[15:58:14.0000] <TabAtkins>
In many cases you wouldn't.  In a case like what I'm showing you, you do, because that's the syntactic convention I've adopted for defining methods.

[15:58:38.0000] <Hixie>
sure. we're debating the relative worthiness of that convention.

[15:59:08.0000] <TabAtkins>
Well, we're debating whether it's sufficiently incorrect as to be worth making *invalid*.

[15:59:52.0000] <Hixie>
right, i'm arguing it's confusing to the reader, semantically dubious since the names involved aren't really the ones you're marking up, and doesn't justify making validators no longer flag (likely accidentally) nested <dfn>s


2014-02-14
[16:00:27.0000] <TabAtkins>
Your "confusing to the reader" argument is based on the simplistic styling conventions I'm currently using to provide permalinks to <dfn>s.

[16:00:32.0000] <Hixie>
seriously, i find that presentation really confusing.

[16:00:42.0000] <TabAtkins>
A different styling would negate your argument; it's not generally valid.

[16:00:58.0000] <Hixie>
the whole thing is bold italics, and as i hover over it i get permalinks that and i can't work out what they're for

[16:01:14.0000] <Hixie>
it's not helpful to define the term but not show what the term is

[16:01:24.0000] <TabAtkins>
That's cool, *but it's an argument against my current simplistic styling, not the markup*.

[16:01:45.0000] <Hixie>
no, whether it's confusing or not has to be determined in the absence of any styling.

[16:01:55.0000] <Hixie>
it'd be much clearer if they were sibling elements

[16:01:57.0000] <TabAtkins>
The "definition" of the family argument is "family is an argument to the FontFace function", which is implicit in the text it's embedded in.

[16:02:01.0000] <Hixie>
with punctuation between them

[16:02:09.0000] <TabAtkins>
???

[16:02:32.0000] <Hixie>
as in, <code><dfn>FontFace</dfn>(DOMString <dfn>family</dfn>, ...)</code> like i suggested earlier

[16:03:25.0000] <TabAtkins>
You're trying to argue that <dfn>FontFace</dfn>() is, in general, better than <dfn>FontFace()</dfn>?

[16:03:49.0000] <Hixie>
no, i'm arguing it's better if you also want to <dfn> the arguments.

[16:03:54.0000] <Hixie>
in the no-argument case i think it's a wash

[16:04:15.0000] <TabAtkins>
So you're arguing that I should change the markup of a function definition based on whether or not I'm defining other things vaguely related to it?

[16:04:26.0000] <Hixie>
(you could argue it either way, i mean, it's common to think of the method as "foo()", but really it's called "foo")

[16:04:33.0000] <TabAtkins>
And that it's important enough that it should be considered invalid to not do that?

[16:04:47.0000] <Hixie>
i'd recommend being consistent throughout, personally

[16:05:14.0000] <Hixie>
i do think the confusion resulting from nesting <dfn>s like this is important enough that it should be considered invalid, yes, based on this example at least

[16:06:04.0000] <Hixie>
(gotta go, mtg)

[16:06:04.0000] <TabAtkins>
Ignoring the permalinks, you wouldn't be confused in the slightest.

[16:06:20.0000] <TabAtkins>
The permalinks are something I added myself - they are completely unconnected to the example.

[16:06:23.0000] <Hixie>
(ignoring the permalinks, i'd be completely unaware of the inner <dfn>s, meaning they'd be pointless)

[16:06:30.0000] <Hixie>
(afk)

[16:06:42.0000] <TabAtkins>
They're link targets!

[16:06:49.0000] <zewt_>
hixie plays magic the gathering

[16:07:05.0000] <TabAtkins>
...and?

[16:07:09.0000] <TabAtkins>
Ah, mtg

[16:07:12.0000] <TabAtkins>
Okay.

[16:18:42.0000] <jamesr__>
TabAtkins: you're setting a bad example for all the kids reading public-webapps. tsk tsk

[16:19:17.0000] <TabAtkins>
Urgh, now I have to either add more explicit metadata to the nested argument definitions and type links, or add a dummy <span> around the whole thing solely to move the metadata args to.

[16:21:31.0000] <zewt>
the shitty attempts at moderation are the most common thing that make me consider unsubscribing from that list; they're always much more unpleasant than anything they're in response to

[02:19:20.0000] <mathiasbynens>
what is the expected behavior here? data:text/html,<img%20name=anchors><img%20name=anchors><script>document.write(document.anchors.length)</script>

[02:19:30.0000] <mathiasbynens>
i’d expect 1 based on http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-tree-accessors

[02:24:40.0000] <mathiasbynens>
which spec says <img name=foo> → `document.foo`? and does that spec explicitly override DOM tree accessors or not?

[02:39:30.0000] <mathiasbynens>
via https://twitter.com/RobbertAtWork/status/434273199648284672 and http://robbertbroersma.nl/demo/kill-document/

[03:31:45.0000] <annevk>
mathiasbynens: seems you missed "getter object (DOMString name)" on Document

[03:31:58.0000] <annevk>
mathiasbynens: http://www.whatwg.org/specs/web-apps/current-work/#dom-document-nameditem

[03:32:13.0000] <annevk>
mathiasbynens: also exists on Window but works a bit differently

[03:40:39.0000] <mathiasbynens>
ah, so DOM tree accessors don’t magically take precedence

[03:40:40.0000] <mathiasbynens>
thanks

[03:45:46.0000] <annevk>
mathiasbynens: because of the [OverrideBuiltins] annotation

[03:53:19.0000] <MikeSmith>
/me wonders if tyoshino__ made it home before the blizzard arrived

[03:54:57.0000] <annevk>
TabAtkins: I don't get why you'd <dfn> an argument either, fwiw

[03:55:11.0000] <annevk>
TabAtkins: the definition is for the method, including its parameters

[03:55:25.0000] <annevk>
TabAtkins: you're not defining the parameters independently from the method

[03:55:39.0000] <annevk>
TabAtkins: (and if you are, that's old-style DOM stuff and wrong)

[03:59:52.0000] <yoav>
TabAtkins & SimonSapin: I'm having some trouble implementing http://dev.w3.org/csswg/css-syntax/#consume-a-number

[04:06:07.0000] <MikeSmith>
annevk: dunno if you're following the recent Streams discussions but do you know is it correct that the plan is to eventually have the ecmascript spec define a Streams abstraction

[04:07:09.0000] <annevk>
MikeSmith: Domenic_ certainly envisions it that way

[04:07:39.0000] <MikeSmith>
ok

[04:07:57.0000] <annevk>
MikeSmith: I get the impression ECMAScript wants to define all the things that make sense across embedding environments, which would also include URLs, encodings, etc.

[04:08:09.0000] <MikeSmith>
oh

[04:08:20.0000] <MikeSmith>
that would be ideal

[04:08:36.0000] <MikeSmith>
as long as they don't mess it all up at least

[04:09:11.0000] <MikeSmith>
I mean to have it define all in once place for all JS environments, including no-browser onces

[04:10:24.0000] <MikeSmith>
a problem I see with

[04:10:56.0000] <MikeSmith>
one problem I see with this plan is that TC39 is not famous for getting things done quickly

[04:11:49.0000] <Ms2ger>
I certainly don't think the JS spec is the right place to define URLs

[04:12:10.0000] <MikeSmith>
has Promises already been folded into the ecmascript draft yet?

[04:12:37.0000] <annevk>
MikeSmith: yes

[04:12:59.0000] <annevk>
Ms2ger: it seems like a good place for the API, certainly

[04:13:06.0000] <MikeSmith>
Ms2ger: maybe not the URL abstract definition

[04:13:10.0000] <MikeSmith>
what annevk said

[04:13:17.0000] <Ms2ger>
Oh, URL api, I guess

[04:15:03.0000] <Ms2ger>
What do people think about moving the editing spec to github/whatwg, btw?

[04:15:06.0000] <SimonSapin>
yoav: How so?

[04:15:45.0000] <annevk>
SimonSapin: oreolunch in 30min, better get to the office

[04:15:58.0000] <SimonSapin>
oreolunch?

[04:16:03.0000] <annevk>
Ms2ger: well we can move things around, but is someone going to maintain it?

[04:16:14.0000] <Ms2ger>
Not it :)

[04:16:34.0000] <MikeSmith>
annevk: I wish Jason would generate a multipage version of the ES6 draft. I wonder if he's using python to generate it

[04:16:50.0000] <MikeSmith>
(to generate the single-age one I mean)

[04:16:56.0000] <Ms2ger>
MikeSmith, the code is on github, I think

[04:17:03.0000] <MikeSmith>
k

[04:17:49.0000] <MikeSmith>
Ms2ger: I say yeah I don7t see any good reason not to move the editing spec to github/whatwg

[04:17:53.0000] <annevk>
Ms2ger: also, you suggesting moving something to GitHub is funny

[04:18:01.0000] <Ms2ger>
It is

[04:18:16.0000] <annevk>
MikeSmith: it loads quite quickly for me

[04:18:17.0000] <MikeSmith>
where would Ms2ger normally prefer to move things?

[04:18:23.0000] <annevk>
MikeSmith: are you on your phone again? :p

[04:18:29.0000] <MikeSmith>
hehah

[04:18:31.0000] <Ms2ger>
hg.whatwg.org ;)

[04:18:47.0000] <MikeSmith>
ah

[04:19:18.0000] <yoav>
 SimonSapin: I think that a "reconsume" is missing in http://dev.w3.org/csswg/css-syntax/#consume-a-token in the digit section

[04:19:32.0000] <yoav>
before the "consume a numeric token"

[04:19:47.0000] <MikeSmith>
annevk: yeah I was loading it on my phone. which is a valid use case

[04:20:05.0000] <yoav>
The way it is specced, the first digit is consumed, and then not added to the number

[04:20:21.0000] <yoav>
Unless I'm missing something, which is highly possible

[04:20:24.0000] <annevk>
MikeSmith: yeah fair

[04:20:43.0000] <MikeSmith>
annevk: but yeah it's hardly a normal case

[04:22:15.0000] <MikeSmith>
hmm I see python in Jason's repo so I bet Philip` spec splitter could be modified to split it. I guess I should try it

[04:29:43.0000] <mathiasbynens>
MikeSmith, Ms2ger: https://github.com/jorendorff/es-spec-html/issues/5

[04:33:00.0000] <annevk>
MikeSmith: make http://es.github.io/ as ES living standard :-)

[04:38:50.0000] <SimonSapin>
yoav: there may be a spec bug. Could you write to www-style with the details?

[04:39:25.0000] <yoav>
SimonSapin: Sure

[04:39:36.0000] <yoav>
Is the spec on GitHub by any chance?

[04:39:46.0000] <yoav>
if so, I can open an issue there

[04:39:53.0000] <SimonSapin>
there is a github mirror of the repo

[04:39:59.0000] <SimonSapin>
but we don’t use github for issue tracking

[04:40:04.0000] <yoav>
OK

[04:40:21.0000] <SimonSapin>
https://github.com/w3c/csswg-drafts

[04:41:00.0000] <SimonSapin>
The "main" repo is https://dvcs.w3.org/hg/csswg

[04:41:46.0000] <SimonSapin>
yoav: or if you’d rather not subscribe on www-style, email me

[04:42:17.0000] <yoav>
I'm subscribed to www-style, just have a hard time spamming everyone with this bug :)

[04:42:29.0000] <yoav>
But I'll get over it

[04:42:30.0000] <SimonSapin>
don’t worry about that

[04:42:59.0000] <SimonSapin>
it’s what the list is for

[04:43:14.0000] <Domenic_>
Hah! Worries about mail volume on www-style! Now I've heard everything.

[04:44:19.0000] <yoav>
Domenic_: That's exactly why I'd rather avoid mailing it to the list :)

[04:45:32.0000] <annevk>
CSS has Bugzilla as well...

[04:45:49.0000] <annevk>
I usually use that as email tends to get lost and forgotten

[04:46:33.0000] <yoav>
annevk: Is it open for non members?

[04:46:52.0000] <annevk>
yoav: yeah is

[04:47:02.0000] <yoav>
OK, will try that

[04:47:05.0000] <yoav>
Thanks!

[04:47:11.0000] <annevk>
yoav: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=CSS

[04:56:08.0000] <yoav>
SimonSapin: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24661

[04:57:09.0000] <SimonSapin>
yoav: why did you go there?

[04:58:07.0000] <SimonSapin>
CSSWG has too many fucking ways to track issues

[04:58:07.0000] <yoav>
annevk suggested to open a bug there

[04:58:13.0000] <SimonSapin>
I need an issue tracker tracker

[04:58:22.0000] <yoav>
Sorry

[04:58:53.0000] <yoav>
I can send it to the list if you prefer

[05:00:11.0000] <SimonSapin>
annevk: Buzilla bugs can get lost and forgotten just as easily. I recently discovered that the specs *I’m* editing had bugs on Bugzilla

[05:01:53.0000] <SimonSapin>
Everything is broken and nobody cares

[05:23:39.0000] <MikeSmith>
mathiasbynens: ah thanks I remember that now. I should get around to trying it and just implement a PR

[05:24:46.0000] <MikeSmith>
annevk: yeah I could just make http://es.github.io/ redirect to Jason's HTML

[05:25:57.0000] <MikeSmith>
oh if I owned "es"

[05:27:22.0000] <MikeSmith>
hey I do own http://ecmascript.github.io/ though

[05:44:40.0000] <MikeSmith>
http://ecmascript.github.io/ now redirects to the latest, and will http://es-spec.github.io/ soon hopefully too

[05:49:22.0000] <MikeSmith>
and http://es6.github.io/ for now

[07:36:45.0000] <JakeA>
annevk: Looking at serviceWorker.ready()… any idea what the use-cases are for it?

[07:38:21.0000] <annevk>
JakeA: no

[07:39:48.0000] <JakeA>
annevk: Ok, not just me then

[07:40:20.0000] <annevk>
JakeA: yeah, I asked in the bug; it seems like you need to use register() anyway

[07:40:38.0000] <JakeA>
annevk: I'm not even sure what "ready" means

[07:40:41.0000] <gsnedders>
Ms2ger: Can we try removing the lxml dependency from Anolis? It should be way quicker in PyPy, because basically all the cost is overhead.

[07:40:52.0000] <JakeA>
annevk: Does it mean when it becomes the active worker?

[07:40:55.0000] <Ms2ger>
We can :)

[07:41:51.0000] <gsnedders>
Ms2ger: Either that or rewrite it in Haskell ;P

[07:41:53.0000] <annevk>
JakeA: yeah I thought maybe that's it

[07:42:03.0000] <annevk>
JakeA: that would be somewhat different from register() anyway

[07:42:12.0000] <annevk>
JakeA: but we also have an event for that

[07:42:20.0000] <Ms2ger>
Not that :)

[07:42:40.0000] <JakeA>
annevk: But register() is the only place you can a non-active worker

[07:43:04.0000] <JakeA>
annevk: Yeah, and we decided that a promise wasn't the right fit, because .active can change without a call to registration

[07:43:16.0000] <JakeA>
annevk: and it can change multiple times over the life of a page

[07:43:19.0000] <annevk>
JakeA: I thought the idea was that if you did getAll() you would get all workers, regardless of whether they are active

[07:43:41.0000] <Domenic_>
NOT USING PROMISES FOR SOMETHING!? IMPOSSIBRU

[07:43:56.0000] <JakeA>
:D

[07:44:14.0000] <Domenic_>
I am pretty sure Alex had a use case for serviceWorker.ready()

[07:44:25.0000] <JakeA>
annevk: ahh ok, yeah, that's possible, I can't remember

[07:44:29.0000] <Domenic_>
https://gist.github.com/slightlyoff/8927885

[07:44:42.0000] <Domenic_>
hmm you guys already seem to be talking about relevant things like .active so you are probably way ahead of me on this

[07:46:02.0000] <annevk>
JakeA: hmm, looking at it now ready() makes sense for code that doesn't want to deal with registration and still needs to get a handle on things

[07:46:11.0000] <annevk>
JakeA: e.g. a library that does push as per Domenic_'s link

[07:46:30.0000] <JakeA>
annevk: Isn't .active already the handle you need?

[07:47:57.0000] <jgraham>
gsnedders: Rewrite in in rust :p Of course you would need to start by writing a HTML parser and tree library…

[07:48:33.0000] <gsnedders>
jgraham: :P

[07:48:37.0000] <annevk>
JakeA: so yeah

[07:48:47.0000] <gsnedders>
jgraham: Yeah, Haskell's still sounding better.

[07:48:57.0000] <annevk>
JakeA: except if you want to wait for a possible register() call, but I'm not really sure how that could work so indeed

[07:49:07.0000] <gsnedders>
I mean, at the end of the day Anolis is just a transformation from one tree to another!

[07:49:31.0000] <JakeA>
annevk: and the registration call may have come from another tab, so the 'activate' event is better in this case

[07:49:58.0000] <annevk>
right, given the event this makes little sense

[07:50:12.0000] <JakeA>
annevk: will add this to the ticket

[08:04:54.0000] <JakeA>
annevk: Tried to make it clearer https://github.com/slightlyoff/ServiceWorker/issues/174#issuecomment-35096632

[08:05:33.0000] <annevk>
JakeA: ta

[08:13:41.0000] <JakeA>
Domenic_: annevk: In https://gist.github.com/slightlyoff/8927885, is the serviceworker the only place you could receive push messages?

[08:23:24.0000] <annevk>
Domenic_: seems like you commented on the wrong thread in blink-dev

[08:23:46.0000] <Domenic_>
annevk: I was trying to be funny... or did the threading go off?

[08:24:42.0000] <annevk>
Domenic_: I see, slow day here

[08:24:54.0000] <Domenic_>
yeah, I guess that could have been clearer, "stop torturing them by messing with the Promise API."

[08:24:54.0000] <JakeA>
Oh, I didn't realise the promises api wsa changing

[08:24:56.0000] <JakeA>
was*

[08:25:13.0000] <annevk>
JakeA: yeah that's the plan

[08:25:26.0000] <annevk>
JakeA: push notifications only really make sense if the app isn't open

[08:25:31.0000] <JakeA>
I guess .race is still in there to confuse people

[08:27:04.0000] <JakeA>
Domenic_: "Keep then, reject chain (NOT DEFER, reject!)" what does that mean?

[08:27:27.0000] <Domenic_>
lol

[08:27:35.0000] <Domenic_>
*that* sentence was almost certainly designed to confuse people

[08:27:46.0000] <Domenic_>
it means don't add monadic chain method to promises, neither now, nor in ES7

[08:27:52.0000] <JakeA>
It is a fruitless collection of words

[08:28:14.0000] <JakeA>
Ahh, the whole flatMap thing?

[08:29:00.0000] <JakeA>
I was playing around with the design of a AsyncMap, it gets quite confusing if the AsyncMap stores promises

[08:29:33.0000] <JakeA>
Domenic_: See https://github.com/slightlyoff/ServiceWorker/issues/156

[08:30:25.0000] <JakeA>
It's one of those weird cases where you want to resolve a promise with a promise without unwrapping

[08:30:53.0000] <Domenic_>
I don't understand why you want to store promises in AsyncMap.

[08:31:35.0000] <Domenic_>
The most natural semantics (for promises, not monads) is option B

[08:31:41.0000] <Domenic_>
in terms of what you can implement in JS

[08:32:27.0000] <Domenic_>
wait no not optionB

[08:32:43.0000] <Domenic_>
I will write it up

[08:33:17.0000] <annevk>
JakeA: btw, I'll be in SF April 1-8 for service workers and summit thingy

[08:33:58.0000] <JakeA>
annevk: What days are you available for serviceworkering?

[08:34:46.0000] <annevk>
JakeA: 7/8 is still best

[08:34:54.0000] <annevk>
JakeA: the tentative dates from the email

[08:35:12.0000] <JakeA>
annevk: Oh yeah, I do have that in my calendar

[08:35:22.0000] <JakeA>
Cool

[08:35:26.0000] <annevk>
great

[09:08:09.0000] <dglazkov>
good morning, Whatwg!

[09:31:17.0000] <annevk>
morning dglazkov

[10:30:50.0000] <TabAtkins>
Domenic_: I gave examples in the es-discuss thread of why you'd want to store a promise.

[10:30:58.0000] <TabAtkins>
And not have it auto-chain.

[10:33:02.0000] <TabAtkins>
Domenic_: I suppose that my example is exactly the example in the OP of SW issue 156

[11:22:21.0000] <Hixie>
so......

[11:22:32.0000] <Hixie>
if you have an <area> that is used by two image maps

[11:22:39.0000] <Hixie>
one in a <dialog> and one in the page

[11:23:01.0000] <Hixie>
and you call .focus() on the <area>

[11:23:04.0000] <Hixie>
should it focus:

[11:23:09.0000] <Hixie>
a) the first one in tree order

[11:23:30.0000] <Hixie>
b) the first one in tree order in whatever (dialog/page) is currently focused, if possible, else the first one in tree order

[11:25:03.0000] <Hixie>
c) the last one that was focused, if any has been focused, or otherwise b)

[11:25:08.0000] <Hixie>
c) the last one that was focused, if any has been focused, or otherwise a)

[11:25:44.0000] <Hixie>
e) something else

[11:25:46.0000] <Hixie>
i'm leading to a.

[11:30:06.0000] <Hixie>
oh... wait...

[11:30:08.0000] <Hixie>
i'm silly

[11:30:22.0000] <Hixie>
well, no, i'm not silly

[11:30:32.0000] <Hixie>
the above is fine, but i was thinking it was more general than that in my head

[11:30:37.0000] <Hixie>
but it really is very specific to <area>

[11:44:40.0000] <annevk>
how does <dialog> makes this different from just two image maps?

[12:11:37.0000] <Hixie>
annevk-cloud: only difference would be that now there's more than one group of controls, since each dialog has its own group

[12:19:28.0000] <jamesr__>
TC39 seems confusing

[12:20:21.0000] <Hixie>
how so?

[12:21:39.0000] <jamesr__>
i'm trying to follow the threads describing what the status of Promises is

[12:23:25.0000] <Hixie>
ah, yeah

[12:23:29.0000] <Hixie>
i assume they just didn't know it had shipped

[12:23:37.0000] <Hixie>
(they presumably wouldn't have changed it if they knew that)

[12:26:58.0000] <jamesr__>
the part in parens is the part i'm not sure about, which is what i find confusing

[12:27:36.0000] <Hixie>
why would they change it if it had shipped? once it's shipped it almost certainly can't change unless it's really really early on, and even then there's a huge cost

[12:31:44.0000] <Hixie>
TabAtkins or any other CSS mavens around: does CSS have some equivalent to "tree order"?

[12:32:24.0000] <Hixie>
if an element generates multiple boxes that are scrollable, then it might have multiple scrollable regions, and i'd like to be able to pick the "first one" by some useful definition

[12:32:33.0000] <Hixie>
but i don't know how to say that

[12:36:35.0000] <jamesr__>
i can't speak strongly, though. these promises threads are very long

[12:36:51.0000] <jamesr__>
Hixie: CSS doesn't define a box tree properly anywhere, sadly

[12:37:00.0000] <jamesr__>
there may be an approximation somewhere though

[12:39:31.0000] <Hixie>
/me figures out these regions have to be in the tab order too, and so defers to that for now

[12:39:36.0000] <Hixie>
(that'll come and bite me in the ass later...)

[12:42:28.0000] <Hixie>
i wish someone could explain to me the value of all the chatter on some of the w3c lists about whether something is "at risk" or not and whether it should be in or out for CR and when to ship the CR and all the crap

[12:42:57.0000] <Hixie>
just publish it all. why would you want to _not_ get the patent protection.

[12:43:07.0000] <Hixie>
and publish it asap. why would you want to wait.

[12:43:12.0000] <Hixie>
sigh

[12:43:55.0000] <Hixie>
(hm, actually i guess they might not theoretically all be in the tab order.)

[12:58:56.0000] <TabAtkins>
Hixie: Yeah, you can do tree order on the box tree.

[12:59:20.0000] <Hixie>
oh, cool. what should i reference when doing that?

[12:59:50.0000] <TabAtkins>
http://www.w3.org/TR/CSS21/intro.html#formatting-structure

[13:00:14.0000] <TabAtkins>
It's not really "defined", per se, but that's the right ref for people to know what you're talkinga bout.

[13:15:40.0000] <Hixie>
TabAtkins: is there any plan for a real definition that i can reference?

[13:15:49.0000] <TabAtkins>
Plan, yes. Timetable, no.

[13:15:53.0000] <Hixie>
i mean, people will "know what i mean" even without a ref... :-)

[13:15:58.0000] <Hixie>
k

[14:21:22.0000] <Hixie>
seriously. running. out. of. words. in. the. english. language.

[15:04:20.0000] <jamesr__>
mint some new words for en-hixie

[15:04:50.0000] <Hixie>
people complain when i do that :-(

[15:11:56.0000] <Hixie>
the fact that my training in the scientific method has so much bearing on my job is freaking ludicrous

[15:12:04.0000] <Hixie>
/me continuous trying to reverse engineer blur()

[15:12:08.0000] <Hixie>
continues, even

[15:49:27.0000] <SimonSapin>
https://pbs.twimg.com/media/A6cKmvQCcAAApzT.png:large is my attempt at CSS box tree

[15:52:25.0000] <Hixie>
dear kittens

[15:52:26.0000] <Hixie>
what is that

[15:52:44.0000] <Hixie>
what do the arrows represent? containership?

[15:52:48.0000] <TabAtkins>
All the various categories of "box" that CSS uses.

[15:53:08.0000] <TabAtkins>
I don't think the arrows represent any strict relationship.

[15:53:18.0000] <TabAtkins>
It's definitley *sometimes* containership

[15:53:40.0000] <Hixie>
i could tell that some of the things on there were types of "box", yes :-P

[15:53:51.0000] <cabanier>
is there an XOR box in there?

[15:54:09.0000] <cabanier>
no, there

[15:54:10.0000] <Hixie>
i was confused by the xor thing too

[15:54:12.0000] <cabanier>
 are 2


2014-02-15
[16:03:37.0000] <Hixie>
what should happen when you have a dialog with two subdialogs, one of which is always focused, and you call .blur() on that focused subdialog?

[16:03:45.0000] <Hixie>
i'm leaning towards "do nothing".

[16:04:07.0000] <Hixie>
similarly, what should happen when you try to blur() the first control in a dialog?

[16:04:19.0000] <Hixie>
(if you blur() the second control, the first gets focus)

[16:04:30.0000] <Hixie>
(if you blur() a control not in a dialog, the viewport gets focus)

[16:04:42.0000] <Hixie>
(if you blur() a dialog that has sibling form controls, they get focus)

[16:45:19.0000] <Hixie>
ok, i'm about 50% done.

[16:45:40.0000] <Hixie>
still got to do the APIs, and managing DOM mutations (like the currently focused control being removed or made inert dynamically)

[17:06:00.0000] <SimonSapin>
Most non-annotated arrows represent "subclassing", eg. a block box is both block-level and a block container

[17:07:43.0000] <SimonSapin>
the XORs don’t really make sense, but eh, I only drew that during my fifth reading of the spec

[17:54:37.0000] <SamB>
did you guys HAVE to require that damned T between the date and the time?

[17:56:26.0000] <TabAtkins>
It's useful to match iso8601 <http://www.w3.org/TR/NOTE-datetime>, so yes.

[18:34:23.0000] <Hixie>
SamB: require where?

[18:35:07.0000] <SamB>
/me just doesn't think that counts as human-readable

[18:35:43.0000] <SamB>
/me greatly prefers a space between the date and the time

[18:35:57.0000] <SamB>
Hixie: in datetimes

[18:36:16.0000] <Hixie>
like in <time>?

[18:37:46.0000] <SamB>
well, essentially, http://dev.w3.org/html5/markup/datatypes.html#form.data.datetime-local

[18:37:57.0000] <Hixie>
jesus wept, don't read the w3c version

[18:38:06.0000] <Hixie>
wait that's not even the w3c spec

[18:39:04.0000] <gavinc>
SamB: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#local-dates-and-times or http://www.w3.org/TR/html5/infrastructure.html#valid-local-date-and-time-string is what your looking for

[18:39:05.0000] <Hixie>
SamB: i recommend reading an actual normative spec, ideally the whatwg one. :-)

[18:39:26.0000] <Hixie>
where in the whatwg one does it require a T for something author-written?

[18:40:02.0000] <SamB>
I did think that seemed odd

[18:40:15.0000] <SamB>
ah, okay, that looks a lot nicer now

[18:40:26.0000] <SamB>
/me glares at google

[19:11:01.0000] <SamB>
/me grumbles about heathens with their weeks that start on monday

[19:13:00.0000] <SamB>
you know, I don't see a definition for Monday ;-P

[02:40:18.0000] <Ms2ger>
Hixie, you would mark things as "at risk" because if they don't get implemented, you would theoretically not be able to get the spec to rec, which is when you get the patent protection

[07:44:59.0000] <Ms2ger>
http://trac.webkit.org/changeset/164131

[07:47:25.0000] <mathiasbynens>
where did the “8.8 million lines” number come from? https://github.com/WebKit/webkit/commit/0e1e0ebf18aaac177366c797cfb1ae11011e55a1 lists 399 deletions

[07:51:28.0000] <mathiasbynens>
/me never gets inside jokes

[08:58:44.0000] <Ms2ger>
foolip, btw, if you ever feel like giving audio_004.htm and friends better names, go for it ;)

[09:36:56.0000] <SimonSapin>
mathiasbynens: This, I guess http://techcrunch.com/2013/05/16/google-has-already-removed-8-8m-lines-of-webkit-code-from-blink/

[09:41:44.0000] <mathiasbynens>
SimonSapin: hah, got it


2014-02-16
[16:56:40.0000] <smaug____>
/me has decided to just ignore Dahmen's emails in webapps mailing list

[18:43:39.0000] <nessy>
SamB: anything wrong in the w3c version, register a bug, please!

[18:51:21.0000] <GPHemsley>
Sometimes it's a wonder how little communication happens in the WebKit Bugzilla.

[18:52:26.0000] <GPHemsley>
A patch revised three times and then successfully reviewed, all with no more discussion than the content of the bug summary.

[18:53:02.0000] <GPHemsley>
/me goes back to Mozilla World.

[19:32:39.0000] <SamB>
nessy: I was looking at the wrong thing on w3.org anyway ...

[19:34:41.0000] <SamB>
I went back and looked again starting from the TR url, and it matched the WHATWG version

[22:10:45.0000] <SamB>
/me has a soft spot for http://simonstl.com/articles/cssFragID.html ...

[01:36:02.0000] <Ms2ger>
Oh, it was MikeSmith's http://dev.w3.org/html5/markup/

[01:36:12.0000] <Ms2ger>
MikeSmith, maybe you should take that down :)

[01:54:10.0000] <MikeSmith>
Ms2ger: will make it a redirect I guess

[02:40:50.0000] <MikeSmith>
 in the context of http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0385.html what is SW

[02:43:00.0000] <MikeSmith>
ah Service Worker

[02:45:30.0000] <MikeSmith>
damn is it really so much trouble to write stuff out

[02:46:32.0000] <Ms2ger>
People need that time to snark about other browser projects

[02:47:30.0000] <Ms2ger>
On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres <w3c⊙mc<javascript:_e(%7B%7D,'cvml','w3c⊙mc');>

[02:47:30.0000] <Ms2ger>
> wrote:

[02:48:01.0000] <marcosc>
strange?

[02:48:17.0000] <marcosc>
Ms2ger: is that from my last email?

[02:48:20.0000] <Ms2ger>
Yeah

[02:48:23.0000] <marcosc>
about manifests

[02:48:30.0000] <marcosc>
I sent if from gMail on iPhone

[02:48:48.0000] <marcosc>
it*

[02:50:30.0000] <marcosc>
Ms2ger: any projects in particular? :)

[02:50:44.0000] <Ms2ger>
marcosc, no comment :)

[02:51:02.0000] <marcosc>
oh, go on! just one  :)

[02:51:36.0000] <marcosc>
just use constructive words... instead of "it's just garbage" you can say, "could be refined"

[06:26:58.0000] <foolip>
Ms2ger: yeah, I hope to rename those in due course

[06:27:29.0000] <Ms2ger>
\o/

[06:29:02.0000] <foolip>
Ms2ger: I've asked for things like that to consider in https://critic.hoppipolla.co.uk/r/796 if you want to give it a look

[06:29:26.0000] <Ms2ger>
Yeah, I looked, but I didn't have time to check the spec yet

[06:30:45.0000] <foolip>
Ms2ger: I can ask zcorpan to do it, but if you have opinions on style more generally I will comply with enthusiasm :)

[06:32:24.0000] <Ms2ger>
I'll look in a bit :)

[08:27:01.0000] <foolip>
Ms2ger: /away night

[08:27:10.0000] <foolip>
oops :)

[08:27:24.0000] <Ms2ger>
I'm going, I'm going...

[08:27:25.0000] <Ms2ger>
;)


2014-02-17
[18:36:30.0000] <MikeSmith>
https://twitter.com/sebmarkbage/status/435113501447573504 "I guess I'm curious if W3C specs are really efficiently policing diverging user level paradigms and even if it is. Is that important?"

[18:37:03.0000] <MikeSmith>
I wonder what "efficiently policing diverging user level paradigms" means

[18:45:00.0000] <nessy>
SamB: that's all good then :-)

[00:36:50.0000] <zcorpan>
annevk-cloud: http://lists.w3.org/Archives/Public/public-web-perf/2014Feb/0048.html shouldn't sendBeacon send a Referer?

[00:37:41.0000] <zcorpan>
annevk-cloud: "API referrer source" is different depending on global env

[05:19:40.0000] <MikeSmith>
weird, I get https://raw.github.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html as text/plain in desktop but rendered HTML on mobile

[05:21:28.0000] <MikeSmith>
hmm maybe because it redirects to https on desktop but not on mobile

[05:30:44.0000] <zcorpan>
MikeSmith: try https://rawgithub.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html

[05:31:21.0000] <zcorpan>
(don't know why the other url wouldn't be text/plain on mobile though)

[05:31:42.0000] <MikeSmith>
ah yeah

[05:31:48.0000] <MikeSmith>
thanks

[05:47:18.0000] <zcorpan>
https://critic.hoppipolla.co.uk/r/800 seems like a good example of "test is testing what it thinks it is testing"

[05:48:27.0000] <jgraham>
*isn't?

[05:48:56.0000] <zcorpan>
or maybe "The test fails when it's supposed to fail"

[05:49:09.0000] <zcorpan>
i mean they fail at it

[05:49:19.0000] <zcorpan>
http://testthewebforward.org/docs/review-checklist.html

[05:51:07.0000] <jgraham>
Yeah, I think I know what you mean :) But I think your original sentence needed an extra negative somewhere to be clear

[06:08:20.0000] <zcorpan>
what is our story for manual tests? https://critic.hoppipolla.co.uk/r/803

[06:09:10.0000] <gsnedders>
"Cry."

[06:11:50.0000] <jgraham>
Yep, the tears of gsnedders are like holy water to a vampire. Just a few drops on a manual test and it will fizz and dissolve into the æther.

[06:12:46.0000] <jgraham>
But actually the policy is to name them -manual and hope that in the future we can convert them to WebDriver tests

[06:13:05.0000] <wilhelm>
Deleting them sounds wrong, unless those features are tested automatically elsewhere.

[06:14:06.0000] <jgraham>
Yeah. I'm not sure if those specific tests are good tests, but it needs someone to decide that rather than just deleting them all

[06:14:16.0000] <jgraham>
(maybe foolip already did, I don't know)

[06:53:59.0000] <zcorpan>
stevef++ in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24679

[07:01:35.0000] <foolip>
jgraham: most of the ones I removed say things like "passes if the audio is playing without sound heard" which can't be automated with any existing framework

[07:02:21.0000] <foolip>
but I'll close the review/PR anyway, since my assumption that manual tests should be nuked was wrong

[07:04:50.0000] <jgraham>
foolip: OK, thanks

[07:05:07.0000] <jgraham>
foolip: A PR to add -manual to the names of manual tests would be much appreciated

[07:05:40.0000] <foolip>
jgraham: will that now

[07:12:28.0000] <foolip>
jgraham: https://github.com/w3c/web-platform-tests/pull/646

[07:16:10.0000] <foolip>
zcorpan: about https://critic.hoppipolla.co.uk/showcomment?chain=2370 do you think it would be useful to have an obsolete.html or some such to collect tests for non-support of various features?

[07:16:58.0000] <zcorpan>
foolip: yeah. i think dom testsuite has a file called historical.html

[07:17:36.0000] <foolip>
zcorpan: ok, I'll start one of those for media then

[07:20:42.0000] <foolip>
zcorpan: whatwg.org/html#embedded-content-0 indicates to me that the -0 in html/semantics/embedded-content-0/ is not really useful

[07:22:00.0000] <zcorpan>
it should be http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#embedded-content-1

[07:22:07.0000] <zcorpan>
but with a stable id

[07:23:05.0000] <Ms2ger>
FileAPI has historical.html too

[07:23:06.0000] <foolip>
how could it be stable given that the -n is generated by anolis?

[07:23:17.0000] <foolip>
zcorpan: you mean ask hixie to make it stable?

[07:23:24.0000] <zcorpan>
foolip: yeah

[07:24:14.0000] <zcorpan>
Hixie: would you WONTFIX a bug asking you to set id="" to all sections in the spec, three levels deep?

[07:24:54.0000] <foolip>
zcorpan: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24694

[07:24:57.0000] <zcorpan>
Hixie: web-platform-tests uses section id as basis for the directory structure so it's a problem that they are not stable

[07:29:08.0000] <gsnedders>
Pretty certain Hixie claims that that's no more of a problem than the fact that the tests become invalid because of oter spec changes

[07:29:42.0000] <jgraham>
Well

[07:29:45.0000] <jgraham>
It sort of is

[07:31:13.0000] <foolip>
given that these are scoped to directories, couldn't we just not include the -0 in the name?

[07:39:49.0000] <foolip>
zcorpan: historical.html for <video auto=muted> in https://critic.hoppipolla.co.uk/r/801

[07:41:56.0000] <zcorpan>
reviewed

[07:45:34.0000] <zcorpan>
foolip: how do you mean not include the -0?

[07:47:07.0000] <foolip>
zcorpan: I mean simply name the directory html/semantics/embedded-content/

[07:47:49.0000] <foolip>
but I guess let's see what Hixie says first

[07:48:16.0000] <zcorpan>
foolip: how would you know which section in the spec the tests map to?

[07:48:34.0000] <Ms2ger>
It has been claimed that the exact mapping to spec IDs is important

[07:49:40.0000] <zcorpan>
i thought the main reason to have this structure is to annotate the spec with links to the tests

[07:55:27.0000] <foolip>
ok, if there are scripts that rely on the IDs then I suppose there's no shortcuts

[07:56:34.0000] <jgraham>
At the very least darobin has a script that gets you the test directory given (something). Which I think probably relies on the ID

[07:57:56.0000] <darobin>
yeah, it's somewhere in the tools

[07:58:32.0000] <jgraham>
Of course no one else can run it because node ;)

[08:07:33.0000] <Hixie>
having spec links in tests imho is a bad idea, because specs test many things, so one link isn't going to help. also, that link will get stale, so it just causes unnecessary churn.

[08:07:41.0000] <Hixie>
but that's separate from the issue of stable IDs

[08:07:52.0000] <Hixie>
if there's a particular heading that needs a stable heading ID, file a bug

[08:08:03.0000] <Hixie>
i won't do it to all headings, but i will to specific ones

[08:09:18.0000] <Hixie>
in other news, it's come to my attention that chaals is mailing people privately telling them to post to public-html instead of whatwg.

[08:09:22.0000] <Hixie>
stay classy chaals.

[08:15:55.0000] <foolip>
Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24694 is a specific one that would make me happy

[08:16:12.0000] <Hixie>
noted

[08:19:54.0000] <zcorpan>
Hixie: tests can have multiple spec links

[08:20:26.0000] <Hixie>
how many of them point to the "in body" parser insertion mode, the "navigate" section, the "html" element section, etc?

[08:22:45.0000] <jgraham>
Hixie: I think there is a certain extent to which the perfect is the enemy of the good here

[08:22:57.0000] <zcorpan>
Hixie: it's not useful to link to everything that a test happens to rely on, but it can be useful to point to things that a test is intended to be testing

[08:23:10.0000] <jgraham>
Although I am generally opposed to metadata, saying that a test [oh zcorpan just said it]

[08:26:31.0000] <Hixie>
in my experience, tests usually find bugs you're not intending to find.

[08:27:22.0000] <zcorpan>
so?

[08:27:31.0000] <Hixie>
*shrug*

[08:27:52.0000] <Hixie>
i find the link to be bad because it misleads people into thinking the section is relevant

[08:28:07.0000] <Hixie>
rather than having them try to find the section from first principles, which avoids them making the same mistake as the test writer

[08:28:17.0000] <Hixie>
but whatever

[08:28:29.0000] <Hixie>
you do as you like :-)

[08:29:43.0000] <zcorpan>
/me gotta go

[08:31:38.0000] <jgraham>
I think having a rough mapping of tests to spec sections is pretty useful to get a coarse view of which tests are *expected* to exercise a particular part of the spec, to find obvious gaps in the coverage, and to find tests that are likely invalid if a section undergoes a major rewrite or is removed. They are not useful as a tool for debugging a failing test

[08:34:00.0000] <gsnedders>
Though as opjsunit shows, we did end up with a testSiteRegressions_0.js file :)

[08:47:13.0000] <foolip>
jgraham: can you finish https://critic.hoppipolla.co.uk/r/801 so that I merge before sleep?

[08:48:29.0000] <jgraham>
foolip: Done. I assume you want to squash and merge?

[08:49:56.0000] <foolip>
jgraham: of course

[08:50:53.0000] <foolip>
jgraham: you can do https://critic.hoppipolla.co.uk/r/812 too if you like, or leave it to zcorpan :)

[08:57:52.0000] <jgraham>
foolip: I might leave that to zcorpan if you don't mind

[09:37:51.0000] <foolip>
jgraham: np

[13:35:41.0000] <Hixie>
http://www.whatwg.org/specs/web-apps/current-work/#overview-of-the-parsing-model vs http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#overview-of-the-parsing-model

[13:35:51.0000] <Hixie>
in chrome i get a different object entirely in the floating object...

[13:35:52.0000] <Hixie>
wtf

[13:35:58.0000] <Hixie>
the markup is identical

[14:20:05.0000] <scott_gonzalez>
smaug____: I talked to the jQuery team and the only case we know of for sync XHR is beforeunload.

[14:20:48.0000] <scott_gonzalez>
smaug____: Devs tend to use it for form validation as well, but that should really be handled async with event.preventDefault() in a submit event handler.

[14:31:49.0000] <smaug____>
scott_gonzalez: right

[14:32:19.0000] <smaug____>
scott_gonzalez: gecko now warns about sync xhr except when used in beforeunload/unload/pagehide event listeners

[14:32:30.0000] <scott_gonzalez>
That sounds reasonable.

[14:32:58.0000] <scott_gonzalez>
I guess you'll start warning in those once beacon lands?

[14:33:25.0000] <smaug____>
right

[14:33:32.0000] <smaug____>
hmm, did beacon land

[14:33:47.0000] <smaug____>
didn't

[14:34:06.0000] <smaug____>
ah, some test fixes still needed

[14:34:23.0000] <smaug____>
/me needs to also ask sicking about the stability of beacon

[14:34:54.0000] <smaug____>
scott_gonzalez: do you think jQuery could actually disable sync XHR at some point

[14:35:31.0000] <scott_gonzalez>
In some magical future, yes.

[14:35:53.0000] <scott_gonzalez>
I've already convinced the team to deprecate $.ajax in favor of separate APIs for each type of transport.

[14:36:02.0000] <scott_gonzalez>
So there would be $.xhr() and it would only support async XHR.

[14:36:19.0000] <scott_gonzalez>
The question is whether we can get to a point where we ship jQuery without $.ajax().

[14:37:20.0000] <scott_gonzalez>
Here's my proposal if you're interested: http://bugs.jquery.com/ticket/14509

[15:41:14.0000] <pdr>
w3.org is down. How will the web ever move forward now


2014-02-18
[16:20:27.0000] <smaug____>
pdr: whatwg.org is working fine ;)

[17:47:17.0000] <SamB>
/me boggles at the requirement that navigator.product == "Gecko"

[22:09:20.0000] <MikeSmith>
whatwg.org seems unresponsive at the moment

[22:10:08.0000] <MikeSmith>
Hixie: ↑

[23:02:59.0000] <MikeSmith>
Hixie: nm, working fine for me now

[23:03:19.0000] <Hixie>
odd

[23:03:29.0000] <Hixie>
didn't see any issues on this side

[23:05:43.0000] <MikeSmith>
maybe just wonky connection on my side but it was weird because I couldn't get a response either over local Japan connection nor when tryining from my server in the UK

[23:06:22.0000] <Hixie>
might have been a connection on the incoming dreamhost pipe from outside california or something

[23:07:49.0000] <MikeSmith>
ok

[23:20:47.0000] <annevk-cloud__>
zcorpan: it is different, but you can pull it from the settings object which exists on the global environment

[23:22:11.0000] <zcorpan>
annevk-cloud: yeah

[01:33:48.0000] <zcorpan>
jgraham: r? https://critic.hoppipolla.co.uk/r/584

[03:19:20.0000] <qFox>
can anybody point me to a reference why orphan </p> will cause an extra <p>?

[03:20:39.0000] <Ms2ger>
It won't?

[03:20:58.0000] <qFox>
<p><p></p></p> how many p's?

[03:21:15.0000] <Ms2ger>
Two

[03:21:19.0000] <qFox>
try .

[03:21:34.0000] <Ms2ger>
Mm

[03:21:40.0000] <qFox>
:)

[03:21:54.0000] <qFox>
Glad I'm not the only one

[03:22:10.0000] <qFox>
But now I'm looking for some reference that explains what/when/why/how/bla on this.

[03:22:42.0000] <jgraham>
Three

[03:22:56.0000] <jgraham>
<p> creates a <p>

[03:23:02.0000] <jgraham>
<p> creates a <p>

[03:23:09.0000] <jgraham>
</p> closes a <p>

[03:23:12.0000] <Ms2ger>
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inbody

[03:23:20.0000] <jgraham>
</p> with no open <p> creates a <p>

[03:23:25.0000] <Ms2ger>
'An end tag whose tag name is "p"'

[03:24:31.0000] <qFox>
"If the stack of open elements does not have a p element in button scope, then this is a parse error; insert an HTML element for a "p" start tag token with no attributes."

[03:24:32.0000] <qFox>
thanks!

[03:26:42.0000] <qFox>
is "button scope" just confusing wording for me right now?

[03:27:34.0000] <jgraham>
qFox: Probably. It should be linked to a definition, but basically you go up the stack of open elements until you find an element in a particular set of elements, or the element you are looking for

[03:28:09.0000] <qFox>
Ok. Button reads for me like "if it's child of a <button>". but okay I get it, just terminology. Cheers

[03:28:14.0000] <Ms2ger>
I argued unsuccessfully that it's confusing at one point

[03:31:04.0000] <qFox>
It implies that it only refers to the scope of a <button>, imo, rather than the scope of a button or anything else.

[03:42:33.0000] <jgraham>
It would be very annoying to call it "in button or [list of other elements] scope"

[03:42:53.0000] <jgraham>
At some point you just have to follow the definitions and read the spec

[05:54:52.0000] <Ms2ger>
http://lists.w3.org/Archives/Public/www-archive/2014Feb/0014.html

[07:09:57.0000] <gsnedders>
/me wonders what IE/Fx do with something not in Windows-1252

[09:04:30.0000] <dglazkov>
good morning, Whatwg!

[09:41:36.0000] <Hixie>
/me learns about importNode()

[09:41:42.0000] <Hixie>
dunno how i didn't realise it cloned before

[09:41:54.0000] <Hixie>
i think i thought it was just adoptNode()

[14:05:40.0000] <Hixie>
so, anyone care what window.focus() does?

[14:05:47.0000] <Hixie>
looks like we don't have interop, so if anyone cares, let me know...

[14:07:06.0000] <Hixie>
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2823

[14:19:08.0000] <rniwa>
Hixie: focus is hard :/

[14:19:17.0000] <Hixie>
yeah seriously

[14:19:27.0000] <Hixie>
i'm 80% done rewriting how focus is specced

[14:19:33.0000] <Hixie>
which should clean this kind of thing up

[14:48:59.0000] <miketaylr>
Hixie: i care. interested in what you spec.

[14:54:05.0000] <Hixie>
miketaylr: right now i'm matching firefox behaviour.

[14:54:36.0000] <Hixie>
miketaylr: which is, as far as i can tell, move the focus to whatever descendant of the window in question last had focus

[14:54:42.0000] <miketaylr>
cool

[14:57:01.0000] <Hixie>
spec is regenned if you want to check what it looks like

[14:57:06.0000] <MikeSmith>
Hixie: in other news I'm curious about in what cases a th element would be interactive content

[14:57:07.0000] <Hixie>
but it has a number of errors

[14:57:16.0000] <Hixie>
MikeSmith: when it's sortable

[14:57:22.0000] <MikeSmith>
ah

[14:57:46.0000] <MikeSmith>
yeah, of course. Hadn't thought about that

[14:59:04.0000] <miketaylr>
/me puts on todo list

[15:00:32.0000] <Hixie>
ok, spec's markup errors are fixed, at least. still lots of polish to do, but if anyone wants to see what the new focus stuff looks like, it's up on the single-page version.

[15:00:46.0000] <Hixie>
quick break then i'll try to finish it off

[15:15:10.0000] <esprehn>
annevk-cloud: rafaelw was supposed to reply to that thread, but I can reply too if you want

[15:20:09.0000] <Hixie>
i hope nobody minds my ghetto diagrams http://www.whatwg.org/specs/web-apps/current-work/#focus

[15:24:03.0000] <miketaylr>
beauty.

[15:24:40.0000] <MikeSmith>
Hixie: I like in your diagram how the spider tentacled person whose head looks like a "2" is grabbing up parts of the the user interface to take back as souvenirs to his home planet

[15:25:15.0000] <Hixie>
lol

[15:25:20.0000] <Hixie>
i should put that as the alt="" text

[15:26:18.0000] <MikeSmith>
+1 to that

[15:28:28.0000] <smaug____>
uh, <output>'s defaultValue handling is so odd

[15:29:52.0000] <esprehn>
Hixie: again, having the concept of <dialog> all tangled into the concept of focus is not something I support

[15:29:59.0000] <Hixie>
smaug____: how so?

[15:30:18.0000] <smaug____>
Hixie: defaultValue isn't initially textContent

[15:30:19.0000] <esprehn>
Hixie: that's what I was trying to convey about Android, the focus management system has no idea about dialogs. There's no special cases like this.

[15:30:20.0000] <Hixie>
esprehn: ? how else would you do it?

[15:30:51.0000] <esprehn>
Hixie: you can add a tabgroup attribute if you want to support groups, and you can spec focus traverses the top layer order when it jumps between things in the top layer

[15:31:12.0000] <Hixie>
smaug____: i think you're misreading it

[15:31:22.0000] <Hixie>
smaug____: oh, no, wait

[15:31:43.0000] <smaug____>
/me was testing two different implementations and wondered why it is so odd

[15:31:44.0000] <Hixie>
smaug____: huh, yeah, that's weird.

[15:31:50.0000] <esprehn>
<dialog> should be something we can express as a module in the browser, if the "FocusController" needs to have lots of if (dialog) doDifferentThings() that's not possible

[15:31:57.0000] <Hixie>
smaug____: looks like it doesn't check the flag correctly on getting?

[15:32:00.0000] <smaug____>
Hixie: Gecko and Blink seem to follow the spec

[15:32:29.0000] <Hixie>
esprehn: it would have been hugely helpful if you could send this feedback before i spent 3 days writing this up, btw.

[15:32:39.0000] <Hixie>
esprehn: but i don't really understand what you're proposing

[15:32:50.0000] <Hixie>
esprehn: the special cases are only because the Web has a legacy we have to support as well

[15:33:02.0000] <Hixie>
esprehn: it's as separate as it can be, given the legacy, as far as i can tell

[15:33:07.0000] <esprehn>
<dialog> is not legacy

[15:33:14.0000] <Hixie>
esprehn: no, <dialog> is the only new thing here

[15:33:25.0000] <esprehn>
yes, and new things should not bleed into core algorithms like this

[15:33:28.0000] <Hixie>
esprehn: and that's why it's carefully kept on the side with dialog groups

[15:34:05.0000] <Hixie>
esprehn: what special case are you specifically concerned about?

[15:34:08.0000] <esprehn>
Android wouldn't accept code that put if (widget instanceof Version5Widget) doStuff() in the core platform either

[15:34:20.0000] <Hixie>
android works pretty much exactly as this describes.

[15:34:34.0000] <esprehn>
I'm sorry I wasn't clear, I thought I was clear when I said <dialog> shouldn't have any special cases in my previous emails

[15:34:52.0000] <Hixie>
which previous e-mails?

[15:36:05.0000] <Hixie>
the only e-mail i've seen from you about it was after i started editing, weeks after i asked for feedback, to a vendor-specific list, and didn't give any actionable feedback

[15:36:23.0000] <Hixie>
(and i replied straight away)

[15:36:40.0000] <esprehn>
"I think we should push back on the <dialog> spec to not introduce more magical behavior that cannot be explained in terms of our existing CSS primitives and JS"

[15:36:48.0000] <esprehn>
that was in the context of positioning

[15:36:52.0000] <esprehn>
but you're adding magic now for focus

[15:36:59.0000] <Hixie>
this isn't magic

[15:37:12.0000] <Hixie>
it's what android, windows, iOS, MacOS, X Windows, etc, all do

[15:37:25.0000] <esprehn>
none of them have instanceof checks inside the core focusing logic

[15:37:40.0000] <Hixie>
i'm not sure what you mean by instanceof checks

[15:37:47.0000] <Hixie>
what part of what algorithm is it you mean?

[15:38:04.0000] <esprehn>
ex. "Each dialog element that has an open attribute specified and that is being rendered "

[15:38:32.0000] <Hixie>
?

[15:38:42.0000] <Hixie>
that's the same as other platforms

[15:38:45.0000] <esprehn>
"The focus chain of a focusable area or control group owner object subject"

[15:38:55.0000] <esprehn>
has a special case for dialogs

[15:39:07.0000] <Hixie>
that's a virtual call.

[15:39:12.0000] <Hixie>
not an instanceof

[15:39:21.0000] <Hixie>
it's just walking a tree

[15:39:26.0000] <Hixie>
same as every other platform

[15:39:33.0000] <esprehn>
"if current object is a dialog object" how is that a virtual call?

[15:39:53.0000] <Hixie>
it's the equivalent of "current object -> parent"

[15:39:54.0000] <esprehn>
you're saying because it's a big stack of cases, heh

[15:40:35.0000] <Hixie>
that step literally just walks up a tree, each node in which might have a different way to get its parent

[15:41:18.0000] <Hixie>
it's the same as, say, nodeName's definition:

[15:41:22.0000] <Hixie>
http://dom.spec.whatwg.org/#dom-node-nodename

[15:41:36.0000] <Hixie>
those aren't instanceof checks, it's just a virtual method defined for each subclass

[15:42:57.0000] <esprehn>
How do you implement <jquery-window> that has the same focusing behavior as dialog?

[15:43:45.0000] <Hixie>
you use <dialog> as the backing element.

[15:43:59.0000] <Hixie>
that's what <dialog> is for

[15:44:03.0000] <esprehn>
that means <dialog> is special

[15:44:13.0000] <Hixie>
every HTML element is special, except <span>.

[15:44:15.0000] <esprehn>
which is not true on Android or iOS

[15:44:32.0000] <Hixie>
um... you can't make a native-like dialog on Windows without using an actual dialog handle vended by the OS

[15:44:42.0000] <esprehn>
you can call the APIs that Android's Dialog uses

[15:44:43.0000] <Hixie>
how is that different?

[15:44:46.0000] <esprehn>
there's nothing special down there

[15:44:56.0000] <Hixie>
<dialog> is "the APIs that Android's Dialog uses"

[15:45:27.0000] <Hixie>
how do you implement <jquery-canvas> without <canvas>?

[15:45:50.0000] <Hixie>
or keyboard input without the keydown/keyup/keypress events?

[15:45:59.0000] <esprehn>
both of those are small self contained things

[15:46:00.0000] <Hixie>
or change the mouse cursor without using CSS 'cursor'?

[15:46:17.0000] <Hixie>
<canvas> is a heck of a lot less small than <dialog> :-)

[15:47:37.0000] <esprehn>
shrug, I'm not sure how to convince you, but I don't support this current path

[15:47:59.0000] <esprehn>
in the same way I think we should remove things like <details>

[15:48:02.0000] <Hixie>
...

[15:48:14.0000] <esprehn>
you're too far up the stack

[15:48:50.0000] <Hixie>
i don't think it's necessarily wrong to have a platform where the main target is "lower down the stack", but, that's not how HTML works...

[15:49:04.0000] <Hixie>
i would love to replace HTML with something better

[15:49:08.0000] <esprehn>
That's the whole concept of the extensible web

[15:49:26.0000] <Hixie>
but i don't think changing the basic approach of how we design HTML 24 years in is going to lead to a sane platform

[15:49:50.0000] <Hixie>
so it wouldn't be a matter of "not having <details> and <dialog>"

[15:50:19.0000] <Hixie>
every time anyone has tried to make "extensible web" stuff, it's failed, so please forgive my lack of enthusiasm :-)

[15:50:33.0000] <Hixie>
q.v. xml, xhtml2, etc

[15:51:29.0000] <esprehn>
In blink our goal is to bunker down on explaining the platform

[15:51:42.0000] <wilhelm>
Please do pave the cowpaths here, so I can write less code. :)

[15:51:57.0000] <esprehn>
and building primitives, so I suppose I'll just keep pushing back on you

[15:52:12.0000] <Hixie>
esprehn: i think that's a misguided approach, fwiw.

[15:52:46.0000] <Hixie>
esprehn: i think we agree on many of the concrete implications, but the approach imho is poorly described as "explaining the platform"

[15:53:12.0000] <Hixie>
though fwiw, i think http://www.whatwg.org/specs/web-apps/current-work/#focus "explains the platform" in far more detail than we've ever had before for focus :-)

[15:53:34.0000] <esprehn>
That's great, remove <dialog> from that and ship it

[15:53:50.0000] <Hixie>
that's unhelpful

[15:54:03.0000] <esprehn>
Then add the tabgroup primitive, explain that dialog uses tabgroup and ship that

[15:54:14.0000] <Hixie>
i've no idea what you mean there

[15:54:24.0000] <Hixie>
tab groups are a presenational issue, which should be dealt with in CSS

[15:54:27.0000] <Hixie>
or web components

[15:54:44.0000] <Hixie>
doesn't seem related to dialogs

[15:55:13.0000] <esprehn>
I'm saying explain what you want for <dialog> in terms of a feature that web components can use

[15:55:22.0000] <Hixie>
(tab groups are really a media-specific overflow mechanism)

[15:56:01.0000] <Hixie>
esprehn: happy to. file a bug with use cases and explaining how it would integrate with the focus model, and i'll spec something up.

[15:56:17.0000] <Hixie>
esprehn: so far, i haven't heard anything regarding how web components wants to interact with focus except some bugs from apple

[15:56:37.0000] <esprehn>
It should work however you want <dialog> to work

[15:56:40.0000] <Hixie>
esprehn: (which weren't actionable, and had more to do with tabindex="" than the focus model)

[15:56:57.0000] <Hixie>
i want <dialog> to work as a native element...? that seems diametrically opposite to what web components is

[15:57:21.0000] <Hixie>
if you want a dialog, you can just use one in a component, i don't understand what you're asking for

[15:57:57.0000] <esprehn>
I don't support that, you want "native" to mean "unexplained magic APIs that JS can't get to"

[15:58:02.0000] <esprehn>
and I plan to push back on that

[15:58:15.0000] <Hixie>
esprehn: it's not "unexplained magic" dude, i just spent multiple days explaining it in excruciating detail.

[15:58:36.0000] <Hixie>
esprehn: and in more detail than has ever been specced before.


2014-02-19
[16:00:30.0000] <esprehn>
Hixie: it doesn't seem we can convince each other

[16:01:23.0000] <Hixie>
esprehn: i'm open to suggestions (though again, in future, please send them when i ask for feedback, not after i've done all the work), but so far i haven't any idea what you're suggesting.

[16:01:42.0000] <Hixie>
esprehn: i'm not trying to convince you, i'm trying to understand what you are proposing.

[16:02:23.0000] <esprehn>
I'm proposing that you explain what <dialog> does in terms of APIs script can use

[16:02:39.0000] <Hixie>
i have no idea what that means.

[16:02:56.0000] <Hixie>
you want _more_ APIs? in your blink e-mail you were saying there were too many (so i didn't end up including them).

[16:03:10.0000] <Hixie>
why can't scripts use <dialog>?

[16:03:40.0000] <Hixie>
what is it that your scripts want to do? like, what are your concrete use cases?

[16:03:56.0000] <Hixie>
please file a bug with the answers to these questiosn so that i can track it: http://whatwg.org/newbug

[16:05:01.0000] <esprehn>
I don't understand how to explain this more clearly

[16:06:12.0000] <Hixie>
well, let's start with: why can't scripts use <dialog>?

[16:08:51.0000] <esprehn>
Because they want to use <jquery-dialog>, and they want the top layer behavior but not the focus behavior (or the opposite)

[16:09:40.0000] <Hixie>
i think i need a concrete use case to understand what you're proposing

[16:09:47.0000] <Hixie>
what does <jquery-dialog> do, exactly?

[16:10:25.0000] <Hixie>
do you have a sample page i could look at that shows the kind of behaviour you want that isn't possible with <dialog>?

[16:10:36.0000] <Hixie>
(and for which <dialog> is relevant, obviously ;-) )

[16:10:42.0000] <esprehn>
this isn't a matter of what is/isn't possible with dialog

[16:11:03.0000] <esprehn>
if you keep adding features to dialog you can make everything possible

[16:11:25.0000] <Hixie>
right, then problem solved

[16:11:32.0000] <Hixie>
isn't that what you wanted? an api to do something?

[16:11:50.0000] <esprehn>
no, because we want the system to be build on small parts you can put together, not big parts full of lots of APIs and features

[16:12:07.0000] <Hixie>
but you literally just said you wanted a new api

[16:12:19.0000] <Hixie>
<dialog> is a "small part you can put together".

[16:12:36.0000] <Hixie>
that's the whole point of <dialog>

[16:12:49.0000] <Hixie>
to be the simplest thing we can provide that lets you do accessible dialogs

[16:13:11.0000] <esprehn>
Dialog.prototype.show = () { document.toplayer.add(this); document.documentElement.inert = true; this.inert = false; }

[16:13:22.0000] <esprehn>
you should be able to explain what's going on that way

[16:13:36.0000] <Hixie>
we do (though we use english instead of pseudocode)

[16:13:57.0000] <esprehn>
that's not pseudo code, we want a toplayer API, and an inert API

[16:14:08.0000] <Hixie>
???

[16:14:12.0000] <Hixie>
wait, what?

[16:14:26.0000] <Hixie>
how is that simpler

[16:14:30.0000] <esprehn>
yes, full screen and dialog use some magic system to put themselves on top

[16:14:38.0000] <esprehn>
it's top layer, and we should just let you use it

[16:14:41.0000] <Hixie>
it's not magic, it's carefully designed

[16:14:56.0000] <esprehn>
that's the core of the extensible web platform

[16:15:12.0000] <Hixie>
i think that's actively the opposite of what we should be aiming for.

[16:15:26.0000] <Hixie>
we should provide primitives that let you create web apps

[16:15:32.0000] <Hixie>
not primitives that let you create web app platforms

[16:16:05.0000] <Hixie>
we _are_ a platform

[16:17:00.0000] <esprehn>
right, so you disagree with the extensible web concept

[16:17:39.0000] <Hixie>
i'm not sure what "the extensible web concept" is

[16:17:44.0000] <Hixie>
the web is hugely extensible already

[16:17:57.0000] <Hixie>
i mean, it's the world's most successful platform

[16:17:57.0000] <esprehn>
you just said "i think that's actively the opposite of what we should be aiming for."

[16:18:35.0000] <Hixie>
i think that having a dialog box should be as simple as just saying you want a dialog box, yes. i don't think everyone should need to say "and i want my dialog on the top layer, and i want it to be focusable, and i want it to be accessible", etc.

[16:19:01.0000] <Hixie>
obviously if there are concrete use cases for which we need other primitives, like the top layer, then we should study them and provide for them.

[16:19:25.0000] <Hixie>
but we shouldn't just provide everything willy nilly; there's a huge cost to every feature and doign that harms both authors and users.

[16:19:34.0000] <Hixie>
authors because it makes everything way more complicated than necessary

[16:19:43.0000] <Hixie>
and users because if the platform is complicated, apps in the platform will be more buggy.

[16:19:50.0000] <esprehn>
That's fine, but you should be able to explain the dialog bits in terms of small APIs that a widget can cobble together without using <dialog>

[16:19:56.0000] <Hixie>
just look at dialogs now, everyone does it there own way and it's all different and buggy.

[16:19:59.0000] <Hixie>
their

[16:20:05.0000] <Hixie>
why?

[16:20:16.0000] <Hixie>
i don't understand why "you should be able to explain the dialog bits in terms of small APIs that a widget can cobble together without using <dialog>"

[16:20:30.0000] <Hixie>
should we be able to explain CSS 'color' and 'margin-top' and form submission and so on in the same way?

[16:20:43.0000] <esprehn>
yes, we plan to propose a form submission API

[16:20:56.0000] <esprehn>
color and margin are sort of build on <canvas>, but there's more work to explain that

[16:20:57.0000] <Hixie>
should we "explain 'http'"?

[16:21:09.0000] <Hixie>
and explain page navigation?

[16:21:15.0000] <Hixie>
and CSP?

[16:21:18.0000] <Hixie>
and iframs?

[16:21:22.0000] <Hixie>
iframes

[16:21:27.0000] <Hixie>
and mouse events?

[16:21:28.0000] <esprehn>
slightlyoff plans to explain iframes too

[16:21:34.0000] <Hixie>
i don't even know what explaining half these things would mean

[16:21:41.0000] <esprehn>
yes, there's a lot of work to do

[16:21:47.0000] <Hixie>
we already have a form submission API

[16:21:49.0000] <Hixie>
we have two, even

[16:22:02.0000] <Hixie>
this is all make-work. it doesn't actually improve the platform at all.

[16:22:10.0000] <Hixie>
it just makes it more complicated and harder to optimise.

[16:22:23.0000] <esprehn>
sure it does, it means <polymer-input> can add fields to the enclosing <form>

[16:22:30.0000] <Hixie>
(and more complicated means it's harder to write web apps, and that means more buggy web apps)

[16:22:40.0000] <esprehn>
it means <tizen-dialog> can be in the top layer, but have totally different focusing behavior

[16:22:43.0000] <Hixie>
esprehn: but how do you explain <form>?

[16:22:54.0000] <Hixie>
"totally different focusing behavior" is a bug!

[16:23:06.0000] <Hixie>
the whole point of <dialog> is to _not_ have "totally different focusing behavior"

[16:23:15.0000] <esprehn>
it's not though, why should a web app suck on Android because the focusing behavior doesn't follow the native one?

[16:23:26.0000] <Hixie>
it _should_ follow the native one

[16:23:30.0000] <Hixie>
automatically

[16:23:44.0000] <Hixie>
it should also follow the iOS 9.1 focus model that the web author doesn't know about

[16:23:52.0000] <Hixie>
and the Windows 2103 focus model

[16:24:01.0000] <Hixie>
and the author shouldn't have to write one line of code for that to just work

[16:24:14.0000] <Hixie>
that's what <dialog> does

[16:24:20.0000] <Hixie>
and <input>

[16:24:23.0000] <Hixie>
and the rest of HTML

[16:25:21.0000] <esprehn>
you're at odds with the extensible web idea, that you should be able to build up complex widgets from building blocks and explain how the existing widgets work

[16:28:25.0000] <Hixie>
esprehn: i'm all for being able to build up complex widgets from building blocks, and my job is to explain how the existing widgets work.

[16:28:37.0000] <Hixie>
esprehn: those both seem orthogonal to the issue at hand, though.

[16:28:57.0000] <esprehn>
You seem to be arguing "why have contenteditable at all, just add a richtext attribute to <textarea> and <input>"

[16:29:17.0000] <esprehn>
"keep expanding the API on <textarea> until it fits all the use cases"

[16:30:57.0000] <Hixie>
i've argued that many times, yes. i think it's supported by how wacked contenteditable is.

[16:31:27.0000] <Hixie>
contenteditable doesn't fit HTML very well at all, and it's universally hated.

[16:31:54.0000] <Hixie>
but even contenteditable doesn't "explain the platform"

[16:31:59.0000] <esprehn>
sure, so add a sensible editing API with text measurement

[16:32:15.0000] <esprehn>
and caret positions and such, and then let <textarea> use it

[16:32:37.0000] <othermaciej>
you need something for the use case of "edit some rich text with a starting point of arbitrary html, then output html as your final product"

[16:32:52.0000] <othermaciej>
there are cases of rich text editing which are not that, but a comprehensive solution needs to hit that case

[16:33:18.0000] <Hixie>
esprehn: i'm all for a better API than contenteditable, but I don't see how it helps. How do you explain the caret? it just becomes magic behind yet another API.

[16:33:42.0000] <Hixie>
esprehn: at the end of the day, there's always some platform feature.

[16:33:51.0000] <Hixie>
esprehn: how do you determine which is the "most explained" feature?

[16:34:49.0000] <Hixie>
esprehn: and how do you know which features to expose in this editing API?

[16:35:04.0000] <Hixie>
esprehn: it always comes back to concrete use cases, and APIs that address those use cases.

[16:35:06.0000] <SamB>
/me wonders who he should report firefox's treatment of "Refresh: " HTTP headers to: a working group (which?), or bugzilla.mozilla.org ...

[16:35:10.0000] <esprehn>
Hixie: all the features necessary to build what contenteditable and <textarea> do today

[16:35:29.0000] <Hixie>
esprehn: <textarea> and contenteditable today already exist, so no new features are needed.

[16:35:43.0000] <esprehn>
that's where we disagree

[16:36:04.0000] <Hixie>
you literally just said you just wanted the features necessary to build what they do. we can already do that, since they exist.

[16:36:20.0000] <Hixie>
"<textarea></textarea>" is an implementation of textarea.

[16:36:27.0000] <esprehn>
huh?

[16:36:29.0000] <SamB>
what was the problem with contenteditable? why not ... fix the problem?

[16:36:41.0000] <SamB>
or did you want some kind of XBL successor

[16:36:50.0000] <esprehn>
Hixie: that doesn't follow

[16:37:08.0000] <Hixie>
esprehn: i don't understand what you mean by "all the features necessary to build what contenteditable and <textarea> do today" then

[16:37:26.0000] <SamB>
Hixie: he wants to NIH it for some reason

[16:37:45.0000] <esprehn>
What if we wanted to ship a browser without <textarea>, that downloaded the implementation on first usage?

[16:37:49.0000] <Hixie>
SamB: that seems unlikely, esprehn is not prone to such thinking

[16:37:56.0000] <SamB>
I don't know why he's not happy to use browser-specific extensions in his browser-specific implementation of textarea

[16:38:13.0000] <esprehn>
This isn't about NIH :)

[16:38:26.0000] <Hixie>
esprehn: that seems highly hypothetical, i don't know how to apply reasoning to such a situation.

[16:38:28.0000] <othermaciej>
to the extent I understand the "explain" idea, it seems to be about "what if I wanted to do something almost like this, but different enough that I can't use the built-in extensibility hooks - are there primitives I could use to build it?"

[16:38:29.0000] <esprehn>
Hixie: how would you implement <textarea> in script as a library

[16:38:53.0000] <othermaciej>
of course at some point you always come down to a primitive that's not explainable

[16:38:53.0000] <SamB>
yeah, "what if I want something that acts *almost* like <textarea>" is a much more interesting question

[16:39:07.0000] <othermaciej>
in terms of something else

[16:39:14.0000] <Hixie>
othermaciej: the only way to make progress on such a line of reasoning that i can see is to have a concrete example to evaluate, because the entirety of the difficulty of answering that question lies in the specifics of "almost".

[16:39:29.0000] <SamB>
yes, you have to come up with a specific difference

[16:39:38.0000] <Hixie>
esprehn: i would do document.createElement('textarea') and be done, since hte browser has native support for it.

[16:39:47.0000] <esprehn>
Hixie: but it doesn't!

[16:39:53.0000] <othermaciej>
Hixie: I tend to agree with your point of view on this; but I think the Extensible Web Manifesto POV is that it's not necessary to specify the details of "different in what way" so as to provide for unexplained ways

[16:39:59.0000] <Hixie>
esprehn: well it better, the web kinda relies on it.

[16:40:16.0000] <esprehn>
Hixie: your browser downloads a JS library that implements textarea the first time you visit a page with it

[16:40:18.0000] <othermaciej>
Hixie: I feel like similar reasoning in the past has led to XML Namespaces so I am a bit wary of it

[16:40:21.0000] <Hixie>
othermaciej: every time people have tried that, it's fallen flat on its face. q.v. XML, XHTML2, etc.

[16:40:23.0000] <SamB>
othermaciej: is there some reason you can't do it with contenteditable and some XBL-successor?

[16:40:40.0000] <Hixie>
esprehn: that sounds like a performance nightmare

[16:40:48.0000] <othermaciej>
SamB: contentEditable doesn't have provisions for being plaintext only

[16:40:49.0000] <Hixie>
esprehn: what's wrong with the built-in <textarea>?

[16:41:02.0000] <esprehn>
Hixie: what if it has a bug?

[16:41:20.0000] <esprehn>
Apple only ships Safari once a year, why can't a install the textarea.js with a patch?

[16:41:28.0000] <Hixie>
esprehn: if there's a bug you use a different browser.

[16:41:31.0000] <esprehn>
you can do that on Android, you can monkey patch the ObjC classes on OS X

[16:41:46.0000] <SamB>
or install a different build of WebKit maybe?

[16:41:47.0000] <esprehn>
on Android you can include the java source with a patch if you want

[16:41:47.0000] <othermaciej>
because our implementation of lowlevel-primitives-that-textarea-uses won't ever have bugs

[16:42:02.0000] <SamB>
othermaciej: lol

[16:42:13.0000] <othermaciej>
and it's easier to add that feature than to fix the bug it helps you workaround I guess?

[16:42:34.0000] <esprehn>
othermaciej: sure, but your OS has bugs too, why not bake libxml into the kernel?

[16:42:41.0000] <esprehn>
you can't just concede that

[16:43:15.0000] <Hixie>
esprehn: the whole point of the web is that there's multiple implementations that compete on quality, it's the one huge difference between the web and every other platform, and is one of its biggest strengths. One big implication of this is that when there's a platform implementation bug, as an author, it's not your problem.

[16:43:16.0000] <esprehn>
obviously we'll have bugs, but you should be able to patch the platform. People use custom ruby installs and custom rails installs all the time

[16:43:21.0000] <othermaciej>
libxml has approx the same update cycle as the kernel on our platform, though in fairness you can bring your own more easily than you can bring your own kernel

[16:44:25.0000] <SamB>
esprehn: usually, textarea doesn't have any particularly grave flaws

[16:44:33.0000] <othermaciej>
a more on-point analogy is that OS X has both NSTextView and much lower-level text primitives that in theory you could use to build your own text editing and layout engine (of which WebKit is one)

[16:44:35.0000] <esprehn>
othermaciej: that's my point, I can bring my own libxml in Foo.app if needed, you can't bring your XNU

[16:44:36.0000] <Hixie>
in practice, btw, authors already commonly work around implementation bugs and it's not a huge deal. bugs in things like <textarea> exists, though, and nobody cares to work around it. I certainly trust Web authors a heck of a lot less than my browser vendor to ship a sane <textarea>.

[16:44:46.0000] <othermaciej>
but very few people do cause it's hard and tends to lack correct platform integration

[16:44:51.0000] <Hixie>
i mean, just compare the textarea that OSes ship, with teh text fields in video games.

[16:45:02.0000] <Hixie>
the custom-built video game text fields are a disaster.

[16:45:14.0000] <Hixie>
they're a poster-child for not having authors reinvent the wheel like this.

[16:45:18.0000] <SamB>
esprehn: so, where did you get stuck in your textarea.js anyway?

[16:46:39.0000] <SamB>
hmm, the main motivation *I've* seen for wanting to clone <textarea> in JavaScript is syntax highlighting

[16:46:56.0000] <Hixie>
SamB: we should definitely provide an API for stuff like that, that's come up several times.

[16:47:46.0000] <SamB>
I assume you've seen https://www.mediawiki.org/wiki/User:Remember_the_dot/Syntax_highlighter then?

[16:47:52.0000] <othermaciej>
I am sympathetic to the argument that sometimes people want to customize in ways that are hard to predict, or so niche that it would be weird to provide for them directly

[16:47:54.0000] <Hixie>
SamB: but implementing syntax highlighting shouldn't require re-implementing bidi editing, text selection, mouse placement of the caret, text-search in textareas, spell-checking, copy-and-paste, scrolling, dragging of bidirectional text selections, ...

[16:48:04.0000] <SamB>
Hixie: quite so

[16:48:18.0000] <othermaciej>
though I also feel it is a potentially dangerous argument that can be used to justify things with no real use case

[16:49:16.0000] <Hixie>
othermaciej: i'm totally on board with the idea that we should provide extension points for things like that, and indeed we do. for example, tabindex="" lets you hook into the focus system. but it's impossible to design good APIs for such things without use cases, IMHO.

[16:49:17.0000] <SamB>
which is why it would probably be best if you could implement it in terms of contentEditable, but still be compatible with a real textarea ...

[16:50:50.0000] <Hixie>
TabAtkins: on an unrelated note, the definition of :focus says that something matches :focus when it "accepts ... mouse events", which seems unlikely to be intended

[16:51:04.0000] <SamB>
othermaciej: Yes, which is why you should look at the places they've already run up against the boundaries. And, while you're at it, be amazed at what they've accomplished anyway (and how)

[16:51:42.0000] <SamB>
Hixie: using the old understatement, are we?

[16:51:43.0000] <rafaelw>
hixie: qq. for clients of "await a stable state", why not instead have them enqueue a microtask?

[16:52:00.0000] <Hixie>
rafaelw: microtasks didn't exist at the time

[16:52:20.0000] <Hixie>
rafaelw: but more importantly, the idea is that all the "await a stable state" cases can run in parallel

[16:52:25.0000] <Hixie>
rafaelw: whereas microtasks are serialised

[16:52:44.0000] <rafaelw>
why is it important for those clients to run in parallel?

[16:52:46.0000] <SamB>
so, is dot's syntax highlighter something or what?

[16:53:30.0000] <Hixie>
rafaelw: well, if we maintain that invariant it allows for a more optimal mutlithreaded implementation

[16:53:37.0000] <Hixie>
multithreaded

[16:53:49.0000] <SamB>
Hixie: you need magic dust to sleep in parallel now?

[16:54:00.0000] <rafaelw>
are there clients that do cpu-intensive algorithms?

[16:54:17.0000] <Hixie>
SamB: not to sleep, to do the work

[16:54:32.0000] <slightlyoff>
SamB: RE: custom textarea, I've had many others

[16:54:35.0000] <SamB>
oh, so you want them to wake up in parallel somehow?

[16:54:36.0000] <Hixie>
rafaelw: media stuff, dunno how cpu-intensive it is. probably not much.

[16:54:48.0000] <slightlyoff>
SamB: for instance, I once implemented a shortcut-expansion system for doctors

[16:54:57.0000] <rafaelw>
seems like premature optimization.

[16:55:11.0000] <Hixie>
rafaelw: it wasn't an optimisation at all, originally, microtasks didn't exist.

[16:55:16.0000] <slightlyoff>
they entered their content in their pidgen language and hit "tab" to expand or skip through the boilerplate

[16:55:28.0000] <rafaelw>
i'm not complaining about the past. i'm asking if we can unify now.

[16:55:47.0000] <SamB>
wouldn't it make more sense to have some kind of *abstraction* that allows some kind of potentially-parallel tasks to be enqueued?

[16:55:49.0000] <Hixie>
rafaelw: ah, ok, i thought you were asking why they were like that before

[16:55:50.0000] <slightlyoff>
SamB: and implementing it on top of textarea was downright painful. Would have been happier for lower-level control of the data and focus models

[16:55:51.0000] <Hixie>
rafaelw: let's see...

[16:56:29.0000] <slightlyoff>
SamB: that neither you nor I thought of that ahead of time is the key reason that extensibility and layering matter. We won't think of everything

[16:56:34.0000] <Hixie>
rafaelw: one case where stable states run but not microtasks is when you call alert(), that might be relevant...

[16:57:07.0000] <Hixie>
rafaelw: other than that, doesn't look like there's much reason one way or the otehr

[16:57:13.0000] <rafaelw>
i only see two clients of awaiting a stable state: img & media.

[16:57:25.0000] <SamB>
whenever I see something like "wait for" in these specs I'm never quite sure what is meant

[16:57:41.0000] <rafaelw>
it's a bit hard to tell, but it seems like the reason they are awaiting a stable state is basically "wait until i'm done being configured" (IOW, when script has exited).

[16:57:46.0000] <rafaelw>
am i misunderstanding?

[16:58:16.0000] <Hixie>
rafaelw: microtasks are more heavyweight, and tend to be more author-visible (e.g. they involve DOM mutations or script callbacks), whereas stable states are just about async algorithms having step they want to run when the DOM is in a known stable state.

[16:58:25.0000] <Hixie>
rafaelw: it's more about getting a lock on the DOM than anything else

[16:58:29.0000] <Hixie>
rafaelw: read lock

[16:58:46.0000] <Hixie>
(*having steps)

[16:59:23.0000] <Hixie>
rafaelw: changing some of these algorithms to use microtasks would be kinda awkward, but in principle i suppose it would be equivalent.

[16:59:29.0000] <Hixie>
rafaelw: i don't see much benefit to changing it though.

[17:00:29.0000] <rafaelw>
in blink i'd prefer to have one mechanism for "running soon when there's no script below me", rather than two.

[17:00:51.0000] <Hixie>
yeah i think it'd be quire reasonable to implement the stable state stuff as a microtask.

[17:00:54.0000] <Hixie>
quite

[17:01:12.0000] <Hixie>
foolip was working on the stable state stuff recently, fwiw

[17:01:17.0000] <rafaelw>
ok. shall i open a bug for that?

[17:01:17.0000] <Hixie>
(in blink)

[17:01:28.0000] <Hixie>
open a bug for what?

[17:01:53.0000] <Hixie>
there's still the alert() difference

[17:02:03.0000] <rafaelw>
aw. sorry. nm. you prefer to keep the notion of stable state in the spec.

[17:02:18.0000] <Hixie>
i mean i can make sure there's a note saying that they can be implemented as the same thing

[17:02:28.0000] <Hixie>
but i would imagine it depends a lot on how it's implemented

[17:02:29.0000] <rafaelw>
why does alert() provide a stable state?

[17:03:10.0000] <Hixie>
because you don't want <script> new Audio('myradio').play(); alert('ok, listen up!'); </script> to not even start the download until you hit ok

[17:03:20.0000] <Hixie>
you want it to just play

[17:03:45.0000] <rafaelw>
seems like a misfeature.

[17:03:50.0000] <Hixie>
the way the spec specs the stable states is more akin to joining the main thread than pushing a task on a queue, fwiw. so i think it is conceptually different, even though they can be implemented in terms of each other.

[17:03:54.0000] <Hixie>
what's a misfeature?

[17:04:22.0000] <rafaelw>
alert() providing a stable state.

[17:04:26.0000] <Hixie>
why?

[17:04:34.0000] <Hixie>
you think in that example the file shouldn't download until you hit ok?

[17:04:41.0000] <Hixie>
that seems highly unintuitive and annoying for users

[17:05:34.0000] <esprehn>
rafaelw: stable state is "hit the event loop" for us, alert() spins a nested event loop so you get that behavior "for free" I think

[17:05:48.0000] <rafaelw>
alert blocks the thread. if i'm an app and I use alert, no code after the alert runs. it's super weird if audio starts playing.

[17:06:39.0000] <Hixie>
 <script> var a = new Audio('hugefile.ogg'); alert('hit ok to start music'); a.play(); </script>

[17:06:48.0000] <Hixie>
you don't want the download to wait until you hit ok.

[17:07:39.0000] <SamB>
rafaelw: you'd get the same thing on practically any toolkit

[17:07:43.0000] <jamesr__>
what part of this awaits a steady state? play() ?

[17:08:02.0000] <Hixie>
the constructor calls load(), effectively, and load() waits

[17:08:18.0000] <Hixie>
so that it can read the src="" or <source> without clashing with DOM manipulation code

[17:08:29.0000] <Hixie>
(since it's running async -- it basically joins the main thread to read the DOM)

[17:10:02.0000] <rafaelw>
basically, it's not worth it to me to weird-up a core notion of separation of concerns (microtasks/stable state/etc..) in order to accomodate alert

[17:10:08.0000] <rafaelw>
or showModalDialog for that matter.

[17:10:13.0000] <rafaelw>
showModalDialog should die in a fire.

[17:10:17.0000] <jamesr__>
well i think this is orthogonal to the discussion but i don't see any reason to await a steady state to read a dom attribute

[17:10:24.0000] <rafaelw>
alert should only be used for debugging.

[17:10:45.0000] <Hixie>
jamesr__: well you need to join the main thread, right?

[17:11:39.0000] <Hixie>
rafaelw: i don't disagree with you in principle, but i also think it's critical that the download start before you hit ok in the case above. I think a simpler solution would just be to have alert() and friends do a microtask checkpoint, but then it would make debugging harder. so maybe it's just best to have some microtask checkpoints only do the stable state microtasks.

[17:11:50.0000] <Hixie>
rafaelw: either way, it seems trivial to implement once you can do it anywhere else.

[17:12:04.0000] <Hixie>
rafaelw: i mean, it's just a flag "only include these microtasks", right

[17:12:14.0000] <rafaelw>
alert() cannot do a microtask checkpoint().

[17:12:22.0000] <rafaelw>
it violates the central invariant.

[17:12:48.0000] <Hixie>
right, so like i just said, you'd just do a checkpoint that excludes the tasks that aren't currently "stable state" cases

[17:13:22.0000] <Hixie>
just like some algorithms spin the main event loop while having put a block on certain task sources.

[17:14:19.0000] <rafaelw>
why is it critical that the download start in that case?

[17:14:23.0000] <jamesr__>
Hixie: var a = new Audio('data:...').play(); while(1) {} - why can't that play?

[17:15:23.0000] <Hixie>
jamesr__: that case probably could, but consider the case of  var a = new Audio(); a.appendChild(document.createElement('source')); ...

[17:15:32.0000] <Hixie>
jamesr__: the constructor starts the load asynchronously.

[17:15:42.0000] <Hixie>
jamesr__: that algorithm then starts running, but it's not on the main thread

[17:16:16.0000] <Hixie>
jamesr__: at some point that algorithm needs to inspect the <video> or <audio> element to figure out what attributes and children elements it has, so it can kick off loads of the media file, the text tracks, etc.

[17:16:57.0000] <Hixie>
jamesr__: those loads are themselves async, and sometimes the loads fail, and then the algorithm needs to reinspect the media element to work out what next to try to load

[17:17:00.0000] <Hixie>
jamesr__: and so on

[17:17:20.0000] <Hixie>
jamesr__: this is especially relevant while parsing, since the parser itself is just doing one bit at a time as a task on the event loop

[17:17:32.0000] <Hixie>
jamesr__: so it might parse enough to add the media element, but not enough to get the first <source>

[17:17:45.0000] <Hixie>
jamesr__: <video> <!-- network delay... --> <source ...>

[17:30:16.0000] <Hixie>
esprehn: so, i'm studying what it would take to hook into the focus model like you were saying. The main thing I specced that wasn't specced before, and for which there's no "hook", isn't actually related to dialogs, it's about things like the viewport and 'overflow:scroll' scroll regions.

[17:30:32.0000] <Hixie>
esprehn: is it ok that you can hook into the focus model with tabindex="" at the element level, but not at the CSS box level?

[17:31:03.0000] <Hixie>
esprehn: or, in the "extensible Web" model, should it also be possible to add focusable CSS boxes somehow?

[17:31:29.0000] <esprehn>
how do you get a css box that doesn't have an associated element?

[17:31:55.0000] <Hixie>
well e.g. the viewport doesn't have an associated element

[17:32:02.0000] <Hixie>
also you could have multiple boxes for one element

[17:32:08.0000] <Hixie>
e.g. div::before { overflow: scroll }

[17:32:22.0000] <esprehn>
I think all engines transfer focus to the "nearest" (there's a vague definition of this) element when you hit an anonymous thing

[17:32:34.0000] <esprehn>
the viewport being focused is like the document being focused I suppose

[17:32:38.0000] <Hixie>
what do you mean by "transfer focus"?

[17:33:17.0000] <esprehn>
if you click a ::before {} thing, we make appear like you actually clicked the thing that owns the ::before

[17:33:53.0000] <esprehn>
it's a sort of weird version of Shadow DOM retargeting

[17:34:30.0000] <Hixie>
sure but for keyboard access we presumably still want them to _actually_ be individually focusable, right?

[17:34:41.0000] <Hixie>
so my question is, how would you create one of these from script?

[17:35:31.0000] <esprehn>
That's an interesting question, I don't think a lot of thought has gone into focusing anonymous content

[17:36:08.0000] <esprehn>
we do some strange things, I don't think browsers agree on where the caret goes if you click a ::before in a content editable

[17:36:29.0000] <Hixie>
so is it ok if the API doesn't "explain" that ::before might be focusable?

[17:36:30.0000] <esprehn>
Hixie: Gecko, Blink and Webkit all create a real Element for ::before/::after and ::backdrop

[17:37:00.0000] <esprehn>
yeah, at some point we need to explain ::before, and we can deal with it being individually focusable at that point

[17:37:09.0000] <esprehn>
I don't think any browser lets you individually focus anonymous content today

[17:37:22.0000] <Hixie>
sure, but that's a bug, right?

[17:37:34.0000] <Hixie>
i mean, it's an accessibility and keyboard access problem that it's not possible today

[17:38:35.0000] <Hixie>
how about Document objects and browsing contexts?

[17:38:36.0000] <esprehn>
Hixie: yeah, I think the idea was that someday you could do element.getPseudoElement("before") and then add event listeners, tabindex, aria roles etc.

[17:38:39.0000] <Hixie>
how do we "explain" those?

[17:39:16.0000] <esprehn>
That's harder, I think slightlyoff has some deeper insight into the innards of them. I couldn't give you a concrete set of primitives on the spot here.

[17:39:26.0000] <Hixie>
k...

[17:39:35.0000] <Hixie>
is there a spec anywhere that i could look at that tries to explain these things?

[17:39:38.0000] <Hixie>
so i can integrate with it?

[17:39:41.0000] <slightlyoff>
pseudo elements are mostly BS. they should have DOM

[17:39:48.0000] <slightlyoff>
Shadow DOM actually helps you there

[17:39:55.0000] <JosephSilber>
slightlyoff: really?

[17:40:05.0000] <slightlyoff>
you can explain that all elements have existing SD that isn't populated

[17:40:16.0000] <slightlyoff>
and that the pseudo elements populate it

[17:40:23.0000] <esprehn>
Hixie: that's a really good question, I don't think we have a good spec for the "foundations of the web" primordial goop. Perhaps we should have a long term plan.

[17:40:25.0000] <slightlyoff>
maybe you don't make it available to scripting, but at least you're out of the conceptual woods

[17:40:51.0000] <slightlyoff>
document objects and browsing contexts need more work. We haven't done the archeology yet

[17:40:54.0000] <slightlyoff>
it's an important project

[17:40:56.0000] <esprehn>
Hixie: slightlyoff has written a bunch about it, but I don't think there's a doc that says "Documents do X, we need to explain it" with bugs to fill in the sections

[17:40:58.0000] <slightlyoff>
one we should stop delaying

[17:41:45.0000] <Hixie>
esprehn: fwiw, looking at the <dialog> stuff specifically, it's actually the least magical of all the stuff here. A straight <dialog open> where you haven't invoked showModal() is just basically a <div> that hooks into the focus model as an owner, just like a <div tabindex=""> is a <div> that hooks into the focus model as an area. So in a way, <dialog> actually _is_ explaining the model.

[17:42:26.0000] <Hixie>
slightlyoff: fwiw, the HTML spec documents the status quo on those in more or less complete detail now (this focus stuff being the last big missing piece, i think)

[17:42:34.0000] <esprehn>
Hixie: I'm not sure I understand

[17:42:45.0000] <Hixie>
slightlyoff: so feel free to use that as a resource

[17:42:49.0000] <esprehn>
what is <dialog> explaining?

[17:43:05.0000] <Hixie>
esprehn: it's basically the "explained" version of being a Document in the focus mdoel

[17:43:08.0000] <Hixie>
mdoel

[17:43:09.0000] <Hixie>
m o d e l

[17:43:20.0000] <slightlyoff>
Hixie: its' really good that way. Thank you.

[17:44:03.0000] <esprehn>
Hixie: interesting.

[17:44:58.0000] <Hixie>
esprehn: there's two kinds of primitives in the focus model, basically. Areas (things you can focus), and owners (things that can group areas so you can tab between them). Before, there was just Documents in the second category. In the first category there's all kinds of magical stuff, plus anything on which you put tabindex="0", which is basically the "explain hook" for focusable areas.

[17:45:17.0000] <Hixie>
esprehn: so now, <dialog open> acts as the "explain hook" for owners

[17:45:29.0000] <esprehn>
Hixie: exactly, that's why I was saying you should add a tabgroup attribute that is the "owners" category

[17:45:37.0000] <Hixie>
esprehn: so to answer your earlier question about tab groups, i think the answer is you just use a <dialog open> as each tab group

[17:45:48.0000] <esprehn>
spec that dialog's tabgroup attribute should compute to something like we do for tabindex on <input>

[17:45:57.0000] <Hixie>
esprehn: and you flip between them, making whichever one is active not inert, and all the others inert

[17:46:13.0000] <Hixie>
esprehn: is an attribute more "explainy" than an element?

[17:46:23.0000] <esprehn>
yes

[17:46:31.0000] <Hixie>
esprehn: the advantage of doing it on an element only is that it avoids tons of crazy complexity and edge cases that have little value

[17:47:29.0000] <esprehn>
I should be able to trap the tab index cycling inside an arbitrary area of the page without adding <dialog open> around it.

[17:48:06.0000] <Hixie>
why? or rather, why should it be possible without adding <dialog open>, but not without adding <div tabgroup="">?

[17:48:18.0000] <Hixie>
i don't understand the difference

[17:48:42.0000] <esprehn>
Hixie: because the only part of dialog I care about is the focusing behavior. That's why tabgroup is a primitive. I only need to use the tabgroup if that's all I want

[17:49:03.0000] <esprehn>
<dialog> has showModal(), but calling it on that part of the page is nonsense, it's not a modal dialog

[17:49:59.0000] <esprehn>
Hixie: XMLHttpRequest can decode JSON, but we still expose JSON.parse since creating an XHR object to decode JSON is silly. You don't need that whole thing just for the one part of it.

[17:51:01.0000] <esprehn>
If you want to be in the top layer, use the top layer API. If you want to trap focus use tabgroup. If you want both, and center positioning and other API stuff use <dialog>.

[17:52:00.0000] <Hixie>
esprehn: but <div tabgroup> has forceSpellCheck(), which you don't care about either. Why is it ok for it to have that, but not ok for it to have showModal()?

[17:53:03.0000] <Hixie>
esprehn: JSON.parse() is different because it's simpler to use JSON.parse() than to cycle content through XHR. In this case, though, it's more or less the same, just syntactic sugar that's different.

[17:53:11.0000] <Hixie>
<div tabgroup> vs <dialog open>

[17:53:28.0000] <Hixie>
the dialog one is even shorter by one character :-)

[17:53:30.0000] <esprehn>
I'm not sure any arbitrary element should support forceSpellCheck() either, does any browser implement that?

[17:54:09.0000] <esprehn>
I guess it sort of lines up with contenteditable

[17:54:23.0000] <Hixie>
yeah, it's for contenteditable.

[17:54:39.0000] <esprehn>
Hixie: having forceSpellCheck on Element seems like a bug, you're missing a real editing API so you're adding API surface to Element

[17:54:56.0000] <Hixie>
contenteditable is on HTMLElement also

[17:55:01.0000] <esprehn>
yeah

[17:55:19.0000] <Hixie>
click() is on every element also

[17:55:26.0000] <Hixie>
you don't care for click() on the tabgroup element

[17:55:29.0000] <esprehn>
you can imagine that adding contenteditable does something like "new Editor(this)"

[17:55:42.0000] <esprehn>
and that editor has spellchecking and such

[17:56:02.0000] <esprehn>
Hixie: why don't you? It's rendered if the things inside it are focusable.

[17:56:18.0000] <esprehn>
perhaps the group has a border and background, why can't a simulate a click on it?

[17:56:21.0000] <Hixie>
so? why would you ever want to fake a click to a non-interactive element?

[17:56:43.0000] <Hixie>
anyway

[17:56:45.0000] <esprehn>
why is it not interactive? Maybe it's draggable.

[17:56:54.0000] <Hixie>
click() wouldn't help you with that

[17:57:03.0000] <esprehn>
true, but it could have other behavior on click

[17:57:21.0000] <Hixie>
my point is i don't understand why it's ok to have these APIs but not the five <dialog> APIs

[17:57:35.0000] <Hixie>
heck, i would even argue that <dialog>'s form integration is something you _would_ want

[17:58:04.0000] <esprehn>
you mean the properties on Document? (the 5 APIs?)

[17:58:28.0000] <Hixie>
i mean <dialog>.open, .returnValue, .show(), .showModal(), and .close()

[17:58:59.0000] <esprehn>
I don't understand, I'm not arguing about the API surface on <dialog> itself

[17:59:28.0000] <Hixie>
what did you mean when you said "because the only part of dialog I care about is the focusing behavior" then ?

[17:59:51.0000] <esprehn>
Hixie: you want to be a tabgroup so that going to the last control and hitting tab again goes back to the first

[18:00:05.0000] <Hixie>
right, that's one of the main things <dialog> does.

[18:00:38.0000] <Hixie>
so why is it not ok to use <dialog>, but it is ok to use <div tabgroup>?

[18:01:06.0000] <Hixie>
my point is both <div> and <dialog> have other baggage, so why is one ok but not the other?

[18:01:29.0000] <esprehn>
Because we decided <div> is a building block, I think slightlyoff might argue that even that isn't enough, and we should provide a real FocusController API someday that <div> calls when you set tabgroup.

[18:01:43.0000] <slightlyoff>
yep!

[18:02:03.0000] <Hixie>
well we certainly shouldn't require that the author use script to do this

[18:02:04.0000] <esprehn>
today <div> is like NSView, it's pretty bare metal and way below <dialog>

[18:02:17.0000] <Hixie>
<div> and <dialog> are almost identical.

[18:02:29.0000] <slightlyoff>
Hixie: don't confuse "can" with "require"

[18:02:45.0000] <slightlyoff>
Hixie: I only ask that <div> (et. al.) be explained, not that we stop adding high-level stuff

[18:03:04.0000] <esprehn>
Hixie: The spec says we should treat <input> as if it had a tabindex IIRC

[18:03:26.0000] <esprehn>
"Modulo platform conventions, it is suggested that for the following elements, the tabindex focus flag be set"

[18:03:28.0000] <Hixie>
esprehn: right. i wouldn't have added tabindex="" if i had anything to do with it, i think it's a poor way to solve the problem. :-)

[18:04:01.0000] <Hixie>
i really have to go. i'll look into this some more. it'd be easy to retrofit a tabgroup="" attribute into this if for some reason <dialog open> isn't a good enough "explanation", anyway.

[18:04:19.0000] <esprehn>
Hixie: thanks for looking into it, lets continue this later.

[18:04:36.0000] <Hixie>
maybe we can skip the attribute and explain it directly in terms of something slightlyoff would like, so we would have two layers instead of having three layers :-)

[18:04:42.0000] <Hixie>
ttyl

[18:04:58.0000] <slightlyoff>
later

[18:18:41.0000] <Domenic_>
hahaha http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Feb/0086.html

[18:18:51.0000] <Domenic_>
my first thought was "this is whatwg@whatwg, not public-html"

[18:19:01.0000] <Domenic_>
but then i saw he brought public-html into the conversation

[23:58:19.0000] <MikeSmith>
reading http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html#attributes-common-to-ins-and-del-elements can anybody tell me if they see any UA requirements that actually testable there?

[23:58:41.0000] <MikeSmith>
I see that the spec says "User agents must parse the datetime attribute according to the parse a date or time string algorithm. If that doesn't return a date or a global date and time, then the modification has no associated timestamp"

[23:59:16.0000] <MikeSmith>
but it never requires the UA to actually do anything with the parsed value

[23:59:46.0000] <MikeSmith>
it doesn't state any specific means for exposing the parsed value

[00:30:32.0000] <zcorpan>
jgraham: do you know if table_inspector.py is around somewhere?

[01:39:50.0000] <vmatva>
Hi everybody. I'm new to all this things around IRC.

[01:40:37.0000] <vmatva>
I'm about to post a bug about DOM3 Events spec. Is it right place to discuss it before to post to bugzilla?

[02:13:10.0000] <zcorpan>
vmatva_: it seems like an appropriate place, although i think the editors of that spec aren't regulars here. also some of that spec is obsoleted by http://dom.spec.whatwg.org/#events

[02:19:11.0000] <zcorpan>
foolip: Hixie: whether a load starts in the face of alert() seems not so relevant. in fact if alert() is used for debugging it seems like it would be better if it did not start to load stuff while the alert is showing

[02:23:20.0000] <foolip>
zcorpan: good point, that would be pretty confusing

[02:24:01.0000] <foolip>
zcorpan: here are three bugs you may want to follow:

[02:24:13.0000] <foolip>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24361

[02:24:13.0000] <foolip>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24707

[02:24:14.0000] <foolip>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24724

[02:24:46.0000] <vmatva_>
zcorpan: Thank you. I have already created a bug in the appropriate W3C bugzilla section. I read document 'DOM 3 Events' by W3C (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html) as it contains more details than one referenced by you.

[02:26:46.0000] <zcorpan>
vmatva_: it actually contains less details

[02:27:47.0000] <vmatva_>
zcorpan: this is URL of bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24729

[02:29:28.0000] <vmatva_>
zcorpan: Ok. I look at section http://dom.spec.whatwg.org/#events And I do not see any description of MouseEvent of WheelEvent. But I see it in W3C document.

[02:29:53.0000] <zcorpan>
vmatva_: thx. ok yeah for WheelEvent, dom3events is the right spec, or possibly https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm

[02:32:39.0000] <vmatva_>
zcorpan: Yep. I looks at latest versions of both W3C specs (DOM3 Events and UI Events). But still see that inconsistence that I described in bug.

[02:33:09.0000] <zcorpan>
vmatva_: yeah

[02:38:19.0000] <zcorpan>
vmatva_: it also gets CustomEvent and CustomEventInit wrong

[02:39:36.0000] <zcorpan>
/me never got the point of CustomEvent

[02:41:22.0000] <zcorpan>
MikeSmith: "This value may be shown to the user"

[02:42:38.0000] <zcorpan>
MikeSmith: so a manual test, with the condition that the UA does show it to the user

[02:45:43.0000] <MikeSmith>
zcorpan: ok

[02:59:31.0000] <jgraham>
zcorpan: I think it was once on html5.org. But I'm not sure

[03:00:32.0000] <zcorpan>
jgraham: http://james.html5.org/tables/table_inspector.py

[03:02:17.0000] <jgraham>
Interesting. Then "i'm not sure". I could have a dig around at home I guess

[03:04:41.0000] <zcorpan>
ok. i wanted to try it on hixie's focus table :-)

[03:15:12.0000] <zcorpan>
jgraham: should we ask youennf for an opinion on https://github.com/w3c/web-platform-tests/pull/556 or just merge?

[03:20:32.0000] <vmatva_>
zcorpan: I don't see any mention of CustomEvent in UI Events at all.

[03:24:18.0000] <zcorpan>
vmatva_: i mean in dom3events

[03:24:50.0000] <jgraham>
zcorpan: merged

[03:53:23.0000] <zcorpan>
TabAtkins: yoav: can you have a look at https://github.com/ResponsiveImagesCG/picture-element/pull/103 please?

[03:56:33.0000] <marcosc>
zcorpan: lgtm

[03:57:26.0000] <zcorpan>
marcosc: thx. can you merge? :-)

[03:57:48.0000] <marcosc>
zcorpan: done

[03:58:00.0000] <zcorpan>
neato

[03:58:38.0000] <marcosc>
zcorpan: yoav will have to regenerate the spec tho. I don't know if I have what I need to regenerated the spec on this machine.

[03:58:50.0000] <zcorpan>
yeah

[04:00:20.0000] <yoav>
Willdo

[04:00:32.0000] <yoav>
s/d/ d/

[04:37:24.0000] <zcorpan>
hmm. "select an image source" should work even when there's no <picture> parent

[10:27:17.0000] <JonathanNeal>
Is ARIA a part of ADA?

[10:44:42.0000] <TabAtkins>
marcosc: There's a network version of Bikeshed, you know, linked in the docs. Just curl to it (or use the webform to do it manually).

[10:45:48.0000] <Domenic_>
still trying to wean people off ReSpec? :P

[10:46:08.0000] <TabAtkins>
Domenic_: Really I'm just trying to kill off the old CSSWG processor. ^_^

[10:46:15.0000] <TabAtkins>
But the picture spec is bikeshedded.

[10:46:24.0000] <TabAtkins>
Bikeshedded already, I mean.

[10:47:22.0000] <Domenic_>
i was considering bikeshed, but like anolis, it seems hard to install on Windows.

[10:47:52.0000] <TabAtkins>
Indeed it is.  Nobody's seriously tried it yet, so I dont' have install instructions, and it's probably difficult to do anyway.

[10:47:59.0000] <TabAtkins>
Fucking *everything* is hard to do on Windows.

[10:48:13.0000] <TabAtkins>
But that's why we have a network service for it.

[10:48:19.0000] <TabAtkins>
(Though curling is *also* hard on Windows...)

[11:49:08.0000] <gsnedders>
Anyone around with Opera BTS access able to tell me what CARAKAN-871 is about?

[11:54:50.0000] <erlehmann>
units!

[11:54:53.0000] <erlehmann>
i like that kind of thing

[11:58:27.0000] <aklein>
annevk-cloud: still around by any chance?

[11:59:08.0000] <aklein>
annevk-cloud: curious about what you had in mind with forcing <link rel=import> to have UTF-8 encoding

[12:23:16.0000] <gsnedders>
mathiasbynens: Why are Object.prototype.__defineGetter__ and __defineSetter__ defined to do stuff with black magic instead of creating a getter/setter property on the object? It leaves a lot undefined.

[12:24:06.0000] <gsnedders>
mathiasbynens: Like, at step four you set [[Enumerable]] of the property to true… but it might not exist yet!

[12:28:20.0000] <Hixie>
MikeSmith: <ins>/<del> are mostly just legacy from HTML4, so yeah, there's not much for UAs to do with them unless they're conformance checkers or analysis tools of sorts

[12:32:22.0000] <Domenic_>
Hmm I use <ins> and <del> a lot

[12:32:36.0000] <Domenic_>
What is preferred?

[12:38:31.0000] <Hixie>
Domenic_: preferred for what?

[12:38:58.0000] <Domenic_>
Hixie: marking up edits to a document or post, for example.

[12:39:18.0000] <Hixie>
<ins> and <del> are the only dedicated way to do that in html as far as i know

[12:40:01.0000] <Domenic_>
So in what sense do you mean they're legacy from HTML4?

[12:41:15.0000] <Hixie>
they came from HTML4, we didn't invent them since

[12:41:27.0000] <Hixie>
like <p> is legacy from the first draft of HTML

[12:41:31.0000] <Domenic_>
ah ok, so not "bad" legacy

[12:41:33.0000] <Hixie>
and <table> is legacy from like HTML2 or so

[12:42:00.0000] <Hixie>
no, i meant it in its sense of "a thing handed down by a predecessor"

[12:42:08.0000] <Hixie>
not "denoting software or hardware that has been superseded but is difficult to replace because of its wide use"

[12:42:13.0000] <Hixie>
sorry for the confusion

[12:43:13.0000] <erlehmann>
i use ins and del as well

[12:43:17.0000] <erlehmann>
i even wrote stylesheets there!

[12:43:50.0000] <erlehmann>
http://daten.dieweltistgarnichtso.net/src/css-del-ins.html

[12:49:46.0000] <gsnedders>
mathiasbynens: https://github.com/whatwg/javascript/issues/18

[12:50:38.0000] <Hixie>
jgraham: zcorpan: looks like some version of the source is at http://html5.googlecode.com/svn/trunk/tables/web/cgi-bin/table_inspector.py

[13:11:03.0000] <mathiasbynens>
gsnedders: nice, thanks. got a link to that bz mail?

[13:11:24.0000] <gsnedders>
mathiasbynens: Nah, it was somewhat tangential anyawy

[13:11:31.0000] <gsnedders>
mathiasbynens: (personal email, about stuff around opjsunit)

[13:11:37.0000] <gsnedders>
(Nothing that interesting in it)

[13:36:03.0000] <zewt>
things that strongly discourage me from bothering with html validation: pages of bogus warnings about custom ports, and equally bogus warnings about rel=noreferer

[13:40:06.0000] <Hixie>
custom ports?

[13:46:19.0000] <zewt>
local development server is on port 81; validators spew dozens of warnings about https://foo.com:81 links

[13:47:58.0000] <zewt>
(internal, rather; not on the local network, not that it matters)

[13:48:34.0000] <zewt>
is there a validator that'll let me shut up particular warnings that I'm not interested in "fixing"?

[13:51:40.0000] <Hixie>
why would validators spew dozens of warnings about https://foo.com:81 links?

[13:51:54.0000] <Hixie>
what's the warning?

[13:52:07.0000] <zewt>
"ports under 1024 should be accessed using the appropriate scheme name"

[13:52:36.0000] <Hixie>
o_O

[13:53:07.0000] <zewt>
i can't even think of a case where that warning makes sense

[13:53:46.0000] <Domenic_>
80 or 443?

[13:53:48.0000] <Hixie>
especially since 81 is unassigned...

[13:54:26.0000] <zewt>
no, 81 (some random arbitrary port; I think it used to be an alternate HTTP server dropped on 80+1, then later became https)

[13:55:17.0000] <Hixie>
have you filed a bug with the validator in question?

[13:56:10.0000] <zewt>
no, since it happened on two validators in a row (html5.validator.nu, validator.w3.org; based on the output I assume they're basically the same thing)

[13:56:37.0000] <Hixie>
you found the same bug on two instances of the same validator and so you didn't file a bug?

[13:56:48.0000] <Hixie>
file a bug dude.

[13:59:32.0000] <zewt>
file a bug where? likely not on those websites if there's some underlying codebase, and the usefulness I find in validators doesn't motivate me to figure that out, or to debate with whoever it goes to

[14:00:30.0000] <Hixie>
http://bugzilla.validator.nu/enter_bug.cgi

[14:00:45.0000] <Hixie>
if you can't be bothered to file a bug, please don't complain here :-)

[14:01:27.0000] <zewt>
filing bugs risks a high time investment

[14:02:02.0000] <gsnedders>
Hixie: Wait, what, we can't bitch here about random shit? :(

[14:02:27.0000] <Hixie>
gsnedders: you can, you file bugs when you bitch.

[14:02:53.0000] <Hixie>
pretty much everyone who bitches here files bugs as they're bitching, even when they are pretending to not care :-)

[14:04:26.0000] <Hixie>
but saying that validators are useless because they have a bug, passively aggressively "threatening" to not use them any more, and then saying that helping make validators better is a "risky investment", seems kinda ridiculous even for #whatwg.

[14:04:42.0000] <gsnedders>
Hixie: Bah! When I don't care I just prod people who will. :)

[14:04:51.0000] <Hixie>
like i said :-)

[14:05:06.0000] <gsnedders>
And I dunno, doesn't seem that ridiculous. There again, my logic *is* all the way over by the door, so I might not be thinking rationally. :)

[14:24:50.0000] <Hixie>
how the heck do you find the element that a touchmove event is over?

[14:25:56.0000] <Hixie>
like, if i want to get the list of elements that a user swiped over

[14:35:38.0000] <TabAtkins>
elementFromPoint()?

[14:36:00.0000] <TabAtkins>
/me isn't familiar with the touch* events, so can't tell if there's an easier way.

[14:37:26.0000] <Hixie>
yeah, looks like elementFromPoint() is the only way

[14:37:45.0000] <Hixie>
would be good if those methods took a MouseEvent or TouchEvent

[15:08:08.0000] <Hixie>
oh man

[15:08:23.0000] <Hixie>
touch events are non-trivial to use

[15:08:38.0000] <Hixie>
i wish each touch would just be its own object with events firing on it

[15:08:55.0000] <Hixie>
instead of having to track touch.identifier

[15:50:57.0000] <Hixie>
ok, got it working. http://damowmow.com/playground/demos/touch/001.html

[15:53:59.0000] <marcosc>
TabAtkins: thanks, sorry I missed that in the docs


2014-02-20
[19:59:38.0000] <MikeSmith>
zewt: http://validator.w3.org/nu/ has an option that lets you persistently filter out any errors or warnings you don't want to see

[20:01:12.0000] <MikeSmith>
after you check a document, you'll see a "Message filtering" button. If you press that, it'll show you all the messages with  show/hide checkboxes

[20:02:53.0000] <MikeSmith>
but I don't know why it would be giving errors or warnings for non-80 ports

[20:24:11.0000] <MikeSmith>
OK after looking at the code I find the reason you're seeing that message is because of the library we're currently using for URL checking

[20:24:29.0000] <MikeSmith>
it has a warning case for this

[20:24:30.0000] <MikeSmith>
http://jena.sourceforge.net/iri/javadoc/com/hp/hpl/jena/iri/ViolationCodes.html#PORT_SHOULD_NOT_BE_WELL_KNOWN

[20:25:13.0000] <MikeSmith>
and the reason that library does it is because of http://www.apps.ietf.org/rfc/rfc3986.html#sec-7.2

[20:26:56.0000] <MikeSmith>
but I agree there's no reason we should be emitting it from the validator so I'll patch the sources to just drop it on the floor

[20:27:09.0000] <MikeSmith>
for now

[20:28:05.0000] <MikeSmith>
but the plan is to replace that library anyway, using smola's library that's based on the current URL standard

[20:49:40.0000] <MikeSmith>
zewt: fixed https://github.com/validator/syntax/commit/d815de537a86d4334294725d40f077ee2eb0cde9

[20:49:53.0000] <MikeSmith>
and pushed to http://validator.w3.org/nu/

[20:51:06.0000] <MikeSmith>
Hixie: about ins & del the thing that confused me is that there are UA requirements there but I couldn't see how to actually test that UA conforms to them

[21:33:00.0000] <MikeSmith>
Hixie: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Feb/0100.html doesn't seem like a usability win

[21:33:21.0000] <MikeSmith>
(message from tkent about input@type=number)

[22:18:37.0000] <Hixie>
MikeSmith: yeah, there's been a bunch of feedback on type=number that i need to go through

[22:19:18.0000] <Hixie>
MikeSmith: re ins/del, you mean about parsing datetime?

[22:19:26.0000] <MikeSmith>
Hixie: yeah, that

[22:19:50.0000] <Hixie>
MikeSmith: that's mostly just there in case a tool wants to do something with the attribute... but yeah, nobody is required to do anything with it, so it's a bit fluffy

[22:19:58.0000] <MikeSmith>
ok

[22:22:47.0000] <Hixie>
Makefile:16: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.

[22:22:59.0000] <Hixie>
i think the existence of that error message is an insult.

[22:26:31.0000] <zcorpan>
i often mistakenly type 8 spaces when i forget it's much easier to press that other key in notepad

[22:31:28.0000] <MikeSmith>
the joys of makefiles

[22:31:58.0000] <MikeSmith>
I guess to be cool you're supposed to be using something else these days

[22:34:14.0000] <zcorpan>
implement make in javascript

[22:41:50.0000] <MikeSmith>
/me wonders if zcorpan is traveling or just up early

[22:44:08.0000] <zcorpan>
the latter, but i'm usually up early when wfh

[22:45:59.0000] <MikeSmith>
seems to me then you probably don't sleep enough

[22:48:06.0000] <zcorpan>
around 8h

[22:49:45.0000] <MikeSmith>
oh

[22:50:00.0000] <MikeSmith>
well then I guess you do

[22:50:18.0000] <zcorpan>
not sleeping enough is bad for the health, so i try not to. but sometimes i do anyway if i get stuck reading about interesting things, e.g. health related stuff (ironically)

[22:50:20.0000] <MikeSmith>
just I still see you on sometimes at like 8am Japan time

[22:50:27.0000] <MikeSmith>
hah

[22:50:51.0000] <MikeSmith>
yeah from what I understand you're really supposed to get 8hours of sleep

[22:51:08.0000] <MikeSmith>
not you personally

[22:51:32.0000] <MikeSmith>
*we're really supposed to

[22:52:32.0000] <MikeSmith>
anyway, https://twitter.com/snystrom/status/436387977259139072 and http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired

[22:52:53.0000] <MikeSmith>
WhatsApp apparently has only 32 engineers

[22:53:17.0000] <Hixie>
that aquisition boggles my mind

[22:54:14.0000] <MikeSmith>
buying the users I guess

[22:54:40.0000] <MikeSmith>
since it's pretty much commodity technology

[22:54:57.0000] <Hixie>
$35 a user is pretty high.

[22:56:01.0000] <Hixie>
i wonder how many of their 450 million users have crossed the 1-year mark when they have to pay

[22:56:31.0000] <Hixie>
anyhoo, i should head to bed. nn.

[22:56:39.0000] <MikeSmith>
night

[01:51:46.0000] <annevk-cloud>
https://twitter.com/edds/status/436395256192704512 makes the buy look reasonable…

[02:01:02.0000] <MikeSmith>
annevk-cloud: canna read that

[02:01:09.0000] <MikeSmith>
tweets protected

[02:14:00.0000] <annevk-cloud>
Oh sorry, it compares money per user with other acquisitions such as YouTube

[02:14:44.0000] <annevk-cloud>
All about the same

[02:19:03.0000] <MikeSmith>
ok

[02:19:39.0000] <MikeSmith>
annevk-cloud: so the money per use for whatsapp comes from users paying a subscription fee?

[02:19:46.0000] <MikeSmith>
*per user

[02:20:31.0000] <MikeSmith>
oh wait I guess you don't mean that

[02:20:56.0000] <MikeSmith>
you mean the cost of the acquisition compared to the number of users it brings

[02:22:21.0000] <MikeSmith>
so for YouTube is must have also been about $35 per user

[02:28:54.0000] <MikeSmith>
"Skype was acquired by eBay in 2005 for $2.6 billion, working out to roughly $240 per user. Google bought YouTube for $1.65 billion, or nearly $49 per user"

[02:29:03.0000] <MikeSmith>
http://www.investopedia.com/financial-edge/0412/did-facebook-overpay-for-instagram.aspx

[02:33:23.0000] <wilhelm>
It's still crazy. Imagine that kind of money being invested into industry, transportation or raw materials instead. You'd get a much quicker return.

[02:33:50.0000] <MikeSmith>
wow del.icio.us acquisition was $150 per user

[02:33:57.0000] <MikeSmith>
wilhelm: sure

[02:35:59.0000] <MikeSmith>
fwiw there's a longer list at https://docs.google.com/spreadsheet/pub?key=0Ag0BxADNLZqgdHdzYVR3a3BoM09jLUxNMC1lMDk2amc

[02:38:57.0000] <MikeSmith>
anyway in other news I set up https://github.com/whatwg/web-history/blob/master/README.md today

[02:39:03.0000] <MikeSmith>
contributions encouraged

[02:39:39.0000] <MikeSmith>
it's pretty thin from 2009 on

[02:40:32.0000] <MikeSmith>
planning to add more when I can but in the mean time maybe somebody else could add a few things

[03:30:27.0000] <bhanu>
hi, I want to know what is host, inclusive ancestor and host-including inclusive ancestor, can someone please explain, if possible with example?

[03:39:30.0000] <MikeSmith>
bhanu: that's in the DOM spec isn't it

[03:39:38.0000] <MikeSmith>
are you reading some other spec that uses it?

[03:40:27.0000] <MikeSmith>
http://robert.ocallahan.org/2014/02/3-mile-limit.html is pretty cool

[03:40:34.0000] <bhanu>
MikeSmith: I couldn't follow it clearly from the spec, so want to understand it

[03:41:28.0000] <MikeSmith>
bhanu: I guess you want to ask annevk-cloud when he's around

[03:41:42.0000] <MikeSmith>
or Ms2ger

[03:42:09.0000] <bhanu>
MikeSmith: I will check with them

[03:42:14.0000] <Ms2ger>
annevk :)

[03:42:32.0000] <Ms2ger>
Or dglazkov

[03:44:12.0000] <bhanu>
Ms2ger: will check with dglazkov since annevk seems to be offline

[03:45:45.0000] <bhanu>
dglazkov: hi, I couldn't clearly understand the terminologies i.e host, inclusive ancestor and host-including inclusive ancestor

[03:45:53.0000] <MikeSmith>
dglazkov won't be online for a while yet

[03:46:11.0000] <MikeSmith>
like 4 hours or so

[03:46:28.0000] <bhanu>
MikeSmith: oh ok, will check with him later, thanks

[03:55:01.0000] <zcorpan>
GPHemsley: http://mimesniff.spec.whatwg.org/#parse-a-mime-type compares bytes to code points

[04:21:08.0000] <MikeSmith>
zcorpan: r? https://critic.hoppipolla.co.uk/r/824 (a few simple validator tests for ins|del@datetime)

[04:23:17.0000] <zcorpan>
MikeSmith: i was now reminded of "del elements should not cross implied paragraph boundaries."

[04:23:38.0000] <zcorpan>
which seems like a "fun" thing to check for

[04:23:42.0000] <MikeSmith>
what that

[04:23:47.0000] <MikeSmith>
/me looks at spec

[04:27:19.0000] <MikeSmith>
hmm yeah

[04:27:45.0000] <MikeSmith>
we don't check for that yet

[04:27:53.0000] <MikeSmith>
I'll raise a bug for it

[04:39:54.0000] <MikeSmith>
zcorpan: http://bugzilla.validator.nu/show_bug.cgi?id=986

[05:25:09.0000] <GPHemsley>
hmm... http://syntax.whatwg.org/ was apparently once a working URL

[05:25:13.0000] <GPHemsley>
(it is no longer)

[05:30:50.0000] <GPHemsley>
zcorpan: Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24745

[05:31:36.0000] <zcorpan>
MikeSmith: you might reject asking for that review

[05:31:40.0000] <zcorpan>
er

[05:31:42.0000] <zcorpan>
regret

[05:59:20.0000] <MikeSmith>
zcorpan: any review is a good review

[06:00:00.0000] <MikeSmith>
I don't mind adding more stuff

[06:01:02.0000] <MikeSmith>
would be nice to get people contributing validator test cases but I don't hold out much hope for that happening, given how hard it is to just get regular tests

[06:03:20.0000] <zcorpan>
ok i think i'm done now

[06:08:33.0000] <MikeSmith>
whew

[06:09:22.0000] <MikeSmith>
heh it's less than it coulda been

[06:10:05.0000] <MikeSmith>
anyway, maybe we need to separate the tests out to .. somewhere else

[06:10:15.0000] <MikeSmith>
I mean other then in the dirs for ins/del

[06:10:48.0000] <MikeSmith>
hmm no, can't do that because datetime for <time> is less restrictive

[06:11:16.0000] <MikeSmith>
so need to keep them with the elements

[06:12:04.0000] <zcorpan>
but you could test ins and del in the same page

[06:15:12.0000] <zcorpan>
i think i'd write the tests in an easy-to-write source format and then generate the html

[06:16:01.0000] <zcorpan>
<test-name><space><input>

[06:17:36.0000] <zcorpan>
either two files to separate valid from invalid or a magic line that switches to invalid

[06:24:01.0000] <MikeSmith>
zcorpan: the limitation I have there is that the test harness is set up to catch only the first error that gets reported

[06:24:35.0000] <MikeSmith>
I guess I should have it catch all the errors

[06:24:38.0000] <MikeSmith>
instead

[06:25:33.0000] <MikeSmith>
that way I could put as many cases as I wanted into each file

[06:26:07.0000] <zcorpan>
MikeSmith: i meant that a script would generate the html files, one test case per file

[06:26:14.0000] <MikeSmith>
sure

[06:26:57.0000] <MikeSmith>
but I mean I have a testrunner in the validator code that automates the tests, and it expects only on error per *novalid.html file

[06:27:08.0000] <MikeSmith>
or rather it only sees the first error

[06:27:45.0000] <zcorpan>
yeah, i don't follow why that is a problem

[06:27:57.0000] <MikeSmith>
oh sorry

[06:28:41.0000] <MikeSmith>
yeah, I wasn't paying attention to what you actually wrote. Yeah, you're right, it'd be better to generate them from a script

[06:29:04.0000] <MikeSmith>
python I guess

[06:30:34.0000] <zcorpan>
i think using the test name in the filename is better than 001

[06:31:40.0000] <MikeSmith>
yeah I'm not fond of the numbering thing

[06:32:35.0000] <MikeSmith>
using the test names makes for longer filenames but it's not like we gain anything from short filenames

[06:33:01.0000] <MikeSmith>
except shorter URLs but the URLs are pretty long already anyway

[08:19:49.0000] <foolip>
zcorpan: https://critic.hoppipolla.co.uk/r/822

[08:23:57.0000] <zcorpan>
done

[08:24:44.0000] <TabAtkins>
setTimeout doesn't get clamped when the page is in the background, does it?

[08:27:48.0000] <jgraham>
No, although it is allowed to per spec

[08:32:00.0000] <TabAtkins>
Darn, and Chrome definitely does it.  Hrm.

[08:36:12.0000] <gsnedders>
http://imgur.com/ZWzDUdS

[08:36:23.0000] <jgraham>
TabAtkins: Maybe all browsers do

[08:36:37.0000] <jgraham>
It is allowed per spec, I just don't recall it being required

[08:38:28.0000] <jgraham>
Seems like Firefox does too at least

[08:43:09.0000] <smaug____>
<body></body> seems to create 2 newlines in body

[08:43:26.0000] <smaug____>
does something require them to be created with just one DOM mutation

[09:31:18.0000] <MikeSmith>
smaug____: just one newline after the <body> start tag, isn't it?

[09:32:40.0000] <smaug____>
MikeSmith: 2

[09:32:52.0000] <smaug____>
I haven't figured out what in the spec adds any

[09:33:28.0000] <smaug____>
but Gecko and Blink both seem to insert 2

[09:34:03.0000] <MikeSmith>
how do I observe that?

[09:34:20.0000] <Ms2ger>
Hmm?

[09:34:30.0000] <Ms2ger>
smaug____, what's the test case?

[09:39:07.0000] <smaug____>
Ms2ger: https://pastebin.mozilla.org/4348132

[09:39:24.0000] <Hixie>
the newline after the </body>

[09:39:28.0000] <Ms2ger>
Yeah, that

[09:39:29.0000] <Hixie>
and i bet you have a newline after the </html>

[09:40:08.0000] <Hixie>
(i tried to fix this, but it turns out there's compat needs or something)

[09:40:17.0000] <smaug____>
body contains two newlines

[09:40:25.0000] <smaug____>
and I'm trying to figure out why

[09:40:32.0000] <Hixie>
all text including whitespace after the </body> end up in the <body>

[09:40:39.0000] <Hixie>
you have two newlines after the </body>

[09:40:41.0000] <smaug____>
aha

[09:41:13.0000] <smaug____>
is it ok for implementation to first insert textnode ("\n"), and then append "\n" to it

[09:41:14.0000] <Hixie>
it's because "a</body>\nb" has to have a space between the a and the b, and they both have to be in the body

[09:41:38.0000] <Hixie>
per spec i think all characters are individually appended

[09:41:41.0000] <smaug____>
and/or is it ok to just create textnode ("\n\n") and append that to body

[09:41:56.0000] <Hixie>
and then mutation observers coallesce the edits

[09:41:57.0000] <Hixie>
or something

[09:41:58.0000] <smaug____>
that is my interpretation too, currently

[09:42:17.0000] <smaug____>
mutation observer doesn't coalesce character data changes

[09:42:29.0000] <Hixie>
probably should be allowed to, at least from the parser

[09:42:50.0000] <Hixie>
though nothing stops the parser from spinning the event loop between each character so it can't be a requirement at the end of the day

[09:42:59.0000] <Hixie>
(i mean, you don't control when the network gives you bytes)

[09:44:40.0000] <smaug____>
yup

[09:59:55.0000] <Hixie>
zcorpan and i have unfortunately non-overlapping hours

[10:35:34.0000] <zcorpan>
Hixie: here now (for a bit)

[10:39:52.0000] <Hixie>
zcorpan: now, what was it i wanted to ask...

[10:40:33.0000] <zcorpan>
Hixie: next time pretend i'm here when i'm not :-P

[10:41:23.0000] <Hixie>
zcorpan: :-)

[10:41:49.0000] <Hixie>
i get confused because you leave the channel and i forget you see the logs! :-)

[10:42:09.0000] <Hixie>
is it bad that my reaction to this thread about P2P web-based games is "use a server"

[10:54:47.0000] <jcgregorio>
Hixie: yeah, the design seems fragile, if that first player crashes or drops the connection the game is over?

[11:06:56.0000] <Hixie>
damnit, i just figured out why i needed zcorpan, and he's gone. :-)

[11:07:10.0000] <Hixie>
jcgregorio: presumably they support handing over to a new peer and doing a master election to pick a new server?

[11:08:02.0000] <Hixie>
zcorpan: so, we need an event that means "the user agent would like to scroll to this element", which can be canceled so that the author can implement scrolling when it's in a canvas

[11:08:16.0000] <Hixie>
zcorpan: that sounds like it belongs in CSSOM? maybe?

[11:08:40.0000] <Hixie>
zcorpan: i'll file a bug

[11:15:03.0000] <rafaelw>
Hixie: I have no idea what https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296#c52 means.

[11:15:29.0000] <jamesr__>
it sounds like he's saying that table sorting has to be special in some way in this scheme

[11:15:43.0000] <Hixie>
rafaelw: there are several kinds of microtasks, right?

[11:15:48.0000] <Hixie>
rafaelw: e.g. mutation observers

[11:16:08.0000] <Hixie>
rafaelw: but also eg. resorting tables, initialising web components, etc

[11:16:19.0000] <rafaelw>
I'd say there are different types of work done in microtasks (just like tasks)

[11:16:23.0000] <rafaelw>
yes

[11:16:28.0000] <Hixie>
rafaelw: ok. call these different types type1, type, type3, etc.

[11:16:42.0000] <rafaelw>
with you.

[11:17:00.0000] <jamesr__>
TabAtkins: sounds like this has been covered but rAF never runs in the background (required by spec) and setTimeout is throttled pretty aggressively in lots of browsers (allowed by spec but not required)

[11:17:18.0000] <Hixie>
rafaelw: if we have a batch of type1 microtasks and a batch of type2 microtasks that all got queued during some especially complicated script, should they all run in the order they were queued, or should they run first all type1, then all type2?

[11:17:24.0000] <jamesr__>
setTimeout has a "wait by some arbitrary additional UA-determined period of time" step

[11:17:40.0000] <jamesr__>
Hixie: FIFO

[11:17:53.0000] <rafaelw>
there's no such thing as a batch of type1 & batch of type2.

[11:18:06.0000] <rafaelw>
there's just a bunch of microtasks and they get run in FIFO order.

[11:18:20.0000] <Hixie>
rafaelw: ok so i agree with jamesr__ and i agree with what you just said, but that contradicts what you said in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296#c47

[11:18:36.0000] <Hixie>
assuming the "no" was a response to comment 46

[11:18:58.0000] <rafaelw>
brb.

[11:19:35.0000] <jamesr__>
i think you're trying to read too much into the internals of how mutation observers work

[11:20:01.0000] <Hixie>
i'm trying to write the internals of how mutation observers work

[11:20:06.0000] <Hixie>
:-)

[11:20:09.0000] <jamesr__>
no

[11:20:14.0000] <jamesr__>
you're trying to write the internals of how microtasks work

[11:20:47.0000] <Hixie>
well, right now, mutation observers provide me with one hook, which i call, and which runs all the mutation observers

[11:21:06.0000] <Hixie>
what i'm arguing is that we should change that so that mutation observers provide me with a hook that just runs a single mutation observer.

[11:21:35.0000] <jamesr__>
and i'm saying you are wrong

[11:21:43.0000] <jamesr__>
why do you think your proposal is better?

[11:21:51.0000] <Hixie>
i'm confused

[11:21:57.0000] <Hixie>
my proposal is what you just said we should do

[11:22:06.0000] <jamesr__>
this is what comment #25 part 4 is about

[11:22:10.0000] <jamesr__>
do you understand that bit?

[11:22:33.0000] <Hixie>
no, i do not understand comment 25 part 4 (see comment 48 where i said as much)

[11:22:39.0000] <jamesr__>
or comment #28

[11:23:09.0000] <Hixie>
comment 28 seems to contradict what you said above in this irc conversation

[11:23:14.0000] <jamesr__>
no?

[11:23:38.0000] <Hixie>
then i do not understand one of those two things (or both)

[11:24:15.0000] <jamesr__>
i think your source of confusion is you are attempting to conflate different units of work into one microtask concept

[11:24:29.0000] <jamesr__>
not everything is on its own a microtask

[11:24:34.0000] <Hixie>
i don't know what you mean by "one microtask concept"

[11:24:40.0000] <jamesr__>
i.e. not every mutation observer callback is a separate independent microtask

[11:24:44.0000] <Hixie>
ok

[11:24:50.0000] <Hixie>
that's what i was asking earlier when you said it was :-)

[11:24:56.0000] <jamesr__>
no, you asked the question badly

[11:25:02.0000] <Hixie>
i'm happy to concede that

[11:25:03.0000] <jamesr__>
you asked a question about a bunch of microtasks

[11:25:13.0000] <Hixie>
let me rephrase the question.

[11:25:23.0000] <jamesr__>
but if the things you're asking about are not microtasks then the answer will be different

[11:25:54.0000] <Hixie>
suppose you have a script which causes a bunch of mutations, then causes a table to need to be sorted, then causes a bunch more mutations.

[11:25:54.0000] <jamesr__>
i would say (1) all microtasks run in FIFO order and (2) some systems, like mutation observers, perform multiple actions within the execution of a single microtask

[11:26:18.0000] <Hixie>
what should happen when we get to running microtasks in that situation?

[11:26:18.0000] <jamesr__>
i'm not familiar with the table sorting mechanism. how does it work?

[11:26:38.0000] <rafaelw>
back.

[11:26:41.0000] <Hixie>
well, that's up in the air, but the proposal is that when a table needs sorting, a microtask is queued to sort it.

[11:26:47.0000] <jamesr__>
let's do the example with promises

[11:26:48.0000] <rafaelw>
hixie: mutation observers have to deliver in order of mutation observer creation time.

[11:26:49.0000] <jamesr__>
those are simple

[11:26:53.0000] <rafaelw>
that's already shipped. we can't break compat.

[11:27:01.0000] <Hixie>
rafaelw: i don't think anyone is disagreeing with that

[11:27:29.0000] <Hixie>
i have no idea how promises work, but ok

[11:27:53.0000] <jamesr__>
so let's say you do "d.appendChild(a); d.appendChild(b); promise.resolve(); d.appendChild(c);". the question is what bits enqueue microtasks and what order they fire in, correct?

[11:27:55.0000] <rafaelw>
what what do you think i was saying in comment 28?

[11:28:18.0000] <Hixie>
jamesr__: that is a question for which i would like the answer, yes

[11:28:39.0000] <jamesr__>
(assuming that promise.resolve() enqueues a microtask to run the promise stuff, whatever that is)

[11:28:44.0000] <rafaelw>
good. so in jame's example:

[11:28:53.0000] <jamesr__>
i think the answer falls out pretty naturally from 25/28 but let's step through it

[11:29:05.0000] <rafaelw>
the first appendChild schedules *the* mutation observer microtask to be scheduled.

[11:29:37.0000] <rafaelw>
all subsequent appendChilds discover that the mutation observer microtask is already scheduled (and don't schedule new microtasks)

[11:29:53.0000] <rafaelw>
the promise.resolve() schedules a microtask for *only itself*.

[11:29:56.0000] <Hixie>
so the answer is "c"'s observer fires before the promise?

[11:30:04.0000] <rafaelw>
yes.

[11:30:17.0000] <Hixie>
...why would we want that?

[11:30:24.0000] <jamesr__>
because that's the only way that makes any sense at all?

[11:30:33.0000] <Hixie>
why does it make sense?

[11:30:42.0000] <jamesr__>
keep in mind that the mutation *observer* callback set is not necessary "a, b, c"

[11:30:54.0000] <jamesr__>
sorry, that was confusing

[11:31:12.0000] <jamesr__>
the mapping from callbacks for mutations to their originating mutations is not the important part

[11:31:12.0000] <rafaelw>
i can't argue that's what we want.

[11:31:22.0000] <Hixie>
what happens if a's callback resolves a promise and then mutates dom node d?

[11:31:24.0000] <rafaelw>
i'm arguing that's the only choice i know of that works.

[11:31:39.0000] <jamesr__>
don't think about "a's callback"

[11:31:44.0000] <jamesr__>
think about "the mutation observer microtask"

[11:31:46.0000] <Hixie>
what happens if a callback resolves a promise and then mutates dom node d?

[11:31:47.0000] <rafaelw>
(doesn't break compat with mutation observers)

[11:32:05.0000] <jamesr__>
if during the mutation observer microtask one of the callbacks mutates the dom, that will enqueue another microtask for mutation observers

[11:32:20.0000] <rafaelw>
it's actually not even as simple as that.

[11:32:24.0000] <Hixie>
from the author perspective, and from my perspective as the guy who has to try to spec how this works with spinning the event loop, the atomic unit we care about is the callback, not the microtask, fwiw.

[11:32:28.0000] <rafaelw>
it's not helpful to ask general questions like that.

[11:32:34.0000] <jamesr__>
Hixie: that's not a useful perspective to have

[11:32:35.0000] <rafaelw>
you can only reason about concrete examples.

[11:32:51.0000] <Hixie>
that's as may be, but it's still my perspective :-)

[11:33:04.0000] <jamesr__>
and that's why you find this so confusing. think about it in terms of microtasks and it's actually very simple

[11:33:07.0000] <Ms2ger>
Oh, are we back to telling Hixie he's an idiot?

[11:33:27.0000] <jamesr__>
there are many ways to think about the problem. some of them make the problem simple, some make it very complicated

[11:33:33.0000] <jamesr__>
i'm saying if you pick the simple one then you'll be much happier

[11:33:37.0000] <Hixie>
jamesr__: ok, but if we think about this in terms of microtasks, please explain how we split the microtask when we sping the event loop when a callback calls showModalDialog().

[11:33:48.0000] <Hixie>
jamesr__: because without thinking of callbacks, i have no idea how to spec that.

[11:34:10.0000] <jamesr__>
my vote was that we just throw an exception when calling showModalDialog()

[11:34:17.0000] <jamesr__>
our usage numbers are pretty darn low for that to begin with

[11:34:18.0000] <rafaelw>
that's my vote as well.

[11:34:18.0000] <Hixie>
that was my vote too, but i got outvoted.

[11:34:29.0000] <rafaelw>
(actually not throw, just silently return)

[11:34:35.0000] <rafaelw>
abarth liked the idea as well.

[11:34:36.0000] <jamesr__>
still, it's not that bad

[11:34:43.0000] <jamesr__>
the mutation observer system has to keep track of which callbacks have run and not run

[11:34:44.0000] <rafaelw>
i was going to post a patch to blink for exactly this.

[11:34:46.0000] <Domenic_>
rafaelw: why does a's mutation observer, b's mutation observer, promise stuff, c's mutation observer not work?

[11:34:47.0000] <jamesr__>
that's not the microtask system's job

[11:35:01.0000] <Hixie>
rafaelw: unfortunately, my vote counts for squat, and you, jamesr__, and abarth's votes collectively only count as one.

[11:35:05.0000] <rafaelw>
dom: you're making a false assumption.

[11:35:20.0000] <Domenic_>
probably :). which one?

[11:35:26.0000] <rafaelw>
there are observers and there are nodes. it's a many-to-many relationship.

[11:35:33.0000] <rafaelw>
not a 1;1

[11:35:35.0000] <Domenic_>
right, ok.

[11:35:56.0000] <rafaelw>
ok. i'll post a patch which prevents showModalDialog during a microtaskCheckpoint today.

[11:35:58.0000] <Hixie>
jamesr__: when you spin the event loop, you have to put a task on the main event loop task queue. What does that task consist of? I was assuming it would consist of just finishing the callback.

[11:35:59.0000] <rafaelw>
is that helpful?

[11:36:02.0000] <Domenic_>
but let's pretend we wrote sample code like doSomeStuffToTriggerObserverA(); doSomeStuffToTriggerPromiseB(); doSomeStuffToTriggerObserverC()

[11:36:22.0000] <Domenic_>
it sounds like that would cause observerA, observerC, promiseB

[11:36:31.0000] <Domenic_>
becaues you only have a single microtask for all observers

[11:36:43.0000] <jamesr__>
Hixie: i think i've argued with you before that the way the spec handles spinning the event loop does not match what browsers actually do and is thus not all that helpful

[11:37:44.0000] <jamesr__>
the behavior i'd actually expect would be that the browser runs the showModalDialog code on top of the callstack of the mutation observer system, then returns, then the mutation observer system takes a look at the state it has after running the showModalDialog and decides what to do

[11:37:49.0000] <jamesr__>
i.e. the "split a task" thing never happens in reality

[11:37:59.0000] <jamesr__>
the pending work is sitting on the callstack

[11:38:13.0000] <Hixie>
jamesr__: so all mutation observers stop during the modal dialog, and then after it returns you get a huge deluge of them?

[11:38:19.0000] <Domenic_>
why would it not be observerA, promiseB, observerC?

[11:38:20.0000] <jamesr__>
that's not what i said

[11:38:22.0000] <jamesr__>
it's reentrant

[11:38:44.0000] <rafaelw>
dom: in order to reason about these examples you need; creation order of observers, which observers observe which nodes and what order mutations took place/promises resolve.

[11:38:47.0000] <Hixie>
jamesr__: so the next time we do microtasks, it continues from where it left off?

[11:38:53.0000] <rafaelw>
jsbin is probably the only way to have the conversation.

[11:39:37.0000] <Domenic_>
rafaelw: well, ok. but i'll try just asking directly then. why would you batch together all observers, instead of interleaving promises as appropriate?

[11:39:54.0000] <Domenic_>
above you seemed to imply that was the only thing that worked, but i don't understand why that would be the case

[11:40:01.0000] <jamesr__>
i think the "as appropriate" bit depends on the actual example

[11:40:04.0000] <rafaelw>
Hixie; FWIW, this is my frustration as well. It's too hard for me to reason about this when the spec language is so different from what the implementation does.

[11:40:25.0000] <jamesr__>
Hixie: that depends on what's changed while the modal dialog is up, i would think

[11:41:07.0000] <rafaelw>
dom: i can only answer that for you by posing a challenge to you: implement microtask delivery as a FIFO queue, and retain the invariant that mutation observers deliver in creation-time order.

[11:41:45.0000] <Hixie>
jamesr__: well presumably the next time you get a microtask checkpoint is very soon after the dialog went up. at most one regular task can run between the time of the method call and the next time we run microtasks.

[11:41:54.0000] <Hixie>
jamesr__: so assume that task does nothing, for the sake of argument

[11:42:09.0000] <Domenic_>
rafaelw: makes sense. the distinction between creation-time order and mutation-order is crucial. i imagine after thinking really hard about this i'll come to the same conclusion as you.

[11:42:31.0000] <Hixie>
rafaelw: i don't understand how other callbacks being run can in any way affect the order of mutation observer delivery.

[11:42:33.0000] <rafaelw>
i've got a cake with your name on it if you figure out something better.

[11:42:57.0000] <rafaelw>
;-)

[11:43:13.0000] <Hixie>
rafaelw: other than potentially causing more mutations (which mo callbacks can as well), how can they have any impact at all?

[11:43:35.0000] <rafaelw>
hixie: what's the current topic?

[11:43:47.0000] <Hixie>
rafaelw: how other callbacks being run can in any way affect the order of mutation observer delivery.

[11:43:58.0000] <rafaelw>
and how is that relevant?

[11:44:20.0000] <Hixie>
isn't that what we've been talking about for the past 40 minutes?

[11:45:03.0000] <Hixie>
you want to batch the mutation observer callbacks rather than run them one at a time interleaved with other microtask callbacks, right?

[11:45:40.0000] <rafaelw>
i think we need to do this differently.

[11:46:05.0000] <Hixie>
every time i ask a question you try to change the approach, it's making it very hard for me to improve my understanding.

[11:46:07.0000] <rafaelw>
how about you propose an approach and i'll try to provide a case which doesn't retain creation-order delivery for mutation observers.

[11:46:13.0000] <Hixie>
ok

[11:46:16.0000] <Hixie>
my approach is this:

[11:46:35.0000] <Hixie>
when it's time to run microtasks, run these steps:

[11:46:56.0000] <Hixie>
1. if one or more mutation observers need to run, run one.

[11:47:08.0000] <Hixie>
2. run another microtask, in the order they were queued.

[11:47:15.0000] <Hixie>
3. goto 1 unless there's no more work to be done.

[11:47:44.0000] <rafaelw>
ok. what you've proposed is not a fifo queue.

[11:47:50.0000] <rafaelw>
it's a priority queue.

[11:48:01.0000] <Hixie>
(this is not a final proposal, i'm just trying to work out if it would work, so that i can figure out the problem you're describing)

[11:48:20.0000] <rafaelw>
yes. it's possible to retain creation-time ordering with this approach.

[11:48:24.0000] <Hixie>
ok

[11:48:29.0000] <Hixie>
so, new approach:

[11:49:30.0000] <Hixie>
whenever a mutation occurs, queue a microtask for each observer that it could fire, ignoring all previously queued microtasks.

[11:50:06.0000] <Hixie>
when a mutation observer microtask comes up, run the callback that applies, taking into account all subsequently queued microtasks, and remove any subsequently queued microtasks that no longer apply because we handled them here.

[11:50:18.0000] <Hixie>
microtask handling consists of:

[11:50:24.0000] <Hixie>
1. run the oldest queued microtask.

[11:50:31.0000] <Hixie>
2. goto 1 unless there's no more queued work.

[11:52:05.0000] <rafaelw>
thinking

[11:52:23.0000] <jamesr__>
IOW, have microtask deliver be the same but redefine the mutation observer microtask's work to be something else. that seems basically equivalent to #25 assuming that the "taking into account all subsequently" also takes care of the reordering that would happen to satisfy the mutation observer constraints

[11:52:55.0000] <Hixie>
can you elaborate on the reordering thing?

[11:52:57.0000] <jamesr__>
trivial mapping back to the comment 25 proposal: the "taking into account" step includes generating all the other callbacks needed to preserver order and firing them

[11:53:08.0000] <jamesr__>
and cancelling all other mutation-related microtasks

[11:53:16.0000] <Hixie>
my aim here is for each microtask to only ever fire one callback

[11:55:00.0000] <rafaelw>
can you explain: "taking into account all subsequently queued microtasks, and remove any subsequently queued microtasks that no longer apply because we handled them here"

[11:57:28.0000] <rafaelw>
hixie: can i re-state this approach as follows:

[11:57:51.0000] <rafaelw>
-every time an observed node is mutated, schedule a new mutation observer microtask

[11:58:02.0000] <rafaelw>
-all mutation observer callbacks do the same thing:

[11:58:27.0000] <rafaelw>
-find the observer with the oldest creation time and deliver all pending records to it

[11:58:48.0000] <Hixie>
does "deliver all pending records" mean more than one callback?

[11:59:16.0000] <aklein>
Hixie: no, that's a single callback (the callback takes an array of MutationRecords)

[11:59:17.0000] <rafaelw>
it doesn't. it means one callback.

[11:59:21.0000] <Hixie>
k

[11:59:52.0000] <Hixie>
wouldn't you need to schedule one of these per observer per mutation?

[11:59:58.0000] <Hixie>
per relevant observer, at least

[12:00:07.0000] <rafaelw>
yes.

[12:00:11.0000] <rafaelw>
sorry. you are right.

[12:00:27.0000] <jamesr__>
fwiw the Object.observe deliverChangeRecords() algorithm invokes a callback multiple times (if i've found the right proposal)

[12:00:33.0000] <rafaelw>
you'd need to schedule a microtask for each observer which had a mutation record added to it's pending queue.

[12:00:40.0000] <jamesr__>
/me is off to lunch, back soon

[12:00:50.0000] <rafaelw>
jamesr__: correct.

[12:00:53.0000] <Hixie>
right

[12:01:16.0000] <Hixie>
as far as dom mutation observers go, i think what you describe is what i meant, yes

[12:01:18.0000] <rafaelw>
hixie: have i correctly restated your proposal?

[12:01:59.0000] <rafaelw>
ok, so this actually does break compat with the current ordering behavior (though it does retain the creation-time invariant).

[12:02:10.0000] <Hixie>
oh ok, good. how so?

[12:02:24.0000] <rafaelw>
the way ordering is spec works like this:

[12:02:30.0000] <rafaelw>
when mutation observers deliver

[12:02:42.0000] <rafaelw>
take the set of observers whcih pending change records

[12:02:51.0000] <rafaelw>
order that set by creation time

[12:03:00.0000] <rafaelw>
deliver to that set in creation order

[12:03:16.0000] <rafaelw>
when you are done, if there are new observers pending delivery, start over.

[12:03:39.0000] <rafaelw>
so basically, you've created a *strict* priority queue for mutation observers, but unfortunately, that's not what is implemented.

[12:04:04.0000] <rafaelw>
(sorry. i have to go to lunch and i'm out tomorrow. we can pick this up next week).

[12:04:30.0000] <Hixie>
what you describe doesn't quite seem to match what i'm reading on dom.spec.whatwg.org

[12:04:31.0000] <rafaelw>
it seems like you're trying really hard to have 1-1 microtask-callback.

[12:04:34.0000] <rafaelw>
this is going to be hard.

[12:04:44.0000] <rafaelw>
custom element callbacks present a different set of ordering requirements

[12:04:52.0000] <Hixie>
the alternative is harder, if we have showModalDialog() :-)

[12:05:09.0000] <Hixie>
if you could convince the other vendors to kill showModalDialog(), this would make our lives way easier

[12:05:21.0000] <Hixie>
even just kill showModalDialog() inside microtasks

[12:05:37.0000] <Hixie>
it's the only remaining spin-the-event-loop callsite that can be invoked in a microtask

[12:05:51.0000] <Hixie>
anyway, we'll carry on next week, sure

[12:06:44.0000] <aklein>
Hixie: re: the dom spec, which part of the algorithm at http://dom.spec.whatwg.org/#concept-mo-invoke doesn't match Rafael's explanation?

[12:07:15.0000] <Hixie>
MikeSmith: if we go with that proposal i suggested, then that IBM.* issue would be much simpler -- they would just click "add as proprietary value" each time they validated a document with a new value, and it'd never come up again

[12:07:18.0000] <aklein>
we worked pretty closely with annevk to get it to match up with the implementation (after several go-rounds that read differently than the implementation)

[12:08:00.0000] <Hixie>
aklein: if i understand rafaelw's description, you first make a list of observers and their records, and then call their callbacks; the spec, though, just makes a list of observers, then for each one gets the records and calls the callback.

[12:08:28.0000] <Hixie>
aklein: so if you have observers A and B, and they each have a record, and A's callback adds a record to B, the next thing that happens is B's callback with two records

[12:08:39.0000] <Hixie>
aklein: as opposed to the next thing being B having two separate callbacks

[12:09:52.0000] <aklein>
Hixie: I think you just misunderstood rafaelw (or he misspoke). in the case you've outlined, A is first called with a single record, and then B is called (once) with two records

[12:10:05.0000] <aklein>
would you agree that's what the spec says? that's what our implementation does

[12:10:19.0000] <Hixie>
i agree that the spec calls B with two records at once in that case

[12:10:21.0000] <MikeSmith>
Hixie: yeah except that everybody who used the validator would click that button every time they checked a page that had unregistered meta@name values and eventually we'd have a gazillion values registereed and that state would be pretty much just like making any arbitary string valid

[12:10:25.0000] <Hixie>
aklein: but so how is what i proposed earlier different?

[12:10:47.0000] <aklein>
Hixie: for this case, it's the same

[12:10:53.0000] <Hixie>
MikeSmith: except that the validator would say "valid! (uses proprietary values)" instead of just "valid!"

[12:10:59.0000] <aklein>
but imagine that A causes a mutation that adds another record to A's queue

[12:11:00.0000] <Hixie>
MikeSmith: and typos would get caught

[12:11:25.0000] <aklein>
Hixie: in that case, you and the spec differ. the spec says to call A with one record, then B with one record, then A again

[12:11:37.0000] <MikeSmith>
Hixie: typos would get registered too

[12:11:46.0000] <aklein>
whereas your ordering would be A (one record), A (one record), B (one record)

[12:11:48.0000] <Hixie>
MikeSmith: why?

[12:12:17.0000] <Hixie>
aklein: ah, yeah, i guess that's a difference between my original proposal and rafaelw's restatement

[12:12:37.0000] <Hixie>
aklein: i meant each microtask to be designated a specific observer whose's queue should be flushed.

[12:12:49.0000] <MikeSmith>
because somebody would click "register" when their document had a typoed value that generated an error slash "do you want to register me?" message

[12:13:07.0000] <aklein>
Hixie: that's why rafael asked what you meant by "taking into account other queued microtasks"

[12:13:09.0000] <Hixie>
aklein: but i guess that would mean my proposal misses the case of A having one record, B having none, and A's callback adding to A and B

[12:13:24.0000] <Hixie>
aklein: since per spec today you'd want A, B, A, but i'd give A, A, B

[12:13:56.0000] <Hixie>
aklein: and that can't be fixed easily since B might not exist when the first record is queued

[12:13:59.0000] <Hixie>
interesting

[12:14:22.0000] <aklein>
Hixie: oh, I think I may begin to understand what you were proposing

[12:14:46.0000] <Hixie>
MikeSmith: well that's why in my proposal we have "did you mean /author/?" and so on. at the end of the day, if people are validating but don't care about the errors, the validator is pointless.

[12:15:00.0000] <Hixie>
MikeSmith: we could just provide a trivial implementation that just said "it's valid! pat pat!"

[12:15:14.0000] <aklein>
Hixie: were you saying that you enqueue tasks for all possible observers whenever a mutation occurs? even ones for which no records were enqueued by that mutation?

[12:15:15.0000] <Hixie>
MikeSmith: i have to believe that validator users at least want to know about errors

[12:15:42.0000] <Hixie>
aklein: i wasn't, but then i was, but then i realised that wouldn't work because mutation observers might be created later

[12:16:22.0000] <Hixie>
MikeSmith: (note that in my proposal there was also the back-end review process where typos would get flagged as permanently not ok)

[12:16:30.0000] <Hixie>
MikeSmith: (so at least eventually they'd get flagged)

[12:16:37.0000] <Hixie>
MikeSmith: (with a useful message)

[12:18:13.0000] <MikeSmith>
yeah I understand all that. I have a half-finished draft of a reply to you on that thread that I will try to finish soon. In the mean time it would still be good to try to get hsivonen to chime in.

[12:18:22.0000] <MikeSmith>
for now I gotta get some sleep

[12:18:25.0000] <Hixie>
yeah i wish i knew what henri wanted here

[12:18:35.0000] <MikeSmith>
yeah

[12:18:46.0000] <Hixie>
aklein: i guess we really do want two kinds of microtasks, those that are trivial with at most one callback, which can be handled easily by the current prose, and then the ones for mutation observers which would need to do special work for each of their callbacks

[12:19:06.0000] <Hixie>
aklein: assuming we can't just break compat and go to just a queued model, anyway

[12:21:49.0000] <aklein>
Hixie: note that custom elements also have special ordering constraints, mutation observers aren't the only one

[12:22:03.0000] <aklein>
Hixie: it's definitely unclear to me how much the web depends on the ordering here

[12:22:55.0000] <aklein>
but without the specified creation-time ordering, we worried that implementations might end up with different orderings due to DOM implementation details

[12:23:52.0000] <aklein>
(e.g., the ordering might be dependent on hash table implementations)

[12:24:38.0000] <Hixie>
yeah

[13:00:14.0000] <jamesr__>
btw, it looks like showModalDialog use is low enough were we might be able to just straight kill it

[13:05:46.0000] <Hixie>
jamesr__: i certainly would support that!

[13:06:01.0000] <Hixie>
jamesr__: historically all attempts at convincing other vendors of this have been unsuccessful :-(

[14:00:42.0000] <Hixie>
k

[14:11:02.0000] <Hixie>
i wish there was a way in bugzilla to select bugs for which i was not the last person who commented

[14:24:25.0000] <Hixie>
anyone got IE around who can tell me what the two frames in this test say for HTTP_REFERER ?

[14:24:28.0000] <Hixie>
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2830

[14:25:00.0000] <Hixie>
also, does safari just not send referers for iframes or something?

[14:26:23.0000] <Hixie>
or actually, try http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2831

[14:26:30.0000] <Hixie>
it has a third frame at the bottom

[14:26:42.0000] <Hixie>
(very bottom of the dom viewer)

[14:27:46.0000] <Hixie>
if you have results for that test, the bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24613

[14:52:55.0000] <Domenic_>
What other things do custom elements not explain? Form submission is an easy and obvious one, but what else can native elements do that custom elements can't?

[14:54:07.0000] <Hixie>
<input> in general is pretty hard to explain

[14:54:21.0000] <Hixie>
e.g. the way it impacts <form>.elements

[14:54:27.0000] <Hixie>
the way you can change hte type="" attribute

[14:54:35.0000] <Hixie>
the way type=file lets you access the file system

[14:54:45.0000] <Hixie>
the way it interacts with <label>

[15:01:43.0000] <Domenic_>
yeah jonas was saying how <form>.elements is screwy

[15:02:06.0000] <Domenic_>
what is tricky about the interaction with label?

[15:15:48.0000] <Hixie>
Domenic_: nothing particularly tricky, but <label> doesn't know about custom elements, so it won't do anything useful with them

[15:16:37.0000] <Hixie>
Domenic_: note that i think form submission is kind of a red herring. With things like web sockets, it's not as important to actually submit anything. It's more interesting to be in form.elements and the like.

[15:16:37.0000] <Domenic_>
ah right

[15:17:47.0000] <Hixie>
hober: it's cute how we're finally discussing these things that i had specced in xbl2 and web control 2.0 back in 2004 :-P

[15:22:06.0000] <hober>
Hixie: right?

[15:22:56.0000] <Hixie>
i wish it had gotten more traction back then

[15:23:06.0000] <Hixie>
oh well

[15:23:11.0000] <Hixie>
i didn't push it much either


2014-02-21
[16:53:22.0000] <erlehmann>
hey what

[16:53:36.0000] <erlehmann>
what is the problem with <source @media> ?

[16:53:37.0000] <erlehmann>
:(

[16:54:03.0000] <erlehmann>
why did you take it away? :(

[17:00:56.0000] <erlehmann>
this is not funny https://www.w3.org/Bugs/Public/show_bug.cgi?id=19619#c31

[17:01:01.0000] <erlehmann>
i use that attribute myself

[17:01:50.0000] <erlehmann>
i used it here! http://news.dieweltistgarnichtso.net/talks/music-c-compiler.html

[17:02:04.0000] <erlehmann>
[[zz]] what is your name, when you are sleeping? [[zzz]]zzz ?

[17:03:49.0000] <[[zz]]>
erlehmann, [[zzz]]   :p

[18:17:25.0000] <erlehmann>
http://daten.dieweltistgarnichtso.net/src/css-pie-chart-form.html

[18:26:37.0000] <jamesr__>
sent an intent-to-remove for window.showModalDialog() in blink

[18:27:12.0000] <jamesr__>
unless our instrumentation is broken it shows up on < 0.006% of page visits

[18:34:29.0000] <erlehmann>
jamesr__ can you tell me why chrome is the only browser to not display the actual feed when navigated to one?

[18:34:41.0000] <erlehmann>
safari, firefox, even IE display the feed.

[18:36:36.0000] <jamesr__>
not sure i understand

[18:36:42.0000] <jamesr__>
you're asking why chrome does not have a built-in RSS reader?

[18:37:46.0000] <jamesr__>
or maybe we're talking about a different type of feed

[18:42:14.0000] <erlehmann>
jamesr__ more like why does it not show the xml of the feed, possibly styled?

[18:42:39.0000] <erlehmann>
jamesr__ there must be some reason for this because every other browser – on desktop at least – is able to.

[18:43:55.0000] <erlehmann>
jamesr__ also why did the chrome team state that it remove h.264 support and then did not remove it? do you know about that?

[18:44:22.0000] <erlehmann>
i never found a further post

[18:44:38.0000] <erlehmann>
(just asking that because you seem to know more about chrome than me)

[18:44:59.0000] <erlehmann>
jamesr__ is there an instrumentation thing for link rel=alternate type=application/atom+xml ?

[18:46:06.0000] <erlehmann>
jamesr__ can i see the chrome instrumentation data somewhere?

[22:13:39.0000] <bhanu>
dglazkov: hi, I am not quite clear of the terminologies host, inclusive ancestor, host-including inclusive ancestor, could you please help me understand?

[22:21:00.0000] <zcorpan>
erlermann: http://news.dieweltistgarnichtso.net/talks/music-c-compiler.html - this doesn't work. the <source> with the media attribute will never be loaded. this is why it was removed.

[22:53:58.0000] <zcorpan>
miketaylr: can you grep for 'showModalDialog' pls?

[00:14:51.0000] <Hixie>
bhanu: see dom.spec.whatwg.org

[00:40:38.0000] <bhanu>
Hixie: I couldn't quite understand it from the spec, I would like to understand it, if possible with example

[00:57:06.0000] <zcorpan>
bhanu: i think something like <template id=t><span></span></template> <script> t.shadowRoot.firstChild.appendChild(t) </script>

[03:42:48.0000] <annevk-cloud>
There is a note explaining it…

[03:43:09.0000] <annevk-cloud>
File a bug if it needs to be clearer I suppose

[03:54:56.0000] <roc>
public-media-capture is making me crazy

[03:58:30.0000] <Ms2ger>
Which one is that? WebRTC?

[03:58:37.0000] <jgraham>
roc: Surely not? All W3C lists, especially those with -media- in the name, are places of Zen-like peace and serenity.

[03:58:54.0000] <roc>
getUserMedia, MediaRecorder

[03:59:17.0000] <Ms2ger>
Ah

[03:59:22.0000] <Ms2ger>
/me reads WebRTC

[05:28:08.0000] <Ms2ger>
  <p><b>400.</b> <ins>That�s an error.</ins>

[05:28:09.0000] <Ms2ger>
  <p>Your client has issued a malformed or illegal request.  <ins>That�s all we know.</ins>

[05:28:13.0000] <Ms2ger>
ins, eh, Google

[05:34:29.0000] <zcorpan>
it's more semantic than <u>

[05:34:53.0000] <zcorpan>
<ins>That's all I know.</ins>

[05:35:42.0000] <Ms2ger>
/me glares at zcorpan 

[05:36:08.0000] <zcorpan>
not you also :-(

[05:37:53.0000] <Ms2ger>
/me slowly turns into gsnedders 

[05:37:54.0000] <jgraham>
/me buys zcorpan a mirror so he can glare at himself

[05:42:26.0000] <Ms2ger>
O hey, addHitRegion in Gecko

[06:24:36.0000] <GPHemsley>
Google loves <ins>

[06:24:43.0000] <GPHemsley>
they use it everywhere

[09:51:51.0000] <SamB>
/me wonders how to cite http://www.w3.org/TR/html4/interact/forms.html ...

[09:52:34.0000] <gsnedders>
Cite HTML4 as a technical report or standard (depending on your citation style), and then reference the Forms section.

[10:53:50.0000] <Hixie>
taijeen: i think something's broken with your internet connection.

[11:06:52.0000] <Hixie>
whatever happened to the thing about how <br> shouldn't be styleable?

[11:09:47.0000] <Hixie>
oh there it is

[11:15:54.0000] <jcgregorio>
W3C BNF question: are BNF rules 'first match wins'?

[11:16:28.0000] <Hixie>
probably depends on the spec that uses it

[11:16:30.0000] <Hixie>
which spec?

[11:16:33.0000] <jcgregorio>
in particular: http://www.w3.org/TR/SVG/paths.html#PathDataBNF

[11:17:00.0000] <Hixie>
do you have a case that's otherwise ambiguous?

[11:17:06.0000] <jcgregorio>
the rule for nonnegative-number looks like it would never match a float

[11:17:21.0000] <jcgregorio>
because it would pick out the leading int part first

[11:17:28.0000] <Hixie>
i would imagine it's "if you can match then it's valid", that's all. i mean, BNF can't describe parsing behaviour, so it doesn't really matter which matches first.

[11:17:44.0000] <Hixie>
you just try them each in turn.

[11:18:26.0000] <jcgregorio>
yeah, building a parser for that and I had to rearrange that rufloating-point-constant before integer-constant to get it to workle to put

[11:18:41.0000] <jcgregorio>
wasn't sure if it was a bug in the parser generator, or the BNF

[11:18:43.0000] <Hixie>
well the bnf isn't describing how to parse

[11:18:51.0000] <Hixie>
i assume they have another spec somewhere that describes how you parse

[11:19:22.0000] <Hixie>
oh, maybe not. weird.

[11:19:43.0000] <Hixie>
wow this really is their parsing spec?

[11:19:53.0000] <jcgregorio>
yeah, appears to be it

[11:20:07.0000] <Hixie>
that shows an unfortunate lack of understanding about what BNF does

[11:20:21.0000] <Hixie>
there's a paragraph after the BNF that implies that this is indeed how you parse it, though

[11:20:32.0000] <jcgregorio>
I also had to flip the order for 'number'

[11:20:49.0000] <jamesr__>
#lolsvg

[11:21:22.0000] <Hixie>
this can't possibly be the parsing spec

[11:21:33.0000] <Hixie>
it doesn't say how to interpret the rules even if they do match

[11:22:15.0000] <jamesr__>
Hixie: but it says "W3C Recommendation" right on the side

[11:22:27.0000] <Hixie>
now you're just trolling me :-P

[11:22:49.0000] <Hixie>
jcgregorio: i'd try to see if there's a more recent svg spec that defines this better

[11:23:15.0000] <jamesr__>
svg2 is identical

[11:23:32.0000] <jamesr__>
as of feb 14th 2014 WD

[11:23:37.0000] <jamesr__>
sorry, feb 11

[11:23:47.0000] <Hixie>
ok then.... jcgregorio: ...i'd file a bug saying "the spec doesn't actually define how to parse this".

[11:25:26.0000] <jamesr__>
Hixie: i'm mostly amused at your surprise at how bad this is

[11:26:38.0000] <Hixie>
i don't understand how we can still be writing bad specs after all this time

[11:26:56.0000] <Hixie>
i mean, CSS 2.1 started what, 15 years ago?

[11:27:10.0000] <jcgregorio>
Hixie: will do... actually, where do I file such a bug?

[11:27:27.0000] <Hixie>
jcgregorio: no idea. there should be a link at the top of the spec if there isn't an inline one making it trivial.

[11:27:50.0000] <Hixie>
jcgregorio: (most modern specs have scripts that make filing bugs trivial... try selecting text and see if a link to file a bug appears in the bottom left)

[11:40:34.0000] <jcgregorio>
"modern specs" you keep using that word...

[11:40:52.0000] <jcgregorio>
Hixie: no such luck with the highlighting, did find their bug tracker, filed as:

[11:40:53.0000] <jcgregorio>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24769

[11:41:14.0000] <jcgregorio>
not sure if you want to add anything to that

[11:41:24.0000] <SimonSapin>
jcgregorio: I don’t know about SVG, but the tokenizer in CSS 2.1 is "longest match wins"

[11:42:58.0000] <jcgregorio>
SimonSapin:  yeah, and ABNF is longest match wins but only for rules grouped in (), but there's no guidance in the SVG spec that I could find

[11:46:34.0000] <SteveF>
hixie: re your recent additions to the aria mapping table http://lists.w3.org/Archives/Public/public-html/2014Feb/thread.html#msg91 thread may be of interest if you want the whatwg spec to reflect implementation reality

[11:49:37.0000] <Hixie>
SteveF: yeah, i agree with alex's comment. unfortunately the ARIA spec doesn't, so... I'm just trying to match the ARIA spec.

[11:50:06.0000] <SteveF>
Hixie: your call

[11:50:50.0000] <Hixie>
SteveF: btw, do you think it makes sense to take the ARIA mappings for HTML entirely out of the HTML/HTML5 specs? I know you're maintaining that other doc, which is more detailed already... seems like it'd be better to just have this in one place.

[11:57:57.0000] <SteveF>
hixie: maybe there are plans  to create an acc implementation guide encompassing aria/html/svg see http://lists.w3.org/Archives/Public/public-pfwg/2014Jan/0018.html for details

[12:04:35.0000] <Hixie>
SteveF: what's an "implementation guide"?

[12:08:23.0000] <SteveF>
Hixie: its the term used to refer to the spec that tells implementers how to implement stuff, for example WAI-ARIA 1.0 User Agent Implementation Guide http://www.w3.org/TR/wai-aria-implementation/ (apologies for the tr url)

[12:08:35.0000] <Hixie>
as opposed to specs that... do what?

[12:08:45.0000] <Hixie>
not tell implementors how to implement stuff?

[12:09:45.0000] <SteveF>
hixie: so yeah its another term for specification I didn't decide the name

[12:11:21.0000] <Hixie>
yeah i don't really understand what the WAI-ARIA 1.0 User Agent Implementation Guide is about

[12:11:52.0000] <Hixie>
it vaguely looks like a spec, but it seems to not invent anything new, it's like it's trying to patch another spec or something

[12:12:01.0000] <Hixie>
its normative status doesn't make much sense to me

[12:12:37.0000] <Hixie>
what i was suggesting wasn't something like that. i meant more something like fetch.spec.whatwg.org, a spec that defines its own thing, owns it, and is referenced by other specs normatively.

[12:13:03.0000] <Hixie>
so, in this case, it would just be a spec that defines the default mapping of HTML elements to ARIA.

[12:13:41.0000] <SteveF>
who is the intended audience

[12:13:59.0000] <Hixie>
browser vendors

[12:15:35.0000] <SteveF>
suggest you ask the people who work on implementing acc in browsers, they are the ones who see use the aria implementation guide (for example)

[12:16:19.0000] <Hixie>
the implementation guide seems like a distraction to this discussion

[12:16:27.0000] <Hixie>
right now we have the ARIA mappings in the HTML spec, right?

[12:16:34.0000] <SteveF>
yes

[12:16:45.0000] <Hixie>
i'm just saying, what do you think of maintaining a spec outside of HTML that has those, instead of putting it in HTML.

[12:17:42.0000] <SteveF>
it sounds reasonable

[12:18:19.0000] <Hixie>
k

[12:18:50.0000] <Hixie>
well if you decide to move the aria default mappings for html into its own spec, let me know. i'd be happy to move them out on the WHATWG side too and point to that spec.

[12:19:14.0000] <SteveF>
OK will think on it

[12:20:54.0000] <Hixie>
k

[13:36:42.0000] <Hixie>
anyone with IE around?

[13:36:48.0000] <Hixie>
if so, please paste the log from http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2837

[13:42:38.0000] <miketaylr>
Hixie: https://gist.github.com/anonymous/9144121

[13:42:47.0000] <miketaylr>
(from IE11)

[14:02:28.0000] <Hixie>
miketaylr: thanks!

[14:48:10.0000] <Hixie>
miketaylr: you mind testing http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2831 on IE? i'm trying to find out if either iframe in the "rendered view", or the iframe right at the bottom under the log, mentions HTTP_REFERER

[14:49:51.0000] <miketaylr>
Hixie: hang on, firing up VM

[14:51:00.0000] <miketaylr>
Hixie: the iframe on the right in the rendered view does, as well as the one below the log

[14:51:16.0000] <Hixie>
thanks

[14:54:45.0000] <heycam>
jcgregorio, it should be match or not, as Hixie guessed

[14:55:13.0000] <heycam>
jcgregorio, if the attribute value doesn't entirely match the grammar, then it's invalid and no path will be rendered

[15:00:51.0000] <Hixie>
heycam: the problem is right now there's nothing that says how to parse it.

[15:02:44.0000] <heycam>
Hixie, I don't think there needs to be a description of how to parse, if "parses unambiguously or not" is sufficient. but we don't say explicitly that the d="" attribute must match the grammar and what happens when it doesn't, so that needs to be added at least.

[15:02:58.0000] <Hixie>
bloody hell, feedback from microsoft on the security bug

[15:03:03.0000] <Hixie>
i must be dreaming

[15:03:18.0000] <gsnedders>
/me slaps Hixie hard to wake him up

[15:03:37.0000] <Hixie>
heycam: nothing i see says that "10" means ten vs sixteen, for example.

[15:03:51.0000] <Hixie>
heycam: or that the first number is the x coordinate and the second the y coordinate

[15:04:16.0000] <Hixie>
heycam: or indeed that "3,2" is not the same, semantically, as "32" or, indeed, "56" or "turtles"

[15:04:44.0000] <Hixie>
abarth: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=24684

[15:04:46.0000] <heycam>
Hixie, that's true, I could add a sentence saying that particular grammar symbols correspond to the commands described in the previous secitons

[15:05:03.0000] <Hixie>
heycam: well it needs _something_.

[15:05:11.0000] <abarth>
not that bug :(

[15:05:22.0000] <Hixie>
lol

[15:05:34.0000] <Hixie>
heycam: i dunno that i'd do anything that involves mapping BNF to anything, but even that would be better than nothing

[15:05:40.0000] <heycam>
Hixie, yeah ok. doesn't need a description of parsing though imo (i.e. consume this character/symbol, move to this state, ...)

[15:05:58.0000] <abarth>
i'm sorry, but I don't have the attention to spend on this issue.  please make whatever decision you all think is best

[15:07:01.0000] <abarth>
I promise not to complain later (at least not out loud :) )

[15:12:15.0000] <Ms2ger>
abarth, dangerous... :)

[15:14:29.0000] <abarth>
more or less dangerous than https://codereview.chromium.org/174073007/ ?

[15:14:30.0000] <abarth>
:)

[15:16:50.0000] <Ms2ger>
abarth, oh, that's not dangerous at all, go ahead and land it ;)


2014-02-22
[16:05:15.0000] <TabAtkins>
heycam: See, for example, CSS Syntax, which declares the meaning of each token.

[16:06:17.0000] <heycam>
TabAtkins, CSS Syntax also defines parsing algorithms in terms of token consumption, which is something that I'd like to avoid if possible

[16:06:38.0000] <heycam>
TabAtkins, I think for CSS it's fine, since you can't neatly describe it with "parse with this grammar or fail"

[16:07:35.0000] <TabAtkins>
You're doing that anyway, if you say things like "the digit-sequence construction represents the result of evaluating the matched characters as a base-10 number", or whatever.

[16:08:05.0000] <TabAtkins>
heycam: Also, only the *parser* has error-recovery of that sort.  Virtually all individual constructs in CSS are described in "parse correctly or fail" terms.

[16:08:19.0000] <heycam>
TabAtkins, ok

[16:08:28.0000] <heycam>
TabAtkins, well I'll see what happens when I eventually rewrite that section :)

[16:08:36.0000] <TabAtkins>
The three-level parsing we have is just a convenience, allowing us to do the various definition work in one place for each thing.

[16:08:54.0000] <TabAtkins>
Tokenizing -> Generic Parsing -> Feature Grammars

[16:44:18.0000] <Hixie>
othermaciej: i gotta say, "this.elements.a.value" seems vastly preferable to "this.querySelector("#a").value"

[16:44:36.0000] <Hixie>
othermaciej: maybe i've just got odd engineering aesthetic taste :-)

[16:45:32.0000] <othermaciej>
Hixie: if it's based on aesthetics and not terseness, I could go either way

[16:46:16.0000] <othermaciej>
(a) magic namespaces can be convenient but on the other hand they can be conceptually confusing

[16:46:43.0000] <othermaciej>
(b) using a very context-specific way to access an element is in some ways less elegant than using a fully general way

[16:47:07.0000] <TabAtkins>
(c) What happens with <div id="toString">???

[16:47:15.0000] <othermaciej>
if it were not for the issues with form.elements that Jonas raised, I would be all for extending it (after all, what's the downside)

[16:47:23.0000] <TabAtkins>
<div id="__proto__">

[16:47:48.0000] <othermaciej>
but the fact that it misses some kinds of form elements and is a live collection - ick

[16:48:13.0000] <othermaciej>
Jonas's getParticipants() could provide a symbolic magic namespace if desired, though at some cost of terseness relative to elements

[16:48:17.0000] <TabAtkins>
Also, we're gaining just a plain .query() (iirc the name it's ending up with?), so "this.query('#a')" versus "this.elements.a" becomes more evenly matched in terseness.

[16:48:55.0000] <othermaciej>
this.query('#a') is some sweet syntax IMO

[16:50:19.0000] <sicking>
in general, proxy like APIs do not seem that great to me. Especially when they have built-in properties like .length, .item, .namedItem and .__proto__

[16:51:07.0000] <othermaciej>
I tend to prefer things that are more overtly a dictionary instead of relying on the poor-man's-dictionariness of JS objects

[16:51:12.0000] <sicking>
I think form.control("name") is just as good as form.elements.name

[16:51:58.0000] <sicking>
oh, right, form.elements does the crazy thing of "return a node or a nodelist" thing

[16:52:08.0000] <TabAtkins>
Yes, objects as pretend dictionaries is terrible.

[16:52:09.0000] <sicking>
that adds another level of crazyness

[16:52:49.0000] <sicking>
especially considering the liveness. It means that a property can morph from being a Node to a NodeList

[16:53:02.0000] <sicking>
a live NodeList to make things worse

[16:55:52.0000] <sicking>
I'll also note that ES6's map class is based on .get() and .set() functions, rather than .foo.

[16:56:18.0000] <sicking>
I generally prefer to defer to the API design patterns from TC39 than the ones from the DOM

[16:57:34.0000] <TabAtkins>
And I've been pushing hard in the same direction, encouraging use of Map/Set methods rather than homebrew collections.

[16:58:16.0000] <sicking>
I'll add Array to that list

[17:04:13.0000] <othermaciej>
Map, Set and Array are good primitives and good ways of managing collections

[17:09:17.0000] <sicking>
TabAtkins: that said, the way you are inheriting Map in the fontloader looks iffy to me. I sent feedback to jdaggett (since he reached out for review). Not sure if he forwarded it to you?

[17:09:33.0000] <TabAtkins>
I didn't get that feedback, I don't think.

[17:09:36.0000] <TabAtkins>
What's iffy about it?

[17:10:01.0000] <TabAtkins>
(heycam also said he might have problems with how I asked for [MapClass] to work, but he hasn't worked out how to fix yet.)

[17:10:02.0000] <sicking>
TabAtkins: for example, what happens if a font is removed from the Set (I forget if you inherit Map or Set?)

[17:10:12.0000] <TabAtkins>
It's a Map.

[17:10:24.0000] <sicking>
TabAtkins: key'ed on?

[17:10:35.0000] <TabAtkins>
Blarg, sorry.  It's a set.

[17:11:04.0000] <TabAtkins>
Anyway, this <http://dev.w3.org/csswg/css-font-loading/#font-face-set-css> defines what happens if you mutate the set yourself.

[17:11:46.0000] <heycam>
TabAtkins, if we make plain Array objects the values of choice for IDL attributes that reflect list-ish things, we might be able to do the same with Map for associated array stuff. but while the browser can Object.watch the Array to watch for changes to it from script, you can't do that with Maps

[17:11:55.0000] <sicking>
TabAtkins: what's the purpose of keying it on FontFace objects? When would you ever want to do a lookup based on a FontFace object?

[17:12:06.0000] <heycam>
since the data is stored in internal properties, and there aren't real property changes that would trigger the Object.watch observer

[17:12:10.0000] <TabAtkins>
heycam: I know. :/  That lack of ability to hook maps/sets is super frustrating.

[17:12:21.0000] <TabAtkins>
sicking: I don't understand your question, since it's not keyed on anything.

[17:12:35.0000] <sicking>
TabAtkins: sets are keyed on their values, no?

[17:12:47.0000] <TabAtkins>
sicking: They're not really "keyed" on anything?

[17:12:53.0000] <sicking>
TabAtkins: i disagree

[17:12:57.0000] <TabAtkins>
I mean, technically, sets can be implemented as maps with a dummy value.

[17:13:15.0000] <sicking>
TabAtkins: sets are maps with no value

[17:13:18.0000] <sicking>
but they still have keys

[17:13:20.0000] <TabAtkins>
But they're just an Array with a less visible ordering, and no duplicates.

[17:13:23.0000] <sicking>
hence they are keyed

[17:13:41.0000] <TabAtkins>
I don't see how they have keys.

[17:13:45.0000] <TabAtkins>
There's no .get() method.

[17:13:54.0000] <TabAtkins>
Just .add()

[17:13:57.0000] <TabAtkins>
And .has()

[17:14:00.0000] <sicking>
TabAtkins: there's a .has() method

[17:14:15.0000] <TabAtkins>
And?

[17:14:27.0000] <sicking>
the has method does a lookup based on the value you pass in. I.e. it uses the value as a key

[17:14:36.0000] <TabAtkins>
Sure.

[17:14:54.0000] <sicking>
expectation is that .has() runs in constant time, no?

[17:15:01.0000] <sicking>
ish

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

[17:15:17.0000] <sicking>
that means that there's a hash table

[17:15:20.0000] <TabAtkins>
Yes.

[17:15:27.0000] <sicking>
hash tables have keys

[17:15:54.0000] <TabAtkins>
We can keep doing this all day, or you can tell me what your point is. ^_^

[17:15:57.0000] <othermaciej>
talking about keys in the context of a non-associative data structure is not the clearest terminology

[17:16:27.0000] <sicking>
TabAtkins: why would you ever want to do .has(FontFace)? Or .add(FontFace)?

[17:16:40.0000] <sicking>
TabAtkins: or .delete(FontFace)

[17:16:42.0000] <TabAtkins>
You probably don't want to do .has().

[17:16:47.0000] <TabAtkins>
.add() is useful if you construct your own.

[17:17:02.0000] <TabAtkins>
.delete() isn't useful most of the time, but if you can add, there might be use-cases for deleting.

[17:17:20.0000] <TabAtkins>
And it comes for free with the "act like a Set", so we keep it.

[17:17:27.0000] <sicking>
TabAtkins: what's the use case for de-duping FontFace objects?

[17:17:46.0000] <sicking>
TabAtkins: i.e. what's the use case for making the .add function not add if the FontFace instance already exists?

[17:17:47.0000] <othermaciej>
/me guesses is that sicking's point is that an array would be better

[17:17:55.0000] <TabAtkins>
the fact that dupes are meaningless?

[17:18:14.0000] <othermaciej>
is the sequence relevant?

[17:18:19.0000] <sicking>
othermaciej: right. The current API doesn't seem to take advantage of the hash at all

[17:18:32.0000] <TabAtkins>
Using an array means that I expose an index as well.  This index isn't stable (it changes if you add/remove @font-face rules from the document's stylesheets).

[17:18:47.0000] <sicking>
i think having a myFontLoader.loadedFonts Array would be much more intuitive

[17:19:16.0000] <TabAtkins>
The only thing I really want to expose is .add() and [iterator]()

[17:19:28.0000] <TabAtkins>
Set is the best match for that.

[17:19:50.0000] <sicking>
TabAtkins: as soon as you have an iterator you have indexes

[17:20:05.0000] <sicking>
so you'll have to deal with that problem no matter what

[17:20:06.0000] <othermaciej>
index being unstable is not really a good reason to specifically not use an Array

[17:20:12.0000] <sicking>
/me isn't sure if Sets have stable indexes

[17:20:17.0000] <othermaciej>
as long as there's still an order

[17:20:18.0000] <TabAtkins>
Only ad-hoc ones you invent yourself.  You can't use those indexes later to directly access something (and be fooled by the value at that index being swapped out).

[17:20:45.0000] <TabAtkins>
The worst you could do is associate it with an index in a side data structure, and assume that'll be stable across invocations.

[17:20:56.0000] <othermaciej>
document.queryAll() gives you an array, because element order in the document is still an order, even though indices can change if you add or remove elements

[17:21:03.0000] <othermaciej>
well, an array-ish thing

[17:21:06.0000] <TabAtkins>
But if you have modern JS, you can just use a Map (or a WeakMap) instead and key it to the FontFace directly.

[17:21:07.0000] <othermaciej>
rather than a set-ish one

[17:21:49.0000] <othermaciej>
Array doesn't really promise a stable order, but it does vaguely imply that order is in some what meaningful

[17:22:01.0000] <sicking>
TabAtkins: is synchronously adding fonts even a good idea. It forces parsing on the main thread, no?

[17:22:03.0000] <TabAtkins>
Everything has an order in JS, because we're not comfortable with enforcing randomized iteration orders, and anything less creates a compat hazard.

[17:22:15.0000] <TabAtkins>
sicking: Nope, read the spec.  ^_^

[17:22:35.0000] <TabAtkins>
It doesn't force any more synchrony than adding a new @font-face to the document via script does.

[17:22:37.0000] <sicking>
TabAtkins: sorry, if you want me to read the full spec in full detail you won't get my review

[17:23:00.0000] <TabAtkins>
I wasn't aware we were doing an ad hoc review right now.  ^_^

[17:23:17.0000] <TabAtkins>
Normally, questions that can be answered by the spec can be adequately answered by "read the spec". ^_^

[17:23:52.0000] <TabAtkins>
Actually parsing the font face data is done asynchronously.  We expose a promise for when the font is fully loaded and ready.

[17:24:14.0000] <sicking>
ah

[17:24:39.0000] <sicking>
any reason you're not accepting URLs or Blobs in the ctor then

[17:24:40.0000] <sicking>
?

[17:24:46.0000] <TabAtkins>
I am.

[17:24:53.0000] <TabAtkins>
/me holds off saying "read the spec" again...

[17:25:11.0000] <TabAtkins>
http://dev.w3.org/csswg/css-font-loading/#font-face-constructor step 3

[17:26:03.0000] <TabAtkins>
Right now I only accept TypedArrays as direct data, but I could accept a Blob as well I suppose.

[17:26:10.0000] <sicking>
ah, URLs are indeed accepted, but not Blobs afaict

[17:26:26.0000] <sicking>
not a big deal as long as URLs are there

[17:26:33.0000] <sicking>
though less leak prone

[17:26:45.0000] <TabAtkins>
Well...  Do blobs have serializable URLs?

[17:27:09.0000] <sicking>
yes, if you use URL.createObjectURL

[17:27:16.0000] <TabAtkins>
Okay.

[17:27:17.0000] <sicking>
but it's leak prone

[17:27:23.0000] <TabAtkins>
It's not a problem to take a Blob directly.

[17:28:15.0000] <TabAtkins>
Hm, is there anything weird I need to know about Blobs?  Or does http://dev.w3.org/csswg/css-font-loading/#font-face-constructor step 4 handle Blobs sufficiently?

[17:28:28.0000] <TabAtkins>
(Being somewhat generic about "the data in it".)

[17:29:15.0000] <sicking>
i think that's pretty much good enough

[17:29:26.0000] <TabAtkins>
kk

[17:29:36.0000] <TabAtkins>
I'll just add Blob to the BinaryData typedef, then.

[17:29:46.0000] <TabAtkins>
(We don't implement the BinaryData side of the constructor quite yet.)

[17:29:50.0000] <annevk-cloud>
At some point blobs will have a way to read their data, not in the blob spec yet

[17:30:06.0000] <sicking>
TabAtkins: i'm still not sure I see the value in the current use of a Set though

[17:30:25.0000] <annevk-cloud>
You need that to better deal with failure or the blob being closed and such

[17:30:50.0000] <sicking>
TabAtkins: Adding a property with an Array seems better

[17:30:54.0000] <TabAtkins>
Shrug.  Array has more stuff in it than I needed - all I need is something that'll hold some objects.

[17:31:05.0000] <TabAtkins>
(I'm seeing Set as being simpler than an Array.)

[17:31:07.0000] <sicking>
TabAtkins: you could make the Array be frozen to avoid worrying about mutations

[17:31:16.0000] <TabAtkins>
Nah, we want to allow mutations.

[17:31:16.0000] <sicking>
TabAtkins: and add a .add(FontFace) function on the loader

[17:31:28.0000] <sicking>
TabAtkins: including removals?

[17:31:32.0000] <TabAtkins>
Why not?

[17:31:41.0000] <sicking>
more code in implementations

[17:31:44.0000] <TabAtkins>
(Note that you can't remove CSS-connected ones, only manually-added ones.)

[17:32:39.0000] <TabAtkins>
Why not just say that .delete() and .clear() don't do anything?

[17:33:20.0000] <TabAtkins>
I gotta head home - we can pick this up tomorrow.

[17:33:41.0000] <sicking>
TabAtkins: how would we implement .delete() not doing anything?

[17:33:56.0000] <sicking>
since we'll likely reuse the actual JS Set implementation

[17:33:58.0000] <TabAtkins>
Exactly that way.

[17:34:02.0000] <TabAtkins>
You can override the methods.

[17:34:45.0000] <sicking>
i'm not entirely sure how we would implement subclassing Set, so i'm not sure

[17:35:05.0000] <sicking>
but having a .delete() function that didn't delete seems pretty poor

[17:38:17.0000] <TabAtkins>
I mean, it would probably throw instead.

[17:38:37.0000] <TabAtkins>
(Subclassing Set/Map is pretty piss-poor right now, I think.)

[17:39:05.0000] <sicking>
agreed. Array too

[17:39:30.0000] <TabAtkins>
(I think the only way to reliably do it is to put Set/Map on your proto chain, for detection purposes, but then implement reimplement all the methods yourself and forward to a contained Set/Map holding the real data.)

[17:39:30.0000] <sicking>
i'm kind'a worried that subclassing in JS is entirely broken

[17:39:39.0000] <sicking>
apparently one of the design patterns is to allow base classes to instantiate subclasses

[17:39:40.0000] <TabAtkins>
Subclassing works fine in user-land. :/

[17:40:22.0000] <sicking>
yeah, i think in user-land they use different rules

[17:40:33.0000] <sicking>
than what tc39 is trying to implement

[17:40:43.0000] <sicking>
at least that's my perception

[17:46:41.0000] <TabAtkins>
heycam: All I really want WebIDL to do is let me define a handful of core methods for my thing, have it act like a Map/Set, and then I never have to worry about it again.

[17:47:23.0000] <TabAtkins>
In particular, "not worry about it" means that if new Map/Set methods get added, it can be handled directly in WebIDL, not in every single spec that uses a Map/Set-like interface.

[17:47:47.0000] <sicking>
TabAtkins: I don't think we should make WebIDL go beyond what ES6 provides

[17:47:53.0000] <TabAtkins>
Also, for friendliness, basic typechecking should work (instanceof), and userland methods added to Map/Set.prototype should work.

[17:48:27.0000] <TabAtkins>
sicking: It's possible that this should be better handled in ES6.  I proposed this a year or so ago, didn't get anywhere with it.

[17:48:30.0000] <heycam>
TabAtkins, those latter points paint us into this awkward corner of subclassing Map where it's not really designed to be subclassed

[17:48:53.0000] <sicking>
TabAtkins: i hear you :(

[17:48:58.0000] <TabAtkins>
(Specifically, I suggested defining a MapCore or whatever class that had just get/set/has/delete, and similar for Set.)

[17:49:29.0000] <TabAtkins>
And Map is defined to store its data in an internal MapCore, and other methods are defined on top of that.

[17:49:53.0000] <TabAtkins>
Maybe MapCore#clear too, just to let that one be efficient.  Oh, and [iterator], obviously.

[17:50:07.0000] <TabAtkins>
So 5 or 6 core methods, and everything else forever defined on top of just those.

[17:51:15.0000] <TabAtkins>
Then WebIDL could specify that when you subclass you can swap out the core for something else that implements the same methods.

[17:51:28.0000] <TabAtkins>
And we can expose that to userland via a [core] symbol or something.

[17:51:54.0000] <heycam>
that sounds more much reasonable than the current [MapClass] setup

[17:52:29.0000] <heycam>
plug a map behaviour into a Map object

[17:52:29.0000] <TabAtkins>
Tell that to AWB.

[17:55:11.0000] <heycam>
the alternative is to do something like we want to do with Arrays, where at defined times the browser can update/replace an IDL attribute's Array object, and uses Object.watch on it

[17:55:20.0000] <heycam>
you'd need to forgo exceptions being thrown with bad values inserted into the Map though

[17:55:30.0000] <heycam>
and you'd need a Map.watch mechanism

[17:56:32.0000] <TabAtkins>
A watch mechanism that lets me filter out the bad things before they get used is sufficient.

[17:56:55.0000] <heycam>
TabAtkins, yeah you can always in prose skip over items of bad types

[17:57:02.0000] <TabAtkins>
Since you'd only be able to insert bad things by doing silly monkeypatching, like "Map.prototype.set.call(mapSubclass, badVal)"

[17:57:04.0000] <heycam>
TabAtkins, doesn't need to be integrated with the watching mechanism

[17:57:08.0000] <sicking>
yeah, synchronously calling into a validate-value hook would help hugely with DOM APIs

[17:57:16.0000] <sicking>
for all container types

[17:57:31.0000] <heycam>
sicking, I think that argues for the map core kind of pattern

[17:57:55.0000] <heycam>
I wonder if you could retrofit something like that onto Arrays as well

[19:18:19.0000] <SamB>
/me wonders if he is the only one who gets oddly-aligned checkboxes on http://naesten.mooo.com:8080/checkbox-off-kilter.html ...

[19:18:49.0000] <TabAtkins>
SamB: Off kilter for me too, in Chrome stable channel.

[19:20:27.0000] <SamB>
/me wonders if it's been like this forever and he only just noticed

[19:27:54.0000] <Goplat>
it should be off in any browser due to the table's cellspacing and cellpadding

[20:34:34.0000] <SamB>
Goplat: does only the one in the table look bad to you?

[20:35:31.0000] <Goplat>
They both look fine on their own, they're just not aligned with each other

[20:36:12.0000] <SamB>
oh, that's really two examples that happen to be in one file

[20:36:48.0000] <SamB>
my problem is that the text seems to be a few pixels below where it ought to be

[01:23:19.0000] <Ms2ger>
foolip is on a roll

[01:39:05.0000] <Ms2ger>
Does anything define the initial networkState?


2014-02-23
[09:52:27.0000] <SamB>
/me kind of wishes that the rules for http-equiv="refresh" would allow a user who has been "forwarded" to a different URL to hit "back" and return to the page with the "refresh" without being forwarded again ... or something like that ...

[10:19:16.0000] <Lachy_>
SamB, there are browser extensions that can be used to disable meta refresh

[10:30:59.0000] <foolip>
Ms2ger: the initial networkState and readyState aren't explicitly listed, but the definitions of HAVE_NOTHING and NETWORK_EMPTY are the only ones that apply for a newly created element.

[10:31:05.0000] <foolip>
and now bed

[10:31:17.0000] <Ms2ger>
Good night, and thanks a lot for all those :)

[11:12:24.0000] <SamB>
the CSS box model needs more illustrations ...

[11:14:58.0000] <Ms2ger>
Make some :)

[11:33:31.0000] <SamB>
making usable technical illustrations is surprisingly tricky

[11:34:07.0000] <SamB>
also, I'd have to actually be able to understand the rules before I could produce diagrams that would elucidate them ;-P

[11:40:36.0000] <Ms2ger>
That's exactly why there are so few :)

[11:41:52.0000] <Ms2ger>
Seriously though, anybody who wants to make illustrations will almost certainly get a hero's welcome :)

[11:52:17.0000] <SimonSapin>
I initially made this only for myself, but https://pbs.twimg.com/media/A6cKmvQCcAAApzT.png:large

[11:59:58.0000] <jgraham_>
/me puts SimonSapin in the set of people with unreadable handwriting

[12:01:00.0000] <SimonSapin>
jgraham: especially when it wasn’t meant to be read by other people, but yeah


2014-02-24
[23:48:28.0000] <zcorpan>
MikeSmith: http://validator.nu/?doc=http%3A%2F%2Fexample.com%2F validates dispite having two encoding decls

[23:49:50.0000] <MikeSmith>
zcorpan: yeah I haven't implemented a check for that case yet

[23:50:26.0000] <zcorpan>
MikeSmith: and now millions of people will copy-paste from example.com and then get angry when you do implement that check :-P

[23:52:29.0000] <MikeSmith>
heh

[23:52:31.0000] <MikeSmith>
yup

[23:57:37.0000] <zcorpan>
TabAtkins: can you have a look at https://github.com/ResponsiveImagesCG/picture-element/pull/109 please?

[00:58:19.0000] <MikeSmith>
zcorpan: do you know if lxml is installed on html5.org?

[00:58:57.0000] <MikeSmith>
Hixie doesn't seem to have it on whatwg.org and I don't want to try to figure out how to do the same thing in perl

[01:01:16.0000] <MikeSmith>
hmm no lxml on html5.org either

[01:17:40.0000] <zcorpan>
MikeSmith: why do you need lxml?

[01:29:09.0000] <MikeSmith>
zcorpan: I don't necessarily need lxml I guess

[01:29:45.0000] <MikeSmith>
if there's some other relaTively easy way

[01:29:51.0000] <zcorpan>
MikeSmith: what are you trying to do?

[01:30:40.0000] <MikeSmith>
get the text contents of the first cell in each row of a table

[01:32:33.0000] <zcorpan>
from an arbitrary URL?

[01:32:48.0000] <MikeSmith>
the MetaExtensions page from the wiki

[01:33:11.0000] <MikeSmith>
just want to grab only the registered names

[01:36:11.0000] <MikeSmith>
I guess I could just use whatever stock DOM API there is in python

[01:37:04.0000] <MikeSmith>
and whatever html parser

[01:38:26.0000] <zcorpan>
don't wikis have APIs to read the data so you don't have to scrape the HTML?

[01:41:21.0000] <MikeSmith>
mediawiki doesn't seem to

[01:41:40.0000] <MikeSmith>
at least not that I could find

[01:41:55.0000] <zcorpan>
http://www.mediawiki.org/wiki/API:Main_page

[01:42:23.0000] <MikeSmith>
wish it did. would save me the trouble

[01:42:43.0000] <MikeSmith>
yeah that doesn't have what I need

[01:43:10.0000] <MikeSmith>
as far as I can tell

[01:43:37.0000] <MikeSmith>
plus we are running an old version of mediawiki

[01:43:43.0000] <MikeSmith>
I think

[01:45:06.0000] <MikeSmith>
as far as I could find, all that API lets me do it's grab the raw wikitext as one big chunk

[01:45:52.0000] <MikeSmith>
but would be very happy to find out I'm missing something in the docs

[01:47:30.0000] <zcorpan>
yeah ok, i can see that it doesn't help you much

[01:49:03.0000] <MikeSmith>
yeah I asked Aryeh about it couple years back and he said even the latest API didn't provide anything

[01:49:24.0000] <MikeSmith>
anyway I'll mess around with or more later

[01:50:02.0000] <MikeSmith>
I'm on a plane to San Francisco that's about to depart

[01:51:21.0000] <Ms2ger>
Don't fall down

[01:53:53.0000] <zcorpan>
MikeSmith: write a regex

[01:53:55.0000] <MikeSmith>
heh

[02:40:08.0000] <darobin>
MikeSmith: if you can get at the raw wiki text, then there's a bunch of parsers for that which you could use

[02:40:30.0000] <darobin>
given how many there are you'd hope at least one is passable

[03:20:03.0000] <jgraham>
MikeSmith: Why does it have to run on html5.org?

[03:20:22.0000] <jgraham>
But you could certainly use html5lib + ElementTree or something

[04:28:35.0000] <JakeA>
Anyone got a clue on how es imports (the declarative kind) may work in the browser?

[07:25:59.0000] <Domenic_>
JakeA: I believe the plan of record is something like <script type="module" src="main-module.js"></script>, where main-module.js uses standard ES import syntax.

[07:26:21.0000] <Domenic_>
JakeA: this would be sugar for <script>System.import("main-module.js");</script>

[07:28:59.0000] <JakeA>
Domenic_: Ahh ok, what would <script>import foo from "foo";</script> do?

[07:29:10.0000] <JakeA>
Would it block?

[07:29:44.0000] <Domenic_>
JakeA: be a syntax error; scripts cannot use syntax only available in modules.

[07:34:35.0000] <JakeA>
Domenic_: Ahh, I didn't know import was module-only.

[07:37:49.0000] <JakeA>
Domenic_: Did the idea of module bundling get beyond the idea of zip urls?

[07:37:50.0000] <Domenic_>
JakeA: not really, although Dave is still interested in working on that. There's also manual bundling with System.define('path-to-module', 'source-code-of-module') I believe.

[07:46:28.0000] <JakeA>
Domenic_: Interesting. What's the scope of System.define? If <script type="module" src="main-module.js"></script> defines a load of modules, are they available to System.imports elsewhere in the page?

[07:49:12.0000] <Domenic_>
JakeA: I think so, although since modules are loaded async you'd have a bad time waiting for module-load before trying to use System.import

[07:49:34.0000] <JakeA>
Domenic_: Exactly what I was thinking

[07:49:41.0000] <Domenic_>
you shouldn't be using System.define in modules, really. It's meant for scripts

[07:49:51.0000] <JakeA>
<script src="my-modules.js" async></script> ... <script>System.import('comments').then(initComments)</script>

[07:49:52.0000] <JakeA>
...will be async faily

[07:49:57.0000] <Domenic_>
yeah, just like anything that relies of <script async> + <script> executing in order

[07:49:57.0000] <JakeA>
Right

[07:49:57.0000] <Domenic_>
just use <script> + <script>

[07:49:57.0000] <JakeA>
Which blocks :(

[07:50:25.0000] <Domenic_>
i think you understand this stuff much more than i, but why does that block any more than <script async> + <script>? In both cases you have a blocking <script>.

[07:50:54.0000] <JakeA>
<script> blocks any further rendering because of the potential of document.write

[07:51:16.0000] <JakeA>
whereas async doesn't. But async throws out any control of execution order

[07:51:26.0000] <Domenic_>
sure. but <script async> + <script> still blocks, right? Since <script> blocks.

[07:52:06.0000] <JakeA>
The 2nd script doesn't wait for the async script

[07:52:24.0000] <Domenic_>
sure, but i thought you were worried about blocking...

[07:53:38.0000] <JakeA>
If script B depends on script A, both scripts must load in a blocking way, right?

[07:54:01.0000] <Domenic_>
I dunno, I vaguely remember there being some HTML attribute that preserved order but didn't block?

[07:54:13.0000] <Domenic_>
Or you could just concat the two and use <script async> for the result

[07:54:34.0000] <JakeA>
defer will execute in doc order, but it waits until domready and is broken in IE<10

[07:54:59.0000] <Domenic_>
(That is how most bundlers, RequireJS, browserify etc. work already---your bundle contains module definitions + main module code.)

[07:55:04.0000] <JakeA>
Right, having to combine isn't great in a spdy/http2 world

[07:55:17.0000] <Domenic_>
well then why are we talking about bundles anyway

[07:55:21.0000] <Domenic_>
just use modules straight-up

[07:55:54.0000] <JakeA>
And if you have scripts A, B, C, D etc, where B onwards depend on A, but no interdependency, you're slowing down enhancements

[07:56:07.0000] <JakeA>
Bundling was a separate question

[07:57:24.0000] <Domenic_>
but you were asking about load order in the context of a bundle ("my-modules.js"), so I got confused.

[07:57:33.0000] <Domenic_>
if you are not bundling, ordering is solved by the module loader system

[07:58:45.0000] <JakeA>
Makes sense, so <script type="module" src="main-module.js"></script> becomes a way to flatten the dependency tree?

[07:59:31.0000] <JakeA>
As in, have as many script[type=module]s as you need, so the preparser catches them?

[08:02:02.0000] <Ms2ger>
Boo, script type

[08:03:11.0000] <Domenic_>
Ms2ger: I know, unfortunately it's the only parser-compatible solution it seems.

[08:03:42.0000] <Domenic_>
JakeA: I guess? I thought in HTTP2 the server would just push all files in the graph the moment you required main-module.js

[08:04:37.0000] <Ms2ger>
Unrelatedly

[08:04:39.0000] <Ms2ger>
zcorpan++

[08:06:18.0000] <JakeA>
Domenic_: unless main-module's requirements had crossover with others that you may have encountered on other pages

[08:06:26.0000] <JakeA>
Domenic_: may end up downloading stuff you already have

[08:06:46.0000] <Domenic_>
JakeA: I thought http2 would try pushing those and then be told it's not necessary

[08:07:13.0000] <JakeA>
Domenic_: hmm, possibly, I'm unclear on that

[08:07:18.0000] <Domenic_>
JakeA: RST_STREAM from http://www.mnot.net/blog/2014/01/30/http2_expectations

[08:08:16.0000] <JakeA>
Domenic_: Ahh that's good, I hadn't seen that feature before

[08:08:54.0000] <JakeA>
Ok, that all makes sense. We went around a bit last year on the idea of <script requires=".other-script-and-link-elements">, but think modules covers most of it

[08:09:21.0000] <Domenic_>
yeah, i think it should work pretty nicely :)

[08:09:45.0000] <JakeA>
Cheers!

[08:40:38.0000] <aleray>
Hi, I'm trying to write a small function to wrap implicit section of an html document into section tags. Here is the input and output: http://dpaste.com/1653856/

[08:40:50.0000] <aleray>
I'm trying to do so with lxml.etree

[08:40:51.0000] <aleray>
any idea?

[09:47:29.0000] <dglazkov>
good morning, Whatwg!

[10:45:23.0000] <cwilso___>
Wow, no replies.  Good morning, dglazkov!

[10:45:32.0000] <Hixie>
a cwilso!

[11:18:30.0000] <gsnedders>
Hixie, TabAtkins: can I get a rucksack shipped to one of you? Warranty replacement will only ship to the US — if either of you could just keep it around until I'm next around (which I guess will be TPAC), I'd appreciate it.

[11:39:37.0000] <TabAtkins>
gsnedders: Yeah, let me send you mya ddress.

[12:50:46.0000] <gsnedders>
Can someone please fix Fx so if there's a new update made available after one has been downloaded it downloads the new one?

[12:54:40.0000] <Ms2ger>
Anyone feel like getting the webgl tests into wpt?

[13:31:00.0000] <MikeSmith>
greetings from San Francisco whatwgians

[13:31:10.0000] <Hixie>
greetings

[13:31:58.0000] <MikeSmith>
I guess I won't need the down jacket I brought

[13:32:36.0000] <MikeSmith>
Ms2ger: yeah I feel like getting webgl tests into wpt but not strongly enough to write them

[13:32:53.0000] <Ms2ger>
Khronos has some

[13:33:02.0000] <MikeSmith>
well

[13:33:14.0000] <Ms2ger>
Not very good ones

[13:33:17.0000] <Ms2ger>
But still :)

[13:33:43.0000] <MikeSmith>
yeah maybe they've improved since that last time I tried to run them

[13:35:28.0000] <rafaelrinaldi>
MikeSmith: greetings from Brazil :)

[13:39:06.0000] <MikeSmith>
rafaelrinaldi: I reckon my down jacket would be even less useful there right now

[13:47:59.0000] <hober>
MikeSmith: how long are you in town?

[13:49:21.0000] <MikeSmith>
hober: all week

[13:50:00.0000] <othermaciej>
hober, MikeSmith: town == SF?

[13:50:48.0000] <MikeSmith>
othermaciej: yep

[13:51:26.0000] <Domenic_>
so... how about dem microtasks? (i am stuck compiling java at work and super-bored.)

[13:51:30.0000] <othermaciej>
I believe this calls for a traditional ritual ingestion of alcoholic beverages at some point

[13:51:38.0000] <othermaciej>
(if time permits)

[13:51:43.0000] <hober>
othermaciej++

[13:52:58.0000] <MikeSmith>
othermaciej: yes and a toast or two or three to something appropriate

[13:54:09.0000] <MikeSmith>
my evenings are pretty much all free so far

[13:54:33.0000] <MikeSmith>
so, plenty of toasting opportunities

[13:55:05.0000] <Hixie>
anyone got ELinks around?

[13:57:13.0000] <MikeSmith>
Hixie: I reckon I do

[13:58:05.0000] <Hixie>
MikeSmith: http://damowmow.com/playground/demos/xhtml/001.xhtml

[13:58:13.0000] <Hixie>
MikeSmith: basic sanity test for xhtml. what does it do on that page?

[13:58:26.0000] <Hixie>
(compare to firefox or chrome or something for a baseline)

[13:58:51.0000] <MikeSmith>
it says "What would you like to do with the file '001.xhtml' (type: text/xml)?"

[13:58:56.0000] <MikeSmith>
prompts me to download it

[13:59:02.0000] <Hixie>
excellent, thanks

[14:04:26.0000] <Hixie>
i wonder where this convention of quoting using [[...]] came from

[14:04:59.0000] <Hixie>
it's so ugly and unclear compared to prefixing lines in blocks, or using regular quotes...

[14:05:09.0000] <TabAtkins>
Who's doing that?  That's weird.

[14:05:23.0000] <TabAtkins>
[...] is only to be used for elisions and rephrasings within a quote.

[14:12:54.0000] <Hixie>
a lot of people do [[...]]

[14:13:03.0000] <Hixie>
e.g. the bug filing thing on dom.spec.whatwg.org

[14:14:30.0000] <TabAtkins>
Oh, that's weird.

[14:56:06.0000] <Hixie>
wtf

[14:56:11.0000] <Hixie>
apache just stopped responding?

[14:56:16.0000] <Hixie>
everything else on the machine is working fine.

[14:57:07.0000] <SimonSapin>
Is there public data where I can look for usage of some features on the web?

[14:57:46.0000] <SimonSapin>
(In this case, this is about dropping display:-moz-grid, which is XUL and not css-grid)

[14:58:13.0000] <Hixie>
SimonSapin: there are some... Philip`_ might know about them?

[14:58:17.0000] <Hixie>
or zcorpan?

[14:58:29.0000] <Hixie>
in other news, it seems my outage is limited to ipv4.

[14:58:53.0000] <Hixie>
no, not even that

[14:58:54.0000] <Hixie>
w.t.f.

[14:59:01.0000] <Hixie>
and now it works

[14:59:03.0000] <Hixie>
computers baffle me.

[15:02:31.0000] <aklein>
Hixie: can you clarify whether you changed <img> elements to reload when _inserted_ into a new document or when _adopted_ into a new document? http://html5.org/tools/web-apps-tracker?from=8508&to=8509 isn't loading for me

[15:03:12.0000] <aklein>
Hixie: ah, just loaded, sounds like adopting

[15:03:23.0000] <Hixie>
i used the hook anne gave, which is triggered on adoption, but after insertion if the adoption happened with insertion. or at least, it will eventually be after, but right now it's before. or something.

[15:05:09.0000] <aklein>
hehe

[15:05:10.0000] <aklein>
ok

[15:05:26.0000] <aklein>
it would be pretty strange for adoption to happen after insertion, imho

[15:05:38.0000] <Hixie>
no i mean the hook is called after insertion

[15:05:39.0000] <aklein>
because then you don't have the invariant that everything in a document has the same ownerDocument

[15:05:42.0000] <Hixie>
the adpotion obviously happens before

[15:05:46.0000] <aklein>
ahh

[15:05:51.0000] <Hixie>
:-)

[15:06:38.0000] <aklein>
I guess I'll have to keep my eye out for that moving around, as it'll make WebKit and Blink incompatible with the spec...

[15:07:00.0000] <Hixie>
supposedly that change is needed for web components

[15:07:10.0000] <Hixie>
but i don't know the details (except what's in the bug)

[15:08:35.0000] <aklein>
huh, even more mysterious

[15:12:39.0000] <Hixie>
any recent IE users around able to tell me what the log is in: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2840 perchance?

[15:12:56.0000] <Hixie>
(make sure to wait the 6 seconds)

[15:19:44.0000] <Hixie>
nevermind, that test is busted

[15:29:01.0000] <Hixie>
heh, a google search for [meta name blogID] gets a lot of broken pages

[15:31:46.0000] <Hixie>
TabAtkins, tantek: do you know if anyone supports http://dev.w3.org/csswg/css-ui/#nav-index ?

[15:32:05.0000] <tantek>
Hixie, not AFAIK. Hence at risk.

[15:32:09.0000] <Hixie>
k

[15:32:27.0000] <TabAtkins>
Presto Opera might have, I dunno.  Maybe some TVs, as they've implemented some of the nav-* stuff, but maybe only the directional ones.

[15:32:33.0000] <tantek>
Hixie, I could be convinced to actually drop it from the next "published draft"

[15:32:44.0000] <tantek>
TabAtkins - only directional

[15:32:49.0000] <TabAtkins>
Ok, cool.

[15:32:52.0000] <Hixie>
i'm trying to figure out what i should be editing, or getting edited, to make sequential tab order work in the new focus world, in particular wrt skipping inertness

[15:33:01.0000] <Hixie>
i'm game to just speccing it in HTML if you think that's best

[15:33:08.0000] <tantek>
Hixie, I have mixed feelings

[15:33:09.0000] <Hixie>
or alternatively i can file a bug on css or something

[15:33:12.0000] <gsnedders>
Relatively certain ZombiePresto supports it, at for TVs.

[15:33:44.0000] <tantek>
Hixie - this is the nav-index issue: http://wiki.csswg.org/spec/css3-ui#issue-25

[15:35:00.0000] <Hixie>
tantek: well we need to spec somewhere that you can tab through viewports, scroll regions, multiple focusable regions e.g. in <video> control UIs, elements with tabindex="", input controls etc, but not e.g. links (by default) on mac, and not elements that are inert

[15:35:16.0000] <tantek>
Hixie, I'm collecting stuff to "fix" nav-index here: wiki.csswg.org/spec/css4-ui#nav-properties

[15:35:25.0000] <tantek>
I don't have strong feelings about where it goes

[15:35:28.0000] <Hixie>
(and not elements that have the tabindex focus flag but had tabindex=-1)

[15:35:40.0000] <tantek>
but if you want to add more "asks" e.g. what you wrote ^^^ I'm ok with that too

[15:36:12.0000] <tantek>
like I said, mixed / not strong feelings about it. if you have strong feelings about it let me know.

[15:36:27.0000] <Hixie>
my only strong feeling is i want it specced, sooner rather than later if possible

[15:36:37.0000] <Hixie>
happy to go either way on this

[15:37:10.0000] <Hixie>
so if your ETA is next 6 months, i can just give you a brain dump. if it's > 6 months, maybe best for me just to spec it, and then i can rip it out when you get a round tuit.

[15:37:35.0000] <Hixie>
either way is fine by me

[15:37:38.0000] <Hixie>
so long as we have a plan :-)

[15:37:39.0000] <TabAtkins>
a round tuit?

[15:37:49.0000] <TabAtkins>
around to it?

[15:38:29.0000] <Hixie>
TabAtkins: https://www.google.com/search?q=round+tuit :-)

[15:39:00.0000] <Hixie>
even better link: http://en.wiktionary.org/wiki/round_tuit

[15:39:11.0000] <TabAtkins>
Ah, I see.

[15:41:32.0000] <Hixie>
tantek: (related: there's been feature requests for tabindex scoping in HTML; presumably we should decide if it belongs in HTML or CSS)

[15:47:01.0000] <aleray>
hi, any advices for this questions? http://stackoverflow.com/questions/21993725/wrap-implicit-section-of-an-html-document-into-section-tags-using-lxml-etree

[15:47:39.0000] <aleray>
my mind is foamy today and I can't think of a solution to handle subheading nesting.

[15:48:24.0000] <Hixie>
tantek: so... should i go ahead and spec something in HTML?

[15:48:36.0000] <tantek>
hixie, bbiab - in meeting

[15:48:51.0000] <Hixie>
tantek: ah, ok. ttyiab!

[15:50:01.0000] <TabAtkins>
aleray: I don't see the problem.  Search over the document for top-level sections, collecting elements into an array and then moving them into a <section> when it's closed.  Then iterate over the <section>'s contents in the same way.

[15:50:09.0000] <TabAtkins>
That'll give you nested sections.

[15:52:58.0000] <aleray>
TabAtkins, interesting thanks


2014-02-25
[16:04:31.0000] <aleray>
TabAtkins, sorry I'm affraid I'm a little bit stuck here

[16:05:19.0000] <aleray>
could you help me drafting the algorithm?

[16:06:06.0000] <aleray>
i'm back with http://dpaste.com/1655272/

[16:09:08.0000] <TabAtkins>
Not really; I don't code against vanilla lxml if I can help it, because the API is terrible.

[16:09:32.0000] <aleray>
TabAtkins, what would you use instead?

[16:09:58.0000] <TabAtkins>
My custom DOM-like API on top of it, and tears when I have to use it directly. ^_^

[16:10:34.0000] <aleray>
on top of what? lxml.etree?

[16:10:42.0000] <aleray>
or something else?

[16:12:55.0000] <TabAtkins>
What I'm suggesting is that you make your algorithm able to take a sequence of elements (like all the children of <body>), and find the subset of them that belong to a given implicit section.  Use that to wrap them into a <section>, then re-run it on the children of the <section>.

[16:14:51.0000] <aleray>
TabAtkins, ok I give another try

[16:18:01.0000] <TabAtkins>
(I assume that you're running this against a relatively "flat" document, where all the headings are siblings.  More complicated structures can't be automatically wrapped in <section>s, because the outline algorithm doesn't necessary correspond to a reasonable nesting structure.)

[16:44:19.0000] <aleray>
TabAtkins, I have this now: http://dpaste.com/1655376/

[16:51:33.0000] <tantek>
Hixie, I'm back

[16:53:47.0000] <tantek>
/me is scrolling backwards

[16:59:43.0000] <tantek>
Hixie, ok I'm collecting your questions as issues with proposed answers.

[16:59:47.0000] <tantek>
re:  there's been feature requests for tabindex scoping in HTML - URLs?

[17:00:12.0000] <Hixie>
well really my question is what's your roadmap. are we talking 2 weeks? 2 months? 2 years?

[17:01:41.0000] <tantek>
it's not a high enough priority for me to put on an explicit roadmap - hence the request for URLs to the requests

[17:01:54.0000] <tantek>
regardless, I'm collecting questions/ thoughts / issues here: http://wiki.csswg.org/ideas/nav-index

[17:02:53.0000] <Hixie>
k. what i propose to do then is spec up what html needs just so we can define the status quo, probably this week or so, and then whenever is convenient for you, if you conclude that it should all be defined in CSS instead, just let me know and we can rip it out of HTML then

[17:03:25.0000] <Hixie>
i don't have any real questions / thoughts / issues other than what i mentioned above -- just a matter of speccing the status quo, for now, and in the future, that issue of the scoping thing.

[17:03:57.0000] <Hixie>
(this only became relevant recently because i just revamped how focus is specced, so there's a lot of loose ends now that i'd like to tie up sooner rather than later)

[17:04:13.0000] <tantek>
Hixie we have to define the status quo of tabindex *anyway*

[17:04:21.0000] <tantek>
so nothing should block you from doing that

[17:04:38.0000] <Hixie>
well the only part of tabindex that isn't specced is the sequential navigation algorithm at this point

[17:04:46.0000] <tantek>
I'm happy to wait to see what you do there before doing anything further with nav-indesx

[17:04:48.0000] <Hixie>
which presumably is the same algorithm that would take into accound nav-index

[17:04:51.0000] <Hixie>
roger

[17:05:12.0000] <tantek>
well there's the absence of spec, and then there's the issues that have been reported

[17:05:45.0000] <Hixie>
are there issues other than the above? i looked at the urls you pasted but they didn't have much in the way of anything else

[17:05:51.0000] <Hixie>
at least, not that i saw

[17:08:01.0000] <tantek>
Hixie, these were enough of a pain that I gave up for now: http://wiki.csswg.org/ideas/nav-index#external-issues-to-be-incorporated

[17:08:10.0000] <tantek>
if you want to tackle all those, be my guest

[17:08:48.0000] <Hixie>
that seems to boil down to "status quo" + "scoping"

[17:08:51.0000] <tantek>
if you could at least drop in a few URLs to your resolutions to that wiki page that would be great. or ping me here and I'll edit the page - either way I do want to shadow this work

[17:09:54.0000] <Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24719 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=23960 are the two things on my radar (status quo and scoping respectively)

[17:10:10.0000] <Hixie>
not planning on doing the scoping thing soon

[17:10:35.0000] <Hixie>
so the only decision is "should we match the status quo" which i'm answering "yes" to. :-)

[17:13:07.0000] <tantek>
Hixie, that's an excellent start and scoping of work ;)

[17:16:06.0000] <tantek>
and thanks for the URLs, incorporated as references: http://wiki.csswg.org/ideas/nav-index#within-a-dialog-and-browsing-context

[17:19:06.0000] <a-ja>
Hixie: haven't looked in a while...anyone doing focus on <summary> correctly yet?

[17:19:19.0000] <Hixie>
define "correctly"? :-)

[17:19:23.0000] <a-ja>
and <summary> containing a link

[17:19:52.0000] <Hixie>
not sure.

[17:19:57.0000] <Hixie>
gotta go, though. bbl.

[17:21:14.0000] <aleray>
TabAtkins, I'm getting there it seems, but I'm having troubles with recursion: http://dpaste.com/1655487/

[17:53:06.0000] <aleray>
TabAtkins, kind of there, seems to make the deal: http://dpaste.com/1655573/

[17:53:10.0000] <aleray>
thanks a lot for helping out$

[23:34:13.0000] <Ms2ger>
Anybody with a corpus want to grep for -moz-grid?

[00:52:21.0000] <zcorpan>
TabAtkins: why do css specs have the "default stylesheet" thing still? isn't that a waste of time given html's rendering section?

[02:21:04.0000] <JakeA>
Hixie: http://www.whatwg.org/specs/web-apps/current-work/multipage/edits.html should embeded content be part of the edits page?

[02:25:46.0000] <zcorpan>
JakeA: i think the splits are a bit arbitrary, based on Philip`_'s size of the scrollbar thumb of each page when he implemented the splitter a few years ago, plus a few tweaks since

[02:26:57.0000] <JakeA>
Ahh ok, gotcha. Didn't realise it was automated like that

[02:48:18.0000] <Ms2ger>
karlcow, :)

[02:49:06.0000] <zcorpan>
JakeA: it's always possible to tweak the splits if they're suboptimal, though i'm not sure who maintains it now

[03:12:01.0000] <Ms2ger>
zcorpan, does anybody spec things like UIEvent.layerX?

[03:13:19.0000] <zcorpan>
Ms2ger: don't see it in dom3events or uievents

[03:13:28.0000] <zcorpan>
Ms2ger: what does it do?

[03:13:57.0000] <Ms2ger>
No idea, I noticed it in IDL that Servo copied from Gecko

[03:40:38.0000] <zcorpan>
i sense that goto fail; is the new meme

[03:41:12.0000] <MikeSmith>
heh

[04:03:05.0000] <JakeA>
The DOMContentLoaded event bubbles, anyone know why?

[04:19:59.0000] <zcorpan>
JakeA: probably because that's what gecko (or whoever was first) implemented

[04:27:41.0000] <JakeA>
zcorpan: oh yeah, it does bubble window, didn't realise that

[05:08:19.0000] <ondras>
so, who is the Custom Elements guru here?

[05:08:36.0000] <ondras>
why is there the "is" attribute for custom elements that use the "extends" clause?

[07:11:03.0000] <JakeA>
Been playing around with the idea of pseudo-classes to hide content that hasn't fully parsed/loaded https://docs.google.com/document/d/1qUAI7BGEAMYh6aNq3NGW2BlI6hNhg4_tKLhL_VsiRqU/edit

[07:11:31.0000] <JakeA>
Hoping it'll be an alternative to html imports render-blocking by default

[07:16:33.0000] <bblfish>
hi, I just posted a mail on keygen, if anyone has any questions on it

[07:16:47.0000] <Ms2ger>
"RDF 1.1 is a W3C Recommendation"

[07:16:52.0000] <Ms2ger>
WHAT YEAR IS IT?!

[07:19:59.0000] <bblfish>
well application/pkix-cert does not seem to work on Chrome for the returned X509 certificate

[07:23:56.0000] <MikeSmith>
bblfish: saw your message but haven't read it yet. I think you'll have a serious uphill battle trying to convince people we should use keygen for anything new

[07:24:01.0000] <bblfish>
keygen works very well

[07:24:14.0000] <MikeSmith>
ok I guess I'll just wish you luck then

[07:24:21.0000] <bblfish>
And Client Side Certificates can be very useful for helping us leave the space of centralised services https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html

[07:24:26.0000] <bblfish>
It's just not widely known how to use them to avoid CAs

[07:27:10.0000] <bblfish>
anyway, all that's missing in the spec is the specification of the mime type  application/x-x509-user-cert since I did not find that in IANA, and that seems to be used in each browser

[08:33:45.0000] <jernoble|laptop>
ericc: g'morning!

[09:51:03.0000] <jcgregorio>
good morning dglazkov !

[09:51:05.0000] <dglazkov>
good morning, Whatwg!

[09:51:14.0000] <dglazkov>
whoa

[09:51:23.0000] <jcgregorio>
/me 0/

[09:54:17.0000] <Hixie>
if i do a bing search for [hixie tests adhoc html frames iframes], the first hit is:

[09:54:20.0000] <Hixie>
HTML Frames: absolute parent.frames['top'].location.href

[09:54:22.0000] <Hixie>
www.hixie.ch/tests/adhoc/html/frames/004.html

[09:54:25.0000] <Hixie>
pass.

[09:54:33.0000] <Hixie>
as far as i can tell, http://hixie.ch/tests/adhoc/html/frames/iframes/004.html doesn't contain the word "pass"

[09:54:40.0000] <Hixie>
so where the heck are they getting the word "pass" from???

[09:56:45.0000] <jgraham>
if (site.host == "hixie.ch" && site.path.indexOf("/tests/") > -1) {site.summary = "pass"}, perhaps?

[09:59:10.0000] <jgraham>
Hixie: (those are different URLs FWIW)

[09:59:45.0000] <Hixie>
oh hey, so they are

[09:59:57.0000] <Hixie>
how did i miss that those urls were different

[10:00:58.0000] <Ms2ger>
/me gives Hixie a cup of coffee

[10:01:37.0000] <jgraham>
/me doesn't think that will help

[10:01:48.0000] <mathiasbynens>
should `element.id = null` result in `id="null"` or remove the `id` attribute? Safari removes, Chrome and Firefox set "null" as the attribute value

[10:01:51.0000] <jgraham>
(he will jsut give it back to you)

[10:02:00.0000] <mathiasbynens>
did this change recently?

[10:02:49.0000] <mathiasbynens>
data:text/html,<p id=x></p><script>var el = x; el.id = null; console.log(el.outerHTML)</script>

[10:03:09.0000] <Hixie>
mathiasbynens: looks to me like it should set it to "null".

[10:03:11.0000] <Hixie>
per spec, anyway

[10:03:24.0000] <Hixie>
null coerces to "null" in WebIDL

[10:03:31.0000] <Hixie>
.id is defined as reflecting

[10:03:42.0000] <Hixie>
and reflecting is defined as follows: On setting, set an attribute for the context object using the name of the attribute and the given value

[10:04:05.0000] <mathiasbynens>
thanks for confirming

[10:04:05.0000] <mathiasbynens>
/me files WebKit bug

[10:08:42.0000] <Ms2ger>
"MikeSmith: You don't need to do anything! I need to get off my ass and do something."

[10:14:58.0000] <MikeSmith>
haha wilhelm actually scribed that

[10:22:56.0000] <TabAtkins>
zcorpan: Possibly, yeah.

[10:27:11.0000] <MikeSmith>
TabAtkins: have you or the CSS WG overall considered putting "Don't use this" warnings on CSS TR drafts?

[10:27:43.0000] <TabAtkins>
Yes we have, but I haven't cared enough to overcome the inertia against making changes like that.

[10:28:03.0000] <MikeSmith>
I ask because I just noticed an implementor somebody in the WebDriver f2f citing TR versions of CSSOM and CSSOM View

[10:28:08.0000] <MikeSmith>
TabAtkins: ok

[10:28:23.0000] <MikeSmith>
yeah I figured that was why

[10:29:00.0000] <SimonSapin>
FWIW, https://github.com/mozilla/servo/wiki/Relevant-spec-links may be useful outside of Servo

[10:29:08.0000] <Ms2ger>
Inertia at the CSSWG?

[10:29:13.0000] <Ms2ger>
Who'd have thought

[10:29:44.0000] <SimonSapin>
Ms2ger: inertia for for making changes to anything on /TR

[10:29:48.0000] <TabAtkins>
It's almost like we're a mature W3C group, and filled with a decent number of people who are scared of living standards.

[10:30:02.0000] <MikeSmith>
SimonSapin: btw for some reason I thought you were co-editing CSSOM

[10:30:07.0000] <TabAtkins>
SimonSapin: Specifically, making *negative-sounding* changes to anything on /TR.

[10:30:15.0000] <Ms2ger>
Heh, mature

[10:30:36.0000] <MikeSmith>
I like how you put the implied scare quotes around the word mature there

[10:31:27.0000] <SimonSapin>
MikeSmith: I’m not, though I did make an edit once after zcorpan’s +1

[10:31:28.0000] <TabAtkins>
"Mature" meaning "crotchety", in my case.

[10:33:31.0000] <MikeSmith>
SimonSapin: you editing something though I thought

[10:33:42.0000] <SimonSapin>
Syntax ?

[10:33:50.0000] <MikeSmith>
ah yeah that

[10:34:19.0000] <SimonSapin>
and Paged Media, though not really since I left Kozea

[10:35:01.0000] <MikeSmith>
OK

[10:35:32.0000] <Domenic_>
SimonSapin: that servo page is amazing.

[10:35:49.0000] <MikeSmith>
man I need HTML Imports and friends so that I can create a Fugly Warning component and easilty add it to tons of documents in TR

[10:36:39.0000] <jgraham>
TabAtkins: Those people are just the ones who need to see that real downstream users of CSS are having to route around the damage the WG is causing

[10:37:02.0000] <MikeSmith>
maybe we should just get the IP ranges for all browser vendors and just block all those from access to /TR

[10:37:03.0000] <TabAtkins>
jgraham: It's been stated.  Some of them *cough*Bert*cough* don't care.

[10:37:15.0000] <jgraham>
So those people should be ignored

[10:37:17.0000] <TabAtkins>
MikeSmith: That would be a pretty wonderful idea.

[10:37:35.0000] <Ms2ger>
MikeSmith, sounds difficult for Mozilla

[10:37:39.0000] <TabAtkins>
jgraham: Yeah, so let's go back to the "mature W3C group" part, and how it's hard to deal with politics.

[10:38:12.0000] <Ms2ger>
MikeSmith, why not block access to TR for everyone except Sofia-Antipolis?

[10:38:18.0000] <jgraham>
Well if their response is "fuck you" it's not politics, it's childishness

[10:38:38.0000] <TabAtkins>
Yes.

[10:38:50.0000] <TabAtkins>
But hey, they're employees.

[10:38:57.0000] <Ms2ger>
And we're back to my scare quotes

[10:38:57.0000] <jgraham>
Why not just take down TR and then tell anyone who complains to get over themselves

[10:39:22.0000] <MikeSmith>
I added fugly to the WebDriver spec at least, just now http://www.w3.org/TR/webdriver/

[10:39:26.0000] <TabAtkins>
There's the ongoing effort (that's getting close to completion, I think?) to make /TR show the ED if the editors opt into it.

[10:39:36.0000] <Ms2ger>
Har har har

[10:40:49.0000] <MikeSmith>
it's nice to have some WGs where I can just do stuff without anybody complaining

[10:41:13.0000] <MikeSmith>
like the WebDriver WG aka Browser Tools and Testing

[10:41:24.0000] <jgraham>
TabAtkins: Opt-in sounds awful. It just makes the problem inconsistent so that people don't learn there's an issue and then trip up

[10:41:46.0000] <MikeSmith>
because everybody in that WG is basically sane and focused on actually working on stuff

[10:42:08.0000] <Ms2ger>
MikeSmith, I guess it must be an "immature" group

[10:42:09.0000] <jgraham>
/me disputes "sane"

[10:42:11.0000] <TabAtkins>
On the other hand, it's a good way to sneak that shit in without people blowing up, and then once it's established, you can make it mandatory.

[10:42:26.0000] <Ms2ger>
jgraham, well, let's just ignore AutomatedTester :)

[10:43:05.0000] <TabAtkins>
Like we did with making groups public.  Optional, but gradually nearly everyone become open.  I think maybe all groups are open now?  (Or maybe there's still a few a11y cobwebs that are closed.)

[10:44:39.0000] <jgraham>
Making groups open didn't really have any potential for hidden traps though

[10:44:49.0000] <jgraham>
Either a group was open or it was closed

[10:44:58.0000] <MikeSmith>
CSS WG needs a crazy staff contact who people are afraid of, afraid to cross. who just does the right thing and then goes on vacation and nobody can figure out how to unwind the stuff he did (like add a Fugly Component to all CSS WG TRs in some obfuscated way)

[10:45:10.0000] <MikeSmith>
hmm I have a feature request for dglazkov

[10:45:11.0000] <TabAtkins>
MikeSmith: Be our father figure, please?

[10:45:18.0000] <TabAtkins>
Or dglazkov, yeah.

[10:45:22.0000] <TabAtkins>
I'm too chummy to do it.

[10:45:43.0000] <Ms2ger>
MikeSmith, Bert?

[10:45:53.0000] <TabAtkins>
You forgot "does the right thing"

[10:46:00.0000] <MikeSmith>
no comment

[10:46:05.0000] <Ms2ger>
Maybe he thinks he does the right thing?

[10:46:06.0000] <MikeSmith>
I'm not here

[10:46:15.0000] <TabAtkins>
Oh, he definitely *thinks* he does.

[10:46:21.0000] <Ms2ger>
MikeSmith, rather I moved the conversation to #testing?

[10:47:43.0000] <MikeSmith>
I'm only here to get dglazkov to spec my mechanism for Secret HTML Imports for adding components to documents in such a way that when you go on vacation nobody else can figure out how to remove them

[10:47:58.0000] <MikeSmith>
Ms2ger: we're going through a open bug list here

[10:48:07.0000] <Ms2ger>
Hack into apache

[10:48:11.0000] <MikeSmith>
which is like listening to nails on the chalkboard

[10:48:20.0000] <Ms2ger>
Or better

[10:48:40.0000] <Ms2ger>
Install wptserve on w3.org and pass everything except TR/css-* requests to apache

[10:49:28.0000] <MikeSmith>
that'd be good

[10:49:47.0000] <MikeSmith>
good way for us to test how wptserve works under load at least

[10:50:24.0000] <ondras>
14:08 < ondras> so, who is the Custom Elements guru here?

[10:50:24.0000] <ondras>
14:08 < ondras> why is there the "is" attribute for custom elements that use the "extends" clause?

[10:51:19.0000] <jgraham>
MikeSmith: "works"

[10:51:26.0000] <MikeSmith>
heh

[10:52:23.0000] <MikeSmith>
ondras: you need to get some attention from dglazkov

[10:54:18.0000] <ondras>
MikeSmith: ok thanks

[10:54:21.0000] <ondras>
dglazkov: ? :)

[10:55:16.0000] <ondras>
dglazkov: why <button is="my-button"> instead of just <my-button>? is there some advantage in the former?

[10:56:50.0000] <Ms2ger>
Fallback

[10:56:53.0000] <Ms2ger>
Accessibility

[10:56:58.0000] <Ms2ger>
Semantics

[10:57:22.0000] <ondras>
I do not see any of those. :-)

[10:57:30.0000] <ondras>
<my-button> is also available, right?

[10:57:41.0000] <Ms2ger>
Maybe

[10:57:44.0000] <ondras>
why shall I prefer the "is" version then?

[10:57:45.0000] <Ms2ger>
It shouldn't be

[10:57:49.0000] <Ms2ger>
<Ms2ger> Fallback

[10:57:50.0000] <Ms2ger>
<Ms2ger> Accessibility

[10:57:50.0000] <Ms2ger>
<Ms2ger> Semantics

[10:58:44.0000] <ondras>
so if I do registerElement("my-button-1"), I can do <my-button-1>; when I registerElement("my-button-2", {extend:Button}), I am limited to <button is="my-button-2">

[10:58:51.0000] <ondras>
looks highly illogical to me.

[11:00:23.0000] <jgraham>
ondras: Why would you want to make a button that a non-web-components UA, or an AT, treats like a plain <div> rather than like a <button>?

[11:01:26.0000] <ondras>
jgraham: because I find it straightforward that registerElement("x") implies <x>

[11:01:40.0000] <ondras>
which is true

[11:01:42.0000] <ondras>
in *some* cases

[11:02:02.0000] <ondras>
but when I pass one very special additional argument to registerElement

[11:02:07.0000] <ondras>
I suddenly cannot do <x>

[11:02:26.0000] <ondras>
from a purely API view, this looks truly strange.

[11:02:34.0000] <jgraham>
ondras: what do you think a UA will do with a <my-button> element?

[11:03:00.0000] <ondras>
jgraham: I have no idea. Shall I be interested in that?

[11:03:09.0000] <ondras>
my aim is to create a custom element that does some stuff

[11:03:14.0000] <ondras>
I am not sure what it does right now

[11:03:24.0000] <ondras>
but one day, someone will require some functionality

[11:03:26.0000] <jgraham>
ondras: Presumably your aim is to deliver some content to web users

[11:03:30.0000] <ondras>
preferrably.

[11:03:49.0000] <jgraham>
In which case it makes sense to worry about how their UA will treat your content

[11:03:58.0000] <ondras>
probably according to the spec?

[11:04:31.0000] <tobie>
tbh, I understand the background for the is="foo" notation, but my first reaction to this was WTF.

[11:04:37.0000] <ondras>
hmh.

[11:04:46.0000] <ondras>
well I probably need some time to understand the reasons

[11:04:56.0000] <Ms2ger>
tobie, that's my first reaction to most of the web

[11:04:59.0000] <ondras>
what if I want to extend my-button that already extends button?

[11:05:01.0000] <tobie>
heh

[11:05:16.0000] <jamesr__>
Hixie: the 'compound microtask' concept seems to be unnecessary

[11:05:20.0000] <ondras>
<button is="my-button-2"> or <my-button is="my-button-2"> ?

[11:05:22.0000] <jgraham>
ondras: In a UA that doesn't support web-components, what will happen if you write <my-button>?

[11:05:36.0000] <ondras>
jgraham: it will be treated as <div>, I guess

[11:05:41.0000] <tobie>
jgraham: that's implementation specific

[11:05:47.0000] <Ms2ger>
tobie, wat

[11:05:55.0000] <Hixie>
jamesr__: only in a UA that doesn't support showModalDialog(). While I'm all for that, so far we haven't proved it's possible to drop it, and other UAs have indicated that they want to support it, including in microtasks.

[11:06:06.0000] <Ms2ger>
tobie, you're aware we're in the standardization business here?

[11:06:11.0000] <jgraham>
tobie: No it isn't

[11:06:14.0000] <ondras>
:P

[11:06:18.0000] <jgraham>
ondras: Pretty much, yeah

[11:06:30.0000] <tobie>
old IE won't let you style the element at all, afaik

[11:06:32.0000] <ondras>
jgraham: the same applies to <my-calendar> that does not extend anything

[11:06:34.0000] <Hixie>
(more like <span>, actually)

[11:06:55.0000] <jamesr__>
Hixie: even in a UA that supports showModalDialog

[11:06:56.0000] <jgraham>
ondras: Well ideally that could extend input type=datetime

[11:07:05.0000] <jgraham>
Not sure if that's possible or not though

[11:07:13.0000] <ondras>
jgraham: there are surely cases where I do not extend. or is that not desirable at all?

[11:07:13.0000] <jamesr__>
a better spin-the-event-loop definition would fix it too

[11:07:35.0000] <ondras>
jgraham: if the non-extend variant was banished, *that* would make sense to me.

[11:07:51.0000] <jgraham>
ondras: If you are creating a better version of a control that has native HTML sematics it's always better to extend

[11:07:51.0000] <ondras>
but having and not having <x> based on whether it extends something... weird.

[11:07:54.0000] <Ms2ger>
That would make a lot of sense to me too

[11:07:56.0000] <Hixie>
jamesr__: please file a bug with a concrete proposal. i don't see any other way to do it that satisfies all the constraints, but i'm happy to consider one if one exists.

[11:08:33.0000] <jgraham>
It makes it much more likely that your page will work in down-rev browsers, in assistive technologies and so on

[11:09:03.0000] <Hixie>
always having to extend would make sense to me too, but extending <span> is kinda pointless, and that's what a lot of components would end up having to do, in practice

[11:09:32.0000] <tobie>
jgraham: : I'm not suggesting this is intentionally left to be impl. specific--just that older IE won't even treat is as a regular div unless you use the document.createElement('foo') trick.

[11:10:03.0000] <jgraham>
tobie: Isn't that quite old IE now?

[11:10:13.0000] <tobie>
fair enough.

[11:10:59.0000] <ondras>
IE8?

[11:11:01.0000] <ondras>
it is old

[11:11:08.0000] <ondras>
but still about 20% here in .cz.

[11:11:41.0000] <ondras>
I see that extending <span> is pointless, but the complete API divergence re. <x> vs. <stuff is="x"> is so strikingly strange

[11:12:05.0000] <ondras>
either the goal *is* to introduce custom elements, or it is not

[11:12:44.0000] <Hixie>
(is there really much divergence? i would expect the former to basically just be syntactic sugar for <span is="x">)

[11:12:44.0000] <ondras>
perhaps the goal is to confuse developers by introducing a puzzling api? :)

[11:13:11.0000] <ondras>
Hixie: *if* <my-button> was allowed (and recommended) as well

[11:13:19.0000] <ondras>
Hixie: so these two variants were freely interchangeable

[11:13:28.0000] <ondras>
and one would pick the one that fits his compatibility needs

[11:13:30.0000] <jgraham>
The goal was to make the right thing easy and all things possible. The API ended up making the right thing hard :(

[11:14:24.0000] <ondras>
to me, this looks like a clear message "do not try to make custom elements; extend instead"

[11:14:37.0000] <Hixie>
jgraham and ondras seem to be saying opposite things

[11:14:57.0000] <ondras>
(which can be also read as "the burden of backward compatibility will haunt you, the developer, forever)

[11:15:01.0000] <Hixie>
but i'm confused as to why there's much difference at all

[11:15:17.0000] <Hixie>
extending is definitely better, if there's an appropriate element

[11:15:37.0000] <jgraham>
Yeah. I'm not sure why you think that <x-foo> is harder than <span is="x-foo">

[11:15:45.0000] <ondras>
better w.r.t. non-customelement UAs?

[11:16:22.0000] <Hixie>
better with respect to any UA. e.g. a web-componenents UA, when the web component files start 404ing.

[11:16:35.0000] <Hixie>
better w.r.t. search engines

[11:16:41.0000] <Hixie>
better w.r.t. downlevel clients

[11:16:59.0000] <Hixie>
better w.r.t. authors new to the widget library

[11:17:07.0000] <ondras>
okay. so when extending is better, I see no point in <x-foo>

[11:19:22.0000] <tobie>
irc the JS API kind of make <x-foo> the expected markup, rather than <div is=x-foo>

[11:19:45.0000] <Hixie>
ondras: sometimes, there's nothing appropriate to extend.

[11:19:58.0000] <Hixie>
ondras: e.g. what would you extend if you wanted to make a chess board container?

[11:20:28.0000] <TabAtkins>
<x-foo> looks way better in the markup than <div is=x-foo>, and is easier to construct in JS.  Has a lot of benefits.

[11:20:28.0000] <Hixie>
ondras: or a chess piece?

[11:20:29.0000] <jgraham>
I thought it was basically that people didn't like the extra keystrokes and (probably) planned to sell out all the cases where extending is better to make their code a bit prettier

[11:21:11.0000] <Hixie>
yes, the real reason people are pushing non-extended elements is that they think it's prettier and they don't care about all the things i said above

[11:21:13.0000] <tobie>
How do selectors handle these?

[11:21:14.0000] <Hixie>
which is lame

[11:21:39.0000] <Hixie>
(but my point above is just that even if the main people pushing this have lame reasons, there are also good reasons)

[11:21:48.0000] <Hixie>
(so the lame reasons are moot)

[11:22:33.0000] <tobie>
E.g. when you do doc.querySelectorAll("x-foo"), does it also return <div is=x-foo>?

[11:26:44.0000] <ondras>
Hixie: for something completely new, I would expect an <element is="chess-piece"> or something

[11:26:57.0000] <ondras>
for the sake of consistency with <button is="my-button">

[11:26:58.0000] <Hixie>
why is that better than <chess-piece> ?

[11:27:06.0000] <Hixie>
for consistency with <button> ?

[11:27:14.0000] <ondras>
Hixie: I thought you already outlined the reasons

[11:27:20.0000] <ondras>
20:16 < Hixie> better w.r.t. search engines

[11:27:21.0000] <ondras>
20:16 < Hixie> better w.r.t. downlevel clients

[11:27:21.0000] <ondras>
20:17 < Hixie> better w.r.t. authors new to the widget library

[11:27:22.0000] <Hixie>
the reasons i gave don't apply here

[11:28:05.0000] <Hixie>
<element is="chess-piece"> and <chess-piece> are identical in all ways except syntax, as far as search engines, down-level clients, unfamiliar authors, etc, go.

[11:28:08.0000] <ondras>
also, how does the "extends" and "prototype" mix together? is it not sufficient to use only "prototype" ?

[11:28:37.0000] <ondras>
Hixie: right. but <button is="my-button"> and <my-button> are not, right?

[11:28:43.0000] <Hixie>
(can anyone test IE for me on http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2845 ? what does the log say?)

[11:28:46.0000] <Hixie>
ondras: right

[11:28:54.0000] <ondras>
and that puzzles me.

[11:29:21.0000] <ondras>
because you offer two ways of doing the same stuff (<e is="chess">, <chess>)

[11:29:23.0000] <ondras>
which is okay

[11:29:25.0000] <Hixie>
a better way to put it is <button is="zzz-zzz"> and <zzz-zzz> are different, but <zzz is="zzz-zzz"> and <zzz-zzz> are the same.

[11:29:30.0000] <ondras>
but you forbid one of them in a different context

[11:29:53.0000] <Hixie>
the difference is that the first (<button is="zzz-zzz">) has a well-understood value, plus the custom value.

[11:30:02.0000] <Hixie>
whereas the second has nothing well-understood.

[11:30:23.0000] <Hixie>
(nor the third, nor the fourth)

[11:31:06.0000] <ondras>
my interest, as a web developer (and teacher), is what version shall I ideally use

[11:31:35.0000] <Hixie>
if you are extending an existing element, is="". otherwise, not is="".

[11:31:55.0000] <ondras>
the recommendation of using <my-chessboard> along with <button is="my-chess-clock-button"> simply looks inconsistent

[11:31:58.0000] <ondras>
that's all.

[11:32:19.0000] <ondras>
20:28 < ondras> also, how does the "extends" and "prototype" mix together? is it not sufficient to use only "prototype" ?

[11:32:47.0000] <ondras>
i.e. registerElement("my-button", {prototype:Object.create(Button.prototype)})

[11:33:03.0000] <ondras>
somehow implies that I am extending the HTMLButtonElement

[11:33:08.0000] <ondras>
or how the hell is it called.

[11:36:44.0000] <tobie>
it is extending it.

[11:55:22.0000] <ondras>
tobie: ?

[11:55:27.0000] <ondras>
tobie: I am not sure I understood

[11:57:57.0000] <tobie>
Well, as far as I understand, registerElement("my-button", {prototype:Object.create(Button.prototype)}) makes <my-button> and <button is=my-button> strictly identical in all but old browsers.

[11:59:13.0000] <ondras>
tobie: right. so why use registerElement("my-button", {extends:HTMLButtonElement}) ?

[11:59:40.0000] <tobie>
does that exist too?

[12:02:23.0000] <ondras>
tobie: yes; when you extend stuff, you have to specify the "extends" clause in the registerElement descriptor.

[12:03:18.0000] <MikeSmith>
oh

[12:04:14.0000] <ondras>
which reminds me... what if the prototype/extends does not strictly match the localName of the "is" element?

[12:04:17.0000] <ondras>
as in

[12:04:33.0000] <ondras>
<button is="my-button">, registerElement("my-button", {prototype/extends: span})

[12:05:37.0000] <MikeSmith>
just syntax?

[12:05:37.0000] <MikeSmith>
conve

[12:06:52.0000] <MikeSmith>
(that was in reply to earlier comment)

[12:07:03.0000] <tobie>
"conve" was?

[12:07:09.0000] <MikeSmith>
convenience

[12:07:16.0000] <MikeSmith>
I meant

[12:07:38.0000] <MikeSmith>
wifi here at Mozilla office seems not terrifically stable

[12:07:58.0000] <tobie>
MikeSmith: which office?

[12:08:15.0000] <MikeSmith>
and I'm on IRC in a persistent screen session so I drop off and some text may be buffered (or something)

[12:08:21.0000] <tobie>
Are you at the Testing F2F?

[12:08:24.0000] <MikeSmith>
tobie:yeah

[12:08:32.0000] <MikeSmith>
SF

[12:08:36.0000] <tobie>
Say hi to all these nice folks.

[12:08:39.0000] <MikeSmith>
the office by the Bay Bridge

[12:08:42.0000] <MikeSmith>
certainly will

[12:08:46.0000] <tobie>
ty

[12:09:06.0000] <wilhelm>
/me waves to tobie

[12:09:10.0000] <tobie>
hey

[12:10:54.0000] <Ms2ger>
MikeSmith, on the guest wifi? :)

[12:13:55.0000] <MikeSmith>
Ms2ger: yeah

[12:15:12.0000] <MikeSmith>
which by "guest" I guess it means it makes it de-guests you now and then so you can then enjoy the hospitality of getting re-guested anew often

[12:16:17.0000] <Ms2ger>
"Haven't you been on our couch for long enough now?"

[12:18:32.0000] <MikeSmith>
heh

[12:22:32.0000] <ondras>
a-ha

[12:22:50.0000] <ondras>
it looks like extends:"button" is the *only* way to enable <button is="my-button">

[12:23:05.0000] <ondras>
otherwise I would be limited to the (not recommended) <my-button> syntax

[12:23:18.0000] <ondras>
although my-button inherits (prototype-wise) from HTMLButtonElement

[12:23:31.0000] <ondras>
http://www.polymer-project.org/platform/custom-elements.html

[12:43:29.0000] <MikeSmith>
ondras: oh so there is a difference

[12:43:33.0000] <ondras>
MikeSmith: apparently. this stuff is rather complicated, I would say.

[12:43:44.0000] <tobie>
Yeah. The cognitive burden is huge. But that's OK because the rest of the platform is super consistant.

[12:44:18.0000] <tobie>
</sarcasm>

[12:44:21.0000] <ondras>
.)

[13:01:46.0000] <smaug____>
dglazkov: yeah, I should get back to that bug, but there were other event propagation changes too, IIRC

[13:01:55.0000] <smaug____>
something to do with multiple shadow roots

[13:02:03.0000] <smaug____>
/me tries to find that

[13:04:52.0000] <smaug____>
dglazkov: one problem is that I haven't see any real world case needing the current behavior

[13:04:56.0000] <smaug____>
perhaps I'm missing something

[13:05:18.0000] <smaug____>
but unless there isn't any real world case, we shouldn't complicate event propagation

[13:28:29.0000] <Domenic_>
I anticipate nobody using is="" because it's too ugly and inconvenient.

[13:29:23.0000] <Domenic_>
If possible I would make <my-button> via document.registerElement("my-button", { prototype: HTMLButtonElement.prototype }) have the same UA benefits as <button is="my-button"> via document.registerElement("my-button", { extends: "button" })

[13:29:38.0000] <Domenic_>
obviously not the same UA benefits for downlevel browsers

[13:29:53.0000] <Domenic_>
but i think custom-element--using authors are not going to try very hard to make their stuff work there

[13:30:50.0000] <Domenic_>
TabAtkins: http://dev.w3.org/csswg/css-font-load-events/ 404s?

[13:30:57.0000] <TabAtkins>
css-font-loading

[13:31:06.0000] <TabAtkins>
Moved as part of the FPWD.

[13:32:19.0000] <Domenic_>
TabAtkins: I don't quite understand why people don't like .ready(); it seems pretty distinct from .load().

[13:32:37.0000] <TabAtkins>
There's not really a need for .ready() separate from .load().

[13:33:00.0000] <Domenic_>
it does give you new capabilities though, right? The ability to get notified upon loading, without actually doing the loading.

[13:33:03.0000] <TabAtkins>
Either you just want to check on the font, in which case you use .status, or you want to make sure it's loaded, in which case you call .load() regardless.

[13:33:27.0000] <Domenic_>
ok, so the idea is that getting notified upon loading without initiating loading is not a useful use case.

[13:33:43.0000] <TabAtkins>
I think so, yeah.

[13:33:52.0000] <Domenic_>
personally .load() + .loaded would make the most sense, but IIRC you can "re-load" or something so a property doesn't work...

[13:34:01.0000] <TabAtkins>
Nah, can't reload.

[13:34:11.0000] <MikeSmith>
wilhelm: are you using the Guest wifi in the f2f?

[13:34:32.0000] <Domenic_>
oh, then why is .ready() currently a property?

[13:34:33.0000] <wilhelm>
MikeSmith: Yes.

[13:34:47.0000] <TabAtkins>
Domenic_: ?_?

[13:34:59.0000] <Domenic_>
TabAtkins: err sorry, currently a method I meant

[13:35:09.0000] <wilhelm>
MikeSmith: "Mozilla Guest".

[13:35:13.0000] <TabAtkins>
Because that's usually how it works?

[13:36:20.0000] <Domenic_>
TabAtkins: I dunno, [citation needed]? maybe in jQuery, but they never use properties for anything. Getter or data property makes most sense to me.

[13:36:26.0000] <Domenic_>
Sigh, we need data properties.

[13:36:43.0000] <TabAtkins>
data properties?

[13:36:50.0000] <Domenic_>
non-accessors in WebIDL

[13:37:09.0000] <TabAtkins>
Still not understanding.

[13:37:36.0000] <MikeSmith>
wilhelm: yeah I get dropped pretty often for some reason

[13:37:37.0000] <Domenic_>
I am going off the rails, sorry. But: I am saying that IMO the most reasonable thing for .loaded would be as a data property. Whereas WebIDL would force it to be a getter.

[13:37:58.0000] <TabAtkins>
Still dont' know what "data property" means, so I cant' comment.

[13:38:19.0000] <Domenic_>
defineProperty(FontFaceSet.prototype, { value: readyPromise }) vs. defineProperty(FontFaceSet.prototype, { get() { return readyPromise; } })

[13:38:43.0000] <Domenic_>
err

[13:38:59.0000] <Domenic_>
you wouldn't put it on the prototype. nevermind, ignore me.

[13:39:19.0000] <TabAtkins>
Okay. ^_^


2014-02-26
[23:03:20.0000] <zcorpan>
TabAtkins: what is the use case for selecting all attributes?

[02:26:06.0000] <zcorpan>
http://html5.org/tools/web-apps-tracker?from=8510&to=8511 what a lovely typo

[02:31:18.0000] <MikeSmith>
hah yeah

[04:15:41.0000] <hsivonen>
I just realized that Latvian Firefox and Lithuanian Mac/Linux Firefox ship with a fallback that's not even in the menu in IE11.

[04:25:12.0000] <hsivonen>
and for Romanian, Firefox, Chrome and IE all have different fallbacks

[04:26:24.0000] <Ms2ger>
Should ask the [qa-] people

[04:29:30.0000] <Ms2ger>
zcorpan_, thanks a lot for all the reviews, btw

[04:30:03.0000] <zcorpan_>
Ms2ger: welcome

[04:30:45.0000] <zcorpan_>
did we have a convention for helper .html files? put in resources/ ?

[04:31:06.0000] <Ms2ger>
I don't think we have one

[04:31:10.0000] <jgraham>
zcorpan_: No, but resources is quite common

[04:31:25.0000] <jgraham>
There isn't a need for such a convention

[04:31:40.0000] <jgraham>
(except consistency for humans)

[04:31:54.0000] <zcorpan_>
oh, the runner figures it out anyway?

[04:32:44.0000] <Ms2ger>
As long as they don't include th.js

[04:32:50.0000] <jgraham>
Yeah, a helper file is anything that doesn't link to testharness.js, specify a reference url, or have -manual in the name

[04:32:55.0000] <jgraham>
(roughly)

[04:33:00.0000] <zcorpan_>
ok

[04:33:46.0000] <Ms2ger>
So the Scooby Doo algorithm, basically

[04:43:08.0000] <MikeSmith>
sigh https://github.com/h5bp/mobile-boilerplate/wiki/The-Markup#wiki-mobile-viewport-optimization

[04:44:16.0000] <MikeSmith>
I guess <meta name="HandheldFriendly" content="True"> and <meta name="MobileOptimized" content="320"> are in every HTML document on the Web that uses html5boilerplate as a template

[04:44:30.0000] <MikeSmith>
along with other winners such as <meta http-equiv="cleartype" content="on"

[04:45:46.0000] <MikeSmith>
*mobile version of html5boilerplate

[04:51:57.0000] <MikeSmith>
jgraham: you're saying that the testrunner figures that out programatically?

[04:52:04.0000] <zcorpan_>
MikeSmith: file a bug on h5bp?

[04:52:17.0000] <MikeSmith>
jgraham: "doesn't link to testharness.js, specify a reference url, or have -manual in the name" I mean

[04:52:45.0000] <zcorpan_>
MikeSmith: it uses voodoo. yama yama yama yama yama...

[04:53:15.0000] <jgraham>
MikeSmith: Yes, that's what I'm saying

[04:53:16.0000] <MikeSmith>
zcorpan_: I should file a bug on that but I don't want to invest the time needed to follow up with it

[04:53:23.0000] <MikeSmith>
nice

[04:53:54.0000] <jgraham>
Well specifically the code for generating a manifest figures it out programatically

[04:54:03.0000] <zcorpan_>
MikeSmith: feel free to cc me

[04:55:37.0000] <MikeSmith>
jgraham: so that allows the testrunner to ignore the whole conformance-checkers tree. Which is good. But there are about 1300 HTML files in there so maybe it should have some other way to flag that while tree as "ignore" (if it doesn't already)

[04:55:45.0000] <MikeSmith>
zcorpan_: OK

[04:57:11.0000] <jgraham>
MikeSmith: There is a blacklist of directories, it would be easy to add conformance-checkers to that

[04:57:37.0000] <MikeSmith>
ok

[04:57:53.0000] <MikeSmith>
I will make a PR to add it then I guess

[04:58:26.0000] <MikeSmith>
because there are no real test in there

[04:58:37.0000] <MikeSmith>
well, not browser tests

[04:59:07.0000] <jgraham>
Thanks

[05:00:59.0000] <MikeSmith>
in other news I am finding that http://mosh.mit.edu/ is indeed pretty great

[05:01:40.0000] <MikeSmith>
for, e.g., when you need to ssh and you're on flaky wifi

[05:03:03.0000] <Ms2ger>
/me read mosh.pit.edu

[05:03:36.0000] <MikeSmith>
heh

[05:04:59.0000] <MikeSmith>
well it's nice when you, say, are forced to scribe a f2f meeting and you also have to use the "Mozilla Guest" wifi network that drops out every 17 minutes or so

[05:06:17.0000] <Ms2ger>
At that point, you make a Mozillian scribe :)

[05:07:11.0000] <MikeSmith>
hmm yeah I like that plan better

[05:07:30.0000] <jgraham>
If it's anything like Mozilla-London, that WiFi probably (unintentionally) provides the "free wifi" for the cafe next door

[05:09:13.0000] <MikeSmith>
ah

[05:09:15.0000] <zcorpan_>
anyone want to defend insertAdjacentHTML? (eseidel suggested removing it from blink along with the other two insert*)

[05:09:42.0000] <hsivonen>
jgraham: I thought it was intentional.

[05:09:45.0000] <zcorpan_>
miketaylr: can you grep for "insertAdjacent(Text|HTML|Element)" ? :-)

[05:10:17.0000] <MikeSmith>
zcorpan_: huh I thought that was used in Web content and performed pretty fast now

[05:10:26.0000] <Ms2ger>
zcorpan_, *HTML is widely implemented, unlike the others

[05:10:32.0000] <jgraham>
hsivonen: Well I meant "unintentional" in the sense that we don't have a specific deal to provide free wifi, as far as I know

[05:10:40.0000] <jgraham>
It's just that the signal reaches

[05:10:41.0000] <Ms2ger>
And I think sicking liked it to wean people off innerHTML +=

[05:10:55.0000] <MikeSmith>
zcorpan_: https://twitter.com/html5/status/134485735024762880

[05:11:04.0000] <zcorpan_>
MikeSmith: *HTML is 0.036% of page views apparently

[05:11:17.0000] <MikeSmith>
wow

[05:11:24.0000] <MikeSmith>
well seems like people should use it more

[05:11:28.0000] <wilhelm>
MikeSmith: Oh, I haven't tried that one yet.

[05:11:29.0000] <MikeSmith>
what Ms2ger said

[05:11:38.0000] <MikeSmith>
wilhelm: mosh?

[05:11:39.0000] <jgraham>
That seems like quite a lot?

[05:11:43.0000] <wilhelm>
Yes.

[05:11:43.0000] <Ms2ger>
Also, I'm interested in -moz-grid, in case anybody has data

[05:12:13.0000] <zcorpan_>
ok i'll put a word for *HTML

[05:12:32.0000] <MikeSmith>
wilhelm: it seems to works as advertised. There's a android SSH client, JuiceSSH, that supports it too

[05:13:14.0000] <hsivonen>
jgraham: ok

[05:13:27.0000] <MikeSmith>
zcorpan_: see also https://hacks.mozilla.org/2011/11/insertadjacenthtml-enables-faster-html-snippet-injection/ from hsivonen

[05:14:27.0000] <MikeSmith>
/me oh that's the same reference as the twitter one I see

[05:15:07.0000] <hsivonen>
Surely Blink isn't seriously considering removing insertAdjacentHTML to improve mobile performance?

[05:15:34.0000] <MikeSmith>
they seem to be going a little overboard with the remove all the things frenzy

[05:15:53.0000] <zcorpan_>
hsivonen: no :-) more to remove legacy cruft, but i'm writing an email now arguing that *HTML should not be considered legacy cruft

[05:16:26.0000] <Ms2ger>
MikeSmith, ssh

[05:21:10.0000] <davve``>
There it not even a UseCounter for insertAdjacentHTML so it hasn't been on the table before. Probably just a misunderstanding.

[05:21:48.0000] <Ms2ger>
davve``, wait, if there is no usecounter, where did zcorpan_ get his figure from?

[05:24:37.0000] <zcorpan_>
hmmm. oh, seems i misread the email. that was for insertAdjacentElement.

[05:24:38.0000] <davve>
Ms2ger: 0.036% is insertAdjacentElement, I think.

[05:25:45.0000] <davve>
http://www.chromestatus.com/metrics/feature/timeline/popularity/141

[05:27:19.0000] <Ms2ger>
Interesting how much it drops on the weekend

[05:28:59.0000] <Ms2ger>
Oh wow, captureEvents is huge

[05:43:42.0000] <MikeSmith>
w00t I've now made 100 w-p-t commits

[05:43:54.0000] <zcorpan_>
jgraham: https://critic.hoppipolla.co.uk/r/790

[05:43:54.0000] <MikeSmith>
most of them shouldn't count but I'll take them anyway

[05:43:59.0000] <Ms2ger>
Congratulations :)

[05:44:33.0000] <MikeSmith>
Ms2ger: thanks now I have only 743 to go before I catch up with you. So watch out

[05:44:40.0000] <Ms2ger>
:D

[05:44:51.0000] <zcorpan_>
Ms2ger: how many chocolates is 100 commits?

[05:45:19.0000] <Ms2ger>
Meh, most of those shouldn't really count ;)

[05:45:44.0000] <zcorpan_>
or maybe it's lines reviewed that generates chocolate

[05:46:25.0000] <Ms2ger>
I should clearly get you some more :)

[06:29:07.0000] <zcorpan_>
i don't object to that :-D

[06:30:52.0000] <Ms2ger>
I should also get Leif Arne some

[06:51:38.0000] <miketaylr>
zcorpan: sure thing

[06:54:54.0000] <zcorpan>
neato

[07:05:09.0000] <hsivonen>
we have a new w3schools: http://www.html-5.com/tutorials/basic-html-code.html

[07:05:27.0000] <hsivonen>
unfortutely found out via a bugzilla comment complaining how Firefox handles that

[07:06:59.0000] <Ms2ger>
Wow, that page looks straight out of the early naughties

[07:09:59.0000] <wilhelm>
It puzzles me that there are real humans out there taking the time to create something like that.

[07:12:38.0000] <zcorpan>
good thing it has links to about and contact in the footer: http://www.html-5.com/about.html http://www.html-5.com/contact.html

[07:14:31.0000] <zcorpan>
"WARNING: Be careful when looking for web sites for learning HTML, especially when it comes to things that are treated differently by different browsers." http://www.htmlattributes.com

[07:17:29.0000] <wilhelm>
/me blinks.

[07:18:21.0000] <wilhelm>
So w3schools is run by a Norwegian complay with 5 employees and an annual turnover of 2.3M USD.

[07:20:11.0000] <wilhelm>
Snake oil certainly is a booming business. http://www.refsnesdata.no/certification/w3certified.asp?id=3020062

[07:24:32.0000] <MikeSmith>
it wouldn't require much more effort from them to actually make it a worthwhile site

[07:30:06.0000] <wilhelm>
It would require qualities like "good taste" and "understanding the subject matter", though.

[07:32:38.0000] <Hixie>
hsivonen: can you elaborate on the difference between ff 25 and ff 26, as far as encodings go?

[07:32:50.0000] <Hixie>
hsivonen: is 26 where you have the fallback be tld-based?

[07:33:05.0000] <Hixie>
hsivonen: and is "locale" in the table the locale of the build?

[07:34:28.0000] <Hixie>
hsivonen: also, if you could send feedback on http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0097.html that would be great

[07:48:44.0000] <hsivonen>
Hixie: no substantial difference between 25 and 26. The two mainly show how much the numbers vary between two releases without changes.

[07:48:51.0000] <hsivonen>
Hixie: locale of the build, yes

[07:49:00.0000] <Hixie>
ok, cool

[07:49:23.0000] <hsivonen>
Hixie: I'll take a look at the email hopefully in near future

[07:51:25.0000] <Hixie>
thanks

[08:21:54.0000] <TabAtkins>
zcorpan: I've done loops through all attributes in Python code before.  Useful when you can't process things by name, because the name is open-ended (like data-*).

[09:12:10.0000] <BS-Harou>
Hi, I'm looking into comments&microdata. What I found is that http://schema.org/Comment encodes the creative work by someone while http://schema.org/UserComments encodes the action event of doing a comment. Can anyone give me a real world example of when I would want to use UserComments rather than Comment? Also the Article#comment property (according to schema.org) refers to UserComments rather than Comment which seems weird. Can I jsut specify

[09:12:10.0000] <BS-Harou>
the itemtype as Comment and use CreativeWork(/Comment) itemprops instead?

[09:15:29.0000] <scor>
BS-Harou: you should ask this on http://lists.w3.org/Archives/Public/public-vocabs/ - I've been advocating to get rid of UserComments the way it's implemented now, so your feedback would be useful there

[09:26:36.0000] <BS-Harou>
thanks :)

[10:20:03.0000] <benvie>
Domenic_: I'm trying to formulate comments describing the expected results of Promise.race, but I'm not actually sure what governs the resolution order

[10:20:07.0000] <benvie>
Domenic_: https://bugzilla.mozilla.org/show_bug.cgi?id=941920#c13

[10:20:42.0000] <benvie>
how can I describe that the result of Promise.race([1, 2]) is deterministic?

[10:28:24.0000] <benvie>
Domenic_: nevermind, got it!

[10:47:50.0000] <Domenic_>
benvie: ok! :)

[11:00:52.0000] <tantek>
BS-Harou, scor, or you could ask in #schema also.

[11:37:38.0000] <benvie>
Domenic_: sorry to bother you again. Could you sanity check the order of Task Queue operations I've outlined in this comment? https://bugzilla.mozilla.org/show_bug.cgi?id=941920#c15

[11:39:22.0000] <Domenic_>
benvie: what code is that referring to?

[11:39:58.0000] <benvie>
the quotes code at the top of the comment, `let p1 = Promise.resolve(2); let p2 = Promise.resolve().then(() => 2);`

[11:40:20.0000] <benvie>
er Promise.resolve(1)

[11:40:40.0000] <Domenic_>
benvie: ah ok. in that case yeah looks right.

[11:40:46.0000] <benvie>
Domenic_: excellent, thanks!

[12:34:23.0000] <Hixie>
TabAtkins: tab order interaction with the 'order' property -- who is correct, chrome or firefox? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2850

[12:34:46.0000] <Hixie>
(chrome uses dom tree order to find the next focusable area, firefox uses rendering tree order)

[12:36:15.0000] <SamB>
/me kind of wishes there was some way to interject text between <li> in an <ol>. Unindented. Or, heck, start a new <ol>, if he could just ask that the numbering pick up where the previous appropriately-nested <ol> ...

[12:36:34.0000] <Hixie>
picking up again is something i want to do

[12:36:45.0000] <Hixie>
let me see if there's a bug one it...

[12:37:00.0000] <SamB>
Hixie: well, firefox's sounds more likely to do what the user will expect in the absense of any attention to tab order from the stylesheet author

[12:37:47.0000] <Hixie>
don't see anything on file, so if you want to track it, http://whatwg.org/newbug . But it's probably not going to happen any time soon, since even reversed="" isn't yet describable with CSS.

[12:38:01.0000] <Hixie>
(actually, maybe this would be easier than reversed="")

[12:38:35.0000] <SamB>
hmm, I'm not sure how CSS is supposed to do the counting anyway ...

[12:38:51.0000] <Hixie>
there's 'counter' properties

[12:39:02.0000] <Hixie>
re focus, i'm thinking firefox is right too...

[12:39:11.0000] <TabAtkins>
I just got in, one sec.

[12:39:40.0000] <TabAtkins>
Hixie: http://dev.w3.org/csswg/css-flexbox/#order-accessibility is clear, 'order' doesn't affect tab-order.

[12:39:59.0000] <Hixie>
oh, interesting

[12:40:26.0000] <TabAtkins>
(This was added after a rather useful review by the i18n wg.)

[12:40:38.0000] <Hixie>
i'm not sure this makes sense

[12:40:47.0000] <Hixie>
how do you write a web page that behaves sanely both with and without flex?

[12:41:09.0000] <SamB>
I knew there was a reason I worded it the way I did ;-)

[12:41:27.0000] <TabAtkins>
Write it with a sane ordering in the raw markup, and then use flexbox as necessary to re-order things visually.

[12:41:40.0000] <SamB>
TabAtkins: well, how do you keep the USER sane

[12:41:41.0000] <Hixie>
right but you want the tab order to follow the visual order, usually

[12:41:53.0000] <SamB>
can CSS set the tab order?

[12:41:57.0000] <TabAtkins>
With even a modicum of care, this'll give you a *more useful* tab ordering, as the useful stuff is at the front.

[12:41:58.0000] <Hixie>
so if it's reorderd, you want a different tab order than if it's not

[12:42:10.0000] <Hixie>
SamB: in theory, but not in practice, as far as i know

[12:42:18.0000] <TabAtkins>
It's a flaw that tab order is affected by whether you want your sidebar on the left or on the right.

[12:42:29.0000] <TabAtkins>
SamB: Yeah, there's a property for it, but no implementations.

[12:42:34.0000] <SamB>
Chrome might want to practice that ;-)

[12:42:51.0000] <Hixie>
TabAtkins: if you sidebar is on the left, surely you want it earlier in the tab order than if it's on the right. no?

[12:43:04.0000] <SamB>
TabAtkins: hmm, yes, it's a flaw, but at least it's easy for the user to understand

[12:43:09.0000] <TabAtkins>
No, you almost always want sidebar to tab after content.

[12:43:16.0000] <TabAtkins>
As it has less important links in it.

[12:43:43.0000] <TabAtkins>
Note that 'order' is basically a vastly easier, less hacky way to do reordering that you can already do today with floats and negative margins.

[12:43:51.0000] <TabAtkins>
The old "holy grail" layouts.

[12:44:03.0000] <Hixie>
take www.whatwg.org/

[12:44:12.0000] <Hixie>
would it be wrong to use CSS to reorder the links?

[12:44:20.0000] <SamB>
... is it possible to say "I want this element's contents to have generally earlier tab order than that other element" in user CSS?

[12:44:22.0000] <Hixie>
seems like it's purely presentational what order they come in

[12:44:25.0000] <SamB>
even if nothing will actually do it

[12:44:43.0000] <Hixie>
SamB: there's a nav-index property in css3 ui, but nobody implements it currently as far as i know

[12:45:00.0000] <TabAtkins>
Hixie: If the ordering is changed because a different order makes sense, then that different order probably makes sense in all media, and should be in the source.

[12:45:05.0000] <SamB>
I mean as opposed to having to do something that matches each tabable element

[12:45:26.0000] <Hixie>
TabAtkins: i change the order randomly based purely on aesthetic grounds, though. the logical order is unrelated to what order they are shown in.

[12:45:42.0000] <Hixie>
TabAtkins: i mean, it seems to me like this is a perfect use of flex 'order'

[12:45:51.0000] <TabAtkins>
Then it doesn't matter, except insofar as using the various CSS methods wont' affect tab order, so it'll be confusing.

[12:45:58.0000] <Hixie>
right

[12:46:18.0000] <SamB>
TabAtkins: if the tab order bears no resemblance to the visual order whatever, and there are more than a handful of items, users are not going to be happy about that

[12:46:22.0000] <Hixie>
hence it seems like you'd want it to follow rendering order...

[12:46:24.0000] <TabAtkins>
This isn't an order-specific thing, though.  Flexbox can lay things out right-to-left, or bottom-to-top.  Grid can put things in any order whatsoever.

[12:46:48.0000] <TabAtkins>
The correct solution, which we want to pursue at some point in the future, is a more global switch that says "use a visual tab order".

[12:47:11.0000] <Hixie>
i guess i don't understand why you wouldn't want that to be the default

[12:47:23.0000] <TabAtkins>
Because it's not the default, and we can't change it to be the default, probabyl.

[12:47:30.0000] <SamB>
Hixie: well, having a switch would be an improvement either way

[12:47:33.0000] <Hixie>
it's the default in firefox, as far as i can tell

[12:47:42.0000] <Hixie>
why wouldn't we be able to make it the spec default?

[12:47:48.0000] <SamB>
actually I think it's BETTER to say that the default is unspecified

[12:47:57.0000] <TabAtkins>
What is the default in Firefox?  Having it affected by 'order'? Or having it be visual order?

[12:48:02.0000] <Hixie>
yeah

[12:48:10.0000] <SamB>
because the user might change it anyway

[12:48:21.0000] <SamB>
in their userstyle

[12:48:34.0000] <Hixie>
TabAtkins: hence my question above about firefox vs chrome on http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2850

[12:48:40.0000] <SamB>
(without using !important)

[12:49:19.0000] <Hixie>
anyway i guess i can leave the default order undefined for now

[12:49:29.0000] <Hixie>
since it's mostly a UI issue

[12:49:47.0000] <SamB>
/me eagerly anticipates grid

[12:50:27.0000] <SamB>
hmm, though, can that steal nested elements from their parents?

[12:50:47.0000] <TabAtkins>
Hixie: Okay, FF adjust tab-index with 'order', but not anything else.  It's violating the spec.

[12:51:08.0000] <TabAtkins>
For example, check out http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2851

[12:51:38.0000] <SamB>
it's not as if the HTML spec doesn't wilfully violate dozones of other specs ;-)

[12:51:39.0000] <TabAtkins>
Like I said, this is *not* an 'order'-specific issue, and we shouldn't try to hack 'order' by itself.

[12:51:53.0000] <Hixie>
yeah i don't think it should be defined per 'order'

[12:52:31.0000] <SamB>
what else is there at the moment?

[12:52:48.0000] <Hixie>
my real question here is when you've got a control focused that isn't in the tab order at all (tabindex=-1), and you hit tab, should i pick the next control in the dom tree, or the next control in the rendering tree?

[12:52:56.0000] <TabAtkins>
If you want HTML to say that tab ordering should be visual, go for it.  Won't affect me at all.

[12:53:13.0000] <TabAtkins>
DOM tree is how it works today.

[12:53:47.0000] <Hixie>
(right now it's "should follow platform conventions" for the tab order of controls that are in the order, fwiw)

[12:54:17.0000] <SamB>
that sounds like a sane default

[12:54:27.0000] <Hixie>
DOM tree is how it works today _in chrome_. in firefox, it's not.

[12:54:40.0000] <TabAtkins>
Are there any FF exceptions besides 'order'?

[12:54:40.0000] <SamB>
whatever "platform conventions" might mean ;-)

[12:54:45.0000] <Hixie>
(see e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2852 )

[12:54:52.0000] <Hixie>
dunno

[12:54:59.0000] <Hixie>
i can't think of any other ways to affect rendering tree order

[12:55:09.0000] <SamB>
TabAtkins: what else is there that unambiguously reorders things in the rendering tree?

[12:55:24.0000] <SamB>
in firefox, I mean

[12:55:37.0000] <SamB>
what does IE do?

[12:55:37.0000] <Hixie>
(flex-direction just reverses the order for layout, but the rendering tree itself is still the same as the dom tree, right? same with floats, abs pos...)

[12:55:39.0000] <TabAtkins>
SamB: The notion of "reorders" is ambiguous itself.  Does flex-direction:row-reverse reorder things?

[12:56:01.0000] <SamB>
TabAtkins: I'd lean towards "no"

[12:56:09.0000] <TabAtkins>
And any notion of 'order' pretty much goes out the window when you involve Grid.

[12:56:24.0000] <TabAtkins>
(Grid does define an ordering that is used by some things in the spec, but it's fairly arbitrary.)

[12:56:36.0000] <Hixie>
part of the problem with using the DOM tree is that the focusable areas aren't always _in_ the DOM tree, or they map to multiple elements, or multiple areas map to one element, which makes it hard to use the DOM tree

[12:56:59.0000] <SamB>
TabAtkins: I dunno, there are some typical notions of order in tables

[12:57:35.0000] <TabAtkins>
SamB: Tables dont' overlap cells, though.  And they're clearly row-major.

[12:57:46.0000] <TabAtkins>
Hixie: I get that.

[12:58:02.0000] <SamB>
I meant abstract tables, not necessarily HTML tables

[12:58:18.0000] <SamB>
but yes, abstract tables don't overlap cells either

[12:58:43.0000] <Hixie>
i guess i can just use the control group order, that's a (more or less) defined order that handles this already

[12:59:08.0000] <Hixie>
(HTML tables actually can overlap cells in edge cases)

[12:59:35.0000] <TabAtkins>
"can", but it's allowed to not overlap them.

[13:00:55.0000] <Hixie>
in the HTML model, they are just defined to overlap.

[13:01:00.0000] <Hixie>
how it renders is a CSS issue.

[13:01:01.0000] <Hixie>
:-)

[13:01:15.0000] <SamB>
TabAtkins: I don't see a way they could not overlap

[13:01:38.0000] <SamB>
are you proposing that the overlapping bit be shoved into a different "column"?

[13:01:40.0000] <TabAtkins>
You just push the columns over more.  It's nasty.

[13:02:08.0000] <Hixie>
btw that's one of the things we should drop when we get around to updating the table spec

[13:02:11.0000] <Hixie>
all the browsers do overlap

[13:02:16.0000] <SamB>
but in any case, well-behaved HTML tables do not perpetrate such evil

[13:02:53.0000] <SamB>
Hixie: is this actually *allowed*, or is the behavior just specified-ish?

[13:03:09.0000] <Hixie>
how do you mean?

[13:03:21.0000] <SamB>
can conforming documents have overlapping table cells?

[13:03:28.0000] <Hixie>
conforming documents can't, no.

[13:03:28.0000] <Ms2ger>
I think not

[13:03:40.0000] <Hixie>
but it's not "just specified-ish". it's specified.

[13:03:49.0000] <Hixie>
in painful detail.

[13:04:31.0000] <SamB>
Hixie: it sounded like there was an alternative behavior here that you wanted to drop because nobody actually implements that alternative anyway

[13:05:23.0000] <Hixie>
CSS table rendering is only vaguely defined. (or at least, was only so, last i checked)

[13:05:43.0000] <Hixie>
one of the ways it's vague is that handling of overlapped cells involves multiple permissible renderings.

[13:05:55.0000] <Hixie>
i'm saying we should tighten it down to just allow what is commonly implemented.

[13:06:18.0000] <TabAtkins>
Huh.  Am I doing something wrong here? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2854

[13:06:31.0000] <TabAtkins>
Yeah, when we actually define table rendering, that shit'll get thrown out.

[13:06:44.0000] <TabAtkins>
My rowspans and colspans dont' seem to work in that table.

[13:06:55.0000] <SamB>
hmm, you mean like it would be allowed to just let one table cell "own" that gridcell and the other table cell(s) could be potentially non-rectangular?

[13:06:58.0000] <Hixie>
TabAtkins: you have your rowspan and colspan backwards

[13:07:11.0000] <Hixie>
TabAtkins: (you can tell that they're working, the top right cell is a few pixels wider than the one below it)

[13:07:25.0000] <Hixie>
SamB: what do you mean by "allowed"?

[13:07:45.0000] <Hixie>
SamB: i'm not proposing any authoring conformance criteria changes

[13:07:46.0000] <TabAtkins>
Ah, durp.

[13:07:47.0000] <SamB>
I mean under the current unspecified table rendering

[13:07:58.0000] <Hixie>
SamB: i forget what the precise allowed renderings are

[13:10:41.0000] <Hixie>
hmmm

[13:10:56.0000] <Hixie>
so normally, tabbing around a dialog jumps you to the start from the end

[13:11:04.0000] <Hixie>
but what if you're a <dialog> inside an iframe?

[13:13:52.0000] <SamB>
hmm, I don't really know what <dialog> is, but why do you mention the iframe?

[13:14:39.0000] <Hixie>
well normally if you have an iframe, tabbing from the last thing in the iframe tabs to the thing after the iframe in the parent doc

[13:15:04.0000] <Hixie>
so if we have a dialog in the iframe, does tabbing from the end return you to the top of the dialog, as if it was a real separate window, or does it tab you out of the doc to the parent doc

[13:18:07.0000] <SamB>
maybe it should be possible to choose?

[13:18:22.0000] <Hixie>
how?

[13:18:38.0000] <SamB>
well, perhaps something on the iframe?

[13:18:42.0000] <Hixie>
(making things an option is rarely the sign of good design, btw)

[13:18:46.0000] <Hixie>
when would you use one vs the other?

[13:18:59.0000] <SamB>
/me goes to read up on dialog ...

[13:25:24.0000] <SamB>
hmm, dialogs in iframes sound kind of ... confusing to start with

[13:25:30.0000] <Hixie>
yeah, no kidding

[13:25:42.0000] <Hixie>
probably best to allow tabbing out

[13:26:02.0000] <SamB>
yes, probably

[13:57:47.0000] <SamB>
hmm, this whole "commands" thing seems kind of odd

[13:58:06.0000] <SamB>
what, exactly, is it for?

[14:04:31.0000] <SimonSapin>
Hixie: I’m importing CSS2.1 commit history from CVS. There are commits by ijacobs, ihickson, and ian. Do you know who is the third?

[14:04:54.0000] <Hixie>
heh

[14:05:02.0000] <Hixie>
sample edits?

[14:05:51.0000] <SimonSapin>
all from 1997

[14:06:08.0000] <Hixie>
get a copy from then and look at the editor's list?

[14:08:31.0000] <Hixie>
i bet it's ijacobs. are there any edits from ijacobs before the last edit from ian?

[14:09:05.0000] <Hixie>
try to correlate edits to what is written in https://lists.w3.org/Archives/Member/w3c-css-wg/1997JulSep/0227.html

[14:09:30.0000] <Hixie>
see if any of the edits mention san jose around the time of https://lists.w3.org/Archives/Member/w3c-css-wg/1997JulSep/0146.html

[14:10:19.0000] <Hixie>
see if there's any chapter-10 edits that correspond to the same timeframe as https://lists.w3.org/Archives/Member/w3c-css-wg/1997OctDec/0056.html

[14:11:18.0000] <SimonSapin>
There are commits from ijacobs both before and after the time range of commits from ian, but not in the middle

[14:11:23.0000] <SimonSapin>
It’s probably him, thanks

[14:12:07.0000] <Hixie>
np

[14:46:38.0000] <tantek>
Hixie, you didn't join CSSWG til at least 1998, how would you have CVS edits in 1997?

[14:48:31.0000] <Hixie>
i didn't join til 2000, i didn't even join www-style until dec 1998 iirc

[14:59:06.0000] <tantek>
Hixie that sounds about right.

[15:24:47.0000] <Hixie>
fascinating

[15:24:56.0000] <Hixie>
tabbing from the first input in the following case leads you to the second input: <input tabindex=-1><input tabindex=2><input tabindex=1>

[15:25:09.0000] <Hixie>
but in the following case, it leads you to the third: <input tabindex=-1><iframe srcdoc="<input tabindex=2><input tabindex=1>">

[15:25:35.0000] <Hixie>
(in chrome)

[15:25:49.0000] <Hixie>
(in firefox, it leads you to the viewport of the iframe, which is what the spec will actually require)

[15:26:06.0000] <Hixie>
(assuming there's no dialogs around)

[15:30:58.0000] <Hixie>
tantek: in retrospect, if i'd known then that 16 years later i'd be speccing focus navigation around iframes, something that should have been specced in HTML4 in 1997 at the latest, i dunno if i'd have bothered to subscribe. :-P

[15:31:31.0000] <tantek>
Hixie, I believe the expression you're looking for is, ignorance was bliss.

[15:32:15.0000] <Hixie>
i think it's more "ignorance leads to poor decisions" :-P


2014-02-27
[16:30:02.0000] <Hixie>
tantek: fwiw, http://www.whatwg.org/specs/web-apps/current-work/#sequential-focus-navigation is what i came up with. nothing new, particularly (other than <dialog> support), as far as authors are concerned. But it should provide us with a good framework for adding e.g. scoping. It doesn't currently support 'nav-index', wasn't sure how to integrate that with tabindex, so I left it out for now. File a bug if there's implementation interest in nav-index such tha

[16:30:56.0000] <SamB>
"[...] in nav-index such tha"?

[16:37:20.0000] <tantek>
Hixie, better to leave out nav-index until there's both a shown need and interest in implementing. It was in CSS3-UI CR for a LONG time and no one implemented. So I consider it dead unless 2+ implementers come to me asking for it.

[16:37:52.0000] <tantek>
thanks for that link. I'll track it in the nav-index page on the CSSWG wiki

[18:14:08.0000] <Hixie>
SamB: such that I should spec it, sorry

[18:14:22.0000] <Hixie>
tantek: k, sounds good

[21:49:28.0000] <wirepair>
why does angularjs rub me the wrong way so much... is this really what the web is going to become?

[22:21:39.0000] <filR>
wirepair: probably. but perhaps not in the form of angularjs. some of the features are coming to html natively. take a look at http://www.polymer-project.org/platform/shadow-dom.html < basically a directive

[22:24:47.0000] <wirepair>
ah yes, been meaning to read up on shadow dom stuff

[22:37:40.0000] <wirepair>
now that makes a lot more practical sense

[02:33:30.0000] <zcorpan>
jgraham: do we have a policy for tests that use the Ahem font? use csswg-style <meta>?

[02:37:26.0000] <zcorpan>
/me finds http://testthewebforward.org/docs/test-templates.html

[02:46:11.0000] <shiongssd>
m

[02:52:59.0000] <zcorpan>
w3c bugzilla down? MikeSmith?

[03:09:06.0000] <jgraham>
zcorpan: I don't think so?

[03:09:38.0000] <jgraham>
zcorpan: I certainly don't consider the CSSWG requirements necessary

[03:11:00.0000] <zcorpan>
hmm, ok. but it's cool to use the ahem font and assume that it's installed?

[03:11:30.0000] <jgraham>
I would say so. We should probably document it as a dependency or something

[03:12:54.0000] <MikeSmith>
zcorpan: yeah the w3c bugzilla host is having some problems. The systems team's working on it

[03:13:18.0000] <zcorpan>
MikeSmith: ok thx

[03:41:20.0000] <zcorpan>
jgraham: what is the status of .sub.html in wptserve?

[03:46:54.0000] <jgraham>
zcorpan: Unimplemented

[03:47:04.0000] <jgraham>
zcorpan: I could have a look now if you need it

[03:47:37.0000] <zcorpan>
i was going to suggest using it in https://critic.hoppipolla.co.uk/r/828

[03:56:46.0000] <jgraham>
https://critic.hoppipolla.co.uk/r/901

[04:00:48.0000] <zcorpan>
jgraham: do i read it right that .html.sub works but .sub.html does not?

[04:01:52.0000] <jgraham>
zcorpan: The other way around

[04:03:07.0000] <zcorpan>
oh ok

[04:05:32.0000] <zcorpan>
thanks

[04:06:38.0000] <MikeSmith>
jgraham: FYI during the test-writing session yesterday at the WebDriver f2f, one of the people there commented that he didn't like it that critic was "forging" his name (and address?) on the e-mail notifications it sent out. I guess he was surprised to see the message was sent out automatically from critic  without him having taken any direct action except creating a github PR

[04:07:40.0000] <MikeSmith>
I didn't really know what to tell him except *shrug*

[04:08:51.0000] <MikeSmith>
github basically does the same thing already, with its notifications. I guess it's just less surprising because people are used to it already

[04:09:23.0000] <jgraham>
Yeah, I don't know what to say, really

[04:09:53.0000] <MikeSmith>
though github does also send them with foo⊙ngc

[04:11:13.0000] <MikeSmith>
jgraham: yeah I explained more about it the setup to him and that seemed to alleviate the heartburn some

[04:11:40.0000] <jgraham>
MikeSmith: OK, well feel free to put him in contact with me if there are any remaining issues

[04:11:45.0000] <MikeSmith>
ok

[04:13:01.0000] <jgraham>
zcorpan: OK, that is pushed

[04:13:36.0000] <zcorpan>
jgraham: awesome

[04:36:47.0000] <zcorpan>
i wonder if <summary>.click() should do anything

[04:37:29.0000] <zcorpan>
i think the spec says it does nothing

[04:48:57.0000] <MikeSmith>
lots of interesting info about screen-reader usage at http://webaim.org/projects/screenreadersurvey5/

[04:49:05.0000] <MikeSmith>
via SteveF

[04:49:13.0000] <MikeSmith>
including mobile usage

[04:49:25.0000] <MikeSmith>
and browsers

[04:49:37.0000] <MikeSmith>
and bits like http://webaim.org/projects/screenreadersurvey5/#finding

[04:50:20.0000] <MikeSmith>
which suggests it's important to put good headings into documents you write

[05:05:19.0000] <MikeSmith>
<meta name="apple-mobile-web-app-title" content="Some App Name"> appears to be supported in iOS Safari and very widely used, but completely undocumented by Apple

[05:05:52.0000] <MikeSmith>
which strictly speaking per the spec would mean it fails to meet the registration requirements in the spec

[05:06:19.0000] <MikeSmith>
but it seems dumb to treat it as an error

[05:06:41.0000] <MikeSmith>
*document-conformance error

[07:23:07.0000] <zcorpan>
jgraham: https://critic.hoppipolla.co.uk/showcomment?chain=2839 (in case hallvord wants/needs assistance with rebasing in critic or with wptserve...)

[07:25:40.0000] <zcorpan>
woot i've caught up with critic email backlog

[07:29:51.0000] <Ms2ger>
zcorpan++

[07:30:27.0000] <zcorpan>
hmm i tried to set up a filter to ignore custom-elements/ but it doesn't match anything

[08:38:42.0000] <dglazkov>
good morning, Whatwg!

[14:50:25.0000] <Ms2ger>
Dave Raggett had excellent foresight: https://twitter.com/mattur/status/438820509086924800

[15:04:57.0000] <Hixie>
"The HTML that Tim invented was strongly based on SGML (Standard Generalized Mark-up Language)" is rather revisionist, isn't it? I mean, I would buy "influenced by", but it wasn't even attempting to be SGML proper until DanC came along.

[15:05:03.0000] <Hixie>
(from http://www.w3.org/People/Raggett/book4/ch02.html)

[15:06:52.0000] <Hixie>
(linked to from the tweet above)

[15:08:33.0000] <erlehmann>
Hixie what is this? http://www.whatwg.org/specs/web-apps/current-work/multipage/section-server-sent-events.html

[15:08:33.0000] <erlehmann>
<p>The page you are looking for is no longer available at this URL.</p>

[15:08:36.0000] <erlehmann>
is there a redirect?

[15:09:02.0000] <Hixie>
that links works for me... try again?

[15:10:39.0000] <erlehmann>
; curl -s http://www.whatwg.org/specs/web-apps/current-work/multipage/section-server-sent-events.html | grep Broken

[15:10:40.0000] <erlehmann>
<title>Broken link</title>

[15:10:46.0000] <erlehmann>
is there some type of IP filtering going on?

[15:11:38.0000] <Hixie>
no, it uses JS to redirect you

[15:11:40.0000] <erlehmann>
; curl -sI http://www.whatwg.org/specs/web-apps/current-work/multipage/section-server-sent-events.html | grep 404

[15:11:40.0000] <erlehmann>
HTTP/1.1 404 Not Found

[15:11:43.0000] <erlehmann>
oh lawl

[15:11:59.0000] <Hixie>
because we don't know ahead of time what the url should be -- we look at the fragment identifier

[15:12:15.0000] <erlehmann>
i see.

[15:12:18.0000] <erlehmann>
pages move around in sections.

[15:12:30.0000] <Hixie>
other way around but yeah

[15:12:40.0000] <erlehmann>
yeah

[15:12:42.0000] <erlehmann>
:3

[15:12:48.0000] <erlehmann>
okay, sorry bothering you

[15:12:50.0000] <Hixie>
np

[15:13:08.0000] <Hixie>
(there is also ip filtering going on, but you have to hit the server pretty hard for quite a long time for my script to even notice you and filter you)

[15:13:17.0000] <erlehmann>
ah

[15:13:34.0000] <erlehmann>
say, if you are there, how could i move forward with my older proposal of having fragment identifiers for media elements contain media fragments?

[15:13:38.0000] <Hixie>
(for some reason there are bots out there that act really weird)

[15:13:49.0000] <Hixie>
don't they already?

[15:13:56.0000] <Hixie>
you mean like <video src="">?

[15:13:56.0000] <erlehmann>
like, i have a polyfill for something like http://example.org/#video?t=abc

[15:14:04.0000] <erlehmann>
like, i have a polyfill for something like http://example.org/#video?t=1:00

[15:14:12.0000] <Hixie>
oh you mean the fragment identifier of the page forwarding to the first video element?

[15:14:32.0000] <erlehmann>
no, i would like to generally address subresources

[15:14:42.0000] <erlehmann>
i did look at the data and '?t=' in urls or ids is very rare.

[15:14:51.0000] <erlehmann>
close to nonexistent, i think.

[15:14:59.0000] <erlehmann>
and one could always use another delimiter

[15:15:30.0000] <erlehmann>
hixie, here is my demo http://daten.dieweltistgarnichtso.net/src/media-fragments-html-polyfill/

[15:15:49.0000] <erlehmann>
is there an appropriate mailing list? the response on the whatwg mailing list was not much.

[15:16:20.0000] <erlehmann>
i *know* there are people building stuff like that in js all the time and i think they would not need to

[15:16:30.0000] <erlehmann>
and „let me link to this podcast“ would be nicer if the link would be on the page

[15:16:35.0000] <Hixie>
ah i see, the fragid forwarding to a generic element in the page, basically?

[15:16:37.0000] <erlehmann>
so how would i go to further that proposal?

[15:16:50.0000] <Hixie>
the short answer is that what matters is whether any browser vendors cares

[15:16:58.0000] <erlehmann>
so whom should i talk to?

[15:17:00.0000] <Hixie>
if you got no response on the list, then they probably don't

[15:17:06.0000] <Hixie>
did i reply to your e-mail or is it still in my pile?

[15:17:13.0000] <erlehmann>
let me check

[15:19:00.0000] <erlehmann>
Hixie thanks for asking. you even converted it into a bug! https://www.w3.org/Bugs/Public/show_bug.cgi?id=23492

[15:19:11.0000] <erlehmann>
Target Milestone: 	Needs Impl Interest

[15:19:20.0000] <erlehmann>
i have author interest (lots of podcasters)

[15:19:51.0000] <erlehmann>
is there a media elements fun mailing list?

[15:20:14.0000] <Hixie>
whatwg⊙wo

[15:20:51.0000] <Hixie>
but basically the next step is getting implementation experience

[15:21:03.0000] <Hixie>
which means getting implementation interest

[15:21:05.0000] <erlehmann>
so i need to convince someone, i assume?

[15:21:44.0000] <erlehmann>
i have no idea how to approach this. my contributions to software projects are usually small patches.

[15:21:48.0000] <Hixie>
well... i'm always a bit reluctant to actually canvas for features. i always feel like if you have to convince someone, it probably means it's not important enough to do in the first place. (As opposed to features people immediately agree are a good idea.)

[15:21:53.0000] <erlehmann>
this would require real world testing and instrumentation.

[15:22:04.0000] <Hixie>
but yeah, convincing multiple browser vendors to do it would be one way

[15:22:27.0000] <Hixie>
or you could go the adobe route and just implement it for each vendor and try to convince them to take the patch

[15:22:39.0000] <erlehmann>
does that work?

[15:22:49.0000] <erlehmann>
i mean, the patches are probably small.

[15:22:49.0000] <Hixie>
it has sometimes worked for them

[15:22:59.0000] <Hixie>
personally i find it a bit distasteful

[15:23:01.0000] <astearns__>
I thought that was the Microsoft pointer-events approach :)

[15:23:08.0000] <Hixie>
yeah, microsoft have done this too

[15:23:26.0000] <Hixie>
i mean, like i said, i feel that if a feature is worth it, people will just implement it without you having to convince them

[15:23:42.0000] <erlehmann>
people implement it all the time in js

[15:23:55.0000] <erlehmann>
badly, broken and non-accessible if you have noscript. only jumping to the first element.

[15:24:15.0000] <Hixie>
yeah

[15:24:24.0000] <Hixie>
it certainly doesn't seem dumb to me

[15:24:28.0000] <Hixie>
:-)

[15:24:36.0000] <erlehmann>
and i think since embedded media is such an important part of html, that could work in a general case

[15:24:45.0000] <Hixie>
(hence filing the bug to track it, rather than saying "I don't think this is a good idea")

[15:24:48.0000] <erlehmann>
other formats have sub-fragments too, i think

[15:24:57.0000] <erlehmann>
ah!

[15:24:58.0000] <erlehmann>
i see.

[15:25:07.0000] <Hixie>
i would caution against trying to be too generic

[15:25:13.0000] <Hixie>
a lot of features die that way

[15:26:17.0000] <erlehmann>
i would just want to apply the media fragment to the embedded resource. but in the end, i could also settle for ?t=hh:mm:ss or something equally simple (though underwhelming, after all, the media fragment implementor experience is there)

[15:27:34.0000] <erlehmann>
so which code base is supposed to be the easiest to work on? blink seems like a horrid mess (also they refer internal stuff i cannot read all the time in their bugtracker), is webkit or mozilla more accessible?

[15:27:49.0000] <erlehmann>
(are there more implementors with open code?)

[15:27:57.0000] <Hixie>
blink doesn't have an internal bugtracker, do you mean webkit?

[15:28:18.0000] <erlehmann>
chromium

[15:28:18.0000] <erlehmann>
probably

[15:28:29.0000] <Hixie>
chromium doesn't have an internal bugtracker

[15:28:38.0000] <Hixie>
blink and webkit are very similar codebases, they only forked recently

[15:28:40.0000] <erlehmann>
oh?

[15:28:46.0000] <erlehmann>
let me look up what i meant

[15:29:57.0000] <erlehmann>
https://code.google.com/p/chromium/issues/detail?id=93841

[15:29:59.0000] <erlehmann>
> Report link: http://go/crash/reportdetail?reportid=06bbd629efcb5c11

[15:30:05.0000] <erlehmann>
i assume /go/ is their internal bugtracker

[15:30:59.0000] <Hixie>
oh that's just the crash log server

[15:31:09.0000] <Hixie>
those are always confidential (so's mozilla's, for example)

[15:31:17.0000] <Hixie>
because they potentially contain user PII

[15:32:16.0000] <erlehmann>
PII?

[15:32:20.0000] <erlehmann>
Private something?

[15:32:30.0000] <Hixie>
Personally identifiable information

[15:32:30.0000] <erlehmann>
ooooookay, also my DNS is messed up

[15:32:31.0000] <erlehmann>
wtf

[15:33:09.0000] <erlehmann>
no it isn't. something has taken over my browsers „cannot find URL“ mechanism.

[15:33:11.0000] <Hixie>
(crash log servers tend to be under very tight control, so that only the engineers that actually need to be able to see the data from a particular crash can see it.)

[15:33:45.0000] <erlehmann>
need to know basis

[15:33:46.0000] <erlehmann>
i understand completely

[15:34:02.0000] <erlehmann>
so the question still stands. what code base would you consider accessible?

[15:36:40.0000] <erlehmann>
oh, it just redirects go to go.com

[15:36:40.0000] <erlehmann>
no hijacking going on

[15:37:36.0000] <Hixie>
i expect they're all about the same... hugely complicated and intimidating :-)


2014-02-28
[16:09:38.0000] <gsnedders>
https://github.com/html5lib/html5lib-python/issues/143

[16:10:10.0000] <gsnedders>
Are data-* attributes safe from the POV of sanitizers?

[16:10:27.0000] <gsnedders>
I mean, so the spec requires that UAs do nothing for all of them, which should make them safe, right?

[16:21:20.0000] <MikeSmith>
unless some UAs do actually do something with them anyway

[16:21:40.0000] <MikeSmith>
which they shouldn't be doing but who knows

[16:22:53.0000] <Hixie>
gsnedders: for some definition of "safe", yes

[16:23:17.0000] <Hixie>
gsnedders: but e.g. maybe the page the markup is being embedded into has a script that uses data-* and has a vulnerability, in which case...

[16:23:52.0000] <Hixie>
i would avoid the word "safe" and always describe the attack scenario you're trying to avoid

[16:25:30.0000] <gsnedders>
Hixie: Well, surely this is true of any output of a sanitizer? If the page it is put into does stuff with script, it can be used for XSS.

[16:25:49.0000] <Hixie>
yep

[23:07:04.0000] <hsivonen>
From morning bugmail: "I liked that Firefox 27 would allow me to see many occurrences of

[23:07:08.0000] <hsivonen>
U+FFFD REPLACEMENT CHARACTER"

[23:07:42.0000] <hsivonen>
https://xkcd.com/1172/ is so true

[23:51:20.0000] <SamB>
/me doesn't really see there being a whole lot of point in using data-* in embedded HTML if a script, UA, or add-on isn't going to be looking at them ... well, or CSS ...

[23:54:19.0000] <Ms2ger>
UAs and add-ons shouldn't look at them

[23:54:36.0000] <Ms2ger>
They're just for script/style from the website itself

[00:58:38.0000] <zcorpan>
argh, it seems it's not possible to reopen issues in critic if the file the issue was about was removed

[06:06:22.0000] <zcorpan>
did blob.close(); blob.close(); throw before?

[06:13:22.0000] <jgraham>
I thought it didn't now?

[06:13:31.0000] <jgraham>
Or have I forgotten the way this changed?

[06:22:26.0000] <darobin>
blob.close(), blob.close(), you're my blob.close()

[06:24:57.0000] <zcorpan>
http://dev.w3.org/2006/webapi/FileAPI/#close-method

[06:25:35.0000] <zcorpan>
darobin: manboy?

[06:26:03.0000] <Ms2ger>
zcorpan, I think it was undefined before

[06:26:10.0000] <darobin>
zcorpan: Sex Bomb :)

[06:26:50.0000] <zcorpan>
darobin: ah

[06:27:25.0000] <zcorpan>
(i guess manboy lyrics is the other way around)

[06:29:25.0000] <darobin>
I don't know that song

[13:35:31.0000] <Hixie>
people interested in the HTML parser should post feedback on https://www.w3.org/Bugs/Public/show_bug.cgi?id=24833

[15:25:08.0000] <zewt>
Your browser's current font size is not supported. Please reset to the standard font size. <- google, always setting such high standards for the web

[15:26:36.0000] <Hixie>
i have to admit i don't understand what docs is doing with that

[15:28:05.0000] <zewt>
that was gmail for me

[15:28:06.0000] <zewt>
er

[15:28:07.0000] <zewt>
maps

[15:29:51.0000] <jsbell>
Needless to say, searching on 'new' isn't helpful :P

[15:40:15.0000] <SamB>
/me guesses those ideas to fix all frameset URLs forever never actually went anywhere?

[15:46:21.0000] <Hixie>
zewt: maps? weird

[15:46:24.0000] <Hixie>
zewt: the new maps?

[15:54:38.0000] <zewt>
no

[15:55:23.0000] <Hixie>
zewt: in that case, good news!

[15:55:30.0000] <Hixie>
zewt: the new maps fixes this

[15:55:38.0000] <zewt>
new maps was horribly slow when I tried it

[15:55:45.0000] <Hixie>
try it again

[15:57:49.0000] <SamB>
/me had trouble finding Help in new maps ...